때로는 답이 빠져 있는 것이 아니라, 흩어져 있을 뿐이다.

몇 주 전, 저는 모든 엔지니어가 한 번쯤 해봤을 것 같은 행동을 스스로 하고 있다는 것을 깨달았습니다.

브라우저 탭을 다섯 개 열어두었습니다.

ADR(Architecture Decision Record).

Jira 티켓.

Slack 스레드.

실행 매뉴얼(runbook).

설정 파일(configuration file).

이 모든 것은 같은 문제에 관한 것이었습니다.

하지만 그 어느 것도 제 질문에 대한 답을 주지 못했습니다.

다섯 가지를 모두 읽고 나서야 그림이 명확해졌습니다.

그 순간, 저는 제가 더 이상 '검색(searching)'하고 있지 않다는 것을 깨달았습니다.

저는 '재구성(reconstructing)'하고 있었습니다.

검색은 실패하지 않았다

질문 자체는 간단했습니다.

서비스 X가 API 게이트웨이 검사를 우회하는 이유는 무엇인가요?

검색은 자신이 해야 할 대로 작동했습니다.

게이트웨이를 설명하는 ADR을 찾아냈습니다.

재시작 방법을 설명하는 실행 매뉴얼(runbook)을 찾았습니다.

서비스 X를 언급하는 Jira 이슈를 찾았습니다.

누군가

대부분의 검색(retrieval) 시스템 아래에는 조용히 깔려 있는 하나의 가정이 있습니다.

그 답은 단일 문서 안에 존재할 것이라고 예상하는 것입니다.

유사도(Similarity)가 계산됩니다.
문서들이 순위 매겨집니다(ranked).
상위 k개(Top-k)가 반환됩니다.

이 방식은 사실 확인 검색(factual lookup)에는 놀라울 정도로 잘 작동합니다.
하지만 조직의 기억(organizational memory)에 대해서는 훨씬 덜 잘 작동합니다.

왜냐하면 조직들은 중요한 결정들을 한 곳에 기록하는 경우가 거의 없기 때문입니다.

디자인 검토(design review)는 하나의 문서를 산출합니다.
구현(implementation)은 또 다른 것을 산출합니다.
운영팀은 실행 매뉴얼(runbook)을 작성합니다.
누군가는 Slack에서 예외 사항을 설명합니다.
몇 달 후, 이 네 가지 모두 기술적으로는 정확합니다.
하지만 어느 것도 전체 이야기를 전달하지 못합니다.

관계가 의미를 지닌다 (Relationships carry meaning)

그 문서들을 연결하는 것이 종종 문서 자체보다 더 중요합니다.

Slack 스레드는 동기(motivation)를 설명하고,
ADR은 아키텍처(architecture)를 설명하며,
커밋(commit)은 구현을 설명하고,
실행 매뉴얼(runbook)은 결과를 설명합니다.

개별적으로는 불완전합니다. 하지만 함께할 때는 하나의 설명을 이룹니다.
이것이 제가 검색 품질 측정 기준을 단순히 '올바른 문서'를 반환했는지 여부로만 보는 것에 점점 회의적이 된 이유입니다.
때로는 단일한 답이 존재하지 않습니다.
때로는 그 답 자체가 여러 문서들 사이의 관계인 경우도 있습니다.

나에게 변화시킨 것 (What changed for me)

저는 다음과 같은 질문을 멈추었습니다:

어떤 문서가 답을 포함하는가?

대신 이렇게 질문하기 시작했습니다:

어떤 문서들이 함께 답을 설명하는가?

이 작은 변화는 제가 검색에 대해 생각하는 방식을 바꿨습니다.
검색 자체가 덜 유용해졌기 때문이 아닙니다.
단지 검색은 종종 첫 번째 단계일 뿐이라는 것을 깨달았기 때문입니다.
발견(Discovery)은 검색 결과가 나타난 후에 시작됩니다.

조직들은 문서를 거의 잃어버리지 않습니다.
오히려 그 문서들 사이의 연결고리를 잃습니다.
그리고 일단 그 연결고리가 사라지면, 모든 문서는 여전히 찾을 수 있지만—설명 자체는 조용히 검색 불가능해집니다.

다음에는 제가 반복적으로 본 또 다른 패턴, 즉 아무것도 삭제되지 않았음에도 불구하고 조직이 무언가를 잊어버릴 수 있는 이유에 대해 탐구하고 싶습니다.