9장의 평가가 시스템이 좋은지를 알려 준다면, 관측 가능성은 어떤 특정한 질의에서 시스템이 왜 그렇게 하고 있는지를 알려 준다. 이 장에 새로운 알고리즘은 없다. 화려하지 않은 기반 공사가 있을 뿐이다. 그러나 믿음직하게 도는 검색 체계와 알 수 없이 실패한 뒤 사흘을 들여 해명하는 체계를 가르는 것이 바로 그 화려하지 않은 일이다.
2025년 11월 말, 어느 의료 기술 회사의 선임 플랫폼 엔지니어가 밤 9시 14분에 최고의료책임자(CMO)로부터 슬랙 메시지를 받았다. 여섯 달 전 배포한 임상 의사결정 지원 어시스턴트가 어느 의사에게 소아 패혈증 관리의 최신 임상 지침과 어긋나는 답을 주었다는 것이다. CMO는 지침을 직접 읽어 답이 틀렸음을 확인했고, 질의를 재생해 시스템이 그 답을 냈음을 확인했다. 그리고 아침이 되기 전에 알고 싶어 했다. 이 일이 어떻게 일어났는지, 같은 범주의 다른 답들도 틀렸는지.
사흘 뒤, 그는 여전히 조사 중이었다. 검색 체계는 정교한 에이전틱 RAG 파이프라인이었다. 하이브리드 검색, 재순위화, 자기교정 성찰 — 2부와 3부의 모든 패턴이 들어 있었다. 주당 임상 질의 4만 건을 처리했다. 공들여 지어졌고 폭넓게 시험되었다. 다만 함께 지어지지 않은 것이 있었다. 프로덕션급 관측 가능성. 그에게 로그는 있었다. 방대한 로그가 일곱 개 서비스에 흩어져 저마다의 형식으로 쓰였고, 어느 것도 질의 ID로 엮이지 않았다. 지표도 있었다. 평균 지연, 오류율, 집계된 품질 점수를 보여 주는 대시보드가 있었다. 없던 것은 CMO의 물음에 답하는 데 실제로 필요한 것이었다. 그 의사의 특정 질의가 처리될 때 무슨 일이 있었는지에 대한, 하나의 조리 있는 추적(trace).
손으로 시간선을 재구성했다. 한 클러스터에서 임베딩 서비스 로그를 끌어오고, 다른 데서 벡터 데이터베이스 질의 로그를, 또 다른 데서 리랭커 로그를 끌어왔다. 서비스 사이에 어긋난 타임스탬프를 맞추었다. 어느 청크가 실제로 회수되었고, 어느 청크가 성찰을 살아남았고, 언어 모델이 그 틀린 답을 낼 때 무엇을 맥락으로 받았는지 식별했다. 하루가 저물 무렵 부분적 그림이 나왔다. 임베딩 모델은 현행 지침을 포함한 청크 집합을 회수했으나, 리랭커가 그것을 끌어내리고 질의의 표면 어휘를 더 많이 담은 옛 지침 문서를 올렸다. 성찰 계층은 그 옛 지침을 충분하다 판정하고 생성으로 나아갔다. 시스템은 환각하지 않았다. 더는 권위 없는 문서에 충실히 접지되어 있었다.
이것이 한 번의 실패인지 패턴인지 조사하는 데 썼다. 분산 추적도 질의 수준 상관도 없었으므로 "지난 한 달간 리랭커가 폐기된 문서를 현행 문서 위로 올린 모든 질의를 보여 달라" 같은 질의를 던질 수 없었다. 정보는 로그에 있었으나 질의 가능하지 않았다. 여러 로그 스트림을 긁고 독자 형식을 파싱하고 대략의 시각으로 레코드를 이어 붙이는 스크립트를 직접 써야 했다. 하루가 저물 무렵 지난 3주간의 유사 사례 열일곱 건을 찾아냈다. 어느 것도 어떤 감시에도 걸리지 않았고, 각각이 임상적으로 유관한 오답을 실제 의사에게 전달한 사례였다.
보고서를 썼다. 찾아낸 것, 데이터가 없어 밝힐 수 없었던 것, 이 범주의 실패가 되풀이되지 않게 하려면 필요한 변경. 가장 큰 변경은 알고리즘적인 것이 아니라 기반적인 것이었다. 질의별 분산 추적, 추적 ID로 엮인 구조화 로그, 검색 실패와 재순위화 실패와 생성 실패를 가르는 검색 고유 지표, 집계만이 아니라 패턴을 드러내는 대시보드. 그것들이 없다면 앞으로의 모든 사고가 또 한 번의 사흘짜리 발굴 작업을 요구할 것이었다.
회사는 이후 두 달을 정확히 그 관측 스택을 짓는 데 썼다. 다음 사고가 왔을 때 — 넉 달 뒤, 임베딩 서비스가 업그레이드되고 좁은 범주의 임상 질의에서 재현율이 퇴행했을 때 — 사흘 걸렸던 진단 작업이 마흔 분이 되었다. 당직 엔지니어는 신고된 실패 질의의 추적을 끌어와 임베딩 단계의 퇴행을 식별하고, 같은 시간창에서 같은 검색 패턴을 보이는 다른 질의를 추적 저장소에 질의하고, 패턴을 확인하고, 임베딩 서비스를 롤백했다. 사용자에게 닿은 영향은 퇴행의 시작과 롤백 사이에 처리된 소수의 질의로 한정되었다. 관측에 들인 투자는 그날 점심때까지 이미 제 값을 했고, 이후 모든 사고에서 계속 값을 할 것이었다.
원래의 사흘짜리 조사를 촉발한 그 CMO는 나중에 사후 검토에서 이렇게 말했다. 두 사고의 차이는 시스템이 나아졌다는 데 있지 않다 — 두 사고 모두 실재하는 결함을 드러냈다 — 차이는 두 번째 것이 같은 업무일 안에 알 수 있고, 진단할 수 있고, 회복할 수 있는 일이었다는 데 있다고.
관측 가능성은 검색을 블랙박스에서 계측된 체계로 바꾸는 운영 규율이다. 그것이 없으면 디버깅은 발굴 고고학이다. 느리고 비싸고 불완전하다. 있으면 디버깅은 질의 가능한 분석이다. 빠르고 포괄적이며, 집계 지표가 가리는 패턴을 드러낼 수 있다.
일반 소프트웨어의 관측 가능성은 세 기둥 위에 서 있다. 특정 요청에 무슨 일이 있었는지 보여 주는 분산 추적, 여러 요청에 걸친 거동을 집계하는 지표, 특정 지점의 상세 사건을 담는 로그. 기둥은 잘 확립되었고 도구는 성숙했으며 전통적 서비스에 대한 패턴은 잘 기록되어 있다. 검색 체계는 표준 패턴이 상자에서 꺼내자마자 다루어 주지 않는 복잡함을 더한다. 검색 관측 가능성의 무엇이 고유한지 이해하는 것이 계측을 제대로 짓는 전제다.
검색 체계의 추적은 하나의 질의를 처리의 모든 단계에 걸쳐 따라간다. 질의가 도착한다. 질의 변환이 검색 표적형 변형을 낸다. 임베딩이 변형마다 벡터를 만든다. 벡터 데이터베이스가 후보 청크를 돌려준다. 리랭커가 순서를 고친다. 성찰 계층이 충분함을 평가한다. 생성이 답을 낸다. 추적은 이 전부를 구조화된 스팬으로, 시각과 입력과 출력과 결정과 함께 담아야 한다.
지표는 질의별 추적 데이터를 패턴을 드러내는 통계로 집계한다. 단계별 지연 백분위, 참조 질의 집합에 대한 재현율, 리랭커의 승격률, 성찰 판정 분포, 생성 토큰 소비. 지표 설계는 추적이 담는 단계 분해를 반영해야 한다. 지표가 움직였을 때 팀이 해당 추적으로 파고들 수 있어야 하기 때문이다. 종단 간 지연은 보이면서 단계별 지연은 보이지 않는 대시보드로는 느린 임베딩과 느린 생성을 구별할 수 없다.
로그는 스팬 속성으로 넣으면 추적을 부풀릴 상세 사건이 가는 곳이다. 회수된 청크의 전문, 언어 모델 응답 전문, 중간 추론 흔적. 규율은 모든 로그 줄을 추적 ID와 스팬 ID로 부모 추적에 상관시키는 것이다. 그러면 팀은 추적을 끌어와 수동 대조 없이 상세 로그까지 따라갈 수 있다. 앞의 첫 사고는 로그가 없어서가 아니라 엮이지 않아서 생긴 문제였다. 데이터는 있었으나 이어 붙일 수 없었다.
추적에서 검색 고유의 관심사는 각 스팬에 어떤 데이터를 담느냐다. 임베딩 스팬에는 입력 텍스트와 결과 벡터(적어도 상관을 위한 벡터의 해시)가 필요하다. 검색 스팬에는 돌려준 청크의 ID만이 아니라 유사도 점수를 지닌 후보 집합이 필요하다. 재순위화 스팬에는 재순위화 전과 후의 순서가 모두 필요하다. 그래야 퇴행 분석이 검색 실패와 재순위화 실패를 가를 수 있다. 성찰 스팬에는 판정 — 확신, 모호, 오류 — 과 그 판정을 이끈 청크가 필요하다. 생성 스팬에는 언어 모델에 최종적으로 주어진 맥락과 모델의 응답이 필요하다. 규율은 시스템의 외부 경계만이 아니라 단계 사이의 경계에서 계측하는 것이다. 내부 단계 지표가, "시스템에 뭔가 문제가 있다"가 아니라 "리랭커가 이 부류의 질의에 X를 하고 있다"고 말할 수 있게 만드는 진단 능력이다.
추적은 임베딩·검색·재순위화·성찰·생성의 구조화 스팬으로 질의별 여정을 담는다. 각 스팬은 자기 단계에 고유한 입력과 출력과 결정을 나른다.
지표는 추적 데이터를 단계별 통계로 집계한다 — 지연 백분위, 참조 집합 대비 재현율, 리랭커 승격률, 성찰 판정. 단계 수준 지표는 외과적 디버깅을 가능하게 하고, 시스템 수준만의 지표는 전체론적 디버깅을 강요한다.
로그는 추적을 부풀릴 상세를 나르며, 추적 ID와 스팬 ID로 추적에 상관되어 진단 작업이 수동 대조 없이 질의를 종단 간으로 따라갈 수 있게 한다.
OpenTelemetry는 업계를 가로지르는 분산 추적의 사실상 표준이 되었고, 2026년의 프로덕션급 RAG는 거의 예외 없이 이를 추적의 바탕으로 쓴다. 표준화의 이점은 호환 백엔드의 넓은 생태계 — Jaeger, Tempo, Honeycomb, Datadog, New Relic 등이 모두 OpenTelemetry 형식을 소비한다 — 와 그 형식을 내는 계측 라이브러리의 넓은 생태계다.
스팬 구조. 표준 패턴은 사용자 질의마다 하나의 루트 스팬을 두고, 처리 단계마다 자식 스팬을 두는 것이다. 루트 스팬은 질의 텍스트, 사용자 식별자(또는 세션 ID), 라우팅 결정(어느 에이전트나 파이프라인이 처리했는지), 최종 응답을 나른다. 자식 스팬마다 한 처리 단계를 담는다. 각 단계 안에서, 그 자체로 관찰할 만한 하위 연산이 다시 스팬을 갖는다. 하이브리드 검색을 돌린다면 검색 단계에 벡터 검색과 어휘 검색의 자식 스팬이 있을 수 있고, 성찰 단계에는 청크별 관련성 평가의 자식 스팬이 있을 수 있다.
스팬 중첩의 깊이는 각 층이 주는 진단 값어치에 달렸다. 과잉 계측은 저장이 비싸고 항행하기 어려운 추적을 낳고, 과소 계측은 사고가 요구하는 진단 물음에 답할 수 없는 추적을 낳는다. 쓸모 있는 어림 규칙은 이렇다. 지연이나 거동이 독립적으로 퇴행할 수 있는 하위 연산은 자기 스팬을 가질 값어치가 있다. 부모와 늘 함께 성공하거나 함께 실패하는 연산은 따로 스팬을 둘 필요가 좀처럼 없고 추적의 크기만 부풀린다.
# 검색 파이프라인의 OpenTelemetry 계측 패턴 from opentelemetry import trace from opentelemetry.trace import Status, StatusCode tracer = trace.get_tracer('rag.pipeline') def answer_query(query: str, user_id: str) -> dict: with tracer.start_as_current_span('rag.query') as root: root.set_attribute('rag.query.text', query) root.set_attribute('rag.user.id', user_id) # 1. 질의 변환 with tracer.start_as_current_span('rag.query_transform') as span: variants = query_transformer.transform(query) span.set_attribute('rag.variants.count', len(variants)) # 2. 하이브리드 검색 with tracer.start_as_current_span('rag.retrieve') as span: candidates = retriever.search(variants, k=50) span.set_attribute('rag.candidates.count', len(candidates)) span.set_attribute('rag.candidates.ids', [c.id for c in candidates[:10]]) span.set_attribute('rag.candidates.scores', [c.score for c in candidates[:10]]) # 3. 재순위화 — 전후의 순서 변화를 함께 남긴다 with tracer.start_as_current_span('rag.rerank') as span: reranked = reranker.rerank(query, candidates) span.set_attribute('rag.rerank.promotions', compute_promotions(candidates, reranked)) # 4. 성찰 with tracer.start_as_current_span('rag.reflect') as span: verdict = reflector.evaluate(query, reranked[:10]) span.set_attribute('rag.reflect.verdict', verdict.verdict) span.set_attribute('rag.reflect.confidence', verdict.confidence) if verdict.verdict == 'incorrect': root.set_status(Status(StatusCode.ERROR, 'evidence_insufficient')) return refusal_response(verdict) # 5. 생성 with tracer.start_as_current_span('rag.generate') as span: answer = generator.generate(query, reranked[:10]) span.set_attribute('rag.tokens.used', answer.token_count) return answer.to_dict()
추적은 공짜가 아니다. 트래픽이 많은 프로덕션은 하루 수백만 스팬을 낼 수 있고 전부 저장하는 것은 운영상 비싸다. 표준 패턴은 지혜로운 표집이다. 특정 성질을 보이는 질의(오류, 거부, 높은 지연, 낮은 확신)는 추적을 100% 붙잡고, 평범한 질의는 더 작은 비율로 붙잡는다. 현대 추적 체계 대부분이 받치는 꼬리 기반 표집은 추적이 끝난 뒤에 표집 결정을 내리게 해 준다. 흥미로운 거동을 보인 추적을 지키고 나머지를 버리는 것이다.
검색 체계에서 표집 결정은 흔히 검색 고유의 신호에 달린다. 성찰 판정이 '모호'나 '오류'였던 질의는 언제나 추적해야 한다. 재순위화가 후보 집합을 극적으로 재배열한 질의는 지킬 값어치가 있다. 생성이 거부나 경고를 낸 질의는 보존해야 한다. 확신 판정과 안정된 순위를 지닌 평범한 질의는 1~5%로 표집할 수 있다. 이 선별적 보존이 저장 비용을 묶어 두면서, 앞의 첫 사고에 없던 진단 값어치를 지킨다.
종단 간 지연이나 전체 답 품질 같은 집계 지표는 무언가 잘못되었다고 알려 주지, 무엇이 잘못되었다고 알려 주지 않는다. 프로덕션급 관측 가능성은 단계 사이의 경계에서 재는 지표를 요구한다. 실패를 그것을 들여온 특정 부품으로 국소화할 수 있는 지표다.
임베딩 단계. 가용성, 지연 백분위, 처리량, 오류율에 더해 검색 고유의 추가가 있다. 임베딩 일관성 — 같은 입력이 시간이 가도 같은 임베딩을 내는가. 일관성은 모델 버전을 가로질러 보장되지 않으며, 소리 없는 임베딩 표류는 기록된 프로덕션 실패 양식이다. 완화책은 임베딩을 주기적으로 재생성해 과거 기준선과 견주는 참조 입력 집합을 유지하는 것이다. 허용 문턱을 넘어 변하면 경보가 울린다.
검색 단계. 참조 질의 집합에 대한 재현율이 토대 지표다. 3장에서 인덱스 건강 감시로 세운 것이 여기서 프로덕션 런타임 지표로 이어진다. 재현율 너머로, 프로덕션 관측은 돌려준 후보 집합의 유사도 점수 분포를 추적한다. 상위 1위 유사도가 시간이 가며 아래로 옮겨 간 체계는 인덱스 퇴화나 임베딩 표류나 말뭉치 분포 변화를 겪고 있을 수 있다. 각각 처방이 다르되 모두 점수 분포에 드러난다.
재순위화 단계. 리랭커가 후보 집합에 무엇을 하고 있는지 드러낸다. 승격 분포 — 평균적 후보가 전후로 몇 자리를 움직이는가. 1위 안정성 — 재순위화 전후로 1위가 같은 청크인 질의의 비율은 얼마인가. 이것은 재순위화가 아무 효과가 없는 경우(리랭커 오설정이거나 1단 검색이 이미 잘 순위된 경우)를 드러낸다. 그리고 리랭커와 임베딩 모델의 불일치 — 리랭커가 최고 유사도 청크를 상위 k 밖으로 밀어내는 빈도 — 가 바로 앞의 첫 사고를 잡아냈을 지표다. 리랭커가 체계적으로 옛 문서를 새 문서 위로 올리고 있었던 그 사고다.
성찰과 생성. 성찰 판정 분포 — 확신·모호·오류의 비율 — 는 부적절한 사례를 우아하게 거부하는 체계와 부실한 증거로 과신하며 생성하는 체계를 가르는 운영 신호다. 이 분포의 갑작스러운 이동은 흔히 문제를 알린다. 오류 판정이 뛰면 말뭉치 변화나 검색 퇴행을 시사할 수 있다. 확신 판정이 뛰면 성찰 계층의 보정이 느슨한 쪽으로 표류했음을 시사할 수 있는데, 처리량 지표는 나아지므로 이는 감춰진 품질 위험이다. 생성 지표는 토큰 사용량, 지연, 거부율에 9장의 답 품질 지표를 프로덕션 트래픽에 걸쳐 표집한 것을 더한다.
집계된 종단 간 지표 — 총 지연, 전체 품질 — 는 많은 질의를 평균하기에 느리게 움직인다. 질의의 10%에 영향을 주는 단계 수준 퇴행은 종단 간 지표를 1퍼센트의 몇 분의 일만큼 움직일 수 있고, 그것은 통상 변동의 잡음 바닥에 한참 묻힌다. 집계 지표는 움직이지 않고, 실패는 감지되지 않는다.
단계 수준 지표는 같은 퇴행을 곧바로 드러낸다. 리랭커가 질의의 일부에서 오작동하고 있다면, 종단 간 지표가 움직이지 않을 때에도 리랭커 지표는 분명히 움직인다. 아키텍처의 규율은 부분집합의 퇴행이 그것이 실제로 태어난 단계에서 보이도록 단계 경계에서 계측하는 것이다.
원격 측정은 원재료다. 대시보드는 팀이 그것을 운영적 통찰로, 결정을 움직이는 패턴과 대응을 촉발하는 경보로 바꾸는 방식이다. 프로덕션급 검색 관측 가능성에는 운영상 중요한 패턴을 드러내는 작은 한 벌의 대시보드가 있다. 모든 것을 보이려다 결국 쓸모 있는 아무것도 보이지 못하는 잡동사니 대시보드가 아니다. 네 범주가 대부분의 프로덕션 필요를 덮는다.
호출을 받은 당직 엔지니어가 가장 먼저 보는 한눈 대시보드다. 건강한 체계와 그렇지 않은 체계를 가르는 소수의 지표만 보인다. 종단 간 p95 지연, 오류율, 질의 물량, 거부율.
규율은 이것을 최소로 유지하는 것이다. 지표를 더하면 진단 값어치가 희석되고, 빼면 실패 신호를 놓칠 수 있다. 대부분의 팀은 운영 첫 몇 달에 걸쳐 내용을 다듬는다. 의미 있는 신호를 낸 적 없는 지표를 덜어 내고, 없어서 사고 감지가 어려웠던 지표를 더하는 식이다.
지금 체계는 성한가
체계를 단계로 분해해 보인다. 임베딩 지연과 일관성, 검색 재현율과 점수 분포, 재순위화 승격 패턴, 성찰 판정 분포, 생성 비용과 품질.
목적은 진단이다. 건강 대시보드가 무언가 잘못되었음을 보일 때, 이 대시보드가 엔지니어에게 어느 단계를 조사할지 알려 준다. 앞의 사흘짜리 디버깅에서 엔지니어가 가장 필요로 했고 갖지 못했던 것이 바로 이것이다.
실패는 어디서 태어났나
코호트를 가로질러 성능을 견준다. 질의 유형, 사용자 세그먼트, 문서 범주, 관할. 집계 지표가 안정적인 동안 특정 코호트가 퇴화할 수 있다. 9장 이커머스 플랫폼의 벤치마크가 좋아 보이는 동안 한 세그먼트의 품질이 퇴행했던 그 방식으로.
표준 구현은 추적 구조를 타고 번지는 지표 태그를 쓴다. 모든 스팬이 질의 유형과 사용자 세그먼트, 그 밖에 잘라 볼 만한 차원의 메타데이터를 나르므로, 같은 바탕 지표를 어느 차원으로든 집계할 수 있다.
누가 영향을 받고 있나
지표의 이상에서 그것을 낳은 구체적 추적으로 데려가는 인터페이스다. 대시보드라기보다 질의 인터페이스이며, 통상 추적 체계의 고유 질의 UI에 흔한 진단 물음을 미리 담아 둔 것이다.
"지난 한 시간 동안 성찰 판정이 '오류'였던 추적을 보여 달라." "최상위 재순위 청크가 폐기 문서였던 추적을 보여 달라." "생성이 답을 거부한 추적을 보여 달라."
"무언가 잘못됐다"를 "이 질의들이다"로
많은 팀이 검색 체계가 진화하며 수십 개의 대시보드를 짓는다. 서비스마다 하나, 팀마다 하나, 언젠가 특정 질문을 했던 임원마다 하나. 대시보드는 늘어나고, 어느 것도 잘 관리되지 않고, 사고 때 어느 것을 봐야 옳은지 분명하지 않으며, 당직 엔지니어는 대시보드를 믿을 수 없어 결국 로그를 grep 한다.
규율은 정전(正典)의 작은 한 벌 — 건강, 단계 분해, 코호트 비교, 파고들기 — 을 명시적 소유자와 정기 검토 주기와 함께 유지하는 것이다. 몇 달간 아무도 열어 보지 않은 대시보드는 언젠가 쓸모 있을지 모른다는 이유로 보존하지 말고 지워야 한다.
검색 관측 가능성은 민감한 데이터를 붙잡는다. 질의에 개인정보가 담길 수 있고, 회수된 청크에 기밀 문서가 들어 있을 수 있고, 생성된 답이 민감한 내용을 재현할 수 있다. 진단 작업을 가능하게 하는 그 관측이 동시에 공격면과 준법 의무를 만든다. 이 장을 닫는 규율은 관측을 책임 있게 운영하는 일이다. 쓸모 있을 만큼 담고, 필요 이상은 담지 않고, 데이터의 생애주기를 의도적으로 관리하는 것.
검색 관측의 기본 가정은 질의와 회수된 내용에 개인식별정보가 담길 수 있다는 것이어야 한다. 응용이 그것을 다루도록 설계되지 않았더라도 그렇다. 사용자는 응용이 청하지 않았어도 질의에 이름과 주소와 식별자와 건강 정보와 금융 정보를 예사로 적는다. 표준 패턴은 계측 계층에서의 마스킹이다. 질의 텍스트가 스팬에 붙기 전에 마스킹 함수를 지나며 패턴이 유형별 토큰(NAME_REDACTED, ADDRESS_REDACTED)으로 바뀐다. 진단에 필요한 구조는 남기고 실제 민감 내용은 덜어 내는 것이다. 완벽하지 않다 — 어떤 자동 탐지도 재현율 100%에 이르지 못한다 — 그러나 관측 데이터에 대한 엄격한 접근 통제와 결합하면 위험을 상당히 줄인다. 고위험 규제 환경이라면 관측 스택도 바탕 응용과 같은 준법 검토를 받아야 한다.
프로덕션 물량에서 모든 질의의 모든 추적을 저장하는 것은 비싸다. 표집이 비용을 줄이지만, 진단 작업이 의지하는 추적을 버리지 않도록 신중해야 한다. 이 장에서 세운 꼬리 기반 표집이 표준이다. 그리고 관측 자체의 비용 감시가 하나의 규율이다. 포괄적 관측을 배포한 뒤 관측 기반이 그것이 관측하는 체계보다 더 비싸다는 것을 발견한 팀이 많다. 처방은 관측 비용을 체계의 다른 비용과 같은 방식으로 계측하고, 관측 예산을 일급 공학 제약으로 대접하는 것이다. 추적 저장 비용, 로그 저장 비용, 관측 백엔드 비용이 모두 바탕 검색 체계와 같은 비용 대시보드에 나타나야 한다.
추적을 얼마나 오래 두느냐는 진단 필요와 준법 제약에 달렸다. 진단 창 — 추적이 디버깅에 쓸모 있을 수 있는 기간 — 은 대부분의 검색 체계에서 통상 30~90일이다. 그보다 묵은 추적이 현재의 디버깅을 밝힐 공산은 낮다. 준법 제약은 특정 데이터 범주에 대해 이를 늘릴 수도 있고(의료의 임상 추적, 규제 금융의 금융 추적) 특정 시점의 삭제를 요구할 수도 있다. 패턴은 보존 계층(최근 추적의 뜨거운 보존, 묵은 추적의 찬 보존, 알맞은 시점의 삭제)을 정의하고 관리되는 생애주기로 운영하는 것이다.
관측 데이터의 접근 통제는 바탕 체계 데이터의 접근 통제만큼은 엄격해야 한다. 추적은 내부 질의와 내부 문서와 체계 거동이라는 운영 정보를 담고 있어 널리 접근 가능해서는 안 된다. 이것 없이는 관측 스택이 응용의 보안 모형을 우회하는 또 하나의 데이터 노출면이 된다.
이 규율을 받치는 문화의 패턴은 공학 팀 안에 관측의 주인을 지명하는 것이다. 관측 스택의 신뢰성과 비용과 보안에 책임을 지는 구체적인 사람들을 두는 것이지, 관측을 모두의 책임으로 두어 결국 아무의 책임도 아니게 만들지 않는 것이다. 이름 붙은 주인이 있는 팀은 그렇지 않은 팀보다 관측을 꾸준히 더 잘 운영한다. 그 주인들이 비슷한 중요도의 프로덕션 서비스에 적용할 공학적 엄정함을 관측 스택에도 적용하기 때문이다.
가장 흔한 관측 실패는 상관 없는 로그를 가진 것이다. 서비스마다 자기 형식과 자기 타임스탬프로 자기 로그를 쓰고, 하나의 질의에 대한 레코드를 서비스를 가로질러 엮는 것이 아무것도 없다. 데이터는 있으나 그것을 손으로 이어 붙이는 진단 작업이 어떤 합리적인 당직 순번의 인내도 넘어선다.
처방 — 모든 부품에 추적 ID를 흘려보내고 모든 로그 줄에 추적 ID를 담아라. 추적 ID 상관이 없으면 로그는 발굴의 원재료이고, 있으면 로그는 질의 가능한 진단 기반이다.
많은 검색 체계가 개발 과정의 끝에 관측을 더해 지어진다. 아키텍처가 확정된 뒤, 통합이 다 쓰인 뒤, 체계가 거의 프로덕션 준비를 마친 뒤에. 사후에 끼워 넣은 관측은 처음부터 설계된 관측보다 꾸준히 못하다. 아키텍처가 옳은 신호를 드러내도록 설계되지 않았으므로 계측이 불완전하다.
처방 — 무엇을 추적에 담고 어떤 지표를 드러내고 어떤 대시보드를 둘지를 기능 아키텍처와 나란히, 후속 작업이 아니라 처음부터 설계하라.
너무 적게 담는 것의 반대편 실패다. 어떤 팀은 모든 내부 연산을 계측하고, 가능한 모든 속성을 모든 스팬에 붙이고, 모든 중간 계산을 기록한다. 그 결과의 원격 측정은 방대하고, 저장이 비싸고, 항행하기 어렵다. 당직 엔지니어는 상세를 찾을 수 없는 것이 아니라 상세에 빠져 익사한다.
처방 — 포괄적으로가 아니라 의도적으로 계측하라. 진단 작업이 실제로 의지하는 지표와 추적과 로그만을. 목적이 문서 보관의 완전함이 아니라 운영적 통찰일 때, 적은 것이 많은 것이다.
검색 관측 가능성은 일반 관측의 세 기둥 — 추적, 지표, 로그 — 위에 검색 고유의 계측을 얹어 지어진다. 앞의 사흘짜리 디버깅은 이 계측의 부재가 낳은 것이었고, 넉 달 뒤의 마흔 분짜리 해결은 그것의 존재가 가능하게 한 것이었다.
OpenTelemetry 분산 추적이 2026년의 프로덕션 표준이다. 질의마다 루트 스팬과 단계별 자식 스팬 — 임베딩, 검색, 재순위화, 성찰, 생성 — 을 낸다. 지혜로운 표집이 흥미로운 성질(오류·거부·이상)을 지닌 추적을 지키고 평범한 질의를 표집해 비용을 다스린다.
단계 수준 지표가 집계 지표가 감추는 실패를 드러낸다. 임베딩 일관성, 참조 집합 대비 검색 재현율, 리랭커 승격 패턴, 성찰 판정 분포, 생성 품질 표본이 각각 파이프라인의 다른 단계를 비춘다. 단계 경계에서 계측하는 것이 어림짐작 대신 외과적 디버깅을 가능하게 한다.
프로덕션 대시보드는 네 범주다 — 건강(한눈의 상태), 단계 분해(실패가 어디인가), 코호트 비교(누가 영향받는가), 파고들기(그 패턴을 낳은 구체적 추적). 대시보드 난립이 실패 양식이고, 명시적 소유자를 둔 정전의 작은 한 벌이 그 교정이다.
관측은 민감한 데이터를 붙잡으므로 바탕 응용과 같은 거버넌스의 규율로 운영되어야 한다. 계측 계층의 개인정보 마스킹, 비용을 위한 꼬리 기반 표집, 의도적인 보존 계층, 관측 데이터에 대한 엄격한 접근 통제는 규제 도메인의 프로덕션급 체계에서 협상의 여지가 없다.
위 문헌 목록은 원서 10장의 Further Reading을 그대로 옮긴 것이다. 서지 사항의 최종 확인은 원 출처를 통해 하는 것이 옳다.
11장은 4부를 RAG FinOps로 이어 간다. 에이전틱 검색이 프로토타입에서 프로덕션 규모로 옮겨 갈 때 결정적이 되는 비용 공학의 규율이다. 이 장에서 지은 관측 기반이 곧 비용 공학의 바탕이다. 재지 못하는 비용은 최적화할 수 없고, 외과적 디버깅을 가능하게 한 단계별 계측이 그대로 외과적 비용 귀속을 가능하게 한다. 임베딩 비용 최적화, 벡터 저장소의 비용 역학, 검색 캐스케이드의 비용 공학, 의미 캐싱, 그리고 프로덕션 에이전틱 검색을 규모가 커져도 경제적으로 지속 가능하게 지키는 운영 규율을 다룰 것이다.
돌아보면 이 장의 이야기는 보이지 않던 것을 보이게 하는 일에 관한 것이었다. 두 사고 사이에 시스템이 나아진 것은 없었다. 두 번 모두 실재하는 결함이 있었다. 달라진 것은 그 결함을 볼 수 있게 되었다는 것뿐이다. 그런데 성숙이란 대개 그런 것이다. 잘못을 없애는 데 있지 않고, 잘못을 알아볼 수 있는 자리를 마련해 두는 데 있다. 등불을 든 사람이 밤을 없애지는 못한다. 다만 발밑을 보고 걸을 수 있다. 조견(照見)이란 비추어 본다는 말이니, 비추는 일이 곧 고치는 일의 시작이다.