4명이 16명처럼 일하는 비밀 — 컬리 OMS팀의 역할 기반 AI 오케스트레이션

PM 1명, 엔지니어 3명. 총 4명이 12개 MSA 서비스를 개발하고 운영한다. 컬리의 OMS(주문관리시스템) 팀 이야기다. MSA가 늘어나면서 설계 단계의 정책 누락, 서비스 간 이해도 편차, 하루 7~8개 배포 요청서 작성이라는 고통이 쌓여갔다. 이 팀은 Claude AI를 도입해 TPM AI 1개 + MSA AI 11개 = 총 16명 규모의 가상 조직을 구축했다.

설계도를 그리려면 원래 4명이 한 방에 모여 머리를 맞대야 했다. 이제는 각자 전담 비서(AI)를 데리고 독립적으로 분석하고, 비서에게 "다른 부서 담당자한테 이거 확인해"라고 시키는 구조다. 비유하면, 소규모 스타트업이 AI라는 계약직 인력풀을 확보한 것과 같다.

숲을 보는 AI, 나무를 파는 AI

OMS팀의 핵심 전략은 Claude AI에게 **역할(Role)**을 부여하는 것이다. "코드 짜줘"가 아니라 TPM, Backend, Frontend, PO 같은 팀 내 역할을 분리해 각각의 AI 세션에 할당한다.

TPM AI는 숲 전체를 조망하고, MSA AI는 나무 하나에 깊이 들어간다. 엔지니어가 EPIC 요구사항을 받으면 TPM AI와 먼저 영향도를 파악하고, 구체적인 설계는 해당 MSA AI에게 넘기는 2단계 워크플로우가 만들어진다.

[💡 잠깐! 이 용어는?] AI Context: AI 세션이 시작될 때 로딩되는 문서, 규칙, 도메인 지식의 집합. Claude Code에서는 CLAUDE.md 파일과 .claude/ 폴더 구조를 통해 정의한다. 어떤 Context를 로딩하느냐에 따라 AI의 전문성이 완전히 달라진다.

지식(What)과 행동(How)을 분리하라

사람에게 업무를 인수인계할 때를 생각해 보면 된다. "우리 시스템이 뭔지"를 설명하는 문서와, "이런 상황에서 이렇게 해라"는 가이드는 성격이 다르다. OMS팀은 이 원리를 그대로 AI Context 설계에 적용했다.

ai-context/
├── knowledge/           # 지식 기반 (What)
│   ├── domain-overview/ # 각 MSA의 도메인 개요
│   ├── api-specs/       # 현행화된 API 스펙
│   └── message-specs/   # 메시지 큐 스펙
└── actions/             # 행동 기반 (How)
    ├── tpm-mode/        # TPM 역할의 분석/계획 가이드
    ├── backend-mode/    # Backend 개발 규칙
    └── frontend-mode/   # Frontend 개발 규칙

Knowledge 폴더에는 "주문 서비스는 어떤 API를 노출하는가", "배송 서비스와 어떤 메시지를 주고받는가" 같은 사실(fact)이 담긴다. Actions 폴더에는 "PR 생성 시 이런 포맷을 따르라", "에러 응답은 이 구조로 설계하라" 같은 행동 규칙이 담긴다.

자연어보다 JSON이 낫다

AI가 도메인을 제대로 이해하려면 자연어 설명만으로는 부족하다. OMS팀은 **JSON 형태의 DSL(Domain Specific Language)**로 도메인 지식을 구조화했다. "대충 이런 느낌이야"라고 말하는 것과, 정형화된 스펙 문서를 건네는 것의 차이다. AI 모델은 후자를 훨씬 정확하게 파싱한다.

[💡 잠깐! 이 용어는?] DSL(Domain Specific Language): 특정 도메인의 문제를 풀기 위해 설계된 언어. 범용 프로그래밍 언어와 달리, 해당 영역에서만 사용되는 어휘와 구조를 갖는다.

{
  "service": "order-service",
  "domain": "주문",
  "responsibilities": [
    "주문 생성/수정/취소",
    "주문 상태 관리",
    "결제 연동 트리거"
  ],
  "dependencies": {
    "upstream": ["product-service", "member-service"],
    "downstream": ["payment-service", "delivery-service"]
  },
  "api_count": 42,
  "message_topics": ["order.created", "order.cancelled"]
}

AI가 틀린 답을 내놓으면 피드백도 DSL 형태로 기록해서 Context에 반영한다. 이 과정이 반복되면서 AI의 도메인 이해도가 점진적으로 올라간다. 비유하면 신입 사원이 업무 매뉴얼에 빨간 펜으로 메모를 추가하는 것과 같다. 다음에는 같은 실수를 하지 않는다.

MCP로 외부 도구의 손발이 되다

Claude Code 단독으로는 한계가 있다. OMS팀은 **MCP(Model Context Protocol)**를 활용해 Atlassian(Jira/Confluence), GitHub, Datadog 같은 외부 도구를 Claude 세션에 연결했다.

[💡 잠깐! 이 용어는?] MCP(Model Context Protocol): AI 모델이 외부 도구 및 데이터 소스와 상호작용할 수 있도록 하는 프로토콜. Claude Code에서 Jira 이슈를 생성하거나, GitHub PR을 만들거나, 모니터링 데이터를 조회하는 등의 작업을 가능하게 한다.

이 연동 덕분에 TPM AI가 요구사항을 분석한 뒤 Jira에 하위 이슈를 직접 생성하고, 각 MSA AI가 해당 이슈를 받아 코드 레벨까지 개발하는 자동화된 파이프라인이 가능해졌다.

잘 정리된 서랍장 vs 뒤죽박죽 짐더미

OMS팀이 발견한 중요한 인사이트가 있다. AI Context 설계의 난이도는 기존 아키텍처에 따라 크게 달라진다는 점이다.

클린 아키텍처에서는 Domain, UseCase, Adapter 같은 레이어가 명확하게 분리되어 있어서, AI Context의 각 파일이 코드의 특정 레이어와 1:1로 매핑된다. 잘 정리된 서랍장에서 물건을 찾는 것과, 뒤죽박죽 쌓인 짐더미에서 찾는 것의 차이다.

[💡 잠깐! 이 용어는?] 클린 아키텍처(Clean Architecture): 비즈니스 로직(Domain)을 프레임워크, DB, UI 같은 외부 의존성으로부터 격리하는 설계 패턴. 동심원 구조로 안쪽(Domain)이 바깥(Adapter)에 의존하지 않는다.

도입 전후, 무엇이 달라졌나

팀의 그라운드 룰도 생겼다. "AI가 작성한 코드는 100% 신뢰하지 않는다. 그러나 정작 검증해야 할 것은 코드가 아니라 TPM AI의 설계다." 코드는 테스트로 검증할 수 있지만, 설계가 잘못되면 올바른 코드라도 틀린 방향으로 간다.

마무리

컬리 OMS팀의 사례에서 핵심은 단순히 "AI를 썼더니 빨라졌다"가 아니다. 역할 기반 Context 설계, 지식과 행동의 분리, 구조화된 DSL 학습, MCP를 통한 도구 연동이라는 체계적인 접근이 있었기에 4명이 16명처럼 일할 수 있었다. 개인의 AI 숙련도에 의존하는 것이 아니라, 팀 전체가 동일한 AI 인프라 위에서 일하는 구조를 만든 것이 진짜 혁신이다.