요약
Superlite는 명세 하나만 받으면 한 번의 승인 뒤 테스트와 커밋까지 혼자 끝내는 Claude Code 플러그인입니다.
엔지니어링 매니저 이헤아투 크리스 워구가 만든 도구입니다. 그는 쓰던 플러그인 Superpowers가 몇 분마다 승인을 물어 에이전트에게 일을 맡기고 자리를 비울 수 없었습니다. 그래서 지연 원인을 분석해 자율 실행에 맞춘 도구를 따로 만들었습니다.
왜 중요한가
- 속도를 늦춘 것은 모델이 아니라 작업 흐름이었다는 분석입니다. 순차 대기열, 작업마다 반복되는 리뷰, 거듭된 전체 테스트가 원인으로 꼽혔습니다.
- 사람의 확인을 실시간 승인에서 사후 검토로 옮겼습니다. 에이전트가 대신 내린 결정은 근거와 위험도와 함께 판정(ruling) 기록으로 남습니다.
- 지시문만으로는 조율 에이전트가 코드를 고치는 것을 막지 못해, 규칙을 훅(정해진 시점에 자동 실행되는 스크립트)으로 강제했습니다.
핵심 내용
- 새 프로젝트면 질문을 최대 4개만 한 번에 묻고, 설계와 계획을 문서 하나로 승인받습니다.
- 승인 뒤에는 파괴적이거나 보안에 민감한 작업에서만 멈추고, main 브랜치 푸시와 병합은 하지 않습니다.
- 작업마다 맡을 파일과 통과할 테스트를 정해 독립 작업을 병렬로 돌리며, 최대 18개 에이전트가 동시에 일했습니다.
- Opus는 조율만 하고 코드는 Sonnet이, 단순 작업은 Haiku가 맡습니다.
- 숨긴 테스트 177개를 16.1분에 모두 통과해 Superpowers 기본 설정(33.6분)보다 52% 빨랐지만, 작성자도 표본이 작다고 인정했습니다.
HN 반응
- 최신 모델은 이런 스킬 없이도 명세를 쓰고 구현까지 해 내서 이제 필요 없고, 오히려 토큰만 낭비한다는 의견이 많았습니다.
- 반면 스킬은 절차를 정하는 도구라서 설계 문서 같은 결과물을 일관되게 남기려면 여전히 필요하다는 반론도 나왔습니다.
저는 이런 접근법은 거의 포기했습니다. 모델은 가장 곤란한 순간에 프로세스 지시를 그냥 무시하곤 합니다. 업무에서는 결국 작은 단위의 작업을 에이전트 하나에 맡기고 제가 직접 조율하는 방식으로 정착했습니다. 저는 AI를 도구로 여기고, 장인은 저 자신이라고 생각합니다.
다들 에이전트 플릿이니 스웜이니 밀고 있고 성공 사례도 많겠지만, 사내에서 실험해 본 바로는 복잡한 작업에서 속도 이점을 느끼는 개발자가 많지 않았습니다. 한 명이 최근 이렇게 말했습니다. "속도에서 얻은 이득이 수작업 리팩터링으로 상쇄된다. 코드는 '맞게' 돌아가지만, 우리 중 누구도 그렇게 짰을 법한 코드가 아니다."
동작만 하면 코드는 무시해도 되고(실제로 임원진이 우리에게 지시한 것이 그것입니다) 최종 결과물이 "돌아가기만 하면" 이런 플릿을 계속 돌리면 된다고 주장할 수도 있겠지만, 장기적으로 잘 끝날지는 완전히 납득이 되지 않습니다.
하긴 저는 사람이 도입했지만 이제는 아무도 이해하지 못하는 수십 년 된 레거시 코드와 시스템에 발이 묶여 있는 처지이긴 합니다...
처음에는 기술 부채가 아직도 중요한지 확신이 없었는데, 지금은 분명히 중요하다고 생각합니다. 계획 단계에 조금이라도 제가 관여하는 한, 코드베이스의 복잡성은 결국 저한테까지 올라옵니다. Claude가 이렇게 말하거든요. "좋아요, 그건 만들 수 있는데, 아무도 필요로 하지 않고 저도 존재하는 줄 몰랐던 레거시 코드 경로 A, B, C, D는 어떻게 처리할까요?"
"레거시"가 같은 세션에서 Claude가 명시적 지시 없이 직접 추가한, 일어날 수도 없는 엣지 케이스용 코드를 가리키는 경우라면 더 좋죠.
지금의 LLM은 모듈식 설계의 덕을 보지만, 사람이라면 질색할 것에서도 덕을 본다고 생각합니다. 바로 임의의 고유성입니다. 서비스가 세 개라면 main() 함수는 고유한 함수 하나를 부르는 게 전부여야 합니다. 안 그러면 모델이 지금 어느 걸 말하는 건지 서서히 놓치기 시작하거든요.
저는 로컬 AI가 수정이 어디에 반영되는지 도무지 파악하지 못해서 1천 줄짜리 스크립트를 기능 단위 컴포넌트로 쪼갠 적이 있습니다. 그렇게 나누고 나니 각 범위 안에서 기능을 고치는 건 아무 문제 없이 해내더군요.
진짜 시장은 2027년쯤부터 32GB 안팎에서 돌아가는 로컬 코딩 모델이라고 봅니다. 물론 우리에게 뭘 내려줄지는 자본주의가 정하겠지만, Qwen3.8-Flash-Next를 SSD 오프로딩으로 VRAM 40GB 정도에서 돌릴 수 있다는 걸 알고 나면, 데이터센터는 훨씬 효율적이 되거나 아니면 말라 죽거나 둘 중 하나일 겁니다.
그래도 그건 코드를 이해하기 쉽게 유지하려고, 어쩌면 문서화까지 하려고 많은 노력을 들였는데도 그런 겁니다. 이제는 그런 시도조차 하지 않는다면 결과는 천 배는 더 나빠질 테고, LLM에 대한 의존은 절대적이 될 겁니다.
에이전트 스웜이 필요하다고 느낀 건 코드베이스 전체를 기계적으로 마이그레이션하거나 검증할 때뿐이었습니다.
어차피 LLM이 내놓는 결과물은 제가 확인하는 속도보다 훨씬 빠릅니다. 오래 걸리는 작업이 있으면 그게 끝나기를 기다리는 동안 다른 작업을 병렬로 합니다.
저는 Every의 Compound Engineering을 꽤 오래 써 왔습니다. 브레인스토밍과 계획 기능이 마음에 들고, Matt Pocock의 /grill-me 스킬도 좋아합니다. 저처럼 평범한 프로그래머에게는 아이디어를 다듬고, 문서화하고, 구현하는 데 도움이 됩니다.
나머지 스킬 대부분은 '엔터프라이즈스러운' 개발 방식을 흉내 낸 것 같았습니다. 모든 걸 '위원회' 같은 걸 거쳐 여러 번 검사하느라 느려지고, 토큰을 미친 듯이 빨아들이고, 과정 전체에서 화물 숭배의 냄새가 납니다.
저도 같습니다. superpowers에서 브레인스토밍만 빼고 전부 꺼 뒀습니다.
직접 결정을 내리고 여러 대안을 저울질하면 이해도가 올라가고, 결과도 더 좋아진다고 생각합니다. 제가 이해하고 있어서 그렇게 느끼는 것일 수도 있지만, 그것만으로도 충분히 가치가 있습니다.
지금은 grill-with-docs가 나왔고, Matt는 이걸 후속작으로 보고 있어요.
다른 분들처럼 저도 superpowers가 한 4개월 전까지는 도움이 됐습니다. 지금 모델들은 더 이상 그게 필요 없는 것 같고요. 저는 글쓴이가 겪는 프롬프트 문제도 없습니다. Opus 5.5는 알아서 스펙을 작성하고, 제가 동의했다고 가정하고, 그대로 만들어 냅니다. 저는 샌드위치를 만들고 돌아와 스펙 md, diff, 그 밖의 완료 증거를 확인합니다. cc cli를 쓰고, cmux 같은 플랫폼을 붙여 제어하게 합니다(스펙과 diff를 보여 주는 탭을 직접 열게 하는 식이죠).
제 생각엔 "제가 동의했다고 가정한다"는 부분이 진짜 퇴보입니다. Opus 5.5나 Fable 5.1도 대부분은 설익은 계획을 내놓거든요.
틀렸으면 중간에 끊고 어디가 틀렸는지 설명하면 되고, 기능에 대해 브레인스토밍이 더 필요하면 그렇게 하면 돼요. 그렇게 어렵지 않아요.
애자일로 일하고 있는 거죠?
죄송합니다, 무슨 말씀이신지 잘 모르겠습니다.
농담이었습니다만, 취지는 이렇습니다. 완벽한 계획을 세우는 건 워터폴 방식이고, "우리"(요즘 소프트웨어 개발자들)는 이제 애자일로 일하니까 어디서든 일단 시작하고 가면서 계획을 고쳐 나간다는 거였습니다.
제가 아는 개발자 대부분은 워터폴에 가까운 방식으로 돌아갔습니다. 에이전트가 이쪽의 전통적인 트레이드오프를 뒤집어 놓았거든요.
저는 에이전트에게 계획 문서 하나와 비교적 단순한 프롬프트만 주고 며칠씩 알아서 작업하게 합니다. 가끔 커밋을 확인해서 무슨 일이 벌어지는지 보는 정도고요. superlite가 여기서 뭘 더 낫게 해 줄지 모르겠습니다.
며칠씩 걸리는 게 대체 무슨 작업인가요?
지금쯤이면 모델들이 이미 그 플러그인 코드를 학습 코퍼스에 갖고 있을 테고, 사용자들이 플러그인과 상호작용한 RL 데이터도 충분히 있을 거라고 생각합니다.
저는 이제 모델은 필요 없다고 봅니다. AI 업계에서 벌어지는 새로운 흐름을 보면, 저는 Gemini 3.8 Flash를 오래 써 왔고 Claude, Opus 5.5, Sonnet 5.5도 써 봤는데, SuperPars든 SuperLight든 그걸 쓸 이유를 정말 하나도 못 찾겠습니다.
스펙에서 가장 중요한 건 일단 스펙을 갖추고, 모델이 명확히 하기 위한 질문을 하게 만드는 거라고 생각합니다. 그러려고 스킬이나 프로세스까지 필요하진 않습니다. 모델에게 스펙에 관해 질문해 달라고 하면 그만입니다.
Haiku와 Sonnet 서브에이전트가 Opus보다 정말 더 나은 결과를 내는지도 아직 확신이 안 서고, 완전히 자율로 돌리는 상황에서 속도가 그렇게까지 중요한지도 모르겠습니다. 글쓴이가 말하는 건 20분쯤 아끼는 얘기잖아요. 하루는 24시간이고, 지금처럼 쉬지 않고 밀어붙이는 입장이라면 병목은 엔지니어링보다 제품 스펙과 자기가 뭘 원하는지 아는 것, 그리고 좋은 아이디어일 가능성이 훨씬 큽니다.
여기 댓글을 보면 스킬이 근본적으로 무엇인지에 대한 이해가 부족하다는 게 분명합니다. 스킬은 프로세스, 즉 절차입니다.
최신 프론티어 모델들은 RL 단계에서 학습된 괜찮은 프로세스를 보여 주고, 그 덕에 원샷 능력이나 전반적인 코딩 능력은 크게 좋아졌을 수 있습니다. 하지만 스킬이 없는 모델에는 지속적으로 유지되는 프로세스가 없습니다.
에이전트를 쓰면서 절차가 필요하다면 이런 스킬은 반드시 필요합니다. 저는 이 스킬이나 superpowers의 상대적 장단점을 논하려는 게 아니라, "스킬은 좋다" 대 "스킬은 나쁘다"는 식으로 계속 반복되는, 거의 종교 논쟁 같은 토론을 말하는 겁니다.
네, 동의합니다.
여기 댓글 대부분은 사람들이 스킬로 얻으려던 구체적인 것들에 초점을 맞추고, 그게 아직 필요한지를 따지고 있네요.
그건 사람마다 크게 다를 겁니다.
superpowers 같은 걸 쓴 목적이 모델이 작업을 "제대로" 하게 만드는 프로세스였다면, 그건 이제 필요 없을 가능성이 높습니다.
목적이 개발한 결과물과 함께 일관된 산출물 세트를 얻는 것이었다면(여기서 일관되다는 건 품질이 아니라 "설계 계획 하나, 구현 계획 하나" 같은 형태를 말합니다) 달라진 건 없습니다. 모델은 뭔가가 시키지 않는 한 이걸 지속적으로, 일관되게 하지 않습니다.
물론 예를 들어 최신 Opus는 스펙을 쓰기로 결정하는 경우가 많습니다. 하지만 항상 그런 건 아니고, 일관된 형식이 있는 것도 아닙니다...
그렇게 되길 원한다면 여전히 그렇게 만들어 주는 스킬이 필요합니다.
그게 상관없다면 당연히 스킬은 더 이상 필요 없고요.
사람들은 스킬을 저마다 다른 목적으로 써 왔기 때문에, 무엇이 아직 필요한지에 대한 의견도 크게 갈립니다.
프로세스가 무슨 뜻인지 제가 이해하지 못하는 것 같습니다. 저는 그냥 LLM에게 원하는 프로세스를 말해 줍니다. 계획 문서를 따르고, 적절할 땐 더 저렴한 서브에이전트를 쓰고, 머지하기 전에 PR 코멘트에 답하라는 식으로요. 보통 짧은 문단 하나입니다.
다른 용도로는 스킬을 쓰고, 스킬이 나쁘다고 생각하지도 않습니다. 다만 이 경우에 스킬이 뭘 더해 주는지 모르겠을 뿐입니다.
그 짧은 문단이 본질적으로 당신의 스킬입니다. 당신이 일하고 싶은 방식, 따르고 싶은 프로세스니까요.
스킬이 있어도 모델에 지속적인 프로세스가 생기진 않습니다. 모델이 업데이트될 때마다 스킬을 해석하는 방식이 바뀌니까요.
에이전트에게 작업을 넘기면 추상화 수준, 중요한 세부 사항, 아니면 그냥 빠뜨린 맥락 중 하나는 꼭, 꼭, 꼭 틀립니다. 작업을 넘기느니 리뷰를 많이 하는 쪽이 낫습니다. 실제로 생성되는 결과물에 신경을 쓴다면, 제 생각엔 아직 거기까진 못 왔습니다.
하위 등급이나 구형 모델에는 필요할 수도 있겠죠. 제 경험상 최신 모델에서는 오히려 성능을 해치고 토큰만 쓸데없이 태웁니다. 프로젝트에 맞춘 agents.md는 여전히 필요하지만 폭넓은 스킬은 더 이상 필요 없습니다. 소프트웨어 개발 모범 사례가 포스트 트레이닝 때 이미 모델에 녹아든 것 같거든요.
마크다운 산업 복합체.
근본적인 문제는 이렇습니다.
모델의 출력은 확률적입니다. 객관적으로 검증 가능한 사실입니다. 같은 프롬프트를 반복해도 출력이 다르게 나옵니다.
마크다운을 잔뜩 쓰는 이런 접근법에서는 시스템이 시스템 상태를 코드뿐 아니라 수많은 마크다운 파일에서도 따로 추적해야 합니다.
기능 추가와 버그 수정으로 시스템이 바뀌면 대응하는 마크다운 파일도 동기화를 위해 같이 갱신해야 합니다.
이 갱신에는 분명히 토큰이 들기 때문에 토큰 지출이 천정부지로 뜁니다.
그런데 모델이 확률적이기 때문에 진짜 문제는, 그 마크다운 파일의 어떤 곳은 갱신이 안 되거나 잘못된 정보로 갱신되는 일이 반드시 생긴다는 점입니다.
다음 에이전트 실행 때 이 마크다운 파일에서 컨텍스트를 불러오면 컨텍스트에 잘못된 정보가 섞여 있고, 작업 도중에 그걸 발견해 바로잡아야 합니다. 토큰 지출은 네 배가 됩니다.
그 마크다운 파일 중 실제로 거쳐 간 엣지 케이스만 바로잡히니 불일치는 여전히 많이 남고, 시간이 지날수록 쌓이고 불어납니다.
이런 접근법을 제대로 경험해 본 사람이라면 누구나 그렇다고 증언할 겁니다.
해결책은 에이전트를 전동 공구처럼 쓰고, 컨텍스트와 원하는 결과물을 자기 머릿속에 담고 있는 것뿐입니다.
찾으시는 단어는 신뢰할 수 없음입니다.
믿을 수 없음.