AI 에이전트 50개로 일한다고요? 개인 AX와 조직 AX는 다른 게임이다

2026년 1월, Boris Cherny는 자신의 워크플로우를 공개했다. 터미널에 Claude Code 인스턴스 5개를 동시에 띄운다. 각 인스턴스는 같은 저장소의 서로 다른 git checkout에서 작업한다. 1번이 테스트를 돌리는 동안 2번에게 피드백을 주고, 3번의 결과를 리뷰한다. 코드를 직접 수정한 마지막 날짜는 2025년 11월이다. 하루에 Pull Request를 10~30개 올린다.

Cherny만의 이야기가 아니다. Midjourney는 107명으로 연 5억 달러 이상의 매출을 만든다. Cursor는 20명 남짓한 팀으로 10억 달러 ARR을 3개월 만에 20억 달러로 두 배 늘렸다. Y Combinator 2025년 Winter 배치의 25%는 코드베이스의 95% 이상을 AI가 작성한 스타트업이었다.

개인 생산성 혁명은 이미 증명됐다. 문제는 이 다음이다.

Phase Transition: 같은 기술, 다른 차원의 문제

물은 99도에서 100도로 올라갈 때 액체에서 기체로 바뀐다. 온도가 1도 오른 것뿐인데 물질의 성격 자체가 달라진다. AI 에이전트가 한 사람의 도구에서 조직의 인프라로 넘어갈 때, 정확히 같은 일이 일어난다. 더 어려운 게 아니라,다른 종류의 어려움이다.

반면 Gartner에 따르면 AI와 함께 업무 프로세스를 재설계한 조직은 매출 목표를 초과 달성할 확률이 2배였다. 기술이 문제가 아니다. 1인 도구를 조직 시스템으로 전환하는 설계가 문제다.

개인 AX, 200인 규모의 조직 AX, 1,000인 이상 대기업 AX를 동시에 보고 있는 입장에서 — 이 셋이 왜 완전히 다른 게임인지 하나씩 풀어본다.

N² 문제: 에이전트를 늘리면 조정 비용은 제곱으로 는다

Cherny가 인스턴스 5개를 동시에 돌릴 수 있는 이유는 단순하다. 모든 에이전트가 같은 CLAUDE.md를 읽고, 같은 코드베이스에서 작업하고, 같은 사람의 판단을 기다린다. 충돌이 나면 본인이 merge한다.한 사람이 전체 컨텍스트를 들고 있기 때문에 조정 비용은 사실상 0이다.

소규모 조직에서도 이게 통하는 이유가 있다. 특정 영역을 여러 명이 동시에 다루는 경우가 드물다. 백엔드는 한 명, 프론트는 한 명, 마케팅은 한 명. 각자가 자기 영역의 유일한 의사결정자이기 때문에 에이전트를 도입해도 커뮤니케이션 비용이 거의 늘지 않는다. CLAUDE.md 하나면 충분한 건 이 구조 덕분이다.

Cherny는 Anthropic에서 의도적으로 프로젝트에 인력을 적게 넣는다. 5명 대신 1명. 무제한 토큰과 내재적 동기가 있으면 한 명이 더 빠르게 배포한다고 한다. 이 원칙으로 엔지니어 1인당 생산성이 200% 증가했다.

조정 복잡도 N²는 수학 법칙이지, 사회학적 제안이 아닙니다.

— Peter Forret

에이전트의 ramp-up 시간은 0이다. CLAUDE.md를 읽는 데 0.5초면 된다. 하지만 에이전트가 작동할 워크플로우를 합의하는 시간은 여전히 사람 수에 비례한다. 마케팅팀의 에이전트가 만든 보고서를 경영진의 에이전트가 읽으려면, 출력 형식이 호환되어야 하고, 데이터 접근 범위가 합의되어야 하고, 에러 시 책임 소재가 정의되어야 한다. 기술 문제가 아니라 조직 문제다.

