coredot.today
미션 팟(Mission Pod): 조직도에 AI를 올린 회사들 — 가장 빠른 AI 퍼스트 기업의 구조 해부
블로그로 돌아가기
미션팟MissionPodAI퍼스트조직설계NFX에이전트멀티에이전트eval평가문화팀토폴로지콘웨이의법칙거래비용이론스타트업조직문화생산성

미션 팟(Mission Pod): 조직도에 AI를 올린 회사들 — 가장 빠른 AI 퍼스트 기업의 구조 해부

NFX의 Gigi Levy-Weiss가 던진 '미션 팟(Mission Pod)'이 화제다. 0→1은 풀렸고 이제 병목은 1→2다. 왜 지금 조직도를 다시 그려야 하는가? 애덤 스미스의 분업과 코즈의 거래비용이론, 콘웨이의 법칙과 브룩스의 n(n−1)/2, 아마존 두 판의 피자 팀과 Team Topologies까지 250년의 계보를 따라가고, ChatDev·MetaGPT·AutoGen 같은 멀티에이전트 논문의 아키텍처를 그림과 함께 뜯어본다. METR의 39%p 인식 격차, 스탠퍼드의 주니어 13% 감소, Klarna의 되돌리기, Shopify 메모, 그리고 Cursor·Midjourney·Base44의 숫자까지 — 인터랙티브 도구 4종과 함께 읽는 특집.

코어닷투데이2026-08-0886

미션 팟 — 성과 중심으로 다시 그린 조직도. 사람과 에이전트가 하나의 목표를 둘러싸고 앉는다크게 보기

들어가며: 조직도에 없는 팀원

한 회사의 조직도를 상상해 보자. 대표가 맨 위에 있고, 그 아래로 기획팀·디자인팀·개발팀·마케팅팀이 늘어선다. 각 상자에는 사람 이름이 적혀 있다. 아주 익숙한 그림이다. 1911년 프레더릭 테일러가 『과학적 관리법』을 낸 이후로 100년 넘게, 회사라는 것은 대체로 이렇게 생겼다.

그런데 2026년의 어떤 회사들에서는 이 그림이 이상해졌다. 매일 아침 코드를 짜고, 고객 문의에 답하고, 경쟁사를 조사하고, 리포트를 쓰는 가장 바쁜 구성원 중 상당수가 조직도에 없다. 그들은 사람이 아니다. 계정이 있고, 권한이 있고, 담당 업무가 있고, 실수를 하면 누군가 책임을 져야 하는데도, 조직도에는 자리가 없다.

2026년 7월, 실리콘밸리의 시드 단계 투자사 NFX의 제너럴 파트너 Gigi Levy-Weiss가 「How The Fastest AI-First Companies Really Work(가장 빠른 AI 퍼스트 회사들은 실제로 어떻게 일하는가)」라는 글을 올렸다. 첫 문장은 이렇게 시작한다.

"'세 명짜리 유니콘' 실험은 이제 3년째다. 우리 포트폴리오를 포함해 수백 개 회사에서. 다들 헤드라인은 안다 — 작은 팀, 빠른 실행. 그런데 구조를 제대로 잡은 회사와 그렇지 못한 회사 사이의 격차는 여전히 어마어마하다."

이 글이 화제가 된 이유는 단순하다. 지난 3년간 모두가 "AI 쓰면 적은 인원으로 크게 할 수 있다"는 말을 들었지만, 정작 어떻게 조직을 짜야 하는지에 대해서는 아무도 구체적으로 말해 주지 않았기 때문이다. 그래서 대부분의 회사는 2015년식 조직도에 AI 구독을 얹었고, 그 결과 도구는 잔뜩 쌓였는데 제품은 그저 그렇고 속도는 나지 않는 상태가 되었다.

Levy-Weiss는 그 대안으로 하나의 구조를 제시한다. 미션 팟(Mission Pod)이다.

이 글에서 우리는 이 개념을 그냥 요약하지 않는다. 왜 이런 개념이 나왔는지 — 애덤 스미스의 핀 공장부터 로널드 코즈의 거래비용이론, 콘웨이의 법칙과 브룩스의 법칙, 아마존의 두 판의 피자 팀과 Team Topologies까지 250년의 계보를 따라가고, 에이전트를 조직도에 올린다는 게 기술적으로 무슨 뜻인지 ChatDev·MetaGPT·AutoGen 같은 논문의 아키텍처를 그림과 함께 뜯어보고, 실제 숫자와 사례로 왜 이게 중요한지 확인한다. 그리고 마지막에는 반론까지 정직하게 다룬다.

직접 만져 볼 수 있는 인터랙티브 도구도 네 개 준비했다. 조정비용을 손으로 계산해 보고, 우리 팀의 사람·AI 배치도를 직접 그려 보고, 학습 속도와 체감 속도의 격차를 재 보고, 마지막엔 우리 조직의 준비도를 진단해 볼 수 있다.

TL;DR — AI는 0→1(만들기) 문제를 풀었다. 새 병목은 1→2(프로토타입 → 배포 → 학습 → 반복)다. 이기는 구조는 직무가 아니라 성과를 중심으로 묶인 교차기능 팟이고, 그 팟 안에서 에이전트는 도구가 아니라 팀원으로 배치된다. 다섯 가지 원칙(생성적 인재·에이전트 조직도·"AI가 할 수 있나?"·평가 문화·전원 고객 접점)과 다섯 가지 함정(소통 못 하는 IC·잘못된 속도 측정·토큰맥싱·주니어 미채용·저(低)구축을 린으로 착각). 대원칙은 하나 — AI 퍼스트는 AI 온리가 아니다.


1장. 0→1은 풀렸다. 이제 1→2가 병목이다

만들기는 풀렸고, 검증이 새로운 병목이 되었다크게 보기

1-1. 옛 조직도가 풀려던 문제

Levy-Weiss의 논지는 아주 명확한 관찰에서 출발한다.

"옛날 조직도 — 기획·디자인·개발·지원이 각각 부서로 나뉘고 그 사이에 중간관리자가 있는 구조 — 는 제품을 존재하게 만드는 것이 가장 어려운 일이던 세상을 위해 설계됐다. 그건 0에서 1로 가기 위한 설계였다."

이 말을 이해하려면 2015년의 스타트업을 떠올려 보면 된다. 그때 "앱 하나 만들자"는 말은 이런 뜻이었다. 기획자가 요구사항을 정리하고(2주), 디자이너가 화면을 그리고(3주), 개발자가 구현하고(8주), QA가 테스트하고(2주), 그제야 출시. 각 단계에는 전문성이 필요했고, 전문성은 희소했고, 그래서 회사는 전문성을 부서로 묶어서 보관했다.

이 구조는 합리적이었다. 만드는 것 자체가 어려웠으니까.

1-2. 그런데 만드는 게 쉬워졌다

2026년에 그 8주짜리 구현은 종종 하룻밤이 된다. 디자인 초안 3주는 30분이 된다. Levy-Weiss의 표현을 빌리면 이렇다.

"AI가 그 문제를 풀었다. 인류 역사상 빈 화면을 채우는 게 이렇게 쉬웠던 적이 없다."

문제는, 병목이 사라진 게 아니라 옮겨 갔다는 것이다.

아이디어
거의 무한
프로토타입
몇 시간
배포 · 검증
여전히 몇 주
학습
가장 느린 구간
앞 두 칸만 100배 빨라졌다 — 전체 속도는 뒤 두 칸이 결정한다

