얼마 전까지 나는 묘한 불편함을 안고 있었다. Claude에게 맡긴 결과물은 대개 기대 이상이었다. 요구한 기능은 돌아갔고, 때로는 내가 직접 짰을 때보다 깔끔하기도 했다. 그런데 정작 그 코드를 들여다보는 일은 쉽지 않았다. 내가 한 줄 한 줄 쓴 코드가 아니니 구조가 머릿속에 들어오지 않았고, 무엇보다 결과물이 쌓여도 내가 성장하고 있다는 감각이 없었다. 프로그램은 늘어나는데 개발자로서의 나는 제자리에 있는 것 같았다.

『AI 루프를 설계하라』는 이 불편함이 어디서 왔는지를 짚어 주었다. 나는 여전히 '코드를 직접 작성하는 것'을 개발자의 본질로 여기고 있었던 것이다.

소스코드의 자리가 옮겨졌다

이 책의 핵심 주장은 단순하지만 꽤 근본적이다. AI가 코드를 작성하는 시대에 진짜 소스코드는 내가 자연어로 쓴 명세이고, 우리가 흔히 코드라고 부르는 것은 그 명세를 구현한 결과물이라는 것이다.

이 관점에서 보면 그동안의 고민은 방향이 조금 어긋나 있었다. 컴파일러가 만든 기계어를 읽지 못한다고 해서 실력이 없다고 느끼는 개발자는 없다. 마찬가지로 AI가 생성한 코드를 처음부터 끝까지 쥐고 있어야만 내 것이 되는 건 아니다. 내가 책임져야 할 것은 무엇을, 왜, 어떤 조건에서 만들어야 하는지를 정확히 정의한 명세이고, 성장도 그 명세를 쓰는 능력에서 일어나야 한다.

그리고 그 명세가 향하는 곳은 결국 사용자다. 코드가 얼마나 우아한지보다 사용자에게 필요한 프로그램이 만들어졌는지가 중요하다는 책의 메시지는, 사실 소프트웨어 공학이 늘 말해 오던 것이기도 하다. 다만 코드를 직접 쓰는 수고가 줄어든 지금, 그 원칙이 비로소 개발자의 일 한가운데로 돌아온 셈이다.

잘 구현되게 만드는 것도 설계다

그렇다고 명세만 잘 쓰면 끝나는 것은 아니다. 책은 AI가 명세를 제대로 구현하도록 만드는 환경, 즉 하네스 엔지니어링을 함께 강조한다. 어떤 맥락을 주고, 어떤 도구를 쥐여 주고, 결과를 어떻게 검증하고 다시 고치게 할지를 설계하는 일이다. 책 제목의 '루프'가 가리키는 것도 여기에 있다고 느꼈다. 한 번 요청하고 결과를 받아 드는 것이 아니라, 명세 → 구현 → 검증 → 수정이 돌아가는 고리 자체를 설계하는 것이 개발자의 새로운 역할이라는 것이다.

이 대목을 읽으며 '내가 쓴 코드가 아니라서 들여다보기 힘들다'는 문제에도 다른 답이 있다는 걸 깨달았다. 모든 줄을 읽어서 신뢰를 얻는 대신, 테스트와 검증 장치를 통해 구현이 명세를 따르고 있음을 확인할 수 있는 구조를 만들면 된다. 코드를 읽는 능력보다 코드를 믿을 수 있게 만드는 능력이 더 중요해진 것이다.

바뀐 질문

책을 덮고 나서 스스로에게 던지는 질문이 달라졌다. 예전에는 "이 코드를 내가 이해하고 있나?"를 물었다면, 이제는 "내 명세는 충분히 정확한가?", “AI가 그 명세를 잘 구현할 수 있는 루프를 만들어 두었나?”, "그래서 이 프로그램은 사용자에게 필요한 것인가?"를 묻게 된다.

AI와 함께 개발하면서 막연한 무력감을 느껴 본 사람이라면 이 책을 권하고 싶다. 코드를 덜 쓰게 되었다고 해서 개발자가 할 일이 줄어든 것이 아니라, 일의 무게 중심이 옮겨 갔을 뿐이라는 것. 그 사실을 받아들이는 것만으로도 AI가 만든 결과물을 바라보는 시선이 꽤 달라진다.

'YES24 리뷰어클럽 서평단 자격으로 작성한 리뷰입니다' 
#리뷰어클럽리뷰

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

예전에 중국 무협영화를 보면 스승의 비전을 조그마한 책자에 초식으로 그려놓은 장면이 있었다. 주인공은 이 책을 보고 무술을 연마하곤 했다. 그림이 정교하거나 묘사가 자세한 것도 아닌데 '어떻게 저런 것을 보고 놀라운 무술을 연마할 수 있을까?'라는 의문을 가진 적이 있었다. 지금 생각하니 주인공은 이미 무술을 오랫동안 수련한 고수였기에, 그런 간결한 그림만 보고도 핵심을 깨달을 수 있었던 게 아닐까 싶다.

《AI 루프를 설계하라》이 책이 바로 그 무협영화의 비전 같은 책이다.

처음 책을 봤을 때는 '컴퓨터 관련 서적치고는 생각보다 두껍지 않네?'라는 생각이 들었다. 예전에 흔히 보던 C++이나 쿠버네티스 두꺼운 전공서 느낌이 아니었다. 하지만 내용을 들여다보니, 부연 설명은 과감히 덜어내고 굵고 짧게 깊은 핵심만 꾹꾹 담아낸 느낌이다. 원래 비전(秘傳)이란 그런 법이니까.

소프트웨어 공학을 접해보지 않은 비전공자가 보기에는 조금 어려울 수도 있겠다는 생각이 든다. 하지만 어느 정도 아키텍처와 엔지니어링을 접해본 사람이라면 필요한 내용을 정확히 짚어주고 있음을 알 수 있다. 버릴 내용이 하나도 없다. 마치 500페이지짜리 책을 추리고 추려서 만든 요약서 같다.

AI덕분에 세상이 바뀌었다.

구현보다는 목적과 설계,  AI 가 제대로 했는지 검증하는 것이 중요한 세상에 살고 있다.

원래 구현에는 아키텍트, 엔지니어, 코더가 있었고 AI등장으로 그 코더가 AI로 대체되었다.

그런데 이 코더가 너무나 순수하고 맥락을 아무것도 모르는 엊그제 입사한 신입사원인 것이 문제다. 어쨌든 코드하나는 빨리 끝내주게 잘 짜는데, 시키는대로 잘 하긴 하는데 영 만족스럽지는 않은 상태의 코드를 계속 만드는 신입사원인 것이다. 나는 알잘딱깔센 신입사원을 원하는데 그게 그렇게 쉬운일이 아니다. 현실은 녹록하지 않다.

'자판기를 원했는데 슬롯머신이 도착했다.'

이 책은 슬롯머신처럼 불확실한 AI에게 매번 같은 의도를 입력했을 때, 정확히 의도에 맞는 결과를 출력하는 '자판기'로 만드는 방법에 대해 이야기한다.

Gherkin 명세, 하네스, 회귀테스트, TDD 등 대규모 엔지니어링에서 쓰이던 많은 도구가 동원된다.

흔히 AI 프롬프트로 빠르게 구현해보고, 내놓은 결함 많은 코드를 수작업으로 고치곤 한다. 하지만 저자는 그러지 말라고 단언한다. AI가 스스로 검증하고 돌아가는 '완전한 루프'를 구현하라는 것이 이 책이 지향하는 핵심 메시지다.

이제 개발의 역할은 운동장에서 직접 공을 차는 선수에 머무르지 않는다. 작전과 명령으로 팀을 움직이는 '감독'이 필요한 순간이다. 감독이 선수만큼 공을 잘 찰 필요는 없으며, 선수의 움직임 하나하나를 전부 지시할 수도 없다. 중요한 것은 시스템과 루프를 완성하고, 이것이 무결하게 작동하도록 지속적으로 개선하는 일이다.

