Agentic Engineering
TMT1년 전, Andrej Karpathy는 “vibe coding”이라는 표현을 만들어, 다음과 같은 다소 무모하지만 즐거운 프로그래밍 방식을 설명했습니다. 프롬프트를 던지고, 키보드를 AI에게 넘기고, AI가 뱉는 코드를 전부 그대로 받아들이고, diff는 읽지 않으며, 에러 메시지를 다시 붙여 넣으면서 반복하는 식이죠. 순수하게 AI 자동 조종 모드로 빠르게 프로토타입이나 MVP를 만드는 실제 방식을 아주 잘 포착한 용어였습니다.
문제는 지금 “vibe coding”이 짐 가방 같은 단어가 되어버렸다는 점입니다. 주말 해커톤 작업부터, AI 에이전트가 인간의 관리 하에 구현을 처리하는 매우 엄격한 엔지니어링 워크플로우까지, 온갖 것을 다 묶어서 부르는 말이 되어버렸습니다. 하지만 이건 근본적으로 서로 다른 활동이고, 이 둘을 뒤섞어 부르는 것이 실제로 혼란을 낳고 있고, 실제 피해도 만들고 있습니다.
vibe coding이 실제로 의미하는 것
Vibe coding은 감에 따라 가는 것이고, 코드를 검토하지 않는 것을 의미합니다. 그게 이 방식의 본질적인 특징입니다. 프롬프트를 던지고, 결과를 그대로 받아서, 실행해보고, 돌아가는지만 확인합니다. 돌아가지 않으면 에러를 다시 붙여 넣고 다시 시도합니다. 이걸 계속 반복합니다. 사람은 엔지니어가 아니라 프롬프트 DJ에 가깝습니다.
이 방식이 실제로 유용한 경우는 다음과 같습니다:
- 그린필드 MVP, 프로토타입, 해커톤 데모. 일요일까지 뭔가 돌아가는 걸 만들어야 할 때. 코드 품질은 중요하지 않습니다.
- 개인용 스크립트와 1회성 도구. 사용자도 나 혼자라서, 망가지면 다시 생성하면 그만인 경우.
- 학습과 탐색. 입문자가 스스로는 절대 못 만들 것 같은 것을 AI 출력물을 예제로 삼아 만들면서 배우는 경우.
- 창의적 브레인스토밍. 의도적으로 과하게 여러 버전을 뽑아보며 AI가 제안하는 접근들을 살펴본 다음, 그걸 버리고 제대로 다시 만드는 경우.
Vibe coding 덕분에 수많은 사람이, 원래라면 불가능했을 커스텀 소프트웨어를 만들 수 있게 된다면, 그건 분명한 이득입니다. 이 기법은 실제로 유효한 도구 상자의 한 칸입니다.
하지만 이 방식의 실패 패턴은 이제 널리 알려져 있습니다. 흐름은 항상 비슷합니다. 데모할 때는 끝내주다가, 현실이 나타납니다. 수정을 하거나, 확장하거나, 보안을 강화하려고 하면, 아무도 이 코드가 실제로 무엇을 하는지 이해하지 못했다는 사실을 깨닫게 됩니다. 한 엔지니어의 말처럼, “이건 엔지니어링이 아니라, 그냥 잘 되기만을 비는 거예요.”
전문적인 버전을 위한 더 나은 용어가 필요하다
중요한 점은, 지금 많은 경험 많은 엔지니어들이 AI로부터 엄청난 생산성 향상—2배, 5배, 때로는 그 이상—을 얻고 있다는 것입니다. 그런데 이들이 일하는 방식은 vibe coding과는 전혀 다릅니다. 프롬프트를 던지기 전에 명세를 쓰고, 모든 diff를 리뷰하고, 테스트 스위트를 돌립니다. AI를 빠르지만 신뢰할 수 없는 주니어 개발자 정도로 보고, 계속해서 감독해야 하는 대상으로 취급합니다. 저는 개인적으로 “AI-assisted engineering(이하 AI 보조 엔지니어링)”이라는 표현을 좋아했고, 사람이 루프 안에 남아 있는 스펙트럼의 한쪽 끝을 설명하는 용어로 이야기해왔습니다.
제가 진심으로 좋아하는 Simon Willison은, 이를 위해 “vibe engineering”이라는 표현을 제안했습니다. “vibe”라는 단어를 다시 가져오면서도, “engineering”을 붙여서 규율이 있다는 걸 강조하려고 한 것이죠. 하지만 커뮤니티가 몇 달 동안 이걸 두고 논쟁하는 걸 지켜본 뒤, 저는 “vibe”라는 단어에는 너무 많은 짐이 실려 있다고 생각하게 되었습니다. 이 단어는 대충, 가볍다는 뉘앙스를 줍니다. CTO에게 “당신네 결제 시스템을 vibe engineering 중입니다”라고 말하면, 그들의 얼굴에서 걱정이 읽힐 겁니다.
이번 주에 Andrej Karpathy가 “agentic engineering”이라는 표현을 제안했는데, 저는 이게 마음에 든다고 느끼는 중입니다.
왜 이 말이 잘 맞는지, 아마도 이유는 다음과 같습니다:
실제로 일어나고 있는 일을 잘 설명합니다. 당신은 AI 에이전트를 오케스트레이션하고 있습니다. 즉, 코드를 실행·테스트·개선할 수 있는 코딩 보조 에이전트를 다루며, 본인은 아키텍트이자 리뷰어, 의사결정자로 행동합니다. 직접 손으로 작성하는 코드는 전체의 몇 퍼센트에 불과할 수도 있습니다. 나머지는 당신의 지휘 아래 일하는 에이전트들이 만들어냅니다. 이건 agentic(에이전트 중심)한 상태입니다. 그리고 그 전 과정에 엔지니어링 규율을 적용합니다. 그게 engineering입니다.
전문적으로 읽히는 표현입니다. “Agentic engineering”은 그 말 그대로 들립니다. 자율 에이전트를 포함하는 진지한 엔지니어링 분야처럼요. 엔지니어링 VP에게도 주저 없이 말할 수 있고, 채용 공고에도 넣을 수 있고, 팀 단위의 실천 방식으로 삼을 수도 있습니다.
명확한 경계를 그어줍니다. Vibe coding = YOLO. Agentic engineering = 구현은 AI가 하되, 아키텍처, 품질, 정확성에 대한 책임은 사람이 가진다. 용어 자체가 이 구분을 강제합니다.
한쪽 끝에는 vibe coding, 다른 한쪽 끝에는 agentic engineering이 있고, 그 사이에 AI-assisted engineering이 놓여 있는 스펙트럼을 떠올려봅시다.
실무에서의 agentic engineering은 아마 이런 모습일 것이다
워크플로우 자체는 복잡하지 않지만, vibe coding이 일부러 버리는 규율을 요구합니다.
먼저 계획을 세웁니다. 아무 프롬프트도 치기 전에 설계 문서나 스펙을 씁니다. 이 과정은 때로는 AI의 도움을 받기도 합니다. 작업을 잘 정의된 태스크로 나누고, 아키텍처를 결정합니다. Vibe coder들이 건너뛰는 부분이 바로 여기이고, 프로젝트가 탈선하는 지점도 바로 이 부분입니다.
지시하고, 그 다음 리뷰합니다. 계획에서 잘 범위가 정의된 태스크를 하나 골라 AI 에이전트에게 줍니다. 그러면 에이전트는 코드를 생성합니다. 그 코드를 인간 팀원 PR을 리뷰할 때와 똑같은 수준의 엄격함으로 검토합니다. 특정 모듈이 무엇을 하는지 설명할 수 없다면, 그 코드는 코드베이스에 들어가서는 안 됩니다.
지독할 정도로 테스트합니다. Agentic engineering과 vibe coding을 가르는 가장 큰 차이는 바로 테스트입니다. 튼튼한 테스트 스위트가 있으면, AI 에이전트는 테스트가 통과할 때까지 루프를 돌며 수정할 수 있고, 그 결과에 대한 높은 신뢰를 얻을 수 있습니다. 테스트가 없다면, 에이전트는 깨진 코드를 만들어 놓고도 기쁜 표정으로 “완료”라고 선언할 겁니다. 테스트가 바로, 신뢰할 수 없는 에이전트를 신뢰할 수 있는 시스템으로 바꾸는 수단입니다.
코드베이스에 대한 소유권은 사람에게 있습니다. 문서를 유지 관리하고, 버전 관리와 CI를 사용하고, 프로덕션을 모니터링합니다. AI는 작업 속도를 높여줄 뿐이고, 시스템에 대한 책임은 당신에게 있습니다.
이걸 잘 해내는 팀은 종종 더 빠른 개발 속도를 보고합니다. 그리고 그 속도 향상은 기존 프로세스를 내던진 결과가 아니라, 탄탄한 프로세스를 증폭시킨 결과입니다. AI는 보일러플레이트와 잡일을 맡고, 사람은 아키텍처, 정확성, 엣지 케이스, 장기 유지보수성에 집중합니다.
아이러니하게도, AI 보조 개발은 전통적인 코딩보다도 오히려 좋은 엔지니어링 관행에 더 큰 보상을 줍니다. 스펙이 좋을수록 AI 출력도 좋아지고, 테스트가 촘촘할수록 더 안심하고 위임할 수 있습니다. 아키텍처가 깔끔할수록 AI가 이상한 추상화를 환각하는 일도 줄어듭니다. 어느 분석에서 이렇게 정리하기도 했습니다. “문제를 만든 건 AI가 아니라, 설계 고민을 생략한 것이었다.”
우리가 이야기해 온 스킬 갭
현장의 다소 불편한 진실 하나를 짚어보겠습니다. Agentic engineering은 시니어 엔지니어에게 훨씬 더 큰 이득을 줍니다. 시스템 설계, 보안 패턴, 성능 트레이드오프에 대한 깊은 기초가 있는 사람이라면, AI를 엄청난 힘의 증폭기로 활용할 수 있습니다. 좋은 코드가 어떤 모양인지 알고 있기 때문에, AI가 생성한 출력을 효율적으로 리뷰하고 수정할 수 있습니다.
반대로, 주니어가 이런 기초를 쌓기 전에 AI에 기대버리면 위험한 역량 위축에 빠지기 쉽습니다. 이해하지 못한 채 코드를 생산할 수 있고, 특정 패턴이 왜 존재하는지 배우지 못한 채 기능을 출시할 수 있습니다. 몇몇 엔지니어링 리더들은 이를 떠오르는 위기로 지적하고 있습니다. 프롬프트는 칠 수 있지만 디버그는 못 하는 세대, 생성은 할 수 있지만 자신이 생성한 것을 논리적으로 따져볼 수는 없는 세대 말입니다.
이건 AI 보조 개발에 대한 반대 주장이 아닙니다. 다만 이 방식이 실제로 요구하는 게 무엇인지 솔직해지자는 이야기입니다. Agentic engineering은 전통적인 엔지니어링보다 더 쉽지 않습니다. 종류가 다른 어려움일 뿐입니다. 타이핑 시간을 리뷰 시간으로, 구현 노력은 오케스트레이션 능력으로, 코드를 쓰는 일은 코드를 읽고 평가하는 일로 바꾸는 겁니다. 기본기가 덜 중요한 게 아니라, 더 중요해집니다.
여기서 어디로 가야 할까
궤적은 분명합니다. AI 에이전트의 역량은 계속 커지고 있고, agentic engineering 워크플로우는 점점 더 많은 프로 개발자에게 기본값이 되어가고 있습니다. 이 흐름은 가속될 것입니다.
우리가 필요한 것은 다음과 같습니다:
- 정직한 용어. 인간의 감독 아래 규율 있는 에이전트 보조 개발을 말하고 싶다면 agentic engineering이라고 부르십시오. 재미있고 무모한, 프로토타입 전용 방식을 말한다면 vibe coding이라고 부르십시오. 두 가지를 가리키는 데 같은 말을 쓰지 마십시오.
- 더 나은 평가 프레임워크. AI 보조 워크플로우가 단지 더 빠른 소프트웨어만이 아니라, 실제로 신뢰할 수 있는 소프트웨어를 만들어내고 있는지 체계적으로 측정할 수 있는 방법이 필요합니다.
- 기본기에 대한 투자. AI가 구현의 더 많은 부분을 맡을수록, 아키텍처적 사고, 보안 인식, 시스템 설계에 대한 프리미엄은 줄어들지 않고 오히려 커집니다. 교육·훈련 프로그램도 이 현실에 맞게 바뀌어야 합니다.
AI 코딩의 부상은 소프트웨어 엔지니어링이라는 장인의 일을 대체하지 않습니다. 오히려 그 기준을 끌어올립니다. 앞으로 살아남을 개발자는 프롬프트를 가장 빨리 치는 사람이 아닙니다. 무엇을 왜 만들고 있는지 가장 명료하게 생각할 수 있는 사람, 그리고 그 목표를 잘 달성하기 위해 사용할 수 있는 모든 도구—AI 에이전트를 포함해서—를 활용해 제대로 만들어내는 사람입니다.
Vibe coding은 우리가 모든 관습을 내려놓았을 때 어떤 일이 가능한지를 보여줬습니다.
이제 다시 엔지니어링을 되찾을 때입니다. 우리는 그걸 있는 그대로 부르기만 하면 됩니다.