Vibe Coding의 유용성과 한계
- 박준성 박사: Univ. of Iowa 종신교수, 삼성SDS CTO, KAIST 초빙교수

- Oct 8, 2025
- 5 min read
Updated: Mar 4
Vibe 코딩은 LLM 모델에게 자연어 프롬트로 필요한 기능이나 UI를 설명해주면 코드를 자동 생성해주는 기술이다.
오늘날 애플리케이션(줄여서 앱)을 구현하려면 5가지 선택이 있다:
SaaS에 가입하여 Customization 및 구현
No 코드 개발 툴로 Configuration하여 구현
LLM 모델을 이용해 바이브 코딩
Low 코드 개발 툴로 모델링 하여 구현
프로그래밍 언어를 이용해 코딩
5가지 선택 중 어느 것이 가장 적합한지는 앱의 종류에 따라 다르다:
개인 소비자 용 앱
사용자의 선호, 기술 타당성 등을 파악하기 위해 실험적으로 개발하는 기업의 파일럿, 프로토타입 또는 MVP 앱
지식 경영 시스템, 일정 관리 시스템 같은 기업용 Administrative 비즈니스 앱
병원 진료 정보 시스템, 은행 여/수신 시스템, 제조업 생산 관리 시스템 같은 기업용 Mission-Critical, Operational 비즈니스 앱
먼저 기업의 비즈니스 앱을 확보하는 방안의 시장 점유율을 보면, 정확한 조사 통계는 없지만, 가트너그룹, 포레스터 리서치 등 IT 분석 기관의 보고서들을 종합해 다음과 같이 대강 추정해 볼 수 있다:
SaaS 가입: 70%
No 코드: 7%
Vibe 코딩: 3%
Low 코드: 13%
프로그래밍: 7%
비즈니스 앱 영역에서 Vibe 코딩의 비중이 급속히 늘어날까? 앞으로 SaaS의 활용, No / Low 코드 플랫폼의 활용이 줄어들 것 같지는 않고, 따라서 순수 바이브 코딩의 활용은 기껏해야 5% 내외일 것 같다. 한편 No / Low 코드 개발 플랫폼이나 특히 프로그래밍 플랫폼(IDE)들도 바이브 코딩 기능을 적극적으로 도입하고 있기 때문에 그런 측면에서의 활용도도 늘어날 것이다.
바이브 코딩의 장점은
SW 비전문가도 앱을 만들어 볼 수 있다.
SW개발자의 개발 생산성을 높여준다.
IDE에 내장된 코드 완성(Code Completion) 기능은 개발자에게 아주 유용한 기술이다.
바이브 코딩의 단점은
LLM이 갖는 근본적 Hallucination 문제로 인해 오류의 가능성이 상존한다.
LLM은 기존의 코드를 원료로 코드를 짜기 때문에, 이 세상에 없었던 신 기술의 신 사용사례와 같이 창의적이고 혁신적인 코드는 짜기 힘들다.
코드 로직의 불투명성, 설명력(Explainability) 부족으로 가독성이 낮고 수정이 어렵다.
LLM이 GitHub, StackOverflow 등에 게재된 코드를 원료로 쓰는 데, 그 코드들의 품질이 편차가 크기 때문에 LLM 이 짜주는 코드도 품질을 보장할 수 없다.
코드의 가독성(Readability), 변경 용이성(maintainability), 재사용성(Reusability), 지속 가능성(Sustainability) 미흡으로 코드의 지속적 업데이트 시 생산성, 품질이 취약하다.
보안, 가용성, 확장성, 규제 준수, 상호 호환성 등 아키텍처 상 중요한 요건(Architecturally Significant Requirement: ASR)들에 대한 고려가 미흡하다.
따라서 SW를 통한 경영의 와해적 변혁을 추구하고, 코드의 품질이 중요하고, 업데이트 생산성이 중요하고, 아키텍처 요건이 복잡한 경우에는 SW 전문가의 개발 및 코드 리뷰가 매우 중요하다. 기업의 주요 앱 경우, 혁신적인 앱이 아니라 하더라도, 바이브 코딩이 개발 생산성 향상에 도움이 되지만, 어디까지나 개발의 보조 툴로 활용하고, 아키텍처 수준 및 객체 수준의 코드 품질에 대해서는 SW 전문가가 검증하고 책임을 져야 한다.
한편 개인용 취미성 앱, 창업 기업의 MVP 앱, 기업의 신기술 응용의 시도를 위한 프로토타입 내지 파일럿 등 SW 품질이 절대적으로 중요하지 않은 경우, 창의적 발명이 아닌 부분에 대해서는, 바이브 코딩에 의존도를 상대적으로 높일 수 있지만, 그로 인한 기술 부채(Technical Debt)의 축적은 각오해야 한다.
바이브 코딩의 증가로 신입 개발자의 수를 줄일 수도 있겠지만, 바이브 코딩 Output의 품질 문제를 해결해야 할 시니어 개발자의 수를 적정 수준으로 유지하려면 시니어로 키울 주니어의 확보를 외면하면 안된다.
* * *
최근 METR(https://metr.org/)의 실증적 연구에 의하면, 시니어 개발자들이 기존의 복잡한 시스템을 추가 개발하는 데 AI를 써보니까, 경제 전문가, AI 전문가나 개발자 당사자들이 예측했던 것과는 달리, 생산성이 19% 감소했다고 한다(아래 도표 참조). AI가 생성한 잘못된 코드를 검증하는 데 소모한 시간이 적지 않은 것이다.

* * *
구글의 SW개발 관행을 예로 보면, 모든 개발된 코드는 3명의 코드 리뷰를 통과해야 한다: 동료 개발자, 코드 Owner 및 가독성 전문가(Readability Specialist). 이들은 코드가 구글의 표준 및 베스트 프랙티스를 따르는 지, 가독성 및 변경 용이성을 갖추었는 지를 검토하며, 이를 통해 시니어에서 주니어로의 지식 전파가 일어나도록 한다.


구글이 Gemini Code Assist 같은 뛰어난 바이브 코딩 툴을 적극적으로 활용하고 있지만, 어디까지나 '지능적 코딩 파트너'{Intelligent Coding Partner)로 활용하고, 코드 품질에 대한 책임은 개발자와 3명의 코드 리뷰어가 진다, 이런 개발자들의 우수한 능력과 책임감이 구글의 Software Engineering Excellence의 초석을 이루고 있다.
요약컨대, Vibe 코딩이 SW Engineering Excellence를 위해 유용한 툴이지만, 우수한 개발자의 지도 하에서만 효용을 발휘할 수 있다는 한계가 있다. 또한, Vibe 코딩이, 창의적 혁신적이지 않은 기 존재해 온 사용사례를 개발하는 경우에도, 품질보다는 개발 속도가 중요한 파일럿, 프로토타입, MVP 개발에는 유용하지만, 개발 속도보다 품질이 중요한 기업용 주요 비즈니스 앱 개발에는 그 기여에 한계가 있다.
* * *
Claude를 개발한 Anthropic사의 CEO가 2025년 9월이면 AI가 모든 코드의 90%를 생성하고, 2026년이면 100%를 생성할 것이라고 확신에 차 예측했었다. 그러나 2025년 9월의 현실은 대부분 코드를 개발자가 짜고 있고, AI는 보조 수단은 되지만 대체 수단은 안된다. AI에 대한 마케팅 하이프와 이를 순진하게 받아들이는 소비자들의 환상이 얼마나 허망한 것인 지를 단적으로 보여 준다.
국내 매스컴에서 AI가 개발자를 대체할 것이라는 보도가 난무하고 있다. 경솔한 기자들의 근거 없는 기사들이다. 예를 들어, 헤럴드 경제 | 네이버 뉴스는 최근 2025년 5월 마이크로소프트가 6000명을 해고한 사건에 대해 "구조조정의 가장 큰 희생양이 AI가 대체 할 수 있는 개발자들인 것으로 나타났다. 소프트웨어 개발자가 전체 감원 인원의 40% 이상을 차지한다."라고 보도하였다.
The Economic Times의 보도에 따르면, 이번 해고는 마이크로소프트가 AI 인프라에 800억 달러를 투자한 결과 매출 이익이 70% 이하로 떨어졌고, 이를 보완하기 위해 주로 60만 달러 이상의 연봉을 받는 관리자 및 시니어 엔지니어 등 고임금 직원들을 해고하여 인건비를 줄이려는 시도이다.
AP 통신도 이번 해고가 AI가 사람을 대체하는 현상으로 볼 수 없다고 보도했다.
일부 국내 기자들이 AI 바람 부는 데 편승하여 왜곡된 기사를 쓰고, 일부 SW 경영자들이 그 말을 믿고 개발자들을 AI로 대체할 수 있다고 생각하게 될까 봐 심히 우려가 된다.
본고의 Vibe 코딩에서 살펴 봤 듯이, AI가 SW 코딩 시간을 줄여줄 수 있지만, 개발자가 AI가 만든 SW 오류를 알아내고 고칠 수 있는 능력이 있어야 한다. SW 개발 팀에서 AI 덕분에 단기적으로 초급 개발자의 수를 줄일 수 있지만, 초급 개발자를 잘 안 키우면 장기적으로 AI를 제대로 활용할 수 있는 중고급 개발자가 부족해져 SW 기업과 SW 산업의 성장이 어려워진다는 점을 간과하면 안된다.
* * *
마이크로소프트가 최근 2025년 7월 9000명을 추가 해고했다. 금년 2025년 상반기에 15000명을 해고한 것이다. 이를 보고서도 혹자는 AI가 사람을 대체한 현상이라 해석하는 데, 이는 해고의 주요 원인이 아니다. 아래 링크의 Economic Times 기사에서 보듯이, 클라우드, 모바일, AI 등 IT 기술 환경 변화에 대처한 사업 구조 및 조직 구조의 조정이었던 것이다.
IT 기업이 IT 기술 환경 변화에 선제적으로 대응하지 않을 경우, 도산까지 갈 수 있음을 마이크로소프트는 깊이 깨닫고 있는 것이다. IT 기술 환경이 메인프레임 컴퓨팅에서 클라이언트/서버 컴퓨팅으로 바뀌던 1980년대에, 그 당시 압도적 최대 IT 기업이었던 IBM이 환경 변화에 대응하지 못해 1990년대 초에 역사 상 최대 적자를 내고 도산 직전에 갔었던 걸 기억하고 있는 것이다. IBM은 다행히 Louis Gerstner 신임 회장이 이끈 파괴적 구조조정으로 살아는 났지만, 더 이상 최대 IT 기업의 위상은 놓치고 말았다. 마이크로소프트는 최대 IT 기업의 위상을 견지하기 위해 선제적으로 구조 조정을 강행하고 있는 것이다.
이번 해고는 주로 게임 사업, 마케팅/영업, 중간 관리층 영역에 집중됐다고 한다. IT 환경 변화에 민감한 사업 부문 및 경영 부문을 손 봤고, 조직의 의사 결정 계층 단계를 줄였다. 1990년대 미국의 많은 기업이 클라이언트/서버 컴퓨팅을 비즈니스 프로세스 리엔지니어링(BPR)과 결합시키면서 국제 경쟁력을 회복했을 때, 기업의 의사 결정 계층 단계를 평균 7단계에서 3단계로 줄였던 게 되풀이되고 있다. IT 기술 환경은 계속 변화할 것이고 모든 기업은 이에 선제적으로 대응하여 신규 IT 기술을 이용한 비즈니스 프로세스 자동화와 의사 결정 자동화를 끊임 없이 추진해야 하는 것이다.
AI도 IT 기술의 하나로, 프로세스 및 의사 결정 자동화에 기여함으로써 사업 및 조직 구조 조정에 일조할 수 있도록 잘 활용해야 할 것이다. 이 것이 우리가 마이크로소프트의 해고 소식에서 얻어야 할 교훈이라고 생각된다.
* * *
OpenAI의 공동 설립자인 Andrej Karpathy나 Amazon, Google에서 인프라 자동화를 이끌었던 Steve Yegge 같은 천재 프로그래머들은 "개발자가 AI로 대체되기는 커녕 앞으로 훨씬 더 가치가 올라갈 것"이라고 예측한다. (https://medium.com/@amareshadak/two-ai-legends-predict-the-future-of-programming-and-its-not-what-you-think-d902f4569127)
그렇다면 미래의 개발자는 어떤 모습일까?
우선 과거를 돌아 보자. 프로그래밍의 진화를 보면,
Machine Language -->
Assembly Language -->
Higher-Level Language (예: Cobol) -->
CASE Tool with 100% Code Generation (예: IEF) -->
Object-Oriented Language (예: Java) -->
No / Low Code Development Platform (예: OutSystems) -->
Vibe Coding (예: GitHub Copilot) 및 Agentic Coding (예: Devin)으로 발전해 왔다.
매 발전 단계마다 개발 생산성의 획기적인 개선이 있었고, 이를 보고 혹자는 이제 개발자에 대한 수요가 줄어들 거라고 예측하곤 했는데, 개발자가 실제로 줄지 않고, SW의 활용 범위가 확대되면서 개발 수요가 증가했다.
매 발전 단계마다 새로운 개발 방식을 빨리 습득한 개발자는 경쟁력을 확보하고 그러지 못한 개발자는 도태했다. LLM을 활용하는 Vibe Coding 및 Agentic Coding이 확산되는 가운데 개발자들은 이러한 새로운 개발 방식에 익숙해져야 경쟁력을 유지한다.
새로운 개발 방식에서 요구되는 능력은 어떤 걸까?
바이브 및 에이전트 코딩 툴의 활용
SW요구사항을 자연어로 자세히 정확하게 표현
AI가 생성한 코드의 디버깅
AI 툴을 이용한 SW테스트 자동화
AI가 저지르는 바보 짓의 패턴을 알고 AI를 감시
AI 모듈을 API를 노출하는 SOA 서비스로 개발하고, 애플리케이션을 구성하는 다른 서비스들과 Orchestration 또는 Choreography로 연결하는 SW아키텍처 설계
자, 이제 개발자가 없어질 거라는 우려는 떨쳐내고, 새로운 개발 능력을 확보하는 데 정진하자!




Comments