멀티에이전트 시스템을 처음 구성하면 역할을 많이 만든다.
Planner
Developer
Reviewer
Tester
Researcher보기에는 그럴듯하다.
하지만 실제로 여러 agent를 오래 쓰다 보면 더 중요한 문제가 보인다.
역할은 다른데, 사실 같은 가설을 공유하고 있지 않은가?
이 문제가 생기면 agent 수가 늘어도 사고의 다양성은 늘지 않는다.
1. 파일 기준 병렬화의 한계
가장 쉬운 분할은 파일 기준이다.
Agent A → service.py
Agent B → schema.py
Agent C → tests병렬화는 잘 된다.
하지만 세 agent 모두 같은 가설을 믿을 수 있다.
그러면 문제의 원인이 가설 밖에 있을 때 셋이 동시에 놓친다.
2. 질문 기준으로 분리한다
더 잘 동작했던 방식은 질문 기준 분리였다.
Ground-Truth → 실제 정답은 무엇인가
Contract → 어떤 schema가 무엇을 거부하는가
Measurer → 계측값은 신뢰 가능한가
Adversarial → Lead가 틀렸을 이유는 무엇인가
Verifier → 수정 후 실제 문제가 사라졌는가이렇게 하면 agent마다 다른 종류의 증거를 가져온다.
3. Ground-Truth는 해결책을 만들지 않는다
Ground-Truth agent에는 “원인을 찾아라”라고 시키지 않는다.
그 대신:
실제 데이터는 무엇인가?
실제 API 응답은 무엇인가?
실제 코드 경로는 무엇인가?를 묻는다.
이렇게 해야 Lead의 기존 가설에서 독립적일 수 있다.
4. Adversarial은 일부러 불편하게 만든다
Adversarial agent의 첫 질문은 다음처럼 고정할 수 있다.
What is the strongest reason the lead may be wrong?이 agent는 Lead를 돕는 것이 아니라 Lead의 가설을 공격한다.
- 반대 로그
- 대체 경로
- instrumentation blind spot
- stale state
- fallback
- contract mismatch
를 우선적으로 찾는다.
5. Evidence와 Verdict를 분리한다
각 agent가 “원인은 이것이다”라고 최종 판정을 내리게 하면 또 다른 문제가 생긴다.
그래서 lane은 evidence를 보고하고, Lead가 verdict를 낸다.
권장 형식:
Question
Evidence
Measurement validity
Limitations
PASS / FAIL / UNKNOWNUNKNOWN을 허용하는 것도 중요하다.
모르는 것을 억지로 PASS나 FAIL로 만들면 멀티에이전트의 신뢰성이 떨어진다.
6. Lead가 틀렸을 때 명시적으로 인정한다
멀티에이전트의 목적은 Lead를 맞게 만드는 것이 아니다.
Lead가 틀렸다면 최종 보고에 그대로 적는다.
해당 lane의 판단이 맞았고
Lead의 초기 가설이 틀렸다.이 규칙이 없으면 반박 agent를 두고도 실제 의사결정은 계속 Lead 중심으로 흐른다.
7. 독립성은 모델보다 질문에서 나온다
서로 다른 모델을 쓰면 도움이 된다.
하지만 다른 모델을 쓴다고 자동으로 독립적 사고가 생기는 것은 아니다.
진짜 독립성은:
질문이 다르고
증거 수집 경로가 다르고
판정 기준이 다른가에서 나온다.
결론
멀티에이전트의 가장 큰 가치는 사람 수가 늘어나는 것이 아니다.
서로 다른 agent가 서로 다른 질문을 독립적으로 검증할 수 있다는 것이다.
역할 이름보다 중요한 것은 질문의 독립성이다.