필자는 개발자를 채용할 때 인터뷰 시 칠판을 이용한 코딩 테스트를 꼭 실시한다. 아무리 화려한 이력을 가지고 있다고 하더라도 코딩 테스트를 통과하지 못하면 채용하지 않는다. 코딩 테스트 문제는 정말 간단하다.
숫자를 문자로 변환한다든지, 숫자 몇 개를 정렬하는 등 아주 단순한 문제다. 코딩 테스트에서 확인하는 것은 개발자의 논리적인 사고, 창의력, 문제 해결 능력이다. 그리고 문제를 해결하기 위해서 면접관과 어떻게 커뮤니케이션을 해나가는지 보는 것도 중요한 요소다. 문법은 중요하게 보지 않고 개발언어는 아무거나 선택해도 된다.
실제로 여러 지원자에게 코딩 테스트를 실시하면 안타깝게도 코딩 테스트를 통과하는 비율은 매우 낮다. 경력은 화려하게 잘 얘기하는데 코딩 및 논리적인 사고는 어처구니 없이 형편없는 경우가 많다. 그래서 서류 심사를 통과한 지원자를 대상으로 온라인 코딩 테스트를 먼저 실시하곤 한다.
온라인 코딩 테스트는 약간 난이도가 있는 문제를 주고 24시간 안에 코딩을 해서 제출하게 하는 것이다. 컴파일이 되어야 하고 실행이 되어야 하며 알고리즘의 효율성을 보기 위해서 실행 제한 시간도 있다. 이런 온라인 코딩 테스트는 어차피 인터뷰에서 탈락할 지원자를 걸러줌으로써 인터뷰 시간과 비용을 절약하는데 도움이 된다.
얼마 전 온라인 코딩 테스트를 실시하는데 어처구니 없는 일이 발생했다. 온라인 코딩 테스트는 꼭 본인이 작성해야 한다는 규칙이 있다. 하지만 온라인의 특성상 주변 지인들에게 약간의 힌트성 도움을 받는 것은 어쩔 수 없다고 생각하고 있다. 출제한 문제는 유명한 코딩 테스트 사이트에서 가져온 문제다.
하지만 지원자는 문제를 받자마자 본인이 풀 생각을 하지 않고 바로 인터넷을 검색하여 해당 사이트를 찾아냈다. 그리고 해당 문제를 푼 사람을 찾아서 소스코드를 보내달라는 이메일을 보낸 것이다. 그런데 이메일을 받은 사람은 프로 개발자가 아니라 초등학생이었던 것이다. 전문 개발자를 채용하려고 실시하는 코딩 테스트에서 자신이 못 풀겠다고 초등학생에게 소스코드를 요청하는 일이 발생한 것이다.
인터넷을 검색해서 알고리즘을 참고한다 던지 아이디어를 구하는 것은 가능하지만 소스코드를 달라고 하는 것은 명백한 속임수(Cheating)이라고 생각한다. 이런 개발자는 실력을 떠나서 채용할 수가 없다.
다른 사례다. 온라인 코딩 테스트를 훌륭하게 통과해서 인터뷰를 진행한 개발자 얘기다. 그런데 칠판 코딩 테스트에서 이상한 일이 발생했다. 온라인 코딩 테스트 문제는 개발자의 논리력, 창의력이 없으면 풀기 어렵기 때문에 칠판 코딩 테스트에서 좋은 결과를 보여줄 것으로 예상했는데 인터뷰 현장에서 형편 없는 결과를 보여줬다.
혹시 긴장해서 원래 실력을 보여주지 못하는 것이 아닐까 생각해서 여러가지 질문을 해봐도 원래 실력이 없었다는 것이 확인이 되었다. 그렇게 탈락을 한 후 이상한 생각이 들어서 온라인 코딩 테스트에서 제출한 답안을 인터넷에 검색을 해보니, 해당 문제를 미국에서 자바로 풀어 놓은 답안과 한 글자도 틀리지 않고 동일한 것을 확인했다.
그 뒤 온라인 코딩 테스트를 세상에 없는 문제로 새로 만들어야 고민을 했지만 지원자가 속임수를 쓰는지 확인할 수도 있으므로 그냥 진행하기로 했다. 단, 지원자에게는 본인이 직접 풀어야 한다고 꼭 당부를 하고 있다.
이런 일이 발생하는 이유는 무엇일까? 요즘 개발자들은 과거에 비해서 훨씬 개발하기 편한 환경에 있다. 개발하다가 필요한 모듈이나 알고리즘은 인터넷을 검색해보면 다 찾을 수 있다. 그러다 보니 원리는 생각하지도 않고 본인이 이해도 하지 않고 그냥 인터넷에서 소스코드를 가져다가 사용하는 경우가 매우 많다.
과거에 인터넷(웹)이 없을 때나 초창기 까지는 소스코드를 구할 곳은 책을 제외하고는 별로 없었다. 그래서 개발자들이 책을 많이 보고 본인이 이해를 해서 직접 구현을 해야 했고, 그러다 보니 소프트웨어 이론에 대해서 속속들이 잘 알아야 했다. 과거에 뛰어난 개발자가 더 많았던 이유는 이런 환경에 기인한 것이 아닌가 생각된다.
요즘은 쉽게 소스코드를 구할 수 있다 보니 깊게 생각하는 습관을 가지기는 어렵다. 개발자들의 고충을 이해하지 못하는 것도 아니다. 촉박한 시간 안에 빨리 구현을 해내야 하고 누가 설계를 잘 해주는 것도 아니고 서로 리뷰를 통해서 내가 작성한 코드를 누가 잘 봐주는 경우도 흔치 않다.
그러다 보니 부랴부랴 인터넷에서 구한 소스코드를 이해도 못하고 그대로 사용하기 일쑤다. 요즘 개발자들을 만나보면 소프트웨어 이론을 속속들이 잘 모르는 경우가 많다. 메모리의 기본 구조도 잘 모르고 기본적인 자료구조와 알고리즘도 잘 모르곤 한다. 대학에서 이런 기본 이론을 철저히 가르쳐야 하는데 이런 이론보다 실무를 가르치는 것이 아닌가 의구심이 들기도 한다. 모든 대학이 그런 것은 아니지만 이론보다 실무를 가르친다면 학원과 다를 것이 없다. 그래서 실무 중심 사관학교라는 대학의 광고를 듣다 보면 안타까운 생각이 든다.
이렇게 개발하기 좋은 환경이 오히려 개발자들의 실력을 떨어뜨리고 있는 것이 아닌가 걱정이 되고 있는 사례들이다. 현재 소프트웨어 공부를 하고 있는 학생이라면 실전 코딩보다도 소프트웨어 기초 이론을 철저히 익히라는 얘기를 하고 싶다. 실전 경험도 중요하지만 기초가 약하다면 언제든지 문제가 될 수 있다.
회사에서는 개발자에게 이론, 경험을 전파하는 수단은 코드리뷰, 설계리뷰다. 선배 또는 동료가 소스코드나 설계서를 보고 리뷰를 하면서 서로의 경험과 이론, 노하우를 전달하는 것이다. 서로 리뷰를 통해서 개발자는 같이 성장해나가는 것이다. 피어리뷰(동료검토)를 하지 않거나 형식적으로 하지 않는 회사에서는 개발자들의 성장이 몇 배 느릴 수 밖에 없다.
개발자는 구글을 믿고 개발을 할 것이 아니고 믿어야 할 것은 자신의 두뇌와 동료들이다. 구글은 단지 거들뿐이다.
이 글은 ZDNet Korea에 기고한 글입니다.
좋은 글 잘 보고 있습니다.
답글삭제글 잘보고 갑니다 저도 후배 사원과 코드리뷰를 하는데. 말로 다시 코드를 설명하다보면 오류나 비 논리적인 부분도 발견하고 일의 능률도 오르더 군요.
답글삭제