에이전트 스킬셋 비교 Part 4: 구현과 검증 — TDD 에서 정면으로 갈린다

이 글은 Claude Opus 5 를 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

Part 3까지는 두 묶음이 다른 방식으로 같은 일 을 하는 것을 봤습니다. 질문 리듬이 다르고, 남기는 것이 다르고, 발동 방식이 달랐습니다.

이번 편은 다릅니다. 같은 실천에 대해 서로 다른 말을 하는 지점 이 나옵니다. TDD 입니다.

1. 구현 — 240줄 vs 15줄#

먼저 규모입니다.

implement 전문이 이렇습니다. 발췌가 아니라 본문 전체 입니다.

Implement the work described by the user in the spec or tickets.

Use /tdd where possible, at pre-agreed seams.

Run typechecking regularly, single test files regularly,
and the full test suite once at the end.

Once done, use /code-review to review the work.

Commit your work to the current branch.

여섯 줄입니다. 그리고 하는 일이 대부분 다른 스킬로 넘기는 것 입니다. /tdd 로 만들고, /code-review 로 검토하고, 커밋합니다.

superpowers 의 subagent-driven-development 는 240줄로 작업마다 새 서브에이전트를 띄우고 2단계 리뷰(명세 준수 → 코드 품질)를 거쳐 다음으로 넘기는 절차를 규정합니다. 자율 실행을 오래 돌리기 위한 장치입니다.

Part 1 의 가설이 여기서 다시 확인됩니다. 한쪽은 에이전트를 오래 맡기려 하고, 다른 쪽은 각 단계를 사람이 열게 합니다. implement 는 disable-model-invocation: true 로 잠겨 있습니다.

2. TDD — 여기서 정면으로 갈립니다#

두 묶음 다 TDD 스킬을 가지고 있습니다. 분량이 371줄과 38줄 입니다. 그런데 진짜 차이는 분량이 아니었습니다.

리팩터링은 루프 안인가 밖인가#

superpowers:

## Red-Green-Refactor

### REFACTOR - Clean Up

After green only:
- Remove duplication
- Improve names
- Extract helpers

리팩터링이 루프의 3단계입니다. 초록이 된 직후에 정리하고, 다음 빨강으로 갑니다.

mattpocock:

Refactoring is not part of the loop. It belongs to the review stage (see the code-review skill), not the red → green implementation cycle.

리팩터링이 루프에 없습니다. 리뷰 단계로 넘깁니다.

같은 실천의 이름을 두고 정반대로 규정합니다. 이건 표현 차이가 아니라 설계 판단의 차이입니다.

flowchart TD
    subgraph MPT["mattpocock — 슬라이스만 반복, 정리는 리뷰에서"]
        direction TB
        M1["RED<br/>실패하는 테스트"] --> M2["GREEN<br/>통과할 만큼만"]
        M2 --> M3["다음 슬라이스"]
        M3 --> M1
        M2 -.->|"루프 종료 후"| M4["code-review<br/>여기서 정리"]
    end
    subgraph SPT["superpowers — 루프 안에서 정리"]
        direction TB
        S1["RED<br/>실패하는 테스트"] --> S2["GREEN<br/>통과할 만큼만"]
        S2 --> S3["REFACTOR<br/>중복 제거 · 이름 개선"]
        S3 --> S1
    end
    style S3 fill:#FF9999,color:#000000
    style M4 fill:#87CEEB,color:#000000
    style M3 fill:#FFD700,color:#000000

어느 쪽이 맞나. 원래의 TDD 서술은 superpowers 쪽에 가깝습니다. Red-Green-Refactor 는 켄트 벡 이래의 표준 표현입니다.

그런데 mattpocock 의 논거도 약하지 않습니다. 에이전트가 루프 안에서 리팩터링을 하면 “통과할 만큼만” 이라는 규율이 흐려집니다. 초록을 만든 직후 정리를 허용하면 그 정리가 어디까지인지 판단해야 하고, 그 판단이 곧 추가 구현으로 새기 쉽습니다. 정리를 리뷰로 미루면 루프는 순수하게 슬라이스만 반복 하게 됩니다.

사람이 아니라 에이전트가 도는 루프라는 점을 감안하면, 판단 여지를 줄이는 쪽이 안전하다는 주장이 성립합니다.

