5 패러다임 비교 + 사용자 결정 가이드

Goose · Claude Code · Codex · pi-mono · Gemini CLI 다섯 reference의 가정 매트릭스 + 각 가정에 대한 자세한 결정 가이드. v1.0이 어떤 가정을 채택할지는 사용자의 strategic 결정. 이 노트는 결정 도구.

한 줄

다섯 reference는 서로 다른 가정 위에 서있다. 각 가정은 trade-off가 있고, 어떤 조합도 기술적으로 가능. 사용자가 12개 가정 각각에 답을 정하면 v1.0 spec의 골격이 됨.

5 reference의 좌표

가정 매트릭스 — 5 reference

관찰: 11번·12번 칸이 다섯 모두 비어 있음. 능력 부족이 아니라 경제성 (대기업/오픈소스에 한 segment fit은 ROI 안 나옴).

★ 12 가정 결정 가이드

각 가정마다: 무엇을 묻는가 · ✅/❌의 의미 · 어느 reference가 그 길 · Trade-off · 고려할 질문.

가정 1 — 모델은 service (vendor 추상화)?

무엇을 묻는가: LLM을 교체 가능한 vendor service로 다룰 것인가, 아니면 특정 vendor의 모델에 결합된 형태로 다룰 것인가.

✅ 채택 시: trait Provider {...} 같은 추상화 layer를 둠. OpenAI·Anthropic·Google·로컬 LLM·학내 endpoint를 같은 호출 코드로 다룸.

• 사례: Goose (15+ provider), pi-mono (pi-ai)
• 장점: vendor 갈아끼우기 쉬움, vendor가 spec 바꿔도 adapter만 변경
• 비용: 추상화 비용 (provider별 quirk 매번 처리), 새 vendor마다 adapter 작성

❌ 채택 시: 단일 vendor에 직접 결합. prompt·tool format이 그 vendor 거동에 맞춤.

• 사례: Claude Code (Anthropic), Gemini CLI (Google)
• 장점: vendor 능력을 최대로 활용 (특화 prompt, 자체 tool format)
• 비용: 다른 vendor로 이전 시 전체가 흔들림

⚠️ partial: Codex — Provider 추상화는 약하지만 ChatGPT plan/API key 두 가지 진입.

Trade-off 한 줄: 유연성 vs vendor 능력 최대 활용

고려할 질문:

• v1.0 사용자가 어느 모델을 쓸 것인가? (학내 endpoint? OpenAI? Anthropic? 로컬?)
• vendor가 spec 바꿀 때 얼마나 흔들려도 되는가?
• 학내 토큰 endpoint가 OpenAI-compatible인가? (그럼 추상화 비용 거의 0)

가정 2 — harness가 곧 product인가?

무엇을 묻는가: 사용자에게 주는 게 product(완성된 도구)인가, library/SDK(조합해서 쓸 부품)인가?

✅ 채택 시: 사용자는 완성된 CLI/desktop app을 받음. 내부 구조는 product가 결정.

• 사례: Claude Code (CLI + desktop), Gemini CLI (CLI), Goose (CLI + desktop)
• 장점: 사용자 즉시 사용 가능, UX 통제 가능
• 비용: 사용자가 내부 결정에 개입할 자리 좁음. strategic 사고 공간 제한

❌ 채택 시: 사용자에게 layer로 쌓을 부품을 줌. 사용자가 자기 product를 만듦.

• 사례: pi-mono (5 패키지 분리, 사용자가 골라 import)
• 장점: 사용자가 자기 segment에 fit하는 product를 직접 빌드
• 비용: 진입 장벽 높음 (코딩 요구)

⚠️ partial: Codex — protocol을 product로 노출 (CLI도 IDE도 같은 binary).

Trade-off 한 줄: 즉시 사용성 vs strategic 결정 공간

고려할 질문:

• v1.0 사용자가 코드를 쓸 수 있는 사람인가? (학생·연구자라면 yes일 가능성)
• 사용자에게 어디까지 결정을 위임할 것인가?
• product와 library 둘 다 가능한가? (core는 library, 그 위에 product를 layer로)

가정 3 — 단일 vendor lock?

무엇을 묻는가: 한 vendor (Anthropic / OpenAI / Google) 의 인프라·모델·과금에 묶이는 형태인가?

✅ 채택 시: 그 vendor의 모든 능력 활용. 인증·결제·grounding 통합.

