‘바이브 코딩’이라는 말이 처음 퍼졌을 때의 분위기는 사실 진지함보다 조롱에 가까웠습니다. “코드를 한 줄도 모르는 사람이 프로그램을 작성한다고?”라는 반응이 대부분이었죠. 하지만 지금은 분위기가 다릅니다. 바이브 코딩 강의가 쏟아지고, 더 나은 AI 에이전트들이 등장하고, 사람들은 자신만의 바이브 코딩 팁을 공유하기 시작했습니다. 그만큼 바이브 코딩이 새로운 기회를 열어준 것이죠.

예전에는 아이디어가 있으면 어떻게 했을까요? 외주를 맡기려면 완벽하게 정리된 기획서가 필요했습니다. 눈을 감고 그림을 그리는 것과 같았죠. 머릿속으로만 상상하며 설명해야 했고, 결과물이 나와야 비로소 "아, 이게 아닌데"를 알 수 있었습니다. 지금은 다릅니다. 직접 만들어보고, 만져보고, 다듬어볼 수 있습니다. 거의 완성된 그림을 눈앞에 두고 생각을 조정할 수 있습니다.

그래서 팀빌딩도 달라졌습니다. 먼저 아이디어를 직접 구체화하고, 확신이 생겼을 때 개발자를 영입합니다. 수익이 발생한 후에 고도화해도 되고요. 일의 순서가 바뀐 거죠. 아마 바이브 코딩이 없었다면, 시도조차 못 했을 아이디어들이 지금은 바로 현실이 되고 있습니다.

‘바이브 코딩 청소’가 등장하다

그 덕분에 ‘바이브 코딩 청소’라는 개념도 생겨났습니다. 이것도 처음엔 우스갯소리였습니다. 바이브 코딩으로 엉망이 된 코드를 결국 개발자가 치워줘야 한다면서요. “바이브 코딩이 개발자를 대체한다”는 말에 대한 반항 심리 같은 거였죠. 그런데 저는 진짜로 하고 있습니다. 바이브 코딩 서비스를 운영하고 있기도 하고, 그중 25개 프로젝트에서 직접 바이브 코딩 청소를 수행했습니다. 사내 기획자, 지인들과 함께 말이죠. 오늘은 바이브 코딩 청소를 경험해 본 제가 지금 느끼고 있는 개발자 포지션의 변화에 대해 이야기해 보려고 합니다.

미리 요점만 콕 집어보면?

바이브 코딩은 처음엔 의심에서 출발했지만, 아이디어를 직접 만들고 검증할 수 있는 현실적인 방법으로 빠르게 자리 잡았습니다.
바이브 코딩으로 만든 코드는 프로젝트가 커질수록 하드코딩과 컨벤션 붕괴 문제가 생기지만, AI 지침과 자동화를 활용한 바이브 코딩 청소로 해결할 수 있었습니다.
이 경험은 개발자의 역할이 기능 구현 중심에서 환경과 규칙을 설계하는 플랫폼 엔지니어로 이동하고 있음을 보여줍니다.

실제 바이브 코딩 청소 사례

실제로 제 비개발자 지인이 바이브 코딩으로 하나의 서비스를 만들었습니다. 일본인 관광객을 대상으로 한국 맛집을 소개하는 사이트인데요. 이 서비스는 관리자 화면에서 게시글을 관리하고, 맛집과 제휴를 맺어 할인과 수익을 공유(쉐어)하는 모델입니다. 서비스를 출시한 이후, 실제 유저가 방문하기 시작했고, 현재는 총 5곳과 제휴를 맺은 상황이었죠. 지인은 이 서비스를 제가 운영하는 바이브 코딩 툴로 직접 개발했습니다. 그래서 개발 도중 문제가 생기면 지인은 저에게 도움을 요청하고, 그사이 다른 프로젝트를 만듭니다.

