"우리 코드의 100%가 AI에 의해 작성된다"는 말이 실제로 의미하는 것

"우리 코드의 100%가 AI에 의해 작성된다"는 말이 실제로 의미하는 것

잘못된 투자 결정, 비현실적인 채용 계획, 그리고 이사회의 혼란을 야기하고 있는 오해 섞인 문장입니다. 이를 자세히 파헤쳐 보겠습니다.

CEO들은 무심코, 마치 지나가는 말처럼 이렇게 말하곤 합니다. "우리 코드의 100%는 AI가 작성합니다."

이 말이 나올 때마다 CFO(최고재무책임자)들은 눈썹을 치켜세웁니다. 이사회 멤버들은 회의 중에 몸을 앞으로 기울이며 묻습니다. "그럼 개발자는 필요 없다는 건가요?"

그 질문이 바로 문제를 드러냅니다. CEO의 발언은 기술적으로는 정확하지만, 소프트웨어 공장(software factory)에 관여하지 않는 사람들에게는 매우 깊게 오해받고 있습니다.

비기술직 종사자들은 "로봇이 모든 소프트웨어를 작성한다"라고 듣습니다. 그것은 현재 상당 부분 가능하긴 하지만, 실제로 그렇게 하고 있는 곳은 정말로 극소수에 불과합니다.

실제로 일어나고 있는 일은 그보다 훨씬 덜 포괄적이며, 이해해야 할 훨씬 더 중요한 내용입니다.

"100% AI 작성 코드"가 (대체로) 어떻게 보이는가

Anthropic의 Chief Product Officer는 최근 Anthropic의 대부분 제품에 대해 사실상 코드의 100%가 Claude에 의해 작성된다는 점을 확인했습니다 [1].

Y Combinator의 CEO는 그들의 2025년 겨울 스타트업 배치(batch) 중 4분의 1이 코드베이스의 95%가 AI로 생성되었다고 보고했습니다 [2].

Dario Amodei (Anthropic의 CEO)는 Davos 2026에서 AI가 6~12개월 이내에 코딩 작업의 "대부분, 어쩌면 전부"를 처리할 수 있을 것이라고 예측했습니다 [3].

이것들은 실제 기업들의 실제 수치입니다. 또한 이들은 대부분의 사람들이 이 말을 들었을 때 상상하는 것과는 매우 다른 무언가를 설명하고 있습니다.

"코드의 100%가 AI에 의해 작성된다"라고 할 때, 대부분의 경우 실제 워크플로(workflow)는 다음과 같습니다:

• 인간이 무엇을 만들지 결정합니다. AI가 아닙니다. 사람이 문제를 식별하고, 접근 방식을 결정하며, 이 기능은 만들 가치가 있고 저 기능은 그렇지 않다는 전략적 판단을 내립니다.
• 인간이 상세한 사양(specification)을 작성합니다. 소프트웨어가 무엇을 해야 하는가? 엣지 케이스(edge cases)는 무엇인가? 제약 조건은 무엇인가? "완료"된 상태는 어떤 모습인가? 이것이 어려운 부분입니다. 사고(thinking)가 필요한 부분입니다. 경험, 노출, 그리고 실전에서의 상처(battle scars)로부터 진정으로 이득을 얻는 부분입니다.

AI가 코드를 생성합니다. 이것이 CEO가 말하고 있는 부분입니다. AI는 인간의 명세(specification)를 작동하는 코드로 변환합니다. 빠르고, 인상적일 정도로 빠르게, 그리고 저렴하게 말이죠. 인간은 출력물을 검토합니다. 그것이 실제로 명세된 대로 작동하는가? 접근 방식이 타당한가? 보안 취약점(security holes)은 없는가? 확장(scale)이 가능한가? 다른 모든 것과 통합되는가? 이 과정에서 AI가 점점 더 많은 도움을 주고 있으며, 특히 테스트 주도 개발 (Test-Driven Development, "TDD")과 같은 전략이 사용될 때 더욱 그러합니다. AI는 피드백에 따라 수정합니다 (필요한 경우). 테스터가 "X 때문에 이 방식은 작동하지 않습니다"라고 말하면, AI는 이를 조정하여 4단계로 돌아갑니다. 인간은 검증하고 배포(ship)합니다. 누군가는 그것이 프로덕션(production)에 투입될 준비가 되었다고 결정합니다. 누군가는 그 결정에 책임을 지며, 누군가는 소프트웨어를 패키징하여 고객이 사용할 수 있도록 만듭니다. 이것은 에이전트(agents)로 이동하고 있습니다. 저는 오늘 제 GitHub 계정을 사용하여 온라인 데이터베이스 호스트에 로그인했고, Mac(저의 Openclaw 에이전트)이 프로젝트를 온라인에 푸시하고, 구성(configure)한 뒤, 나머지 과정을 안내해 주었습니다. AI는 무엇을 만들지, 혹은 왜 만들어야 하는지를 단 한 번도 결정하지 않았습니다. AI는 타이핑했습니다. 매우 빠르고, 매우 유능하며, 패턴과 구문(syntax)에 대한 끝없는 지식을 바탕으로 말이죠. 하지만 AI는 인간이 입력하도록 지시한 내용을 타이핑했을 뿐이며, 인간은 배포되기 전에 모든 줄을 검증했습니다. 최첨단 AI 사용자들은 이에 대해 약간의 이의를 제기할 수도 있습니다. 이 각각의 역할들이 점점 더 높은 수준으로 AI의 도움을 받고 있기 때문입니다. 그 부분은 나중에 다시 다루겠지만, 지금은 여기서 설명한 대로 상상해 봅시다.

