2026년 2월 20일 · 아샬

바이브 코딩과 에이전틱 코딩, 무엇이 다른가

“바이브 코딩”이라는 말이 유행한 지 1년이 조금 지났습니다.

이 단어를 만든 Andrej Karpathy가 최근 입장을 수정했습니다.1 바이브 코딩이 맞는 방향이 아닐 수 있다고. 자신이 만든 용어를 스스로 되짚은 셈입니다. 대신 그가 제시한 것이 에이전틱 엔지니어링입니다.

“바이브 코딩”은 이렇게 합니다.

AI에게 요청합니다. AI가 코드를 씁니다. diff를 읽지 않고 수락합니다. 실행해봅니다. 동작하면 됩니다. 왜 이렇게 동작하는지는 중요하지 않습니다. 뭔가 이상하면 AI에게 고쳐달라고 합니다.

빠릅니다. 허들이 낮습니다. 코드를 몰라도 뭔가 만들 수 있습니다. 처음에는 신기합니다. 이걸로 앱이 만들어집니다.

그런데 시간이 지나면 문제가 생깁니다.

어느 순간부터 잘 안 됩니다. 이 부분을 고치면 저 부분이 망가집니다. 저 부분을 고치면 또 다른 데가 이상해집니다. AI에게 물어봐도 “죄송합니다, 수정했습니다”를 반복합니다. 코드가 왜 이렇게 돼 있는지 모르니까 어디서부터 접근해야 할지도 모릅니다.

뭘 요청해야 할지조차 점점 모르게 됩니다.

이것은 예측 가능한 결과입니다. 코드를 이해하지 않고 만들면, 코드를 이해하지 않고 고쳐야 합니다. AI도 마찬가지입니다. 맥락 없이 쌓인 코드를 맥락 없이 수정합니다.

“에이전틱 코딩”은 다릅니다.

AI에게 자율성을 줍니다. 여러 파일을 수정하고, 테스트를 실행하고, 결과를 확인하는 과정을 스스로 처리하게 합니다. 여러 단계를 에이전트가 알아서 진행합니다.

그러나 인간은 판단을 놓지 않습니다.

무엇을 만들지 정의하는 것은 인간이 합니다. 맞는지 확인하는 기준을 세우는 것도 인간이 합니다. 에이전트가 작업을 마치면 그 결과가 기준을 충족하는지 인간이 확인합니다.

AI는 손이고, 인간은 머리입니다.

차이는 여기에 있습니다. 바이브 코딩은 결과를 보고 판단합니다. 에이전틱 코딩은 기준을 먼저 세우고 결과를 확인합니다.

기준을 먼저 세운다는 건 뭘 말하는 걸까요?

스펙을 먼저 씁니다.2 이 기능이 어떻게 동작해야 하는지, 성공의 조건이 무엇인지를 글로 정의합니다. “사용자가 로그인하면 대시보드로 이동한다. 잘못된 비밀번호를 입력하면 에러 메시지가 보인다. 세 번 실패하면 계정이 잠긴다.” 이런 식으로.

그리고 그것을 테스트로 표현합니다.3 글로 쓴 기준을 코드로 옮깁니다.

테스트가 통과하면 성공입니다. 통과하지 못하면 아직 덜 된 것입니다. 모호함이 없습니다.

이 기준이 있으면 에이전트가 뭘 만들든 확인할 수 있습니다. 에이전트가 스스로도 확인할 수 있습니다. 기준이 없으면 결과를 눈으로 하나하나 확인해야 합니다. AI가 빠를수록 확인할 것이 더 많아집니다.

바이브 코딩이 나쁘다는 게 아닙니다.

혼자 빠르게 프로토타입을 만들어 볼 때, 아이디어가 되는지 안 되는지 감을 잡을 때, 완성도보다 속도가 중요할 때. 이런 상황에서는 바이브 코딩이 맞는 선택입니다. 버릴 코드를 빨리 써보는 것, 그 자체로 가치가 있습니다.

하지만 실무 코드베이스에 그대로 가져오면 문제가 생깁니다. 팀이 함께 유지보수해야 하는 코드에서, 왜 이렇게 만들었는지 모르는 코드가 쌓이면, 고치는 비용이 만드는 비용보다 커집니다. 한 명이 바이브 코딩으로 만든 것을 다른 사람이 이해하고 수정하는 게 어렵습니다. AI도 마찬가지입니다.

실무는 책임을 요구합니다.4 동작하는 것만으로는 부족합니다.

개발자

에이전틱 코딩은 사실 새로운 것이 아닙니다.

스펙을 명확히 하고, 테스트를 먼저 작성하고, 구현을 검증하는 것. 좋은 개발 방식이라고 오래전부터 알려진 것들입니다. Specification by Example5, Acceptance Test-Driven Development6, Test-Driven Development7, Behavior-Driven Development8 등, 이름은 달라도 방향은 같습니다.

현실의 제약 때문에 제대로 하기 어려웠을 뿐입니다. 테스트를 먼저 쓰는 데 시간이 들었고, 스펙을 세세하게 정의하는 것도 번거로웠습니다. 그래서 생략했습니다.

AI가 그 제약을 걷어냈습니다.

스펙을 쓰는 데 AI가 도움을 줍니다. 테스트를 작성하는 데도 도움을 줍니다. 스펙대로 구현하는 것은 AI가 대신해 줍니다. 검증의 기준이 있으면 AI를 훨씬 잘 쓸 수 있습니다.

소수만 실천할 수 있던 올바른 방법을 이제 누구나 핑계 없이 쓸 수 있습니다.

바이브 코딩은 개발을 잘 모르는 사람도 할 수 있습니다. 에이전틱 코딩은 무엇이 맞는지 아는 사람이 할 수 있습니다.

판단력이 있어야 AI를 제대로 쓸 수 있습니다.

  1. Andrej Karpathy의 트윗: https://twitter.com/karpathy/status/2019137879310836075 

  2. AI 코딩 에이전트를 위한 스펙 문서, 어떻게 쓸 것인가?: https://dal-lab.com/2026/02/18/how-to-write-spec-documents/ 

  3. AI 시대의 TDD, 궁극의 애자일을 향하여: https://wild-coding.com/blog/2026/02/09/tdd-in-ai-era 

  4. AI 시대, 개발자에게 진짜 필요한 역량은?: https://wild-coding.com/blog/2026/01/23/beyond-vibe-coding 

  5. 실제 예시로 요구사항을 명세화하는 방법. Gojko Adzic의 《Specification by Example》 참고. 

  6. 인수 테스트를 먼저 작성하고 개발을 진행하는 방식. 사용자 관점의 시나리오를 테스트로 표현합니다. Markus Gärtner의 《ATDD by Example: A Practical Guide to Acceptance Test-Driven Development》, Kenneth Pugh의 《Lean-Agile Acceptance Test-Driven Development》 참고. 

  7. 테스트를 먼저 작성하고 구현하는 개발 방법론. Kent Beck의 《Test-Driven Development: By Example》 참고. 

  8. 비즈니스 팀과 기술 팀이 같은 언어로 시스템의 행위를 정의하는 방법론. TDD와 DDD를 통합했습니다. 핵심은 “올바른 단어 사용하기”로, 모호함을 제거하고 모두가 같은 개념을 공유하게 만듭니다. Dan North가 제안했습니다. http://behaviourdriven.org/BehaviourDrivenDevelopment 

DAL-LAB Services

우리 팀에 맞는 AI 도입과 개발 전략이 필요하신가요?

상황에 맞는 실행 계획을 함께 정리해드립니다.

서비스 보러 가기