Page history of 개발자 채용

내가 개발자를 채용해야 할 때 중요하게 생각하는 원칙과 면접 방법들을 정리해본다.

우선 내가 생각하는 채용의 대원칙을 한 마디로 정리하면, 장점이 뚜렷한 사람이다. 현재의 팀에 부족한 장점을 갖고 있으면 더더욱 좋고, 장점이 많으면 더 좋다. 하지만 약한 장점이 여러 개인 사람보다는 하나의 장점이 확실한 사람을 더 선호한다. 단점은 전혀 고려하지 않는다. 정말로 단점은 고려하지 않는다. 아, 물론 흉악 범죄를 저지를 것 같은 사람이라거나 그러면 안되겠지만, 그런 사람은 한 번도 면접에서 본 적이 없기 때문에 별로 생각할 필요 없다.

단점을 고려하지 않는 이유는 고려할 필요가 없기 때문이다. 팀의 성과는 개개인의 장점이 모여서 나오는 것이다. 개개인의 단점은 팀이 보완하면 된다. 세 명 이상 모인 팀에서 개개인의 단점을 보완 못할 상황은 거의 발생하지 않는다. 만약 팀을 이끄는 팀장이 명확하게 있는 상황이라면 개개인의 단점을 보완하는 것은 팀장의 책임이다. 나는 내가 팀장이면 다른 사람의 단점이 뭐든 보완할 자신이 있기 때문에 자신 있게 장점이 뛰어난 사람을 뽑는다. 나는 운이 좋아서 늘 좋은 팀원만 만나왔다고 생각할 수도 있겠지만, 난 충분히 일반화해도 좋을 만큼 대부분의 단점이 별 것 아니라고 생각한다.

물론 나 역시 단점이 아주 뚜렷하고 단점의 종류도 여러 가지다. 하지만 나 자신에게도 같은 기준이 적용된다. 난 내 단점을 극복하기 위한 노력은 전혀 하지 않는다. 내 노력은 내 장점을 강화하는데 집중된다. 단점에 관해 내가 하는 노력은 단 두 가지. 늘 내 단점을 보완해줄 수 있는 사람이 있는 팀에서 일하려고 하는 것. 그리고 내 단점을 커버할 수 있는 시스템을 만드려고 노력하는 것. 나 뿐 아니라 난 내 팀원들이 다 장점을 강화하기 위한 노력을 더 많이 했으면 좋겠다.

장점이 뚜렷한 사람을 뽑는 것이 목표라면 채용 과정은 장점을 발견하는 과정이다. 장점의 발견은 서류 전형에서부터 시작되지만, 아직 서류에서 걸러야 할 정도로 지원자가 많은 상황은 별로 겪어본 적이 없어서 눈에 띄는 점 하나만 있으면 대부분 서류 전형은 합격이었다. 정말 중요한 건 면접에서 장점을 발견하는 방법이다.

원래 이 문서는 면접에서 물어보기 좋은 질문들을 정리하기 위한 용도로 시작했다. 하지만, 여러 번 채용 면접을 하다보니 사전에 정해진 질문은 의미가 없었다. 중요한 건 그 질문에 대한 답을 듣고 두번째, 세번째 깊이 파고드는 질문을 하는 것이다. 간혹 보면 유용한 면접 질문으로 널리 퍼져 있는 질문을 기계적으로 하는 경우를 본다. 이를테면 이런 것들이다.

• 가장 최근에 읽은 책은 무엇인가요?
• 개발자 커뮤니티에서 활동을 하시나요?
• 집에서 취미로 개발을 하나요?

