에이전트를 매일 쓰는 개발자가 1년 만에 14% 에서 37% 로 늘었고 Microsoft 에서는 CLI 에이전트를 쓴 엔지니어가 PR 을 24% 더 머지했습니다. 2026년에 나온 조사와 Karpathy·DORA·Thoughtworks 의 진단으로 "개발한다"는 말이 무엇으로 바뀌었는지 정리했습니다.
2026년의 개발 화면
요즘 개발자 화면을 보면 에디터보다 터미널이 더 자주 떠 있습니다. 거기서 Claude Code 나 Codex 같은 에이전트가 파일을 읽고 명령을 실행하고 테스트를 돌립니다. 사람은 그 옆에서 무엇을 만들지 설명하고 결과 diff 를 읽습니다. 이 장면이 낯설지 않다면 이미 AI 네이티브 개발 안에 있는 겁니다.
그럼 "AI 네이티브"는 정확히 뭘 가리키는 말일까요? 에이전트가 실행 주체이고 사람이 방향·검증을 맡는 개발 방식을 뜻합니다. 자동완성을 붙인 개발과는 다릅니다. 예를 들어볼까요? 예전에는 로그인 버그를 고치려고 파일을 열고 코드를 읽고 고치고 테스트했습니다. 지금은 "세션 만료 후 로그인이 실패한다, src/auth/ 를 보고 재현 테스트부터 써라"라고 말하면 에이전트가 그 네 단계를 혼자 돌고 결과를 가져옵니다.
2025년과 2026년의 숫자
저도 처음엔 "다들 쓴다더라"는 분위기가 실제 수치와 얼마나 맞는지 궁금했습니다. 2026년에 나온 조사 몇 개를 나란히 놓으면 이렇습니다.
Stack Overflow 가 2026년 4월 말에 개발자 1,100명에게 물었더니 에이전트를 매일 쓴다는 응답이 37% 였습니다. 2025년 연례 조사에서는 14% 였습니다. 어떤 빈도로든 쓴다는 응답은 31% 에서 59% 로 늘었습니다. 반대로 "자율적이지 않은 AI 보조 도구만 쓴다"는 응답은 37% 에서 16% 로 줄었습니다. 자동완성에서 에이전트로 무게가 옮겨 갔다는 뜻입니다.
Microsoft 안의 데이터도 있습니다. 2026년 1월 5일부터 4월 29일까지 수만 명 엔지니어에게 Claude Code 와 GitHub Copilot CLI 를 배포한 결과를 arXiv 논문(2607.01418)으로 냈는데 초기 도입자가 하루에 머지한 PR 이 24.0% 늘었고 네 달 동안 그 효과가 줄지 않았습니다. 재미있는 대목은 도입 경로입니다. 같은 직급의 동료가 이미 쓰고 있으면 써 볼 확률이 216% 높았습니다. 공식 공지보다 옆자리가 강했습니다.
"AI 를 쓰면 느려진다"는 연구는 어떻게 됐나
2025년 7월에 METR 이 "숙련 개발자가 AI 를 쓰면 19% 느려진다"는 무작위 대조 실험을 내서 화제가 됐습니다. 그 후속은 어떻게 됐을까요?
METR 은 2026년 2월 24일에 실험 설계를 바꾼다고 발표했습니다. 2025년 하반기에 개발자 57명·저장소 143개·작업 800건 이상으로 다시 재 보니 기존 참가자는 18% 속도 향상, 신규 참가자는 4% 향상으로 방향이 바뀌었습니다. 다만 신뢰구간이 0 을 걸쳐서 단정하지는 못했습니다. 더 큰 문제는 측정 자체였습니다. 개발자들이 AI 없이 일하는 대조군에 들어가기를 거부했고 30~50% 는 "AI 로 하고 싶은 작업"을 실험에 내지 않았습니다. 에이전트가 다른 일을 동시에 처리하니 작업 시간을 재는 방법도 흔들렸습니다.
결론은 "빨라졌다"보다 "기존 방식으로는 더 이상 측정이 안 된다" 에 가깝습니다. 그만큼 일하는 방식 자체가 바뀌었다는 방증입니다.
Karpathy 가 말한 12월의 변곡점
왜 하필 2025년 말부터 이렇게 됐을까요? Andrej Karpathy 는 2026년 4월 30일 Sequoia AI Ascent 대담에서 2025년 12월을 변곡점으로 꼽았습니다. 그 무렵부터 에이전트가 내놓는 코드 덩어리가 손볼 곳 없이 그냥 맞았고 "마지막으로 고쳐 준 게 언제인지 기억이 안 난다"고 했습니다.
그는 두 단어를 나눠 씁니다. 바이브 코딩은 비전문가도 소프트웨어를 만들게 해 주는 방식이라 바닥을 올립니다. 에이전틱 엔지니어링은 전문가가 여러 에이전트를 조율해 보안·품질·설계 취향을 지키며 제품을 만드는 방식이라 천장을 올립니다. 이 시리즈가 다루는 쪽은 후자입니다.
같은 대담에서 나온 한 문장이 이 시리즈 전체를 관통합니다. "전통 소프트웨어는 명세할 수 있는 것을 자동화하고 LLM 은 검증할 수 있는 것을 자동화한다." 그래서 AI 네이티브 개발의 핵심 역량은 코드를 치는 손이 아니라 명세를 쓰는 능력과 검증을 설계하는 능력으로 옮겨 갑니다.
DORA 가 말하는 J 커브
조직 단위로 보면 어떨까요? Google 의 DORA 팀이 2026년 4월 22일에 낸 "ROI of AI-assisted Software Development" 보고서는 도입 직후 생산성이 떨어졌다가 올라오는 J 커브를 전제로 깔았습니다. 떨어지는 이유로 학습 곡선, AI 코드를 검토하는 검증 비용, 늘어난 코드량을 받아 낼 테스트·승인 절차 조정을 꼽았습니다. 보고서는 이 구간을 "전환의 수업료"라고 불렀습니다.
Thoughtworks 도 2026년 4월 15일 Technology Radar 34권에서 비슷한 경고를 했습니다. AI 가 코드를 대량으로 만들수록 사람이 시스템을 이해하지 못하는 인지 부채가 쌓인다는 겁니다. 그래서 오히려 제로 트러스트, DORA 지표, 테스트 가능성 같은 기본기로 돌아가야 한다고 적었습니다.
이 시리즈에서 다룰 것
정리하면 2026년의 개발은 에이전트가 실행하고 사람이 명세·검증·통제를 맡는 구조로 바뀌었습니다. 그 구조를 운영하려면 알아야 할 것이 몇 가지 있습니다. 조사하면서 반복해서 등장한 주제를 순서대로 묶었습니다.
| 주제 | 한 줄 요약 |
|---|---|
| 개발 루프 | 탐색→계획→구현→검증 루프와 하네스 |
| AI-DLC | AWS 가 제안한 AI 주도 개발 수명 주기, 애자일과의 차이 |
| 스펙 주도 개발 | Spec Kit·Kiro 가 왜 문서부터 쓰게 하는가 |
| 컨텍스트 엔지니어링 | CLAUDE.md·AGENTS.md 와 컨텍스트 창 관리 |
| MCP | 에이전트가 외부 도구와 연결되는 표준 |
| 스킬·서브에이전트·훅 | 에이전트를 확장하는 세 가지 장치 |
| 검증과 리뷰 | AI PR 이 만든 리뷰 병목과 자동 리뷰 |
| 보안 | 프롬프트 인젝션·권한 경계·OWASP 에이전트 Top 10 |
| sLLM 자체 구축 | 폐쇄망·소버린 AI 와 코딩용 오픈 웨이트 모델 |
| 조직과 역량 | DORA 7대 역량과 개발자가 배워야 할 것 |
다음 글에서는 에이전트가 실제로 어떤 루프로 일하는지에 대해서 알아보겠습니다. 그 루프를 알면 나머지 도구들이 어디에 끼워지는지 알게 됩니다.
참고 자료
- Agents on a leash: Agentic AI remains mostly single-agent and monitored at work — Stack Overflow (2026-05-27) — 에이전트 사용 빈도 도표 출처
- We are Changing our Developer Productivity Experiment Design — METR (2026-02-24) — 후속 연구 도표 출처(CC-BY)
- Adoption and Impact of Command-Line AI Coding Agents: Microsoft's Early 2026 Rollout — arXiv 2607.01418
- Sequoia Ascent 2026 summary — Andrej Karpathy
- ROI of AI-assisted Software Development — DORA (2026-04-22)
- Thoughtworks Technology Radar Vol.34 — 인지 부채 경고 (2026-04-15)
