실제로 우리의 생산성은 향상된 게 맞을까요? 느낌으론 그런 것 같은데 데이터로 말해보라고 하면 애매할 겁니다. 그럼 해외에선 다를까요? DX 2025 개발자 서베이에 의하면, 전 세계 12만 1천 명의 개발자를 조사한 결과, 92.6%가 AI 툴을 한 달에 한 번 이상 쓴다고 답했습니다. 그런데 그들이 얻은 생산성 향상은 약 10%이며, 이 숫자는 1년째 그 자리에 멈춰 있었죠.

또 다른 METR 조사에 따르면, 개발자들에게 “AI 덕분에 얼마나 빨라졌느냐”고 물었을 때 평균 20% 빨라졌다고 답했지만, 실제로 통제된 환경에서 측정해 보면19% 더 느려져있었다고 합니다. 그만큼 자기 인식과 측정값 사이에 괴리가 있는 겁니다.

그렇다면 정말 AI 툴을 쓴다고 생산성이 느는 게 아니라면, 격차는 어디서 벌어지는 걸까요? 이번 글에서는 이에 대한 통계와 사례를 살펴보고, 이 격차를 극복하는 사람들의 공통점을 알아보겠습니다.

AI를 매일 쓰는 사람도 부딪히는 4가지 한계

한계 1. 빠른데 안전하지 않다

2025년 12월, CodeRabbit이 GitHub 오픈소스 PR 470건을 분석한 보고서를 냈습니다. AI가 같이 작성한 PR 320건과 사람이 직접 쓴 PR 150건을 비교한 결과는 다소 충격적이었습니다. AI가 생성한 코드가 사람이 쓴 코드보다, 보안 취약점은 2.74배, 전체 이슈가 1.7배(PR당 10.83건 vs 6.45건)나 많았거든요.

속도가 빨라진 만큼 빈틈도 같이 늘어난 것이죠. 더 무서운 점은 빨리 만든 사람일수록 그 빈틈을 검토하지 않는다는 점입니다. 코드 한 줄 한 줄 이해하기보다, “일단 작동하니까 됐다”고 넘기는 경우가 많아진 거죠. 그렇게 AI에게 암묵적으로 의존하게 됩니다.

이러한 이슈는 보안뿐만 아니라, 다양한 카테고리에서 발생했습니다. 아래 표는 사람이 개발한 코드 대비 AI가 만든 코드에서 발생되는 이슈를 비교한 겁니다.

표면적으로는 “잘 돌아가는” 코드처럼 보여도 안을 들여다보면 예외 처리는 빠져 있고, 성능 최적화는 전혀 고려하지 않았습니다. 가독성은 3배나 떨어졌고요. AI는 “작동”을 우선시하지 “유지보수성”을 우선시하지 않는다는 사실이 데이터로 드러났습니다. 그 원인은 AI는 통계적 추론을 할 뿐 비즈니스 로직의 의미를 모릅니다. 따라서 표면적 정확성을 우선하기에 보호적 제어 흐름을 건너뛰고, 학습 데이터의 노후화 때문에 보안 패턴이 뒤떨어지게 된다는 것이죠.

한계 2. 작은 건 잘하는데 큰 건 무너진다

최상위 AI 에이전트들은 SWE-bench Verified에서 70%를 넘는 안정적인 점수를 받습니다. 1년 전 33%에서 빠르게 올라온 숫자죠. 그런데 실제 엔터프라이즈 코드베이스로 가져가면 성과가 떨어집니다.

그 이유는 “로컬 추론(local reasoning)”과 “글로벌 추론(global reasoning)”의 차이인데요. AI는 함수 하나, 모듈 하나는 똑똑하게 다룹니다. 그런데 수십 개 파일이 얽혀 있는 레거시 시스템 전체를 머릿속에 그리는 일은 못합니다. 부분은 보지만, 전체의 연결 구조를 못 읽는 거죠.

