opp-tree

Core Goal

• 자동화 기회를 체계적으로 탐색하고 우선순위를 정하여 팀이 가장 값있는 에이전트에 투자하도록 함
• 반복빈도, 자동화가능성, 판단의존도를 기준으로 기술적 가능성과 비즈니스 가치의 균형을 맞춤
• 검증 실험 설계를 통해 구현 전에 핵심 가정(Value/Feasibility/Reliability/Ethics)을 빠르게 테스트

---

Trigger Gate

Use This Skill When

• 에이전트 도입을 고려 중인데 어디서부터 시작할지 결정해야 할 때
• 조직의 반복 작업, 병목 지점, 자동화 기회를 체계적으로 매핑해야 할 때
• 여러 개의 에이전트 아이디어가 있는데 어느 것을 먼저 구현할지 우선순위를 정해야 할 때
• 기술 팀과 비즈니스 팀의 의견이 갈려 "에이전트를 만들어야 하는가"를 데이터 기반으로 판단해야 할 때

Route to Other Skills When

• 선택된 기회의 가정(Value/Feasibility/Reliability/Ethics)을 깊이 있게 검증해야 할 때 → assumptions 스킬
• 최우선 기회의 기술 구현 방식(Trigger Agent vs Pipeline Agent vs Research Agent)을 결정해야 할 때 → discover/assumptions --mode build-or-buy
• 선택한 에이전트에 인간 개입 지점을 설계해야 할 때 → hitl 스킬
• Opportunity Tree를 Mermaid + docs/OPPORTUNITY_TREE.md로 영구화하고 5/3 strong-Push 패턴으로 검증할 때 → ost (hplan plugin)

Boundary Checks

• 범위 확인: AOT는 "어떤 에이전트를 만들 것인가"를 정하는 것이지, "어떻게 만드는가"를 설명하지 않음 — 구현은 deliver/agent-setup으로 연결
• 판단 의존도 주의: 점수가 5점을 넘어가거나 판단 의존도가 높다면(4~5점) AOT 대상이 아닐 수 있음 — 그냥 Rule-based 자동화나 인간 처리가 더 나을 수 있음

---

Agent Opportunity Tree (AOT)

에이전트를 "만들 수 있냐"가 아니라 "만들어야 하냐"를 결정하는 프레임워크.
Teresa Torres의 Opportunity Solution Tree를 AI 에이전트 디스커버리에 맞게 재설계했습니다.

---

왜 에이전트에는 다른 OST가 필요한가

일반 OST는 제품 기능을 탐색할 때 씁니다.
에이전트 OST는 다릅니다. 에이전트는 자율적으로 행동하기 때문에 잘못된 기회를 선택하면 오류가 조용히 증폭됩니다.

에이전트 디스커버리에서 빠지기 쉬운 함정:

• "기술적으로 가능하니까" 만든다 → 아무도 안 씀
• "반복 작업이니까" 자동화한다 → 판단이 필요한 부분을 건드려 더 큰 문제 발생
• 에이전트 1개로 너무 많은 걸 해결하려 한다 → 실패율 급증

AOT는 이 함정을 피하기 위해 4개 레이어를 순서대로 탐색합니다.

---

구조 (4 레이어)

[Automation Outcome]
        │
   ┌────┴────┐
[Opportunity] [Opportunity] ...
        │
   ┌────┴────┐
[Agent Type] [Agent Type] ...
        │
   ┌────┴────┐
[Experiment] [Experiment] ...

레이어 1 — Automation Outcome (자동화 목표)

단 하나의 측정 가능한 목표를 정합니다.
좋은 예: "PM이 뉴스 수집에 쓰는 시간을 주 5시간 → 0시간으로 줄인다"
나쁜 예: "업무를 AI로 자동화한다" (너무 넓음)

레이어 2 — Opportunities (기회, 문제 공간)

자동화로 해결 가능한 반복 작업, 판단 패턴, 병목 지점을 발굴합니다.
기회 프레이밍 공식:
"[누가] [어떤 상황에서] [반복적으로] [무엇을 해야 하는데] [시간/실수/비용이 든다]"