---
status: completed
task_id: task-1936+1
type: feature
scope: dashboard/naver-blog
created_at: 2026-04-18
---

# Context Notes

## 현재 상태
- NaverBlogView.js:967-981 — 이미 model 드롭다운 존재 (sonnet/haiku/gemini/gpt 4개)
- routes_post.py:1898 — VALID_MODELS = {"sonnet", "haiku", "gemini", "gpt"}
- blog_writer.py:91-140 — model별 분기: sonnet/haiku → claude CLI, gemini → gemini CLI, gpt → openai SDK

## CLI 확인 결과
- claude CLI: /home/jay/.local/bin/claude, --model 옵션으로 alias(sonnet/haiku) 또는 full name(claude-sonnet-4-6) 지원
- gemini CLI: /home/jay/.nvm/versions/node/v24.14.0/bin/gemini, -p 옵션 사용
- codex CLI: /home/jay/.nvm/versions/node/v24.14.0/bin/codex, exec 서브커맨드
- GLM: /home/jay/workspace/tools/glm-call.py, z.ai API (OpenAI 호환) 직접 호출

## 3 Step Why
1st Why: "왜 이 설계가 필요한가?" → 현재 모델이 4개로 고정되어 세부 모델 선택 불가. 사용자가 품질/속도/비용 trade-off를 직접 제어할 수 있어야 함.
2nd Why: "왜 모델 ID 매핑 딕셔너리 접근이 최선인가?" → 각 모델별 CLI 호출 방식이 다르므로 (claude CLI / gemini CLI / codex CLI / openai SDK / glm API), 모델 ID → {provider, cli_model_name} 매핑이 가장 확장 가능한 구조.
3rd Why: "왜 이 접근이 다른 대안보다 나은가?" → 대안1(모든 모델을 API 호출로 통일)은 claude/gemini/codex CLI의 인증 체계가 다르므로 비현실적. 대안2(프론트에서 provider+model 따로 선택)는 UX 복잡도 증가. 매핑 딕셔너리는 기존 코드 구조를 최소 변경하면서 확장 가능.