AGENTIC RAG SYSTEMS · RAYMOND NORMAN · 제 15 장 · PART VI
行不由徑

90일 플레이북 — 틀에서 프로덕션으로틀은 목적지를 서술하고, 여정표는 길을 서술한다. 이 장은 길이다.

앞의 열넉 장이 프로덕션 에이전틱 검색이 요구하는 아키텍처와 운영의 규율을 세웠고, 5부의 사례들이 그 규율이 세 도메인에서 어떤 모습인지 보였다. 남은 것은 실무의 물음이다. 팀은 지금 있는 곳에서 그 패턴을 담은 배포까지 어떻게 옮겨 가는가. 90일 플레이북이 그 답이다. 기계적으로 따를 대본이 아니라, 첫 90일의 일을 실제로 중요한 일이 되도록 조직하는 구조다.

원서 277–292쪽 Part VI · The Roadmap 지름길로 가지 않는 일
한 분기를 들여 만든 계획
23쪽 · 11 · 6 · 12개월
아키텍처 도해 23쪽, 평가 방법론 11가지, 배포 점검표 6종, 분기 마일스톤과 위험 관리대장을 갖춘 12개월 여정표. 15년 경력에서 가장 철저한 계획이었다.
3주째에 그것을 대체한 것
30 · 30 · 30
세 개의 30일 국면. 국면마다 완료할 과업이 아니라 내야 할 결과를 두었다. 주간 점검은 미리 정한 과업이 아니라 국면의 결과에 견주어 진척을 보았다.
어느 중견 기업용 소프트웨어 회사 · 스태프 엔지니어의 한 분기
계획은 정밀했고, 그 정밀함이 오히려 오도했다

어느 중견 기업용 소프트웨어 회사의 스태프 엔지니어가 자기 팀이 지난 분기를 들여 만든 전략 문서를 펼쳤다. 문서는 꼼꼼했다. 아키텍처 도해 23쪽. 평가 방법론 열한 가지. 프로덕션 배포 점검표 여섯 종. 분기별 마일스톤과 위험 관리대장을 갖춘 상세한 12개월 여정표. 계획 분기가 끝날 무렵 그는 이것이 프로덕션 체계를 지어 온 15년 동안 자기가 만든 가장 철저한 계획이라고 결론지었다. 그리고 동시에, 다음 90일이 실제로 어떻게 펼쳐질지에 관해서는 완전히 틀렸다고 의심하기 시작했다.

의심은 실행 첫 주에 굳었다. 팀의 첫 구체적 과업 — 사내 지식 베이스를 벡터 저장소에 수집하는 일 — 이 계획 분기가 예상하지 못한 말뭉치 품질 문제를 드러냈다. 원본 문서의 약 30%가 중복이거나 근사 중복이거나, 어느 것이 현행인지 메타데이터가 분명히 알려 주지 않는 묵은 버전이었다. 계획된 2주짜리 수집 스프린트가 4주짜리 중복 제거와 정제 작업이 되었다. 하류 과업들이 밀렸다. 공들여 순서 매긴 마일스톤들이 서로를 밀치며 뭉쳤다. 3주가 끝날 무렵 그는 12개월 여정표를 더는 들여다보지 않았다. 그것이 장식적으로 틀려 있었기 때문이다 — 들여다보는 일이 오히려 팀이 어디쯤 있는지에 대해 팀을 오도하는 방식으로 틀려 있었다.

그는 12개월 여정표를 다른 산출물로 갈아 치웠다. 세 개의 30일 국면으로 조직된 90일 플레이북이다. 국면마다 완료할 과업의 집합이 아니라 내야 할 결과를 두었다. 1국면은 정제된 말뭉치 부분집합에 대해 작동하는 종단 간 검색 파이프라인과 기본 평가. 2국면은 프로덕션 품질의 관측 가능성과 비용 공학, 그리고 팀의 도메인에 알맞은 구조적 가드레일. 3국면은 12장의 운영 생애주기가 설계되어 있는 데 그치지 않고 실제로 돌아가는 통제된 프로덕션 배포. 국면 안에서 주간 점검은 미리 정한 과업이 아니라 국면의 결과에 견주어 진척을 보았다. 현실이 계획과 갈라질 때 — 그런 일은 되풀이되었다 — 팀은 국면의 결과를 지키면서 과업을 조정했다.

팀은 87일째에 통제된 프로덕션 코호트로 출시했다. 출시한 체계는 12개월 계획이 서술한 체계와 아키텍처의 여러 세부에서 달랐다. 그리고 중요한 구조적 성질에서는 같은 체계였다. 맥락에 유관한 검색, 구조적 가드레일, 포괄적 관측 가능성, 실제로 돌아가는 운영 생애주기. 90일 지점의 짧은 회고에서 그는 그 분기의 가장 중요한 결정이 3주째에 12개월 계획을 버린 일이었다고 돌아보았다.

