예스 24 리뷰어클럽 서평단 자격으로 도서를 제공받고 작성한 리뷰입니다.

 최근 AI가 발전하면서 많은 사람이 AI를 이용해서 실무에 큰 도움을 받고 있다. AI를 시켜야만 움직이지 않고 내가 원하는 행동을 스스로 실행하도록 만드는 루프와 하네스를 이 책에서는 다루고 있다. 단순하게 루프의 설계 방식을 알려주는 것이 아니라 루프와 하네스의 연결, 그리고 그 방식을 만들면서 생길 수 있는 문제점이나 놓치기 쉬운 취약점을 자세히 알려주는 책이다. 

 AI는 의도한 것 그대로 작동하지 않는다. 사람의 명령은 AI가 받아들이기엔 다소 모호하고 간략한 부분이 있을 수 있다. 그런 모호한 부분을 AI는 자신의 상상력으로 덮어서 결과물을 만든다. 그리고 그런 결과물을 아무 검증 없이 실행했다가 문제가 생기면 책임은 사람이 지게 된다. 

 AI를 처음 시작하는 사람들에겐 이 부분이 생각보다 어렵게 다가온다. 이 책은 그런 AI와 인간 사이의 소통에서 생기는 문제점이나 집중해야 할 부분을 자세하게 설명해 준다. AI로 생산적인 루프를 만들기 시작하는 사람들에게 추천해 주고 싶은 책이다.

#리뷰어클럽리뷰

"예스24 리뷰어클럽 서평단 자격으로 도서를 제공받고 작성한 리뷰입니다."

책제목  : AI루프를 설계하라

저자 : 신상윤

출판년도 : 2026.10.05

AI가 만든 코드를 어디까지 믿어도 될까?

한 줄 결론

AI로 앱과 서비스를 만들고 있지만, 작업 완료 보고를 받아도 출시하기 전에는

마음이 놓이지 않는 개발자에게 추천하고 싶은 책이다.

읽게 된 이유

20년째 프로그래머로 살아가고 있다.

요즘은 개인적으로 앱을 개발하면서 AI와 함께 작업하는 시간도 많아졌다.

만들고 싶은 기능을 설명하면 코드가 나오고, 오류를 전달하면 수정안이 돌아온다. 이 속도에는 아직도 종종 놀란다.

그런데 개발이 빨라졌다고 해서 확인할 일까지 줄어드는 것은 아니었다.

빌드는 성공했고 테스트도 통과했다는데, 실제 휴대폰에서 실행해 보면 글자가 잘리거나

이전 화면으로 돌아가는 동선이 어색한 경우가 있었다.

기능 하나를 고친 뒤에는 원래 잘되던 부분도 다시 살펴봐야 했다.

AI가 일을 많이 해주는 것은 분명한데, 마지막에 남는 질문은 여전히 내 몫이었다.

이 정도면 정말 끝났다고 해도 되는지, 내가 놓친 조건은 없는지.

『AI 루프를 설계하라』를 집어 든 이유도 여기에 있다.

약 일주일 동안 책을 읽으며, AI에게 일을 맡기면서 느끼던 이 불안감을 어떻게 다뤄야 할지 계속 생각했다.

책을 읽으며...

책을 시작부분부터 내가 느꼇지만 애서 회피하고 싶었던 내용이 나왔다.

"10년 뒤, 박물관에 전시될 두꺼운 문법책"

아직 기억하고 있다.

20대에 "c++ 기초 플러스"와 c++관련 책들을 항상 들고다니며 보고 외우고 

손에 익게 하려고 항상 따라 연습하며 이해하려 노력했던 시간들.

그 두꺼운 책들을 들고다니느라 힘들었었다.

그 노력이 박물관에 전시될 만큼 옛날일이 된다는 것에...

반박하고싶지만 반박할 수 없음이 속상하다.

"코드는 의도의 손실 압축이다"

이 문장이 이 책의 시작점이지 않을까.

이젠 코드의 문제가 아니라 내 의도를 가장 충실하게 구현해 낼 수 있는 방법을

고민해야 할 때라는 것.

내가 당연하게 생각한 조건을 AI는 모른다

먼저 눈에 들어온 것은 명세에서 빠진 조건을 다루는 부분이었다.

책에는 현금을 결제하지 않은 포인트 주문이 외부 결제사의 취소 경로로 처리된 사례가 등장한다.

저자는 이런 문제를 막기 위해 동작의 조건과 입력, 기대 결과를 구체적으로 나누고,

Gherkin 형식으로 실행해서는 안 되는 경로까지 명시하는 방법을 설명한다.

여기서 나는 평소 AI에게 전달하던 요청들을 떠올렸다.

기능을 설명할 때 머릿속에는 완성된 모습이 있는데, 막상 글로 적으면 그중 일부만 전달하는 경우가 많다.

나에게 너무 당연한 조건일수록 설명에서 빠지기 쉽다.

내가 만드는 기록 앱으로 옮겨 생각하면 이해가 빨랐다.

“기록을 수정할 수 있게 해줘”라는 말에는 취소했을 때 원래 내용이 유지되어야 한다는 조건도,

저장 버튼을 여러 번 눌러도 기록이 중복으로 생기면 안 된다는 조건도 들어 있지 않다.

화면에 수정 버튼이 생겼다고 해서 내가 생각한 기능이 전부 구현된 것은 아니다.

이 부분을 읽으며 프롬프트의 길이에 기대고 있었던 것은 아닌지 돌아보게 됐다.

설명을 길게 적으면 충분히 전달했다고 느끼기 쉽다. 하지만 실제로 필요한 것은 빠진 조건을 찾아내고,

지켜야 할 동작을 확인할 수 있게 쓰는 일이었다.

‘완료’라는 보고가 무엇을 확인한 것인지

배포 명령은 성공했는데 실제 배포 폴더에는 이전 파일이 남아 있던 사례도 기억에 남았다.

에이전트는 명령이 정상 종료됐다는 이유로 다음 테스트를 진행했고, 옛 파일에서 발생한 실패를 새 코드의 문제로 받아들였다.

저자는 빌드 산출물과 배포된 파일의 해시를 대조해, 실제로 파일이 바뀌었는지를 확인하도록 과정을 보완한다.

명령이 성공했다는 사실 자체는 틀리지 않았다.

다만 그 사실만으로 다음 작업을 시작하기에는 확인이 부족했던 것이다.

이 대목이 특히 현실적으로 느껴졌다.

AI와 개발하다 보면 작업 결과를 요약한 보고를 자주 받는다.

빌드 성공, 테스트 통과, 수정 완료. 바쁘게 작업을 이어가다 보면 나도 그 단어들부터 확인하게 된다.

하지만 어떤 코드로 빌드했는지, 무엇을 대상으로 테스트했는지,

그 결과가 이번 실행에서 나온 것인지까지 연결되어야 보고를 믿을 수 있다.

내가 확인해야 할 질문이 조금 더 구체적으로 정리되는 느낌이었다.

어디에서 작업을 멈출지도 설계해야 한다

제목에 등장하는 ‘루프’도 읽기 전보다 구체적으로 다가왔다.

책은 명세와 테스트, 실행 기록, 회귀 검증을 연결한다.

실제로 어느 경로가 실행됐는지 확인하고, 수정한 기능과 기존 동작이 함께 기준을 만족하는지

검사한 뒤 다음 단계로 넘어가는 구조다.

나는 책에서 말하는 하네스를 AI가 작업하는 동안 따라야 할 검증 환경으로 이해했다.

무엇을 만들지뿐 아니라, 무엇을 근거로 통과시킬지, 문제가 발견되면 어디에서 진행을 막을지도 그 환경 안에 들어간다.

개인 개발을 하다 보면 AI가 조금 더 알아서 진행해 줬으면 싶다.

사소한 것까지 계속 확인하면 흐름이 끊기기 때문이다.

