AI 도구를 켰더니 오히려 느려졌다
AI 코딩 도구를 쓰면 당연히 빨라져야 한다. 그런데 2025년 AI 안전성 연구기관 METR이 수행한 무작위 대조 실험은 정반대의 결과를 내놨다. 숙련된 오픈소스 개발자 16명이 246개의 실제 태스크를 수행하는 실험에서, AI 도구를 자유롭게 쓴 그룹은 쓰지 않은 그룹보다 복잡한 태스크에서 19% 더 느렸다. 실험 전 같은 개발자들이 예측한 수치는 '24% 빨라질 것'이었다. 실험이 끝난 후에도 그들은 자신이 더 빨랐다고 믿었다.
이 연구의 진짜 헤드라인은 'AI가 쓸모없다'가 아니다. 헤드라인은 따로 있다. 병목은 모델 품질이 아니라 컨텍스트 품질이다. 개발자들이 느려진 이유는 AI가 코드를 못 짜서가 아니었다. AI가 아키텍처 제약, 네이밍 컨벤션, 기존 유틸 함수, 팀이 쌓아온 패턴을 전혀 모른 채 코드를 생성했고, 개발자들은 그 결과물을 수정하고 검증하는 데 대부분의 시간을 썼다. 연구자들은 이를 'verification overhead'와 'workflow friction'이라 불렀다. AI는 코드를 짰다. 하지만 존재하지 않는 시스템을 위한 코드를 짰다.
AI는 매 세션마다 백지에서 시작한다
이게 구조적 문제인 이유가 있다. 새 AI 세션을 열 때마다 모델은 아무것도 모른다. 당신 팀이 왜 그 아키텍처를 선택했는지, 어떤 패턴을 표준으로 정했는지, 'service'와 'handler'와 'controller'를 뭐라고 부르는지, 공유 라이브러리에 어떤 유틸 함수가 있는지, PR이 통과되려면 무엇을 지켜야 하는지—이 중 어느 것도 모른다. 그 결과 AI는 매우 빠르고 매우 자신감 넘치는 주니어 개발자처럼 행동한다. 당신 코드베이스를 한 번도 본 적 없고, 훈련 데이터에서 가장 자주 본 패턴을 그대로 재현하는 주니어 개발자.
컨텍스트 엔지니어링: 설계해야 할 운영 레이어
dev.to에 게재된 'Context Engineering for AI Coding' 시리즈는 이 문제를 정면으로 다룬다. 핵심 주장은 단순하다. AI 코딩 도구의 ROI는 모델 선택이 아니라 컨텍스트를 얼마나 잘 구조화해서 전달하느냐에서 결정된다. 저자는 이를 AI의 'DevOps 모멘트'라고 표현한다. 실험적 AI 지원과 신뢰할 수 있는 프로덕션급 AI 협업을 가르는 운영 레이어라는 뜻이다.
실용적인 해법은 세 층위로 나뉜다. 첫 번째는 규칙 파일(Rule Files)이다. AGENTS.md, CLAUDE.md, .cursorrules 같은 파일을 저장소 루트에 두면, AI 에이전트는 모든 태스크를 시작하기 전에 이 파일을 읽는다. 여기에 아키텍처 레이어 규칙, 금지 패턴, 보안 제약을 명시적으로 적는다. "클린 아키텍처를 따르라"는 지시는 모호하다. "biz 레이어는 절대 gorm.DB를 직접 임포트하지 않는다"는 지시는 결정론적이다. 이 차이가 AI가 만들어내는 코드의 품질을 가른다.
두 번째는 세션 관리다. 세션이 길어질수록 컨텍스트 창 안에 실패한 시도, 수정된 오류, 폐기된 계획이 쌓이고, 모델은 핵심 제약보다 최근 잡음을 우선시하기 시작한다. 이른바 '컨텍스트 부패(context rot)' 현상이다. 고성능 팀들은 AI 세션을 스테이트리스 함수처럼 다룬다. 태스크 경계가 곧 세션 경계다. 세션이 길어지면 AI에게 현재 상태를 요약하게 하고, 그 내용을 PLAN.md에 저장한 뒤 새 세션에서 다시 로드한다. 세 번째는 RAG 파이프라인이지만, 이는 팀 규모와 코드베이스 복잡도가 일정 수준을 넘었을 때의 이야기다.
Cursor iOS 앱이 상징하는 것
같은 맥락에서 Cursor의 iOS 앱 베타 출시(2025년 6월 30일)를 읽어야 한다. 클라우드 VM에서 AI 에이전트를 직접 구동해 PC 없이도 스마트폰으로 개발을 이어갈 수 있다는 것이 핵심이다. 음성 입력, 슬래시 명령어, MCP 연동까지 갖췄다. AI 코딩 도구의 접근성은 빠르게 높아지고 있다. 하지만 여기서 냉정하게 짚어야 할 게 있다. 도구의 접근성이 높아진다고 컨텍스트 설계 문제가 자동으로 해결되지는 않는다. 스마트폰에서 더 편하게 AI에게 지시를 내릴 수 있게 됐지만, AI가 여전히 당신 코드베이스의 맥락을 모른다면 검증 오버헤드도 함께 모바일로 이동할 뿐이다.
비개발자 영역으로 확산되는 같은 문제
51년 업력의 건축설계·CM 기업 선엔지니어링이 Claude Code 기반 비코딩 자동화 교육에 나선 사례도 같은 구조적 문제를 다른 각도에서 보여준다. 코딩 경험이 없는 직원들이 AI로 문서 자동화, 법무 검토 에이전트를 직접 만들겠다는 목표다. 이런 사례가 늘어난다는 건 AI 도구의 확산 속도가 개발자 집단을 이미 넘어섰다는 신호다. 그런데 컨텍스트 설계 문제는 여기서 더 심각해진다. 숙련 개발자들도 19% 느려졌다면, 도메인 전문가이지만 AI 출력 검증 경험이 없는 현업 직원들에게 검증 오버헤드는 훨씬 더 가파른 비용이 된다.
팀 리드가 먼저 설계해야 할 것
METR 연구가 주는 진짜 교훈은 이렇다. AI 도구 도입의 ROI는 도구 선택 단계에서 결정되지 않는다. 컨텍스트를 팀의 공유 자산으로 구조화하는 설계 단계에서 결정된다. 내일 당장 팀에 Cursor를 깔기 전에, 먼저 AGENTS.md를 작성하라. 아키텍처 레이어 규칙을 적고, 금지 패턴을 명시하고, PR 기준을 문서화하라. 세션 관리 규칙을 팀 컨벤션으로 만들고, 세션 길이와 태스크 경계를 정의하라. 이 설계 없이 AI 도구를 팀에 배포하면, METR 실험의 결과를 팀 단위로 재현하는 것과 같다. 도구는 빨라졌는데 팀은 느려지는, 그 역설을.
AI 코딩 도구의 다음 병목
Cursor iOS 앱, 비코딩 자동화 확산, 그리고 METR의 실험 결과가 동시에 가리키는 방향은 하나다. AI 코딩 도구의 진입 장벽은 계속 낮아지고 있고, 그만큼 컨텍스트 설계 역량이 팀 경쟁력의 핵심 변수가 되어간다. 모든 팀원이 AI를 쉽게 쓸 수 있는 세상에서, 잘 설계된 컨텍스트 인프라를 가진 팀과 그렇지 않은 팀의 격차는 좁혀지지 않고 오히려 벌어질 것이다. AI 도구가 팀을 느리게 만드는 진짜 이유는 도구 자체가 아니다. 도구에 먹일 컨텍스트를 설계하지 않은 것이다.