TL;DR: Multi-Agent 아키텍처로 일곱 개의 서로 다른 모델을 24시간 운영되는 AI 팀으로 편성했습니다 — Claude Opus가 관리자로 작업을 분해하고, MiniMax가 코드를 작성하고, Hermes가 글을 쓰고, Gemini CLI가 팩트를 확인하고, Groq Llama가 트레이딩 판단을 내립니다. 컨트롤 타워는 Linear이며, 작업 카드를 발행하면 5분 내에 자동 수령되어 Gate 심사와 QA 팩트 검증을 거친 후 보고됩니다. 이 글은 전체 아키텍처, 모델 분업 선택 로직, Gate가 300회 이상의 거짓 완료를 차단한 방법, 그리고 최소 단위에서 시작하는 법을 다룹니다.

AI를 어떻게 자동으로 일하게 하느냐는 질문이 끊이지 않는 이유

저는 거의 모든 것이 AI로 운영되는 회사를 꽤 오래 운영해왔습니다. 내부에는 일곱 개의 서로 다른 AI 모델을 실제 회사처럼 분업시키는 Multi-Agent 아키텍처가 돌아가고 있습니다. 이 Multi-Agent 아키텍처를 소개할 때마다 사람들이 가장 많이 묻는 것은 “무슨 모델을 쓰나요?“가 아닙니다. 바로 이겁니다:

“도대체 어떻게 AI가 스스로 일하게 만드나요?”

많은 분들이 AI에게 작업을 맡겨봤지만 결국 같은 지점에서 막혔습니다 — 여전히 계속 지켜봐야 하고, 지켜보다 보면 내가 직접 하는 게 더 빠르겠다는 생각이 듭니다. 문제는 AI가 부족한 게 아니라 아키텍처입니다. 아무리 강한 단일 AI라도 ‘스스로 작업을 집어 들고, 스스로 분업하고, 스스로 심사하고, 스스로 납품’하는 일은 잘 못합니다. 진정한 AI 자동화를 위해 필요한 것은 더 강한 모델이 아니라 Multi-Agent 아키텍처입니다.

제 일상은 이렇지 않습니다. 아침에 작업 하나가 생각나면 Linear를 열어 카드를 만들고, 태그에 “J"를 입력하고, Enter를 누릅니다. 5분 내에 이 카드는 제 관리자 에이전트가 수령합니다. 에이전트는 이것이 글쓰기인지, 코딩인지, 조사인지, 마케팅인지 판단해 해당 역할에 배분하고, 그 역할이 실행을 시작해 완료되면 Gate 심사를 거치고, 통과하면 QA 팩트 검증으로 넘어가고, 모두 통과해야 비로소 저에게 보고됩니다.

제가 하는 일은 두 가지뿐입니다: 카드 발행, 결과 확인.

이 글에서는 “파이프라인마다 전용 에이전트"에서 “일곱 개의 서로 다른 모델이 전문 분업"으로 넘어오기까지의 시행착오를 포함해 전체 Multi-Agent 아키텍처를 풀어드립니다.

흔한 실수: 내가 걸어온 Multi-Agent 아키텍처의 잘못된 길

처음에 저도 직관적인 실수를 저질렀습니다.

“다른 일에는 다른 에이전트를 쓰면 되지"라고 생각했습니다. 그래서 에이전트를 잔뜩 만들었습니다: 블로그 쓰는 에이전트, X에 포스팅하는 에이전트, 트레이딩 시그널 만드는 에이전트, 시장 정보 수집하는 에이전트, SEO 돌리는 에이전트, 이미지 만드는 에이전트…

세 달 후 몇 가지 사실을 깨달았습니다:

  • 메모리가 공유되지 않습니다. 블로그 에이전트는 X 포스팅 에이전트가 지난주에 뭘 올렸는지 모릅니다.
  • 서로가 뭘 하는지 모릅니다. 한 에이전트가 블로그를 썼는데, 다른 에이전트가 그걸 X에 올릴 때 또 새로 씁니다.
  • 디버깅이 악몽입니다. 문제가 생기면 다섯 개의 로그를 봐야 합니다.