저는 지인의 코드 저장소에 접속해 클로드 코드(Claude Code)로 문제를 수정했습니다. 둘 다 같은 클로드 코드 기반을 사용하고 있어서, 어떤 지시 사항이 빠졌는지 파악하기 수월했고요. 지인이 보내는 요청은 주로 이런 식입니다.

“ㅇㅇ기능이 안 돼요.”
“~~를 하고 싶은데 AI가 이해를 못 해요.”

문제의 핵심은 코드가 커지고 문맥(Context)이 길어지면서, AI가 요청사항을 제대로 이해하지 못하는 경우가 잦아졌다는 점입니다.

바이브 코딩에서 발생하는 코드의 문제점들

코드를 살펴보니 몇 가지 문제가 눈에 띄었습니다. 비개발자들이 말하는 ‘코드가 꼬인다’는 게 이런 거였구나 싶더군요.

하드코딩

AI가 유저의 요청을 단편적으로 수행하려다 보니 발생하는 문제입니다. 예를 들어, "대시보드 구성해 줘"라고 하면, UI에 특정 값이 그대로 박혀 있는 경우가 많습니다. 말 그대로 껍데기만 만들어놓은 셈이죠. 물론 처음부터 실제 값을 넣기보다는 가짜 데이터를 사용하는 것도 괜찮습니다. 기능을 확인하려면 어차피 그런 과정이 필요하니까요. 하지만 중요한 건 그 방식입니다.

가짜 데이터를 api → page 형태로 만들어놓으면, 나중에 api 부분만 실제 연동으로 바꾸면 됩니다. 그런데 화면에 값이 박혀 있으면, 나중에 실제로 연동할 때 수정이 어려워집니다.

컨벤션 룰 미준수

배포 플랫폼과의 호환, Next.js에서 글로벌 상태를 쓰기 위한 베스트 프랙티스 같은 것들이 지켜지지 않았습니다. 컨벤션은 ‘코드를 이런 식으로 작성하라’는 일종의 규칙입니다. 단순히 파일 이름을 소문자로 쓰는 컨벤션도 있지만, 데이터베이스 테이블 작성 규칙, UI와 상태, API의 연계 흐름 등도 포함됩니다.

왜 이런 규칙이 필요할까요? 기획이 변경되거나, 새로운 기능이 추가됐을 때 변경 범위를 최소화하기 위해서입니다. 오류가 전파되는 것을 막고, 기능을 쉽게 추가할 수 있게 하죠. 원래 개발자들은 코드 리뷰를 하면서 이런 규칙을 서로 맞춰 갑니다. 사실 개발에서는 코드를 작성하는 시간보다, 이런 합의를 만드는 데 더 많은 시간이 걸립니다. 그런데 바이브 코딩에서는 이 룰이 지켜지기 어렵습니다.

왜 이런 일이 생겼을까?

프로젝트의 코드량이 많아질수록, AI는 점점 지침을 누락하기 시작했습니다. 아무래도 코드 에이전트는 평균적인 코드를 작성하는 경향이 있습니다. 프레임워크의 새로운 기능을 적극적으로 활용하지 않고, ‘옛날’ 코드 패턴을 따라가는 경우가 많죠. 원래는 제가 만들어 둔 지침이 이런 문제를 방어해줘야 하는데, 그 지침이 누락되면서 방어막이 뚫린 겁니다.

제가 만들고 있는 지침은 지난 6년간 개발하면서 다양한 프로젝트를 직접 수행한 경험을 바탕으로 작성한 것입니다. “당신은 구글 시니어 개발자입니다” 같은 롤플레잉 프롬프트와는 다릅니다. 사내에서 코드를 작성할 때 실제로 사용하는 리뷰용 체크리스트이며, 완전히 개발 용어로 구성돼 있어 일종의 코드에 가깝다고 볼 수 있습니다.

그런데 AI가 이 지침을 따르지 않았습니다.

제가 에이전트 지시 사항에서 그 내용을 빠뜨렸거나,
혹은 에이전트가 지침을 누락했거나,

둘 중 하나입니다.

