훌륭한 개발 문화의 이면(1) – 코딩 테스트 인터뷰 제대로 하기

연재 목차

• 훌륭한 개발 문화의 이면(1) – 코딩 테스트인터뷰 제대로 하기
• 훌륭한 개발 문화의 이면(2) – 자율적 개발 환경을 선택하라!
• 훌륭한 개발 문화의 이면(3) – 다른 팀 소스 코드를 볼 수 있는가?
• 훌륭한 개발 문화의 이면(4) – 사내 라이브러리를 잘 관리하려면?
• 훌륭한 개발 문화의 이면(5) – 소통 비용의 절약 – 서로 API로 말하자
• 훌륭한 개발 문화의 이면(6) – 입사하고픈 회사를 위한 오픈 전략 구사하기
• 훌륭한 개발 문화의 이면(7) – 잉여력이냐 vs. 효율성이냐

지난 주에 모 대기업에서 코딩 테스트를 개발자 소프트웨어 역량을 확인하기 위한 수단으로 사용한다는 기사가 나간 후, 많은 분들이 다양한 의견을 많이 내어 주셨습니다.

…개발자들이 알고리즘 문제풀이집 10권을 열심히 공부해서 구글 코딩 인터뷰 문제를 척척 풀어낸다고 하자. 팔란티어 문제도 다 풀어낸다. 그래서 뭐? 문화와 개방으로 표상되는 진짜 혁신이 없으면 그런 문제 좀 푼다고 해서 달라질 것이 정말이지, 아무 것도 없다. 임백준, 삼성전자의 소프트웨어 개발자 역량 중

…그 회사 개발자들의 능력이 떨어진다고 생각하지 않는다. 아주 뛰어난 개발자도 많이 있을 것이다. 개발자 면면을 보면 아주 뛰어난 개발자가 많음에도 불구하고 SW 능력이 떨어진다는 의미는 조직, 문화의 문제가 많다고 생각한다. 임형준, 삼성의 반성…”SW인력 절반이 기초수준 실력”을 읽고

공통적으로 획일적인 코딩 테스트로 개발자 자질을 검증하는 것 보다는 사내 개발 조직의 유연한 문화를 주문하는 목소리가 훨씬 많았습니다. 이건 대기업이 아니더라도 소프트웨어 개발자로 일하시는 분들은 누구나 느끼시는 점일 것입니다. 하지만, 아무리 좋은 개발 문화라고 해도 이것을 어떻게 운용하느냐에 따라 그 결과는 달라져서 결국 맞지 않는 옷을 입듯 실패하게 됩니다. 앞으로 제 경험을 토대로 몇 가지 이러한 개발 문화를 운용해 봤던 사례를 이야기해 보려고 합니다.

첫 번째로 이번에 이슈가 된 ‘코딩 테스트’입니다. 사내 직원들을 획일적으로 테스트하는 건 문제가 있지만, 입사 시 기초 역량 검증을 위해 코딩 테스트는 매우 중요합니다. 글로벌 IT 기업에서는 하루 종일 4-5명이 시간을 투자해서 돌아가며 코딩 테스트 면접을 봅니다. 인터뷰에 이렇게 많은 자원을 투여하는 게 쉽지 않습니다.

국내에서도 개발자 채용 시 단순 대면 면접만 보다가 코딩 테스트를 보는 IT 기업들이 늘어나고 있는 추세입니다. 코딩 테스트가 잘 시행이 되고 있는지 어떤지는 모르지만 저의 경험을 통해 어떻게 하는 게 도움이 될지 공유해 보고자 합니다.

■ 결과가 아닌 과정을 보라
Daum에서는 2004년에 처음 경력 채용 시 코딩 테스트를 (아마 업계 최초로)도입했습니다. 당시에 ‘서류 전형 – 실무 기술 – 임원/HR’의 3단계 인터뷰 과정 중 개발자 채용에만 한 단계를 더 넣게 되었죠. 목적은 단순했습니다. 실무 면접 전에 적어도 소프트웨어 개발에 대한 기초적인 사고를 하는지를 검증하는 절차를 만들어 오프라인 실무 면접의 부담을 줄여주자는 것이었습니다. (당시 마이크로소프트나 야후 등 글로벌 기업의 코딩 테스트 면접을 벤치마킹 하기도 했습니다.)