그렇다고 잘못된 전제를 붙잡은 채 수정을 반복하게 두는 것도 곤란하다.

그래서 이 부분은 꽤 실용적인 고민으로 남았다.

계속 진행해도 되는 작업의 범위와, 증거를 다시 확인해야 하는 상황을 미리 정해 두는 것.

그래야 작업을 맡긴 뒤에도 매 순간 화면을 지켜보지 않을 수 있겠다는 생각이 들었다.

내 일이나 생각과 연결된 부분

오래 개발한 사람 입장에서는 기존 코드에 숨어 있는 규칙을 다루는 부분에도 자연스럽게 눈이 갔다.

책은 운영자의 기억이나 오래된 장애 기록에 남아 있는 규칙을 명세와 테스트에 연결해야 한다고 설명한다.

코드에 드러나지 않은 맥락까지 다음 변경에서 확인할 수 있도록 남기자는 이야기다.

오래된 코드를 보면 지금 기준으로는 이해하기 어려운 조건문이 있다.

당장 보기에는 불필요해도 특정 환경의 문제를 피하려고 남겨둔 처리일 수 있다.

그런 이유를 모른 채 코드를 정리하면, 모양은 좋아졌는데 제품은 이전보다 불안해지는 일이 생길 수 있다.

AI에게 수정을 맡길 때도 내가 알고 있는 사정을 어디까지 전달했는지 생각해야 한다.

“기존 기능은 유지해줘”라고 말하는 것만으로는 무엇을 유지해야 하는지 충분히 정해지지 않는다.

결국 오래 일하며 쌓은 경험을 검증 가능한 규칙으로 옮기는 일이 필요하다는 생각으로 이어졌다.

의외로 오래 남은 부분은 에필로그였다.

저자는 자신이 만든 개발 루프가 점점 잘 돌아가고 AI가 검증까지 통과하자,

자신의 역할에 무력감을 느꼈다고 털어놓는다.

자동화를 잘해 놓고도 마음이 편하지만은 않았다는 이야기가 솔직하게 다가왔다.

20년 동안 개발해 온 입장에서 쉽게 지나칠 수 없는 대목이었다.

AI가 만드는 결과를 보며 감탄하다가도, 앞으로 내 경험을 어디에 써야 할지 생각하게 된다.

책의 끝에서는 시스템이 실패하는 방식과 테스트의 한계, 레거시의 숨은 맥락을 이해하는 일이 여전히 필요하다고 말한다.

나는 이 부분을 읽으며 앞으로 공부할 방향을 조금 더 구체적으로 생각할 수 있었다.

코드를 알아보는 눈에 더해, 그 코드가 올바르게 동작했다고 판단할 근거를 설계하는 능력도 키워야겠다고.

좋았던 점 

첫째, AI와 개발하면서 느끼던 불안을 구체적으로 짚어준다.

작업은 끝났다는데 마음이 놓이지 않는 이유를 막연하게만 생각하고 있었다.

책의 사례를 따라가다 보면 내가 확인하지 못한 조건이나 증거가 무엇인지 생각하게 된다.

이미 AI로 무언가를 만들어 본 사람에게 더 잘 와닿을 내용이다.

둘째, 익숙한 개발 원칙을 지금의 작업 방식에 다시 연결해 준다.

명세나 테스트 자체가 처음 보는 개념은 아니다.

그런데 AI에게 구현을 맡기는 흐름 안에서 바라보니, 평소 뒤로 미뤘던 작업들의 필요성이 더 선명해졌다.

알고 있는 원칙을 실제 작업 순서에 어떻게 놓고 있었는지 돌아보게 한다.

셋째, 내 프로젝트를 점검할 단서가 있다.

Engineering Note와 설계 체크리스트, 현장용 프롬프트 예시가 함께 제시된다.

읽은 내용을 내 작업에 대입해 보고 싶은 독자에게 이런 장치는 유용하다.

내게도 당장 개발 지침에서 빠진 항목을 찾아보는 출발점이 될 만했다.

좀 더 하고싶은 말

