답을 기다리지 않고 일을 맡기는 법

Claude Code 에 일을 맡기면서 세 가지 문제가 계속 걸렸다.

1. 하나를 시키면 끝날 때까지 기다려야 했다
2. 여러 개를 동시에 굴리자, 쏟아지는 응답을 하루 종일 읽어야 했다
3. 그 사이에서 내가 골라야 할 결정이 묻혔다

이 글에서는 이 문제들을 창구 에이전트 paul 의 오케스트레이션, 출력 형식 통일, 화면을 카드로 바꾼 mod 로 하나씩 풀어 온 과정을 적어 보려 한다.

하나를 시키면 하나를 기다려야 했다

Claude Code 를 쓰면서 가장 많이 한 일은 기다리는 것이었다.

리뷰를 시키면 서브에이전트 여럿이 돌고 Jira 와 Swagger 를 읽는 동안 입력창이 막힌다. 그 사이 떠오른 질문은 메모장에 적어 두고 기다려야 했다.

느린 작업이 문제가 아니었다. 느린 작업 하나가 빠른 질문 열 개를 줄 세우는 것이 문제였다.

사람에게 일을 맡길 때처럼, 맡기고 다음 일을 하다가 끝났다는 연락이 오면 확인하고 싶었다.

창구를 하나 두기로 했다

내가 말을 거는 상대는 하나만 두고, 그 상대는 직접 일하지 않는다. 요청을 읽고 알맞은 담당자에게 넘긴 뒤 곧바로 다음 요청을 받는다. 9월 21일, 이 창구 에이전트에 paul 이라는 이름을 붙였다.

paul 의 우선순위는 지침 맨 위 한 줄이다.

빠른 업무 완료 > 빠른 분류 > 답변 품질

코드를 읽지도, 고치지도, 스킬을 부르지도 않는다. 창구가 일을 직접 하는 순간 창구가 막힌다.

가장 빨리 끝내는 것이 목적이라, 넘기는 방식은 유연하다.

• 같은 리드도 여러 개 띄운다. 요청이 다섯 개면 다섯 개가 같이 돈다. 같은 종류의 리드여도 다루는 일이 다르면 따로 띄운다
• 돌고 있는 리드에 이어 붙인다. 새 메시지가 이미 돌고 있는 리드와 같은 결과물(같은 파일·PR·이슈)을 다루면, 새로 띄우지 않고 그 리드에 맥락을 넣어 잇는다. 같은 파일을 두 리드가 따로 고치면 한쪽이 덮이기 때문이다
• 늦으면 끊는다. 빨리 끝나야 할 질문이 아직 돌고 있으면 멈추고, 일이 크면 둘로 쪼개 다시 넘긴다. 리뷰·검증처럼 원래 느린 일과 워크트리에서 개발 중인 리드는 끊지 않는다

맡기는 쪽은 기다리지 않고, 합치는 쪽만 기다린다

처음부터 그렇게 돌지는 않았다. 9월 27일에 기록을 세어 보니 위임 26번 중 10번이 포그라운드였다. paul 이 리드가 끝날 때까지 같이 멈춰 있었고, 나는 그때마다 40초에서 210초를 기다렸다. 그렇다고 리드까지 서브를 백그라운드로 부르게 하자, 리드가 서브 결과를 기다리지 않고 끝나 버려 결과가 합쳐지지 못한 채 흩어졌다.

10월 1일에 호출 방식을 이렇게 정리했다.

1. paul → 리드는 백그라운드. paul 은 리드를 띄우고 바로 다음 요청을 받는다
2. 리드 → 서브는 포그라운드로, 한 번에 동시에. 리드는 서브가 모두 돌아올 때까지 기다렸다가 결과를 하나로 합친다
3. 리드 결과 → paul → 나. 리드가 끝나면 완료 알림으로 결과가 paul 에게 돌아온다. paul 은 형식만 훑고 고치지 않은 채 결과마다 그대로 전하고, 같은 메시지의 리드가 모두 끝나면 종합을 한 통 따로 붙인다

