자바스크립트 코딩 테스트

Author: 주니용

 

요새 IT직군에서 알아주는 회사들은 대부분 입사 전 코딩 테스트를 필수로 치루게 된다.

나도 많은 코딩 테스트를 치뤄봤지만, 서버를 주로 개발한 사람의 입장으로서 자바를 코딩 테스트 언어로 많이 선택했었다.

내가 아는 한도에서 적어도 자바스크립트를 코딩 테스트 언어로 사용하는 이유는 다음과 같을 것이다.

 

• 편해서 또는 눈에 익어서
• 오토캐스팅이 되서
• 소스코드를 빠르게 작성하기 위해서
• 컴파일러 설치를 안해도 되서

 

현재도 그렇지만, 아직까지도 웹 생태계는 지속적으로 변하고 있다.

지금의 추세는 자바스크립트를 기본으로 한 프레임워크인 리-뷰-앵(React, Vue, Angular)의 시대라고 해도 과언이 아니다.

그래서 그런지 웹 개발을 할 수 있다는 사람이 주변에 너무나도 많고,

그 때문에 선택하는 언어가 자바를 제치고 자바스크립트라고 해도 된다.

 

위에서 말한 편하다는 이유가 이에 상통한다.

웹 개발의 기본이 W3(HTML, CSS, JavaScript)이고 화면에서의 움직이는 모든 컨트롤은 자바스크립트가 담당하기 때문이다.

(사람은 이쁜 것에 매료될 수 없다는 것이 정설)

물론, CSS도 중요하고 백그라운드 이미지나 아이콘, 폰트도 무시할 수 없는 것이 규칙이다.

하지만, 자바스크립트는 위에서 말한 조건인 사용하기 편하고 눈에 익는 것이 특장점이다.

속도가 느린 것도 아니다. 느렸다면 프레임워크를 만들었어도 느렸을 것이다.

 

또 하나의 장점이 있는데, 자바는 일일히 객체별로 생성을 해주고 그 생성된 객체의 프로퍼티를 각각 정해주어야 하는 반면, 자바스크립트는 그럴 필요가 없다. 내가 만들고 싶은대로 만들어서 사용 가능하다. 예시를 한 번 살펴보자.

 

JSON

Array

 

 

이렇게 선언만 하여도 String과 int같은 정수형 타입의 선언이 가능하다.

 

자바랑 비교하면 너무 차이가 많이 난다. 

 

물론 명시적으로 타입을 선언하고 사용하는 개발자들에게 자바는 선호되는 언어이다.

하지만 자바스크립트의 강점은 위에서 말한 2, 3번과 같은 장점이 있어서 코딩테스트용으로 적절하다고 생각한다.

 

---

 

서론이 너무 길었다. 요새 코딩 테스트의 전형은 Codility, HackerRank, TopCoder 등과 같이 알고리즘 코딩 테스트를 치룰 수 있는 좋은 사이트들에 위탁을 하여 진행하는 것으로 알고 있다. 물론, 회사 내에서 자체적으로 개발한 솔루션을 가지고 있어 역량테스트 방법이 다를 수도 있다. 하지만 대다수의 테스트는 위 3개의 사이트에서 진행이 되고 있다. 

 

위 사이트 들에서 제일 중요한 것은 사실 기준 점수이다. 코드가 효율적으로 돌아가던지를 떠나, 먼저 원하는 결과값이 도출되어야 한다.

그 이후에서야 지원자의 꼼꼼함과 섬세함, 성향 등을 유추해보고 분석하는 것이 다음 과정이라고 할 수 있다. 

지금 이 글에서 작성하는 내용이 Main이 아닌 Sub가 될 수도 있다는 것을 유념하였으면 좋겠다.

 

var, let, const

 

자바스크립트에는 3개의 변수가 있다고 이전 글에서 작성하였던 적이 있다.

여태까지 나도 그랬지만, 해당 개념에 대해 명확히 수립이 되지 않았을 때는 규칙과 순서없이 뒤죽박죽으로 섞어서 사용했던 적이 허다하다.

하지만 이러한 점은 나중에 정밀하게 코드 리뷰할 때의 마이너스의 요인이 될 가능성이 있다.

아래의 샘플 코드를 보자.

 

 

해커랭크에서 풀 수 있는 문제 중 하나에 대한 풀이코드이다.

코드에는 var와 let을 모두 선언해두었다. 

또, 루프문에는 var가 들어가있는 것을 확인할 수 있다.

여기서는 이와 같이 변경되면 좋을 듯 하다.

이렇게 var를 다른 변수 예약어와 혼용해서 사용하게 될 경우 코드를 리뷰하는 사람들이 점수를 짜게 주는 요인 중의 하나가 될 수 있다.

 

세미콜론(;)

 

자바의 경우는 컴파일러가 작동하여 세미콜론이 붙어있지 않은 경우 오류를 발생시킨다. 

하지만 자바스크립트는 이에 비해 자유로운 부분이 있다. 붙여도 되고 안붙여도 크게 지장이 없다.

협업해서 작업을 할 때는 이와 같은 규칙을 맞추어야 하지만 코딩 테스트는 사실상 개인이 보는 것이라 달리 생각해야한다.

 

위 소스는 immutable한 state tree를 생성하는 Immer.js 라는 라이브러리의 함수이다. 위의 소스에서는 세미콜론을 사용하지 않고 있는데, 이 소스의 틀린 점은 사실 없다.