계획은 신중한 사유의 산물이었다. 그러나 불확실한 땅에 대한 신중한 사유는 그 정밀함이 오히려 오도하는 정밀한 계획을 낳는다.

대체된 플레이북은 덜 상세했고 바로 그 때문에 더 쓸모 있었다. 팀이 짓는 행위 속에서 배우게 될 것의 자리를 남겨 두었기 때문이다.

이 장은 그 대체된 플레이북을, 어느 팀이든 적용할 수 있는 구조로 일반화한 것이다. 세 개의 30일 국면으로 짜인다. 1일에서 30일이 토대를 세운다 — 말뭉치, 수집, 기본 검색, 기본 평가. 31일에서 60일이 프로덕션 공학을 더한다 — 관측 가능성, 비용 규율, 도메인에 알맞은 구조적 가드레일. 61일에서 90일이 운영 생애주기를 세운다 — 배포 패턴, A/B 시험 기반, 이어지는 개선의 고리. 국면마다 구체적 산출물과, 나아갈 준비가 되었음을 알리는 결정 관문과, 그 국면에서 팀을 흔히 이탈시키는 실패 양식을 식별한다.

THE 90-DAY PLAYBOOK · THREE PHASES 1국면 · 토대 DAY 1–30 2국면 · 프로덕션 공학 DAY 31–60 3국면 · 운영 생애주기 DAY 61–90 관문 관문 관문 작동하고 측정되는 파이프라인 관측·비용·가드레일 돌아가는 운영 생애주기 W1W2 W3W4 W5W6 W7W8 W9W10 W11W12 90일은 끝이 아니라 운영이 시작되는 자리다 국면은 과업이 아니라 결과로 정의된다 — 현실이 어긋날 때 과업을 고치고 결과를 지킨다 advance when the gate is met · not when the calendar says so
세 국면과 세 관문 — 달력이 아니라 관문이 나아갈 때를 정한다. 지름길로 가면 뒤에서 되돌아와야 한다
PHASE 1 · DAY 1–30 — 토대
15.1 · THE FOUNDATION PHASE

1일에서 30일 — 토대의 국면

토대의 국면은 뒤따르는 모든 것의 바탕을 낸다. 30일째의 산출물은 정제된 말뭉치 부분집합에 대해 작동하는 종단 간 검색 파이프라인과 기본 평가다. 파이프라인이 프로덕션 준비를 갖춰야 하는 것은 아니다. 작동하고 측정 가능해야 한다. 이 국면의 규율은 토대가 단단해지기 전에 정교함을 더하려는 유혹을 버티는 것이고, 실패 양식은 토대에 의지하는 기능을 좇아 토대의 일을 건너뛰는 것이다.

WEEK 1

말뭉치 정제

첫 주는 말뭉치의 일이다. 초기 검색 말뭉치를 채울 문서를 식별하고, 말뭉치가 요구하는 중복 제거와 메타데이터 정제를 적용하고, 수집 파이프라인이 처리할 깨끗한 기준선을 낸다. 이 일은 화려하지 않고 꾸준히 과소평가된다. 그 스태프 엔지니어의 계획 분기는 수집에 2주를 잡았고, 실제 작업은 4주가 걸렸으며 앞선 정제가 미리 드러냈을 말뭉치 품질 문제가 그 대부분을 차지했다.

구체적 산출물은 넷이다. 문서화된 말뭉치 목록(어떤 문서가 있고 어디 살며 각각 얼마나 최신인지), 뻔한 중복을 없애는 중복 제거 통과, 도메인에 알맞은 메타데이터 스키마(하류 가드레일이 의지할 환자 맥락·관할 권위·버전 날짜 같은 구조 메타데이터를 담는), 그리고 대표 사용자가 이 말뭉치에 던질 질의 약 100개의 표본. 질의 표본이 이 국면 뒤쪽 평가 작업의 씨앗이 된다.

WEEK 2

수집 파이프라인

둘째 주는 4장에서 세운 수집 파이프라인을 구현한다. 말뭉치가 담은 형식들의 문서 파싱. 말뭉치 구조에 알맞은 전략의 청킹(산문에는 시맨틱 청킹, 구조화 문서에는 표를 아는 청킹, 규제 문면에는 13장이 서술한 인용 보존 청킹). 선택한 임베딩 모델에 대한 임베딩 생성. 벡터 저장소 채우기.

둘째 주 끝의 산출물은 채워진 벡터 저장소, 정제된 말뭉치의 임베딩된 청크, 그리고 프로덕션 데이터에 실제로 구현된 메타데이터 스키마다.

WEEK 3

기본 검색 캐스케이드

셋째 주는 기본 검색 패턴을 구현한다. 5장에서 세운 벡터 검색과 어휘 검색의 하이브리드에 1차 리랭커를 얹은 것이다. 캐스케이드가 뒤에 올 정교한 성찰이나 멀티 에이전트 오케스트레이션이나 도메인 특화 가드레일을 지녀야 하는 것은 아니다. 질의 표본에 대해 관련된 청크를 믿음직하게 돌려주어야 하고, 팀이 그것이 무엇을 돌려주는지 들여다보고 왜 그것을 돌려주었는지에 대한 판단을 세울 수 있어야 한다. 이 들여다볼 수 있음이 넷째 주의 평가 작업을 가능하게 한다.

WEEK 4

기본 평가

넷째 주는 9장의 평가 기반을 세운다. 첫 주의 질의 표본을 참조 답변을 지닌 약 300개 질의로 넓힌다. RAGAS 방식의 자동 지표 — 맥락 정밀도, 맥락 재현율, 충실도, 답변 관련성 — 를 연결한다. 보정을 위한 작은 사람 채점 부분집합을 마련한다. 평가 파이프라인을 현재 캐스케이드에 대해 종단 간으로 돌려 기준선 수치를 낸다.

이 기준선이 이후 모든 개선을 재는 바탕이다. 그것 없이는 팀이 이후의 변경이 개선인지 퇴행인지 알 수 없다.

구체적 산출물결정 관문
WEEK 1
정제된 말뭉치, 메타데이터 스키마, 질의 표본
팀이 말뭉치에 무엇이 있는지 말할 수 있는가
WEEK 2
채워진 벡터 저장소, 임베딩된 청크
청크를 ID로 회수해 들여다볼 수 있는가
WEEK 3
리랭커를 갖춘 작동하는 하이브리드 검색
특정 청크가 왜 돌아왔는지 설명할 수 있는가
WEEK 4
기준선 수치를 지닌 평가 파이프라인
그 기준선이 앞날의 결정에 쓸모 있는가
Key Definition

토대 국면의 시험

30일째에 팀은 이것을 할 수 있어야 한다. 표본 질의 하나를 체계에 돌리고, 어느 청크가 회수되었으며 왜 그랬는지 정확히 보고, 그 질의의 평가 지표를 보고, 그 평가에 근거해 다음에 할 개선을 식별하는 것. 이 능력 가운데 하나라도 없다면 토대는 뒤따르는 국면의 일을 받칠 만큼 단단하지 않다.

약한 토대로 2국면에 나아간 팀은 2국면 몇 주 뒤에 미뤄 둔 1국면의 일로 되돌아가야 함을 어김없이 발견한다. 나아가기 전에 토대를 제대로 마치는 값은 성급히 나아간 뒤 되돌아오는 값보다 언제나 작다.

PHASE 2 · DAY 31–60 — 프로덕션 공학
15.2 · THE PRODUCTION ENGINEERING PHASE

31일에서 60일 — 프로덕션 공학의 국면

둘째 국면은 체계를 작동하되 부서지기 쉬운 것에서 프로덕션 공학이 된 것으로 끌어올린다. 60일째의 산출물은 제대로 된 관측 가능성과 비용 규율, 그리고 팀의 도메인에 알맞은 구조적 가드레일을 지닌 체계다. 1국면의 파이프라인은 바탕으로 남고, 2국면이 그것을 프로덕션에서 지속 가능하게 만드는 공학의 규율로 감싼다.

WEEK 5

관측 기반

10장의 관측 패턴을 구현한다. 검색 캐스케이드의 모든 단계에 OpenTelemetry 계측을 더한다. 분산 추적이 임베딩·검색·재순위화·생성을 지나는 질의별 여정을 담는다. 구조화 로그가 추적 ID로 추적에 상관된다. 첫 대시보드가 지어진다 — 건강 대시보드, 단계 분해 대시보드. 흥미로운 성질의 추적을 지키면서 비용을 다스리도록 표집이 설정된다. 산출물은 이 주 뒤로 어떤 프로덕션 질의든 추적 저장소를 통해 종단 간으로 들여다볼 수 있게 된다는 것이다.

WEEK 6

비용 공학의 규율

11장의 FinOps 패턴을 구현한다. 관측 스택에 비용 귀속을 더해 질의당 비용을 재고 단계별로 분해할 수 있게 한다. 현재 체계의 비용 구성을 확립한다 — 지출의 몇 할이 임베딩이고 몇 할이 벡터 저장소이며 몇 할이 검색 캐스케이드인지. 질의 분포가 받쳐 준다면 의미 캐싱을 구현한다. 모델 계층화를 검토해 현재 사용이 과잉인 곳에 적용한다. 산출물은 돈이 어디로 가는지 보여 주는 비용 대시보드와, 첫 비용 최적화 통과다.

WEEK 7

도메인 특화 구조적 가드레일

팀의 도메인에 알맞은 구조적 가드레일을 짓는다. 규제 금융이면 13장의 인용 검증 패턴. 의료면 14장의 용량 경계 검사와 금기 검증. 법률이면 14장의 인용 그래프와 유효 법리 검증.

