"변하는 한 가지만 추상화해. 나머지는 전부 당당하게 구체적으로 둬."
물려받은 규칙
Firekeeper 는 아키텍처를 맨땅에서 발명하지 않았어. Pippa 집에서 규칙을 물려받았지. 추상 경계는 정확히 한 좁은 곳에 두고, 그 아래는 전부 특화하게 둔다. 브레인 쪽에선 그 이음새가 스트리밍 모델 API 야. 그 위에 올라간 앱들은 전부 한 가지 모양을 전제하고 구체적으로 쓰였고. Firekeeper 에선 같은 규칙이 이음새 두 곳에 걸려. STT 엔진, 그리고 정리 브레인. 나머지 자리에선 코드가 곧이곧대로고 읽기 쉬워. 인터페이스를 위한 인터페이스 같은 건 없어.
왜 전부 추상화 안 해?
여기서 넘어가기 쉬운 게, 앱 전체를 어느 프로바이더에도 안 묶이게 만들고 싶어지는 거야. 오디오 계층도, 삽입 계층도, 설정 계층도, 혹시 모르니까 전부 추상화. 그건 진짜 비용을 내고 상상 속 이득을 사는 거야. 추상화는 하나하나가 누군가 뚫고 읽어야 하는 한 겹이거든. 교체는 한 곳에서만 일어나는데, 그 한 곳을 위해 모든 파일에서, 영원히 세금을 내는 거지. 좁은 이음새 규칙은 이걸 뒤집어. 추상화 비용은 변하는 부분이 실제로 사는 곳에서만 내고, 딴 데선 안 내.
넓은 추상화 (피함) 좁은 이음새 (이걸 함)
------------------------ ---------------------
모든 계층이 인터페이스 STT + 정리만 인터페이스
어디서나 교체 준비 교체가 일어나는 곳만 교체 준비
모든 파일에 우회 비용 딴 데선 구체적, 읽기 쉬움
절대 안 쓸 유연함 필요한 곳에 정확히 유연함비용은 하류로 흘러
더 깊은 원칙이 하나 있어. 새로 들어온 놈이 뭔가 필요하면, 그러니까 새 STT 엔진이든 새 정리 브레인이든, 기존 이음새에 맞추는 비용은 그놈이 흡수해. 이음새가 걔를 받아 주려고 새 추상화를 키우는 게 아니라. 구체적인 걸 먼저 쓰고, 필요해지면 그때 특화해. 올지도 모를 놈을 미리 짐작해서 일반화하는 일은 절대 없어. 실제로 오면 그때 특화하는 거야. Pippa 가족이 코어를 작게 유지하면서 표면을 여럿 지탱하는 방식이 이거고, Firekeeper 도 같은 규율을 따르는 표면 중 하나야.