앞의 두 칸이 100배 빨라졌는데 뒤의 두 칸이 그대로면, 전체 속도는 거의 그대로다. 이건 컴퓨터 구조에서 말하는 암달의 법칙(Amdahl's Law)과 정확히 같은 이야기다. 전체 작업 중 20%만 무한히 빠르게 만들어도 최대 개선은 1.25배에 그친다.

개념 정리 — 0→1과 1→2

  • 0→1: 존재하지 않던 것을 존재하게 만드는 일. 빈 화면 채우기, 첫 프로토타입, MVP.
  • 1→2: 존재하는 것을 실제 고객에게 내보내고, 결과를 측정하고, 다음 버전을 만드는 일. 이 사이클을 몇 번 도느냐가 회사가 얼마나 빨리 똑똑해지는지를 결정한다. 지금 대부분의 회사는 0→1에만 AI를 붙여 놓고, 회사 전체가 빨라졌다고 느끼고 있다.

1-3. "출시 전 연옥"

Levy-Weiss가 붙인 이름이 있다. pre-launch purgatory(출시 전 연옥).

"비효율적인 AI 기반 회사들은 출시 전 연옥에 갇힌다. AI 덕분에 뭐든 시도해 보기가 너무 쉬워져서, 제품을 내보내고 실제 고객 데이터가 판단하게 하는 대신 AI에게 '이 제품 괜찮아?'라고 물어보고 싶은 유혹에 빠진다."

이 문장은 뼈아프다. 프로토타입을 다섯 개 만들고, AI에게 각각 평가를 시키고, 또 세 개를 만들고, 다시 평가를 시키고… 한 달이 지났는데 실제 고객은 아직 아무것도 못 봤다. 회사는 굉장히 바빴지만 아무것도 배우지 못했다.

이 관찰은 데이터로도 뒷받침된다. 2025년 DORA(State of DevOps) 리포트는 응답자의 90%가 업무에 AI를 쓰고 있고, AI 도입이 소프트웨어 전달 처리량과 뚜렷한 양(+)의 상관을 보인다고 보고했다. 동시에 AI 도입은 불안정성과도 양의 상관을 보였다 — 변경 실패가 늘고, 재작업이 늘고, 문제 해결까지의 시간이 길어졌다. DORA는 AI를 증폭기(amplifier)로 규정했다. 잘하는 조직은 더 잘하게, 망가진 조직은 더 빨리 망가지게 만든다는 뜻이다.

정리하면 이렇다. AI는 생산 능력을 올렸지, 검증 능력을 올려 주지 않았다. 그리고 조직 구조란 결국 그 검증 능력이 어디에 있는지를 정하는 일이다.


2장. [역사] 조직도는 왜 지금 이 모양이 되었나 — 250년의 계보

조직도의 250년 — 분업, 기능 조직, 두 판의 피자 팀, 그리고 미션 팟크게 보기

미션 팟은 하늘에서 떨어진 개념이 아니다. 조직 설계에는 250년 된 논쟁의 계보가 있고, 미션 팟은 그 계보의 가장 최근 항목이다. 이 계보를 알면 "왜 하필 지금 이 형태인가"가 훨씬 선명해진다.

2-1. 1776, 애덤 스미스 — 분업의 발견

『국부론』 1장, 애덤 스미스는 핀 공장 이야기를 한다. 한 사람이 핀을 처음부터 끝까지 만들면 하루에 20개도 못 만든다. 그런데 철사 뽑기, 자르기, 뾰족하게 갈기, 머리 붙이기로 18개 공정을 나눠 10명이 분담하면 하루 48,000개를 만든다. 1인당 4,800개. 240배.

여기서 조직 설계의 첫 번째 원리가 나온다. 전문화(specialization)는 처리량을 폭발적으로 늘린다. 지난 250년간 우리가 회사를 직무별로 나눈 이유의 뿌리가 여기다.

하지만 스미스는 같은 책에서 이미 비용도 지적했다. 평생 핀의 머리만 붙이는 사람은 "인간으로서 될 수 있는 만큼 어리석고 무지해진다"고. 전문화의 대가는 전체를 보지 못하는 것이다. 이 긴장이 250년 뒤 미션 팟 논의의 핵심으로 다시 돌아온다.

2-2. 1937, 로널드 코즈 — 회사는 애초에 왜 존재하는가

여기가 이 글 전체의 이론적 심장이다. 1937년, 26살의 경제학자 로널드 코즈는 「기업의 본질(The Nature of the Firm)」이라는 논문에서 이상한 질문을 던졌다.

시장이 그렇게 효율적이라면, 왜 사람들은 회사에 모여서 일하는가? 필요할 때마다 시장에서 사람을 구해 계약하면 되지 않나?

코즈의 답은 거래비용(transaction cost)이었다. 시장에서 무언가를 구할 때는 눈에 보이지 않는 비용이 든다. 누가 잘하는지 찾는 비용(탐색), 조건을 정하는 비용(협상), 약속을 지키게 만드는 비용(집행). 이 비용이 사내에서 사람을 고용해 지시하는 비용보다 크면, 사람들은 회사를 만든다.

그리고 코즈는 회사의 크기에 대해서도 답했다. 회사가 커질수록 내부 조정비용(회의, 보고, 승인, 정치)이 늘어난다. 회사는 "한 건의 거래를 사내에서 처리하는 비용"이 "시장에서 처리하는 비용"과 같아지는 지점에서 성장을 멈춘다.

이 프레임으로 보면 2026년에 벌어지는 일이 아주 선명해진다.

?
코즈의 질문
회사의 최적 크기는 내부 조정비용과 시장 거래비용이 만나는 지점에서 결정된다.
AI
AI가 바꾼 변수
AI는 사내 조정비용을 극적으로 낮춘다. 디자이너에게 요청서를 쓰고 기다릴 필요 없이 개발자가 직접 시안을 뽑는다. 리서치를 외주 줄 필요 없이 에이전트가 하룻밤에 훑는다.
따라서
같은 매출을 내는 데 필요한 사람 수와 부서 수가 줄어든다. 세 명짜리 유니콘은 마법이 아니라 코즈 방정식의 변수가 하나 바뀐 결과다.

미션 팟은 결국 이 질문에 대한 실무적 답이다. 조정비용을 어디에 둘 것인가? 부서와 부서 사이(느리고 비싸다)가 아니라, 팟 안(즉시 해결된다)에 두자는 것.

2-3. 1911~1962, 테일러와 챈들러 — 기능 조직의 완성

프레더릭 테일러의 『과학적 관리법』(1911)은 스미스의 분업을 측정 가능한 시스템으로 만들었다. 시간 연구, 표준 작업, 계획하는 사람과 실행하는 사람의 분리. 알프레드 챈들러의 『전략과 구조』(1962)는 여기에 사업부제(M-form)를 얹어 GM과 듀폰 같은 거대 기업의 조직도를 완성했다.

이 시기의 핵심 가정은 "정보는 위로 올라가고 결정은 아래로 내려온다"였다. 정보를 모으고 판단하는 비용이 비쌌기 때문에, 소수의 사람에게 몰아서 처리하는 게 합리적이었다. 이 가정은 정확히 2026년에 무너지는 중이다.

2-4. 1968·1975, 콘웨이와 브룩스 — 조직이 곧 아키텍처

두 개의 유명한 법칙이 소프트웨어 조직 설계를 지배한다.

콘웨이의 법칙(1968) — 멜빈 콘웨이는 이렇게 썼다.

"시스템을 설계하는 조직은, 그 조직의 커뮤니케이션 구조를 그대로 복제한 설계를 만들어낼 수밖에 없다."

프론트엔드팀과 백엔드팀을 나눠 두면, 프론트엔드와 백엔드가 분리된 시스템이 나온다. 4개 부서가 만든 컴파일러는 4단계 컴파일러가 된다. 조직도는 청사진의 초안이다.

브룩스의 법칙(1975) — 프레드 브룩스는 IBM System/360 프로젝트의 실패를 복기하며 『맨먼스 미신』을 썼다. 핵심 공식은 이거다. n명이 있으면 소통 경로는 n(n−1)/2개.

팀 인원과 소통 경로 수 — n(n−1)/2
5명
10개
한눈에 파악
10명
45개
아직 괜찮다
15명
105개
구조가 필요
20명
190개
쪼개야 한다
25명
300개
전원 정렬 불가

인원은 5배 늘었는데 소통 경로는 30배 늘었다. 그래서 브룩스의 결론은 유명하다. "늦어진 프로젝트에 인력을 추가하면 더 늦어진다."

이 두 법칙을 합치면 이런 명제가 나온다. 조직을 어떻게 나누느냐가 곧 제품이 어떻게 생길지, 그리고 얼마나 빨리 나올지를 결정한다. 미션 팟은 이 명제를 정면으로 받아들인 설계다.

2-5. 1992~2012, 던바·아마존·스포티파이 — 작은 팀의 시대

  • 던바의 수(1992): 인류학자 로빈 던바는 영장류의 대뇌 신피질 크기와 집단 크기의 상관에서, 인간이 안정적 사회 관계를 유지할 수 있는 한계를 약 150명으로 추정했다. 그 안에도 층위가 있어서, 깊게 신뢰하는 핵심 집단은 5명 안팎이다.
  • 아마존의 두 판의 피자 팀(2002): 제프 베조스는 팀 크기를 "피자 두 판으로 식사가 되는 규모"로 제한했다. 같은 해 나온 것이 그 유명한 API 명령(API Mandate)이다 — 모든 팀은 서비스 인터페이스를 통해서만 데이터와 기능을 주고받아야 하고, 예외는 없으며, 따르지 않으면 해고. 이건 콘웨이의 법칙을 역이용한 조치였다. 조직 간 통신 규약을 강제해서 아키텍처를 만들어낸 것이다.
  • 스포티파이 모델(2012): 스쿼드(Squad)·트라이브(Tribe)·챕터(Chapter)·길드(Guild). 전 세계가 이 그림을 따라 그렸다. 그런데 정작 스포티파이 내부의 코치들은 나중에 "우리도 그렇게 일한 적 없다"고 밝혔다. 이건 아주 중요한 경고다. 조직 모델은 복사해서 붙여넣는 순간 카고 컬트가 된다.

2-6. 2019, Team Topologies — 직전 세대의 정답

Matthew Skelton과 Manuel Pais의 『Team Topologies』는 콘웨이의 법칙과 인지 부하 이론을 결합해 네 가지 팀 유형을 제시했다. 그중 주인공은 스트림 정렬 팀(stream-aligned team) — 하나의 가치 흐름(제품, 서비스, 사용자 여정)에 정렬된 교차기능 팀이고, 나머지 세 유형(플랫폼·활성화·복잡 하위시스템)은 오직 스트림 정렬 팀의 인지 부하를 줄여 주기 위해 존재한다.

핵심 개념 두 가지를 짚고 가자.

인지 부하(cognitive load) — 한 팀이 머릿속에 동시에 담을 수 있는 것에는 한계가 있다. 담당 영역이 넓어지면 팀은 느려지는 게 아니라 얕아진다. 그래서 좋은 조직 설계란 팀에게 "감당 가능한 크기의 문제"를 주는 일이다.

역콘웨이 기동(Inverse Conway Maneuver) — 콘웨이의 법칙이 "조직 → 아키텍처"라면, 이걸 뒤집어서 원하는 아키텍처를 먼저 정하고 그에 맞게 팀을 재배치하는 전략이다. 아마존의 API 명령이 대표 사례.

2-7. 그래서 미션 팟은 계보의 어디에 있나

시대묶는 기준해결하려던 문제한계
기능 조직
1911~
직무(전문성)희소한 전문성을 효율적으로 활용부서 간 핸드오프마다 대기·오해·책임 회피
두 판의 피자 팀
2002~
서비스(소유권)팀 간 의존을 API로 규격화서비스는 나눴지만 여전히 직무별 역할 분담
스쿼드 모델
2012~
기능 영역자율성과 속도복사된 형식만 남고 원리는 사라짐
스트림 정렬 팀
2019~
가치 흐름인지 부하 관리, 흐름 최적화팀 구성은 여전히 100% 사람
미션 팟
2026~
성과(outcome)학습 사이클 최소화 + 사람·AI 혼성 편성검증되기엔 아직 이르다

미션 팟이 이전 세대와 결정적으로 다른 점은 하나다. 팀의 구성원이 더 이상 사람만이 아니라는 것. 스트림 정렬 팀까지는 "사람을 어떻게 묶을 것인가"의 문제였다면, 미션 팟은 "사람과 에이전트를 어떻게 함께 묶을 것인가"의 문제다.

직접 만져 보기 — 조정비용 실험실

같은 인원이라도 어떻게 묶느냐에 따라 소통 경로와 핸드오프 대기가 얼마나 달라지는지, 브룩스의 공식을 직접 돌려 보자.

여기서 반드시 짚어야 할 반직관적 사실이 하나 있다. 미션 팟으로 바꾼다고 소통 경로 총합이 극적으로 줄지는 않는다. 달라지는 건 그 경로가 어디에 있느냐다. 팟 안의 경로는 옆자리에서 30초에 해결되고, 부서 사이의 경로는 티켓·회의·오해·2주가 된다. 코즈의 언어로 다시 말하면, 조직 설계란 조정비용의 총량을 줄이는 일이 아니라 값싼 곳으로 옮기는 일이다.


3장. 미션 팟의 해부학

기능 조직의 릴레이 vs 미션 팟의 순환크게 보기

3-1. 정의부터

Levy-Weiss의 정의는 짧다.

"직무가 아니라 성과를 중심으로 팀을 조직하라 — 고객 문제 해결, 제품 표면 하나의 완성, 매출 목표 달성. 각 팟은 그 성과를 완전히 소유한다. 고객을 이해하고, 프로토타입을 만들고, 배포하고, 측정하고, 반복한다. 다른 부서를 기다리지 않고."

여기서 세 단어가 중요하다.

  • 성과(outcome): "디자인팀"이 아니라 "온보딩 이탈률 팟". "개발팀"이 아니라 "결제 전환 팟". 팟의 이름은 직무가 아니라 바꾸려는 숫자다.
  • 완전히(entirely): 팟 안에서 끝나야 한다. 승인 한 번, 티켓 한 장이라도 밖으로 나가면 그건 팟이 아니다.
  • 기다리지 않고(without waiting): 대기 시간이 0에 수렴해야 한다. 학습 사이클의 대부분은 일하는 시간이 아니라 기다리는 시간이다.

3-2. 팟 안에서는 무슨 일이 벌어지나

"팟 안에서 목표는 무슨 수단을 쓰든 문제를 푸는 것이다 — 제품, 세일즈, 마케팅, 전부. 세 명짜리 유니콘 모델에서처럼 도메인 전문가는 여전히 있겠지만, 모두가 기능 경계를 유동적으로 넘나들며 자기 기술과 이해의 빈틈을 AI로 메운다."

이게 핵심 메커니즘이다. 예전에는 "나는 백엔드 개발자니까 디자인은 못 해"가 정당한 말이었다. 지금은 그 문장이 "나는 디자인 도구를 쓸 줄 모른다"로 축소된다. AI가 개인의 역량 경계를 흐리면, 조직의 부서 경계는 존재 이유를 잃는다.

3-3. 팟의 구조도

미션 팟
성과 하나를 완전히 소유
예: "신규 사용자 7일 리텐션 40% → 55%"
사람 3~6명
생성적 + 소통 능력
도메인 전문성은 있되 경계는 유동적
에이전트 N개
이름·범위·책임자 지정
리서치, 코드, 데이터, 1차 응대
평가 루프
무엇이 '내보낼 만한가'
골든셋 · 자동 채점 · 사람 스팟체크
고객 파이프
원본 데이터 직접 접근
인터뷰 · 세션 리플레이 · VoC 원문

이 네 요소 중 하나라도 빠지면 팟이 아니다. 특히 자주 빠지는 게 뒤의 두 개다. 사람과 에이전트만 있고 평가 루프와 고객 파이프가 없는 팀은, 빠르게 잘못된 방향으로 달려가는 팀이 된다.

3-4. 기능 조직과의 실제 차이

항목기능 조직미션 팟
팀 이름디자인팀, 개발팀, 그로스팀온보딩 팟, 결제 팟, 리텐션 팟
성공 정의각 부서의 산출물 완료하나의 지표 이동
핸드오프기능당 6~8회 (왕복 포함)0회
고객 접점PM과 CS만전원
AI의 위치개인이 각자 쓰는 도구팟에 배정된 팀원
병목부서 간 대기열검증 대역폭
실패 양상느리지만 예측 가능빠르지만 기준 없으면 슬롭 생산

마지막 줄이 중요하다. 미션 팟은 만병통치약이 아니라 다른 실패 양상을 가진 다른 구조다. 기능 조직의 실패가 "아무것도 안 나온다"라면, 미션 팟의 실패는 "나쁜 게 잔뜩 나온다"다. 그래서 평가 문화가 선택이 아니라 필수인 것이다.


4장. 다섯 가지 원칙 — 하나씩 깊게

Levy-Weiss는 미션 팟을 만드는 다섯 가지 기본 원칙(cardinal rules)을 제시한다. 하나씩, 왜 그런지까지 파고들어 보자.

원칙 1. 생성적인 사람을, 소통 능력과 함께 뽑아라

"팀의 모든 사람은 완전히 새로운 산출물을 만들어낼 수 있어야 한다. 무언가를 만들어 본 이력이 있어야 한다. 산출물을 내놓지 못하는 사람을 위한 자리는 없다. 특히 산출물을 만들기가 그 어느 때보다 쉬워진 AI 시대에는."

"하지만 결정적으로, 그건 1번일 뿐이다. 핵심은 당신의 빌더들이 결과를 다듬고, 피드백을 받고, 소통할 줄 알아야 한다는 것이다. 자아는 낮게, EQ는 높게, 팀 플레이어로."

여기서 "생성적(generative)"이라는 단어에 주목하자. 이건 "코딩을 할 줄 안다"가 아니라 "백지에서 무언가를 완성해 본 적 있다"는 뜻이다. 개발자든 마케터든 디자이너든, 누군가가 시킨 것만 처리해 온 사람과 스스로 만들어낸 사람은 AI 시대에 완전히 다른 궤적을 그린다. 왜냐하면 AI는 지시를 실행하는 능력을 상품화했기 때문이다. 남는 것은 무엇을 지시할지 아는 능력이다.

NFX는 이런 팀의 작동 방식에 이름을 붙였다 — 1,000 Simultaneous Experiments(천 개의 동시 실험) 접근법. 하나의 큰 베팅이 아니라, 수많은 작은 시도를 동시에 굴리고 살아남는 걸 키우는 방식이다.

그런데 왜 소통이 그렇게 중요할까? 앞에서 본 브룩스의 공식으로 돌아가 보자. AI가 개인의 처리량을 5배로 만들면, 그 사람이 만들어내는 정보량도 5배가 된다. 소통 경로의 수는 그대로인데 각 경로를 통과해야 하는 정보가 5배가 되면, 소통 능력이 떨어지는 사람은 병목이 아니라 정보 블랙홀이 된다. 혼자서 빠르게 많이 만들고, 아무도 그게 뭔지 모른다.

원칙 2. 에이전트도 조직도에 올려라

에이전트도 조직도에 — 사람, AI, 사람 검토를 색으로 구분한 명패크게 보기

"AI를 소프트웨어라고 생각하는 걸 멈춰라. 에이전트를 팀원이라고 생각하고, 그에 맞게 일을 배정하라."

"모든 팀은 어떤 일이 사람에 의해, 어떤 일이 AI에 의해, 어떤 일이 사람 검토를 거쳐 이뤄지는지 정확히 말할 수 있어야 한다. 그 지도가 없다면, 당신은 AI 네이티브 조직을 가진 게 아니라 구독료를 내는 사람들을 가진 것이다."

마지막 문장이 이 글 전체에서 가장 많이 인용된 대목이다. 그리고 여기서부터가 이 특집에서 가장 깊게 파고들 아키텍처 부분이다.

4-2-1. 논문에서 먼저 벌어진 일 — AI가 회사를 흉내 내기 시작했다

재밌는 사실이 있다. "에이전트를 조직도에 올린다"는 발상은 사실 경영이 아니라 논문에서 먼저 나왔다. 2023년, 여러 연구팀이 거의 동시에 같은 아이디어에 도달했다. LLM 여러 개에 서로 다른 직책을 주고 회사처럼 일하게 만들면 어떨까?

프레임워크핵심 발상조직 비유남긴 교훈
CAMEL
Li et al., 2023
두 에이전트에게 역할극(role-playing)을 시키고 대화로 과제를 풀게 함 (AI 유저 ↔ AI 어시스턴트)2인 페어 워크역할을 주는 것만으로 협업이 구조화된다
ChatDev
Qian et al., 2023
설계·코딩·테스트 3단계를 채팅 체인(chat chain)으로 쪼개, CEO·CTO·프로그래머·리뷰어·테스터가 다중 턴 대화로 진행워터폴 소프트웨어 회사자유로운 대화는 표류한다. 단계 정의가 필요
MetaGPT
Hong et al., ICLR 2024
인간 조직의 표준운영절차(SOP)를 프롬프트 시퀀스로 인코딩. PM·아키텍트·엔지니어·QA가 산출물(PRD·설계도·코드)을 주고받는 조립라인 방식SOP를 갖춘 성숙한 회사대화가 아니라 문서를 주고받게 하면 오류가 줄어든다
AutoGen
Wu et al., 2023 (Microsoft)
대화 가능한 에이전트들을 유연한 대화 패턴으로 조합. 사람이 루프 안에 들어올 자리를 명시적으로 설계사람이 섞인 혼성 팀사람 검토 지점을 아키텍처에 명시해야 한다

이 흐름에서 배울 점이 명확하다. MetaGPT의 기여를 이해하면 왜 실무에서 "지도"가 필요한지가 보인다. ChatDev처럼 에이전트들끼리 자유롭게 대화하게 두면, 대화가 길어질수록 원래 목표에서 멀어지고 환각이 누적된다. MetaGPT는 이 문제를 인간 조직이 이미 푼 방식으로 풀었다. 사람 회사도 "다 같이 계속 대화"로 일하지 않는다. 기획서를 쓰고, 설계 문서를 넘기고, 코드 리뷰 코멘트를 남긴다. 구조화된 산출물이 대화보다 오해를 덜 만든다.

쉬운 비유 — 카톡 단톡방에서 100번 대화하며 프로젝트를 진행하는 팀과, 기획서 → 설계서 → PR 순서로 문서를 넘기는 팀을 상상해 보자. 후자가 느려 보이지만, 다시 읽을 수 있고 어디서 틀렸는지 짚을 수 있다. MetaGPT가 발견한 게 정확히 이거다.

4-2-2. 2026년의 실전 아키텍처 — 오케스트레이터와 워커

논문의 발상이 실전으로 넘어오면서 가장 널리 쓰이는 형태로 수렴한 것이 오케스트레이터–워커(orchestrator-worker) 패턴이다. Anthropic이 자사 리서치 기능의 구조를 공개하면서 널리 알려졌다.

리드 에이전트(오케스트레이터)
문제를 쪼개고, 몇 명을 어디에 보낼지 계획한다
↓ 병렬로 위임
워커 A
독립 컨텍스트
자기 도구
워커 B
독립 컨텍스트
자기 도구
워커 C
독립 컨텍스트
자기 도구
↓ 결과 회수
종합 + 인용 검증
합치고, 근거를 붙이고, 모순을 잡아낸다

여기서 반드시 알아야 할 용어 두 개를 짚자.

컨텍스트 윈도(context window) — LLM이 한 번에 "머릿속에 담을 수 있는" 텍스트의 양. 사람으로 치면 작업 기억이다. 아무리 좋은 모델도 이 한계를 넘으면 앞부분을 잊는다.

왜 워커를 나누는가 — 각 워커가 자기만의 컨텍스트 윈도를 갖기 때문이다. 혼자 100개 문서를 읽으면 기억이 넘치지만, 5명이 20개씩 읽고 요약을 넘기면 들어간다. 이건 사람 팀이 일을 나누는 이유와 정확히 같다.

그런데 여기에 아주 중요한 비용이 따라온다. Anthropic이 공개한 수치에 따르면, 이 멀티에이전트 구조는 일반 채팅 대비 약 15배의 토큰을 소모한다(단일 에이전트도 채팅보다 4배가량 쓴다). 성능은 크게 올라가지만 — 그들의 내부 평가에서 단일 에이전트 대비 90% 이상 향상 — 경제성이 맞는 영역은 제한적이다. 법률 실사, 경쟁 정보 조사, 문헌 리뷰처럼 답 하나의 가치가 큰 작업에서만 정당화된다.

이 사실은 조직 설계에 직접적인 함의가 있다. 모든 업무에 멀티에이전트를 붙이는 것은 토큰맥싱이다. 어디에 붙일지 고르는 판단이 곧 조직의 실력이다. (뒤의 함정 3에서 다시 다룬다.)

4-2-3. 에이전트를 "팀원"으로 만든다는 것의 실제 의미

에이전트를 팀원으로 대우한다는 건 감성적인 표현이 아니다. 사람 팀원에게 하는 일을 똑같이 해 준다는 뜻이다.

사람 팀원에게 하는 것에이전트에게 해당하는 것2026년의 도구·규약
이름과 직책에이전트 이름 + 담당 범위 정의내부 에이전트 레지스트리
입사 시 계정과 권한 부여고유 아이덴티티 + 최소 권한Microsoft Entra Agent ID(2026.4 GA), Okta·Auth0의 비인간 아이덴티티 관리
업무 도구 접근권도구·데이터 소스 연결MCP(Model Context Protocol)
동료와의 협업에이전트 간 통신A2A(Agent-to-Agent) 프로토콜
성과 평가산출물 품질 측정eval 스위트, 골든셋, LLM-as-a-judge
사고 시 책임 소재담당 사람 지정대부분의 조직에 아직 없음
퇴사 시 계정 회수오프보딩78%가 문서화된 정책 없음

마지막 두 줄이 2026년 현재 가장 크게 벌어져 있는 구멍이다. 여러 조사에 따르면 평균적인 엔터프라이즈에서 비인간 아이덴티티(NHI)가 사람 아이덴티티보다 17배 많고, 2024→2025년 사이 44% 증가했다. 그런데 프로덕션에서 돌아가는 에이전트가 실제로 무엇을 하는지 안정적으로 파악할 방법이 없다고 답한 조직이 압도적 다수이고, 절반 이상이 이미 에이전트가 예상 범위를 벗어나 행동한 보안 사고를 겪었다.

왜 이게 조직 설계 문제인가 — 이건 보안팀만의 숙제가 아니다. "이 일은 누가 하는가"에 답할 수 없다는 것은, 책임 소재가 없다는 뜻이고, 책임 소재가 없으면 품질 관리가 불가능하다. 미션 팟이 요구하는 "지도"는 결국 거버넌스 문서이기도 하다.

MCP와 A2A에 대해 더 알고 싶다면 코어닷의 MCP 완전 이해A2A 프로토콜 가이드를 함께 읽어 보길 권한다.

직접 만져 보기 — 사람 · AI · 검토 맵 만들기

말로만 들으면 추상적이다. 12개 업무를 직접 배치해 보면, 이 지도를 그리는 일이 왜 생각보다 어렵고 또 왜 반드시 필요한지 바로 느껴진다.

원칙 3. "AI가 이걸 할 수 있나?"를 먼저 묻고, 결과를 정직하게 평가하라

"채용을 기본값으로 삼기 전에 물어라: AI가 이 일의 일부라도 할 수 있나? 이미 있는 사람이 AI와 함께 이걸 할 수 있나? 그리고 완벽하지 않더라도, 내보낼 만한 수준인가?"

"핵심은 AI가 무언가를 할 수 있다고 해서 품질이 충분하다고 가정하지 않는 것이다. 때로는 정말로 사람 전문가를 데려와야 한다."

이 원칙의 현실판이 Shopify CEO 토비 뤼트케의 2025년 4월 메모다. 유출 직전에 본인이 직접 공개한 그 메모의 제목은 「반사적 AI 사용은 이제 Shopify의 기본 기대치다」였고, 내용에는 이런 대목이 있다.

  • 인원과 자원을 더 요청하기 전에, 왜 AI로는 안 되는지를 먼저 입증해야 한다.
  • 관리자들은 스스로 물어야 한다: "자율 AI 에이전트가 이미 팀의 일부라면 이 영역은 어떤 모습일까?"
  • AI 사용에 관한 항목이 성과 평가와 동료 평가 설문에 추가된다.

이 메모는 즉각적인 벤치마크가 되었지만, 동시에 위험한 오독도 낳았다. "AI로 안 되는 걸 증명하라"가 "사람을 뽑지 마라"로 읽히면 곧바로 함정 5로 직행한다. Levy-Weiss도 이 지점을 조심스럽게 다룬다.

"당신 비즈니스의 어떤 영역에서는 이 패러다임이 통할 것이다. 모든 곳은 아니다 — 우리는 항상 슬롭을 내보내라고 말하는 게 아니다. 하지만 통할 수도 있는 중간 지대가 있다. (그리고 통하지 않는다면, 그건 무엇이 당신에게 가장 중요한지를 알려 주는 정보다.)"

그리고 저항을 다루는 방법도 함께 제시한다. "실제 성과를 만들어내는 프로세스를 자동화한 노력에 보상하라 — 허영 지표 말고." 자동화가 곧 자기 일자리를 없애는 것으로 느껴지는 조직에서는 아무도 자동화하지 않는다.

원칙 4. 평가(eval) 문화를 구축하라

양이 열 배가 되면, 기준도 열 배가 되어야 한다크게 보기

"슬롭(slop) 문제는 실재한다. 판단 없는 볼륨은 제품을 갉아먹고, 당신보다 고객이 먼저 알아챈다. AI가 콘텐츠·코드·답변을 10배로 만들어내는데 당신의 품질 기준이 그에 맞춰 확장되지 않는다면, 당신은 자기 자신의 쇠퇴를 자동화한 것이다."

이 원칙은 앞서 본 DORA 2025의 발견과 정확히 짝을 이룬다. 처리량은 올랐는데 불안정성도 올랐다는 것은, 생산 능력만 늘리고 검증 능력을 안 늘렸다는 뜻이다.

그럼 "평가 문화"란 구체적으로 뭘 갖추는 것인가? 실무에서는 대개 다음 네 층으로 정리된다.

1층
합격선 정의(rubric) — "무엇이 내보낼 만한가"를 글로 적는다. 예: "고객 응대 답변은 ① 사실 오류 없음 ② 다음 행동 명시 ③ 200자 이내." 적히지 않은 기준은 기준이 아니다.
2층
골든셋(golden set) — 정답이 확정된 대표 사례 50~300개를 고정해 둔다. 프롬프트나 모델을 바꿀 때마다 이 세트를 다시 돌려 회귀를 잡는다. 소프트웨어의 회귀 테스트와 같은 역할.
3층
자동 채점(LLM-as-a-judge) — 다른 모델에게 채점을 시켜 규모를 확보한다. 단, 채점자 자신이 편향될 수 있으므로(길고 화려한 답을 선호하는 경향 등) 사람 채점과의 일치율을 주기적으로 확인해야 한다.
4층
사람 스팟체크와 실사용 신호 — 무작위 표본을 사람이 직접 보고, 실제 고객 지표(해결률·재문의율·환불률)와 대조한다. 최종 심판은 언제나 고객이다.

슬롭(slop)이란? — 문법적으로는 멀쩡하지만 알맹이가 없는 AI 생성물. 읽으면 "틀린 건 없는데 왜 읽었지?" 싶은 그 느낌. 개별 산출물로는 판별이 애매하지만, 누적되면 브랜드 신뢰를 확실하게 갉아먹는다.

여기서 미션 팟 구조가 왜 유리한지가 드러난다. 기능 조직에서는 품질 기준이 QA팀이라는 별도 부서에 있다. 그래서 만드는 사람은 "일단 넘기고 QA가 잡겠지"라고 생각하고, 검증 대역폭이 부서 하나로 고정된다. 미션 팟에서는 기준이 팟 안에 있다. 만드는 사람이 곧 기준을 아는 사람이다.

원칙 5. 모두가 고객과 대화한다

"고객 인텔리전스는 이제 회사에서 가장 희소한 투입 자원이다."

"누구나 일주일이면 무엇이든 만들 수 있게 되면, 우위는 고객을 가장 잘 이해하는 쪽으로 간다. 엔지니어도, 디자이너도, 운영자도 고객과 직접 이야기하거나 그 데이터를 직접 분석해서 다음 수를 정해야 한다."

이 원칙은 앞의 네 개를 관통하는 논리적 귀결이다. 정리해 보자.

1
만드는 능력이 상품화되었다
누구나 일주일이면 만들 수 있다면, 만드는 능력은 더 이상 해자(moat)가 아니다.
2
남은 희소 자원은 '무엇을 만들지 아는 것'
그리고 그건 오직 고객에게서만 나온다. 시장 리포트가 아니라 실제 사람의 실제 좌절에서.
3
따라서 고객 접점을 독점하면 안 된다
PM 한 명이 고객을 만나고 나머지가 요약본을 읽는 조직은, 가장 희소한 자원의 대역폭을 한 사람으로 제한한 것이다.

역설적이게도 이건 AI가 고객 데이터 분석을 잘하기 때문에 더 중요해진다. VoC 수천 건을 요약하는 건 AI가 사람보다 낫다. 그래서 유혹이 생긴다 — "요약본만 보면 되잖아?" 하지만 요약은 이미 아는 범주로 정리된 것이다. 새로운 것은 언제나 요약에서 먼저 탈락한다. 고객이 인터뷰 중간에 짓는 표정, 말을 흐리는 지점, 화면을 헤매는 3초. 그건 요약본에 없다.


5장. 다섯 개의 함정

다섯 개의 함정 — 소통 단절, 잘못된 속도, 토큰맥싱, 끊긴 사다리, 저구축크게 보기

"대부분의 회사는 이걸 이론적으로는 다 이해한다. 그러고는 몇 가지 흔한 함정에 빠진다."

함정 1. 소통 못 하는 IC를 뽑는 것

"정론은 AI가 '순수한' 관리자의 필요를 없앴다는 것이고, 그건 대체로 맞다. 그런데 실제로 이걸 해내고 있는 사람들을 자세히 보면 패턴이 보인다."

"최고의 AI 네이티브 팀은 유연하고 자기주도적인 실험가 IC들로 채워져 있다 — 그런데 그들을 구분 짓는 특징은 동시에 최상급 커뮤니케이터라는 점이다. 프로그래머와 마케터가 둘 다 빠르게 움직이면서 서로에게 계속 상황을 공유한다."

"팀 차원의 정렬 없는 개인 차원의 속도는, 반쯤 만들다 만 출시되지 않은 작업물의 공동묘지를 만든다. 모두가 빠르다. 그런데 아무것도 라이브가 아니다."

"반쯤 만들다 만 작업물의 공동묘지"는 이 글에서 가장 그림이 잘 그려지는 표현이다. 그리고 이건 브룩스의 법칙이 새 옷을 입고 돌아온 것이기도 하다. 브룩스 시대에는 사람이 늘어서 소통 경로가 폭발했다면, 지금은 사람 수는 그대로인데 각자가 만들어내는 것이 늘어서 각 경로의 부하가 폭발한다.

IC(Individual Contributor)란 관리 책임 없이 직접 실무를 하는 사람을 말한다. AI 시대에 관리 계층이 얇아지면서 IC의 비중이 커졌는데, 이때 "혼자 잘하는 사람"만 모으면 조직이 아니라 프리랜서 집합이 된다.

함정 2. 잘못된 종류의 속도를 재는 것

"그들은 옛 패러다임의 속도를 잰다. 0에서 1로 가는 속도. 'AI로 블로그 글 쓰는 데 2분밖에 안 걸렸다'거나 '주말에 제품 하나 만들었다'는 것에 주목하면서, 그것들이 여전히 거친 초안일 뿐 실제로 내보낸 게 아니라는 사실을 놓친다."

"오늘 당신이 재야 할 것은 학습 속도다. 프로토타입에서 출시까지 얼마나 걸리는가? V1에서 V2까지는? 그 곡선은 가차 없이 가팔라지고 있어야 한다."

"그렇지 않다면 당신은 더 빨라진 게 아니다. 빠르다고 느낄 뿐이다. 생산적이라고 느낄 뿐이다. 그런데 제자리에서 바퀴만 굴리고 있다."

Levy-Weiss는 이 대목에서 Lenny Rachitsky의 설문을 인용한다. 97%가 AI 덕분에 "일을 더 잘하게 됐다"고 답했지만, 자세히 보니 대부분이 그 품질을 순수한 산출량과 속도만으로 측정하고 있었다는 것.

그리고 이 "느낌과 실제의 괴리"에는 아주 유명한 실증 연구가 있다.

METR 무작위 대조 실험 (2025.7)수치
대상숙련 오픈소스 개발자 16명, 자신이 잘 아는 성숙한 코드베이스
과제실제 이슈 246건 (버그 수정·기능·리팩터링)
사전 예상AI로 24% 빨라질 것
실제 결과AI 사용 시 19% 더 오래 걸림
사후 체감그러고도 20% 빨라졌다고 응답
인식 격차39%p

이 결과는 반드시 주의해서 읽어야 한다. METR 자신이 2026년 2월, 참가자 선택 효과를 보정한 후속 코호트에서 −4%(신뢰구간 −15%~+9%)라는 훨씬 완화된 결과를 발표했고, 원 연구도 "숙련자가 익숙한 성숙 코드베이스에서 2025년 초 도구를 쓴 경우"라는 좁은 조건이었다. "AI는 사람을 느리게 만든다"가 교훈이 아니다.

진짜 교훈은 이거다. 체감과 실측은 다르다. 그것도 아주 크게, 그리고 항상 낙관 방향으로. 그래서 조직은 느낌이 아니라 루프 시간을 재야 한다.

직접 만져 보기 — 학습 속도 계산기

당신 팀의 학습 루프 한 바퀴가 실제로 며칠인지, 그중 "빨라졌다고 느끼는 구간"이 몇 %인지 재 보자.

함정 3. AI 사용량을 생산성 지표로 삼는 것

"당신이 하는 모든 것은 위의 출시하고 배우는 제품 사이클을 통과하는 데 가차 없이 집중되어야 한다. 오늘 어제는 없던 무엇을 만들었는가? 어제는 몰랐던 무엇을 배웠는가? 그리고 그게 내일 무엇을 할지로 어떻게 이어지는가?"

"수많은 유명 기업들이 AI 사용량을 성과와 동일시하는 이 함정에 빠졌다. 토큰맥싱(tokenmaxing)이 바로 그것이다. 한때 토큰맥싱을 신봉하던 회사들이 지금 AI 지출을 줄이고 ROI가 나쁘다고 불평하는 건 놀랄 일이 아니다."

토큰맥싱은 2025~2026년에 퍼진 말이다. 토큰 소비량 자체를 생산성의 대리 지표로 삼는 관행. 대시보드에 "이번 달 3억 토큰 사용"이 뜨면 뭔가 열심히 한 것 같은 착시가 생긴다.

2026년 들어 이 착시의 청구서가 도착했다. 여러 조사에서 엔터프라이즈 AI 지출이 급증하는 동안 절반 이상의 경영진이 매출이나 비용 측면의 실익을 확인하지 못했다고 답했고, MIT 계열 분석에서는 생성형 AI 파일럿의 약 95%가 측정 가능한 이익을 내지 못했다는 결과가 인용되며 논쟁이 붙었다.

Levy-Weiss가 소개하는 대안 지표가 흥미롭다.

"떠오르기 시작한 지표 하나는 백만 토큰당 매출(revenue per million tokens)이다 — AI 사용이 산출을 이끌어야지 그 자체가 목적이 되어선 안 된다는 생각으로의 재초점. 이게 자리 잡을지 지켜보는 것도 흥미로울 것이다."

앞서 본 멀티에이전트의 15배 토큰 비용을 여기에 대입해 보면 계산이 선명해진다. 15배 토큰을 쓰는 구조는 15배의 가치를 만들 때만 정당하다. 법률 실사에는 맞고, 사내 위키 요약에는 안 맞는다.

실무 팁 — 팟 단위로 이렇게 물어보자. "이 워크플로에 쓰는 토큰 비용이 월 X원이다. 이게 만들어낸 결과는 무엇인가?" 답이 "리서치 문서 40건"이면 아직 답이 아니다. "그 리서치로 어떤 결정을 바꿨고, 그 결정이 무엇을 움직였나"까지 가야 한다.

함정 4. 주니어를 뽑지 않는 것

새로운 도제 모델 — 주니어는 에이전트를 지휘한다크게 보기

"그렇다. AI는 지난 50년간 주니어 직원을 훈련시켜 온 일의 대부분을 흡수하고 있다. 게으른 답은 주니어 채용을 멈추는 것이고, 그건 엄청난 실수다."

"당신은 종자옥수수를 먹어 치우고 있는 것이다. 스카우트, 문화 침식, 지식 손실에 취약해진다. 당신이 원하는 인재의 다음 세대를 길러내지 않고 있다."

"종자옥수수를 먹는다(eating your seed corn)"는 표현은 미국 농가의 오래된 관용구다. 겨울에 배가 고파서 내년에 심을 씨앗까지 먹어 버리는 것. 당장은 배가 부르지만 내년에는 아무것도 못 심는다.

이 함정이 이미 현실이라는 증거는 충분하다. 스탠퍼드 디지털 이코노미 랩의 Erik Brynjolfsson·Bharat Chandar·Ruyu Chen이 2025년 8월 발표한 「Canaries in the Coal Mine?(탄광 속 카나리아)」는 미국 최대 급여 처리업체 ADP의 개인 단위 급여 데이터로 이 현상을 측정했다.

AI 노출도 높은 직군의 상대적 고용 감소폭 (2022년 말 이후, 연령대별)
22–25세 (사회 초년)
−13%
가장 큰 타격
26–35세
미미
거의 변화 없음
36세 이상 (경력)
0
안정 또는 증가

주요 발견을 정리하면 이렇다.

  • AI 노출도가 가장 높은 직군(소프트웨어 개발자, 고객 서비스 담당 등)에서 22~25세의 고용이 상대적으로 13% 감소했다.
  • 같은 직군의 더 경력 있는 인력은 안정적이거나 증가했다.
  • 감소는 AI가 증강(augment)하기보다 자동화(automate)하는 직군에 집중되었다.
  • 조정은 임금이 아니라 고용 수량을 통해 일어났다.

코어닷은 이 주제를 끊어진 사다리 — 주니어가 없으면 시니어도 없다에서 이미 자세히 다룬 바 있다.

Levy-Weiss의 해법은 "그냥 주니어를 뽑아라"가 아니다. 훈련 방식을 바꾸라는 것이다.

"우리는 새로운 도제 모델을 제안한다. 에이전트를 지휘하는 주니어(그들은 아마 이미 AI 네이티브일 것이다), 촘촘한 평가 루프 안에서 일하며, 첫날부터 성과에 대한 오너십을 갖는 주니어. 각 주니어는 자기 미션 팟 안에서 하나의 프로젝트를 맡는다."

"이건 높은 기준이다. 오늘의 주니어는 역사상 어느 세대보다 빠르게 실행과 자기주도적 오너십의 수준으로 올라서야 한다. 많은 이들이 실패할 것이다. 하지만 성공하는 이들은? 그들이 바로 A+ 팀 플레이어다."

이 문단은 정직해서 오히려 신뢰가 간다. 낭만화하지 않는다. 예전의 주니어는 "선배 옆에서 3년 배우며 성장"했다면, 지금의 주니어는 첫 주부터 결과를 소유해야 한다. 대신 회사는 그 주니어에게 에이전트 부대와 평가 루프를 쥐여 준다.

한 문장 요약 — 예전의 주니어는 시니어의 일을 나눠 받으며 배웠다. 지금의 주니어는 에이전트의 일을 검수하며 배운다. 판단력은 여전히 반복에서 나오지만, 반복의 대상이 "직접 만들기"에서 "만들어진 것을 평가하기"로 바뀌었다.

함정 5. 저(低)구축을 린으로 착각하는 것

"작은 팀에도 여전히 강한 책임 체계, 방향성, 무엇이 되고 안 되는지 평가할 기회가 필요하다."

"당신의 10인 회사는 옛 200인 회사와 동일한 의무를 진다. 작은 팀에 맞추려고 범위와 비전을 줄이지도 말고, 그렇다고 팀을 진짜로 가능한 수준 너머로 밀어붙이지도 마라."

"결국 이거다. AI 퍼스트는 AI 온리가 아니다. 사람 지원을 완전히 잘라낸 회사들은 품질이 무너지고, 고객 만족도가 떨어지고, 엔지니어들이 티켓 큐에 끌려 들어가는 걸 목격했고 — 결국 사람 지원을 복구해야 했다. 교훈은 AI 지원이 실패한다는 게 아니다. 비용 절감이 잘못된 목적함수라는 것이다. 성장이 올바른 목적함수다."

이 문단이 지목하는 사례는 이름을 대지 않았지만 누구나 안다. Klarna다.

2024.2
Klarna가 OpenAI 기반 AI 어시스턴트가 고객 서비스 직원 700명분의 업무를 처리하고 있으며, 전체 대화의 3분의 2 이상을 담당한다고 발표. AI 도입의 상징이 되었다.
2025.5
CEO 세바스티안 시에미아트코프스키가 "너무 멀리 갔다"고 인정. "우리는 효율성과 비용에 너무 집중했다. 그 결과는 낮은 품질이었고, 그건 지속 가능하지 않다."
이후
사람 상담 인력 재고용. 단, AI 이전으로의 회귀는 아니다 — 확장 가능한 AI와 고품질 사람 지원을 결합하는 혼성 모델로 이동. 정형 문의는 AI가, 감정·분쟁·복합 케이스는 사람이.

비슷한 사례가 하나 더 있다. Duolingo는 2025년 4월 "AI 퍼스트 회사가 되겠다"며 AI가 처리할 수 있는 일에서 외주 계약자 사용을 점진적으로 중단하겠다고 발표했다가, 소비자 백래시에 직면했다. CEO 루이스 폰 안은 나중에 "내 탓이다. 맥락을 충분히 주지 못했다"고 밝혔고, 2026년 들어 AI 사용을 성과 평가에 반영하는 규칙을 철회했다.

두 사례에서 뽑아낼 교훈은 같다. AI 도입의 목적함수를 "비용 절감"으로 잡으면, 품질이 무너지는 지점을 지나칠 때까지 브레이크가 없다. 목적함수를 "성장"으로 잡으면 품질 저하가 곧바로 지표에 잡힌다. 같은 기술, 다른 나침반.


6장. 2026년, 미션 팟을 떠받치는 기술 스택

미션 팟을 떠받치는 2026년 스택 — 6개 계층크게 보기

미션 팟이 2019년이 아니라 2026년에 등장한 데는 이유가 있다. 이 구조를 실제로 돌리려면 여섯 개의 계층이 다 필요한데, 그 여섯 번째가 이제야 갖춰지고 있기 때문이다. 하나씩, 생소한 용어를 풀어 가며 살펴보자.

6-1. 1층 — 모델(Model)

가장 아래는 추론 엔진이다. 2026년의 실무적 변화는 "어떤 모델이 제일 좋은가"에서 "어떤 일에 어떤 등급을 쓸 것인가"로 질문이 바뀌었다는 점이다. 프론티어 모델은 백만 토큰당 수십 달러, 경량 모델은 수십 센트 수준이다. 백 배 차이가 난다.

미션 팟에서 이 선택은 팟이 직접 한다. 중앙 아키텍트가 정해 주는 게 아니라, "이 워크플로에는 경량 모델로 충분하다"를 팟이 판단하고 그 절감분이 팟의 성과가 된다.

6-2. 2층 — 컨텍스트와 메모리(Context & Memory)

컨텍스트 엔지니어링(context engineering) — 모델에게 무엇을 보여 줄지 설계하는 일. 프롬프트를 잘 쓰는 것을 넘어, 어떤 문서를 어떤 순서로 얼마나 넣을지, 무엇을 요약하고 무엇을 원문으로 넣을지를 다룬다. 2024년의 "프롬프트 엔지니어링"이 2026년에 이 이름으로 진화했다.

에이전트가 "팀원"이 되려면 어제 한 일을 기억해야 한다. 여기서 필요한 것이 메모리 계층이다. 단기(현재 작업), 중기(이번 프로젝트), 장기(회사의 규칙과 취향)로 나뉜다. 코어닷의 AI 에이전트는 어떻게 기억하는가에서 이 구조를 자세히 다뤘다.

RAG(Retrieval-Augmented Generation, 검색 증강 생성)도 이 층에 속한다. 회사 내부 문서를 검색해서 컨텍스트에 넣어 주는 방식이다.

6-3. 3층 — 도구 연결(Tools)

에이전트가 실제로 일하려면 캘린더를 읽고, DB를 조회하고, PR을 열 수 있어야 한다.

MCP(Model Context Protocol) — 2024년 말 Anthropic이 공개한 개방형 규약으로, AI 모델과 외부 도구·데이터 소스를 연결하는 표준 커넥터다. USB-C에 비유되곤 한다. 이전에는 도구 하나마다 전용 연동을 만들어야 했다면, MCP는 "이 서버가 제공하는 도구 목록"을 모델이 스스로 발견하고 호출할 수 있게 한다.

6-4. 4층 — 오케스트레이션(Orchestration)

여러 에이전트를 어떻게 조합할 것인가. 앞서 본 오케스트레이터–워커 패턴, 순차 파이프라인, 토론(debate) 패턴 등이 여기 속한다.

A2A(Agent-to-Agent) 프로토콜 — 서로 다른 벤더가 만든 에이전트끼리 통신하기 위한 규약. MCP가 "에이전트 ↔ 도구"라면 A2A는 "에이전트 ↔ 에이전트"다. 사내 채용 에이전트가 외부 백그라운드 체크 에이전트와 대화하는 식.

이 층에서 앞서 본 토큰 경제성 판단이 이뤄진다. 워커를 3개 띄울지 10개 띄울지, 병렬로 갈지 순차로 갈지가 곧 비용이다.

6-5. 5층 — 평가와 관측(Eval & Observability)

원칙 4에서 다룬 평가 문화가 기술적으로 구현되는 층이다. 골든셋 회귀 테스트, LLM-as-a-judge 채점, 트레이스 수집(에이전트가 어떤 순서로 무슨 도구를 호출했는지 기록), 비용·지연 모니터링.

왜 관측이 중요한가 — 에이전트는 확률적이다. 같은 입력에도 다른 경로를 탈 수 있다. 그래서 "왜 이런 답이 나왔지?"를 사후에 재구성할 수 있어야 하고, 그러려면 모든 단계를 기록(trace)해 둬야 한다. 결정론적 소프트웨어에서 로그가 하던 역할을, 에이전트 시대에는 트레이스가 한다.

6-6. 6층 — 아이덴티티와 거버넌스(Identity & Governance)

가장 최근에 갖춰지기 시작한 층이다. 에이전트에게 고유 아이덴티티를 부여하고, 최소 권한 원칙을 적용하고, 누가 만들었고 언제 폐기하는지를 관리한다. Microsoft Entra Agent ID가 2026년 4월 정식 출시되며 OAuth 2.0·MCP·A2A 같은 표준 위에서 제로 트러스트를 비인간 아이덴티티로 확장했고, Okta·Auth0 등도 유사한 제품을 내놓았다.

Gartner는 2026년 말까지 엔터프라이즈 애플리케이션의 40%가 에이전트를 내장한 채 출시될 것으로 전망한다(2025년에는 5% 미만). 즉, 이 층을 준비하지 않은 조직은 곧 "누가 무엇을 하는지 모르는 상태"를 대규모로 맞게 된다.

미션 팟 스택 — 한 눈에
6층 · 아이덴티티/거버넌스 — 에이전트에게 이름·권한·수명을 부여. 책임 소재 확정
5층 · 평가/관측 — 골든셋, 자동 채점, 트레이스, 비용 모니터링
4층 · 오케스트레이션 — 오케스트레이터–워커, A2A, 병렬도와 토큰 예산
3층 · 도구 연결 — MCP로 DB·API·SaaS 연결
2층 · 컨텍스트/메모리 — RAG, 단기·중기·장기 메모리, 컨텍스트 설계
1층 · 모델 — 작업별 등급 선택(프론티어 vs 경량)

※ 위로 갈수록 최근에 성숙한 층이다. 대부분의 조직은 1~3층만 갖춘 채 미션 팟을 시도하다가, 4~6층이 없어서 실패한다.

7장. 숫자와 사례 — 이게 진짜 되는 일인가

이론은 충분히 봤다. 실제로 이 구조로 돌아가는 회사들의 숫자를 보자.

7-1. 작은 팀, 큰 매출

회사규모성과특징
Midjourney40명 안팎연 2억 달러대 매출, 외부 투자 0디스코드 위에서 시작. 영업 조직 사실상 없음
Cursor (Anysphere)수십 명 규모역사상 가장 빠른 ARR 성장 곡선 중 하나1인당 매출이 전통 SaaS의 수십 배
Lovable146명 (2026 초)ARR 4억 달러1인당 약 270만 달러
Base448명창업 6개월 만에 Wix에 8,000만 달러 현금 인수창업자 1인 지분 100%, 인수 대금 중 2,500만 달러를 팀과 공유
— 역사적 대조군 —
WhatsApp (2014)55명사용자 4.5억, 190억 달러 인수AI 이전에도 극단적 효율은 가능했다. 단, 단일 제품·단일 기능이라는 조건에서
Instagram (2012)13명10억 달러 인수같은 조건

여기서 중요한 해석 하나. WhatsApp과 Instagram이 이미 존재했다는 사실은 "작은 팀"이 새로운 게 아님을 보여 준다. 정말 새로운 건 이거다. 예전의 소수 정예는 한 가지를 극단적으로 잘하는 제품에서만 가능했다. 2026년의 소수 정예는 여러 기능을 동시에 커버하면서도 작다. 리서치, 콘텐츠, 세일즈, 지원, 데이터 분석까지. 그 차이를 만든 게 에이전트다.

또 하나. 위 숫자들은 출처에 따라 편차가 크다. 특히 Midjourney의 인원수는 11명부터 40명까지, Cursor의 ARR도 보도마다 다르다. 비상장 기업의 숫자는 대체로 회사가 말하고 싶은 숫자다. 방향성은 신뢰하되 소수점은 믿지 말자.

7-2. 1인당 매출이라는 새 지표

여러 분석이 공통적으로 보고하는 패턴이 있다. AI 네이티브 스타트업은 전통 SaaS 대비 1인당 매출이 수 배 높고, 팀 규모가 약 40% 작으며, 유니콘에 도달하는 시간이 1년 이상 짧다. 그리고 2026년에는 10명 미만으로 ARR 1,000만 달러를 넘기는 회사가 50곳 이상 나올 것으로 전망된다 — 5년 전이라면 불가능했을 일이다.

주의 — 1인당 매출은 좋은 지표지만 만능은 아니다. 토큰 비용, 인프라 비용, 그리고 "지금 안 뽑아서 3년 뒤에 치를 비용"은 이 지표에 잡히지 않는다. 함정 4와 5가 바로 그 지점을 경고한다.

7-3. 한국에서는

한국 시장에서도 같은 전환이 진행 중이지만 결이 조금 다르다.

  • 에이전트 도입 자체는 빠르다. 한국IDC는 국내 기업의 60%가 코파일럿 단계를 넘어 전용 에이전트로 이동할 것으로 전망했고, 삼성·LG·SK·네이버·카카오는 이미 현장 통합을 진행 중이다.
  • 그런데 조직 구조 변화는 느리다. 대기업의 기능 조직 관성, 연공 기반 직급 체계, 그리고 "누가 책임지나"에 대한 보수적 문화가 미션 팟 같은 구조를 어렵게 만든다.
  • 토큰 비용이 실질적 제약이다. 국내 AI 스타트업들의 공통 과제로 지목되는 것이 외부 모델 사용에 따른 지급수수료다. 매출이 늘수록 토큰 비용도 함께 늘어, 이 비용을 관리하지 못하면 성장이 곧 적자 확대가 된다. 한국에서 "백만 토큰당 매출" 같은 지표가 더 절실한 이유다.

한국 조직이 미션 팟을 시도한다면, 전사 개편보다 하나의 팟을 파일럿으로 띄우는 편이 현실적이다. 기존 조직도는 그대로 두고, 명확한 지표 하나를 소유하는 팟 하나를 만들어 6개월 돌려 보는 것. 스포티파이 모델의 교훈 — 형식을 복사하면 실패한다 — 이 여기에도 적용된다.


8장. 반론과 한계 — 정직하게

좋은 특집이라면 반론도 다뤄야 한다. 미션 팟 개념에 제기할 수 있는 정당한 비판들이다.

반론타당한 지점그럼에도 남는 것
"검증되지 않았다"미션 팟을 5년 이상 돌린 회사는 아직 없다. 스포티파이 모델도 초기엔 완벽해 보였다구성 원리(성과 중심, 핸드오프 제거)는 Team Topologies 등에서 이미 검증된 부분이 많다
"VC의 포지션 토크 아닌가"투자사는 적은 인원으로 큰 매출을 내는 서사에 이해관계가 있다그렇다고 관찰 자체가 틀린 건 아니다. 다만 실패한 소수 정예 팀은 보도되지 않는다는 생존자 편향은 감안해야 한다
"소규모 스타트업에만 해당"대부분의 사례가 50명 미만 회사다. 규제 산업, 하드웨어, 대기업에는 그대로 적용되지 않는다부분 적용은 가능하다. 조직 전체가 아니라 특정 성과 영역 하나부터
"기준 미달 인력에게 가혹하다""산출물을 못 내는 사람을 위한 자리는 없다"는 문장은 냉정하다. 실제로 "많은 이들이 실패할 것"이라고 명시한다이건 개념의 한계라기보다 선택의 윤리 문제다. 조직이 감당할 훈련 비용을 어디까지 질 것인가
"AI 성능이 정체되면?"전제가 "AI가 계속 좋아진다"에 기대 있다정체되더라도 핸드오프 제거와 고객 접점 확대는 여전히 유효하다. 이 부분은 AI와 무관한 조직 원리다

특히 마지막 항목을 강조하고 싶다. 미션 팟의 다섯 원칙 중 세 개(생성적 인재, 평가 문화, 전원 고객 접점)는 AI가 없어도 좋은 조직 원리다. AI 특유의 것은 두 개(에이전트 조직도, "AI가 할 수 있나?")뿐이다. 이건 이 개념의 약점이 아니라 강점이다. 기술 트렌드가 꺾여도 살아남는 부분이 있다는 뜻이니까.


9장. 그래서 무엇을 할 것인가 — 코어닷의 관점

사람이 AI로 증폭되는 구조크게 보기

Levy-Weiss의 마무리는 이렇다.

"2010년대 SaaS 회사의 조직도를 베끼지 마라. 그리고 이미 균열을 보이고 있는 AI 온리 극단도 베끼지 마라."

"뉘앙스를 찾아라. 조직에서 불필요한 경계를 녹여라. 공격적으로 자동화하되, 말이 되는 곳에서는 사람을 뽑아라. AI를 처음부터 모든 워크플로에 넣어라. 사람을 고객 가까이에, 그리고 판단의 책임자로 두어라. AI 허영 지표가 아니라 1인당 성과를 측정하라."

"이기는 구조는 AI에 의해 대체된 사람이었던 적이 없다. AI에 의해 증폭된 사람이다. 최고의 회사들은 이 뉘앙스를 이해하고 그에 따라 행동한다."

코어닷이 여기에 덧붙이고 싶은 것은 세 가지다.

첫째 — 구조보다 먼저 "성과 하나"를 정하라

미션 팟을 도입한다며 조직도부터 다시 그리는 것은 순서가 틀렸다. 스포티파이 모델이 실패한 이유가 정확히 그것이다. 먼저 바꾸고 싶은 숫자 하나를 정하고, 그 숫자를 완전히 소유할 수 있는 최소 인원을 모으고, 그들에게 필요한 모든 권한을 주면 — 조직도는 결과로 따라 나온다. 역콘웨이 기동을 조직 전체가 아니라 팟 하나에서 시작하는 것.

둘째 — 지도를 먼저 그려라, 도구를 더 사기 전에

"어떤 일이 사람의 일이고, 어떤 일이 AI의 일이며, 어떤 일이 사람 검토를 거치는가." 이 지도는 하루면 그린다. 그리고 이 지도를 그려 보면 대개 두 가지가 드러난다. 아무도 담당하지 않는 일아무도 검토하지 않는 AI 산출물. 이 두 개를 메우는 것만으로도 도구 하나 더 사는 것보다 낫다.

셋째 — 속도의 정의를 팀 안에서 합의하라

"우리 빨라졌지?"라는 말이 나올 때, 무엇을 재고 있는지 서로 다르면 그 대화는 무의미하다. 프로토타입 속도인가, 배포 속도인가, 학습 속도인가. METR의 39%p 인식 격차는 개인의 착각이 아니라 측정 대상의 부재에서 온다. 팟 회고 때 반드시 물어야 할 질문은 하나다 — "이번 주에 우리가 새로 알게 된 것은 무엇인가?"

코어닷은 AI 생산성 역설과 DX Core 4에서 이 측정 문제를 별도로 다뤘고, 1인 기업의 시대에서는 극단적 소수 정예의 가능성과 한계를 짚었다. 함께 읽으면 이 특집의 빈틈이 메워질 것이다.

직접 만져 보기 — 미션 팟 준비도 진단

마지막으로, 우리 팀이 지금 어디쯤인지 12개 문항으로 확인해 보자. 점수보다 중요한 건 어떤 문항에서 팀원끼리 답이 갈리는지다. 답이 갈린다는 건 그 지점에 지도가 없다는 뜻이니까.


마무리: 조직도는 회사가 세상을 이해하는 방식이다

콘웨이가 1968년에 발견한 것은 결국 이런 이야기였다. 조직도는 인사 문서가 아니다. 그것은 회사가 세상을 어떻게 쪼개서 이해하고 있는지를 보여 주는 지도다.

기능 조직은 세상을 "기획 문제, 디자인 문제, 개발 문제"로 쪼개서 봤다. 그래서 고객의 문제는 항상 여러 부서에 걸쳐 있었고, 그래서 항상 아무도 온전히 책임지지 않았다.

미션 팟은 세상을 고객의 문제 단위로 쪼갠다. 그리고 그 문제를 푸는 데 필요한 지능이라면 — 사람의 것이든 모델의 것이든 — 같은 원 안에 넣는다.

이 전환의 어려운 부분은 기술이 아니다. 에이전트를 붙이는 건 며칠이면 된다. 어려운 건 "내 부서"라는 경계를 지우는 일, 그리고 "AI가 만든 것을 내보내도 되는가"를 매일 판단하는 일이다. 전자는 정치의 문제고 후자는 판단의 문제다. 둘 다 자동화되지 않는다.

그래서 결국 남는 문장은 Levy-Weiss의 마지막 한 줄이다.

"이기는 구조는 AI에 의해 대체된 사람이었던 적이 없다. AI에 의해 증폭된 사람이다."

증폭이라는 말이 정확하다. 증폭기는 없는 신호를 만들어내지 않는다. 있는 신호를 키울 뿐이다. 고객을 이해하려는 의지, 좋은 것과 그저 그런 것을 구분하는 눈, 틀렸을 때 인정하고 다시 하는 태도 — 그 신호가 애초에 약하다면, 증폭기를 아무리 크게 틀어도 커지는 건 잡음뿐이다.

조직도를 다시 그리기 전에, 우리 회사에 증폭할 만한 신호가 있는지부터 물어보는 게 순서일지도 모른다.


참고 자료

원문

  • Gigi Levy-Weiss, "How The Fastest AI-First Companies Really Work", NFX, 2026년 7월 — nfx.com
  • James Currier, "The 3-Person Unicorn Startup", NFX, 2023

조직 이론

  • Adam Smith, 『The Wealth of Nations』, 1776 (핀 공장과 분업)
  • Ronald H. Coase, "The Nature of the Firm", Economica, 1937 (거래비용이론)
  • Frederick W. Taylor, 『The Principles of Scientific Management』, 1911
  • Alfred D. Chandler, 『Strategy and Structure』, 1962
  • Melvin E. Conway, "How Do Committees Invent?", Datamation, 1968 (콘웨이의 법칙)
  • Frederick P. Brooks Jr., 『The Mythical Man-Month』, 1975 (n(n−1)/2, 브룩스의 법칙)
  • Robin Dunbar, "Neocortex size as a constraint on group size in primates", 1992
  • Matthew Skelton & Manuel Pais, 『Team Topologies』, 2019

멀티에이전트 아키텍처

  • Guohao Li et al., "CAMEL: Communicative Agents for 'Mind' Exploration of Large Language Model Society", NeurIPS 2023
  • Chen Qian et al., "ChatDev: Communicative Agents for Software Development", arXiv:2307.07924
  • Sirui Hong et al., "MetaGPT: Meta Programming for a Multi-Agent Collaborative Framework", ICLR 2024 (arXiv:2308.00352)
  • Qingyun Wu et al., "AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation", Microsoft Research, 2023
  • Anthropic, "How we built our multi-agent research system", 2025 (오케스트레이터–워커, 토큰 15배)

실증 연구와 산업 데이터

  • METR, "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity", 2025년 7월 / 후속 업데이트 2026년 2월
  • Erik Brynjolfsson, Bharat Chandar, Ruyu Chen, "Canaries in the Coal Mine? Six Facts about the Recent Employment Effects of Artificial Intelligence", Stanford Digital Economy Lab, 2025년 8월
  • DORA, "State of DevOps Report 2025" (Google Cloud) — AI는 증폭기
  • Tobi Lütke, "Reflexive AI usage is now a baseline expectation at Shopify" 메모, 2025년 4월
  • Klarna 고객 서비스 전략 전환 관련 보도, 2024~2025
  • Duolingo "AI-first" 메모와 그 이후, 2025~2026
  • Microsoft Entra Agent ID GA, 2026년 4월 / 비인간 아이덴티티 거버넌스 관련 산업 조사

코어닷 관련 글

※ 인용문은 원문의 취지를 살려 옮긴 것이며, 통계 수치는 각 원 출처의 발표 시점 기준이다. 비상장 기업의 매출·인원 수치는 보도마다 편차가 있어 방향성 파악 용도로 읽기를 권한다.