자율 주행 코드베이스를 향하여 — 토큰맥싱 이후의 소프트웨어 엔지니어링

본문

AI 코딩 에이전트는 이제 실제로 재미있는 게임을 한 번의 시도로 만들어내고, 적절한 가드레일만 있으면 복잡한 코드베이스의 대규모 마이그레이션이나 다른 언어로의 재작성까지 수행합니다. 그럼에도 '실제' 소프트웨어 작업의 대부분은 여전히 사람 엔지니어가 주도하고 있습니다. Detail 블로그의 이 글은 올해 상반기 많은 조직이 에이전트 군단과 적대적 루프(adversarial loop)에 최대한 많은 일을 떠넘긴 이른바 '토큰맥싱(tokenmaxxing)'의 결과가 '의심스러운 코드의 산'만 남겼을 뿐 ROI가 불분명했다고 진단합니다. 하이프 사이클로 말하면 지금은 '환멸의 저점(trough of disillusionment)'이며, 다음 단계는 다른 도입 주기와 마찬가지로 모범 사례를 찾고 필요한 빌딩 블록을 만드는 것입니다.

엔지니어는 무엇을 하게 되는가

흔한 답인 '루프를 세팅하는 일'은 오해라고 저자는 말합니다. 지금은 비용 대비 순수익이 나는 소프트웨어 루프를 만드는 것이 어렵지만, 그것은 툴체인이 준비되지 않았기 때문이며 도구가 갖춰지면 루프는 쉽고 저렴해질 것입니다. 가장 가치 있는 엔지니어링 작업은 '좋은 아이디어를 갖는 것'입니다. Cursor Tab, Descript의 트랜스크립트 편집, OpenRouter의 추론 벤더 통합 결제처럼 킬러 기능은 여전히 회사를 만드는 아이디어이고, 문제에 대한 친밀함과 도메인 전문성이 필요합니다. 킬러 아키텍처 역시 고레버리지로, 올바른 단순화는 이후의 버그와 복잡성을 크게 줄입니다.

어떤 부분이 자율 주행이어야 하는가

저자는 '좋은 아이디어' 외의 코드베이스 작업은 GPU로 옮겨야 한다고 주장합니다. 대상으로 ▲대부분의 버그 탐지와 수정 — SSO 로그인 사용자에게만 안 되는 기능, 일괄 삭제 시 행 카운터 미갱신처럼 의도된 동작이 자명한 버그는 사람의 판단이 필요 없음 ▲프로덕션 에러 디버깅 — 에러를 최근 커밋·트래픽·인프라 변화와 연관 짓고 패치까지 수행해 백엔드의 500 에러와 브라우저 콘솔 에러를 사실상 제거 ▲에이전트 최적화 — Braintrust, Raindrop, Arize, Langfuse 같은 도구가 에이전트의 병리를 분리하고 프롬프트 개선을 제안·백테스트·배포 ▲프론트엔드 일관성 — 폰트·색상·간격이 스스로 부트스트랩되고 강제되는 디자인 시스템 ▲애플리케이션 폴리시 — Ctrl+클릭 새 탭, 비활성 버튼의 이유 설명, 새로고침 시 폼 유지, 모바일 렌더링, 스크린 리더 등 수십 가지 품질 기대치 ▲그로스 최적화 — 장바구니 이탈 이메일 같은 검증된 플레이북을 에이전트가 코드가 아니라 현실을 상대로 반복 실험 등을 열거합니다. GitHub Copilot이 코드 라인의 자동완성이었다면, 에이전트는 제품 전체의 자동완성이 될 것이라고 요약합니다.

빠진 프리미티브

이 비전에는 세 가지 새 프리미티브가 필수라고 합니다. 첫째, 에이전트가 읽을 수 있는 개발 환경(agent-legible dev environment)입니다. 버그는 압도적으로 에이전트가 볼 수 없는 영역에서 발생하며, 서드파티 통합을 end-to-end로 검증할 수 없거나 브라우저 확인 수단이 없으면 그 영역은 사각지대가 됩니다. 둘째, 글로벌 메모리입니다. 에이전트가 어리석은 실수를 하는 것은 괜찮지만 같은 실수를 반복하면 안 되며, 감사 로그 테이블이 append-only라는 교정이 코드 리뷰 봇이나 SRE 봇 등 툴체인 전체와 미래의 모든 에이전트에 공유되어야 합니다. 셋째, 코드베이스 부패 방지로, 데드 코드 방치나 같은 일의 다섯 가지 방식을 관리하지 않으면 코드베이스가 나선형으로 악화됩니다. APM·CI·A/B 테스트 같은 기존 프리미티브도 에이전트 중심 형태로 계속 필요합니다.