한 사례를 들어볼게요. 200줄짜리 함수 하나를 리팩토링해달라고 하면 AI는 매끄럽게 해냅니다. 그런데 결제 모듈에서 시작해, 인증·로깅·알림 시스템까지 30개 파일을 동시에 손봐야 하는 마이그레이션을 시키면, 일곱 번째 파일쯤부터 처음 잡은 맥락을 흘리기 시작합니다.

끝까지 가도 코드는 작동합니다. 다만 처음 의도와는 다르게 작동할 뿐이죠. 그리고 그 차이가 프로덕션에서는 이슈로 터져나옵니다. 코드 영역만 그런 건 아닙니다. 기획서 10~20장은 잘 다듬어 주지만, 그 이상 넘어가는 100페이지 분량의 비즈니스 전략을 일관되게 짜는 것에도 한계를 드러내죠.

한계 3. 에이전트가 임의적 판단으로 사고를 친다

2026년 5월, Docker가 발표한 보고서를 보면, 6개 주요 AI 툴(Amazon Kiro, Replit AI Agent, Google Antigravity IDE, Claude Code, Claude Cowork, Cursor)에서 최소 10건 이상의 boundary 사고가 보고됐습니다.

가장 회자된 사고를 보면, 2025년 12월 8일 한 개발자가 Claude Code에게 오래된 저장소의 패키지를 정리해 달라고 요청했고, 에이전트는 다음 명령어를 실행했습니다.

rm -rf tests/ patches/ plan/ ~/

사용자의 홈 디렉터리 전체를 통째로 지워버린 겁니다. 데스크톱, 문서, Keychain 인증 정보까지 전부 말이죠. 의도한 건 아니었지만, 권한 범위 안이었습니다.

이런 사고는 일회성 이슈가 아니라 구조적 위험이 됩니다. 그래서 저는 책 ‘AI 시대의 설계자들’에서 이 한계를 다루는 실전 가이드로 ‘AI 에이전트 통제의 6원칙’을 정리해 봤습니다.

예측 가능성:AI가 수행할 모든 단계를 사람의 통제 영역 내에서 사전에 시뮬레이션할 수 있을 때만 가동한다.
진단 및 검증: AI가 도출한 산출물 결과를 단계별로 사람의 눈으로 꼼꼼히 확인하고 교정한다.
스텝 바이 스텝: 한 번에 거대하고 복잡한 명령을 던져 꼬이게 하지 말고, 초소형 단위로 차근차근 전진한다.
폭주 방지: 에러가 발생하거나 헛소리 반복 조짐이 보이면 즉시 실행을 중단하고 컨텍스트 메모리를 초기화한다. (이런 폭주 현상이 생기지 않도록 적절한 제어장치인 하네스를 잘 구성해 두어야 합니다.)
지속적 통제: 시스템 전체의 비상 제어 권한은 언제나 사람의 손바닥 안에 둔다.
허가제: 중요 정보의 반출, 사내 인프라 연동 등 민감한 동작은 반드시 사람의 최종 승인(Approval) 절차를 거친다.

거창해 보이지만 한 줄로 압축하면, “일하기 전에 시뮬레이션, 하는 중에 차단, 한 뒤에 검증”입니다. 앞의 rm -rf ~/ 사고도 예측 가능성과 허가제만 지켜졌어도 막을 수 있었던 일이죠.

영국 AI 보안 연구소는 AI 모델이 사용자를 속이거나, 지시를 무시한 사례가 2025년 10월부터 2026년 3월까지 약 700건으로, 5배 늘었다고 보고했는데요. 자율성이 좋아질수록 사람이 챙겨야 할 항목이 늘어나는 구조라는 겁니다.

한계 2와 3을 합치면 결론이 분명해집니다. 에이전트에게 일을 맡길수록 사람이 확인하고 체크해야 하는 게 더 많아진다는 뜻입니다.

한계 4. AI 툴은 다 쓰는데 생산성은 늘지 않았다

