최신 AI 에이전트 스킬 21선 2편, 코드를 대신 시키고 검증을 맡기는 세 가지

1편에서 스킬이 뭔지까지 봤다. 2편은 코딩 쪽이다. 에이전트한테 코드를 맡길 때 쓰는 세 가지 스킬을 넣었다. 하나는 코드를 아예 대신 시키는 스킬, 하나는 고친 내용을 남한테 검증을 맡기는 스킬, 하나는 테스트를 먼저 짜게 하는 스킬이다.

셋이 서로 이어져 있다. 순서가 코드를 맡기고, 검증을 받고, 다음엔 테스트를 먼저 짜게 한다.

1. delegate-coding

software-development 카테고리. 설명이 강제로 시작한다.

Delegate ALL code writing/editing to the configured API cloud agent via delegate_task.
Use when the user asks to: write code, create a script, edit code, fix code, implement a feature

설명 첫 글자가 Delegate ALL이다. 보통 스킬은 "Use when..."으로 시작하는데 이건 예외다. 그리고 본문 첫 줄이 이 스킬의 전부다.

You MUST NOT write code yourself. Delegate every coding task to the configured API cloud agent.

이게 왜 의외냐면

에이전트에게 "이거 만들어"라고 시키면 기본 동작은 자기가 코드를 쓰는 거다. 이 스킬은 그 기본 동작을 금지한다. 요청이 코드로 끝나는 순간 무조건 남한테 넘긴다.

1. delegate_task 호출
   - task: 파일 경로, 요구사항, 기대 동작까지 포함한 전체 요청
   - context: 관련 저장소 경로와 제약
2. 위임 결과 대기
3. 위임된 에이전트가 코드를 쓰고 반환 → 나는 중계와 검증만
   (파일 존재 확인, 요청하면 실행)
4. 위임 실패 시 정직하게 보고. 절대 직접 작성으로 폴백하지 않는다

금지 항목이 이 스킬의 진짜 내용

- 코드 내용을 직접 답에 쓰지 않는다
- write/edit 도구를 코드 파일에 쓰지 않는다
- 디스크에 존재를 확인하기 전 "저장했다"고 말하지 않는다

마지막 항목이 실전에서 제일 자주 어긋난다. 에이전트가 파일을 못 썼는데 "완료했습니다"라고 말하는 경우가 있다. 나도 그랬다. 이 스킬은 그런 거짓말을 구조적으로 막는다.

2. delegate-debugging (v2.0.0)

제목이 곧 정의다.

Delegate Debugging (수행은 로컬, 검증은 위임)

버그가 났을 때 뭘 남에게 맡기느냐가 이 스킬의 설계다. 고치는 건 직접 하고, 검사만 위임한다.

1. systematic-debugging 원본 스킬을 먼저 읽는다
2. 수행은 네가 직접 한다
   원인 조사 → 가설 → 최소 수정 → 재현 명령어로 검증까지 로컬에서
3. 검증은 반드시 위임한다
4. 판정이 "보완 필요"면 반영 후 재위임 (최대 2회)
   "통과"면 원인 + 수정 + 판정을 함께 보고

왜 수정과 검증을 분리하나

같은 에이전트가 고치고 같은 에이전트가 검사하면 자기 수정을 정당화한다. 버그를 만든 쪽과 버그를 잡는 쪽의 시각이 같으면 안 된다. 그래서 고치는 건 로컬 모델로 하고 검사는 API 클라우드 에이전트에 맡긴다. 서로 다른 모델이 다른 판단을 한다.

위임할 때 넘기는 것

- 원본 에러/증상 전문
- 네가 파악한 근본 원인
- 수정 diff (파일 경로 + 변경 내용)
- 재현·검증 명령어와 그 실행 결과

그리고 검사 에이전트에게 물어야 할 질문이 정해져 있다.

- 원인 진단이 맞는가
- 수정이 최소·정확한가
- 놓친 엣지케이스·회귀 위험이 있는가
- 최종 판정: 통과 / 보완 필요

재위임이 최대 2회로 묶여 있는 것도 의미가 있다. 두 번을 넘어가면 그건 검증이 아니라 무한 수정이다.

3. test-driven-development (v1.1.0)

software-development 카테고리. obra/superpowers에서 가져와 적응한 스킬이다.

TDD: enforce RED-GREEN-REFACTOR, tests before code.

핵심 원칙이 한 문장에 박혀 있다.

Write the test first. Watch it fail. Write minimal code to pass.

If you didn't watch the test fail, you don't know if it tests the right thing.

번역하면 이렇다. 테스트를 먼저 써라. 그 테스트가 실제로 실패하는 걸 지켜라. 그러고 나서 통과할 만큼만 코드를 써라. 실패하는 걸 안 봤으면 그 테스트가 진짜 원하는 걸 검사하는지 알 수 없다.

여기에 덧붙는 문장이 하나 더 있다.

Violating the letter of the rules is violating the spirit of the rules.

규칙의 글자를 어기면 규칙의 정신도 어긴다. 테스트를 먼저 썼지만 검증 없이 통과시켜 버리면 글자는 지켰어도 정신은 어긴 거다. 에이전트가 "테스트 작성 완료, 통과함"이라고 보고하는데 그게 통과인지 우연인지 구분을 못 하는 상태가 여기 해당한다.

적용 범위가 넓다

- 신규 기능
- 버그 수정
- 리팩토링
- 동작 변경

Always:로 시작한다. 예외가 없다. 심지어 버그 수정에도 TDD를 요구한다. 버그를 테스트로 먼저 고정해 놓고 그 테스트가 실패하는 걸 보고 그다음 고치는 순서다. 이게 버그 재발을 막는 유일한 방법이다.

이번 편 정리

앞으로는 3편에서 버그를 잡는 순서와 파이썬·노드를 붙잡는 도구 쪽으로 넘어간다.