화이트보드 코딩테스트의 문제점
출처: 곽중선님 Facebook https://www.facebook.com/sunny.kwak.90/posts/410349009090091
좋은 개발자를 뽑기 위해 다양한 테스트 방법들이 사용되는데 그중에서 논란이 많은 방식이 입 코딩 혹은 보드 코딩을 시켜보는 방법이 있다. 전자는 구두로 로직을 설명하게끔 하는 것이고, 자료 구조처럼 어느 정도 구조를 그려봐야 눈에 보이는 코드를 시험보고자 할 경우에는 화이트 보드를 이용해 가상 코드(pseudo code)를 보여주게끔 하기도 한다. 변형된 방법으로 종이를 주고 필기로 시험보거나, 노트북을 지급하고 직접 코딩을 하게끔 하거나, 혹은 숙제를 제시하는 경우도 있다.
이런 방식으로 실무 능력을 테스트하는 이유는 이력서와 자기소개서에 적힌 경험보다 직접적으로 실무 능력을 파악할 수 있다는 잇점, 그리고 블러핑(bluffing)을 시도하는 면접자들을 제외하기 있다는 점 때문이다.
그런데 이런 식으로 인력을 선발할 때 놓치게 되는 문제가 몇가지 있다.(라이브 코딩 테스트가 꼭 나쁘다는 것은 아니니 오해가 없기를 바란다.)
- 사람마다 코딩하는 습관이 다르다는 점을 배려하지 않는다.
누군가 지켜보고 있다는 상황 그리고 제한된 시간 내에 코드를 작성해야 한다는 것은 상당한 압박이다. 개발자들 중에는 내성적인 성격인 사람들이 많다. 자신만의 공간과 시간 속에서 문제를 푸는 버릇을 가진 사람에게 공개된 장소와 압박을 이겨내라는 것은 핸디캡을 부여하는 것과 같다. 육상선수 발목에 족쇄를 달아놓고 달리라는 말과 다르지 않다. - 숙련된 개발자를 뽑는다는 목적에는 부합할지 모르지만, 과연 그것이 창의적인 개발자를 뽑는 방법인가에 대해서는 좋은 답이 되지 못한다. 타이핑이 빠르거나, 반복적으로 특정 패턴의 코드를 많이 연습한 사람에게는 유리하지만, IDE의 자동 완성 기능에 길들여져 있다거나, 충분히 뇌내 코딩을 마친 후에야 코딩하는 사람에게는 불리한 시험 방식이다. (일정부분 앞서의 문제제기와 같은 맥락의 이유이다.)
- 단숨에 좋은 코드를 작성하는 것만이 프로그래머의 역량인가? 그렇지는 않다고 본다. 완벽한 코드를 한번에 잘 짜는 개발자는 거의 없다. 단숨에 좋은 코드를 작성하기 어렵다는 것을 모두가 인정하기 때문에 디자인 패턴, 리팩토링, 그리고 TDD 같은 코드 개선을 위한 전략과 기법들이 연구된 것이다. 짧은 시간에 앞서 말한 기법들에 대한 숙련도를 테스트할 수 있는가? 거의 어렵다.
- 코드가 만들어지면 유지보수는 필요 없는가? 코드가 오동작하는 이유는 자체적인 로직의 문제도 있지만, 코드가 오동작하는 이유의 대다수는 외부의 요인으로 발생한다. 코드를 작성한 개발자가 예상치 못한 외부의 변수로 인해 중단점이나 예외가 발생한다는 말이다. 좋은 프로그래머는 좋은 코드를 만드는 능력 뿐만 아니라 예기치 않은 데이터로 인한 장애가 발생했을 때 유연하고 신속히 대처할 수 있어야 한다. 이런 능력은 테스트 기간 그리고 운영 기간에 들어가서야 검증할 수 있다.
- 남의 코드를 볼 줄 아는지 파악할 수 없다. 현대적인 소프트웨어 개발에 있어서 협업은 필수다. 그것이 오픈소스이건 혹은 기업의 내부 솔루션이건 상관없는 문제이다. 자신의 코드를 잘 작성할 뿐만 아니라 다른 사람의 낯선 코드를 빨리 이해하고, 때로는 문제점을 지적하고 개선점을 지적할 줄도 알아야 한다. 자신의 코드가 팀원들이 작성한 코드와 문제없이 결합되어 잘 동작할지도 예측할 수 있어야 한다. 혼자서 코딩을 하는 테스트를 통해서는 이런 능력 -페어 프로그래밍이나 코드 리뷰-을 점검할 수 없지 않은가?
- 실행 및 테스트 시 발생하는 오류 로그를 분석하고, 성능과 자원 활용을 예측 및 제어하는 능력을 점검할 수 없다. 소프트웨어의 품질과 관련해서 중요한 점은 아름다운 코드를 작성하는 것보다 적은 양의 자원을 사용하고, 빠른 응답 속도를 내는 코드를 작성하는 것이다. trade-off를 고려할 줄 모르는 개발자는 결국 소프트웨어의 품질을 망가 뜨리고 만다. 오류 로그나 스택 트레이스(stack trace)를 볼 줄 모르는 개발자는 전진만 할 줄 알고 후진을 못하는 운전자와 같다.
핵심 논지는 개발자의 역량을 단시간에 측정하기는 어렵다는 것이다.