이 책은 특히나 공감이 많이 가는 책이었다.

비슷한 기간동안 프로그래머로 일해온 저자가 AI를 활용하면서 느끼는 생각과 감정도

어느정도 녹아있어서 공감이 많이 가는 책이었다.

회사에서, 그리고 집에서 끊임없이 AI를 통해 개발을 진행하면서 느끼는 감정은 딱 두가지 였다.

어떻게 하면 좀 더 AI를 잘 활용할 수 있을까?

그리고 AI를 잘 활용하려고 하면 할 수록, 내가 필요할까? 라는 생각이 들었다.

원칙에 공감하는 것과 내 프로젝트에 적절한 규모로 적용하는 것 사이에는 여전히 거리가 있다.

혼자 앱을 개발하는 입장에서는 검증 환경을 얼마나 만들어야 하는지,

그 환경을 유지하는 데 어느 정도 시간을 써야 하는지가 현실적인 고민으로 남았다.

모든 기능에 같은 수준의 검증을 붙이려 하면 준비만 하다가 지칠 수도 있다.

나 같으면 먼저 사용자의 기록이 바뀌거나 사라질 수 있는 기능,

한 번 수정했는데 비슷한 문제가 반복됐던 부분부터 적용 범위를 정할 것 같다.

또한 책을 읽으며 “테스트를 더 많이 만들어야겠다” 정도로만 정리하면 아쉬울 듯하다.

테스트가 무엇을 확인하는지, 어떤 상황은 여전히 놓치고 있는지까지 생각해야 이 책의 문제의식이 내 작업으로 이어진다.

최근에 겪은 오류 하나를 떠올리면서 읽으면 좋겠다.

당시 무엇을 요구했고, 어떤 결과를 보고 해결됐다고 판단했는지 되짚어 보는 것이다.

그러면 책의 설명이 내 개발 과정을 돌아보는 질문으로 바뀐다.

"예스24 리뷰어클럽 서평단 자격으로 도서를 제공받고 작성한 리뷰입니다."

'예스24 리뷰어클럽 서평단 자격으로 도서를 제공받고 작성한 리뷰입니다.'

전에 리뷰어클럽을 통해 읽은 책 중에 나노벤처라는 도서를 읽은 적이 있다. 그 책에서의 교훈 중 하나가 러닝루프를 만들어두라는 것이었다. 나도 러닝루프에 대한 중요성을 깨달았지만 러닝루프를 어떻게 만들고 쌓고 활용하는지에 대해서는 그때까지는 제대로 알지 못했다. 그리고 얼마 뒤 지금의 책인 'AI 루프를 설계하라'를 읽게 되었다.

책이 얇은 편이나 여러가지 상황에 대한 답을 주는 책이다. 소제목이 나에게는 다소 추상적이나 내용은 자세하고 구체적이며 친절하다. AI 루프를 만드는 과정에서 겪는 문제점들과 해서는 안되는 일 그리고 체계를 만들 때 잊지 않아야 할 일들을 거의 모두 담아놓은 것이 아닐까싶다.

AI로 러닝루프를 만들고 싶으나 막막하다면 혹은 만들었으나 제대로 활용하지 못하는 사람이라면 이 책을 두고 도움을 받으면 되겠다.

#리뷰어클럽리뷰

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

『AI 루프를 설계하라』는 두께만 보고 가볍게 펼쳤다가 생각보다 오래 붙잡고 있게 된 책이다. 184쪽이라 금방 넘기겠거니 했는데, 한 장을 넘길 때마다 지금까지 AI에게 일을 맡겨온 방식을 되짚게 되어 좀처럼 속도가 나지 않았다. 다 읽고 나서 남은 건 기법 몇 가지라기보다 AI가 내놓은 결과를 대하는 태도 자체가 달라졌다는 감각이다. AI가 "다 됐다"라고 말한 결과를 그대로 믿어도 되는지 한 번이라도 의심해 본 사람이라면 읽어볼 만한 책이라 생각된다.