처음부터 다시 만들었습니다. ‘전문성’을 분류 축으로 — 더 이상 ‘일’을 기준으로 나누지 않는 방식으로 바꿨습니다.

즉, 어떤 파이프라인이든 ‘글쓰기’ 전문성이 필요하면 글쓰기 에이전트에게 맡기고, ‘QA 팩트 확인’이 필요하면 QA 에이전트에게 맡깁니다. 에이전트 하나에 전문성 하나, 모든 파이프라인이 공유합니다.

이렇게 하면:

  • 글쓰기 에이전트 하나가 모든 글쓰기(블로그, X, 이메일, 상품 카피)를 담당합니다.
  • QA 에이전트 하나가 모든 심사(글쓰기 품질, 코드 리뷰, 팩트 검증)를 담당합니다.
  • 엔지니어링 에이전트 하나가 모든 코드 구현을 담당합니다.
  • 관리자 에이전트 하나가 작업 분해, 배분, 반려를 담당합니다.

많다고 좋은 게 아닙니다. 적어도 올바른 것이어야 합니다.

이 아키텍처가 안정화된 후에야 다음 이야기가 가능했습니다.

Multi-Agent 아키텍처의 구조

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

       작업 발행
         │
         ▼
   ┌──────────┐  매 5분 폴링  ┌──────────┐
   │  Linear  │ ─────────────▶│ 중앙 디스패처 │
   └──────────┘               └─────┬────┘
                                    │
                                    ▼
                        ┌──────────────────────┐
                        │  관리자 에이전트 (Opus)  │ ── 작업 분해·배분·반려
                        └──────────┬───────────┘
                                   │
           ┌────────────┬──────────┼──────────┬────────────┐
           ▼            ▼          ▼          ▼            ▼
      ┌────────┐  ┌────────┐  ┌────────┐  ┌────────┐  ┌────────┐
      │엔지니어링│  │ 글쓰기  │  │  QA   │  │마케팅  │  │트레이딩│
      │MiniMax │  │ Hermes │  │ Gemini │  │MiniMax │  │ Groq   │
      └───┬────┘  └───┬────┘  └───┬────┘  └───┬────┘  └───┬────┘
          │           │           │           │           │
          └───────────┴────┬──────┴───────────┴───────────┘
                           │
                           ▼
                   ┌──────────────┐
                   │  Gate 심사    │ ── 모호함·날조·유출 차단
                   └──────┬───────┘
                          │
                          ▼
                   ┌──────────────┐
                   │  QA 팩트 검증  │ ── 내장 검색으로 검증
                   └──────┬───────┘
                          │
                          ▼
                       Judy에게 보고

각 박스는 독립적인 스크립트 또는 서비스이며, 파일 기반 메일함으로 통신합니다. 전체 시스템은 Oracle 클라우드 VM 하나에서 돌아가고, cron으로 스케줄링되며, 메시지 큐도, 웹훅도, 별도의 미들웨어 서비스도 없습니다. 너무 단순해서 제가 직접 파일을 들여다보면서 디버깅할 수 있습니다.

실행 과정: 카드 발행부터 원고 수령까지 단계별 분해

구체적인 예를 들겠습니다. 오늘 아침 특정 AI 도구 소개 글을 쓰고 싶었습니다.

Step 1 (00:00) — Linear를 열어 카드를 만듭니다: “XX 도구 소개 글 작성, 800자, 타겟 독자는 AI 자동화를 활용하려는 개인 개발자”. 태그에 “J"를 입력하고 Enter를 누릅니다. Linear를 닫고 다른 일을 합니다.

Step 2 (+5분) — 중앙 디스패처가 이 새 카드를 폴링합니다. 태그 “J"를 확인하고 카드 내용을 관리자 에이전트의 메일함에 씁니다.

Step 3 (+6분) — 관리자 에이전트가 깨어나 메일함을 읽고, 이것이 “글쓰기” 유형 작업이라고 판단해 글쓰기 에이전트의 메일함에 배분합니다. 지시 사항 포함: “800자, 튜토리얼 스타일, 타겟 독자 개인 개발자, FAQ 포함”.

