The Philosophy: AI 네이티브 채용

🇺🇸 Read in English

AI 네이티브 채용 시리즈 Part 1입니다. Part 2-1: “The Machine” | Part 2-2: “Under the Hood” | Part 3: “The Human” (준비 중)

2026년 1월, 무신사에서 AI 네이티브 엔지니어 채용을 진행했습니다. 수백 명의 지원자를 AI 파이프라인으로 처음부터 끝까지 자동 평가했습니다. 문제 설계, 평가 파이프라인, 그 바탕이 되는 철학까지 직접 만들었습니다. 이 시리즈는 그 과정에서 배운 이야기입니다.

“AI 네이티브"란 무엇인가?

모든 기술 시대에는 그 시대의 네이티브가 있습니다.

인터넷 시대는 “디지털 네이티브"를 만들었습니다. 구글 없는 세상을 모르는 세대. 스마트폰 시대는 “모바일 네이티브"를 만들었습니다. 클릭이 아니라 탭이 본능인 사람들. 이제 AI 시대가 만들어내는 세대가 있습니다: AI 네이티브.

이들은 AI의 등장과 함께한 사람들입니다. 대학 입학할 때 ChatGPT가 있었고, 첫 IDE에 Copilot이 깔려 있었고, 첫 프로덕션 버그를 Claude와 함께 잡았습니다. AI는 이들이 도입한 도구가 아니라, 이들에게는 당연한 환경입니다.

일본에서는 스마트폰 세대 신입사원에게 키보드 사용법을 가르치는 회사가 있다고 합니다. 대부분의 조직은 본능적으로 “교정"하려 합니다. 새 세대를 옛 방식으로 되돌리려 합니다. 스마트폰의 경우는 일리가 있습니다. 모바일이 데스크탑을 대체한 건 아니니까요. 하지만 AI는 다릅니다. 이전 도구를 대체하는 게 아니라 넘어서는 도구입니다. 교정이 아니라 이렇게 묻는 게 낫습니다: 우리가 못하는 것 중에 이들이 자연스럽게 잘하는 건 뭘까요?

AI도 마찬가지입니다. “지원자가 AI를 쓰지 못하게 하려면?“이 아니라, **“AI를 진짜 잘 쓰는 사람을 어떻게 찾을 것인가?”**를 물어야 합니다.

이 질문에서 모든 게 시작되었습니다.

얼어붙은 신입 채용

AI의 파도는 엔지니어의 업무 방식만 바꾼 게 아닙니다. 기업들이 신입을 바라보는 시선 자체를 흔들어 놓았습니다.

평가 방법만의 문제가 아닙니다. 더 근본적인 질문들이 있습니다. AI를 쓰는 팀에 엔지니어가 실제로 몇 명이나 필요할까요? AI가 직무를 재편하는 판에, 몇 년 키워야 하는 주니어를 뽑아야 할까요? 경력자만 뽑고 적응을 기대해야 할까요?

신입 채용 앞에서 기업들의 반응은 대충 세 가지로 갈립니다:

• 금지: “코딩 테스트 중 AI 도구 사용 금지.” (실제 도구 없이 코딩하게 하는 건 목수에게 전동 공구 빼고 일하라는 꼴입니다.)
• 무시: 똑같은 LeetCode 스타일 면접을 돌리면서 아무것도 안 변한 척. (지원자들은 에이전트로 60초 만에 알고리즘 문제를 풀고 있습니다. 당신이 못 볼 뿐입니다.)
• 동결: 신입 채용을 중단하고 “상황이 안정될 때까지” 기다리기. (빅테크의 신입 채용은 2022년 이후 절반 이상 줄었습니다. 국내 IT 업계의 신입 공채 공고는 전년 대비 67% 감소했습니다.)

동결이 가장 눈에 띄는 반응이고, 가장 해로운 반응입니다. 평가가 어려워서가 아닙니다. AI가 주니어 업무 상당 부분을 해치울 수 있는 시대에, 신입의 자리가 뭔지 아무도 모르기 때문입니다. 불확실하니까 안 뽑는 겁니다. 그 사이에 한 세대의 신입 엔지니어들이 어느 때보다 좁아진 문 앞에 서 있습니다.