작지만 매우 강력한 책이다. AI를 활용해 더 높은 수준의 시스템을 구현하고자 하는 분들에게 일독을 권한다.

#AI #AI루프를설계하라 #한빛미디어 #신상윤 #검증가능한루프 #책임은나의것 #예스24리뷰어클럽

출판사로부터 책을 제공받아 작성한 솔직한 리뷰입니다.

AI로 바이브 코딩을 하는 게 당연해진 요즘, 누구나 쉽게 코딩을 할 수 있게 되었다. 하지만 여전히 AI에게 방향을 알려줘야 하고, AI가 인간 언어에 담긴 함축적 의미까지 모두 파악하여 일을 처리하지는 못한다. 결국 소프트웨어 공학을 잘 알아야 AI에게도 일을 잘 시킬 수 있다. 이 책은 그 지점을 정확히 지적하면서 우리가 바이브 코딩을 하며 쉽게 놓치는 부분들을 현업 개발자의 눈으로 체계화하여 안내한다.

바이브 코딩이나 특정 생성형 AI와 관련된 책들이 우후죽순 쏟아지고 있다. 그중에는 내용의 깊이가 아쉬운 책도 적지 않은데, 이 책은 핵심을 정확히 짚으면서도 실제 코딩에 바로 적용할 수 있는 실용적인 도서라고 생각한다.

그동안 어설프게 루프 엔지니어링을 해왔던 나에게 이 책은 AI를 활용한 개발 과정에서 무엇을 점검하고 개선해야 하는지 구체적인 답을 주었고, 개인 프로젝트를 개발하는 데도 큰 도움이 되었다. 바이브 코딩에 어느 정도 익숙하지만 자신이 제대로 개발하고 있는지, 작성된 코드가 얼마나 안정적인지 판단하기 어려웠던 사람들이라면 이 책을 통해 AI를 더욱 체계적이고 스마트하게 활용할 수 있을 것이라고 생각한다.

#바이브코딩 #루프엔지니어링 #코딩 #AI

예스24 리뷰어클럽 서평단 자격으로 도서를 제공받고 작성한 리뷰입니다! AI 루프, 하네스로 효율적으로 일하는 방법이 궁금했다. 18년 차 엔터프라이즈/보안 소프트웨어 개발자인 저자의 실무 인사이트와 핵심만 담겨있어서 부담 없이 완독했다. 개발자는 아니지만 내용이 어렵지 않았다.

실무 기반 사례를 보며 AI 루프, 하네스로 AI가 일하는 구조를 설계하는 과정과 흐름을 배울 수 있었다.

AI 시대, 기본기의 중요함을 느끼고 있어서, 서두의 메시지가 기억에 남는다.

“ AI 시대 소프트웨어 공학의 기본기는 더 중요해졌다. ”

“ AI 시대의 개발자는 더 깊게 공부해야 한다 ”

고품질 소프트웨어를 만들기 위해서는 좋은 설계와 위험한 변경을 판단하는 안목이 필요하기 때문이다.

코드 작성은 AI가 더 잘한다.

AI 시대의 엔지니어는 AI가 일할 구조를 설계하고, 결과를 책임지는 사람이다.

책임지려면 판단을 해야 하고, 판단하려면 구조가 있어야 한다.

프로젝트 안에서 AI가 안전하게 작동하도록  루프와 하네스로 개발 프로세스를 설계해야 한다.

루프는 작업의 흐름, 하네스는 그 흐름을 관리하는 시스템이다. 정리하면 아래와 같다.

＜ 루프 ＞

- 실행, 실패 확인, 수정을 반복하는 개발 흐름

- 반복해서 이어지는 문제 해결 흐름

＜ 하네스 ＞

- 루프가 안전하게 작동하도록 입력, 출력, 도구, 로그, 평가 기준, 중단 조건을 하나로 묶은 통제된 실행 환경

＜ 루프와 하네스 설계 ＞

- 명세 구조화: 모호한 요구 사항, 금지 경로를 거킨 시나리오로 작성