5부가 직접 다루지 않은 도메인이라면 팀은 14.5절의 통합 원칙을 적용해 자기 도메인의 등가 구조 요건을 식별한다. 어떤 맥락 차원이 중요한가, 어떤 도메인 구조화 데이터가 필요한가, 어떤 구체적 안전 성질이 어림이 아니라 구조로 강제되어야 하는가.

WEEK 8

도메인 평가와 경화

평가 모음을 도메인 특화 사례로 넓힌다. 1국면의 300개 질의 표본에 팀의 도메인에 고유한 실패 양식을 담은 질의를 더한다 — 구조적 가드레일을 작동시키는 질의, 맥락적 판별을 요구하는 정답 알려진 질의, 가장 고위험 사용 사례를 표상하는 질의. 평가를 현재의 프로덕션 공학된 체계에 대해 돌린다. 드러난 가드레일 실패나 관측 빈틈이나 비용 퇴행은 2국면이 닫히기 전에 수습한다.

Production Insight

프로덕션 공학은 복리로 붇는다

2국면의 관측 가능성과 비용 규율과 구조적 가드레일은 1국면 파이프라인에 더해지는 개선이 아니다. 곱해지는 개선이다. 관측 가능성은 이후 모든 조사를 빠르게 만든다. 비용 규율은 이후 모든 기능을 경제적으로 지속 가능하게 만든다. 구조적 가드레일은 이후 모든 배포를 안전하게 만든다. 그 복리 효과가 둘째 국면의 투자를 정당화한다. 2국면을 제대로 마친 팀은 이후의 모든 것을 가속하는 바탕을 지은 것이다.

프로덕션 배포로 서둘러 가려고 2국면을 아낀 팀은 그 프로덕션 공학의 일이 사고 대응과 비용 위기와 안전 수습으로 뒤늦게 돌아옴을 꾸준히 발견한다. 31일에서 60일 사이에 의도적으로 하는 2국면은, 6개월에서 12개월 사이에 반응적으로 하는 2국면보다 극적으로 싸다.

PHASE 3 · DAY 61–90 — 운영 생애주기
15.3 · THE OPERATIONAL LIFECYCLE PHASE

61일에서 90일 — 운영 생애주기의 국면

셋째 국면은 체계를 출시되는 산출물에서 운영되는 것으로 바꾸는 운영 생애주기를 세운다. 90일째의 산출물은 12장의 운영 생애주기가 실제로 돌아가는 통제된 프로덕션 배포다. 버전 관리, 배포 패턴, A/B 시험 기반, 이어지는 개선의 고리. 3국면이 출시되는 체계와 시간에 걸쳐 운영되는 체계를 가르는 국면이다.

WEEK 9

버전 관리와 배포 기반

12장의 버전 관리 규율을 구현한다. 모든 부품이 자기 버전을 메타데이터 스키마에 지닌다. 추적 데이터가 그것을 나른다. 배포 파이프라인이 그림자 배포와 카나리 전개와 기능 플래그를 서로 다른 패턴으로 받친다. 팀은 최근 변경 하나를 통제된 조건에서 되돌려 보고 체계가 예측 가능하게 이전 상태로 돌아오는지 확인함으로써 되돌림을 검증한다. 산출물은 팀이 압박 아래에서 신뢰하는 배포 기반이다.

WEEK 10

A/B 시험 기반

12장에서 세운 A/B 시험을 구현한다. 트래픽 분할 기반이 통제된 몫의 질의를 실험 버전으로 보내고 나머지는 기준선으로 섬긴다. 통계 분석 파이프라인이 변형마다 지표를 계산한다. 사전 등록의 규율이 팀의 실험 표준으로 확립된다. 산출물은 기반과, 그 기반을 통해 도는 첫 실험이다. 통상 리랭커의 작은 조율이나 프롬프트 변형으로, 상당한 개선을 내려는 것이 아니라 기반을 작동시켜 보려는 것이다.

WEEK 11

통제된 프로덕션 배포

체계를 통제된 프로덕션 코호트에 배포한다. 코호트는 작다 — 사내 사용자, 베타 고객 세그먼트, 관여도 높은 이해관계자가 있는 특정 사용 사례 — 그리고 배포는 낮은 초기 비율의 카나리 패턴을 쓴다. 팀은 프로덕션 트래픽을 가까이 감시하고, 코호트가 주는 피드백을 붙잡고, 전개를 넓히기 전에 드러난 문제를 다룬다.

배포는 일의 끝이 아니다. 남은 기반이 받치는 운영 생애주기의 시작이다.

WEEK 12

이어지는 개선의 고리

