스탠퍼드·칭화대 공동 연구팀이 올해 흥미로운 실험을 발표했다. 같은 모델, 같은 태스크, 다른 하네스 아키텍처. 결과는 6배 성능 차이였다. 모델을 바꾸지 않았다. 프롬프트를 튜닝한 것도 아니다. 에이전트를 감싸는 시스템 구조만 달랐을 뿐인데, 점수가 18.4포인트 벌어졌다. 더 극단적인 사례도 있다. 편집 도구 포맷 하나를 바꿨더니 성능이 6.7%에서 68.3%로 뛰었고, 토큰은 61% 줄었다. Vercel의 에이전트는 도구를 16개에서 1개로 줄이자 성공률이 80%에서 100%로 올라갔다.
이 수치들이 공통으로 가리키는 방향은 하나다. AI 에이전트의 성능 병목은 모델 안에 있지 않다. 병목은 모델 바깥, 즉 툴 호출 방식, 컨텍스트 관리, 상태 지속성, 오류 복구 루프—이 구조적 레이어에 있다. 팀이 더 비싼 모델로 업그레이드하거나 프롬프트를 다듬는 데 시간을 쏟는 동안, 정작 레버리지가 큰 지점은 건드리지 않고 있는 셈이다.
이 맥락에서 'Compound Engineering' 플러그인은 주목할 만한 시도다. Every.to가 만든 이 플러그인은 Claude Code, Cursor, GitHub Copilot 등 주요 AI 코딩 도구에 설치해 쓸 수 있는데, 핵심 철학이 단순하다. 각 작업 사이클이 다음 사이클을 더 쉽게 만들어야 한다. 전통적 개발이 기술 부채를 쌓는 방향으로 흐른다면, Compound Engineering은 반대 방향을 지향한다. 80%를 기획과 리뷰에, 20%를 실행에 쏟는다. 날카로운 계획이 더 작고 깔끔한 구현을 만들고, 좋은 코드 리뷰는 특정 버그가 아니라 패턴을 잡는다.
운영 루프는 /ce-brainstorm → /ce-plan → /ce-work → /ce-code-review → /ce-compound 순서로 돌아간다. 여기서 마지막 /ce-compound가 핵심이다. 이 단계에서 사이클의 학습이 파일로 기록되고, 다음 세션의 컨텍스트로 쌓인다. AI 코딩 에이전트의 구조적 약점—세션 간 무기억성—을 디스크에 저장되는 파일 레이어로 보완하는 방식이다. STRATEGY.md, docs/brainstorms/, /ce-product-pulse의 누적 리포트가 에이전트를 위한 지속 컨텍스트가 된다. 단, 한 가지 솔직한 경고가 있다. /ce-compound를 건너뛰면 복리 효과는 없다. 루프를 완전히 돌려야만 의미가 있다.
여기서 Dev.to의 또 다른 글이 중요한 질문을 던진다. 에이전트가 코드를 작성할 때 인간은 어디에 있어야 하는가. 저자는 'Vibe Coding'(빨강)과 'Enabled Coding'(파랑) 사이 스펙트럼을 구분한다. 빨강은 AI 출력을 이해 없이 수락하는 상태, 파랑은 에이전트가 실행 부담을 줄여주되 인간이 방향·검증·유지보수 책임을 유지하는 상태다. 차이는 AI 개입 비중이 아니다. 인간이 평가를 포기했느냐 아니냐다.
이 구분은 팀 리빌딩 관점에서 실질적인 기준이 된다. AI가 코드를 얼마나 많이 쓰느냐를 묻는 것은 틀린 질문이다. 맞는 질문은 이것이다. 팀원이 AI가 만든 결과물의 의도, 구조, 실패 지점을 설명할 수 있는가. "왜 이 패턴을 선택했나