AI 로 더 좋게, 그러나 더 느리게 — Nolan Lawson 이 깬 '생산성 그래프' 의 가정
AI 로 더 좋게, 그러나 더 느리게 — Nolan Lawson 이 깬 ‘생산성 그래프’ 의 가정
2026 년 5 월 25 일, Nolan Lawson 의 짧은 블로그 글이 HN 최상단에 올라 1167 점과 433 코멘트를 모았다. 제목은 직설적이다 — “Using AI to write better code more slowly”. ‘AI 가 코드를 더 빠르게 써 준다’ 는 통념을 정면에서 부정하는 첫 줄로 시작해, ‘내 코드의 품질은 올라갔는데, 내 작업 속도는 올라가지 않았다’ 는 솔직한 자기 보고로 본론을 연다. 왜 이 한 줄이 그 주의 가장 무거운 엔지니어링 글이 됐는가.
도입 — ‘생산성’ 이라는 단일 변수의 함정
AI 코딩 도구의 평가는 지난 2 년 동안 거의 단일 변수로 수렴해 왔다 — 속도. ‘몇 분 만에 만들었는가’, ‘한 시간에 몇 줄을 썼는가’, ‘버그를 몇 초만에 잡았는가’. 도구 회사의 홍보 자료, 사용자의 데모 동영상, 기업 도입 발표의 보도 자료가 모두 같은 변수를 변주한다. 그 단일 변수의 그래프 위에서 도구의 우열이 결정되고, 채택 의사결정이 일어나고, 다음 세대 도구의 디자인 방향이 정해진다.
Nolan Lawson 의 글이 무거운 이유는, 이 단일 변수의 가정 자체에 균열을 낸다는 점이다. 글의 첫 단락은 거의 도발에 가깝다 — “I haven’t necessarily seen my velocity go up” (내 속도가 올라간 것은 아니다). 이 문장은 Lawson 본인 — Microsoft Edge 의 전직 시니어 엔지니어, Pinafore 의 개발자, 웹 표준 커뮤니티의 활발한 기여자 — 의 입에서 나왔다는 점에서 더 무겁다. AI 도구에 회의적인 외부자가 아니라, 여러 AI 도구를 능숙하게 쓰는 시니어 엔지니어가 “내 속도는 올라가지 않았다” 고 보고하는 것이다.
그리고 그 보고에 즉시 따라오는 또 다른 한 줄이 글의 골격이다 — “But I find this style of coding to be a more super-powered version of the kind of programming I was already trying to do” (그런데 이 방식의 코딩은 내가 원래 하려고 했던 종류의 프로그래밍을 더 강력하게 만든 버전이다). 즉, AI 가 속도를 올린 것은 아니지만 ‘더 좋게’ 하는 차원 에서는 분명한 변화가 있다는 진술이다.
본 글이 풀고자 하는 것은 이 두 줄의 진단을 받아안고, Lawson 이 묘사하는 실제 워크플로가 어떤 종류의 ‘좋게 함’ 인지, 그리고 그 좋게 함이 도구 평가의 기준 자체를 어떻게 바꿔야 하는지를 짚는 것이다.
본문 1 — 다중 에이전트 리뷰의 실제 작동
Lawson 의 글이 처음부터 끝까지 구체적인 이유는, 그가 자기 작업 워크플로를 거의 명령 한 줄 단위로 적어 두기 때문이다. 핵심은 한 줄 — “Run a Claude sub-agent, Codex, and Cursor Bugbot to find bugs in this PR ranked by critical/high/medium/low” (Claude 서브 에이전트, Codex, Cursor Bugbot 을 동시에 돌려 이 PR 의 버그를 critical/high/medium/low 로 랭킹해 와라) — 이다.
이 한 줄의 의미를 풀어 보면, 그가 코드를 쓰는 방식은 다음 네 단계의 반복이다.
첫째 단계는 자기가 직접 코드 한 덩이를 쓴다 (사람 ↔ 에이전트 페어 또는 사람 단독 모두 가능). 둘째 단계는 그 덩어리에 대해 세 개의 독립 에이전트 — Claude 서브 에이전트, OpenAI Codex, Cursor 의 Bugbot — 를 동시에 돌려 버그·디자인 문제·테스트 누락을 리포트시킨다. 셋째 단계는 세 리포트의 교집합과 합집합을 자기가 직접 읽고, critical / high 등급의 항목을 다시 에이전트에게 고치게 시킨다. 넷째 단계는 그 고침이 의도한 변화를 일으켰는지 자기가 직접 확인하고, 의도와 다른 부작용이 있으면 처음으로 돌아간다.
이 사이클이 한 번 도는 데 보통 몇십 분에서 몇 시간이 걸린다. 만약 자기가 혼자 코드를 썼다면 몇 분 안에 끝났을 수도 있다. 즉 워크플로 단위 시간으로 보면 — Lawson 의 보고대로 — 속도가 분명히 더 느려진다.
그러나 이 느려짐의 대가가 무엇인지를 보면 평가의 기준이 바뀐다. Lawson 은 글의 중반에서 ‘발견’ 의 부수 효과를 묘사한다. 에이전트 리포트가 자주 짚어내는 것은 그가 방금 쓴 코드의 버그가 아니라, 그 코드가 호출하는 주변 코드의 이미 존재하던 버그 다. 한 PR 의 리뷰가 다섯 개의 무관한 사전 버그를 발견하게 되고, 그 발견이 다섯 개의 “탄젠셜 사이드 퀘스트 (tangential side-quests)” — 새 유닛 테스트 작성, 호출 패턴 리팩토링, 문서화 보강 — 로 이어진다. 한 PR 의 리뷰가 다섯 개의 새 PR 을 만든다.
이 사이드 퀘스트의 시간이 글로벌 속도 측정값을 끌어내린다. 그러나 그 시간의 산출물은 코드베이스 전반의 품질 상승이다. ‘PR 하나를 머지하는 시간’ 으로 측정하면 느려졌지만, ‘3 개월 후의 코드베이스 결함 밀도’ 로 측정하면 분명히 개선됐다. Lawson 이 짚는 것은 이 두 측정값의 분리다.
본문 2 — ‘의도된 느림’ 의 두 종류 트레이드오프
이 워크플로가 단순한 자기 만족이 아니라 일반화 가능한 평가 변화의 신호인 이유는, 그것이 두 가지 분명한 트레이드오프를 명시화하기 때문이다.
첫째 트레이드오프는 ‘토큰 비용 ↔ 코드 품질’ 이다. 세 에이전트를 동시에 돌리는 워크플로는 단일 에이전트만 돌리는 워크플로보다 3 ~ 5 배 많은 토큰을 소비한다. Claude / Codex / Bugbot 각각이 PR 의 전체 컨텍스트를 다시 로드해 다시 추론하기 때문이다. 같은 작업의 토큰 비용이 5 배가 된다는 것은 회사 청구서의 입장에서는 무시할 수 없는 숫자다. Lawson 의 워크플로를 회사 단위로 표준화하면, 이전 글에서 다룬 Microsoft 의 ‘12 개월 AI 예산 몇 달 소진’ 사건의 직접 원인이 된다.
그러나 이 토큰 비용의 대가가 ‘발견된 사전 버그의 수’ 라면 비교의 의미가 달라진다. 한 PR 의 토큰 비용이 $5 늘었지만 5 개의 사전 버그를 발견했다면, 그 발견 한 건당 추가 비용은 $1 이다. 같은 사전 버그를 사내 QA 가 발견하는 단가는 그것보다 한 자릿수 큰 경우가 흔하다. 토큰 비용을 ROI 의 분자가 아니라 분모로 보면, Lawson 의 워크플로는 비싸지 않다.
둘째 트레이드오프는 ‘개발자의 인지 부하 ↔ 코드 검증의 깊이’ 다. 다중 에이전트 리포트를 자기가 직접 읽고 판단하는 작업은 결코 가볍지 않다. Lawson 의 글의 한 단락 — HN 코멘트의 Ashton Antony 가 짚은 부분 — 이 정확히 이 점을 강조한다. “this approach still requires enough domain knowledge to triage what the agents surface” (이 접근은 에이전트가 띄운 항목을 트리아지할 수 있을 만큼의 도메인 지식을 요구한다). 즉 다중 에이전트 리포트는 도메인 지식이 깊은 시니어의 손에서만 가치를 만들고, 주니어가 같은 워크플로를 쓰면 오히려 노이즈에 묻혀 코드 품질이 떨어질 수도 있다.
이 두 번째 트레이드오프의 의미가 무겁다. AI 코딩 도구의 보편적 약속 — “주니어도 시니어처럼 작업할 수 있다” — 이 이 워크플로 위에서는 정반대로 작동한다. 시니어는 더 좋아지고, 주니어는 같은 도구로 더 느려질 수도 있다. 같은 도구가 사람의 기존 역량에 따라 정반대 방향으로 작용한다는 것은, 도구 평가의 기준을 ‘tool intrinsic’ 이 아니라 ‘tool ↔ user fit’ 으로 옮겨 가게 만든다.
또 다른 HN 코멘터 Spencer Karenbauer 가 짚는 한 줄 — 정서 요약 — 이 이 옮겨감의 무게를 정리한다. “enablement and governance need to be occurring simultaneously” (역량 확장과 거버넌스가 동시에 일어나야 한다). 즉 도구를 주는 것만으로는 부족하고, 도구를 잘 쓰는 워크플로의 모범 사례와, 그 워크플로가 코드베이스에 만드는 변화를 통제하는 거버넌스가 같이 깔려야 한다는 진단이다.
본문 3 — 도구 평가 기준의 재정렬
이 두 트레이드오프를 받아들이면, AI 코딩 도구의 평가 기준이 재정렬된다. 이전의 단일 변수 (속도) 에서, 적어도 네 개의 변수가 동시에 측정되는 다변수 평가로 옮겨 간다.
첫째 변수는 여전히 속도 다. 사라지지 않는다. 그러나 단독 변수가 아니다.
둘째 변수는 품질의 시간 미분 이다. 같은 도구를 3 개월 사용한 코드베이스의 결함 밀도가 어떻게 변하는가. 정적 분석의 경고 수, 테스트 커버리지의 흐름, 프로덕션 버그 발생 빈도 등으로 측정된다. Lawson 의 워크플로는 첫째 변수에서 손해를 보고 둘째 변수에서 이득을 본다. 도구의 도입 결정은 이 둘의 합을 본다.
셋째 변수는 토큰 단가당 발견 수 다. 같은 100 만 토큰을 소비할 때 발견되는 사전 버그의 수, 또는 작성되는 유닛 테스트의 수가 얼마인가. 이 변수가 도구의 효율성 (efficiency, 속도가 아닌) 을 측정한다. 토큰 가격이 외부 변동 변수임을 감안하면, 이 변수의 측정값이 같은 도구의 가치를 시점에 따라 다르게 만든다.
넷째 변수는 사용자 역량 분포 위의 효과 곡선 이다. 시니어 / 미드 / 주니어 각각의 코드 품질 변화가 어떻게 분포하는가. Lawson 의 워크플로가 시사하듯, 같은 도구가 시니어에게는 +30 % 의 품질 향상을, 주니어에게는 ‑10 % 의 품질 저하를 가져온다면, 그 도구의 회사 단위 효과는 사용자 구성에 크게 의존한다. 평가 단계에서 이 분포를 측정하지 않는 것은 도구 도입 의사결정의 가장 큰 사각지대다.
네 변수가 같이 측정되면, 도구의 우열은 단순한 순위가 아니라 ‘어떤 종류의 사용 시나리오에서 어떤 종류의 사용자에게 어떤 종류의 가치를 만드는가’ 의 매트릭스로 표현된다. Lawson 의 글이 던지는 가장 큰 함의가 이것이다. 도구 평가의 단순함이 끝나고, 평가의 다층화가 시작된다.
결론 — ‘느림’ 을 의도하는 엔지니어의 새 정체성
Lawson 의 글이 HN 의 1167 점을 모은 진짜 이유는, 이 글이 단지 워크플로 보고가 아니라 엔지니어의 새 정체성 선언 이기 때문이다. ‘AI 가 나를 더 빠르게 만들어야 한다’ 는 외부의 기대를, ‘AI 가 나를 더 좋게 만든다, 더 빠르게 만들지는 않을 수도 있다’ 로 다시 정의하는 선언이다. 433 개의 코멘트 가운데 다수가 자기 경험으로 같은 선언을 변주한 것이 그 정체성 선언이 폭넓게 공명한 증거다.
이 정체성 선언이 산업에 던지는 무게가 두 갈래다. 첫째, 도구 회사의 마케팅 언어가 다층화될 압력 이 생긴다. ‘5 배 빠른 개발’ 이라는 단일 약속은 시니어 엔지니어 사용자층에서는 더 이상 매력적인 메시지가 아니다. ‘같은 시간에 5 배 더 깊은 검토’ 또는 ‘한 PR 의 5 개 사전 버그 자동 발견’ 같은 더 정밀한 메시지가 필요하다. 이미 일부 도구 회사 (Cursor, Cognition) 가 이 방향으로 메시지를 조정하기 시작했다.
둘째, 회사의 엔지니어 평가 지표가 재편될 압력 이 생긴다. ‘PR 처리 속도’ 만으로 엔지니어를 평가하는 회사에서는 Lawson 의 워크플로를 따르는 엔지니어가 처벌받는다. 그 워크플로가 만든 코드베이스 품질의 향상이 엔지니어 한 사람의 평가 지표에 반영되지 않기 때문이다. 평가 지표가 ‘코드베이스 결함 밀도의 시간 미분’ 같은 팀 단위 지표로 보완되지 않으면, 회사는 더 좋은 도구를 쓰는 사람을 더 나쁘게 평가하는 모순에 빠진다.
마지막으로 한 가지 질문을 독자에게 던지면서 닫는다. 우리가 AI 도구를 평가할 때, 우리는 정말 우리의 워크플로가 어느 방향으로 옮겨 가는지 측정하고 있는가. ‘속도’ 라는 단일 변수의 그래프 위에서만 보면, Lawson 의 워크플로는 후퇴다. 그러나 그 그래프 옆에 ‘품질의 시간 미분’ 의 그래프를 두면, 같은 워크플로는 전진이다. 우리는 두 그래프를 같이 그려 본 적이 있는가, 아니면 한 그래프만 그리고 있는가. 그 답이 다음 6 개월의 도구 도입 의사결정의 정확성을 결정한다.
출처: