두 명의 개발자가 정확히 같은 도구를 씁니다. 한 명은 "코드의 90%를 AI가 쓴다, 인생 최고로 즐겁다"고 하고, 다른 한 명은 "동료가 만든 건 테스트도 안 된 쓰레기, 가스라이팅당하는 기분"이라고 합니다. 둘 다 거짓말이 아니에요. 이 간극이 어디서 갈리는지가 오늘의 핵심이에요.
"90% vs 가스라이팅" — 누가 맞나
주장하는 쪽은 David Crawshaw예요. Tailscale 공동 창업자 출신이고, 지금은 exe.dev라는 에이전트 플랫폼을 만들고 있어요. 그가 1년 넘게 연재하는 실전 기록은 개발자 커뮤니티에서 "가장 솔직한 현장 보고서"로 꼽혀요. 첫 글 HN 919점, 두 번째 615점, 이번 세 번째 223점.
그의 1년 변화는 숫자로 보면 비현실적이에요. AI가 쓰는 코드 비중이 25%에서 90%로. 코딩 시간 배분은 읽기:쓰기가 50:50에서 95:5로. 그리고 충격적으로, IDE를 버리고 50년 된 Vi로 돌아갔어요.
그런데 같은 글을 읽은 HN의 다른 개발자들은 정반대로 반응했어요. 한 명은 동료들이 AI로 찍어내는 코드가 테스트도 안 된 slop이라며 "가스라이팅당하는 기분"이라고 했고요. 더 날카로운 반론은 이거였어요. 코딩 속도는 애초에 병목이 아니었다는 거죠. 진짜 병목은 PR 리뷰, CI/CD, IAM 권한 같은 조직 프로세스인데, AI는 거기엔 손도 못 댄다는 거예요. 한 댓글이 이걸 잔인하게 요약했어요.
"AI가 우리의 5일짜리 프로세스를 4.9일로 줄여줬다."
둘 다 진실이다 — 갈림길은 '도구'가 아니다
여기서 대부분의 글이 "그래서 누가 맞냐"로 빠지는데, 진짜 답은 따로 있어요. Crawshaw 본인이 반론을 인정해요. 에이전트 경험은 개인차가 극심하다고요. 파워 유저는 10배 생산성을 보지만, 대다수는 아직 거기 못 갔다고요.
차이를 만드는 건 모델도, 구독료도 아니에요. 워크플로우를 에이전트 중심으로 통째로 재설계했느냐예요. 도구만 VS Code에서 Claude Code로 바꾸고 예전처럼 일하면, 그게 바로 "5일이 4.9일"이 되는 구간이에요. Crawshaw가 90%에 도달한 건 일하는 방식 자체를 갈아엎었기 때문이에요.
| Copilot 시대 (2021~2024) | 에이전트 시대 (2025~) | |
|---|---|---|
| 주력 도구 | VS Code + Copilot | 터미널 + Claude Code/Codex |
| 개발자 역할 | 코드 작성 + AI 보조 | 코드 리뷰 + 에이전트 디렉팅 |
| AI 기여도 | 타이핑 효율 50%↑ | 코드의 90%를 직접 작성 |
| 시간 배분 | 읽기 50% / 쓰기 50% | 읽기 95% / 쓰기 5% |
| 에디터 | IDE 필수 | Vi/Neovim으로 충분 |
IDE의 퇴장이 이 재설계의 상징이에요. 2021년 Copilot 시대엔 자동완성·인라인 편집 덕에 IDE가 필수였어요. 그런데 에이전트는 터미널과 코드베이스 접근만 있으면 돼요. 내가 타이핑할 일이 거의 없으니, 타이핑을 도와주던 IDE가 통째로 불필요해진 거죠. 그래서 Vi로 충분한 거고요.
한 가지 더. Crawshaw가 강조하는 미묘한 포인트가 있어요. 에이전트 하네스(도구)는 1년간 거의 안 변했고, 모델만 극적으로 좋아졌다는 거예요. 그가 만든 에이전트 Sketch가 6개월 전에 하던 걸 인기 에이전트들이 아직도 못 하기도 한대요. 결론: 도구 비교에 시간 쓰지 말고, 가장 좋은 모델을 쓰세요. 공개 벤치마크는 전부 게임당했으니 무시하라고까지 말해요.
그래서, 오늘 뭘 바꿔야 4.9일 함정을 피하나
"재설계"가 추상적으로 들린다면, Crawshaw의 보고서에서 바로 실행 가능한 4가지를 뽑았어요. 순서대로 적용해보세요.
- 저렴한 모델을 끊고, 프론티어 모델부터 쓰세요
그의 가장 강한 조언이에요. 저렴한 모델을 쓰면 "잘못된 교훈"을 배운대요. 에이전트의 한계가 매달 바뀌는데, 최신 프론티어 모델의 진짜 실력을 알아야 "어디까지 맡길지"를 정확히 판단할 수 있어요. 싼 모델로 실망하고 "역시 안 되네" 하는 게 가장 흔한 실패예요. - 빌트인 샌드박스를 끄고, 세션마다 새 VM을 띄우세요
"cat foo.txt 실행해도 될까요?" 같은 확인 프롬프트가 생산성을 죽여요. 권한 승인을 일일이 누르는 순간 당신은 다시 50:50으로 돌아가요. 세션마다 격리된 VM을 새로 띄우고, 그 안에서 에이전트가 제약 없이 일하게 두세요. 망가져도 VM만 버리면 되니까요. - 코드를 '쓰는' 연습이 아니라 '읽는' 연습을 하세요
시간 배분이 95:5로 바뀌면, 새로운 핵심 역량은 타이핑이 아니라 리뷰예요. 에이전트가 쏟아낸 코드를 빠르고 정확하게 읽어내는 힘. 이게 바로 slop을 머지하는 사람과 90%를 신뢰하는 사람을 가르는 선이에요. 리뷰를 못 하면 "테스트 안 된 쓰레기"가 그대로 들어가요. - 제품을 만든다면, UI보다 API를 먼저 만드세요
Crawshaw의 핵심 철학: "프로그래머에게 최고인 소프트웨어가 결국 모든 사용자에게 최고다." 모든 고객이 에이전트를 갖게 되면, 그 에이전트가 당신 제품을 다루게 돼요. 그때 API와 개발자 경험이 곧 사용자 경험이 됩니다.
이게 실제로 먹히는 장면 — Stripe Sigma 사례
Stripe가 SQL 쿼리 시스템(Sigma)과 내장 LLM 어시스턴트를 냈는데, 정작 API 엔드포인트는 비공개 알파였어요. Crawshaw는 기다리지 않았어요. 에이전트에게 세 문장만 지시해서 Stripe API → 로컬 SQLite → 자체 쿼리 시스템을 직접 만들었죠. 결과적으로 Stripe의 공식 제품보다 자기 문제를 더 잘 풀었어요. "기다릴 필요가 없어진다"는 게 어떤 의미인지 보여주는 장면이에요.
현실 체크 — 안 통하는 경우
이 4가지를 해도 조직의 병목(느린 PR 리뷰, 빡빡한 CI/CD, IAM 승인 지옥)이 그대로면, 개인 생산성이 10배여도 출시 속도는 그대로예요. 에이전트는 '쓰는 단계'를 압축할 뿐, '내보내는 단계'는 못 줄여요. 워크플로우 재설계는 내 에디터뿐 아니라 팀 프로세스까지 봐야 진짜예요.
정리하면 이래요. 90% 진영과 가스라이팅 진영의 차이는 재능도 도구도 아니에요. 일하는 방식을 갈아엎었느냐 아니냐예요. 위 4가지가 그 갈아엎기의 출발점이고요. 안 하면, 당신의 5일은 계속 4.9일일 거예요.
