Will Larson — AI 에이전트를 비계(Scaffolding)로 써야 하는 이유

원문: https://lethain.com/agents-as-scaffolding/ | Will Larson (Irrational Exuberance), 2026년 4월 12일

핵심 요약

엔지니어링 리더십 블로그 Irrational Exuberance의 저자 Will Larson이 AI 에이전트 자동화에 관한 반직관적인 교훈을 공유했다. 핵심 메시지는 단순하다: 에이전트는 인간의 완전한 대체재가 아니라, 모호함을 처리하는 특정 지점에만 배치해야 하는 '비계(scaffolding)'다. 보안 취약점 알림 자동화를 직접 구현하며 얻은 이 결론은, 2026년 AI 에이전트 열풍 속에서 조용하지만 날카롭게 현실을 짚어낸다.

"CRITICAL: 반드시 이것만 해야 한다" — 그래도 말을 안 듣는다

Larson은 GitHub Dependabot 웹훅을 모니터링해 중요 보안 알림을 자동으로 처리하는 에이전트를 구축하려 했다. 목표는 간단했다: '심각(critical)' 등급의 취약점만 걸러내어 담당자에게 Slack으로 알리는 것.

문제는 에이전트가 '심각'이 아닌 취약점도 계속 처리한다는 점이었다. 프롬프트를 수십 번 반복해서 수정했다. "CRITICAL: 반드시 critical 등급만 처리할 것"이라는 문구를 여러 번 넣어도 마찬가지였다. 에이전트는 끝까지 신뢰할 수 없었다.

이 경험에서 Larson이 발견한 핵심 통찰이 있다. 동료에게 메시지를 보내는 행위는 거의 완벽한 정확도를 요구한다. 인간 직원이 실수를 반복하면 즉각적인 피드백을 받지만, 에이전트의 오작동은 조용히, 그리고 지속적으로 반복된다. 수신자는 반복되는 잘못된 알림에 지쳐 아예 무시하기 시작하고, 결국 자동화 시스템 전체가 신뢰를 잃는다.

해결책: 에이전트를 '좁은 구간'에만 배치하라

Larson의 답은 에이전트를 버리는 것이 아니었다. 에이전트가 잘하는 일과 코드가 잘하는 일을 분리하는 것이었다.

그가 도달한 아키텍처는 다음과 같다:

웹훅 수신 → 코드: 자동화 스크립트가 Dependabot 알림을 받아 심각도를 추출하고 필터링한다. 이 부분은 코드가 100% 신뢰할 수 있게 처리한다.
코드 오너 탐색 → 에이전트: 어떤 팀이 해당 저장소를 담당하는지는 내부 지식이 필요한 모호한 문제다. 에이전트가 GitHub MCP와 내부 스킬을 활용해 판단한다.
Slack 알림 포맷 → 에이전트: 메시지 형식과 맥락을 자연스럽게 구성하는 것은 에이전트가 유리한 영역이다.

결과적으로 이 하이브리드 구조는 "100% 동작한다." 에이전트는 인간 판단이 필요한 모호한 지점만 처리하고, 나머지는 예측 가능한 코드가 담당한다.

Larson은 이를 세 단계 패턴으로 정리했다:

"에이전트 기반으로 프로토타입을 만든다 → 에이전트 제어 로직을 코드로 대체한다 → 에이전트는 오직 모호함을 탐색해야 하는 작업에만 남긴다."

업계의 반응: 동의와 경고

Larson의 접근 방식은 업계 실무자들의 경험과 맞닿아 있다.

Stripe는 매주 1,300건 이상의 자율적인 풀 리퀘스트를 생성한다고 알려졌다. Uber는 주당 1,800건의 코드 변경 중 70%를 AI가 생성한다. 하지만 두 회사 모두 공통적으로 강조하는 것이 있다: 철저한 스캐폴딩과 내부 개발 도구와의 통합이 핵심이었다는 점이다. 에이전트를 단순히 '풀어놓은' 것이 아니라, 엄격한 제약 안에 배치했다.

반대 증거도 존재한다. Gartner는 2027년까지 에이전트 기반 AI 프로젝트의 40%가 취소될 것으로 전망한다. Fortune이 인용한 연구에 따르면 레거시 에이전트의 90%가 배포 몇 주 내에 실패한다. 가장 흥미로운 데이터 중 하나는 AI 코딩 에이전트가 주니어 개발자의 생산성은 10~30% 향상시키지만, 숙련된 개발자는 19% 느려지게 만든다는 연구 결과다. 검증 부담이 코드 생성 속도의 이점을 상쇄하는 것이다.

Andrej Karpathy는 같은 시기에 "vibe coding은 끝났다"고 선언하며, 개발자가 에이전트를 오케스트레이션하는 '기술 감독자'로 역할이 바뀌어야 한다고 주장했다. Larson의 비계 전략은 그 감독의 구체적인 형태를 보여준다고 볼 수 있다.

개발자 역할의 재정의: 프롬프트 엔지니어에서 하네스 엔지니어로

Larson의 글이 제기하는 더 큰 질문은 개발자 역할 자체에 관한 것이다.

AI 에이전트 도입 초기, 많은 조직이 "프롬프트를 잘 쓰면 에이전트가 다 해준다"는 기대로 시작했다. 하지만 실제 프로덕션에서 신뢰할 수 있는 결과를 얻으려면, 코드 기반의 제약(constraint)과 피드백 루프, 에이전트의 출력을 검증하는 하네스(harness)를 설계하는 능력이 핵심 경쟁력이 된다.

이른바 '하네스 엔지니어링(harness engineering)'이다. 코드를 쓰는 것과 다르고, 프롬프트를 최적화하는 것과도 다르다. 에이전트가 실패했을 때 조용히 넘어가지 않도록 경계를 설계하고, 에이전트가 잘하는 좁은 구간을 정확히 파악해 배치하는 능력이다.

Larson은 이 접근이 "더 빠르고, 더 저렴하며, 더 유지보수하기 쉽다"고 말한다. 그리고 대부분의 경우 기존 로그와 프롬프트를 언어 모델에 넣어주면 몇 분 안에 구현 가능하다고 덧붙인다.

이 논의가 남기는 질문

Larson의 비계 전략은 오늘 당장 적용 가능한 실용적인 답이다. 하지만 그의 글 끝에서 짧게 언급한 부분이 더 큰 질문을 남긴다.

"AI로 역량이 강화된 팀이 초기 하이퍼그로스를 빠르게 통과한 것처럼, 후기 하이퍼그로스도 빠르게 통과할 수 있을까? 만약 그게 가능하다면 경제적 기적이 될 것이다."

지금 많은 스타트업이 에이전트로 초기 제품을 빠르게 만들고 있다. 하지만 규정 준수, 안정성, 고객 지원, 계약 이행 같은 후기 과제들도 에이전트로 '빠르게' 극복할 수 있을까? 아직 아무도 답을 모른다.

에이전트를 비계처럼 쓰라는 조언은 겸손한 접근처럼 들리지만, 사실 그 안에는 명확한 엔지니어링 철학이 있다. 신뢰는 설계에서 온다. 프롬프트에서 오지 않는다.