‘바이브 코딩’과 대비되는 ‘바이브 엔지니어링’을 제안하며, LLM과 코딩 에이전트를 활용해 생산 소프트웨어를 빠르게 만들면서도 품질과 책임을 지키기 위해 필요한 관행과 역량을 정리한다.
2025년 10월 7일
저는 바이브 코딩이 이제 AI로 소프트웨어를 만드는 빠르고, 느슨하며, 책임감 없는 방식—완전히 프롬프트 중심이고 코드가 실제로 어떻게 동작하는지는 신경 쓰지 않는—을 가리키는 개념으로 꽤 자리 잡았다고 느낍니다. 그렇다면 용어의 공백이 생깁니다. 반대편 끝, 즉 노련한 전문가들이 LLM으로 작업을 가속하면서도 자신이 만든 소프트웨어에 당당하게 책임을 지는 방식을 우리는 뭐라고 불러야 할까요?
저는 이를 바이브 엔지니어링이라고 부르자고 제안합니다. 반쯤은 농담이지만요.
장난감 수준이 아닌 프로젝트에서 소프트웨어 엔지니어로서 LLM과 생산적으로 일하는 데 대해 잘 드러나지 않는 사실 중 하나는, 이게 _어렵다_는 점입니다. 도구를 어떻게 써야 하는지 이해하는 데 깊이가 필요하고, 피해야 할 함정도 많으며, LLM이 작동하는 코드를 쏟아내는 속도가 인간 참여자가 기여해야 할 수준의 기준을 높여 버립니다.
코딩 에이전트의 부상—Claude Code(2025년 2월 출시), OpenAI의 Codex CLI(4월), Gemini CLI(6월)처럼 목표를 달성할 때까지 코드를 반복적으로 테스트하고 수정해 나가는 도구들—은 현실 세계의 코딩 문제에서 LLM의 유용성을 극적으로 끌어올렸습니다.
경험 많고 신뢰할 수 있는 소프트웨어 엔지니어들이 동시에 여러 개의 에이전트를 돌려 병렬로 여러 문제를 해결하며 자신의 작업 영역을 넓혀 가고 있다는 이야기를 점점 더 자주 듣습니다. 처음엔 회의적이었지만 저도 이제 여러 에이전트를 병렬로 돌려 보고 있는데, 정신적으로는 피곤하지만 놀랄 만큼 효과적입니다!
이건 고전적인 바이브 코딩과는 아주 다르게 느껴집니다. 바이브 코딩에서는 간단하고 리스크가 낮은 일을 LLM에 외주 주고, 겉보기에 잘 동작하면 결과를 받아들이죠. 제 tools.simonwillison.net 모음의 대부분(이전에)은 그렇게 만들어졌습니다. 반면, 코딩 에이전트와 함께 반복해가며 앞으로도 제가 자신 있게 유지보수할 수 있는 프로덕션 품질의 코드를 만드는 일은 전혀 다른 과정처럼 느껴집니다.
또한 LLM은 기존의 최상급 소프트웨어 엔지니어링 관행을 적극적으로 보상한다는 점도 분명해졌습니다.
이 새로운 도구들의 역량을 제대로 활용하려면, 당신은 _최상의 컨디션_으로 운영되어야 합니다. 코드를 쓰는 것만이 책임이 아닙니다—접근법을 조사하고, 고수준 아키텍처를 결정하고, 명세를 작성하고, 성공 기준을 정의하고, 에이전트 루프를 설계하고, QA를 계획하고, 기회를 주면 분명 편법을 쓸 그 기묘한 디지털 인턴 군단을 관리하며, 코드 리뷰에 정말 많은 시간을 씁니다.
이 모든 것의 거의 전부는 이미 시니어 소프트웨어 엔지니어의 특성입니다!
AI 도구는 기존 전문성을 증폭합니다. 소프트웨어 엔지니어로서 보유한 기술과 경험이 많을수록, LLM과 코딩 에이전트로부터 더 빠르고 더 좋은 결과를 얻을 수 있습니다.
이름이 바보 같냐고요? 아마 그렇습니다. AI에서의 “바이브”라는 개념은 이제 좀 진부하게 느껴지기도 합니다. “바이브 코딩”이라는 말 자체도 많은 개발자에게 비꼬는 표현으로 쓰이죠. 저는 더 건설적인 의미로 바이브를 되찾을 준비가 되어 있습니다.
저는 “코더”와 “엔지니어” 사이의 인위적인 구분을 그리 좋아하지 않습니다—약간의 게이트키핑 냄새가 나거든요. 하지만 이번만큼은 약간의 게이트키핑이 우리에게 꼭 필요합니다!
바이브 엔지니어링은 바이브 코딩과 명확히 구분됩니다. 이는 프로덕션 소프트웨어를 만들기 위해 AI 도구를 다루는 전혀 다른, 더 어렵고 더 정교한 방식이라는 신호이기도 합니다.
이 표현이 짓궂고 논쟁적일 가능성이 있다는 점이 좋습니다. 이 영역 전반이 여전히 여러 면에서 우스꽝스럽죠. 이 새로운 도구들을 가장 생산적으로 적용하는 법을 찾아가는 동안, 너무 심각할 필요는 없습니다.
예전에 AI 보조 프로그래밍 같은 용어를 유행시키려 해 봤지만, 성공률은 사실상 제로였죠. 이왕이면 바이브를 좀 발라 보고 어떻게 되는지 지켜보려 합니다.
또 “바이브”와 “엔지니어링” 사이의 선명한 부조화도 마음에 듭니다. 두 단어가 결합됐을 때 생기는 자기모순은 어딘가 장난스럽고, (바라건대) 기억에 오래 남을 만합니다.