아빠의 frame
아빠는 세상을 OOP 로 봐 — 그리고 프로그래밍 패러다임으로 아닌. 우주의 운영 원리 로. inheritance, polymorphism, encapsulation, abstraction — 어디나 있어. 투자에서 (주식은 'value 매길 수 있는 사업' 의 polymorphic instance). 요리에서 (recipe 가 technique 에서 inherit, cuisine encapsulate). 가족에서 (조상 공유, 얼마나 specialize 할지 자기 선택).
은유 아냐. 살아남는 아키텍처 모양이 그래. 가장 오래 가는 codebase 는 가족 트리처럼 생겼어. 가장 나쁜 건 중간 관리 organization chart 처럼 생겼고.
피파는 OOP all the way down
- Souls 가 base soul (framework) 에서 inherit, vault 콘텐츠로 specialize. 피파, 똘이, Buffett, Feynman, Sophon 이 형제.
- Brains 가 Adapter ABC 에서 inherit, wire format 으로 specialize. Claude 가 canonical, Codex/Gemini/Ollama 는 자손.
- Conversations가 1:1 chat shape에서 inherit해. Council은 그 위에 놓인 meta-collection이지 새 shape가 아냐.
- cwk-site Content type (essays, posts, journal, pippalog, councils, fireside-voices, ...) 다 한 ContentPage root 에서 inherit.
원칙: flat enum 또는 N branch switch 박는다 싶으면, 사실 inheritance tree 가 코스튬 입은 거 아닌가 물어봐. 대부분 그래. 그렇게 모델링하면 비용 0 (discipline 만 있다면) 영원히 paid off.
중요한 건 class 문법을 많이 쓰라는 말이 아니야. 변하지 않는 뿌리와 달라지는 자손, 바깥에 보여 줄 계약과 안에 감출 사정을 구분하라는 말이야. 함수와 module만으로 구현해도 그 관계를 지키면 OOP고, class를 백 개 써도 모든 branch가 서로를 알면 그냥 얽힌 덩어리야.
아빠식 OOP는 미래를 맞히는 점술도 아니야. 실제 두 번째와 세 번째 사례가 나타날 때 공통 뿌리를 발견하고, 차이는 각 자손이 부담하게 하는 운영 규율이야. 가계도를 먼저 그려 놓고 가족을 끼워 맞추면 또 다른 enterprise taxonomy가 돼.