-
-
[전자책] AI 시스템 설계 - 불확실한 AI를 운영 가능한 시스템으로 만드는 구조와 원칙
이한울 지음 / 한빛미디어 / 2026년 9월
평점 :
한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다.
요즘 AI 기능을 붙이는 일은 예전보다 훨씬 쉬워졌습니다. API를 연결하고 문서를 검색해 답변에 넣으면 데모 화면은 금방 나옵니다. 몇 가지 질문을 던져 보고 그럴듯한 답이 돌아오면 일단 안심하게 됩니다. 그런데 운영에 들어가는 순간 질문이 달라집니다. 답변이 틀렸을 때 검색 결과가 문제인지, 프롬프트가 문제인지, 모델이 맥락을 놓친 건지 어디서부터 봐야 할까요?
백엔드 개발에서는 장애가 나면 로그와 지표를 따라 원인을 좁혀 갑니다. AI 기능 앞에서는 그 익숙한 감각이 자주 막힙니다. 요청은 성공했고 응답도 왔는데 내용만 틀릴 수 있기 때문입니다. 게다가 에이전트가 외부 도구까지 사용한다면 잘못된 답변이 실제 행동으로 이어질 수도 있습니다.
<AI 시스템 설계>는 바로 이 지점을 다룹니다. 432쪽, 5개 부, 15개 장에 걸쳐 데모와 운영의 간극부터 LLM 파이프라인, RAG와 에이전트, 평가 데이터, 가드레일과 관측 가능성까지 이어집니다. 기능을 하나 더 붙이는 방법보다 만든 기능의 동작을 어떻게 확인하고 고칠 것인가에 무게를 둔 구성입니다.
데모의 뒤에서 사람이 하던 일
1부에서 눈에 들어온 절 제목은 '사람의 개입이 만든 데모 성공'입니다. 데모에서는 개발자가 질문을 고르고, 어색한 답이 나오면 입력을 바꾸고, 결과를 보여주기 전에 한 번 더 확인합니다. 화면에는 AI가 혼자 잘한 것처럼 보이지만 실제로는 사람이 뒤에서 품질을 관리한 셈입니다.
운영에서는 모든 요청 옆에 개발자가 서 있을 수 없습니다. 책이 말하는 하네스(Harness)는 그때 사람이 하던 통제와 판단을 반복 가능한 시스템 구조로 옮기는 방법입니다. 잘못된 입력을 다루고, 출력 형태를 확인하고, 실패했을 때 다음 행동을 정하는 일까지 모델 바깥에 설계합니다. 모델을 더 좋게 만드는 것만큼, 모델 주변에 어떤 경계를 둘지 생각하게 하는 대목입니다.
파이프라인을 나눠야 실패도 보인다
4장은 LLM 호출을 한 덩어리로 두지 않습니다. 입력 처리기, 프롬프트 구성기, LLM 호출기, 출력 처리기로 흐름을 나누고 상태 관리자와 오류 처리기를 곁에 둡니다. 93~94쪽의 그림에는 이 구성 요소들이 하나의 파이프라인으로 그려져 있습니다. 바로 아래 절 제목이 '교체·테스트·진단을 가능하게 하는 경계'인 것도 좋았습니다.
구성 요소를 나누는 이유가 코드 정리만은 아닙니다. 답변이 틀렸을 때 입력이 잘못됐는지, 프롬프트에 들어간 문맥이 부족했는지, 모델 호출 뒤 출력 처리에서 문제가 생겼는지 확인할 수 있어야 합니다. 백엔드에서 계층별 로그를 남기는 이유와 닮았습니다. 실패가 어디서 시작됐는지 보이지 않으면 개선도 추측에 머무릅니다.
RAG와 에이전트를 기능보다 구조로 보다
RAG를 붙이고도 부정확한 답을 받으면 검색 모델이나 벡터 DB부터 바꾸고 싶어집니다. 하지만 필요한 문서를 아예 찾지 못한 것과, 올바른 문서를 찾아 놓고도 답변에 반영하지 못한 것은 서로 다른 문제입니다. 5장은 RAG를 단일 검색 기능이 아니라 정보가 흘러가는 아키텍처로 바라봅니다. 파이프라인을 단계별로 나누고 어느 지점에서 정보가 어긋났는지 진단하는 구성입니다.
에이전트로 가면 경계는 더 중요해집니다. 계획·기억·도구가 연결된 시스템에서는 잘못된 판단이 잘못된 행동으로 이어질 수 있으니까요. 메일을 보내거나 데이터를 수정하는 도구까지 붙였다면 무엇을 허용하고, 어느 단계에서 멈추고, 문제가 생겼을 때 어떻게 되돌릴지 먼저 정해야 합니다. 저자도 인터뷰에서 에이전트가 현실에 영향을 미칠 수 있는 범위를 어디까지 허용할지가 중요한 설계 경계라고 설명합니다.
assertEqual에서 멈추는 순간
가장 오래 눈길이 간 부분은 11장의 테스트와 평가 이야기입니다. 일반적인 API라면 예상한 상태 코드나 응답값을 비교할 수 있습니다. AI 답변은 같은 뜻을 다른 문장으로 표현하고, 핵심 단어가 들어 있어도 전체 내용은 틀릴 수 있습니다.
277~278쪽에서는 정확한 문자열 비교를 넘어 의미 유사도와 키워드 포함 여부로 비교하는 예를 보여줍니다. 세 방법 모두 그럴듯해 보이지만 한 번 더 들여다보면 빈틈이 있습니다. 표현이 달라서 실패하는 테스트, 의미는 비슷해도 중요한 사실이 틀린 답변, 키워드만 들어 있고 엉뚱한 결론을 내린 답변을 생각해 보면 됩니다. 더 영리한 비교 함수 하나가 답변의 품질 판단을 대신해 주지는 않습니다.
실패한 질문을 다음 평가에 남기기
책의 중심축인 평가 주도 개발(EDD)도 이 문제에서 출발합니다. 서비스를 만들기 전에 무엇을 좋은 결과로 볼지 정하고, 그 기준을 평가 데이터와 운영 과정에 연결합니다. 챗봇이라면 답변의 정확성과 안전성이 중요할 수 있고, 다른 시스템을 직접 바꾸는 에이전트라면 중단과 복구 가능성이 더 큰 기준이 될 수 있습니다.
특히 운영에서 발견한 실패를 다시 평가 데이터에 넣는 흐름이 실무적으로 와닿습니다. 시연 때 준비한 질문에 계속 잘 답하는 것보다, 지난주에 틀렸던 질문을 이번 변경 뒤에는 어떻게 처리하는지 확인할 수 있어야 하니까요. 후반부에서 다루는 실패 신호와 트레이스, 체크포인트도 같은 방향을 향합니다. 최종 답변 하나만 남기지 말고 중간에 무슨 일이 있었는지 볼 수 있게 만들자는 것입니다.
총평 및 추천 대상
<AI 시스템 설계>는 AI 기능을 운영하는 개발자가 마주칠 질문들을 한 흐름으로 묶어 놓은 책입니다. 답변이 틀렸을 때 원인을 어떻게 찾을지, 무엇을 기준으로 개선됐다고 말할지, 에이전트에게 어디까지 맡길지. 모델을 선택한 뒤에 남는 일들입니다.
432쪽에 15개 장을 담은 만큼 한 가지 RAG 기법이나 특정 에이전트 프레임워크의 구현법만 깊게 파고들려는 분과는 기대가 다를 수 있습니다. 대신 여러 기술을 하나의 운영 가능한 시스템으로 연결하는 기준이 필요한 분에게 잘 맞겠습니다. 데모를 서비스로 옮겨야 하는 팀이라면, 책의 각 장을 설계 점검표처럼 따라가 볼 만합니다.
✅ 이런 분들에게 강력 추천합니다:
- LLM이나 RAG 데모는 만들었지만 운영 중 답변 품질을 어떻게 확인할지 막막한 개발자
- 모델을 바꿀 때마다 '전보다 좋아졌다'는 말을 근거 있게 하고 싶은 AI·백엔드 엔지니어
- 외부 도구를 쓰는 에이전트의 권한과 실패 범위를 설계해야 하는 팀 리드
- AI 기능의 로그·평가·복구 절차를 하나의 운영 흐름으로 묶고 싶은 분
데모가 한 번 성공한 것은 좋은 출발입니다. 다음에 같은 질문이 왔을 때도 믿을 수 있는지, 실패하면 어디서 고칠 수 있는지까지 설명할 수 있어야 비로소 서비스가 됩니다. AI를 실제 업무에 붙여야 하는 개발자라면 곁에 두고 돌아볼 만한 질문이 많은 책입니다.
AI가 답을 만드는 일과
그 답을 믿고 운영할 수 있게 만드는 일은 다르다.