지난 16년 동안 8개의 회사를 거치면서, 후보자의 입장에서 여러 번의 면접을 경험해봤고, 반대로 면접관으로서 회사를 대표해 수많은 후보자를 평가하기도 했다. 그 과정에서 여전히 인상 깊게 기억하는 면접이 있는가 하면, 아쉽거나 이해하기 어려운 면접도 있었다. 또한 어떻게든 훌륭하고 좋은 개발자를 찾기 위해 면접 프로세스를 설계하고 고민하면서 여러 번의 시행착오를 겪어보기도 했다. 오늘은 이러한 경험을 바탕으로 내가 생각하는 이상적인 개발자 기술 면접에 대해 이야기해보고자 한다.
단순한 기술 지식 확인 차원의 면접은…
기술 면접에서 흔히 접할 수 있는 질문들은 알고리즘 문제나 특정 언어의 문법, 또는 내부 구조에 관한 것들이다. 그런데 이러한 질문에만 초점을 맞추는 기술 면접은 지원자가 해당 기술에 대한 기초 지식이나 기본 역량을 갖추고 있는지를 빠르게 확인하는 데는 도움이 되지만, 지원자가 실제 현업에서 마주하는 복잡한 문제들을 해결할 수 있는 능력을 갖추었는지를 평가하기에는 한계가 있다고 본다.
우리가 하는 일은 종종 풀어야 할 문제가 명확하게 정의되지 않은 상태에서 시작되는 경우가 많다. 때로는 ‘매출 증대’나 ‘클릭율 향상’과 같은 목표가 분명하게 설정되지만, 이를 달성하기 위해 필요한 기능이나 기술 아키텍처는 개발자가 문제 해결 과정에서 직접 찾아내고 검증해야 하는 경우가 대부분이다.
또한 기술이라는 것은 계속해서 발전하고 변화하기 때문에, 특정한 목표를 달성하기 위한 최적의 선택이나 기술은 상황에 따라 매번 달라질 수 있다고 본다. 따라서 현재의 기술적 지식만으로 후보자를 평가하는 면접 방식은 개발자의 잠재력이나 실질적인 문제 해결 능력을 온전히 파악하기에는 어려움이 많을 것이라 생각한다.
이상적으로 생각하는 기술 면접
내가 생각하는 이상적인 기술 면접은 지원자의 과거 경험을 바탕으로 “어떤 문제를 어떻게 해결했는지를 확인하는 것" 이다. 지원자가 풀고자 했던 문제가 무엇이었는지를 명확하게 설명할 수 있는지, 그 문제를 해결하기 위해 선택한 기술과 아키텍처는 무엇이었는지, 그리고 그러한 기술 선택의 근거는 무엇이었는지, 이후의 실행 과정은 어땠는지, 실행 과정에서 예상했던 어려움과 예상치 못한 어려움은 무엇이었는지, 그리고 이를 어떻게 해결했는지 등을 질문한다. 이를 통해 후보자가 단순히 기술을 알고 있는 것 뿐만 아니라, 그 기술을 언제, 어떻게, 왜 사용하는지를 깊이 고민하고 선택할 수 있는지를 확인할 수 있다고 생각한다.
(내 경험상, 뛰어난 개발자분들에게는 적절한 면접 환경만 제공하면, 면접이라는 사실을 잊고 마치 함께 일하는 동료 개발자와 대화하듯이 자신의 기술 이야기를 열정적으로 풀어내는 경우가 많다. 사실, 면접만큼 자신의 이야기를 집중해서 들어주는 사람 앞에서 신나게 개발 이야기를 전할 수 있는 기회는 흔치 않다 ^^)
면접에서의 주요한 질문 몇 가지를 적어본다면 다음과 같다.
가장 먼저 “지원자가 풀었던 문제 중 가장 재미있거나 큰 성과를 냈던 것이 무엇인지”를 묻는다. 이러한 질문을 통해 지원자가 중요하게 생각하는 가치가 무엇인지를 파악할 수 있다고 본다. 또한, 이러한 질문을 통해 문제 안에 내재된 서비스의 목표와 가치를 지원자가 명확하게 알고 있는지도 간접적으로 확인할 수 있다고 본다.
가끔 새로운 기술 도입이나 레거시 시스템 개선에 대한 이야기를 하시는 분들이 있는데, 기술 역량을 어필한다는 관점에서는 좋은 주제이지만 1) 이러한 문제를 해결한 이후에 고객과 회사가 얻게된 가치가 무엇인지 2) 그 가치의 크기가 어느 정도였는지 3) 그리고 그 문제가 그 당시에 얼마나 높은 우선순위를 가졌는지는 명확하게 설명하지 못하는 경우가 있다. 물론 레거시로 인한 기술 부채가 팀의 생산성과 서비스 안정성에 부정적인 영향을 끼칠 수 있기 때문에 이러한 개선이 중요하지 않다는 것은 아니지만, 때로는 그 부채를 감안하더라도 더욱 시급하고 중요한 문제를 해결해야 할 때가 있다. 그렇기 때문에 레거시를 개선하는 작업에서는 개발자 스스로가 이러한 작업에 대한 가치와 우선순위를 객관적으로 평가하고, 이를 다른 동료들에게 설명하고 설득할 수 있어야 한다고 본다.
그 다음 자주 묻는 질문은 “문제를 해결하기 위해 선택한 기술과 아키텍처, 그리고 그 선택의 근거” 이다. 문제가 명확히 정의되고 목표가 분명하다면(What), 그 문제를 어떻게 해결할 것인지(How) 가 중요해진다.
하나의 문제를 해결하기 위한 방법은 여러 가지가 있을 수 있지만, 모든 기술과 아키텍처는 고유의 장단점을 가지고 있으며, 팀의 상황에 따라 그 영향도 다르게 나타난다. 그렇기 때문에 우리는 다양한 요소를 고려해 신중하게 기술을 선택해야 한다. 우선, 풀고자 하는 목표에 부합해야 하며, 기존 시스템과 아키텍처와 잘 맞아야 하고, 학습 및 운영 비용이 낮은 것이 바람직하다. 또한, 가능하다면 기술의 성숙도와 생태계가 잘 발달된 것이 그렇지 않은 것보다는 당연히 좋다. 추가로 문제 해결을 위해 검토했던 다른 대안을 설명하면서, 그러한 대안이 선택되지 않았던 사유를 설명할 수 있다면 더더욱 좋다.
마지막으로 자주 묻는 중요한 질문은 “실행 과정에서 겪은 어려움이 무엇인지, 그리고 이를 어떻게 해결했는지” 이다. 사실 초기 설계와 검토보다 더 어려운 부분은 실제로 서비스를 구현하고 런칭하여 목표를 달성하는 과정이다. 문제를 해결하는 과정에서 예상치 못한 장애물이 나타나기도 하고, 도메인 지식이 확장되면서 더 나은 해결책을 발견하기도 한다. 때로는 함께 일하던 동료가 갑자기 퇴사하거나, 심지어 비즈니스 상황에 따라 목표 자체가 변경되기도 한다. 이러한 어려움 속에서도 목표를 달성한 경험이 발견된다면, 이는 지원자가 높은 수준의 목표 달성 능력을 갖추고 있음을 증명한다고 생각한다.
이러한 질문들은 지원자가 중요하게 생각하는 가치가 무엇인지(예: 고객 경험과 비즈니스 목표 달성), 적절한 기술 구조를 선택할 판단력과 역량을 갖추었는지, 주어진 목표를 달성할 실행력을 가지고 있는지를 확인하는 데 도움이 된다고 생각한다.
과거의 기술 면접 사례 공유
좋았던 면접 경험
여러 회사에 지원하면서 기술 면접도 여러번 경험해봤는데, 그 중에서 가장 재밌고 인상 깊었던 면접은 16년의 C 사와 17년의 T 사 면접이었다.
C사의 채용 과정은 1) 영어 이력서 작성, 2) 과제 전형, 3) 전화 면접, 4) 3차례에 걸친 기술 면접, 5) 3차례에 걸친 컬쳐 면접으로 진행되었으며, 각 단계를 거칠 때마다 명확한 의도와 목적을 확인할 수 있었다. 그러나 단계가 많고 절차가 길어서 “그냥 포기하고 다른 회사로 갈까?”라는 생각이 들 정도로 많은 리소스 투자를 요구했었다.
C사의 기술 면접은 각 면접관이 1시간씩 배정되어 총 3번에 걸쳐 진행되었다. 첫 번째 면접관은 간단한 요구사항을 제시한 후 이를 화이트보드에 코드로 구현하도록 요청했고, 이후 추가적인 요구사항을 덧붙이며 기능 확장과 리팩토링을 요구했다. 어렵지 않고 재밌었던 기억만 남아있다. 두 번째 면접관은 과거 회사에서 내가 구현했던 서비스의 목적과 구조, 아키텍처를 상세하게 설명할 것을 요구하였고, 이것도 화이트보드에 그림을 그려가면서 적당한 수준에서 잘 대답했던 것 같다. 마지막 면접관은 알고리즘 문제에서 흔히 나오는 최단경로 문제를 제시했었는데, 알고리즘을 제대로 익히고 배운 적이 없었기 때문에 초반에 엄청 헤맸던 기억이 난다. 그래도 어떻게든 풀어내고 싶어서 면접관에게 역으로 질문하고 제약 조건을 얻어가면서 대충 방향성은 맞게끔 설명하고 마무리했던 것 같다.
C사의 채용 과정은 지원자의 기본적인 컴퓨터 공학 지식, 코드 구현 능력, 그리고 실제 설계 및 개발 역량을 단계별로 확인할 수 있는 구조라고 생각했다. 컬쳐 면접에서도 C사가 원하는 인재를 찾기 위한 적절한 질문들이 잘 배치되어 있었다고 본다.
T사의 기술 면접은 예상보다 어렵지 않으면서도 매우 재미있었던 기억이 난다. 세 명의 면접관이 2시간 넘게 면접을 진행했는데, 초반에는 각 면접관이 다양한 질문을 던지는 방식으로 시작됐다. 그런데 그 질문들은 흔히 다른 회사에서 물어보는 “JVM의 메모리 구조, GC 방식, 객체지향 원칙” 같은 것이 아니라, “이런 상황에서 어떤 기술을 선택할지, 그 이유는 무엇인지, 추가적인 제약 조건이 있다면 선택을 바꿀 것인지”처럼 한 번 더 생각하고 대답해야 하는 질문들이었다. 그 후에는 내가 실제로 개발하고 운영했던 특정 프로젝트를 선택해 이를 화이트보드에 그리며 상세히 설명하도록 요청했다. 면접관들은 꼬리에 꼬리를 무는 질문 방식으로 깊이 있는 질문을 이어갔고, 여기까지 진행되었을 때에는 그 순간이 면접이 아니라 흥미로운 개발 이야기를 나누는 세미나처럼 느껴지기도 했다.
그렇게 기술 면접이 끝난 후, 면접관들이 모두 퇴장하고 혼자 사무실에 남겨졌다. 약 10분 후 1차 기술 면접 합격 소식을 들었고, 바로 이어서 2차 면접이 진행되었다. 그리고 다시 1시간도 안 되어 최종 합격 통보를 받았다. 이렇게 빠르게 결정하고 실행하는 T사의 업무 방식이 매우 마음에 들어, 합격했던 다른 회사들은 생각하지 않고 T사로 이직해야겠다고 결심했었다.
탈락을 줄 수 밖에 없었던 면접
2019년 이후로는 특정 회사에 지원하는 입장이 아니라, 회사를 대표해 지원자를 평가하는 면접관의 입장으로 기술 면접에 참여했던 것 같다. 위에서는 내가 생각하는 이상적인 면접 방식과 인상 깊었던 실제 면접 경험을 적었고, 이제는 면접 과정에서 탈락 결정을 내릴 수밖에 없었던 사례를 이야기해보고자 한다. (물론, 후보자를 특정할 수 없도록 상세한 정보는 제외하고, 맥락만 이해할 수 있는 수준으로 기술할 예정이다)
12년차 백엔드 개발자 면접이 있었다. 면접 진행 과정에서 Redis 사용 경험을 기반으로 질문과 답변을 이어가다가 합격 의견을 드리기 어려운 사항을 발견하였다.
- “Redis 를 통해 캐시를 적용했지만, Database 에서 데이터를 가져오는 것이 Redis 를 통해 데이터를 가져오는 것보다 빨랐다” /// 정말일까? 물론 내가 해당 시스템의 상세 구현을 알 수 없으니 그럴 수도 있겠다는 생각은 든다. 그럼 왜그럴까? 네트워크 레이턴시는 동일하다는 가정 하에 메모리 기반의 조회보다 테이블에서의 조회가 더 빠른 이유가 뭘까? PK 기반의 조회? 테이블 조인은 거의 없겠지?
- “Redis 에 저장된 데이터를 직렬화, 역직렬화 하는 과정에서 느린 병목이 있었다” /// 자바 기본 직렬화 방식을 사용한 것인가? 그래도 그게 DB 조회 이상으로 엄청 느리진 않을텐데? 근데 직렬화가 병목인 것은 어떻게 알았을까? 그리고 직렬화, 역직렬화 속도를 개선한다면 어떤 방법이 있었을까? 그리고… 직렬화, 역직렬화는 서비스 통신 구간, 저장 과정에서 언제든지 발생하는 것 아닌가?)
- “이러한 상황을 개선하고자 리모트 캐시 방식을 로컬 캐시 방식으로 모두 변경하였다" /// ??? 아까는 캐시 사용 구간에서의 직렬화, 역직렬화가 병목이라고 했는데, 갑자기 리모트 캐시를 로컬 캐시로 변경해서 문제를 해결했다? 파편화 이슈는 어떻게 해결했을까? 서버를 새로 띄울 때마다 데이터 웜업은 어떻게 해결했을까? 네트워크 레이턴시는 당연히 훨씬 줄어들었겠지만, 직렬화 이슈는 그대로일 것 같은데?
이런 방식으로 기술 면접이 진행되면서 지원자의 문제 정의와 해결 과정에서의 의문이 점점 쌓여갔다. 이러한 의문을 풀고자 기술 질문의 범위를 좁혀 하나씩 상세히 질문하였는데, 그 때마다 의문이 풀리기보다는 점점 쌓여가면서 이해하기 어려운 부분들이 계속 드러났고, 결국 탈락 의견을 줄 수 밖에 없는 상황으로 이어졌던 기억이 난다.
16년차 백엔드 개발자 면접이 있었다. 이 분은 여러 회사를 경험하면서 다양한 기술을 실제로 경험하고 적용하였던 이력이 발견되었기 때문에 큰 기대를 가지고 면접을 진행했던 기억이 난다. 그럼에도 2시간 정도의 기술 면접을 진행하면서 탈락 의견을 줄 수 밖에 없었던 사유는, 모든 기술 선택의 기준이 “고객 경험과 비즈니스 목표 달성" 이 아니라, “내가 써보고 싶은 최신 기술인지" 였기 때문이었다.
기존 로직으로 충분히 해결할 수 있었던 요구사항에 굳이 Spring Integration을 적용하여 프로젝트의 복잡도를 높였고, gRpc 를 선택할 근거가 충분하지 않았던 프로젝트에 굳이 gRPC를 도입했으며, akka 같이 학습 난이도가 높은 Actor 모델 기반 오픈소스를 초기 개발팀에 도입한 것이 이분의 탈락 사유였다. 이분이 속했던 여러 회사의 개발 팀은 대부분 규모가 작았고, 이분이 퇴사한 후에는 그러한 기술을 빠르게 익히고 운영할만한 팀원이 부족했거나 전무한 경우가 많았다. 이런 식의 기술 선택은 개인을 넘어서 팀 전체의 운영에 악영향을 미칠 수 있다고 판단했고, 무엇보다 중요한 문제는 지원자가 개발하고 운영하는 서비스에서 고객 경험이라는 핵심 가치를 발견하기 어려웠다는 점이었다. 동년배 개발자였기 때문에 나도 잘 알고 있었던 것은, Spring Integration, gRPC, akka 와 같은 기술이 개발 커뮤니티에 회자되는 시점이, 이 분이 그런 기술을 실제로 도입했던 시점과 일치한다는 것이었다. 이는 지원자의 기술 선택 기준이 “고객 경험과 비즈니스 목표 달성” 보다는 “쓰고 싶은 기술” 에 있다는 것을 간접적으로 확인할 수 있는 것이라고 봤다.
마무리
개발자 면접은 단순히 기술적인 지식이나 특정 언어의 숙련도를 평가하는 자리가 되어서는 안된다고 생각한다. 물론 기술적인 지식은 개발자로서 기본적으로 갖춰야할 소양이지만, 내가 생각하는 이상적인 기술 면접은 그 이상의 요소를 포함해야 한다고 본다. 면접이라는 것은 우리가 함께 일할 동료를 찾는 과정이기 때문에 실제로 우리가 일하는 방식, 우리가 추구해야 하는 가치와 일치하는 분들을 찾아야 하고, 그 때문에 기술 면접도 실제로 일하는 과정에서 필요로 하는 역량을 검증하는 방식으로 이루어져야 한다고 생각한다.
아무쪼록 이러한 글이 기술 면접을 준비하는 분들에게 도움이 되었으면 한다.
