서론

소프트웨어 엔지니어로서 커리어를 시작할 때의 낙관주의는 매우 특정한 순간에 기반합니다. 바로 문제를 직접 해결했을 때, 즉 당신의 뇌가 고안한 솔루션이 어떤 프로그래밍 언어로 구현되어 작동할 때입니다. 그 짜릿함은 초기 동력이 됩니다. 하지만 당신이 작성한 코드가 작동은 하지만 정작 해야 할 일은 하지 않는 상태로 30시간 동안 검토하게 될 때, 그 낙관주의는 서서히 마모됩니다. 그리고 검토해야 할 대상이 더 이상 당신이 작성한 코드조차 아닐 때 그 낙관주의는 완전히 죽어버립니다.

오늘날 AI는 당신의 마음을 환희로 채워주던 부분을 가져가 버렸고, 당신에게는 끔찍한 부분인 검토와 수정만을 남겨두었습니다.

그럼에도 불구하고, 업계는 우리가 55% 더 빨라졌다고 계속해서 반복하고 있습니다.

배경

모두가 반복하는 수치인 "GitHub Copilot이 당신을 55% 더 빠르게 만든다"는 것은 GitHub과 Accenture가 4,800명의 개발자를 대상으로 JavaScript에서 HTTP 서버를 구현하는 제한된 과제를 수행한 실험에서 나온 것입니다. 출력물의 품질 평가는 없었습니다. 테스트 커버리지(Test coverage)도 없었습니다. 코드가 프로덕션(Production) 환경에서 살아남을 수 있는지에 대한 확인도 없었습니다. 참가자들은 자신들이 시간 측정을 당하고 있다는 사실을 알고 있었습니다. 이것은 실제 데이터이지만, 8자릿수(수천만 달러) 규모의 라이선스 비용을 정당화할 수 있는 데이터는 아닙니다.

한편, 2025년 METR (Model Evaluation & Threat Research)은 숙련된 개발자들을 대상으로 그들의 실제 리포지토리(repositories)에서 실제 작업에 대한 무작위 대조 실험 (randomized controlled trial)을 실시했습니다. 결과는 직관에 반했습니다. AI를 사용하는 개발자들이 AI를 사용하지 않을 때보다 19% 더 오래 걸렸습니다. 하지만 그들은 자신들이 20% 더 빨라졌다고 믿었습니다. METR은 2026년 2월, 더 넓은 표본 집단을 대상으로 한 업데이트를 발표했습니다. 이때 속도 저하는 약 -4%로 감소했으며, 신뢰 구간 (confidence interval)은 -15%에서 +9% 사이였습니다. 솔직하게 말하자면, 그 효과는 모호하지만

1. "거의 맞을 것 같은" 코드의 문제. Stack Overflow Developer Survey 2025에 따르면, 개발자들의 가장 큰 좌절은 맞은 것처럼 보이지만 미세하게 틀린 AI 솔루션을 다루는 것입니다. 거의 절반에 달하는 개발자들이 해당 코드를 디버깅 (debugging)하는 것이 처음부터 직접 작성하는 것보다 더 많은 시간이 걸린다고 답했습니다. 당신이 코드를 직접 작성할 때는 각 변수에 대한 멘탈 모델 (mental model)을 구축합니다. 하지만 생성된 코드를 검토할 때는 외부에서 그 모델을 재구축해야 하며, 이때 발생하는 인지적 비용 (cognitive cost)은 엄청납니다. 커리어 막바지에 당신을 지치게 했던 바로 그 부분, 즉 자신이 작성하지 않은 것을 검토하는 작업이 AI로 인해 배가되었습니다.

2. 속도의 환상은 구조적입니다. METR의 연구에서 참가자들은 사전에 24%의 속도 향상 (speedup)을 예측했고, 사후에는 20%를 보고했으며, 실제 측정 결과는 19%의 속도 저하 (slowdown)로 나타났습니다. 인지와 측정 사이의 격차는 거의 40포인트에 달했습니다. 이는 단순한 일화가 아니라 체계적인 인지 편향 (cognitive bias)입니다. 도구가 즉각적인 피드백 (텍스트가 나타나는 것)을 제공하면, 나중에 이를 수정하는 데 30분을 소비하더라도 뇌는 이를 "진전"으로 기록합니다.

