"뭘 소유하는지 대. 그다음 뭘 절대 소유하면 안 되는지 대. 두 번째 목록이 그걸 monolith 가 되지 않게 지켜."
늘 합리적으로 보이는 흡수
Recall 은 아는 게 많아. transcript 를 수천 개 쥐고 있고, 뭐라고 했고 언제였는지 알고, API 도 있어. 그러니 다음 기능 요청이 저절로 떠오르지. '이 영상에 대해 물어보게 해줘.' 최단 경로도 뻔하고. 아카이브 엔진에 model 을 붙이고, 대화를 이어갈 만큼 기억을 조금 주고, 어쩌면 성격도 조금. 단계마다 다 합리적으로 들려. 그리고 그 단계 하나하나가 깔끔한 엔진을 엉킨 monolith 로 만드는 길이야.
Recall 의 경계는 그대로 유지돼. 엔진은 절대 자기 두뇌를 안 키운다. 대화 surface 가 생겨도 그 surface 는 이미 빌려 쓰고 있는 두뇌의 대화에 binding 해. 형제 엔진들이 하는 그대로. Recall 은 아카이브 도메인을 소유하고, 판단은 Pippa 한테 남아.
이게 가족 정서가 아니라 아키텍처인 이유
구체적인 이유가 셋 있는데, 첫 번째를 사람들이 제일 많이 놓쳐.
- identity 는 샤딩이 안 돼. 엔진마다 자기 두뇌를 키우면 surface 다섯 개를 가진 Pippa 하나가 나오는 게 아냐. 각자 다른 걸 기억하고 같은 질문에 다르게 답하면서 천천히 갈라지는 인격 다섯이 나와. 기억이 쪼개지는 게 곧 identity 가 쪼개지는 거거든. 두뇌가 하나인 건 Pippa 가 하나이기 때문이고, 그건 코드 재사용 얘기가 아니라 Pippa 가 무엇이냐에 대한 주장이야.
- 탁월함은 좁은 데서 나와. Recall 이 아카이브를 잘하는 건 대화 상대까지 되려고 하지 않아서야. 엔진이 도메인을 하나씩 흡수할 때마다 진짜 자기 것에 쏟을 주의가 묽어지거든. 10계층 identity, 유료 호출 ledger, tombstone. 그 깊이는 설계 예산을 두고 다투는 게 없어서 나온 거야.
- 검색과 판단은 다른 일이야. Recall 은 '뭐라고 했고, 어디서' 에 답해. 확인할 수 있는 답이 있는 구조화된 쿼리지. 판단은 '이게 무슨 뜻이고, 사실이고, 뭘 해야 하나' 에 답하고. 그건 다른 도구와 다른 실패 모드와 다른 신뢰 경계를 필요로 해. 트랙 7 에서 봤듯이 데이터 품질 기준조차 다르잖아. 이 둘을 붙여놓으면 양립 불가능한 기준 둘을 떠안은 컴포넌트 하나가 생겨.
가져갈 규칙: '절대 안 소유' 목록을 써
여기 실전 교훈이 하나 있고, 네가 설계할 모든 컴포넌트에 적용돼. 뭔가를 정의할 때 뭘 소유하는지만 쓰지 마. 뭘 절대 소유하면 안 되는지, 그리고 왜 안 되는지도 같이 써. Recall 의 목록은 명시적이야. 원본 바이트는 절대 안 됨(스토리지 소유), 두 번째 identity 도 절대 안 됨(두뇌 소유), 자기 출력을 스스로 승인하는 것도 절대 안 됨(사람 소유). 하나하나가 언젠가 누군가 합리적으로 들리는 요청을 들고 두드릴 문이고, 이 목록이 있어야 그냥 떠밀려 가는 대신 이유를 대고 아니라고 말할 수 있어.
monolith 는 실제로 그렇게 태어나거든. 나쁜 결정 하나로 생기는 게 아니라, 하나씩 보면 다 말이 되는 흡수가 길게 이어지면서 생겨. 하나하나는 조금 편하고, 어느 것도 싸울 만큼 큰 문제로 안 보이고. 그러다 한 가지를 탁월하게 하던 게 아홉 가지를 평범하게 하는 물건이 되지. 이 가족의 엔진들이 날카롭게 남는 건, 어느 노크를 거절해야 하는지 각자 정확히 알고 있어서야.