AI 시대 개발자에게 필요한 것 — 경험, 훈련, 그리고 함께 바뀌는 조직
글쓴이: NAVER Search Product Dev 전용우 네이버에서 통합 검색 시스템과 검색 서버를 개발하는 전용우입니다. 사용자의 검색 여정이 시작되는 Edge 서버부터 통합검색, 프론트엔드, 검색 서버까지 엔드투엔드로 책임지고 있습니다. 여러 서비스에 확장 가능한 검색 플랫폼을 제공하고, 더 빠르고 정확한 검색 경험을 만들기 위해 끊임없이 개선합니다.
도구는 진화했다
불과 몇 달 전까지만 해도 vibe coding은 기존 개발 경험의 연장선에서 "좀 편해졌네" 정도로 느껴졌습니다. 자동완성이 조금 똑똑해진 것, 검색할 시간을 아껴주는 것. 그 정도였죠. 그런데 제가 쓰는 Claude Code(Opus 4.5 모델) 기준으로, 어느 순간 체감이 확 달라졌습니다. 새로운 아이디어가 떠올랐을 때, 예전이라면 초기 설정부터 기대하는 대로 동작하게 만들기까지 직접 손대야 할 것이 너무 많았습니다. 수정에 수정을 거듭하다 지치기도 하고, 진행하다 포기하는 경우도 적지 않았습니다. 그게 이제는 몇 시간이면 내 아이디어가 어느 정도 동작하는 제품으로 나옵니다. 이 경험을 하면서 — 이건 '정도의 차이'가 아니라 '종류의 차이'라고 느꼈습니다. 단순한 개선이 아니라, 개발 방식 자체의 전환입니다. vibe coding이라는 용어를 만든 Andrej Karpathy도 2026년 2월 초 이렇게 말했습니다.
"1년 전에는 LLM 성능이 낮아서 vibe coding을 재미 삼아, 일회성 프로젝트나 데모 정도에 썼습니다. 거의 되긴 했죠. 오늘날(1년 후), LLM 에이전트를 통한 프로그래밍이 전문가들의 기본 워크플로우가 되어가고 있습니다. 다만 더 많은 감독과 검증을 동반할 뿐입니다." — Andrej Karpathy, 2026.02.04
그는 이 새로운 방식을 agentic engineering이라 부릅니다. "99%의 시간 동안 직접 코드를 작성하지 않고, 에이전트를 조율하며 감독하는 것이 기본"이기 때문입니다. 그러나 에이전트와 함께 일하는 것이 기본이 되었다는 것이, 에이전트에게 모든 것을 맡길 수 있다는 뜻은 아닙니다.
실제로 Anthropic의 2026 Agentic Coding Trends Report(링크)에 따르면, 개발자가 AI에 "완전히 위임" 가능하다고 느끼는 작업은 전체의 0~20%에 불과합니다. 감독 없이는 아직 안 되는 셈이죠. 이 보고서는 Anthropic이 자사 내부 연구 및 고객 사례를 기반으로 작성한 것이지만, 이 수치는 Claude Code만이 아니라 Cursor, Copilot, Windsurf 등 에이전트형 도구 전반의 현실을 반영합니다. 그럼에도 변화의 속도는 빠릅니다. 커뮤니티에서 커스텀 스킬로 여러 에이전트를 동시에 오케스트레이션하던 방식이 불과 며칠 만에 Claude Code의 Agent Teams라는 공식 기능(링크)으로 올라올 정도로, 외부 생태계의 혁신이 제품에 빠르게 반영되고 있습니다. SemiAnalysis의 2026년 2월 분석(링크)에 따르면 이미 GitHub 공개 커밋의 4%가 Claude Code로 작성되고 있으며 연말까지 20% 이상으로 증가할 것으로 전망됩니다.
이 속도를 보여주는 또 하나의 증거가 있습니다. Google DORA 2025 보고서(링크)에 따르면, 불과 1년 전인 2024년에는 AI 도입이 소프트웨어 딜리버리 성과를 오히려 악화시켰는데, 2025년에는 같은 방법론으로 측정한 결과가 정반대로 뒤집혔습니다. 1년 만에, 사람과 도구와 조직이 그 사이에 적응한 것입니다. 이 모든 상황을 보면, 지금은 분명 격변의 시대입니다.
개인의 속도가 곧 제품의 속도는 아니다
변화는 확실히 일어나고 있습니다. Google DORA 2025 보고서(이하 DORA 2025)에 따르면, AI를 많이 활용하는 개발자일수록 개인 효과성(individual effectiveness)이 높고, 코드 품질도 좋으며, 팀과 조직 수준의 성과까지 양의 관계를 보입니다. 이 긍정적 관계는 2024년부터 흔들림 없이 유지되고 있습니다. 더 인상적인 것은 사회 인지적 연구 결과입니다. AI를 많이 쓰는 개발자일수록 진정한 자긍심(authentic pride)이 높아지고, AI와 함께 작성한 코드에 대한 심리적 소유감(psychological ownership)도 유지되며, 인지 욕구(need for cognition) — 즉 깊이 생각하려는 성향 — 에도 변화가 없었습니다. AI가 단순히 일을 대신하는 것이 아니라, 개발자가 가치 있는 일에 더 집중할 수 있게 해주고, 그 결과 스스로의 일에 대한 자부심도 커지는 것입니다.
여기까진 좋습니다. 문제는 그 다음입니다. 이 긍정적 변화가 조직의 일부 영역에는 아직 닿지 못하고 있습니다.
DORA의 2024년과 2025년 데이터를 나란히 놓으면, 이 상황이 선명해집니다.
개인 효과성 (Individual effectiveness)
양(+)
양(+)
[안정적 긍정] 24년에도, 25년에도 AI의 활용은 개인의 효과성을 높이는 것으로 확인됨
배포 처리량 (Software delivery throughput)
음(-)
(AI 도입 25% 증가당 -1.5%)*
양(+)
[적응 성공] 24년에는 AI 활용이 배포 속도를 늦추는 경향이 있었으나, 25년에는 소프트웨어 배포 처리량과 제품 성과 모두 양(+)의 상관 관계로 반전됨
유의미한 업무 시간 (Valuable work)
음(-)
양(+)
[적응 성공] 25년에는 개발자들이 반복적인 업무를 AI에 맡기고 더 가치 있는 일에 시간을 쓸 수 있게 되었음을 시사함
제품 성과 (Product performance)
중립
양(+)
[적응 성공] AI 채택 수준이 높은 사람일수록 더 높은 수준의 제품 성과를 보고하는 경향이 뚜렷하게 나타남
배포 불안정성**(Software delivery instability)
양(+)
(AI 도입 25% 증가당 +7.2%)*
양(+)
[미해결] AI는 속도를 높여주지만, 동시에 배포 실패율이나 복구 시간 같은 불안정성도 함께 높이는 경향이 있음
번아웃 (Burnout)
관계 없음
관계 없음
[미해결] AI가 생산성을 높여줌에도 불구하고, 개인이 느끼는 번아웃은 해결되지 않음
업무 마찰 (Friction)
관계 없음
관계 없음
[미해결] AI가 생산성을 높여줌에도 불구하고, 개인이 느끼는 업무적 마찰은 해결되지 않음
* 2024 DORA Report 원문 수치입니다. ** 이 수치의 증가(+)는 상황의 악화(-)를 의미합니다.
출처: Google DORA 2024 Report, Google DORA 2025 Report
개인 효과성, 배포 처리량, 제품 성과는 분명히 좋아지고 있습니다. 사람과 도구가 적응하고 있다는 신호입니다. 하지만 배포의 불안정성은 여전히 악화되고 있고, 번아웃과 업무 마찰은 꿈쩍도 안 합니다. DORA 2025는 이 "완고한 결과(stubborn results)" 에 대해, AI가 키보드 앞의 개인에게는 효과를 발휘하지만 조직의 시스템과 프로세스에는 아직 닿지 못하기 때문이라고 분석합니다. 빠르게 코드를 생성해도, 그것을 검증하고 배포하고 운영하는 파이프라인이 따라가지 못하면 불안정성은 오히려 커집니다. 마이크로소프트가 2019년에 식별한 개발자 마찰 요인 — 불안정한 시스템, 낡은 문서, 행정 부담 — 은 AI로 해결될 문제가 아니라 조직이 풀어야 할 문제입니다.
솔직히 좀 걱정되는 부분도 있습니다. DORA의 질적 연구에서는 AI로 인한 업무 강도 증가(work intensification)의 징후가 나타나고 있습니다. 한 개발자는 이렇게 말했습니다: "이해관계자들이 더 짧은 기한 안에 더 많은 작업을 기대하고 있다. 데드라인과 프로젝트가 더 빠듯해졌고, 그게 일하는 방식을 바꾸고 있다." AI가 개인의 생산 능력을 높이면, 조직이 그만큼 더 많은 산출물을 기대하게 되어 결국 요구와 자원의 균형이 같아지는 구조입니다. 번아웃이 줄지 않는 이유가 여기에도 있습니다.
다른 연구에서도 비슷한 패턴이 보입니다. Daniotti et al.의 Science 연구(링크, 16만 명, 3,000만 커밋 분석)에 따르면 미국 내 신규 Python 코드의 AI 생성 비율은 2022년 5%에서 2024년 말 29%로 급증했지만, 실제 생산성 증가는 전체 평균 3.6% 에 머물렀으며 효과는 숙련 개발자에게 집중되었습니다. Faros AI 보고서(링크)의 데이터도 같은 이야기를 합니다. AI 도입 팀에서 PR 머지가 98% 늘었지만, 리뷰 시간도 91% 늘었습니다. 개인의 산출량은 올라갔지만 조직 수준의 검증 부담이 함께 올라간 것입니다.
그런데 이 데이터를 곧이곧대로 믿어도 되는 걸까요?
METR의 2025년 RCT 연구(링크)에서는 오픈소스 프로젝트에서 AI 도구를 사용한 숙련 개발자가 실험 결과로는 오히려 19% 느려졌는데, 본인들은 20% 빨라졌다고 느꼈습니다. 체감과 실제 사이에 이 정도의 괴리가 있다는 건 꽤 충격적인 결과입니다. DORA의 대규모 설문과 METR의 통제 실험이 서로 다른 방향을 가리키고 있다는 것은, 우리가 아직 이 변화의 진정한 영향을 충분히 이해하지 못하고 있다는 뜻이기도 합니다. Stack Overflow 2025 설문(링크)에서도 AI 도구나 AI 에이전트가 생산성에 긍정적 영향을 줬다고 답한 개발자는 52%에 머물렀으며, AI 도구 전반에 대한 긍정적 호감도 역시 전년 대비 70%대에서 60%로 하락했습니다. 더 많은 증거 기반 연구가 필요합니다.
그럼에도 한 가지는 분명합니다. "AI는 '승리하는 조직의 강점'과 '고전하는 조직의 약점'을 동시에 증폭시킨다." 개인이 아무리 빨라져도, 조직의 파이프라인과 문화가 함께 변하지 않으면 그 속도는 제품 수준의 성과로 이어지지 않습니다. 이것이 지금 우리가 마주한 진짜 도전입니다.
경험과 훈련, 서로가 서로를 완성하는 시대
AI 시대에 개발자의 역량은 두 가지 축 위에 서 있습니다. 하나는 경험 — 수년간 쌓아온 도메인 지식과 판단력이고, 다른 하나는 훈련 — AI를 효과적으로 활용하는 새로운 스킬입니다. 어느 한쪽만으로는 충분하지 않습니다.
경험 없이는 AI에게 무엇을 시키고, 그 결과를 어떻게 검증할지 판단할 수 없습니다. 앞서 언급한 Daniotti et al.의 Science 연구(링크)에 따르면, 주니어 개발자는 코드의 37% 에서 AI를 활용하는 반면 시니어는 27% 에 그치지만, 생산성 향상은 경험 많은 개발자에게만 나타났습니다. 연구진은 "초보자는 거의 혜택을 받지 못한다"고 밝혔습니다. 이미 쌓아온 경험이 있어야 AI의 결과물을 올바르게 평가하고 활용할 수 있다는 뜻입니다. 여기서 중요한 것은, "판단"의 형태가 고정되어 있지 않다는 점입니다. 과거에는 코드를 한 줄씩 읽으며 판단했다면, 지금은 어떤 스펙을 작성할지, 어떤 시나리오로 검증할지, 어떤 아키텍처 제약을 설정할지를 결정하는 것이 판단의 핵심이 되어가고 있습니다. 경험의 가치가 줄어드는 것이 아니라, 경험이 발휘되는 층위가 올라가고 있는 것입니다.
90%의 개발자가 AI를 사용하고 80% 이상이 생산성이 올랐다고 느끼지만, 30%는 AI가 생성한 코드의 품질을 거의 신뢰하지 않습니다. 이걸 "건강한 회의주의(healthy skepticism)" 라고 부를 수 있는데, Stack Overflow의 답변을 참고하되 무조건 신뢰하지 않는 것과 비슷합니다. 이런 회의주의는 경험에서 나옵니다. 다만 시니어라고 해서 이 감각이 자동으로 유지되는 것은 아닙니다. MIT Technology Review(링크)에 소개된 한 숙련 개발자는 업무에서 AI 도구를 적극 활용하다가, AI 없이 사이드 프로젝트를 시작하자 "본능이었던 것이 수동적이고 번거롭게 느껴졌다"고 고백했습니다. Addy Osmani 역시 시니어 엔지니어의 핵심 프로그래밍 역량이 AI 의존으로 위축될 수 있다고 경고합니다(링크). 솔직히 저도 비슷한 경험이 있어서, 이 경고가 남의 이야기처럼 느껴지지 않습니다. 경험에서 비롯된 건강한 회의주의도, AI를 무비판적으로 사용하면 약해질 수 있습니다.
그러나 경험만으로도 충분하지 않습니다. DORA 2025의 Foreword에 소개된 Booking.com 사례가 이를 잘 보여줍니다. 3,000명 이상의 개발자를 보유한 이 회사는 초기에 AI 도입 효과가 불균등했는데, 원인은 경험 부족이 아니라 훈련 부족이었습니다. 개발자들이 "더 명확한 지시와 효과적인 컨텍스트 제공법"을 배운 후에야 머지 리퀘스트가 30% 증가했습니다. 프롬프트 엔지니어링, 컨텍스트 설계, AI 결과물의 검증 방법 — 이러한 새로운 스킬은 도메인 경험과 별개로 의도적으로 배워야 하는 것입니다. 건강한 회의주의 역시 경험에서 자연스럽게 생겨나기도 하지만, 이 사례에서 보듯 적절한 훈련을 통해서도 길러질 수 있습니다. 중요한 것은 경험이든 훈련이든, 팀 전체가 이 역량을 갖추도록 지원하는 것입니다.
역설적으로, 경험이 풍부한 시니어 개발자에게는 그 경험 자체가 새로운 도구 앞에서 걸림돌이 되기도 합니다. Addy Osmani는 AI 시대에 어려움을 겪는 엔지니어들의 공통점을 지적합니다 — AI를 "더 빠른 타자기"처럼 사용하며, 워크플로우 자체를 적응시키지 못하고, 에이전트의 접근 방식과 싸운다는 것입니다(링크). "이전에는 이렇게 했으니까"라는 관성. 이게 생각보다 강합니다. 오히려 새로운 도구를 편견 없이 받아들이는 신입 세대의 워크플로우에서 배울 점이 있고, 그 관점을 수용하며 함께 개선해야 합니다. 이것이 바로 경험이 훈련을 필요로 하는 지점입니다.
결국 경험과 훈련은 따로 떨어질 수 없습니다. 시니어의 도메인 판단력은 AI 결과물을 평가하는 토대가 되지만, 새로운 도구를 효과적으로 쓰려면 의도적인 훈련이 필요합니다. 주니어의 AI 도구 적응력은 빠르지만, 그것을 의미 있는 결과로 전환하려면 경험에서 오는 판단력이 필요합니다. 이 양방향의 상호보완이 작동할 때 비로소 앞으로 나아갈 수 있습니다.
결국 우리가 해야 할 것 — 시스템의 문제를 시스템으로 푸는 것
DORA의 2024-2025 데이터가 알려주는 방향은 명확합니다. 개인 수준의 적응은 이미 효과를 내고 있습니다. 배포 처리량과 제품 성과가 1년 만에 반전된 것은 개인과 도구가 빠르게 진화한 결과입니다. 하지만 불안정성, 번아웃, 마찰이 꿈쩍도 하지 않는 것은, 그것이 개인이 아니라 조직 시스템의 문제이기 때문입니다. AI는 키보드 앞에 있는 개인에게 도움을 주지만, 프로세스와 문화와 파이프라인은 조직이 함께 바꿔야 합니다.
그리고 이 조직 차원의 문제에는 경험을 쌓을 기회의 보존도 포함됩니다. UC Santa Barbara의 Matt Beane 교수의 연구에 따르면, 31개 이상의 직종에서 지능형 자동화가 전통적인 도제 모델을 변화시켜 초보자가 성장에 필수적인 실무 경험에 참여할 기회를 줄이고 있습니다. 전문가는 AI로 스스로 해결할 수 있으니 그렇게 하고, 주니어는 그 과정에서 배울 기회를 잃습니다. 경험의 가치가 아무리 높아도, 그 경험을 쌓을 파이프라인이 끊기면 조직의 미래가 위태로워집니다. AWS CEO Matt Garman은 주니어 개발자를 AI로 대체하겠다는 발상을 "지금까지 들어본 것 중 가장 멍청한 소리 중 하나"라 일축했습니다(링크). "10년 후 아무것도 배운 사람이 없으면 어떻게 되겠는가"라는 그의 반문은, 주니어 없이는 시니어 파이프라인 자체가 무너진다는 경고입니다. 조직은 주니어가 경험을 쌓을 수 있는 환경을 보존하면서, 모든 구성원이 새로운 역량을 훈련할 수 있도록 지원해야 합니다.
다만 이 변화를 서두르기만 해서는 안 됩니다. DORA 2025는 AI 도입이 "과대 포장과 FOMO에 의해 추동될 수 있다"고 분명히 경고합니다. 모든 조직이 무조건 빠르게 AI를 도입해야 한다는 뜻이 아닙니다. 어디에, 어떻게 적용해야 하는지를 깊이 생각하는 것이 먼저입니다. 빠르게 도입하는 것보다 잘 도입하는 것이, 그리고 한 번 도입한 후에도 지속적으로 관심을 기울이는 것이 중요합니다.
Adidas 사례가 이를 잘 보여줍니다. 약 1,000명의 개발자를 보유한 Adidas는 느슨하게 결합된 아키텍처와 빠른 피드백 루프를 가진 팀에서 20~30%의 생산성 향상과 50%의 이른바 "Happy Time"(직접 코딩에 집중하는 시간) 증가를 경험했습니다. 반면 ERP 시스템과 밀결합된 팀에서는 AI 도입 효과가 거의 없었습니다. 같은 회사, 같은 도구입니다. 조직 구조에 따라 결과가 완전히 달랐습니다.
이 방향을 더 극단적으로 밀어붙인 사례도 있습니다. StrongDM의 AI 팀(링크)은 "코드를 사람이 작성해서도, 리뷰해서도 안 된다"는 원칙 아래 Software Factory(링크)를 구축했습니다. 스펙과 시나리오가 에이전트를 구동하고, 외부 서비스의 행동을 복제한 Digital Twin Universe에서 자동 검증하는 방식으로, 코드 리뷰라는 병목 자체를 시스템으로 대체한 것입니다. 아직 3명 팀의 특수한 도메인에서, 엔지니어당 하루 $1,000이라는 높은 비용을 감수하며 운영되는 실험적 접근이지만, 주목할 점이 있습니다 — 이 접근에서도 무엇을 만들어야 하는지, 어떤 시나리오가 사용자를 만족시키는지, 어떤 edge case를 Digital Twin에 반영해야 하는지를 설계하는 것은 여전히 깊은 도메인 경험을 가진 사람의 몫입니다. 사람의 판단이 사라지는 것이 아니라, 코드 리뷰에서 시스템 설계로 그 판단이 발휘되는 층위가 올라간 것입니다.
우리 팀의 최근 경험도 이와 비슷합니다(링크). 기존에 장애가 발생하면, 흩어져 있는 메트릭과 로그, 그리고 수많은 경험을 통해 내재화된 담당자의 직관으로 대응했습니다. 문제는 그 직관이 특정 사람에게만 있다는 것이었죠. 다른 팀원들도 유사한 수준으로 대응하려면 어떻게 해야 할까 — 이 고민에서 장애 대응 에이전트 개발이 시작됐습니다. LLM을 활용해 분산된 메트릭과 로그를 통합하고, 여러 팀원들의 대응 경험을 하나로 엮는 방식입니다. 처음에는 생각했던 것만큼 잘 동작하지 않았습니다. 하지만 다양한 팀원들의 경험이 하나둘 녹아들고, 여러 도구와 통합하고, 지난 장애 사례를 분석해 지속적으로 업데이트하면서 점점 좋아졌습니다. 이제서야 꽤 쓸 만한 수준이 됐다고 생각합니다.
이것은 정확히 "시스템의 문제를 시스템으로 푸는 것"입니다. 개인의 직관을 에이전트라는 조직 자산으로 전환한 것이고, AI가 키보드 앞을 넘어 파이프라인까지 닿게 만든 것입니다. 하지만 이 에이전트도 한 번 만들어서 끝이 아니었습니다. 새로운 장애 유형이 생기고, 시스템 구조가 바뀌고, 팀원이 사용하면서 피드백을 주는 과정이 반복되어야 비로소 쓸 만한 것이 됩니다. 도입 자체보다 지속적인 개선이 더 중요했습니다.
코드를 생성하는 것 이상으로, 전체 개발 파이프라인을 개선하기 위한 노력도 하고 있습니다. 우리도 기존 시스템들을 하나둘씩 손보기 시작했습니다. 코드 에이전트가 우리 환경에서 더 정확하게 코드를 작성하고 디버깅할 수 있도록, 컴포넌트 문서를 정비하고 오류 메시지를 더 명확하게 다듬는 프로젝트를 진행하고 있습니다. LLM이 잘 활용할 수 있도록 API 구조를 변경하는 작업도 병행하고 있고요. 새로운 환경을 전방위적으로 도입하기 위한 준비를 동시다발적으로 하고 있는 셈입니다. 문서를 어떻게 작성해야 사람과 LLM 모두가 코드를 잘 작성할 수 있을지, 코드 리뷰도 단순히 변경 사항을 확인하는 수준이 아니라, AI가 시니어 개발자처럼 맥락과 설계 의도까지 짚어줄 수 있게 하려면 어떻게 해야 할지. 이런 질문들에 답하려면 현재 도메인과 환경에 대한 깊은 이해가 먼저이고, 거기에 새로운 변화를 감지해서 적용해 나가야 합니다.
이 과정에서 더 나은 방법이 있는데 경험에 익숙해 기존 방식을 고수하고 있던 경우도 많았습니다. 그때 새로운 방법을 검증해보고, 실제로 더 낫다면 빠르게 업데이트하는 것 — 말로는 쉽지만 생각보다 어려운 일입니다. 하지만 이런 일들이 결국 변화에 대응하는 최선이라고 생각합니다. 이건 개인의 노력만으로 되는 일이 아닙니다. AI의 가치는 도구 자체가 아니라 그것이 존재하는 업무 시스템을 재설계하는 것에서 나옵니다. 제품을 만드는 모든 팀원이 함께 변해야 하고, 함께 나아가야 합니다.
도구는 바뀌어도, 좋은 소프트웨어를 만드는 판단력은 변하지 않습니다. 그리고 그 판단을 팀 전체가 공유할 때, 비로소 AI 시대 개발자의 진짜 경쟁력이 됩니다.
Last updated