3. 찬양받는 지표들은 잘못된 것을 측정하고 있습니다. "수락된 제안의 88%가 커밋 (commit)에 남는다"는 것이 코드가 좋다는 의미는 아닙니다. 그것은 개발자가 수락했다는 의미일 뿐입니다. 실제 커밋에 대한 종단적 연구 (longitudinal research)에 따르면, AI 헤비 유저들은 4배에서 10배 더 많은 비지속적 코드 (non-durable code)를 생성합니다. 즉, 리팩터링 (refactoring)이 필요하거나 얼마 지나지 않아 삭제되는 코드입니다. 출력 속도 (output velocity)가 인도 속도 (delivery velocity)는 아닙니다.

4. 병목 현상은 작성이 아니라 검토입니다. 코드를 생성하는 것은 결코 비용이 많이 드는 문제가 아니었습니다. 비용이 많이 드는 문제는 항상 그것을 이해하고, 유지 관리하고, 디버깅하는 것이었습니다. AI는 저렴한 단계를 최적화하고, 비싼 단계를 배가시킵니다. 이는 선을 정확히 지켜서 칠해야 하는 사람에게 스프레이 건을 주는 것과 같습니다. 처음에는 더 빨라지지만, 결국 마지막에는 더 느려지게 됩니다.

5. 프롬프트 엔지니어링 (Prompt Engineering)은 혐오와 유용성 사이의 경계선입니다. 거의 모든 "반(anti)-AI" 관점에서 놓치고 있는 미묘한 차이가 여기에 있습니다. 바로 리뷰(Review) 노력을 줄이기 위해서는 경험과 상식(Common sense)이 필요하다는 점입니다. 프롬프트 엔지니어링(Prompt Engineering) — 더 솔직히 말하자면, 무엇을 요청할지, 무엇을 요청하지 않을지, 그리고 어떻게 컨텍스트(Context)를 제한할지를 아는 능력 — 은 AI를 증오하느냐, 아니면 훌륭한 주니어 개발자(Dev junior)처럼 다루느냐의 차이를 만듭니다. 천재적인 수준은 아니지만 괜찮은 주니어 개발자 말입니다. 감독이 필요하고, 때로는 놀라움을 주기도 하지만, 백발이 성성한 누군가가 검토하지 않고서는 절대로 프로덕션(Production)에 배포해서는 안 되는 그런 개발자 말이죠. 그리고 여기에 문제가 있습니다. 기업들은 AI를 마치 시니어(Senior)인 것처럼 취급하고 있다는 점입니다.

결론

이 모든 내용이 Cursor를 쓰레기통에 버리라는 뜻은 아닙니다. 도구가 주는 '느낌'에 기반하여 조직적인 의사결정을 내리는 것을 멈추라는 뜻입니다. 여러분 자신의 시간을 직접 측정해 보십시오. 속임수 없이, AI를 사용할 때와 사용하지 않을 때의 동일한 작업들을 비교해 보십시오. 그러면 양방향 모두에서 놀라운 결과를 보게 될 것입니다.

AI는 우리의 일자리를 빼앗아 간 것이 아닙니다. AI는 업무의 가장 좋은 부분은 가져가고 가장 최악인 부분만 남겨두었으며, 거시적 데이터에서는 나타나지 않는 속도 향상(Speedup)을 약속했습니다. 그 대가로 우리에게는 커피를 마실 수 있는 비동기적 휴식 시간을 주었습니다. 이는 기묘한 트레이드오프(Trade-off)이며, 우리가 이에 대해 솔직하게 이야기하고 있는지조차 확신할 수 없습니다.

당신은 자신의 실제 생산성을 측정해 보았습니까, 아니면 그저 AI의 출력값(Output)을 기다리는 동안 느껴지는 기분이 좋다는 이유로 특정 도구를 옹호하고 있습니까?