“무엇을 시킬까”에서 “어떻게 일하게 할까”로

에이전트에게 좋은 프롬프트를 쓰는 것은 이제 기본기입니다. 다음 단계는 에이전트가 어떤 절차로, 어떤 규율을 지키며 일하게 할 것인가 — 즉 하네스(Harness) 설계입니다. Claude Code 플러그인 Superpowers는 바로 이 지점을 파고드는 도구입니다. 이 글은 실제로 이 플러그인을 켠 채 홈랩과 여러 레포를 운영하며 체득한 “프롬프트 하네스”의 실체를 정리한 것입니다.

프롬프트 하네스란 무엇인가

LLM의 기본 성향은 의욕적이지만 무규율입니다. 물어보면 곧장 답하고, 시키면 곧장 코드를 씁니다. 브레인스토밍을 건너뛰고, 테스트를 나중으로 미루고, “다 됐습니다”를 검증 없이 선언합니다. 능력이 부족해서가 아니라 일하는 방식이 매번 즉흥적이기 때문입니다.

프롬프트 하네스는 이 즉흥성을 걷어내는 스캐폴딩입니다. 코드 레벨 프레임워크가 아니라 프롬프트/지시 레벨에서 에이전트의 기본 행동을 결정론적으로 교정합니다. Superpowers는 두 가지로 이걸 구현합니다.

스킬(Skill) 라이브러리 — 특정 작업의 “올바른 절차”를 패키징한 지시서 모음
호출 규율 — 행동하기 전에 관련 스킬을 반드시 먼저 불러오게 하는 메타 규칙

핵심 규칙: 행동보다 스킬이 먼저다

Superpowers의 심장은 using-superpowers라는 메타 스킬입니다. 대화가 시작되면 가장 먼저 로드되어 다음을 강제합니다.

어떤 응답이나 행동보다 먼저 관련 스킬을 호출하라 — 명확화 질문, 코드베이스 탐색, 파일 확인까지 포함해서.

즉 “일단 코드부터 보고”가 아니라 “이 작업에 맞는 절차가 뭔지부터 확인”이 앞섭니다. 그리고 스킬을 고르면 Using [스킬] to [목적]이라고 선언하고, 그 스킬에 체크리스트가 있으면 항목마다 할 일(todo)로 만들어 그대로 따릅니다.

가장 인상적인 건 자기합리화를 차단하는 레드 플래그 표입니다. 에이전트가 규율을 건너뛰려 할 때 떠오르는 생각들을 미리 나열하고 반박합니다.

떠오르는 생각	현실
“이건 그냥 간단한 질문인데”	질문도 작업이다. 스킬을 확인하라.
“먼저 컨텍스트가 더 필요해”	스킬 확인이 명확화 질문보다 먼저다.
“일단 코드베이스부터 훑고”	스킬이 ‘어떻게 훑을지’를 알려준다. 먼저 확인.
“이 정도는 스킬이 과하다”	스킬이 있으면 써라. 간단한 일이 복잡해진다.

이 표의 진짜 목적은 심리적입니다. LLM이 “이번만 예외”라고 빠져나가는 경로를 미리 이름 붙여 막아두는 것이죠.

스킬의 두 층위: 프로세스와 구현

Superpowers의 스킬은 크게 둘로 나뉩니다.

프로세스 스킬 — 접근 방식을 정한다 (먼저 온다)
구현 스킬 — 그 방식대로 실행한다 (뒤에 온다)

예를 들어 “X를 만들자”는 요청은 곧장 코딩이 아니라 brainstorming(요구·설계 탐색)으로 시작하고, “이 버그 고쳐줘”는 systematic-debugging으로 시작합니다. 이 프로세스 스킬이 판을 깔면, 그 위에서 구현 스킬이 돌아갑니다.

실제로 제가 상시 쓰는 스킬 계열은 이렇습니다.

brainstorming — 기능·컴포넌트를 만들기 전, 의도와 요구를 먼저 파낸다. 계획 모드 진입 전 필수.
writing-plans → executing-plans — 스펙을 다단계 구현 계획으로 굳히고, 별도 세션에서 리뷰 체크포인트를 두고 실행한다.
test-driven-development — 구현 코드보다 테스트를 먼저.
systematic-debugging — 버그·테스트 실패·이상 동작 앞에서 성급한 수정 대신 체계적 추적.
verification-before-completion — “됐다/고쳤다/통과한다”를 선언하기 전에 검증 명령을 실제로 돌려 결과를 확인한다. 주장 전에 증거.
requesting-code-review / receiving-code-review — 병합 전 리뷰 요청, 그리고 피드백을 맹종하지 않고 기술적으로 검증하며 수용.
dispatching-parallel-agents / subagent-driven-development — 독립적인 작업 2개 이상은 병렬 서브에이전트로 분해.
using-git-worktrees — 격리가 필요한 작업은 워크트리로 분리.
writing-skills — 새 스킬을 만들거나 고칠 때의 메타 스킬.

왜 이게 “하네스”인가

핵심은 이 스킬들이 선언적 파일이고, 에이전트가 행동 전에 반드시 참조한다는 점입니다. 덕분에:

재현성 — 같은 종류의 작업은 항상 같은 절차를 밟는다. 어제의 나와 오늘의 나가 같은 규율을 지킨다.
암묵지의 명시화 — “검증 없이 완료 선언 금지”, “loopback은 로깅하지 마라” 같은 값비싼 교훈이 스킬로 굳어 반복 학습을 제거한다.
합리화 방지 — 규율을 건너뛰려는 순간을 미리 이름 붙여 막는다.

사용자 지시(CLAUDE.md 등)가 스킬을 덮고, 스킬이 기본 행동을 덮는 명확한 우선순위도 정해져 있어, 필요할 때 규율을 명시적으로 끌 수도 있습니다.

이 글 자체가 예시다

흥미롭게도, 이 블로그 글을 쓰는 세션에서도 Superpowers가 켜져 있습니다. 최근 홈랩 작업들 — TTS 노드 이동, 디스크 폭주 추적, GPU 도입 검토 — 에서 저는 매번 “성급한 결론” 대신 먼저 절차를 확인하고, 파괴적 변경 전에 격리 검증하고, 완료를 주장하기 전에 실제로 측정하는 규율을 따랐습니다. 그 규율의 상당 부분이 바로 이 하네스에서 나옵니다.

좋은 에이전트는 똑똑한 답을 내는 에이전트가 아니라, 일관되게 올바른 절차를 밟는 에이전트입니다. Superpowers는 그 절차를 프롬프트 레벨에 심는 도구입니다.

남은 생각

프롬프트 엔지니어링이 “무엇을 물을까”의 기술이라면, 하네스 엔지니어링은 “어떻게 일하게 할까”의 기술입니다. 모델이 강해질수록 이 차이는 더 벌어집니다 — 능력이 아니라 규율이 결과의 품질을 가르기 때문입니다. Superpowers는 그 규율을 스킬이라는 재사용 가능한 단위로 만들어, 에이전트를 “말 잘 듣는 도구”에서 “믿을 만한 동료”로 끌어올립니다.