Google Research가 올해 보여준 결과도 같은 방향이다. 멀티에이전트 시스템은 병렬 가능한 작업에서 극적으로 성능이 올라가지만, 순차적 의존성이 있는 작업에서는 오히려 떨어진다. 현실의 기업 업무는 대부분 순차적 의존성 투성이다. A팀 결과가 나와야 B팀이 시작하고, B팀 피드백이 반영되어야 C팀이 마감한다.

실전에서 부딪힌 것: QANDA의 Wizard 도입기

QANDA에서는 올해 초 전사에 Claude Code Max를 도입하고, Wizard라는 자체 harness 시스템을 만들었다. CLAUDE.md 하나로 충분한 건 10명 이하 팀까지다. 그 이상의 규모에서는 워크플로우 정의, 코드/작업 컨벤션 관리, 아웃풋 품질 보장이 하나의 시스템으로 통합되어야 한다. Wizard가 하는 일이 그것이다.

처음에는 단순했다. 개발자 한 명이 Wizard skill을 로드하고 작업하면 됐으니까. 팀 전체가 쓰기 시작하면서 문제가 드러났다. 개발자 A의 에이전트가 만든 PR이 개발자 B의 에이전트가 만든 PR과 충돌했다. 같은 컨벤션을 따라야 하는데 에이전트마다 해석이 달랐다. 에이전트가 생성한 코드의 품질을 누가 보장하는지도 정해지지 않았다.

지금은 세 가지 축으로 풀고 있다. 첫째, 워크플로우 — PRD → Spec → Code → Test 파이프라인을 에이전트가 따르도록 강제한다. 둘째, 컨벤션 — 코딩 스타일, 커밋 규칙, 리뷰 기준을 에이전트가 참조하는 명시적 규칙으로 정의한다. 셋째, 품질 게이트 — 에이전트의 아웃풋이 일정 기준을 통과해야만 다음 단계로 넘어간다. 여기에 boundary separation을 더해서, orchestrator가 전체 dispatch를 담당하고 각 worker는 자기 domain의 context만 접근한다. 이 구조 전체가 Wizard다.

권한 아키텍처: 내 노트북에서의 God Mode가 조직에서는 지옥이 되는 이유

혼자 일하면 에이전트의 권한은 곧 "나"다. 내 Google Drive, 내 Notion, 내 이메일. "다 읽어"라고 하면 된다. 전편에서 다뤘던 Human-in-the-Loop도, 1인일 때는 "내가 확인하면 됨"이다.

100명 조직에 에이전트를 도입하면 권한 매트릭스가 폭발한다.

50명이 에이전트 3개씩 쓰고, 데이터 범위가 10개, 행동 범위가 5단계면 — 7,500개의 권한 결정이 필요하다. 사람이 팀을 옮기거나 프로젝트가 바뀔 때마다 재계산된다.

QANDA에서도 이 문제를 풀고 있다. CEO의 에이전트는 재무 데이터를 읽지만 개발팀의 에이전트는 못 한다. 같은 Wizard 위에서 돌아가는데 접근 범위가 다르다. 서버의 크론잡 에이전트가 발견한 할 일이 로컬 에이전트의 작업 목록에 반영되어야 하고, 여러 에이전트가 동시에 같은 knowledge vault를 수정하면 충돌 방지가 필요하다.

이건 분산 시스템 설계의 고전적 문제 — eventual consistency, conflict resolution, access control — 가 에이전트 시대에 새로운 형태로 나타난 것이다.

Klarna가 "We went too far"라고 말한 이유

Klarna는 가장 공격적인 AX 사례로 꼽힌다. 직원을 절반으로 줄이고 매출을 108% 늘렸다. AI가 고객 서비스의 상당 부분을 대체했고, 비용이 6,000만 달러 절감됐다. 숫자만 보면 완벽한 성공이다.

그런데 CEO Sebastian Siemiatkowski가 올해 2월 공개적으로 인정했다.

We went too far. AI의 능력을 과대평가하고, 서비스의 인간적 측면을 과소평가했다.

