"한빛미디어 서평단 ＜나는리뷰어다＞ 활동을 위해서 책을 협찬받아 작성된 서평입니다."

요즘 팀 회의에서 자주 나오는 말이 있다. "어제는 됐는데 오늘은 왜 안 되지?" 코드를 안 건드렸는데, 배포도 안 했는데, 프롬프트도 그대로인데 답변 품질이 흔들린다. 처음엔 내가 뭘 놓쳤나 싶어서 로그를 뒤졌다. 에러는 없었다. 배포 이력도 깨끗했다. 그냥 결과가 어제와 달랐을 뿐이다.

전통적인 개발자로 커리어를 시작한 사람이라면 이 감각이 얼마나 불편한지 알 것이다. 나는 늘 "입력이 같으면 출력도 같다"는 세계에서 일해왔다. 단위 테스트를 짜고, 재현 가능한 버그를 잡고, 같은 조건이면 같은 결과가 나온다는 걸 믿고 하루하루를 살았다. 그런데 LLM을 서비스에 붙이는 순간, 그 전제가 깨진다. 같은 질문을 열 번 던지면 열 개의 답이 조금씩 다르게 나온다. 버그가 아니다. 원래 그렇게 설계된 시스템이다.

문제는 이걸 '버그가 아니다'라고 받아들이는 순간부터 시작이다. 그럼 대체 뭘 테스트하고, 뭘 모니터링하고, 뭘 믿어야 하나. QA 팀에 어떻게 테스트 케이스를 요청해야 하나. 이 질문들 앞에서 나는 몇 달째 답을 찾지 못하고 있었다.

그 막막함을 안고 있던 차에 이 책을 만났다. 부제부터 눈에 들어왔다. '모델의 불확실성을 시스템으로 통제하는 AI 엔지니어링 실무 가이드.' 통제라는 단어가 마음에 걸렸다. 확률적인 걸 어떻게 통제한다는 거지, 싶었다. 모순처럼 들리는 그 제목이 오히려 끌렸다. 다 읽고 나니 그 질문 자체가 틀렸다는 걸 알게 됐다. 통제한다는 건 모델을 확정적으로 만든다는 뜻이 아니었다. 모델이 흔들려도 시스템은 흔들리지 않게 만든다는 뜻이었다.

돌이켜보면 우리 팀이 겪었던 사건들에는 공통점이 있었다. API 제공자가 조용히 모델 버전을 올렸는데 우리는 몰랐고, 어느 날부터 응답 톤이 미묘하게 달라져 있었다. 우리는 그걸 우리 코드의 버그라고 착각하고 사흘을 날렸다. 이 책 초반부에서 '버전 시점의 고정'이라는 개념을 마주쳤을 때, 그 사흘이 다시 떠올랐다. 우리가 의존하는 모델은 우리 서버 안에 있지 않다. 외부 API 뒤에서 언제든 조용히 바뀔 수 있는, 우리가 통제할 수 없는 변수다. 이걸 전제로 시스템을 짜본 적이 있었나 자문했더니, 없었다.

이 책은 '어떻게 물어볼까'가 아니라 '뭘 믿지 말아야 할까'를 묻는다

시중에 나온 AI 개발서 대부분은 프롬프트를 어떻게 짜고, RAG를 어떻게 붙이고, 에이전트에 도구를 어떻게 연결하는지를 다룬다. 다 필요한 내용이지만, 어느 순간부터 나는 그 책들을 읽어도 허기가 채워지지 않았다. 왜냐하면 내 문제는 '어떻게 붙이는가'가 아니라 '붙인 다음 왜 자꾸 무너지는가'였으니까. 붙이는 건 이미 몇 시간이면 끝난다. 문제는 붙이고 난 이후, 서비스가 실제 사용자를 만나는 순간부터 시작된다.

이 책은 정반대에서 출발한다. 1장 제목부터 "모델은 똑똑한데, 시스템은 왜 바보가 될까?"다. 저자는 처음부터 못을 박는다. AI 엔지니어링의 본질은 모델을 잘 다루는 기술이 아니라 통제다. 이 한 문장을 읽는 순간 내가 지금껏 헤매던 이유에 이름이 붙는 느낌이었다. 나는 모델을 더 똑똑하게 만드는 방법을 찾고 있었는데, 실제로 필요했던 건 모델이 틀려도 시스템이 안전하게 버티는 구조였다.

목차 구성도 이 태도를 그대로 반영한다. 총 5부 14장 중에서 모델 자체를 설명하는 건 3부 두 챕터뿐이다. 나머지는 데이터 파이프라인, 도구와 에이전트, 배포와 운영에 할애되어 있다. 챗봇 프레임워크를 소개하는 책이었다면 이런 비중이 나올 수 없다. 이 책이 처음부터 겨냥한 독자는 '모델을 잘 부르는 사람'이 아니라 '모델 주변의 시스템을 설계하는 사람'이라는 게 목차만 봐도 드러난다.

2장에서 저자가 "'모델은 무죄다'라는 관점"을 제시하는 대목도 인상적이었다. 장애가 나면 반사적으로 모델 탓을 하게 되는데, 실제 현장에서 가장 자주 터지는 장애는 모델 밖에서, 그러니까 데이터 파이프라인이나 프롬프트 조합, 컨텍스트 관리 같은 데서 시작된다는 것이다. 처음엔 이 주장이 조금 과하다고 느꼈다. 그런데 지난 반년간 우리 팀이 겪었던 장애들을 하나씩 떠올려보니, 실제로 모델 자체가 원인이었던 경우는 손에 꼽았다. 대부분은 우리가 넘긴 컨텍스트가 잘못됐거나, 파이프라인 어딘가에서 데이터가 조금씩 어긋나 있었다.

3장에서 데이터 파이프라인을 "단순한 ETL이 아니라 의사결정 생성기"라고 정의하는 부분도 관점을 바꿔놓았다. 나는 그동안 파이프라인을 '데이터를 옮기고 정리하는 배관 작업'쯤으로 생각해왔다. 그런데 저자는 그 배관을 어떻게 설계하느냐가 모델의 사고 구조 자체를 고정시킨다고 말한다. 배치로 처리할지 스트리밍으로 처리할지를 정하는 순간, 이미 어떤 종류의 판단을 모델에게 넘길지가 결정된다는 것이다. '나중에 고치자'가 통하지 않는 이유도 여기서 나온다. 파이프라인은 나중에 갈아끼우기가 생각보다 훨씬 어려운 구조물이니까.

부록으로 실린 현업 AI 엔지니어 4인의 인터뷰도 이 책의 결을 보여준다. 이론서로 끝나지 않고, 실제로 그 판단이 현장에서 어떻게 작동하는지까지 보여주려는 시도다. 인터뷰 하나에서 "'나중에 만들자'가 쌓이면 시스템이 무너진다"는 제목을 보고 뜨끔했다. 우리 팀 백로그에도 딱 그런 항목들이 쌓여 있으니까. 다른 인터뷰에서는 "AI는 완성되지 않는다, 도메인을 만나기 전까지는"이라는 말이 나오는데, 이건 두고두고 곱씹게 되는 문장이었다.

결정론과 확률론, 이 두 단어의 거리를 처음 실감했다

