코드 리뷰 대신 문서 리뷰: Old Coder 스킬 활용법

Old Coder 스킬이 실제로 변경하는 것

Old Coder 스킬은 코드 리뷰를 문서 리뷰로 대체합니다. 코딩 에이전트는 코드를 작성하기 전에 먼저 SPEC을 작성하며, 사용자가 해당 문서를 승인해야만 구현을 시작합니다. 이후 에이전트는 gauntlet이라 불리는 고정된 자동화 검사 스택을 통해 자신의 작업을 실행하고, 정확한 명령어와 실제 수치가 담긴 EVIDENCE 보고서를 사용자에게 전달합니다. 사용자는 두 개의 문서를 읽을 뿐, diff를 직접 읽지는 않습니다.

이러한 방식은 두 문서가 기존의 diff가 가졌던 신뢰를 담보할 때만 유효합니다. SPEC은 코드가 존재하기 전에 사용자가 승인하므로, 에이전트가 이미 작성한 코드에 맞춰 내용을 조작할 수 없어 신뢰를 얻습니다. EVIDENCE 보고서는 보고서 내의 모든 수치가 사용자가 직접 실행하여 동일한 결과를 확인할 수 있는 명령어에서 도출되므로 신뢰를 얻습니다. 만약 두 부분 중 하나라도 허술해지면, 리뷰를 리뷰의 요약본으로 대체하는 꼴이 됩니다. 이는 완료된 것처럼 느껴지기 때문에 diff를 읽는 것보다 더 위험합니다.

이 스킬은 일반적인 markdown 형식이므로 Claude Code, Codex CLI, Cursor 또는 사용자가 직접 만든 루프 등 서면 지침을 따르는 모든 에이전트와 함께 사용할 수 있습니다. 이 스킬은 Ponytail lazy senior developer persona 스킬과 같은 계열에 속합니다. 파일 형식이 생소하다면 에이전트 스킬의 정의와 에이전트가 이를 로드하는 방식에서 관련 메커니즘을 확인할 수 있습니다.

SPEC은 사용자가 직접 결정하는 유일한 요소입니다

SPEC은 코드가 작성되기 전에 작성되는 테스트 계획입니다. 기술 파일에는 다음 네 가지 항목이 포함되어야 합니다.

• 구체적인 시나리오: 입력값, 예상 출력값, 경계 사례, 오류 사례. divide(1, 0) raises ZeroDivisionError with message X와 같이 명시해야 하며, "잘못된 입력을 처리함"과 같이 모호하게 작성해서는 안 됩니다.
• 부정적 제약 조건: 기존 테스트나 공개 API 서명과 같이 변경되어서는 안 되는 사항입니다.
• 설정 계획: 모든 도구와 새로운 의존성 항목을 나열하고, 각 항목이 왜 필요한지 한 줄로 설명합니다.
• 절대 파일 경로: 파일을 찾기 위해 헤맬 필요가 없도록 절대 경로를 명시합니다.

설정 계획은 모델의 학습 데이터 차단 시점이 드러나는 부분입니다. 메모리에서 불러온 도구나 고정된 버전은 약 1년 정도 지난 것일 수 있으므로, 에이전트에게 웹 검색을 위한 자체 호스팅 SearXNG 인스턴스를 제공하여 제안하기 전에 최신 버전을 확인하도록 하는 것이 좋습니다.

SPEC을 승인한 뒤 커밋하십시오. 승인 후 수정할 수 있는 SPEC은 계약서가 아니며, 커밋은 나중에 증거가 사용자가 서명한 내용에 따라 측정되었는지 확인할 수 있게 해줍니다.

이것은 사용자에게 남은 유일한 예/아니오 결정이며, 이것이 핵심이자 위험 요소입니다. 프로덕션 환경에 대한 변경 사항처럼 취급하십시오. 실제로도 그렇기 때문입니다. 이미 에이전트 작업 앞에 명시적인 승인 단계를 운영하고 있다면, SPEC 승인 절차를 워크플로의 동일한 위치에 배치하면 됩니다.

EVIDENCE 보고서: 명령어가 포함된 수치