처음 시행이다 보니 아무래도 문제 출제나 평가 방법 등을 현업 개발팀에게 떠 맡기면 면접 절차가 하나 더 늘어나고, 평가 공정성도 그렇고 하니, CTO 직속팀에서 이 일을 맡아서 부담을 줄여주자는 형태로 결정을 하게 되었습니다. 당시 제가 개발자 채용, 교육, 경력 개발에 대한 스탭 업무를 담당하다보니 전사 개발자 채용 상향 평준화를 위해 코딩 테스트를 입안 했던 저에게 다시 일이 떨어지더군요.

당시 제가 목표로 했던 것은 개발자들이 코드를 짜면서 문제 해결의 과정에서 기초적 소양이 있는지 검증하는 것이었기 때문에, 매주 화요일 수요일 저녁 시간에 매번 노트북 5대씩 세팅을 하고 직접 와서 자신이 무작위로 고른 문제를 직접 푸는 방식을 택했습니다. (덕분에 매주 이틀은 항상 야근을 할 수 밖에 없었죠.)

직접 코딩 실습을 참관한 제가 문제 푸는 과정에 대한 의견을 내고, 코딩 결과물은 다른 시니어 개발자 몇 명이 교차 검증하여 종합적인 평가를 거쳐 당락을 결정하였죠. 이렇게 검증을 통과한 분들만 실무 면접으로 가니, 예전에 여러 명 봐야 했던 부담을 줄여 다행히 실무 팀장들에게도 훨씬 좋은 피드백을 받았습니다. 덕분에 2005년 부터 시작된 개발자 신입 공채를 뽑을 때도 슈도 코드(pseudo code)를 짜는 코딩 문제를 내는 것을 시작했습니다.

■ 문화가 형식으로 바뀌게 될 때
제가 2006년에 제주로 오면서 제가 해오던 일을 새로 조직된 기술HR팀에서 맡았습니다. 당연히 코딩 테스트를 보던 업무에서는 빠지게 되었습니다. 그런데, 그 뒤로 코딩 테스트 운용 상황이 좀 바뀌게 되더군요. 일단 사람이 수고해서 오프라인에서 직접 보던 코딩 테스트를 온라인 방식으로 바꾼 것입니다. 시간을 짧게 주고 풀이한 코드를 메일로 주고 받는 방식으로 말이죠.

코딩 테스트 담당자가 매번 사람들 일정을 맞추고, 회의실 잡아 랩탑을 세팅하고 하는 일이 쉽지 않고 회사가 커지면서 좀 더 많은 사람들이 코딩 테스트를 봐야 하는데 그게 점점 어려워졌으니까요. (2004년에 200여명이던 개발자가 10년이 지나 900여명까지 늘어났습니다.) 물론 초기에는 어느 정도 효과를 발휘하는 듯 했습니다만 이게 계속되면서 단점이 들어나기 시작하더군요.

우선 코딩 테스트 문제가 유출이 되기 시작하였습니다. 사실 문제를 유출하면, 다른 경쟁자에게 도움을 주는 격이 되니까 유출되지 않을 거라 생각했는데 그렇지 않더군요. 특히 오프라인과 달리 온라인에서는 유출은 쉽고 유혹도 더 강하니까요. 그러다 보니, 문제 은행에 더 많은 문제 그리고 좀 더 어려운 (알고리즘 대회에나 나올 법한) 문제들이 생성되기 시작하였습니다.

코딩 테스트 결과에 대해서도 풀이 과정을 못 보고, 메일로 제출된 코드만 보고 채점을 하다 보니 코딩 테스트를 통과한 사람이 실무 면접에서 피드백이 좋기도 하고 나쁘기도 하고 그런 상황이 되더군요. 급기야 마지막에는 현업 팀으로 부터 코딩 테스트 무용론까지 나오게 되었습니다.

■ 좋은 사람을 뽑고 싶다면 투자하라

제가 회사를 그만 둘 시점에 이러한 문제를 해결할 개발자 채용 프로세스 개혁에 대한 사내 TF가 만들어지기도 했습니다. Daum에서 코딩 테스트를 처음 입안했던 사람으로서 그 TF에 참여하였습니다. 사실 코딩 테스트의 초심은 그 사람의 문제 해결 방법에 대한 소양을 두 사람 이상의 면접자가 교차로 직접 확인하는 과정이었지 단지 시험을 내고 점수를 메기는 게 아니었습니다.

