주니어 AI 엔지니어가 반드시 알아야 할 실무 지식 - LLM의 불확실성을 시스템으로 통제한다는 것의 실체
"한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다."
여행 일정 추천 기능을 OpenAI API로 만들어 배포하고, 지금도 유지보수 중이다. 만들고 나면 고민이 끝날 줄 알았는데, 고민은 그다음에 시작됐다. 같은 질문에도 모델이 조금씩 다른 답을 내놓았고, 결과가 이상하면 로그를 뒤져야 했다. 품질을 올리면 비용이 걱정되고, 비용을 줄이면 품질이 걱정됐다. 모델의 불확실성을 어떻게 감당할지 막막하던 때 펼친 책이 《주니어 AI 엔지니어가 반드시 알아야 할 실무 지식》(김태헌, 한빛미디어)이다.
이 책은 프롬프트 잘 쓰는 법이나 모델 튜토리얼을 알려주는 책이 아니다. "정상처럼 보이는 실패"를 다루는 실무형 AI 엔지니어링 가이드다. 아래는 LLM 기능 하나를 운영하며 모델의 불확실성에 부딪힌 입장에서, 책을 읽으며 가장 많이 "아, 이거였구나" 했던 지점들을 정리한 회고다.
"모델은 똑똑한데, 시스템은 왜 바보가 될까?" (1장)
책의 1장은 통제의 7단계로 시작한다. 그중에서 가장 오래 붙잡고 있었던 건 "하드 가드레일은 프롬프트가 아닌 코드로 제약한다"는 구절이었다. LLM 출력을 프롬프트 문구만으로 통제하려는 유혹은 끊기 어렵다. "이런 답은 하지 마세요"를 한 줄 더 추가하는 게 그 순간에는 가장 쉬운 수정처럼 보이니까. 그런데 7단계를 끝까지 읽고 나니, 결정권을 모델에게 두는 프롬프트식 제약은 방어가 아니라 그냥 부탁이라는 생각이 들었다. 모델은 제안만 하고, 최종 결정은 코드가 하는 구조여야 한다. 할루시네이션도 "버그가 아니라 특성"이니 없애려 하지 말고, 근거를 붙이고 검증하고 실패 시 폴백하는 구조로 관리하라는 설명도 같은 맥락에서 이해가 갔다.
장애의 대부분은 모델 밖에서 시작된다 (2장)
LLM 기능을 디버깅할 때, 내가 쌓아 둔 로그는 주로 오류를 잡는 데만 쓰고 있었다. 그런데 책은 정반대로 말한다. 디버깅은 바깥에서 안으로, 데이터 → 전처리 → 외부 의존성 → 후처리 순서로 진행하고 모델은 마지막에 보라는 것이다. 장애 유형 Top 5에도 모델 자체 문제는 5번째에 겨우 들어 있다.
가장 무서웠던 개념은 "침묵하는 장애"였다. 에러 로그 없이 그냥 잘못된 결과를 내놓는 장애는 발견까지 며칠, 몇 주가 걸린다. 에러가 없다는 건 오히려 위험 신호일 수 있다는 관점이 크게 와닿았다. 그래서 성능 지표뿐 아니라 출력 분포와 피처 분포를 평소에 봐 둬야 한다는 조언도 받아들여졌다. 모델이 유죄인 경우는 오직 드리프트, 즉 배포 한참 뒤 성능이 서서히 떨어질 때뿐이라는 구분도 실용적이었다.
데이터는 생각보다 훨씬 쉽게 망가진다 (3~5장)
2부는 데이터 파이프라인을 다룬다. "데이터 파이프라인은 데이터를 옮기는 코드가 아니라 모델이 보는 현실을 편집하는 시스템"이라는 문장이 인상적이었다. BI와 달리 AI 파이프라인의 소비자는 이상치를 무시하지 못하는 모델이기 때문에, 필터 하나와 윈도우 하나가 모델의 세계관을 결정한다. 파이프라인 하나를 모니터링 대상으로 대접하라는 말도, 데이터 파이프라인의 출력이 다운스트림과의 암묵적 계약이라는 지적도 그 연장선이다.
4장에서는 스키마 드리프트와 시맨틱 드리프트를 구분한다. 스키마 드리프트는 시끄러워서 잡을 수 있는데, 시맨틱 드리프트는 조용하고 치명적이다. 통화 단위가 바뀌거나 레이블 정의가 달라지면 코드를 한 줄도 안 고쳤는데도 모델이 망가진다. 인상 깊었던 건 "오래된 문서는 RAG에 독이 된다"는 문장이다. 문서 TTL만으로는 부족하고, 새 문서가 들어올 때 이전 문서를 자동으로 대체하는 문서 관계도를 핵심 방어 기제로 봐야 한다고 한다. 컨텍스트 포이즈닝은 근거가 있는 틀린 응답이라 할루시네이션보다 검증이 어렵다는 지적은, LLM에게 맥락을 넣어서 답을 만드는 기능을 만들고 있는 나에게 특히 오래 남았다.
5장의 자기 강화적 편향도 흥미로웠다. 모델의 출력이 학습 데이터로 다시 돌아오는 루프가 생기면, 데이터가 쌓일수록 편향이 커진다. "데이터가 많아지면 나아지겠지"는 착각이며, 편향된 방향으로 많아질 뿐이다. 그래서 인기 있는 것이 더 인기를 먹는 피드백 루프를 끊으려면 탐색 슬롯 같은 의도적인 장치가 필요하다는 설명에 고개가 끄덕여졌다.
LLM은 API가 아니라 확률 엔진이다 (6~7장)
3부는 LLM을 "다음 토큰 예측기"로 다시 정의하는 데서 시작한다. 온도를 0으로 해도 완전한 결정성이 보장되지 않고, API 제공자의 모델 업데이트 같은 통제 불가능한 요인이 남는다. 그래서 모델 버전 핀닝과 캐싱이 필요하다는 부분은 실무에서 바로 써먹을 팁이었다.
그다음의 "앤트로픽조차 자사 모델을 날것으로 믿지 않는다"는 내용은 흥미로웠다. 클로드 코드의 51만 줄 중 대부분이 모델 출력을 검증하고 통제하는 결정론적 코드이며, Bash 도구 하나에만 12,000줄의 보안 코드가 들어간다고 한다. 확률적 LLM을 결정론적으로 유지하는 것은 다층적 아키텍처의 몫이라는 것이다. 그리고 수학, 날짜, 조건 분기, 비즈니스 규칙은 코드로 처리하고 LLM은 자연어 이해와 생성에만 맡기라는 "결정론적 분리" 원칙이 7장의 정수로 다가왔다. LLM이 있으면 모든 걸 맡기고 싶어지는데, 이 원칙은 코드가 맡을 일과 모델이 맡을 일의 경계를 분명히 그어 준다. 품질과 비용을 고민하고 있는 나에게 가장 먼저 적용하고 싶은 기준이었다.
RAG, 도구 호출, 에이전트를 운영 가능하게 (8~10장)
4부는 데모에서는 멋지게 보이지만 프로덕션에서 무너지는 지점들을 파고든다.
- 청킹 전략이 RAG 전체 품질을 좌우한다. 고정 크기 청킹은 데모 전용이다.
- 벡터 유사도가 높다고 정답이 거기 있는 것이 아니다. 메타데이터 필터링으로 검색 공간을 줄이고 하이브리드 검색과 리랭킹으로 관련 문서를 앞에 두어야 한다.
- 맥락은 시간에 따라 썩는다. 임베딩 드리프트와 문서 오염에 대비해야 하며, 지식 기반은 유지 관리하는 살아 있는 시스템이다.
도구 호출 쪽도 엔지니어가 API 설계를 하는 감각으로 봐야 한다고 한다. 도구 스키마는 할 수 있는 것뿐 아니라 할 수 없는 것까지 명시해야 하고, 읽기 도구와 쓰기 도구를 다르게 취급해야 한다. 쓰기 도구의 최종 실행은 모델이 아니라 코드가 결정하고, 멱등성 키가 없으면 모델의 확률적 재시도 때문에 같은 호출이 중복 실행될 수 있다고 한다.
에이전트 파트에서 가장 인상 깊었던 숫자는 멀티스텝의 확률 곱이다. 각 단계가 90% 정확해도 5단계면 59%, 10단계면 35%다. 단계 수를 줄이는 것이 가장 효과적인 신뢰성 향상 전략이라는 결론은 단순하지만 설득력이 있었다. 하드 리밋(반복 횟수, 비용 상한, 시간 제한, 컨텍스트 크기)이 없으면 47,000달러 사건 같은 일이 벌어질 수 있고, 계획은 모델의 머릿속이 아니라 외부 체크리스트로 관리하는 것이 안정적이라는 조언도 실무에서 곧바로 적용할 만했다.
운영 파트와 마지막 장의 원칙 (11~14장)
5부는 평가, 비용, 관측 가능성으로 마무리된다. "감이 아니라 측정으로, 평가 주도 개발"이라는 제목이 말해주듯, 무엇을 바꾸든 변경 전후의 품질을 비교할 수 있어야 한다. 그리고 "관측되지 않는 AI 시스템은 이미 실패했다"는 13장의 관점은, 디버깅을 위해 로깅이 필요하다는 걸 알고는 있었지만 관측 가능성을 설계의 일부로 봐야 한다는 점을 새기게 했다.
책의 마지막 장인 14장의 끝에는 "도구보다 오래가는 원칙"이라는 소제목이 있고, 거기서 네 가지를 정리한다.
- 모델을 믿지 말고 감싸라. 확률적 시스템은 자신 있게 틀릴 수 있다.
- 바꾸기 전에 측정하라. 비교할 수 없으면 더 좋아졌는지 알 수 없다.
- 자동화 전에 경계를 그어라. 어디까지 자동화하고 어디서 사람이 판단할지 먼저 정의해야 한다.
- 운영 전부터 관측 가능하게 만들어라. 문제가 생겼을 때 원인을 찾을 데이터가 있어야 한다.
모델, API, 프레임워크는 몇 달마다 바뀌어도 이 원칙은 바뀌지 않을 것이다. 그래서 도구 이름이나 버전이 낡아도 이 책의 가치는 남는다고 느꼈다.
아쉬웠던 점
- 장애, 데이터, 안전 설계에 무게가 실려 있고, 실제 서빙 아키텍처나 비용 최적화는 상대적으로 얇게 다뤄진다. 배포 세부 운용을 코드로 배우고 싶다면 다른 책이 필요하다.
- 실습 위주의 책이 아니어서, AI 시스템 경험이 전혀 없는 상태에서 읽으면 "그래서 어디서부터 시작하라는 거지?"라는 질문이 남을 수 있다. 나처럼 LLM API로 기능 하나를 만들어 배포해 본 뒤에 읽으면 이해가 훨씬 빠를 것 같다.
이런 분께 추천
- RAG나 에이전트 데모는 만들었는데, 프로덕션에 못 올리고 막힌 개발자
- 프롬프트를 정교하게 다듬는 것을 AI 엔지니어링이라고 생각해 온 1년 차 주니어
- MCP, 도구 호출, 에이전트 프레임워크가 계속 바뀌는데 어떤 기준으로 안전하게 적용해야 할지 모르겠는 실무자
- 프롬프트를 몇 줄 추가해서 문제를 해결하려는 개발자(책을 읽으면 그 접근을 버리게 된다!)
총평
《주니어 AI 엔지니어가 반드시 알아야 할 실무 지식》은 데모와 프로덕션 사이의 간극을 구체적으로 설명하는 책이다. 모델의 불확실성 때문에 어디서부터 잡아야 할지 막막했던 나에게, 이 책은 문제를 보는 순서를 바꿔 줬다. 이제는 모델 출력을 감싸는 구조와 모델 밖의 요소부터 확인하게 된다.
빠르게 변하는 기술 앞에서 흔들리지 않고자 한다면, 이 책에서 제시하는 변하지 않는 중요한 원칙을 훑어보기를 권한다.