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의 답에서 읽어. 카탈로그는 뷰 열 때랑 명시적 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

'저장하냐 물어보냐'의 기준은 변화율이랑 소유권이야. 저쪽이 말없이 바꿀 수 있는 거면, 사본 두지 말고 물어보기랑 맞추는 규칙을 둬.