EVIDENCE 보고서는 작업의 마지막에 확인하는 결과물입니다. 이 기술을 활용하려면 각 사양의 동작을 검증하는 테스트에 매핑하고, 각 가운틀(gauntlet) 계층을 실행한 명령어와 실제 결과로 보고해야 합니다. 모든 수치는 마지막 코드 수정 이후 새로 실행한 결과여야 하며, 건너뛴 계층은 그 이유를 명시해야 합니다. 형용사는 증거가 될 수 없습니다. "50개의 테스트가 모두 통과되었으며, 커버리지는 49/49 문장입니다"는 결과이지만, "잘 테스트됨"은 결과가 아닙니다.

저장소의 데모 보고서인 demo-rate-limiter/evidence.md은 소스 상태를 커밋과 sha256 트리 해시로 식별합니다. 이 정보는 해당 수치를 생성한 정확한 바이트를 알려주기 때문에 매우 중요합니다. 이 정보가 없으면 보고서는 더 이상 존재하지 않는 작업 트리를 설명하는 상태가 될 수 있습니다. 데모는 이러한 드리프트 현상을 보여줍니다. 커밋 acc5a89에서 보고서는 소스 상태 8b88bda과 41개의 통과된 테스트를 명시했습니다. 2026년 10월 12일 기준 main에서는 커밋 42528d9, 트리 해시 5aa96ec5487c957c, 그리고 50개의 통과된 테스트를 명시하며, 커버리지는 49/49 문장 및 20/20 분기로 변함없음을 보여줍니다.

보고서의 신뢰성을 유지하기 위해 세 가지 부정 방지 규칙을 준수해야 하며, 기술 파일은 이를 절대적인 원칙으로 규정합니다. 테스트를 통과시키기 위해 테스트를 약화하지 마십시오. 단언(assertion)을 완화하거나 허용 오차를 높여서는 안 됩니다. 테스트 통과를 위해 테스트와 구현을 같은 단계에서 수정하지 마십시오. 동시에 수정하면 어느 쪽이 잘못되었는지 알 수 없기 때문입니다. 실행하지 않은 계층을 보고하지 마십시오. "건너뜀, 도구 없음, 대신 수동 변이 수행"과 같이 기록하면 신뢰를 유지할 수 있지만, 조작된 결과는 전체 체계를 무너뜨립니다.

스킬 설치 및 설치한 커밋 고정

저장소는 AmazingAng/old-coder이며 MIT 라이선스를 따릅니다. README에는 skills CLI를 통한 한 줄 설치 명령어가 나와 있습니다. 현재 저장소에는 HTTP 및 JSON API 설계를 위한 두 번째 스킬인 old-coder-api도 포함되어 있으므로, 명령어에 스킬 이름을 명시해야 합니다.

npx skills add https://github.com/amazingang/old-coder --skill old-coder

이 명령은 실행 시점에 main이 가리키는 버전을 설치하며, CLI 자체도 계속 변경됩니다. 스킬이 활성화되었다고 가정하기 전에 파일이 어디에 설치되었는지 확인하십시오.

ls ~/.claude/skills/old-coder/

SKILL.md 파일과 references/ 디렉터리가 보여야 합니다. 아무것도 없다면 Claude Code가 스킬을 찾을 수 있는 위치에 설치되지 않은 것입니다. skills CLI는 에이전트별로 설치됩니다. Claude Code의 전역 경로는 ~/.claude/skills/인 반면, ~/.agents/skills/은 Codex와 같은 다른 에이전트의 경로입니다. 따라서 그곳에만 설치된 스킬은 디스크에는 존재하지만 Claude Code는 불러오지 못합니다. npx skills@latest add ...을 실행하면 오래된 캐시 버전의 CLI를 사용하지 않게 됩니다.

설치한 내용을 기록할 수 있도록 수동 경로 방식을 권장합니다.

git clone https://github.com/AmazingAng/old-coder.git
cd old-coder
git checkout acc5a89
git rev-parse HEAD
mkdir -p ~/.claude/skills
cp -r skills/old-coder ~/.claude/skills/

