braintrust

Braintrust — 인-세션 적대검토 패널 (집단지성)

핵심 아이디어 (왜)

설계·계획을 만든 그 사고는 자기 맹점을 못 본다(self-confirming). 진짜 레버는 저자의 추론을 공유하지 않는 독립 검토자 여럿 — 한 명(advisor)보다 N명이, 같은 렌즈 N개보다 서로 다른 렌즈 N개가 실패모드를 더 잡는다(diversity > redundancy).

결정적 우위는 fork 에이전트가 현재 대화 컨텍스트를 통째 상속한다는 것. 검토 대상을 프롬프트로 재직렬화할 필요 없이 "지금 합의한 것"을 그대로 검토한다. (fresh 에이전트는 매번 맥락을 붙여야 하고 그 과정에 저자 프레이밍이 샌다 — fork는 그 누수가 없다.)

언제 쓰나 / 안 쓰나 (역할 경계 — 단일 소스)

전제: 검토 대상이 현재 세션 컨텍스트에 있어야 한다(fork 상속이 전부니까). 없으면 먼저 대상을 받는다.

쓴다: 중대한 설계·아키텍처·계획·정책을 굳히기 직전 / 사용자가 "적대검토·패널·여러 관점·red-team" 요청 / 자기검토가 미덥지 않은 비가역·고영향 결정.

위임한다(안티-트리거) — 아래와 역할이 다르다:

• 코드 diff 리뷰 → /code-review (ultra=클라우드 멀티에이전트)
• 단일 외부검증 한 번이면 충분 → advisor
• 수정안의 파급반경/경계 판정만 → 별도의 범위 검토 에이전트가 설치돼 있으면 활용
• 대규모(≈8+) fan-out·결정론 파이프라인 → 별도의 대량 fan-out 워크플로우

고유 니치 = 소수 렌즈(3~5)·현재 세션·설계/계획/결정·fork 상속·종합까지. 위가 더 맞으면 패널을 띄우지 말고 위임하라 — 도구 중복은 부담만 는다(비중복 슬롯에만 도구를 둔다).

절차

1. 렌즈 선정 (3~5개, 직교하게)

검토 대상에 맞춰 겹치지 않는 비판 축을 고른다. 디폴트 메뉴(도메인 맞춤 가능):

렌즈	묻는 것
정합성/원칙	내부 논리·기존 원칙·제약과 충돌하나? 빠진 규칙은?
실패모드(적대)	시간경과·게이밍·엣지케이스로 어떻게 깨지나? 데이터 손실은?
실행가능성	실제로 강제·구현 가능한가? 결정론 가능 vs 사람/모델 규율 의존?
운영 현실성	누가·언제 실제로 수행하나? 6개월 뒤에도 작동하나? 측정 가능한가?
대안/기회비용	더 단순한/검증된 방법이 이미 있나? 기존 자산과 중복인가?

렌즈는 직교해야 한다 — 같은 렌즈 5개면 N명이 같은 말을 반복할 뿐이다. 대상이 한 방향으로만 깨질 수 있으면 그 축에 검토자를 더 붙이되, 보통은 직교 렌즈로 펼친다.

2. 병렬 fork 배포

렌즈마다 fork 1개씩, 한 메시지에 여러 Agent 호출로 동시 배포한다(병렬 실행).

Agent({ subagent_type: "fork", name: "Lens-<렌즈명>", description: "<렌즈> 검토", prompt: <3번 규약> })

fork는 컨텍스트 + 메인 모델을 상속하므로 model 지정·대상 재설명 불필요. 프롬프트엔 렌즈와 산출 규약만 담는다 — 검토 대상을 복붙하지 말 것(컨텍스트에 이미 있고, 복붙하면 저자 프레이밍이 샌다).

3. fork 프롬프트 규약 (각 에이전트) — 형식적 검토(theater)를 막는 장치

• 이 렌즈로만 적대적으로 검토하라. 다른 렌즈는 다른 에이전트 몫.
• 일반론·칭찬 금지, 구체적 보완·첨삭만. 항목별 [심각도 高/中/低][구체적 수정 문구].
• 가능하면 실측 근거(파일·라인·재현 경로)를 대고, 추정과 사실을 구분하라.
• 없으면 "없음 + 이유"를 명시하라 — 없는 결함을 지어내지 말 것(거짓 양성이 종합을 오염시킨다).
• read-only, 검토 보고만 (코드 수정 금지).
• (적대성 강화가 필요하면: "기본값을 '문제 있음'으로 두고 반증하라"는 refute-first 프레이밍.)