assumptions

Core Goal

• 구현 전에 에이전트의 숨겨진 가정을 발굴하고 리스크를 수치화하여 팀이 무엇을 먼저 검증해야 하는지 명확히 함
• 4축(Value/Feasibility/Reliability/Ethics) 분석을 통해 기술적 가능성과 실제 운영 가능성의 갭을 조기에 발견
• 우선순위 점수(위험도 × 검증 난이도)를 기준으로 2일 이내에 실행 가능한 최소 검증 실험을 설계

---

Trigger Gate

Use This Skill When

• opp-tree 스킬로 기회를 선택한 후, 구현하기 전에 핵심 가정을 빠르게 검증하고 싶을 때
• 에이전트 아이디어가 있는데 "정말 작동할 것 같나"에 대한 우려가 있을 때
• 기술 팀은 구현 가능하다고 하는데 비즈니스 팀이 의심스러워할 때
• 윤리/안전 위험(예: 잘못된 판단이 고객에게 영향)이 있을 수 있다고 생각할 때

Route to Other Skills When

• 검증 실험 설계 후 실제로 프롬프트/API를 테스트해야 할 때 → hitl 스킬 (Human-in-the-Loop으로 초기 신뢰도 측정) 또는 본 스킬 --mode build-or-buy
• 가정 검증 결과 위험도가 매우 높으면 → hitl 스킬로 에스컬레이션 전략 설계
• 검증 통과 후 에이전트 설계 및 프롬프트/인스트럭션을 작성해야 할 때 → deliver/agent-setup
• 8축 100점 evidence 루브릭으로 정량 채점이 필요할 때 → evidence-rubric (hplan plugin). V/F/R/E 4축과 상보적.

Boundary Checks

• 검증의 범위: Assumptions는 가정을 "정의"하고 "우선순위"를 정하는 것이지, 실제로 검증 실험을 끝까지 실행하지는 않음 — 실험 실행은 팀이 직접 담당
• 이미 검증됨: 기술 스택이 프로덕션에서 이미 검증되었다면(예: 우리 팀이 동일 모델로 다른 에이전트를 성공했다면) 그 가정의 점수는 내려야 함

---

Agent Assumption Map

에이전트 아이디어에는 수십 개의 숨겨진 가정이 있습니다. 그 중 단 하나만 틀려도 에이전트는 조용히 잘못된 방향으로 실행됩니다.

일반 제품과 다른 점:

• 일반 제품: 사용자가 결과를 보고 판단 → 오류 발견 즉시 가능
• 에이전트: 자율 실행 → 오류가 쌓일 때까지 발견 어려움

Agent Assumption Map은 4축 분석으로 핵심 가정을 사전에 발굴합니다.

---

4축 정의

Axis 1 — Value (가치 가정)

"이 에이전트가 실제로 의미 있는 문제를 해결하는가?"

검토 질문:

• 자동화 후 실제로 시간/비용/오류가 줄어드는가?
• 사용자가 에이전트의 결과를 실제로 사용하는가?
• 에이전트 없이도 충분히 빠르게/잘 할 수 있지 않은가?
• 자동화로 해결되는 불편함이 진짜 불편함인가, 아니면 낮은 빈도의 사소한 불편인가?

Axis 2 — Feasibility (실현 가능성 가정)

"이 에이전트를 실제로 구현할 수 있는가?"

검토 질문:

• 필요한 데이터에 접근 가능한가? (API 권한, 인증, 비용)
• 필요한 툴이 안정적으로 작동하는가?
• 기술 스택 (모델, 프레임워크) 이 요구사항을 지원하는가?
• 개발 리소스와 타임라인이 현실적인가?
• 외부 의존성 (API 변경, 서비스 중단) 리스크는?

Axis 3 — Reliability (신뢰성 가정) ← 에이전트 특화 축

"이 에이전트가 충분히 정확하고 안정적으로 반복 실행 가능한가?"

검토 질문:

• 정확도 기준은 무엇인가? (90%? 99%? 100%?)
• 오류 발생 시 자동 감지 및 복구 가능한가?
• 컨텍스트 길이 / 모델 응답 일관성이 보장되는가?
• 외부 API 장애 시 에이전트가 어떻게 반응하는가?
• 장기 실행 시 성능 저하 (컨텍스트 오염, 비용 증가) 없는가?

⚠️ 신뢰성 기준은 용도에 따라 다릅니다. 뉴스 요약 에이전트 (90% 충분) vs 금융 거래 에이전트 (99.9% 이상 필요)