에이전틱 엔지니어링은 고객 작업이고, 바이브 코딩은 실험입니다.

Andrej Karpathy가 2025년 2월 2일 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.”(내가 ‘바이브 코딩’이라고 부르는 새로운 코딩 방식이 있다. 분위기에 완전히 몸을 맡기고, 기하급수를 받아들이고, 코드가 존재한다는 사실조차 잊는 것이다.) 같은 게시물에서 그는 이것이 “not too bad for throwaway weekend projects”(버리고 말 주말 프로젝트에는 나쁘지 않다)라고 했습니다.

몇 주 뒤 Simon Willison이 이 용어를 명확히 정의했습니다. 바이브 코딩은 “building software with an LLM without reviewing the code it writes”(LLM이 작성한 코드를 검토하지 않고 소프트웨어를 만드는 것)입니다. 코드를 검토하고 테스트하고 다른 사람에게 설명할 수 있다면, 그것은 소프트웨어 개발입니다.

이것이 쓸모 있는 정의입니다. 바이브 코딩은 AI가 쓴 코드에 대한 평가가 아닙니다. 코드를 들여다보지 않겠다는 결정을 가리키는 말입니다.

1년 뒤인 2026년 2월 4일, Karpathy는 지난 1년을 돌아봤습니다. LLM 에이전트로 프로그래밍하는 것이 전문가의 기본 워크플로가 되어 가고 있다며, 다만 “except with more oversight and scrutiny”(더 많은 감독과 검증이 따른다는 점이 다르다)라고 썼습니다. 그가 선호하는 이름은 에이전틱 엔지니어링(agentic engineering)입니다.

‘에이전틱’인 이유는 “you are not writing the code directly 99% of the time, you are orchestrating agents who do and acting as oversight”(99%의 경우 코드를 직접 쓰지 않고, 코드를 쓰는 에이전트를 지휘하며 감독하는 역할을 한다)이기 때문입니다. ‘엔지니어링’인 이유는 “there is an art & science and expertise to it”(여기에는 기술과 과학, 전문성이 있다), 즉 배울 수 있는 것이기 때문입니다.

실제로는 에이전트가 코드를 쓰고, 테스트를 실행하고, 변경을 제안합니다. 사람은 목표를 정하고, 작업을 에이전트가 끝낼 수 있는 단위로 나누고, diff를 읽고, 무엇을 배포할지 결정하고, 그에 대해 책임집니다.

고객은 코드를 사는 것이 아닙니다. 코드가 작동하고, 안전하고, 누군가 그 뒤를 책임진다는 확신을 삽니다. 그중 어느 것도 에이전트에게 넘어가지 않습니다.

품질은 모델이 아니라 리뷰에서 나옵니다. 1분에 100줄을 쓰는 에이전트는 누군가 확인해야 할 100줄도 함께 씁니다.

책임은 청구서에 서명하는 사람에게 남습니다. “에이전트가 한 일입니다”는 고객이 받아들이는 답이 아닙니다.

새로운 것은 추적 가능성입니다. 에이전트가 고객 프로젝트에서 한 시간 동안 실행되었다면, 고객은 그것이 청구되었다는 사실만이 아니라 에이전트가 무엇을 했는지도 볼 수 있어야 합니다.

사람이 코드를 직접 타이핑하던 동안에는 시간이 공정한 대리 지표였습니다. 에이전트와 일하면 작업 시간과 공수가 서로 어긋납니다.

5분의 프롬프트가 한 시간의 에이전트 작업을 일으키고, 그 뒤에 15분의 리뷰가 이어집니다. 여러 프로젝트가 동시에 진행됩니다. 그리고 시간 단위로 청구하는 사람은 더 짧은 시간에 더 많이 해낼 때 오히려 덜 법니다.

그렇다고 공수가 의미 없어지는 것은 아닙니다. 시간 단위로 청구하는 비중이 줄수록, 프로젝트에 실제로 무엇이 들어갔는지 더 잘 알아야 합니다. 고정가라면 수지가 맞았는지 보기 위해, 시간제 정산이라면 공수를 빠짐없이, 고객이 이해할 수 있게 넘기기 위해서입니다.

• 공수: 프로젝트별 작업 시간, 에이전트의 활성 실행 시간, 에이전트가 쓴 토큰.
• 진행 상황: 각 세션이 무엇에 관한 것이었고 어떤 커밋이 나왔는지.
• 가치: 공수 기준으로 청구하든 고정가로 청구하든, 프로젝트에 들어간 것 대비 프로젝트의 가치.

바이브 코딩은 그 실체대로 팔 수 있습니다. 프로토타입, 목업, 아무도 코드를 유지보수하지 않을 실험으로서입니다. 견적서에 그렇게 명시하십시오.

고객이 운영하고, 확장하고, 의존할 소프트웨어는 다른 제품입니다. 그것은 에이전틱 엔지니어링이며, 엔지니어링처럼 청구하고 문서화합니다.