먼저 움직이기로 했다

무신사는 다른 선택을 했습니다.

이 혼란의 시대에 관망하지 않기로 했습니다. “AI 네이티브 엔지니어"가 뭔지 우리가 직접 정의하면 어떨까? 거기에 맞는 이론을 세우고, 테스트를 만들고, 평가 파이프라인까지 구축하면? 일회성 실험이 아니라 미래를 향한 의도적인 베팅으로.

무모함이 아닙니다. 나름의 계산이 있습니다. AI 네이티브 채용을 먼저 해결하는 기업이 이 세대 최고의 인재를 끌어올 것입니다. 나머지는 뒤따라갈 수밖에 없습니다.

Andrew Ng은 이렇게 말한 적이 있습니다. “회사 문을 열고 들어갈 때 느끼는 로고의 설렘에서 배우는 게 아닙니다. 매일 함께 부대끼며 일하는 사람들에게서 배웁니다.” 우리가 진짜 신경 쓰는 건 그겁니다. 브랜드 후광도, 헤드카운트도 아닙니다. 서로에게서 배우고 함께 성장할 수 있는 사람들을 모으는 것. “좋은 동료"의 기준 자체가 바뀌고 있는 지금이니까요.

최전선에 서서 직접 길을 만들기로 했습니다. 업계가 정답을 찾아줄 때까지 기다리지 않았습니다. 우리만의 기준을 만들었습니다.

먼저 버린 건 기존 코딩 테스트였습니다. 새로운 시험을 설계하면서 네 가지 질문과 마주했습니다.

• 기존 테스트는 왜 안 되는가?
• 공정성은 어떻게 확보할 것인가?
• 문제의 모호함은 어디까지 허용할 것인가?
• 테스트 가능성과 모호함 사이의 균형은?

LeetCode는 죽었다

C나 C++로 짧은 알고리즘 문제? 오늘날 1분이면 끝납니다.

AI 에이전트는 전형적인 LeetCode medium을 몇 초 만에 풉니다. 많은 hard도 프롬프트 한 번이면 됩니다. 코딩 테스트가 측정하려던 것, 즉 문제를 동작하는 코드로 옮기는 능력이 하룻밤 사이에 범용화되었습니다.

코딩 테스트만의 이야기가 아닙니다. Andrew Ng이 스탠퍼드 CS 수업에서 이야기한 적이 있습니다. 만드는 일과 결정하는 일 사이의 무게중심이 극적으로 옮겨지고 있다고요:

과거에는 엔지니어 대 PM 비율이 7:1이나 8:1이었습니다. PM 한 명이 스펙을 쓰면 엔지니어 7~8명이 달라붙어 만들었습니다. AI가 구현을 극적으로 싸고 빠르게 만들면서 이 비율이 2:1, 심지어 1:1까지 무너지고 있습니다. 기획(사용자 이해, 요구사항 정의, 판단)은 같은 속도로 빨라지지 않았습니다. 병목이 이동한 겁니다. Ng은 더 나아갑니다: 역할의 경계가 사라지고 있다고 합니다. 지금 실리콘밸리에서 가장 빠르게 움직이는 사람들은 사용자와 직접 소통하고, 무엇을 만들지 결정하고, AI를 시켜 만드는 제품 감각 있는 엔지니어들입니다. 한 사람이 두 역할을 합니다.

구현이 싸다면, 비싼 건 뭘까요?

무엇을 구현할지 아는 것.

모호한 상황을 보고, 실제 요구사항을 도출하고, 불확실성 속에서 합리적인 결정을 내리고, AI를 올바른 방향으로 이끄는 능력. 이것이 지금 중요한 역량입니다. 기존 코딩 테스트는 이걸 전혀 측정하지 못합니다.

웹 샌드박스에 가두고 AI 없이 코딩하게 하는 건 완전히 잘못된 방향입니다. 엔지니어링 역량을 테스트하는 게 아닙니다. 2020년처럼 코딩할 수 있는지를 테스트하고 있는 겁니다. 필요한 역량이 바뀌었습니다. 테스트도 바뀌어야 합니다.