바이브 코딩 청소도 바이브 코딩이다

그렇다면 저는 이 문제를 어떻게 정리했을까요? 바이브 코딩 청소도 바이브 코딩 방식으로 해결했습니다. 저는 코드를 직접 고치지 않았습니다.

빠뜨린 경우: 지시 사항을 추가한 뒤, 해당 지시 사항을 제대로 따랐는지 파일을 검사하라고 AI에게 지시합니다.
누락한 경우: 누락된 부분을 지시 사항 파일과 다시 매칭해 주는 방식으로 정리했습니다.

제가 전에 기획자, 혹은 현재 개발자로서 일할 때와는 사뭇 다릅니다. 예전에는 적극적으로 프로덕트의 기능을 파악하고, 화면을 직접 띄워보며 수정 사항을 반영하곤 했습니다. 하지만 지금은 기계적으로 체크리스트에 맞는지 확인하고, 누락된 부분이 있으면 다시 요청하는 방식으로 일하고 있습니다.

터미널에서 반복적으로 타이핑하는 키워드가 있었고, 엔터를 누른 뒤 결과를 점검하는 과정을 반복합니다. 비개발자의 바이브 코딩과 제가 하는 바이브 코딩의 차이점은, 저는 코드의 품질을 판단할 수 있고, 그에 따라 다시 요청할지를 결정할 수 있다는 점입니다. 솔직히 고백하자면, 저는 이 서비스의 정확한 기능을 잘 모릅니다. 서비스가 일본어로 되어 있어서, 제가 들어가 봐도 이해하기가 어렵거든요. 그럼에도 불구하고 청소가 가능했다는 사실은, 개발자로서의 저를 다시 한번 돌아보게 만들었습니다.

개발자로서의 역할이 변하고 있다

제가 생각하는 엔지니어의 역할은 이렇습니다. 프로덕트를 빨리 만들고, 기능을 수정하고, 안정적으로 운영하는 것이죠. 이걸 수행하는 방법은 여러 가지가 있는데, 프로덕트 엔지니어와 플랫폼 엔지니어로 나눠볼 수 있을 것 같습니다. 프로덕트 엔지니어는 제품과 비즈니스를 이해하면서 개발하는 사람입니다. 플랫폼 엔지니어는 엔지니어를 위한 엔지니어입니다. 제반 환경을 설정하고, 오로지 비즈니스 기능 구현에 집중하게 하고, 프로덕트가 운영이 잘되도록 하는 코드 환경을 구성합니다.

프로덕트 엔지니어로 살아왔다

저는 그동안 프로덕트 엔지니어로 살아왔습니다. 기획자와 면밀히 소통하거나, 제가 기획과 개발을 모두 맡아 진행했습니다. 이 방식이 단순히 개발자일 때보다 나았던 이유가 있습니다. 모든 기획 내용을 일일이 전달하는 것은 현실적으로 어렵기 때문입니다. 어느 정도는 개발자도 스스로 의사결정을 내리는 순간이 필요했습니다.

작은 기업일수록 그 필요성은 더욱 커집니다. 그리고 실제로 만들면서 생겨나는 아이디어들도 존재합니다. 그렇기 때문에 현재 개발 중인 프로덕트의 기능을 잘 알고, 소비자의 니즈를 이해하면 기획자와의 소통 간극을 줄일 수 있고, 결과적으로 더 빠르게 프로덕트를 만들 수 있었습니다.

바이브 코딩 청소를 하면서 달라졌다

바이브 코딩 청소를 하면서 제 역할이 달라졌습니다. 앞서 말했듯, 저는 프로덕트의 기능에 전혀 관심을 가지지 않았습니다. 모든 동작은 바이브 코더가 구현해 놓았기 때문입니다. 그게 실제로 동작하든, 안 하든요. 저는 그것이 돌아가기만 하면 된다는 1차적인 목표만 생각했습니다. 그럼에도 불구하고 실제로 돌아가더군요. AI가 프로덕트를 이해하고, 기능을 알고 있었기 때문입니다.