• 사례: Claude Code (Anthropic), Codex (OpenAI), Gemini CLI (Google)
• 장점: 진입 장벽 낮음 (구독 활용), 능력 통합 깊음
• 비용: vendor 정책·가격·spec 변경에 직접 노출

❌ 채택 시: vendor 무관 substrate. 사용자가 자기 vendor 선택.

• 사례: Goose, pi-mono
• 장점: vendor lock 회피, 학내 토큰 endpoint 자유 사용
• 비용: vendor 능력 공통분모만 사용

Trade-off 한 줄: 통합 깊이 vs 자유

고려할 질문:

• 학내 토큰 프로그램이 상업적 lock에 묶이면 안 되는 조건이 있는가?
• 사용자가 자기 vendor를 고르는 자유가 strategic 가치인가?
• 가정 1 (vendor 추상화)과 직결됨

가정 4 — Tool = MCP 일원화?

무엇을 묻는가: agent의 모든 tool을 MCP (Model Context Protocol) 표준으로 통일할 것인가, 아니면 자체 정의 + MCP 혼용인가?

✅ 채택 시: 모든 tool을 MCP server로 노출. 자체 tool format 없음.

• 사례: Goose (rmcp::model::Tool 처음부터), Codex (양방향), Gemini CLI (settings.json에 MCP)
• 장점: 70+ MCP extension ecosystem 무료 활용, 표준화
• 비용: in-process 가벼운 tool도 MCP overhead, MCP spec 변경 따라가야 함

❌ 채택 시: 자체 tool format. MCP는 별 layer로.

• 사례: Claude Code (자체 tool, MCP는 부분 통합)
• 장점: tool 호출 fast path, format 자유
• 비용: ecosystem 격리, 자체 tool 정의 부담

⚠️ pi-mono: Extension API로 자체 tool 등록. MCP 통합은 약함.

Trade-off 한 줄: ecosystem 무료 vs fast path 자유

고려할 질문:

• 학내 통합 모듈을 MCP server로 노출하면 가치 있는가? (yes일 가능성 — 다른 학내 사용자도 사용 가능)
• 가벼운 in-process tool도 MCP overhead를 감내할 것인가?

가정 5 — 차등 확장 비용?

무엇을 묻는가: 모든 확장(plugin/tool/skill)이 같은 token 비용인가, 비용 차등 모델 (zero-cost / low / medium / high)인가?

✅ 채택 시: hooks(0 token) / skills(low, lazy load) / plugins(medium) / MCP(high) 4단계.

• 사례: Claude Code (유일하게 명시적 차등 모델)
• 장점: Context Rot 회피, 사용자가 경제 cost 보고 strategic 선택
• 비용: 4가지 mechanism 구현 부담

❌ 채택 시: 단일 확장 모델 (Extension API 하나).

• 사례: Goose, pi-mono, Codex, Gemini CLI
• 장점: 단순함, 학습 곡선 짧음
• 비용: Context Rot 직격, 모든 확장이 token 씀

Trade-off 한 줄: context 효율 vs 구현 단순함

고려할 질문:

• v1.0 사용자가 long-running task를 돌릴 것인가? (그럼 차등 비용 필수)
• zero-cost lifecycle event(hook)가 학내 use case에 가치 있는가?

가정 6 — OS-level sandbox?

무엇을 묻는가: agent action을 OS 커널 수준에서 격리할 것인가, UI 토글/Docker container/없음인가?

✅ 채택 시: Linux Landlock + seccomp, macOS Seatbelt, Windows AppContainer 사용.

• 사례: Codex (3-tier: read-only/workspace-write/danger-full-access)
• 장점: 진짜 deny-first. UI 우회 불가
• 비용: OS별 구현, 복잡

❌ 채택 시: UI 토글 또는 권한 enum.

• 사례: Claude Code (7 layer지만 OS 커널 X), pi-mono (없음)
• 장점: 단순
• 비용: compound command bypass 같은 우회 가능

⚠️ partial: Goose (capability 일부), Gemini CLI (Trusted Folders, 단순한 trust 모델)

Trade-off 한 줄: 진짜 보안 vs 구현 비용

고려할 질문:

• 학내 환경에서 어디까지 신뢰할 수 있는가? (학생 개인 컴퓨터 vs 학내 공용 서버)
• 사용자 아이디어 2 (sandbox + rollback)가 이 가정과 직결됨