공정성 문제

처음에는 각자 로컬 환경을 쓰게 할까 했습니다. “환경 구축도 실력이다”, 나름 일리가 있었습니다. 익숙한 도구를 자유롭게 쓰게 하자는 논리였습니다.

하지만 “AI 도구"가 핵심 변수가 되면서, 자유와 공정성 사이의 균형이 깨졌습니다.

2-3시간 테스트에서 잘 세팅된 AI 에이전트(ChatGPT Pro, Claude Max, 최적화된 IDE 연동, 커스텀 프롬프트)를 가진 사람과 아닌 사람의 차이는 압도적입니다. 실력 차이가 아니라 자본 차이입니다. 좋은 도구를 가졌는지를 테스트하는 거지, 깊이 생각하는지를 테스트하는 게 아닙니다.

사고력을 테스트하고 싶었지, 구매력을 테스트하고 싶은 게 아니었습니다.

그래서 모든 지원자에게 동등한 AI 환경을 제공하기로 했습니다. OpenAI와 협업하여 모든 지원자에게 충분한 토큰의 무료 에이전트를 제공했습니다. 도구 조건을 맞추고, 진짜 중요한 사고력을 테스트합니다.

이 자리를 빌려 OpenAI 팀에 감사를 전합니다. 덕분에 공정한 평가 환경을 만들 수 있었습니다.

모호함의 스펙트럼

AI 시대 코딩 테스트 설계에서 가장 어려운 문제: 문제가 얼마나 모호해야 하는가?

별거 아닌 것 같지만, 여기서 모든 게 갈립니다. 보정을 잘못하면 완전히 엉뚱한 걸 테스트하게 됩니다.

완전 모호: “유용한 걸 만들어라”. AI 에이전트에게도 여전히 어렵습니다. 의도를 모르니까요. 하지만 지원자에게도 비생산적입니다. 너무 열려 있고, 신호가 너무 적습니다.

반쪽 모호: “이 엔드포인트로 REST API를 만들어라: POST /users, GET /users/{id}…” 이건 너무 쉽습니다. API 엔드포인트, 데이터 모델, UI 레이아웃을 지정하는 순간 구현을 알려준 거나 다름없습니다. AI 에이전트는 반쯤 빈 상자를 추론으로 몇 분 만에 채웁니다.

Sweet spot은 양극단 사이에 있습니다: 모호한 요구사항 + 명확한 결과 기대치. 지원자가 무엇을 만들지 도출해야 합니다. AI는 실행할 수 있지만 무엇을 실행할지 결정할 수는 없습니다.

가설은 이렇습니다: 실제 이해관계자가 쓰듯이 빈틈 있는 문제를 주면, 깊이 생각하는 사람은 자연스럽게 드러날 것입니다. 그래서 엣지 케이스 처리 방법을 지정하지 않았습니다. NFR을 정의하지 않았습니다. API 엔드포인트를 나열하지 않았습니다. 시스템이 뭘 해야 하는지만 적고, 나머지는 지원자에게 맡겼습니다. 딱 한 줄 덧붙였습니다: “명시되지 않은 모든 사항은 자유롭게 결정하세요.”

모호함 자체가 테스트입니다.

이것이 “AI 네이티브"와 “AI 의존"의 차이입니다: 스펙이 알려주지 않을 때, 무엇을 해야 하는지 스스로 파악할 수 있는가?

시간/범위의 딜레마, 그리고 오픈소스라는 해법

AI 시대 테스트 설계에는 패러독스가 있었고, 이걸 풀어내는 데 시간이 걸렸습니다:

1. 알고리즘 테스트는 죽었다. 짧은 알고리즘 문제는 오늘 1분이면 끝납니다. 신호가 부족합니다.
2. 그러면 풀 서비스를 요구하자. 데이터베이스, API, 비즈니스 로직, 동시성을 갖춘 실제 애플리케이션은 AI가 자동으로 못할 만큼 복잡합니다. 지원자가 생각해야 합니다.
3. 하지만 풀 서비스는 테스트하기 어렵다. 수백 개 제출물을 수작업으로 채점할 수 없습니다. 자동화된 테스트가 필요합니다. 즉 각 제출물을 실행할 방법이 필요한데…
4. 그러면 Docker를 요구하자? 하지만 Docker를 필수로 하는 건 구현에 대한 큰 힌트입니다. API 엔드포인트, DB 스키마, 테스트 인프라를 지정하는 것도 마찬가지입니다. 힌트를 줄수록 AI가 사고를 건너뛸 수 있습니다.