— Sebastian Siemiatkowski

60% 급여 인상으로 사람을 다시 뽑고 있다. 이건 기술 실패가 아니다. 아키텍처 실패다. 어떤 업무에 Agent 수준의 자율성을 주고 어떤 업무에 Human-in-the-Loop를 유지할 것인지 — 전편에서 다뤘던 그 autonomy spectrum의 경계 설계가 잘못된 것이다.

개인이 자기 업무의 경계를 잡는 건 쉽다. 내가 판단하면 되니까. 1,000명 조직에서 수백 개 업무의 자율성 수준을 일관되게 설계하는 건 전혀 다른 스케일의 문제다.

조직의 기억: CLAUDE.md에서 Context Infrastructure로

모든 회사가 같은 AI 모델을 쓸 수 있을 때, 컨텍스트가 경쟁 우위가 된다.

— Harvard Business Review

Cherny의 팀에서 CLAUDE.md는 문서가 아니다. 에이전트가 읽고 즉시 행동을 바꾸는 실행 가능한 컨텍스트다. Claude가 뭔가 잘못하면 CLAUDE.md에 한 줄 추가한다. "다음엔 이렇게 하지 마라." 팀 전체가 주 여러 번 기여하고, git에 체크인돼 있으니 버전 관리된다. 한 줄 추가하면 그 순간부터 모든 에이전트 인스턴스의 행동이 바뀐다.

사람이 읽는 wiki와의 결정적 차이가 여기 있다. wiki에 "이렇게 하지 마라"를 써도 사람은 안 읽는다. CLAUDE.md에 쓰면 에이전트는 반드시 읽는다.규칙의 완전한 준수가 가능해진다.

QANDA의 Wizard는 이걸 한 단계 더 밀고 나갔다. CLAUDE.md는 컨텍스트의 한 조각일 뿐이다. Wizard에는 워크플로우 정의, 작업 컨벤션, 품질 게이트가 통합되어 있어서 에이전트가 "어떤 순서로, 어떤 규칙을 따라, 어떤 기준을 통과해야 하는지"를 시스템 수준에서 강제한다. 1월에 반복하던 실수를 3월에는 안 하는 건 CLAUDE.md 한 줄 때문이 아니라, 품질 게이트가 그 실수를 통과시키지 않기 때문이다.

CLAUDE.md가 충분한 건 10명까지다

10명이 넘어가면 CLAUDE.md 하나로는 안 된다. 컨벤션이 복잡해지고, 워크플로우가 분기하고, 품질 기준이 팀마다 달라진다. 그래서 CLAUDE.md를 포함하되 워크플로우, 컨벤션, 품질 게이트를 통합한 harness 시스템이 필요해지는 것이다. QANDA의 Wizard의 초기 버전이 이 문제를 푸는 시도다.

100명을 넘어가면 문제가 한 번 더 바뀐다. 조직의 컨텍스트가 Notion, Slack, Jira, Confluence, Google Drive, Salesforce, SAP, 사내 ERP에 흩어져 있다. 각 시스템의 데이터 형식이 다르고, 접근 권한이 다르고, 업데이트 주기가 다르다.

전편에서 다뤘던 세 가지 context 문제가 조직 수준에서 증폭된다.

Observation Oversizing — 30개 시스템의 데이터가 합쳐지면 어떤 context window도 넘친다. Lost in the Middle — 정작 중요한 정보가 중간에 묻힌다. Silent Failures — 어떤 시스템의 데이터가 누락됐는지 에러조차 나지 않는다.

계층화된 컨텍스트: QANDA의 접근

이건 전편에서 다뤘던 에이전트의 Memory(short-term, long-term, episodic)를 조직 수준으로 확장한 것이다. 개인 에이전트에는 세 종류면 충분하지만, 조직에서는 누가 어떤 Memory에 접근할 수 있는지가 추가로 정의되어야 한다.

"How We Work"를 다시 쓴다는 것

