AI 코딩 테스트라는 새로운 채용 관문
무신사가 2차 코딩 테스트에 'AI 활용 능력 평가'를 도입했다는 소식을 처음 접했을 때, 솔직히 "드디어 왔구나"라는 생각이 먼저였습니다. 한 합격자의 회고(velog, @yds05074)를 보면, 1차에서는 요구사항을 코드로 변환하는 전통적 역량을 평가하고, 2차에서는 3시간 동안 수강신청 시스템을 Claude Code로 설계·구현·검증하도록 요구했습니다. 흥미로운 점은 합격자가 직접 코드를 거의 작성하지 않았다는 것입니다. Plan mode로 개발 계획을 세우고, 에이전트가 생성한 결과물을 Swagger와 API 문서로 검증하며, JWT 토큰 적용·서버 부하 테스트·매크로 방지 기능까지 의사결정과 피드백 루프를 주도하는 방식으로 3시간을 채웠습니다.
이건 단순히 "AI 잘 쓰는 사람 뽑겠다"는 이야기가 아닙니다. AI-First 팀 리빌딩 관점에서 보면, 채용 기준 자체가 바뀌고 있다는 신호입니다. 알고리즘 암기력이 아니라 "요구사항 분석 → 에이전트 지시 → 생성물 검증 → 추가 의사결정"이라는 AI 협업 루프를 얼마나 빠르고 정확하게 돌릴 수 있느냐가 평가 축이 된 겁니다. 팀을 꾸릴 때도 마찬가지입니다. 앞으로 온보딩 프로세스에 Claude Code Plan mode 워크플로우와 MCP 세팅 가이드가 포함되지 않는 팀은 경쟁력을 잃을 수밖에 없습니다.
오퍼스가 셰프, 소넷이 주방 보조: AI 오케스트레이션의 실전
채용이 바뀌면 워크플로우도 바뀌어야 합니다. 브런치에 올라온 한 비전공자 출신 경영인의 경험담(@jimmyjeon42)이 이를 정확히 보여줍니다. 처음에는 Opus 4.6 모델로 에이전트 40개를 동시에 돌리다 월 70만 원을 토큰 비용으로 태웠습니다. 그러다 Opus를 CTO(기획·의사결정·품질 검수), Sonnet을 실무 개발자(병렬 모듈 개발·디버깅)로 역할을 분리하는 오케스트레이션 구조를 도입하면서 비용과 속도 문제를 동시에 해결했습니다.
이 사례가 AI-First 팀 리빌딩에 시사하는 바는 명확합니다. 에이전트를 "하나의 만능 도구"로 쓰는 단계는 끝났습니다. 모델별 강점을 파악해 역할을 배분하고, 비용 대비 효율을 최적화하는 것은 이제 테크 리드의 핵심 역량입니다. 과거 CFO 시절 10명이 필요했던 경영 전 과정을 AI 오케스트레이션으로 혼자 수행한다는 그의 주장이 과장일 수 있지만, 방향성 자체는 틀리지 않았습니다.
Kagan: 에이전트에게 필요한 건 능력이 아니라 '지휘자'였다
오케스트레이션의 필요성이 커질수록 이를 구조화하는 도구도 등장합니다. MakerX가 공개한 Kagan은 AI 코딩 에이전트를 칸반 보드 위에서 지휘하는 TUI(Terminal UI) 도구입니다. Claude Code, Codex, Gemini CLI 등 14개 에이전트를 지원하며, 각 태스크마다 AUTO(에이전트 자율 실행) 또는 PAIR(개발자 협업) 모드를 선택할 수 있습니다. 핵심은 git worktree 기반으로 에이전트들이 서로 충돌 없이 병렬 작업하고, Agent Communication Protocol(ACP)로 세션 상태를 관리한 뒤, 리뷰 단계에서 diff·체크리스트·AI 요약과 함께 GitHub PR을 자동 생성한다는 점입니다.
이건 앞서 언급한 오케스트레이션을 수동으로 구성하던 방식을 도구 레벨로 표준화한 것입니다. "명확하고 범위가 한정된 태스크는 AUTO, 탐색적이거나 아키텍처 판단이 필요한 태스크는 PAIR" — 이 판단 기준이 팀 전체에 공유되면, AI-First 워크플로우의 일관성이 비약적으로 올라갑니다. uvx kagan 한 줄로 설치할 수 있다는 점도 도입 장벽을 낮춥니다.
AI 브라우저로 사용성 테스트까지: 검증의 마지막 마일
코딩과 오케스트레이션 다음은 테스트입니다. 브런치(@55tree)에 공개된 실험에서는 ChatGPT의 AI 브라우저 Atlas를 활용해 가상 퍼소나 기반 사용성 테스트(UT)를 시도했습니다. 두 명의 가상 사용자에게 Think Aloud 기법을 적용하고, 소요 시간·물리적 행동·속마음·장애물 반응까지 기록하도록 프롬프트를 설계한 결과, 실제 수강생에게서 동일한 VoC(Voice of Customer)가 확인된 인사이트가 도출되었습니다.
물론 한계는 분명합니다. AI 시뮬레이션은 진짜 감정과 맥락을 완벽히 재현하지 못하고, 화면 요소를 잘못 인식하는 경우도 발생합니다. 하지만 실제 UT 진행 전에 프롬프트 한 번으로 1차 필터링을 돌릴 수 있다는 것 자체가 리소스 절약에 큰 의미가 있습니다. AI-First 팀에서는 "일단 AI로 리뷰 받아보고, 거기서 나온 걸 기반으로 우리가 다듬는" 패턴이 코드 리뷰를 넘어 UX 검증까지 확장되고 있는 셈입니다.
시사점: AI-First 팀이 세팅해야 할 세 개의 레이어
네 가지 사례를 관통하는 메시지는 하나입니다. AI는 이제 '보조 도구'가 아니라 '팀원'으로 편제되어야 한다는 것. 구체적으로 팀에 적용할 레이어는 세 가지입니다.
- 채용·온보딩 레이어: 무신사처럼 AI 협업 능력을 평가하는 코딩 테스트를 설계하고, 신규 팀원에게 에이전트 워크플로우(Plan → Implement → Verify → Commit)를 첫 주에 교육합니다.
- 오케스트레이션 레이어: Kagan 같은 도구로 에이전트 역할 분배를 표준화하고, AUTO/PAIR 모드 판단 기준을 팀 컨벤션으로 문서화합니다.
- 검증 레이어: AI 기반 코드 리뷰와 AI 브라우저 UT를 병행해, 생성물의 품질을 인간이 최종 판단하는 게이트를 반드시 유지합니다.
"AI가 생성해준 걸 기반으로 우리가 다듬으면" — 이 문장이 모든 팀원의 입에서 자연스럽게 나올 때, AI-First 팀 리빌딩은 완성됩니다. 도구는 이미 충분히 갖춰졌습니다. 남은 건 팀의 마인드셋과 프로세스를 얼마나 빠르게 전환하느냐의 문제입니다.