포스트

Compozy로 AI 개발을 병렬화해도 될까: 스펙, 비용, 리뷰 루프

Compozy는 기획부터 리뷰까지 단계를 파일과 워크플로로 고정하는 데 유용하지만, 초반 스펙이 틀린 채 병렬 실행되면 한 에이전트보다 더 빠르게 잘못된 코드를 늘릴 수 있습니다.

Compozy는 원문 기준 Go 단일 바이너리와 선언적 워크플로로 여러 코딩 에이전트를 조율합니다. 프로젝트 사이트와 원문은 PRD, 기술 명세, 작업 분할, 구현, 리뷰를 단계화하고 마크다운 결과를 다음 단계의 상태로 넘기는 구조를 설명합니다. 세부 명령과 구성은 버전 한정 스냅샷입니다.

대화 대신 검토 가능한 산출물을 넘긴다

긴 채팅 전체를 다음 에이전트에 주면 토큰이 늘고 어느 결정이 확정됐는지 흐려집니다. PRD와 tech-spec 같은 파일로 인계하면 사람도 단계별 diff를 검토할 수 있고 실패한 지점에서 다시 시작하기 쉽습니다. Skeeper 같은 사이드카 버전 관리라는 원문의 설명도 이 목적에 가깝습니다.

파일이 있다고 진실이 되는 것은 아닙니다. 각 산출물에는 원문 요구, 확정 결정, 아직 모르는 항목, 완료 조건과 근거 코드 경로를 구분해야 합니다. 다음 단계로 넘어가기 전에 스키마나 인터페이스 같은 고비용 결정은 사람이 승인하는 게 안전합니다.

병렬화는 독립성이 증명된 작업만 한다

gograph 기반 코드 구조 분석과 작업 분할은 겹치는 영역을 찾는 데 도움을 줄 수 있습니다. 프론트엔드와 백엔드가 같은 API 계약을 동시에 추측하거나 여러 워커가 공통 파일을 수정하면 병렬성이 병합 비용으로 돌아옵니다. 공통 계약을 먼저 고정한 뒤 독립된 수직 조각만 동시에 실행해야 합니다.

원문의 ‘단일 바이너리’는 Compozy 실행 파일의 배포 형태를 가리킵니다. 실제로 호출하는 Codex, Claude Code나 다른 에이전트의 설치, 인증과 비용까지 사라지는 것은 아닙니다. 각 워커에 필요한 도구와 파일 권한을 최소화하고 운영 자격 증명은 제공하지 않습니다.

리뷰 루프는 목표와 상한이 있어야 한다

리뷰 코멘트를 공통 마크다운으로 정규화하고 에이전트가 수정하도록 하면 반복 작업을 줄일 수 있습니다. 그러나 ‘코멘트 0개’만 목표로 두면 에이전트가 검사를 약화하거나 리뷰어와 같은 잘못된 전제를 공유할 수 있습니다. 테스트, 정적 검사, 변경 범위와 사람 승인 같은 독립된 종료 조건이 필요합니다.

재시도 횟수, 전체 시간, 동시 워커와 비용을 워크플로에 명시하고 같은 오류가 반복되면 중단합니다. PRD부터 전체를 다시 돌리기보다 실패한 단계와 영향을 받은 하위 산출물만 무효화해야 불필요한 호출과 변경을 줄일 수 있습니다.

작은 기능으로 프로세스 비용을 잰다

기존에 완료 시간이 알려진 중간 크기 기능 하나를 골라 수동 워크플로와 Compozy 흐름을 비교합니다. 계획 시간, 모델 호출 비용, 병합 충돌, 리뷰 반복, 사람이 고친 diff와 전체 리드 타임을 기록하세요. 생성 속도만 비교하면 스펙 검토와 통합 비용이 빠집니다.

간단한 스크립트까지 모든 단계를 강제하면 오버헤드가 더 큽니다. 위험도에 따라 PRD, 명세 단계를 생략할 수 있는 경량 경로와, 데이터, 배포 변경에는 승인 단계를 추가하는 엄격 경로를 나눌 때 조직의 SDLC에 도구를 맞출 수 있습니다.

마크다운 산출물은 어떻게 상태가 되는가?