1부와 2부를 읽으면서 계속 밑줄을 그었다. 특히 시맨틱 드리프트와 컨텍스트 포이즈닝을 다루는 4장이 뼈아팠다. 시맨틱 드리프트는 데이터의 형식은 그대로인데 의미가 슬쩍 바뀌는 현상이다. 예를 들어 '활성 사용자'라는 컬럼 하나가 어느 날 팀 내부에서 정의가 바뀌었는데 아무도 공지하지 않았다면, 파이프라인은 여전히 잘 돌아간다. 타입도 안 깨지고, 스키마 에러도 없다. 그런데 그 위에서 학습되거나 참조되는 모든 판단이 조용히 틀려간다.

이게 왜 무서운가 하면, 로그가 정상이기 때문이다. 대시보드도 초록불이다. 나는 이 대목에서 잠시 책을 덮었다. 지난달 우리 서비스에서 답변 품질이 미묘하게 떨어졌던 시기가 있었는데, 그때 우리는 인프라 지표만 보고 있었다. CPU도 정상, 응답 시간도 정상, 에러율도 정상이었다. 정작 봐야 했던 건 데이터의 '의미'였다는 걸 이 챕터를 읽고 나서야 알았다.

컨텍스트 포이즈닝도 마찬가지다. 비정형 데이터, 그러니까 문서나 텍스트 뭉치가 조금씩 오염되는 과정은 사람 눈에 잘 안 띈다. RAG를 붙여본 사람이라면 검색은 멀쩡히 되는데 답변이 이상하게 나오는 순간을 겪어봤을 것이다. 8장에서 이 문제를 "검색 결과는 좋은데 응답이 이상한 이유"라는 제목으로 정면으로 다루는데, 청킹 전략부터 손을 대야 한다는 저자의 주장이 지극히 실용적이었다. 나는 그동안 청킹을 그냥 '적당히 나누면 되는 전처리 단계'로 취급했는데, 이 책은 그게 시스템 전체 사고 구조를 결정짓는 첫 관문이라고 못 박는다. 단순히 몇 토큰씩 자를지의 문제가 아니라, 그 조각이 모델에게 어떤 '생각의 단위'를 제공하는지의 문제라는 것이다.

5장에서 다루는 피드백 루프 이야기도 짚고 넘어가면 자기 강화적 편향이라는 개념이 낯설게 느껴질 수 있는데, 쉽게 말하면 모델이 낸 답을 사람이 무심코 긍정 신호로 되돌려주는 게 반복되면서 편향이 스스로 몸집을 불리는 현상이다. 이걸 읽으면서 우리 서비스의 '좋아요' 버튼이 떠올랐다. 사용자는 그냥 눌렀을 뿐인데, 그 데이터가 다음 학습에 들어가고, 다시 비슷한 답을 강화하는 구조. 아, 이게 그거였구나 싶었다. 혼자만 겪는 문제인 줄 알았던 것에 이름이 붙는 순간이었다.

다섯 겹의 방어막, 그리고 그 뒤에 숨은 7단계 프레임워크

이 책에서 내가 가장 유익했던 곳은 7장이다. "예측 불가능한 모델 위에 안정적인 시스템을 만드는 법"으로 저자는 설명해주고 있다. 모델 파라미터를 통제해서 확률의 폭을 줄이는 것부터 시작해, 출력 형식을 강제하고, 생성-검증-수정 루프를 돌리고, 결정론적으로 처리해야 할 로직은 아예 모델에서 떼어내고, 마지막으로 다층 검증 인프라를 얹는 형태다.

읽으면서 자연스럽게 정리가 됐다. 결국 이건 확률적으로 답하는 모델 위에 결정론적인 안전장치를 겹겹이 쌓는 이야기다. 모델 자체를 완벽하게 만들려는 시도가 아니라, 모델이 틀릴 걸 전제하고 시스템을 짜는 접근이다. 이 전환이 이 책 전체를 관통하는 핵심 주장이라고 봐도 될 것 같다. '규칙 설계자'로 일하다가 어느 순간 '확률 조율자'로 역할이 바뀌었는데, 그 사이의 간극을 아무도 설명해주지 않았던 것 같다. 이 책이 처음으로 그 간극에 이름을 붙여줬다.

여기서 특히 인상 깊었던 건 7단계로 정리되는 원칙들이었다. 결정권을 모델에서 분리하라는 원칙부터 읽으면서, 나는 우리 팀이 정확히 반대로 하고 있다는 걸 깨달았다. 최종 승인이 필요한 판단까지 모델의 출력을 그대로 다음 단계로 흘려보내고 있었으니까. 불확실성을 시스템 신호로 승격시키라는 원칙도 마찬가지다. 모델이 "잘 모르겠다"는 신호를 냈을 때 그걸 그냥 버리지 말고, 사람에게 넘기거나 다른 경로로 라우팅하는 분기를 만들어야 한다는 건데, 말은 쉬워도 실제 코드로 짜려면 꽤 많은 설계가 필요하다는 걸 이 장을 읽으며 실감했다.

가드레일은 모델 밖에 두라는 원칙, 폭발 반경을 미리 설계하라는 원칙도 좋았지만, 개인적으로 가장 오래 곱씹은 건 마지막 원칙이었다. 휴먼 인 더 루프는 임시방편이 아니라 영구 컴포넌트라는 것. 사람은 레이블러이자 백업이자 평가자이면서, 동시에 '세상이 바뀌었다'는 걸 가장 먼저 감지하는 센서라는 표현이 오래 남았다. 나는 그동안 사람의 개입을 자동화가 완성되기 전까지의 임시 땜빵으로 여겨왔는데, 이 책은 그게 시스템 설계의 정식 구성요소라고 말한다. 이 관점 하나만으로도 지금 진행 중인 프로젝트의 설계도를 다시 그려야겠다는 생각이 들었다.

9장과 10장에서 도구 호출과 에이전트를 다루는 부분도 살펴보면 읽기 도구와 쓰기 도구는 위험도가 완전히 다르다는 당연한 말이, 실제로 우리 시스템에는 반영되어 있지 않았다는 걸 깨달았을 때 조금 부끄러웠다. 최소 권한 원칙을 도구에도 적용해야 한다는 문장 앞에서 잠시 멈췄다. AI 시대에도 멱등성은 변하지 않는다는 짧은 문장 하나가, 그 어떤 긴 설명보다 정확하게 핵심을 찔렀다. 10장에서 멀티스텝으로 갈수록 불확실성이 곱해진다는 설명은 특히 와닿았다. 스텝마다 90% 정확도라고 해도, 다섯 스텝을 거치면 전체 성공률은 60%도 안 된다. 그동안 왜 에이전트 데모는 잘 되는데 실서비스에서는 자꾸 삐끗하는지, 이 계산 하나로 설명이 됐다.

10장에서 "에이전트를 만들지 않는 기술"이라는 표현으로 워크플로 다섯 패턴을 먼저 소개하는 순서도 좋았다. 다들 에이전트, 에이전트 하는데, 정작 필요한 건 자율성이 아니라 정해진 절차인 경우가 많다는 걸 이 챕터가 짚어준다. 체크포인팅과 롤백을 처음부터 다시 시작하지 않는 설계로 소개하는 대목에서는, 우리 에이전트 파이프라인이 실패하면 그냥 처음부터 재시도하도록 짜여 있다는 게 떠올라 민망했다. 능력의 분리, 그러니까 에이전트에게 권한을 주기 전에 무엇을 나눠서 줄지 고민하라는 원칙과, 읽기 도구조차 공격 통로가 될 수 있다는 경고까지, 10장 하나만으로도 우리 에이전트 설계를 다시 검토할 이유가 충분했다.

배포 이후: 비용, 평가, 그리고 침묵하는 실패를 잡는 법

