| name | parallel-hypothesis-investigation |
| description | 문제의 원인이 여러 계층에 걸쳐 그럴듯하게 나뉘어 있거나, 출력이 서로 독립적인 여러 판단 기준을 모두 통과해야 할 때 적용하세요 — 가설을 조사하거나 기준을 평가할 때 순차로 하지 말고 동시에 하라는 겁니다. 특히 뻔한 수정이 이미 실패했거나, 문제가 경계를 넘나들 때(config는 설정돼 있는데 동작은 틀린 경우) 쓰세요. |
병렬 가설 조사
문제의 원인이 여러 갈래로 그럴듯하거나 서로 독립적인 판단 기준이 여럿일 때는, 순차로 하지 말고 동시에 조사하세요.
분해 축
병렬 조사는 작업이 깔끔하게 쪼개질 때만 이득이 납니다. 쓸 만한 축은 두 개이고, 둘은 서로 바꿔 쓸 수 없습니다 — 축을 잘못 고르면 워커들이 겹쳐서 서로의 일을 다시 하게 됩니다.
| 축 | 언제 쓰나 | 워커 프레이밍 |
|---|
| Layer (가설) | 근본 원인이 불확실하고 서로 다른 여러 계층에 있을 수 있을 때 | "원인이 <계층>에 있는지 검증하라" |
| Criterion (평가) | 출력이 서로 독립적인 여러 판단 기준을 통과해야 할 때 | "출력을 <기준>만으로 판단하라" |
layer 축은 무언가를 찾기 위한 것이고, criterion 축은 무언가를 판단하기 위한 것입니다. 리뷰나 advisor 성격의 작업은 보통 criterion 축이고, 디버깅은 보통 layer 축입니다. 한 작업이 둘을 순차로 쓸 수도 있습니다 — 먼저 원인을 찾고(layer), 그다음 수정을 판단하는(criterion) 식으로 — 하지만 하나의 병렬 배치 안에서 둘을 섞지는 마세요.
criterion 축의 종합 출력 포맷은 evaluation-integrity.md §Multi-advisor synthesis를 보세요.
언제 적용하나
- 근본 원인이 불확실하고, 서로 다른 3개 이상 영역(라이브러리 내부, config, 인프라 등)에 있을 수 있을 때
- 출력이 서로 독립적인 2개 이상의 판단 기준을 만족해야 하는데, 리뷰어 한 명이 보면 그 기준들이 뭉개질 때
- 각 워커가 다른 워커를 막지 않고 독립적으로 진행할 수 있을 때
- 첫 추측이 틀리면 순차 조사가 시간을 낭비할 때
절차
- 축을 먼저 고르고, 그다음 나열하라. layer로 나눌지 criterion으로 나눌지 정하세요. 그런 다음 워커를 나열합니다 — layer 축이면 가설, criterion 축이면 판단 기준. 이 단계에서는 깊이보다 폭을 노립니다.
- 병렬 에이전트를 띄워라. 각 워커에 겹치지 않는 범위를 배정하세요. 각 에이전트는 무엇을 찾아야 하는지(layer 축) 또는 무엇을 기준으로 판단해야 하는지(criterion 축)를 알아야 하고, 무엇이 finding인지도 알아야 합니다.
- 그냥 모으지 말고 종합하라. 결과가 들어오면 finding들을 교차 검토하세요. layer 축에서는 한 에이전트의 발견이 다른 에이전트의 발견을 설명하거나 무효화할 수 있습니다 — 근본 원인은 종종 여러 계층의 교차점에 있습니다. criterion 축에서는 같은 산출물을 두고 에이전트들이 자주 의견이 갈리는데, 그 불일치는 노이즈가 아니라 신호입니다(evaluation-integrity.md 참고).
에이전트 브리핑 원칙
- 각 에이전트에 지시를 그냥 따르기만 하는 게 아니라 스스로 판단할 수 있을 만큼의 맥락을 주세요
- 시작할 정확한 디렉터리, 파일, 함수를 지정하세요
- "X를 조사하라"가 아니라, 검증할 가설(layer 축) 또는 판단할 기준(criterion 축)을 명시하세요
- criterion 축 에이전트에는 다른 기준에 대한 코멘트를 명시적으로 금지하세요 — 보안 리뷰어가 UX를 두고 왈가왈부하기 시작하면 기준들이 다시 하나의 뭉개진 리뷰로 무너집니다
- 빠짐없는 리포트가 아니라 간결한 finding을 요청하세요
이 접근이 필요하다는 신호
- 뻔한 수정을 이미 해봤는데 안 됐다
- 사용자가 "되어야 하는데 안 돼요"라고 말한다
- 문제가 경계를 넘나든다(환경변수는 제대로 설정됐는데 동작은 틀림, config는 있는데 적용이 안 됨)
- 초기 조사에서 첫 계층은 배제됐고, 원인이 더 깊거나 아예 다른 계층에 있음을 시사한다
규칙
- 사소한 걸 병렬화하지 마세요. 확인할 곳이 1~2군데뿐이면 그냥 직접 확인하세요.
- 각 에이전트는 겹치지 않는 조사 범위를 맡아 중복 작업을 피해야 합니다.
- 종합한 finding은 에이전트별로 따로 노는 리포트가 아니라, 명확한 근본 원인 사슬을 가진 하나의 그림으로 제시하세요.
- 여러 에이전트가 서로 다른 각도에서 같은 finding으로 모이면 그건 강한 신호입니다. 서로 모순되면 그 간극을 조사하세요.
