TL;DR

  • Claude Code, Codex 등을 사용하는 코딩 에이전트의 병렬 세션은 세션이 세 개에 이르면 사람의 컨텍스트와 관리 능력이 병목이 되며, 이를 작업 큐와 자원 제한으로 해결하는 Cezar를 구축함.
  • Open Mercato는 릴리스마다 300~500개 풀 리퀘스트(PR)를 처리하며, 에이전트 세션을 하나씩 지켜보는 방식은 규모에 맞지 않음.
  • Cezar는 여러 저장소의 작업을 대기열에 넣어 병렬 실행하고, 최대 동시 실행 수나 메모리(RAM) 예산을 준수하며, 에이전트가 사람의 입력을 기다리면 해당 슬롯을 바로 비움.
  • 기존 Claude Code, Codex, OpenCode, pi 구독을 활용하며, 마크다운(Markdown) 스킬과 야믈(YAML) 워크플로, 셸 검증 단계를 조합해 반복 작업을 자동화함.
  • 같은 작업을 두세 에이전트에 맡겨 구현 결과를 나란히 비교하는 병렬 변형 기능을 제공하며, 무료이고 MIT 라이선스로 공개됨.

병목이 된 지점

  • Open Mercato는 인공지능(AI) 우선 고객 관계 관리·전사적 자원 관리(CRM/ERP) 프레임워크이며, 일주일에서 2주 간격으로 릴리스를 배포함.
  • 릴리스마다 300~500개 PR이 포함되므로 에이전트 세션을 하나씩 지켜보는 방식은 감당하기 어려움.
  • 에이전트가 작업하는 동안 터미널을 지켜보는 것은 회사에서 가장 비싼 유휴 시간이며, 숙련된 엔지니어가 기다리게 됨.
  • 에이전트 비용은 이미 지불하고 있었지만, 에이전트를 인프라처럼 운영할 방법이 없었음.
  • 병렬 세션을 세 개 실행하자 사람의 컨텍스트가 가득 차고, 탭과 입력 대기 중인 터미널을 오가며 브랜치와 작업을 헷갈리는 문제가 발생함.
  • 한 엔지니어는 “병렬 세션 세 개를 돌리니 제 컨텍스트 윈도우가 가득 찼다”고 표현함. 이를 개인 생산성 문제가 아니라 엔지니어링 문제로 다룬 결과 Cezar가 만들어짐.

Cezar의 작동 방식

  • Cezar는 인공지능 코딩 에이전트를 위한 관제석임.
  • 작업을 등록하면 대기열에 넣고 병렬 실행하며, 사람의 개입이 필요한 시점에 알림을 보냄.
  • 여러 저장소에 걸쳐 10개, 20개, 30개 작업을 대기열에 넣을 수 있음.
  • 최대 병렬 실행 수 또는 메모리 예산을 제한 조건으로 설정할 수 있음.
  • 에이전트가 입력을 기다리며 멈추면 해당 슬롯을 즉시 비우고 다음 작업을 시작하므로, 입력 대기 작업이 실행 슬롯을 붙잡지 않음.
  • 기존 Claude Code, Codex, OpenCode, pi 구독을 사용하며, 별도 API 키가 필요하지 않고 추가 비용 청구도 발생하지 않음.

야믈 워크플로와 마크다운 스킬

  • 일회성 수정에는 단일 프롬프트로 충분하지만, 반복 작업에는 절차가 필요함.
  • 스킬은 저장소 또는 팀 공유 저장소에 보관하는 마크다운 플레이북임.
  • 워크플로는 스킬을 연결한 야믈(YAML) 체인이며, 코딩 없이 빌더에서 순서를 드래그해 조정할 수 있음.
  • 셸 검사 단계는 각 작업 단계 사이에서 검증 관문 역할을 함.
  • 자동 수정 워크플로는 다음 단계로 구성됨.
  • 재현 확인: 버그가 실제로 재현되는지 확인함.
  • 근본 원인 분석: 버그의 발생 지점을 찾음.
  • 구현: 수정 사항을 작성함.
  • 검토 반복: 검사를 통과할 때까지 다듬음.
  • 초안 PR: 사람이 검토할 수 있도록 넘김.
  • 워크플로를 한 번 작성해 모든 버그에 실행할 수 있으며, 한 번의 클릭으로 GitHub 이슈를 적절한 워크플로가 연결된 실행 중인 에이전트 작업으로 전환함.
  • ‘먼저 계획(Plan first)’ 모드에서는 에이전트가 작업 체인을 작성하고, 실행 전에 사람이 승인함.

병렬 변형

  • 같은 작업을 에이전트 두세 개에 맡기면 Cezar가 구현 결과를 나란히 보여주고, 사용자가 가장 나은 결과를 선택함.
  • 코드에 대한 저비용 A/B 테스트 방식이며, 어떤 모델이 특정 코드베이스의 어떤 작업 유형을 더 잘 처리하는지 빠르게 확인할 수 있음.
  • 벤치마크만으로는 이런 차이를 알 수 없음.

사용 및 공개 정보