첫 번째 토큰이 나오기 전에 — 프롬프트 연극이 아닌 사전 등록으로서의 AI 코딩 인터뷰

코딩 인터뷰는 언제나 양심의 가책을 느끼는 타협점이었습니다.

코딩 인터뷰는 '이 사람이 실제로 업무를 수행할 수 있는가?'라는 진지한 질문에 답하기 위해, 실제 업무와 부분적으로만 닮은 퍼포먼스를 연출함으로써 답을 찾으려 노력합니다. 지원자는 면접관 앞에 앉아 작은 문제를 전달받고, 생각을 소리 내어 말하라는 요구를 받으며, 소프트웨어 엔지니어링을 실질적으로 만드는 거의 모든 요소가 제거된 환경에서 코드를 생성해야 합니다. 즉, 기존 코드베이스 (codebase), 테스트 (tests), 팀의 컨벤션 (conventions), 빌드 시스템 (build system), 오래된 문서 (documentation), 제품의 경계 (product boundary), 숨겨진 불변량 (hidden invariant), 그리고 왜 차이점 (diff)이 이렇게 큰지 물어볼 리뷰어 (reviewer) 같은 요소들이 모두 배제된 상태입니다.

업계는 이 사실을 알고 있습니다. LeetCode, 화이트보드, 불안감, 암기된 패턴, 그리고 관찰당하는 동안 생각을 말로 설명해야 하는 기묘한 연극에 대해 불평합니다. 그러면서도 이 의식을 계속 유지하는데, 그 이유는 이 의식에 방어 가능한 속성이 하나 있기 때문입니다. 바로 신호 (signal)를 만들어낸다는 점입니다. 항상 공정한 신호는 아닐지라도, 항상 올바른 신호도 아닐지라도, 어쨌든 어떤 신호는 만들어냅니다. 명확하게 추론하고, 코드를 작성하며, 압박감 속에서도 회복할 수 있는 사람은 아마도 기술적 능력을 갖추었을 것입니다. 그렇지 못한 사람도 여전히 유능할 수 있지만, 인터뷰에는 이를 확인할 깔끔한 방법이 없습니다.

인공지능 (Artificial intelligence)은 이 문제를 제거하지 않습니다. 오히려 더 날카롭게 만듭니다.

소프트웨어 개발이 점점 더 AI의 도움을 받아 이루어진다면, AI를 금지하는 인터뷰는 이미 노후화되어 가는 직무 버전에 대한 순수성 테스트 (purity test)처럼 보이기 시작할 것입니다. 동시에, 단순히 AI를 허용하는 인터뷰는 과거의 의식보다 더 나빠질 수 있습니다. 모델의 역량을 지원자의 역량과 혼동할 수 있기 때문입니다. 도구에 대한 접근 권한, 개인적인 프롬프트 라이브러리 (prompt libraries), 숨겨진 도움, 또는 좋은 완성 (completion)을 얻는 운에 보상을 줄 수도 있습니다. 이는 LeetCode 연극을 프롬프트 연극 (prompt theater)으로 대체할 뿐일지도 모릅니다.

따라서 중요한 질문은 지원자가 코딩 인터뷰에서 AI를 사용해야 하는가 하는 문제가 아닙니다.

중요한 질문은 AI가 허용되었을 때 인터뷰가 무엇을 가시화해야 하는가 하는 점입니다.

그 답은 AI보다 더 오래된 것입니다.

훌륭한 엔지니어는 언제나 낯선 시스템에 진입하여 무엇이 중요한지를 결정해야 했습니다. 그들은 항상 관련 파일을 찾아내고, 숨겨진 계약 (hidden contract)을 보존하며, 의미 있는 테스트 표면 (test surface)을 식별하고, 불필요한 폭발 반경 (blast radius)을 피하며, 왜 국소적인 변경 (local change)이 영웅적인 재작성 (heroic rewrite)보다 안전한지를 설명해야 했습니다. 그들은 항상 무엇을 건드리지 말아야 하는지를 알아야 했습니다. 그들은 항상 모호함을 제한된 작업 (bounded work)으로 전환해야 했습니다.

AI는 그러한 판단력을 만들어내지 않습니다.

AI는 그 판단력을 사전 등록 (preregister)할 기회를 만듭니다.

