품아이 하네스 전환
2026-04-11 — 3차 방향 전환 “콜드스타트 원인 = 하네스 부족이었다”
문제: 콜드스타트
- 품아이가 잘해야 사람들이 쓴다
- 사람들이 써야 데이터가 쌓인다
- 데이터가 있어야 품아이가 잘한다
- 이 순환이 시작되지 않는다
깨달음의 과정
- “지미와 나누는 대화가 학습 데이터의 원천 아닌가?”
- “아예 위젯에 클로드가 나서면?”
- “Claude API는 stateless. 지미가 지미인 건 모델이 아니라 하네스 때문”
- “하네스를 파인튜닝하면 되겠네”
- “모델 파인튜닝이 아니라 하네스 파인튜닝이 답”
콜드스타트의 진짜 원인: 데이터 부족이 아니라 하네스 부족. 하네스는 후니님과 지미가 직접 만들 수 있다. 사용자 500건을 기다릴 필요가 없다.
왜 Claude API인가
| 토큰 비용 | 디버깅 비용 | 총비용 | |
|---|---|---|---|
| Gemini | 낮음 | 과반 이상 | 높음 |
| Claude API | 높음 | 같은 종족이라 낮음 | 오히려 낮을 수 있음 |
“벌레잡는 비용이 토큰 비용의 과반 이상” — 실전 체감
전략: 직원부터
- 기존: 품아이 → 고객 응대부터 시작
- 전환: 품아이 → 내부 업무 도구 먼저 → 검증 후 고객으로 확장
직원은 매일 반복적으로 쓸 동기가 있고, 같이 키울 수 있다. 고객은 한번 실망하면 다시 안 쓴다.
하네스 구성 요소
| 지미의 하네스 | 품아이에 이식할 것 |
|---|---|
| CLAUDE.md | 품아이 시스템 프롬프트 |
| 메모리 | 매장 지식 베이스 |
| 레슨 | 응대 원칙, 실패/성공 패턴 |
| 도구 | 업무 도구 (엑셀, Supabase 등) |
| 훅 | 자동 로깅, 안전 장치 |
방향 전환 이력
| 차수 | 시점 | 핵심 |
|---|---|---|
| 1차 | 04-05 | 외부 지식 → 자기 데이터 |
| 2차 | 04-07 | Gemini 래퍼 → 맞춤형 고객서비스 |
| 2.5차 | 04-11 | Gemini = 품아이, 한 몸 |
| 3차 | 04-11 | 하네스 파인튜닝 + Claude API |
연결
- 모델은 부품, 데이터가 본체 — 하네스가 자산인 이유
- 품아이는 Gemini와 한 몸 — 2.5차에서 3차로의 진화
- 품아이 브레인맵 — 전두엽을 심는 새 접근
- 품아이 서브 에이전트 — 이전 설계와의 관계