테스트 가능성을 높일수록 구체성이 높아지고, 구체성이 높아질수록 AI의 일이 쉬워지고 지원자의 사고는 얕아집니다.

해법은 의외의 곳에서 왔습니다: 오픈소스.

좋은 오픈소스 프로젝트를 떠올려 보세요. 엔드포인트 목록이나 Docker 명령어를 채점표에 적어두지 않아도, README만 읽으면 빌드하고 실행할 수 있습니다. 헬스체크가 있고, 다른 개발자(또는 에이전트)가 바로 쓸 수 있는 API 문서가 갖춰져 있습니다.

그래서 테스트 인프라를 지정하는 대신, 좋은 오픈소스 프로젝트처럼 문서화하라고 했습니다. 빌드하는 법, 실행하는 법, 테스트하는 법을 적어라. 그러면 우리의 평가 에이전트(역시 AI)가 그 문서를 읽고, 프로젝트를 빌드하고, 기능을 테스트합니다.

다른 사람이 테스트할 수 있게 신경 쓰는 지원자는 자연스럽게 README도, 빌드 스크립트도, 헬스체크도, API 문서도 잘 씁니다. 지시받지 않아도. 힌트 없이도.

코드를 포장하는 방식 자체가 평가 대상입니다.

실제로 무엇을 물었나

이 모든 철학을 바탕으로, 실제 시험은 어떤 모습이었을까요?

지원자들에게 낸 문제: 대학교 수강신청 시스템을 구축하라.

기획팀 메모로 시작합니다:

“매 학기 수강신청 기간마다 서버가 다운되어 학생들의 불만이 폭주하고 있습니다. 이번에는 제대로 된 시스템을 만들어주세요.”

메모에는 기본 기능(학생 조회, 강좌 조회, 수강신청, 수강취소, 시간표 조회)이 나열되어 있습니다. 18학점 상한과 시간 충돌도 언급됩니다. 그리고 이 한 줄:

“정원이 1명 남은 강좌에 100명이 동시에 신청해도, 정확히 1명만 성공해야 합니다.”

이것이 전부입니다. 락 메커니즘 지정 없음. 성능 요구사항 없음. NFR 없음. 인증 모델 없음. 취소 정책 없음. 선수과목 규칙 없음.

그리고 문제에 명시합니다: “명시되지 않은 모든 사항은 자유롭게 결정하세요.”

반문할 수 있습니다: “수강신청 시스템을 만들라고 했으면 무엇을 만들지 이미 알려준 거 아닌가?”

그럴까요? “수강신청 시스템"이 대체 뭘까요? 한 문장으로 완전히 정의할 수 있을까요? 그 네 글자 뒤에 뭐가 숨어 있는지 생각해 보세요: 극한 경쟁 상황의 동시성, 비즈니스 규칙이 엮인 데이터 정합성, 부하 상태의 성능, 실패 모드, 시간표 엣지 케이스, 좌석 배분의 공정성. 네 글자 뒤에 끝없는 복잡성이 숨어 있습니다.

다행인 건, 우리 지원자들은 이 문제를 겪어봤다는 것입니다. 자기 대학교의 망가진 수강신청을 뚫어봤고, 부하에 뻗어버리는 티켓 예매 사이트에 욕을 해봤습니다. 적어도 당하는 쪽으로서, 경쟁 상황에서 시스템이 터지면 어떻게 되는지 압니다. 그 경험이 씨앗입니다. 문제의 정의는 저 한 문장에서 시작될 뿐이지, 사양서가 아닙니다.

