이런 상황이라면
프로토타입은 돌아가는데 실서비스로 올리려니 막막한 개발자에게 맞는다. 응답이 느리고 비용이 새고 품질을 측정할 방법이 없다면 모델 문제가 아니라 설계 문제일 가능성이 크다. 반대로 모델 자체를 학습시키고 튜닝하는 연구 단계에 있다면 이 책의 관심사와 어긋난다.
한눈에 보기
AI 기능을 붙이는 일은 쉬워졌다. 어려워진 건 그 기능을 서비스로 유지하는 일이다. 이 책은 "모델을 어떻게 고르는가"보다 "모델을 둘러싼 구조를 어떻게 짜는가"를 문제로 잡는다. 데이터가 들어오고, 추론이 일어나고, 결과가 저장되고, 품질이 측정되는 경로 전체를 하나의 시스템으로 본다. 그래서 다루는 대상도 프롬프트 한 줄이 아니라 파이프라인, 서빙, 캐싱, 비용, 모니터링 같은 설계 결정이다. 한빛미디어의 기술 실무서 계열답게 추상적인 전망보다 구현 가능한 구조에 무게를 둔다.
기존 AI 책들이 모델의 성능과 가능성을 설명했다면, 이 책은 그 모델이 트래픽과 비용과 장애를 만나는 지점을 다룬다. 통념은 "좋은 모델을 쓰면 좋은 서비스가 된다"는 것이다. 현실은 그 반대에 가깝다. 모델은 비결정적이고, 응답 시간은 들쭉날쭉하고, 비용은 요청 수에 비례해 늘어난다. 이 성질을 가정에 넣고 설계하지 않으면 데모는 되지만 운영은 안 된다. 그래서 이 책의 관심은 정확도 몇 퍼센트가 아니라 "틀릴 수 있는 부품으로 신뢰할 만한 시스템을 만드는 방법"에 있다.
핵심 인사이트
- 01
AI 기능의 난이도는 모델이 아니라 경계에 있다
모델 호출 자체는 함수 하나다. 문제는 그 함수를 감싸는 경계에서 생긴다. 입력이 얼마나 길어질지 모르고, 출력 형식이 매번 보장되지 않고, 외부 API는 느려지거나 끊긴다. 전통적인 모듈은 같은 입력에 같은 출력을 주지만 모델은 그렇지 않다. 그래서 검증, 재시도, 폴백, 타임아웃 같은 장치가 선택이 아니라 기본 구성이 된다. 설계의 중심을 모델 내부에서 모델 바깥으로 옮기는 순간, 손댈 수 있는 지점이 훨씬 많아진다.
- 02
비결정성은 버그가 아니라 전제다
같은 질문에 다른 답이 나오는 걸 고치려 들면 끝이 없다. 이 성질은 제거 대상이 아니라 설계 전제다. 받아들이면 질문이 바뀐다. "항상 맞게 만들 방법"이 아니라 "틀렸을 때 사용자가 덜 다치게 할 방법"을 묻게 된다. 출력은 자유 텍스트 대신 스키마로 받고, 확신이 낮으면 사람에게 넘기고, 중요한 판단에는 두 번 묻는다. 결정적 시스템의 테스트 방식도 그대로 쓸 수 없어서, 단일 정답 비교 대신 분포와 샘플 평가로 옮겨간다. 이 전환을 못 하면 품질 관리가 "느낌"에 머문다.
- 03
비용은 아키텍처가 결정한다
AI 서비스의 비용은 요금표가 아니라 구조에서 나온다. 요청 수, 컨텍스트 길이, 모델 등급, 재시도 횟수가 모두 곱해지기 때문이다. 흔한 실수는 모든 요청에 가장 큰 모델을 쓰고 전체 문서를 매번 넣는 것이다. 같은 기능도 캐싱, 라우팅, 요약된 컨텍스트를 적용하면 비용이 자릿수 단위로 달라진다. 반대로 과도한 절감은 품질을 깎아 사용자를 잃는다. 그래서 비용은 재무 문제가 아니라 설계 선택이고, 기능을 기획하는 단계에서 함께 결정해야 한다.
- 04
측정 없는 개선은 취향 싸움이 된다
AI 기능은 좋아졌는지 나빠졌는지 눈으로 판단하기 어렵다. 그래서 팀 안에서 프롬프트 수정은 쉽게 취향 논쟁으로 번진다. 해결은 바꾸기 전에 기준을 만드는 것이다. 실패 사례를 모아 평가셋으로 묶고, 수정 전후를 같은 셋에 돌려 비교한다. 서비스 지표도 정확도 하나가 아니라 응답 시간, 폴백 비율, 사용자 재질문 비율처럼 운영 가능한 숫자로 나눈다. 숫자가 생기면 논쟁이 실험으로 바뀌고, 롤백할 근거도 함께 생긴다.
- 05
검색이 모델보다 결과를 더 바꾼다
답이 부실한 이유는 모델이 멍청해서가 아니라 근거를 못 받았기 때문인 경우가 많다. 모델은 주어진 컨텍스트 안에서만 똑똑하다. 그래서 문서를 어떻게 쪼개고, 무엇을 넣고, 어떤 순서로 주느냐가 모델 교체보다 효과가 크다. 청크가 너무 크면 핵심이 묻히고, 너무 작으면 문맥이 끊긴다. 상위 모델로 올리기 전에 검색 품질을 먼저 들여다보는 쪽이 비용도 싸고 개선 폭도 크다. 이 순서를 뒤집으면 돈을 쓰고도 같은 답을 받는다.
- 06
운영은 배포가 아니라 관찰에서 시작한다
AI 기능은 배포한 날부터 데이터가 달라진다. 사용자는 개발자가 상상하지 못한 입력을 넣고, 모델 제공자는 버전을 올린다. 그래서 한 번 잘 맞춘 상태는 유지되지 않는다. 입력과 출력, 지연 시간, 실패 유형을 남겨 두지 않으면 품질이 떨어졌다는 사실조차 늦게 안다. 로그는 디버깅 수단이기도 하지만 다음 평가셋의 원재료이기도 하다. 관찰 가능성을 나중에 붙이는 기능으로 두면, 정작 필요한 순간에 아무 기록이 없다.
이렇게 적용한다
상황데모에서는 잘 되던 AI 기능이 실사용자에게 풀자 품질 불만이 쌓일 때
불만이 들어온 요청 30건을 모아 입력·출력·기대값으로 정리한다. 이게 첫 평가셋이 된다. 프롬프트나 모델을 바꿀 때마다 이 30건을 돌려 전후를 비교하고, 통과 건수를 기록으로 남긴다. 체감이 아니라 숫자로 개선 여부를 말할 수 있게 되는 게 목적이다.
상황AI 기능의 월 비용이 예상보다 몇 배로 나와 기능 축소 얘기가 나올 때
요청을 난이도로 나눠 라우팅부터 손댄다. 단순 분류나 형식 변환은 작은 모델로 내리고, 복잡한 추론만 큰 모델에 남긴다. 반복되는 질문은 캐싱하고, 컨텍스트에 매번 들어가던 전체 문서를 필요한 구간으로 줄인다. 기능을 빼기 전에 구조를 바꿀 여지가 보통 더 크다.
상황모델이 가끔 엉뚱한 형식으로 답해 뒷단 로직이 깨질 때
출력을 자유 텍스트로 받지 않고 스키마로 고정한다. 파싱 실패는 예외가 아니라 정상 경로로 처리해 재시도와 폴백을 붙인다. 실패한 응답은 그대로 로그에 남겨 어떤 입력에서 깨지는지 패턴을 찾는다. 모델을 믿는 대신 깨질 자리를 미리 정해 두는 쪽이 싸다.
ACTION ITEMS
오늘 바로 할 수 있는 것.
- ✓지금 운영 중인 AI 기능의 입력·출력·지연 시간을 남기는 로그를 오늘 추가한다.
- ✓실패 사례 20건을 모아 평가셋 파일 하나로 만들어 저장소에 커밋한다.
- ✓가장 자주 호출되는 AI 기능 하나를 골라 월 비용을 요청 수 × 토큰으로 계산해 본다.
- ✓모델 응답을 받는 코드에 타임아웃과 폴백 경로를 하나 넣는다.
- ✓자유 텍스트로 받고 있던 출력 한 곳을 스키마 기반 파싱으로 바꾼다.
- ✓검색 단계에서 모델에 실제로 전달되는 컨텍스트를 그대로 출력해 눈으로 확인한다.
밑줄 그은 문장
“모델을 바꾸기 전에 모델에 무엇을 주고 있는지 먼저 봐야 한다.”
“측정하지 않는 AI 기능은 좋아지지도 나빠지지도 않는다. 그냥 모를 뿐이다.”
이 책이 답하지 않는 것
모델을 직접 학습시키거나 구조를 설계하는 연구 영역은 이 책의 범위가 아니다. 시스템 설계를 다루는 책이라 특정 프레임워크의 최신 API나 빠르게 바뀌는 모델별 성능 비교는 기대하지 않는 게 좋다. 프로덕션 경험이 전혀 없는 입문자에게는 전제되는 배경지식이 많다.
이 통찰의 근거가 궁금하다면?
원서·번역서 정보와 가격은 판매처에서 확인하세요.
※ 구매 링크는 제휴 활동의 일환이며, 이를 통해 일정액의 수수료를 제공받습니다. 구매자에게 추가 비용은 발생하지 않습니다.
비슷한 주제의 책
NEWSLETTER
매일 아침, 새로운 인사이트
하루의 시작을 도와줄 책 한 권의 핵심과 실천 과제를 보내드립니다.