칼럼 | AI 개발 시대, 코딩 면접은 정말 필요할까

좋은 소프트웨어 개발자를 채용하는 일은 어렵다. 채용 공고에 지원하도록 유도하는 것도 쉽지 않고, 면접에 응하게 하는 일도 쉽지 않다. 하지만 가장 어려운 건, 면접을 본 이후 이 후보자가 실제로 채용할 만한 인재인지 판단하는 일이다. 이 사람이 좋은 코드를 작성할 수 있을까? 자신이 안다고 말한 프로그래밍 언어를 정말 알고 있는 걸까? 실제 경력 수준은 어느 정도일까? 게다가 코딩 실력만으로는 부족하다. 개발자는 원활하게 소통할 수 있어야 하며, 끊임없이 변화하는 기술 생태계도 따라잡아야 한다. 이런 요소들을 짧은 면접 몇 차례로 파악하는 것은 결코 쉽지 않다.

그만큼 리스크도 크다. 잘못된 사람을 뽑으면 시간은 물론 코드 품질 면에서도 큰 손실을 입게 된다.

이처럼 복잡한 채용 문제를 해결하기 위해 많은 조직은 면접 과정에 코딩 테스트를 포함시킨다. 이 방식이 과연 적절한지에 대한 논쟁은 끊이지 않고 있으며, 이에 대해 나 역시 생각을 덧붙이고자 한다.

스트레스 테스트

초기에는 면접 현장에서 화이트보드에 직접 코드를 작성하게 했다. 예를 들어 ‘링크드 리스트를 뒤집는 함수를 작성하라’거나 ‘정렬된 배열에서 이진 탐색을 구현하라’는 식의 문제를 출제했다. 대형 테크 기업들이 이러한 질문으로 유명해지면서, 리트코드(LeetCode)나 알고익스퍼트(AlgoExpert) 같은 문제 풀이 사이트까지 생겨났다.

더 창의적이고 어려운 퍼즐을 출제하고 싶은 유혹도 크지만, 이 방식은 자칫 후보자를 걸러내기 위한 ‘덫’을 만드는 문화로 이어질 수 있다. 현실에서는 개발자가 화이트보드에 코드를 작성하지 않는다. 그들은 통합 개발 환경(IDE)을 사용한다. 건조한 화이트보드 마커로 억지로 코딩하던 방식은 이제 화면 공유를 통한 실시간 코딩으로 바뀌었지만, 여전히 과도한 압박감 속에서 비효율적인 결과로 이어지는 경우가 많다.

필자 역시 수많은 화이트보드 코딩 면접을 진행해봤지만, 그 결과에 만족하지 못했다. 경험상 이 방식은 ‘걸릴 수도, 아닐 수도 있는’ 운에 가깝다. 어떤 지원자는 잘 해내고, 어떤 이는 당황한다. 물론 화이트보드 코딩을 잘하는 지원자는 대체로 유능한 개발자인 경우가 많았다. 압박 속에서도 민첩하게 사고할 수 있다는 점은 분명 유용한 역량이기 때문이다.

하지만 필자는 이런 테스트에서 당황했다고 해서 그 사람이 능력이 부족하다고 단정할 수 없다고 생각했다. 아마도 나는 화이트보드에서 ‘덫’ 같은 문제를 풀지 못한 유능한 후보자들을 놓쳤을 것이다. 게다가 면접 과정이 후보자에게 ‘함정’처럼 느껴진다면, 그 과정이 어떤 인상을 남길지 다시 생각해봐야 한다.

모든 유능한 개발자가 압박 속에서 빠르게 사고할 수 있는 것은 아니다. 오히려 ‘문제를 체계적으로 분석하고, 끝내 훌륭한 결과를 도출하는 능력’이야말로 훨씬 더 중요하지 않을까?

실무에 가까운 과제형 테스트

이후 우리는 지원자에게 과제를 제공하는 방식으로 전환했다. 문제는 더 깊고 넓어졌다. ‘간단한 신호등 시스템을 만들어라’ 혹은 ‘기초적인 밈 생성기를 개발하라’ 같은 유형이었다. 이 방식은 기본적인 설계 역량까지 포함해, 개발자가 실제로 시간과 노력을 투입해야만 해결할 수 있도록 구성됐다. 지원자는 일정 기간 동안 과제를 수행한 뒤, 결과물을 시연하고 코드에 대해 설명한다.

필자는 이 방식이 훨씬 더 낫다고 생각한다. 실제 개발자가 일하는 방식과 유사하기 때문이다. 현실에서는 개발자에게 즉흥적으로 정답을 내놓으라고 하지 않는다. 문제를 조사하고, 숙고하고, 다양한 해결책을 고민하면서 최적의 설계를 찾는 것이 더 중요하다. 개발자에게 일주일 정도 시간을 주고 문제를 풀게 하는 것이, 그들의 실제 역량을 평가하는 훨씬 나은 방법이다.

물론 이 방식에 대한 반론도 있다. ‘인터넷에서 정답을 검색하거나, AI에게 문제를 풀게 할 것이다’라는 주장이다. 이에 대한 필자의 답은 “그거면 괜찮다.”다. 필자는 개발자가 어떤 방식으로 답을 도출했는지에는 큰 관심이 없다. 그들이 문제를 해결할 수 있느냐가 핵심이다. 코드를 어디서 가져왔는지보다, 그 코드에 대한 ‘소유감’을 어떻게 드러내는지가 더 중요하다. 만약 제출한 코드가 잘 작성되어 있고, 단위 테스트도 포함되어 있으며, 그 코드가 무엇을 하고 어떻게 작동하는지를 명확히 설명할 수 있다면, 그 코드가 어떻게 만들어졌는지를 따질 이유가 없다.

솔직히 말해 요즘 시대에 AI를 활용하지 않는다면, 그 개발자는 이미 뒤처진 셈이다. 나는 우리 개발팀이 가능한 모든 도구를 활용해 빠르고 정확하게 업무를 수행하길 원한다. 오히려 과제형 문제를 풀면서 AI나 외부 자원을 사용하지 않은 개발자라면 의심스럽게 바라볼 것이다. 후보자의 성공 여부는 과제를 ‘어떻게’ 수행했느냐보다, 주어진 문제에 대해 ‘얼마나 잘 설명하고 설득력 있게 전달할 수 있는가’에 달려 있다. 이 능력을 갖추고 있다면, 그 과정이 어떻게 진행됐는지는 중요하지 않다.

결국 면접 과정의 목적은 단 하나다. ‘이 후보자가 우리가 필요로 하는 일을 해낼 수 있는 사람인가?’라는 질문에 답을 찾는 것이다. 만약 지원자가 요건에 부합하는 깔끔하고 작동 가능한 코드를 제출하고, 사고 과정을 명확하게 전달하며, 상황에 맞춰 해결책을 유연하게 조정할 수 있다면, 그들이 어떤 방법으로 정답에 도달했는지는 중요하지 않다. 그런 개발자가 바로 당신 팀에 필요한 인재다.
dl-ciokorea@foundryco.com