가정 7 — 외부 protocol 표준 (ACP)?

무엇을 묻는가: agent ↔ client 통신을 Agent Client Protocol (vendor neutral 표준)으로 노출할 것인가, 자체 RPC인가?

✅ 채택 시: ACP를 외부 인터페이스로. 다른 client (IDE, web)가 같은 protocol로 연결.

• 사례: Goose (goose-acp crate), Codex (Op/EventMsg + ACP 정렬)
• 장점: vendor 무관 client ecosystem, 합성 가능
• 비용: ACP spec 따라가야, 자체 protocol 자유 일부 손실

❌ 채택 시: 자체 RPC 또는 stdin/stdout.

• 사례: pi-mono (자체 JSONL RPC), Claude Code (자체 protocol), Gemini CLI (stream-json)
• 장점: 자유로운 protocol 설계
• 비용: 다른 client와 통합 어려움

Trade-off 한 줄: 생태계 호환 vs 설계 자유

고려할 질문:

• v1.0이 다른 client (VS Code, web, 학내 시스템 UI)에서도 호출되어야 하는가?
• ACP가 충분히 mature하다고 보는가? (현재 v0.11)

가정 8 — 진입 장벽 = product 핵심?

무엇을 묻는가: 진입 장벽 낮추기를 product의 모든 결정 단계에 input으로 넣을 것인가?

✅ 채택 시: OAuth/free tier/zero-config가 product 1순위. 사용자가 "왜 안 써?"의 모든 이유를 제거.

• 사례: Gemini CLI (Google OAuth + 60 req/min 무료)
• 장점: 채택률 ↑, 사용자 빠르게 늘어남
• 비용: 진입 장벽 감소가 vendor lock 강화가 될 수 있음

❌ 채택 시: 사용자가 설정·인증·환경을 직접 다룸.

• 사례: Goose, pi-mono, Claude Code, Codex 대부분
• 장점: 통제·자유
• 비용: 진입 장벽 높음

⚠️ partial: Codex (ChatGPT plan 통합으로 부분 진입 장벽 낮춤)

Trade-off 한 줄: 채택률 vs lock 위험

고려할 질문:

• 학내 토큰 = 학내의 free tier인데, 이걸 product 결정의 input으로 박을 것인가?
• zero-config에 가까운 학내 진입 path를 만들 수 있는가?

가정 9 — OSS 세션 공유 문화?

무엇을 묻는가: 사용자의 agent 세션 데이터를 오픈 dataset으로 공유하는 문화를 product에 박을 것인가?

✅ 채택 시: 사용자가 자기 session을 (anonymized) Hugging Face 같은 곳에 publish. 산업·다른 사용자 학습에 기여.

• 사례: pi-mono (Hugging Face dataset)
• 장점: real-world data가 benchmark보다 강함, 산업 학습 가속, 학내에선 학내 학습 가속
• 비용: privacy 신중 처리 필요, opt-in 명시 UI

❌ 채택 시: 세션은 vendor 안에 가둠. 사용자가 명시적으로 export 안 하면 외부 안 나감.

• 사례: 나머지 4개 모두
• 장점: privacy 단순
• 비용: 산업 학습 lever 미활용

Trade-off 한 줄: 학습 가속 vs privacy 단순함

고려할 질문:

• 학내 segment에서 공유 dataset이 다른 학생 학습에 가치 있을 것인가? (yes일 가능성 매우 높음)
• privacy 처리를 어떻게? (코드 redact, 학번 hash, 옵트인 명시)

가정 10 — 재단/표준 거버넌스?

무엇을 묻는가: 프로젝트를 단일 회사/maintainer 소유로 둘 것인가, 재단(Linux Foundation 같은) 거버넌스에 둘 것인가?

✅ 채택 시: 재단 가입, 다중 contributor governance, license 안전성 ↑.

• 사례: Goose (block → AAIF/Linux Foundation 이전)
• 장점: 장기 안정성, 단일 maintainer 위험 회피
• 비용: 거버넌스 절차 무겁움, 결정 속도 ↓

❌ 채택 시: 개인/회사 소유.

• 사례: pi-mono (개인 maintainer), Claude Code/Codex/Gemini (회사 소유)
• 장점: 결정 빠름, 일관된 vision
• 비용: bus factor 1, license 변경 위험

Trade-off 한 줄: 안정성 vs 결정 속도

고려할 질문:

• v1.0이 얼마나 오래 갈 프로젝트인가?
• 학내 사용자에게 상업적 license 안전성이 중요한가?
• 지금 결정할 것이 아니라 v1.0 후 검토할 사안일 수도

가정 11 — 학내·niche segment 1순위?

무엇을 묻는가: 일반 개발자 대상이 아니라 특정 좁은 segment(학내 등)를 1순위 사용자로 둘 것인가?

✅ 채택 시: 모든 결정 단계에 그 segment의 fit을 input으로. 학내 vocabulary, 학내 endpoint, 학내 use case.

• 사례: 5 reference 모두 ❌. 시장 빈 좌표.
• 장점: segment 종속적 해자, 88%/12% gap에서 12%로 갈 가능성 ↑
• 비용: 다른 segment에 fit 약함, 시장 크기 작음

❌ 채택 시: 일반 개발자 도구.

• 사례: 5 reference 모두
• 장점: 시장 큼
• 비용: 88% pilot 실패 cohort 합류 위험

Trade-off 한 줄: segment fit vs 시장 크기

고려할 질문:

• 학내 segment의 진짜 demand가 무엇인가? (수강신청? 과제? 동아리? 연구실?)
• 학내 segment 성공 후 다른 캠퍼스로 복제가 가능한가?
• 사용자가 명시적으로 학내를 1순위로 한다고 말함 → 이 가정은 ✅로 가는 흐름

가정 12 — 로컬 광고 = 수익 lever?

무엇을 묻는가: 수익 모델로 로컬 광고 + AI 추천을 넣을 것인가?

✅ 채택 시: agent가 사용자 컨텍스트(시간표·전공·동아리) 기반으로 학내·로컬 사업자(서점·카페·학원·과외) 추천. 광고주 결제.

• 사례: 5 reference 모두 ❌. 시장 빈 좌표.
• 장점: 대기업이 못 들어오는 hyper-local 광고, segment 종속적 해자, 핵심 수익 lever
• 비용: 광고/비광고 표기 명확성 부담, 학내 정책상 가능 여부 확인 필요, 신뢰 위험

❌ 채택 시: vendor billing / freemium / enterprise 라이선스 등 일반 모델.

• 사례: 5 reference 모두
• 장점: 단순
• 비용: 학내 segment 종속적 해자 lever 미활용

Trade-off 한 줄: segment 해자 vs 단순함·신뢰 부담

고려할 질문:

• 학내 토큰 프로그램 ToS가 상업적 사용 허용하는가? (결정적 변수)
• 광고/비광고 표기를 어떻게 할 것인가?
• 사용자가 명시적으로 H6 광고 모델 제안 → 이 가정은 ✅ 방향

★ 사용자가 결정할 빈 매트릭스

위 12개 가정의 자세한 가이드를 보고, 사용자의 v1.0 답을 채울 자리:

사용자가 명시적으로 말한 것 (대화에서)

내가 임의로 박은 답과 분리해서, 사용자가 직접 명시한 결정만:

→ 이게 현재 시점에서 v1.0의 사실상 spec 일부. 나머지 가정 12개는 사용자가 직접 채울 자리.

명시한 결정과 12 가정의 연결 — hint

사용자가 명시한 결정에서 자연스럽게 도출되는 12 가정의 답들 (참고용 — 사용자가 검토 후 결정):

→ 5-7개 가정은 명시 결정에서 자연 도출. 나머지 5-7개(4·5·7·8·9·10)는 사용자가 추가 검토 필요.

다음 단계

1. 사용자가 빈 매트릭스 12칸을 채움 — 위 가이드를 보고 ✅/❌/⚠️ + 메모
2. 가정 4·5·7·8·9·10이 추가 검토가 필요한 부분 — 명시 결정에서 자연 도출 X
3. 12 가정 답이 정해지면 → v1.0 spec 골격 완성 → 그 위에서 design 노트들 작성

관련

• stateless-definition — v0.1 정의 (사용자가 명시한 stateless 시작점)
• references-goose · references-claude-code · references-codex · references-pi-mono · references-gemini-cli
• software-fundamentals-thesis — Matt thesis (사용자 흡수)
• research-to-production-gap — 12% pattern (사실 데이터)
• industry-hot-issues-2026 — 시장 컨센서스 (사실 데이터)

Sources

위 5 references 노트의 모든 1차 자료. 별도 source 없음.