데모를 넘어, 실제로 운영할 수 있는 AI 시스템을 설계하라

LLM을 호출하고 RAG와 에이전트를 구현하는 것만으로 AI 시스템이 완성되지는 않습니다.

실제 운영에서는 예측하기 어려운 입력과 출력, 반복되는 실패, 평가와 통제처럼 모델 밖의 문제까지 함께 설계해야 합니다.

 

이 책을 통해 데모와 운영 사이의 간극이 왜 발생하는지 이해하고, 사람이 대신하던 통제와 판단을 하네스라는 반복 가능한 시스템 구조로 옮기는 방법을 익힐 수 있습니다. 입력부터 운영까지 실패 지점을 나눠 진단하고, RAG와 에이전트를 기능이 아닌 아키텍처로 바라보며, 평가 데이터·가드레일·관측 가능성을 연결해 AI를 평가하고 개선할 수 있는 구조를 설계합니다. 좋은 모델을 선택하는 데서 한 걸음 더 나아가, 모델과 환경이 바뀌어도 다시 검증하고 개선할 수 있는 AI 시스템 설계 역량을 갖추게 됩니다.

[목 차]

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 전쟁 2.0』『AGI의 시대』 저자)

요즘 기업 현장에서 자주 듣는 고민은 ‘데모 버전은 훌륭했지만, 전체 시스템에 연결하자 제대로 동작하지 않거나 성능이 나오지 않는다’는 고백이다. 이 책은 이러한 문제가 왜 발생하는지, AI 프로젝트를 단순한 모델 적용이나 RAG 도입 정도로 가볍게 여겼던 기업들이 놓친 것이 무엇인지 명확하고 실용적인 방향성을 제시한다. 왜 단순 모델 적용을 넘어 시스템적 접근이 필요한지, 운영과 평가 문제를 어떻게 다뤄야 하는지, 가드레일과 정책이 AI 시스템 개발과 신뢰성 확보에 왜 핵심 역할을 하는지를 실제 사례와 함께 알기 쉽게 설명한다.

 

노현빈 (신한투자증권 AI 에이전트부 부서장 & 전 뤼이드 수석 연구원)

진짜로 기업 규격의 제품을 만드는 프로들은 기능 개발이 전체 공수의 일부에 불과하다는 사실을 안다. 나머지는 LLM 오케스트레이터의 유연성을 통제하고, 데이터 참조에서의 환각을 제거하며, 내부의 오작동과 외부의 악의적인 공격에 대응할 준비를 하는 데 들어간다. 이 책에는 이론을 넘어 AI 시스템을 실제로 개발하고 운영하며, 다양한 AI 시스템의 취약점을 개선해 온 실전 경험이 녹아 있다. 기업 규격의 AI 시스템을 만들기 위한 가이드이자, 이미 만들어진 제품의 취약점을 발견하고 개선할 수 있는 체크리스트로 활용할 수 있을 것이다.

 

신종호 (AIM Intelligence 부문장 & Head of Offensive Security)

이 책은 AI를 하나의 모델이 아닌 운영 시스템으로 바라보고, 왜 PoC에서는 성공했던 프로젝트가 실제 운영 환경에서는 실패하는지, 그리고 그 간극을 어떻게 메울 수 있는지를 소프트웨어 엔지니어링의 관점에서 차근차근 설명한다. 추상적인 원칙만 나열하는 것이 아니라 실제 운영에서 마주치는 문제를 바탕으로 하네스, 평가, 실패 처리와 같은 핵심 개념을 구체적인 사례와 함께 설명한다. AI의 비결정성과 복잡성이 커질수록 견고한 시스템 설계는 더욱 중요해진다. 이 책은 AI 시대에 좋은 시스템을 만든다는 것이 무엇인지 다시 생각하게 한다.