과소평가와 과대평가 사이
바이브 코딩이라는 주제에 대해 글을 쓰는 게 맞을까라는 고민을 수개월 동안 해 본 결과, 결국 쓰는 게 의미가 있다는 결론을 내렸다. 많이 고민했던 이유는, 바이브 코딩을 바라보는 인식이 개발자와 비개발자 사이에서 매우 다르고, 대기업(국내, 외국계 모두 포함)과 스타트업의 차이 또한 매우 크며, 제조업과 비제조업의 차이 또한 정말 크기 때문이다.
전통적인 제조업(코닥, 필립스, 다이슨) 기반에서 10년 넘는 경력을 SCM에서 쌓아왔고, 이때 SAP의 Super User로서 거의 모든 사내 프로젝트를 리딩하거나 TF에 참여해 왔으며, 이후 테크 플랫폼 기업(쇼피, 쿠팡)에서 4년 동안 SCM 및 Program Management로 경력을 이어왔고, 현재는 스케일업 단계에 있는 더파운더즈에서 COO Staff의 Process Innovation 팀 리드로 일하며 AI 활용과 프로세스 자동화에 집중하고 있는 나의 상황은, 바이브 코딩을 바라보는 다양한 관점을 동시에 이해할 수 있는 독특한 기회를 제공해 주었다. (과거 일했던 회사의 일하는 방식에 대한 글: 내가 경험한 6개 회사의 일하는 방식)
더 깊은 이야기를 하기 전에, 바이브 코딩에 대해서 내가 어디까지 직접 해봤고, 어디까지 회사의 워크플로우에 적용해 봤고, 어떤 실패들을 해봤는지를 먼저 언급하려 한다.
새로운 플랫폼과 테크놀로지에 대해 다른 사람들보다 먼저 사용해 보는 성향이 강하다 보니, 바이브 코딩도 비개발자 중에서는 상당히 빠르게 시도해 보았었다. 그리고 이를 위한 PRD(제품 요구 사양서)는 쿠팡에서 매일 읽고 테크 팀과 깊은 논의를 이어왔었으니 형식과 구조, 그리고 어떤 PRD가 좋은 PRD인지는 충분한 이해가 있었다. (다만, 이해하는 것과 실제로 그런 PRD를 쓰는 것의 차이는 정말 크다는 것을 지속적으로 깨닫게 된다.)
이를 바탕으로, Lovable(AI 웹 빌더)과 Cursor(AI 코드 에디터)로 딸을 위한 인형 뽑기 게임을 몇 시간 투자해서 만들어보려는 첫 시도는 터무니없이 실패했다. 거의 그림판에 각종 이미지를 붙여 넣고 이미지를 움직여서 픽업하는 듯한 수준의 처참한 품질이었다.
이후 보다 더 많은 자료를 읽고 작은 시도들을 이어가며 조금의 자신감을 얻었고, 두 번째 시도로, 회사에서 나 혼자 사용해 볼 만한 대시보드를 만들어보았다. 이번에도 사용한 툴은 Cursor. 내부 솔루션에서 매일 업데이트되는 데이터를 csv 파일로 다운로드하여 내가 만든 대시보드에 업로드하면 본부/팀/사용자에 따른 분석을 해주는 툴이었다. 스프레드시트나 엑셀로 가능했던 작업을 비슷한 대시보드 형태로 구현해 볼 수 있다는 경험이었으나 실제로 업무에 활용성은 0이었다. 굳이 엑셀을 두고 내가 만든 대시보드를 활용할 이유는 없었으니까.
다시 시간이 지나서 시도한 것은 Antigravity를 활용한 유튜브 콘텐츠 추천 솔루션이었다. n8n, Zapier, Notion을 통한 자동화 방법을 공유하는 유튜브 영상 중, 신뢰할 만한 소스에서 업로드된 영상을 추천해 주고, 내 회사 캘린더의 빈 시간에 시청 미팅을 생성하며, 평가에 따라 추천 빈도를 조절하는 솔루션이었다. (나중에 깨달은 사실은, 추천 빈도 로직은 프런트엔드에서만 그럴듯하게 구현되었을 뿐 백엔드 로직이 설정되지 않아 실제 추천에 아무런 영향을 주지 못했다는 점이었다.)
위 작업 이후 조금의 자신감을 얻게 된 나는, 이제 회사의 실제 업무에 작게 적용하기 시작했다. 구글 API를 통해 특정 검색어의 트렌드를 가져오고, 이를 AI로 요약한 후 슬랙 채널에 매일 공유하는 것을 n8n을 활용해서 만들었다. n8n을 제대로 활용하기 위해선 JavaScript 및 Python에 대한 이해가 필요했으나, 전무했던 나는 Gemini와 함께 거의 8시간 가까이 스크린샷을 공유하고, 코드를 받아 적용하고, 에러를 각 단계별로 따라가면서 고쳐야만 했다. 이후 실제 회사 슬랙 채널에 공유를 시작했고, 동료들로부터 추가 국가 반영이나 로직 개선에 대한 피드백을 받아 이를 다시 적용시켰다. 이 프로젝트는 처음으로 버전 관리와 분기 관리의 필요성을 느껴 Github에 반영하고 관리했던 케이스가 되었다.
이후 회사 내의 특정 프로세스를 자동화시켜달라는 요청을 받아, 처음으로 Claude Code(터미널 기반 AI 코딩 도구)를 사용해 보게 된다. 지난번에는 n8n에 들어가서 하나하나 맵핑하며 코드를 만들었다면, 이번에는 Claude Code에 n8n API를 연동하여 AI가 내 요청을 직접 구현하게 하는 방법이었다. 기존보다 훨씬 빠르고 전체 맥락을 보면서 작업이 가능해 작업 시간을 크게 줄여주었다. 물론 각 단계별 에러를 잡아내는 고군분투는 여전했지만, 이 방식은 내게 큰 자신감을 주었고 실제 업무에 파일럿으로 적용해 테스트를 시작할 수 있었다. 동시에 CLAUDE.md 파일의 중요성을 이해하고, 컨텍스트 윈도우가 다 사용되었을 때 Hand-off 작업을 통해 새로운 프로젝트 창으로 이어가는 경험도 이때 하게 되었다.
여기까지 한 나는, 또 다른 방법으로 새로운 자동화를 시도해 보게 된다. 유튜브 영상 스크립트를 AI로 요약해서 노션 DB로 옮겨보는 것. 누군가 요청한 내용은 아니고 금요일 저녁부터 시작해 일요일 오전에서야 최종 결론이 내려진 프로젝트였다.
이번 접근법은 Claude Code가 아니라 Claude Chrome Extension이었다. Claude를 크롬 사이드바에 띄워두고 화면 디버깅 권한을 주어 AI가 직접 n8n 화면을 보면서 전체 워크플로우를 만드는 방법이었다. AI가 직접 화면을 보니 좀 다를까 싶었는데 장단점이 명확했다. 장점으로는 일을 시키고 놀 수 있다는 것, 단점으로는 화면을 하나하나 캡처해서 해독하느라 엄청나게 느리다는 것과 기존에 정의해 둔 CLAUDE.md의 규칙들이 죄다 무시된다는 것이었다. 실제로 이렇게 만든 워크플로우를 Claude Code에게 분석시킨 결과, API Key가 하드코딩되어 있거나 파라미터가 너무 크게 설정되어 있는 등 각종 이슈가 확인되어 결국 처음부터 다시 리뷰하고 수정해야만 했다. 거의 14시간을 투자해 에러를 잡았으나 마지막 단계에서 멈추게 되었다. 당시 Gemini App과 Gemini API의 차이를 구분하지 못하고 있던 나는, 무료 버전의 API 사용량 한계에 부딪히며 실행 불가 상태를 맞이했다. 내 사이드 프로젝트를 위해 회사 비용을 쓸 이유는 없었으니 14시간을 투입했던 이 프로젝트는 여기서 스톱했다.
이제 다시 원래 하고자 했던 이야기로 돌아가보자. 바이브 코딩.
전통적인 제조 대기업에서 보안과 프로세스 표준화의 중요성을 너무나도 잘 알고,
거대 테크 플랫폼 기업에서 컨트롤 가능한 환경 속 실험 방법론을 충분히 이해하는 상황에서,
스타트업의 리스크 있는 시도에 공감하는 나.
이러한 관점에서 내가 바라보는 바이브 코딩은, 실제보다 지나치게 과소 평가되고 있는 동시에, 실제보다 지나치게 과대 평가되고 있는 방법론이다. 그리고 이 차이는 회사가 현재 어떤 산업에서 어떤 스테이지에 있느냐에 따라 달라지며, 이 안에서 어떤 제약식과 가능성이 열려있는지를 아는 개인에 따라서도 달라지는 것이라 생각한다.
하지만.
보안적으로 완벽하지 않다는 이유로, 스케일업이 쉽지 않을 것이라는 이유로, 그리고 나의 업무는 AI에 영향을 받지 않을 것이라는 생각으로 바이브 코딩과 이를 통한 변화를 무시하는 것은, 너무나도 순진한 생각이라는 것을 의심하지 않는다.