5부는 결이 조금 다르다. 여기서부터는 시스템을 '만드는' 이야기가 아니라 '버티게 하는' 이야기다. 11장의 비용 최적화는 솔직히 실무자가 아니면 체감이 덜한 챕터일 수 있다.

하지만 프롬프트 캐싱이 프리필 단계를 건너뛰는 설계라는 설명, 지연 시간과 비용과 품질이 동시에 만족되지 않는다는 트레이드오프 인정은 현실적이었다. 어디선가 하나는 포기해야 한다는 걸 숫자로 받아들이게 해준다. 모델 라우팅과 캐스케이딩 부분, 그러니까 쉬운 요청은 싼 모델로, 어려운 요청만 비싼 모델로 넘기는 설계도 당장 다음 스프린트에 적용해볼 만했다.

12장과 13장이 오히려 나에게는 더 값졌다. "감이 아니라 측정으로"라는 12장 제목이 이 책의 태도를 압축한다. 에러 분석에서 출발해 골든 데이터셋을 작게 시작해서 살아있게 유지하라는 조언, LLM 심판을 신뢰하게 만드는 절차까지, 평가라는 게 한 번 만들고 끝나는 게 아니라 계속 기준이 표류한다는 걸 인정하고 다시 다듬어야 하는 일이라는 걸 알려준다. 처음엔 '기준 표류'라는 단어가 낯설었는데, 곱씹어보니 이게 우리 팀이 매번 평가 기준을 새로 짜는 이유였다. 기준은 원래 표류하는 게 정상이었다.

13장 제목은 이 책에서 가장 섬뜩했다. "관측되지 않는 AI 시스템은 이미 실패했다." 침묵하는 장애가 가장 위험하다는 말이 2장에서 한 번 나오고, 13장에서 세션-트레이스-스팬이라는 관측 단위로 구체화된다. 알림 설계 부분에서 "모든 것에 알림은 어떤 것에도 알림이 없는 것과 같다"는 문장을 읽고 우리 팀 슬랙 채널을 떠올렸다. 알림이 너무 많아서 아무도 안 읽는 채널이 하나 있다. 정확히 이 문제였다.

14장은 짧지만 책 전체를 다시 요약해주는 챕터다. 좋은 AI 엔지니어는 문제를 어디서부터 의심하는가, 라는 질문으로 시작해서 세 가지 렌즈를 제시하는데, 이걸 읽고 나서야 1장부터 13장까지 흩어져 있던 내용들이 하나의 흐름으로 이어졌다. 자동화의 경계선은 검증 가능성이라는 마지막 문장은, 어디까지 자동화하고 어디서부터 사람이 검증해야 하는지 갈피를 못 잡던 나에게 하나의 기준선을 그어줬다.

이런 사람에게 필요하다

프로덕션에서 반복되는 장애 앞에서 매번 "이번엔 또 뭐지" 하며 로그를 뒤지는 주니어 엔지니어라면 이 책에서 진단 순서를 얻어갈 수 있다. RAG나 에이전트, 도구 호출을 데모 수준에서 실서비스로 옮기려는 1~3년 차 엔지니어에게도 맞다. 이미 서비스를 운영 중인데 비용과 지연 시간, 품질 사이에서 계속 줄다리기를 하고 있다면 5부만 따로 읽어도 값어치를 할 것이다. 그리고 현업 엔지니어들이 실제로 어떤 기준으로 의사결정을 하는지 궁금한 신입에게는 부록 인터뷰가 의외의 보물이다.

반대로 프롬프트 엔지니어링 팁이나 특정 프레임워크 사용법을 빠르게 찾고 싶은 사람에게는 이 책이 답답하게 느껴질 수 있다. 이 책은 도구보다 원칙을 먼저 세우자는 입장이라, 당장 오늘 배포할 코드를 찾고 있다면 다른 책이 더 빠를 것이다. LLM을 아예 처음 써보는 완전 초심자에게도 다소 벅찰 수 있다. 데이터 사이언티스트나 ML 엔지니어 출신이 아니라 전통적인 백엔드 개발자 출신이라면, 오히려 이 책의 결정론 대 확률론 서술이 더 크게 와닿을 것이다. 반대로 이미 확률적 시스템에 익숙한 ML 엔지니어라면 1부의 상당 부분은 다소 당연하게 느껴질 수도 있다.

팀 단위로 본다면, 온보딩 자료로 1~2부만 발췌해서 스터디하는 것도 방법이라고 생각한다. 특히 시맨틱 드리프트와 컨텍스트 포이즈닝 부분은 신입 엔지니어가 프로덕션 장애를 처음 마주했을 때 겪는 당혹감을 미리 예방접종해주는 효과가 있다. 실제로 나는 이 챕터를 팀 채널에 요약해서 공유했더니, 지난달 겪었던 원인 불명의 이슈 하나가 뒤늦게 설명이 되더라는 반응이 돌아왔다. 7장의 7단계 프레임워크는 스프린트 회고 때 체크리스트로 써도 좋을 것 같다.

다 읽고 나서 달라진 건

이 책을 읽기 전과 후, 내가 코드를 짜는 방식 자체가 크게 바뀌진 않았다. 여전히 같은 프레임워크를 쓰고, 같은 API를 부른다. 그런데 달라진 게 하나 있다면, 이제는 뭔가 이상하게 동작할 때 "버그인가?"라고 먼저 묻지 않는다는 점이다. 대신 "이게 모델의 확률적 변동인가, 아니면 데이터가 조용히 썩은 건가, 아니면 시스템 설계에 결정권을 너무 많이 넘겨준 건가"부터 나눠서 생각하게 됐다.

AI가 들어간 이상 서비스는 확률형 서비스라는 걸, 이 책을 읽기 전에도 머리로는 알고 있었다. 그런데 그 문장이 실제로 내 코드와 내 모니터링 대시보드와 내 배포 프로세스에 어떤 의미인지는 이 책을 읽고 나서야 구체적으로 그려지기 시작했다.

결정론의 세계에서 살아온 개발자가 확률의 세계에서 안전한 시스템을 짜려면 무엇부터 내려놓아야 할지. 이 책은 그 답을 대신 내려주지 않는다. 대신 어디서부터 질문해야 하는지를 알려준다. 다음 스프린트 회고 때 팀원들과 이 질문부터 다시 던져봐야겠다. "우리 시스템에서, 결정권을 모델에게 너무 많이 넘긴 지점은 어디인가."

오늘도 찾아주셔서 감사합니다.

출처: https://patiencelee.tistory.com/1285 [PatienceLee:티스토리]

#한빛미디어 #나는리뷰어다

한빛미디어 서평단 ＜나는리뷰어다＞ 활동을 위해서 책을 협찬받아 작성된 서평입니다.

부트캠프 팀 프로젝트에서 서버를 맡아 '여운'을 만들었다. 전시를 보고 남긴 감상을 기록해두고, 나중에 다시 꺼내 그때의 나와 비교해보는 서비스다.

여기에 AI를 붙였다. 사용자가 편하게 적은 감상을 AI가 문장으로 다듬어주고, 감정 키워드를 뽑아주는 기능이었다. 만들었고, 돌아갔고, 사용자도 받았다.

이 책을 읽으면서 그때 무엇을 놓쳤는지 알게 됐다. 세 대목이 특히 그랬다.

1. 고장은 대부분 AI 바깥에서 시작된다

베타 테스트 중에 감상문 다듬기 기능이 작동하지 않는 걸 발견했다. 그때 팀에서 나온 첫 반응은 "AI가 이상한가?"였다.

