"변하는 한 가지를 추상화해. 나머지 전부는 찬란하게 구체적으로 둬."
물려받은 규칙
Firekeeper 는 아키텍처를 맨땅에서 발명 안 해 — Pippa 집에서 규칙을 물려받아: 추상 경계를 정확히 한 좁은 곳에 두고, 그 아래 모든 걸 특화하게 해. 브레인에선 그 이음새가 스트리밍-모델 API 고; 그 위 앱 전체는 한 모양을 가정해 구체적으로 쓰여. Firekeeper 에선 같은 규칙이 두 이음새에 적용돼: STT 엔진과 정리 브레인. 딴 데선 코드가 직접적이고 읽기 쉬워 — 인터페이스를 위한 인터페이스는 없어.
왜 전부 추상화 안 해?
솔깃한 실수는 앱 전체를 '프로바이더-중립' 으로 만드는 거야 — 오디오 계층, 삽입 계층, 설정 계층, 전부 혹시 몰라 추상화. 그건 진짜 비용을 상상의 이득과 맞바꿔. 모든 추상화는 누군가 뚫고 읽어야 하는 간접 계층이야. 한 곳에서 일어나는 교체를 가능하게 하려고 그 세금을 모든 파일에서, 영원히 내. 좁은-이음새 규칙은 뒤집어: 추상화 비용을 변이가 실제 사는 곳에서만 내고, 딴 데선 안 내.
넓은 추상화 (피함) 좁은 이음새 (이걸 함)
------------------------ ---------------------
모든 계층이 인터페이스 STT + 정리만 인터페이스
어디서나 교체 준비 교체가 일어나는 곳만 교체 준비
모든 파일에 간접 세금 딴 데선 구체적, 읽기 쉬움
절대 안 쓸 유연함 필요한 곳에 정확히 유연함비용은 하류로 흘러
더 깊은 원칙: 새 변종이 뭔가 필요하면(새 STT 엔진, 새 정리 브레인), 기존 이음새에 맞추는 비용을 그것이 흡수해 — 이음새가 걜 수용하려고 새 추상화를 키우지 않아. 구체적-먼저, 필요할-때-특화. 도착할지 모를 변종을 예상해 절대 일반화 안 해; 실제 도착하면 특화해. 그게 Pippa 가족이 코어를 작게 유지하면서 많은 표면을 지원하는 방식이고, Firekeeper 는 같은 규율을 따르는 그 표면 중 하나야.
변이가 있는 곳에 이음새를 둬. 진짜로 대안이 있는 한둘 — 여기선 어느 엔진이 널 듣고 어느 브레인이 정리하나 — 을 식별하고 정확히 걔네만 추상화해. 진짜 구현이 하나뿐인 건 구체적으로 남아. 추상화는 교체 가능성을 사는 비용 — 실제 교체할 곳에서만 사.
구체적-먼저가 추상적-먼저를 이겨. 구체적 버전을 쓰고, 두 번째 진짜 구현이 강제할 때만 인터페이스를 추출해. 두 번째 구현 전에 발명한 인터페이스는 거의 항상 틀린 모양을 추측하고, 현실이 나타나면 어차피 리팩터해. 두 번째 케이스가 이음새를 설계하게 둬.