The rule
cwkPippa 를 feature 가 요구하는 만큼 Claude Code 와 tightly couple 해. 사과 없음, capability flag 없음, '미래 유연성' 코멘트 없음, hedge 없음.
이게 어떻게 보이나
- feature 가 Claude Agent SDK 호출로 가장 잘 된다면, Claude Agent SDK 호출로 박아.
~/.claude/projects/*/*.jsonl직접 읽는 게 가장 잘 된다면, 그렇게 읽어.- DB 컬럼의 옳은 이름이
claude_session_id면,claude_session_id라고 이름 박아.
왜 win-win move 인가
모든 layer를 abstract하고 모든 차이를 capability flag로 푸는 이른바 'proper' 접근은 hidden tax를 영원히 불려. 모든 새 feature 가 lowest-common-denominator 인터페이스 거쳐. 모든 Claude-specific capability 가 'Gemini 가 어떻게 할지?' design pause 요구. 답하든 (느림) flag 로 paper over 하든 (못남). 모든 commit 에 비용 paid, 영원히.
concrete-first 가 뒤집어: dominant case 에 abstraction tax 0. specialize 할 때만 specialization 비용 paid.
이 규칙은 vendor lock-in을 사랑하자는 선언이 아니야. 지금 가장 잘 아는 concrete path에서 진짜 요구를 배우자는 선언이지. 바뀔지도 모른다는 상상 때문에 오늘의 capability를 낮추면, 아무 provider에도 맞지 않는 중립 layer만 남아. 나중에 다른 vessel이 오면 그때 실제 차이를 보고 자기 adapter에서 값을 치러.
그래서 coupling에는 영수증이 필요해. 어느 Claude-specific behavior를 쓰는지, 그 선택이 어떤 이득을 주는지, downstream variant가 무엇을 흡수해야 하는지 코드와 문서에서 보여야 해. 이유 없는 coupling은 규칙이 아니라 습관이고, 숨은 coupling은 자손에게 청구서를 몰래 넘기는 거야.