이 책은 그 반응을 정면으로 다룬다. 실제 현장에서 AI 시스템이 고장 날 때, 원인이 AI 자체인 경우는 드물다는 것이다. 대부분은 AI에 도달하기 전이나 떠난 후에 생긴다. 잘못된 데이터가 들어오거나, 연결해둔 외부 서비스가 멈추거나, AI를 감싼 우리 코드가 틀렸거나.

우리도 그랬다. 원인은 AI를 불러오는 우리 쪽 코드의 실수, 그리고 외부 AI 서비스의 무료 사용량이 다 떨어진 것. 둘 다 AI가 똑똑하냐 아니냐와는 상관없는 문제였다.

"모델은 무죄다"라는 이 책의 관점은 AI를 두둔하는 말이 아니다. 문제가 생겼을 때 어디부터 열어볼지 순서를 정해주는 지침이다.

더 뜨끔했던 건 조용한 고장에 관한 대목이다. 어느 쇼핑몰에서 상품 분류 정보가 비어 있는 채로 들어왔는데, 처리하는 코드가 그걸 전부 '기타'로 묶어버렸다. 추천 결과는 엉망이 됐지만 어디서도 오류가 나지 않았다. 코드도 AI도 정상 동작했고, 단지 들어온 데이터가 의도와 달랐을 뿐이다. 그래서 문제가 있다는 사실조차 알기 어려웠다.

우리는 여기서 한 단계 더 나빴다. 무슨 일이 있었는지 확인할 기록 자체를 남기고 있지 않았다. 화면에서도 실패가 보이지 않아서, 사용자 눈에는 버튼을 눌러도 아무 일도 일어나지 않는 것처럼 보였다. 실패를 화면에 띄우는 처리를 넣고 나서야 비로소 실패가 실패로 보였다.

다른 프로젝트에서 데이터가 꼬였을 때는 프로그램이 즉시 멈추고 오류를 뱉었다. 시끄러웠지만, 그래서 고칠 수 있었다. AI 쪽에는 그런 장치를 만들어두지 않았다.

2. AI에게 준 참고자료도 검증 대상이었다

이 책은 데이터가 망가지는 방식을 둘로 나눈다.

하나는 모양이 바뀌는 것이다. 항목 이름이 달라지거나 사라지면 프로그램이 곧바로 멈추고 담당자를 부른다. 저자는 이걸 "시끄럽게 실패하는 변화"라 부르며, 시끄러운 실패는 오히려 안전하다고 말한다. 문제가 있다는 걸 즉시 알 수 있으니까.

다른 하나는 모양은 그대로인데 의미가 바뀌는 것이다. 어떤 형식 검사에도 걸리지 않는다. 책이 드는 예시가 인상 깊었다. 뉴스 기사를 받아

분석하는 서비스에서, 기사 본문에 광고 문구가 섞여 들어왔다. 형식은 완벽하니 모든 검사를 통과했고, AI는 그 광고 문구까지 기사의 논조로 읽고 잘못된 분석을 내놓았다.

이 대목에서 우리 서비스를 다시 봤다.

여운의 전시 정보는 공공 데이터에서 받아온다. AI에게 감상을 다듬으라고 시킬 때, 그 전시 설명을 참고자료로 함께 줬다. 나는 이걸 안전장치라고 생각했다. 실제 정보를 쥐여주면 AI가 없는 얘기를 지어내지 않을 거라고.

그런데 전시 설명에는 홍보 문구가 섞여 있다. "국내 최초", "놓치면 후회할" 같은 표현들. 형식은 흠 하나 없다. 그걸 그대로 참고자료로 주면, 다듬어져 나온 감상문에 그 톤이 묻어난다. 책의 예시와 똑같은 구조다. 참고자료 자체도 검증해야 한다는 생각을 나는 한 번도 못 했다.

한 군데 더 걸린다. 목록에 없는 전시장은 사용자가 이름을 직접 적어 등록할 수 있게 했다. 사용자 편의로는 옳은 결정이었다. 하지만 같은 미술관을 사람마다 다르게 적으면 서로 다른 장소로 쌓인다. 아무 오류도 나지 않는다. 그 위에 취향 분석을 얹으려 했다.

데이터 검사라고 하면 나는 형식만 떠올렸다. 의미가 조용히 미끄러질 수 있다는 감각이 없었다.

3. 답이 왔다는 것과 답이 맞다는 것은 다르다

이 책에서 가장 오래 들여다본 건 결제 서비스와 AI 서비스를 나란히 놓은 그림이었다.

결제 서비스에 요청을 보내고 "성공"을 받으면, 그건 결제가 끝났다는 확정된 사실이다. 같은 요청에는 언제나 같은 결과가 온다.

AI 서비스에서 받는 "성공"은 다르다. 그건 글이 만들어졌다는 뜻일 뿐이다. 내용이 맞는지는 아무것도 보장하지 않는다. 완전히 엉뚱한

답이 나와도 성공이고, 존재하지 않는 정보를 그럴듯하게 지어내도 성공이다. 같은 질문에 매번 다른 답이 나올 수도 있다.

나는 결제 쪽 감각으로 AI를 다뤘다. 응답이 오면 성공, 오류가 없으면 정상. 앞서 겪은 실패들이 전부 그 전제 위에서 벌어진 일이었다.

비용 이야기도 뼈아팠다. AI 서비스는 글을 잘게 쪼갠 단위로 요금이 매겨지는데, 한국어는 같은 뜻의 영어 문장보다 훨씬 많은 단위로 쪼개진다. 여운은 감상도, AI가 던지는 질문도, 참고자료로 넣는 전시 설명도 전부 한국어다.

무료 사용량이 다 떨어져 AI 기능이 멈췄을 때, 나는 그걸 "요청이 생각보다 많았나 보다"로 이해했다. 요금이 요청 횟수가 아니라 오가는 글의 양으로 매겨진다는 걸, 그것도 한국어에 훨씬 불리하게 매겨진다는 걸 계산에 넣지 않았다.

쪼개는 방식은 AI 서비스마다 달라서 다른 회사 기준으로 어림잡으면 안 된다는 주의도 있었다. 우리는 중간에 AI 제공사를 바꿨는데, 그 계산을 다시 하지 않았다.

그리고 AI에는 답변이 얼마나 자유롭게 나올지 조절하는 설정이 있다. 나는 한 번도 건드리지 않고 기본값으로 뒀다. 다듬어진 감상문의 품질이 들쭉날쭉했던 이유 중 하나가 거기 있었을 것이다.

마무리

세 대목이 하나로 이어진다. AI의 "성공"이 무엇을 보장하고 무엇을 보장하지 않는지, 고장이 나면 어디부터 봐야 하는지, 그리고 겉이 멀쩡한 채로 무엇이 조용히 망가지는지.

나는 이 셋을 모르는 채로 AI 기능을 만들었고, 그래도 서비스는 돌아갔다. 몰라도 굴러가긴 한다. 다만 왜 굴러가는지, 언제 멈출지를 설명할 수 없을 뿐이다.

이런 사람에게 권하고 싶다.

• AI 기능을 만들어 서비스에 올려봤지만, 문제가 생기면 어디부터 봐야 할지 막막한 사람
• 일반적인 개발 감각 그대로 AI를 다루고 있는 사람
• AI에게 외부 자료나 사용자 입력을 참고자료로 넘기면서, 그 자료를 검증 대상으로 보지 않는 사람
• 한국어 서비스에 AI를 붙여놓고 비용을 요청 횟수로 어림잡고 있는 사람

