코딩 테스트에 대한 생각

며칠 간 구직 활동 관련한 글을 썼다. 그 중에서 “코딩 테스트”에 대한 부분은 쓰다보니 길어져서 이렇게 별도 글로 쓴다.

나는 코딩 테스트는 당연히 필요하다는 입장이다. 다만, 어떤 방식을 쓸지, 어떤 문제가 더 좋은 문제인지에 대해선 개선할 부분이 있다고 생각한다. 그 생각을 이번 구직 활동 기간 동안의 경험과 함께 써보려고 한다. 크게 세 종류의 코딩 테스트를 경험했다.

온라인 자동화 테스트
온라인 공유 문서를 통한 코딩 테스트 (컨퍼런스 콜 중에 공유 도구 사용)
오프라인에서 종이/화이트 보드를 활용한 코딩 테스트 이 중 온라인 자동화 테스트 횟수가 몇 번 있었는데 기억나는 것만 떠올려 보면 아래와 같은 경우들이 있었다.
3시간 제한; 코드를 짤 수 있는지 확인하는 간단한 문제 / 설명을 보고 구현하는 문제 / greedy 최적화 문제
2시간 40분 제한; 코드를 짤 수 있는지 확인하는 간단한 문제 / 설명 보고 구현하는 문제 / 다이나믹 프로그래밍 문제
24시간 제한; 코드를 짤 수 있는지 확인하는 간단한 문제 / NP-hard 문제의 최적화(휴리스틱 찾기) …를 두 개

그리고 이에 대해서 언어를 미리 제한하는 경우도 있었고 — 내가 쓰겠다고 한 언어로 미리 제한한 경우 / 미리 특정 언어로 제한한 경우 / 해당 도구에서 허용하는 언어 중 아무거나 쓸 수 있는 경우 등이 있었다. 심한 경우에는 해당 회사/부문에서 쓰는 언어랑 관련 없는 다른 언어가 나온 경우도 있다. 해당 팀에선 golang / python3를 쓴다고 했는데 시험 언어는 JavaScript / Java 였다. 나는 이런 “온라인으로 치뤄지고 자동으로 채점하는 테스트”가 지원자와 (해당 기업의) 면접관이 상호 작용할 수 있는 다른 코딩 테스트와 크게 다르며, 그렇기 때문에 용도가 달라야한다고 생각한다.

이에 대한 이유를 들자면, 첫째로는 현실세계에서 소프트웨어 개발자가 작업 방식을 크게 반영하지 못한다는 점. 현실에선 “모호한 부분”을 파악하고 이에 대해서 다른 소프트웨어 개발자나 서비스 기획자 등과 의사소통하는게 중요한데 이런 부분을 짚고 넘어가기 어렵다. 그리고 출제하는 쪽에서도 문제에서 모호한 부분을 줄이려 하다보니, 문제 후보군이 PS 스타일로 줄어든다. 특히나 채점 과정의 편의를 생각하면 그럴 수 밖에 없다. 모든 회사가 좀 더 유연한 채점 방식을 도입하기엔 그럴만한 자원이 있기도 어렵고, 채점자 주관이 들어가는 형식일 수록 객관성도 떨어질테니까. 둘째, 소프트웨어 개발이 어려운 이유 중 하나는 “소프트웨어에 대한 요구 사항은 변한다”라는 것. 하지만 이런 종류의 상호 작용 없는 코딩 테스트에서는 이런 부분을 확인하기 어렵다.

조금 바꿔 말하면 이런 종류의 문제가 거의 최악의 문제라고 생각한다.

온라인 테스트 + 채점 자동화
다이나믹 프로그래밍

이런 형태의 문제는 내가 아는 좁은 범위에서 생각하면 힌트를 제공하기 어렵다. 그래서 대면이나 온라인 공유 도구를 사용한 코딩 테스트를 할 때도 쓰기 좋지 않다고 생각하며, 응시자가 질문할 수 없는 이런 상황에선 더 나쁜 문제가 된다. 그리고 부분 문제를 잘 정의하지 못한다면 아예 진행이 불가능할 수도 있다. 만약 테스트 셋을 잘 정의하지 않는다면 응시자가 잘못된 접근(greedy 최적화하거나 등등)을 한다면 부분 점수 조차 못 받을 가능성이 있다.

PS 능력 프로그래머의 자질을 측정할 수 있는 괜찮은 척도라고 생각한다. 문제를 풀려면 프로그래밍을 할 줄 알아야하고, 자료구조나 최적화, 알고리즘 분야의 전산학 지식이 있어야 하니 그렇다. 다만 일정 수준을 넘어서면 단순히 이 점수로 뭔가를 판단하는 것은 지양해야 한다는게 내 의견이다. 내가 마지막으로 PS 비슷한 걸 해본 게 14년 전에 python2 써 본다고 Project Euler 문제를 푼 것이고, 마지막으로 다이나믹 프로그래밍 문제를 풀어본 건 (Project Euler에서 가끔 나오는 경우 빼면) 18년 전에 알고리즘 수업 과제로 나온걸 풀었던 것인듯. 그럼에도 PS 스타일의 코딩 테스트를 통과할 수 있었으니 이걸로 평가할 수 있는 범위는 매우 좁은 것이라고 생각한다.(간단한 문턱값 넘는 테스트가 아니라면, 최근에 안한 사람을 reject할 수 있었어야 한다고 생각함)

다시 본론으로 돌아와서, 이런 온라인 코딩 테스트 + 채점 자동화는 “전화 테스트/스크리닝”에 해당하는 단계로 써야 할 것 같다. 즉 아주 어렵지 않은 수준의 모호하지 않은 PS 문제로 “이 지원자가 프로그래밍 할 줄 아는가”를 확인하고, 실직적인 확인은 뒤로 미루는 것. 공유 도구나 화이트 보드 앞에서 상호작용하면서 문제를 푸는 단계를 추가하거나, 아니면 설계 문제를 만들어서 좀 더 실 세계에 가까운 문제 해결 능력을 확인해보는게 양쪽 모두에게 유용하다고 생각한다. 특히 문제 유형을 좀 더 제한한 자동화 테스트있는 온라인 시험 + 면접 중에 상호 작용하는 시험이 있다면 적절히 객관적인 스크리닝 / 다면적으로 응시자 평가하는 것 두 가지를 모두 챙길 수 있을 것 같다.