-
-
AI 시스템 설계 - 불확실한 AI를 운영 가능한 시스템으로 만드는 구조와 원칙
이한울 지음 / 한빛미디어 / 2026년 9월
평점 :
한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다.
데모는 성공했는데, 왜 서비스가 되지 못했을까요?
저는 인턴십 동안 AI 프로젝트를 기획하고 만들었습니다. 결과는 모두 PoC였고, 제 눈에는 잘 돌아가 보였습니다. 실제 서비스로 이어지지는 않았지만, 저는 만족스러웠습니다.
하지만 이 책을 읽으며 스스로에게 물었습니다. 만약 그대로 서비스가 됐다면, 제 PoC는 운영할 수 있었을까? 자신 있게 답할 수 없었습니다.
<데모를 성공시킨 건 모델이 아니었습니다>
1장의 제목인 'AI는 왜 데모에서는 성공하고 운영에서는 실패하는가'부터 와닿았습니다. 저자는 데모가 성공한 이유를 세 가지 역할로 설명합니다.
첫째, 입력 통제입니다. 시스템이 잘 답하는 질문만 데모에 넣고, 나머지는 뺐습니다.
둘째, 출력 평가입니다. 사람이 응답을 읽고 쓸 만한 것만 골랐습니다.
셋째, 실패 처리입니다. 이상한 답이 나오면 다시 돌리거나, 그 장면을 발표에서 뺐습니다.
모델이 좋아진게 아닌 사람이 모델 주변에 보이지 않는 구조를 쌓았고, 그 덕분에 데모가 돌아갔던 것입니다.
데모가 끝나면 그 구조는 사라집니다. 실제 사용자는 내가 준비하지 않은 질문을 던지고, 응답을 검토하는 사람도 없습니다. 모델과 프롬프트는 그대로인데 결과가 달라집니다.
그래서 나오는 말이 "데모 때는 됐는데"입니다.
제 PoC도 다르지 않았습니다. 데모에 쓸 질문은 제가 골랐고, 결과도 제가 먼저 확인했습니다. 그 역할을 제가 하고 있다는 걸 잊고 있었습니다.
저자는 이 구조에 이름을 붙이고 시스템으로 설계하는 것을 하네스의 출발점이라고 말합니다.
사람이 하던 판단을 반복 가능한 구조로 옮기는 것, 이것이 이 책이 말하는 하네스입니다.
<정답인가가 아니라, 충분히 좋은가>
그럼 사람이 하던 판단을 어떻게 시스템으로 옮길까요? 2장이 그 답입니다.
기존 테스트는 통과 아니면 실패입니다.
하지만 AI의 답은 매번 표현이 달라집니다. 정답 문장 하나와 비교하면, 좋은 답도 틀렸다고 나올때도 있습니다.
저자는 판결문에 빗대어 설명합니다. 같은 사건이라도 판사마다 문장은 다릅니다.
그래도 법과 증거, 논리에 맞는지는 판단할 수 있습니다.
법령 질의응답 챗봇을 만든 저에게 가장 와닿은 비유였습니다.
그래서 평가를 둘로 나눕니다.
개인정보 노출처럼 반드시 지켜야 할 것은 통과와 실패로 가립니다.
관련성이나 완결성처럼 정도가 있는 품질은 점수로 봅니다.
여기서 평가 주도 개발(EDD)이 나옵니다. 코드를 짜기 전에 "충분히 좋은 출력이 무엇인가"를 먼저 정하는 방법으로 저자는 '충분히 좋다'가 타협이 아니라고 강조합니다.
무엇을 우선할지, 어느 수준까지 요구할지 정해야 하니 오히려 더 많은 결정이 필요합니다.
저는 코드를 다 짠 뒤, 몇 개의 답을 눈으로 확인하고 넘어갔습니다. 기준은 제 머릿속에만 있었습니다.
EDD는 평가 기준, 평가자, 하네스로 이루어집니다.
1장의 하네스가 여기서 다시 등장합니다. 데모 때 한 번 하고 끝냈던 확인을, 매번 반복할 수 있는 평가로 바꾸는 장치입니다.
<모델을 세 번 바꿔도 남는 문제>
3장에는 금융 상담 보조 시스템 사례가 나옵니다.
여러 프로젝트에서 반복되는 패턴을 보여주려고 저자가 재구성한 가상 사례입니다.
데모는 순조로웠지만, 실제 상담에 연결하자 불만이 쏟아집니다. 개발팀은 모델을 바꿉니다. 조금 나아지자 또 바꿉니다. 세 번째 교체를 논의하던 날, 팀장이 묻습니다. 모델을 또 바꾸는데 왜 같은 문제가 남아 있느냐고요.
바뀐 것은 모델뿐이었습니다. 관련 없는 문서까지 그대로 넣는 검색, 답이 근거와 맞는지 확인하지 않는 출력, 잘못된 답을 모으지 않는 운영은 그대로였습니다. 문제는 사라지지 않고 모양만 바뀌었습니다.
그래서 질문을 바꿔야 합니다. "어떤 모델로 바꿀까?"가 아니라 "실패는 시스템의 어디에서 일어났나?"입니다.
저자는 1부를 이렇게 정리합니다. 하네스는 모델 주변에서 무엇을 통제할지, EDD는 품질을 어떻게 반복해서 평가할지, 시스템 관점은 그 범위를 어디까지 넓힐지를 묻습니다. 세 개념이 가리키는 결론은 하나입니다. AI 프로젝트의 실패는 모델 성능이 아니라 시스템 설계의 문제입니다.
<평가는 나중에 붙이는 것이 아닙니다>
그렇다면 어떻게 설계해야 할까요? 13장이 구체적인 답을 줍니다.
저자는 평가 가능성을 가용성이나 보안처럼 설계 단계에서 정해지는 것으로 봅니다.
평가 코드를 나중에 끼워 넣는다고 평가 가능한 시스템이 되지는 않습니다. 그리고 이를 위한 네 가지 패턴을 제시합니다. 생성과 판단 분리, 실패를 신호로 드러내기, 트레이스로 중간 과정 평가하기, 체크포인트에서 단계별로 평가하기입니다.
저자가 말하는 가장 오래 붙잡고 있던 건 '우연한 통과'라는 개념이었습니다.
사용자가 "제15조 위반 시 과태료는 얼마인가?"라고 묻습니다.
검색기는 엉뚱하게 제5조를 가져왔는데, 모델이 학습 데이터에서 기억한 숫자로 답했고 그게 우연히 맞았습니다.
최종 답만 보는 평가자는 이걸 통과시킵니다. 하지만 검색의 결함은 그대로 남아 있습니다. 다음 모델에서는 틀린 답을 할 수 있습니다.
법령 챗봇을 만들면서 저도 최종 답이 맞으면 넘어갔습니다. 그 답이 정말 검색한 조문에서 나왔는지는 확인하지 않았습니다. 이 책의 예시가 제 프로젝트 이야기처럼 읽혔습니다.
조용한 실패도 같은 이야기입니다. AI 시스템에서 가장 위험한 실패는 에러가 아니라, 정상 응답과 함께 돌아오는 그럴듯한 오답입니다. 환각, 답할 수 있는데도 거부하는 응답, 다섯 개를 물었는데 세 개만 답하는 누락. 서버 지표로는 모두 성공입니다. 그래서 실패의 종류와 근거를 시스템이 직접 신호로 내보내도록 설계해야 합니다.
에이전트라면 체크포인트가 필요합니다. 10단계 에이전트의 최종 답이 틀렸을 때, 최종 답만 보면 어느 단계에서 어긋났는지 알 수 없습니다. 그래서 도구를 고르는 지점, 인자를 만드는 지점처럼 다음 단계를 크게 오염시키는 경계에 판단 지점을 둡니다. 책에는 LangGraph 노드 사이에 평가 노드를 넣는 코드도 나옵니다. LangGraph로 멀티 에이전트를 구성해 본 저에게는 바로 적용해 볼 수 있는 부분이었습니다.
이렇게 AI 시스템 설계 책을 읽고 일부분만 소개해 봤는데요
<이 책은 이런 분들에게 추천합니다>
- RAG나 에이전트를 만들어 봤지만, 서비스로 이어지지 않았던 분
- AI 출력을 어떻게 테스트해야 할지 막막한 분
- 모델 선택을 넘어 시스템 설계 역량을 키우고 싶은 분
AI를 만드는 일은 점점 쉬워지고 있습니다. 하지만 AI를 운영하는 일은 여전히 어렵고 복잡합니다.
이 책은 그 간극을 메우는 것이 설계라고 말합니다.
데모 다음 단계가 궁금하신 분들에게, 이 책을 추천합니다