AI 시대, 회사도 대체될 수 있을까 — 멀티에이전트 조직 설계

앞선 글에서 개발자 개인이 AI에 의해 압축되는 흐름을 이야기했다. 이번엔 그 스케일을 조직 전체로 올려본다.

---

개발자 한 명이 대체된다면, 팀도 대체될 수 있지 않을까. 팀이 된다면 부서도. 부서가 된다면 회사 전체도.

이론적으로는 완전히 가능한 구조다. 각 팀원을 서브에이전트로 두고, 팀장 에이전트가 조율하고, 부서장 에이전트가 그 위를 관리하는 계층 구조. Multi-agent 오케스트레이션이라는 기술적 프레임은 이미 존재한다.

---

회사는 단순한 실행 구조가 아니다

문제는 회사가 "지시 → 실행 → 검증" 루프만으로 돌아가지 않는다는 점이다. 실제 조직에서 일어나는 대부분은 불완전한 정보 속에서 이해관계를 조율하는 과정이다.

팀장이 팀원에게 일을 시키는 게 아니라, 팀장이 위아래 눈치를 보면서 요구사항을 현실에 맞게 깎아내고, 팀원이 "이건 이렇게 하면 안 됩니다"라고 밀어붙이고, 그 마찰 속에서 결과물이 나온다. AI 에이전트 계층은 지시는 잘 따르지만 마찰을 만들지 못한다. 역설적으로 그 마찰이 품질을 만드는 경우가 많은데.

그래서 AI로 대체 가능한 조직에는 조건이 생긴다.

• 요구사항이 명확하게 정의될 수 있는 도메인
• 결과물의 품질을 객관적으로 검증할 수 있는 도메인
• 실패 비용이 낮거나 롤백이 가능한 도메인

B2B SaaS처럼 스펙이 비교적 명확한 곳은 빠르게 잠식될 수 있다. 반면 컨설팅이나 정치적 의사결정이 많은 대기업 내부 조직은 훨씬 느릴 거다.

---

실제로 어떻게 설계할까

카카오의 조직도를 보면 에이전트 구조와 거의 1:1 매핑이 된다.

오케스트레이터 (CTO 에이전트)
├── 기획/PM 에이전트
├── Frontend 에이전트
├── Server 에이전트
├── Infra 에이전트
├── Database 에이전트
├── QA 에이전트
├── Security 에이전트
└── Technical Writing 에이전트

하지만 카카오 구조를 그대로 구현하면 안 된다. 카카오는 수천 명 조직이라 각 팀이 독립적으로 굴러가도 되지만, 에이전트 구조에서 모든 팀을 다 돌리면 비용이 폭발한다. 기능 요청 하나에 12개 에이전트가 전부 개입할 필요가 없다.

현실적인 접근은 온디맨드 호출이다. 오케스트레이터가 요구사항을 분석한 뒤 필요한 에이전트만 선택적으로 호출한다.

로그인 기능 추가 요청
→ Server + Database + Security + QA만 호출
→ Data Science, Hadoop은 이번엔 스킵

---

플로우: 기획부터 배포까지

에이전트 간 통신에서 핵심은 풀 컨텍스트를 넘기지 않는 것이다. 대신 요약 보고서 형태로 인계한다.

기획자 에이전트
    ↓ 요구사항 명세서 (요약본)
백엔드 에이전트  ←→  파일시스템 (코드 직접 읽고 씀)
    ↓ 구현 완료 보고서 (요약본)
기획자 에이전트 (검토) → 수정 요청 시 루프
    ↓ OK 사인
QA 에이전트  ←→  파일시스템 (코드 읽고 테스트)
    ↓ QA 통과 보고서 (요약본)
인프라 에이전트 (배포 전략 수립)
    ↓ 전체 요약 패키지
최고관리자 에이전트 (최종 승인)

각 에이전트가 다음 에이전트에게 넘길 때 이런 형태의 보고서만 전달한다.

[인계 보고서]
- 요구사항: 로그인 기능 구현
- 구현 내역: JWT 인증, /auth/login 엔드포인트
- 변경 파일: src/auth/AuthController.java
- 미결 사항: 없음
- 다음 담당: QA

풀 대화 히스토리 대신 이 보고서만 넘기면 토큰이 극적으로 줄어든다. 그리고 각 에이전트는 공유 파일시스템에 직접 접근해서 코드를 읽고 쓴다. 코드 전체를 컨텍스트로 받는 게 아니라 필요한 파일만 그때그때 읽는 방식이다. Claude Code가 실제로 이렇게 동작한다.

/workspace
├── /server        # Server 에이전트 작업 공간
├── /frontend      # Frontend 에이전트 작업 공간
├── /reports       # 공유 보고서
│   ├── requirements.md
│   ├── api_spec.md   ← 팀간 계약서 역할
│   └── qa_report.md
└── /context       # 오케스트레이터 상태

팀 간 직접 대화보다 api_spec.md 같은 계약 문서를 중간에 두고 비동기로 통신하는 방식이 실제 협업 구조와도 맞고, 컨텍스트도 절약된다.

---

더 현실적인 첫 번째 시나리오

회사 전체를 한 번에 대체하는 게 아니라, 스타트업 1인 창업자가 AI 에이전트 팀을 끌고 10명짜리 팀과 경쟁하는 구조가 먼저 올 것 같다. 이미 그런 사례들이 나오고 있다. 그게 쌓이면 자연스럽게 "이 규모의 팀이 필요한가"라는 질문이 조직 단위로 올라오게 된다.

회사도 대체되는 게 아니라 압축되는 거다.

그리고 그 압축된 구조를 실제로 구축해보고 싶어졌다. 우분투 서버 하나, Anthropic API, LangGraph. 일단 오케스트레이터 + Server 에이전트 + QA 에이전트 3개짜리 미니 회사부터 시작해볼 생각이다.

---

이 생각의 출발점은 Youtube @HONGLAB의 <드디어 C++ 무너지나> 였다.