acc5a89는 2026년 8월 17일 기준 main의 최신 커밋이었습니다. main는 그 이후 이동하여 2026년 8월 18일에는 a0eb529가 되었으며, 이는 2026년 10월 12일까지도 최신 상태를 유지했습니다. 직접 원하는 버전을 선택하고 기록해 두십시오. 저장소는 활발하게 개발 중이며, gauntlet 참조, 템플릿, 검증 프로토콜은 이미 파일 간에 이동되었습니다. EVIDENCE 보고서에 어떤 버전의 스킬로 평가했는지 명시하지 않으면, 코드 변경으로 인한 결과인지 규칙 변경으로 인한 결과인지 구분할 수 없습니다. 해당 커밋 해시를 SPEC 옆에, 그리고 그 규칙이 적용되는 코드와 동일한 저장소에 저장하십시오.

~/.claude/skills을 읽지 못하는 에이전트의 경우, 시스템 프롬프트나 규칙 파일에 skills/old-coder/SKILL.md 및 skills/old-coder/references/gauntlet.md을 추가하십시오. 이것으로 통합 과정이 완료됩니다.

Gauntlet 내부에서 실행되는 작업

Gauntlet은 스택 형태의 계층으로 구성되며, 모든 사양 동작이 정상(green)일 때 한 번씩 실행됩니다. 각 단계의 명칭은 다음과 같습니다.

• 전체 테스트 스위트: 회귀 테스트를 수행합니다. 새로운 실패가 없어야 하며, 기존 실패 항목은 사전에 기준선(baseline)으로 기록합니다.
• 정적 타입 검사, 린트(lint), 포맷팅: 버그 클래스 전체를 방지하고 코드 스타일의 이탈을 막습니다.
• 변경된 코드 줄에 대한 커버리지: 임계값을 충족하지 못하면 0이 아닌 종료 코드를 반환해야 합니다.
• 뮤테이션 테스트(Mutation testing): 아무것도 검증하지 않는 테스트를 찾아냅니다.
• 속성 기반 테스트(Property-based tests): 예상치 못한 엣지 케이스를 탐색합니다.
• 복잡도 예산, 실제 프로그램의 1회 실행, 공급망 및 보안 비밀 스캔, 무작위 순서의 스위트 상태 점검.
• 작업의 위험도에 따라 선택된 도메인 계층: 동시성 스트레스 테스트, API 호환성, 롤백 리허설, 지연 시간 벤치마크.

데모에서는 이 작업들을 demo-rate-limiter/tools/gauntlet.sh 스크립트로 묶어 requirements-dev.txt에 고정된 툴체인 환경에서 실행합니다. pytest, pytest-cov, coverage, hypothesis, mypy, ruff, pip-audit, pytest-randomly가 포함되며, 각 도구는 정확한 버전(2026년 10월 기준 pytest 9.1.1, ruff 0.16.0)으로 고정되어 있습니다. 다음 명령으로 실행하십시오:

cd demo-rate-limiter
python3 -m venv .venv && .venv/bin/pip install -r requirements-dev.txt -e .
./tools/gauntlet.sh

스크립트는 === tests + coverage ===이나 === mutation ===와 같은 배너를 계층별로 출력하며, 마지막에 === gauntlet: all layers green ===을 출력합니다. 이 스크립트는 set -e 환경에서 실행되므로, 첫 번째로 실패하는 계층에서 즉시 중단되며 마지막 배너는 출력되지 않습니다. 마지막 배너를 확인하는 것이 곧 검증입니다. 이는 상위의 모든 계층이 0을 반환하며 종료되었음을 의미합니다. 이것이 acc5a89에서 스크립트가 읽히는 방식입니다. 현재 main에서는 각 계층이 run_layer 헬퍼를 통해 실행되므로, 배너에 === tests-coverage ===과 같은 계층 ID가 포함됩니다. 또한, 예상된 계층이 실행되지 않으면 종료 단계에서 실패 처리되므로, 건너뛴 계층이 조용히 통과하는 일은 발생하지 않습니다.

스크립트에서 여러분의 환경으로 복사해둘 만한 세부 사항이 하나 있습니다. 커버리지 계층은 다음과 같이 작성됩니다:

pytest -q --cov=ratelimiter --cov-report=term-missing --cov-fail-under=100

