도구 도입이 아니라 구조 전환이다
컴투스가 Claude Code를 사내 표준 코딩 도구로 지정하고, 전 직원에게 개인 AI 에이전트를 한 명씩 배정하는 '1인 1에이전트' 체제를 전사로 확산하고 있다. 게임와이가 분석한 '2026 컴투스 ESG 리포트'에 따르면, 이 회사는 AI 전담 조직 'AX HUB'를 신설하고 아트·기획·개발·QA까지 게임 제작 전 과정에 AI를 붙였다. 선언적 구호가 아니라 재무 압박이 만들어낸 실행이다. 2025년 매출 6,964억 원에 영업이익 26억 원, 영업이익률 0.4%라는 숫자가 이 전환의 배경이다.
내가 이 사례에서 주목하는 건 'Claude Code 도입' 자체가 아니다. 도입 방식의 구조다. 컴투스는 4단계 교육 체계(오프라인 밋업·온라인 세미나)를 설계하고, 2025년 사내 세미나의 81%를 AI 주제로 채웠다. 여기에 현업 밀착형 AI 설계 엔지니어(FDE·Forward Deployed Engineer)를 제작·사업 본부에 배치하는 방안까지 준비 중이다. 단순히 라이선스를 사서 푸는 게 아니라, 도구를 조직 안으로 녹여내는 구조를 함께 설계하고 있다는 점이다.
Codex 오케스트레이션이 바꾸는 역할 분담
1인 1에이전트 체제가 정착되면 필연적으로 등장하는 문제가 있다. '에이전트를 어떻게 다루는가'다. dev.to에 공개된 Codex 오케스트레이션 매니저 활용 프롬프트는 이 질문에 실용적인 답을 제시한다. 핵심 아이디어는 단순하다. 에이전트를 단일 채팅 창으로 쓰지 말고, 하나의 Codex 스레드를 오케스트레이션 매니저로 지정해서 나머지 워커 스레드를 조율하게 하라는 것이다.
구조는 세 레이어로 나뉜다. 사람이 작업 범위를 정의하고 최종 판단을 내린다. 오케스트레이션 매니저가 작업을 분해하고, 워커 스레드에 목표를 배분하고, 10분 단위 하트비트로 진행 상황을 추적한다. 워커 스레드는 좁게 정의된 태스크를 실행하고, 완료·블록·PR 오픈 같은 상태 변화를 즉시 보고한다. 이 구조에서 사람이 해야 할 일은 '코드를 직접 짜는 것'이 아니라 '작업 범위를 명확하게 정의하고, 에이전트가 막힌 지점에서 판단을 내리는 것'이다. 에이전트 워크플로우가 대부분 핸드오프 지점에서 무너지는 이유를 보면 이 구조의 필요성이 명확해진다. 첫 결과물은 그럭저럭 나온다. 문제는 그 다음이다. 테스트를 돌렸는가? PR을 올렸는가? CI가 통과했는가? 리뷰 피드백이 왔는가? 이 질문들에 아무도 답하지 않으면 결국 사람이 다시 프로젝트 매니저 자리로 끌려 들어온다.
오케스트레이터의 딜레마, 그리고 현실적인 답
dev.to의 'The Orchestrator's Dilemma' 글은 이 구조 전환이 만들어내는 불편한 질문을 정면으로 꺼낸다. "우리는 개발자인가, 아니면 그냥 퀘스트를 주는 사람인가?" AI가 코드의 99%를 짜는 시대에 개발자의 정체성은 어디서 오는가라는 질문이다. 저자는 자신을 "스티브 잡스처럼 오케스트레이션하는 사람"으로 비유하면서도, 워즈니악이 진짜 영웅이었다는 사실을 안다고 고백한다.
나는 이 정체성 위기가 실재한다고 본다. 하지만 그 위기에 대한 답을 '내가 직접 코드를 짜야 진짜 개발자다'에서 찾는 건 틀렸다. 더 생산적인 질문은 이것이다. "AI가 실행을 담당할 때, 사람이 독점해야 하는 판단 영역은 무엇인가?" 컴투스 AX HUB 실장 박상준이 인터뷰에서 한 말이 여기에 정확히 닿는다. "기술을 무조건 도입하기보다 품질 검증 시스템과 인간의 전문성이 조화를 이루도록 단계적으로 확장하는 구조." 속도가 아니라 구조를 먼저 설계하겠다는 선언이다.
팀 리빌딩에서 실제로 달라져야 할 것
컴투스 사례와 오케스트레이션 매니저 워크플로우를 팀 리빌딩 관점에서 종합하면 세 가지 설계 원칙이 나온다.
첫째, 교육보다 구조를 먼저 설계하라. 컴투스가 4단계 교육 체계를 설계하고 FDE를 각 본부에 배치하는 이유는 '사용법'을 전달하는 게 아니라 'AI를 일상 워크플로우에 녹이는 구조'를 이식하기 위해서다. 도구 교육과 워크플로우 설계는 다른 문제다.
둘째, 역할을 코드 생산량이 아니라 판단 영역으로 재정의하라. 오케스트레이션 레이어에서 사람이 해야 하는 일은 작업 범위의 명확한 정의, 에이전트 충돌 가능성 사전 탐지, 최종 검증 기준 설정이다. 이 세 가지는 AI가 대체하기 어렵고, 팀 내에서 가장 시니어한 판단이 필요한 영역이다.
셋째, 보안과 품질 기준을 속도보다 먼저 놓아라. 컴투스가 '캐치시큐(CatchSecu)' 보안 체계를 먼저 도입하고 AI 확산을 진행한 구조는 의미 있다. AI-First 전환에서 품질과 보안 게이트가 뒤늦게 붙으면 기술 부채가 아니라 구조적 리스크가 된다.
전망: 1인 1에이전트 이후의 팀
1인 1에이전트 체제가 정착되면 팀의 병목은 '코드를 얼마나 빠르게 쓰는가'에서 '에이전트에게 얼마나 명확하게 작업을 정의하고, 그 결과를 얼마나 날카롭게 검증하는가'로 이동한다. 이건 개발자의 역할이 사라진다는 뜻이 아니라, 역할의 무게중심이 바뀐다는 뜻이다. 오케스트레이터의 딜레마에서 벗어나는 길은 코드를 직접 짜는 것이 아니라, 에이전트가 틀리게 달릴 수 없는 구조를 설계하는 것이다. 컴투스가 Claude Code를 '주체(Main)'로 쓰겠다고 선언하면서도 단계적 확장과 인간 전문성 조화를 강조한 이유가 거기에 있다.
팀 리빌딩의 실질적 과제는 이제 '누가 AI를 잘 쓰는가'가 아니다. '팀 전체가 에이전트와 함께 작동하는 구조를 누가 설계하는가'다. 그 설계자의 자리가 앞으로 가장 희소하고, 가장 중요해질 것이다.