마지막 주는 12장의 이어지는 개선의 고리를 세운다. 첫 공식 주간 검토를 수행한다. 평가 데이터와 관측 신호와 비용 지표를 살피고, 관찰을 우선순위 매겨진 목록으로 옮기고, 첫 개선을 일정에 넣는다. 주기가 한 번의 활동이 아니라 이어지는 것으로 확립된다.

90일째의 산출물은 배포된 체계만이 아니다. 뒤따르는 달과 해에 걸쳐 그 체계를 끊임없이 개선할 고리를 돌리고 있는 팀이다.

# 90일째 준비 점검표 — 운영 생애주기가 실재하는가
 모든 부품의 버전이 모든 질의 추적에 기록되고 있다
 통제된 조건에서 되돌림을 성공적으로 수행해 보았다
 적어도 하나의 A/B 시험이 통계 분석까지 종단 간으로 돌았다
 카나리 전개가 지표 기반 승격 관문과 함께 돌고 있다
 이어지는 평가가 선별된 질의 집합에 대해 매일 돈다
 비용 대시보드가 주간 공학 검토에서 실제로 검토된다
 구조적 가드레일이 프로덕션에서 아슬아슬한 사건을 적어도 한 번 잡았다
 관측 가능성이 프로덕션 디버깅 한 번을 실제로 받쳤다
 이어지는 개선의 고리가 우선순위 매겨진 목록을 내놓았다
 팀이 답할 수 있다 — "다음 개선은 무엇이고 왜인가?"

# 90일째에 채워지지 않은 항목이 있다면, 그 항목이 다음 우선순위다.
# 초기 통제 코호트를 넘어 프로덕션 전개를 넓히기 전에.
원서 15.3절 — 설계된 것과 돌아가는 것을 가르는 열 줄
15.4 · GATES AND DERAILMENTS

결정 관문과 흔한 이탈

플레이북의 규율은 그 관문에 있다. 국면마다 팀이 나아가기 전에 실질적으로 이루어야 할 구체적 결과가 있다. 성급히 나아가려는 유혹 — 1국면이 미완인 채 2국면을 시작하고, 2국면이 약한 채 3국면을 시작하는 것 — 이 팀을 가장 꾸준히 이탈시키는 실패 양식이다.

1국면에서 2국면으로foundation → production engineering

이 관문은 팀이 체계의 현재 거동에 관한 구체적 진단 물음에 답할 수 있는지다. 특정 질의가 왜 그 특정 청크를 돌려주었는지 설명할 수 있는가. 우선순위 정하기에 쓸모 있는 기준선 평가 지표를 낼 수 있는가. 말뭉치의 약한 자리 — 대표성이 모자란 주제, 품질이 의심스러운 문서, 일관되게 채워지지 않은 메타데이터 필드 — 를 식별할 수 있는가. 어느 하나라도 아니라면 토대는 단단하지 않고 2국면은 모래 위에 지어진다.

말뭉치와 평가의 토대가 약한 채로 더 흥미로운 2국면의 일 — 관측 가능성, 가드레일, 눈에 보이는 공학 — 로 나아가는 것이다. 공학이 눈에 보이고 지표가 나아지므로 일이 생산적으로 느껴진다. 바탕의 문제는 보이지 않게 겹쳐 붇는다. 이후의 모든 개선이 스스로 믿음직하지 않은 기준선에 견주어 측정되고, 이후의 모든 결정이 프로덕션 현실을 반영할지 알 수 없는 신호에 인도된다.

2국면에서 3국면으로production engineering → operational lifecycle

이 관문은 배포된 뒤 체계가 운영 가능할 것이라는 팀의 확신이다. 관측 가능성이 실패를 며칠이 아니라 몇 분 안에 실제로 드러내는가. 비용 규율이 11장 SaaS 회사가 겪은 종류의 청구서 배증을 실제로 막는가. 구조적 가드레일이 팀의 도메인에 고유한 실패 양식을 실제로 잡는가. 어느 하나라도 불확실하다면 체계는 배포될 준비가 되지 않았다. 배포가 수습이 더 비싼 조건에서 그 빈틈을 드러낼 것이기 때문이다.

일정의 압박이다. 원래 계획은 60일째 프로덕션 배포를 말했고, 실제 준비는 60일째에 불확실하고, 팀은 일정이 그렇게 말하므로 그대로 배포한다. 그 배포는 그다음 3국면의 일에 쓰려던 공학 노력을 몇 주의 사고 대응으로 삼킨다. 규율은 60일이라는 표지를 계획의 산출물로, 준비 관문을 실제 기준으로 대접하는 것이다. 일정이 되었을 때가 아니라 준비되었을 때 배포한다.

90일째에서 이어지는 운영으로day 90 → continuing operations

