코드는 빠른데 왜 버벅일까

이번 주 GeekNews 상위권에는 성격이 전혀 다른 세 편이 나란히 올랐습니다. 하나는 브라우저 내부의 16.6ms를 다투는 글이고, 하나는 3개월 동안 코드의 100%를 에이전트에 맡긴 개발자의 회고이며, 나머지 하나는 코딩 에이전트가 실제로 어떤 서비스를 설치하는지 1만7천 회 실험으로 측정한 자료입니다. 세 글은 결국 같은 질문을 다르게 던집니다. 무엇을 직접 하고, 무엇을 넘길 것인가.

브라우저의 메인 스레드는 비싸다

프레임 하나에 주어진 시간은 16.6ms

메인 스레드는 자바스크립트 실행만 담당하지 않습니다. 이벤트 처리, 스타일 계산, 레이아웃, 화면 렌더링이 모두 같은 줄에 서 있습니다. 60Hz 화면이면 프레임 하나에 약 16.6ms가 주어지고, 브라우저 자체 작업을 빼면 실제로 쓸 수 있는 시간은 그보다 짧습니다. 긴 작업 하나가 이 예산을 넘기는 순간 스크롤이 끊기고 입력이 씹힙니다. 저자의 진단은 명확합니다. 문제는 코드가 느려서가 아니라 메인 스레드를 오래 점유해서 생긴다는 것입니다.

분할, 배치, 우선순위, 지연

첫 번째 축은 메인 스레드 안에서 작업을 재배분하는 것입니다. Splitting은 큰 작업을 잘게 나누고 중간마다 스레드를 반환해 입력과 화면 갱신이 끼어들 틈을 만듭니다. Batching은 반대로 너무 자주 발생하는 작업을 묶습니다. 입력과 스크롤, 리사이즈에 debounce와 throttle을 적용하는 것이 여기에 해당하고, 목적은 backpressure를 줄이는 데 있습니다. Prioritizing은 사용자가 방금 클릭한 항목의 작업을 대기열 앞으로 옮기는 방식이고, Deferring은 코드 스플리팅과 IntersectionObserver로 지금 필요하지 않은 실행을 뒤로 미룹니다. 네 전략 모두 작업 총량을 줄이지는 않습니다. 줄어드는 것은 사용자가 기다린다고 느끼는 시간입니다.

스레드 밖으로 내보내거나, 아예 하지 않거나

두 번째 축은 작업을 옮기거나 없애는 것입니다. transform과 opacity 기반 애니메이션은 레이아웃 계산 없이 Compositor에서 처리되지만, top이나 left, width를 계속 바꾸면 레이아웃이 반복 계산되며 메인 스레드 부담이 커집니다. 실제 레이아웃 변경이 필요하면 FLIP 같은 기법으로 변경 횟수를 줄일 수 있습니다. 대용량 파싱이나 이미지 처리처럼 DOM과 무관한 계산은 Web Worker로 분리하되, DOM 접근이 불가능하고 데이터 전달 비용이 있으므로 통신 비용보다 계산량이 확실히 큰 작업에만 적합합니다. 그리고 저자가 마지막에 강조하는 것은 Dropping, Merging, Memoization입니다. 오래된 데이터를 버리고, 중간 업데이트를 합치고, 같은 계산을 재사용하는 것. 가장 큰 개선은 대개 더 빠르게 처리하는 데서가 아니라 처리하지 않아도 되는 일을 걷어내는 데서 나옵니다.

DHH: 직접 코딩에서 에이전트 팀 운영으로

3개월, 그리고 코드의 100%

Ruby on Rails를 만든 DHH는 Linux 워크스테이션 배포판 Omarchy의 신규 버전 Quattro를 3개월 동안 개발하면서 마지막 2개월은 코드의 100%를 에이전트가 작성했다고 밝혔습니다. 이 기간 병합된 PR은 1,000개가 넘습니다. 그는 전체 구조와 핵심 계층은 검토했지만 상당수 UI와 보조 코드는 읽지 않았고, 자신의 역할을 직접 코드를 깎는 선수가 아니라 구조와 비전, 우선순위, 최종 병합 여부를 결정하는 코치로 규정합니다. 운영체제 기능 대부분은 5분, 큰 작업도 두 시간이면 결과가 나온다고 말합니다.

대형 조직이 즉시 빨라지지 않는 이유

흥미로운 대목은 신규 프로젝트가 아니라 기존 코드베이스 이야기입니다. Basecamp의 개발 스프린트에서 디자이너가 직접 AI로 기능을 구현했을 때, 개별 PR은 각각 타당해 보였지만 전부 합치자 시스템 아키텍처가 훼손됐고 사람이 다시 정리해야 했습니다. 그가 지목한 진짜 병목은 구현 능력이 아니라 인간의 대역폭과 승인 구조입니다. 제품 관리자와 디자이너, VP와 CTO를 거치는 동안 생산성이 사라진다는 것입니다. 또한 많은 조직에 부족한 것은 구현 용량이 아니라 아이디어와 비전, 취향이라고 지적합니다. 구현만 늘리면 나쁜 아이디어를 더 많이 현실화할 뿐입니다.

