서브에이전트에게 일을 맡길 때 꼭 적는 여섯 줄

서브에이전트 아홉 개를 한꺼번에 돌리면 빨라질 줄 알았습니다.

절반은 맞았습니다.
실제로 빨라집니다.
그런데 경계를 안 나누면 빨라진 만큼 수습도 빨라집니다.
같은 파일을 서로 고치고, 한쪽은 dry-run이라고 했는데 파일이 생기고, 다른 한쪽은 “완료”라고 했는데 diff가 없습니다.

처음엔 에이전트가 덜 똑똑해서 그런 줄 알았습니다.

아니었습니다.
제가 일을 애매하게 줬습니다.

“조사해줘”는 너무 넓었습니다

초기에는 이렇게 시켰습니다.

이 부분 전체 조사해서 문제 있으면 고쳐줘.

사람에게도 넓은 요청입니다.
에이전트에게는 더 위험합니다.
어디까지 읽어야 하는지, 어떤 파일을 건드려도 되는지, 커밋해도 되는지, 어떤 형식으로 돌아와야 하는지 전부 추측해야 합니다.

추측이 많으면 결과가 흔들립니다.

어떤 에이전트는 너무 많이 고칩니다.
어떤 에이전트는 읽기만 합니다.
어떤 에이전트는 로그를 길게 붙여서 부모 컨텍스트를 더럽힙니다.
다 열심히 한 건데 합치기가 어려워집니다.

지금은 여섯 줄을 먼저 씁니다

제가 지금 기본으로 넣는 계약은 거의 고정입니다.

1. 너는 혼자 작업하는 게 아니다.
2. 쓰기 범위는 이 파일/폴더뿐이다.
3. 커밋, push, destructive git 금지.
4.
완료 기준은 이것이다.
5.
증거는 git diff / 명령 / 파일 경로로 남겨라.
6.
전체 로그 말고 요약만 반환하라.

이 여섯 줄만 있어도 사고가 많이 줄었습니다.

특히 “너는 혼자 작업하는 게 아니다”가 생각보다 중요했습니다.
에이전트는 기본적으로 자기 작업 공간이 전부라고 가정하기 쉽습니다.
그래서 다른 사람이 만진 파일을 되돌리거나, 겹치는 변경을 만들 수 있습니다.

공유 체크아웃에서는 그 한 줄이 방어선이 됩니다.

병렬화는 겹치지 않을 때만 이깁니다

서브에이전트를 풀로 쓰는 가장 쉬운 기준은 파일 경계입니다.

서로 다른 글 10개를 리뷰한다.
좋습니다.

서로 다른 화면 5개를 캡처한다.
괜찮습니다.

같은 공통 컴포넌트를 여러 에이전트가 동시에 고친다.
위험합니다.

공유 파일, 공통 스키마, 루트 설정, 빌드 스크립트는 메인 세션에서 먼저 정리하는 게 낫습니다.
그 다음에 하위 작업을 팬아웃합니다.
순서를 바꾸면 각 에이전트가 서로 다른 전제를 읽고 작업합니다.

이건 사람 팀에서도 똑같습니다.
공통 인터페이스가 정해지기 전에 각자 구현하면 나중에 맞추느라 더 오래 걸립니다.

완료 보고는 부모가 다시 봅니다

서브에이전트가 “완료”라고 하면 저는 이제 바로 다음으로 가지 않습니다.

간단히 봅니다.

git status --short
git diff --stat
git log -1 --oneline

읽기 전용이라고 했는데 파일이 바뀌었는지 봅니다.
커밋 금지라고 했는데 커밋이 생겼는지 봅니다.
수정했다고 한 파일이 실제로 diff에 있는지 봅니다.

이건 불신이라기보다 역할 분리입니다.
에이전트는 일을 하고, 오케스트레이터는 상태를 측정합니다.

긴 로그는 도움이 안 됐습니다

초반에는 전체 실행 로그를 다 받는 게 안전하다고 생각했습니다.
뭘 했는지 다 알아야 한다고 느꼈습니다.

막상 받아보면 거의 못 씁니다.
긴 로그는 부모 컨텍스트를 잡아먹고, 중요한 사실을 묻습니다.
필요한 건 보통 다섯 가지입니다.

결론
변경 파일
검증 명령
남은 리스크
다음 사람이 알아야 할 것

이 정도면 충분합니다.

서브에이전트를 많이 쓰는 건 팀을 키우는 것과 비슷했습니다.
사람 수가 늘면 지시가 더 명확해야 합니다.
“알아서 잘”은 한 명일 때도 위험한데, 아홉 명일 때는 그냥 비용입니다.

요즘 저는 팬아웃 전에 먼저 여섯 줄을 씁니다.

그 여섯 줄을 못 쓰겠으면 아직 나눌 준비가 안 된 겁니다.