그것이 미래의 코딩 인터뷰가 지향해야 할 더 강력한 버전입니다. 지원자에게 저장소 (repository), 현실적인 과제, 결함이 있을 수 있는 코딩 에이전트 (coding agent), 그리고 제한된 환경을 제공하십시오. 지원자가 모델에게 무엇인가를 요청하기 전에, 짧은 '에이전트 이전 기록 (pre-agent record)'을 요구하십시오. 즉, 그들이 이해한 과제가 무엇인지, 어떤 파일이 중요할 것으로 보이는지, 어떤 불변량 (invariants)이 유지되어야 하는지, 에이전트가 무엇을 건드릴 수 있고 무엇을 피해야 하는지, 어떤 테스트가 증거로서 유효할지, 그리고 무엇이 "완료"를 의미하는지를 기록하게 하는 것입니다.

그 기록의 가치는 지원자의 판단력을 완벽하게 포착한다는 데 있지 않습니다. 완벽할 수는 없습니다. 그 가치는 증거가 도착하기 전에 기록된다는 데 있습니다.

그것이 핵심입니다.

과학에서 사전 등록 (preregistration)이 중요한 이유는 첫 번째 가설이 항상 옳기 때문이 아닙니다. 연구자가 결과를 보기 전에 스스로를 구속하기 때문입니다. 연구자는 결과가 어떻게 나오든 간에, 마치 그것을 예측했던 사람인 것처럼 조용히 변신할 수 없습니다. 여기에도 동일한 논리가 적용됩니다. 에이전트가 패치 (patch)를 내놓기 전에, 테스트가 통과하거나 실패하기 전에, 지원자가 기계가 무엇을 쉽게 만들고 무엇을 어렵게 만드는지 확인하기 전에, 지원자는 작업에 대한 자신의 이론을 적어야 합니다.

그렇게 함으로써 인터뷰는 기존 형식이 거의 갖지 못했던 것, 즉 '사전 약속의 기록 (record of prior commitment)'을 갖게 됩니다.

지원자의 설계도(map)가 올바른 서브시스템(subsystem)을 찾아냈는가? 그들은 올바른 불변성(invariant)을 보호했는가? 그들이 정의한 완료 기준(definition of done)이 패치(patch)와 맞닥뜨린 후에도 유지되었는가? 코드가 자신의 이론과 모순될 때 정직하게 이론을 수정했는가? 자신이 명시한 제약 조건(constraints)을 위반하는 모델의 제안에 맞서 원칙을 고수했는가? 아니면 에이전트(agent)가 그럴듯한 결과물을 만들어낸 뒤에야 그에 맞춰 이야기를 사후에 끼워 맞추었는가?

그것이 바로 신호(signal)입니다. 결과물(artifact) 자체는 신호가 아닙니다. 방어(defense) 자체도 신호가 아닙니다. 신호는 전체적인 도구(instrument)입니다. 즉, 사전 약속(pre-commitment), AI 보조 시도(AI-assisted attempt), 테스트와 리뷰를 통해 확립된 작업의 실체(task reality), 그리고 그 사이의 간극에 대한 방어(defense)가 결합된 전체 과정이 신호입니다.

과거의 화이트보드 인터뷰는 잘못된 15분을 측정했습니다. 바로 키스트로크(keystrokes), 구문(syntax), 그리고 공개적인 퍼포먼스였습니다. AI 시대의 더 나은 인터뷰는 그보다 앞선 결정 사항을 측정합니다. 즉, 구현이 시작되기 전 지원자가 어떻게 작업 범위를 설정(scope)하는지, 그리고 현실적인 문제에 부딪혔을 때 그 범위를 얼마나 정직하게 수정하는지를 측정하는 것입니다.

미래의 코딩 인터뷰는 첫 번째 토큰이 나오기 전에 시작되어야 합니다.

이것은 예측이지, 승전보가 아닙니다

AI 보조 개발(AI-assisted development)은 이미 채용 과정에서 무시할 수 없을 만큼 보편화되었습니다. Stack Overflow의 2025년 개발자 설문조사(Developer Survey)에 따르면, 전문 개발자의 51%가 매일 AI 도구를 사용한다고 보고했습니다. 동일한 설문조사에서 개발자의 66%는 "거의 맞지만 틀린" AI 솔루션에 좌절감을 느낀다고 답했으며, 45%는 AI가 생성한 코드를 디버깅(debugging)하는 것이 더 많은 시간이 소요된다고 말했고, 46%는 AI 도구의 정확성을 적극적으로 불신한다고 답했습니다. 채용 시장이 진입하고 있는 세상은 바로 이렇습니다. 높은 사용률, 낮은 신뢰도, 그리고 인간의 검증(human verification)에 대한 필요성 증대입니다.

