무신사 AI 응용 채용 3편

요약

무신사 채용팀이 자체 구축한 AI 채용 파이프라인의 오프라인 면접 단계를 회고. 앞 단계에서 AI가 후보자 400여 명을 분류하고, 후보자별 코드 증거 기반 면접 가이드까지 만들어 면접관에게 전달. 면접관 20여 명이 5일 동안 100명 넘는 후보자와 1인당 60분씩 진행.

머신 점수 분류와 면접에서 드러난 깊이가 어긋나는 사례가 반복됨. 사람의 사고와 AI 산출물을 분리하는 일은 결국 사람의 몫으로 남았다는 결론. 다음 사이클에서는 설계 문서를 평가 중심에 두는 방향을 예고.

내용

무신사 채용팀이 도입한 AI 네이티브 평가 파이프라인의 구성 요소.

• Functional Gate: 후보자 제출물이 동작하는 시스템처럼 응답하는지로 채점. 내부 구현(pessimistic / optimistic lock 등)은 따지지 않고 결과만 본다는 원칙(Duck Typing — 동작이 같으면 같은 것으로 취급)
• Quality Gate: 프롬프트·에이전트 지침과 코드 증거에서 후보자의 사고 깊이(Depth) 점수를 추론. 코드 자체가 아니라 코드와 문서에 남은 흔적을 봄
• 점수 프로필: Base(기능)와 Depth(사고)의 조합으로 후보자를 Ace/Craftsman, Hustler, Thinker 등으로 분류 (Part 2 산출물)
• 면접 가이드: AI가 후보자별 코드에서 실제 라인(예: EnrollmentService.java:30-59)을 인용한 질문, 5점·3점·1점 기대 답변 수준, 후속 질문까지 자동 생성

상황의 출발점: 3시간짜리 과제에 분산 트레이싱·DDD 패턴·멀티레이어 캐싱까지 들어온 제출물이 다수. AI 코딩 에이전트의 구현 역량이 그 수준에 도달한 결과. 코드 뒤에 후보자의 사고가 있는지, AI가 만든 결과를 제출만 한 것인지를 코드만 보고 가르기 어려워짐. 한 번의 제출만으로는 재현성도 검증되지 않음.

면접에서 드러난 패턴

면접관은 점수 프로필별로 다른 전략을 받음.

• Ace/Craftsman (높은 Base + 높은 Depth): 아키텍처 한계를 밀어보는 질문. 예 — "이 서비스를 여러 서버 인스턴스에 배포한다면 이 락 전략이 동작할까요?"
• Hustler (높은 Base + 낮은 Depth): 문서와 코드의 일치, 설계 결정을 설명할 수 있는지 검증. 설명 못 하면 AI 과의존 신호
• Thinker (낮은 Base + 높은 Depth): 빌드 실패 후보자에게 "테스트 환경과 실제 환경 차이의 원인은?" 같은 자기 실패 진단 능력을 확인

전체적으로는 Quality Gate 점수가 면접 성과와 더 상관 있었지만, 개별 사례에서 어긋남이 나옴.

• Hustler 중 Depth 64/120점이던 후보자가 면접에서 단일 락 한계를 직접 짚고 샤딩 환경의 형평성 붕괴까지 확장. 면접관 평가 — "경력자 인터뷰에서도 보기 쉽지 않은 수준의 사고"
• 같은 Hustler 그룹 내에서 자기 코드 동작 원리를 설명하지 못하는 사례가 동시에 존재. 머신이 같은 패턴으로 묶은 사람들이 면접에서 갈라짐
• Quality Gate는 높은데 Functional Gate가 매우 낮은 후보자: 인증 체계를 엄격히 짜서 동시 접근을 제한, 테스트 케이스 전제와 어긋난 엣지 케이스. 코드를 사람이 수동 확인 후 면접 진행, 면접 점수는 높게 나옴

면접관 자신도 캘리브레이션 대상이었음. 점수와 코멘트 온도차(높은 점수 + 미지근한 코멘트, 낮은 점수 + 칭찬 코멘트)가 발생. 1인당 4–5건 이상 배정해 패턴을 드러내고 별도 캘리브레이션 단계에서 편향을 보정.

면접의 나머지 30분은 사람을 보는 시간. 신입이 다수라 경력 기반 리더십 평가 대신 학습·적응 태도에 집중. 협업 항목은 AI와의 협업 방식으로 관찰 — AI 제안을 비판적으로 검토했는지, 반문하고 방향을 바꾼 경험이 있는지.

회고에서 본 한계

채용팀이 파이프라인을 만들 때는 코드가 아니라 지침을 고쳤음. AI에 전달하는 작업 지시와 평가 룰브릭을 다듬는 작업, 즉 하네스 엔지니어링. 최근 Context Engineering이라 불리는 방향과 같음 — AI에 전달하는 문맥의 품질이 산출물 품질을 결정한다는 접근.

그런데 후보자 평가에서는 프롬프트와 코드 산출물에 의존. 설계 문서를 요구는 했지만 평가의 중심에 놓지는 못함.

면접 결과가 이 차이를 노출. 기능 점수는 스크리닝까지 유효했고, 면접에서 드러난 깊이와 더 관련이 있었던 것은 코드 품질·설계 사고. 코드는 의도의 그림자라는 결론. 왜 그렇게 만들었는지의 문맥은 코드가 아니라 설계 문서에 남음.

면접관도 AI 가이드에 묶일 위험이 있음. 가이드를 따라 질문하고 기대 답변에 점수를 매기는 모습이, Hustler를 의심한 이유(AI가 만든 코드를 이해 없이 제출)와 대칭이라는 자각. 다만 가이드를 발판 삼아 가이드 밖 방향으로 대화를 이끈 면접관이 더 깊은 정보를 얻었다는 관찰이 같이 나옴.

참고

이번 채용에서 채용팀이 정리한 결론.

• 머신은 필터로 작동. 다만 사람의 사고와 머신 산출물을 분리하는 일은 머신의 몫이 아니었음
• 다음 사이클에서는 설계 문서를 평가 중심에 두는 방향을 시도할 예정 — "왜 이 설계를 선택했고 어떤 트레이드오프를 고려했는지"를 명시적으로 요구
• Part 1의 문장("정답에 도달한 사람이 아니라 질문을 이해한 사람을 찾는다")에 추가 — 도구가 강력해질수록 도구를 쓰는 사람의 판단이 결과를 가른다(적어도 현재 시점)

시리즈 구성: Part 1 The Philosophy / Part 2 The Machine (AI가 AI 활용 코드를 평가한 단계) / Part 3 The Human (이 글).

원문: The Human: 점수 너머의 판단 (MUSINSA techblog)