이 관문은 이어지는 개선의 고리가 문서화된 의도가 아니라 실제로 돌아가는 실천으로 존재하는지다. 주간 검토가 실제로 열리는가. 그것이 실제로 우선순위 매겨진 목록을 내놓는가. 그 목록이 실제로 다음 주의 일을 이끄는가. 고리가 절차 도해로만 존재한다면 체계는 규율 없는 모든 체계가 표류하는 방식으로 표류한다. 고리가 돌고 있다면 체계는 달과 해에 걸쳐 복리로 붇는 이어지는 개선의 상태로 들어간다.

15.5 · THE FORWARD DIRECTION

90일 이후의 방향

90일 플레이북은 운영 생애주기를 갖춘 통제된 프로덕션 배포를 낸다. 그것은 체계의 운영하는 삶의 시작이지 팀의 일의 끝이 아니다. 90일 너머의 방향은 다른 리듬을 따른다. 이산적 국면이 아니라 이어지는 개선의 주기이며, 팀을 12장의 RAGOps 성숙도 모형에서 초기 프로덕션 배포로부터 이어지는 개선과 끝내 자기 최적화의 운영으로 나아가게 한다.

BEYOND DAY 90 DAY 90 Level 2 다음 90일 · 안정화 코호트 피드백 · 가드레일 조율 Q1Q2 Q3Q4 분기 개선 주기 — 겹쳐 쌓이도록 설계된다 Level 3 — 한 해 안에 Level 4 — 점진적으로 진행은 고르지 않다 — 한 체계의 부분마다 성숙이 다르다 팀의 일은 가장 낮은 자리를 가장 높은 자리에 맞춰 끌어올리는 것이다
90일 이후 — 안정화의 한 분기, 겹쳐 쌓이는 분기 주기, 그리고 고르지 않게 오르는 성숙

프로덕션 이후의 첫 90일

초기 프로덕션 배포에 뒤따르는 90일은 통상 안정화와 확장의 일이 지배한다. 통제 코호트의 피드백이 팀이 예상하지 못한 실패 양식을 드러낸다. 구조적 가드레일이 프로덕션 데이터에 근거해 조율된다. 실제 질의 패턴이 떠오르며 비용 구성이 옮겨 간다. 프로덕션 트래픽이 드러낸 패턴을 담도록 평가 모음이 넓어진다. 이 일은 화려하지 않고 아키텍처적 새로움을 좀처럼 내지 않는다. 배포를 믿음직한 프로덕션 체계로 바꾸는 일이다. 이 기간을 존중하고 기초가 단단해지기 전에 아키텍처적 정교함을 더하려는 유혹을 버틴 팀이, 여섯 달 뒤에 꾸준히 더 믿음직한 체계를 낸다.

분기 개선 주기

초기 안정화 뒤 자연스러운 리듬은 분기 개선 주기가 된다. 분기마다 소수의 실질적 개선 — 새 검색 패턴, 넓힌 구조적 가드레일, 정련된 평가 방법론, 비용 최적화 과제 — 을 이어지는 개선의 고리가 프로덕션 데이터에 근거해 고른다. 주기는 겹쳐 쌓이도록 설계된다. 분기의 개선이 앞 분기 위에 서고, 네 분기에서 여덟 분기에 걸친 누적 효과는 상당한 체계의 진화가 된다.

성숙의 진행

규율 있는 운영 열두 달에서 열여덟 달에 걸쳐 팀은 RAGOps 성숙도 모형을 나아간다. 90일째의 초기 프로덕션 배포는 팀을 네 수준 모형의 2수준(계측)에 놓는다. 이어지는 개선의 고리를 돌린 첫 해가 팀이 적극적으로 다룬 부분에 대해 통상 3수준(이어지는 개선)으로 끌어올린다. 4수준(자기 최적화)은 실천의 최전선이며, 팀이 개선의 고리 자체의 일부를 자동화하는 대로 점진적으로 떠오른다. 진행은 고르지 않다 — 같은 체계의 다른 면이 다른 성숙 수준에서 돌 수 있고, 팀의 일은 고른 전진을 좇는 것이 아니라 가장 낮은 성숙의 면을 가장 높은 면에 맞춰 끌어올리는 것이다.

COMMON PITFALLS

플레이북 실행의 실수 — 세 가지

국면을 선택 사항으로 다루기Treating Phases as Optional

어떤 팀은 플레이북의 국면을 순서가 아니라 메뉴로 본다. 1국면의 평가 작업을 "나중에 평가를 더하겠다"며 건너뛴다. 2국면의 구조적 가드레일을 "프로덕션 검증 뒤에 경화하겠다"며 건너뛴다. 3국면의 운영 생애주기를 "안정화 뒤에 운영화하겠다"며 건너뛴다. 이 패턴은 믿음직하게 운영할 토대 없이 출시되는 배포를 낳고, 미뤄 둔 일은 원래 값의 몇 배로 뒤늦게 돌아온다.

처방 — 국면은 서로를 딛고 선다. 그것을 선택 사항으로 다루면 4부와 5부의 사례들이 기록한 그 실패 양식이 나온다.

