더 짧은 호출이 틀린 호출이야
음성 공급자를 직접 부르는 건 몇 줄이면 돼. 인증하고, 텍스트 보내고, 오디오 받고. 형제를 거쳐 가는 건 딱히 나아 보이지 않아. 홉이 하나 늘고, 의존이 하나 늘고, 떠 있어야 하는 서비스가 하나 생기니까. 줄 수만 놓고 보면 직접 호출이 이겨.
줄 수가 안 보여주는 나머지 전부에서 져. 내레이션을 만드는 건 연산 하나가 아니라 관심사 네 개가 묶인 거고, 그중 '공급자한테 텍스트 보내기'는 하나뿐이거든.
- 정체성 해석 — 이름 하나가 특정 계정의 특정 목소리로 풀려. 그 대응은 '누가 말하고 있나'에 대한 사실이지 매개변수가 아냐.
- 정규화 — 합성 전에 텍스트한테 벌어지는 일. 숫자를 어떻게 읽는지, 약어를 어떻게 펴는지, 어떤 문장부호가 쉼이 되는지.
- 캐시 계약 — 뭘 같은 요청으로 칠 건지, 따라서 언제 새 테이크 대신 이전 테이크를 돌려줄 건지.
- 공급자 호출 — 직접 버전이 실제로 대체하는 유일한 부분.
구현이 둘이면 벌어지는 일
이 관심사들을 도구 둘로 쪼개면 조용히 갈라져. 원인을 짚기 어려운 방식으로. 한쪽은 약어를 펴고 다른 쪽은 글자로 읽어. 한쪽은 쌍반점을 쉼으로 치고 다른 쪽은 안 쳐. 한쪽은 원문으로 캐시하고 다른 쪽은 정규화된 문장으로 캐시해서, 똑같아 보이는 요청이 다르게 굴어. 증상은 크래시가 아냐. 어느 도구가 만들었느냐에 따라 내레이션이 미묘하게 자기 같지 않게 들리는 거고, 누가 알아챌 즈음엔 두 구현 다 사용자가 붙어 있어.
이게 능력 추출을 소비자 쪽에서 본 그림이야. 보통은 생산자 시점으로 설명하지. 공유되는 걸 뽑아내고, 소유자를 주고, 호출자들이 거기 의존하게 하라고. 호출자 쪽에 서 있으면 규율의 느낌이 달라. 매일같이 더 짧은 길을 거절하는 일이고, 그건 규칙이 취향이 아니라 소유권으로 적혀 있을 때만 버텨.
호출이 아니라 관심사를 뽑아내. 뭔가한테 소유자가 필요한지 판정하는 기준은 코드 양이 아냐. 독립된 구현 둘이 만들어낼 차이가 '사용자는 알아채는데 테스트는 못 잡는' 종류인지야. 목소리, 서식, 반올림, 시간대, 정렬 순서. 그런 것들이야말로 소유자가 정확히 하나여야 해.