이번에도 서평단으로 선정되어 받은 책이고, 끝까지 완독했다. 먼저 밝혀두자면 나는 개발자가 아니다. 화면을 만드는 웹퍼블리셔로 일하면서 요즘은 AI 도구에 작업을 맡기고 그 결과를 받아 쓰는 일이 일상이 된 정도. 물론 업무의 경계가 많이 허물어지고 있다는 것을 체감하고 있다. 단지, 개발자를 위해 쓰인 책을 내 입장에서 어디까지 따라갈 수 있을지 반신반의하며 펼쳤는데, 의외로 남 얘기처럼 읽히지 않는 대목이 많았다.

코드는 원본이 아니다, AI 시대의 진짜 원본은 명세

책을 소개하는 문구 중에 "AI는 감옥에 가지 않는다"는 한 줄이 있다. AI는 고객에게 사과하지도, 장애 보고서를 쓰지도 않으니 결과에 대한 책임은 결국 사람에게 남는다는 뜻이다. 이 책은 AI를 더 잘 쓰는 요령을 알려주는 대신, AI가 만든 결과를 사람이 책임질 수 있게 만드는 구조를 다룬다고 스스로 선을 긋고 시작한다. 그 출발점이 첫 장의 제목인 "코드는 원본이 아니다"인데, 코드는 얼마든지 다시 뽑아낼 수 있을 만큼 싸졌지만 그 코드가 맞는지 검증하는 일은 오히려 비싸졌다는 진단이다. 그렇다면 지켜야 할 원본은 코드가 아니라 무엇을 만들려 했는지를 적은 의도, 즉 명세(specification)라는 이야기로 이어진다.

두 번째 장 제목은 "빈칸을 주면 AI는 소설을 쓴다"이다. 무상으로 지급한 포인트로만 결제한 주문이 현금 환불 경로를 타 버린 사례가 나오는데, 문제는 코드가 아니라 명세에 금지 조건이 빠져 있었다는 데 있었다. AI는 명세되지 않은 조건을 멈춰서 되묻기보다 그럴듯한 기본값으로 채워 넣는다. 그래서 기능을 전제 조건·행위·결과로 쪼개고, 거킨(Gherkin)의 Given-When-Then 문법으로 시나리오를 쓰되 결과를 적는 Then 절에 "하지 말아야 할 것"까지 명시하라고 권한다. 프롬프트를 길게 쓰면 할 말을 다 했다고 여기기 쉬운데, 긴 프롬프트가 오히려 조건을 다 적었다는 착각을 준다는 지적에서는 뜨끔했다. 길게 쓰는 것과 빠짐없이 쓰는 것은 전혀 다른 일이었다.

테스트를 통과했다고 성공한 게 아니다, 껍데기 성공과 실행 트레이스

세 번째 장은 "코드를 읽지 말고 증거로 심문하라"는 제목처럼 검증 이야기다. 콘크리트를 다 굳힌 뒤에 거푸집을 대는 건 누가 봐도 우스꽝스러운데, AI에게 먼저 코드를 짜게 하고 돌아가는지 본 다음에야 테스트를 만드는 방식이 바로 그 순서라는 비유가 와닿았다. 테스트를 먼저 세워 AI가 넘지 말아야 할 경계를 정해두라는 것이 이 장의 출발점이다.

가장 오래 머문 개념은 '껍데기 성공'이었다. 명령이 오류 없이 끝났다는 신호와 시스템이 실제로 바뀌었다는 증거는 별개라는 것. 파일을 복사하는 명령이 정상 종료됐다고 해서 파일이 정말 새것으로 교체됐다는 보장은 없고, 결과 파일이 존재한다고 해서 그 파일이 이번 실행에서 만들어졌다는 보장도 없다. 사람이 읽기 좋게 남긴 텍스트 로그는 기록되지 않은 사건을 증명하지 못하니, 어떤 함수가 언제 시작해서 어떻게 끝났는지를 구조화한 실행 트레이스(execution trace)로 남겨 AI가 추론이 아닌 기록으로 대조하게 만들라고 한다.

