결론부터 말씀드리겠습니다. 코딩 테스트에서 정답을 맞혀도 개발자 면접에서는 떨어집니다. 면접관은 여러분이 제출한 완성된 코드를 정답지와 대조하지 않습니다. 문제를 어떻게 좁히는지, 접근을 어떻게 소리 내어 설명하는지, 엣지 케이스를 어떻게 다루는지를 봅니다. 그리고 2026년에는 이유가 하나 더 늘었습니다. AI가 정답 코드를 순식간에 대신 써주면서, 코드를 짜는 능력 자체의 신호값이 떨어졌습니다. 오늘은 개발자 면접이 실제로 무엇을 채점하는지, 그리고 AI가 낀 지금 어떻게 준비해야 하는지 이야기해보겠습니다.
코딩 테스트를 맞혀도 개발자 면접에서 떨어지는 이유
먼저 오해부터 걷어내겠습니다. 많은 지원자가 코딩 면접을 정답 맞히기 게임으로 준비합니다. 문제를 최대한 많이 풀고, 최적해를 외우고, 제출 버튼을 누르면 통과라고 믿습니다. 그런데 상위 IT 기업들이 공개한 코딩 면접 평가 기준은 네 축입니다. 커뮤니케이션, 문제 해결, 기술 역량, 그리고 테스트. 최종 코드가 맞았는지는 이 중 일부일 뿐입니다.
정답 코드는 필요조건이지 충분조건이 아닙니다. 면접관 자리에 앉아 보면 이게 확연히 보입니다. 정답을 다 완성한 지원자가 왜 떨어지는지. 한마디 말도 없이 20분을 코딩하고 완성된 화면을 내밀면, 저는 그 사람이 문제를 어떻게 이해했는지, 왜 그 자료구조를 골랐는지, 다른 선택지를 고려는 했는지 알 방법이 없습니다. 평가할 근거가 없으니 점수를 줄 수가 없습니다. (침묵 속의 정답은 생각보다 점수가 되지 않습니다.) 반대로 절반밖에 못 짰지만 접근을 또렷하게 설명한 지원자는 통과하기도 합니다.
면접관은 코드가 아니라 사고의 경로를 채점한다
왜 코드가 아니라 과정일까요. 수학자 조지 폴리아가 1945년에 쓴 문제 해결론이 답을 줍니다. 폴리아는 문제를 푸는 과정을 네 단계로 나눴습니다. 문제를 이해하고, 계획을 세우고, 계획을 실행하고, 돌아보며 검토하는 것. 대부분의 지원자는 곧장 세 번째 단계인 실행부터 뛰어듭니다. 하지만 면접관이 보려는 신호는 첫 두 단계에 몰려 있습니다. 무엇을 묻는 문제인지 되묻고, 어떤 접근이 가능한지 소리 내어 저울질하는 지점 말입니다.
이건 개발만의 이야기가 아닙니다. 시니어 개발자가 코드를 짜기 전에 요구사항과 설계에 시간을 쓰는 습관이 면접이라는 45분으로 압축된 것뿐입니다. 실무에서 좋은 코드를 낳는 습관과 면접에서 점수를 얻는 행동은 같은 뿌리에서 나옵니다.
폴리아의 네 단계를 코딩 면접에 대입하면 감점과 가점이 이렇게 갈립니다.
| 단계 | 흔한 실패 | 노련한 접근 |
|---|---|---|
| 이해 | 문제를 받자마자 코딩 시작 | 입력 범위·제약·엣지 케이스부터 되물음 |
| 계획 | 떠오른 첫 해법으로 직행 | 두어 개 접근의 시간·공간 복잡도를 소리 내어 비교 |
| 실행 | 침묵 속에서 코드만 작성 | 지금 무엇을 왜 하는지 말하며 코딩 |
| 검토 | 통과하면 끝 | 스스로 반례를 던지고 개선점을 언급 |
소리 내어 풀기는 실력이 아니라 담력을 재기도 한다
여기서 불편한 진실을 하나 짚어야 합니다. 면접관이 사고 과정을 보려고 요구하는 그 소리 내어 풀기가, 실력만이 아니라 관찰 스트레스를 함께 잰다는 것입니다.
2020년 마흐나즈 베흐루지와 크리스 파닌 연구팀은 컴퓨터공학 전공자 48명을 두 집단으로 나눠 실험했습니다. 한쪽은 면접관이 지켜보는 앞에서 화이트보드 문제를 풀게 했고, 다른 쪽은 면접관 없이 혼자 풀게 했습니다. 결과는 분명했습니다. 지켜보는 조건의 참가자는 혼자 푸는 조건보다 문제 해결 성능이 약 50% 낮았고, 스트레스와 인지 부하 지표가 더 높았으며, 더 나은 해답에 도달하는 비율도 낮았습니다. 같은 사람이라도 누가 보고 있느냐에 따라 절반의 실력만 나왔다는 뜻입니다.
인지심리학자 존 스웰러의 인지 부하 이론이 이 현상을 설명합니다. 작업 기억의 용량은 한정돼 있는데, 문제 자체의 난이도가 주는 부하 위에 관찰당한다는 긴장과 말을 만들어내는 부담이 얹히면 정작 문제를 풀 여력이 줄어듭니다. 시작 지점에서 잠깐 멈추는 것조차 느려 보일까 봐 조바심이 나고, 그 조바심이 다시 부하를 키웁니다. 그러니 면접에서 얼어붙는 것은 여러분만의 문제도, 실력 부족의 증거도 아닙니다. 형식이 만들어내는 구조적 부작용입니다. 다만 이 사실을 안다고 형식이 바뀌지는 않으니, 대비의 방향이 달라질 뿐입니다.
2026년, AI가 정답을 대신 쓰면서 면접이 다시 바뀌었다
여기에 최근 이 년 사이 지형이 통째로 흔들렸습니다. AI가 웬만한 알고리즘 문제의 정답 코드를 몇 초 만에 뱉어내면서, 정답 코드로 지원자를 가른다는 전제 자체가 무너진 것입니다. 개발자의 대다수가 이미 일상 업무에서 AI 코딩 도구를 쓰는 상황에서, 면접만 그 존재를 없는 척할 수는 없게 됐습니다.
기업들의 대응은 둘로 갈렸습니다. 한쪽은 차단을 택했습니다. 아마존은 면접 중 AI 사용에 실격 조항을 뒀고, 골드만삭스는 녹화 면접에서 AI를 금지했습니다. 라이브 코딩 라운드는 대체로 자동완성을 끄고 진행되며, 명시가 없으면 AI는 꺼져 있다고 가정하는 게 안전합니다. 몰래 쓰다 적발되면 영구 불채용 명단에 오를 수 있습니다. 다른 한쪽은 아예 끌어안았습니다. 메타는 후보가 모델을 쓸 수 있는 AI 라운드를 도입했고, 쇼피파이는 자기 IDE와 AI 페어 도구를 들고 오게 했으며, 캔바는 백엔드·프론트엔드·ML 직군 후보에게 AI 도구 사용을 기대한다고 못박았습니다.
| 접근 | 대표 사례 | 후보가 준비할 것 |
|---|---|---|
| 금지 | 아마존·골드만삭스, 대부분의 라이브 라운드 | AI 없이 사고 과정을 또렷이 설명하는 연습 |
| 허용·기대 | 메타·쇼피파이·캔바 | 프롬프트 설계, 출력 검증, 통합 판단 |
| 새 포맷 | 구글의 코드 이해 라운드 | AI가 낀 코드를 읽고 버그를 찾아 근거 대기 |
특히 눈여겨볼 것은 구글이 2026년 면접 루프에 넣은 코드 이해 라운드입니다. 기존 코드베이스를 주고 읽고 디버깅하고 최적화하게 하는데, Gemini를 옆에 켜둔 채 진행하며 프롬프트 설계, 출력 검증, 디버깅 능력을 평가합니다. 여기서 더 나아간 AI 코드 리뷰 형식도 등장했습니다. AI가 그럴듯하게 짰지만 미묘한 버그나 설계 결함이 숨은 코드를 주고, 무엇이 왜 문제인지 찾아 설명하고 고치게 하는 것입니다. 이건 정확히 AI가 짠 코드를 누가 검증하느냐는 질문을 면접장으로 옮겨온 것이고, 코드 리뷰가 코드를 눈으로 읽는 게 아니라 의도와 위험을 판단하는 일이라는 원리와 같습니다. 정답을 만드는 능력의 값이 떨어진 자리를, 정답을 의심하고 검증하는 판단이 채우고 있습니다.
그래서 준비는 암기가 아니라 언어화와 판단 리허설이다
정리하면 준비의 방향이 세 갈래로 바뀝니다. 첫째, 소리 내어 푸는 것을 리허설로 자동화합니다. 베흐루지 연구가 보여줬듯 관찰 스트레스는 실재하므로, 접근을 말로 설명하는 행위가 몸에 배어 인지 부하를 덜 잡아먹도록 미리 반복해야 합니다. 정답을 조용히 맞히는 연습만으로는 이 근육이 자라지 않습니다.
제가 예전에 알고리즘 스터디를 운영할 때, 정답을 맞히는 것보다 접근을 소리 내어 설명하는 걸 규칙으로 삼았습니다. 통과한 코드라도 왜 그렇게 풀었는지 3분 안에 설명하지 못하면 다시 풀게 했습니다. 처음엔 다들 어색해했지만, 몇 주 지나자 문제를 보는 순간 입이 먼저 움직였습니다. 나중에 실제 면접을 본 스터디원들이 입을 모아 말한 게, 손보다 말이 먼저 나오는 습관이 긴장 속에서 가장 큰 자산이었다는 것이었습니다. (외운 문제 수보다 설명한 횟수가 합격을 갈랐습니다.)
둘째, 접근을 먼저 말하고 코딩합니다. 폴리아의 이해와 계획 단계를 눈에 보이게 만드는 것입니다. 입력 범위와 제약을 되묻고, 두어 개 접근의 트레이드오프를 소리 내어 비교한 뒤, 하나를 고른 이유를 말하고 나서 손을 움직이세요. 셋째, AI가 준 코드를 의심하는 연습입니다. 멘토링을 하다 보면, AI가 뽑아준 코드를 검증 없이 그대로 믿고 제출했다가 숨은 버그를 못 짚어 떨어지는 경우를 자주 봅니다. AI 허용 면접에서 감점되는 지점이 바로 여기입니다. 도구가 뱉은 결과를 읽고 반례를 던지고 근거를 대는 훈련이 이제 알고리즘 암기만큼 중요합니다.
마지막으로 실무적인 당부. 면접 전에 리크루터에게 AI 사용 정책을 반드시 확인하세요. 정책을 공개하지 않은 회사가 더 많고, 이 회색지대에서의 잘못된 가정이 합격을 날립니다.
결론
코딩 면접은 정답 코드를 채점하는 시험이 아닙니다. 문제 앞에서 여러분이 어떻게 사고하고, 그 사고를 어떻게 소리 내어 설명하는지를 보는 대화입니다. 폴리아의 말처럼 좋은 문제 해결은 실행보다 이해와 계획에서 갈리고, 베흐루지 연구가 보여줬듯 그 과정을 드러내는 형식은 실력과 담력을 함께 잽니다. 그리고 AI가 정답을 대신 써주는 지금, 면접은 코드를 만드는 능력에서 코드를 판단하는 능력으로 무게를 옮기고 있습니다.
그러니 문제를 더 많이 외우는 데 시간을 쓰기보다, 익숙한 문제 몇 개를 놓고 접근과 트레이드오프를 소리 내어 설명하는 연습, 그리고 AI가 준 코드를 의심하고 검증하는 연습을 하세요. 이건 시스템 디자인 면접이 완성된 다이어그램이 아니라 트레이드오프를 판단하는 과정을 보는 것과, PM 면접이 참신한 아이디어가 아니라 문제를 정의하는 방식을 채점하는 것과, 디자이너 면접이 예쁜 화면이 아니라 결정의 근거를 채점하는 것과, 마케터 면접이 좋은 성과 숫자가 아니라 그 성과를 만든 판단을 채점하는 것과 정확히 같은 원리입니다. 정답은 이제 AI도 압니다. 면접이 확인하려는 건 여러분이 그 정답을 어떻게 다루는 사람인가입니다.
참고 자료
- George Pólya, 『How to Solve It』 (1945) — 문제 해결의 4단계(이해·계획·실행·검토) 휴리스틱
- Mahnaz Behroozi, Shivani Shirolkar, Titus Barik & Chris Parnin, “Does Stress Impact Technical Interview Performance?” ESEC/FSE (2020) — 면접관 입회 조건에서 문제 해결 성능 약 50% 하락, 스트레스·인지 부하 증가
- John Sweller, “Cognitive Load During Problem Solving: Effects on Learning,” Cognitive Science (1988) — 작업 기억 한계와 외재적 인지 부하
- Tech Interview Handbook, “Coding interview rubrics” — 커뮤니케이션·문제 해결·기술 역량·테스트의 4축 평가 기준
- Exponent · IEEE-USA InSight, “AI-assisted coding interviews / How AI is reshaping technical interviews” (2026) — 구글의 코드 이해 라운드, AI 유창성(프롬프트·출력 검증·디버깅) 평가
- 기업별 AI 면접 정책 보도 (2026) — 아마존·골드만삭스의 금지, 메타·쇼피파이·캔바의 허용·기대
