>> 책 소개

왜 내 AI는 말을 안 듣지?

성능 좋은 모델을 쓰면 결과물이 뚝딱 나올까요? 챗GPT를 쓰다가 제미나이로 넘어가고, 제미나이를 쓰다가 클로드로 넘어가면 문제가 해결될까요? 서점에 이런 종류의 책은 이미 넘쳐납니다. 프롬프트 엔지니어링이나 도구 사용법으로는 이 문제를 해결할 수 없습니다. 문제를 해결하려면 패러다임을 전환해야 합니다.

코더에서 지휘자로!

프롬프트를 입력하고 코드를 확인하는 코더의 방식이라면 인간이 명확한 병목입니다. 에이전트 팀을 지휘하는 지휘자가 되어야 합니다. 코드를 중심으로 생각하는 코더의 방식에서 벗어나 계획, 위임, 검토하는 지휘자의 방식으로 전환해야 합니다. 프롬프트 기법 같은 구체적인 요령이 아니라 사고방식의 전환을 배워야 합니다.

구조화된 접근 방식

에이전트를 에이전트답게 활용하려면 요청 → 결과라는 단일 사고방식에서 벗어나야 합니다. 에이전트를 프로젝트 단위로 굴리려면 구조적인 방법론이 필요합니다. PLAN 프레임워크는 AI 모델이나 도구 중립적인 방법론을 제시합니다. 에이전트에 일을 맡기는 요령이 아니라 에이전트 기반 개발을 안정적으로 운영하기 위한 실행 프레임워크로 시작하세요. “왜 내 AI는 말을 안 듣지?”라고 고민하고 있다면 PLAN 프레임워크로 구조부터 설계하세요.

>> 출판사 리뷰

“로그인 기능 만들어 줘.”로 끝나는 시대는 지났습니다!

이제는 목표를 던지면 에이전트가 계획→구현→테스트→수정→배포까지 스스로 굴리는 시대

개발자는 코더가 아니라 지휘자가 됩니다.

《어쨌든, 에이전틱 코딩》은 바이브 코딩을 넘어 프로덕션을 실제로 움직이는 ‘에이전틱 엔지니어링’ 레시피를 제공합니다.

PM, 아키텍트, 구현, QA, 보안, DevOps, 리뷰어… 역할을 나눈 멀티 에이전트 팀을 한 사람의 워크플로로 만드는 방법, 그리고 “빠르게”가 아니라 “안전하게, 검증 가능하게” 자동화를 운영하는 방법을 다룹니다.

이 책의 핵심은 도구 사용법이 아니라 프레임워크입니다.

검증된 4단계 PLAN 프레임워크로 위임의 품질을 끌어올리고, 실패를 예방하며, 문제가 생겨도 복구 가능한 운영 체계를 만듭니다.

이 책에서 얻는 것

  • 목표 설정부터 결과 검토까지, 에이전트를 “에이전트답게” 쓰는 실전 프로세스
  • 대규모 리팩터링, 마이그레이션, 문서화, CI/CD 자동화 등 22가지 튜토리얼
  • 테스트·리뷰, 롤백, 권한 제한 등 안전 제일 가드레일과 보안 체크리스트
  • “언제는 에이전틱, 언제는 바이브”를 가르는 의사결정 기준
  • 에이전틱 팀 전환 로드맵부터 바로 쓸 수 있는 프로젝트 템플릿

이런 개발자에게

  • AI 보조를 써봤지만, 이제 작업 단위가 아니라 ‘프로젝트 단위’로 위임하고 싶은 사람
  • 유지보수, 업그레이드, 반복 업무에 지쳐 레버리지가 필요한 시니어
  • 속도보다 신뢰성과 재현성이 중요한 프로덕션 환경의 실무자

감으로 만들다, 망하지 말고!

이제는 “알아서 해 줘.”가 아니라 “안전하게 알아서 해내게 만드는 법”을 배울 차례입니다.

>> 책 속으로

우리는 어려운 질문을 피하지 않습니다.

에이전트가 실패하면 무슨 일이 벌어질까요? AI 가 생성한 코드는 어떻게 리뷰해야 할까요? 팀 워크플로는 어떻게 해야 할까요? 에이전트가 데이터베이스를 삭제한다면 어떡할까요? 우리는 이러한 시나리오를 실제 사례와 현실적인 해결책으로 다룹니다. _vxi

솔직한 이야기

