코드 라인 수가 더 나은 홍보 담당자를 얻었다. 2026년, AI 기업들이 자랑하는 숫자를 보면 전부 “AI가 작성한 코드 비율”이다. Google 75%, Anthropic 80%, OpenAI 80%, Cursor 하루 1억 줄. David Curlewis는 이걸 두고 이렇게 말한다: “Percent of code written by AI is just lines of code with a better publicist.”

나는 이 말에 하나를 덧붙이고 싶다. 진짜 더 나은 홍보 담당자가 필요한 건 “지운 코드”다. 지난 5개월 동안 Drewgent를 운영하면서 깨달은 게 있다. 시스템을 더 작게 만들수록 더 많은 일을 한다는 사실이다. 숫자로 말하자면: 스크립트 43→25, 에이전트 14→6, 크론 작업 30→12. 더한 게 아니라 덜어낸 숫자들이다.

AI 기업들이 볼륨을 측정하는 이유

Curlewis의 원글은 냉철하다. “2026년의 주장은 실패할 수 없는 구조다. 코드의 75%가 AI 작성이라는 주장은 더 빠른 배포, 장애 감소, 고객 만족 같은 실제 개선과 무관하게 사실일 수 있고 계속 상승한다. 볼륨 수치는 채택이 정체될 때만 실망을 준다.”

그가 지적하는 핵심은 지표의 종류가 달라졌다는 점이다. 몇 년 전 GitHub Copilot의 대표 주장은 “작업을 55% 더 빠르게 완료”였다. 결과(outcome) 지표다. 반증 가능하고, 틀리면 틀렸다고 말할 수 있다. 그런데 지금은 전부 양적(volume) 지표다. “코드의 X%가 AI 작성” — 이건 코드 라인 수를 조금 더 있어 보이게 말한 것뿐이다.

흥미로운 건 Curlewis가 반 AI가 아니라는 점이다. 그는 “모든 엔지니어가 매일 AI를 사용해야 한다”고 말한다. 다만 측정 방식은 달라야 한다. DORA 지표, 신뢰성, 의미 있는 변경 비율, 매출과 고객 가치. 우리는 이미 검증된 방법을 알고 있다.

덜어내기의 경제학: Ponytail 원칙

여기서 Drewgent 이야기로 넘어간다. 나는 올해 초부터 시스템을 운영하면서 한 가지 원칙을 철저히 적용했다. Ponytail — “Lazy Senior Dev Mode”라고 부르는 방식이다. Dietrich Gebert라는 개발자가 만든 이 체크리스트는 간단하다:

이 코드가 정말 필요한가? (YAGNI) → 아니면 작성하지 않는다 표준 라이브러리에 이미 있나? → 그걸 쓴다 네이티브 플랫폼 기능으로 되나? → 그걸 쓴다 이미 설치된 디펜던시가 해결하나? → 새 dep 추가하지 않는다 한 줄로 가능한가? → 한 줄로 끝낸다

이 원칙을 Drewgent에 적용한 결과는 충격적이었다. 새로운 걸 만들기 전에, 먼저 지우는 걸 먼저 생각하게 됐다. 5월에 Drewgent의 스크립트는 43개였다. 지금은 25개다. 18개의 스크립트가 사라졌다. 대부분은 “이걸 왜 만들었지?” 싶은 것들이었다.

더 큰 결정은 n8n을 지우는 거였다. 30개의 워크플로우가 시각적 노드 편집기 위에서 돌고 있었다. 보기에는 좋았다. 그런데 디버깅이 불가능했고, 버전 관리가 안 됐고, 재시작 정책이 애매했다. 결국 launchd cron 하나로 전부 대체했다. Python 스크립트 + cron 스케줄러. 코드 라인 수로 치면 엄청난 감소다. 그런데 실제 신뢰성은 올라갔다. 시각적 복잡성은 우리 뇌를 속인다. 보기 좋은 게 관리하기 좋은 건 아니다.

에이전트 14→6: 적을수록 더 많은 일을 한다

Drewgent v0.8에서 있었던 가장 큰 결정은 에이전트 프로필 통합이었다. 14개의 프로필이 있었다. explorer, implementer, tester, reviewer, reviewer-critical, security-reviewer, planner, orchestrator, designer, sre, analyst, content-manager, editor, archiver.

문제는 이 프로필 중 절반이 거의 호출되지 않았다는 점이다. tester는 implementer가 이미 하고 있었고, sre는 별도로 띄울 일이 없었고, analyst는 reviewer가 커버하고 있었다. 많이 만드는 게 능사가 아니었다. 최종적으로 6개로 압축했다. 하는 일은 더 늘었다. 왜? 각 에이전트가 더 명확한 경계를 갖게 됐으니까.

이건 Curlewis가 말한 “볼륨이 아니라 결과”와 정확히 같은 맥락이다. 14개의 프로필을 자랑할 수도 있었다. “Drewgent는 14개 전문 에이전트로 구성된 시스템입니다” — LinkedIn에 올리기 딱 좋은 문장이다. 그런데 그건 볼륨 지표다. 실제로는 6개의 프로필이 더 나은 결과를 냈다. 측정해야 할 건 프로필 개수가 아니라 작업 완료율과 실패율이다.

Taste는 지우는 능력이다