토대 국면을 과잉 공학하기Over-Engineering the Foundation Phase

반대편 실패는 90일 전부를 1국면의 토대 작업에 쓰는 팀이다. 말뭉치를 정련하고, 청킹 전략을 완성하고, 임베딩을 최적화하고, 평가 모음을 다듬는다. 토대의 국면은 언제나 미완으로 느껴진다. 토대는 늘 더 정련될 수 있기 때문이다.

처방 — 일이 완성된 느낌이 들 때가 아니라 관문이 충족되었을 때 나아가라. 2국면이 수습이 필요한 토대의 빈틈을 드러낼 것이며, 그 수습은 정상적 실행의 일부이지 1국면이 성급했다는 증거가 아니다.

플레이북을 대본으로 다루기Treating the Playbook as a Script

플레이북은 구조이지 대본이 아니다. 기계적으로 따르는 팀 — 2주가 무엇을 냈든 3주가 되었으므로 3주의 과업을 실행하는 팀 — 은 플레이북이 담으려는 규율을 놓친다.

처방 — 관문이 충족됨에 근거해 나아가고, 현실이 드러내는 것에 근거해 과업을 조정하고, 그것을 내는 구체적 일에는 유연하되 국면의 결과는 지켜라. 그 스태프 엔지니어의 12개월 계획은 과업을 명시했기에 실패했고, 그를 대체한 플레이북은 결과를 명시했기에 성공했다. 같은 원리가 여기에도 적용된다.

Common Pitfall

'91일째'라는 안티패턴

많은 팀이 90일이라는 표지를 운영의 시작이 아니라 프로젝트의 끝으로 대접한다. 이어지는 개선의 고리는 지어졌으나 돌려지지 않는다. 관측 기반은 갖춰졌으나 들여다보이지 않는다. 구조적 가드레일은 있으나 프로덕션 데이터가 쌓이는 대로 정련되지 않는다. 체계는 느리고 조용히 1수준의 불 끄기 성숙으로 표류한다.

규율은 90일을 끝이 아니라 시작으로 대접하는 것이다. 체계의 장기적 신뢰성에 가장 중대한 몇 주는 초기 프로덕션 배포 직후의 몇 주다. 그 몇 주에 운영의 실천이 이어지는 습관으로 확립되거나 조용히 버려지기 때문이다. 프로덕션 이후 첫 분기 동안 고리를 지킨 팀은 꾸준히 그것을 무한히 지속하고, 그 분기에 그것을 놓친 팀은 좀처럼 그 규율을 되찾지 못한다.

CHAPTER SUMMARY

이 장에서 남는 다섯

90일 플레이북은 구체적 결과를 지닌 세 개의 30일 국면으로 짜인다. 1~30일이 말뭉치와 수집과 기본 검색과 기본 평가를 세우고, 31~60일이 관측 가능성과 비용 공학과 도메인 특화 구조적 가드레일을 더하고, 61~90일이 버전 관리와 배포 패턴과 A/B 기반과 이어지는 개선의 고리를 세운다. 국면은 서로를 딛고 서니, 성급히 나아가면 앞 국면을 제대로 마치는 값을 언제나 넘는 하류 수습이 따른다.

국면마다의 결정 관문은 국면이 시작된 뒤 흐른 시간이 아니라, 현재 체계에 관한 구체적 진단 물음에 실질적으로 답할 수 있는 능력이다. 1국면의 관문은 토대의 단단함, 2국면의 관문은 프로덕션 공학의 완결성, 90일째의 관문은 문서화된 고리가 아니라 돌아가는 고리의 존재다.

가장 흔한 이탈은 플레이북을 구조가 아니라 대본으로 다루는 것, 일정의 압박 아래 국면 사이를 성급히 나아가는 것, 그리고 90일을 일의 끝으로 대접하는 것이다. 국면의 결과를 지키면서 구체적 과업을 현실에 맞춰 조정한 팀이, 상세한 12개월 계획이든 플레이북 자체든 기계적으로 지킨 팀보다 꾸준히 더 오래 견디는 체계를 낸다.

90일 너머의 방향은 열두 달에서 열여덟 달에 걸쳐 겹쳐 쌓이며 팀을 성숙도 모형으로 끌어올리는 분기 개선 주기다. 90일째의 초기 배포는 2수준(계측)이고, 규율 있는 운영이 한 해 안에 통상 3수준(이어지는 개선)에 이르며, 4수준(자기 최적화)은 고리의 일부가 자동화되는 대로 점진적으로 떠오른다.

플레이북은 팀이 현재 상태에서 이 책이 세운 규율을 담은 배포로 어떻게 옮겨 가는가라는 물음의 실무적 답이다. 대본이 아니다. 첫 90일의 실행을 조직해, 만들어지는 일이 실제로 중요한 일이 되게 하고, 확립된 규율이 뒤따르는 해들에 체계를 지탱할 운영의 습관이 되게 하는 구조다.

