짓기 vs 빌리기

"왜 그냥 호스팅 RAG 서비스 안 썼어? 정직한 답이 '짓는 게 낫다' 가 아니라 — '내 제약 중 아무것도 그쪽 목록에 없었다' 라서."

진짜 답을 받을 자격이 있는 질문

손으로 지은 코퍼스 엔진을 보는 누구나 즉시 물어: 호스팅 검색 서비스가 수십 개고 일부는 훌륭한데 — 왜 지어? 자화자찬 답들이 있고 다 나빠. "짓는 게 항상 낫다." "벤더를 안 믿는다." "더 재밌다." 그중 어느 것도 진지한 리뷰를 못 견디고, 어느 것도 이 엔진이 존재하는 이유가 아냐. 진짜 답은 더 밋밋하고 훨씬 강해.

빌리는 게 보통 옳아

일반 경우를 먼저 인정하고 시작해, 사실이니까: 대부분 프로젝트에서, 대부분의 경우, 호스팅 검색 서비스를 쓰는 게 올바른 엔지니어링 결정이야. 유지되는 시스템, 남의 운영 부담, 그리고 오후 하나면 작동하는 제품을 얻어. 요구사항이 범용이면 — 문서 좀 색인하고, 질문에 좀 답하고 — 직접 짓는 건 보통 시작할 수 있었던 곳에 느리게 도착하는 방법이야. 이걸 인정 못 하는 build 결정은 결정이 아냐; 정당화를 입은 취향이야.

정직한 답은 제약 불일치야

그러니 짓는 논거는 구체적이어야 해. 이 엔진이 지켜야 했던 실제 제약을 줄 세워: 아무의 일도 아닌 개인의 평생 코퍼스. 검색 경로에 모델 없음, 그래서 모델 서버가 꺼져도 검색이 돼. 완전 오프라인 결정론. 사는 곳에 정확히 안 건드려진 채 남는 원본. 10년 뒤에도 resolve 돼야 하는 citation. 어떤 재수집도 재생성 못 하는 판단을 쥔 증거 레이어. 이제 어느 호스팅 서비스가 그 목록에 최적화하는지 물어. 없어 — 나빠서가 아니라, 범용 호스팅 RAG 를 위해 지어졌고, 그 제약 중 하나도 그 목록에 없어서. 그쪽 흠이 아냐; 불일치야.

제약이 특수하고 동시에 내구성 있을 때 지어. 특수: 네 요구사항이 시장이 최적화하는 것과 진짜로 달라. 내구성: 10년 뒤에도 여전히 네 요구사항이야. 둘 다 성립해야 해. 특수하지만-일시적 제약은 빌리고 적응해야 한다는 뜻이고, 범용이지만-내구성 있는 건 당연히 빌려야 한다는 뜻이야. 오직 교집합 — 10년 뒤에도 가질 특이한 요구사항 — 만이 엔진 소유를 정당화해. 두 질문을 정직하게 물어, 안 그러면 자존심으로 짓고 아키텍처라 부를 거야.

10년 테스트

내구성 절반이 이걸 기울여. 개인 글의 코퍼스는 수십 년에 걸쳐 쌓여 — 대부분 회사보다, 대부분 제품보다, 확실히 대부분 가격 모델보다 오래 살 거야. 내 말을 찾는 능력을 빌리면 내 지적 역사를 남이 날 계속 서비스할 관심에 의존하게 만든 거야: deprecate 하나, 가격 변경 하나, 종료 하나, 조용한 정책 변경 하나면 네 아카이브가 인질이야. 일 전체가 20년 뒤에도 작동하는 거인 시스템한텐, 소유가 이념이 아냐. 요구사항이야.

Code

두 칸 다 yes 여야 해 — 아니면 자존심으로 짓는 거야·text

THE BUILD-VS-RENT TEST — both columns must say YES to build.

  CONSTRAINT                          PARTICULAR?   DURABLE (10 yrs)?
  ----------------------------------  ------------  -----------------
  Private lifelong personal corpus    yes           yes
  No model in the retrieval path      yes           yes
  Works fully offline, deterministic  yes           yes
  Originals never move from disk      yes           yes
  Citations resolve a decade later    yes           yes
  Evidence layer holds judgments      yes           yes
  ----------------------------------  ------------  -----------------
  VERDICT: build.

  Compare a typical project:
  "Index our docs, answer questions"  no            no   -> RENT.

  Particular but not durable  -> rent, adapt later.
  Durable but not particular  -> rent, definitely.
  Neither                     -> rent, obviously.
  BOTH                        -> own the engine.

Exercise

이미 제품이 있는데 네가 지은(또는 짓고 싶은) 걸 잡아. 두 칸 테스트를 정직하게 돌려: 제약을 나열하고, 각각 진짜로 특수(시장이 거기 최적화 안 함) 하고 내구성(10년 뒤에도 참) 있는지 표시해. 두 칸을 진짜 항목으로 못 채우면, '이건 빌려야겠다' 문장을 쓰고 어떤 느낌인지 봐. 그 움찔이 네가 아키텍처라 부르려던 자존심이야.

Hint

'특수' 에 냉혹해져. '빨랐으면 좋겠어' 는 특수가 아냐 — 다들 원하고 시장이 서비스해. '경로에 모델 없이 10년 뒤 resolve 되는 인용 가능한 결과를 돌려줘야 해' 는 특수야, 시장이 주는 걸 가리키며 틈을 보일 수 있으니까.