질문 자체는 나쁘지 않다. 첫번째 질문도 "자기 계발을 열심히 하시나요?" 같은 질문에 비하면 좀더 구체적인 답을 이끌어내기 좋은 질문이다. 하지만, 이 질문의 한계는 닫힌 질문이라는 것이다. 닫힌 질문은 뭐고 그럼 열린 질문은 뭔가? 닫힌 질문은 알고 싶은 정보가 정해져 있는 상태에서 던지는 질문이다. 첫번째 질문은 이 개발자가 공부를 열심히 하는 사람인지 아닌지 알기 위해서 던진 질문이다. 하지만 이 질문으로 정말 이 개발자가 공부를 열심히 하는지 아닌지 알 수 있을까? 공부를 하는 방식은 여러 가지가 있다. 책은 이미 낡았다고 생각해서 전혀 안 읽지만 인터넷에서 문서를 열심히 찾아보면서 직접 실험해보는 개발자는 어떨까? 혹은 각종 논문을 열심히 탐독하는 개발자는? 코드가 최고라고 생각해서 오픈소스 코드를 깊이 파고드는 개발자는? 이처럼 다양한 공부 스타일이 있는데, 후보자가 공부를 열심히 하는지 아닌지 알기 위해서 이 모든 가능성에 대해 질문을 던질 것인가?

집에서 취미로 개발을 하냐고? 나도 이 질문 몇 번 받았다. 그 때는 마침 집에서 불꽃 코딩 할 때라서 당연히 yes라고 대답했지만 이콜레모를 주로 하던 동안에는 집에서 일과 분리된 개발을 따로 한 적이 없다. 당연히 회사 일이 가장 재미있었기 때문이다. 그런데 이런 질문을 던져서 과연 이 사람이 geek인지 아닌지 알 수 있을까? 이것이 닫힌 질문의 함정이다.

물론 닫힌 질문도 좀더 잘할 수는 있다. 이를테면 이렇게 해볼 수 있다.

• Q: 기술적인 공부를 많이 하는 편인가요?
• A: 네.
• Q: 그럼 최근에 어떤 공부를 했었는지 말씀해주실 수 있나요?
• A: 최근에 실용주의 사고와 학습을 읽었습니다.
• Q: 그게 언제였나요?
• A: 재..재작년이군요.
• Q: 최근에 다른 건 없었나요?
• A: 아, 지난 주에 Dynamo 관련 논문을 하나 읽었네요.
• Q: 그 논문을 간단히 요약해서 말씀해주실 수 있나요?

이런 식이면 공부하는 스타일인지 아닌지 좀더 파고들어볼 수는 있다. 그런데, 만약 공부는 별로 열심히 하지 않지만, 데이터베이스 성능 튜닝을 기가 막히게 해내는 사람이라면 어떨까? 장점은 수십 수백가지가 있다. 닫힌 질문은 말하자면 수십 수백 가지의 장점의 리스트를 뽑아놓고 하나씩 물어보면서 체크 표시를 하는, 그런 방식이다. 물론 이렇게 세상에 존재하는 개발자의 모든 장점을 체크해볼 수 있으면 더할 나위 없이 좋겠지만, 우리의 면접 시간은 제한되어 있다. 그래서 나는 확인할 장점의 리스트를 미리 가지고 가지 않는다.

그보다 더 좋은 방법은 열린 질문을 하는 것이다. 열린 질문이라고 해서 엄청 고급스러운 질문이 아니라, 그냥 특정한 답을 기대하지 않고 그 사람의 경험을 더 깊이 끄집어낼 수 있는 질문이다.

예를 들면 다음과 같은 식이다.

• Q: 아이폰 애플리케이션 강의를 하신 적이 있네요? 아이폰 개발하는 건 다른 것에 비해 어땠나요?
• A: 지랄 같았습니다.
• Q: ㅎㅎㅎ, 어떤 점이 어려웠나요?
• A: 제일 골치아픈 건 앱이 자꾸 죽는 겁니다. 지금은 자동으로 메모리 해제를 해주는 그...
• Q: ARC 말이군요?
• A: 네, 그게 있어서 괜찮은데, 예전엔 수동으로 해제를 해줘야 했었거든요.
• Q: 그래서 그 문제를 결국 완전히 정복했나요? 아니면 아직도 어려움을 겪으시나요?
• A: 예전보단 적게 겪습니다만, 아직 완전히 그 문제를 이해했다고는 할 수 없네요.

