에이전틱 엔지니어링

1년 전, Andrej Karpathy는 통쾌할 정도로 무모한 프로그래밍 방식을 묘사하며 "바이브 코딩(vibe coding)"이라는 표현을 만들었다. 프롬프트를 던지고, AI에 키보드를 넘기고, AI가 뱉어내는 결과물을 그대로 수용하고, diff를 읽지도 않고, 에러 메시지가 나오면 다시 붙여넣어 반복하는 방식이다. 실제로 존재하는 현상을 정확히 짚어낸 훌륭한 이름이었다 — 순전히 AI에 맡겨서 빠른 프로토타입이나 MVP를 만들어내는 것.

문제는 "바이브 코딩"이 만능 용어처럼 쓰이기 시작했다는 점이다. 이제 사람들은 주말에 가볍게 만드는 사이드 프로젝트부터, 사람의 감독 아래 AI 에이전트가 구현을 담당하는 체계적인 엔지니어링 워크플로까지 전부 바이브 코딩이라 부른다. 본질적으로 완전히 다른 활동인데, 이를 하나로 뭉뚱그리면서 진짜 혼란이 — 그리고 진짜 피해가 생기고 있다.

바이브 코딩이란 실제로 무엇인가

바이브 코딩은 말 그대로 분위기 따라 가는 것, 그리고 코드를 검토하지 않는 것이다. 이것이 핵심 특징이다. 프롬프트를 쓰고, 결과를 받아들이고, 실행해보고, 되는지 확인한다. 안 되면 에러를 다시 붙여넣고 재시도한다. 계속 프롬프트만 날린다. 여기서 사람의 역할은 엔지니어가 아니라 프롬프트 DJ에 가깝다.

이 방식이 진짜 유용한 경우가 있다:

• 처음부터 새로 만드는 MVP, 프로토타입, 해커톤 데모. 일요일까지 돌아가는 무언가가 필요하다. 코드 품질은 상관없다.
• 개인 스크립트나 일회성 도구. 사용자가 나뿐이다. 망가지면 다시 생성하면 된다.
• 학습과 탐색. 입문자도 혼자서는 만들기 어려운 것을 AI 결과물을 보며 예제 학습 방식으로 만들어볼 수 있다.
• 창의적 브레인스토밍. 의도적으로 과잉 생성해서 AI가 어떤 접근법을 제안하는지 살펴본 뒤, 전부 버리고 제대로 새로 만드는 것이다.

바이브 코딩 덕분에 기존에는 소프트웨어를 직접 만들 수 없었던 수백만 명이 맞춤 소프트웨어를 만들 수 있게 된다면, 그것만으로도 분명한 가치가 있다. 도구 상자에서 나름의 자리를 차지할 자격이 충분하다.

하지만 실패 양상은 이 시점에서 이미 충분히 기록되어 있다. 패턴은 항상 같다. 데모에서는 훌륭하다가, 현실이 찾아온다. 수정하려 하거나, 확장하려 하거나, 보안을 적용하려 하면, 코드가 실제로 무슨 일을 하는지 아무도 이해하지 못한다는 사실을 깨닫게 된다. 어떤 엔지니어의 말처럼, "이건 엔지니어링이 아니라 기도다."

전문가 버전에는 더 나은 이름이 필요하다

핵심은 이거다. 이미 많은 숙련된 엔지니어가 코드 품질을 유지하면서도 AI를 통해 엄청난 생산성 향상 — 2배, 5배, 때로는 그 이상 — 을 얻고 있다. 그런데 이들의 작업 방식은 바이브 코딩과 전혀 닮지 않았다. 프롬프트를 쓰기 전에 먼저 스펙을 작성한다. 모든 diff를 꼼꼼히 검토한다. 테스트 스위트를 돌린다. AI를 빠르지만 믿을 수 없는 주니어 개발자처럼 취급하며 끊임없이 감독한다. 나는 개인적으로 "AI 보조 엔지니어링(AI-assisted engineering)"이라는 표현을 선호해왔고, 이 표현이 사람이 루프 안에 머무르는 스펙트럼의 끝을 잘 설명한다고 이야기해왔다.