--cov-fail-under가 없으면, pytest --cov은 커버리지 수치가 아무리 떨어져도 백분율을 출력하고 0을 반환하며 종료됩니다. 이는 첫 번째 실패 시 중단되어야 하는 스크립트 내부에서 실패를 허용(fail-open)하는 계층이 됩니다. 실패할 수 없는 Gauntlet 계층은 장식에 불과합니다.

뮤테이션 테스팅이 커버리지보다 나은 점

커버리지는 테스트 스위트가 해당 라인을 실행했는지 여부만 알려줍니다. 하지만 실제로 중요한 것은 해당 라인이 잘못되었을 때 단언문(assertion)이 실패하는지 여부입니다. 함수를 호출하기만 하고 아무것도 검증하지 않는 테스트도 실행된 모든 라인에 대해 100% 커버리지를 보고합니다. 커버리지는 테스트되지 않은 코드를 찾아낼 뿐, 아무것도 검증하지 않는 테스트는 찾아내지 못합니다.

뮤테이션 테스팅은 이 두 번째 질문에 직접 답합니다. 코드를 의도적으로 조금씩 수정하며 테스트 스위트를 반복 실행합니다. 테스트가 실패하면 뮤턴트(mutant)가 제거(killed)된 것으로 간주하며, 이는 특정 단언문이 해당 동작을 감시하고 있음을 의미합니다. 테스트가 여전히 통과한다면 뮤턴트가 살아남은 것입니다. 즉, 라인은 실행되었지만 결과값을 검증하는 장치가 없다는 뜻입니다.

데모에서는 tools/mutants.py를 사용하여 이를 수행합니다. src/ratelimiter/__init__.py에 번호가 매겨진 단일 수정 사항을 삽입하고, 매번 pytest를 실행한 뒤 파일을 복구합니다. 수정 사항은 사람이 피로할 때 흔히 저지르는 실수들입니다. 예를 들어 >=가 >로 바뀌거나, 반환값이 누락되는 식입니다.

이 러너(runner)에서 가장 중요한 규칙은 제거(kill) 판정입니다. 직접 만든 뮤테이션 스크립트에서 가장 흔히 실수하는 부분입니다. 오직 pytest의 종료 코드 1만 제거로 간주해야 합니다. 코드 1은 테스트가 실행되었고 최소 하나 이상이 실패했음을 의미하기 때문입니다. 종료 코드 0은 뮤턴트가 살아남았음을 의미합니다. 그 외의 코드(수집 오류나 테스트 미발견 등)는 아무것도 검증되지 않았음을 뜻하므로 제거 수치에 포함해서는 안 됩니다. "0이 아닌 모든 값"을 제거로 처리하는 스크립트는 자신의 충돌조차 성공으로 기록하게 되며, 결과 수치는 무의미하게 상승하기만 합니다.

같은 파일에는 두 가지 더 정직한 세부 사항이 있습니다. M11이라는 뮤턴트는 목록에서 제외되는데, 이는 등가(equivalent) 뮤턴트이기 때문입니다. 모든 만료 항목을 삭제하는 대신 하나만 삭제해도 단조 시계(monotone clock) 환경에서는 동일한 동작을 보이므로, 어떤 테스트로도 이를 제거할 수 없습니다. 또한 러너는 PYTHONDONTWRITEBYTECODE=1을 설정하고 가운틀렛(gauntlet)은 __pycache__을 먼저 삭제합니다. 동일한 시간에 작성된 동일한 크기의 두 뮤턴트가 캐시된 .pyc을 공유하여, 두 번째 뮤턴트가 첫 번째 뮤턴트의 판정을 그대로 물려받을 위험이 있기 때문입니다.

이러한 위험 때문에 가운틀렛은 실제 뮤테이션을 수행하기 전에 음성 대조군(negative control) 테스트를 먼저 실행합니다.

.venv/bin/python tools/mutants.py --negative-control
.venv/bin/python tools/mutants.py