이 정도면 이 사람은 어려운 문제를 만났을 때 그럭저럭 헤처 나가기는 하지만 완전한 개념 이해를 하려고 하는 타입은 아니다. 이쯤에서 면접관도 iOS 개발을 잘 알아서, autorelease와 release의 차이를 이해하는지에 대해 물어볼 수 있으면 더 확실하게 확인할 수 있다. 만약 이런 차이를 정확하게 이해하고 설명할 수 있다면 이 사람은 어려운 문제를 만났을 때 개념을 깊이 이해하고 해결하는 장점을 가졌다는 것을 발견한 것이다.

예를 몇 개 더 들어보자.

• Q: 최근에 node.js를 사용하셨었네요? node.js 써보니까 어떻던가요?
• A: 편한 점도 있는데, 실행 결과를 콜백으로 받아야 되는 건 좀 불편하더군요.
• Q: 최근 커뮤니티에서 node.js의 CPS 스타일에 대해 논쟁이 있었다는 것을 아시나요?
• A: 네, 관심 있게 지켜봤었습니다.
• Q: 그 논쟁에 대해 어떻게 생각하시나요?
• A: 저도 CPS 스타일은 나쁘다고 생각합니다.
• Q: 그럼 그 문제를 해결하기 위해 어떤 노력들을 해보셨나요?
• A: 처음에는 step 같은 라이브러리를 도입해서 써봤는데, 크게 도움이 되진 않더군요. 그러다가 node-fibers를 알게 되어서 써봤는데, 이게 정말 좋더군요.
• Q: 어떤 점이 좋던가요?
• A: node-fibers를 쓰면 그냥 일반적인 절차적 코드처럼 코드를 짤 수 있어요. 그래서 콜백을 신경쓰지 않고 코딩을 하는데, 비동기의 장점은 그대로 살릴 수 있어서 좋았습니다.
• Q: node-fibers를 쓰면서 어려움은 없었나요?
• A: 아, node 버전에 따라 실행 시 에러율이 높아지기도 해서 좀 고생했는데, 잘 되는 버전을 찾아서 빌드했습니다.
• Q: 잘 되는 버전은 어떻게 찾았나요?
• A: 에러 메세지로 검색을 하다보니까 github에서 issue가 나오더군요. 그래서 그 이슈가 해결된 버전을 찾았습니다.

이쯤 되면 이 사람은 커뮤니티의 흐름도 보고 있으면서 당장의 문제 해결 뿐 아니라 코드 품질에 대한 고민도 하는 사람이고(CPS는 코드 품질 문제), 문제를 해결하기 위해 끝까지 추적하는 끈기도 가진 사람이다. 단 하나의 경험을 집중적으로 파고 들어도 여러 가지 장점이 나오는 것이다. 경력이 많다고 해서 그 사람의 여러 가지 경력에 대해 다 붙잡고 물어볼 필요가 없다. 하나만 끈질기게 물고 늘어지면 여러 가지 장점이 발굴되는 것이다.

이건 면접관도 node.js 경험이 있어서 저렇게 질문을 던질 수 있다고 볼 수도 있지만, 또 질문을 자세히 뜯어보면 대부분 node.js를 몰라도 파고들 수 있는 질문이다.

물론, 후보자가 경험한 기술에 대해 면접관이 잘 알고 있다면 좀더 쉽고 편한 방법들이 많다. 이를테면, 데이터베이스 성능 문제를 많이 다룬 후보자를 만났다고 해보자. 그럼 이런 질문을 던져볼 수 있다.

• Q: 데이터베이스 성능 튜닝의 핵심을 한 문장으로 말하라면 어떻게 표현할 수 있을까요?
• A: 그야 물론 인덱스죠.