Step 4 (+10분) — 글쓰기 에이전트가 초고를 작성합니다. Hermes 모델이 작성 완료 후 초고 영역에 저장합니다.

Step 5 (+15분) — Gate 심사가 초고를 스캔합니다. 책임을 사람에게 미루는 모호한 보류 표현이 있는지, 날조된 KPI 수치가 있는지, 내부 경로가 유출되었는지 확인합니다. 이번 글에서 Gate가 “데이터 출처는 내부 데이터베이스"라는 문장을 탐지해 자동으로 글쓰기 에이전트에게 반려하고 “공개 데이터 기반 추정"으로 수정하도록 했습니다.

Step 6 (+20분) — 수정 후 Gate를 재통과했습니다. QA 단계로 넘어갑니다.

Step 7 (+30분) — QA 에이전트가 Gemini 내장 검색을 사용해 글의 사실 주장을 하나씩 검증합니다. 버전 번호 하나가 잘못 기재된 것을 발견하고 자동으로 표시합니다. 소수정 반려.

Step 8 (+45분) — 수정 완료, 전부 통과. 글이 자동으로 Notion에 동기화되고 상태는 “Judy 검토 대기"가 됩니다.

Step 9 — 저는 아침 식사를 마치고 Notion을 열어 바로 발행 가능한 원고를 확인합니다. 읽고 “발행 가능"을 누릅니다. 시스템이 자동으로 영어·한국어 번역을 완료하고 블로그에 배포합니다.

이 과정에서 제가 쓴 시간: 카드 발행 30초 + 원고 확인 5분. 나머지 시간은 다른 일을 했습니다.

제 협업 방식: Opus가 프레임워크를, MiniMax가 구현을

이것이 전체 아키텍처의 핵심 노하우입니다. 구체적인 예로 코드 작성을 들겠습니다.

트레이딩 시스템의 새 전략 코드를 짠다면, 가장 직관적인 방법은 Claude Opus에게 처음부터 끝까지 쓰라고 하는 것입니다. 가능합니다. 하지만 비용이 높고 느립니다.

제 방법은 이렇습니다:

  1. Opus가 프레임워크를 분해합니다 — 요구사항을 Opus에게 주면 파일 구조, 함수 시그니처, 각 함수의 책임, 경계 조건, 필요한 테스트를 출력합니다. 구현 세부 사항은 작성하지 않고, 뼈대만 작성합니다.
  2. MiniMax가 구현을 채웁니다 — Opus가 분해한 뼈대를 MiniMax에 전달하면 함수 하나씩 채웁니다.
  3. Sonnet이 코드 리뷰를 담당합니다 — MiniMax가 작성을 마치면 Sonnet이 한 번 리뷰해 로직 허점과 경계 케이스를 지적합니다.
  4. Opus가 마무리를 담당합니다 — Sonnet이 표시한 문제로 돌아와 Opus가 수정 여부와 방법을 판단합니다.

왜 이렇게 나누나요?

  • Opus는 추론이 강해 판단이 필요한 작업(분해, 마무리)에 최적입니다. 하지만 대량 실행은 비용이 높습니다.
  • MiniMax는 구독제로 빠르고 저렴하며, 컨텍스트도 충분히 길어 스펙에 따른 구현에 최적입니다.
  • Sonnet은 중간 정도로, 리뷰에 딱 맞습니다 — Opus보다 저렴하지만 로직은 여전히 탄탄합니다.

이 패턴은 글쓰기에도 똑같이 적용됩니다: Opus가 구조 개요를 잡고, Hermes가 초고를 작성하고, Sonnet이 사실 레이어를 리뷰하고, Opus가 마지막 한 번 수정합니다.

각 모델이 가장 잘하는 일을 하게 합니다 — 이것이 제 Multi-Agent 아키텍처 전체를 관통하는 유일한 원칙입니다.

일곱 개 모델, 일곱 가지 전문성

현재 일곱 개의 서로 다른 모델을 운용 중이며 각각 전담 포지션이 있습니다:

1. Claude Opus 4.x — 전략가 / COO

판단력이 가장 강합니다. 작업 분해, 배분, 반려, 코드 프레임워크 작성, 최종 코드 리뷰, 분쟁 중재를 담당합니다.

