AI 도구, 정말 생산성을 올리는가: 현실 데이터부터
Cursor나 GitHub Copilot을 쓰면서 ‘이거 쓰면 훨씬 빠르지’라고 느낀다면 — 그 느낌이 틀릴 수 있다.
2025년 상반기 METR이 발표한 무작위대조시험(RCT) 결과는 꽤 충격적이었다. 숙련 오픈소스 개발자 16명이 246개 실제 이슈를 처리하는 실험에서, AI 도구를 사용한 그룹의 완료 시간이 오히려 19% 증가했다. 동시에 같은 개발자들은 본인이 AI 덕분에 20% 빨라졌다고 인식했다. 체감과 실측이 정반대 방향으로 벌어진 것이다. METR 원문에서 구체적인 설계와 결과를 확인할 수 있다.
그렇다고 도구가 쓸모없다는 뜻은 아니다. 2026년 5월 METR의 자기보고 서베이에서는 기술 직군 응답자들이 AI 지원 업무 가치를 미사용 대비 약 2배로 추정했다 — 다만 이건 RCT가 아닌 주관 응답이다. 해당 서베이를 보면, 생산성 체감은 도구 자체보다 어떻게 쓰느냐에 크게 달려 있다는 공통된 패턴이 보인다.
빠른 사람과 느린 사람을 가르는 건 Cursor냐 Copilot이냐의 도구 선택이 아니라, 협업 패턴의 차이다.
시작 전 필수: 컨텍스트 주입과 도구 세팅
어떤 패턴을 쓰든 전제가 되는 것이 하나 있다. AI가 현재 프로젝트의 맥락을 알고 있어야 한다는 것.
Cursor Rules (.cursor/rules/ 디렉토리 또는 프로젝트 루트 .cursorrules 파일)와 GitHub Copilot 지시사항 (.github/copilot-instructions.md)은 프로젝트 스택, 컨벤션, 금지 패턴을 AI에게 미리 알려주는 채널이다. “이 프로젝트는 TypeScript strict mode, ESM only, 절대 any 쓰지 말 것, 테스트는 Vitest” 같은 내용을 여기에 넣어두면 매 대화에서 같은 말을 반복하지 않아도 된다.
대화 시작 시 파일 구조와 핵심 의존성을 첫 메시지에 붙여넣는 것도 유효하다. 간단한 템플릿 형태로:
# 컨텍스트
- 스택: Next.js 15, Prisma, PostgreSQL
- 관련 파일: src/lib/auth.ts, src/app/api/user/route.ts
- 현재 목표: [...]이걸 매 세션 초반에 붙이는 게 귀찮다면 snippets 또는 스크립트로 자동화해도 된다.
세션 분리도 중요하다. 대화가 길어지면 컨텍스트 윈도우 초반 지시사항이 희석되고, AI 응답이 점점 일반적인 방향으로 흐른다. 기능 단위로 새 세션을 시작하는 게 낫다.
비용 측면도 고려해야 한다. Cursor Pro는 월 $20에 $20 크레딧 풀로 운영되며, 2025년 6월부터 고정 요청 방식이 아닌 크레딧 소비 방식으로 전환됐다. GitHub Copilot은 2026년 6월 1일부터 GitHub AI 크레딧 기반 사용량 과금으로 전환되며, 월 $100·포함 사용량 $200의 Max 플랜도 신설된다. Copilot 요금 개편 공식 발표에 따르면, 사용 패턴에 따라 실제 월 비용이 크게 달라지므로 어떤 패턴을 많이 쓰는지 파악하고 플랜을 고르는 게 합리적이다. Cursor 요금제와 Copilot 차이를 더 깊이 비교한 글도 참고할 수 있다.
패턴 1–3: 계획 단계에서 AI를 설계 파트너로
패턴 1 — 스펙→테스트→구현
구현을 먼저 요청하지 말고, 테스트 케이스 목록을 먼저 요청한다.
“이 함수를 구현해줘”가 아니라 “이 함수가 처리해야 할 입력과 예상 출력 목록을 만들어줘. 엣지케이스 포함”으로 시작하면, AI가 구현을 시작하기 전에 동작 범위를 명시적으로 합의하게 된다. 목록에 빠진 케이스가 보이면 그때 수정한다. 그 다음 구현을 요청하면 생성 코드의 품질이 눈에 띄게 달라진다.
특히 입출력이 복잡한 파싱 함수나 상태 머신, 인증 로직처럼 엣지케이스가 많은 영역에서 이 순서가 효과적이다.
패턴 2 — 분할 정복
“이 기능 전체를 구현해줘”는 거의 항상 실망스럽게 끝난다. 기능이 커질수록 AI가 만드는 코드와 실제 필요한 코드 사이 간극이 벌어진다.
대신 “이 기능을 구현하려면 어떤 서브태스크로 나눌 수 있어? 의존 순서도 포함해서”를 먼저 묻는다. AI가 제안한 분해 구조를 검토하고 조정한 뒤, 서브태스크 단위로 하나씩 진행한다. 각 서브태스크가 끝나고 실제로 작동하는 걸 확인한 다음 다음 단계로 넘어가는 것이 핵심이다.
패턴 3 — 선제 함정 찾기
설계가 어느 정도 잡혔을 때, 구현 전에 이렇게 묻는다: “이 설계에서 엣지케이스와 위험 지점은 뭐야? 특히 동시성, 타입 안전성, 롤백 처리 관점에서.”
이 질문 하나로 나중에 재작업이 될 코드를 미리 걸러낼 수 있다. AI는 설계 단계에서 이런 비판자 역할을 잘 해낸다. 실제 구현에 들어가면 이미 정해진 방향을 강화하는 쪽으로 응답이 기울기 때문에, 비판적 시각은 설계 단계에서 끌어내야 한다.
패턴 4–5: 구현 단계의 반복 루프
패턴 4 — 초안→검토→재요청 루프
AI가 처음 생성한 코드를 그대로 붙여넣는 건 절반의 AI 활용이다. 초안을 받은 뒤 의도와 품질을 직접 확인하고, 구체적인 피드백으로 재요청하는 것이 이 패턴의 핵심이다.
피드백의 품질이 결과를 결정한다. “이 코드가 이상해요”는 거의 도움이 안 된다. “이 함수가 O(n²)인데 정렬된 입력을 가정하면 O(n log n)으로 개선 가능해. 이진탐색으로 바꿔줘”처럼 문제를 특정하고 방향을 제시하면 다음 응답이 훨씬 정확해진다. 코드 리뷰어에게 요청하는 것처럼 쓰면 된다.
루프를 3회 이상 반복했는데도 원하는 결과가 안 나온다면, 질문 방식 자체를 재검토하거나 세션을 새로 시작하는 게 낫다. 같은 컨텍스트에서 조금씩 수정하는 것보다 깨끗한 시작이 효율적일 때가 많다.
패턴 5 — 에러 컨텍스트 통째 붙여넣기
디버깅에서 가장 흔한 실수는 에러 메시지만 붙여넣는 것이다. AI 입장에서는 문맥 없이 에러 메시지만 보면 가장 일반적인 해결책을 제시할 수밖에 없다.
효과적인 디버깅 요청 형태는 이렇다:
- 스택 트레이스 전체
- 관련 코드 (에러가 발생한 함수 + 호출하는 쪽)
- 이미 시도한 것과 결과
이 세 가지를 한 번에 제공하면, AI가 맥락을 이해하고 실질적인 원인을 짚어낼 확률이 크게 올라간다. 추가 질문 없이 바로 핵심으로 들어오는 응답을 받게 된다.
패턴 6–7: 리뷰·리팩터 단계에서 AI를 비판자로
패턴 6 — 리팩터 전 의존성 지도
리팩터를 시작하기 전에 범위를 파악해야 한다. “이 함수/모듈을 변경하면 영향받는 파일과 흐름은 어디야?”를 먼저 묻는다.
AI가 전체 코드베이스를 보는 건 아니지만, 제공한 파일들 안에서 의존 관계를 정리해주는 것만으로도 빠뜨리기 쉬운 사이드 이펙트를 미리 볼 수 있다. 리팩터 범위를 정한 뒤 변경하는 것과, 바로 손대기 시작하는 것의 차이는 PR 리뷰 단계에 가서야 드러난다. Cursor Composer로 멀티파일 리팩터를 다루는 방법은 이 패턴과 잘 맞는다.
패턴 7 — 커밋 전 AI 코드 리뷰
변경이 완료된 diff를 AI에 붙여넣고 묻는다: “이 변경에서 놓친 케이스와 보안 이슈는 뭐야? null 처리, 인증 누락, 타입 불일치 위주로.”
직접 챙기지 못한 시각으로 한 번 더 보는 효과가 있다. AI가 생성한 코드를 AI가 리뷰하는 이중 루프는 맹점이 있다 — 같은 모델이 같은 편향을 가지고 있으므로 구조적 문제는 잘 잡히지 않는다. 그래서 이 단계는 체크리스트 형태로 활용하는 게 현실적이다. “보안 이슈가 없다고 판단했어”가 아니라, “이 항목들은 확인됐고, 이 부분은 불확실해”처럼 결과를 해석해야 한다.
패턴을 망가뜨리는 습관과 주의사항
좋은 패턴도 나쁜 습관이 끼어들면 효과가 사라진다.
검증 없이 붙여넣기가 가장 흔하다. 생성 코드를 테스트 없이 커밋하면 버그 원인이 AI 코드인지, 내 코드인지 구분이 안 된다. AI가 속도 저하의 원인이 되는 건 대부분 이 경우다. 생성 코드는 반드시 로컬에서 실행해보고 의도한 동작인지 확인한다.
컨텍스트 없는 질문은 AI도 의도를 알 수 없다. ‘이거 고쳐줘’, ‘왜 안 돼?‘식 요청은 AI가 가장 일반적인 방향으로 응답하도록 유도한다. 배경, 원하는 결과, 제약 조건을 같이 넣어야 한다.
과도한 위임은 덜 눈에 띄지만 실질적인 비용이 크다. 아키텍처 결정이나 데이터 모델 설계를 AI에 통째로 맡기면, 나중에 AI 답변을 이해하고 검증하는 시간이 직접 설계하는 시간을 초과하는 경우가 생긴다. AI는 설계의 선택지와 트레이드오프를 정리하는 데 쓰고, 최종 결정은 직접 내려야 한다.
긴 세션 유지도 흔한 실수다. 수천 토큰이 쌓이면 AI는 초반에 제시한 제약 조건을 망각하고 응답이 흐릿해진다. 기능 단위로 세션을 리셋하는 습관이 필요하다.
마지막으로 도구 과신. Copilot Max나 Cursor Ultra 같은 상위 플랜은 더 많은 사용량을 주지만, 사용 방식이 바뀌지 않으면 결과도 바뀌지 않는다. 특히 Copilot은 2026년 6월부터 과금 구조가 크게 바뀌는 시점이므로, 지금 쓰는 패턴의 크레딧 소비량을 한 번은 점검해볼 필요가 있다.
자주 묻는 질문
Q. METR 실험에서 AI가 오히려 느리게 했다면, 지금 당장 써야 하는 이유가 있나?
METR RCT는 숙련 개발자가 익숙한 오픈소스 코드베이스에서 실제 이슈를 처리하는 조건이었다. 반복적인 보일러플레이트 작성, 새로운 라이브러리 탐색, 테스트 작성처럼 ‘모르는 영역’을 빠르게 채우는 작업에서는 체감 이득이 분명히 있다. RCT 결과가 “AI는 쓸모없다”가 아니라 “익숙한 영역에서 깊이 집중해야 하는 작업은 오히려 방해가 될 수 있다”는 신호로 읽는 게 맞다.
Q. Cursor와 Copilot 중 어느 쪽이 이 워크플로에 더 잘 맞나?
워크플로 패턴 자체는 도구에 독립적이다. 다만 멀티파일 컨텍스트와 대화형 리팩터가 많다면 Cursor Composer가 파일 간 편집에 더 자연스럽고, 에디터 통합이 이미 돼 있고 Copilot에 익숙하다면 굳이 전환할 이유가 없다. 두 도구의 구체적인 차이는 별도로 정리되어 있다.
Q. 세션을 자주 끊으면 컨텍스트가 날아가는 게 문제 아닌가?
그래서 .cursorrules나 copilot-instructions.md 같은 프로젝트 레벨 지시사항 파일이 중요하다. 반복적으로 제공해야 하는 프로젝트 컨벤션은 이 파일에 넣어두면 세션이 바뀌어도 자동으로 적용된다. 나머지 세션 특유의 컨텍스트(현재 작업 목표, 관련 파일)는 첫 메시지 템플릿으로 30초 안에 붙여넣을 수 있도록 스니펫으로 만들어두면 된다.
Q. AI 리뷰로 보안 이슈를 잡을 수 있나?
OWASP Top 10 수준의 패턴성 이슈(SQL injection, XSS, 하드코딩 시크릿 등)는 꽤 잘 잡는다. 하지만 비즈니스 로직과 엮인 인증 우회, 멀티테넌시 격리 누락처럼 도메인 지식이 필요한 이슈는 놓치기 쉽다. AI 리뷰를 보안 체크의 유일한 수단으로 쓰지 말고, 첫 번째 필터로 활용하고 민감한 변경은 별도로 점검해야 한다.