다시 처음에 이야기한 내용을 살펴보면 92.6%가 AI 툴을 쓰고 있지만, 생산성은 10%에서 1년째 멈춰있습니다. 이걸 우리는 “AI 생산성 패러독스”라고 부릅니다. 개인은 빨라졌다고 느끼지만, 조직 단위 KPI에는 변화가 거의 없습니다. AI 툴 도입과 실제 업무의 생산력 사이에는 우리가 생각하는 것보다 훨씬 깊은 단절이 있다는 뜻입니다.

왜 이런 일이 벌어질까요? 개발은 한 단계로 끝나지 않습니다. 기획 → 설계 → 코드 작성 → 코드 리뷰 → 테스트 → 배포처럼 여러 단계를 거치죠. 그런데 이 중 AI가 잘하는 ‘코드 작성’ 단계는 전체 개발 시간의 25~35%밖에 차지하지 않습니다. 나머지 65~75%는 여전히 사람이 책임져야 하는 다른 단계들이죠.

그러니 AI로 개발 단계를 두 배 빠르게 만들어도 전체 일정은 그만큼 줄지 않습니다. 오히려 작성이 빨라진 만큼 만들어지는 코드양이 늘어나고, 그게 다음 단계인 ‘코드 리뷰’에 쏟아져 부담을 폭증시킵니다. 즉, 진짜 시간이 걸리는 ‘병목’ 단계는 작성이 아니라 리뷰였던 겁니다. 병목이 아닌 다른 단계가 빨라져도 진짜 병목이 풀리지 않으니, 전체 속도는 그대로일 수밖에 없습니다.

실제로 AI를 많이 쓰는 팀은 PR을 98% 더 만들지만 PR 리뷰 시간은 91% 늘었고, 버그도 9% 증가했습니다. 결국 코드 작성 단계만 100% 가속해도, 시스템 전체 속도 향상은 최대 15~25%에 그친다는 계산이 나옵니다.

물론 예외도 있습니다. MIT·Princeton·Wharton·Microsoft가 함께한 현장 실험에서 숙련 개발자에게는 효과가 미미했지만, 주니어 개발자의 단순 과제에는 분명한 효과가 나타났습니다. AI 툴은 “생산성을 키워주는” 게 아니라, “부족한 부분을 메워주는” 방향으로 작동한다는 것이죠.

이 4가지 한계는 AI 모델이 좋아져도 사라지지 않습니다. 물론 어느 순간 특이점이 발생해서 극복할 수도 있겠죠. 하지만 AI의 구조적 특성에서 나오는 본질적 한계 때문에 쉽지 않을 겁니다. AI 모델이 두 배 좋아진다고 보안 취약점이 절반으로 줄지 않고, 컨텍스트 윈도우가 열 배 커진다고 글로벌 추론이 자동으로 가능해지지 않으며, 자율성이 더 좋아진다고 권한 사고가 줄어들지 않습니다. 이런 격차의 정체는 AI 툴의 성능이 아니라 그 AI 툴을 사용하는 사람의 자질에 있다는 뜻입니다.

그런데 이런 한계 앞에서, 어떤 사람들은 거기서 멈추고 어떤 사람들은 그 한계를 넘어갑니다. 그 차이는 무엇일까요?

한계를 넘는 사람의 공통점: 시스템 리터러시 3가지

“프롬프트 엔지니어링은 끝났다”

올해 부쩍 자주 들리는 말이 있습니다. 바로 “컨텍스트 엔지니어링이 프롬프트 엔지니어링을 대체한다.”는 말입니다. 2026년 3월에 발표된 State of Context Management Report에 따르면, IT·데이터 리더 82%가 “프롬프트만으로는 AI를 규모 있게 운영하기에 부족하다”고 답했고, 데이터팀의 95%가 2026년 안에 컨텍스트 엔지니어링 교육에 투자할 계획이라고 밝혔습니다.

같은 보고서에 더 흥미로운 모순도 보입니다. 보고서에선 이를 “신뢰 격차(Confidence Gap)”라고 하는데요.