진짜 질문은 이겁니다: 그 한 문장에서 얼마나 멀리 갈 수 있을까요? 겪어본 불만을 어떻게 체계적인 시스템 설계로 풀어낼까요? 요청한 사람들조차 자기가 원하는 걸 정확히 모르는데, “올바른 시스템"이 뭔지를 어떻게 정의할까요? 괜히 과학자와 수학자가 정의로부터 시작하는 게 아닙니다. 정의하는 행위 자체가 진짜 사고이기 때문입니다.

이건 원래 시니어 IC의 영역이었습니다. 뭉뚱그려진 요구를 명확한 기술 방향으로 바꾸는 능력. AI라는 사고 파트너가 생기면서 그 경계가 허물어지고 있습니다. 에이전트와 함께 문제를 파고들 줄 아는 주니어 엔지니어, 올바른 질문을 던지고 가정을 흔들어보고 엣지 케이스를 찾아내는 주니어 엔지니어가 과거에는 팀이 해야 했던 일을 혼자 할 수 있는 시대입니다. 어떤 엔지니어든 시니어 IC처럼 일할 수 있습니다. 실제로 그렇게 하는 사람이 우리가 찾는 사람입니다.

앞의 모든 설계 원칙이 이 문제에 수렴합니다. 모호함이 보정되어 있습니다: 무엇을 만들지는 알지만(수강신청 시스템), 어떻게는 도출해야 합니다. 결과 기대치는 명확하지만(100명 동시 신청, 1명만 성공), 메커니즘은 본인이 선택합니다. 문제를 실제 기획팀 메모처럼 쓴 건, 입사 첫날 읽게 될 문서가 바로 그런 것이기 때문입니다.

의도적인 모호함이 자연스러운 갈림길을 만듭니다. 깊이 생각할수록 다른 답이 나옵니다. 몇 가지를 살펴보겠습니다.

숨겨진 깊이

데이터 설계 함정

문제는 시작 시 현실적인 테스트 데이터 생성을 요구합니다. 학생 10,000명 이상, 강좌 500개 이상, 교수 100명 이상을 동적으로, 1분 이내에 만들어야 합니다.

겉으로는 간단해 보입니다. 학생을 만들고, 강좌를 만들고, 교수를 배정한다. 끝.

하지만 숨겨진 복잡성은 관계에 있습니다. 강좌 시간표를 어떻게 배정할까요? 랜덤으로 시간대를 뿌리면 모든 강좌가 겹쳐버릴 수 있고, 시간 충돌 테스트가 무의미해집니다. 정원을 어떻게 잡을까요? 너무 크면 동시성 테스트가 사소해지고, 너무 작으면 시스템이 못 쓰게 됩니다. 교수-강좌 관계는? 교수 당 강좌 1개? 현실적인 강의 부하?

미리 생각하는 지원자는 이 데이터로 실제 뭘 할 건지를 염두에 두고 데이터 생성을 설계했습니다. 시간 충돌을 테스트할 수 있을 만큼 다양한 시간표, 동시성을 검증할 수 있을 만큼 타이트한 정원, 엣지 케이스를 드러낼 수 있을 만큼 현실적인 관계. 데이터 설계를 시스템 설계로 다뤘지, 일회용 스크립트로 보지 않았습니다.

미리 생각하지 않은 지원자는 얕고 연결되지 않은 데이터를 만들었습니다. 기술적으로는 유효하지만, 시스템이 그 데이터를 가지고 뭘 할지까지는 생각하지 못한 겁니다. 시더는 돌아갔지만, 테스트할 가치가 있는 세계를 만들지는 못했습니다.

데이터 문제 안에 숨어 있는 설계 문제입니다. 이걸 알아차리고, 왜 그렇게 만들었는지까지 적어둔 지원자들이 우리가 찾던 사람입니다.

동시성 사다리

“100명 동시 요청을 처리하라"고 했지만 방법은 지정하지 않았습니다. pessimistic lock, optimistic lock, 큐, 단일 머신 vs 분산. 아무것도. 지원자가 무엇을 선택했는지가 사고 깊이를 드러냅니다:

어떤 수준도 “틀린” 것이 아닙니다. synchronized를 선택하고 이유를 명확히 설명하는 지원자(단일 인스턴스 범위, 주어진 제약에 맞는 단순성, 트레이드오프 정리)가 이유도 모르면서 Redis 락을 쓰는 지원자보다 높은 점수를 받습니다.