책을 덮고 나서 질문이 바뀌었다.

전에는 "이거 잘 되나?"를 물었다. 지금은 셋을 묻는다. 이 성공 응답은 무엇을 보장하나. 틀렸을 때 나는 알 수 있나. 지금 AI에게 넘기는 이 자료는 누가 검증했나.

#한빛미디어 #나는리뷰어다 #주니어AI엔지니어가반드시알아야할실무지식

 "한빛미디어 서평단 ＜나는 리뷰어다＞ 활동을 위해서 책을 협찬받아 작성된 서평입니다."

실무에서 AI는 어떻게 사용되는가?

책제목  : 주니어 AI 엔지니어가 반드시 알아야 할 실무 지식

                   : 시행착오를 줄여주는 실무 밀착 AI 엔지니어링 가이드

저자 : 김태헌

출판년도 : 2026/07/30

https://www.hanbit.co.kr/books/%EC%A3%BC%EB%8B%88%EC%96%B4-ai-%EC%97%94%EC%A7%80%EB%8B%88%EC%96%B4%EA%B0%80-%EB%B0%98%EB%93%9C%EC%8B%9C-%EC%95%8C%EC%95%84%EC%95%BC-%ED%95%A0-%EC%8B%A4%EB%AC%B4-%EC%A7%80%EC%8B%9D?code=B6420970634

한 줄 결론

AI 기능을 만들어본 경험은 있지만, 그것을 실제 서비스에서 안정적으로 운영하려면 무엇을 더 알아야 하는지

궁금한 주니어 개발자와 AI 엔지니어에게 잘 맞는 책이다.

읽게 된 이유

요즘 AI 관련 자료를 보다 보면 “일단 만들어보자”는 흐름이 강하다.

ChatGPT API를 호출하고, RAG를 붙이고, 에이전트를 구성하고, 간단한 데모를 만드는 예제는 이제 어렵지 않게 찾아볼 수 있다.

그런데 개발자 입장에서 진짜 궁금한 부분은 그다음이다.

데모에서는 잘 돌아가던 기능이 실제 사용자 앞에서도 계속 잘 동작할까?

문서가 바뀌었을 때 답변 품질은 어떻게 유지할까?

AI가 그럴듯하지만 틀린 답을 했을 때 시스템은 어떻게 막아야 할까?

나는 20년 동안 게임 프로그래머로 일해왔고, 최근에는 회사에서도 집에서도 AI와 바이브코딩을 꽤 적극적으로 쓰고 있다.

AI가 코드를 만들어주고 문서를 정리해주는 경험은 이미 익숙해졌지만,

쓸수록 오히려 더 조심스러워지는 부분도 있다.

“이 답을 어디까지 믿어도 될까?”, “이 구조를 서비스에 넣으면 어떤 문제가 생길까?”,

“실무에서는 어떤 기준으로 품질을 판단할까?” 같은 질문이 계속 남는다.

게다가 그 편안함에 기술적 부채라는 문제도 있다.

"과연 AI가 제공해준 이 결과물이 문제를 일으키면 내가 바로 고칠 수 있을까?"

그래서 『주니어 AI 엔지니어가 반드시 알아야 할 실무 지식』이라는 제목이 눈에 들어왔다.

내가 주니어 AI 엔지니어는 아니지만, AI 시스템을 실무적으로 이해한다는 관점에서는 배울 것이 많아 보였다.

약 2주 동안 읽으면서 이 책은 AI를 처음 써보는 입문서라기보다,

AI를 실제 서비스로 가져가려는 사람이 한 번쯤 짚고 넘어가야 할 기준을 정리한 책에 가깝다고 느꼈다.

책을 읽으며

이 책을 읽으면서 가장 크게 남은 것은 “AI 시스템은 정상처럼 보이면서 실패할 수 있다”는 것 이었다.

일반적인 프로그램은 오류가 나면 비교적 명확하게 드러나는 경우가 많다.

크래시가 나거나, 예외가 발생하거나, 결과값이 완전히 이상하게 나온다.

하지만 AI 시스템의 실패는 더 애매하다.

답변은 자연스럽고 문장도 그럴듯한데, 실제 내용은 틀릴 수 있다.

검색 기반으로 답했지만 엉뚱한 문서를 참고했을 수도 있고,

사용자의 질문 의도와 다른 방향으로 답했을 수도 있다.

겉으로는 정상 동작처럼 보이기 때문에 오히려 더 위험하다.

이 부분이 개발자로서 꽤 현실적으로 다가왔다.

회사에서 AI를 활용한 업무를 많이 진행하면서 생기는 기술적 부채와

AI가 작성해준 결과를 검증이나 케어를 할 수 없는 사람들의 결과물이

계속해서 쌓이고 있다고 생각이 든다.

책에서 다루는 RAG, 데이터 파이프라인, 시맨틱 드리프트, 평가 같은 개념들은

결국 이 흔들림을 어떻게 발견하고 관리할 것인가와 연결되어 있었다.

단순히 “AI가 답을 잘하게 만들자”가 아니라, “AI가 언제 왜 흔들리는지 관찰하고 통제하자”는 쪽에 더 가깝다.

특히 RAG를 바라보는 관점이 좋았다.

RAG는 요즘 너무 쉽게 붙이는 기능처럼 소비되지만,

실제로는 문서 수집, 분할, 임베딩, 검색, 랭킹, 응답 생성, 평가가 모두 연결된 구조다.

어느 한 곳이 약하면 답변 품질이 바로 흔들릴 수 있다.

이 책은 그런 지점을 실무자의 시선으로 계속 짚어준다.

내 생각은...

오래동안 프로그래머로 일해 왔고 현재 라이브 서비스중인 프로젝트에서 일하고 있다 보니

가장 중요시 하게 되는게, 시스템의 안정성이나 재현성이다.

화면에 이상한 아티팩트가 생기면 단순히 “렌더링이 이상하다”로 끝나지 않는다.

어떤 패스에서 문제가 생겼는지, 리소스 상태가 어떤지, 특정 조건에서만 발생하는지 하나씩 좁혀가야 한다.

AI 시스템도 비슷하게 봐야 한다는 생각이 들었다.

답변이 이상하다고 해서 모델만 탓할 수는 없다.

프롬프트가 문제일 수도 있고, 검색된 문서가 문제일 수도 있고, 데이터 업데이트 주기가 문제일 수도 있다.

혹은 사용자의 질문을 시스템이 잘못 해석했을 수도 있다.

이 책을 읽으면서 AI 엔지니어링은 단순히 모델을 잘 쓰는 일이 아니라는 생각이 더 강해졌다.

모델은 중요한 부품이지만, 실제 서비스에서는 그 앞뒤의 데이터 흐름, 검증 방식, 모니터링, 운영 기준이 함께 있어야 한다.

데모를 만드는 능력과 운영 가능한 시스템을 만드는 능력 사이에는 꽤 큰 간격이 있다.

평소 바이브코딩을 하면서도 비슷한 고민을 한다.

AI가 만들어준 코드는 빠르게 결과를 보여주지만, 내가 구조를 이해하지 못하면 유지보수하기 어렵다.

AI 서비스도 마찬가지다.

처음에는 빠르게 붙일 수 있지만, 운영 단계에서는 결국 사람이 기준을 세워야 한다.

이 책은 그 기준을 어떻게 잡아야 하는지 생각하게 만든다.

좋았던 점 

첫째, AI를 데모가 아니라 운영 관점에서 바라보게 해주는 점이 좋았다.

