AI 코딩, 장난감에서 실무 파이프라인으로: 단일 바이너리로 끝내는 Compozy 멀티 에이전트 오케스트레이션 심층 해부

Posted May 18, 2026

AI Coding, From Toy to Production Pipeline: Deep Dive into Compozy Multi-Agent Orchestration with a Single Binary

20 min read

[Compozy - AI-assisted Development Orchestration Platform]
GitHub: https://github.com/compozy/compozy
Official Website: https://compozy.com
Core Stack: Go (단일 바이너리, Zero Dependencies), Declarative YAML 기반 워크플로우
Key Ecosystem: compozy/skeeper (사이드카 Git 스펙 버전 관리), compozy/gograph (Go 코드베이스 AST 분석), compozy/codex-loop (리뷰 자동화 루프)
Creator: Pedro Nauck

The Hook: AI 코딩, 왜 실무에만 오면 무용지물이 될까?

“솔직히 말씀드리죠. 요즘 쏟아지는 AI 코딩 툴들, 데모 영상이나 사이드 프로젝트에서 처음 한두 번 쓸 땐 마법 같지만, 수백 개의 파일이 얽혀 있는 실무 프로젝트에 투입하는 순간 재앙이 시작됩니다.”

현업에서 Copilot이나 Cursor 같은 툴을 치열하게 써보신 시니어 분들이라면 깊이 공감하실 겁니다. 처음엔 자동완성의 쾌감에 취합니다. 하지만 복잡한 비즈니스 로직을 수정하거나 레거시 시스템의 핵심 코어를 리팩터링하려고 하면, AI는 금세 컨텍스트를 잃어버리고 환각(Hallucination)에 빠집니다. 우리는 어떻게든 AI에게 맥락을 이해시키려고 기획서(PRD)를 복사해서 붙여넣고, 데이터베이스 스키마를 긁어오고, 에러 로그를 다시 프롬프트 창에 욱여넣습니다.

그러다 보면 어느새 ‘토큰 한도 초과(Token Limit Exceeded)’ 에러가 뜨거나, AI가 방금 전까지 논의했던 핵심 설계 원칙을 붕어처럼 까먹고 스파게티 코드를 뱉어냅니다. 프롬프트 엔지니어링을 하다가 하루가 다 가버리죠. 우리는 본질적인 ‘아키텍처 설계와 개발’을 하고 싶은 거지, AI의 비위를 맞추며 타이핑 노가다를 하고 싶은 게 아닙니다.

바로 이 지점에서 기존 AI 도구들의 치명적인 한계가 여실히 드러납니다. 그들은 여전히 ‘단일 프롬프트’나 ‘채팅창’이라는 좁은 감옥에 갇혀 있습니다. 소프트웨어 개발은 단순히 텍스트를 생성하는 1회성 작업이 아니라, ‘아이디어 기획 → 설계 → 태스크 분할 → 구현 → 코드 리뷰’로 이어지는 복잡한 상태 머신(State Machine)입니다. 오늘 해부할 Compozy는 기존 툴들이 방치했던 이 본질적인 SDLC(소프트웨어 개발 수명 주기) 오케스트레이션 문제를 정확하게 타격하는 플랫폼입니다.

TL;DR: 핵심 가치 요약

Compozy는 AI 코딩을 단순한 텍스트 완성이 아닌 ‘아이디어 → PRD → 기술 명세 → 태스크 분할 → 실행 → 코드 리뷰’라는 7단계의 구조화된 파이프라인으로 규정하고, 40개 이상의 AI 에이전트를 조율하여 마크다운(Markdown) 기반의 영구적 컨텍스트를 통해 구동하는 Go 언어 기반의 강력한 CLI 오케스트레이션 프레임워크입니다.

Deep Dive: Under the Hood (핵심 아키텍처 심층 해부)

단순한 기능 나열은 접어두고, 산전수전 다 겪은 엔지니어의 시각에서 이 도구가 내부적으로 어떻게 돌아가는지 아키텍처 레벨로 뜯어보겠습니다. 처음 터미널에서 $ brew install compozy/tap/compozy로 단일 바이너리를 설치하고 코어 구조를 까보며 제가 가장 감탄했던 부분은 ‘컨텍스트 메모리의 2계층 분리’와 ‘병렬 에이전트 루프 로직’입니다.

1. 단일 바이너리(Go)와 Zero Dependency가 주는 해방감

보통 이런 복잡한 오케스트레이션 툴은 Python이나 Node.js로 작성되어 지옥 같은 pip 의존성이나 node_modules 충돌을 유발하기 마련입니다. 하지만 Compozy는 Go 언어로 컴파일된 단일 바이너리 형태로 제공됩니다. 이는 단순히 설치가 편하다는 것을 넘어, 로컬 환경에서 40개 이상의 에이전트(Claude Code, Codex, Cursor, Gemini 등)를 스폰(Spawn)하고 프로세스를 관리할 때 압도적인 실행 속도와 안정성을 보장한다는 뜻입니다.

2. 거대 프롬프트의 종말과 ‘Two-tier Markdown Memory’

