바이브 엔지니어링

2025년 10월 7일

저는 바이브 코딩이 이제 AI로 소프트웨어를 만드는 빠르고, 느슨하며, 책임감 없는 방식—완전히 프롬프트 중심이고 코드가 실제로 어떻게 동작하는지는 신경 쓰지 않는—을 가리키는 개념으로 꽤 자리 잡았다고 느낍니다. 그렇다면 용어의 공백이 생깁니다. 반대편 끝, 즉 노련한 전문가들이 LLM으로 작업을 가속하면서도 자신이 만든 소프트웨어에 당당하게 책임을 지는 방식을 우리는 뭐라고 불러야 할까요?

저는 이를 바이브 엔지니어링이라고 부르자고 제안합니다. 반쯤은 농담이지만요.

장난감 수준이 아닌 프로젝트에서 소프트웨어 엔지니어로서 LLM과 생산적으로 일하는 데 대해 잘 드러나지 않는 사실 중 하나는, 이게 _어렵다_는 점입니다. 도구를 어떻게 써야 하는지 이해하는 데 깊이가 필요하고, 피해야 할 함정도 많으며, LLM이 작동하는 코드를 쏟아내는 속도가 인간 참여자가 기여해야 할 수준의 기준을 높여 버립니다.

코딩 에이전트의 부상—Claude Code(2025년 2월 출시), OpenAI의 Codex CLI(4월), Gemini CLI(6월)처럼 목표를 달성할 때까지 코드를 반복적으로 테스트하고 수정해 나가는 도구들—은 현실 세계의 코딩 문제에서 LLM의 유용성을 극적으로 끌어올렸습니다.

경험 많고 신뢰할 수 있는 소프트웨어 엔지니어들이 동시에 여러 개의 에이전트를 돌려 병렬로 여러 문제를 해결하며 자신의 작업 영역을 넓혀 가고 있다는 이야기를 점점 더 자주 듣습니다. 처음엔 회의적이었지만 저도 이제 여러 에이전트를 병렬로 돌려 보고 있는데, 정신적으로는 피곤하지만 놀랄 만큼 효과적입니다!

이건 고전적인 바이브 코딩과는 아주 다르게 느껴집니다. 바이브 코딩에서는 간단하고 리스크가 낮은 일을 LLM에 외주 주고, 겉보기에 잘 동작하면 결과를 받아들이죠. 제 tools.simonwillison.net 모음의 대부분(이전에)은 그렇게 만들어졌습니다. 반면, 코딩 에이전트와 함께 반복해가며 앞으로도 제가 자신 있게 유지보수할 수 있는 프로덕션 품질의 코드를 만드는 일은 전혀 다른 과정처럼 느껴집니다.

또한 LLM은 기존의 최상급 소프트웨어 엔지니어링 관행을 적극적으로 보상한다는 점도 분명해졌습니다.

