본문 바로가기

책 리뷰 & 베타리딩 후기

『바이브 엔지니어링』 리뷰 — AI가 짜준 코드, 어디까지 믿어도 될까?

반응형

길벗 35차 개발자 리뷰어 활동으로 도서를 제공받아 읽고 솔직하게 작성한 리뷰입니다. #협찬

바이브 엔지니어링

코드가 너무 빨리 나올 때 드는 불안

요즘은 AI에게 기능을 설명하면 코드가 금방 나온다. 간단한 API나 테스트 초안 정도는 커피 한 잔 마시는 사이에 만들어질 때도 있다. 처음에는 마냥 신기했다. 그런데 이게 익숙해지니 다른 걱정이 생겼다.

“잘 돌아가긴 하는데, 이걸 그대로 운영에 올려도 되나?”

화면은 뜨고 응답도 온다. 그렇다고 좋은 코드라는 뜻은 아니다. 데이터가 많아졌을 때 느려지지 않을지, 동시에 요청이 몰리면 값이 꼬이지 않을지, 예외 상황에서 엉뚱한 데이터를 남기지는 않을지 확인할 게 한두 가지가 아니다. AI가 만들어 준 코드가 길수록 검토하는 쪽이 오히려 더 부담스러울 때도 있었다.

『바이브 엔지니어링』은 그 찜찜함을 그냥 넘기지 않는 책이다. AI를 쓰지 말자는 이야기는 전혀 아니다. 빨라진 만큼 개발자가 무엇을 더 꼼꼼히 봐야 하는지, 어디까지 맡기고 어디서부터 직접 판단해야 하는지를 다룬다.

도서 정보
제이 킴 지음 · 길벗 · 312쪽 · 2026년 6월 30일 출간

바이브 코딩 다음에 ‘엔지니어링’이 필요한 이유

책에서 말하는 바이브 코딩은 AI에게 원하는 기능을 이야기하고 빠르게 결과물을 얻는 단계다. 여기까지만 해도 생산성은 확실히 올라간다. 문제는 그다음이다. 요구사항이 모호하거나 전체 구조를 생각하지 않은 상태에서 코드를 계속 붙이면, 처음에는 빨랐던 프로젝트가 뒤로 갈수록 손대기 어려워진다.

바이브 엔지니어링은 한 걸음 더 간다. 무엇을 만들지 먼저 정리하고, 구조를 그리고, 필요한 맥락을 AI에게 전달하고, 작업을 작게 나눠 요청한다. 나온 결과는 테스트와 코드 리뷰로 확인한다. 말만 놓고 보면 기존 개발 방식과 크게 다르지 않다. 오히려 그게 이 책의 중요한 지점이라고 느꼈다. AI가 들어왔다고 소프트웨어를 만드는 기본 원칙까지 사라진 것은 아니기 때문이다.

솔직히 초반에는 “결국 요구사항 잘 쓰고 테스트하라는 말 아닌가?” 싶기도 했다. 그런데 읽다 보니 익숙한 원칙을 AI와 일하는 순서에 맞춰 다시 정리해 둔 데 이 책의 쓸모가 있었다. 알고 있는 것과 실제 작업에서 매번 지키는 것은 다른 문제니까.

빠른 코드 생성에서 설계·테스트·검증을 갖춘 엔지니어링으로

목차에서 먼저 눈이 간 건 ‘조용한 버그’였다

문법 오류는 그나마 친절하다. 빨간 줄이 생기고 빌드가 실패한다. 반면 논리 오류는 아무 일도 없는 척 숨어 있다. 날짜 경계, 반올림, 빈 값, 중복 처리, 권한 조건처럼 실제 업무 규칙과 맞닿은 곳에서 이런 문제가 잘 생긴다.

AI가 만든 코드는 문법적으로 꽤 그럴듯해서 더 쉽게 안심하게 된다. 책은 “실행되는가?”에서 멈추지 말고 왜 이 로직이 맞는지, 반례는 없는지, 경계값에서도 같은 결과가 나오는지를 계속 확인하라고 말한다. 당연한 이야기인데, AI가 코드를 순식간에 쏟아내는 상황에서는 이 당연한 절차가 자주 생략된다.

비기능 요구사항을 다루는 부분도 비슷했다. 응답 시간, 보안, 동시성, 장애 복구 같은 조건은 프롬프트에 적지 않으면 빠지기 쉽다. AI가 알아서 못 챙겼다고 탓하기 전에 개발자가 먼저 기준을 세웠는지 돌아보게 됐다.

프롬프트를 잘 쓴다는 말이 조금 다르게 들렸다

프롬프트 관련 책이나 글을 보다 보면 특별한 문장 공식이 있을 것처럼 느껴질 때가 있다. 이 책은 그보다 훨씬 현실적으로 접근한다. 프롬프트는 멋진 질문이 아니라 작은 요구사항 문서에 가깝다는 것이다.

무엇을 만들지, 입력과 출력은 무엇인지, 지켜야 할 제약은 무엇인지, 예외는 어떻게 처리할지, 완료됐다고 판단할 기준은 무엇인지 적어야 한다. 막상 써보면 모델을 위한 기술이라기보다 개발자 스스로 문제를 제대로 이해했는지 확인하는 과정에 가깝다.

