braintrust

name	braintrust
description	현재 세션에서 합의·작성한 설계·계획·결정·산출물을 3~5개 독립 fork 에이전트가 서로 다른 렌즈로 적대적으로 검토(adversarial review)하고 충돌조정·종합하는 인-세션 패널. "적대검토", "패널 검토", "다중 에이전트로 검토", "여러 관점으로 뜯어봐", "집단지성", "브레인스토밍 패널", "red-team", "fork 패널", "최종검토 돌려줘" 등을 언급하거나, 중대한 설계/계획/결정을 굳히기 직전 교차검증이 필요할 때 반드시 사용한다. 단일 외부검증(advisor)·코드 diff 리뷰(/code-review)와는 역할이 다르며 그쪽이 맞으면 위임한다(아래 "언제 쓰나/안 쓰나").

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 프레이밍.)

4. 종합

1. 중복 제거 — 여러 렌즈가 같은 지점을 짚으면 합치되, 합의 강도(몇 명이 짚었나)는 신호로 남긴다.
2. 충돌 조정 — 렌즈 간 상충은 근거로 판정한다(어느 제약이 우선인지). 상충 자체를 사용자에게 드러내는 게 가치다 — 묻어두지 말 것.
3. 우선순위화 — 심각도 × 합의강도로 정렬. CRITICAL/다수합의가 먼저.
4. 산출 — 보완/첨삭 목록 + (수정한다면) 최종 합의안. 무엇을 채택/기각했는지와 근거를 남긴다.

중대 결정이면 종합 후 advisor 1회로 외부검증을 덧대도 좋다(패널=내부 다수, advisor=독립 1인, 보완적).

규모 조절

"가볍게 봐줘" → 3 렌즈, 단일 라운드. "철저히/최종검토" → 4~5 렌즈 + 핵심 발견을 별도 fork로 반증(2차). 대상이 좁으면 렌즈를 줄인다 — 억지로 5개 만들지 말 것.

Known Pitfalls (위에서 안 다룬 것만)

• 모델 동질 편향. 모든 fork가 같은 모델이라 상관된 편향(같은 맹점 공유)이 남는다. 독립성이 정말 중요한 결정이면 한 렌즈를 다른 벤더(Codex/Gemini, 외부 키 필요)에 맡기는 cross-vendor 검토를 사용자와 논의하라 — 기본은 동질 패널이되 이 한계를 인지한다.
• 가치는 artifact가 아니라 독립성에서 난다. 보고서 모양만 그럴듯하고 렌즈가 비직교거나 대상을 복붙했거나 "뭐든 찾아내라"고 압박하면 theater가 된다(각각 절차 1·2·3에서 차단).

예시

• "이 설계 최종검토 돌려줘" → 정합성/실패모드/실행가능성/운영 4 렌즈 fork 병렬 → 종합.
• "이 정책 여러 관점으로 뜯어봐" → 도메인 맞춤 렌즈 3~5개 → 병렬 → 충돌조정 종합.
• "코드 바뀐 거 적대적으로 봐줘" → 위임: /code-review(diff 전용)가 맞다고 안내.