-
-
AI 시스템 설계 - 불확실한 AI를 운영 가능한 시스템으로 만드는 구조와 원칙
이한울 지음 / 한빛미디어 / 2026년 9월
평점 :
한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬받아 작성된 서평입니다.
부트캠프 강사로서 Spring AI로 RAG(검색 증강 생성) 수업을 하면서 여러 한계를 느꼈다. 문서를 나누고 검색한 뒤 모델에 전달하는 흐름을 구현해도 무언가 어색함과 답답한 느낌을 지울 수 없었다. <AI 시스템 설계>를 읽으며 그 원인을 알아갈 수 있었다. 중요한 건 '설명'이었다. 즉, 각 단계에서 무엇을 확인하고 실패하면 어디를 살필지에 관한 지침이 필요했던 것이다.
답변이 엉뚱할 때 확인할 곳은 생각보다 많다. 관련 문서를 못 찾았는지, 찾은 자료를 자르거나 배치하는 과정에서 중요한 내용을 놓쳤는지, 모델이 근거를 무시했는지를 구분해야 한다. 출력 검증까지 포함하면 검색의 성공과 시스템의 성공 사이에는 여러 단계가 있다.
입력을 통제하고 출력을 평가하며 실패를 처리하는 구조가 하네스(harness)다. 데모에서는 사람이 질문을 고르고 결과를 확인하며 다시 실행하기도 한다. 운영에서는 이런 판단과 처리를 어디에 둘지 정해야 한다. 모델의 답변이 조금 달라도 괜찮은 경우와 반드시 막아야 하는 실패를 구분하는 일도 여기에 포함된다.
코드 없이 아키텍처에 집중한 구성이 좋았다. 단계 사이의 경계와 책임을 생각하며 읽었다. 다만 LangChain이나 Spring AI로 간단한 시스템을 만들어본 뒤 읽는 편이 낫다. 중간중간 개념에 대한 설명이 있긴하지만, 나처럼 클린 아키텍처나 AI 모델에 대한 이해도가 없다면 길을 잃을 것 같다.
다행(?)이도 직접 구현하며 느꼈던 한계 덕분에 설명 속 문제를 구체적으로 와닿았다. 이전에 간결한 챗봇, 검색 시스템, 추천 시스템 등을 만들며 default 값을 아무 의심 없이 쓰던 시절이 없었다면 느끼질 못했을 감각이다.
멀티 에이전트를 오케스트레이션하는 경험이 쌓이다보면 자연스레 모델과 에이전트를 어떻게 평가하고 운영할지에 관심이 커질 수밖에 없다. 최종 답변이 괜찮다는 이유만으로 중간 과정까지 괜찮았다고 판단할 수는 없는 것이 재현성이나 신뢰성 문제가 항상 남기 때문이다. 단계마다 어떤 입력을 받았고 무엇을 반환했는지, 실패하면 다음 단계가 어떻게 처리하는지까지 확인해야 한다.
기억에 남는 단어 중에 하나가 바로 평가 주도 개발(EDD)이다. TDD, BDD의 비슷한 계열에 있는 개념인데 어차피 확률적으로 주어지는 모델/에이전트의 결과에 대해 명확한 기준을 하나 둔다기보단 충분히 좋은 결과의 기준을 먼저 정한다는 점이 흥미로웠다. 같은 질문에도 답이 달라진다면 정확성이나 관련성 중 무엇을 우선할지부터 결정해야 할텐데 그 과정을 측정 가능하게 만드는 것이 중요하다는 걸 깨달을 수 있었다.
관측 가능성(observability)은 개인적으로 항상 중요시 여기던 분야였는데 다른 관점을 볼 수 있었다. 지금까지 관측 가능성을 그저 백엔드의 운영 효율성과 모니터링에 가까운 개념으로 생각해왔다. 그런데 AI 인프라에서도 이렇게 중요했다니... 같은 질문에 다른 결과가 나왔을 때, 실행 기록을 따라 컨텍스트와 도구 응답, 상태의 차이를 비교해야 하는 측면은 미처 보지 못했던 방식이었다. 즉, 모델의 출력만 보는 것으로는 부족하다는 사실이 평가와 운영의 문제에서도 반복되기에 어느 경계에서, 어떤 방식으로 감시할 것인지를 봐야한다.
1~2년 전만 해도 이만큼 체계적이라고 느끼지 못했던 분야가 이렇게 구체적으로 정리된 점이 좋았다. 도구의 이름은 바뀌어도 역할과 경계를 이해한 경험은 남는다. 무엇이 부족해서 새 도구가 나왔는지 이해하려면 그전의 시행착오도 알아야 한다. 어제 배운 것이 오늘 사라지는 시대라지만, 역설적으로 그렇기에 오늘 배워놔야만 그 필요와 발전을 느낄 수 있다고 생각한다. 이 책을 통해 그 과정이 덜 고통스럽고 더욱 체계적으로 접근할 수 있었다. 여러 라이브러리와 프레임워크 수준에서 AI 기반 시스템을 구현한 초보자들부터 어느정도 감을 잡기 시작한 시니어까지 두루 추천한다.