PRD, 기술 명세와 작업 목록이 단순 설명 파일이면 다음 에이전트가 임의로 해석합니다. 각 파일에 입력 버전, 작성 시점의 기준 커밋, 확정, 미확정 항목, 소유자와 승인 상태를 넣어야 워크플로 상태로 쓸 수 있습니다. 요구가 바뀌면 문장 하나만 고치는 대신 영향을 받는 명세와 작업을 추적해 해당 산출물을 다시 검증합니다.

예를 들어 PRD의 인증 방식이 바뀌었는데 이전 기술 명세를 그대로 구현하면 모든 워커가 일관되게 틀린 코드를 만들 수 있습니다. 단계 사이에 스키마 검사를 두어 필수 항목과 승인 서명을 확인하고, 이전 단계의 내용 해시를 다음 산출물에 기록하면 오래된 입력을 발견하기 쉽습니다. 모델 대화는 보조 기록이고 저장소에 있는 승인된 파일이 실행의 기준이어야 합니다.

‘완료’의 의미도 단계별로 다릅니다. 작업 분할 완료는 코드 생성이 아니라 각 작업의 수정 범위, 선행 의존성, 테스트와 롤백 방법이 정해졌다는 뜻입니다. 구현 완료는 로컬 테스트 통과만이 아니라 최신 통합 브랜치 위에서 계약 테스트가 통과했다는 뜻으로 정의할 수 있습니다.

작업 DAG와 병합 순서는 어떻게 맞추는가?

코드 구조 분석이 의존 후보를 보여 줘도 업무 의미의 의존성까지 자동으로 확정하지는 못합니다. 공통 API, 데이터베이스 마이그레이션과 feature flag를 먼저 DAG의 선행 노드로 두고, 그 계약이 병합된 커밋을 후행 워커의 기준으로 사용합니다. 같은 파일을 수정하지 않아도 한 작업의 출력 형식을 다른 작업이 소비하면 의존 관계입니다.

병렬 워커마다 허용 경로와 예상 write set을 선언합니다. 예상 밖의 공통 파일이나 잠금 파일을 건드리면 자동 병합하지 않고 재계획합니다. 각 브랜치의 단위 테스트가 통과해도 최신 통합 브랜치 위에서 재실행해야 하며, 병합 큐는 선행 계약과 작은 변경부터 처리합니다.

의미 충돌은 Git의 텍스트 충돌로 드러나지 않을 수 있습니다. 한 워커가 에러 코드를 바꾸고 다른 워커가 옛 코드를 UI 분기에 사용하면 자동 병합은 성공합니다. 계약 fixture와 소비자 테스트를 선행 단계에서 만들고 후행 작업이 그 테스트를 바꾸려 하면 별도 승인을 요구하는 방식이 유용합니다.

실패한 단계만 안전하게 다시 실행하려면?

모든 단계의 입력과 출력을 실행 ID로 묶고, 어떤 산출물이 어느 버전에서 만들어졌는지 기록합니다. 리뷰 단계가 실패하면 구현과 리뷰만 다시 돌릴 수 있지만, PRD 자체가 바뀌었다면 기술 명세 이후를 무효화해야 합니다. 재시작 지점은 비용이 싼 곳이 아니라 변경이 영향을 미치는 가장 이른 단계입니다.

재시도에는 최대 횟수, 시간, 모델 호출 비용과 diff 크기를 둡니다. 같은 테스트가 반복 실패하거나 워커가 허용 범위를 벗어나면 자동 수정 대신 원인 요약과 마지막 상태를 사람에게 넘깁니다. 재시도 때 이전 실패 대화를 전부 주입하기보다 확인된 사실, 실패한 명령, 폐기된 가설을 구분해야 잘못된 전제가 고착되지 않습니다.

외부 서비스 장애와 코드 오류도 나눕니다. 패키지 저장소나 테스트 API가 일시적으로 실패했다면 코드 변경 없이 backoff할 수 있지만, assertion 실패를 인프라 문제로 취급해 무한 재시도하면 비용만 늘어납니다. 상태 파일은 성공, 실패뿐 아니라 blocked_external, needs_decision, invalid_input 같은 원인을 표현해야 합니다.

에이전트별 권한과 비용은 어디서 막는가?