• 자동화 테스트. 프로젝트에 견고하고 포괄적이며 안정적인 테스트 스위트가 있으면 에이전트형 코딩 도구는 그 위에서 날아다닙니다. 테스트가 없다고요? 에이전트가 실제로 테스트하지도 않고 동작한다고 주장할 수 있고, 새로운 변경이 관계없는 기능을 깨뜨려도 눈치채지 못할 수 있습니다. 루프를 돌며 반복하는 에이전트와는 테스트 우선 개발이 특히 효과적입니다.
• 사전 계획. 앉아서 뚝딱 만들어 보려 해도 먼저 고수준 계획부터 시작하면 훨씬 잘됩니다. 에이전트와 일할 때는 더 중요합니다—먼저 계획을 함께 다듬고, 그 다음에 그 계획을 에이전트에게 넘겨 코드를 쓰게 하세요.
• 포괄적인 문서화. 인간 프로그래머와 마찬가지로 LLM도 한 번에 코드베이스의 일부만 문맥에 담아둘 수 있습니다. 관련 문서를 공급할 수 있으면 코드를 읽지 않고도 다른 영역의 API를 사용할 수 있게 됩니다. 먼저 좋은 문서를 써 두면, 모델이 그 입력만으로도 일치하는 구현을 만들어 낼 수 있습니다.
• 건전한 버전 관리 습관. 실수를 되돌리고, 무엇이 언제 어떻게 바뀌었는지 이해하는 일은 코딩 에이전트가 변경을 했을 수도 있는 상황에서 더욱 중요합니다. LLM은 Git에도 대단히 능숙합니다—버그의 기원을 추적하기 위해 스스로 히스토리를 탐색할 수 있고, git bisect를 쓰는 솜씨는 대부분의 개발자보다 낫습니다. 이점을 활용하세요.
• 효과적인 자동화를 갖추기. 지속적 통합, 자동 포매팅과 린팅, 프리뷰 환경으로의 지속적 배포—이 모든 것은 에이전트형 코딩 도구에도 도움이 됩니다. LLM 덕분에 간단한 자동화 스크립트를 빠르게 쓰기도 쉬워져서, 다음 번에는 작업을 정확하고 일관되게 반복하는 데 도움이 됩니다.
• 코드 리뷰 문화. 말이 필요 없습니다. 코드 리뷰를 빠르고 생산적으로 할 수 있다면, 누군가(혹은 무언가) 대신 쓴 코드를 리뷰하는 것보다 직접 코드를 쓰고 싶어하는 사람보다 LLM과 훨씬 즐겁게 일할 수 있을 겁니다.
• 아주 이상한 형태의 매니지먼트. 코딩 에이전트에서 좋은 결과를 끌어내는 일은, 불편할 정도로 인간 협업자에게서 좋은 결과를 끌어내는 일과 비슷하게 느껴집니다. 명확한 지시를 제공하고, 필요한 문맥을 보장하며, 산출물에 대해 실행 가능한 피드백을 줘야 합니다. 사람을 상대로 할 때처럼 기분을 상하게 하거나 의욕을 꺾을까 걱정할 필요가 없다는 점에서 훨씬 쉽지만, 기존의 관리 경험은 놀랍도록 유용합니다.
• 정말 뛰어난 수동 QA(품질 보증). 자동화 테스트 너머로, 수동으로 소프트웨어를 아주 잘 테스트할 줄 알아야 하며, 엣지 케이스를 예측하고 파고드는 능력이 필요합니다.
• 강력한 리서치 능력. 어떤 코딩 문제든 해결 방법은 수십 가지입니다. 최선의 옵션을 찾고 접근법을 입증하는 일은 늘 중요했고, 에이전트가 실제 코드를 쓰기 전에 여전히 진행을 막는 요소가 되곤 합니다.
• 프리뷰 환경으로 배포할 수 있는 능력. 에이전트가 기능을 만들었다면, 그 기능을 (곧바로 프로덕션에 배포하지 않고) 안전하게 프리뷰할 수 있는 방법이 있으면 리뷰가 훨씬 생산적이고, 깨진 것을 배포할 위험이 크게 줄어듭니다.
• AI에 무엇을 외주 줄 수 있고 무엇은 스스로 처리해야 하는지에 대한 직감. 모델과 도구가 더 효과적으로 변함에 따라 이 직감도 계속 진화합니다. LLM을 효과적으로 다루는 큰 부분은, 언제 LLM을 적용하는 게 최적인지에 대한 강한 직감을 유지하는 것입니다.
• 업데이트된 추정 감각. 프로젝트 소요 시간을 추정하는 일은, 특히 예산과 전략 결정이 그 추정에 기반하는 조직에서는, 시니어 엔지니어로서 가장 어렵지만 중요한 일 중 하나입니다. AI 보조 코딩은 이 일을 더 어렵게 만듭니다—예전에 오래 걸리던 일은 훨씬 빨라졌지만, 이제 추정은 우리가 아직도 파악 중인 새로운 요인들에 좌우됩니다.

이 새로운 도구들의 역량을 제대로 활용하려면, 당신은 _최상의 컨디션_으로 운영되어야 합니다. 코드를 쓰는 것만이 책임이 아닙니다—접근법을 조사하고, 고수준 아키텍처를 결정하고, 명세를 작성하고, 성공 기준을 정의하고, 에이전트 루프를 설계하고, QA를 계획하고, 기회를 주면 분명 편법을 쓸 그 기묘한 디지털 인턴 군단을 관리하며, 코드 리뷰에 정말 많은 시간을 씁니다.

이 모든 것의 거의 전부는 이미 시니어 소프트웨어 엔지니어의 특성입니다!

AI 도구는 기존 전문성을 증폭합니다. 소프트웨어 엔지니어로서 보유한 기술과 경험이 많을수록, LLM과 코딩 에이전트로부터 더 빠르고 더 좋은 결과를 얻을 수 있습니다.

“바이브 엔지니어링”, 정말로?#

이름이 바보 같냐고요? 아마 그렇습니다. AI에서의 “바이브”라는 개념은 이제 좀 진부하게 느껴지기도 합니다. “바이브 코딩”이라는 말 자체도 많은 개발자에게 비꼬는 표현으로 쓰이죠. 저는 더 건설적인 의미로 바이브를 되찾을 준비가 되어 있습니다.

저는 “코더”와 “엔지니어” 사이의 인위적인 구분을 그리 좋아하지 않습니다—약간의 게이트키핑 냄새가 나거든요. 하지만 이번만큼은 약간의 게이트키핑이 우리에게 꼭 필요합니다!

바이브 엔지니어링은 바이브 코딩과 명확히 구분됩니다. 이는 프로덕션 소프트웨어를 만들기 위해 AI 도구를 다루는 전혀 다른, 더 어렵고 더 정교한 방식이라는 신호이기도 합니다.

이 표현이 짓궂고 논쟁적일 가능성이 있다는 점이 좋습니다. 이 영역 전반이 여전히 여러 면에서 우스꽝스럽죠. 이 새로운 도구들을 가장 생산적으로 적용하는 법을 찾아가는 동안, 너무 심각할 필요는 없습니다.

예전에 AI 보조 프로그래밍 같은 용어를 유행시키려 해 봤지만, 성공률은 사실상 제로였죠. 이왕이면 바이브를 좀 발라 보고 어떻게 되는지 지켜보려 합니다.

또 “바이브”와 “엔지니어링” 사이의 선명한 부조화도 마음에 듭니다. 두 단어가 결합됐을 때 생기는 자기모순은 어딘가 장난스럽고, (바라건대) 기억에 오래 남을 만합니다.