기존 방식은 AI에게 모든 컨텍스트를 하나의 거대한 시스템 프롬프트로 욱여넣습니다. 이는 필연적인 토큰 낭비(Token Bloat)를 불러옵니다. 반면 Compozy는 7단계의 파이프라인을 거치며 각 단계의 결과물을 독립적인 마크다운(.md) 아티팩트로 만들어 .compozy 폴더와 같은 사이드카(Sidecar) Git 레포지토리(compozy/skeeper 활용)에 저장합니다.

이것이 왜 혁신적일까요? 다음 단계의 에이전트는 이전의 난잡한 대화 기록을 전부 로드하는 것이 아니라, 정제된 최종 마크다운(예: tech-spec.md)만 읽어 들입니다. 즉, 중간 기억(Mid-term memory)을 파일 시스템에 오프로딩함으로써 모델의 컨텍스트 윈도우를 극한으로 아끼면서도, 자동 압축(Compaction)을 통해 가장 신선하고 핵심적인 컨텍스트만 유지하는 영리한 아키텍처입니다.

비교 항목	기존 AI Chat & IDE (예: Cursor, Copilot)	Compozy 오케스트레이션 파이프라인
컨텍스트 관리	세션 내 임시 저장 (휘발성, 토큰 낭비 심함)	마크다운 기반 아티팩트 영구 저장 (`skeeper` 사이드카 버전 관리)
SDLC 커버리지	코드 작성 및 자동완성 단계에 국한	아이디어 기획(PRD)부터 코드 리뷰 및 자체 수정까지 전체 커버
실행 모델	단일 에이전트의 순차적 실행 및 대기	40+ 멀티 에이전트 병렬 실행, 지수적 백오프 기반 재시도
코드베이스 인지	벡터 DB 기반의 단순 시맨틱 검색 의존	`compozy/gograph` 기반의 코드베이스 그래프 분석 후 태스크 주입

3. 선언적 YAML과 병렬 실행 엔진

특히 놀라운 것은 YAML과 명령줄을 통해 제어되는 실행 엔진입니다. 아래는 Compozy가 다중 에이전트 작업을 병렬로 처리하는 설정의 컨셉을 보여주는 구조적 스니펫입니다.

  
# .compozy/workflows/feature-add.yaml (개념적 예시)
pipeline:
  stages:
    - name: "PRD Generation"
      agent: "claude-3-5-sonnet"
      input: "idea.md"
      output: "prd.md"
    - name: "Task Breakdown"
      agent: "gpt-4o"
      context: ["prd.md", "architecture.md"]
      action: "split_tasks"
    - name: "Concurrent Execution"
      type: "parallel"
      timeout: "300s"
      retries: 3
      agents: 
        - name: "frontend-agent"
          ide: "cursor"
        - name: "backend-agent"
          ide: "gemini-1.5-pro"

  
# 터미널에서 파이프라인을 실행하는 단 하나의 명령어
$ compozy run --from idea
[10:00:01] INFO  compozy run --from idea
[10:00:02] PRD   Generating Product Requirements Document...
[10:00:04] SPEC  Creating TechSpec with architecture plan...
[10:00:06] TASK  Breaking spec into 4 independent tasks... (Spawning parallel agents)

단일 명령어 안에서 각 태스크의 성격에 맞는 최적의 에이전트를 핀셋으로 골라내어 동시에 띄웁니다. 프론트엔드는 Cursor에 물리고, 복잡한 데이터베이스 스키마 설계는 추론에 강한 모델에 맡기는 병렬 오케스트레이션이 CLI 백그라운드에서 실시간 터미널 UI와 함께 돌아갑니다.

Pragmatic Use Cases: 뻔한 Hello World를 넘어서

그렇다면 이 기술을 현업의 진흙탕 같은 실무에서 어떻게 써먹을 수 있을까요? ‘간단한 ToDo 앱 만들기’ 같은 유치한 예시는 버리겠습니다. 현업 시니어들이 마주칠 법한 구체적인 시나리오를 살펴봅시다.

시나리오 1: 거대 레거시 시스템의 도메인 분리 (feat. AST 메타데이터)

오래된 Spring Boot 모놀리식 서버에서 특정 결제 모듈을 마이크로서비스(MSA)로 분리해야 한다고 가정해 보죠. 일반적인 AI 도구에게 수십만 줄의 코드를 던져주면 컨텍스트가 터져버립니다. 하지만 Compozy 환경에서는 compozy/gograph를 활용해 기존 프로젝트의 의존성(Dependency) 및 AST(추상 구문 트리) 그래프 메타데이터를 추출합니다. 이 정제된 구조도를 초기 컨텍스트로 주입하여 --from idea 로 실행하면, AI는 전체 코드가 아닌 인터페이스 구조를 분석해 정교한 tech-spec.md를 뽑아냅니다. 이후 파이프라인이 태스크를 독립적으로 쪼개고 에이전트를 띄웁니다. 대규모 트래픽 스파이크나 API Rate Limit(HTTP 429)이 발생하더라도, Compozy 엔진은 설정된 타임아웃과 재시도 로직에 따라 에이전트를 안정적으로 복구시킵니다.

