오늘 지인과 전화 통화를 했다. 이런저런 이야기를 나누다 최근 면접에서 어려움을 겪었다는 말이 나왔다. 외국계 회사 본사의 개발자들과 온라인 코딩 면접을 봤는데 프로그래머스 같은 라이브코딩 서비스로 진행했다 한다. 그런데 라이브코딩 서비스로 코딩 인터뷰를 진행한다는 안내 자체를 받지 못해서 당황했다고 한다. 지인은 이런 면접을 많이 접하지 않은 채로 한 회사에서 쭉 승진해 온 사람이다. 접할 기회가 드물었으니 어려움이 컸던 듯하다.
라이브코딩 면접 자체가 문제는 아니다. 문제는 크게 두 가지다. 라이브코딩으로 무엇을 얻으려는지 뚜렷한 생각 없이 남들이 하니까 관성적으로 따라 하는 것, 그리고 최종 수요자인 면접자의 관점이 아니라 공급자인 회사 위주로 면접을 편성하고 고민하지 않는 것. 나는 이 문제를 오늘 처음 생각한 것이 아니다. 십여 년 넘게 고민해온 문제이고, 이 관점이 이 업계에서 극히 소수를 대변한다는 것도 알고 있다.
구글 출신 지원자
오래전 이야기다. 구글이 첫 회사였던 면접자가 있었다. 구글만 꽤 오래 다니다가 새로운 환경을 찾고 있다고 했다. 우리도 기대가 컸다. 적합한 사람을 1년 넘게 찾아 헤매는 중이었고 그 사이 합격했던 두 명은 모두 다른 곳에 빼앗겼는데 구글에서 후보자가 오다니!
나는 그의 이력서를 읽고 구글의 데이터베이스인 Spanner와 MySQL 중 어느 걸 선호하는지 그 이유는 무엇인지 물었다. MySQL은 대학 때 써본 것이 전부라 기억이 안 나고 구글에서는 Spanner가 아닌 다른 데이터베이스를 이용하려면 제약이 많았다고 했다. 그 점은 수긍이 갔다. 그래서 부탁했다. Spanner의 특징, 좋아했던 점이라도 설명해달라고. 대답을 못 했다. 아쉽지만 탈락이었다.
그 친구가 만약 라이브코딩 면접을 봤다면 손쉽게 통과했을 것이다. 하지만 생각을 묻는 내 방식의 면접에서는 그렇지 않았다.
시킨 일만 하는 사람을 채용한다면, 별다른 고민 없이 요즘 업계가 하는 방식으로 라이브코딩 면접을 해도 별 상관은 없다. 하지만 자율적으로 일하고 고성과를 추구하는 사람을 찾는다면 생각해볼 일화다. 라이브코딩 시험이 실제로 무엇을 측정하는지 살펴보자.
시험은 익숙함을 측정한다
라이브코딩 류의 시험은 사전 안내가 있으면 이런저런 문제를 구해서 풀어보고 익숙해지는 것만으로도 도움이 많이 된다. 짧은 시간 안에 과제를 해야 하기 때문에 익숙하냐 아니냐도 중요한 문제가 된다. 라이브코딩 서비스마다 환경도 다르다. 어디는 Visual Studio Code를 쓰고 다른 데는 다른 IDE를 쓴다. 시간이 짧을 때는 IDE 숙련도도 크게 작용한다. 소프트웨어 개발 분야는 워낙 다양한 기술을 다루고 회사마다 기대하는 바도 서로 다르다. 이런 걸 안내하지 않으면 우연히 그 회사의 시험에 과적합된 사람을 채용하게 될 뿐이다.
이건 추측이 아니다. 한 회사가 라이브코딩 면접을 도입하기 전에 사전 테스트를 했고 나는 그 과정을 심사관으로 지켜봤다. 1회차에는 안내가 없었다. 아무런 안내를 못 받은 상태에서는 IDE가 익숙한지 아닌지만으로 면접의 승패가 갈리기도 했다. “VSCode 처음 써봐요”라는 지원자도 실전에서 나왔다. 2회차에는 VSCode 기반으로 면접을 진행한다고 미리 안내하고 면접자가 준비할 기회를 줬다. 그러자 그런 사소한 문제로 면접에서 떨어지는 일은 없었다. 안내 하나로 면접 결과가 크게 달라졌다.
문제 쪽도 마찬가지였다. 자바 면접이라고만 안내해놓고 실무에서 쓰는 스프링 프레임워크의 웹 API 개발을 라이브코딩 문제로 냈다. 스프링은 자바의 전형이 아닌데 문제를 낸 면접관이 자기 업무에 갇혀서 그렇게 생각했던 것이다. Java Stream처럼 당시 기준으로는 최신이었던 기능을 묻는 문제도 있었다. 자바 스트림을 사용할 줄 안다는 게 어떤 의미가 있을까. 출시된 지 얼마 안 된 릴리즈는 사용 못하게 하는 곳에 재직 중인 면접자라면 이걸 기준으로 그 사람의 역량을 평가해도 되는 걸까? 차라리 몇 가지 문제 유형을 준비해놓고 면접자가 고르게 하는 게 나을 것이다. 처음부터 Spring Framework로 웹 서비스를 개발하는 과제가 있을 거라 안내했다면 더 좋았을 것이다.
이제야 드러난 것
대 AI 시대가 와서 코딩 인터뷰가 망가졌다는 이야기가 많다. 내 논지는 반대다. 이제야 사람들이 깨닫기 시작했을 뿐, 시험은 이미 십여 년 전, 한국에 코딩 인터뷰가 본격적으로 보급되던 시기, 어쩌면 그 이전에 이미 망가졌다. 그 사실이 AI 덕에 이제야 수면 위에 드러났을 뿐이다.
최근 데이터도 그렇다. interviewing.io의 실험에서 출제 그대로, 변형 없이 풀어둔 문제를 ChatGPT에 의존해 푼 지원자의 73%가 합격했다. 정직하게 본 지원자의 평균 합격률은 53%였다. 부정행위를 언급한 면접관은 0명이었다. 다른 조사에서는 FAANG 면접관의 81%가 지원자의 AI 컨닝을 의심한다고 답했고 3분의 1은 실제로 적발해 본 경험이 있었다.
흥미로운 건 업계가 이 사실을 두고 내리는 결론의 방향이다. 지원자를 의심하고, 문제 은행을 갱신하고, 감시를 강화하거나 대면 면접으로 돌아가자는 목소리가 나온다. 전부 시험을 지키는 쪽이다. 이 담론조차 지원자를 문제의 근원으로 본다. “이건 무결성의 위기가 아니라 측정의 위기”라고 짚은 글은 드물다. 측정은 무너졌는데 시험을 운영하는 쪽의 자세는 아직 그대로다.
생각하지 않아도 되는 편함
왜 이럴까. 나는 업계에 채용의 절실함이 부족하니까 코딩 인터뷰라는 손쉬운 길로 빠진다고 본다. 무엇을 얻으려는지 생각하지 않아도 되니까 편한 것이다. 코딩 인터뷰는 객관적인 결과를 보증해 준다고 믿는데, 그 믿음 뒤에 숨어서 채용에서 우리가 무엇을 얻으려 하는지, 이 면접이 그러한 목적에 부합하는지 묻지 않는다. 정말 좋은 사람이 단순히 준비를 못 해서 떨어져도 채용과 면접의 목적을 생각해본 적이 없으니 손해라는 자각조차 없다.
채용시장은 회사가 일방적으로 시혜를 베푸는 곳이 아니다. 시장에서 최고인 사람은 소수이고 그들을 데려오려면 그만한 노력이 따라야 한다. 노력이란 결국 이 시험으로 무엇을 얻으려는지 원점에서 고민하는 일이다. 그 고민 없이 남들이 하는 대로 라이브코딩 면접을 맡긴다면 시장에서 그럭저럭한 수준에 머물게 된다.
생각을 묻는 면접
스타트업 시절을 떠올리면, 우리는 돈이 많지 않았다. 잠재력은 매우 높지만 어떤 이유로 시장에서는 덜 인정받는 사람을 싸게 데려와야 했다. 그래서 잠재력 있는 사람을 발견하면 내가 그 사람의 부족한 부분을 채워줄 수 있는지부터 생각하고 제안했다. 시킨 일만 해야 하는 환경에 질린 사람에게는 어느 정도의 자율적인 결정권을 주겠다고 약속하면 됐고 내가 먼저 다뤄 본 기술을 경험하고 싶어 하는 사람이라면 어려울 게 없었다. 물론 큰 회사일수록, 내 위치가 낮을수록 약속하기 힘든 부분이 많다. 때로는 일반화하기 어려운 방법이라는 것도 안다.
사람이나 조직에 따라 지원자에게 바라는 바가 다를 것이다. 나는 잠재력을 가진 사람을 원했고 이때 내가 말하는 잠재력은 독립적으로 일할 수 있게 빠르게 성장하는 힘이다. 성장하려는 열의는 기본이고 무엇보다 자기만의 생각이 있어야 한다. 그래서 나는 주로 그 사람의 생각을 물어본다. 예를 들어 7년짜리 이력서에 서로 다른 회사의 MySQL과 MSSQL 사용 경험이 적혀 있으면, MySQL과 MSSQL 중 뭐가 더 맘에 드는지, 그 이유는 무엇인지 묻는다. 그리고 대답에 따라 더 깊게 물어본다. 정답을 정해놓고 물어보지 않는다. 나와 의견이 100% 달랐던 사람도 자기 생각이 뚜렷하면 주저하지 않고 합격시켰다. 의외로 자기 의견이 뚜렷한 사람은 적다. 내가 다뤄보지 않은 기술이라도, 상대가 정말 알고 말하는지 그저 감정적인 대답을 내뱉을 뿐인지 구분하는 건 어렵지 않다.
한 가지 기술에 집착하는 면접도 하지 않았다. 자바를 주로 쓰는 부서에서 자바 관련 질문을 하는 건 정상이다. 하지만 그 부서가 자바만 평생 할 것인가? 기술 트렌드는 바뀌고 맡게 될 과제에는 자바보다 파이썬이 적합할 수도 있다. 그래서 유연한 사람이 필요하다.
그 어떤 면접 방식도 완벽할 수는 없다. 이렇게 뽑았다고 다 잘됐다고는 못 하겠다. 하지만 실망한 경우가 적었다는 것은 단언할 수 있다. 그리고 이 방식에는 결정적인 장점이 하나 있다. 이력서만 있으면 충분하다. 면접자가 준비를 많이 할 필요가 없다. 회사가 절대 갑이 아닌 스타트업에서는 이 점도 매우 중요했다.
그런데 이런 방식을 두고 이력서가 너무 많이 들어와서 힘들다고 말하는 사람이 있다면, 그 사람은 행복에 겨운 것이고 동시에 게으른 것이다. 나는 그럴 때 간단한 기재로 걸러냈다. JD에 나이나 성별 등은 기술하지 말라고 눈에 띄게 안내해두고 이력서에 그런 것이 기재되어 있으면 탈락시켰다. 생각보다 많은 사람이 걸러졌다. 자잘한 어려움을 핑계 삼지 말고 면접과 채용으로 무엇을 얻고자 하는지를 더 고민하자.
구글은 어땠는가
누가 이렇게 면접자에게 신경 쓰냐고 물을지 모르겠다. 구글이 그랬다. 그리고 각 시기에 내가 선망했던 회사들이 그랬다. 내가 경영진이었던 회사도 그랬다. 이런 회사가 적기 때문에 내가 이 글을 쓰지만 이런 회사가 없지는 않다. 구글은 안내 자료만 수십 장이었고 그 안에 추천 서적과 면접에서 다룰 수도 있는 여러 컴퓨터과학 주제를 폭넓게 알려 줬다. 유튜브에 안내 영상도 있었다. 물론 요즘도 그런지는 확실하지 않다.
온전하게 객관적인 면접, 라이브코딩이 나쁘니 버리란 말이 아니다. 그 뒤에 숨지 말라는 거다. 어떤 면접도 객관적일 수 없다. 그렇게 믿기 쉬운 면접 유형이 있을 뿐이다. 그러니 라이브코딩을 책임 회피, 게으름의 정당화용으로 쓰지 말고 면접으로 뭘 얻으려 하는지 원점에서 고민하자는 거다. 면접자를 을이라고 여겨서는 안 되고 면접자들이 동일선상에서 출발하도록 기본적인 조치는 하자. 코딩 인터뷰를 도입하겠다면 최소한 그 정도는 감당해야 하지 않겠나.
정리하면 이렇다. 이 시험으로 무엇을 얻으려는지 생각해보지도 않고 단편적인 정보로 사람을 쉽게 채용하려는 게으름을 극복하자. 자율적인 사고를 할 줄 아는 사람을 채용하자.
지인의 면접은 아직 진행 중이다.
참고한 글
- interviewing.io — “How hard is it to cheat with ChatGPT in technical interviews?” 컨닝 실험. https://interviewing.io/blog/how-hard-is-it-to-cheat-with-chatgpt-in-technical-interviews
- interviewing.io — “How is AI changing interview processes? Not much and a whole lot.” FAANG 면접관 설문. https://interviewing.io/blog/how-is-ai-changing-interview-processes-not-much-and-a-whole-lot
- Built In — “Is Anthropic’s ‘Cheating’ Scandal the End of the Coding Interview?” (2026). “무결성 위기가 아니라 측정 위기”. https://builtin.com/articles/reimagining-coding-interview
- Joel Spolsky — “The Guerrilla Guide to Interviewing, v3.0” (2006). 객관적 절차를 제대로 하려면 감당해야 할 성실량의 잣대. https://www.joelonsoftware.com/2006/10/25/the-guerrilla-guide-to-interviewing-version-30/
- Valeri Karpov — “I Don’t Want To Hire You If You Can’t Reverse a Binary Tree” (2015). 이 논쟁의 반대 진영 최선수. https://thecodebarbarian.com/i-dont-want-to-hire-you-if-you-cant-reverse-a-binary-tree