고려해 볼 만한 건설 비유

대형 건물이 세워지는 모습을 상상해 보십시오. 이 과정에는 설계자(architect), 종합 건설업자(general contractor, foreman), 하도급업자(subcontractors), 그리고 작업자(workers, 벽돌공, 전기 기술자, 배관공)가 포함됩니다. 누군가가 "우리 코드의 100%가 AI에 의해 작성된다"라고 말할 때, 그들은 다음과 같이 말하는 것입니다: 벽돌 쌓기가 자동화되었다. 벽돌을 놓거나, 전선을 깔고, 파이프를 끼우는 물리적인 행위가 이제 기계에 의해 수행된다는 것입니다. 그것은 진정으로 변혁적입니다. 과거에 벽돌 쌓기는 느리고 비용이 많이 들었으며, 엄청난 숙련 노동력이 필요했습니다.

하지만 건축에는 여전히 다음과 같은 요소들이 필요합니다: 구조를 설계하고, 미적·기능적 결정을 내리며, 규정을 준수하는지 확인하고, 설계에 대한 전문적 책임을 지는 건축가 (Architect)가 필요합니다. (소프트웨어의 경우: 무엇을 만들지, 시스템이 어떻게 결합될지를 결정하는 제품 소유자 (Product Owner), 시스템 아키텍트 (System Architect), 그리고 기술 리드 (Technical Lead)가 이에 해당합니다.) 각 공정을 조정하고, 작업 순서를 정하며, 설계도가 현실과 맞닥뜨릴 때 발생하는 문제를 해결하고, 현장에서 판단을 내리는 종합 건설업자 (General Contractor)가 필요합니다. (소프트웨어의 경우: AI를 조율하고, 결과물을 검토하며, 실수를 잡아내고, 명세서(Specs)가 결코 다루지 못하는 수백 가지의 작은 결정들을 내리는 테크 리드 (Tech Lead) 또는 시니어 엔지니어 (Senior Engineer)가 이에 해당합니다.) 작업이 표준을 충족하는지, 기초가 튼튼한지, 배선이 안전한지, 배관에 누수가 없는지를 검증하는 검사관 (Inspector)이 필요합니다. (소프트웨어의 경우: QA, 보안 검토 (Security Review), 코드 리뷰 (Code Review), 그리고 컴플라이언스 검증 (Compliance Verification)이 이에 해당합니다.) AI는 벽돌 쌓기를 자동화했으며, 현대의 최첨단 기술로 사용될 때 종합 건설업자의 업무 일부와 검사관의 업무 일부를 처리하기 시작했습니다. Claude Code나 Devin과 같은 도구들은 이제 다단계 작업을 조율하고, 파일 간의 협업을 조정하며, 일부 순서 결정(Sequencing decisions)을 자율적으로 내릴 수 있습니다. 이는 2025년 말/2026년 초 기준으로 새로운 변화입니다. 에이전트 군집 (Agent swarms)이나 에이전트 팀을 조율하기 위해 도구를 사용하는 방법을 아는 숙련된 사용자들에게는 '현장 소장 (Foreman)' 계층이 자동화될 수 있습니다. 하지만 건축가는 어떨까요? 전문 검사관은요? 가장 복잡한 구조물의 종합 건설업자는요? 그 역할들은 어디로도 사라지지 않았습니다. 벽돌이 아무리 빨리 쌓이더라도, 건물은 스스로 설계되지 않습니다.