사용 시점: 선택이 필요할 때. 예를 들어 “이 버그 수정법 A와 B 중 어느 게 맞나”, “이 카드는 누구에게 배분해야 하나”, “블로그 글이 절반 작성된 상태에서 방향이 틀렸다면 어떻게 살릴까”.

2. Claude Sonnet 4.6 — 글쓰기 팩트체크 / 코드 리뷰 / 트레이딩 분석가 백업

Opus의 저렴한 버전. 논리 강도는 거의 같고 가격은 절반입니다.

사용 시점: 엄밀한 추론이 필요하지만 대량 실행해야 하는 경우. 블로그 튜토리얼 팩트 검증, 코드 리뷰, 트레이딩 분석가(Groq 주력의 백업).

3. MiniMax M2.7 — 엔지니어링 구현 / 마케팅 실행

구독제, 컨텍스트가 길고 빠릅니다.

사용 시점: 이미 분해된 프레임워크에 따른 구현(스스로 판단할 필요 없음), 마케팅 카피 실행, 번역.

4. Hermes (OpenRouter를 통해) — 글쓰기 역할

글쓰기 품질은 충분하고 비용이 낮습니다. 장문 스타일이 안정적입니다.

사용 시점: 블로그 초고, 소셜 게시글 초고, 상품 카피 초고. 팩트 확인 없이 분량이 필요한 모든 글쓰기.

5. Gemini CLI 구독판 — QA 팩트 확인

내장 웹 검색이 대체 불가한 강점입니다. 일부 모델은 팩트를 확인하려면 외부 검색 API를 연결해야 하지만, Gemini CLI는 스스로 검색합니다.

참고: Gemini CLI를 고른 현실적인 이유가 하나 더 있습니다 — 연초에 1년치 구독을 끊어둬서, 안 쓰면 손해라서요.

사용 시점: 블로그 게시 전 팩트 확인, 보도자료 검증, 시장 조사 소스 비교.

6. Gemini API (Flash) — 뉴스 파이프라인

무료 할당량만으로 매일 뉴스 정리를 충분히 돌릴 수 있고, 빠르며 API도 안정적입니다.

사용 시점: 매일의 뉴스 수집·정리 파이프라인. 대량 실행이 필요하고 강한 추론이 필요 없습니다. 무료라서 비용 폭발을 걱정하지 않아도 됩니다.

7. Groq Llama-4-Scout 17B — 트레이딩 시그널 / 포지션 관리

속도가 극히 빠릅니다. 추론 지연이 다른 모델의 10분의 1입니다.

사용 시점: 트레이딩 전략에서 즉각 반응이 필요한 경우 — 시그널 심사(진입 여부 결정), 포지션 관리(HOLD / 손절 강화 / 익절 / 즉시 청산 권고). 1초 늦으면 손실이 나는 일.

왜 Linear를 컨트롤 타워로 쓰나

Notion도 써봤고, Slack도 써봤고, 직접 대시보드도 만들어봤습니다. 결국 Linear만 남았습니다. 이유는 단순합니다:

이슈 트래커는 원래 사람에게 작업을 배분하는 가장 자연스러운 인터페이스입니다.

태그가 라우팅이고, 상태가 흐름이고, 댓글이 커뮤니케이션이고, 하위 작업이 분해입니다. 이 기능들은 제가 설계할 필요가 없습니다. 원래 내장되어 있습니다. 제가 할 일은 ‘스스로 카드를 집어 드는 AI 에이전트’를 연결해서 AI들이 Linear를 작업 소스로 쓰게 만드는 것뿐입니다.

더 중요한 것은: 댓글 주고받기도 Linear로 합니다. 에이전트가 완료하면 댓글을 남기고, 제가 질문이 있으면 댓글로 답하고, 에이전트가 댓글을 보고 다시 답합니다. 전체 대화 흐름이 카드에 자동으로 누적되어 나중에 되돌아볼 때 그 카드만 보면 됩니다.