요즘은 AI 기능을 붙이는 것 자체보다, 붙인 뒤에 안정적으로 유지하는 것이 더 중요해지고 있다.

이 책은 그 차이를 계속 의식하게 만든다.

둘째, 주니어에게 필요한 실무 감각을 넓게 다룬다.

단순히 모델 API 사용법이나 프롬프트 작성법에 머무르지 않고, 데이터 파이프라인,

RAG, 평가, 장애, 운영 같은 주제로 시야를 넓혀준다.

래서 AI 엔지니어가 실제로 무엇을 고민해야 하는지 감을 잡기 좋다.

셋째, “그럴듯한 실패”를 조심하게 만든다.

AI 답변은 틀려도 자연스럽게 보일 수 있다. 이 책은 그 위험을 막연한 경고로만 말하지 않고,

시스템적으로 어떻게 바라봐야 하는지 생각하게 한다.

넷째, 이미 개발 경험이 있는 사람에게도 읽을 거리가 있다.

제목은 주니어 AI 엔지니어를 향하고 있지만, AI를 서비스에 붙이려는 개발자라면

경력과 상관없이 한 번쯤 점검해볼 만한 내용이 많다.

 "한빛미디어 서평단 ＜나는 리뷰어다＞ 활동을 위해서 책을 협찬받아 작성된 서평입니다."

[ 한빛미디어 서평단 '나는 리뷰어다' 활동을 위해서 전자책 을 제공 받아 작성한 도서 리뷰 입니다. ]

- 읽어보니?

저자가 친절하게  어떤 독자가 읽으면 좋을지  대상을 지정해 놓았다.

저자가 지정한 대상 독자를 보면 알 수 있듯이 AI 에이전트를 사용하는 '주니어' 라고 생각되는 개발자들을 위해 실무와 관련된 내용들로 구성되어 있다.

이 책은 실화를 바탕으로 시작하는 서론이 흥미를 더해준다.

 'AI 에이전트는 실수를 할 수 있다.' 라고만 쓰여있던 대부분의 책들과 달리 실제 사례들을 가져와 '이런 일이 있었다.' 라고 이야기를 시작한다. 실제로 AI 에이전트를 활용해 개발을 하면서 AI가 사람이라면 상상도 못 할 멍청한 실수(예를 들어 DB를 고쳐야 한다면서 기존에 생성되어있던 설계를 다 제거해버린다던지...) 를 하는것은 많이 보았지만, 실제 사용자에게 제공하면서 발생하는 일은 겪을 일이 없었다. 대부분은 '개발'에 활용하지 어느정도 규모가 있는 기업에서 사용자 구매를 돕기위해 챗봇을 만들고 학습을 시키진 않기 때문이다.

 실화를 바탕으로 하는 이야기와 더불어 개발자들이 자주 마주치는 난관에 대해서도 이야기한다. 

AI를 전문적으로 누구보다 잘 쓴다고는 말 할 수 없지만, 꽤나 써와본 입장으로써 '누가' 쓰느냐보단, '어떻게' 쓰느냐에 따라 10인분을 할 수도, 1인분을 못 할 수도 있는 것이 AI라고 생각한다.

 이러저러한 시행착오를 겪으며 AI를 써오며 느낀 경험들이 이 책에 잘 녹아들어가 있어 '아, 나 뿐만이 아니라 다른 사람도 그렇구나' 하고 공감을 하고, 해결과정을 바라보는 것 또한 즐겁게 읽을 수 있는 포인트라고 할 수 있다.

 실화를 바탕으로 해결방법을 알아보고 어떻게 해결해야 하는지까지 알아보았다면, 실제로 LLM을 어떻게 구성해야 하는지, 어떤식으로 학습시켜야 하는지 등 시스템 구성쪽의 내용도 전반적으로 살펴본다.

 그리고 학습 시 위험성을 경계해 조심하는것도 중요하지만, 실제 학습된 데이터 자체도 중요하기 때문에 모든것을 너무 보수적으로 보지 말자는 이야기도 나온다.

 처음 이야기 했던 것처럼 책의 구성은 위와같이 총 5장으로 되어있다.

실화를 바탕으로 한 AI에 대한 불만과 문제점들로 공감과 흥미 위주로 읽혔던 1부를 지나, 실제 현업에서 AI가 어떤식으로 문제점을 일으킬 수 있는지에 대한 2부 설명을 통해 3부에서 이런 문제들을 해결하기 위해선 LLM의 작동 원리를 알면 좋다는 내용으로 이어진다. 4장에서는 생성된 LLM 모델을 통해 실제 프로덕션에선 어디에 문제가 생기는가를 활용하여 어떻게 시스템을 설계하면 좋을지를 이야기하고, 5부에선 이를 바탕으로 배포와 운영까지 이어지는 깔끔한 스토리라인을 구축하여 읽는사람이 덜 지루하게, 그리고 재미있고 흥미롭게 볼 수 있도록 구성되어 있다.

크게 5부로 나뉘어 있고 전체적인 스토리라인이 이어져 있기 때문에 저자도 가능하면 순서대로 읽기를 권하지만, 특정 문제를 해결하기 위해 이 책을 찾았다면 위와 같은 내용을 보고 해당 장을 먼저 읽어봐도 좋다고 한다.

- 느낀점은?

 그간 다양한 AI 관련 서적을 읽어오면서 그저 프롬프트만 읊어주던 시기를 지나 이제 진짜 찐 AI 사용자들의 경험담이 들어있는 내용들이 나오는구나 하고 점점 더 좋아지는 내용들에 감동(?)을 느끼고 있다.

 이 책을 왜 이 돈을 주고 사야하지(?) 라는 충족감을 채워 줄 수 있을만한 내용들이 들어가 있지 않는다면, 독자들은 외면할 것이다, 왜냐? AI 딸깍으로 알려달라고 하면 되니까 말이다.

 얼마 전 'AI 토큰 비용 때문에 다시 개발자들 채용이 활발해지고 있다' 라는 이야기를 들었다. 결국 AI 과도기를 지나 미국 AI 3파전으로 굳혀지는듯 하더니, 그록의 눈에 띄는 발전과 제미나이의 눈에 띄는 후퇴, 중국 AI의 눈부신 발전등에 힘 입어 거대한걸 떠나 더욱 효율성을 추구하는 시기로 접어든 모양이다.

 더 싸지고 더 좋아지면 소비자는 좋다. 하지만 이게 언제까지 갈까? 라고 한다면 그건 아무도 예측할 수 없을것이다. 갑자기 지구에서 전기가 사라진다거나 3차 세계대전이 발발해서 AI 발전이 모두 사라져 버린다거나, 갑자기 너무 뜨거워져서 데이터센터가 다 폭발한다거나 하는 재해들이 언제 일어날지 우리는 예측할 수 없기 때문이다.

 개발자들이 살아남는 방법이 'AI를 적극 활용해서 결국 관리자' 라는 방향으로 가는듯 하다가 이제는 'AI를 효율적으로 사용하면서 생각을 하는 사람' 으로 또 방향이 틀어지고 있다.

 AI를 직원처럼 고용해서 전부 AI로 무언가를 만들던 회사는 대체 무엇을 만들고 무엇을 서비스하고 있는것일까? 내가 아는바에 의하면 AI로 모든 직원을 꾸린 회사가 돈을 벌었다는 이야기를 들은적은 없다. 파산이라도 안했으면 다행이라고 생각한다. 어쩌면 사람과의 관계를 껄끄러워하는 사장님들이 부러워할만한 환상이 아니었을까?

 아무튼, 대 AI 시대가 도래했다가 갑자기 사라질 수도 있는 노릇이지만 우리는 지금 이 시대를 살고 있다. AI가 등장해서 세상에 영향을 끼친지 얼마나 되었는가? 우리는 모두 AI 초보자이고 AI를 탐험하는 탐험가일 뿐이다. 이 책처럼 여러 AI 선구자들의 이야기를 듣고 보고 따라하면서 우리 능력을 기를 수 밖에 없는것이다.

 이 책은 그런면에서 굉장히 친절하다. 새로운 영역에 발을 들일 때 필수 요소 중 하나는 '재미' 라고 생각한다. 실화를 바탕으로 한 흥미를 유발해 어찌 그런 일이 터졌고, 그곳에서의 문제는 무엇이고, 어떻게 해결할 수 있었을까? 하고 생각을 유도한다. 그리고 직접생각해보고 설계해보고 운영해보는 것까지 구성되어있다.

 친절, 재미, 구성 등 모든 요소가 꽉꽉 찬 이런 서적은 한번 쭉 읽어보고, 또 필요한 곳을 골라 읽어보면서 저자의 AI 경험을 나만의 AI 경험으로 녹이는 것도 좋은 일이 아닐까 싶다.