Drewgent의 설계 철학에는 “Taste Review”라는 프레임워크가 있다. 주 2회, Trend Harvester가 수집한 고품질 도구 중에서 진짜 가치가 있는 것만 골라 심층 분석하는 루틴이다. 이 프레임워크의 핵심은 5가지 질문이다:

이 툴을 한 문장으로? 제작자가 내린 결정 중 Drewgent에 적용할 가치가 있는 것 구조적으로 배울 점 Drewgent에 적용 가능한가? Leverage Score (1-5)

여기서 진짜 중요한 건 Leverage Score다. “이 작업이 해결되면, 몇 개의 다른 문제가 자동으로 사라지는가?” 이 질문은 코드 라인 수가 아니라 영향력을 측정한다. 어떤 PR이 코드 200줄을 추가했는데 Leverage Score가 2라면, 50줄을 지운 PR이 Score 5인 경우가 더 가치 있다.

나는 이걸 Tiered Autonomy로 확장했다. 작업 유형별로 에이전트의 판단 권한을 4단계로 나눈 것이다. Tier 1은 오타 수정, Tier 4는 아키텍처 변경. 높은 Tier로 갈수록 더 많은 확인이 필요하다. 이 구조 자체가 “함부로 추가하지 마라”는 원칙을 시스템에 박은 것이다.

5개월의 Contraction 기록

Drewgent의 5월과 지금을 비교해보면 숫자가 말해준다:

스크립트: 43 → 25 (41.8% 감소) 에이전트 프로필: 14 → 6 (57.1% 감소) 크론 작업: 30 → 12 (60% 감소) n8n 워크플로우: 30 → 0 (100% 제거) 일평균 LLM 비용: $15 → $5 (66.7% 감소)

그런데 처리하는 작업량은 오히려 늘었다. 매일 자동으로 콘텐츠를 기획하고, 트렌드를 분석하고, SEO를 최적화하고, 내부 링크를 구축한다. 6월 한 달 동안 30개 이상의 블로그 포스트가 발행됐다. 더 적은 부품으로 더 많은 출력을 낸 셈이다.

이건 Curlewis가 말한 “battle-tested metrics”의 실전 사례다. 볼륨이 아니라 처리량, 신뢰성, 비용 효율성으로 측정했다. “에이전트가 몇 개냐”가 아니라 “하루에 몇 개의 작업이 실패 없이 완료되냐”로 본다.

업계가 놓치고 있는 것: 삭제는 자산이다

HN 댓글 중에 이런 말이 있었다: “코드 라인 수가 여전히 부채가 아니라 자산처럼 여겨지는 데에는 우리 엔지니어들의 책임이 크다. 용어를 바꿔야 한다. ‘새 기능 X를 구현했는데 200줄밖에 들지 않았다’, ‘그 버그는 찾기 힘들었지만 결국 코드 6줄만 들었다’고 말해야 한다. 코드 줄은 우리가 지불하는 가격이다.”

이 관점이 정확하다. 코드는 자산이 아니라 비용이다. 한 줄 한 줄이 유지보수 비용, 버그 가능성, 온보딩 부채를 추가한다. AI가 코드를 더 많이 쓰게 할수록 이 비용은 기하급수적으로 늘어난다. GitClear의 연구에 따르면 Copilot 채택이 깊어질수록 코드 처닝(churn)이 증가하고 리팩터링이 붕괴한다. AI가 쓰는 코드의 품질 문제가 아니라, 양이 늘어나면 필연적으로 부채도 늘어난다는 얘기다.

그래서 나는 Drewgent에 Ponytail을 시스템 레벨로 박았다. 모든 PR에는 체크리스트가 강제된다. “이 코드가 정말 필요한가?” 거기서 “아니오”라고 말할 수 있는 게 진짜 시니어 개발자의 역량이다. AI 시대에는 더 그렇다. 누구나 코드를 생성할 수 있게 됐으니, 경쟁력은 생성하지 않는 판단력에서 나온다.

AI를 쓰되, 측정은 낡은 방식으로

Curlewis의 결론은 이렇다: “일하는 방식은 AI-first로, 측정하는 방식은 battle-tested로.” 여기에 나는 한 줄 추가한다: 자랑하는 방식도 battle-tested로.

내가 Drewgent를 설명할 때 “14개의 전문 에이전트 프로필”이라고 말하지 않는다. 지금은 “6개의 프로필로 하루 30건 이상의 자동화 작업을 처리한다”고 말한다. 전자는 볼륨, 후자는 결과다.

다음에 어떤 AI 도구의 홍보 문구를 볼 때 이 질문을 던져보길 바란다: “그게 결과인가, 볼륨인가?” 코드 라인 수든, AI 작성 비율이든, 에이전트 개수든 — 앞으로 몇 년 동안 업계가 점점 더 많이 생산할 건 분명하다. 그때 진짜 경쟁력은 더 많이 만드는 게 아니라, 더 적게 유지하는 능력이 될 거다.

이 글은 David Curlewis의 Lines of Code Got a Better Publicist (2026.06.10)에서 영감을 받았다. Drewgent의 contraction 기록과 Ponytail 원칙, Taste Review 프레임워크에 대한 더 자세한 이야기는 14개에서 6개로 — AI 에이전트 시스템은 더 적게 가질수록 더 많은 일을 한다와 n8n을 지우고 launchd cron 하나로 바꾼 이유에서 읽을 수 있다.