기업들도 적응하기 시작하고 있습니다. Canva는 2025년 6월, 백엔드(backend), 머신러닝(machine-learning), 프론트엔드(frontend) 엔지니어링 지원자들이 기술 면접 중에 Copilot, Cursor, Claude와 같은 도구들을 사용할 것으로 예상된다고 발표했습니다. Canva의 논리는 명확합니다. 자사의 엔지니어들이 일상 업무에서 AI를 사용하고 있으므로, 이러한 도구들을 금지하는 면접은 지원자가 실제 직무에서 어떻게 수행할지를 제대로 평가하지 못한다는 것입니다. Canva만이 아닙니다. Google은 지원자가 AI 어시스턴트와 함께 기존 코드베이스(codebase)를 읽고, 디버깅(debug)하며, 최적화(optimize)하는 "코드 이해(code comprehension)" 단계를 시범 운영하고 있다는 보고가 있었으며, Meta는 AI 보조 면접을 부분적으로 검증(verification) 측면에서 평가하고 있다고 알려졌습니다. 이는 이 에세이에서 핵심으로 다루는 바로 그 축입니다. 이러한 움직임들은 보고된 내용일 뿐 공식적인 원칙(doctrine)으로 발표된 것은 아니기에, 방법론에 대한 증거라기보다는 방향성을 보여주는 증거입니다.

그 방향성이 AI 보조 면접이 유효하다는 것을 증명하는 것은 아닙니다.

심지어 AI 도구가 현재 성숙한 저장소(repositories)에서의 시니어 엔지니어링 업무를 개선한다는 사실조차 증명하지 못합니다. METR의 2025년 7월 무작위 대조 시험(randomized controlled trial)에 따르면, 자신의 저장소에서 작업하는 숙련된 오픈 소스(open-source) 개발자들이 2025년 초 버전의 AI 도구를 사용했을 때 시간이 19% 더 오래 걸린 것으로 나타났습니다. METR는 이 결과를 보편적인 법칙이라기보다 하나의 관련 있는 설정에 대한 스냅샷으로 규정했습니다.

그 발견이 이 논증을 무너뜨리는 것은 아닙니다. 오히려 논증을 더 정직하게 만듭니다.

AI를 인지하는 면접(AI-aware interviews)을 옹호하는 근거는 AI가 모든 저장소에서 이미 명백한 생산성 승리라는 점이 아닙니다. 핵심은 소프트웨어 작업이 인간과 기계의 협업(human-machine collaboration)을 향해 나아가고 있으며, 그 협업에서 가장 중요한 인간의 기술은 도구에 대한 판단력(judgment)이라는 점입니다.

따라서 이 에세이는 "AI가 미래이므로 면접은 반드시 AI 유창성(AI fluency)을 테스트해야 한다"라는 것보다 더 좁은 범주의 주장을 하고 있습니다.

그 주장은 다음과 같습니다:

AI 코딩 에이전트(AI coding agents)가 일반적인 개발 도구가 됨에 따라, 면접은 생성된 코드를 지원자의 능력에 대한 증거로 취급하기보다는, 지속 가능한 엔지니어링 판단력 — 특히 범위 설정(scoping), 컨텍스트 선택(context selection), 검증(verification), 수정(revision), 그리고 리뷰(review) — 을 드러내기 위해 이들을 활용해야 한다.

그 주장은 부분적으로는 현재형이고, 부분적으로는 예측입니다. 현재형인 부분은 많은 개발자가 이미 매일 AI를 사용하고 있으며, 일부 기업은 이미 이를 중심으로 인터뷰를 설계하고 있다는 점입니다. 예측인 부분은 가장 지속 가능한 채용 신호(hiring signal)가 프롬프트 유창성(prompt fluency), 턴 예산 준수(turn-budget discipline), 또는 토큰 절약(token thrift)이 아니라는 점입니다. 그것은 바로 자동화를 제어(govern)하는 후보자의 능력일 것입니다.