대조군은 수정 시간을 고정한 상태에서 두 개의 뮤턴트를 실행합니다. 하나는 반드시 제거되어야 하고, 다른 하나는 엄격히 등가이므로 반드시 살아남아야 합니다. 만약 둘 다 제거된 것으로 나온다면 바이트코드 캐시가 실행 간에 유출된 것이며, 보고서의 모든 제거 수치는 부풀려진 것입니다. 이는 검증 도구 자체를 검증해야 한다는 기술의 원칙을 구체화한 것입니다. pytest와 mypy는 수년간의 검증을 통해 실패 동작을 신뢰할 수 있게 되었습니다. 지난주에 작성한 스크립트는 그렇지 않으므로, 통과했을 때 신뢰하기 전에 먼저 실패할 수 있음을 증명하고 그 증거를 EVIDENCE에 기록하십시오.

[
  {
    "label": "Scenario tests",
    "mutants_killed": 22,
    "mutants_run": 22
  },
  {
    "label": "Property tests",
    "mutants_killed": 3,
    "mutants_run": 22
  }
]

데모의 EVIDENCE 보고서는 단일 집계 수치가 어떻게 진실을 가리는지 보여줍니다. 시나리오 스위트는 22개의 뮤턴트 중 22개를 제거했습니다. 속성 기반 테스트(property-based tests)만 따로 떼어 같은 뮤턴트를 대상으로 실행했을 때는 3개를 제거했습니다. 제거 판정은 가장 먼저 실패한 테스트에 귀속되므로, 완벽한 총합은 스위트 전체의 유효성을 입증할 뿐 내부의 각 계층에 대해서는 아무것도 말해주지 않습니다. 속성 기반 테스트는 사람이 미처 열거하지 못한 입력 형태를 잡아내므로 여전히 제 역할을 합니다. 하지만 이들이 정확성을 전적으로 책임지는 것은 아니며, 각 계층을 개별적으로 측정해야만 그 사실을 알 수 있습니다.

노트북이 아닌 서버에서 gauntlet 실행하기

EVIDENCE 보고서는 특정 명령어가 특정 수치를 생성했다는 주장입니다. 이 주장은 다른 사람이 동일한 수치를 재현할 수 있을 때만 검증 가능하며, 노트북은 이를 시도하기에 가장 부적합한 환경입니다. 사용 중인 Python의 패치 버전이 다를 수 있고, PATH에는 다음 기기에는 없을 도구들이 포함되어 있기 때문입니다. Mutation testing은 뮤턴트 하나당 전체 테스트 스위트를 다시 실행하므로 상황을 더 악화시킵니다. 따라서 데모의 목록만으로도 22만큼의 추가 스위트 실행이 필요합니다.

VPS의 컨테이너 안에서 실행하십시오. 컨테이너는 운영 체제와 인터프리터를 고정하고, 고정된 requirements-dev.txt는 도구를 통일하며, VPS는 브라우저가 실행되지 않는 독립된 환경을 제공합니다.