꼭 인덱스가 정답인 건 아니지만, 이런 문제에 대해 주관이 정리되어 있다면 깊이 있게 고민해왔을 가능성이 높다. 물론 인덱스라고 답했으니 인덱스에 대해서 좀더 깊이 물어봐야 한다. 이를테면 인덱스를 타지 않는 게 더 좋은 건 어떤 경우인가, MySQL에서 결합 인덱스는 어떤가, 힌트는 어떨 때 사용하는가 등등. 이것도 정답을 확인하기 위한 것이 아니다. 예를 들어 MySQL 결합 인덱스는 개판이죠하고 답했다면 왜 개판인지 또 한 번 더 물어봐야 한다.

기술을 잘 알고 있을 때는 짤막한 닫힌 질문을 여러 개 해보는 것도 도움이 될 때가 있다. 이를테면, HTML/CSS 개발자에게 블록 엘리먼트와 인라인 엘리먼트의 차이점을 설명하라고 했는데 잘 못한다면 실격 사유가 될 수 있다. 대답하면 높은 점수를 줄 수 있지만 대답 못해도 감점요인이 아닌 질문들도 있다. 이를테면 해당 기술을 깊이 있게 공부했으면 알 법한 것들을 물어보는 것이다. 내가 기술면접이라는 걸 처음 면접자로 경험한 게 NHN 입사할 때였는데, 그 때 Java의 int와 C의 int가 어떻게 다르냐는 질문을 받았다. 몰라도 별 지장 없는 것이지만 알고 있으면 아 이 사람이 제법 디테일하게 공부하는 사람이구나 하는 걸 알 수 있다.(물론 난 정확하게 대답했지 하하)

만약 어려운 문제를 해결해간 경험이 있다면 더없이 파고들기 좋은 소재다.

• Q: 온라인 결제 붙일 때 뭐가 제일 어려웠나요?
• A: 환불 프로세스 적용하는 게 제일 어려웠어요. 운영팀에서 접수를 받았을 때 주문 내역에 대한 확인도 간편해야 하고, 쉽게 취소를 할 수 있어야 하지만, 또 매니저의 승인을 받아야 하거든요. 절차가 복잡해서 뭔가 하나 놓치기가 쉬웠어요.
• Q: 그래서 어떻게 해결했나요?
• A: 처음에는 그냥 구현한 다음 운영팀 담당자 찾아가서 매번 테스트를 부탁했어요. 그런데, 처음에는 열심히 해주더니 점점 짜증을 내는 거예요. 한 번에 잘 되는 걸 들고 오길 바라나봐요. 근데 프로세스를 정확하게 설명해주는 것도 아니고, 설명할 때마다 조금씩 다른 거예요. 너무 힘들었어요.
• Q: 그래서 운영팀 담당자와의 갈등은 어떻게 해결했나요?
• A: 그림으로 정리를 해보기로 했어요. 이것도 같이 그리면 산으로 갈 것 같아서 제가 미리 지금까지 들은 이야기를 바탕으로 초안을 그렸어요. 그래서 그 초안을 들고 찾아갔죠. 그랬더니 여기저기 수정을 해주더라구요. 그리고 그 수정된 그림을 다른 운영팀 사람들에게도 보여줬어요. 그렇게 피드백을 받아서 그림을 개발팀으로 가져왔죠. 그리고는 그 그림대로 selenium으로 테스트 케이스를 만들었어요.
• Q: 테스트 케이스를 만든 이유는요?
• A: 프로세스가 복잡하다보니 테스트가 없으면 뭐 하나 놓칠 것 같아서요.
• Q: 테스트 케이스를 만들고 나니 잘 되던가요?
• A: 일단 테스트가 있으니 개발이 다른 건 괜찮았는데, 결제 모듈까지 엮어서 자동 테스트를 돌리기가 어렵더군요.
• Q: 그건 왜 어려웠어요?
• A: 아, 결제 취소를 하려면 결제를 먼저 해야 되는데 그건 ActiveX 때문에 selenium으로 자동화가 안되거든요.
• Q: 그럼 어떻게 해결했어요?
• A: 결제 모듈의 실행파일에 전달하는 인자를 봤어요. 그래서 그 인자를 정확하게 전달하면 결제 및 결제 취소가 된 것으로 볼 수 있도록 결제를 흉내내는 코드를 만들어서 테스트하기 전에 injection을 시켰어요. 그리고 그 mock 코드가 실제 결제와 동일하게 동작하는지는 매뉴얼 테스트로 확인했구요.