추론이 메커니즘보다 중요합니다. 어떤 락을 골랐느냐가 아니라, 왜 그 락을 골랐느냐가 점수를 가릅니다.

더 좋은 AI 모델이나 더 날카로운 프롬프트가 이런 인사이트를 대신 찾아줄 수 있지 않냐고요? 당연히 가능합니다. 그리고 괜찮습니다. Duck Typing과 같은 원리입니다. 깊은 사고의 결과가 나오고 깊은 사고의 과정을 거쳤다면, 그건 깊은 사고입니다. 혼자 힘으로 도달했든 에이전트와의 대화를 통해 도달했든, 도달했다는 것 자체가 실력입니다.

이중 락 인사이트

가장 깊은 분기점입니다. 두 범위의 락을 모두 구현한 명확한 증거를 남긴 지원자는 다섯 명 중 한 명이 채 안 됐습니다. 그중에서도 절반 정도만 프롬프트나 설계 문서에서 이 문제를 스스로 짚어낸 흔적을 남겼습니다. 나머지는 AI 에이전트가 알아서 처리한 경우입니다. (에이전트가 먼저 풀어버려서, 지원자가 생각할 기회 자체가 없었을 수도 있습니다.)

대부분의 지원자는 동시성을 강좌 레벨 락으로만 생각합니다. 정원이라는 공유 자원을 보호하는 것. 100명이 1자리에 몰리면 1명만 성공해야 한다. 강좌 행에 락을 건다. 끝.

하지만 그건 문제의 절반일 뿐입니다.

같은 학생이 동시에 두 개의 수강신청 요청을 보내는 경우를 생각해 보세요. 더블클릭이든, 브라우저 탭 두 개든. 서로 다른 과목에 대한 두 요청이 동시에 도착합니다. 둘 다 확인합니다: “이 학생 18학점 미만인가?” 둘 다 15학점을 봅니다. 둘 다 통과. 둘 다 등록. 학생은 이제 21학점. 학점 제한이 깨집니다.

같은 패턴이 시간 충돌 감지와 중복 수강 체크도 깨뜨립니다.

강좌 레벨 직렬화는 정원(모든 학생에게 공유되는 자원)을 보호합니다.

학생 레벨 직렬화는 학생별 제약조건(학점 제한, 시간 충돌, 중복 수강)을 보호합니다.

둘 다 필요합니다. 그리고 둘 다 필요해지는 순간, 새로운 문제가 생깁니다: 락 순서. 어떤 코드 경로는 학생 락을 먼저 잡고, 다른 경로는 강좌 락을 먼저 잡으면 데드락이 걸립니다. 동시성을 깊이 파고들수록 함정은 더 늘어납니다.

메커니즘은 다를 수 있습니다. pessimistic lock, optimistic lock + 재시도, application-level lock, 분산 락, serializable isolation. 하지만 요구사항은 같습니다: 같은 학생의 동시 요청은 직렬화해야 합니다. 그래야 제약조건이 깨지지 않습니다.

여기에 도달한 지원자들이 우리가 원하는 엔지니어입니다. 혼자 알아냈든, 에이전트와의 대화를 통해 도달했든. 그리고 그중에서도 더 나아간 사람들이 있습니다. 문제를 풀고 끝낸 게 아니라, 왜 이렇게 풀어야 하는지를 문서로 남기고, 다음에 비슷한 문제를 만났을 때 스스로 판단할 수 있는 사람. 우리 평가 모델은 바로 그 차이를 드러내도록 설계되어 있습니다.

철학을 실전으로

철학만으로는 부족합니다. 측정할 수 있어야 합니다. 그래서 3-Tier 평가 모델을 만들었고, 각 Tier는 점점 더 깊은 질문을 던지도록 설계했습니다. Part 2와 3에서 다루겠지만, 제출물에서 기계가 실제로 읽어낼 수 있는 신호는 예상보다 까다로운 문제였습니다. 다만 프레임워크 자체는 유효했습니다.