FROM ubuntu:24.04
RUN apt-get update && apt-get install -y --no-install-recommends \
      python3 python3-venv git ca-certificates \
 && rm -rf /var/lib/apt/lists/*
WORKDIR /work

docker build -t gauntlet:24.04 .
docker run --rm -v "$PWD:/work" -w /work/demo-rate-limiter gauntlet:24.04 \
  sh -c 'python3 -m venv .venv && .venv/bin/pip install -r requirements-dev.txt -e . && ./tools/gauntlet.sh'

정상적인 실행은 === gauntlet: all layers green ===으로 종료됩니다. 두 단계에서 외부 네트워크 연결이 필요합니다. 고정된 도구를 설치하는 pip 과정과, 의존성 취약점을 서비스와 대조하는 pip-audit 계층입니다. 오프라인 실행 시 이 계층을 조용히 건너뛰지 않습니다. 게이트로서 기대하는 동작대로 실패를 반환합니다.

모든 푸시마다 실행하려면 동일한 스크립트를 CI 작업 단계로 구성하십시오. 저장소는 ubuntu-latest의 GitHub Actions에서 Python 3.12를 사용하여 자체 gauntlet을 실행하며, 이는 main으로의 푸시와 풀 리퀘스트에 의해 트리거됩니다. runs-on을 자체 호스팅 러너(self-hosted runner)로 지정하면 작업이 VPS에서 실행됩니다. 이때 pull_request 트리거는 제외하십시오.

name: gauntlet
on:
  push:
    branches: [main]
jobs:
  gauntlet:
    runs-on: self-hosted
    defaults:
      run:
        working-directory: demo-rate-limiter
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: '3.12'
      - run: python -m venv .venv && .venv/bin/pip install -r requirements-dev.txt -e .
      - run: ./tools/gauntlet.sh

직접 관리하는 브랜치로의 푸시에만 트리거를 유지하십시오. 포크된 풀 리퀘스트를 빌드하는 자체 호스팅 러너는 서버에서 타인의 코드를 러너의 권한으로 실행하게 됩니다. 에이전트 자체도 마찬가지입니다. 워크스테이션 대신 폐기 가능한 VM을 사용하십시오. gauntlet 결과를 변경 사항이 논의되는 곳으로 전달하려면 자체 호스팅 PR 리뷰 에이전트를 연결하십시오.

이 접근 방식이 실패하는 경우

첫 번째 실패는 구조적인 문제이며, 어떤 도구를 사용하더라도 해결되지 않습니다. gauntlet은 SPEC의 제약 조건을 실행 가능한 증거로 변환할 뿐입니다. SPEC이 올바른지 여부는 판단할 수 없습니다. 잘못된 요구 사항을 인코딩한 SPEC을 승인하면, 잘못된 프로그램에 대해 완벽한 EVIDENCE 보고서를 얻게 됩니다. 전체 커버리지, 모든 뮤턴트 제거, 모든 계층의 통과 상태를 확인하더라도, 결과물은 원하지 않는 동작을 수행하는 소프트웨어가 됩니다. diff를 읽지 않아 절약한 모든 시간은 SPEC을 검토하는 데 투자해야 합니다.

두 번째는 체커(checker)의 문제입니다. 저장소는 자체 증거 파일에서 이 사실을 솔직하게 밝히고 있습니다. 독립적인 검증 프로토콜은 6라운드에 걸쳐 실행되었으나, 6라운드에서 failed를 반환했습니다. 해당 라운드 이후에 이루어진 수정 사항은 재검증되지 않았으므로, 배포되는 상태는 전체 구간에 대해 검증된 것이 아닙니다. shell lint 계층은 통과가 아닌 사용할 수 없는 상태로 기록되어 있습니다. 초기 라운드에서는 실제 동작상의 결함과 이미 녹색(통과)으로 보고된 상태 뒤에 숨겨진 불완전한 뮤테이션 러너가 발견되었습니다. 녹색 gauntlet이 스스로를 인증하지는 않습니다.

세 번째는 범위의 문제입니다. 수동으로 작성된 뮤턴트 목록은 누군가가 심어두겠다고 생각한 버그만 다룰 뿐이며, 해당 목록에서 제외된 모든 동등 뮤턴트(equivalent mutant)는 여러분이 신뢰하기로 결정한 판단의 결과입니다. 기성 뮤테이션 도구(mutmut, cosmic-ray, Stryker, PIT)는 체계적으로 뮤턴트를 생성하므로, 사용하는 언어에서 지원한다면 이를 기본값으로 사용하는 것이 더 좋습니다.

위험 수준에 따른 작업 강도 조정

이 기술은 세 가지 단계를 정의하며, 에이전트는 자신이 선택한 단계를 명시해야 합니다.

• 1단계, 사소함: 오타, 주석, 설정 값 수정. 전체 테스트 스위트와 린트(lint)를 실행하며, 새로운 테스트가 필요 없는 이유를 한 문장으로 기술합니다.
• 2단계, 일반: 버그 수정 또는 소규모 기능 구현. 전체 루프를 수행하며, 버그 수정 시에는 반드시 해당 버그를 재현하는 실패 테스트 케이스부터 시작해야 합니다. 이를 통해 어제의 버그가 내일의 회귀 테스트가 되도록 합니다.
• 3단계, 고위험: 금전, 인증, 데이터 손실, 동시성, 공개 API 관련 작업. 변경 사항이 문제를 일으킬 수 있는 방식을 나열한 실패 모델에서 시작합니다. 각 위험 요소에 대한 방어 계층을 추가하고, 전체 루프와 함께 속성 기반 테스트(property testing), 변이 테스트(mutation testing)를 수행합니다. 마지막으로 악의적인 입력을 사용하여 구현부를 공격하는 검증 과정을 한 번 거칩니다.

3단계에는 실험적인 단계가 추가됩니다. 새로운 컨텍스트를 가진 두 번째 에이전트가 작업 계약, 승인된 SPEC, 소스 상태만을 확인하고, EVIDENCE가 서명되기 전에 완성된 결과물을 파괴하려고 시도합니다. 이 에이전트는 수정하지 않고 보고만 하며, 사람이 발견된 내용을 평가합니다. 이는 작업 컨텍스트 공유로 인해 발생하는 상관관계를 줄여줍니다. 단, 모델 공유로 인한 상관관계는 줄이지 못합니다.

이 방식을 채택하는 대신 직접 구축하고 싶다면, 나만의 에이전트 기술 작성하기에서 파일 레이아웃과 에이전트가 해당 기술을 로드할 시점을 결정하는 설명 필드에 대해 다룹니다.

FAQ

코드 커버리지가 놓치는 부분을 뮤테이션 테스팅은 어떻게 잡아냅니까?

커버리지는 특정 라인이 실행되었는지 여부만 기록합니다. 해당 라인이 잘못되었을 때 단언문(assertion)이 실패하는지까지는 확인하지 못하므로, 함수를 호출하기만 하고 아무것도 검증하지 않는 테스트도 100% 커버리지로 보고됩니다. 뮤테이션 테스팅은 코드를 의도적으로 한 번에 하나씩 수정하며 테스트 스위트를 다시 실행합니다. 살아남은 뮤턴트(mutant)는 해당 라인이 실행되었음에도 그 결과를 검증하는 장치가 없음을 의미합니다. 이것이 바로 이 기술에서 "커버리지 수치를 맹신하지 말 것"을 절대 원칙으로 삼고, 수치 조작을 잡아내는 계층으로 뮤테이션 테스팅을 지목하는 이유입니다.

에이전트가 작성한 코드를 여전히 직접 읽어야 합니까?

이 워크플로우에서는 코딩 전에 SPEC을 읽고, 작업 후에는 EVIDENCE 보고서를 읽습니다. 보고서에 인용된 명령어를 직접 실행해 보며 내용을 검증하십시오. 코드 변경 사항(diff) 확인은 선택 사항입니다. 주의할 점은 모든 판단이 하나의 문서에 집중된다는 것입니다. 잘못된 요구사항이 포함된 스펙은 원치 않는 프로그램에 대해서도 성공(green) 결과를 내놓기 때문입니다. 절약한 시간은 스펙을 검토하는 데 투자하십시오.

제 서버의 CI 환경에서 Old Coder gauntlet을 실행할 수 있습니까?

네, 그곳이 가장 적합한 실행 환경입니다. requirements-dev.txt에서 고정된 툴체인을 컨테이너 내부에 설치하고 프로젝트의 gauntlet 스크립트를 하나의 작업 단계로 실행하십시오. GitHub Actions를 사용한다면 runs-on: self-hosted을 설정하고 귀하의 VPS에 러너(runner)를 등록하십시오. 직접 제어하는 브랜치에 푸시할 때만 트리거가 작동하도록 설정하십시오. 포크된 저장소의 풀 리퀘스트를 빌드하는 자체 호스팅 러너는 신뢰할 수 없는 코드를 러너의 권한으로 실행하기 때문입니다.

어떤 버전의 기술을 설치해야 합니까?

특정 버전을 고정하십시오. 이 저장소는 활발히 개발 중이며 참조 파일들이 이미 분리 및 이동되었으므로, 지난달에 생성된 보고서는 현재와 다른 규칙으로 평가되었을 수 있습니다. 저장소를 클론하고 특정 커밋을 체크아웃한 뒤, skills/old-coder을 ~/.claude/skills/로 복사하고 해당 커밋 해시를 SPEC 옆에 기록해 두십시오. 이렇게 하면 EVIDENCE의 변경 사항이 곧 코드의 변경 사항임을 보장할 수 있습니다.