큰 작업을 한 번에 던지지 말고 설계, 인터페이스, 구현, 테스트처럼 나눠서 요청하라는 조언도 실용적이었다. 중간 결과를 보면서 방향을 고칠 수 있고, 문제가 생겨도 어느 단계에서 잘못됐는지 찾기 쉬워진다. “한 번에 완성해 줘”가 편해 보이지만 실제로는 수정할 때 더 오래 걸린다는 걸 몇 번 겪어본 사람이라면 바로 공감할 부분이다.

테스트는 AI를 못 믿어서 쓰는 게 아니었다

책을 읽으며 가장 오래 남은 부분은 테스트 코드였다. AI의 결과를 의심해서 테스트하는 것이 아니라, 사람과 AI가 같은 완료 기준을 보게 하려고 테스트를 만든다는 설명이 좋았다.

“정상적으로 동작하게 만들어 줘”는 사람마다 해석이 다르다. 반면 어떤 입력에서 어떤 결과가 나와야 하는지 테스트로 적어두면 훨씬 분명해진다. 기존 코드에 기능을 추가할 때도 먼저 테스트를 보강해 두면 AI가 건드려서는 안 될 범위를 알려줄 수 있다. 테스트가 검증 도구이면서 동시에 지시서가 되는 셈이다.

마지막에 컴퓨터 공학 기초와 도메인 지식을 강조하는 것도 인상적이었다. 기술적으로 말이 되는 코드라도 회사의 정산 규칙이나 권한 체계를 잘못 이해하면 결과는 틀린다. 결국 AI의 답이 맞는지 판단하려면 사람이 알고 있어야 한다. 도구가 좋아질수록 기초 공부가 덜 필요할 거라 생각하기 쉬운데, 오히려 반대에 가까웠다.

요구사항부터 배포까지, 사람이 중심을 잡는 AI 협업 개발 흐름

읽고 나서 작업 방식을 조금 바꿔봤다

거창한 변화는 아니다. AI에게 코드를 요청하기 전에 아래 정도는 먼저 적어두려고 한다.

  • 이 기능을 왜 만드는지 한 문장으로 써보기
  • 입력, 출력, 예외 상황을 빠뜨리지 않기
  • 성능이나 보안처럼 기능 밖의 조건도 같이 적기
  • 한 번에 맡기지 않고 리뷰할 수 있는 크기로 나누기
  • 완료 기준을 테스트나 체크리스트로 남기기

결과를 받은 뒤에는 설명을 읽고 끝내지 않고, 내가 이 코드를 다른 사람에게 설명할 수 있는지 확인한다. 설명이 안 되면 아직 내 코드가 아니다. 이 기준 하나만 있어도 AI가 만든 코드를 무심코 붙여 넣는 일이 꽤 줄어든다.

좋았던 점과 아쉬웠던 점

특정 도구의 화면이나 명령어에 매달리지 않는 점이 좋았다. Cursor나 Claude Code가 업데이트돼도 요구사항, 설계, 테스트, 검증이라는 뼈대는 남는다. 주니어 개발자 용이와 시니어 개발자 제이가 함께 문제를 풀어가는 구성도 딱딱한 내용을 읽기 편하게 만든다. 각 장 끝의 프롬프트와 체크리스트는 팀에서 그대로 고쳐 써도 괜찮아 보였다.

반대로 AI 코딩 도구를 처음 켜는 단계부터 따라 하는 실습서를 기대했다면 조금 다를 수 있다. 경험이 있는 개발자에게는 이미 아는 이야기처럼 느껴지는 부분도 있다. 다만 머리로 알고 있던 원칙을 실제 AI 협업 과정에 맞춰 한 줄로 세워주는 책은 생각보다 드물다.

이런 분이라면 잘 맞을 것 같다

  • AI가 만든 코드를 쓰고 있지만 어디까지 검토해야 할지 막막한 개발자
  • 빠르게 만든 결과물이 나중에 기술 부채로 돌아온 경험이 있는 분
  • AI 시대에 무엇을 공부해야 할지 고민하는 주니어 개발자
  • 팀의 AI 코딩 규칙이나 리뷰 기준을 만들려는 리더

마무리 ⭐️⭐️⭐️⭐️☆ (4.5/5)

이 책은 AI에게 코드를 덜 맡기라고 하지 않는다. 대신 더 잘 맡기고, 나온 결과를 제대로 책임지는 방법을 이야기한다. 읽고 나니 “AI를 잘 쓰는 개발자”의 의미가 조금 달라졌다. 프롬프트를 빨리 입력하는 사람이 아니라, 문제를 분명히 설명하고 결과가 맞는지 끝까지 확인할 수 있는 사람에 가깝다.

한 줄 평: AI가 짜준 코드 앞에서 ‘잘 돌아가네’로 끝내지 않게 해주는 책.

도서 링크

#협찬 #길벗 #길벗출판사 #바이브엔지니어링 #바이브코딩 #AI코딩 #생성형AI #개발자책추천 #서평 #책리뷰

반응형