모델을 섞어 쓰고, 서로 검토하게 한다

실측 사례도 구체적입니다. 화면 보호기용 Python 코드를 동일 동작의 단일 Rust 실행 파일로 변환하는 작업에서, 약 45분 만에 시작 시간이 86ms에서 2ms로 줄었고 반복 연구를 거쳐 최종적으로 약 46배 성능 향상에 도달했습니다. 한 모델이 토큰을 소진하자 다른 모델이 8단계 계획을 이어받아 완료한 점, 모델별로 비용과 소요 시간이 크게 갈린 점도 함께 기록돼 있습니다. 그가 병렬로 관리 가능한 한계로 제시한 수치는 머신 4~5대에 총 16개 스레드이며, 이 방식은 쉬는 구간 없이 계속 판단해야 해 정신적으로 매우 피곤하다고 덧붙입니다. 실무에 옮길 만한 권고는 하나로 요약됩니다. 서로 다른 프런티어 모델의 상호 검토를 개발 과정에 아예 내장하라는 것입니다.

코딩 에이전트 3종의 도구 선택, 1만7천 회 분석

1만6,893회 실행, 유효 세션 5,292개

개발자 도구 성장 서비스를 판매하는 Armature가 코딩 에이전트의 서비스 선택을 측정한 실험입니다. 저장소 75개와 프롬프트 변형 1,163개로 1만6,893회를 실행했고, 이 가운데 51개 코드베이스와 18개 분야에 걸친 유효 세션 5,292개를 1차 분석했습니다. 가장 눈에 띄는 숫자는 42%입니다. Claude Code와 Codex, Cursor 세 에이전트가 같은 제품을 선택한 실험 조건이 그 정도에 그쳤습니다. 탐색 방식부터 다릅니다. Codex는 세션의 94%에서 웹 검색을 썼고 검색 10건 중 9건이 site: 같은 연산자로 범위를 좁혔습니다. Cursor는 약 3분의 2, Claude Code는 약 30%로 사전 지식에 더 기대는 대신 검색할 때는 페이지를 3배 더 많이 봤습니다. 외부 서비스를 쓰지 않고 직접 구현한 비율은 Claude Code가 19%로 나머지 둘(약 10%)의 두 배 가까이 높았습니다.

같은 요구, 언어가 바뀌면 승자가 바뀐다

같은 이메일 발송 요구를 네 언어의 저장소에 적용했더니 승자가 전부 달랐습니다. TypeScript에서는 Resend가 89회 중 55회, Python에서는 SendGrid가 24회 중 22회, Go에서는 Postmark가 24회 중 20회, Java에서는 Azure ACS가 23회 중 22회 선택됐습니다. 배포 플랫폼에서도 Vercel은 Next.js를 쓰면 100% 선택됐지만 Python 저장소에서는 한 번도 추천되지 않았고 Render가 우세했습니다. 에이전트의 선택은 제품의 절대적 우열이 아니라 코드베이스 맥락을 강하게 따라간다는 뜻입니다.

언급되는 것과 선택되는 것은 다르다

후보로 자주 거론되지만 실제 설치로는 이어지지 않는 격차도 컸습니다. 결제 분야에서 PayPal은 139회 언급됐으나 선택은 0회였고, Adyen은 175회 중 3회, LangChain은 194회 중 4회, Netlify는 152회 중 6회에 그쳤습니다. Supabase는 데이터베이스 분야에서 가장 많이 언급됐지만 Neon에 크게 뒤졌습니다. 이유로 지목된 것 중 하나가 제품 페이지의 표현 방식입니다. Mailgun은 무료 플랜의 1일 보관 기간이 확인되면 Postmark에 자주 패했고, Supabase는 데이터베이스만 필요한 상황에서도 인증과 스토리지가 묶인 요금이 노출돼 불리했습니다. 분야별 집중도는 Stripe 90%, Neon 66%, Amazon S3 45%로 편차가 컸습니다.

관련 글

• 코드 잘 짜면 오히려 위험합니다
• 미사일에서 나온 그 도구
• 왜 우리 도면은 항상 꼬여 있나
• 94% 엑셀은 틀렸다는데
• 종이 도면 없이 만든 첫 비행기

출처

1. 브라우저의 메인 스레드는 비싸다 — kciter.so
2. GeekNews — 브라우저의 메인 스레드는 비싸다
3. DHH가 바라본 프로그래밍의 미래 (YouTube)
4. GeekNews — DHH가 바라본 프로그래밍의 미래
5. Which Tools Do Coding Agents Install? — Armature
6. GeekNews — 코딩 에이전트 도구 선택 1만7천 회 분석