면접에서 AI를 사용했다는 이유로 탈락했습니다 — 그런데 면접관도 AI를 쓰고 있었습니다

AI 요약

저자는 화요일에 기술 역량은 강하지만 평가 과정에서 AI 도구에 의존한 점이 회사가 원하는 독립적인 문제 해결 능력을 보여주지 못했다는 불합격 통보를 받았다고 합니다. 문제는 같은 화상 통화에서 면접관 역시 AI가 만든 답변을 읽는 듯한 모습을 보였다는 점입니다. 저자는 이것이 단순한 위선보다 더 큰 문제라고 봅니다. 실제 규칙은 ‘AI를 사용하지 말라’가 아니라 ‘AI를 사용하는 모습을 들키지 말라’였다는 것입니다.

■ 면접에서 AI를 사용한 방식과 불합격 과정

면접 문제는 복잡한 입력을 파싱하고 변환한 뒤 구조화된 결과를 반환하는, 일반적인 중간 난도의 과제였습니다. 저자는 실제 업무에서 하던 방식대로 문제를 분해하고 핵심 로직은 직접 작성했으며, 반복적인 보일러플레이트는 AI 어시스턴트가 스캐폴딩하도록 했습니다. 또한 면접 중에 “이 부분은 어시스턴트가 스캐폴딩하도록 하고, 실제로 깨질 수 있는 부분에 집중하겠습니다”라고 사용 사실을 명시했습니다.

저자는 AI 사용을 숨기지 않은 것이 오히려 실수였다고 말합니다. 면접관이 시간 복잡도에 관한 후속 질문을 한 뒤, 잠시 시선을 움직이고 사람이 즉석에서 말하기에는 지나치게 매끄럽고 구조화된 답변을 내놓았다는 것입니다. 저자는 면접관의 화면을 직접 본 것은 아니므로 단정할 수 없다고 밝히지만, 2년 동안 매일 AI 도구를 사용해 온 경험을 바탕으로 생성된 답변을 읽는 사람의 모습을 알아봤다고 설명합니다. 자신은 AI를 사용했다는 이유로 감점됐지만, 면접관은 같은 도구를 사용하면서도 그 사실을 드러내지 않았다는 것이 저자의 주장입니다.

■ 코딩 평가가 측정해야 하는 능력

저자는 회사가 AI 없이 문제를 해결할 수 있는지를 확인하려 했지만, 그것은 더 이상 존재하지 않는 직무를 대상으로 한 시험이라고 주장합니다. 회사 구성원 누구도 AI 없이 제품을 출시하지 않을 것이며, 면접관조차 후속 질문에 답할 때 AI를 활용한 것처럼 보였기 때문입니다. 저자가 제안하는 평가는 반대 방식입니다. AI를 제공한 뒤, 지원자가 AI가 거짓말을 하거나 잘못된 코드를 제시하는 순간을 알아차리는지를 관찰해야 한다는 것입니다.

글에서는 코딩이라는 단어 안에 서로 다른 두 능력이 섞여 있다고 설명합니다. 첫째는 문법, API, 플래그 순서, 특정 명령어 사용법을 기억하는 ‘회상(recall)’입니다. 저자는 AI가 이 영역을 사실상 대체했으며, 이것을 평가하는 일은 2026년에도 글씨 쓰기 능력을 시험하는 것과 같다고 봅니다. 둘째는 무엇을 만들어야 하는지, 무엇을 의심해야 하는지, 실제 사용자가 새벽 2시에 예상 밖의 행동을 했을 때 무엇이 고장 나는지를 판단하는 ‘판단(judgment)’입니다. 이 능력은 AI가 대신 제공할 수 없고, AI가 만든 결과를 거부할 수 있을 때 비로소 드러난다고 설명합니다.

■ 100% AI 작성 실험과 오류를 잡아내는 경험

저자는 한 달 동안 AI가 코드의 100%를 작성하게 하고 자신은 애플리케이션 로직을 한 줄도 직접 입력하지 않는 실험을 했다고 말합니다. 그 결과 실제 제품을 출시할 수는 있었지만, 제품을 출시 가능하게 만든 것은 AI 자체가 아니었습니다. 매끄럽고 자신감 있으며 그럴듯한 코드 변경(diff)을 보고도 “아니요”라고 판단했던 순간들이 핵심이었다고 합니다.

저자는 같은 작업에서 보일러플레이트를 작성하기 전에 문제의 설계 자체에도 위험이 있다고 지적했다고 설명합니다. 쓰기 경로(write path)는 성공 응답을 반환하기 전에 데이터를 영속화해야 하며, 저장보다 먼저 확인 응답(acknowledgement)을 보내면 재시도 과정에서 같은 작업이 두 번 집계될 수 있다는 내용입니다. 그는 과거 30일 실험 중 실제로 확인 응답을 먼저 보내고 저장하지 않아, 장애가 발생한 날 결제 고객이 기록 없이 계정에 접근하지 못하는 문제가 생겼다고 회고합니다. 이러한 장애 모드와 시스템의 결과를 예상하는 능력은 AI가 제공한 것이 아니라, 수년간 실제 작업을 하며 얻은 경험이라고 강조합니다. 그러나 면접에서는 이 판단력 대신 자동완성 사용 여부가 기록됐다고 말합니다.

■ 저자가 제시한 AI 에이전트의 통제 구조

글의 후반부에서 저자는 이 경험을 AI 에이전트 설계 원칙으로 연결합니다. 코드를 작성하는 주체가 그 코드의 품질까지 승인하게 해서는 안 된다는 것입니다. 저자가 설명하는 구조에서는 하나의 작성자 에이전트(author agent)가 변경 사항(diff)을 만들고, 별도의 회의적 검토자 에이전트(skeptic agent)가 결과를 칭찬하는 대신 반박하는 역할을 맡습니다. 마지막 병합 버튼(merge button)은 사람이 누르며, 모델이 볼 수 없는 변경의 영향 범위와 시스템상의 파급 효과를 사람이 확인하도록 합니다.

저자는 이 구조를 자신들이 만드는 에이전트 플랫폼인 xenition의 형태라고 설명합니다. AI의 역할을 숨기거나 기본적으로 신뢰하는 대신, AI가 어디에 관여했는지를 명시하고 사람이 그 결과를 판단할 수 있게 해야 한다는 원칙입니다. 따라서 이 글의 결론은 면접에서 AI를 쓰지 않는 사람이 더 뛰어나다는 것이 아닙니다. AI를 사용하더라도 그 결과를 검증하고, 필요할 때 거부하며, 사용 사실을 숨기지 않을 수 있는지가 실제 채용에서 평가해야 할 능력이라는 주장입니다.

원문: dev.to / 번역·요약: Trawling