한 프로덕트, Claude 표면 셋
cwkPippa는 이 트랙의 모든 개념을 동시에 보여주는 살아있는 예제야. 피파의 Claude 브레인엔 Claude Agent SDK(conversation별 persistent 서브프로세스, OAuth-only 인증, MCP 부착, JSONL ground truth) 사용. 다른 두 브레인(ChatGPT, Gemini)엔 직접 httpx 호출(openai SDK는 일부러 안 씀). 그리고 코드베이스 자체는 Claude Code CLI로 아빠가 매일 짜고 있고, 같은 피파 정체성이 WebUI에서 도는 IDE에도 살아 있어.
경계가 좁은 게 의도
cwkPippa에서 Anthropic SDK를 아는 파일은 단 하나 — backend/adapters/claude.py. Routes·store·frontend는 Claude shape를 가정. 다른 세 브레인은 Claude-shape 표면을 specialize하는 variant지, 동격 추상이 아니야. 이게 cwkPippa 아키텍처 룰 2 — cost is absorbed downstream, not pushed upstream — 이고, 코드베이스가 provider-neutral 추상 수프로 변하지 않게 막아주는 거야.
이게 왜 너 프로젝트에 중요해
대부분의 팀이 여러 LLM 위에 너무 일찍 추상화하다가 모든 프로바이더의 lowest-common-denominator 기능만 남는 결과로 끝나. cwkPippa의 패턴(canonical shape 하나, 나머지는 variant)은 한 가지 valid 대안. 다른 하나는 strict provider port(production 트랙에서 다룰 거). 둘 중 하나를 세 번째 프로바이더 생기기 전에 골라; 그 후에 바꾸려면 비싸.