바이브 코딩에서 에이전틱 엔지니어링으로: 1년 만에 바뀐 AI 코딩의 이름

2025년 2월 2일, Andrej Karpathy가 X에 이런 글을 올렸습니다.

There's a new kind of coding I call "vibe coding", where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.

같은 글에는 "Accept All을 항상 누르고, diff는 더 이상 읽지 않는다"는 문장과 "주말에 만들고 버릴 프로젝트에는 나쁘지 않다"는 문장이 함께 있었습니다. 이 단어는 그해 콜린스 영어사전의 올해의 단어가 됐습니다. 그리고 딱 1년 뒤, 이름을 붙인 본인이 다른 이름을 꺼냈습니다.

바이브 코딩이 AI로 코딩하는 모든 것이라는 오해

단어가 퍼지면서 뜻이 넓어졌습니다. AI의 도움을 받아 코드를 짜는 일이면 무엇이든 바이브 코딩이라고 부르게 됐습니다.

원래 정의는 훨씬 좁습니다. 핵심은 "코드가 존재한다는 사실을 잊는다"는 부분입니다. 결과만 보고, 코드는 읽지 않습니다. Simon Willison은 이 차이를 일찍 짚었습니다. AI가 쓴 코드를 검토하고, 테스트하고, 설명할 수 있다면 그것은 바이브 코딩이 아니라 그냥 AI를 도구로 쓰는 소프트웨어 개발이라는 것입니다. 그리고 바이브 코딩으로 운영 코드베이스를 만드는 것은 분명히 위험하다고 덧붙였습니다.

1년 동안 드러난 대가

그 위험은 곧 사례로 나타났습니다. 위키백과의 바이브 코딩 문서는 몇 가지를 정리해 둡니다. 2025년 5월에는 Lovable로 만든 웹 앱 1,645개 중 170개에서 개인정보가 노출되는 취약점이 발견됐습니다. 같은 해 7월에는 Replit의 AI 에이전트가 하지 말라는 지시가 있었는데도 운영 데이터베이스를 지웠습니다.

두 사건 모두 모델이 코드를 못 짜서 생긴 일이라기보다, 아무도 코드를 읽지 않아서 생긴 일에 가깝습니다. 주말 프로젝트에는 괜찮다는 원래의 단서가 빠진 채로 단어만 퍼진 결과라고 저는 봅니다.

2025년 12월에 바뀐 것

Karpathy는 2026년 2월 말 X에 두 달 사이 프로그래밍이 얼마나 바뀌었는지 전하기 어렵다고 썼습니다. 점진적인 발전이 아니라 특히 2025년 12월에 일어난 변화라는 것입니다. 이후 4월 Sequoia의 AI Ascent 발표를 정리한 그의 글에 따르면, 그 무렵부터 에이전트가 만든 코드가 꾸준히 멀쩡하게 나오기 시작했고, 기능 구현이나 리팩터링이나 테스트 실행처럼 큰 단위의 작업을 맡길 수 있게 됐습니다.

같은 2월 글에서 그는 새 이름을 썼습니다. 최상위 수준의 에이전틱 엔지니어링(agentic engineering)이 주는 지렛대가 지금 매우 크다는 것입니다. 그리고 그것에 필요한 것으로 높은 수준의 방향 설정, 판단, 취향, 감독, 반복, 그리고 작업을 잘 나누는 일을 들었습니다.

에이전틱 엔지니어링의 정의와 사람의 몫

두 이름을 나란히 놓으면 방향이 정반대입니다. 바이브 코딩은 코드를 잊는 것이고, 에이전틱 엔지니어링은 에이전트가 쓴 코드의 품질을 전문 소프트웨어 수준으로 지키는 공학 분야라고 Karpathy는 정의합니다. 에이전트는 "틀릴 수 있고 확률적이지만 극도로 강력하다"고 표현했습니다.

그가 든 예가 구체적입니다. 그의 앱 MenuGen에서 에이전트가 Stripe 결제 메일 주소와 Google 계정 메일 주소를 맞대어 사용자를 연결했습니다. 동작은 했지만 메일 주소가 다른 사용자는 결제가 사라집니다. 영구적인 사용자 ID로 연결해야 한다는 판단은 사람이 해야 했습니다. 시스템의 기본 구조를 이해하고 일을 지휘하는 것은 여전히 사람의 몫이라는 것이 그의 결론입니다.

도구가 좋아질수록 더 읽어야 하는 코드

이름이 바뀐 이유를 도구가 좋아져서 이제 코드를 안 읽어도 된다는 뜻으로 읽으면 정반대입니다. 에이전트가 한 번에 만드는 코드가 몇 줄에서 기능 하나로 커졌습니다. 틀렸을 때 피해의 크기도 같이 커졌습니다. 바이브 코딩 시절에는 한 줄을 잘못 받아들여도 금방 보였지만, 지금은 그럴듯하게 동작하는 설계 결함이 기능 하나에 통째로 들어옵니다.

그래서 요즘 코딩 도구들이 경쟁하는 영역도 바뀌었습니다. 여러 에이전트의 결과를 비교하고, diff에 줄 단위로 의견을 달고, 병합 전에 사람이 확인하는 기능이 전면에 나옵니다. Orca 같은 도구가 에이전트 실행보다 검토 기능에 공을 들이는 것도 같은 흐름입니다.

바이브 코딩이 여전히 맞는 용도

바이브 코딩이라는 말이 사라진 것은 아닙니다. Karpathy도 바이브 코딩이 모든 사람이 소프트웨어로 할 수 있는 일의 바닥을 높였다고 평가합니다. 버릴 프로토타입, 혼자 쓰는 스크립트, 아이디어를 확인하려는 주말 프로젝트에는 지금도 가장 빠른 방법입니다.

저는 두 이름을 경쟁 관계보다 용도의 구분으로 봅니다. 만든 것을 버릴 생각이면 바이브 코딩을, 다른 사람이 쓰거나 내가 계속 고쳐야 한다면 에이전틱 엔지니어링을 합니다. 경계는 코드를 누가 짰느냐가 아니라, 그 코드를 누군가 끝까지 책임지느냐에 있습니다.