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

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

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

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

스트레스 테스트

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

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

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

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

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

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

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

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

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

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

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