현재의 에이전트 메커니즘은 부패할 것입니다. 프롬프트 구문(prompt syntax)은 변할 것입니다. 컨텍스트 윈도우(context windows)는 확장될 것입니다. 에이전트 인터페이스는 더욱 자율적으로 변할 것입니다. 턴 횟수(turn counts), 파일 제한, 승인 모드, 그리고 "최선의 프롬프트 작성 관행(best prompting practices)"은 빠르게 노후화될 수 있습니다.

지속 가능한 기술은 AI보다 오래되었습니다. 바로 시스템을 안전하게 변경할 수 있을 만큼 충분히 잘 이해하는 것입니다.

인터뷰는 그 점에 베팅해야 합니다.

에이전트 이전의 기록 (The Pre-Agent Record)

에이전트 이전의 작업 샘플(work sample)은 간단한 규칙에서 시작합니다. 후보자는 저장소(repository)를 수동으로 조사할 수 있지만, 짧은 설정 기록(setup record)을 생성하기 전까지는 AI 어시스턴트에게 동작을 요청할 수 없습니다.

그 기록에는 작업 요약(task summary), 컨텍스트 맵(context map), AGENTS.md 또는 그에 상응하는 에이전트 지침 파일(agent-instruction file), 검증 계획(verification plan), 리스크 노트(risk note), 그리고 완료 정의(definition of done)가 포함될 수 있습니다.

형식보다는 타이밍이 더 중요합니다. 모델이 코드를 생성하기 전에 후보자가 먼저 확정(commit)해야 합니다.

취약한 에이전트 이전 기록은 다음과 같이 말합니다: 클린 코드(clean code)를 사용하세요. 베스트 프랙티스(best practices)를 따르세요. 테스트를 추가하세요. 주의하세요.

그것은 판단(judgment)이 아닙니다. 그것은 엔지니어링 향수(engineering perfume)일 뿐입니다.

더 강력한 기록은 다음과 같이 말합니다:

영향 범위는 validator.ts, schema.ts, 그리고 validator.test.ts일 가능성이 높습니다. 실패하는 동작이 검증 레이어(validation layer)에서 재현되지 않는 한 라우터(router)는 범위 외(out of scope)입니다. 공개 에러 응답 형태(public error-response shape)를 보존하세요. 새로운 포매터(formatter)를 추가하기보다 formatValidationError를 재사용하세요. 누락된 중첩 배열 값에 대한 회귀 테스트(regression test)를 추가하세요. 의존성(dependencies)을 추가하지 마세요. 새로운 회귀 테스트와 기존 검증 스위트(validator suite)가 통과하면 변경이 완료된 것으로 간주합니다.

이것은 단순히 에이전트(agent)에게 내리는 지시가 아닙니다. 이것은 시스템에 대한 주장입니다. 지원자는 반증 가능한 약속을 하고 있는 것입니다: "제 생각에 문제가 있는 지점은 여기입니다. 제 생각에 경계선은 여기입니다. 제 생각에 불변량(invariant)은 이것입니다. 제 생각에 이 테스트가 변경 사항을 증명할 것입니다. 제 생각에 이 하위 시스템들은 건드리지 않은 채로 유지되어야 합니다."

그 후 에이전트의 출력은 하나의 증거 원천이 됩니다. 그것은 정답(ground truth)이 아닙니다. 그 차이는 매우 중요합니다. 만약 지원자가 라우터(router)는 범위 밖(out of scope)이라고 말했는데 에이전트가 라우터를 수정했다면, 에이전트의 행동이 지원자가 틀렸음을 자동으로 증명하는 것은 아닙니다. 모델이 과잉 행동(overreach)했을 수 있기 때문입니다. 그러한 과잉 행동에 저항하는 것이야말로 인터뷰가 측정하고자 하는 바로 그 거버넌스(governance) 기술일 수 있습니다.

정답(ground truth)은 에이전트가 수행한 작업이 아닙니다. 정답은 테스트, 리뷰, 코드 소유권(code ownership), 그리고 명시된 제품 계약(product contract)을 통해 확립된, 해당 작업이 실제로 요구했던 사항입니다.

따라서 유용한 비교는 다음과 같은 삼각 비교입니다:

대상	드러내는 것
에이전트 이전 기록 (Pre-agent record)	자동화가 작동하기 전 지원자가 믿었던 것
...