결과를 합칠 쪽만 기다리니, 나는 더 이상 입력창 앞에서 기다리지 않게 됐다.

빨라졌지만, 하루 종일 읽고 있었다

원하던 속도는 얻었다. 요청을 연달아 던지면 리드들이 동시에 돌고, 끝나는 대로 결과가 돌아왔다. 대신 이번엔 읽는 게 일이 됐다. 리드마다 틀 없는 긴 줄글로 답하고 그 답이 끝난 순서대로 섞여 들어오니, 어느 답이 어느 요청의 것인지, 결론이 어디 있는지 하나하나 읽어 내려가야 했다. 하루 종일 응답을 읽고 있었다.

하루 종일 읽지 않으려고, 틀을 정했다

하루 종일 읽는 시간을 줄이려고 이번엔 출력을 손봤다. 답이 내가 읽기 편한 모양으로 오게 하는 것이다.

여기서 하나 알게 된 게 있다. 코드를 어떻게 짜라는 기준은 모델이 좋아질수록 낡는다. 내가 세워 둔 개발 규칙보다 모델이 더 잘 아는 날이 금방 온다. 하지만 출력 기준은 다르다. 무엇이 읽기 편한지는 "나"의 기준이라, 모델이 좋아지는 것과 상관없이 그대로 남는다.

모델이 발전할수록 코드는 점점 더 잘 짜 준다. 하지만 무엇이 읽기 편한지, 어떤 순서로 일하고 싶은지는 모델이 대신 정해 주지 않는다. 내 취향과 작업 구조는 내가 잡아 나가야 한다.

그래서 어떻게 출력해야 읽기 편한지 기준을 정했다. 모든 리드가 이 틀로 보고한다.

---
---
# ⚡️ lead-dev · [결정 카드 완료 문구] · 20

## 결정 카드에서 적용하면 선택지가 사라지고 결과 문구만 남아요

시킨 것 1 · 한 것 1 · 남은 것: 없음

(본문 · 참고사항)
---
---

[paul 에게]
결정: 없음

---
---
# ⚡️ lead-dev · [결정 카드 완료 문구] · 20

## 결정 카드에서 적용하면 선택지가 사라지고 결과 문구만 남아요

시킨 것 1 · 한 것 1 · 남은 것: 없음

(본문 · 참고사항)
---
---

[paul 에게]
결정: 없음

• 제목 끝 숫자는 내가 보낸 메시지 번호다. 결과가 뒤섞여 와도 번호로 맞춰 본다
• ## 한 줄이 결론이다
• 시킨 것 · 한 것 줄로 맡은 일을 줄여 오지 않았는지 대조한다
• 내가 골라야 하는 결정은 본문에 쓰지 않고 [paul 에게] 아래에만 쓴다. 그래야 결정을 한 번에 모아 물을 수 있다

정리된 글을 한 번 더 요약했다

틀을 맞추니 글은 정리됐다. 하지만 분량은 그대로였다. 리드 결과 하나하나가 여전히 긴 글이라, 요청을 몇 개만 던져도 스크롤이 올라가고 맨 끝의 결정 블록은 다시 위로 밀려 묻혔다.

그래서 정리된 틀을 한 번 더 요약하기로 했다. 10월 6일부터 Claude Code 화면을 바꾸는 mod(card-ui)가 틀의 결론 줄과 첫 불릿만 읽어 카드로 접어 보여 준다. 틀이 줄글을 요약했다면, 카드는 그 틀을 다시 요약한 요약의 요약이다. 메시지 번호 하나마다 카드 한 묶음이 선다.

도는 동안은 주황 고리가 돌고, 끝나면 초록 체크로 바뀐다. 내가 골라야 하는 결정 카드만 파란 물음표다. 화면을 훑을 때 파란 카드만 찾으면 된다.

결정 카드에서 선택지를 고르고 적용을 누르면, paul 이 그 결정을 올린 리드에게 이어 붙인다.

내가 모르는 필요를 채우는 리드

