코드는 빨리 나오는데, 출시일은 왜 그대로일까요?
AI 코딩 도구를 붙이면 첫 코드가 나오는 시간은 눈에 띄게 줄어듭니다. 그런데 리뷰 대기열이 길어지고 테스트 실패와 재작업이 늘면, 고객에게 전달되는 날짜는 거의 달라지지 않을 수 있어요.
그래서 Cursor 사례에서 봐야 할 숫자는 생성된 코드량만이 아닙니다. 요구사항을 정리하고, 구현 단위를 나누고, 리뷰와 테스트 결과를 다시 반영하는 한 바퀴의 시간이 얼마나 짧아졌는지가 더 중요합니다.
a16z는 AI 코딩 시장에서 가장 똑똑한 팀이나 가장 많은 컴퓨팅보다 빠르게 반복하는 팀에 베팅한다고 설명합니다. 다만 이는 Cursor 투자자의 시장 해석이지, 반복 속도가 승리를 보장한다는 비교 실험 결과는 아닙니다.
NAB의 3주는 상세한 요구사항에서 시작됐어요
호주 NAB의 하드웨어 비종속 결제 앱은 수작업으로 약 4개월이 걸릴 것으로 산정됐지만, 수석 엔지니어 한 명이 Cursor를 이용해 3주 미만에 구축했습니다. 담당자는 개발 속도가 5~8배 개선됐다고 평가했어요.
여기서 4개월은 실제 대조 프로젝트의 완료기간이 아니라 사전 추정치입니다. 출시 후 장애나 유지보수 결과도 공개되지 않았으므로, “Cursor를 쓰면 모든 프로젝트가 5배 빨라진다”고 일반화할 수는 없어요.
대신 작업 방식은 참고할 만합니다. Kotlin 경험이 없던 팀은 곧바로 코드를 생성하지 않았습니다. 먼저 상세한 제품 요구사항과 다단계 구현 계획을 만들고, 병렬화할 수 있는 작업을 하위 에이전트에 나눈 뒤 구현에 들어갔어요. 빠른 실행보다 먼저 에이전트가 되돌아올 기준을 만든 것입니다.
같은 고객 사례의 BizCalc 마이그레이션에서도 전체 6개월 계획 중 첫 2개월로 잡았던 레거시 문서화, 제품 요구사항, 사용자 스토리, API 명세 작성을 한 명이 일주일에 마쳤습니다. 다만 전체 마이그레이션이 실제로 2개월 안에 끝났다는 뜻은 아니며, 그 기간은 당시의 예상치였습니다.
코드가 3배 늘자 병목은 리뷰와 테스트로 이동했어요
NVIDIA는 3만 명이 넘는 개발자가 매일 Cursor를 사용하며, 사용 개발자의 커밋 코드량이 도입 전보다 3배가 된 동안 버그율은 유지됐다고 보고했습니다. 측정 기간과 버그율 정의, 대조군은 공개되지 않았기 때문에 이 역시 공급사가 소개한 고객 사례의 범위에서 읽어야 합니다.
더 실용적인 발견은 그다음에 있습니다. 코드 생산량이 늘자 리뷰, 테스트, 디버깅이 새 병목이 됐고 NVIDIA는 규칙과 MCP, 에이전트 적용 범위를 그 흐름까지 넓혔어요. 구현만 빨라지면 다음 단계의 대기열이 커진다는 뜻입니다.
반복 속도는 타이핑 속도가 아닙니다.
요구사항 확정부터 구현, 리뷰 승인, 테스트 통과, 배포까지 한 바퀴를 재세요. 구현시간이 줄었어도 리뷰 대기나 재작업이 늘었다면 팀의 순환은 아직 빨라지지 않은 것입니다.
다음 작은 기능 하나로 순환시간을 확인하세요
새 도구의 효과를 확인하려면 최근 완료한 같은 유형의 작업 3건 이상과 다음 시험 작업 1건을 준비하세요. 티켓과 저장소 기록에서 요구사항 확정일, 리뷰 시작일, 테스트 통과일, 배포일을 찾고 결함·재작업·롤백·리뷰 반려율 중 하나를 품질 기준으로 고릅니다.
- 비교할 작업의 범위를 맞춥니다.
예를 들어 최근 결제 화면의 소규모 기능 변경 3~5건을 기준선으로 고르세요. 신규 기능과 문구 수정처럼 난이도가 크게 다른 작업은 한 묶음으로 비교하지 않습니다. - 코딩 전후가 아니라 전체 단계를 기록합니다.
‘요구사항 확정 → 구현 완료 → 리뷰 승인 → 테스트 통과 → 배포’의 시각을 적고, 각 단계의 작업시간과 기다린 시간을 분리하세요. - 인수 조건부터 문서화합니다.
기존 테스트 전체 통과, 신규 결함 0건처럼 완료 조건을 먼저 고정한 뒤 작업을 병렬화 가능한 단위로 나눕니다. 보안과 권한 위험이 낮은 단위만 에이전트에 맡기세요. NAB도 상세 요구사항과 구현 계획을 먼저 만들었습니다. - 기존 리뷰와 테스트를 그대로 통과시킵니다.
AI가 만든 변경이라는 이유로 검증 기준을 낮추지 마세요. 구현시간 감소가 리뷰 반려, 테스트 실패, 재작업 증가로 이동했는지 확인합니다. - 순환시간과 품질이 함께 좋아진 유형만 확장합니다.
모델 비용도 작업별 실제 사용량으로 따로 기록하세요. CursorBench 3.2에서 Composer 2.5는 56.1%, 작업당 평균 0.44달러로 Opus 4.8 Medium의 같은 점수와 2.81달러보다 낮았지만, 이는 Cursor가 만든 벤치마크의 과제 평균이지 팀의 실제 프로젝트 비용은 아닙니다.
시험 작업: ______
기준선의 전체 순환시간: ______
시험 작업의 전체 순환시간: ______
결함·재작업·리뷰 반려 변화: ______
다음 반복에서 줄일 대기 구간: ______
성공 기준은 단순합니다. 같은 범위와 완료 조건에서 전체 순환시간이 줄고, 결함과 재작업, 리뷰 대기시간은 늘지 않아야 합니다. 과거 기록이 없다면 개선율을 추정하지 말고 이번 작업부터 기준선을 남기면 됩니다.
도구의 속도와 공급 안정성은 따로 보세요
Cursor는 2026년 8월 14일 SpaceX 인수가 완료됐다고 발표했고, a16z는 거래 규모를 600억 달러의 주식 거래로 설명했습니다. 이는 특정 환율 기준이 없는 ‘약 60조 원’과 같은 금액이 아니므로 달러 금액 그대로 보는 편이 정확합니다.
인수는 모델 선택에도 변수가 됐습니다. OpenAI는 2026년 8월 28일 SpaceX에 Cursor 모델 공급 계약을 종료할 의사를 알렸으며, 제안된 중단일은 11월 12일입니다. 실제 종료 범위와 대체 방식은 아직 확정적으로 확인되지 않았어요.
따라서 도입 계획에는 특정 모델 이름만 적지 않는 편이 좋습니다. 필요한 품질 수준, 허용 비용, 대체 가능한 모델, 공급 중단 시 전환 책임자를 함께 정해두세요. 빠른 반복은 도구가 바뀌어도 팀의 피드백 순환이 유지될 때 비로소 조직의 능력이 됩니다.