Notion은 너무 유연하고, Slack은 너무 선형적입니다. 직접 만든 대시보드도 있었지만 — 에이전트가 매번 업데이트하는 걸 잊어버려 제가 지켜봐야 했고, 그렇다면 대시보드의 의미가 없습니다. Linear는 딱 맞습니다 — 상태 전환이 내장되어 있고, 에이전트가 일을 하려면 반드시 Linear를 거치게 되어 있어 “업데이트를 깜빡"할 수 없습니다.

파일이 곧 통신 프로토콜

에이전트 간에 어떻게 통신하냐고 많이 물어봅니다. 파일을 씁니다.

에이전트마다 메일함 폴더가 있고, 관리자 에이전트가 배분할 때는 해당 메일함에 메시지 파일 하나를 씁니다. 실행 에이전트는 자신의 메일함을 폴링하다가 새 메시지를 발견하면 처리하고, 처리 완료 후 결과 파일을 “완료” 폴더에 씁니다.

왜 메시지 큐, Redis, 웹훅을 쓰지 않나요?

  • 단순합니다 — cron만으로 실행됩니다. 유지할 서버가 없습니다.
  • 감사 가능합니다 — 메시지 하나하나가 파일이라 디버깅할 때 파일 내용을 바로 볼 수 있습니다.
  • 재실행 가능합니다 — 결과가 잘못되었나요? 파일을 메일함으로 다시 옮겨서 재처리하면 됩니다.
  • 의존성이 없습니다 — 새로운 도구를 배울 필요가 없습니다. 운영체제 내장 기능으로 충분합니다.

원시적으로 들릴 수 있지만 안정적으로 돌아갑니다. 가장 단순한 도구가 가장 오래 갑니다.

Gate + QA + TA 세 겹 심사: AI를 믿지만 완전히 믿지 않는 이유

AI의 가장 큰 문제는 뭔가를 못 만드는 게 아닙니다. 만든 것이 그럴듯해 보이지만 사실은 아닌 경우입니다.

구체적으로 제가 겪은 몇 가지 상황:

  • 코드를 다 쓰고 이제 문제없다고 했는데 — 실제로는 테스트조차 안 했습니다.
  • 글을 쓰고 데이터를 인용했는데 — 그 데이터는 스스로 만들어낸 겁니다.
  • 문안을 쓰다가 내부 경로나 API 변수명이 무심코 유출되었습니다.
  • 같은 버그를 세 번 고쳤는데 매번 “이번엔 맞았다"고 했습니다.

그래서 자동 심사를 두 겹 추가했습니다.

Gate 레이어 — 게으름 모드 탐지