"한빛미디어 서평단 ＜나는 리뷰어다＞ 활동을 위해서 책을 협찬받아 작성된 서평입니다."


AI 데모를 만드는 것과 실제 운영 가능한 AI 시스템을 만드는 것은 완전히 다르기 때문에 AI 프로젝트를 하기 전에 이 책을 한 번 읽어 보시는 것을 추천합니다. 
 
단순히 AI를 만들어보는 것을 넘어, 안정적으로 운영되는 제대로 된 AI 시스템을 만들고 싶다면  꼭 읽어볼 만한 책입니다.

그럼 여러분들의 시행 착오를 확연히 줄여 줄 것입니다.

“한빛미디어 서평단 ＜나는 리뷰어다＞ 활동을 위해서 책을 협찬 받아 작성된 서평입니다.”

현시대는 빅데이터와 딥러닝의 급격한 발전으로 AI가 엄청난 발전을 하였으며 현재까지도 계속 발전을 하고 있어 영화 “터미네이터”의 스카이넷이 현실로 실현될 날이 머지않아 보입니다. 이렇게 발전된 AI는 IT계열에서 뿐만 아니라 사무분야, 논문 작성, 소설 작성, 실시간 강의 정리, 농장 관리 같은 스마트팜 등등 모든 분야에서 사용되고 있는 동반자 같은 존재가 되는 추세이며 특히 IT계열 그 중에서도 프로그램 및 게임 개발에서 매우 편리함을 제공하고 있습니다. AI가 발전하기 전까지의 개발은 자신의 아이디어를 실현하기 위해서 사람이 직접 프로그래밍 언어와 전문 기술을 익혀야 하고 그래픽, 사운드 등 타 분야와의 협업을 필요시 했지만 AI가 발전된 현재는 아이디어만 있으면 누구나 프로그램 개발을 하는 1인 개발자가 될 수 있습니다.

오늘은 이러한 AI를 엔지니어가 실무에서 어떻게 사용해야 하는지에 대해 파이썬을 이용하여 다뤄보겠습니다.

파이썬(Python)이란 인터프리터 방식의 고급 프로그래밍 언어로 간결한 문법과 코드를 컴파일 과정 없이 한 줄씩 즉시 실행하고 결과를 확인할 수 있어 개발 속도가 빨라 전 세계적으로 널리 쓰이고 있습니다.

제가 이 책을 선택한 이유는 이 책의 내용이 AI를 써보는 단계의 내용이 아닌 AI로 실제 서비스를 만드는 사람을 위한 내용을 다루고 있기 때문입니다.

이 책의 특성은 유행을 쫒은 흔한 내용구성이 아닌 데이터가 어떻게 시스템을 망가뜨리는지, 확률적으로 출력을 어떻게 통제하는지, 무엇을 모델에 맡기고 무엇을 코드로 막아야 하는지, 시스템이 조용히 망가지는 것을 어떻게 알아채는지 등의 5년 뒤에도 유효할 내용을 다루고 있습니다.

구성

Part 1: AI 시스템에서 처음으로 착각하게 되는 것들

Chapter 1: 모델은 똑똑한데, 시스템은 왜 바보가 될까?

Chapter 2: AI 시스템 장애의 대부분은 모델 밖에서 시작된다

Part 2: 데이터 파이프라인: 망가지는 건 항상 여기서 시작된다

Chapter 3: 데이터 파이프라인은 단순한 ETL이 아니다

Chapter 4: 데이터는 생각보다 훨씬 쉽게 망가진다

Chapter 5: 잘못된 피드백 루프는 AI 시스템을 천천히 죽인다

Part 3: LLM의 작동 원리를 모르면, 시스템 설꼐도 모른다

Chapter 6: 생성형 AI는 API가 아니라 확률 엔진이다

Chapter 7: 예측 불가능한 모델 위에 안정적인 시스템을 만드는 법

Part 4: 모델을 둘러싼 시스템을 설계하라

Chapter 8: 모델에게 올바른 맥락을 제공하는 기술

Chapter 9: 모델이 외부 세계와 상호작용하는 구조

Chapter 10: 자율적으로 판단하고 행동하는 시스템을 설계하는 법

Part 5: 시스템을 배포하고 운영하라

Chapter 11: AI 시스템은 배포되는 순간부터 비용이 된다

Chapter 12: 감이 아니라 측정으: 평가 주도 개발

Chapter 13: 관측되지 않는 AI 시스템은 이미 실패했다

Chapter 14: AI 엔지니어는 무엇을 다르게 판단해야 하는가?

Appendix A: 현업 AI 엔지니어 인터뷰

Appendix B: 추가 자료

파트별로 나누어 봤을때 책에서 나온 대로 파트1인 1~2장은 데모에서 되던 것이 프로덕션에서는 무너지는지, 모델은 같은 입력에도 다르게 답하는 확률적 시스템이라는 것, 그래서 장애의 대부분은 모델이 아니라 그 바깥에서 시작된다는 것에 대해, 파트2인 3~5장은 코드를 건들지 않았는데도 시스템이 왜 망가지는지, 파이프라인이 단순한 ETL이 아닌 이유, 데이터가 소리 없이 부패하는 경도들, 피드백 루프가 시스템을 천천히죽이는 방식과 반대로 혜자가 되는 방식에 대해, 파트3인 6~7장은 확률 엔진 위에 어떻게 안정성을 쌓는지, 토큰과 샘플링이라는 작동 원리에서 출발해, 파라미터 통제부터 검증 인프라까지 다섯겹의 안정화 레이어를 쌓는 방법에 대해, 파트4인 8~10장은 모델 바깥 설계 방법, 모델에게 올바른 맥락을 제공하는 기술(청킹과 검색), 외부 세계와 상호작용하는 구조(도구), 자율적으로 행동하는 시스템(에이전트), 에이전트를 만들지 않아도 되는 겨우를 먼저 걸러내는 법과 에이전트에게 권한을 주기 전에 능력을 분리하는 법에 대해, 파트5인 11~14장은 배포된 뒤에 시작되는 진짜 문제들, 추론 비용의 구조와 최적화, 감이 아니라 측정으로 개선하는 평가 주도 개발, 조용한 품질 저하를 잡아내는 관측 가능성 그리고 AI엔지니어는 무엇을 다르게 판단해야 하는에 대해 그리고 책끝의 부록에는 여러 분야에서 경험을 쌓아온 AI 엔지니어들의 인터뷰와 본문에서 인용한 논문, 보고서, 사례의 출처에 대해 설명하고 있습니다.