Simon Willison(내가 매우 존경하는 분)은 이를 "바이브 엔지니어링(vibe engineering)"이라 부르자고 제안했다 — "바이브"를 되살리면서 "엔지니어링"을 붙여 규율을 강조하려는 의도였다. 하지만 커뮤니티에서 몇 달간 논쟁을 지켜본 결과, "바이브"라는 단어에는 짐이 너무 많다는 생각이 들었다. 가볍고 느슨한 느낌을 풍긴다. CTO에게 결제 시스템을 "바이브 엔지니어링"하고 있다고 말하면, 그 얼굴에 떠오르는 우려를 직접 볼 수 있을 것이다.

이번 주 Andrej Karpathy가 "에이전틱 엔지니어링(agentic engineering)"이라는 표현을 제안했고, 나는 이게 맞다는 느낌이 든다.

이 표현이 적절한 이유는 아마 이런 것들일 것이다:

실제 일어나는 일을 그대로 묘사한다. 코드를 실행하고, 테스트하고, 개선할 수 있는 코딩 어시스턴트 — 즉 AI 에이전트 — 를 오케스트레이션하면서, 자신은 아키텍트이자 리뷰어이자 의사결정자 역할을 맡는 것이다. 직접 손으로 작성하는 코드는 일부에 불과할 수 있다. 나머지는 에이전트가 지시에 따라 만들어낸다. 그것이 "에이전틱"이다. 그리고 그 전 과정에 엔지니어링 규율을 적용한다. 그것이 "엔지니어링"이다.

전문적인 맥락에서 자연스럽다. "에이전틱 엔지니어링"은 들리는 그대로를 의미한다: 자율 에이전트를 활용하는 진지한 엔지니어링 분야. VP of Engineering 앞에서 말해도 민망하지 않다. 채용 공고에 넣을 수 있다. 팀의 업무 방식으로 정립할 수 있다.

깔끔한 경계선을 긋는다. 바이브 코딩 = 무모한 도전(YOLO). 에이전틱 엔지니어링 = AI가 구현하고, 사람이 아키텍처·품질·정확성을 책임진다. 용어 자체가 이 구분을 명확히 해준다.

에이전틱 엔지니어링의 실제 모습

워크플로 자체는 복잡하지 않다. 다만 바이브 코딩이 명시적으로 내던진 규율이 필요하다:

계획에서 시작한다. 프롬프트를 쓰기 전에 설계 문서나 스펙을 작성한다 — 이 과정에서도 AI를 활용할 수 있다. 작업을 명확하게 정의된 단위로 쪼갠다. 아키텍처를 결정한다. 바이브 코딩에서 건너뛰는 것이 바로 이 부분이고, 프로젝트가 산으로 가는 지점도 정확히 여기다.

지시하고, 검토한다. 계획에서 도출한 범위가 명확한 작업을 AI 에이전트에 할당한다. 에이전트가 코드를 생성한다. 그 코드를 동료의 PR에 적용하는 것과 같은 수준의 엄밀함으로 리뷰한다. 어떤 모듈이 무슨 일을 하는지 설명할 수 없다면, 반영하지 않는다.

집요하게 테스트한다. 에이전틱 엔지니어링과 바이브 코딩을 가르는 가장 큰 차이점은 테스트다. 견고한 테스트 스위트가 있으면, AI 에이전트는 테스트를 통과할 때까지 루프 안에서 반복하며 결과에 대한 높은 확신을 준다. 테스트가 없으면, 에이전트는 깨진 코드를 놓고도 거침없이 "완료"라고 선언한다. 테스트는 신뢰할 수 없는 에이전트를 신뢰할 수 있는 시스템으로 바꿔주는 핵심 장치다.

코드베이스에 대한 주인의식을 갖는다. 문서를 관리하고, 버전 관리와 CI를 사용하고, 프로덕션을 모니터링한다. AI가 작업 속도를 높여주지만, 시스템에 대한 책임은 사람에게 있다.

이 방식을 잘 실천하는 팀은 개발 속도가 빨라졌다고 보고하는 경우가 많은데, 그 이점은 탄탄한 프로세스를 보강한 결과이지, 프로세스를 버린 덕이 아니다. AI가 보일러플레이트와 단순 반복 작업을 처리한다. 사람은 아키텍처, 정확성, 엣지 케이스, 장기적인 유지보수성에 집중한다.