Tier 1 — Make it Work. 빌드되는가? 시작되는가? 헬스체크에 응답하는가? 동작하는 서비스를 배포할 수 없다면, 나머지는 의미 없습니다.

Tier 2 — Basic Features. API가 동작하는가? 비즈니스 규칙이 시행되는가? 동시성 제어가 부하 상태에서 버티는가? 카테고리별 자동화 테스트를 Docker 컨테이너 안에서 돌립니다. 사람 손 안 탑니다.

Tier 1과 2는 Duck Typing입니다. 동작하는 시스템처럼 행동하면 동작하는 시스템입니다. 어떻게 거기 도달했는지는 묻지 않습니다. 외부 행동이 곧 검증입니다.

Tier 3 — Deep Thought. 여기서 Duck Typing 너머로 갑니다. Duck Typing은 동작한다는 건 알려주지만, 이 엔지니어가 이 수준을 유지할 수 있는지, 더 성장할 수 있는지는 알려주지 않습니다. 그래서 내부를 들여다봅니다: 프롬프트 이력, 에이전트 지침, 요구사항 도출 문서, 데이터 설계, 코드 품질, 테스트 커버리지, git 이력, 추가 구현사항. 이걸 AI가 평가합니다. 모든 점수에 파일 경로와 라인 번호가 근거로 붙습니다.

Tier 3에서 가르려는 건 맡기기만 한 건지, 이해하면서 쓴 건지입니다. 이 구분은 생각보다 중요합니다.

Anthropic의 최근 연구(“How AI assistance impacts the formation of coding skills,” Shen & Tamkin, 2026)가 이 두 모드 사이에 분명한 선을 긋습니다. AI에게 맡기기만 하는 엔지니어는 당장은 빠릅니다. 하지만 이해하면서 쓰는 엔지니어, AI를 같이 생각하는 파트너로 쓰는 엔지니어는 시간이 지날수록 역량이 복리로 쌓입니다. Anthropic 내부 데이터에 따르면 최고 성과 엔지니어들이 1.2~2배 더 생산적이었던 건, AI를 사고의 대체재가 아니라 사고의 파트너로 썼기 때문입니다.

우리 채점의 핵심은 이겁니다: 사고의 깊이가 기능적 완성도보다 무겁다. Tier 1은 “배포 가능하며 실행되는가?“를 묻습니다. Tier 2는 “의도대로 작동하는가?“를 묻습니다. Tier 3는 “배포한 것을 이해하는가? 여기서 더 성장할 수 있는가?“를 묻습니다.

구체적인 예를 들어 보겠습니다. 두 지원자 모두 이중 락을 정확히 구현했습니다. Duck Typing으로 보면 동등합니다. 겉으로 보이는 행동이 같으니까요. 하지만 안을 들여다보면: 한 명은 점점 더 깊은 프롬프트를 통해 문제를 파고들었고, 왜 두 가지 락이 필요한지 문서로 남기고, git 이력에 이해한 흔적이 남아 있습니다. 다른 한 명은 범용적인 프롬프트로 답을 얻고 넘어갔습니다. 결과물은 같지만, 그 안에 담긴 이해의 깊이는 전혀 다릅니다.

기능 점수는 높은데 깊이가 얕으면 AI 과의존 신호입니다. 빠르게 배포하지만 왜 그렇게 했는지 설명 못 합니다. 빌드는 실패했는데 설계 사고가 탁월하면 다른 이야기입니다. 기술적으로 삐끗했어도 면접은 볼 만합니다. 정답에 도달한 사람만 찾는 게 아닙니다. 질문을 이해한 사람을 찾고 있습니다.

철학이 실전이 되는 과정입니다. 다음 글에서는 우리가 만든 실제 머신, 약 400명의 지원자를 AI가 채점하는 자동화된 파이프라인을 뜯어보겠습니다. 우리가 부딪힌 자동 평가의 한계와, 거기서 사람의 판단이 왜 필요했는지를 데이터로 보여드리겠습니다.

AI 네이티브 채용 시리즈 3부작 중 Part 1. 다음: “The Machine: AI가 AI 활용 코드를 평가하다”. 자동화된 평가 파이프라인의 기술적 심층 분석.