어떤 회사든 "How We Work"가 있다. 일의 cadence가 있고, 일하는 방식이 있다. 주간 보고는 월요일 아침에 올라오고, 코드 리뷰는 PR 올린 뒤 24시간 안에 하고, 디자인 시안은 Figma 링크로 공유한다. 어떤 건 명시적이고, 어떤 건 암묵지다. 오래 일한 사람일수록 "그냥 아는" 것들이 많다.

에이전트로 업무를 자동화한다는 건, 이 How We Work를 처음부터 다시 쓴다는 뜻이다.

에이전트는 암묵지를 모른다. "그냥 아는" 게 없다. 에이전트들이 어떻게 일할지, 에이전트 간 협업은 어떻게 할지, 인간과 로컬 에이전트와 서버 에이전트는 어떤 구조로 상호작용할지, 결과물의 품질은 어떻게 보장할지 — 이 모든 것을 명시적으로 설계해야 한다. 사람 사이에서는 "알아서 하는" 것들이, 에이전트 사이에서는 전부 코드나 규칙으로 정의되어야 하는 것이다.

예상 밖의 난관: 직군의 경계가 허물어진다

QANDA에서 실제로 부딪힌 일이다. 디자이너가 Figma에서 시안을 만들고, 프론트엔드 개발자가 그걸 코드로 옮기는 — 이 당연한 워크플로우가 흔들렸다. 에이전트가 프론트엔드 코드를 바로 만들 수 있으니까, "Figma를 꼭 거쳐야 하나?"라는 질문이 나왔다. 작동하는 프로토타입으로 커뮤니케이션하는 게 시안 파일보다 빠를 수 있다.

PM과 PD의 경계가 허물어졌다. 기획자가 직접 프로토타입을 만들고, 디자이너가 에이전트로 코드를 작성하고, 개발자가 제품 의사결정에 더 깊이 관여한다. 기존에는 각 직군이 자기 파트의 일부 작업을 완수하는 사람이었다면, 이제는 모두가 Builder가 되어 end-to-end 비즈니스 결과물을 낸다. 기획자가 마케팅 영상까지 만들고, 디자이너가 작동하는 프로덕트를 내놓는다. 다만 각자가 원래 가지고 있던 전문 도메인 — 디자인 원칙, 엔지니어링 품질, 제품 판단력 — 은 harness layer에 기여하는 방식으로 살아남는다. 개인의 전문성이 사라지는 게 아니라, 그 전문성이 에이전트가 따르는 규칙으로 변환되는 것이다.

이게 개인 AX와 결정적으로 다른 지점이다. 개인은 자기 시스템을 자기가 개선하면 된다. 합의가 필요 없다. 조직에서는 모두가 쓰는 에이전트 시스템에 기여해야 하고, 그러려면 합의된 룰이 필요하다. harness에 새 skill을 추가하는 규칙, 컨벤션을 변경하는 프로세스, 품질 게이트의 기준을 조정하는 권한 — 이런 것들이 정의되지 않으면 모두가 어디에 기여할지조차 정할 수 없다.중앙화된 설계 팀이 필수인 이유다.

Karpathy가 올해 "99%의 시간을 에이전트 오케스트레이션에 쓴다"고 한 건, 그가 자기 워크플로우를 자기가 재설계할 수 있기 때문이다. 개인에겐 자연스러운 진화다.

조직에서 How We Work를 바꾸는 건 기술이 아니라 정치다. 마케팅팀 주간 보고 하나만 자동화하려 해도 — 데이터팀 파이프라인, 경영진 기대 형식, QA 프로세스, 담당자 역할 — 4개 팀이 동시에 바뀌어야 한다. 각 팀에는 현재 방식을 유지하고 싶은 인센티브가 있다.

이게 top-down으로 밀어야 하는 이유다. QANDA에서 올해 초 전사 AX를 할 수 있었던 이유는 하나다. CEO가 직접 기술을 이해하고, 조직의 How We Work를 새로 설계하고, 실행까지 밀어붙였다. "에이전트가 이 워크플로우를 따른다. 이 컨벤션을 지킨다. 이 품질 게이트를 통과해야 다음 단계로 간다." — 이 결정이 한 사람의 머리에서 나왔고, 그래서 빠르게 실행됐다.