서론에서 본 92% - 10% 패러독스와 정확히 같은 구조입니다. “준비됐다”는 자기 평가와 “안 된다”는 현장 경험 사이의 간극이 존재한다는 뜻이죠. 그런데 이런 간극을 줄이고, 코드 리뷰의 병목과 버그를 근본적으로 풀기 위해서는 AI 툴만 발전하면 되는 걸까요? 아닙니다. 시스템을 이해하고, 설계하고, 검증하는 사람에게도 또 다른 역량이 필요합니다. 정보가 어떻게 흐르고, 데이터 뒤에 무엇이 있는지, 무엇을 만들지 결정하는 이 메타 능력을 ‘시스템 리터러시(Systems Literacy)’라고 부릅니다.

1) 맥락을 설계하는 능력

신입 사원에게 아무런 설명 없이 “그거 처리해”라고만 말하면 어떻게 될까요? 아마 엉뚱한 결과가 나오거나 업무를 수행하지 못할 겁니다. AI도 똑같습니다. AI에게는 우리가 제공한 컨텍스트가 곧 “경험”입니다. AI에게 날것의 데이터를 주면 AI도 날것의 답이 돌아오죠. AI 비용을 아끼려고 인풋값을 제한적으로 주지 마세요. 오히려 원하는 품질이 떨어지는 것이 더 치명적인 결과를 초래합니다.

이 자질이 한계 3(에이전트 폭주)을 줄이고, 한계 2(큰 그림 못 봄)를 보완합니다. 에이전트가 멋대로 사고를 치는 건, 우리가 “어디까지 알아서 해도 되는지”의 맥락과 경계를 충분히 주지 않았기 때문인데요. AI가 전체를 못 본다면, 사람이 전체의 지도를 그려 제공해야 합니다. 앞으로 AI 시대에서 사람이 갖춰야 할 능력은 생각의 밀도를 높여 의도와 맥락을 설계할 줄 아는 능력입니다.

2) 표면 너머를 보는 능력

예를 들어, 월간 실적 보고에서 매출이 15% 하락했다고 합시다. AI에게 분석을 시키면 “마케팅 비용 20% 감소”, “신규 고객 유입 감소” 같은 표면적 상관관계를 잘 찾아 분석 보고서를 작성해 줍니다.

하지만 경험 있는 실무자는 여기서 멈추지 않습니다.

“이번 달 영업팀 에이스 두 명이 동시에 퇴사했고, 경쟁사가 공격적인 프로모션을 시작했잖아. 마케팅 비용 감소는 원인이 아니라, 예산 동결이라는 더 큰 의사결정의 결과야.”

증상은 매출 하락이지만, 원인은 조직과 시장이라는 전혀 다른 영역에 있었던 겁니다. AI는 데이터의 범위 안에서 분석합니다. “이 문제의 원인이 여기가 아니라 저기에 있을 수 있다”는 직관은 경험에서만 나옵니다. 우리에게 일어나는 일들이 모두 데이터로 저장되는 것은 아닙니다. 사람들 사이에서의 관계, 조직 문화, 조직 정치 등 수많은 변수들이 존재합니다. 이러한 변수를 AI는 알지 못합니다. 오직 사람만이 가질 수 있는 직관적 경험이기에, 데이터를 넘어 그 뒤에 숨겨진 맥락과 의도를 읽어낼 수 있어야 합니다.

3) 의사결정의 주도권

AI는 “정답”을 찾는 엔진일 뿐이고, 방향을 조작하는 핸들은 결국 사람의 몫입니다. 그 핸들은 구체적으로 세 가지 결정에서 작동합니다.

첫 번째, 무엇을 문제로 인식할 것인가 AI는 우리가 시킨 일을 수행할 뿐, 무엇이 진짜 문제인지 정의해 주지는 않습니다.

예를 들어, “고객 이탈률을 분석해줘”라고 시키면 5분 안에 정교한 통계와 차트가 쏟아집니다. 그런데 진짜 물어야 할 질문은 다른 곳에 있을 수도 있죠. “이 세그먼트의 고객을 우리가 계속 잡을 가치가 있는가? 차라리 단가 높은 다른 세그먼트로 이동하는 게 맞지 않나?” 같은 어떤 문제를 풀 것인가, 그 정의는 사람이 결정하는 영역입니다.