개인적인 생각으로 학습은 주니어 AI 엔지니어, AI 기능을 도입한 개발사, 프로덕션 엔지니어링을 하게 된 데이터 직군, AI를 처음 사용하는 분들은 1장부터, AI 엔지니어(2년차~) 및 AI를 사용하여 업무를 진행하는 기업 담당자, 데이터 직군인 분들께서는 2장부터 학습하시는 것이 좋을 것 같습니다.

개인적으로 약간의 단점이 어쩌면 욕심일수도 있는게 좀더 많은 실습 예제 및 비즈니스 케이스가 담겨있으면 더 좋았지 않았을까라는 아쉬움이 있습니다.

저의 리뷰를 읽어주셔서 감사합니다. 다음에는 좀더 유용하고 좋은 책으로 더 나은 리뷰를 통해 여러분께 책을 소개시켜 드릴 수 있도록 더 노력하겠습니다.

감사합니다.

“한빛미디어 서평단 ＜나는리뷰어다＞ 활동을 위해서 책을 협찬받아 작성된 서평입니다.”

LLM의 불확실성은 없애는 문제가 아니라 통제하는 문제라고 말한다. 할루시네이션, 시맨틱 드리프트, 피드백 루프처럼 데모에서는 잘 보이지 않던 실패 지점을 구체적으로 짚어 준다. LLM 기능을 하나라도 배포해 본 개발자라면 크게 공감할 내용들이 많다.

빠르게 변하는 기술 앞에서 흔들리지 않고자 한다면, 이 책에서 제시하는 변하지 않는 중요한 원칙을 훑어보자.

#한빛미디어 #나는리뷰어다 #주니어AI엔지니어가반드시알아야할실무지식

“한빛미디어 서평단 ＜나는리뷰어다＞ 활동을 위해서 책을 협찬받아 작성된 서평입니다.”

나는 개발자가 아니다. 그저 AI라는 분야에 관심이 많은 입문자에 가깝다. 그런데도 이 책을 끝까지 읽은 건, 제목 그대로 '반드시 알아야 할 지식'이라면 나 같은 사람도 알아둬서 나쁠 게 없겠다 싶었기 때문이다. 한빛미디어 서평단에 신청해서 받은 책으로 신청할 때 목차만 훑어봐도 어렵겠다는 느낌은 있었는데, 요즘 여기저기서 AI 에이전트니 RAG니 하는 말들이 쏟아지길래 이참에 제대로 알아보자는 마음으로 펼쳤다. 읽기는 했지만, 당연히... 모든 챕터를 다 이해지는 못했다.

모델은 똑똑한데 시스템은 왜 바보가 될까

그동안 막연히 'AI가 가끔 엉뚱한 답을 한다더라' 정도로만 알고 있었는데, 왜 그런지를 구조적으로 짚어주는 첫 챕터에서 이해도가 깊어진 느낌이다. 전통적인 소프트웨어는 같은 입력에는 같은 결과가 나오는 결정론적 시스템이고, AI는 같은 질문에도 매번 조금씩 다른 답이 나오는 확률론적 시스템이라고 구분해서 설명한다. 말로만 들으면 당연한 소리 같은데, 이 차이 하나가 이후 모든 챕터의 전제로 계속 깔린다는 걸 읽으면서 알게 됐다.

성능 지표는 멀쩡한데 서비스는 이미 망가져 있을 수 있다는 대목도 흥미로웠다. 응답 속도도 정상, 에러율도 정상인데 정작 사용자가 받은 답이 엉뚱한 경우를 침묵하는 장애라고 부르는 것이 납득이 갔다. 이 부분은 비전공자가 읽어도 무리 없이 따라갈 수 있는, 책 전체에서 가장 친절한 구간이었던 것 같다.

진짜 사고는 데이터 파이프라인에서 난다

2부부터는 솔직히 조금씩 벅차지기 시작했다. ETL이라는 단어부터 이 책에서 제대로 처음 접했는데, 데이터를 모으고 가공하는 과정이라는 정도는 이해했지만 구체적으로 어떤 작업인지까지는 잘 그려지지 않았다. 그래도 데이터가 생각보다 훨씬 쉽게 망가진다는 이야기, 잘못된 피드백 루프가 시스템을 서서히 무너뜨린다는 이야기의 큰 줄기만큼은 어렵지 않게 따라갈 수 있었다.

RAG와 에이전트, 어렴풋이나마 알게 된 것들

3부와 4부는 이 책에서 가장 기대하고 펼친 부분이다. 뉴스나 SNS에서 RAG니 에이전트니 하는 단어를 하도 많이 봐서 이번 기회에 궁금증을 해소하고 싶었다. 생성형 AI를 API가 아니라 확률 엔진으로 다시 정의하고, 그 위에 맥락을 어떻게 설계해서 얹느냐가 RAG의 핵심이라는 설명까지는 따라갈 수 있었다. 벡터 검색 같은 세부 기술 이야기로 들어가면 다시 아득해졌지만, 적어도 'RAG가 왜 필요한가'라는 질문에는 예전보다 훨씬 또렷하게 답할 수 있게 됐다.

에이전트 설계 부분은 읽는 재미가 가장 컸다. 모델에게 도구를 쥐여주고 알아서 판단하게 두는 방식이 매력적으로 들리지만, 통제되지 않은 자율성은 결국 예측할 수 없는 위험으로 되돌아온다는 경고가 여러 번 반복된다. 화려해 보이는 에이전트와 실제 서비스에 올려도 되는 에이전트 사이의 거리가 생각보다 멀다는 걸, 이 챕터를 읽고 나서야 어렴풋이 실감했다.

배포 이후: 나에게는 가장 어려웠던 구간

5부는 비용 최적화, 평가, 관측 가능성까지 이어지는 운영 파트인데, 솔직히 여기서부터는 절반 정도는 흘려보내듯 읽었다. 구체적인 지표나 도구 이야기가 나오면 용어 자체가 낯설어서 속도가 잘 안 났다. 그나마 부록으로 실린 현업 AI 엔지니어 네 명의 인터뷰는 반가웠다. 이론으로만 읽었던 이야기들을 실제 사람의 목소리로 다시 들으니, 앞서 어렵게 읽은 챕터들도 책 속 이야기만은 아니었구나 싶은 확인을 받는 기분이었다.

이런 사람에게 맞을 것 같다

정리하자면, 이 책이 진짜로 도움이 될 사람은 나 같은 입문자가 아니라 제목처럼 1~3년 차 AI 엔지니어일 것 같다. 코드를 다뤄본 적 없는 완전 입문 자라면 좀 과장해서 각오하고 펼쳐야 하는 책이지만, 그래도 뜻을 짐작하며 읽은 대목이 많았어도 남는것도 있었다. 적어도 AI가 왜 예측 불가능하고, 그 위에 어떤 고민들을 쌓아야 서비스가 안정적으로 돌아가는지에 대한 큰 그림 하나는 얻어 간 것 같다. RAG와 에이전트라는 단어를 이제는 뉴스에서 봐도 예전만큼 막막하진 않겠다 싶은데, 이 정도면 비전공자 입장에서는 나쁘지 않은 결과라 생각된다.