에이전트 친화적 개발 스택 만들기

현재 개발 에이전트의 제약은 모델이나 하네스가 아니라 동작 환경이라고 저자는 단언합니다. 에이전트가 체계적으로 재현할 수 없는 경합 조건이나 데이터 형태를 모르는 느린 쿼리에서 실수가 나오고, 사각지대는 신뢰를 낮추며 신뢰 하락은 리뷰 부담을 키워 위임 가능 범위를 줄입니다. 따라서 지금 가장 중요한 투자는 개발 환경을 에이전트에게 극도로 친화적으로 만드는 일이지만, 이 작업은 코드베이스마다 다르고 소수만 잘하는 '기술'이라 많은 소프트웨어 팩토리가 실망스러운 이유라고 분석합니다. Detail의 경로는 ▲코드베이스에서 중요한 버그를 채굴하고 ▲버그를 수정하며 검증을 어렵게 하는 갭을 추적하고 ▲그 트레이스로 에이전트 친화성 개선 작업의 우선순위를 정해, 리포지토리의 '에이전트 준비도'를 벤치마크하는 것입니다. 이 과정을 언덕 오르기(hillclimb)처럼 반복해 저수준 버그를 자율 처리하고 엔지니어는 기능 아이디어와 추상화에 집중하게 하는 것이 '생산성 안정기(plateau of productivity)'로 가는 길이며, 토큰맥싱도 AI 금지도 아닌 이 방식이 향후 6개월간 최고 팀들의 운영 방식이라고 전망합니다.

역사적 유비

기술은 저수준 관심사를 시스템에 위임하며 발전해 왔습니다. 2010년대 클라우드 이전으로 물리적 실행 위치를 신경 쓰지 않게 됐고, CI/CD 구축도 수개월 프로젝트에서 오후 한 나절 작업으로 바뀌었습니다. '루프'도 유사한 전환을 겪을 것이며, 지금의 혼란은 과도기일 뿐이라는 것이 저자의 결론입니다.

Hacker News 반응

• @rrook — 자율 주행 코드베이스가 목표가 되면서 하네스의 제2 레이어가 등장할 것이라는 게 제 예측입니다. 에이전트용 하네스와 직교하는, 애플리케이션용 하네스가 생길 겁니다. 앱 하네스는 개발 중인 특정 애플리케이션을 위해 출현하는 소프트웨어 팩토리를 표현하게 됩니다. 어쨌든 제 것은 여기 있습니다, 아직 wip입니다: https://hale-lang.org/docs/dna/
• @cyanydeez — 하네스가 아니라, 검증된 리소스라는 사용자 선택 컨텍스트의 우주에서 훈련된 더 특화된 LLM이 될 거라고 봅니다. 왜냐면 대규모로 훈련된 LLM은 항상 멍청할 것이기 때문입니다. 소프트웨어를 말하는 능력이 사용자 친화적 입력 레이어와 갈라집니다. 하네스는 그걸 극복하지 못하지만, 큰 모델 위에 얹은 LLM 안장은 원하는 피드백 루프를 제공할 겁니다. 두 결정론적 시스템이 많은 걸 만들어내진 못할 거라고 생각합니다.
• @verdverm — 파인튜닝이 같은 컨텍스트를 두 LLM에 전부 보내는 것보다 LLM 개인화에 더 확장성 있는 접근일 수 있습니다. homelab에서 little qwen으로 둘 다 해보는 중입니다.
• @rrook — 그러면 '자율 주행' 구분이 녹아버리지 않나요? 코드베이스를 구동하는 메커니즘은 코드베이스 자체 안에 존재해야 합니다. 그렇지 않으면 그냥 일반적인 대역 외 개발 프로세스일 뿐입니다.
• @sroerick — 이 글이 암시하지만, 블로커는 환경이라고 생각합니다. Windows에서 어떻게 앱을 자율 주행하나요? 명확한 UI 프레임워크도, 디자인 패턴도, 앱을 방탄으로 만들 수 있는 것도 없습니다. Plan 9에서라면 더 나았을 겁니다. 선택지를 제거하세요. 옵션이 제한되고 기본값이 바로 쓸 수 있는 프레임워크를 만드세요.

원문: Detail Blog (blog.detail.dev) / 번역·요약: Trawling