AI 네이티브 채용 시리즈 3부작 중 Part 3입니다. Part 1: 철학, 루브릭, 3-Tier 평가 모델 · Part 2: The Machine — AI가 AI 활용 코드를 평가하다
Part 2의 머신이 400여 명을 분류하고, 각자에게 맞춤 면접 가이드까지 준비해뒀습니다. 이제 그 가이드를 손에 쥔 20명 이상의 면접관이, 5일 동안 100명 넘는 후보자와 마주 앉습니다.
그 자리에 앉기 전까지는 보이지 않았습니다. 점수가 무엇을 말해주지 못하는지. 이 글은 점수 너머에서 사람이 확인한 것, 우리가 놓친 것, 그리고 앞으로 남는 질문에 대한 이야기입니다.
점수가 구분하지 못하는 것
결과가 말해주는 것, 말해주지 않는 것
Part 1에서 Duck Typing을 빌려 이야기했습니다. 동작하는 시스템처럼 응답하면, 동작하는 시스템으로 인정한다. Functional Gate는 이 원리로 채점합니다. 어떻게 거기 도달했는지는 묻지 않습니다.
이 접근은 기능 검증에서는 합리적입니다. 수강신청 API가 올바른 응답을 돌려주면, 내부 구현이 pessimistic lock이든 optimistic lock이든 상관없습니다. 결과가 정확하면 됩니다.
문제는 코드 뒤에 누구의 사고가 있는지를, 코드만 보고는 알 수 없다는 것입니다.
3시간짜리 과제에서 분산 트레이싱, DDD 패턴, 멀티레이어 캐싱까지 구현한 제출물이 들어옵니다. 한 명이 아닙니다. AI 코딩 에이전트의 구현 파워가 이 수준입니다. 그래서 어려워집니다. 코드를 그 사람이 이해하고 만든 것인가, AI가 만든 것을 제출한 것인가.
Quality Gate가 프롬프트와 에이전트 지침을 평가하고, 코드 증거를 요구하는 이유가 여기 있습니다. 하지만 Depth 점수도 결국은 코드와 문서에서 사고의 흔적을 추론하는 것입니다. 사고 자체를 직접 확인하는 것은 아닙니다.
한 번의 결과로 알 수 없는 것
또 하나의 문제가 있습니다. 재현성입니다. 역량이 있는 후보자라면 AI 에이전트를 활용해 일관된 결과물을 반복해서 만들어낼 수 있을 것입니다. 하지만 우리가 본 것은 한 번의 제출물입니다. 한 번의 결과가 역량을 반영하는 것인지, AI가 우연히 잘 만들어준 것인지 — 결국 같은 문제의 다른 면입니다.
Part 2에서 소개한 Hustler가 이 문제를 가장 선명하게 보여줍니다. 기능은 완벽한데 Depth가 낮은 사람. 실행에 집중하며 깊이 사고한 결과일 수도 있고, AI가 만든 코드가 운 좋게 잘 돌아간 것일 수도 있습니다. 점수만으로는 모릅니다.
점수가 확인하지 못한 것을, 면접에서 확인해야 합니다. 점수는 필터로는 작동했습니다. 하지만 사람의 사고와 머신의 산출물을 분리하려면, 결국 사람의 눈이 필요했습니다.
머신이 준비한 대본
코드 증거 기반 면접 질문
머신의 마지막 산출물은 면접 가이드입니다. AI가 후보자의 코드를 분석하고, 그 코드에서 출발하는 맞춤 질문을 만들어냅니다.
예를 들어, 이런 질문이 생성됩니다:
질문: 이중 락 전략
코드 증거:
EnrollmentService.java:30-59— 두 개의ReentrantLock인스턴스로 동시 수강신청을 직렬화.private final Map<Long, ReentrantLock> courseLocks = new ConcurrentHashMap<>(); private final Map<Long, ReentrantLock> studentLocks = new ConcurrentHashMap<>();“두 개의 별도 락 맵을 사용하고 계시네요. 사고 과정을 설명해주세요 — 왜 락을 하나가 아니라 둘로 나누셨나요? 두 학생이 서로의 강좌에 동시에 등록하려 하면 어떤 일이 생기나요?”
질문 뒤에는 기대 답변 수준이 따라붙습니다. 5점이면 강좌 레벨 락과 학생 레벨 락의 역할 분리를 설명하고 데드락 방지 전략까지 기술하는 것. 3점이면 두 락의 범위는 이해하지만 데드락 순서는 고려 못하는 것. 1점이면 코드가 하는 일은 설명하지만 왜 두 개인지 설명 못하는 것.
후속 질문도 준비됩니다. “이 서비스를 여러 서버 인스턴스에 배포한다면, 이 락 전략이 여전히 동작할까요?” 약점을 직접 지적하지 않습니다. 후보자가 스스로 발견하도록 유도합니다.
점수 프로필이 면접 전략을 바꾼다
모든 후보자에게 같은 질문을 하지 않습니다. Base(기능)와 Depth(사고)의 조합에 따라 면접의 방향이 달라집니다.
Ace/Craftsman (높은 Base + 높은 Depth). 아키텍처의 한계를 밀어봅니다.
“advisory lock을 학생 ID로 걸고, 바로 아래에서 Course에 FOR UPDATE를 걸었는데요. 이 두 개의 잠금이 각각 어떤 시나리오를 방어하는 건지, 하나만 쓰면 안 되는 이유가 뭔가요?”
이 사람들은 자기 코드의 한계를 알고 있습니다. “이 서비스를 여러 서버 인스턴스에 배포한다면?“으로 경계를 밀어보는 것이 면접의 목적입니다.
Hustler (높은 Base + 낮은 Depth). 문서에 적힌 것과 코드가 일치하는지, 선택의 이유를 설명할 수 있는지를 검증합니다.
“수강신청에서 6단계 검증을 이 순서로 배치하셨는데, 시간표 충돌 체크를 마지막에 놓은 이유가 뭔가요? 충돌이 정원 확인보다 빈번하다면 순서를 바꾸는 게 더 효율적일까요?”
기능은 완벽하지만 자기 코드의 설계 결정을 설명하지 못한다면, AI 과의존 신호입니다.
Thinker (낮은 Base + 높은 Depth). 빌드에 실패했지만 사고력이 높은 사람.
“본인의 테스트에서는 통과했는데, 실제 환경에서는 정원 초과가 발생했습니다. 테스트 환경과 실제 환경에서 이런 차이가 발생할 수 있는 원인이 뭘까요?”
자기 실패를 진단할 수 있는가? 힌트를 주면 얼마나 빨리 복구하는가? 실행의 부족이 이해의 부족은 아닌지를 확인합니다.
면접 현장
100명 이상, 60분
3차 오프라인 면접에 100명 이상이 올라왔습니다. 5일간 20명 이상의 면접관이 각 60분(기술을 보는 30분 + 사람을 보는 30분)을 진행했습니다.
면접관의 손에는 AI가 만든 가이드가 있습니다. 후보자의 실제 코드에서 뽑아낸 질문, 기대 답변 수준, 후속 질문, 점수별 판단 기준. 면접관은 범용 기술 질문을 준비할 필요가 없습니다. 그 사람의 코드를 놓고 바로 대화를 시작할 수 있습니다.
예상과 다른 패턴
면접을 마치고 결과를 모았을 때, 예상과 다른 패턴이 나타났습니다.
Functional Gate에서 높은 점수를 받은 사람 — 서비스가 실제로 동작하고, TC를 통과하고, 동시성을 처리한 사람 — 중에 면접에서 예상 이상으로 깊은 이해를 보여주는 경우가 있었습니다. Quality Gate 점수가 높지 않았는데도.
물론 전체적으로 보면 Quality Gate 점수가 면접 성과와 더 관련이 있었습니다. 하지만 흥미로운 것은 개별 사례였습니다. 기능 구현에 집중한 사람이 그 과정에서 깊이 이해하게 된 경우. “이 API가 동시 요청 100개를 정확히 처리해야 한다"는 목표가 명확하면, 그 목표를 달성하는 과정 자체가 이해를 강제하는 것처럼 보였습니다.
반면 품질 메트릭은 — 코드 구조, 문서화, 추가 구현 — AI가 잘 만들어준 결과를 후보자가 얕게 이해한 채 제출했을 가능성을 배제하기 어렵습니다.
Hustler에서 이 패턴이 가장 극적으로 드러났습니다. Part 2에서 이야기한 그 랭크 — 기능은 완벽한데 Depth가 낮은 사람들.
Depth 120점 만점에 64점을 받은 후보자가 있었습니다. 문서화가 부족해서 AI 채점은 낮았습니다. 그런데 면접에서 동시성 제어 방식을 설명하기 시작하자 흐름이 달라졌습니다. 단일 락의 한계를 직접 짚었고, 힌트를 따라 샤딩 환경까지 확장했습니다. 파티션을 나누면 락은 분산되지만, 다른 버킷에 할당된 사용자 간에 형평성이 무너진다는 점까지 언급했습니다. 면접관의 평가: “경력자 인터뷰에서도 보기 쉽지 않은 수준의 사고.” 사고력만 놓고 보면, Ace를 넘었습니다.
반면 같은 Hustler 중에는 자기 코드의 동작 원리를 설명하지 못하는 사람도 있었습니다. 머신이 같은 패턴으로 분류한 사람들이, 면접에서 극단적으로 갈라졌습니다.
반대 방향의 사례도 있었습니다. 인증 체계를 엄격하게 구현해서 동시 접근 자체를 제한한 후보자가 있었습니다. Quality Gate 점수는 높은데 Functional Gate 점수가 매우 낮았습니다. 두 점수의 격차가 크면 이상 시그널로 잡히고, 사람이 직접 들여다보게 됩니다.
코드를 자세히 살펴보니, 설계 자체는 탄탄했지만 테스트 케이스가 전제하는 접근 흐름과 맞지 않았습니다. 400여 명의 다양한 구현에서 생기는 엣지 케이스였습니다. 모든 엣지 케이스를 커버하도록 테스트를 복잡하게 만들 수는 없었기에, 코드의 로직 흐름을 수동으로 확인하고 면접을 진행했습니다. 면접 결과는 매우 높았습니다.
순수한 Thinker — 빌드 자체가 실패한 경우 — 는 사실 많지 않았습니다. 대부분의 후보자가 잘 만들어왔기 때문입니다. 하지만 이처럼 시스템이 예상하지 못한 패턴을 사람이 발견하고 구제한 사례는, 머신만으로 채용을 끝낼 수 없는 이유를 보여줍니다.
이 사고가 코드가 아니라 문서에 남아 있었다면 어땠을까요. “왜 이 설계를 선택했는지, 어떤 트레이드오프를 고려했는지를 명시적으로 기술하라"고 요구하고, 그것을 평가의 중심에 놓았다면. 후보자도 무엇이 중요한지 알고, 평가자도 무엇을 볼지 알게 됩니다. 이 부분은 뒤에서 다시 이야기합니다.
점수와 면접장 사이의 간격, 진짜 질문은 거기 있었습니다.
같은 도구, 다른 대화
가이드가 면접관에게 좋은 도구였느냐고 물으면, 대부분 그렇다고 답했습니다. 후보자의 코드를 몇 시간씩 읽지 않아도 핵심 질문을 할 수 있었으니까.
하지만 면접을 반복하면서 묘한 회의가 생겼습니다.
면접관이 가이드를 따라 질문하고, 기대 답변 수준에 맞춰 점수를 매기는 모습. 이것이 Part 2에서 Hustler를 의심한 이유와 닮아 있지 않은가? AI가 만든 코드를 이해 없이 제출한 후보자를 걸러내려 했는데, 면접관도 AI가 만든 가이드를 따르고 있습니다. 도구를 따라가는 것과 스스로 판단하는 것, 그 경계는 어디인가? 이 대칭이 불편한 질문을 던집니다.
물론 면접관은 경험 있는 엔지니어입니다. 가이드는 출발점이지 도착점이 아닙니다. 실제로 가이드를 발판 삼아 더 나아간 사례가 있었습니다. 가이드에 없는 방향으로 대화를 이끌어가며 후보자의 사고를 더 깊이 확인한 면접관들. 도구가 같아도 도구를 활용하는 깊이는 달랐습니다. 후보자든 면접관이든, 결국 같은 이야기입니다. 도구가 강력해질수록, 도구를 쓰는 사람의 판단이 결과를 가릅니다.
사람도 캘리브레이션이 필요하다
Part 2에서 머신의 채점을 캘리브레이션했습니다. 사람도 마찬가지였습니다.
스코어카드는 Git으로 관리했습니다. 명확한 채점 기준을 배포했지만, 점수와 코멘트의 온도차가 생겼습니다. 높은 점수를 주면서 코멘트는 미지근한 면접관, 낮은 점수를 주면서 코멘트에서는 후보자를 칭찬하는 면접관. 면접관마다 관대함의 기준이 달랐습니다.
한 면접관에게 한두 건만 배정하면 편향을 잡을 수 없습니다. 1인당 4-5건 이상을 배정해서 패턴이 보이게 했습니다. 그 위에 캘리브레이션 단계를 추가했습니다. 점수와 코멘트의 온도를 비교하고, 면접관별 편향을 확인하고, 보정합니다. (참고로 이 글을 쓰고 있는 저도 관대함 편향을 지적받았습니다.)
사람을 보는 30분
면접은 기술을 보는 30분과 사람을 보는 30분으로 나뉘었습니다. 기술 쪽은 앞에서 이야기한 내용입니다. 사람을 보는 30분은 다른 질문을 던졌습니다.
많은 후보자가 신입이었습니다. 경험에 비추어 리더십을 평가할 수는 없었습니다. 대신 신입에게 가장 중요한 역량 — 학습과 적응 — 에 집중했습니다. 시험을 준비하면서 모르는 문제를 어떻게 풀어갔는지, 시험을 마친 뒤 무엇을 더 공부했는지. 경험이 아니라 학습의 태도를 봤습니다.
협업도 물었습니다. 다만 사람과의 협업 사례가 많지 않은 신입에게, AI와의 협업이 좋은 관찰 지점이었습니다. AI가 제안한 방향을 그대로 따랐는지, 비판적으로 검토했는지. AI의 주장에 반문하고, 틀렸을 때 자기 판단으로 방향을 바꾼 경험이 있는지. 사람과의 협업에서 중요한 덕목 — 비판적 수용, 자기 판단, 건설적 반론 — 이 AI와의 협업에서도 그대로 드러났습니다.
흥미로운 것은, Part 1에서 이야기한 오픈소스 원칙이 여기서 다시 나타났다는 점입니다. 코드를 읽을 사람을 생각하며 문서를 쓴 후보자, 테스트 가능성을 고려해서 코드를 구조화한 후보자 — 이런 사람들이 사람을 보는 30분에서도 높은 점수를 보여줬습니다. 다른 사람의 관점을 고려하는 습관은 코드에서도, 대화에서도 드러납니다.
대화를 평가하고, 설계를 놓치다
면접을 마치고 돌아보니 아이러니가 있었습니다.
평가 파이프라인을 만들 때, 우리는 코드가 아니라 지침을 고쳤습니다. Part 2에서 이야기한 하네스 엔지니어링을 이미 하고 있었습니다. 정작 후보자를 평가할 때는 프롬프트에 의존하고 있었습니다.
면접 결과가 이 차이를 드러냈습니다. 앞에서 이야기한 것처럼, 기능 점수는 스크리닝까지만 유효했고, 면접에서 깊이를 보여준 것과 상관이 있었던 것은 코드 품질과 설계 사고 쪽이었습니다.
코드는 의도의 그림자입니다. 왜 만드는지, 어떤 아키텍처를 왜 선택했는지, 어떤 트레이드오프를 고려했는지 — 이런 문맥은 코드만 봐서는 알기 어렵습니다. 설계 문서에는 그 문맥이 남습니다.
최근 Context Engineering이라 불리는 접근입니다. AI에게 전달하는 문맥의 품질이 산출물의 품질을 결정합니다. 대화 중 휘발되는 프롬프트보다, 명시적으로 기술된 문맥이 더 일관된 결과를 만듭니다. 우리가 파이프라인을 만들면서 배운 것이기도 합니다.
설계 문서 자체는 요구했지만, 평가의 중심에 놓기는 어려웠습니다. 머신은 코드가 ‘어떻게’ 동작하는지는 읽어냈지만, ‘왜’ 이렇게 만들었는지는 결국 사람의 영역에 남았습니다. 머신의 한계가 여기서 드러났습니다. 사람의 의도와 머신의 산출물을 분리하는 문제는 여전히 남아 있지만, 설계 문서는 그 실마리가 될 수 있습니다.
우리가 파이프라인을 만들면서 자연스럽게 하고 있던 일을, 채용 평가에도 적용할 수 있었을 것입니다. 하네스 엔지니어링이라는 이름이 붙기 전부터 뛰어난 팀은 이미 하고 있는 일이니까요. 이번에는 더 잘할 수 있었습니다. 다음에는 반영할 예정입니다.
채용을 넘어서
여기까지가 이번 채용에서 배운 것입니다. 하지만 이 이야기는 채용에서 끝나지 않습니다. AI와 함께 일하는 모든 사람이 같은 질문 앞에 서 있습니다.
20년
네비게이션 안내를 받으며 운전한 지 거의 20년입니다.
처음에는 불안했습니다. 기계가 안내하는 길이 맞는 건지, 더 빠른 길을 놓치고 있는 건 아닌지. 내가 판단하지 않는다는 불편함이었습니다.
20년이 지나고 보니 명확해진 것이 있습니다. 길 안내는 사람이 집중해야 할 문제가 아니었습니다. 그 일에 사람의 주의를 쏟을 가치가 없었을 뿐입니다. 이제 와서 사람이 직접 경로를 짜야 한다고 주장하는 사람은 없습니다. 운전자 자체도 언젠가는 사라질 것입니다. 순수하게 재미로 운전하는 경우를 제외하면 말입니다.
하지만 경로를 짜던 사람은 어디로 갈지를 결정하는 사람이 됐고, 도착해서 무엇을 할지를 생각하는 사람이 됐습니다. 하나의 역할이 사라질 때마다 빈자리가 생기고, 그 자리에 다른 역할이 들어왔습니다. (낙관적인 전망이기는 합니다.)
전환의 과정에서 흥미로운 차이는 있었습니다. 공간 감각이 있는 운전자는 네비가 틀려도 판단할 수 있었습니다. 네비가 시키는 대로만 가는 사람은 교차로에서 당황했습니다. 하지만 이 차이도 시간이 지나면서 흐려졌습니다. 네비가 틀리는 일 자체가 줄어들었기 때문입니다.
면접에서 본 것도 비슷했습니다. AI가 만든 코드를 설명 못하는 사람과 구조를 이해하는 사람의 차이. 지금은 이 차이가 중요합니다. 하지만 길 안내가 그랬듯이, 언제까지 중요할지는 모릅니다.
자율주행
최신 자동차를 생각해 봅니다.
차선 유지 보조. 자동 긴급 제동. 자동 주차. 네비게이션이 “어디로 갈지"를 안내했다면, 센서는 “어떻게 갈지"까지 실행합니다. 계획의 영역에 있던 자동화가 실행의 영역까지 들어왔습니다.
AI 에이전트도 같은 방향입니다. 처음에는 코드 자동완성이었습니다. 다음 줄을 제안하는 수준. 지금은 “수강신청 시스템을 만들어줘"라고 하면 프로젝트 구조부터 테스트까지 만들어냅니다. 3시간에 분산 트레이싱과 DDD가 나오는 시대입니다.
운전도 같은 길을 갈 것입니다. 자율주행이 충분히 성숙하면, 미래의 누군가는 물을 수 있습니다. 그 위험한 걸 왜 사람이 직접 했지? 기계가 더 잘해서가 아니라, 그 일 자체가 사람의 문제가 아니게 됩니다. 길 안내가 그랬듯이.
이번 채용에서 본 것도 이미 이 방향이었습니다. 면접 가이드를 AI가 만들고, 채점도 AI가 하고, 면접관은 사람만이 판단할 수 있는 것에 집중했습니다. AI가 대체한 시간을 면접관은 후보자와의 대화에 썼습니다. 역할이 사라진 게 아니라, 더 중요한 곳으로 옮겨간 것입니다.
돌아보며
시리즈를 시작할 때의 질문: AI 시대에 개발자를 어떻게 평가하는가.
머신을 만들어 답하려 했습니다. 필터로는 작동했습니다. 하지만 사람의 사고와 머신의 산출물을 분리하는 것은 끝내 머신의 몫이 아니었습니다. 대화를 평가하면서 설계를 놓쳤다는 것도 알게 됐습니다. 코드는 의도의 그림자였고, 우리는 그림자를 채점하고 있었습니다.
같은 도구를 쓰고, 같은 시간을 받고, 같은 문제를 풀었는데 결과의 스펙트럼은 넓었습니다. 머신이 같은 패턴으로 분류한 사람들이 면접에서 극단적으로 갈라지는 것을 봤고, 같은 가이드를 받은 면접관이 전혀 다른 깊이의 대화를 이끌어내는 것도 봤습니다. 사람이 개입하는 지점에서, 머신이 보지 못한 것들이 드러났습니다.
지금 이 순간 이 차이는 중요합니다. 하지만 길 안내가 그랬듯이, 이 중요함이 얼마나 오래 갈지는 확신할 수 없습니다.
질문이 바뀌고 있습니다. “기계가 이것을 할 수 있는가"에서, “이것이 여전히 사람이 집중해야 할 문제인가"로.
Part 1에서 “정답에 도달한 사람이 아니라 질문을 이해한 사람을 찾고 있다"고 했습니다. 이번 채용을 거치며 그 문장에 한 가지를 더하게 됐습니다. 도구가 강력해질수록 도구를 쓰는 사람의 판단이 결과를 가릅니다. 적어도 지금은요.
이번에도 빈자리가 생기고 있습니다. 다만 아직은 거기에 무엇이 들어올지 모릅니다. 하지만 이번 채용을 통해 그 빈자리의 가장자리는 확인했습니다. 다음 여정은 거기서부터입니다.
긴 시리즈였습니다. 여기까지 함께해주셔서 감사합니다. AI 시대의 채용뿐 아니라, 그 빈자리가 있다는 것을 인지하고, 윤곽을 조금이라도 선명하게 하는 데 도움이 되었다면 좋겠습니다.
AI 네이티브 채용 시리즈 3부작. Part 1: The Philosophy | Part 2: The Machine | Part 3: The Human.