Pipeline

순서대로 진행되는 단계들로, 조사 → 구현 → 검토 순으로 작업을 전달하며, 품질 게이트를 통해 불량 핸드오프를 초기에 차단합니다.

대부분의 실제 코딩 세션은 이미 파이프라인 형태입니다: 조사하고, 구현하고, 검토합니다. 각 에이전트의 출력은 다음 에이전트의 입력이 됩니다. Pipeline은 이 구조를 명시적으로 만들어, 터미널 사이에서 텍스트를 직접 옮겨 다니지 않아도 되게 합니다.

Builder에서 Cmd+2 / Ctrl+2로 만들거나, 컴포저에서 바로 시작할 수 있습니다.

단계

파이프라인은 순서가 지정된 단계 목록입니다. 각 단계에는 에이전트, 모델, 그리고 간략한 지시가 포함되며, 이전 단계의 출력을 입력으로 받습니다.

순서가 즉흥적이 아니라 선언되었기 때문에, 어떤 에이전트가 무엇을 하는지 한눈에 파악할 수 있으며, 에이전트들도 마찬가지입니다.

품질 게이트

각 단계는 전달받은 작업을 승인하거나 거부할 수 있습니다.

이것이 이 기능의 핵심입니다. 게이트가 없다면, 문제가 있는 초안에 대한 꼼꼼한 검토가 실제로 발생하며 비용이 큽니다. 게이트가 있다면, 거부는 4단계가 아닌 2단계에서 일어납니다.

거부는 제한되어 있습니다 — 기본적으로 두 번까지. 그 이후에는 파이프라인이 사용자에게 에스컬레이션되며, 의견이 다른 두 에이전트가 무한 반복하지 않습니다.

컴포저에서 시작하기

문장으로 작성하세요:

auth 버그를 조사하고, grok이 수정안을 작성하고, opencode가 검토합니다

이것은 Pipeline으로 인식되며, 현재 터미널이 1단계가 됩니다. 그리고라는 단어가 신호입니다 — Auto 모드의 Agent Input이 Pipeline을 선택한 이유를 알려줍니다.

실행 모니터링

Mission Control은 실행 중인 파이프라인의 단계 스트립을 보여주므로, 4단계 검토 디버깅이 조직도가 아닌 실제 4단계 검토처럼 보입니다.

중단된 실행 — 의도적인 중지 포함 — 은 Run & Logs에 계속 표시되며, 실행 상세에서 오류 원인을 확인할 수 있고, 오케스트레이션 로그가 첨부된 zip 파일로보낼 수 있습니다.

Pipeline 또는 Hierarchy?

  • 작업에 순서가 있을 때 Pipeline: 이것, 그것, 저것 순서로.
  • 작업에 명령 체계가 있을 때 Hierarchy: 리드가 작업을 분배하고 결과를 수집하는 구조.
  • 작업이 병렬이고 에이전트들이 동등한 관계일 때 Team 또는 Swarm.

Pattern Guide — Agent Input의 모드 컨트롤 옆에 있는 ? — 에서 다섯 가지를 나란히 비교하며, 각 패턴을 구분하는 핵심 동사를 보여줍니다.

관련 문서