단일 바이너리로 오케스트레이터를 배포해도 하위 에이전트의 모델 비용, 도구 설치와 자격 증명은 별도입니다. 문서 분석 워커에는 읽기 권한만, 테스트 워커에는 격리된 데이터와 필요한 명령만 제공합니다. 원격 push, 데이터 마이그레이션과 배포는 일반 코드 편집 흐름 밖의 승인 단계로 둡니다.

비용 예산은 전체 워크플로와 단계별로 함께 둡니다. 한 리뷰 루프가 예산을 소진해 다음 필수 테스트를 실행하지 못하는 상황을 막기 위해 단계별 상한과 전체 잔여량을 확인합니다. 비용을 줄이려고 검증 단계를 생략하지 말고, 낮은 위험 작업은 작은 모델이나 짧은 문맥을 쓰는 식으로 경로를 나눕니다.

로그에는 모델 요청 수, 토큰, 벽시계 시간, 변경 파일과 승인자를 공통 실행 ID로 남깁니다. 다만 프롬프트나 산출물에 비밀과 사용자 데이터가 들어갈 수 있으므로 보존 범위와 마스킹 정책이 필요합니다. 재현 가능성은 모든 민감 원문을 영구 저장한다는 뜻이 아닙니다.

파일럿의 합격 기준은 무엇인가?

과거에 완료한 중간 크기 기능과 비슷한 업무를 고르고 기존 수동 흐름을 기준선으로 둡니다. PRD 수정 횟수, 첫 코드 생성 시간, 전체 리드 타임, 모델 비용, 병합 충돌, 리뷰에서 사람이 고친 diff, 배포 전 발견 결함을 측정합니다. 생성된 코드 줄 수나 동시 워커 수는 품질 지표가 아닙니다.

첫 파일럿은 되돌리기 쉬운 내부 기능으로 제한하고 데이터 마이그레이션과 외부 공개 배포는 제외합니다. 두세 번 반복해 워크플로 자체를 배우는 초기 비용과 안정 상태를 구분하세요. 수동 방식보다 빠르더라도 승인 근거와 실패 상태를 설명할 수 없다면 프로덕션 범위를 넓히기 어렵습니다.

경량, 표준, 엄격 세 경로를 정의하면 모든 변경에 동일한 오버헤드를 강제하지 않아도 됩니다. 문서 수정은 계획과 테스트만, 일반 기능은 명세, 구현, 리뷰, 인증, 결제, 마이그레이션은 보안 검토와 배포 승인을 추가하는 식입니다. 자동화의 목적은 단계를 많이 만드는 것이 아니라 위험에 맞는 검증을 빠뜨리지 않는 것입니다.

원문과 버전 확인

함께 읽으면 이해가 이어지는 글

자주 묻는 질문

Compozy를 쓰면 PRD부터 코드 리뷰까지 완전 자동화할 수 있나요?

단계를 자동 연결할 수 있어도 요구사항, 공통 계약, 배포 위험의 판단은 남습니다. 고비용 결정을 승인 지점으로 두고 검증 가능한 산출물만 다음 단계에 넘겨야 합니다.

여러 코딩 에이전트는 어떤 작업을 병렬로 실행해야 하나요?

수정 경로와 공개 인터페이스가 겹치지 않고 독립 테스트가 가능한 작업만 병렬화합니다. 공통 스키마와 생성 파일은 먼저 고정하거나 단일 소유자에게 맡깁니다.

워크플로 실패 시 처음부터 다시 실행해야 하나요?

아닙니다. 실패 단계와 그 산출물에 의존한 하위 단계만 무효화하고, 기준 커밋, 입력 버전, 예산을 확인한 뒤 재실행해야 중복 비용과 엇갈린 상태를 줄일 수 있습니다.

THE END / OPSOAI

여기까지 읽었습니다

핵심 장면을 한 번 더 떠올려 보세요. 이해가 남았다면 이 책은 제 역할을 다했습니다.

다른 책 고르기
표지 1 —

←→ 키와 좌우 스와이프를 지원합니다. 읽던 페이지는 이 기기에 저장됩니다.

CONTENTS

이 책의 목차

    12개 장 20 분읽는 시간