localhost 띄워놓고 개발자를 무시하지 말자
내 컴퓨터 밖으로 나가는 순간
바이브코딩으로 앱을 만들어봤다. "대시보드 하나 만들어줘"라고 했더니 진짜 만들어줬다. 차트도 나오고 필터도 되고, 심지어 다크모드까지 붙어 있었다. 브라우저에 localhost:3000을 치면 앱이 뜬다. 솔직히 뿌듯했다. (건설 전공이 대시보드를 만들 줄이야.)
여기까지는 누구나 할 수 있는 시대가 됐다. 진짜 문제는 그 다음이다.
이 앱을 회사 서버에 올린다고 생각해보자.
보안 정책부터 걸린다. 회사에는 인증 체계가 있고, 방화벽 규칙이 있고, 데이터 암호화 기준이 있다. 기존 아키텍처에 맞춰야 하고, CI/CD 파이프라인을 통과해야 하고, 장애가 나면 롤백할 수 있어야 한다. 컴플라이언스 요구사항까지 있다. 대기업의 73%가 컴플라이언스 때문에 제품 출시가 지연된다고 보고한다. 전문 개발팀이 만든 앱도 이 관문에서 막히는데, 바이브코딩으로 만든 앱이 이 질서 안으로 들어가는 순간 어마어마한 무게가 생긴다.
localhost에서 되는 것과 세상에 내놓는 것은 전혀 다른 일이다. 배포는 코드 문제가 아니라 환경 문제이기 때문이다. 네트워크 구성, 서버 설정, 권한 관리, 데이터 마이그레이션. 개발자의 76%가 배포와 모니터링에 AI를 사용하지 않는다.
코드를 짜는 데는 AI를 쓰지만, 그 코드를 세상에 내보내는 일은 여전히 사람이 한다.
보안은 더 심각하다. Escape.tech가 5,600개 이상의 바이브코딩 앱을 분석한 결과, 2,000개 이상의 보안 취약점과 400개 이상의 노출된 시크릿이 발견됐다. 금융 정보, 의료 기록, 전화번호까지 포함됐다. Wiz Research에 따르면 바이브코딩 앱의 20%에서 심각한 취약점이 확인됐다. 클라이언트 측에서 인증을 처리하거나, 시크릿을 코드에 직접 박아놓은 경우다.
물론 Bolt나 Vercel v0 같은 도구들이 배포까지 자동화하려는 시도를 하고 있다. 하지만 이런 도구들도 결국 표준화된 환경 위에서만 작동한다. 회사마다 다른 보안 정책, 레거시 시스템과의 연동, 내부 인증 체계 — 이런 것들은 원클릭 배포로 해결되지 않는다.
localhost에서는 아무 문제가 없었다. 나만 쓰니까.
만드는 건 한순간이다
바이브코딩으로 앱을 만드는 데 하루면 된다. 유지하는 데는 몇 년이 걸린다.
소프트웨어 전체 수명주기 비용의 60~90%는 유지보수에 들어간다. 초기 개발비의 2~4배다. 만드는 것보다 돌아가게 유지하는 것이 압도적으로 비싸다. 이건 localhost를 띄워본 적 없는 사람도 알아야 하는 현실이다.
그런데 바이브코딩으로 만든 앱을 누가 유지보수할 것인가.
버그가 생기면 누가 고치나. 외부 API가 버전업되면 누가 대응하나. 나는 회사에서 바이브코딩으로 만든 내부 도구 하나를 운영해본 적이 있다. 만들 때는 반나절이었다. 그 뒤로 매주 뭔가를 고쳤다. 라이브러리 업데이트에 깨지고, 데이터 포맷이 바뀌면 또 깨지고. 이 업무를 누군가는 follow-up 해야 한다. 사람이 부족하다.
Forrester는 2026년까지 기술 의사결정자의 75%가 중등도 이상의 기술부채에 직면할 것이라고 예측했다. 원인으로 AI를 통한 급속 개발을 지목했다. 빠르게 만들었지만 그 뒤를 감당할 사람이 없는 구조다.
localhost 안에서는 보이지 않던 무게가 배포 순간부터 쌓이기 시작한다.
질서 없는 코드
바이브코딩으로 나온 코드를 열어본 적이 있는가.
어떤 표준에 의거해서 짠 게 아니다. 말 그대로 AI가 알아서 짠 코드다. 네이밍 규칙이 회사 표준과 안 맞는다. 에러 처리 방식이 기존 코드베이스와 다르다. 한 파일 안에서조차 스타일이 뒤섞여 있다. (나도 내가 만든 코드를 다시 열어보고 당황한 적이 있다. 이걸 내가 만들었다고?)
이건 프로 개발자가 AI 도구를 쓸 때도 마찬가지다. GitClear가 2억 1,100만 줄의 코드 변경을 분석한 결과, AI 도구 도입 이후 코드 중복 비율이 8.3%에서 12.3%로 올랐다. 리팩토링 비율은 25%에서 10% 미만으로 떨어졌다. 복붙은 늘고, 정리는 줄었다. 프로가 써도 이 수준이면, 코드를 읽을 줄 모르는 사람이 바이브코딩으로 만든 코드는 어떨지 짐작이 된다.
개발자의 약 3분의 2가 AI의 가장 큰 불만으로 '거의 맞지만 완전히 맞지는 않는 것'을 꼽았다. 거의 맞는 코드가 가장 위험하다. localhost에서는 돌아가니까 넘어가고, 넘어간 것이 쌓이면 아무도 손댈 수 없는 코드가 된다.
거미줄을 머릿속에 넣은 사람들
앞에서 배포, 유지보수, 코드 품질 문제를 나열했다. 이 문제들을 매일 해결하며 살아가는 사람들이 있다. 개발자다.
개발자를 과소평가하는 사람들은 이들이 뭘 하는지 모르는 경우가 많다.
네트워크. 하드웨어. 백엔드. 프론트엔드. 데이터베이스. 클라우드. 보안. DevOps. 이 각각이 깊이를 가진 분야다. 개발자는 이것들이 어떻게 맞물려 돌아가는지를 머릿속에 넣고 있는 사람들이다. 어찌 보면 거미줄 같은 컴퓨터 속 세상의 지도를 가진 사람들이다.
패킷이 어떻게 흐르는지 안다. 인덱스를 안 걸면 쿼리가 왜 느려지는지 안다. 메모리 누수가 왜 무서운지 안다. 이 지식들이 쌓여서 시스템이 작동한다. 나는 IT 업무를 하면서 이 사실을 체감했다. 내가 "왜 이렇게 느려요?"라고 물으면 돌아오는 답은 항상 내가 모르는 세계의 이야기였다.
Stanford Digital Economy Lab의 분석이 이를 뒷받침한다. 22~25세 소프트웨어 개발자 고용은 2022년 대비 약 20% 감소했지만, 26세 이상은 안정적이거나 오히려 증가했다. 단순 코드 작성은 AI가 대체할 수 있어도, 이 거미줄을 이해하고 판단하는 능력은 대체되지 않는다는 뜻이다. 바이브코딩으로 localhost 하나 띄운 것과는 무게가 다르다.
다리와 날개
바이브코딩이 무의미하다는 얘기가 아니다.
AI 코딩 에이전트는 비개발자에게 다리다. 코드의 세계에 발을 디딜 수 있게 해준다. 프론트엔드가 뭔지, API가 뭔지, 데이터베이스가 왜 필요한지를 직접 만들어보면서 체감할 수 있다. 나도 그랬다. 바이브코딩 덕분에 개발자들이 하는 일의 일부를 이해하게 됐다. 이전에는 불가능했던 경험이다.
실제로 쓸 수 있는 범위도 분명히 있다. Gemini나 Claude 같은 도구는 결과물을 아티팩트로 만들어 팀에 바로 공유할 수 있다. 회의록을 정리하는 간단한 도구, 반복 업무를 줄여주는 스크립트, 개인용 아카이빙 시스템. 회사 서버에 올릴 필요 없이 내 컴퓨터에서, 혹은 팀 안에서 돌아가면 되는 것들이다. 이 단계의 바이브코딩은 충분히 실용적이다. 그리고 이 과정에서 얻는 것이 하나 더 있다. 코드가 어떻게 돌아가는지를 감으로라도 알게 되면, 나중에 개발자와 대화할 때 깊이가 달라진다. "이거 안 돼요"가 아니라 "API 응답이 늦는 것 같은데 확인해줄 수 있어요?"로 바뀐다. 시스템화 이전의 바이브코딩은 능률 향상뿐 아니라, 개발자와의 의사소통을 한 단계 끌어올리는 다리이기도 하다.
그런데 같은 도구가 개발자에게는 날개다.
Y Combinator 2025 Winter Batch에서 스타트업의 25%가 코드의 95%를 AI로 생성했다. 이들은 전원 직접 제품을 만들 수 있는 고급 기술 인력이었다. AI가 대신 짜줘서 개발자가 필요 없어진 게 아니다. 개발자가 AI를 써서 제품 단위의 속도를 끌어올린 것이다.
흥미로운 역설도 있다. METR의 연구에서 숙련된 오픈소스 개발자 16명이 AI 도구를 쓰고 개별 태스크를 수행했더니, 실제로는 19% 느렸다. 그런데 본인들은 20% 빨라졌다고 인식했다. 도구를 쓴다고 마법이 일어나지는 않는다. 하지만 YC 사례처럼 제품 전체를 설계하고 판단할 수 있는 사람이 쓰면 이야기가 달라진다. 결국 도구의 가치는 쓰는 사람의 깊이에 달려 있다.
localhost만 띄워놓고 무시하지 말자
바이브코딩은 생각만큼 안정적이지 않다. 내 컴퓨터에서 돌아가는 것과 회사 서버의 보안, 아키텍처, 프레임워크를 따르는 질서 속에서 돌아가는 것은 완전히 다른 문제다.
생성하는 건 쉬워졌다. 운영하고, 유지하고, 보수하는 일은 여전히 무겁다. 그리고 그 무거운 일을 해온 사람들이 개발자다.
나도 localhost를 띄우고 뿌듯해한 사람이다. 하지만 그 뿌듯함이 진짜인지는, 그 앱을 세상에 내놓는 순간 알게 된다. 바이브코딩만으로 개발자를 대체할 수 있다는 생각은 그릇된 생각이다. AI 코딩 에이전트는 비개발자가 그들에게 가까워지는 데 도움을 주고 있지만, 정작 그들에게는 날개를 펼칠 더 좋은 환경을 주고 있다.
localhost만 띄워놓고, 그들이 뭘 하는지도 모른 채, 무시하지 말자.
참고 자료
[1] Secureframe, "Compliance Statistics" (2025). https://secureframe.com/blog/compliance-statistics
[2] Stack Overflow, "2025 Developer Survey" (2025). https://survey.stackoverflow.co/2025/ai
[3] Escape.tech, "How We Discovered Vulnerabilities in Vibe-Coded Apps" (2025). https://escape.tech/blog/methodology-how-we-discovered-vulnerabilities-apps-built-with-vibe-coding/
[4] Wiz Research, "Common Security Risks in Vibe-Coded Apps" (2025). https://www.wiz.io/blog/common-security-risks-in-vibe-coded-apps
[5] Galorath, "Software Maintenance Costs" (2025). https://galorath.com/blog/software-maintenance-costs/
[6] Forrester, "Predictions 2025: Tech & Security" (2025). https://www.forrester.com/press-newsroom/forrester-predictions-2025-tech-security/
[7] GitClear, "AI Copilot Code Quality 2025 Research" (2025). https://www.gitclear.com/ai_assistant_code_quality_2025_research
[8] Stanford Digital Economy Lab, "Canaries in the Coal Mine" (2025). https://digitaleconomy.stanford.edu/wp-content/uploads/2025/08/Canaries_BrynjolfssonChandarChen.pdf
[9] TechCrunch, "A quarter of startups in YC's current cohort have codebases that are almost entirely AI-generated" (2025). https://techcrunch.com/2025/03/06/a-quarter-of-startups-in-ycs-current-cohort-have-codebases-that-are-almost-entirely-ai-generated/
[10] METR, "AI-Experienced OS Developer Study" (2025). https://arxiv.org/abs/2507.09089
