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 모델이 바뀌어도 남는 설계 원칙