솔직히 이 대목에서 가장 많이 고개를 끄덕였다. AI에게 일을 맡기면 완료되었다는 보고가 올라오고 겉으로는 그럭저럭 동작하는 것 같은데, 막상 들여다보면 계산이 틀려 있거나 기대했던 만큼 세밀하게 제어되지 않는 경우가 간혹 생긴다. 그걸 바로잡다 보면 빨리 끝났겠거니 했던 일이 오히려 시간을 더 잡아먹는 경우가 꽤 있었다. 분명히 편해지긴 했는데 편해지지 않았다고 해야 할 것 같은, 묘한 상황이랄까. 여기저기서 들었던 이야기처럼 부하 직원에게 맡긴 업무를 검토하던 시간이 AI가 한 일을 검토하는 시간으로 바뀌었을 뿐, 결과를 검토하는 데 시간을 따로 떼어 써야 한다는 사실은 변함이 없었다. 증거로 심문하라는 말이 그 검토를 매번 사람 눈에만 맡기지 말고 구조로 만들어 두라는 이야기로 읽혔다.

하네스와 회귀 게이트, 증거가 없으면 멈추는 루프

네 번째 장과 다섯 번째 장이 책 제목의 '루프'를 본격적으로 다룬다. 여기서 말하는 하네스(harness)는 AI를 감싸 루프를 지탱하고, 결함이 고객에게 닿기 전에 루프를 멈춰 세우는 검증 구조에 가깝다. 핵심 장치는 회귀 게이트(regression gate)인데, 새로 추가한 테스트가 새 빈틈을 막는다면 회귀 게이트는 이미 지켜오던 보장이 깨지지 않았는지를 배포 전에 확인하는 역할이다. AI가 코드를 빨리 만들수록 사람이 할 일은 일일이 손으로 다시 확인하는 쪽에서 게이트를 설계하는 쪽으로 옮겨 간다는 설명이 인상 깊었다. 빨라진 속도가 그대로 결함이 퍼지는 속도가 될 수도 있다는 말이니까.

다섯 번째 장은 이 루프를 v0에서 v3까지 단계적으로 키워 나가는 구성이다. 그중 반복해서 뜨는 승인 창을 없애려고 권한을 열어줬다가 예상하지 못한 동작이 무인으로 실행되어 버린 사례는 AI 에이전트를 쓰는 사람이라면 한 번쯤 곱씹어볼 만한 이야기라 생각된다. 실행 권한을 주는 것과 판단까지 맡기는 것은 다른 문제이고, 루프에는 달리는 단계만큼이나 멈추는 조건과 사람이 승인하는 경계가 필요하다는 것. 끝까지 달리는 루프보다 증거가 없으면 멈추는 루프가 좋은 루프라는 관점이 이 책 전체를 관통하는 메시지인 것 같다.

장마다 엔지니어링 노트와 설계 체크리스트, 현장에서 바로 쓸 수 있는 프롬프트 예시가 붙어 있어 읽고 끝나지 않게 만든 점도 좋았다. 개념만 던지고 마는 책이었다면 실무에 써먹을 생각까지는 못 했을 텐데, 체크리스트를 따라가다 보면 내 작업 흐름의 어디에 멈춤 장치를 두면 좋을지 자연스럽게 그려진다.

책을 덮고 나서는 반복 작업을 어떻게 정리하는 게 좋을지 고민하는 시간이 늘었다. 지금 하고 있는 작업의 앞과 뒤에 무엇을 어떤 순서로 규칙적으로 늘어놓아야 하는지, 어떤 지시를 얼마나 자세하게 전달해야 하는지를 계속 생각하게 된다. 예전에는 일을 던져 놓고 결과가 나오기만 기다렸다면, 이제는 그 일이 어디서 시작해서 어디서 멈춰야 하는지부터 그려 보게 되었달까. 루프를 설계하라는 제목이 무슨 뜻인지 조금은 알 것 같다.

테스트 없는 레거시에 AI를 풀지 마라

