본문 바로가기
경험담

내가 더 이상 Superpowers를 쓰지 않는 이유

jhste102lab 2026. 6. 28. 19:34

결국 내 워크플로는 내가 설계해야 했다

한동안 나는 AI 코딩 에이전트를 더 잘 쓰기 위해 꽤 많은 스킬과 프롬프트 묶음을 써봤다.
Superpowers도 써봤고, Karpathy 스타일의 짧고 강한 코딩 지침도 써봤고, Matt Pocock의 스킬들도 가져다 써봤다. GSD류의 작업 지시 방식도 시도했다.

 

각각 배울 점은 있었다. 문제는 “이거 하나면 됐다” 싶은 것은 없었다는 점이다.

 

특히 Superpowers는 처음에는 꽤 매력적으로 보였다. 많은 상황을 커버하려고 하고, 에이전트가 놓치기 쉬운 절차를 강하게 잡아주려는 방향도 이해가 됐다. 그런데 실제로 오래 써보니 내 사용 패턴과는 잘 맞지 않았다. 토큰을 많이 쓰는 편인데, 그만큼 정확도가 안정적으로 올라간다는 느낌은 적었다. 에이전트가 많은 절차를 읽고 움직이느라 시간이 늘어나는 경우도 있었다. 그리고 가장 중요한 문제는, 내 입맛대로 고치기가 쉽지 않았다는 점이다.

 

남이 만든 스킬을 수정하려면 “어디를 바꿔야 하는지”가 보여야 한다. 그런데 설계 의도와 경계가 내 머릿속에 없으면, 작은 문장 하나를 고치는 것도 멈칫하게 된다. 이 문장을 줄이면 어떤 상황에서 빠질까? 이 규칙을 약하게 만들면 어떤 실패가 늘어날까?

 

반대로 이 규칙을 강하게 만들면 작은 작업까지 무거워지는 것은 아닐까? 결국 오래 쓰려면 단순히 좋은 스킬을 가져오는 것보다, 내가 왜 그렇게 쓰는지 이해하고 있어야 했다.

완벽한 스킬은 없었다

AI 코딩 에이전트를 쓰다 보면 한 가지 착각을 하기 쉽다. 좋은 스킬을 잘 붙이면, 구현 후 리뷰에서 구멍이 거의 사라질 것 같다는 기대다.

내 경험은 반대였다. 아무리 잘 만든 스킬처럼 보여도, 코드 구현 후 다시 보면 항상 구멍이 있었다. 입력 검증이 빠져 있거나, 실패 처리가 애매하거나, API 경계가 흔들리거나, 테스트는 통과하지만 실제 consumer path 검증이 부족한 식이다. 어떤 날은 범위가 너무 넓어졌고, 어떤 날은 반대로 중요한 side effect를 충분히 보지 못했다.

그래서 결론이 바뀌었다.

스킬은 정답지가 아니라, 내가 반복해서 놓치는 실패를 줄이기 위한 작업 습관의 압축본이어야 한다.

이 관점으로 보면 “가장 완벽한 스킬”을 찾는 일보다 더 중요한 것이 있다. 내가 실제로 어떤 실패를 반복하는지, 어떤 지시를 매번 손으로 치고 있는지, 어떤 리뷰 기준이 나에게 효과가 있었는지를 기록하고 다듬는 일이다.

 

나는 Codex를 쓰면서 엄청난 양의 토큰을 태웠다. 대략 700억 토큰에 가까운 시행착오를 거치면서, 결국 내게 남은 것은 멋진 프롬프트 문장이 아니라 반복되는 패턴이었다.

  • 작업 전에 사용자의 전제를 그대로 믿지 말 것
  • 작은 변경이라도 ownership boundary를 먼저 볼 것
  • API, DB, UI, worker, crawler의 책임을 섞지 말 것
  • guard 출력은 증거일 뿐, 완료 증명은 아니라고 볼 것
  • 구현 후에는 반드시 diff 기반으로 다시 공격적으로 리뷰할 것
  • 새 경고가 나오면 무한 루프를 돌지 말고, bounded fix 후 남은 리스크를 보고할 것
  • 장기 작업은 대화 history에만 맡기지 말고, 필요한 것만 durable artifact로 남길 것