클래스 컴포넌트가 아니라 함수형 컴포넌트를 원한다고 명시하지 않는 바람에 에이전트가 일을 한 뒤 수습하느라 2시간을 썼습니다. 에이전트는 자신이 생각하기에 “최신” 리액트를 선택해 30개 파일을 리팩터링했고 내 테스트의 절반을 깨뜨렸습니다. 초기 프롬프트에 “함수형 컴포넌트만 사용하라.”고 써 뒀다면 그 2시간은 30초로 끝났을 일입니다. 교훈은 명확합니다. 계획을 명시적으로 세우면 나중에 비싼 수정 비용을 막을 수 있습니다. _98p

솔직한 이야기

한번은 에이전트가 생성한 코드가 지나치게 복잡해 보이길래 검토한 적이 있습니다. 실행 트레이스(execution trace)를 확인해 보니 에이전트가 더 단순한 접근 방식을 세 번 시도했지만 그 세 가지 모두 테스트에 실패했다는 걸 알게 됐습니다. 복잡한 해법이 테스트를 통과한 유일한 방법이었습니다. 그 복잡성은 실수가 아니라 필요한 것이었습니다. 실행 트레이스가 없었다면 나는 그 코드를 “단순화”해 버렸을 것이고 테스트를 통과하지 못했을 것입니다. _126p

솔직한 이야기

저의 첫 의존성 마이그레이션은 eval 문 안에 숨어 있던 동적 import를 놓쳤습니다. 에이전트가 정적 import 47개를 찾아냈고 저는 그게 전부라고 생각했습니다. 그러나 2주 후 프로덕션 환경에서 어떤 사용자 액션이 이전 API를 호출하는 동적 import를 실행했습니다. 에러 메시지는 암호문 같았습니다: “undefined is not a function.” 이를 디버깅하는 데 몇 시간이 걸렸습니다. import 경로를 동적으로 생성할 수 있는 문자열 연결 패턴도 검토하라고 꼭 에이전트에 요청하세요. _172p

솔직한 이야기

예전에 어디에서도 호출되지 않는 “죽은” 유틸리티 함수를 삭제한 적이 있습니다. 그로부터 6개월 뒤 한 고객사와의 연동이 깨졌습니다. 알고 보니 고객사는 디버깅을 위해 Postman으로 우리의 내부 유틸리티를 호출하고 있었습니다. 문서에는 없었지만, 그 함수를 없애니 고객사의 워크플로가 깨진 것이죠. 그 이후로는 공개 함수를 삭제하기 전에 최소한 한 번의 릴리스 사이클 동안은 반드시 사용 중단 예정(deprecated) 표시를 하고 있습니다. _181p

솔직한 이야기

내 Docker 프로젝트에서 에이전트가 처음 만든 CI/CD 워크플로는 이미지 레이어 캐싱을 제대로 하지 못했습니다. 매번 처음부터 다시 빌드하느라 빌드마다 15분이 걸렸습니다. 워크플로가 겉보기엔 정상적이어서(테스트 통과, 빌드 성공) 리뷰 중에 놓쳤습니다. 누군가 CI가 왜 이렇게 느리냐고 묻기 전까지 느린 빌드는 2주나 이어졌습니다. 특히 Docker나 컴파일 언어에서는 빌드 캐싱이 제대로 되는지 반드시 확인하세요. _204p

솔직한 이야기

저는 중간(medium) 심각도 취약점이 하나라도 발견되면 빌드가 실패하도록 보안 스캔을 구성했습니다. 첫 스캔에서 쉽게 고칠 수 없는 전이 의존성(transitive dependencies)에서 중간 심각도 이슈 23개가 발견되었습니다. 모든 빌드가 실패했습니다. 중첩된 의존성을 업그레이드하느라 이틀을 날렸는데 알고 보니 일부 취약점은 스캔 도구가 잘못 잡아낸 오탐(false positive)이었습니다. 지금은 치명적 이슈에 대해서만 실패 처리하고 중간 심각도 경고는 별도로 관리합니다. 완벽한 보안을 좇느라 배포가 막히지 않게 하세요. _213p

솔직한 이야기

검색 기능은 500개 상품이 들어 있는 테스트 데이터베이스가 있는 개발 환경에서는 완벽하게 작동했습니다. 하지만 50,000개 제품이 들어 있는 프로덕션 환경에서는 쿼리가 8초나 걸리다가 결국 타임아웃이 발생했습니다. 에이전트에 프로덕션 규모로 테스트해 달라고 요청하지 않았기 때문입니다. GIN 인덱스는 생성되었지만 쿼리가 전문 검색 연산자를 사용하지 않아 인덱스가 전혀 사용되지 않았습니다. 에이전트가 생성한 쿼리는 배포하기 전에 반드시 현실적인 규모에서 성능을 테스트하세요. _240p

《어쨌든, 에이전틱 코딩》은 다음 서점에서 구입하실 수 있습니다.

교보문고 | 예스24 | 알라딘