--- title: "개발자의 90%가 코드를 짜지 않게 된다" description: "Gartner는 2026년 엔지니어의 90%가 직접 코딩 대신 AI 오케스트레이션으로 이동할 것이라 예측했다. 정작 무서운 변화는 시니어 자리가 흔들리는 것이 아니라, 시니어가 만들어지던 학습의 사다리가 부서지고 있다는 점이다." createdAt: 2026-05-18 author: 이든 category: tech jobCategory: dev tags: [AI 엔지니어링, 개발 생산성, 암묵지, 엔지니어링 리더십, 도제 학습] featured: false canonical: "https://blog.careernote.io/article/engineers-stop-writing-code" source: CareerNote Blog language: ko --- Gartner가 작년 말 내놓은 보고서를 보고 한참 멈춰 있었습니다. 2026년이 끝나기 전에 소프트웨어 엔지니어의 90%가 직접 코드를 작성하는 일에서 벗어나 AI 에이전트의 오케스트레이션으로 역할이 이동할 것이라는 전망이었습니다. 처음에는 늘 그렇듯 수사라고 생각했습니다. 그런데 최근 몇 달 사이 팀의 일하는 방식을 다시 들여다보면서, 이 숫자가 결코 과장이 아니라는 사실을 인정하게 됐습니다. (솔직히 저 자신도 IDE보다 에이전트 콘솔을 띄워 두는 시간이 더 길어졌습니다.) 그런데 이쯤에서 더 중요한 질문이 따라옵니다. 개발자가 코드를 짜지 않게 될 때, 정작 사라지는 것은 무엇일까요? ## 코드는 줄어들지만 검토는 폭증한다 Anthropic의 2026 Agentic Coding Trends Report와 Stack Overflow 2025 개발자 설문이 가리키는 풍경은 일관됩니다. 응답자의 84%가 AI 도구를 쓰고 있고, 코드의 41%가 AI에 의해 생성됩니다. 다만 같은 조사에서 도구에 대한 긍정 감정은 70%에서 60%로 떨어졌습니다. 도구는 사방에 깔렸는데 신뢰는 후퇴하는 흐름입니다. 이 모순은 두 가지를 동시에 가리킵니다. 첫째, 한 줄씩 키보드로 코드를 두드리는 일 자체는 더 이상 개발자만의 차별화된 가치가 아닙니다. 도구만 있으면 누구든 비슷한 수준의 결과물을 빠르게 만들어 낼 수 있는 작업으로 평준화되고 있습니다. 보일러플레이트와 테스트 스캐폴드, 문서화 작업에서 가장 큰 생산성 향상이 발생한다는 점은 여러 벤더 데이터에서 공통적으로 확인됩니다. 둘째, 그렇게 만들어진 코드를 받아 적합성을 판단하고 보안·아키텍처·도메인 차원의 책임을 지는 일은 줄어들지 않습니다. 오히려 폭발적으로 늘어납니다. 손이 키보드에서 떼지는 만큼, 눈은 더 많은 차원의 위험을 봐야 합니다. 여기서 한 가지 더 흥미로운 데이터를 짚고 가겠습니다. ## 주니어의 39%, 시니어의 0%라는 역설 2025 Stack Overflow 설문은 신참 개발자가 AI 도구로 약 39%의 생산성 향상을 본다고 보고합니다. 같은 조사에서 시니어, 특히 특정 코드베이스와 도메인에 익숙한 개발자들은 작업 속도가 의미 있게 빨라지지 않았습니다. 비영리 연구기관 METR이 진행한 통제 실험은 한 발 더 나아갑니다. 경험 많은 오픈소스 개발자들이 AI 없이 작업할 때보다 AI를 썼을 때 실제로는 19% 더 느렸는데, 정작 본인들은 20% 더 빨라졌다고 느꼈습니다. 인식과 측정 사이에 39%의 격차가 벌어진 셈입니다. 처음 이 결과를 봤을 때 직관과 충돌해서 한참 곱씹었습니다. 보통의 가설은 둘 중 하나입니다. AI가 모두를 동등하게 빠르게 만들어 주거나, 도구를 영리하게 쓰는 시니어가 가장 큰 이득을 본다. 데이터는 그 어느 쪽도 아니었습니다. AI는 주니어에게 가장 큰 직접 생산성을 주고, 시니어는 실제 속도가 거의 그대로인데도 빨라졌다는 체감만 강해집니다. 여기서 끝나면 "그러니까 주니어가 유리하다"라는 단순한 결론이 나오겠지만, 진짜 문제는 다른 곳에 있습니다. ## 사라지는 것은 사다리다 시니어 개발자는 태어나지 않습니다. 만들어집니다. 학습 경로를 거꾸로 따라가 보면 익숙한 풍경이 보입니다. 누군가가 못생긴 코드를 짜고, 시니어가 PR에 빨간 펜을 들고, 점심 자리에서 같은 실수의 역사가 전수되고, 새벽에 장애를 함께 처리하며 직감이 자랍니다. 마이클 폴라니가 **우리는 말할 수 있는 것 이상을 안다**고 표현한 그 암묵지(tacit knowledge)는 텍스트로 옮겨지지 않고 사람과 사람 사이의 협업 안에서만 전달됩니다. 도널드 쇤은 『성찰적 실천가』에서 전문가의 지식이 책에서 오는 것이 아니라 행위 중 성찰(reflection-in-action)에서 자란다고 적었습니다. 코드를 직접 마주하고, 실패를 만지고, 동료의 피드백을 즉시 반영하는 그 마찰의 순간이 시니어로 가는 사다리의 각 단입니다. 문제는 AI 오케스트레이션 시대에 이 사다리의 중간이 빠르게 사라지고 있다는 점입니다. 보일러플레이트, 단순한 CRUD, 테스트 스캐폴드, 첫 리팩터링 같은 작업들처럼 한때 주니어가 손에 흙을 묻혀 가며 익혔던 단계들이 통째로 에이전트에게 위임됩니다. SAGE 저널에 실린 2026년 연구(Guo & Hu)는 이 현상을 정확히 지목합니다. 생성형 AI는 암묵지를 명시적 지식으로 빠르게 변환해 학습 곡선을 가파르게 만들지만, 그 과정에서 도제 학습이 만들어 오던 사람 사이의 학습 채널 자체가 약해진다는 것입니다. 몇 년 전, 작은 플랫폼 프로젝트에서 프론트엔드 리더 역할을 맡았던 적이 있습니다. Features 기반 구조와 DDD 스타일을 도입하면서 아키텍처 설계, 작업 분배, 코드 리뷰를 주도했는데, 돌이켜 보면 그 일들의 절반은 코드 품질을 지키기 위한 것이 아니라 후배에게 판단의 기준을 전수하기 위한 도구였습니다. 다국어 처리나 페이지네이션 같은 평범한 기능 하나를 PR에 올려놓고, 왜 이 추상화를 선택했는지를 두고 한 시간씩 토론했던 시간이 결과적으로 팀의 시니어를 만들어 냈습니다. 또 한 번은 한 앱의 초기화 로직을 async/await 기반으로 리팩터링해 초기 진입 속도를 40% 정도 끌어올린 일이 있었습니다. (지금 같으면 에이전트가 한나절이면 해낼 일이었을 겁니다.) 그러나 그 변화의 진짜 산출물은 코드가 아니라, 그 과정을 통해 후배가 비동기 흐름의 직감을 얻은 점이었다고 지금도 생각합니다. AI가 같은 결과를 더 빨리 내놨다면, 그 직감을 만들 시간은 어디서 마련했어야 했을까요. 답하기 어려운 질문입니다. ## 코드를 짜지 않는 개발자에게 남는 것 그러면 코드를 짜지 않는 개발자에게 무엇이 남느냐는 것이 진짜 질문입니다. 제 결론은 세 가지로 모입니다. 첫째, **맥락의 설계**. 에이전트에게 무엇을 시킬지 정의하는 능력이 코드를 짜는 능력보다 비싸집니다. 프로덕트 매니지먼트 영역에서도 비슷한 변화가 보고됩니다. 사용자 스토리를 쓰던 자리에 **Goal Vector**, 즉 측정 가능한 목표 벡터를 정의하는 일이 들어옵니다. 개발자에게도 같은 흐름입니다. 도메인을 이해하고, 제약을 명문화하고, 평가 기준을 미리 설계해 두는 일이 키보드에서 보낸 시간을 대체합니다. 평가 파이프라인을 어떻게 설계할지, 어떤 회귀 케이스를 어떤 비중으로 둘지를 정하는 능력이 코드를 짜는 능력보다 먼저 와야 합니다. 둘째, **검증과 아키텍처**. AI가 보일러플레이트는 잘 짜지만 시스템 전체의 무결성을 책임지지는 않습니다. 분산 트랜잭션의 일관성, 마이크로서비스 간 결합도, 보안 표면 등, 마틴 클레프만이 『데이터 중심 애플리케이션 설계』에서 강조한 신뢰성·확장성·유지보수성이라는 세 축은 여전히 사람이 통합적으로 봐야 합니다. AI가 답을 빠르게 내놓을수록 그 답을 검증하는 사람의 부담은 커집니다. 시니어가 코드를 덜 쓰는 만큼, 더 많은 종류의 위험을 동시에 보는 일에 시간을 쓰게 됩니다. 셋째, **의도적 도제의 재설계**. 가장 어려운 일입니다. 자연 발생하던 사다리가 사라진다면 조직이 사다리를 의도적으로 만들어야 합니다. 페어 프로그래밍의 의례화, 코드 리뷰의 학습 도구로의 재정의, 장애 회고에 주니어를 의도적으로 끌어 넣기, AI 산출물을 일부러 망가뜨려서 주니어가 판단의 근육을 키우게 하는 워크숍 같은 장치가 필요합니다. (솔직히 저도 아직 정답은 없습니다. 지금 이 순간에도 팀에서 시도하고 깨지고를 반복하는 중입니다.) 여기에 한 가지 덧붙이면, 시니어가 자신의 암묵지를 명시지로 옮기는 일을 미루지 말아야 한다는 점입니다. AI 시대 이전에는 그 기록이 "언젠가 정리할 위키"였지만, 이제는 에이전트가 참조할 수 있는 평가 셋, 코드 스타일 가이드, 아키텍처 결정 기록(ADR)으로 즉시 변환되어야 합니다. 시니어의 머릿속에만 있던 직감이 명시적 자산으로 바뀌는 만큼, 도제의 부담은 조직의 시스템이 분담하게 됩니다. ## 코드를 짜지 않을 때, 우리는 무엇을 짜고 있어야 하는가 Gartner가 말한 90%라는 숫자가 정확한지는 사실 중요하지 않습니다. 정작 의미 있는 변화는 비율이 아니라 사다리의 구조에 있습니다. 코드를 짜지 않는 개발자가 표준이 되는 흐름은 누구도 막을 수 없을 것입니다. 그러나 시니어가 만들어지던 경로까지 같이 사라지게 둘 것인지는 우리 손에 달려 있습니다. 좋은 엔지니어링은 늘 손과 머리 양쪽에서 자랐습니다. 손이 줄어드는 시대에 머리만 살아남게 두지 않으려면, 시니어가 짊어져야 할 책임은 코드 리뷰가 아니라 학습 채널을 다시 짓는 일일지도 모릅니다. (그리고 시니어 자신도 새로 배우는 자리에 다시 앉아야 합니다. 저 역시 마찬가지입니다.) 코드를 짜지 않을 때, 우리는 무엇을 짜고 있어야 하는가. 저는 이 질문이 앞으로 몇 년 동안 우리 직업을 가장 깊이 흔들 것이라고 생각합니다. --- ## 참고 자료 - Gartner, "Predicts 2026: AI and the Future of Work in Software Engineering", 2025 - Anthropic, "2026 Agentic Coding Trends Report" - Stack Overflow, "2025 Developer Survey", 2025 - METR, "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity", 2025 - Michael Polanyi, *The Tacit Dimension*, 1966 - Donald A. Schön, *The Reflective Practitioner: How Professionals Think in Action*, 1983 - Martin Kleppmann, 『데이터 중심 애플리케이션 설계』, O'Reilly, 2017 - Guo, G., & Hu, J., "Making tacit knowledge explicit: Generative AI's role in enhancing apprenticeship systems", *SAGE Open*, 2026