A CLOSING NOTE FROM THE AUTHOR

저자의 맺음말

이 책은 특정한 독자를 염두에 두고 쓰였다. 프로덕션 에이전틱 검색을 지으라는 요청을 받았고, 그 일을 마땅한 진지함으로 다루는 참조를 필요로 하는 엔지니어와 설계자다. 논문의 개관이 아니다. 프레임워크의 목록이 아니다. 역량을 과장하며 둘러보는 여행이 아니다. 프로덕션급 배포를 프로토타입과 실제로 가르는 패턴에 관한, 일하는 엔지니어의 안내다.

모든 장이 실제 프로덕션 실패로 열리는 까닭은, 실패가 이 규율이 실제로 자라나는 방식이기 때문이다. 아세트아미노펜의 아슬아슬한 사건, 지어낸 인용, 갑절이 된 청구서, 사흘의 디버깅 — 이 실패들과 뒤따른 수습이 각각, 어떤 아키텍처 도해도 가르칠 수 없는 것을 가르쳤다. 이 책의 패턴들은 누군가 그것을 어렵게 배웠기에 존재한다. 그것을 적어 두는 규율은 다음 팀이 같은 값으로 같은 교훈을 치르지 않게 하려는 것이다.

이 책에서 하나만 가져간다면 이것을 가져가기 바란다. 에이전틱 검색 체계의 아키텍처적 정교함은 그것을 운영하는 규율보다 덜 중요하다. 가장 우아한 아키텍처도 관측 가능성과 평가와 비용 공학과 운영 생애주기 없이 배포되면, 더 평범한 아키텍처가 더 나은 운영 규율과 함께라면 겪지 않을 방식으로 실패한다. 5부의 사례들이 인상적인 까닭은 아키텍처가 새롭기 때문이 아니다 — 대개 그렇지 않다 — 운영의 규율이 엄정하기 때문이다. 2026년 프로덕션 에이전틱 검색의 최전선은 아키텍처가 아니다. 운영이다. 그에 맞게 지으라.

잘 지으라. 조심스럽게 운영하라.
이 분야가 이미 값을 치른 실패에서 배우라.
그리하여 당신 팀의 실패가 이 규율을 한 걸음 더 밀고 갈 새로운 실패가 되게 하라. — 저자의 맺음말에서
FURTHER READING AND FORWARD DIRECTION

더 읽을 것, 그리고 앞으로

Multi-Agent AI Systems Handbook (Norman, 2026) — 프로덕션 검색이 그 안에서 작동하는 더 넓은 에이전틱 패턴을 다루는 자매편. 두 책은 함께 읽도록 설계되었다. 자매편의 에이전트 오케스트레이션과 LLMOps와 AgentOps 취급이 이 책의 검색 고유 패턴을 더 넓은 에이전틱 맥락으로 일반화한다.
Kleppmann, M., Designing Data-Intensive Applications (O'Reilly, 2017) — 프로덕션 신뢰성을 위한 데이터 체계 공학의 기초 텍스트. 패턴은 에이전틱 검색 시대보다 앞서지만 원칙은 그대로 적용된다 — 진화를 위해 설계하고, 관측을 위해 계측하고, 일관성 선택을 명시하고, 실패를 예상하며 우아하게 회복하라.
Beyer, Jones, Petoff & Murphy, Site Reliability Engineering (O'Reilly, 2016) — 규모 있게 프로덕션 체계를 믿음직하게 운영하는 정전. 이 책이 에이전틱 검색에 적용한 규율은 SRE가 일반 프로덕션 체계를 위해 길러 온 그 규율이다.
Anthropic · OpenAI · Cohere 기술 문서 (상시 갱신) — 프로덕션 에이전틱 검색 대부분이 의지하는 언어 모델과 임베딩 서비스의 준거 문서. 끊임없이 진화하므로, 아키텍처 결정에 영향을 줄 역량 변화를 식별하려면 프로덕션 배포를 적어도 분기마다 현행 문서에 견주어 검토해야 한다.
The Production AI Systems series, 이어질 권들 (Norman, 2026 이후) — 이 책은 이 시리즈의 두 번째 권이다. 이어질 권들은 AgentOps를 독립된 규율로, 에이전트 간 통신을 다스리는 MCP와 A2A 프로토콜을, 그리고 에이전틱 체계가 실무를 다시 짜고 있는 도메인별 패턴을 다룰 것이다.

위 문헌 목록은 원서 15장의 Further Reading을 그대로 옮긴 것이다. 서지 사항의 최종 확인은 원 출처를 통해 하는 것이 옳다.

원서에는 이 장 뒤로 부록 A(프레임워크 참조), 부록 B, 부록 C(프로덕션 준비 점검표), 용어집이 이어진다. 이 페이지는 15장 본문만을 다룬다.