이런 것들은 남이 만든 스킬을 읽어서 알게 된 것도 있지만, 대부분은 내가 매일 Codex에게 직접 타이핑하던 지시문에서 나왔다.

그래서 jhste-skills를 만들었다

jhste-skills는 내가 AI 코딩 에이전트를 쓰면서 반복적으로 필요했던 작업 규칙을 묶은 작은 kit다. 핵심은 대단한 프레임워크를 만드는 것이 아니라, 내가 실제로 쓰는 워크플로를 여러 PC와 여러 repo에서 같은 방식으로 재현하는 것이다.

구성은 단순하다.

먼저 코드 변경 전에는 jhste-engineering-groundwork로 목표, 범위, failure path, data contract, final behavior predicate를 확인한다. 에이전트가 사용자의 말을 무조건 맞다고 받아들이거나, 옆 범위까지 넓혀서 고치려는 습관을 줄이기 위한 장치다.

코드 변경 후에는 guard를 돌린다. 하지만 guard는 판사가 아니다. guard는 “여기를 사람이 더 봐야 한다”는 신호에 가깝다. 그래서 완료 전에는 jhste-red-team-review로 실제 변경 diff를 다시 본다. 테스트가 통과했다는 사실과, 실제 consumer path가 안전하다는 사실은 다르기 때문이다.

API나 DB 경계를 만질 때는 jhste-db-api-boundary를 쓰고, crawler나 worker류 자동화에는 jhste-crawler-automation을 쓴다. 입력 검증, observable failure, secret-safe logging 같은 것은 jhste-code-quality가 잡아준다. 중요한 점은 이 스킬들이 “SOLID를 지켰는가” 같은 추상 점수를 매기기 위한 것이 아니라, 실제 실패 모드를 줄이기 위한 렌즈라는 점이다.

그리고 최근에는 jhste-long-running-work-loop를 추가했다.

6월 22일 OpenAI 글을 보고 바로 녹인 것

최근 OpenAI에 올라온 Codex-maxxing for long-running work 글을 봤다. OpenAI가 2026년 6월 22일 공개한 글로, Codex를 단발성 프롬프트 도구가 아니라 오래 이어지는 작업 공간으로 다루는 방법을 설명한다. 글의 핵심은 꽤 실용적이었다. durable thread, memory, steering, review, verifiable goal 같은 개념을 통해 긴 작업이 중간에 끊기지 않게 만드는 방식이다.

 

그 글을 보면서 “이건 내 workflow에도 들어가야 한다”고 생각했다. 다만 그대로 길게 복사하고 싶지는 않았다. 긴 thread와 memory는 분명 도움이 되지만, 무턱대고 모든 것을 저장하면 오히려 stale context가 권위처럼 굳는다. 작업 일지를 CONTEXT.md에 계속 쌓아두면 나중에는 문서가 사실인지 추측인지 구분하기 어려워진다.

 

그래서 jhste-long-running-work-loop는 일부러 좁게 만들었다. 이 스킬은 코드 품질을 리뷰하지 않는다. PRD를 다시 쓰지도 않고, issue breakdown이나 handoff를 대체하지도 않는다. 역할은 딱 하나다.

이 일이 장기 작업인지 판단하고, 목표/단계/완료 기준/승인 경계/다음 세션 연결/기록 위치를 정한다.

예를 들어 여러 세션에 걸치는 작업, 반복 리뷰, 외부 CI나 preview deploy 대기, 여러 repo에 영향을 주는 변경, PRD → issue → 구현 → 리뷰 흐름, 되돌리기 어려운 설계 결정이 있을 때만 켜진다. 반대로 단순 Q&A, 오타 수정, formatting-only, 작은 README 수정, 작은 단일 파일 수정에는 쓰지 않는다.

 

기록 위치도 강하게 나눴다.

  • CONTEXT.md: 작업일지가 아니라 glossary/domain context
  • ADR: 되돌리기 어려운 설계 결정
  • issue/PR notes: active work state
  • handoff: 다음 세션 연결
  • 아무 가치 없는 임시 상태: 기록하지 않음

이렇게 한 이유는 간단하다. 장기 작업에는 기억이 필요하지만, 모든 기억이 영구 문서가 되어서는 안 된다.

“남의 스킬”에서 “내 스킬”로 넘어가는 순간

Superpowers나 다른 스킬들이 쓸모없었다는 말은 아니다. 오히려 여러 스킬을 써봤기 때문에 내 기준이 생겼다. Karpathy 스타일의 간결함, Matt Pocock 스킬의 작업 흐름, GSD식 실행 압력, OpenAI의 long-running work 관점에서 배운 것이 있다.

 

하지만 2~3개월 정도 실제로 쓰다 보면 결국 자기만의 루틴이 생긴다. 매번 같은 말을 하고 있다면, 그것은 프롬프트가 아니라 스킬이 되어야 한다. 매번 같은 리뷰 기준을 적용하고 있다면, 그것은 기억에 의존할 것이 아니라 repo와 PC를 넘어 재사용 가능한 형태가 되어야 한다.

 

내가 jhste-skills를 만든 이유가 이것이다.

  • 내 입맛대로 고칠 수 있어야 한다
  • 최신 OpenAI 문서나 Codex 사용 경험을 바로 반영할 수 있어야 한다
  • 여러 PC에서 같은 스킬을 빠르게 업데이트할 수 있어야 한다
  • 각 repo의 AGENTS.md는 길게 오염시키지 않고, 필요한 bridge만 둬야 한다
  • code quality, architecture, review, long-running workflow의 경계를 분리해야 한다

이번에도 그랬다. OpenAI의 long-running work 글을 보고 괜찮다고 판단했고, 바로 jhste-long-running-work-loop로 얇게 녹였다. 릴리즈도 올리고, npm으로 배포하고, 여러 머신에서 바로 업데이트했다. 남이 만든 스킬을 기다리는 것보다, 내가 쓰는 도구를 내가 고치는 쪽이 훨씬 빠르다.

내가 얻은 결론

이제 나는 “완벽한 스킬 묶음”을 찾는 데 시간을 덜 쓴다. 대신 내 작업에서 반복적으로 실패하는 지점을 본다. 그리고 그 실패를 줄이는 최소한의 지시를 스킬로 만든다.

 

좋은 스킬은 모든 일을 대신해주는 마법이 아니다. 좋은 스킬은 에이전트가 자주 틀리는 지점을 줄이고, 사람이 책임져야 할 판단을 더 잘 보이게 만드는 장치다.

 

그래서 내 결론은 이렇다.

누구나 거대한 프롬프트 컬렉션을 가질 필요는 없다. 하지만 AI 코딩 에이전트를 진지하게 오래 쓴다면, 결국 자기만의 스킬은 필요해진다. 남의 스킬을 그대로 쓰는 기간은 학습에는 좋다. 하지만 어느 순간부터는 “내가 매번 타이핑하던 지시문”을 기준으로, 자기 워크플로를 직접 설계해야 한다.

 

나는 그 결과물이 jhste-skills였다.

그리고 아마 앞으로도 계속 바뀔 것이다. Codex가 바뀌고, OpenAI 문서가 바뀌고, 내 실패 패턴도 바뀌기 때문이다. 중요한 것은 한 번 만든 스킬을 신앙처럼 고정하는 것이 아니라, 실제 작업에서 가성비가 떨어지는 부분을 계속 걷어내고 업데이트하는 것이다.

참고 링크

티스토리툴바