바이브코딩 뛰어넘기

바이브코딩의 한계를 짚고, 이 강의가 정의하는 에이전틱 엔지니어링의 큰 그림을 그립니다.

얻어갈 것

바이브코딩은 한 번 말하면 완성품이 나오는 "딸깍"이 아닙니다. 실제 흐름은 요청하기 -> 만들기 -> 확인하기 -> 문제 찾기를 계속 반복하는 쪽에 가깝습니다.
처음 요청이 완벽하지 않아도 괜찮습니다. 오히려 처음부터 완벽한 프롬프트를 쓰려고 하기보다, 작게 만들고 실제로 눌러본 다음 후속 요청을 이어가는 편이 현실적입니다.

바이브코딩은 시작을 빠르게 만들어줍니다. 작은 데모나 화면 초안은 빠르게 만들 수 있습니다. 하지만 실제로 조금만 오래 만들어보면 곧 한계가 드러납니다.

엔지니어링에 대한 기본 이해 없이 제품을 계속 개발하는 것은 한계가 분명합니다. 특정 시점부터 버그가 많아지고, 에이전트가 하는 말을 이해하기 어려워지고, 개발 속도도 크게 느려집니다.

이 한계를 부정할 필요는 없습니다. 오히려 여기서부터가 이 강의의 핵심입니다.

빠르게 만든 결과물을 계속 고칠 수 있게 만들려면, AI에게 더 좋은 맥락을 주고 사람이 확인할 기준을 가져야 합니다. 그 방식을 에이전틱 엔지니어링이라고 부릅니다.

이 강의에서는 에이전틱 엔지니어링을 에이전트가 잘 일할 수 있는 개발 환경을 만들고, 그 결과를 사람이 검증하며 제품으로 이어가는 방식으로 둡니다.

안드레이 카파시는 Sequoia AI Ascent 2026 대담에서 바이브코딩 이후 소프트웨어 개발의 중심이 "코드를 직접 치는 일"에서 "에이전트를 지휘하고 검증하고 설계하는 일"로 옮겨가고 있다고 설명합니다.

이 변화의 핵심은 단순히 코딩이 빨라졌다는 것이 아닙니다. 앱, 문서, 배포, 인프라, 교육까지 에이전트가 읽고 실행하기 좋은 형태로 다시 설계되어야 한다는 점입니다.

더 나은 결과물을 만들기 위해서는 크게 두 가지 이해가 필요합니다.

화면, API, 데이터베이스, 인증, 배포, 에러 대응처럼 제품이 실제로 굴러가는 구조를 이해해야 합니다.

모든 코드를 직접 짤 필요는 없지만, AI가 만든 결과가 어느 부분에 속하는지는 알아야 합니다.

에이전트가 어떤 도구를 쓰고, 어떤 맥락을 읽고, 어디서 잘하고 어디서 흔들리는지 알아야 합니다.

같은 요청이라도 파일을 가리켜줬는지, 검증 기준을 줬는지, 작업 범위를 쪼갰는지에 따라 결과가 크게 달라집니다.

이 둘이 함께 있어야 "다 만들어줘"에서 끝나지 않고, 에이전트가 잘할 수 있는 환경을 만들어줄 수 있습니다.

처음부터 어렵게 생각할 필요는 없습니다. 차근차근 문제를 해결하다 보면, 이런 개념들은 자연스럽게 익히게 됩니다.

바이브코딩은 빠르게 시작하는 힘이고, 에이전틱 엔지니어링은 그 결과를 계속 다룰 수 있게 만드는 기준입니다.

다음 챕터부터는 이 기준을 실제 도구와 Claude Code 사용법으로 내려봅니다. 터미널, IDE, Git, Claude Code 같은 도구는 단순한 설치 목록이 아니라, 에이전트가 만든 결과를 확인하고 이어가기 위한 작업 환경입니다.