실행계획
정리.html 에서 뽑아낸 실행 부분만 따로 모았다. 각 단계마다 무엇을 하는가 · 무엇을 얻는가 · 왜 하는가 를 붙였다.
클로드 코드를 쓰는 것과 서브 에이전트를 쓰는 것은 다른 일이다. 차이는 도구가 아니라 내가 매번 지시하느냐, 에이전트가 알아서 나눠 부르게 만들어 뒀느냐다.
아래 다섯 단계가 그 전환을 만든다. 처음 만든 서브 에이전트는 무조건 이상하게 나온다 — 그건 실패가 아니라 정상 경로다.
실행 — 프로젝트에 .claude/agents 폴더를 만들고, 그 안에 마크다운 파일을 하나 만든다. 파일 안에 네 가지만 적는다.
얻는 것 — 첫 서브 에이전트. 이게 있어야 "내가 부르는 게 아니라, 에이전트가 부르는 에이전트"를 실제로 경험할 수 있다.
왜 — 최수민의 말대로, "마크다운 파일을 하나 만들기만 하면" 서브 에이전트가 된다. 새로 배울 문법이 없다.
실행 — 프로젝트에 프롬프트 폴더를 만든다. 반복해서 쓸 것 같은 지시는 에이전트 창에 바로 치지 말고, 이 폴더의 파일에 먼저 적는다.
얻는 것 — 다음에 비슷한 일을 시킬 때, 파일을 열어 복사하기만 하면 된다. 바뀌는 부분만 변수로 바꿔 두면 그 자체가 서브 에이전트 초안이 된다.
왜 — 최수민은 이 습관 하나로 "체크리스트 생성 에이전트" 같은 걸 몇 분 만에 만든다. 처음부터 범용적으로 쓰려 하지 말고, 일단 아카이빙부터 하는 게 순서다.
실행 — 서브 에이전트가 반복적으로 파일을 만들거나(이미지, 스크린샷, 데이터 추출 등) 계산을 해야 한다면, 그 부분을 타입스크립트나 파이썬 스크립트로 미리 짜 두고, 에이전트에게는 "이 스크립트를 실행해라"라고만 시킨다.
얻는 것 — 이미지 데이터 같은 큰 중간 결과물이 컨텍스트 윈도우(AI의 책상)를 차지하지 않는다. 결과물만 남는다.
왜 — 3장의 그 이유다. 플레이라이트 MCP로 스크린샷을 직접 생성하게 시키면, 이미지 페이로드가 통째로 책상에 올라온다. 스크립트로 빼면 찌꺼기 없이 결과만 남고, 속도도 정확도도 올라간다.
실행 — 자주 반복하는 작업이 생기면, "어떤 서브 에이전트를 어떤 순서로 부를지" 적은 마크다운 문서를 하나 만든다. 그 안에서 서브 에이전트가 다시 서브 에이전트를 병렬로 부르게 짠다.
얻는 것 — 다음부터는 "이 문서를 참고해서 처리하세요" 한 줄이면 끝난다. 최수민은 이 한 줄로 웹페이지 하나를 컴포넌트로 쪼개는 데 한 시간짜리 작업을 돌린다.
왜 — 이게 9장의 그 차이를 실제로 쓰는 방법이다. 내가 매번 여러 번 명령하는 대신, 한 번의 명령으로 열 개든 백 개든 에이전트가 딸려 호출되게 만드는 것이다.
실행 — 새 도구나 서비스를 만들기 전에 내가 이걸 실제로 쓸 것인가를 먼저 따진다. 만들고 나서 자신이 안 쓰고 있다면, 그게 배드 시그널이다.
얻는 것 — 불편한 지점을 남의 피드백 없이도 스스로 빠르게 캐치한다. 도컬렉션 같은 기능이 이렇게 나왔다.
왜 — 최수민은 과거 창업에서 자기가 만든 사이트를 안 쓰고 경쟁사를 썼던 경험을 "완전 배드 시그널"이었다고 말한다. 이 원칙은 안전 가드레일로 작동한다.
| 단계 | 없으면 생기는 문제 |
|---|---|
| 1. 서브 에이전트 폴더 | 매번 내가 직접 여러 번 불러야 한다 (커서와 같은 한계) |
| 2. 프롬프트 아카이빙 | 같은 지시를 매번 새로 쓴다 |
| 3. 스크립트 분리 | 컨텍스트가 금방 차서 큰 작업을 못 끝낸다 |
| 4. 파이프라인 문서 | 반복 작업마다 처음부터 다시 지시해야 한다 |
| 5. 직접 쓰기 원칙 | 불편함을 스스로 못 느껴서 개선이 늦어진다 |
1~4단계는 도구를 다루는 법이고, 5단계는 무엇을 만들지 정하는 법이다. 앞의 넷이 갖춰져도, 마지막 하나가 없으면 빠르게 만든 것이 결국 아무도(자신조차) 안 쓰는 것이 될 수 있다.
1단계의 서브 에이전트 폴더에, 무슨 반복 작업부터 넣을지. 이번 주에 두 번 이상 손으로 반복한 작업이 있다면 그게 첫 후보다.