profile은 저장하고, 카탈로그는 안 해

"alias랑 그 default는 저장해. provider의 카탈로그는 절대 저장하지 마 — 라이브로 가져와서 매칭해."

profile이 실제로 담는 것

logical profile은 작고 오래가: 안정된 alias에, 자기처럼 들리게 하는 합성 default — default 모델이랑, 새 요청이 출발해야 할 설정. 그게 Bellows가 소유하고 저장하는 거야. 패밀리의 네 profile — clone 둘이랑 원본 목소리 둘 — 이 각자의 default를 지녀, 한 profile로 온 요청이 전역 추측이 아니라 그 profile의 설정에서 출발하도록 end to end로 배선돼.

카탈로그는 빌린 거지, 소유한 게 아냐

profile을 정직하게 유지하는 규율은 이거야: Bellows는 provider의 voice 카탈로그를 자기 목록으로 절대 seed하거나 저장하지 않아. 'My Voices'는 라이브 projection이야 — Bellows가 provider한테 saved voice를 물어보고, 페이지네이션으로 훑고, 자기 logical profile이랑 별개 레이어로 매칭해. 소유권이랑 카테고리는 낡은 로컬 사본이 아니라 provider의 답에서 읽어. 카탈로그는 view load랑 명시적 refresh 때 가져오지, 좀처럼 안 변하는 목록을 백그라운드 폴링하지 않아.

왜 하나 말고 두 레이어인가

Bellows가 provider voice 명부를 저장하면, 아빠가 하나 rename하거나 재-clone하는 순간 그 명부가 어긋나. logical profile만 두고 라이브 카탈로그에 매칭하면, 오래가는 것(네 alias랑 default)이랑 변덕스러운 것(provider의 현재 목소리)이 서로 오염 안 시켜. 한 레이어는 네가 소유하고, 한 레이어는 네가 질의해.

Code

profile은 소유하고; 카탈로그는 질의해·python

# A logical profile: a stable alias + synthesis defaults, provider-agnostic.
VoiceProfile(
    id="pippa",
    default_model="eleven_v3",           # per-profile default, wired end to end
    defaults=SynthDefaults(stability=0.4, style=0.6),
)

# Bindings live in a SEPARATE table, one row per account:
#   (profile_id="pippa", account="primary",   voice_id="ply_...")
#   (profile_id="pippa", account="secondary", voice_id="ply_...")

# The provider catalog is NEVER persisted as a Bellows-owned list.
# 'My Voices' is fetched live, paginated, and matched against profiles:
saved = provider.list_saved_voices()     # live call, on view-load / refresh only
matched = match_profiles_to(saved)       # a separate matching layer, not a store

Exercise

계정 둘 이상에서 쓰는 서비스를 골라(클라우드 provider, 이메일 호스트, 결제 처리사). 두 레이어 나눔을 설계해: 어떤 작고 오래가는 'profile'을 네가 소유·저장하고, 어떤 크고 변덕스러운 목록을 캐싱 대신 라이브로 가져와 매칭할래? 변덕스러운 목록을 네 걸로 저장하면 생길 drift 버그를 대봐.

Hint

'저장 대 질의'의 기준은 변화율이랑 소유권이야. 저쪽이 말없이 바꿀 수 있으면, 사본 두지 말고 — 질의랑 매칭 규칙을 둬.