- 증거 확보: 명세를 테스트로 바꿔 사전에 결함 확인, 텍스트 로그를 실행 트레이스(기록 대조)로 바꿔 개발 루프의 판단 근거를 남김

- 하네스 구축: SDLC (소프트웨어 개발 생명 주기) 레일, 회귀 게이트(멈출 지점)를 세워, AI가 일할 구조를 설계

- 루프 연결: 증거 패키지로 태스크를 잇고, 멈춤, 승인, 재개를 상태로 설계, 루프와 하네스 개선

- 레거시 통제: 사람만 아는 운영 규칙을 가드레일로 고정

＜ 배운 점 ＞

업무 흐름에 AI를 활용하고 있지만, 루프와 하네스는 아직 구축하지 못했다.

하지만, 이 책을 읽고 일하는 흐름을 고칠 수 있었다.

“코드가 아닌 명세가 자산이다”라는 인사이트를 통해 디자인 산출물을 빨리 만들어내고 보관하는 일보다, 

AI가 좋은 결과를 만들도록  가이드 md 문서를 다듬고 챙기는 것이 더 중요하다는 것을 배웠다.

AI가 정리해 준 내용을 검토하며, 더 좋은 결과물을 만들기 위해 근거를 확인하는 과정도 잊지 않았다.

레거시 통제에서 배운 내용을 떠올리며, 실제 운영 상황에서만 알 수 있는 컨텍스트를 내 머릿속이 아닌,

AI가 안전하게 반영하도록 가이드 md 문서에 업데이트하고 적용했다.

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 리뷰어클럽 서평단 자격으로 도서를 제공받고 작성한 리뷰입니다."

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

『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가 빨라질수록 사람의 일은 더 많이 만드는 쪽이 아니라 제대로 멈추게 하는 쪽으로 옮겨 가는 것 같다. 얇은 책 한 권이 그 방향을 꽤 선명하게 보여준다.

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

AI가 만든 코드를 개발자가 어떻게 검증하고 책임질 것인가에 대한 실무적 해법을 제시하는 책이라 생각합니다. 저자는 테스트와 증거를 통해 경계를 만들며, 반복 가능한 개발 루프 속에서 AI의 안전성을 확보하는 과정을 체계적으로 안내하고 있습니다.

책에서는 ‘명세-테스트-증거-반복’이라는 루프 과정을 통해 AI 코드를 책임지고 관리하는 법을 쉽게 알려줍니다. AI 도구를 쓰면서 ‘내가 만든 코드는 믿을 만한가?’ ‘문제가 있으면 어떻게 찾지?’ 하는 고민이 있는 개발자라면 큰 도움을 받을 수 있을 거예요.

#한빛미디어 #신상윤 #검증가능한루프 #책임은나의것

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

최근 AI를 활용한 개발 방식에 관심이 많아지면서, 단순히 코드를 생성하는 것보다 AI가 만든 결과물을 어떻게 검증하고 관리할 것인지에 대한 고민도 생겼다.

AI에게 코드를 작성해 달라고 요청하면 짧은 시간 안에 꽤 많은 코드를 만들어 준다. 하지만 코드가 생성되었다고 해서 요구사항을 제대로 만족하는 것은 아니고, 빌드가 성공했다고 해서 모든 문제가 해결된 것도 아니다.

특히 기존 프로젝트에 기능을 추가하거나 레거시 코드를 수정하는 경우에는 AI가 알지 못하는 규칙이나 의도하지 않은 동작이 있을 수 있다. 이번에 읽은 『AI 루프를 설계하라』는 이러한 문제를 다룬다. AI를 더 잘 사용하는 방법보다는 AI가 만든 결과물을 검증하고, 사람이 책임질 수 있는 개발 구조를 만드는 방법에 초점을 맞춘 책이다.

https://www.yes24.com/product/goods/196815992

1. 코드는 빨리 만들 수 있지만, 검증은 별개의 문제다

