AI 코딩 에이전트에게 명세서를 건네고 자리를 비웠다가, 돌아와 보니 'design 섹션 1을 승인하시겠습니까'라는 질문 하나만 덩그러니 떠 있는 경험. 에이전트 기반 개발을 해 본 사람이라면 익숙한 풍경이다. superlite를 만든 개발자 이헤아투 크리스 워구(Iheatu Chris Wogu)는 이 상황을 '4분마다 허락을 구하는 협업자'라고 표현한다. 그가 원했던 것은 매 단계 손을 잡아 주는 동료가 아니라, 명세와 열쇠를 넘기면 끝났을 때 전화를 주는 '계약자'였다. superlite는 바로 그 계약자 모델을 Claude Code 플러그인으로 구현한 결과물이다.
왜 기존 워크플로는 느린가
저자는 superlite가 인기 워크플로인 superpowers의 경쟁자가 아니라고 분명히 선을 긋는다. superpowers는 사람이 모든 단계 가까이에서 방향을 잡는 신중한 협업 도구이고, superlite는 플러그인 구조, 세션 시작 훅, 수명주기 스킬 등 그 뼈대를 그대로 빌려 왔다. 다만 겨냥하는 작업이 다르다. 저자가 이미 무엇을 원하는지 정확히 알고 있을 때, 시간의 대부분은 모델이 깊이 사고하느라가 아니라 워크플로가 스스로를 기다리느라 흘러갔다. 작업 하나, 그 작업에 대한 리뷰, 리뷰에 대한 수정, 수정에 대한 재리뷰가 직렬로 이어지는 구조였다. 각각은 합리적인 안전장치지만, 쌓이면 '그냥 만들어지기만 하면 되는' 상황에서는 족쇄가 된다.
superlite의 핵심은 네 가지다. 한 번의 승인, 병렬 실행을 전제로 쓰인 계획, 작업에 맞춘 에이전트 배치, 그리고 프롬프트가 아닌 코드로 강제되는 규칙이다. 요청이 들어오면 먼저 규모를 가늠한다. 오타는 설계 문서 없이 그냥 고치고, 기존 플로 변경은 짧은 설계를 대화로 제시하며, 신규 프로젝트는 최대 네 개의 질문을 한 묶음으로 던진 뒤 설계·계획 문서 하나를 내놓는다. 사용자는 이것을 한 번 승인하면 된다. 이후로는 파괴적이거나, 외부로 나가거나, 보안에 민감한 일에서만 멈춰 선다. 점심을 먹으러 간 사이에 main 브랜치로 푸시하는 일은 없다는 뜻이다.
병렬화를 전제로 짠 계획과 코드로 막는 규칙
계획 자체가 작업 그래프(task graph)로 설계된다는 점이 특징이다. 각 작업은 자신이 소유한 파일, 소비하고 생성하는 인터페이스, 통과해야 할 테스트를 명시한다. 파일을 공유하지 않고 서로 의존하지 않는 작업은 동시에 돌아간다. 현재 벤치마크에서는 동시에 18개의 에이전트가 작동하는 지점까지 치솟았다고 한다. 오케스트레이터는 사람이 맡아 예측 일정이 포함된 전체 계획을 승인할 수도 있고, AI에게 맡겨 전혀 개입하지 않을 수도 있다. 어느 쪽이든 에이전트가 원래 물어봤을 모든 선택은 '무엇을, 왜 결정했고, 틀렸을 때의 비용은 얼마인지'를 담은 ruling으로 기록된다. 돌아왔을 때 어떤 결정부터 의심해 봐야 하는지 바로 알 수 있게 하려는 설계다.
규칙을 프롬프트가 아닌 코드로 강제한다는 대목은 실무자에게 특히 시사적이다. 저자는 '코디네이터는 절대 코드를 편집하지 않는다'를 굵게, 대문자로, 감정을 담아 적어도 코디네이터가 읽고 고개를 끄덕인 뒤 코드를 편집하더라고 토로한다. 그래서 지금은 훅이 이를 막는다. 한 훅은 코디네이터의 프로젝트 코드 편집을 차단하고, 다른 훅은 날것의 pytest나 npm test 실행을 백그라운드 실행으로 조용히 바꿔 테스트가 작업을 막지 않게 한다. 계획은 작업 시작 전 lint --stable을 통과해야 하며, 모든 에이전트의 토큰·비용·시간이 기록돼 다음 실행의 예측과 상한의 70%에서 알림을 주는 소프트 예산에 반영된다.
벤치마크를 어떻게 읽어야 하나
저자는 '자기가 만든 도구를 빠르다고 말하기는 누구나 쉽다'며, 숫자는 모두 헤드리스 벤치마크 하니스에서 나온 것임을 강조한다. 테스트 대상은 흔한 할 일 목록 앱이 아니라, 정적 사이트 생성기와 스프레드시트 엔진(수식 평가기, HTTP API, 브라우저 UI)을 하나의 명세로 묶어 만들고 177개의 숨겨진 테스트로 채점하는 프로젝트다. 결과는 superpowers와 동일하게 177개 전부 통과하면서 시간은 약 절반, 그리고 평균 26.9분이던 자사 이전 빌드보다 40% 빠른 16.1분이었다. 속도의 상당 부분은 큐를 없앤 데서 나왔다. 직렬로 21개 에이전트를 던지던 방식 대신 최대 5개를 동시에 돌리는 식이다.
다만 저자 스스로 이 수치를 '동일 머신에서의 단일 실행 비교이므로 동료 심사를 거친 과학이라기보다 강한 힌트'라고 규정한다는 점은 균형 있게 받아들일 필요가 있다. 또한 superpowers와 superlite를 같은 세션에서 함께 켜면 안 된다. 스킬 이름을 공유하고 둘 다 시작 시 컨텍스트를 주입하기 때문이다. 결국 이 글이 주는 실무적 교훈은 도구 선택 자체보다 진단법에 가깝다. 에이전트 워크플로가 느리다면 그 원인은 모델의 깊은 사고가 아니라 작업이 줄을 서 있고 무언가 계속 허락을 구하기 때문일 가능성이 크다. 인터페이스 경계를 따라 작업을 쪼개 독립적인 것은 동시에 돌리고, 기계적인 단계는 스크립트로 옮기며, 중요한 규칙은 코드로 강제하라는 것. 방향을 일일이 잡고 싶다면 여전히 협업형 도구가 맞지만, 이미 원하는 바가 명확한 자율 개발이라면 설계 방향을 뒤집어 볼 만하다는 제안이다.