저는 어느 순간부터 바이브 코더를 일종의 개발자로 간주하기 시작했습니다. 이들이 더 편하게 코드를 작성할 수 있도록, 그리고 더 이상 문제가 제게 넘어오지 않도록 하기 위해 제가 코드를 짜고 있는 모습을 발견했습니다. 플랫폼 엔지니어로서의 역할로 바뀐 겁니다.

플랫폼 엔지니어로서 하고 있는 일들

1) 컨텍스트 지침서

필요한 폴더마다 .ai.md 파일을 작성해 규칙을 정리합니다. 그리고 AI가 해당 파일을 먼저 읽고 나서 작업을 시작하도록 지시하죠. AI의 자율성을 존중하면서도 최소한의 제한을 둠으로써, 코드가 일관되게 작성될 수 있도록 돕는 방식입니다. 저는 평소에도 코드 방법론에 대해 블로그 글을 써왔는데요. 그런 저의 생각들을 .ai.md 파일에 녹여내고 있습니다.

2) ESLint 커스텀

ESLint를 커스텀합니다. ESLint는 코드 작성 규칙을 자동으로 검사해주는 도구입니다. 지침만으로는 누락되는 부분이 생기기 때문에, 컴파일러의 결과물을 분석해 제가 원하는 형태로 코드가 작성됐는지 확인할 수 있는 커스텀 룰을 추가하기 시작했습니다. 처음에는 3~4개 정도였는데, 지금은 15개가 넘습니다. 에이전트는 작업을 수행한 뒤 코드 유효성 검사 스크립트를 실행해 규칙에 위반되는 코드를 발견하고, 그 내용을 바탕으로 다시 수정합니다.

3) 제반 환경 연결

제반 환경을 연결합니다. 데이터베이스, 로그인, 이미지 업로드 등 서비스에 필요한 기반들을 모두 세팅해 줍니다. 배포 비용이 거의 들지 않도록 구성했습니다. 돈을 벌지 않는 서비스가 매달 2만 원을 낸다고 하면 부담스럽잖아요. 그래서 서버리스 환경을 구축하고, 그 위에서 Next.js가 동작할 수 있도록 인프라를 구성했습니다. 이미지 서버, 데이터베이스, 프론트 서버들을 한 번에 구성해, 트래픽이 과도해지기 전까지는 비용이 발생하지 않도록 했습니다.

또 better-auth와 같은 오픈소스를 활용해 카카오 로그인 같은 소셜 로그인을 쉽게 연동할 수 있게 만들었습니다. OAuth 개념을 몰라도 자동으로 지원되도록 구성했고요. 이 밖에도 DB 백업, 코드 백업 같은 항목도 관리합니다. 혹시 모를 오류에 대비하기 위해서죠. 이런 제반 환경은 함께 일하는 팀원이 작업하고 있습니다. 복잡한 작업을 미리 수행해 둠으로써, 사용자는 비용이나 연동 과정을 신경 쓰지 않고 개발에 집중할 수 있습니다.

4) 바이브 코딩 툴의 발전

바이브 코더가 더 많은 프로젝트를 수행하고, 더 정확하게 의도를 반영할 수 있도록 툴을 발전시키고 있습니다. 여러 프로젝트를 동시에 띄울 수 있게 하거나, 고치고 싶은 부분을 클릭해 대화창을 열면 해당 위치의 코드가 자동으로 전송되는 방식 등으로 개선 중입니다.

5) 리팩토링 스킬

청소를 하면 할수록, 제가 놓쳤던 AI 지침을 추가하게 됐습니다. 그리고 제가 반복적으로 요청하던 부분, 즉 AI가 자주 실수하는 항목들을 자동화했습니다. 에이전트가 루프를 돌며 체크리스트를 확인하게 하는 리팩토링 스킬을 만들었고, 이제 이 스킬을 실행하면 클로드 코드가 30분에서 2시간 동안 돌아가면서 누락된 지침들을 모두 채워 넣습니다.