위반했을 때#

superpowers 는 삭제를 명령합니다.

## The Iron Law

NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST

Write code before the test? Delete it. Start over.

No exceptions:
- Don't keep it as "reference"
- Don't "adapt" it while writing tests
- Don't look at it
- Delete means delete

그리고 그 앞에 이 줄이 있습니다.

Thinking “skip TDD just this once”? Stop. That’s rationalization.

mattpocock 의 tdd 에는 이런 규정이 없습니다. 대신 “Red before green” 을 규칙으로 적고, 위반 처리는 언급하지 않습니다.

Part 2 에서 본 구도가 그대로 반복됩니다. 한쪽은 에이전트의 이탈을 실패 모드로 규정하고 문서로 틀어막고, 다른 쪽은 그러지 않습니다.

mattpocock 에만 있는 것 — 이음매 합의#

반대로 superpowers 에 없는 개념이 있습니다.

Test only at pre-agreed seams. Before writing any test, write down the seams under test and confirm them with the user. No test is written at an unconfirmed seam.

어디를 테스트할지 먼저 사용자와 합의하라 는 것입니다. 이유도 적혀 있습니다. 다 테스트할 수는 없으니, 이음매를 미리 정해야 노력이 핵심 경로와 복잡한 로직에 가고 모든 엣지 케이스에 흩어지지 않는다 는 것입니다.

그리고 안티패턴 셋을 정의합니다.

세 번째가 특히 좋습니다. 테스트를 한꺼번에 쓰면 아직 이해하지 못한 구현에 대해 테스트 구조를 먼저 확정하게 되고, 결국 사용자 관점 동작이 아니라 모양 을 검증하게 된다는 지적입니다. 대안으로 수직 슬라이스 를 제시합니다. 테스트 하나 → 구현 하나 → 반복, 각 테스트가 예광탄(tracer bullet) 입니다.

superpowers 의 371줄에도 좋은 테스트에 대한 표가 있지만, “어디를 테스트할지 합의하라” 는 절차적 요구는 없습니다.

정리#

분량이 10배인데 다루는 범위가 넓은 것은 아닙니다. superpowers 는 규율의 강제에 지면을 쓰고, mattpocock 은 테스트 품질의 정의에 지면을 씁니다.

3. 코드 리뷰 — 두 축 vs 두 스킬#

superpowers 는 요청하는 쪽과 받는 쪽을 나눕니다. receiving-code-review 가 213줄로 더 깁니다. 리뷰를 받았을 때 무비판적으로 수용하지도, 방어적으로 거부하지도 말라 는 규율을 다룹니다.

mattpocock 은 축을 나눕니다.

Two-axis review of the diff between HEAD and a fixed point the user supplies:

• Standards: does the code conform to this repo’s documented coding standards?
• Spec: does the code faithfully implement the originating issue / spec?

Both axes run as parallel sub-agents so they don’t pollute each other’s context.

두 축을 별도 서브에이전트로 돌리는 이유가 “서로의 컨텍스트를 오염시키지 않기 위해서” 입니다. 코딩 표준을 보는 눈과 명세 준수를 보는 눈을 섞지 않겠다는 것입니다.

그리고 시작 전에 고정 지점이 실제로 해석되는지, diff 가 비어 있지 않은지 확인 합니다. 이유가 실무적입니다.

A bad ref or empty diff should fail here, not inside two parallel sub-agents.

서브에이전트 두 개를 띄운 뒤에 실패하는 것보다 띄우기 전에 실패하는 게 낫다 는 것입니다. 병렬 실행 비용을 아는 사람이 쓴 문장입니다.

4. 디버깅 — 이름이 다른 같은 규율#

두 스킬은 이 시리즈에서 가장 비슷한 한 쌍 입니다. 둘 다 “추측하지 말고 근본 원인부터” 를 말합니다.

mattpocock 쪽의 첫 국면 서술이 특히 좋습니다.

Phase 1: Build a feedback loop#

This is the skill. Everything else is mechanical. If you have a tight pass/fail signal for the bug (one that goes red on this bug), you will find the cause; bisection, hypothesis-testing, and instrumentation all just consume it. If you don’t have one, no amount of staring at code will save you.

