팀네이버 코딩 테스트 후기

시험 전날 적어도 한-두 문제 통과해 달라고 교내에서 붙여진 포스터 들고 기도하는 모습

어제 오전, 네이버 신입 기술 직군의 공채 코딩 테스트에 응시했습니다. 오랜만에 치른 시험이라 저의 반복적인 실수 패턴을 다시금 깨닫게 되었는데요, 크게 두 가지로 정리할 수 있었습니다.

1. 문제를 파악하자마자 구현부터 시작하기

문제를 처음 접했을 때, 수도코드를 바로 떠올리고 곧장 구현에 들어갔습니다. 하지만 그렇게 만든 해답은 문제를 끝까지 파악하지 않은 채로 나온 부분 해(部分 解)일 뿐이였습니다.

간단한 예시로 제가 “직사각형의 세 꼭짓점을 통해 나머지 한 꼭짓점의 좌표를 찾는 문제"를 접근하는 과정을 사례로 소개합니다.

알고리즘 문제 - 나머지 한 점 | 프로그래머스 스쿨

입출력 예

문제 접근 과정과 실수

1. 이어진 점의 특성을 활용해 “같은 숫자는 한번만 나온다"라고 파악했습니다.
2. 수도코드로 해시맵을 구성하여 짝이 없는 숫자를 찾으면 되겠다고 생각했습니다.
3. 구현 직후 결과가 맞아 보였지만, 곧이어 x와 y 좌표를 구분하지 않은 실수를 깨달았습니다.
4. 두 번째 테스트 케이스를 확인하고 나서야 x, y 축을 각각 따로 처리해야 한다는 점을 파악했습니다.

결국, 애초에 조금 더 차분히 문제를 분석했으면 절반의 시간으로 해결할 수 있는 문제였습니다.

2. 시험 상황에서 백지 현상(white-out) 겪기

이번 코딩 테스트 문제는 수학/구현/조합 세 가지 카테고리로 나왔습니다. 이 중에서 다음과 같은 백지 현상이 있었습니다.

• 수학 문제: 난이도를 미리 판단하여 문제를 풀지도 않았는데, 나중에 보니 실제로는 매우 단순한 기약분수 문제였습니다.
• 구현 문제: 특정 상태 전이를 enum 자료형으로 저장하는 복잡한 설계를 했습니다. 하지만 다시 점검하니 그럴 필요 없이 바로 계산하면 쉽게 풀 수 있는 문제였습니다.
• 조합 문제: 파이썬에서 제공하는 조합 API가 순간 떠오르지 않아 당황했습니다. 프로그래머스의 시험 환경에서 문서를 참조할 수 있었지만, 백지 상태에서 이를 활용하는 생각을 하지 못했습니다.
  • Python itertools 라이브러리의 Combinatoric iterators를 기억합시다.

마치며

돌이켜보니 현업에서도 이번에 소개한 실수 패턴과 유사한 경험을 했었습니다. 설계의 부분 해만 생각해내고 구현하는 바람에, 다시 돌아가 재설계하는 상황이 발생하곤 했습니다.

그나마 재설계를 할 수 있는 경우는 다행입니다. 때로는 주어진 비즈니스의 한계상 설계를 바꾸지 못하고 문제를 안고 가야 해서 가역성(可逆性, reversibility)¹을 놓치는 상황이 더 많았기 때문입니다.

“당신이 가진 생각이 딱 하나밖에 없다면, 그것만큼 위험한 것은 없다.”
— 에밀 오귀스트 샤르티에(Emill-Augste Chartier), 《종교론(Propos sur la religion)》

짧은 제한 시간 내에 합불이 갈리는 코딩 테스트를 통해 이러한 가역성을 압축적으로 경험했다고 느꼈습니다. 설계에서 겪는 실수를 줄여나가며, 오랜 시간 꾸준히 일할 수 있는 지속 가능한 소프트웨어 엔지니어로서의 삶을 지켜내고자 합니다.