‘바이브 코딩’과는 구별되는, 인간의 감독 아래 AI 에이전트를 오케스트레이션하며 품질을 유지하는 전문적 개발 방식을 ‘에이전틱 엔지니어링’으로 부르자는 제안과 그 실천 방식, 요구되는 역량을 정리한다.
홈GitHub보도자료약력LinkedInTwitter뉴스레터블로그
1년 전 Andrej Karpathy는 “바이브 코딩(vibe coding)”이라는 말을 만들어, 즐겁고도 무모한 방식의 프로그래밍을 묘사했습니다. 프롬프트를 던지고, 키보드를 AI에게 넘긴 뒤, AI가 뱉어내는 것을 전부 받아들이고, 변경(diff)을 읽지 않은 채, 에러 메시지를 다시 붙여넣으며 반복하는 방식이죠. 순수하게 AI 오토파일럿에 맡겨 빠른 프로토타입이나 MVP를 만드는 ‘실제 존재하는 것’에 딱 맞는 훌륭한 라벨이었습니다.
문제는 “바이브 코딩”이 이제는 여행가방 같은(모든 걸 담아버리는) 용어가 되어버렸다는 점입니다. 사람들은 주말 해킹부터, AI 에이전트가 인간의 감독 아래 구현을 담당하는 규율 잡힌 엔지니어링 워크플로까지 전부를 이 말로 부릅니다. 하지만 이는 근본적으로 서로 다른 활동이며, 이를 혼동하면서 실제 혼란—그리고 실제 피해—가 생기고 있습니다.
바이브 코딩이란 분위기(바이브)에 몸을 맡기고 코드를 리뷰하지 않는 것을 뜻합니다. 이것이 정의적인 특징입니다. 프롬프트를 던지고, 받아들이고, 실행하고, 동작하는지 봅니다. 동작하지 않으면 에러를 다시 붙여넣고 또 시도합니다. 계속 프롬프트를 던집니다. 인간은 엔지니어가 아니라 프롬프트 DJ가 됩니다.
이 방식은 다음과 같은 경우에 정말 유용합니다:
바이브 코딩이 수백만 명에게—그렇지 않았다면 불가능했을—맞춤형 소프트웨어를 만들 능력을 준다면, 그것은 진짜 승리입니다. 이 기법은 도구상자 안에서 정당한 자리를 갖습니다.
하지만 실패 양상도 이제는 충분히 문서화되었습니다. 패턴은 늘 같습니다. 데모는 훌륭한데, 현실이 닥치면 문제가 터집니다. 이를 수정하거나, 확장하거나, 보안 강화하려 하면, 아무도 코드가 실제로 무엇을 하는지 이해하지 못한다는 사실을 깨닫게 됩니다. 한 엔지니어의 표현처럼, “이건 엔지니어링이 아니라 희망(hope)이다.”
여기서 핵심은 이것입니다. 많은 숙련 엔지니어들이 지금 AI로 엄청난 생산성 향상—2배, 5배, 때로는 그 이상—을 얻고 있으면서도 코드 품질을 유지하고 있습니다. 하지만 그들이 일하는 방식은 바이브 코딩과 전혀 닮지 않았습니다. 그들은 프롬프트를 던지기 전에 명세(spec)를 작성합니다. 모든 diff를 리뷰합니다. 테스트 스위트를 실행합니다. AI를 빠르지만 신뢰할 수 없는 주니어 개발자처럼 대하며, 지속적인 감독이 필요하다고 봅니다. 저는 개인적으로 “AI 보조 엔지니어링(AI-assisted engineering)”을 좋아했고, 인간이 루프 안에 남아 있는 스펙트럼의 그쪽 끝을 설명하는 용어로 이야기해 왔습니다.
제가 사랑하는 Simon Willison은 이를 위해 “바이브 엔지니어링(vibe engineering)”을 제안했습니다. “vibe”를 되찾되 “engineering”을 붙여 규율을 강조하는 방식이죠. 하지만 커뮤니티가 몇 달간 이 용어를 두고 논쟁하는 걸 지켜본 뒤, 저는 “vibe”라는 단어가 너무 많은 짐(뉘앙스)을 지고 있다고 생각하게 됐습니다. 가벼움을 연상시킵니다. CTO에게 결제 시스템을 “바이브 엔지니어링”으로 만들고 있다고 말하면, 얼굴에 드리워지는 걱정을 볼 수 있습니다.
Andrej Karpathy는 이번 주 “에이전틱 엔지니어링(agentic engineering)”을 제안했고, 저는 이게 마음에 듭니다.
아마도 이 용어가 잘 작동하는 이유는 다음과 같습니다:
실제로 벌어지는 일을 정확히 묘사한다. 당신은 실행·테스트·개선을 수행할 수 있는 코딩 어시스턴트(에이전트)들을 오케스트레이션하고, 당신은 아키텍트·리뷰어·의사결정자로 행동합니다. 손으로 직접 쓰는 코드는 일부(%)일 수 있습니다. 나머지는 당신의 지휘 아래 에이전트들이 만들어냅니다. 이것이 agentic(에이전트적)입니다. 그리고 그 과정 전반에 엔지니어링 규율을 적용합니다. 그것이 engineering(엔지니어링)입니다.
전문적으로 ‘말이 된다’. “에이전틱 엔지니어링”은 그 자체로 의미가 드러납니다. 자율 에이전트를 포함하는 진지한 엔지니어링 분야처럼 들립니다. 엔지니어링 VP에게 말해도 민망하지 않습니다. 직무기술서에 넣을 수도 있습니다. 팀의 실천(practice)으로 구축할 수도 있습니다.
명확한 선을 긋는다. 바이브 코딩 = YOLO. 에이전틱 엔지니어링 = AI가 구현을 하고, 인간이 아키텍처·품질·정확성을 책임진다. 용어 자체가 그 구분을 강제합니다.
워크플로 자체는 복잡하지 않지만, 바이브 코딩이 명시적으로 버리는 규율을 요구합니다:
계획으로 시작한다. 무엇이든 프롬프트하기 전에 설계 문서나 명세를 작성합니다(때로는 AI의 도움을 받기도 함). 작업을 잘 정의된 태스크로 쪼갭니다. 아키텍처를 결정합니다. 바이브 코더들이 건너뛰는 부분이고, 프로젝트가 탈선하는 바로 그 지점입니다.
지시하고, 그다음 리뷰한다. 계획에서 잘 범위가 잡힌 태스크 하나를 AI 에이전트에 줍니다. 에이전트가 코드를 생성합니다. 그 코드를 사람 팀원의 PR을 리뷰하듯 동일한 엄격함으로 리뷰합니다. 어떤 모듈이 무엇을 하는지 설명할 수 없다면, 그 코드는 들어가면 안 됩니다.
무자비하게 테스트한다. 에이전틱 엔지니어링과 바이브 코딩의 가장 큰 차이는 테스트입니다. 탄탄한 테스트 스위트가 있으면, AI 에이전트는 테스트가 통과할 때까지 루프를 돌며 반복할 수 있고, 결과에 대해 높은 신뢰를 제공합니다. 테스트가 없으면, 망가진 코드 위에서도 태연히 “완료”라고 선언할 것입니다. 테스트는 신뢰할 수 없는 에이전트를 신뢰할 수 있는 시스템으로 바꾸는 방법입니다.
코드베이스의 주인은 당신이다. 문서를 유지합니다. 버전 관리와 CI를 사용합니다. 프로덕션을 모니터링합니다. AI는 일을 가속하지만, 시스템에 대한 책임은 당신에게 있습니다.
이걸 잘하는 팀들은 종종 더 빠른 개발 속도를 보고합니다—그리고 그 이득은 프로세스를 버려서가 아니라, 탄탄한 프로세스를 증강(augment)해서 얻는 것입니다. AI는 보일러플레이트와 잡무를 처리합니다. 인간은 아키텍처, 정확성, 엣지 케이스, 장기적 유지보수성에 집중합니다.
아이러니하게도, AI 보조 개발은 전통적인 코딩보다 좋은 엔지니어링 관행에 더 큰 보상을 줍니다. 명세가 좋을수록 AI 출력이 좋아집니다. 테스트가 포괄적일수록 더 자신 있게 위임할 수 있습니다. 아키텍처가 깔끔할수록 AI가 이상한 추상화를 환각(hallucinate)할 가능성이 줄어듭니다. 한 분석에서 말했듯, “문제를 만든 건 AI가 아니라, 설계 사고를 건너뛴 것이었다.”
현장에서 마주하는 불편한 진실이 있습니다. 에이전틱 엔지니어링은 시니어 엔지니어에게 불균형적으로 유리합니다. 시스템 설계, 보안 패턴, 성능 트레이드오프를 이해하는 등 기초가 탄탄하다면, AI를 엄청난 ‘힘의 배수기(force multiplier)’로 활용할 수 있습니다. 좋은 코드가 어떤 모습인지 알기 때문에 AI 출력물을 효율적으로 리뷰하고 교정할 수 있습니다.
하지만 주니어가 그런 기초를 쌓기 전에 AI에 기대면, 위험한 기술 퇴화(skill atrophy)로 이어질 수 있습니다. 이해하지 못한 채 코드를 만들어낼 수 있고, 특정 패턴이 왜 존재하는지 배우지 못한 채 기능을 출시할 수 있습니다. 여러 엔지니어링 리더들이 이를 새로운 위기로 지적했습니다. 프롬프트는 할 수 있지만 디버깅은 못 하고, 생성은 하지만 자신이 생성한 것을 추론하지 못하는 개발자 세대가 생길 수 있다는 것입니다.
이는 AI 보조 개발에 대한 반대가 아닙니다. 그것이 요구하는 바를 솔직히 보자는 주장입니다. 에이전틱 엔지니어링은 전통적 엔지니어링보다 쉬운 것이 아니라—다른 종류의 어려움입니다. 타이핑 시간을 리뷰 시간으로, 구현 노력을 오케스트레이션 능력으로, 코드를 쓰는 일을 코드를 읽고 평가하는 일로 바꾸는 것입니다. 기초는 덜 중요한 게 아니라, 더 중요해집니다.
흐름은 분명합니다. AI 에이전트는 더 유능해지고 있고, 에이전틱 엔지니어링 워크플로는 점점 더 많은 전문 개발자들에게 기본값이 되어가고 있습니다. 이는 더 가속될 것입니다.
우리에게 필요한 것들:
AI 코딩의 부상은 소프트웨어 엔지니어링이라는 장인정신을 대체하지 않습니다—그 기준을 높입니다. 살아남는 개발자는 가장 빨리 프롬프트하는 사람이 아니라, 무엇을 왜 만들고 있는지 가장 명확하게 사고하고, 그다음 AI 에이전트를 포함한 모든 도구를 사용해 그것을 잘 만들어내는 사람들일 것입니다.
바이브 코딩은 모든 관습을 내려놓으면 무엇이 가능한지 보여주었습니다.
이제는 엔지니어링을 다시 가져올 때입니다. 그것을 있는 그대로 부릅시다.
O’Reilly와 함께 새 책 Beyond Vibe Coding을 썼습니다. AI 보조(그리고 에이전틱) 엔지니어링을 위한 실천적 프레임워크를 더 깊게 다룹니다. 여러분의 워크플로에서 이를 직접 풀어가고 있다면, 무엇이 효과적인지 꼭 듣고 싶습니다.
Addy Osmani는 Google에서 Google Cloud와 Gemini를 담당하는 소프트웨어 엔지니어다.트윗BlueskyMastodonThreadsLinkedIn공유
더 많은 글을 원하시나요? 무료 뉴스레터를 구독하세요:
