에이전트를 '훈련'할까, 그냥 '잘 설명'할까
Claude Code 같은 코딩 에이전트를 쓰다 보면 누구나 비슷한 고민을 하게 돼요. 에이전트가 똑똑한 건 알겠는데, 일을 맡기면 엉뚱한 방향으로 달려가요. 테스트도 안 돌려보고 '다 했어요!' 하고 끝내버리는 일도 많고요. 그래서 에이전트에게 일하는 절차를 가르치는 워크플로 도구들이 나왔는데요. 그중 대표가 Jesse Vincent가 만든 Superpowers예요.
이번에 소개할 Superlite는 이름 그대로 Superpowers보다 가볍고 빠른 대안을 내세워요. 메시지는 단순해요. 에이전트에게 복잡한 절차를 따르게 하지 말고, 잘 쓴 스펙(명세서) 하나를 건네라는 거예요.
먼저, Superpowers는 뭐였나
Superpowers는 Claude Code용 플러그인이에요. 개발 방법론을 '스킬(skill)' 형태로 에이전트에게 넣어줘요. 스킬이 뭐냐면, 특정 상황이 오면 에이전트가 꺼내 읽는 업무 매뉴얼 같은 마크다운 문서예요. 신입 사원에게 '버그 잡을 땐 이 체크리스트대로 해' 하고 가이드를 쥐여주는 거랑 비슷해요.
흐름은 대략 이래요. 먼저 브레인스토밍 단계에서 에이전트가 질문을 하나씩 던지면서 요구사항을 다듬어요. 다음 계획 작성 단계에서는 작업을 몇 분짜리 태스크로 잘게 쪼개요. 각 태스크마다 어떤 파일을 고치고 어떻게 검증할지까지 적어두고요. 실행 단계에서는 태스크마다 새 서브에이전트(따로 띄우는 작은 에이전트)한테 일을 시키고, 결과를 리뷰한 다음 넘어가요. 그 사이 테스트를 먼저 쓰는 TDD도 엄격하게 지키게 하죠.
품질은 확실히 좋아요. 대신 질문을 주고받는 횟수가 많고, 문서도 여러 겹 생기고, 서브에이전트를 띄울 때마다 컨텍스트를 새로 채워야 해요. 그래서 시간과 토큰을 꽤 많이 써요. 버튼 색 하나 바꾸는데 회의하고 기획서 쓰고 결재까지 받는 대기업 프로세스 같다는 느낌이 들 때도 있어요.
Superlite의 발상: 절차 대신 스펙
Superlite가 노리는 게 바로 이 부분이에요. 따져보면 Superpowers의 여러 단계는 결국 하나를 위한 거예요. '에이전트가 뭘 만들어야 하는지 정확히 알게 하는 것'이요. 그럼 사람이 처음부터 명확한 스펙을 들고 오면 그 많은 의식(ritual)을 상당 부분 건너뛸 수 있지 않을까요?
이렇게 하면 왜 빨라지는지는 분명해요. 우선 에이전트와 질문을 주고받는 횟수가 줄어요. 그리고 에이전트의 컨텍스트 창이 절차 설명서 대신 실제 작업 정보로 채워져요. 컨텍스트 창은 에이전트가 한 번에 머릿속에 담아둘 수 있는 작업 공간이라고 보면 돼요. 마지막으로 스펙이 곧 완료 기준이 되니까, 에이전트가 '다 됐다'고 판단할 근거가 분명해져요.
예를 들어 이 정도 스펙만 있어도 에이전트가 훨씬 덜 헤매요.
- 목표: 회원 목록 API에 페이지네이션 추가
- 범위: GET /users에 page, size 쿼리 파라미터 추가(기본값 1, 20), 응답에 total, page, size 필드 포함
- 하지 말 것: 기존 응답 필드 이름 변경 금지
- 완료 기준: 기존 테스트 전부 통과, size=0이나 size=1000 같은 경계값 테스트 추가
업계 흐름: 스펙 주도 개발의 부상
'스펙이 먼저'라는 흐름은 Superlite만의 이야기가 아니에요. GitHub은 Spec Kit을 내놓고 명세, 계획, 태스크 순서로 AI 개발을 진행하는 '스펙 주도 개발(Spec-Driven Development)'을 밀고 있어요. AWS의 Kiro IDE도 요구사항, 설계, 태스크 문서를 먼저 만든 다음 코드를 생성하는 방식을 내세웠고요. 감으로 대충 코딩을 맡기는 '바이브 코딩'과는 반대 방향이죠.
결국 차이는 '스펙을 누가, 얼마나 무겁게 만드느냐'예요. Superpowers는 에이전트가 사용자를 인터뷰하면서 스펙과 계획을 같이 만들어가는 무거운 쪽이에요. Superlite는 사람이 스펙을 들고 와서 바로 넘기는 가벼운 쪽이고요. 어느 쪽이 정답이라기보다는 작업 크기에 맞춰 골라 쓰는 도구에 가까워요.
한국 개발자에게 주는 시사점
팀에서 Claude Code나 Cursor를 막 쓰기 시작했다면 이 논쟁에서 건질 게 많아요. 제일 실용적인 교훈은 작업 크기에 맞춰 프로세스 무게를 조절하라는 거예요. 새 기능을 처음부터 설계해야 하거나 요구사항이 흐릿하다면 Superpowers처럼 에이전트가 질문하게 두는 게 나아요. 반대로 뭘 할지 이미 분명한 수정이나 확장 작업이라면 짧은 스펙 하나로 바로 맡기는 게 훨씬 빨라요.
그리고 이제는 스펙을 잘 쓰는 능력이 핵심 역량이 돼요. 한국 개발 문화에서는 기획서는 기획자가 쓰고 개발자는 구현만 하는 경우가 많았잖아요. 그런데 에이전트 시대에는 '에이전트가 오해할 틈이 없는 짧고 정확한 명세'를 직접 쓸 줄 아는 개발자가 생산성에서 앞서가요. 팀에서 스펙 템플릿 하나 정해두는 것부터 시작해보세요.
마무리
한 줄 정리: 에이전트에게 일하는 방법을 길게 가르치는 것보다, 뭘 만들지 정확히 알려주는 게 더 빠를 수 있어요.
여러분은 코딩 에이전트에게 일을 맡길 때 어느 쪽이세요? 꼼꼼한 워크플로를 깔아두는 편인가요, 아니면 짧은 프롬프트나 스펙 하나로 바로 맡기는 편인가요? 실제로 어느 쪽이 더 잘 먹혔는지 경험을 나눠주세요.
🔗 출처: Hacker News