어쨌든 에이전틱 코딩 - 바이브 코딩을 끝내고 에이전틱 엔지니어링으로 가는 레시피

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

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

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

[목 차]

소개 당신의 에이전틱 전환

1부 기초

1 기존 개발 방식 왜 한계에 부딪혔나

__1.1 우리 모두가 느끼는 고충

__1.2 수동 유지보수의 숨겨진 비용

__1.3 비즈니스 사례 시간은 절약되고 품질은 좋아진다

__1.4 SE 3.0으로의 전환 무엇이 바뀌었나

__1.5 기존 도구가 한계에 도달할 때

__1.6 에이전트 전환이 약속하는 것

__1.7 함께 전환해 봅시다

2 바이브 코딩에서 에이전틱으로 전환 로드맵

__2.1 바이브 코딩 다시 보기 우리가 이미 알고 있는 것

__2.2 에이전틱 코딩 정의하기 목표 계획 자율성

__2.3 핵심 구분 감독자 대 아키텍트

__2.4 상호 보완적인 관계

__2.5 의사결정 프레임워크 바이브인가 에이전트인가

__2.6 전환할 준비가 되었다는 신호

__2.7 앞으로 여러분의 경로

3 안전제일 사고방식

__3.1 왜 보안이 먼저인가

__3.2 자율성이 가져오는 근본적인 리스크

__3.3 치명적인 3요소 LLM이 지시와 내용을 혼동할 때

__3.4 보안 플레이북

__3.5 에이전틱 코딩을 사용하지 말아야 할 때

__3.6 실패를 예상하기 그리고 복구하기

__3.7 기초가 갖춰졌습니다

2부 프레임워크

4 에이전틱 워크플로 프레임워크

__4.1 PLAN 프레임워크 소개

__4.2 준비 성공을 위한 준비

__4.3 실행 자신감을 가지고 위임하기

__4.4 감사 검토와 검증

__4.5 육성 학습과 개선

__4.6 프레임워크 실습 완전한 예제

__4.7 프레임워크 체크리스트

__4.8 앞으로 나아가기

5 실전 도구 나만의 에이전틱 도구 모음

__5.1 도구 지형도

__5.2 도구 선택 의사결정 트리

__5.3 필수 도구 비교

6 첫 번째 완전한 설정 연습을 통한 마스터

__6.1 에이전틱 환경 설정

__6.2 첫 번째 ACM 만들기

__6.3 튜토리얼 첫 번째 ACM을 처음부터 만들기

__6.4 컨텍스트 관리 장기 세션을 운영하는 기술

__6.5 첫 번째 에이전트 작업 자동화된 코드 리팩터링

__6.6 첫 승리를 축하하기

3부 숙련

7 새로운 역할 코더에서 지휘자로

__7.1 인지적 전환

__7.2 선 계획 후 코딩

__7.3 에이전트 관리에 필요한 핵심 역량

__7.4 책임의 장벽

__7.5 감독자로서의 첫 번째 주간

__7.6 실전에서의 사고방식 전환

__7.7 저항 극복하기

__7.8 앞으로의 길

8 계획 및 위임 마스터

__8.1 의도 마스터하기 목표 명세의 기술

__8.2 계층형 프롬프트 엔지니어링

__8.3 계획 루프 먼저 계획부터 요청하기

__8.4 위임 모범 사례

__8.5 마스터로 가는 길

9 신뢰하되 검증하라 에이전트 작업 검토하기

__9.1 실행과 반복 루프

__9.2 에이전트가 생성한 코드를 위한 코드 리뷰

__9.3 개입 시점 결정적 순간을 인식하기

__9.4 리뷰 마인드셋

10 일이 잘못되었을 때 복구와 디버깅

__10.1 에이전트가 실패하는 이유 항상 그들 잘못만은 아니다

__10.2 에이전트 행동 디버깅

__10.3 복구 전략 롤백 및 리셋

__10.4 실제 실패 시나리오 사례 연구

__10.5 실패에서 배우기 사후 분석 프로세스

__10.6 복구 프롬프트 실전 예시

__10.7 앞으로 나아가기

4부 실전 응용

11 코드베이스 유지보수 마이그레이션

__11.1 소개

__Tutorial 1 점진적 타입스크립트 마이그레이션

__Tutorial 2 자동화된 의존성 마이그레이션

__Tutorial 3 체계적인 명명 규칙 강제 적용

__Tutorial 4 죽은 코드 제거

__Tutorial 5 자동화된 문서 생성

__Tutorial 6 레거시 코드 리팩터링

__11.2 요약

12 CI CD 인프라 자동화

__12.1 소개

__Tutorial 7 에이전틱 코딩을 활용한 깃 워크플로

__Tutorial 8 CI CD 파이프라인 생성

__Tutorial 9 자동화된 보안 감사 통합

__Tutorial 10 로컬 개발 환경 설정

__Tutorial 11 자동 롤백 및 복구

__Tutorial 12 코드형 인프라 생성

__12.2 요약

13 규모에 따른 기능 개발

__13.1 소개

__Tutorial 13 엔드 투 엔드 검색 통합

__Tutorial 14 결제 게이트웨이 연동

__Tutorial 15 다국어 지원 i18n

__Tutorial 16 실시간 대시보드 기능

__Tutorial 17 멀티에이전트 QA 루프 만들기

__13.2 요약

14 품질 보증 보안

__14.1 소개

__Tutorial 18 코드 리뷰에 에이전트 사용하기

__Tutorial 19 완전한 단위 테스트 커버리지

__Tutorial 20 보안 취약점 스캔

__Tutorial 21 성능 최적화 감사

__Tutorial 22 합의 기반 코드 리뷰

__14.2 요약

5부 심화 전략

15 멀티에이전트 시스템과 팀 협업

__15.1 에이전트 하나로 부족할 때

__15.2 멀티에이전트 워크플로 설계

__15.3 오케스트레이션 프레임워크

__15.4 에이전트 시대의 팀 역학

__15.5 애자일과 스크럼에 통합하기

__15.6 에이전틱 실천을 조직 전반으로 확장하기

6부 전환

16 전환 계획

__16.1 1 30일차 기초 다지기

__16.2 31 60일차 기술 개발

__16.3 61 90일차 숙련 및 통합

__16.4 포트폴리오 구축

__16.5 패러다임의 수렴

__16.6 미래 개발자에게 필요한 역량

__16.7 당신이 되려는 개발자

부록

부록 A 용어집

부록 B 프롬프트 템플릿 라이브러리

부록 C 보안 체크리스트

부록 D PLAN 프레임워크 빠른 참조

부록 E 팀 협업 가이드

부록 F AI 코딩이 처음이라면 

[본 문]

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

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

클래스 컴포넌트가 아니라 함수형 컴포넌트를 원한다고 명시하지 않는 바람에 에이전트가 일을 한 뒤 수습하느라 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