시나리오 2: 스스로 버그를 고치는 자가 치유 루프 (Provider-agnostic Reviews)

개발자들을 가장 지치게 하는 것은 무한 수정 핑퐁입니다. Compozy는 이 문제에 대한 해답으로 독립적인 리뷰 시스템 통일화를 제시합니다. 코드가 작성된 후, GitHub PR이나 CodeRabbit에 달린 리뷰 코멘트들을 Compozy가 패치해 옵니다. 그리고 모든 피드백을 단일 마크다운 포맷으로 정규화(Normalize)한 뒤, compozy/codex-loop를 통해 에이전트 스스로 리뷰 피드백을 분석하고 코드를 수정하는 과정을 목표치에 도달할 때까지 무한 반복합니다. 우리는 그저 터미널에서 에이전트들이 서로 피드백을 주고받으며 코드를 고치는 로그를 감상하며 커피를 마시면 됩니다.

Honest Review & Trade-offs: 진짜 장단점과 비판적 시선

하지만 아무리 뛰어난 기술이라도 은탄환(Silver Bullet)일 수는 없습니다. 10년 차 엔지니어의 깐깐한 시선으로 볼 때, 실무 도입 전 반드시 각오해야 할 치명적인 트레이드오프가 존재합니다.

Garbage In, Garbage Out의 폭발적 연쇄 (캐스케이딩 효과): SDLC 전체를 자동화한다는 것은 양날의 검입니다. 만약 초기 1단계(PRD)나 2단계(TechSpec)에서 AI가 비즈니스 로직을 잘못 이해하여 미세한 환각(Hallucination)을 일으켰다면 어떻게 될까요? 그 오염된 마크다운 문서가 병렬로 쪼개진 하위 에이전트들에게 뿌려지며, 잘못된 구조의 코드가 기하급수적으로 양산됩니다. 파이프라인이 자동화될수록, 초기에 인간 개발자가 스펙 문서를 철저히 검증해야 하는 부담은 오히려 가중됩니다.
자본주의의 쓴맛, 무자비한 API 과금 리스크: “40개의 멀티 에이전트를 병렬로 띄워 알아서 개발하게 둔다”는 말은 낭만적으로 들리지만, 백엔드에서는 당신의 OpenAI/Anthropic API 크레딧이 분당 수만 원씩 타들어 가고 있다는 뜻입니다. 에이전트가 복잡한 컨텍스트를 들고 리뷰 수정 무한 루프 버그에라도 빠진다면? 그 달 클라우드 청구서는 끔찍한 재앙이 될 수 있습니다.
가파른 러닝 커브와 프로세스 강제(Workflow Lock-in): 특정 AI 벤더에 종속되지는 않지만, Compozy가 강제하는 ‘마크다운 기반 7단계 파이프라인’에 조직의 개발 프로세스를 억지로 끼워 맞춰야 하는 락인이 발생합니다. “그냥 스크립트 하나 빨리 짜고 싶은데?” 하는 상황에서는 거창한 PRD와 Spec을 생성해야 하는 이 시스템이 오히려 엄청난 개발 오버헤드로 작용합니다.

Closing Thoughts: AI는 이제 에디터를 벗어났다

Compozy의 아키텍처를 밑바닥까지 뜯어보면서 저는 하나의 거대한 패러다임 시프트를 확신했습니다. AI 코딩의 시대는 이미 ‘에디터 안의 단순 자동완성(Autocomplete)’을 넘어, 독립적인 워커 노드들을 관리하는 ‘에이전트 오케스트레이션(Agent Orchestration)’의 영역으로 진입했습니다.

과거 우리가 서버를 하나하나 수동으로 세팅하다가 Kubernetes의 등장과 함께 오케스트레이션의 시대를 맞이했듯, 이제는 파편화된 프롬프트와 복붙의 늪에서 벗어나 체계적인 AI 파이프라인을 설계하는 자만이 살아남을 것입니다.

당장 내일 아침, 회사의 메인 프로덕션 코드에 Compozy를 전면 도입하라고 무책임하게 권하진 않겠습니다. 아직은 초기 오픈소스 특유의 불안정성이 존재하고, 비용 최적화 측면에서 튜닝해야 할 변수가 너무나 많습니다.

“하지만, 이번 주말에 개인 사이드 프로젝트를 이 녀석의 파이프라인에 한 번 던져보십시오. 단일 터미널 창에서 스스로 기획서를 쓰고, 병렬로 워커를 띄워 코드를 짜고, 깃허브 리뷰를 파싱해 스스로 버그를 고치는 광경을 목격하는 순간, 당신이 알던 ‘개발’과 ‘소프트웨어 엔지니어링’의 정의가 영원히 바뀌게 될 것입니다.”

현업에서 끝없이 쏟아지는 레거시와 싸우며 프롬프트 창에 코드를 복붙하느라 지치신 분들. 이제는 무의미한 타이핑을 멈추고, 당신만의 AI 파이프라인을 설계할 때입니다.

Tech

This post is licensed under CC BY 4.0 by the author.