Orca Git worktree 데모, 에이전트 답이 섞일 때 비교부터 분리하는 법
여러 코딩 에이전트에 같은 일을 맡길 때는 한 폴더에서 번갈아 돌리기보다 처음부터 작업 공간을 나누는 편이 낫습니다. Orca는 에이전트마다 Git worktree를 붙여 같은 프롬프트의 결과를 나란히 비교하는 흐름을 지원합니다. 승자를 자동으로 고르는 도구가 아니라, 사람이 고를 수 있게 결과를 분리해 주는 작업대입니다.
30초 요약
- 같은 작업에는 같은 프롬프트와 평가 조건을 둡니다.
- 에이전트마다 별도 worktree를 두고 diff·테스트·요구사항으로 비교합니다.
- 병합은 한 후보만 고른 뒤에 합니다.
Orca가 나누는 것은 에이전트가 아니라 작업대입니다
Orca 공식 문서는 Codex, Claude Code, Cursor CLI 같은 코딩 에이전트를 나란히 실행하는 데스크톱 IDE라고 설명합니다. 각 작업에 Git worktree와 에이전트 터미널을 붙이므로 stash와 브랜치 전환을 반복하지 않고 후보를 비교할 수 있습니다.
Git worktree는 하나의 저장소에 연결된 여러 작업 트리를 만드는 Git 기능입니다. 같은 원본에서 복사한 세 장을 책상에 놓는 모습에 가깝습니다. 분리되는 것은 작업 디렉터리와 브랜치 맥락이지, 검토 책임까지 사라지는 것은 아닙니다.
같은 입력, 다른 브랜치로 하는 하루 데모
목표는 ‘어느 모델이 최고인가’를 선언하는 일이 아닙니다. 작은 기능 하나를 정하고, 같은 요구사항을 받은 세 후보가 남긴 수정 범위를 비교하는 것입니다.
입력: "기존 list 명령에 --json 옵션을 추가하세요.
기존 텍스트 출력은 유지하고, 테스트를 추가하거나 수정하세요.
바꾼 파일과 검증 방법을 마지막에 짧게 설명하세요."
출력: agent/codex-json, agent/claude-json, agent/opencode-json의
각각의 diff·테스트 결과·설명
평가 조건을 프롬프트에 넣어야 합니다. “구현해 줘”만 쓰면 문제 범위를 다르게 잡아 비교가 흐려집니다.
문서 기반 최소 명령
아래는 Git 공식 문서의 git worktree add -b <새-브랜치> <경로> 의미를 이용한 예시입니다. 특정 저장소에서 실행한 기록이 아니라 구조를 이해하기 위한 문서 기반 예시입니다.
git status
git worktree add -b agent/codex-json ../demo-codex main
git worktree add -b agent/claude-json ../demo-claude main
git worktree add -b agent/opencode-json ../demo-opencode main
git worktree list
각 worktree에서 Orca로 별도 에이전트 세션을 열고 같은 프롬프트를 전달합니다. 한쪽의 수정이 다른 후보 작업 디렉터리를 덮어쓰지 않는 것이 핵심입니다.
main이라는 기준 브랜치 이름과 테스트 명령은 저장소마다 다릅니다. 데모 전에는 기준 브랜치와 깨끗한 작업 상태를 먼저 확인해야 합니다.
결과는 세 칸으로 고릅니다
에이전트의 설명은 빠르게 읽되, 선택 근거는 저장소에 남은 것으로 잡는 편이 안전합니다. 좋아 보이는 설명보다 재현 가능한 검증 명령이 우선입니다.
| 비교 칸 | 볼 것 | 탈락 신호 |
|---|---|---|
| 요구사항 | --json과 기존 출력이 공존하는가 |
요청하지 않은 인터페이스 변경 |
| 변경 범위 | 필요한 파일만 바꿨는가 | 무관한 리팩터링·잠금 파일 대량 변경 |
| 검증 | 실제 테스트·린트 명령이 있는가 | 실행하지 않은 검증을 했다고 적음 |
세 에이전트면 첫 비교에 충분합니다. 후보를 늘릴수록 읽고 검증하는 비용도 함께 늘어납니다.
병합과 제품화의 경계
선택한 후보의 실제 테스트·린트 명령을 다시 실행하고 diff를 읽은 뒤에만 커밋 또는 병합으로 넘어갑니다. 비교가 끝난 worktree는 필요할 때 git worktree remove <경로>로 정리할 수 있습니다.
여러 후보의 좋은 부분을 즉석에서 합치는 일은 새 브랜치와 새 검증 기준을 둔 다음 작업으로 분리하는 편이 낫습니다. .env, 로컬 데이터베이스, 포트, 외부 API 키는 worktree 사이에서 충돌하거나 공유될 수 있으므로 별도 실행 규칙도 필요합니다.
이 흐름은 작은 버그 수정, UI 구현안 비교, 테스트 추가처럼 diff로 검토 가능한 일에 잘 맞습니다. 긴 설계 논의나 배포·데이터 마이그레이션처럼 실행 비용이 큰 일은 한 명의 담당 흐름에서 검토 지점을 촘촘히 두는 편이 낫습니다.
바이브코딩으로 확장할 때는 “가장 좋은 것을 골라 줘”보다 “변경 파일·변경 이유·실제로 실행한 테스트만 보고해”라고 요구하세요. 병렬 작업의 속도보다 먼저 점검할 것은 공유 자원과 최종 리뷰 책임입니다.
작업 환경을 함께 정리한다면
여러 창과 외부 화면을 함께 쓰는 데스크 환경을 만들 때만 볼 만한 연결 허브 후보입니다. 실제 호환 포트는 카드의 상품 정보를 확인해야 합니다.
노트북·키보드·마우스를 한 자리에 두는 작은 작업대용 후보입니다. 코드 품질이나 에이전트 성능을 높이는 제품은 아닙니다.
이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.
출처
- Orca 공식 문서: What is Orca?
- Orca 공식 GitHub 저장소
- Orca 공식 변경 로그 — 2026-09-25 확인, 1.4.210 표기 확인
- Git 공식 문서: git-worktree
핵심 정리: 다섯 가지 질문과 답
Q. Orca가 여러 에이전트의 답을 자동으로 병합하나요?
아닙니다. 분리된 worktree와 비교 환경을 제공하고, 병합 후보는 사람이 검토해야 합니다.
Q. worktree를 만들면 파일이 완전히 독립적인가요?
작업 디렉터리와 브랜치 맥락은 분리되지만, 키·포트·로컬 데이터는 별도 관리가 필요합니다.
Q. 같은 프롬프트를 쓰는 이유는 무엇인가요?
입력 조건을 맞춰야 diff와 테스트를 같은 기준으로 비교할 수 있습니다.
Q. 첫 데모에는 몇 개 에이전트가 적당한가요?
세 개면 비교 흐름을 배우기에 충분합니다.
Q. 병합 직전에 반드시 할 일은 무엇인가요?
선택 후보의 실제 테스트·린트 명령을 다시 실행하고 diff를 검토합니다.
'AI > 오픈 소스 소개' 카테고리의 다른 글
| Kiro Crew 0.7.1, 재시작 뒤에도 이어지는 작업은 어디까지일까 (0) | 2026.09.27 |
|---|---|
| ConnectOnion 함수 도구 연결, 에이전트가 무엇을 했는지 기록까지 남기는 법 (0) | 2026.09.26 |
| Smithers 0.35.0 복구 데모, 실패한 에이전트 작업을 처음부터 다시 돌리기 전에 (0) | 2026.09.22 |
| VeloxQuant-MLX로 긴 대화를 붙잡을 때, 압축률보다 먼저 볼 것 (0) | 2026.09.21 |
| SandBase Harness, 도구 실행이 멈췄을 때 승인 흐름을 확인하는 법 (0) | 2026.09.20 |
댓글