(3/4) Orca 결과 검수 — diff 리뷰·Design Mode·브라우저
🐳 Orca — 병렬 AI 에이전트 오케스트레이션 4부작 — Claude Code·Codex 같은 코딩 에이전트를 여러 개 동시에 굴리고, 각자 격리된 git worktree 에서 경쟁시킨 뒤 제일 나은 결과만 골라 합치는 데스크톱 도구 Orca 를 실전 워크플로우 중심으로 정리했어요. 먼저 Orca 가 뭐고 왜 필요한지 전체 그림을 잡고(1편), add→worktree→agent→split→diff→ship 첫 3-에이전트 세션을 손에 익히고(2편), diff 리뷰·Design Mode·브라우저로 결과를 검수하고(3편), 원격(SSH·VPS)·모바일·CLI 로 스웜을 확장하는 것(4편)까지 이어집니다. 전체 4편.
- Orca 란 무엇인가 — 병렬 에이전트 ADE 의 전체 그림
- 첫 3-에이전트 세션 — add→worktree→agent→split→diff→ship
- 결과 검수 — diff 리뷰·Design Mode·브라우저 ← 지금 글
- 스웜 확장 — 원격(SSH·VPS)·모바일·CLI 자동화
Summary
2편에서 add→worktree→agent→split→diff→ship 한 바퀴를 돌렸어요. 거기서 “diff 를 골라 합친다”고 슥 지나갔는데, 사실 여기가 Orca 를 제대로 쓰느냐 마느냐가 갈리는 자리예요.
에이전트가 짠 코드를 그냥 믿고 머지하면, 병렬로 세 개를 굴린 의미가 없어요. 세 개 중 가장 그럴듯해 보이는 것을 고르는 게 아니라, 실제로 맞는 것을 골라야 하니까요. 그러려면 사람이 검수자로 개입하는 도구가 필요한데, Orca 는 그걸 세 갈래로 줘요.
💡 이 글에서 다루는 것
- 왜 “검수”가 병렬 에이전트의 진짜 핵심인지
- diff 줄에 코멘트 달아 에이전트에게 되돌리는 리뷰 왕복
- 코드 출처 표시(attribution) — 이 줄 누가 짰지?
- Design Mode — UI 버그를 코드 말고 화면을 클릭해서 잡기
- worktree 별 브라우저 탭 — 결과를 눈으로 확인
- Orca 안에서 편집·커밋까지 (터미널로 안 나가고)
1. 왜 “검수”가 진짜 핵심인가
코딩 에이전트가 내놓는 코드에는 고약한 특징이 하나 있어요. 틀린 코드도 아주 그럴듯하게 생겼다는 거예요. 변수명도 깔끔하고, 주석도 달려 있고, 언뜻 읽으면 완벽해 보이는데 정작 엣지 케이스에서 조용히 틀려요.
병렬로 세 개를 굴리면 이 위험이 오히려 세 배가 돼요. 셋 다 그럴듯하게 생겼으니까요. 그래서 “제일 예뻐 보이는 걸 고르기”는 함정이에요. 필요한 건 “실제로 맞는지 확인하는 절차” 예요.
여기서 사람의 역할이 분명해져요. 2편에서 “사람의 자리가 앞(뭘 시킬까)과 뒤(누구 걸 조립할까)로 옮겨간다”고 했는데, 이 ‘뒤’가 바로 검수예요. 코드를 직접 타이핑하지 않는 대신, 사람은 최종 판단자가 돼요. Orca 의 리뷰 도구들은 전부 이 판단을 돕기 위한 거예요.
| 검수 방식 | 무엇을 볼 때 |
|---|---|
| diff 리뷰 + 코멘트 |
로직·구조가 맞는지 |
| 코드 출처 표시 | 이 줄을 사람이 vs 에이전트가 짰나 |
| Design Mode | 화면(UI)이 의도대로 나오나 |
| 브라우저 탭 | 실제로 돌려보면 어떤가 |
2. diff 리뷰 왕복 — 줄에 코멘트를 달아 되돌리기
가장 많이 쓰는 검수 도구예요. diff 뷰에서 어느 줄에든 코멘트를 달 수 있어요. GitHub PR 에서 리뷰 코멘트 다는 것과 똑같은 감각인데, 결정적으로 다른 게 있어요. 그 코멘트를 곧바로 그 에이전트에게 되돌릴 수 있다는 거예요.
흐름은 이래요.
- A(Claude Code) 의 diff 를 읽다가, 어떤 함수의 예외 처리가 빠진 걸 발견
- 그 줄에 코멘트: “여기 입력이 null 이면 터져요. 방어 코드 추가해줘”
- 코멘트를 에이전트에게 ship back → A 가 그 지적을 반영해 다시 수정
- 갱신된 diff 를 다시 확인
즉 리뷰가 일방적 지적이 아니라 왕복 대화가 돼요. GitHub 라면 “코멘트 달기 → 에이전트가 알림 받고 → 다시 작업 → 다시 PR” 이 여러 도구를 거쳐야 하는데, Orca 안에서는 한자리에서 돌아요. 리뷰하고, 고치라고 하고, 직접 손보고, 커밋까지 Orca 를 떠나지 않고 끝나요.
💡 이 왕복이 병렬 레이싱과 만나면 강력해져요. 세 결과를 놓고, “A 는 로직은 좋은데 예외 처리가 약하다 → 코멘트로 보강 요청”, “B 는 테스트가 좋다 → 그 부분만 채택” 식으로, 각 에이전트의 약점을 리뷰로 메꿔가며 최종본을 조립할 수 있어요.
3. 코드 출처 표시 — 이 줄, 누가 짰지?
검수할 때 은근히 중요한 정보가 “이 줄을 사람이 짰나, 에이전트가 짰나” 예요. 사람이 손댄 부분과 에이전트가 생성한 부분을 구분할 수 있으면, 리뷰의 무게를 어디에 둘지 정할 수 있거든요. 보통은 에이전트가 새로 만든 로직을 더 의심하며 보게 되죠.
Orca 는 diff 에서 이 출처(attribution) 를 표시해줘요. 여러 에이전트와 사람의 손이 섞인 worktree 에서, 어느 변경이 누구에게서 왔는지 추적할 수 있어요. “여긴 내가 아까 직접 고친 데고, 여긴 에이전트가 새로 만든 데” 를 구분해서 보면, 검수의 초점을 새로 생성된 위험 지점에 맞출 수 있어요.
4. Design Mode — UI 버그를 “클릭해서” 잡기
여기가 Orca 에서 제일 신선한 기능이에요. UI 버그를 고칠 때의 흔한 고통을 떠올려 보세요. “이 버튼 색이 이상해요”를 에이전트에게 설명하려면, 개발자 도구를 열고 → 해당 요소를 찾고 → 셀렉터를 복사하고 → HTML/CSS 를 긁어서 → 프롬프트에 붙여넣어야 했어요. 이 맥락 전달이 은근히 큰 일이었죠.
Design Mode 는 이걸 클릭 한 번으로 바꿔요. Orca 안에는 진짜 Chromium 브라우저 창이 떠 있는데, Design Mode 에서 화면의 UI 요소를 그냥 클릭하면 Orca 가 알아서:
- 그 요소의 HTML 과
- 적용된 CSS 와
- 화면 스크린샷 을
에이전트 프롬프트에 자동으로 담아 줘요. 사람은 “이 버튼 여백을 8px 줄여줘” 정도의 자연어만 얹으면 되고, 셀렉터를 찾고 복사하는 뒤치다꺼리가 사라져요.
이게 왜 좋냐면, UI 버그는 말로 설명하기 어려운 경우가 많아서예요. “그 카드 안의 두 번째 줄 텍스트”를 글로 정확히 지목하는 것보다, 화면에서 그냥 클릭하는 게 훨씬 정확하고 빨라요. 시각적인 문제를 시각적으로 지목하게 해주는 거죠.
💡 Design Mode 는 “화면 → 에이전트”로 맥락을 넘기는 다리예요. 반대로 에이전트가 고친 결과는 같은 Chromium 창에서 바로 새로고침해서 확인하면 되니까, 고치고 → 보고 → 또 지적하는 UI 루프가 한 창 안에서 빠르게 돌아요.
5. worktree 별 브라우저 탭 — 결과를 눈으로
Design Mode 의 바탕에는 worktree 마다 딸린 브라우저 탭이 있어요. 각 worktree 는 자기만의 코드 상태를 갖고 있으니까, 각자 띄운 로컬 서버도 다르겠죠. Orca 는 worktree 별로 브라우저 탭을 붙여줘서, A 가 고친 화면과 B 가 고친 화면을 각각 띄워놓고 눈으로 비교할 수 있어요.
2편의 레이싱을 여기까지 확장하면 이런 그림이 돼요.
| worktree | 코드 diff | 화면(브라우저) |
|---|---|---|
| A | Claude 의 수정 | A 서버의 렌더 결과 |
| B | Codex 의 수정 | B 서버의 렌더 결과 |
| C | Cursor 의 수정 | C 서버의 렌더 결과 |
코드 diff 만 비교하는 게 아니라 실제로 돌아가는 화면까지 나란히 놓고 고르는 거예요. UI 작업에서는 “코드가 맞아 보이는 것”보다 “화면이 맞게 나오는 것”이 진실에 가까우니까, 이 눈 검수가 결정적일 때가 많아요.
6. 편집도 Orca 안에서 — Monaco 에디터
검수하다 보면 “이 정도는 내가 직접 고치는 게 빠르겠다” 싶은 순간이 와요. 에이전트에게 되돌려 왕복하기엔 사소한, 한두 줄짜리 수정 같은 거요. 이때 터미널이나 다른 에디터로 나갈 필요 없이, Orca 안의 Monaco 에디터(VS Code 의 그 편집기예요)로 바로 손봐요. 자동 저장이 기본이라 저장 단축키를 신경 쓸 일도 없고, 드래그앤드롭으로 파일을 넣거나 마크다운을 보는 것도 돼요.
정리하면 검수의 세 가지 손이 한 화면 안에 다 있어요.
- 지적한다 → diff 줄에 코멘트 → 에이전트에게 되돌리기
- 직접 고친다 → Monaco 에디터로 바로 수정
- 눈으로 본다 → Design Mode·브라우저 탭으로 화면 확인
그리고 최종본이 되면 그 자리에서 커밋. 터미널·브라우저·에디터·리뷰 도구 사이를 왔다갔다 하던 맥락 전환이 사라지는 게 이 단계의 핵심 이득이에요.
7. 정리 — 검수자가 된다는 것
이번 편의 한 줄 요약은 이거예요. 병렬 에이전트 시대의 개발자는 타이피스트가 아니라 검수자다.
- 에이전트 코드는 틀려도 그럴듯해서, “예뻐 보이는 것”이 아니라 “맞는 것”을 골라야 해요.
- diff 코멘트 왕복으로 약점을 메꿔가며 최종본을 조립하고,
- UI 는 Design Mode 로 화면을 클릭해 맥락을 넘기고,
- worktree 별 브라우저로 결과를 눈으로 비교해요.
- 이 모든 걸 Orca 한 창 안에서 하니까 맥락 전환 비용이 없어요.
다음 4편에서는 이 판을 데스크톱 밖으로 넓힙니다. 무거운 작업은 원격(SSH·VPS) 박스에서 굴리고, 조종은 모바일로 하고, 반복 작업은 CLI 로 자동화하는 — 스웜을 확장하는 이야기예요.
📚 참고 링크
- Orca 문서 (코드 리뷰·Design Mode) — https://www.onorca.dev/docs
- Orca GitHub (Stably AI, MIT) — https://github.com/stablyai/orca
