[목 차]
PART 1 AI 프로젝트가 운영에서 실패하는 이유
CHAPTER 1 AI는 왜 데모에서는 성공하고 운영에서는 실패하는가
_1.1 사람의 개입이 만든 데모 성공
_1.2 PoC와 운영의 간극
_1.3 비결정성이 만드는 새로운 문제
_1.4 데모를 성공시킨 세 가지 역할
_1.5 실패 원인을 잘못 짚는 네 가지 진단
_1.6 이름 없던 구조, 하네스
CHAPTER 2 AI 시스템은 왜 기존 테스트만으로 검증하기 어려운가
_2.1 질문 목록이 테스트 코드를 대신한 이유
_2.2 TDD가 강력하게 작동하는 조건
_2.3 같은 질문에도 답이 달라지는 이유
_2.4 AI 생성 계층에서 TDD가 흔들리는 세 지점
_2.5 ‘정답인가’에서 ‘충분히 좋은가’로
_2.6 평가 주도 개발은 무엇을 먼저 설계하는가
_2.7 테스트와 평가를 함께 쓰는 개발
CHAPTER 3 문제는 모델이 아니라 시스템이다
_3.1 모델을 바꿔도 문제가 반복된다
_3.2 실패 원인을 좁혀가는 방법
_3.3 세 번 모델을 바꿔도 남아 있는 문제
_3.4 AI 시스템의 실패 지점
_3.5 우리는 왜 계속 모델을 탓하는가
_3.6 시스템 관점은 무엇을 바꾸는가
_3.7 하네스·EDD·시스템 관점은 어떻게 연결되는가
_3.8 실패 진단에서 시스템 설계로
PART 2 LLM 호출에서 RAG·에이전트까지, 운영 가능한 AI 구조
CHAPTER 4 LLM 호출을 운영 가능한 시스템으로 만들기
_4.1 한 덩어리 시스템은 실패를 진단할 수 없다
_4.2 파이프라인은 실패 지점을 드러낸다
_4.3 입력 처리기: 잘못된 입력을 먼저 막는다
_4.4 프롬프트 구성기: 지시·컨텍스트·입력의 분리
_4.5 LLM 호출기: 모델 공급자와 호출 방식 격리
_4.6 출력 처리기: 모델 응답을 시스템 데이터로 바꾸기
_4.7 상태 관리자: 대화의 연속성 만들기
_4.8 오류 처리기: 실패 다음의 행동 결정
_4.9 구성 요소 분리가 만드는 세 가지 이점
CHAPTER 5 RAG는 왜 검색 기능이 아니라 아키텍처인가
_5.1 LLM 지식 구조의 세 가지 한계
_5.2 검색 기능으로만 보면 실패 지점이 사라진다
_5.3 RAG를 정보 흐름 아키텍처로 재정의하기
_5.4 RAG 파이프라인의 다섯 단계
_5.5 RAG 실패를 단계별로 진단하기
CHAPTER 6 AI 에이전트는 왜 모델 호출이 아니라 시스템인가
_6.1 계획·기억·도구로 에이전트 구조 분해하기
_6.2 컴포넌트 계약이 실패 전파를 결정한다
_6.3 시스템 경계와 관측 가능성
_6.4 평가 하네스는 왜 에이전트 밖에 있어야 하는가
_6.5 시스템 관점이 바꾸는 교체와 확장
PART 3 신뢰할 수 있는 AI 시스템의 설계 원칙
CHAPTER 7 좋은 답변을 만드는 AI와 신뢰할 수 있는 AI 시스템의 차이
_7.1 답변이 정확해도 운영 시스템은 멈출 수 있다
_7.2 신뢰할 수 있는 AI 시스템이란 무엇인가
_7.3 신뢰성은 시스템 구조에서 만들어진다
_7.4 동작 품질과 시스템 신뢰성 진단
_7.5 실행 자유도와 통제 비용
_7.6 신뢰성을 설계 목표로 전환하기
CHAPTER 8 AI 위험을 통제 가능한 문제로 바꾸기
_8.1 사고는 시스템 경계에서 시작된다
_8.2 AI 위험은 기존 소프트웨어 위험과 무엇이 다른가
_8.3 위험을 네 축으로 나누기
_8.4 더 좋은 모델만으로 위험을 해결할 수 없는 이유
_8.5 신뢰 경계와 블래스트 라디우스
_8.6 위험을 설계로 다루는 5단계
CHAPTER 9 운영을 닮은 평가 데이터는 어떻게 만드는가
_9.1 잘 나오는 질문들의 함정
_9.2 평가 데이터는 어디에서 가져오는가
_9.3 합성 평가 데이터는 어떻게 만드는가
_9.4 합성 데이터는 어디에서 왜곡되는가
_9.5 노후화되는 데이터셋과 유지보수 가능한 파이프라인
CHAPTER 10 가드레일과 정책은 어떻게 AI의 행동을 통제하는가
_10.1 안전을 모델 밖에서 통제하기
_10.2 입력·출력·행동을 어디에서 통제하는가
_10.3 정책을 코드 밖에서 관리하기
_10.4 위반 뒤에는 어떤 대응을 선택하는가
_10.5 가드레일도 평가해야 한다
_10.6 가드레일이 막지 못하는 것
_10.7 가드레일을 평가 루프에 연결하기
PART 4 테스트를 넘어, AI 시스템을 평가하고 개선하는 방법
CHAPTER 11 AI 시스템에서 테스트와 평가의 경계는 어디인가
_11.1 assertEqual이 멈추는 순간
_11.2 더 영리한 비교도 평가를 대신하지 못한다
_11.3 RAG 파이프라인에서 검증 경계 나누기
_11.4 테스트가 여전히 필요한 영역
_11.5 테스트로 위장한 평가의 함정
_11.6 평가는 테스트와 무엇이 다른가
CHAPTER 12 AI 시스템 평가는 어떻게 설계하고 운영하는가
_12.1 평가 점수가 높아도 운영이 무너지는 이유
_12.2 평가 기준을 품질 차원으로 나누기
_12.3 평가자는 무엇을 기준으로 선택하는가
_12.4 LLM 평가자는 어떻게 검증하는가
_12.5 사람 검토는 어디에 배치할 것인가
_12.6 오프라인 평가와 온라인 평가
_12.7 운영 평가 루프는 어떻게 닫히는가
_12.8 평가 루프를 갖춘 팀의 최소 조건
PART 5 운영 가능한 AI 시스템의 설계 패턴
CHAPTER 13 평가 가능한 AI 시스템은 어떻게 설계하는가
_13.1 평가 가능성은 왜 설계 단계에서 결정되는가
_13.2 평가할 수 없는 시스템은 어떻게 생겼는가
_13.3 평가 가능성을 시스템 속성으로 정의하기
_13.4 패턴 1: 생성과 판단 분리
_13.5 패턴 2: 실패를 신호로 드러내기
_13.6 패턴 3: 트레이스로 중간 과정을 평가하기
_13.7 패턴 4: 체크포인트에서 단계별로 평가하기
_13.8 시스템 유형별 평가 지점
_13.9 평가 가능한 시스템을 어떻게 운영하는가
CHAPTER 14 AI 시스템의 동작은 어떻게 관찰하는가
_14.1 AI 시스템에서 관측 가능성이 더 중요한 이유
_14.2 로그·트레이스·메트릭을 AI 시스템에 맞게 설계하기
_14.3 다단계 실행에서 책임 지점 찾기
_14.4 운영 실패를 가시화하는 관찰 패턴
_14.5 관찰 데이터를 시스템 개선으로 연결하기
CHAPTER 15 도메인에 따라 AI 아키텍처는 어떻게 달라지는가
_15.1 도메인 제약이 시스템 설계를 바꾸는 방식
_15.2 금융 도메인은 어떤 하네스를 요구하는가
_15.3 의료와 법률은 무엇이 다른가
_15.4 도메인 제약에 맞춘 통제·평가·감사
_15.5 모델이 바뀌어도 남는 설계 원칙
AI 시스템의 완성도는 모델 밖에서 결정된다
LLM을 호출하고 RAG와 에이전트를 구현하는 일은 빠르게 쉬워지고 있습니다. 하지만 실제 운영에서는 예상하지 못한 입력, 달라지는 출력, 외부 도구의 실패처럼 데모에서는 보이지 않던 문제가 드러납니다. 이 책은 바로 데모와 운영 사이의 간극에서 출발해, 더 좋은 모델을 찾는 대신 불확실한 AI를 통제·평가·개선할 수 있는 시스템을 어떻게 설계할 것인지에 초점을 맞춥니다.
핵심은 문제를 모델 하나로 좁히지 않는 것입니다. 데모에서 사람이 대신하던 입력 통제·출력 평가·실패 처리를 하네스 구조로 옮기고, 입력부터 운영까지 다섯 개의 실패 지점으로 나눠 원인을 진단합니다. RAG는 정보 흐름을 통제하는 아키텍처로, 에이전트는 계획·기억·도구와 책임이 분리된 시스템으로 바라보며 교체하고, 추적하고, 평가할 수 있는 구조로 설계합니다.
또한 이 책에서 정의하는 평가 주도 개발(EDD)을 통해 ‘무엇이 충분히 좋은가’를 먼저 정하고, 그 기준을 반복해서 검증하는 방법을 제시합니다. 평가 데이터를 설계하고, 오프라인·온라인 평가를 연결하며, 운영에서 발견한 실패를 다시 회귀 평가셋으로 환류합니다. 여기에 가드레일과 관측 가능성, 생성과 판단의 분리·실패 신호·트레이스·체크포인트 같은 평가 가능한 시스템 패턴까지 연결해, AI 기능을 만드는 데서 그치지 않고 운영하며 지속적으로 개선할 수 있는 시스템 설계 원칙을 완성합니다.