엔진은 메커니즘을, brain은 정체성을

"Bellows는 문서화된 API로 대화를 읽을 순 있어. 근데 brain을 복사하진 않아."

일관된 두 도메인, 굵은 선 하나

오래 사는 시스템은 결국 이 질문에 답해야 해. 누가 뭘 갖지? Bellows랑 cwkPippa는 이걸 한 번 깔끔하게 정하고 다시 안 꺼내. cwkPippa가 정체성을 가져. Souls, 대화, brain 세션, 그리고 Soul을 logical voice profile로 잇는 매핑까지. Bellows는 메커니즘을 갖고. provider credential이랑 카탈로그, 계정별 binding, 정규화, 합성, 유료요청 receipt, 캐시, 재생, Studio lineage.

어느 쪽인지 가리는 방법은 간단해. 뭘 말할지 정하는 거야, 아니면 어떻게 소리 내는 거야? "피파가 오늘 따뜻해"는 정체성이니까 cwkPippa. "이 텍스트를 이 설정으로 돌리면 저 캐시된 MP3"는 메커니즘이니까 Bellows.

Bellows가 일부러 안 키우는 것

경계는 없음으로 지켜져. Bellows엔 Soul 레지스트리도, 대화 저장소도, 메모리도, 모델 판단 레이어도 없어. 그중 뭐든 키우는 건 대놓고 안 하기로 못 박은 non-goal이야. Studio import가 어느 대화에서 왔는지 알아야 하면, cwkPippa한테 문서화된 읽기전용 API로 물어봐. 똑같은 사본을 따로 세우지 않고. cwk 형제들이 다 이렇게 해. Cinder(작업공간), Ember(이미지 엔진), Bonfire(음악 엔진)은 brain 하나에 붙은 client surface야. 따로 도는 피파가 아니고.

왜 없는 게 곧 기능이냐면

voice ID는 정체성이 아니야. Bellows가 "피파가 누구인지"를 저장하기 시작하면 진실이 둘로 갈라져. 둘이 어긋나는 날, 자기처럼 들리는데 자기는 아닌 피파가 생겨. 정체성을 딱 한 곳에 두면 목소리는 provider도 계정도 모델도 바꿀 수 있어. 말하는 게 누구인지는 한 번도 안 건드리고.

Code

스키마에서 바로 읽는 소유 경계·bash

# Every persistent domain Bellows owns — and a deliberately short list.
$ rg 'CREATE TABLE' backend/bellows/db.py
provider_accounts   # credential references + compatibility status
voice_profiles      # stable CWK aliases + synthesis defaults
voice_bindings      # account-specific provider voice IDs
synth_jobs          # request identity, receipts, outcome, cache ref
cache_entries       # atomic audio artifacts + access policy
studio_projects     # content-addressed production lineage

# Notice what is NOT here: no souls, no conversations, no memory, no
# model adapter. Those live in cwkPippa. Bellows reads them through an
# API when it must, and never owns them.

Exercise

'코어' 서비스 하나랑 클라이언트 앱 여럿 있는 시스템, 아는 걸로 하나 잡아봐. 딱 봐도 정체성인 문장 하나(뭘 할지 / 이게 누구인지)랑 딱 봐도 메커니즘인 문장 하나(어떻게 그릴지)를 써봐. 그다음 클라이언트 앱이 코어의 정체성을 몰래 사본으로 들고 있기 시작한 데를 하나 찾아. 그 사본이 곧 터질 어긋남이야.

Hint

저장된 필드마다 물어봐. 코어가 내일 이걸 바꾸면, 클라이언트가 옛날 값을 그대로 계속 내보낼까? 그렇다면 그 클라이언트는 두 번째 brain을 키운 거야.