AI 코딩의 현실: 100% AI 작성 주장 너머의 진실
“클로드 코드 제작자는 이제 자신의 모든 기여가 100% 클로드에 의해 작성되었다고 확인했다”라는 문장을 접한 사람들은 곧바로 “이제 딸깍 바이브 코딩이 표준이 되겠네”라고 반응한다. 하지만 이 문장을 액면 그대로 받아들이는 것은 현실을 왜곡하는 순진한 해석에 가깝다. 이 주장은 전문가가 필요 없어졌다는 증거라기보다, 개발자가 코드를 직접 치지 않고 프롬프트로 해결책을 도출하는 방식으로 역할을 이동시켰다는 증거에 더 가깝다.
Claude Code의 “100%” 주장에 대한 정확한 맥락을 살펴보면, 이 발언은 Anthropic의 엔지니어 Boris Power가 2025년 6월 Latent Space 팟캐스트에서 실제로는 “약 80%”라고 밝힌 것이 시작이다. 그러나 더 중요한 부분은 그가 즉시 덧붙인 문장이다. “하지만 인간이 여전히 방향을 제시했고, 반드시 코드를 검토했습니다.” 이 문장이 핵심인데, 많은 사람들이 이 부분을 의도적으로 생략하거나 간과한다. 이것은 단순히 “AI가 코드의 80%를 작성했다”는 표면적 사실이 아니라, 숙련된 개발자가 이미 정확히 어떤 구조로, 어떤 의도로 코드가 작성되어야 하는지 알고 있는 상태에서 AI에게 명확한 지시를 내리고, 생성된 코드를 검증하고, 필요시 수정 지시를 반복한 결과다. 즉, 개발자의 역할이 사라진 것이 아니라 코드 작성에서 프롬프트 설계, 아키텍처 검증, 품질 관리로 이동한 것이다.
“Vibe coding”이라는 용어는 OpenAI 공동창업자 Andrej Karpathy가 2025년 2월 소개한 개념으로, “완전히 분위기에 몸을 맡기고, 기하급수적 성장을 받아들이며, 코드가 존재한다는 사실조차 잊어버리는 것”이라고 정의했다. Karpathy는 개발자들이 대화형 프롬프트를 사용하여 AI 도구를 가이드하는 방식으로의 전환을 설명했다. “character by character” 코드 작성에서 “보고, 말하고, 실행하고, 복사-붙여넣기 하는” 방식으로의 전환이다. 이 용어는 2025년 Collins Dictionary의 올해의 단어로 선정될 만큼 빠르게 확산되었다. 2025년 초 데이터에 따르면 약 44%의 개발자가 AI 코딩 도구를 채택했으며, 이 수치는 계속 증가하고 있다. GitHub Copilot, Cursor, Replit 같은 도구의 발전으로 기업과 스타트업은 vibe coding 접근법을 사용하여 프로젝트 완료를 최대 55% 빠르게 달성했다고 보고한다. Y Combinator의 2025년 Winter 배치에서는 25%의 스타트업이 95% AI 생성 코드베이스를 사용했다는 보고가 나왔다.
그러나 실제 현장에서는 이 개념이 심각한 문제들을 드러내고 있다. 2025년 9월 Fast Company는 “Vibe coding 숙취가 시작되었다”는 제목의 기사에서 시니어 엔지니어들이 AI 생성 코드 작업을 “개발 지옥”이라고 표현하고 있다고 보도했다. 스웨덴의 vibe coding 앱 Lovable은 2025년 5월 심각한 보안 취약점 문제가 발견되었는데, 생성된 1,645개 웹 애플리케이션 중 170개가 개인정보 유출 가능성이 있는 취약점을 가지고 있었다. 이는 전체의 약 10%에 해당하는 비율이다.
실제 생산성 데이터는 매우 복잡한 그림을 보여준다. McKinsey의 최신 연구에 따르면 AI 도구를 사용하는 소프트웨어 팀의 90% 이상이 주당 평균 6시간을 절약한다고 보고했다. 고성능 조직들은 팀 생산성, 고객 경험, 출시 시간에서 16-30% 개선을, 소프트웨어 품질에서는 31-45% 개선을 보았다. PwC는 AI 도구가 개발자 생산성을 20-50% 향상시킬 수 있다고 주장한다. 비용 절감 측면에서도 14%의 소프트웨어 엔지니어링 조직이 지난 12개월간 운영 비용 11-19% 감소를 경험했으며, 7%의 응답자는 20% 이상의 비용 감소를 보고했다.
하지만 이것은 이야기의 한 면일 뿐이다. 2025년 7월 METR(Model Evaluation and Threat Research)이 발표한 엄격한 무작위 대조 실험 연구는 완전히 다른 결과를 보여준다. 이 연구는 대형 오픈소스 프로젝트(평균 22,000+ stars, 100만+ 코드 라인)에 수년간 기여해온 경험 많은 개발자 16명을 대상으로 246개의 실제 작업을 무작위로 AI 허용/불허용 그룹으로 나누어 진행했다. 사용된 도구는 주로 Cursor Pro와 Claude 3.5/3.7 Sonnet이었다. 결과는 충격적이었다. 개발자들은 작업 전에 AI가 24% 시간을 단축할 것이라 예상했고, 작업 후에도 20% 단축했다고 추정했지만, 실제 측정 결과는 정반대였다. AI 도구를 사용한 개발자들이 오히려 19% 더 느렸다. 이는 경제학 전문가들의 예측(39% 빠름)과 ML 전문가들의 예측(38% 빠름)과도 정반대되는 결과다.
이 모순을 어떻게 이해해야 할까? McKinsey 연구에서 중요한 단서를 제공한다. 복잡도가 높은 작업에서는 시간 절약이 10% 미만으로 급격히 떨어진다. 특히 개발자가 익숙하지 않은 프로그래밍 프레임워크를 다루어야 하는 경우 효과가 거의 사라진다. 반면 단순 반복 작업, 보일러플레이트 코드 생성, 문서화 같은 루틴한 작업에서는 극적인 생산성 향상을 보인다. 이것이 바로 핵심 통찰로 이어진다. AI는 개발자의 가치를 희석시키는 것이 아니라, 무엇을 이해하지 못한 개발자를 더 빠르게 드러내는 도구가 되고 있다.
2025년 7월 Fastly의 설문조사에 따르면 10년 이상 경력의 개발자들이 주니어 개발자들보다 코드의 절반 이상을 AI로 작성할 가능성이 2배 이상 높다. 이들은 AI를 사용하여 2.5배 빠르게 코드를 배포하지만, 동시에 자신들의 일상을 “AI 베이비시팅”이라고 표현한다. 즉, AI가 생성한 코드를 면밀히 검토하고 디버깅하는 데 상당한 시간을 투자해야 한다는 의미다. 실제 개발자들의 워크플로우 변화를 보면 이 점이 더욱 명확해진다. Claude Code를 효과적으로 사용하는 개발자들은 “먼저 좋은 스펙을 작성하라. 스펙에 충분한 시간을 투자하라. 처음부터 테스트를 확보하라”고 조언한다. 한 사용자는 “AI를 감독하고 명시적인 지시를 주어라. 완료된 후에는 ‘당신은 주니어의 작업을 검토하는 스태프 엔지니어입니다’라는 식으로 프롬프트를 주어라”고 말한다. 이것은 개발자의 역할이 코더에서 검토자와 아키텍트로 전환되고 있음을 보여준다.
GitHub Copilot의 실제 사용 데이터를 보면 이 현실이 더욱 분명해진다. 2025년 1분기 데이터에 따르면 Copilot은 46%의 코드 완성률을 제공하지만, 개발자들은 그중 약 30%만 실제로 수용한다. 즉, AI가 제안한 코드의 70%는 개발자의 검토 과정에서 거부된다. 이것은 개발자의 판단력과 검증 능력이 여전히 핵심적이라는 증거다. 더 우려스러운 것은 코드 품질 문제다. AI 도구 사용으로 코드 중복이 4배 증가했고, 단기 코드 변경(churn)이 증가하고 있다. 이는 복사-붙여넣기는 많아졌지만 유지보수 가능한 설계는 줄어들고 있음을 시사한다. 2025년 1분기 조사에서 75%의 개발자가 여전히 모든 AI 생성 코드 스니펫을 병합 전에 수동으로 검토한다고 답했다. 이것은 AI가 여전히 보조 도구이며, 최종 책임은 인간 개발자에게 있음을 보여준다.
실제로 코딩 능력이 제한적인 사람들에게 AI 도구가 어떤 영향을 미치는지를 보여주는 사례도 있다. New York Times의 Kevin Roose는 2025년 2월 전문 코더가 아닌 입장에서 vibe coding으로 여러 소규모 애플리케이션을 만드는 실험을 했다. 그는 냉장고 내용을 분석해서 도시락 아이템을 제안하는 앱 같은 “소프트웨어 for one”을 만들 수 있었지만, 결과는 제한적이고 오류가 많았다. 한 경우 AI 생성 코드가 전자상거래 사이트에 가짜 리뷰를 만들어냈다. 그는 AI 보조 코딩이 개인이 이전에는 엔지니어링 팀이 필요했던 소프트웨어를 개발할 수 있게 하지만, 그 품질과 안정성은 전문가의 것과는 거리가 멀다고 결론지었다.
Claude Code의 제작자 자신이 경고를 보내고 있다는 점도 중요하다. 2025년 12월 Medium 기사에 따르면, Claude Code 제작자는 개발자들이 AI 생성 코드를 너무 맹목적으로 신뢰하고 있다고 우려를 표명했다. 문제는 AI가 무능력해서가 아니라, 개발자들이 AI에게 생각을 대신하게 하는 데 너무 익숙해지고 있다는 것이다. 도구를 만든 사람이 그 도구의 사용 방식에 대해 우려를 표명할 때, 업계는 귀를 기울여야 한다. AI 생성 코드는 보통 컴파일되고, 기본 테스트를 통과하며, 스타일 가이드를 따른다. 하지만 실제 보안 취약점이 숨어있을 수 있고, 장기적 유지보수성 문제가 있을 수 있으며, 개발자가 직접 작성하지 않은 코드이므로 완전히 이해하지 못할 수 있다.
McKinsey의 최신 인터뷰에서 Jellyfish CEO Andrew Lau는 매우 통찰력 있는 지적을 한다. “수십 년 동안 우리는 코딩이 어려운 부분이라고 생각했습니다. 알고 보니 무엇을 만들어야 하는지 설명하는 것이 더 어렵습니다. 생성 도구가 코드 작성을 쉽게 만들어주면서, 올바른 의도, 즉 ‘스펙’을 정의하는 것이 핵심적인 인간의 작업이 될 것입니다. 이러한 변화는 개발 프로세스에서 누가 가치를 더하는지를 바꿉니다. 명확성, 시스템 사고, 그리고 AI를 올바른 결과로 안내하는 능력이 보상받을 것입니다.” 이것은 AI가 강력해질수록 달라지는 것은 ‘누가 코드를 치느냐’이지, ‘누가 문제를 정의하고 책임지느냐’는 아니라는 점과 정확히 일치한다.
2025년 개발자의 핵심 역량은 근본적으로 변화했다. 명확한 스펙 작성 능력, 즉 AI에게 무엇을 만들어야 하는지 정확히 설명하는 능력이 필수가 되었다. 시스템 설계, 즉 구성 요소들이 어떻게 맞춰지는지 이해하는 능력도 중요하다. 코드 리뷰, 즉 AI 솔루션이 올바르게 작동하는지 빠르게 확인하는 능력, 패턴 인식, 즉 AI 제안이 합리적인지 판단하는 능력, 그리고 AI 도구 오케스트레이션, 즉 전문화된 도구들을 조합하여 사용하는 능력이 요구된다. 이러한 역량들은 전통적인 프로그래밍 지식 위에 구축되며, 그것을 대체하지 않는다.
AI 코딩 도구가 가져온 가장 아이러니한 결과 중 하나는 문서화의 중요성이 줄어든 것이 아니라 오히려 기하급수적으로 증가했다는 점이다. AI 생성 코드는 인간이 읽을 수 있는 설명이 필요하다. 프로젝트 요구사항 문서가 이전보다 훨씬 더 상세하고 구조화되어야 한다. “Spec Flow” 접근법을 사용하는 개발자들은 AI에게 작업을 맡기기 전에 기능, 기술 스택, 아키텍처, 구현 세부사항을 명확히 문서화하는 데 상당한 시간을 투자한다. AI는 이 문서를 읽고, 기존 코드베이스를 검토한 후, 현재 기술 스택을 사용하여 솔루션을 설계한다.
효과적인 AI 코딩을 위해서는 개발자가 더 넓은 역량을 갖춰야 한다는 것도 명확해졌다. 아키텍처 설계, 테스팅 전략, 보안 이해, 여러 프로그래밍 패러다임 이해 같은 기술적 역량뿐만 아니라, 아이디어를 명확하게 설명하는 소프트 스킬도 필요하다. 왜냐하면 이제 인간과 AI 모두에게 설명해야 하기 때문이다. 단순히 코딩만 잘하는 것으로는 부족하다. 2025년 현재 AI 전문성을 가진 개발자들의 급여 데이터가 이를 증명한다. AI 역량을 갖춘 엔트리 레벨 개발자는 연봉 $90,000-$130,000을 받는 반면, 전통적인 개발 직무는 $65,000-$85,000이다. 이것은 AI 도구가 개발자를 대체하는 것이 아니라, AI를 효과적으로 사용할 수 있는 새로운 종류의 전문성이 높은 가치를 갖게 되었음을 보여준다.
2025년 현재 82%의 개발자가 주간 단위로 AI 도구를 사용하며, 59%가 3개 이상의 AI 도구를 병렬로 사용한다. Google 코드의 25%가 AI 보조로 작성되지만, CEO Sundar Pichai는 엔지니어링 속도가 10% 향상되었을 뿐이라고 강조한다. 가장 빠른 AI 채택은 10명 이하의 소규모 개발팀에서 일어나고 있으며, 활성 사용자의 51%가 소규모 팀에 속한다. Cursor는 2025년 6월까지 연간 반복 수익 $500M을 달성하여 $1M에서 $500M ARR까지 단 12개월 만에 도달했는데, 이는 SaaS 역사상 가장 빠른 성장이다. GitHub Copilot은 보고된 ARR $400M과 130만 유료 구독자를 보유하고 있으며, Claude Code는 2025년 5월 일반 출시 후 사용량이 10배 증가하여 연간 매출 5억 달러 이상으로 성장했다.
그러나 2025년 AI 엔지니어링 트렌드를 분석한 The New Stack의 보고서는 vibe coding의 장기적 실행 가능성에 대해 회의적이다. 코드 품질 문제가 미해결 상태이고, 유지보수성 문제가 지속되며, 완전 자율 에이전트에 대한 과장된 주장과 MCP의 보안 위험이 존재한다. AI 엔지니어링 도구와 개발 관행이 여전히 다소 취약하고 미성숙하다는 평가다. Andrew Ng는 “vibe coding”이라는 용어 자체가 오해를 불러일으킨다고 비판했는데, 소프트웨어 엔지니어들이 AI 도구를 사용할 때 단순히 “분위기에 맞춰 간다”고 생각하게 만든다는 것이다. 실제로는 훨씬 더 체계적이고 전문적인 접근이 필요하다.
McKinsey 연구에서 AI 도구가 큰 생산성 향상을 가져온 영역은 명확히 구분된다. 수동 및 반복 작업 가속화, 즉 표준 함수 자동 채우기, 타이핑 중 코드 문장 완성, 표준 형식의 코드 기능 문서화 같은 작업에서 효과가 크다. 빠른 프로토타이핑, 즉 아이디어에서 작동하는 코드까지의 시간 단축과 여러 아이디어를 병렬로 프로토타입하는 능력도 향상되었다. 테스트 생성, 특히 단위 테스트 자동 생성은 소규모 기업에서 최대 50% 빠르게 이루어진다. 코드 리팩토링 및 현대화, 즉 레거시 코드를 마이크로서비스로 리팩토링하고 다중 파일 리팩토링 작업을 자동 실행하는 것도 가능해졌다. 프로토타이핑 및 개념 증명, 테스트 작성, 프로그래밍 언어 간 코드 변환, 문서화 자동화, 보일러플레이트 코드 생성 같은 작업들은 vibe coding에 자연스럽게 적합하다. 핵심은 명확성이다. 입력과 기대사항이 더 구조화될수록 AI의 성능이 향상된다.
반면 AI는 단순 작업에서는 매우 능력이 뛰어나지만, 새로운 복잡한 코딩 문제, 특히 다중 파일 프로젝트, 문서화가 부실한 라이브러리 사용, 실제 세계에 영향을 미치는 중요한 코드, 혁신적인 돌파구가 필요한 문제에서는 여전히 어려움을 겪는다. LLM은 코드를 동적으로 생성하며, 구조가 변동될 수 있다. 또한 개발자가 직접 작성하지 않은 코드이므로 자신이 사용하지 않은 구문이나 개념을 완전히 이해하지 못할 수 있다. AI 생성 코드는 개발자가 즉시 포착하지 못할 수 있는 보안 취약점을 도입할 수 있다. AI는 특정 환경의 보안 모범 사례를 항상 이해하지 못하며, 공개 코드 저장소에서 훈련되어 많은 불안전한 코드 예제를 포함하고 있다. 인증 시스템, 데이터베이스 쿼리, API 엔드포인트 생성 시 일반적인 보안 실수를 재현할 수 있다.
흥미롭게도 McKinsey에 따르면 AI 도구를 사용하는 개발자들은 더 행복하다고 보고하고, 더 성취감을 느끼며, 정기적으로 “몰입 상태”에 진입한다. 이것은 스마트한 AI 채택이 팀 사기에도 좋다는 신호다. 시니어 개발자들의 인터뷰에서는 AI 베이비시팅이 지루하게 느껴질 수 있지만, 창의적인 문제 해결을 위한 시간을 확보하고 백로그에 묻혀있던 혁신적 기능을 구현할 수 있게 해준다고 말한다. “수고할 가치가 있다”는 것이다. 왜냐하면 인간의 독창성을 증폭시키기 때문이다.
일부 기업의 인터뷰는 이제 전통적인 코드 테스트 대신 프롬프트를 제공하고, AI를 어떻게 가이드하는지 평가하며, 단순히 무엇을 타이핑할 수 있는지가 아니라 얼마나 효과적으로 AI를 활용하는지 측정한다. AI를 효과적으로 활용하려면 더 높은 수준의 시니어리티와 더 넓은 사고가 필요하며, 기술적 이해와 의사소통 능력의 조합이 요구된다. 2026년과 그 너머를 바라보면 음성 기반 개발, 지속적 코드베이스 에이전트, Parameter-Efficient Fine-Tuning의 확대, 관찰성 플랫폼과의 통합 같은 기술적 발전이 예상된다. 개발자의 역할은 시스템 설계자 및 AI 가이드로, 코드 작성은 문제 정의 및 솔루션 검증으로, 개별 작업은 다중 AI 에이전트 조율로 진화할 것이다. 그러나 보안 및 컴플라이언스, IP 및 저작권 문제, AI 생성 코드의 책임 소재, 장기적 유지보수성 같은 지속적인 과제들이 남아있다.
결국 AI가 강력해질수록 달라지는 것은 ‘누가 코드를 치느냐’이지, ‘누가 문제를 정의하고 책임지느냐’는 아니다. 정답이 존재하고 패턴이 축적된 영역에서는 AI가 개발 속도를 극단적으로 끌어올릴 수 있으며, 단순 반복 작업에서 극적인 생산성 향상을 보인다. 하지만 정답이 없고, 맥락과 트레이드오프를 고려해야 하는 영역에서는 오히려 더 깊은 전문성과 판단력이 요구된다. AI가 제안을 할 수 있지만, 최종 결정은 인간의 몫이다. AI는 개발자의 가치를 희석시키지 않는다. 오히려 무엇을 이해하지 못한 개발자를 더 빠르게 드러내고, 진짜 전문성과 AI 의존의 차이를 명확히 한다. 프로젝트가 복잡해지고, 버그가 발생하고, 스케일링이 필요해질 때 그 차이가 결정적이 된다.
“100% AI가 작성했다”는 주장을 순진하게 받아들이는 것은 위험하다. 이는 마치 “자동차가 100% 자율주행했다”고 말하면서 운전자가 계속 핸들을 잡고 브레이크를 밟을 준비를 하고 있다는 사실을 생략하는 것과 같다. Claude Code의 경우, 숙련된 엔지니어가 정확히 무엇이 필요한지 알고 있고, 명확한 지시를 내리고, 생성된 코드를 검증하고, 필요시 수정을 요구하며, 전 과정을 관리했다. 이것은 개발자가 필요 없어졌다는 증거가 아니라, 개발자의 역할이 저수준 코딩에서 고수준 오케스트레이션과 품질 보증으로 이동했다는 증거다.
이 변화가 가져올 미래는 개발자 없는 세상이 아니라, 더 높은 수준의 사고와 판단력을 갖춘 개발자가 필수적인 세상이다. AI는 도구이지 대체물이 아니다. 모든 강력한 도구가 그렇듯, 그것을 효과적으로 사용하려면 그것이 무엇을 하는지, 언제 신뢰할 수 있는지, 언제 의심해야 하는지를 아는 전문가가 필요하다. 2026년 성공적인 개발자는 AI 도구를 마스터한 사람이 아니라 AI 도구를 언제, 어떻게, 왜 사용해야 하는지 아는 사람, 시스템을 설계하고 트레이드오프를 이해하고 품질을 보증할 수 있는 사람, 기술적 깊이와 전략적 사고를 모두 갖춘 사람이다. AI 시대의 개발자는 더 적은 코드를 타이핑하지만, 더 많이 생각하고, 더 잘 설계하고, 더 철저히 검증해야 한다.
작성 일자: 2026-01-01
“클로드 코드 제작자는 이제 자신의 모든 기여가 100% 클로드에 의해 작성되었다고 확인했다”라는 글을 보고, 사람들은 곧바로 “아, 이제 딸깍 바이브 코딩 표준이 되겠네”라고 반응한다. 하지만다 요즘 여러 개발자들이 느끼듯이 이 문장을 그대로 받아들이는 건 꽤 순진한 해석에 가깝다고 생각한다. 이 사례는 전문가가 필요 없어졌다는 증거라기보다, 개발자가 코드를 ‘직접 치지 않고 프롬트로 해결책으로 드리블 하는 방식’으로 역할을 이동시켰다는 증거에 가깝다.
이 제작자는 이미 코드가 어떤 구조로, 어떤 의도로 작성되어야 하는지를 정확히 알고 있는 상태였을 가능성이 높다. 즉, 검증과 판단을 포기한 100% 바이브 코딩이 아니라, 기존의 개발 지식을 전제로 한 고도의 지시·선별·검증 작업을 AI에 위임한 것이다. 이를 단순히 “AI가 코드를 다 썼다”로 요약하는 건 핵심을 의도적으로 흐리는 표현에 가깝다.
결국 AI가 강력해질수록 달라지는 것은 ‘누가 코드를 치느냐’이지, ‘누가 문제를 정의하고 책임지느냐’는 아니다. 이미 정답이 존재하고, 패턴이 축적된 영역에서는 AI가 개발 속도를 극단적으로 끌어올릴 수 있다. 하지만 정답이 없고, 맥락과 트레이드오프, 실패 비용까지 고려해야 하는 문제일수록 오히려 더 깊은 전문성과 판단력이 요구된다.
아이러니하게도, AI는 개발자의 가치를 희석시키기보다 무엇을 이해하지 못한 개발자를 더 빠르게 드러내는 도구가 되고 있다. 그리고 그 차이는 시간이 갈수록 더 분명해질 것이다… 라고 생각하는 오늘이였음….. 생각보다 생각이 기네..
https://www.threads.com/@chosundev/post/DS9RyCiEptU?xmt=AQF0F128RuMa-7DESbFLs9aUgIdVFBUoaTXH-PLqOiwt5yQcPRjvSwDkKk-lMS2iOgHWdXfk&slof=1