AI 루프를 설계하라 후기 - AI를 대하는 태도를 바꿔준 책

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

#2622

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