리팩토링을 직접 했을 때는 처음에 12시간이 걸렸습니다. 그러나 지금은 시간이 점점 줄어들어 2시간 정도면 됩니다. 그마저도 대부분 자동으로 처리됩니다. 이 리팩토링 스킬은 바이브 코딩 툴에도 탑재해서, 지인이 직접 호출할 수 있도록 했습니다. 최대한 제가 직접 수정할 일이 없도록 하기 위해서죠. 이제는 프로젝트당 단 한 번만 도움 요청이 들어옵니다.

바이브 코딩의 한계

사실 바이브 코딩 열풍이 불면서, 겉보기만 그럴듯한 팁을 쏟아내는 포스팅도 많아졌습니다.

저는 링크드인에 이런 글을 쓴 적이 있습니다. 초반만 읽고 “진짜 팁인 줄 알았다”는 반응이 많았죠. 그만큼 가짜 팁이 퍼지기 쉽다는 뜻입니다. 문제는 이런 가짜 팁을 수용해 작성하면, 오히려 일을 더 복잡하게 만든다는 점인데요. 그냥 “여기 안 돼요”라고만 하면 해결될 수도 있었던 문제를 말이죠.

그래서 제가 드릴 수 있는 유일한 팁은 “내가 이해한 말만 넣기”입니다. 자신이 개발자인 척하면서 직접 코드를 지시하는 순간, 에러가 발생합니다. 한편으로는, 개발자였다면 쉽게 수정할 수 있었던 문제들이 바이브 코딩에서는 시간이 오래 걸리거나, 끝내 해결되지 못하는 경우도 봤습니다. 결국 코드를 직접 봐야만 풀리는 문제들은 여전히 존재하고 있는 겁니다.

바이브 코딩이 보여준 새로운 협업 가능성

바이브 코딩이 열어준 기회는 분명합니다. 저와 비개발자의 협업은 일종의 외주 관계였지만, 기존 외주와는 전혀 달랐습니다. 예전에는 외주로 프로덕트를 맡기면 결과물이 엉망이었고, 결국 제가 직접 개발하는 게 더 빠르다고 느껴 개발자로 전향하기도 했습니다. 문제는 항상 의사소통이었죠. 그래서 대부분 팀을 직접 구성하려고 합니다. 제대로 된 프로덕트를 만들려면 긴밀한 소통이 필요하니까요. 하지만 팀을 꾸리기 위해선 시간과 비용이 듭니다. 수익도 없는 상황에서 제품이 검증될 때까지 버티기는 쉽지 않죠. 이 리스크 때문에 시작조차 못 하는 프로젝트가 많습니다.

그런데 바이브 코더와의 협업은 달랐습니다. 메일로만 소통했지만 충분했습니다. 제가 한 번 전체 코드를 정리해주면, 이후엔 요청 없이 기능이 잘 추가됐습니다. 제가 청소한 프로덕트들은 바이브 코딩이 아니었다면 세상에 나오지 못했을 겁니다. 초기 실험에 필요한 시간과 자본이 항상 부족하니까요. 바이브 코딩은 이 자원을 효율적으로 활용할 수 있게 해줍니다.

이 경험을 통해 깨달은 건, 바이브 코딩이 개발자를 대체하진 못하지만 보완할 수 있다는 점입니다. 개발자가 중간에 조금만 개입해도 작업 속도가 훨씬 빨라집니다. 굳이 개발자를 안 쓸 이유가 없죠. 이제 개발자는 동시에 더 많은 프로젝트에 참여할 수 있습니다. 저처럼 하루에 세 개 프로젝트를 다루는 것도 가능합니다.

이제 ‘바이브 코딩 청소’라는 방식이 새로운 협업 형태로 자리 잡을 수 있을까요? 저는 이 방식이 개발자와 비개발자 모두에게 새로운 기회를 줄 거라고 믿습니다. 여러분의 생각은 어떠신가요?