AI를 활용하면서 가장 크게 달라진 부분 중 하나는 코드 작성에 필요한 시간이다. 이전에는 직접 구현해야 했던 작업도 이제는 요구사항을 설명하고 AI가 생성한 코드를 검토하는 방식으로 진행할 수 있다.

하지만 코드 작성 시간이 줄어든다고 개발에 필요한 전체 시간이 같은 비율로 줄어드는 것은 아니다.

생성된 코드가 요구사항에 맞는지 확인해야 하고, 기존 코드에 영향을 주지는 않는지 검토해야 한다. 테스트가 부족하다면 직접 검증 방법부터 만들어야 할 수도 있다.

책에서는 이러한 문제를 여러 사례를 통해 설명한다. 로그 파일은 생성되었지만 실제 요청은 전송되지 않은 경우, 환불이 성공한 것으로 기록되었지만 잘못된 처리 경로를 거친 경우처럼 겉으로 보이는 성공과 실제 동작이 일치하지 않는 상황이다.

이러한 사례를 보면 단순히 테스트가 통과했다는 사실만으로 결과물을 신뢰하기는 어렵다는 것을 알 수 있다.

결국 AI를 활용하는 환경에서는 코드를 얼마나 빠르게 생성하는지만큼이나, 생성된 결과가 올바른지 판단할 수 있는 기준이 중요하다.

2. 구현하기 전에 검증 기준부터 만들어라

개인적으로 가장 중요하게 생각한 부분은 검증을 구현 이후의 작업으로 생각하지 않는 것이다.

일반적으로 기능을 구현한 뒤 테스트를 작성하거나, 문제가 발생하면 그때 원인을 찾아 수정하는 경우가 많다. 하지만 AI를 활용할 때는 이러한 순서를 그대로 유지하는 것이 좋은 방법이 아닐 수 있다.

AI는 주어진 요구사항을 해석해 코드를 생성한다. 요구사항에 빈틈이 있다면 그 부분을 임의로 판단해 구현할 수 있다. 결과물이 자연스럽고 그럴듯해 보이더라도 실제 의도와 다를 수 있다는 의미다.

따라서 코드를 작성하기 전에 기능의 조건, 수행할 동작, 기대 결과를 명확하게 정의하는 것이 중요하다.

예를 들어 특정 기능을 구현한다고 했을 때 단순히 정상 동작만 정의하는 것이 아니라, 잘못된 입력이 들어오거나 외부 요청이 실패했을 때 어떻게 동작해야 하는지도 함께 정의해야 한다.

이러한 명세가 있어야 AI가 생성한 결과를 객관적으로 검증할 수 있다.

책에서는 Gherkin을 활용한 명세 작성과 테스트 우선 접근 방식도 다룬다. 핵심은 테스트를 나중에 추가하는 보조 작업으로 취급하지 않고, 구현이 지켜야 할 기준으로 활용하는 것이다.

이 부분은 AI를 사용하지 않는 일반적인 개발에서도 중요한 원칙이라고 생각한다. 다만 AI가 코드 생성을 빠르게 해 주는 환경에서는 명세가 부족할 때 발생하는 문제가 더욱 커질 수 있다.

3. 테스트가 통과해도 안심할 수 없는 이유

테스트를 작성하고 통과 여부를 확인하는 것은 중요하다. 하지만 테스트가 통과했다는 사실과 실제 요구사항이 충족되었다는 사실은 다르다.

테스트 자체가 잘못 작성되었거나 중요한 조건을 놓쳤다면 문제가 있는 코드도 정상으로 판정될 수 있기 때문이다.

이 책에서는 이러한 문제를 해결하기 위해 실행 트레이스와 회귀 게이트의 중요성을 다룬다.

단순히 로그에 성공 메시지가 출력되었는지 확인하는 것이 아니라, 실제로 어떤 실행 경로를 거쳤고 기대한 결과가 발생했는지 확인해야 한다는 것이다.

또한 기능을 수정한 뒤 기존에 정상 동작하던 기능이 깨지지 않았는지 반복해서 검증할 수 있는 구조도 필요하다.