그 삼각 간극(three-way gap) 속에 신호(signal)가 존재합니다.

만약 지원자가 라우터를 제외했고 작업에 실제로 라우터가 필요하지 않았다면, 에이전트의 라우터 수정을 거부하는 것은 거버넌스 측면에서의 승리입니다. 만약 지원자가 라우터를 제외했는데 버그가 실제로 그곳에 있었다면, 그것은 범위 설정의 실수(scope miss)입니다. 만약 지원자가 자신이 등록한 제약 조건을 위반하는 에이전트의 수정을 수용했다면, 그것은 규율의 실패(discipline failure)입니다. 만약 실패한 테스트가 실제 의존성(dependency)을 드러낸 후 지원자가 자신의 범위를 수정했다면, 그것은 변절이 아닙니다. 그것은 훌륭한 업데이트입니다.

이것이 바로 순서(sequencing)가 중요한 이유입니다.

실제 엔지니어링은 인터리브(interleaved, 교차)되어 있습니다. 엔지니어는 가설을 세우고, 조사하고, 수정하고, 테스트를 실행하고, 새로운 사실을 발견하고, 다시 수정합니다. 강제된 에이전트 이전 기록은 인위적입니다. 하지만 그 인위성은 '봉인된 봉투(sealed envelope)'를 만들어내기 때문에 그 가치를 인정받습니다. 봉투가 없다면, 지원자는 에이전트가 결국 발견하게 될 모든 것을 처음부터 알고 있었던 사람처럼 보일 수 있기 때문입니다.

에이전트 이전 단계(pre-agent phase)는 직무 전체를 시뮬레이션하는 것이 아닙니다. 그것은 측정 장치입니다. 지원자는 여전히 자신의 이론을 수정할 기회를 얻습니다. 사실, 수정 과정은 점수로 반영되어야 합니다. 하지만 면접관은 이제 전후 추적 데이터(before-and-after trace)를 갖게 됩니다. 즉, 자동화가 작동하기 전에 지원자가 무엇을 믿었는지, 코드가 무엇을 드러냈는지, 그리고 지원자가 그 간극을 어떻게 다루었는지를 알 수 있게 됩니다.

이는 누군가가 타이핑하는 것을 지켜보는 것보다 더 깔끔한 신호(signal)를 제공합니다.

침묵하는 전문가와 달변가 사기꾼

사전 등록(preregistration) 프레임워크는 한 가지 문제를 해결하는 동시에 또 다른 문제를 드러냅니다.

이 방식은 사후에 끼워 맞추기식으로 합리화하는 지원자를 잡아내는 데 도움이 됩니다. 일단 에이전트 이전의 기록이 존재하면, 지원자는 해당 서브시스템(subsystem)이 중요하다는 것을 항상 알고 있었다거나, 해당 불변량(invariant)을 보존할 의도가 항상 있었다거나, 혹은 그 테스트를 실행할 의도가 항상 있었다고 가장할 수 없습니다. 봉투는 에이전트가 작동하기 전에 이미 봉인되었습니다.

하지만 사전 등록이 '침묵하는 전문가(silent expert)' 문제를 해결하지는 못합니다.

어떤 뛰어난 엔지니어들은 암묵적 판단력(tacit judgment)을 지니고 있습니다. 그들은 감각적으로 범위를 올바르게 설정합니다. 깔끔하게 설명하기 전에도 위험을 감지합니다. 그들의 지식은 수년간의 코드 리뷰(code review), 마이그레이션(migrations), 장애(outages), 그리고 서서히 쌓인 경험의 흉터들로부터 컴파일(compiled)된 것입니다. 시간 압박 속에서 정제된 컨텍스트 맵(context map)을 작성하라고 요구한다면, 그 결과물은 불변량(invariants)과 폭발 반경(blast radius)에 관한 모든 에세이를 읽은 달변가 미드 레벨(mid-level) 엔지니어가 만들어낸 결과물보다 빈약해 보일 수 있습니다.

이것은 실제적인 약점입니다. 가독성 측정 장치(legibility device)가 가독성 결과물(legibility artifacts)을 만드는 데 능숙한 사람들에게만 보상을 준다면, 그것은 문해력 테스트(literacy test)로 변질될 수 있습니다.

이와 반대되는 실패 모드는 달변가 사기꾼(articulate fraud)입니다.