이 대화에서는 이 사람이 상황에 맞는 커뮤니케이션 수단을 선택할 수 있다는 것, 거듭된 수정 요구에 화를 내지 않고 애자일하게 접근해갈 수 있다는 것, 테스트 자동화에 대한 고민이 깊다는 것을 확인할 수 있다.

장점을 많이 발견하려면 결국 후보자가 자신의 경험에 대해 깊이 있게 말할 수 있도록 해야 한다. 단편적인 질문에 그치면 후보자의 답변도 단편적으로 흐르고 만다. 간혹 말하는 걸 좋아해서 장광설을 늘어놓는 후보자도 있지만, 대개 그런 장광설은 깊게 들어가기보다는 넓게 퍼지는 경향이 있기 때문에 적절한 질문으로 깊게 들어가도록 유도해야 한다. 파고들되 닫힌 질문이 아니라 열린 질문을 해야 후보자 스스로 깊게 들어갈 수 있는 것이다.

약간 사족을 넣자면, 내가 기술을 선택하는 기준은 이와 정반대다. 기술을 선택할 때는 장점이 뚜렷한 기술보다 단점이 적은 기술을 선호한다. 이것이 내가 파이썬과 장고를 선택한 이유이기도 하다. 사람과 기술은 다르다. 보완할 수 없는 치명적인 단점을 가진 사람은 생각보다 아주 드물다. 적어도 내 경력 13년 간 저 사람은 구제불능의 단점을 가졌다고 생각한 사람이 아무도 없었다. 물론 다시 상종하기 싫은 사람은 여럿 있었지만;;

팀웍을 해치는 사람 이런 것도 난 안 믿는다. 내 지론은 이거다. 팀웍이 나쁜 팀원은 없다. 팀웍이 나쁜 팀이 있을 뿐이다. 팀웍의 실패는 팀장의 책임이지 개별 팀원에 돌릴 일이 아니다. 물론 나 역시 팀장으로서 팀웍에 실패한 경험이 있지만, 적어도 난 그게 내 책임이라는 정도는 안다. 게다가 면접 자리에서 팀웍을 검증하는 건 불가능한 일이다.

커뮤니케이션 스킬도 그다지 중요하게 생각하지 않는다. 내가 오픈마루에 있을 때 어떤 팀장은 커뮤니케이션 스킬도 능력의 일부이기 때문에 기술려과 커뮤니케이션을 따로 떼서 생각할 수 없다고 주장하는 사람도 있었는데, 내 생각은 전혀 다르다. 커뮤니케이션도 팀의 역할이다. 내가 경험한 개발자 중에는 개발은 잘하는데 표현은 잘 못하는 사람도 많았다. 그런 사람이 팀에 기여하게 만들 방법은 얼마든지 있다.

목적이 장점을 발견하는 것이니만큼, 압박 면접 같은 건 안한다. 물론 내가 티몬에서 채용 면접을 했을 때 그걸 압박 면접이라고 느낀 사람도 있었는데, 솔직히 그 때는 후보자의 입장을 충분히 배려하지 못했다. 깊이 파고드는 질문을 많이 해야 하는 만큼, 그 집요함에 불쾌감을 느낄 가능성도 꽤 있다. 그래서 처음부터 긴장을 잘 풀어주고, 부드러운 톤으로 대화를 이어가야 한다. 그래도 그 때 두어 번 실수한 이후로는 잘 해온 것 같다.

한줄 요약. 채용 면접은 장점을 발견하는 과정이고, 장점을 끄집어내기 위해서는 단편적인 질문이나 닫힌 질문이 아니라, 열린 질문으로 깊이 파고들어야 한다.

블로그 소프트웨어 개발