개발 과정에서 흔히 발생하는 회귀 버그를 방지하기 위해서다.

AI가 코드를 수정할 때도 마찬가지다. 오류가 발생했다고 곧바로 코드를 다시 수정하도록 요청하기보다는, 먼저 무엇이 잘못되었는지 확인하고 그 판단을 뒷받침하는 근거를 확보해야 한다.

이런 과정을 거쳐야 잘못된 수정이 반복되는 상황을 줄일 수 있다.

4. AI 루프를 실제 개발에 적용한다면?

언리얼 엔진으로 게임을 개발하는 입장에서 생각해 보면 이 책의 내용을 적용할 수 있는 부분이 많다.

예를 들어 AI에게 기존 C++ 클래스의 기능을 수정하도록 요청했다고 가정해 보자.

단순히 코드를 생성하고 컴파일하는 것으로 작업을 마무리하면 놓치는 부분이 생길 수 있다. 기존 클래스의 책임과 호출 관계, 객체의 생명주기, 게임플레이에 영향을 주는 조건 등을 함께 확인해야 하기 때문이다.

이러한 과정을 체계화한다면 다음과 같은 루프를 구성할 수 있을 것이다.

1. 명세 작성: 수정 목적과 정상·실패 조건을 정의한다.
2. 테스트 설계: 요구사항을 검증할 수 있는 테스트와 기준을 마련한다.
3. 구현: AI를 활용해 코드를 작성하거나 수정한다.
4. 검증: 빌드, 자동화 테스트, 로그 및 실행 결과를 확인한다.
5. 개선: 실패 원인을 분석하고 수정한 뒤 다시 검증한다.

여기서 중요한 것은 모든 과정을 무조건 자동화하는 것이 아니다.

빌드나 명확한 조건에 대한 테스트처럼 자동화하기 쉬운 부분은 시스템에 맡기고, 아키텍처 설계나 게임플레이에 미치는 영향처럼 맥락이 필요한 부분은 개발자가 판단해야 한다.

또한 기존 프로젝트에 AI를 적용할 때는 현재 동작을 먼저 기록하고 기준선을 만드는 과정도 필요하다. 기존 코드에 문제가 있어 보이더라도 실제로 어떤 동작을 유지해야 하는지 모르는 상태에서 수정하면 예상하지 못한 문제가 발생할 수 있기 때문이다.

결국 AI를 개발 과정에 적용하려면 코드를 생성하는 단계만 자동화할 것이 아니라, 그 결과를 검증하고 관리하는 과정까지 함께 설계해야 한다.

마치며

『AI 루프를 설계하라』는 AI를 활용한 개발에서 무엇을 중요하게 생각해야 하는지 다시 한번 정리해 볼 수 있는 책이다.

AI가 코드를 작성하는 능력은 계속 발전하고 있다. 하지만 코드 생성 능력이 좋아지는 것과 결과물의 품질을 보장하는 것은 별개의 문제다.

특히 실제 서비스나 대규모 프로젝트에서는 단순히 빌드가 성공하거나 테스트가 통과했다는 이유만으로 결과물을 신뢰하기 어렵다. 명확한 명세와 검증 기준, 실행 결과에 대한 근거, 기존 동작을 보호하는 회귀 테스트가 함께 필요하다.

개발자 입장에서는 AI에게 어떤 코드를 작성하도록 요청할 것인지뿐만 아니라, 그 코드가 올바르다는 것을 어떻게 확인할 것인지도 고민해야 한다.

앞으로 AI를 활용한 개발이 더 보편화될수록 코드를 직접 작성하는 능력뿐만 아니라, 요구사항을 정의하고 검증 가능한 개발 환경을 설계하는 능력도 중요해질 것이라고 생각한다.

AI를 활용해 개발 생산성을 높이는 데 관심이 있다면, 단순히 코드 생성에 집중하기보다 AI가 만든 결과물을 신뢰할 수 있도록 어떤 검증 구조를 마련해야 하는지 고민해 볼 수 있는 책이다.

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

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

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

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

#리뷰어클럽리뷰