Gate는 일련의 정규식과 규칙으로 에이전트 출력을 자동 스캔합니다:

  • 모호한 보류 표현 탐지 — 책임을 사람에게 미루는 표현(사람이 직접 확인하라는 요구, 모호한 “문제없다"는 표현, 영어 모호 보류 표현)을 탐지하면 자동 FAIL. PASS하려면 증거(명령 출력, 파일 내용, API 응답)를 첨부해야 합니다.
  • 같은 카드 반려 횟수 카운팅 — 같은 카드에서 같은 에이전트가 세 번 이상 반려되면 자동으로 교체하고 무한 루프를 방지합니다.
  • 타임아웃 알림 — 에이전트가 작업을 수령했지만 6시간 이내에 보고가 없으면 자동 알림을 발송합니다.
  • 내부 정보 유출 — 경로, 호스트명, API 변수명, 개인 계정, 재무 수치를 스캔하면 차단합니다.

Gate 레이어 하나만으로 누적 차단된 FAIL이 380회를 넘었고, 자동 교체가 90회를 넘었습니다. 즉, 이 거짓 완료들은 단 하나도 제 눈 앞에 도달하지 않았습니다.

QA 레이어 — 실제 팩트 검증

Gate를 통과했다고 글이 정확하다는 의미는 아닙니다. QA 레이어는 Gemini 내장 검색을 사용해 글의 사실 주장(버전 번호, 날짜, 인용, 통계 수치)을 하나씩 온라인에서 검증합니다. 불일치가 발견되면 소수정 반려합니다.

TA 레이어 — 타겟 독자 시각 심사

QA를 통과해도 그 글이 ‘읽을 가치가 있는지’는 별개입니다. TA(타겟 독자) 심사는 다른 에이전트가 타겟 독자의 시각으로 읽게 합니다 — 예를 들어 이 글의 타겟 독자가 개인 개발자라면, TA 에이전트는 개인 개발자의 시각으로 읽습니다: 읽고 나서 직접 해볼 수 있는 것이 있는가? 다음 글을 클릭하고 싶어지는가? 전문 용어가 너무 무겁지 않은가? 감정적 공감대가 있는가? TA도 통과하지 못하면 반려합니다.

세 겹을 모두 통과해야 저는 결과만 봐도 됩니다. 매번 직접 팩트체크할 필요가 없습니다.

보충 설명: 여기서 소개하는 것은 기본형 세 겹 심사이며, 파이프라인마다 별도 커스텀 설정이 있습니다 — 예를 들어 트레이딩 파이프라인에는 리스크 Gate가 추가되어(단일 거래 2% 초과 리스크 즉시 차단), 상품 출시 파이프라인에는 저작권·브랜드 일관성 Gate가 추가되고, 블로그 파이프라인에는 유입 리듬 Gate가 추가됩니다. 기본 뼈대는 같고 세부 사항은 상황에 따라 자라납니다.

우리가 할 수 있는 것들

이 Multi-Agent 아키텍처가 안정화된 후 할 수 있는 일이 많아졌습니다:

  • 블로그 자동 작성(중국어, 영어, 한국어 세 개 언어) 및 SEO / AEO 최적화
  • 매일 자동으로 시장 뉴스를 스캔하고 요점을 정리해 푸시
  • 암호화폐 퀀트 트레이딩 실행 — 자동 전략 연구부터 시그널 심사, 포지션 관리까지 전자동 — 시스템이 스스로 백테스팅을 돌리고, 새 전략을 발견하고, 테스트넷에서 검증하고, 통과하면 실거래로 올림
  • 이메일 자동 처리, 중요한 것은 한국어로 번역해 알림
  • 소셜 마케팅 자동 운영 — X 게시글, Threads, Reddit 자동 배포
  • 시장 조사 수행 — 키워드 연구부터 경쟁사 분석, Notion 보고서까지

가장 대표적인 역량은 상품 개발입니다 — 저는 아침에 일어날 때 새 상품 하나를 볼 수 있어야 한다는 규칙을 스스로에게 부과했습니다. 그래서 시스템은 제가 자고 있는 몇 시간 동안 시장 조사 → 기회 평가 → 상품 설계 → 카피 → 출시 → 마케팅 문안, 이 전체를 자동으로 완료하고, 늦어도 제가 눈을 뜨는 순간 결과물을 제 앞에 가져다 놓아야 합니다. 매일 하나씩, 예외 없이.

이것이 가능한 이유는 최강의 모델을 써서가 아닙니다. 각 전문성에 맞는 역할자가 포지션에 있기 때문입니다.

최소 단위에서 시작할 수 있습니다

처음부터 일곱 개 모델을 목표로 하지 마세요. 주말 90분이면 돌려볼 수 있는 최소 버전으로 쪼개보겠습니다.

Step 1: Linear 보드 하나 (10분)

Linear 무료 워크스페이스 생성 → 프로젝트 추가 → Settings → API → LINEAR_API_KEY 발급 후 .env에 저장.

최소 설정:

  • 레이블 3개: role:executor, role:qa, status:rejected
  • 상태 3개: Todo → In Progress → Done (Linear 기본값 그대로)

Step 2: cron 두 개 (20분)

Cron A — 배분기 (5분마다 Linear 폴링)

1
2
3
4
5
6

# dispatcher.py 의사코드
new_cards = linear.list_issues(status="Todo", missing_label=["role:*"])
for card in new_cards:
    role = classify(card.title)        # 키워드 매칭 또는 LLM 호출
    linear.add_label(card.id, f"role:{role}")
    linear.set_status(card.id, "In Progress")

crontab:

1

*/5 * * * * cd /opt/agent && python dispatcher.py >> logs/dispatch.log 2>&1

Cron B — 실행기 (5분마다 해당 에이전트 트리거)

1
2
3
4
5
6
7

# executor.py 의사코드
cards = linear.list_issues(status="In Progress", label="role:executor")
for card in cards:
    prompt = f"Task: {card.title}\nSpec: {card.description}"
    result = run_cli("claude-code", prompt)   # 또는 codex / aider / gemini cli
    linear.add_comment(card.id, result)
    linear.add_label(card.id, "needs-qa")

1

*/5 * * * * cd /opt/agent && python executor.py >> logs/exec.log 2>&1

Step 3: 역할 프롬프트 3개 (30분, 그대로 복사 가능)

각 역할 = 시스템 프롬프트 1개 + 트리거 조건 1개.

관리자 (Opus 또는 Sonnet) — 요구사항을 실행 가능한 카드로 분해:

1
2
3

당신은 PM입니다. 사용자 요구를 읽고 Linear 카드 JSON을 출력하세요:
{"title": "...", "description": "구체적으로 무엇을 할지", "acceptance": "통과 기준"}
acceptance는 반드시 검증 가능해야 합니다. "잘 한다" 같은 막연한 표현 금지.

실행자 (저렴한 모델이면 무엇이든 — MiniMax / Codex / Haiku 모두 가능) — 실제로 카드를 처리:

1
2
3

당신은 executor입니다. task를 읽고 처리한 뒤 결과를 출력하세요.
철칙: "아마도", "~일 것입니다", "수동으로 확인 부탁", "probably", "please check" 등 모호한 표현 절대 금지.
확실하지 않으면 "모르겠습니다. 이유: ..." 라고 직접 쓰세요.

QA (Gemini CLI 또는 웹 검색 내장된 도구) — 팩트 검증 + 모호함 차단:

1
2
3
4
5

당신은 QA입니다. executor의 출력을 3단 검사:
1. 사실이 정확한가? (웹 검색으로 최소 1개 데이터 검증)
2. 모호한 표현이 있는가? (grep "아마|~것|수동으로|probably|please check")
3. acceptance 기준을 충족하는가?
어느 하나라도 실패 → FAIL + 구체 사유. 모두 통과 → PASS.

Step 4: 첫 카드 돌려보기 (20분)

Linear에서 수동으로 카드 하나 작성:

  • 제목: Claude Code 소개를 100자로 작성
  • 설명: 비기술 독자 대상, 사실 기반, 모호 표현 금지, “그것이 무엇인지"와 “할 수 있는 일” 반드시 포함

10분 내 기대 흐름:

  1. Cron A 수령 → role:executor 추가 → In Progress로 이동
  2. Cron B 수령 → executor 호출 → 결과를 코멘트로 → needs-qa 추가
  3. QA cron (또는 Cron B 끝에 체이닝) → 코멘트 읽기 → 웹 검색 팩트 검증 + 모호 표현 grep → PASS/FAIL 코멘트

PASS → Done으로 이동. FAIL → Todo로 반려 + status:rejected 레이블 + 사유 코멘트.

Step 5: 돌면 확장하기

첫 카드가 처음부터 끝까지 돌면, 단계적으로 추가:

  • 두 번째 실행 모델 — 레이블에 따라 다른 CLI 라우팅 (lang:code → Codex, lang:writing → MiniMax)
  • 반려 메커니즘 — 같은 카드 FAIL 3회 → 자동 Blocked + Telegram 알림
  • 역할 추가 — 마케팅, 트레이딩, 데이터 각각 시스템 프롬프트 + 레이블 규칙 1개
  • 알림 레이어 — Telegram 봇이 완료 카드를 푸시, Linear에 계속 붙어 있지 않아도 됨

한 번에 완성하려 하지 마세요. 카드 한 장 돌리는 것부터, 나머지는 확장입니다.

마무리: 1.0은 멀티 인스턴스, 2.0은 멀티 모델 멀티 역할

최근 OpenAI가 Symphony라는 것을 오픈소스로 공개했습니다. 비슷한 일을 합니다: Linear를 컨트롤 타워로 쓰고, 카드마다 Codex 에이전트 하나, 에이전트가 스스로 카드를 집어 들고 처리합니다. OpenAI 내부에서 PR 수가 500% 성장했다는 결과를 냈습니다.

보고 나서 든 생각은 단 하나입니다: 절반만 했습니다.

Symphony의 설정은 “같은 모델을 여러 인스턴스로 실행” — 전부 Codex입니다. 코딩의 대량 생산 문제는 해결할 수 있지만, “다른 작업에는 다른 전문성이 필요하다"는 문제는 해결하지 못합니다. 코드 작성, 글쓰기, 팩트 확인, 트레이딩, 마케팅은 본질적으로 다른 다섯 가지 일이며, 같은 모델이 담당해서는 안 됩니다.

제 Multi-Agent 아키텍처는 실제 회사 운영에 더 가깝습니다: 다수의 역할, 다수의 모델, 각자의 책임. 관리자 하나, 엔지니어링 하나, 글쓰기 하나, QA 하나, 마케팅 하나, 트레이딩 하나, 데이터 하나 — 실제 소규모 팀처럼.

멀티 인스턴스 동질 에이전트가 1.0. 멀티 역할 멀티 모델 Multi-Agent 아키텍처가 2.0입니다.

AI를 진짜로 스스로 일하게 만들려 한다면, 이 글이 제가 걸어온 시행착오를 건너뛰는 데 도움이 되길 바랍니다. Linear 카드 한 장, 역할 세 가지에서 시작해 천천히 키워가세요.

덧붙이자면, 이 Multi-Agent 아키텍처의 원형은 사실 두 달여 전에 이미 오픈소스로 공개했습니다 — ai-night-shift라는 레포지토리로, “밤에 자는 동안 에이전트가 계속 일하게 하는” 문제를 풀기 위한 것이었습니다.

그 시점에 이미 돌아가던 핵심 아이디어:

  • 파일이 곧 통신 프로토콜 — bot_inbox/ + night_chat.md 이중 채널, 메시지 큐 의존 없음
  • 어댑터 추상화 레이어 — 한 스크립트로 Claude Code, Codex CLI, Aider, 커스텀 CLI 모두 지원
  • Autonomy Rules로 인터랙션 멈춤 방지 — 모든 프롬프트 템플릿에 반인터랙티브 블록 내장
  • 원자적 PID 락 — 파일 대신 mkdir 사용, TOCTOU 레이스 컨디션 방지
  • 플러그인 시스템 — pre/task/post 3단계, 끼우고 빼기 자유

이 글에서 다루는, 그 이후에 자라난 것들:

  • Linear를 컨트롤 타워로 — 로컬 bot_inbox/에서 클라우드 보드로 업그레이드, 머신/에이전트 간 통합
  • 멀티 모델 분업 — “야간 한 모델"에서 “일곱 모델 각자 전담"으로 진화
  • Gate-9 모호한 표현 차단 — 가짜 완료 보고 수백 번에 데인 뒤 사후 검사 레이어로 추가
  • 반려 + QA 2차 심사 — 에이전트가 PASS라 말해도 무효, J가 재실행 + Moon QA 통과해야 인정

관심 있는 분은 그 레포에서 출발하세요. 이 글 아키텍처의 최소 실행 가능한 원조이며, MIT 라이선스로 자유롭게 포크해도 됩니다. 거기서 먼저 “파일 통신 + 자율 실행” 골격을 이해한 뒤, 이 글로 돌아와 그것이 어떻게 24시간 멀티 모델 팀으로 자랐는지 보면 됩니다.

더 읽어보기

이 Multi-Agent 아키텍처는 계속 반복 개선 중입니다. 비슷한 시도를 하고 계시거나 특정 부분에 궁금한 점이 있으시면 댓글로 자유롭게 이야기 나눠요.

멀티 에이전트 팀이 만들어낸 결과와 제가 직접 정리한 생각을 가장 먼저 받아보고 싶으신가요? Judy AI Lab 뉴스레터를 구독하시면 매주 한 통씩 보내드립니다. 저희 팀이 매일 사용하는 AI 팀 아키텍처 가이드 PDF도 함께 보내드립니다.

무료: AI 팀 아키텍처 가이드 (PDF)

저희 팀이 매일 사용하는 4계층 시스템.