Spend disproportionate effort here. Be aggressive. Be creative. Refuse to give up.

“이 스킬의 전부가 이것이고 나머지는 기계적이다.” 재현 신호를 먼저 만들라는 것인데, 강조 방식이 인상적입니다.

그리고 mattpocock 에만 있는 절이 하나 있습니다. 비밀 값 처리 입니다.

This skill has you show commands, outputs and captured artifacts. Redact every secret first: write <REDACTED> in its place. Build loops against env vars, so the credential stays in the environment rather than in what you show.

디버깅 스킬이 출력물에 자격 증명이 섞여 들어가는 것을 명시적으로 막습니다. 에이전트가 로그와 요청을 그대로 보여 주는 작업이라 실제로 필요한 지침입니다. superpowers 의 systematic-debugging 에는 이 절이 없습니다.

5. superpowers 에만 있는 것 — 완료 검증#

Part 1 의 빈칸 중 하나입니다. verification-before-completion 139줄입니다.

Claiming work is complete without verification is dishonesty, not efficiency.

The Iron Law#

NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE

If you haven’t run the verification command in this message, you cannot claim it passes.

그리고 게이트 함수를 규정합니다. 상태를 주장하기 전에 ① 무슨 명령이 이걸 증명하는가 ② 전체 명령을 새로 실행 ③ 전체 출력과 종료 코드를 읽음 ④ 출력이 주장을 확인하는가 를 거치라는 것입니다.

“이 메시지 안에서 실행하지 않았으면 통과한다고 말할 수 없다” 는 규정이 핵심입니다. 이전 메시지의 결과를 근거로 삼는 것을 막습니다.

mattpocock 쪽에는 이에 대응하는 스킬이 없습니다. implement 가 “타입 검사와 단일 테스트 파일을 자주, 전체 스위트를 마지막에 한 번” 이라고 적을 뿐입니다.

이건 두 묶음의 차이를 잘 보여 주는 빈칸입니다. 에이전트를 오래 자율 실행시킬수록 “다 됐습니다” 라는 거짓 주장의 비용이 커집니다. superpowers 는 그 시나리오를 전제하고 별도 스킬을 만들었고, mattpocock 은 각 단계를 사람이 열기 때문에 그만큼 급하지 않습니다.

6. 이번 편의 정리#

TDD 의 리팩터링 위치가 이 시리즈에서 유일하게 “둘 중 하나는 틀렸다” 고 말할 수 있는 지점입니다. 나머지는 대부분 어느 쪽도 틀리지 않은 절충이었습니다.

그리고 그마저도 누가 루프를 도느냐 를 따지면 판단이 갈립니다. 사람이 돌면 켄트 벡 쪽이 맞고, 에이전트가 돌면 판단 여지를 줄이는 쪽에 일리가 있습니다.

다음 편이 마지막입니다. 두 저자가 README 에서 서로를 반박하는 대목, 외부에서 제기된 “의식 비용” 비판, 그리고 실무에서 무엇을 언제 쓸 것인가를 정리합니다.

References#

1차 자료

• obra/superpowers — https://github.com/obra/superpowers (MIT). test-driven-development, requesting-code-review, receiving-code-review, systematic-debugging, verification-before-completion, subagent-driven-development
• mattpocock/skills — https://github.com/mattpocock/skills (MIT). tdd(+tests.md,mocking.md), implement, code-review, diagnosing-bugs
• 인용문은 모두 로컬 설치본(superpowers v4.0.3, mattpocock-skills v1.2.3)의 원문이며, 한국어 설명은 인용이 아니라 해설입니다.

측정값

• 줄 수는 wc 실측, 호출 토큰은 claude plugin details 의 추정치입니다.

밝혀 둘 것

• 2절의 “어느 쪽이 맞나” 는 필자의 판단 이며 두 저장소 어느 쪽도 상대를 지목해 반박하지 않았습니다. 원문에 있는 것은 각자의 규정뿐입니다.

시리즈

• Part 1: superpowers 와 mattpocock/skills 의 지형도
• Part 2: 자동 활성은 셸 스크립트 한 개였다
• Part 3: 계획 단계 — 한 질문씩 vs 프론티어, 그리고 없는 프로토타입