마지막 장은 테스트도 명세도 없는 오래된 시스템에 AI를 붙여야 할 때의 이야기다. 인상적이었던 건 명백히 이상해 보이는 값이라도 일단 현재 동작을 기준선(baseline)으로 기록해 두라는 조언이었다. 이상한 값을 바로 고치고 싶은 마음이 들 법한데, 그 값에 기대어 돌아가는 무언가가 있을지 모르니 지금 시스템이 실제로 하는 일부터 남겨두라는 것. 그다음 절개선(seam)을 찾아 테스트 하네스를 걸고, 사람만 알고 있던 규칙을 AI가 넘지 못할 가드레일로 바꿔 나가는 순서로 정리된다.

테스트 함수 이름을 한글로 써도 된다, 오히려 더 낫다는 조언도 재미있었다. 테스트가 실패해 빨간불이 떴을 때 어떤 규칙이 깨졌는지 이름만 보고 바로 읽히게 하자는 이유인데, 사소해 보여도 현장 감각이 묻어나는 팁이었다. 명세가 없는 레거시에서 질문만으로 명세를 복원하는 오픈소스 도구 Q2 Spec까지 함께 공개했다고 하니, 이 장은 특히 레거시를 떠안은 개발자에게 반가울 듯하다.

184쪽인데 왜 이렇게 오래 걸렸을까, 아쉬운 점

확실히 얇은 책인데 쉬어가는 페이지가 거의 없다. 장마다 실제로 터진 사고에서 출발해 원인을 거꾸로 짚고 처방을 내놓는 구조가 촘촘하게 압축되어 있어서, 한 장을 읽고 나면 잠깐 덮고 생각을 정리할 시간이 필요했다. 분량 대비 밀도로 따지면 책값은 충분히 하지 않을까 싶다.

다만 한계도 분명하다. 분류상으로는 초급으로 표시되어 있지만 실제 내용은 CI, PR 리뷰, 소프트웨어 개발 생명주기(SDLC) 같은 개발 실무 용어를 당연한 전제로 깔고 간다. 개발 경험이 전혀 없는 사람이 첫 AI 책으로 집어 들기에는 문턱이 꽤 높게 느껴질 것 같다. 사례도 정산, 물류, 설치와 배포처럼 백엔드나 엔터프라이즈 쪽에 몰려 있어서 화면 쪽 일을 하는 사람이 자기 작업에 그대로 대입하려면 한 번 더 번역하는 과정이 필요하다. 그리고 책이 스스로 밝히듯 AI를 더 잘 쓰는 요령이나 프롬프트 기술을 기대하고 펼친다면 결이 전혀 다른 책이라 실망할 수도 있겠다.

『AI 루프를 설계하라』는 누구에게 맞는 책일까

『AI 루프를 설계하라』는 AI가 만든 결과물을 승인하고 그 결과에 책임을 져야 하는 개발자와 팀 리드에게 가장 잘 맞는 책이다. 수만 줄짜리 PR 앞에서 무엇을 기준으로 승인해야 할지 막막하거나, 테스트는 통과하는데 운영에서 자꾸 사고가 나는 이유를 찾고 있다면 바로 그 질문에 답하려는 책이라 생각된다. 테스트 없는 레거시에 AI를 붙여야 하는 상황이라면 마지막 장 하나만으로도 본전은 뽑을 듯하다.

나처럼 개발자는 아니지만 AI 도구에 일을 맡기는 게 일상이 된 사람에게도 권하고 싶다. 모든 기법을 그대로 가져다 쓰지는 못하더라도, AI가 "다 했다"고 말할 때 무엇을 증거로 확인해야 하는지, 어디서 멈추게 해야 하는지 묻는 습관 하나는 확실히 남는다. AI가 빨라질수록 사람의 일은 더 많이 만드는 쪽이 아니라 제대로 멈추게 하는 쪽으로 옮겨 가는 것 같다. 얇은 책 한 권이 그 방향을 꽤 선명하게 보여준다.