대부분의 중규모 이상 조직에서 이건 쉽지 않다. CEO가 MCP와 Context Memory를 이해하지 못하면 에이전트 아키텍처를 잡을 수 없고, CTO에게 맡기면 기술 최적화만 되고 업무 프로세스는 안 바뀌고, COO에게 맡기면 프로세스는 바뀌지만 기술적 일관성이 없다. 가장 흔한 결과는 각 부서가 따로따로 AI를 도입해서 호환되지 않는 에이전트 섬들이 만들어지는 것이다.

보안: 에이전트 하나가 뚫리면 blast radius는 어디까지인가

1인 기업에서 에이전트가 내 데이터를 읽으면 — 상관없다. 내 데이터니까. 100명 기업에서 같은 일이 일어나면 법적 책임이다.

전편에서 다뤘던 prompt injection과 indirect injection이 조직 수준에서는 완전히 다른 위험이 된다. 고객 개인정보 유출은 GDPR 위반이고, 재무 데이터 접근은 내부자 정보 문제이며, 영업 기밀 학습은 경쟁사 유출로 이어질 수 있다.

개인 / 소규모 / 대규모 AX — 무엇이 다른가

Phase transition이 두 번 일어난다. 첫 번째는 소규모에서 중규모(100인+)로 넘어갈 때 — CLAUDE.md만으로 안 되고 워크플로우+컨벤션+품질 게이트를 통합한 harness 시스템이 필요해지는 지점이다. 우리가 Wizard로 풀고 있는 구간이다.

두 번째는 1,000인을 넘어설 때다. 여기서부터 문제의 성격이 근본적으로 달라진다. 법인체가 다르다. 한국 법인과 베트남 법인이 같은 에이전트 시스템을 쓸 수 없다 — 적용받는 개인정보보호법이 다르고, 데이터 국외이전 규제가 다르고, 감사 기준이 다르다. 기술 아키텍처가 아니라 법률 아키텍처가 설계의 제약 조건이 된다. 중규모까지는 "어떻게 설계할까"의 문제지만, 대규모에서는 "설계할 수 있는 범위가 어디까지인가"의 문제다.

조직 AX를 시작하려면

QANDA에서 내부 AX를 설계하고, 대기업 현장에 들어가서 같은 일을 하면서 반복적으로 확인한 패턴이 있다.

지난주 AX 컨퍼런스에서 발표를 하고, 매주 AX 스터디를 하고, 베이에리어에 있는 팀들과 최신 동향을 나누고 있다. 솔직히 말하면, 10인 이상 규모에서 harness 수준의 AX를 실전으로 풀고 있는 팀은 아직 많지 않다. 대부분 "에이전트 도입했다"에서 멈춰 있거나, 개인 생산성 도구 수준에 머물러 있다.

에이전트를 만드는 건 2시간이면 된다. 조직의 How We Work를 에이전트 시대에 맞게 다시 쓰는 건 — 그 회사의 업무를 이해하고, 기술을 알고, 사람의 역할이 어떻게 바뀌어야 하는지 아는 누군가가 파고들어야 하는 일이다.

QANDA AX의 AI 업무 통합 서비스가 하는 일이 정확히 그것이다. Custom MCP 서버를 구축하고, 사내 시스템과 AI를 연결하고, 조직에 맞는 에이전트 아키텍처 — harness — 를 설계한다. 동시에 AI Literacy 교육으로 구성원이 "에이전트와 함께 일하는 방법"을 익히게 한다. PM이 harness에 기여하고, 디자이너가 품질 게이트를 정의하고, 개발자가 워크플로우를 설계하는 — 그런 조직을 만드는 것이다. 도구만 납품하면 Klarna가 된다. How We Work의 재설계와 교육이 함께 가야 한다.