[목 차]
PART 01 AI 시스템에서 처음으로 착각하게 되는 것들
CHAPTER 1 모델은 똑똑한데, 시스템은 왜 바보가 될까?
_1.1 전통적인 소프트웨어와 AI 시스템의 결정적 차이
_1.2 결정론적 시스템 vs. 확률론적 시스템
_1.3 AI 엔지니어링의 본질은 통제다
_1.4 핵심 정리
CHAPTER 2 AI 시스템 장애의 대부분은 모델 밖에서 시작된다
_2.1 실제 현장에서 가장 자주 터지는 장애 유형
_2.2 왜 성능 지표는 정상인데 서비스는 망가질까?
_2.3 침묵하는 장애가 가장 위험한 이유
_2.4 '모델은 무죄다'라는 관점
_2.5 핵심 정리
PART 02 데이터 파이프라인: 망가지는 건 항상 여기서 시작된다
CHAPTER 3 데이터 파이프라인은 단순한 ETL이 아니다
_3.1 데이터 파이프라인 = 의사결정 생성기
_3.2 행동을 위한 스트리밍, 진실을 위한 배치
_3.3 파이프라인 설계가 모델의 사고 구조를 고정시키는 방식
_3.4 '나중에 고치자'가 통하지 않는 이유
_3.5 핵심 정리
CHAPTER 4 데이터는 생각보다 훨씬 쉽게 망가진다
_4.1 정형 데이터의 부패: 스키마 드리프트 vs. 시맨틱 드리프트
_4.2 비정형 데이터의 부패: 컨텍스트 포이즈닝
_4.3 데이터 관측 가능성: 코드가 아니라 데이터를 테스트하라
_4.4 핵심 정리
CHAPTER 5 잘못된 피드백 루프는 AI 시스템을 천천히 죽인다
_5.1 피드백 루프의 구조 해부
_5.2 자기 강화적 편향
_5.3 피드백 루프를 끊는 방법
_5.4 피드백은 위험이자 자산이다: 암묵적 신호와 데이터 플라이휠
_5.5 핵심 정리
PART 03 LLM의 작동 원리를 모르면, 시스템 설계도 모른다
CHAPTER 6 생성형 AI는 API가 아니라 확률 엔진이다
_6.1 토큰, 확률, 샘플링: LLM이 텍스트를 만드는 방법
_6.2 컨텍스트 윈도우: LLM의 유한한 작업 기억
_6.3 생성형 AI 기반 시스템의 고유한 위험들
_6.4 핵심 정리
CHAPTER 7 예측 불가능한 모델 위에 안정적인 시스템을 만드는 법
_7.1 레이어 1: 모델 파라미터 통제: 확률의 폭을 줄이기
_7.2 레이어 2: 구조화된 출력 강제: '형식만큼은 결정론적으로'
_7.3 레이어 3: 생성-검증-수정 루프: 자기 교정 아키텍처
_7.4 레이어 4: 결정론적 로직 분리: LLM에게 맡기지 말아야 할 것
_7.5 레이어 5: 검증 인프라: 모델의 출력을 다층적으로 검증
_7.6 안전망의 비용: 신뢰성과 지연 시간의 트레이드오프
_7.7 핵심 정리
PART 04 모델을 둘러싼 시스템을 설계하라
CHAPTER 8 모델에게 올바른 맥락을 제공하는 기술
_8.1 청킹: 가장 먼저 다듬어야 할 곳
_8.2 검색 결과는 좋은데 응답이 이상한 이유
_8.3 단일 검색으로는 답할 수 없는 질문들
_8.4 벡터 검색 너머의 맥락 설계
_8.5 텍스트를 넘어서: 멀티모달 시스템의 맥락 설계
_8.6 맥락이 시간에 따라 썩는 문제
_8.7 맥락의 품질을 측정하는 법
_8.8 핵심 정리
CHAPTER 9 모델이 외부 세계와 상호작용하는 구조
_9.1 도구 스키마가 모호하면 잘못된 행동이 실행된다
_9.2 읽기 도구와 쓰기 도구는 위험도가 완전히 다르다
_9.3 최소 권한 원칙: 도구에도 적용된다
_9.4 AI 시대에도 멱등성은 변하지 않는다
_9.5 도구 실패가 추론을 붕괴시키는 방식
_9.6 프레임워크보다 원칙이 먼저다
_9.7 핵심 정리
CHAPTER 10 자율적으로 판단하고 행동하는 시스템을 설계하는 법
_10.1 에이전트를 만들지 않는 기술: 워크플로 다섯 패턴
_10.2 계획이 잘못되면 나머지 전부가 잘못된다
_10.3 멀티스텝에서 불확실성은 곱해진다
_10.4 아무도 트윗하지 않는 이야기: 비용과 안전의 현실
_10.5 체크포인팅과 롤백: 처음부터 다시 하지 않는 설계
_10.6 싱글 에이전트와 멀티 에이전트: 언제 무엇을 선택하는가?
_10.7 자율성의 경계를 설계하라
_10.8 능력의 분리: 에이전트에게 권한을 주기 전에
_10.9 읽기 도구가 공격 통로가 될 때
_10.10 핵심 정리
PART 05 시스템을 배포하고 운영하라
CHAPTER 11 AI 시스템은 배포되는 순간부터 비용이 된다
_11.1 추론의 두 단계: 프리필과 디코드
_11.2 지연 시간, 비용, 품질: 세 가지는 동시에 만족되지 않는다
_11.3 프롬프트 캐싱: 프리필을 건너뛰는 설계
_11.4 출력을 줄이는 것이 가장 효과적인 비용 레버다
_11.5 모델 라우팅과 캐스케이딩: 요청마다 적절한 모델을 고르는 법
_11.6 배치 처리: 실시간이 아니어도 되는 작업을 분리하라
_11.7 시맨틱 캐싱: 모델 호출 자체를 건너뛰는 설계
_11.8 에이전트 비용을 구조적으로 관리하는 법
_11.9 온프레미스와 셀프 호스팅: 다른 세계의 최적화
_11.10 비용 최적화의 올바른 순서
_11.11 핵심 정리
CHAPTER 12 감이 아니라 측정으로: 평가 주도 개발
_12.1 에러 분석: 모든 평가의 출발점
_12.2 평가의 3레벨
_12.3 골든 데이터셋: 작게 시작해 살아있게 유지한다
_12.4 LLM 심판을 신뢰하게 만드는 절차
_12.5 기준은 진화한다: 기준 표류
_12.6 평가·가드레일·관측 가능성의 관계
_12.7 핵심 정리
CHAPTER 13 관측되지 않는 AI 시스템은 이미 실패했다
_13.1 AI 관측 가능성의 기본 단위: 세션, 트레이스, 스팬
_13.2 무엇을 기록하고 무엇을 측정해야 하는가?
_13.3 품질이 조용히 떨어지는 것을 잡는 법
_13.4 장애를 체계적으로 분류하는 프레임워크
_13.5 알림 설계: '모든 것에 알림'은 '어떤 것에도 알림이 없는' 것과 같다
_13.6 관측 가능성은 처음부터 설계해야 한다
_13.7 핵심 정리
CHAPTER 14 AI 엔지니어는 무엇을 다르게 판단해야 하는가?
_14.1 좋은 AI 엔지니어는 문제를 어디서부터 의심하는가?
_14.2 차이를 만드는 세 가지 렌즈
_14.3 좋은 AI 엔지니어는 해결책의 순서를 의식적으로 고른다
_14.4 자동화의 경계선은 검증 가능성이다
_14.5 도구보다 오래가는 원칙
APPENDIX A 현업 AI 엔지니어 인터뷰
_Interview 1 숫자의 이유를 찾다: AI 에이전트 기반 실험 지표 진단 팟을 리드하며
_Interview 2 AI는 완성되지 않는다, 도메인을 만나기 전까지는
_Interview 3 안 되는 이유를 끝까지 추적하는 일
_Interview 4 “나중에 만들자”가 쌓이면 시스템이 무너진다
APPENDIX B 추가 자료
_Reference 참고문헌과 더 읽을거리
주니어 AI 엔지니어에게 필요한 건 LLM 사용법이 아니라, AI 시스템 설계의 감각이다
AI 에이전트와 RAG를 붙이는 일은 이제 누구나 몇 시간이면 해낸다. 하지만 그렇게 만든 데모가 프로덕션에서도 안정적으로 동작하는지는 전혀 다른 문제다. 이 책은 'LLM API를 어떻게 잘 부를 것인가'가 아니라 '확률적으로 답하는 모델 위에서 어떻게 결정론적으로 안전한 시스템을 만들 것인가'를 묻는다.
1부와 2부에서는 AI 시스템의 장애가 왜 모델이 아니라 데이터 파이프라인, 피드백 루프처럼 모델 바깥에서 시작되는지를 파헤친다. 시맨틱 드리프트와 컨텍스트 포이즈닝처럼 겉으로는 '정상'으로 보이는 실패 유형을 짚고, 자기 강화적 편향이 시스템을 어떻게 서서히 망가뜨리는지 보여준다. 3부와 4부에서는 생성형 AI가 확률 엔진이라는 본질을 받아들인 뒤, 모델 파라미터 통제, 구조화된 출력 강제, 생성-검증-수정 루프, 결정론적 로직 분리, 검증 인프라라는 다섯 겹의 방어 아키텍처를 제시한다. RAG의 맥락 설계, 도구 호출의 스키마와 멱등성, 에이전트의 자율성 경계 설계까지 실무에서 바로 맞닥뜨리는 문제들을 순서대로 다룬다. 5부는 배포 이후의 이야기다. 지연 시간·비용·품질은 동시에 최적화되지 않는다는 트레이드오프를 인정한 뒤, 프롬프트 캐싱과 모델 라우팅으로 비용을 관리하고, 감이 아니라 측정으로 개선하는 평가 주도 개발 방법론과 세션-트레이스-스팬 기반의 관측 가능성 설계까지 이어진다. 마지막 장에서는 이 모든 원칙을 관통하는 질문 하나로 되돌아온다. '좋은 AI 엔지니어는 무엇을 다르게 판단하는가?'
그 질문에 이 책이 답하는 것은 두 가지다. 장애가 났을 때 모델·데이터·검색·도구 중 어디부터 의심할지 아는 진단 감각, 그리고 확률적인 출력 위에 결정론적인 안전장치를 쌓는 설계 감각. 이 두 감각을 실무 사례를 통해 함께 기를 수 있다. 그 차이가 데모만 잘 만드는 사람과, 무너지지 않는 시스템을 만드는 사람을 가른다.
대상 독자
●프로덕션에서 반복되는 장애 앞에서 막막한 주니어 AI 엔지니어
●데모 수준을 넘어 안정적으로 운영되는 AI 시스템을 만들고 싶은 1~3년 차 엔지니어
●RAG, 에이전트, 도구 호출을 실제 서비스에 안전하게 적용할 기준이 필요한 실무자
●현업 AI 엔지니어들이 실제로 어떻게 판단하고 일하는지 궁금한 신입·주니어 개발자