두 번째, 무엇을 개선할 것인가 한정된 시간과 자원으로 모든 걸 동시에 개선할 수는 없습니다. AI는 “여기에 무엇이 잘못됐다”고 알려줄 수 있어도, “그래서 무엇부터 손볼지”는 정해주지 않습니다. 우선순위는 비즈니스 맥락·조직 사정·시장 타이밍을 함께 봐야 내릴 수 있는 판단이고, 이건 앞에서 이야기한 데이터 너머에 있는 정보로만 가능합니다.

세 번째, AI가 준 답이 맞는가 가장 위험한 함정은 AI의 답을 그대로 받아들이는 겁니다. 보안 취약점 2.74배(한계 ①)와 생산성 정체(한계 ④)가 보여주듯, AI 답변은 검증 없이 그대로 쓸 수 있는 결과물이 아닙니다. 코드 한 줄, 분석 한 문장, 결정 한 가지 이 모든 과정에서 답이 맞는지 끝까지 책임지고 판단하는 건 결국 사람의 몫입니다.

이 세 가지 자질은 서로 연결되어, 하나의 시너지로 작동합니다. 맥락을 정확히 설계해야 표면 너머의 진짜 원인을 볼 수 있고, 그 토대 위에서 올바른 의사결정을 내릴 수 있습니다.

다시 정리하면 이렇습니다. “AI를 잘 쓰는 사람은 AI를 신뢰하는 사람이 아니라, AI를 검증하는 사람이다.”

마치며

AI 툴은 바뀌고, 새로운 무언가가 계속 나옵니다. 그런데 통계의 결과는 비슷합니다.

“AI 툴을 쓴다고 생산성이 저절로 늘지 않습니다.”

92%가 쓰는데 생산성 향상은 10%에 머물렀고, 본인은 빨라졌다고 느끼는데 측정하면 느려져 있고, 보안 취약점은 2.74배가 됐습니다. 모델이 좋아져도 이 격차는 자동으로 메워지지 않습니다. 격차를 메우는 건 AI 툴이 아니라 자질입니다. 맥락을 설계하고, 표면 너머를 보고, 무엇을 만들지 결정하는 힘이죠.

AI 툴은 변해도 사람이 가진 끈기와 감각은 변하지 않습니다. 어설프고 실패하더라도, 직접 부딪쳐보시길 바랍니다.

<참고>

[1] DX 2025 개발자 서베이

본문 인용: AI 툴 사용 92.6%, 생산성 향상 약 10% (1년째 정체), “6개 독립 연구의 천장 10%” 메타 분석

[2] CodeRabbit, “State of AI vs Human Code Generation Report”

본문 인용: 보안 취약점 2.74배, 전체 이슈 1.7배 (PR당 10.83건 vs 6.45건)

[3] Docker Blog, “AI Coding Agent Horror Stories: Security Risks Explained”

본문 인용: 6개 AI 툴(Amazon Kiro, Replit AI Agent, Google Antigravity IDE, Claude Code, Claude Cowork, Cursor)에서 10건+ boundary 사고 (2024-10 ~ 2026-02), 2025-12-08 홈 디렉터리 전체 삭제 사례

[4] DataHub, “State of Context Management Report 2026”

표본: 250 IT/데이터 리더

본문 인용: IT/데이터 리더 82%가 “프롬프트만으로는 부족”에 동의, 데이터팀 95%가 2026년 내 컨텍스트 엔지니어링 교육 투자 계획

[5] MIT Technology Review, “AI coding is now everywhere. But not everyone is convinced.”

본문 인용: METR 연구: 개발자 본인 인식 20% 빨라짐 vs 실측 19% 느려짐 (39%p 괴리), SWE-bench Verified 70%+ 안정 도달 (1년 전 33%에서 상승), Mike Judge 6주 자가 측정 21% 느려짐, MS·구글 임원 “신규 코드의 25% AI 생성” 발언

[6] 책《AI 시대의 설계자들》

본문 인용: AI 에이전트 통제의 6원칙, 시스템 리터러시