시간이 실제로 소요되는 곳
"코드의 100%가 AI에 의해 작성된다"는 프레임은 전체 이야기를 다 말해주지 않습니다. 그것은 코딩이 업무의 전부인 것처럼 들리게 만듭니다. 코딩은 결코 업무의 전부였던 적이 없습니다. 소프트웨어 개발 생명주기 (Software Development Lifecycle)는 대략 다음과 같이 나뉩니다:
요구사항 정의 및 계획 (Requirements and planning): 노력의 15-20%. 문제를 이해하고, 무엇을 만들지 정의하며, 작업 범위를 설정하고, 우선순위 결정을 내리는 단계입니다.

Architecture and design (아키텍처 및 설계): 노력의 10-15%. 구성 요소들이 어떻게 서로 맞물릴 것인가? 어떤 패턴을 사용할 것인가? 어떤 트레이드오프 (trade-offs)가 있는가? 무엇이 확장 가능하고 무엇이 불가능한가?

Coding (implementation) (코딩 (구현)): 노력의 15-20%. 설계를 작동하는 소프트웨어로 변환하는 과정입니다. 이것이 바로 AI가 자동화하는 부분입니다.

Testing and verification (테스트 및 검증): 노력의 15-25%. 제대로 작동하는가? 부하 상황에서도 작동하는가? 잘못된 데이터에서도 작동하는가? 여러 플랫폼에서 작동하는가? 접근성 (accessibility) 요구 사항을 충족하는가?

Deployment and operations (배포 및 운영): 노력의 10-15%. 프로덕션 (production) 환경에 적용하기. 모니터링하기. 시스템을 유지하기.

Maintenance and evolution (유지보수 및 진화): 전체 라이프사이클 (lifecycle) 비용의 40-80% [4]. 버그 수정, 의존성 (dependencies) 업데이트, 변경되는 요구 사항에 적응, 보안 취약점 패치, 출시 후 수년간 시스템을 가동 상태로 유지하기.

이 숫자들을 다시 한번 읽어보십시오. AI가 자동화하는 부분인 코딩은 소프트웨어를 만드는 노력의 약 15-20%를 차지하며, 수명 주기 동안 발생하는 총 소유 비용 (total cost of ownership) 측면에서는 훨씬 더 작은 비중을 차지합니다. 유지보수 비용만으로도 초기 개발 비용보다 3-4배 더 큽니다. CEO가 "우리 코드의 100%는 AI에 의해 작성된다"라고 말할 때, 그들은 "AI가 전체 생성 노력의 15-20%를 처리한다"라고 말하는 것입니다. 사실입니다. 가치 있는 일입니다. 하지만 청중이 듣는 내용은 아닙니다.

그리고 조직이 나머지 부분을 가속화하지 않고 오직 그 15-20%만을 가속화할 때, 그들은 더 빨라지는 것이 아니라 채찍 효과 (bullwhip effect)를 겪게 됩니다. 테스트, 리뷰, 배포가 비례해서 빨라지지 않은 채 코드 생성만 빨라지면 병목 현상 (bottleneck)의 위치만 옮겨질 뿐이며, 전체 가치 스트림 (value stream) 전반에 걸쳐 진동을 만들어냅니다. 제가 워터베드 문제 (waterbed problem)에 관한 동반 기사에서 썼듯이, 전체 처리량 (throughput)은 가장 느린 단계에 의해 제한됩니다. 수동 검사를 유지하면서 벽돌 쌓기만 자동화하는 것은 품질 재앙이나 값비싼 유휴 시간 (idle time)을 초래하는 레시피입니다.

크레인 비유가 중요한 이유
"우리 코드의 100%는 AI에 의해 작성된다"라고 말하는 소프트웨어 또는 AI 기업의 CEO는 "우리 건물의 100%는 크레인에 의해 세워진다"라고 말하는 건설업계 CEO와 같습니다. 기술적으로는 크레인이 모든 보 (beam)를 들어 올립니다. 하지만 누군가는 건물을 설계했습니다. 누군가는 용접 부위를 검사했습니다.

누군가는 부지 내에 구조물이 어디에 위치할지 결정하고, 허가를 협상하며, 예산을 관리하고, 최종 점유 승인(occupancy)을 할 것입니다. 크레인은 작업에서 가장 눈에 띄는 부분일 수 있지만, 지능의 관점에서는 아마도 가장 흥미롭지 않은 부분이 될 것입니다. 지능은 의사결정에 있습니다. AI가 노동력을 제공하는 것입니다. 이 구분이 중요한 이유는 '100% AI 작성'이라는 서사가 실제 세계적인 결과를 초래하고 있기 때문입니다. 잘못된 투자 결정. 투자자들은