리드가 늘어날수록 리드와 스킬을 손보는 일도 늘었다. 바쁜 와중에 무엇이 문제였는지 다시 떠올리고, 파일을 직접 열어 읽고 고치는 일이 생각보다 번거로웠다. 그래서 스킬을 손보는 일까지 자동화하기로 했다.

여기까지의 리드는 모두 내가 필요하다고 느껴서 만든 것이다. 그런데 자동화하려고 채팅 기록을 다시 보니, 나는 같은 종류의 일을 여러 번 시키면서도 그걸 하나의 일로 알아채지 못하고 있었다.

• mod 화면을 고치고, 지금 세션에 다시 불러와 보고, 또 고치기
• 시안을 열 개 띄우고 "1, 4, 5 빼고 다시" 로 좁혀 가기
• 리뷰 결과 중 "2, 5, 7번만 반영해줘"

그래서 오토 리드(lead-auto)를 만들었다. 최근 120일 채팅 기록에서 자주 시키는데 기존 리드로는 잘 안 풀리던 일을 찾아 오토 스킬을 자동으로 넣고, 다듬고, 뺀다. 지금은 여덟 개다.

실제로 오토에 들어온 스킬 두 개를 보면 이렇다.

• auto-review-items-apply : 리뷰를 받고 "2·5·7번만 반영해줘" 처럼 번호를 골라 시키는 일이 잦아 생겼다. 리뷰를 새로 하지 않고 고른 번호만 고친 뒤, 번호별로 무엇을 왜 고쳤는지 표로 보인다
• auto-root-cause-trace : "등록 누르면 500 나는 원인", "예전엔 설치 상태 확인했었어?" 같은 질문이 반복돼 생겼다. 증상을 재현 시나리오로 고정하고, 코드·git 이력·백엔드·실행 로그로 언제 왜 바뀌었는지 좁힌다

그래서 무엇이 바뀌었나

오케스트레이션, 출력 형식 통일, Mod 도입. 세 가지를 들이기 전과 후를 나란히 놓으면 이렇다.

지금 시도하고 있는 것

듀엣: 출시되면 옮겨 보기

지금 구조는 리드 지침, 넘기는 규칙, 출력 틀, 틀을 읽는 mod 까지 전부 손으로 만들었다. Claude 가 이런 구성을 듀엣이라는 이름으로 쉽게 만들 수 있게 내놓을 예정이고 메모리도 자동으로 갱신된다고 해서, 듀엣이 출시되면 시도해볼 예정이다.

출처: Introducing Claude Duet

도구가 바뀌어도 직접 부딪히며 정한 기준, "결과를 합칠 쪽만 기다린다", "결정은 한 자리에만 모은다" 는 그대로 가져가려 한다.

PaulStack: 터미널 밖에서 버튼 하나로

지금은 모든 것이 터미널 대화로 굴러간다. 매번 같은 말로 시키는 일은 굳이 대화일 필요가 없어서, PaulStack 이라는 페이지를 만들고 있다. 버튼 하나에 리뷰가 돌고, 이슈가 채워지는 식이다.

지금 만들고 있는 에이전트 화면이다. 위쪽에 리드 캐릭터가 서고, 그 아래로 paul 과의 대화가 이어진다.

대화로 하나씩 시키던 일이, 이제는 버튼 하나로 옮겨 가는 중이다.

시행착오에서 남은 것

1. 일단 해 봐야 부족한 게 보인다. 처음 만든 paul 은 리드가 끝날 때까지 같이 멈춰 있었고, 틀을 맞춘 뒤에도 결정은 다시 묻혔다. 미숙한 채로라도 굴려 봤기 때문에 다음에 고칠 곳이 보였다.
2. 모델은 바뀌어도 내 취향은 잘 바뀌지 않는다. 코드 실력은 모델이 올려 주지만, 읽기 편한 모양과 일하는 순서는 내가 정해야 한다. 내 작업 방식에 맞춰 다듬는 일은 모델이 좋아져도 남는다.
3. 문제를 문제로 정의해야 고칠 수 있다. "기다린다", "하루 종일 읽는다", "결정이 묻힌다" 처럼 불편을 한 문장으로 짚고 나서야 무엇을 바꿀지가 정해졌다.