서로 다른 세 표면을 함께 운영하기

"셋 다 텍스트를 검색한다는 말은 맞아. 하지만 그 한 문장만 믿고 합치면 가장 비싼 실수를 하게 돼."

겉으로 닮은 검색 표면이 셋 있어

뇌의 자기 메모리는 개인 vault와 대화 기록에서 현재 대화에 필요한 맥락을 찾아 시스템 프롬프트에 넣어.
실시간 공동 집필 경로는 지금 편집하는 노트에서 모델 완성에 필요한 주변 내용을 찾아.
코퍼스 엔진은 10년 치 완성된 글에서 결정론적이고 인용 가능한 결과를 찾아.

셋 다 쿼리와 관련 텍스트를 주고받으니 하나로 합치고 싶어져. 하지만 공통점은 인터페이스 표면에만 있어.

범위와 수명, 모델의 자리가 다르다

뇌의 메모리는 대화 단위이고 공동 집필은 현재 문서 단위야. 둘 다 모델에게 맥락을 주는 것이 목적이라 판단 흐름 안에 모델이 있는 게 맞아. 코퍼스 엔진은 오랜 아카이브 전체를 맡고, 모델 없이도 돌아가며, 대화가 끝난 뒤에도 인용이 남아야 해. 크기만 다른 것이 아니라 지켜야 할 제약 자체가 달라.

합치면 한쪽의 비용을 다른 쪽에 떠넘겨

Lantern을 뇌의 메모리와 합치면 검색이 대화 범위와 모델 가동 여부에 묶여. 반대로 공동 집필을 코퍼스 엔진에 넣으면 아직 쓰는 중인 문장까지 영구 수집하고 내용 기반 주소를 만들어야 해. 각 기능에 맞던 설계를 이웃의 요구에 맞추느라 망가뜨리는 셈이지.

제약이 다르면 통합은 비용을 없애지 않고 멀쩡한 쪽으로 옮겨. 닮은 함수 둘을 합치기 전에 지연 시간과 범위, 수명, 의존성, 실패 허용 범위를 비교해. 목록이 다르면 별도 표면으로 두는 게 맞아.

합치지 않은 이유도 아키텍처에 남겨

'모든 검색을 하나로 만들자'는 생각은 다시 나타날 거야. 그래서 어느 표면이 무엇을 소유하고 어떤 제약을 지키는지 문서의 표로 남겨야 해. 다음 사람이 한 달을 써서 같은 실패를 재발명하기 전에 경계의 이유를 읽을 수 있도록. 무엇을 만들었는지뿐 아니라 왜 일부러 합치지 않았는지도 설계 기록의 일부야.

Code

호출 모양은 같아도 지켜야 할 제약은 서로 달라·python

# Three surfaces. Same-looking interface, incompatible constraints.

# 1. The brain's memory — judgment-shaped, conversation-scoped.
def recall_for_prompt(conversation_id: str, query: str) -> list[str]:
    ...  # feeds a system prompt. Model in the loop by design. Ephemeral scope.

# 2. Live co-writing — judgment-shaped, document-scoped, right-now.
def cowrite_context(active_note: str, cursor: int) -> list[str]:
    ...  # embeds notes you're editing THIS MINUTE to feed completions.

# 3. The corpus engine — engine-shaped, archive-scoped, permanent.
def search(query: str, mode: str = "hybrid") -> list[CitableResult]:
    ...  # no model in the path. Citable. Must work with the brain down.

# Merge #3 into #1 -> the engine inherits a model dependency and conversation
#                     scope. Search no longer works when the brain is down.
# Merge #2 into #3 -> a note you're still typing must be permanently ingested
#                     and content-addressed just to autocomplete a sentence.
# The interfaces rhymed. The constraints never did.

Exercise

네가 아는 시스템에서 누가 합치자고 제안할 만큼 비슷해 보이는 컴포넌트 둘을 찾아. 각각 제약을 적어: 지연 시간 예산, 범위, 수명, 의존성, 실패 허용 범위. 목록을 비교해. 의미 있게 다르면, 다음 사람의 한 달을 아껴줄 '왜 이걸 안 합쳤나' 한 문단 노트를 써.

Hint

핵심 질문은 '서로 닮았나?'가 아니라 '같은 제약을 지키나?'야. 호출 형식이 같아도 제약이 다르면 별개의 표면으로 남겨야 해. 서로 맞지 않는 제약을 문서로 적어 두면, 나중에 겉모양만 보고 잘못 합치는 일을 막을 수 있어.

겉으로 닮은 검색 표면이 셋 있어

범위와 수명, 모델의 자리가 다르다

합치면 한쪽의 비용을 다른 쪽에 떠넘겨

합치지 않은 이유도 아키텍처에 남겨

Code

External links

Exercise

Progress

댓글 0