그들은 여전히 아키텍처 (Architecture), 설계 (Design), 리뷰 (Review), 디버깅 (Debugging), 그리고 의사결정 (Decision-making)을 수행하고 있습니다. 단지 벽돌을 쌓는 작업 (Bricklaying)을 하지 않을 뿐입니다. 이 주장의 솔직한 버전은 다음과 같습니다: "우리 시니어 엔지니어들은 이제 코드를 타이핑하는 대신 아키텍처, 설계, 사양 정의 (Specification), 리뷰, 그리고 검증 (Verification)에 시간의 80%를 소비합니다. AI가 타이핑을 처리하기 때문입니다. 우리는 여전히 그 엔지니어들 한 명 한 명이 필요합니다. 사실 우리는 그들이 이전보다 더 시니어급이 되기를 요구합니다. 코드가 더 빠르게 생성될수록 판단력 (Judgment calls)이 더 중요해지기 때문입니다." 이 방식은 덜 자극적이지만, 또한 정확합니다. 사실, 이 새로운 워크플로우 (Workflow)에서 가장 중요한 기술은 전통적인 엔지니어링 기술이 전혀 아닙니다. 바로 제품 관리 (Product Management) 기술입니다. 요구사항을 명확하게 정의하고, 문제를 지능적으로 분해하며, 풍부한 맥락 (Context)을 제공하고, 제품에 대한 안목 (Product taste)으로 결과물을 평가하는 능력 말입니다. AI의 도움을 받는 최고의 엔지니어는 가장 빠른 코더 (Coder)가 아닙니다. 그들은 최고의 사양 정의자 (Specifier)입니다. 오랫동안 "소프트 스킬 (Soft skill)"로 간주되었던 PM 기술셋 (PM skillset)이 AI의 생산성을 끌어올리는 "하드 스킬 (Hard skill)"임이 드러나고 있습니다.

왜 코더 (Coder)의 100%가 사라지지 않는가: 건설 산업은 수십 년 전에 벽돌 쌓기 작업을 자동화했습니다 (프리패브 패널, 모듈형 건설, CNC 제작 등). 하지만 건설 산업은 여전히 수백만 명의 사람을 고용하고 있습니다. 변한 것은 구성 비율 (Mix)입니다. 프로젝트당 벽돌공의 수는 줄어들었습니다. 대신 건축가, 엔지니어, 프로젝트 매니저, 그리고 검사관의 수는 늘어났습니다. 전체 노동 인력이 사라진 것이 아니라, 기술과 판단력의 측면에서 상향 이동한 것입니다. 소프트웨어 또한 동일한 패턴을 따르고 있습니다: 작업자 (일상적인 코드를 작성하는 주니어 개발자): 이 역할은 실제로 줄어들고 있습니다. AI가 과거에 수많은 주니어들을 고용해야 했던 반복적인 구현 (Implementation) 작업을 처리합니다. 신입 코딩 일자리는 46-67% 감소했습니다 [5]. IBM은 이러한 변화에 대응하여 신입 역할을 없애는 대신, 신입 개발자의 온보딩 (Onboarding) 기간을 세 배로 늘리고 있습니다. 이는 주니어 엔지니어들이 과거에는 실무를 통해 수년에 걸쳐 개발하던 사양 정의, 리뷰, 그리고 아키텍처 판단력을 이제는 갖춘 상태로 투입되어야 한다는 점을 인식했기 때문입니다.

벽돌 쌓기 도제 교육은 사라지고 있지만, 건물을 이해하는 사람들에 대한 필요성은 사라지지 않았습니다. 현장 소장 (실행을 조율하는 Tech Leads): 이 역할은 제거되는 것이 아니라 보강되고 있습니다. AI가 어느 정도의 오케스트레이션 (Orchestration)을 처리할 수는 있지만, 여전히 누군가는 작업을 지시하고, 실수를 잡아내며, AI가 할 수 없는 결정을 내려야 합니다. 숙련된 사용자들은 이 역할을 자신의 워크플로 (Workflow)에 흡수하고 있습니다. 건축가 (System Designers 및 Product Thinkers): 이 역할의 중요성은 커지고 있습니다. 코드가 저렴해질 때, 무엇을 만들고 그것을 어떻게 구조화할지에 대한 결정이 병목 현상 (Bottleneck)이 됩니다. 나쁜 아키텍처 (Architecture)와 AI가 만나면 나쁜 소프트웨어를 더 빠르게 만들어낼 뿐입니다. 검사관 (Security, QA, Compliance): 이 역할의 중요성은 커지고 있습니다.