작동하는 화면 하나를 만드는 일과 서비스를 책임지는 일 사이에는 큰 간격이 있습니다. 한국의 바이브코딩 열풍은 이 간격을 너무 쉽게 지웁니다. AI에게 기능을 말하고 코드와 배포 결과를 얻으면 개발이 아이디어를 설명하는 일로 바뀐 듯합니다.
하지만 사용자가 들어오고 결제와 개인정보가 얽히는 순간 질문은 달라집니다. 누가 시스템을 고칠 것인가. 장애와 데이터 손실을 어떻게 복구할 것인가. 이 질문에 답하지 못한 채 결과물만 시장에 올리는 일이 바이브코딩의 첫 번째 폐해입니다.
프로토타입은 서비스가 아니다
바이브코딩 자체는 문제라기보다 유용한 도구입니다. 초기 프로토타입, 내부 자동화, 아이디어 검증에서는 비개발자도 자신의 문제를 작은 도구로 풀어볼 수 있습니다.
개발자의 생산성을 돕던 도구가 “개발을 몰라도 서비스와 수익을 만들 수 있다”는 약속으로 바뀌는 데서 문제가 시작됩니다. 진입장벽이 낮아진 것과 소프트웨어 사업의 난도가 낮아진 것은 같은 말이 아닙니다.
국내 수요가 커지는 흐름은 확인됩니다. 뉴시스는 패스트캠퍼스 자체 집계를 인용해 바이브코딩 강의 매출이 6개월 만에 175% 늘고, 강의 수가 15개에서 39개로 증가했다고 보도했습니다. 한국 전체 시장이나 강의 품질을 보여주는 수치는 아니지만, 새 도구가 교육 상품과 수익 기회로 빠르게 포장된다는 신호입니다.
Stack Overflow의 2025 개발자 조사에서도 응답자의 87%는 AI 에이전트의 정확성을, 81%는 보안과 개인정보를 우려했습니다. 한국 시장을 측정한 자료는 아니지만, 현업에서도 생성 결과를 그대로 믿지 않는다는 점은 보여줍니다.
운영비는 사라지지 않는다
바이브코딩은 화면을 빨리 만들지만 운영에 필요한 일은 화면 뒤에 남깁니다. 요구사항과 권한, 비밀정보와 데이터, 마이그레이션을 관리해야 합니다. 오류와 성능을 관찰하고 백업·의존성·클라우드 비용·개인정보를 점검하며, 문의와 장애에도 대응해야 합니다.
빠르게 만든 화면 아래에는 운영을 지탱하는 보이지 않는 기반이 있습니다.
AI는 이 작업을 도울 수 있지만 책임을 대신 지지는 않습니다. METR은 숙련 오픈소스 개발자 16명의 246개 작업을 분석한 실험에서, 2025년 초 AI 도구 사용이 완료 시간을 오히려 19% 늘렸다고 보고했습니다. 모든 도구에 적용되는 법칙은 아니지만, 새 데모와 기존 시스템의 안전한 변경은 다르다는 점을 보여줍니다.
Veracode의 실험에서도 100개가 넘는 모델이 수행한 80개 과제 중 보안 요구를 만족한 비율은 55%였습니다. 실제 서비스 전체의 결과는 아니지만, “실행된다”와 “안전하다”가 다른 품질 축이라는 점은 분명합니다.
한탕주의가 만드는 신뢰의 비용
생성 비용이 내려가면 결과물의 공급은 늘어납니다. 시장이 문제 해결보다 배포된 화면과 짧은 성공담을 보상하면, 오래 운영할 수 없는 제품도 계속 만들어질 수 있습니다. 아직 한국 시장 전체가 망가졌다고 단정할 통계는 없지만, 로그인·결제·데이터 삭제가 실패하고 문의가 사라지는 경험이 쌓이면 새로운 서비스 전체가 의심받게 됩니다.
AI로 돈을 벌게 해주겠다는 강의도 같은 구조 안에 있습니다. 도구를 배우는 교육에는 가치가 있지만 “도구를 익히면 곧 수익이 난다”는 약속은 기술보다 기대를 판매합니다. 개발과 사업에는 몇 번의 프롬프트로 안정적인 수익이 생긴다는 공식이 없습니다. 고객의 문제, 제품 전달, 반복 사용, 가격, 장애와 문의를 함께 책임져야 수익이 만들어집니다.
직접 비용을 떠안는 쪽은 개발자와 운영자일 때가 많습니다. 이들은 엉킨 코드를 읽고, 보안 문제를 막고, 장애를 복구하며, “AI가 하루 만에 만들었다”는 기대 뒤의 일을 처리합니다. 그 노동이 값싸게 취급되면 개발자의 전문성과 진짜 제품을 만드는 팀 모두가 불리해집니다.
개발자는 사라지지 않는다
미래에 개발자가 없어질 것이라고 생각하지 않습니다. 다만 직접 코드를 입력하는 행위의 상당 부분은 줄어들 수 있습니다. 코딩을 하지 않는다고 해서 코드를 보지 않는 것은 아닙니다. AI가 만든 코드의 구조와 실패 지점, 다른 시스템과의 연결을 판단하는 눈은 더 중요해집니다.
앞으로의 개발자는 코드를 쓰는 사람인 동시에 코드를 읽고 판단하는 사람입니다.
개발자의 소양은 코딩 속도만으로 평가하기 어려워질 것입니다. 요구사항을 기술 구조로 바꾸는 지식, 장애를 견디는 아키텍처 설계, 생성된 코드를 검토하는 판단력이 핵심으로 남습니다. 코드를 작성하는 손은 AI에 빌릴 수 있어도 무엇을 배포할지 결정하는 책임까지 넘길 수는 없습니다.
배포 전에 물어야 할 것
장애가 나면 되돌릴 수 있는가. 백업을 실제로 복구해 봤는가. 비밀정보와 사용자 데이터의 위치를 아는가. 오류를 찾을 로그와 모니터링이 있는가. 의존성 변경과 사용자 문의를 누가 책임질 것인가.
이 질문에 답하지 못한다면 아이디어를 포기할 필요는 없습니다. 아직은 서비스가 아니라 프로토타입이라고 말하면 됩니다. 테스트 범위와 사용자를 제한하고 운영 책임자를 정한 뒤 다음 단계로 넘어가면 됩니다.
바이브코딩은 개발의 문턱을 낮췄지만 책임의 문턱까지 없애지는 않았습니다. 중요한 것은 AI를 쓰지 않는 일이 아니라, 빠르게 만든 결과물을 언제 시장에 내놓을 수 있는지 판단하는 일입니다. 만들었다는 사실보다 고칠 수 있는가, 팔았다는 사실보다 계속 책임질 수 있는가를 먼저 물어야 합니다.