아이러니하게도 AI 보조 개발은 전통적인 코딩보다 오히려 좋은 엔지니어링 관행에 더 큰 보상을 준다. 스펙이 정교할수록 AI의 결과물이 좋아진다. 테스트가 포괄적일수록 더 과감하게 위임할 수 있다. 아키텍처가 깔끔할수록 AI가 이상한 추상화를 환각(hallucinate)하는 빈도가 줄어든다. 어떤 분석이 정확히 짚었듯이, "문제를 일으킨 건 AI가 아니라, 설계 사고를 생략한 것이다."

이전부터 논의해온 역량 격차 문제

현장에서 드러나는 불편한 진실이 있다. 에이전틱 엔지니어링은 시니어 엔지니어에게 압도적으로 유리하다. 시스템 설계, 보안 패턴, 성능 트레이드오프에 대한 깊은 기본기가 있다면, AI를 강력한 전력 증폭기로 활용할 수 있다. 좋은 코드가 어떤 모습인지 알고 있기에, AI 결과물을 효율적으로 리뷰하고 교정할 수 있다.

반면 주니어가 기본기를 쌓기 전에 AI에 의존하면, 위험한 역량 퇴화(skill atrophy)에 빠질 수 있다. 이해하지 못한 채 코드를 만들어낼 수 있다. 특정 패턴이 왜 존재하는지 배우지 않은 채 기능을 배포할 수 있다. 여러 엔지니어링 리더가 이를 새롭게 부상하는 위기로 경고하고 있다 — 프롬프트는 쓸 줄 알지만 디버깅은 못하고, 코드를 생성할 줄은 알지만 자신이 생성한 코드에 대해 추론하지 못하는 개발자 세대가 나타날 수 있다는 것이다.

이것은 AI 보조 개발에 반대하는 주장이 아니다. AI 보조 개발이 무엇을 요구하는지 솔직해지자는 주장이다. 에이전틱 엔지니어링은 전통적 엔지니어링보다 쉬운 게 아니라, 어려운 지점이 다른 것이다. 타이핑 시간 대신 리뷰 시간이 늘어나고, 구현 노력 대신 오케스트레이션 역량이 필요해지고, 코드를 쓰는 일 대신 코드를 읽고 평가하는 일이 핵심이 된다. 기본기의 중요성은 줄어드는 게 아니라 오히려 커진다.

앞으로 나아갈 방향

방향은 분명하다. AI 에이전트는 점점 더 강력해지고 있고, 에이전틱 엔지니어링 워크플로는 갈수록 더 많은 전문 개발자에게 기본 방식으로 자리잡고 있다. 이 흐름은 가속화될 것이다.

우리에게 필요한 것은 다음과 같다:

• 솔직한 용어 사용. 사람의 감독 아래 에이전트를 활용하는 체계적 개발을 뜻할 때는 에이전틱 엔지니어링이라 부르자. 가볍고 무모하게, 프로토타이핑 용도로만 쓰는 방식을 뜻할 때는 바이브 코딩이라 부르자. 하나의 용어로 둘 다 지칭하는 일은 그만둬야 한다.
• 더 나은 평가 프레임워크. AI 보조 워크플로가 단지 빠른 소프트웨어가 아니라, 실제로 신뢰할 수 있는 소프트웨어를 만들어내고 있는지 체계적으로 측정할 방법이 필요하다.
• 기본기에 대한 투자. AI가 구현의 더 많은 부분을 담당할수록, 아키텍처 사고, 보안 인식, 시스템 설계에 대한 프리미엄은 줄어드는 것이 아니라 높아진다. 교육 프로그램도 이에 맞춰 변해야 한다.

AI 코딩의 부상은 소프트웨어 엔지니어링의 장인정신을 대체하지 않는다 — 그 기준을 높인다. 앞으로 성장할 개발자는 프롬프트를 가장 빠르게 치는 사람이 아니다. 무엇을 왜 만드는지 가장 명확하게 사고하고, AI 에이전트를 포함한 모든 도구를 활용해 제대로 만들어내는 사람이다.

바이브 코딩은 모든 관례를 내려놓으면 무엇이 가능한지 보여주었다.

이제는 엔지니어링을 되찾아올 차례다. 그것을 있는 그대로 부르자.

---

O'Reilly에서 새 책 Beyond Vibe Coding을 출간했다. AI 보조(그리고 에이전틱) 엔지니어링을 위한 실용적 프레임워크를 더 깊이 다룬다. 각자의 워크플로에서 이 방식을 실험해오고 있다면, 어떤 것이 효과가 있었는지 꼭 듣고 싶다.