물론 지금은 온라인 코딩 테스트 업체도 생겨서 문제 풀이 과정에서 개발자가 어떻게 코드를 짰는지 변경 이력을 볼 수 있지만, 그것으로만 진정한 코딩 테스트의 좋은 결과를 얻어낼 수는 없습니다. TF에서 제가 낸 의견은 “전사 코딩 테스트 안 해도 좋다. 그렇다면, 실무 면접에서 적어도 20분은 화이트 보드 코딩 테스트 문제를 내라. 다만, 실무 팀장 혼자가 아니라 적어도 2명 이상이 (타팀 개발자라면 더 좋고) 그 실무 면접에 들어가야 한다.”는 것이었습니다.

그리고, 지금 근무하는 회사에 입사하면서 기술 폰스크리닝(Phone Screening), 코딩 과제와 아키텍처 화이트 보딩 인터뷰를 포함해서 무려 9번 가까이 면접을 봤던 저로서는 왜 글로벌 IT 기업들이 여러 사람이 시간을 내어서라도 코딩 테스트 기반 인터뷰를 심층적으로 하는지 더 이해할 수 있게 되었습니다.

지금 카카오에서는 어떻게 개발자 면접을 하는지는 잘 모르겠습니다만 국내에서 가장 좋은 개발 문화를 가졌다고 자부했던 Daum에서 조차도 그것을 유지하고 운용해 나가는 게 얼마나 힘든 지를 보여 주는 단적인 실례입니다. 만약 글로벌 기업이 코딩 테스트로 개발자를 뽑는다고 해서, 이를 단순화해서 기출 문제를 빌어다가 전사 개발자에게 시험을 보게 하고, 그 결과로 승진이나 탈락을 시키는 획일적인 제도로 도입된다면 그것 만큼 바보 같은 일은 없을 겁니다.

아무리 해외 유수 IT 기업의 좋은 문화라도 제대로 이해하고, 자원을 투자할 의지가 있지 않다면 결국 남귤북지(南橘北枳, 귤이 회수를 건너면 탱자가 된다)가 되는 전형적인 결과를 만들어낼 것이 뻔합니다.

사내 개발 문화는 살아있는 유기체와 같습니다. 이걸 어떻게 좋은 상태로 만들면서 유지하느냐는 매우 어렵고도 힘든 문제입니다. 코딩 테스트 인터뷰 사례를 시작으로 앞으로 제가 경험했던 사내 개발자 문화에 몇 가지 사례들을 좀 더 공유해 볼까 합니다.

만일 국내 코딩 테스트를 하시는 IT 기업이라면, 어떻게 시행하고 있는지 어떤 문제가 있었는지 공유해 주시면 어떨까요?

연재 목차

• 훌륭한 개발 문화의 이면(1) – 코딩 테스트인터뷰 제대로 하기
• 훌륭한 개발 문화의 이면(2) – 자율적 개발 환경을 선택하라!
• 훌륭한 개발 문화의 이면(3) – 다른 팀 소스 코드를 볼 수 있는가?
• 훌륭한 개발 문화의 이면(4) – 사내 라이브러리를 잘 관리하려면?
• 훌륭한 개발 문화의 이면(5) – 소통 비용의 절약 – 서로 API로 말하자
• 훌륭한 개발 문화의 이면(6) – 입사하고픈 회사를 위한 오픈 전략 구사하기
• 훌륭한 개발 문화의 이면(7) – 잉여력이냐 vs. 효율성이냐

- Channy Yun (윤석찬);

※ Disclaimer- 본 글은 개인적인 의견일 뿐 제가 재직했거나 하고 있는 기업의 공식 입장을 대변하거나 그 의견을 반영하는 것이 아닙니다. 사실 확인 및 개인 투자의 판단에 대해서는 독자 개인의 책임에 있으며, 상업적 활용 및 뉴스 매체의 인용 역시 금지함을 양해해 주시기 바랍니다. (The opinions expressed here are my own and do not necessarily represent those of current or past employers. Please note that you are solely responsible for your judgment on checking facts for your investments and prohibit your citations as commercial content or news sources.)