작동하는데 문제가 있거나 속도가 느리다거나 하지 않기 때문이다. 

 

하지만 채용 담당자의 관점에서 보았을 때 세미콜론을 모든 소스에 붙여서 사용하거나 사용하지 않거나 통일을 하는 것과

쓰고 싶을 때만 사용하는 것은 의구심이 들수도 있다.

 

결론적으로 말하자면, 세미콜론의 사용/미사용을 통일하는 것이다.

 

일치 연산자

 

자바스크립트에서 값을 비교하는 방법은 '==' 뿐만 아니라 '===' 가 있다.

둘의 차이는 다음과 같다.

== : 자바스크립트 내에서 타입을 자동으로 변환시켜 값을 비교한다. 예를 들어, 숫자 1과 문자열 '1'이 있다면 (1 == '1')은 참(true)이다. 

=== : 타입까지 일치하는지 비교한다. 위와 같은 예시에서 (1 === '1')은 거짓(false)이다.

 

현재 기준으로 === 를 사용하는 것이 국룰이라고 하는데, 기존의 소스에서도 별 문제가 되지 않았다. 

개발자의 성향이나 스타일에 따라 다를 수 있다. = 하나 더 붙이는 것이 번거로울 수도 있다.

마치 위의 ; 를 붙이냐마냐는 것과 같은 이치인 듯 하다.

 

다음과 같은 함수를 수행하였을 때 결과는 이와 같이 나온다.

 

원하는 결과는 1, 2, '0', '1', '2' 이었는데, 문자열인 것을 체크를 하지 않았기 때문에 위와 같은 결과가 나오게 된다. 

이는 === 를 사용하지 않은 결과로 도출된 것이기 때문이다. 

때문에 코딩 테스트에서 소스를 작성하는데 원하는 결과가 나오지 않을 가능성이 다분하다.

 

불변성

 

불변성이라는 개념은 이전에 다루었던 var & let & const의 차이와도 연관이 있다. 

외부 스코프에 대한 영향력을 줄이고, 발생할 수 있는 문제점을 보완하기 위한 객체의 상태 보존성을 의미한다.

다시 말해, 객체가 기존에 가지고 있던 값을 변하지 않게 함을 의미한다.

 

함수에서 개발자가 지켜야 할 부분은 협업일 경우 규칙이라던지 주석등도 중요하지만, 코딩 테스트의 특성상 개인이 개발을 진행하게 되는 것이므로 논외로 생각하여야겠다. 그 중 하나는 인자로 들어온 값을 수정하지 않는 것인데, 파라미터가 수정되는 경우 문제가 발생한다.

변조된 값이 해당 함수가 호출된 이후 계속 재사용되기 때문에 기존의 고유성을 잃게 되는데 대표적인 함수는 오름차순으로 정렬하는 함수이다.

 

아래의 소스는 매우 심플하다. 사용자ID가 포함된 Array를 받아 순차적으로 정렬하는 함수이다.

 

Shallow Copy

 

하지만 이와 같은 소스를 사용하는 경우 원본의 데이터가 훼손되어(훼손이라기 보다는 기존의 데이터를 잃어) 연이은 화면이나 객체를 사용하는데 문제가 있을 수 있다. 사용을 하려면 위와 같은 얕은 복사(Shallow Copy)보다는 다음과 같이 깊은 복사(Deep Copy)를 사용하여야 한다.

 

Deep Copy

 

삼항 연산자

 

마지막으로는 삼항연산자이다.

삼항연산자는 사용법이 간편하고 짧게 작성할수 있어 대부분의 프로그래밍 언어에서 제공하는 연산중 하나이다.

 

if 연산과 삼항 연산자는 차이가 있다.

아래의 소스는 2020년 기준으로 우리 나라의 법정 공휴일을 계산한 소스코드이다.

경우의 수가 많아서 if문을 먼저 작성해보면 다음과 같다.

또는 아래와 같이 나타낼 수도 있다.

 

이 부분을 삼항연산자로 치환하면

너무 극단적인 삼항연산자 코드

 

코드를 보기에는 이쁠지 몰라도 상당한 가독력이 필요한 코드가 되어버린다.

되도록이면  a ? b : c 형태의 깔끔하고 단순한 형태를 사용하는 것을 추천한다.

 

정리하자면, 코드가 잘 돌아가고 원하는 결과가 도출되도록 이끌어내는 것이 개발자의 덕목이고 할 일이라고 생각한다.

하지만 코딩 테스트를 합격한 지원자가 개발자의 꿈을 펼쳐보기도 전에 서류 면접 및 IT 관련 질문에서 떨어지는 이유 중의 일부도

코딩 테스트때 사용하였던 지원자의 '사소한 실수' 하나가 발목을 잡을 수도 있다고 생각이 든다.

 

세 살 버릇이 여든 간다는 말이 있듯이, 코딩 스타일은 한 번 잡히면 쉽게 고쳐지지 않고

그 부분이 차후 이직을 하더라도 개선될 가능성은 극히 낮다고 한다. 

물론 나조차도 완전한 개발자가 아니기 때문에 계속해서 배우고 나가고 있고, 실천해 나가고 있지만

이러한 코딩 스타일의 개선 또는 방향성을 잡는 것 또한 하나의 매력으로 느끼고 있다.