@ai-dev-methodologies/rlp-desk 0.15.3 → 0.15.5

package/docs/rlp-desk/internal/verification-strategy-research.md

@@ -1,2097 +0,0 @@
-# RLP Desk Verification Strategy Research
-
-> Internal document — gitignored, not published.
-> Last updated: 2026-03-24 (v3 — 학술논문, 정형 방법론, 기업 QE, 추가 스킬)
-
-## 1. 핵심 문제
-
-### 실전 사례
-- Trading 시스템: mock 73개 ALL PASS → Redis 무한루프, 매도 실패, 유령 포지션, 시그널 이중 경로
-- 근본 원인: L1(unit test)만 요구, L2/L3/L4 강제 없음
-- "code inspection"을 검증으로 인정 → Verifier가 대충 PASS
-
-### 역사적 사례
-| 사건 | 손실 | 근본 원인 | 잡았어야 할 계층 |
-|------|------|----------|----------------|
-| Knight Capital | $440M / 45분 | 7년 미테스트 dead code + 수동 배포 | L4 (deploy verify) |
-| Boeing 737 MAX | 346명 사망 | 단일 센서 의존 시스템 테스트 누락 | L3 (E2E simulation) |
-| Mars Climate Orbiter | $327M | 단위 불일치 (파운드 vs 뉴턴) | L2 (contract test) |
-| Therac-25 | 3명 사망 | race condition, timing 미테스트 | L2 (concurrency test) |
-| AI 생성 테스트 | 구현 복사 tautological test | L1은 pass하지만 버그 못 잡음 | mutation testing gate |
-
----
-
-## 2. 검증 계층 모델 (L1-L4)
-
-```
-L1: Unit Test        — 함수 단위 (mock 허용), 항상 필수
-L2: Integration      — 외부 서비스 실제 연결, 해당 시 필수
-L3: E2E Simulation   — 알려진 입력 → 전 구간 재현, 항상 필수
-L4: Deploy Verify    — 실제 환경 동작 확인, 배포 시 필수
-```
-
-규칙:
-- 빈칸/TODO → Verifier 무조건 FAIL
-- "N/A — 사유" 명시 시에만 skip
-- "inspection"은 automated 검증으로 불인정
-
----
-
-## 3. 속일 수 없는 AC 6가지 속성
-
-1. **Observable outcome** — 관찰 가능한 결과
-2. **Quantitative threshold** — 숫자 pass/fail 기준
-3. **Negative test** — "일어나면 안 되는 것"
-4. **Edge case** — boundary value 명시
-5. **Implementation-independent** — HOW가 아닌 WHAT
-6. **Third-party verifiable** — 코드 모르는 사람도 검증 가능
-
-출처: Specification by Example (Gojko Adzic), Example Mapping (Cucumber)
-
----
-
-## 4. 비코드 검증 패턴
-
-| 유형 | 검증 방법 | 정량 기준 |
-|------|----------|----------|
-| 디자인 | pixel diff, WCAG | diff < 5%, contrast 4.5:1 |
-| 콘텐츠 | 텍스트 존재, 링크, 맞춤법 | broken links 0, EPT < 2 |
-| API | contract test, 스키마 | Pact pass, OpenAPI 0 errors |
-| 배포 | health check, canary | /health 200, error < 0.5% |
-| 인프라 | validate, policy scan | Checkov HIGH 0건 |
-| 문서 | 링크, 코드블록 실행 | broken 0, 예제 실행 가능 |
-| 데이터 마이그레이션 | row count, checksum | source == target, SHA 10% |
-| 보안 | OWASP ASVS, SAST | CVSS ≥ 7.0 취약점 0건 |
-
----
-
-## 5. 테스트 품질 게이트
-
-```
-Gate 1: 테스트 존재 (coverage ≥ 80%)
-Gate 2: 테스트가 버그 잡음 (mutation score ≥ 60%)
-Gate 3: 행동 검증 (anti-pattern checklist pass)
-```
-
-Anti-patterns:
-- Liar: assertion 없이 실행만
-- Inspector: private 메서드/내부 상태 검증
-- Mockery: mock만 테스트
-- Tautological: 구현 로직 복사한 expected value
-- Snapshot abuse: 300줄 HTML diff 무검토 승인
-
----
-
-## 6. 언어/프레임워크 중립성
-
-### 추상 검증 카테고리 (도구가 아닌 카테고리로 지정)
-
-| 카테고리 | Python | JS/TS | Go | Rust | Shell | Java |
-|----------|--------|-------|----|------|-------|------|
-| unit-test | pytest | vitest/jest | go test | cargo test | bats | junit |
-| lint | ruff | eslint/biome | golangci-lint | clippy | shellcheck | checkstyle |
-| type-check | mypy | tsc --noEmit | (built-in) | (built-in) | n/a | (built-in) |
-| format | ruff format | prettier | gofmt | cargo fmt | shfmt | google-java-format |
-| security | bandit | npm audit | govulncheck | cargo audit | n/a | spotbugs |
-| mutation | mutmut | stryker | — | cargo-mutants | — | pitest |
-| concurrency | — | — | go test -race | loom | — | jcstress |
-| backward-compat | griffe | api-extractor | apidiff | cargo-semver-checks | — | japicmp |
-
-### Polyglot 프로젝트 처리
-test-spec에 per-component 블록 지원:
-```
-## Component: backend (python)
-| AC | Category | Command |
-
-## Component: frontend (typescript)
-| AC | Category | Command |
-```
-
----
-
-## 7. 추가 검증 차원 (현재 전략에서 누락)
-
-| 차원 | 설명 | 도구 | 우선순위 |
-|------|------|------|---------|
-| perf-regression | "이전보다 느려졌는가" | k6, hyperfine, benchstat | Medium |
-| accessibility | WCAG AA 준수 | axe-core, Playwright | Medium |
-| backward-compat | API/라이브러리 호환성 | semver-checks, Pact | High |
-| concurrency | race condition | go -race, loom, jcstress | High |
-| db-consistency | 마이그레이션 후 정합성 | pgTAP, alembic round-trip | Medium |
-| observability | 로그/메트릭/트레이스 존재 | OTel weaver, grep | Low |
-| error-recovery | 장애 복구 | toxiproxy, chaos-mesh | Medium |
-| anti-gaming | AI가 테스트 속이는 것 방지 | hidden test, assertion 체크 | High |
-
----
-
-## 8. AI 검증 특수 문제
-
-### AI-generated test의 한계 (Mark Seemann)
-- "Tests work best when you have seen them fail" — AI가 만든 테스트는 한 번도 실패한 적 없음
-- 구현을 읽고 expected value를 복사 → tautological test
-- mock이 버그와 같은 가정을 인코딩
-
-### NIST: AI Agent 평가 속임 방지 (2026)
-1. **Solution contamination**: AI가 답을 인터넷에서 검색
-2. **Grader gaming**: assertion 비활성화, 테스트 전용 로직 삽입
-
-방지 방법:
-- Worker가 볼 수 없는 hidden test
-- assertion 무결성 체크 (assert 문 삭제 감지)
-- Worker와 Verifier에 다른 모델 사용
-- 테스트 코드에 `if __name__ == '__test__'` 패턴 탐지
-
-### AI 코드의 실제 위험도 (Harness 2025, CodeRabbit)
-- AI 생성 PR: 1.7x 더 많은 이슈, 1.4x 더 많은 critical 버그
-- 72% 조직이 AI 코드로 인한 프로덕션 사고 경험
-- XSS 취약점 2.74x 더 높음
-
----
-
-## 9. 외부 스킬 (skills.sh)
-
-### 설치 가능한 관련 스킬
-
-| 스킬 | 설치수 | 용도 |
-|------|--------|------|
-| `aj-geddes/useful-ai-prompts@mutation-testing` | 135 | mutation testing 가이드 |
-| `am-will/codex-skills@tdd-test-writer` | 857 | TDD 테스트 작성 |
-| `jwilger/agent-skills@mutation-testing` | 76 | mutation testing 워크플로우 |
-| `proffesor-for-testing/agentic-qe@mutation-testing` | 51 | QE 관점 mutation testing |
-| `swingerman/atdd@atdd` | 7 | ATDD 2-stream (acceptance + unit) |
-| `bacoco/bmad-skills@bmad-test-strategy` | 19 | 테스트 전략 수립 |
-| `mikeyobrien/ralph-orchestrator@test-driven-development` | 30 | ralph loop TDD |
-| `doubleslashse/claude-marketplace@requirements-clarification` | 20 | 요구사항 명확화 |
-
----
-
-## 10. 참고 레포
-
-| 레포 | 핵심 아이디어 |
-|------|-------------|
-| [swingerman/atdd](https://github.com/swingerman/atdd) | ATDD 2-stream + mutation testing, Claude Code 플러그인 |
-| [eyaltoledano/claude-task-master](https://github.com/eyaltoledano/claude-task-master) | PRD → task list, complexity scoring, TDD autopilot |
-| [dodona-edu/universal-judge](https://github.com/dodona-edu/universal-judge) | 언어 중립 테스트 러너 (TESTed) |
-| [darrenhinde/OpenAgentsControl](https://github.com/darrenhinde/OpenAgentsControl) | 6단계 검증 파이프라인 AI agent |
-| [qodo-ai/pr-agent](https://github.com/qodo-ai/pr-agent) | 15+ 전문 agent PR 리뷰 |
-| [automazeio/ccpm](https://github.com/automazeio/ccpm) | PRD → Epic → Issue 트래킹 |
-| [ruvnet/sparc](https://github.com/ruvnet/sparc) | SPARC (Spec→Pseudo→Arch→Refine→Complete) |
-
----
-
-## 11. 방법론 출처
-
-| 방법론 | 출처 | 핵심 |
-|--------|------|------|
-| Specification by Example | Gojko Adzic (10년 회고) | 구체적 예시가 AC, 2.75x 품질 향상 |
-| Example Mapping | Matt Wynne (Cucumber) | Yellow/Blue/Green/Red 카드, 25분 세션 |
-| ATDD 2-stream | swingerman/atdd | acceptance test = 불변, Worker 수정 불가 |
-| Shape Up | Basecamp | appetite 기반 scoping, circuit breaker |
-| INVEST | Agile | Independent, Negotiable, Valuable, Estimable, Small, Testable |
-| IEEE 829 | IEEE | 16 clause 테스트 계획 표준 |
-| ISTQB | ISTQB Foundation | EP, BVA, decision table, state transition |
-| ISO 25010:2023 | ISO | 9가지 품질 특성 (safety, flexibility 추가) |
-| DO-178C | FAA | 리스크 기반 검증 수준 (DAL A-E), 독립 검증 의무 |
-| Three Amigos | John Ferguson Smart | Intent + Correctness + Adversarial 3관점 |
-| Testing Trophy | Kent C. Dodds | integration 중심 (unit < integration < e2e) |
-| Google Mutation Testing | IEEE TSE 2021 | 24,000+ 개발자, 82% productive mutants |
-| NIST CAISI | NIST 2026 | AI agent 평가 속임 방지 가이드 |
-
----
-
-## 12. 구현 우선순위
-
-| 순위 | 항목 | 근거 |
-|------|------|------|
-| **P0** | test-spec L1/L2/L3/L4 필수 섹션 | 실전 장애 직접 방지 |
-| **P0** | Verifier Layer Enforcement | TODO → FAIL, inspection ≠ verification |
-| **P0** | Criteria Mapping에 Layer 컬럼 | AC별 검증 계층 추적 |
-| **P1** | 추상 검증 카테고리 (언어 중립) | 다중 언어 프로젝트 지원 |
-| **P1** | brainstorm Given/When/Then + Task Type | PRD 품질 강제 |
-| **P1** | Worker TDD + L3 E2E 의무 | unit test만 돌리고 끝내기 방지 |
-| **P1** | anti-gaming 대책 | hidden test, assertion 무결성 |
-| **P2** | Anti-pattern 체크리스트 | L1 품질 개선 |
-| **P2** | perf-regression, accessibility, concurrency | 추가 검증 차원 |
-| **P2** | Sweep 검증 (도메인 특화) | trading 등 특수 도메인 |
-| **P3** | per-component polyglot 지원 | 복합 스택 프로젝트 |
-| **P3** | formal verification 연동 | 장기 비전 (Lean4, Isabelle) |
-
----
-
-## 13. 외부 스킬 흡수 분석
-
-### 13-1. swingerman/atdd — 2-Stream ATDD
-
-**핵심 방법론:**
-- Acceptance test(WHAT)와 Unit test(HOW)를 완전 분리
-- Acceptance test는 Worker가 수정 불가 (read-only contract)
-- Spec은 Given/When/Then + **도메인 언어만** 사용 (기술 용어 금지)
-- Spec-Guardian agent가 implementation leakage 감지
-
-**7단계 워크플로우:**
-1. Given/When/Then spec 작성 (도메인 언어만)
-2. 프로젝트별 test pipeline 생성 (parser → IR → generator)
-3. Acceptance test 실행 → 반드시 FAIL (RED)
-4. TDD로 구현 (unit test + code → 양쪽 pass)
-5. Spec leakage 감사
-6. Mutation testing 실행
-7. 다음 feature로 반복
-
-**Implementation leakage 예시:**
-```
-BAD: "GIVEN the UserService has an empty userRepository"
-GOOD: "GIVEN there are no registered users"
-```
-
-금지 패턴: class/function 이름, DB 테이블, API 엔드포인트, 프레임워크 용어, 파일 경로
-
-**rlp-desk 흡수 지점:**
-| ATDD 구성요소 | rlp-desk 적용 위치 |
-|-------------|-------------------|
-| Acceptance test (불변) | test-spec 내 별도 섹션, Verifier가 소유 |
-| Spec-Guardian | Verifier prompt에 leakage 체크 규칙 추가 |
-| 도메인 언어 강제 | brainstorm에서 AC 작성 시 기술 용어 금지 가이드 |
-| Mutation testing | Verifier 검증 게이트 Gate 2 |
-
-출처: https://github.com/swingerman/atdd
-
----
-
-### 13-2. Mutation Testing 스킬 (3개 통합)
-
-**비교:**
-| 차원 | aj-geddes (135) | jwilger (76) | agentic-qe (51) |
-|------|-----------------|-------------|-----------------|
-| Kill rate 기준 | 80%+ | **100% 강제** | 95%+ excellent |
-| 시나리오 검증 | 없음 | **GWT 시나리오 필수** | 학습 기반 |
-| 병렬 실행 | 없음 | 순차 | **8 workers** |
-| 증분 테스트 | 파일 단위 | changed files | **changed lines** |
-| 증거 출력 | HTML | **JSON packet** | JSON+MD+HTML |
-
-**흡수할 핵심:**
-
-1. **시나리오 커버리지 검증 (jwilger)**
-   - surviving mutant에 대응하는 GWT 시나리오가 없으면 → 코드 삭제 or 시나리오 추가 (사람 판단)
-   - 시나리오 없이 테스트만 추가하는 건 metric gaming
-
-2. **Mutation type → 테스트 추천 (공통)**
-   - `>=` → `>` 생존: boundary test 추가
-   - `&&` → `||` 생존: 한쪽만 true인 케이스 추가
-   - statement 삭제 생존: return value 미검증
-   - arithmetic 생존: 계산 결과 미검증
-
-3. **증거 패킷 형식 (jwilger)**
-```json
-{
-  "tool": "cargo-mutants",
-  "scope": ["src/money.rs"],
-  "total_mutants": 42,
-  "killed": 40,
-  "survived": 2,
-  "score": 95.2,
-  "survivors": [{"file":"...","line":45,"mutation_type":"arithmetic"}],
-  "verdict": "FAIL"
-}
-```
-
-4. **언어별 도구 매핑 (공통)**
-   - Rust: cargo-mutants
-   - JS/TS: Stryker
-   - Python: mutmut
-   - Java: PITest
-   - Elixir: Muzak
-
-출처: aj-geddes/useful-ai-prompts, jwilger/agent-skills, proffesor-for-testing/agentic-qe
-
----
-
-### 13-3. TDD 스킬 (4개 통합)
-
-**핵심 발견: Context Isolation이 TDD 강제의 열쇠**
-
-단일 컨텍스트 LLM은 자연스럽게 "구현을 먼저 설계하고 테스트를 맞추는" 치팅을 함.
-해결책: RED/GREEN/REFACTOR 각 단계를 **별도 Agent**로 분리.
-
-```
-RED:      test-writer agent (구현 계획 못 봄)
-GREEN:    implementer agent (테스트 파일만 봄)
-REFACTOR: refactorer agent (통과한 코드만 봄)
-```
-
-**backpressure gate (ralph-orchestrator):**
-- 테스트 미통과 → 다음 단계 진입 거부
-- lint 실패 → 다음 단계 진입 거부
-- typecheck 실패 → 다음 단계 진입 거부
-
-**TEA (bmad) — Risk-Based 테스트 전략:**
-- P0-P3 리스크 분류 (probability × impact)
-- P0/P1 시나리오 먼저 테스트
-- 40개 재사용 가능 test fixture/helper Knowledge Base
-- Requirements → Tests 추적 (Traceability Matrix)
-- go/no-go gate: 릴리스 결정은 추적 가능한 증거 기반
-
-**TDD Anti-patterns (공통):**
-- "Implement X with tests" → 구현 우선으로 전락
-- "Test existing code" → 함수가 이미 존재한다고 가정
-- 단계 결합 → RED와 GREEN을 한 번에 하면 TDD 아님
-
-**rlp-desk 흡수 지점:**
-| TDD 구성요소 | rlp-desk 적용 위치 |
-|-------------|-------------------|
-| Context isolation | Worker 내부에서 RED/GREEN/REFACTOR 단계 분리 지시 |
-| Backpressure gate | Verifier가 테스트/lint/typecheck 통과 확인 후 PASS |
-| Risk-based prioritization | brainstorm에서 US별 리스크 분류 |
-| Traceability matrix | test-spec의 Criteria Mapping 확장 |
-| Requirements clarification | brainstorm에서 2-3개 targeted 질문 (10개+ 금지) |
-
-출처: modu-ai/moai-adk, bacoco/bmad-skills, mikeyobrien/ralph-orchestrator, am-will/codex-skills
-
----
-
-## 14. 통합 흡수 전략 — rlp-desk 적용 맵
-
-### brainstorm 단계
-- Given/When/Then AC + 도메인 언어 강제 (ATDD)
-- Task Type 식별 + US별 리스크 분류 P0-P3 (TEA)
-- 2-3개 targeted 명확화 질문 (requirements-clarification)
-- 검증 계층(L1-L4) 지정 (실전 피드백)
-
-### PRD 템플릿
-- AC를 Given/When/Then + 도메인 언어 (기술 용어 금지)
-- Boundary Cases 필수
-- Task Type + Risk Level 필드
-- 검증 계층 매핑 (AC별 L1/L2/L3/L4)
-
-### test-spec 템플릿
-- L1/L2/L3/L4 필수 섹션 (실전 피드백)
-- Acceptance test 섹션 (Worker 수정 불가, ATDD)
-- Anti-pattern 체크리스트
-- Mutation testing gate
-- Deploy Checklist
-- Traceability Matrix (Requirements → Tests → Evidence)
-
-### Worker prompt
-- TDD 강제: RED→GREEN→REFACTOR (context isolation 권장)
-- L3 E2E 실행 의무
-- Acceptance test 수정 금지
-- Backpressure gate: 테스트/lint/typecheck 통과 전 complete 금지
-
-### Verifier prompt
-- Layer Enforcement: L1~L4 각 계층 실행 확인 (TODO → FAIL)
-- Spec-Guardian: AC에 기술 용어 leakage 체크
-- Mutation testing: score ≥ 60% (Phase 1), 시나리오 커버리지 검증
-- Anti-gaming: assertion 무결성, hidden test, inspection ≠ verification
-- Backpressure: 테스트 미통과 → FAIL
-
-### governance.md
-- 리스크 기반 검증 수준 정의 (low/medium/high/critical)
-- 리스크 높을수록 검증 계층 + mutation + consensus 강제
-
----
-
-## 15. 도메인별 AC 템플릿 라이브러리
-
-### 15-1. Web API Endpoint
-- CRUD 정확성: 200/201/204/400/401/403/404/409/422/500 각 상태코드
-- 인증/인가: 미인증→401, 권한 없음→403, 다른 사용자 리소스 접근 차단
-- 입력 검증: 필수 필드 누락→422, 잘못된 타입→400, SQL injection→400(not 500)
-- 페이지네이션: 기본 size 제한, page=0/-1→400, 마지막 페이지 초과→빈 배열
-- 에러: 일관된 JSON 구조, 내부정보 미노출, 5xx→서버 로그 + correlation ID
-- 보안 헤더: X-Content-Type-Options, X-Frame-Options, CSP, CORS
-- 출처: Shieldfy API Security Checklist, OWASP
-
-### 15-2. Frontend UI Component
-- 렌더링: 정상 데이터, 빈 데이터, 최대 길이, 특수문자, 로딩/에러/빈 상태
-- 인터랙션: hover/focus/active, 키보드 내비게이션, 폼 유효성, 포커스 트랩 없음
-- 반응형: 320px/768px/1024px/1920px, 터치 타겟 44x44px, 가로 스크롤 없음
-- 접근성(WCAG 2.2 AA): 대비 4.5:1, alt 텍스트, label 연결, 스크린리더, 200% 줌
-- 출처: GOV.UK, A11Y Project Checklist, Lost Pixel
-
-### 15-3. Data Pipeline
-- 수집: 소스 연결, 소스 불가 시 재시도, 스키마 drift 검증, 중복 처리
-- 변환: 알려진 N건 입출력 검증, NULL 처리, 타입 캐스팅, 집계 수동 대조
-- 유효성: 완전성(NULL%), 유일성(PK 중복), 참조 무결성, 범위, 포맷, freshness
-- 출력: 스키마 일치, 멱등성, 파티셔닝, 메트릭 발행
-- 장애 복구: 체크포인트, 부분 실패 → 비일관 상태 없음, DLQ, 알림
-- 출처: lakeFS, Monte Carlo, Integrate.io
-
-### 15-4. CLI Tool
-- 인자 파싱: --help/-h, --version, 필수 인자 누락→에러+사용법, 미지 플래그→유사 제안
-- 출력: stdout=정상, stderr=에러, --json, --quiet, --verbose, 비TTY시 색상 해제
-- 종료 코드: 0=성공, 1=에러, 2=사용법, 부분 실패→0 아님
-- 에러 메시지: 원인+해결법, 경로 포함, sudo 제안, 비디버그시 스택트레이스 없음
-- 견고성: Ctrl+C 클린업, SIGTERM 정상종료, SIGPIPE 처리, stdout 리다이렉트 동작
-- 출처: clig.dev (CLI Guidelines)
-
-### 15-5. Infrastructure
-- 프로비저닝: IaC 정의, plan 확인, apply 멱등, 태그 적용
-- 네트워킹: 최소 권한 SG, 비공개 서브넷 DB, LB 헬스체크, TLS 자동갱신
-- 보안: IAM 최소 권한, 하드코딩 크레덴셜 없음, 저장소 암호화, 감사 로깅
-- 모니터링: 헬스체크, CPU/메모리/디스크 수집, 알림 설정, 로그 중앙화, 런북
-- DR: 자동 백업+복원 테스트, 멀티AZ, 페일오버 테스트, RTO/RPO 문서화
-- 출처: Mercari Production Readiness Checklist
-
-### 15-6. Batch Job
-- 스케줄링: cron 확인, 이전 실행 중 중복 방지(mutex), 수동 트리거, TZ 명시
-- 멱등성: 재실행=동일 결과, 체크포인트 추적, 부분+재실행=전체 실행
-- 에러 복구: transient→재시도(backoff), permanent→DLQ, 부분 실패 안전
-- 로깅: 시작/종료 시간, 처리/실패/스킵 건수, 실행 ID, 대시보드
-- 출처: AWS Batch, BullMQ
-
-### 15-7. Real-Time System
-- 지연: p50/p95/p99 SLA, 2x 부하시 20% 이내 증가, E2E 측정
-- 처리량: 정상 N msg/s, 버스트 2N T분, 선형 확장, 손실 0
-- 백프레셔: 프로듀서 throttle(crash 아님), 신호 전파 T초 내, 큐 80% 알림
-- 페일오버: 컨슈머 장애→T초 내 대체, 브로커 장애→재라우팅, 데이터 손실 0
-- 순서/전달: 파티션 내 순서 보장, at-least-once/exactly-once 문서화, DLT 구성
-- 출처: Conduktor, Azure Reliability, New Relic
-
-### 15-8. Mobile App
-- 플랫폼: 최소 iOS/Android 버전, HIG/Material 가이드, safe area
-- 오프라인: 핵심 기능 캐시, 오프라인 표시, 큐잉→온라인 동기화, 충돌 해결
-- 권한: 필요 시점에 요청, 사전 설명, 거부 시 fallback, 미사용 권한 없음
-- 알림: 가치 시연 후 요청, 탭→올바른 화면, 잠금화면 민감정보 없음, 채널 분류
-
----
-
-## 16. 검증 계층별 상세 체크리스트 (L1-L4)
-
-### L1 Unit Test (25항목)
-**커버리지 게이트:**
-- Happy path, 각 에러 경로, null/empty/zero, boundary(n-1,n,n+1), return value assertion, side effect 검증
-**테스트 설계:**
-- 1 테스트 = 1 행동, 이름=given/when/then, 독립성, mock=외부 의존성만
-**입력 엣지케이스:**
-- 특수문자(SQL injection, XSS), Unicode/emoji, 최대 길이, 잘못된 타입
-**비즈니스 로직:**
-- 상태 전이, 동시성, 타임아웃/재시도, 무효 상태 조합, 롤백
-
-### L2 Integration Test (서비스별)
-**DB:** 연결풀, CRUD, 트랜잭션, ACID, 제약조건, 마이그레이션 가역성, 연결 손실 복구
-**Redis:** set/get/expire, pub/sub, 연결 손실 복구, 캐시 미스, 직렬화
-**HTTP API:** auth, 헤더, 상태코드, 타임아웃, 재시도(429/503), rate limit, TLS
-**Message Queue:** produce/consume/ack, DLQ, 순서, 우선순위, 재생, publisher confirm, durability
-**File System:** read/write/delete, 권한, 디스크 풀, 인코딩, 동시 접근
-**Email/SMS:** 전송 확인, 템플릿 변수 치환, rate limit, 바운스, 수신 거부
-
-### L3 E2E Simulation
-**사전조건:** 알려진 입력 정의, 기대 출력(정량) 정의, 환경 초기화, baseline 확보
-**실행:** 전체 파이프라인, 모든 서브시스템, 실제 호출(mock 아님), 타이밍/순서 검증, async 완료 대기
-**검증:** baseline ± 허용 오차, 출력 형식 스키마, DB 상태, 예상 외 부작용 없음
-**에러 전파:** 각 단계 실패 전파, 부분 실패→비일관 없음, 재시도 멱등
-**정리:** 테스트 데이터 삭제, 외부 계정 초기화, 잔여 큐 메시지 없음
-
-### L4 Deploy Verification
-**즉시 (5분):** /health 200, 버전 일치, 프로세스 실행 확인, ERROR 로그 0건, 의존성 연결
-**설정:** 환경변수, 시크릿 로드, 피처 플래그, SSL 유효+30일 이상, DNS
-**데이터:** 마이그레이션 완료, 미적용 없음, 롤백 스테이징 테스트 완료
-**트래픽:** P95 SLA 이내, 에러율 < 0.1%, CPU/메모리 정상, 오토스케일링
-**카나리 (Google SRE):** 컨트롤 그룹 대비, HTTP 코드+지연 primary signal, 대표 트래픽 사이클 이상, 자동 롤백
-**모니터링:** 대시보드 golden signals, 알림 라우팅, synthetic probe, 로그 수집
-**롤백:** 단일 명령, 이전 아티팩트 존재, DB 마이그레이션 롤백 테스트, 의사결정자 연락 가능
-
-출처: Google SRE Launch Checklist, AWS Well-Architected, Cortex, bregman-arie/sre-checklist
-
----
-
-## 17. 테스트 설계 템플릿
-
-### Equivalence Partitioning 워크시트
-| 파티션 ID | 타입 | 범위/값 | 대표값 | 테스트 ID |
-규칙: 파티션당 최소 1 TC, invalid 파티션은 각각 독립 TC
-
-### Boundary Value Analysis 워크시트
-2-value BVA: min, min-1, max, max+1
-3-value BVA: min-1, min, min+1, max-1, max, max+1
-
-### Decision Table
-조건 N개 → 2^N 규칙 → 규칙당 1 TC → 무관 조건 병합으로 축소
-
-### State Transition → TC 매핑
-| 현재 상태 | 이벤트 | 다음 상태(pass) | 다음 상태(fail) | TC ID |
-+ 무효 전이 TC (발생하면 안 되는 전이)
-
-### Error Guessing 카테고리별 체크리스트
-**Null/Missing:** null, undefined, "", 필수 필드 누락, 빈 배열/객체
-**Overflow:** MAX_INT±1, 최대 길이+1, 최대 depth, 스택 오버플로우
-**Concurrent:** 동시 업데이트, 더블클릭, 1ms 내 동일 요청, read-during-write
-**Encoding:** Unicode, SQL injection, XSS, path traversal, null byte, URL encoding
-**Timezone:** 연말→연초, 윤년 2/29, DST 전환, UTC vs local, 2038 문제
-
----
-
-## 18. Gaming 방지 Given/When/Then 패턴
-
-### Negative (일어나면 안 되는 것)
-```
-Then NO user record is created
-Then the response does NOT contain "password_hash"
-Then order status is still "cancelled"
-```
-
-### Boundary (정확한 경계값)
-```
-Scenario Outline: username length 2→422, 3→201, 30→201, 31→422
-```
-
-### Concurrent (race condition)
-```
-When user A and user B simultaneously POST (last item)
-Then exactly 1 order created, exactly 1 receives 409, inventory = 0 (not -1)
-```
-
-### Failure (X가 깨졌을 때)
-```
-Given the database connection is unavailable
-Then response 503, NO stack trace, Retry-After header present
-```
-
-### Performance (N ms 이내)
-```
-Given 100 concurrent users
-Then p95 < 200ms AND zero 5xx AND CPU < 90%
-```
-
----
-
-## 19. Mutation Testing 상세
-
-### Surviving Mutant → 테스트 추천 매핑 (완전 테이블)
-| 생존 mutant 유형 | 근본 원인 | 테스트 액션 |
-|-----------------|----------|-----------|
-| 산술 연산 교체 (+→-) | 계산 결과 미검증 | 알려진 입력의 정확한 숫자 출력 assert |
-| 경계 이동 (<→<=) | boundary 미테스트 | n-1, n, n+1 테스트 추가 |
-| null 반환 주입 | null 경로 미검증 | null/empty 결과 처리 테스트 |
-| boolean 반환 뒤집기 | return값 미검증 | assertTrue/assertFalse |
-| void 메서드 삭제 | 부작용 미검증 | 상태 변경/호출 횟수 검증 |
-| 빈 컬렉션 반환 | 컬렉션 내용 미검증 | size > 0 또는 특정 요소 |
-| 조건 부정 (==→!=) | 실패 경로 미테스트 | 거부/실패 케이스 추가 |
-| increment 뒤집기 (++→--) | 카운터 미검증 | 루프 종료 상태 assert |
-| 문자열 변경 | 문자열 정확히 미비교 | exact string assert |
-| dead code | 도달 불가 | 코드 삭제 또는 도달성 테스트 |
-
-### 동치 mutant 판단 결정 트리
-```
-생존 → 테스트가 해당 라인 실행? NO → 커버리지 갭 (동치 아님)
-      → 관찰 가능한 출력 변경? NO → dead code/로깅 → 동치, 억제
-      → 테스트가 해당 값 assert? YES → assertion 약함 → 강화
-```
-
----
-
-## 20. TDD 단계별 체크리스트
-
-### RED (실패 테스트 작성)
-- 즉시 실행 → 반드시 FAIL (pass하면 새 행동 아님)
-- 1 테스트 = 1 행동
-- 테스트 이름: MethodName_Scenario_Expected
-- 프로덕션 코드 미작성 상태
-- 구현 leakage 없는 assertion
-
-### GREEN (최소 구현)
-- 테스트만 보고 구현 (구현 계획 참조 금지)
-- 딱 통과할 만큼만 (over-engineering 금지)
-- 테스트 수정 금지
-- 다른 테스트 우연히 통과시키지 않음
-
-### REFACTOR (개선)
-- 모든 테스트 통과 상태에서만 시작
-- 새 기능 추가 금지 (새 RED 필요)
-- 테스트 assertion 변경 금지
-- 끝난 후에도 모든 테스트 통과
-
-### Metric Gaming 감지 체크리스트
-| 패턴 | 징후 | gaming 이유 |
-|------|------|------------|
-| No-assertion | assert 없이 호출만 | 커버리지만 올림 |
-| Tautological | `!= null` (null 불가능한 곳) | 항상 통과 |
-| Pre-passing | 코드 작성 후 테스트 | RED 안 봄 |
-| Logic in test | if/for in test body | 테스트에 버그 유입 |
-| Shared state | 순서 의존 | 비재현성 |
-
----
-
-## 21. Test Quality Scoring Rubric (0-100)
-
-10개 차원 × 0-10점:
-1. 테스트 네이밍 명확성
-2. AAA 구조 (Arrange/Act/Assert)
-3. 단일 Act per test
-4. Assertion 구체성
-5. Assertion 밀도 (1-3개 적정)
-6. 테스트 격리성
-7. 순서 독립성
-8. Mock 규율 (외부 의존만)
-9. 테스트 내 로직 없음
-10. Mutation score
-
-해석: 0-49 비신뢰, 50-69 기본, 70-84 양호, 85-100 고신뢰
-
-### Spec-Guardian Leakage 탐지 규칙
-금지: class/type 이름, 메서드명, DB 테이블, API 경로, HTTP verb, 프레임워크 용어, 데이터 구조, 파일 경로, 에러 코드/예외 이름, 테스트 프레임워크 용어
-이식성 테스트: "다른 언어/스택으로 구현해도 Given/When/Then 한 줄도 안 바꿔도 되는가?"
-
-### AC Quality Scoring (0-12)
-6개 차원 × 0-2점: 단일 행동, 도메인 언어, 이해관계자 명확성, 이식성, 구체적 예시, 독립성
-0-5 거부, 6-9 수정, 10-12 승인
-
----
-
-## 22. Property-Based Testing 흡수
-
-### 핵심 원칙
-```
-GIVEN ANY <임의 입력, 제약 조건 충족>
-WHEN <함수 호출 또는 액션>
-THEN <조건이 항상 성립>
-```
-"ANY"와 "ALWAYS/NEVER"로 보편적 검증 — 특정 입출력 쌍이 아닌 불변 조건 검증
-
-### Property 식별 체크리스트
-- [ ] 핵심 불변 조건 식별 완료
-- [ ] 추상적 표현 (특정 입출력 아님)
-- [ ] 수학적으로 건전
-- [ ] 완전성 검증 (버그를 잡을 만큼 충분한 property)
-- [ ] 과잉 명세 없음
-- [ ] 보편 양화사 사용 ("모든", "항상", "절대 ~아님")
-
-### 언어별 도구
-| 언어 | 프레임워크 | 핵심 기능 |
-|------|-----------|----------|
-| JS/TS | fast-check | composable arbitraries, 자동 shrinking, runner 무관 |
-| Python | Hypothesis | @given 데코레이터, st.composite, pytest 통합 |
-| Rust | proptest | ProptestConfig, 전략 조합 |
-| Java | jqwik | @Property, @ForAll |
-
-### Shrinking (최소 반례 탐색)
-실패 시 자동으로 최소 재현 케이스 생성 — 디버깅 효율 극대화
-fast-check: 통합 shrinking (별도 함수 불필요)
-Hypothesis: 자동 최소화 + 실패 DB 저장
-
-### rlp-desk 적용
-- test-spec에 "Property Tests" 선택적 섹션 추가
-- 순수 함수/알고리즘/데이터 변환에 property 정의 권장
-- Verifier가 property test 존재 여부 + invariant 건전성 체크
-
-출처: fast-check.dev, hypothesis.works, dubzzz/fast-check, laurigates/claude-plugins
-
----
-
-## 23. Visual/Accessibility/E2E 스킬 흡수
-
-### Visual Regression Testing
-- Playwright + screenshot 비교 (336 installs — 가장 인기 스킬)
-- pixel diff threshold 설정 (기본 5%, 엄격 1%)
-- 실패 시 before/after 스크린샷 증거 캡처
-- CI에서 자동 실행 가능
-
-### E2E Testing 5-Dimension Scoring
-| 차원 | 0 (나쁨) | 1 | 2 (좋음) |
-|------|---------|---|---------|
-| 셀렉터 | CSS class | data-testid | semantic role |
-| 독립성 | 공유 상태 | 약한 의존 | 완전 격리 |
-| 안정성 | 고정 timeout | 부분 intelligent wait | 완전 intelligent wait |
-| 범위 | E2E에서 unit 로직 | 핵심 워크플로우 | 피라미드 정렬 |
-| 데이터 | 하드코딩 | 부분 동적 | 자동 정리 |
-
-### E2E 체크리스트
-- [ ] Semantic 셀렉터 (role, label, testid)
-- [ ] Page Object 패턴
-- [ ] 외부 API mock
-- [ ] 병렬 실행
-- [ ] 실패 시 스크린샷/비디오 캡처
-- [ ] 테스트 데이터 정리
-- [ ] E2E에서 edge case 피하기 (unit에서 처리)
-- [ ] 크로스 브라우저
-- [ ] 접근성 검증
-- [ ] CI/CD 통합
-
-출처: manutej/luxor-claude-marketplace, proffesor-for-testing/agentic-qe, thapaliyabikendra/ai-artifacts
-
----
-
-## 24. Traceability & Audit 스킬 흡수
-
-### Traceability Matrix 패턴
-**cumulative tagging (aidoc-flow-framework):**
-```
-@brd: BRD.01.01.30  → 비즈니스 요구사항
-@prd: PRD.01.01.30  → 제품 요구사항
-@code: CODE.01.01.30 → 구현
-```
-모든 아티팩트에 상위 레이어 태그 누적 → 끊김 없는 감사 체인
-
-**spec-compliance-validator:**
-frame concerns → acceptance criteria → tests 양방향 연결
-Design by Contract 강제, 위반 테스트 필수
-
-### Pre-Push 10-Phase Audit (codebase-audit-pre-push)
-1. 정크 파일 제거
-2. .gitignore 검증
-3. 소스 코드 분석 (dead code, magic number, debug 문)
-4. 보안 검사 **(ZERO-TOLERANCE: 하드코딩 시크릿, SQL injection)**
-5. 확장성 평가 (N+1 쿼리, 미인덱스, 메모리 누수)
-6. 아키텍처 리뷰
-7. 성능 최적화
-8. 문서 완전성
-9. 테스트 커버리지
-10. 최종 회귀 검증
-
-CRITICAL blocker: 하드코딩 시크릿, SQL injection, 미보호 auth, 스택트레이스 노출
-
-### 12-Attack-Surface Security (repo-sentinel)
-0-12번 공격 표면 × 심각도(CRITICAL/HIGH/MEDIUM/LOW)
-4-Stage DAG: 민감 자산 → 법적 준수 → 공개 표면 → 릴리스
-
-### Drift Detection
-SHA-256 해시 기반 상위 문서 변경 감지
-.drift_cache.json에 파일 해시 + 수정 시간 + 리뷰 이력
-
-### rlp-desk 적용
-- test-spec에 Traceability Matrix 섹션 (US→AC→Test→Evidence)
-- Verifier가 traceability 완전성 체크 (연결 안 된 AC → FAIL)
-- 보안 체크리스트를 Verifier prompt에 포함 (시크릿, injection)
-
-출처: vladm3105/aidoc-flow-framework, knowlet/skills, sickn33/antigravity-awesome-skills, mathews-tom/praxis-skills
-
----
-
-## 25. 추가 외부 자료
-
-### 기업 QE 패턴
-| 기업 | 패턴 | 핵심 |
-|------|------|------|
-| Spotify | Testing Honeycomb | 마이크로서비스: integration 중심 (unit 아님), 서비스 경계에서 테스트 |
-| Stripe | Testing 2.0 | 결정적 시뮬레이션, ML 테스트 생성, 지속적 장애 주입, property 기반, 100% 재현 |
-| Shopify | 5-Flow Load Test | browsing, admin, flash sale, API, headless + Game Day chaos |
-
-### Contract-First 도구
-| 도구 | 입력 | 방식 |
-|------|------|------|
-| Schemathesis | OpenAPI/GraphQL 스키마 | property-based 자동 생성 — zero per-endpoint 유지보수 |
-| Dredd | OpenAPI | example-based, hook 지원 |
-| Microcks | AsyncAPI/OpenAPI/gRPC | mock + conformance test 동시 |
-| Pact (Message) | 이벤트 계약 | consumer-driven, Kafka/SQS/RabbitMQ |
-| Specmatic | AsyncAPI | 실행 가능 계약 |
-
-### 비기능 테스트 템플릿
-**Load (k6):** smoke(2VU 1m) → load(ramping 100VU) → stress(300 arrival/s) → soak(50/s 4h)
-**Chaos Game Day:** 가설 → 폭발 반경 → 사전 체크리스트 → 실험 단계 → 사후 분석
-**Security (OWASP):** 11 카테고리 89 테스트, ZAP CI 자동 스캔 + 분기별 수동 펜테스트
-**Metamorphic Testing:** 입출력 관계 검증 (정확한 값이 아닌), AI 시스템 44편 연구 191 MR, 18% 실패율
-
-### 추가 GitHub 레포
-| 레포 | 용도 |
-|------|------|
-| schemathesis/schemathesis | OpenAPI property-based 테스트 |
-| dastergon/awesome-chaos-engineering | chaos engineering 리소스 목록 |
-| t3l3machus/OWASP-Testing-Guide-Checklist | OWASP 89 테스트 체크리스트 |
-| bregman-arie/sre-checklist | SRE 체크리스트 |
-
-### 추가 스킬 (skills.sh)
-| 스킬 | 설치수 | 용도 |
-|------|--------|------|
-| playwright-visual-testing | 336 | 시각 회귀 테스트 |
-| fast-check/javascript-testing-expert | 61 | property-based (공식 fast-check 레포!) |
-| hypothesis-testing | 60 | Python property-based |
-| trace-check | 47 | 요구사항 추적성 |
-| codebase-audit-pre-push | 37 | 10-phase 코드 감사 |
-| qe-visual-accessibility | 28 | 시각+접근성 테스트 |
-| repo-sentinel | 22 | 12-표면 보안 감사 |
-| spec-compliance-validator | 9 | 스펙 준수 검증 |
-
----
-
-## 26. 학술 논문 — AI 코드 검증
-
-### 핵심 논문
-
-| 논문 | 저자 | 연도 | 핵심 기여 | 출처 |
-|------|------|------|----------|------|
-| TDAD: Test-Driven AI Agent Definition | Tzafrir Rehan | 2026 | 행동 명세→실행 가능 테스트 컴파일. anti-gaming 3중 장치: visible/hidden test, semantic mutation, spec evolution | arXiv 2603.08806 |
-| TDAD: Reducing Code Regressions via Graph-Based Impact Analysis | Alonso, Yovine, Braberman | 2026 | 소스→테스트 의존성 그래프. regression 70% 감소(6.08%→1.82%). 일반 TDD 지시는 오히려 악화(9.94%) | arXiv 2603.17973 |
-| TOGLL: Correct and Strong Test Oracle Generation with LLMs | Hossain, Dwyer | 2024 (ICSE 2025) | LLM 기반 oracle 생성. 3.8x 더 정확한 assertion, 1023 unique bugs 탐지 | arXiv 2405.03786 |
-| Test Oracle Automation in the Era of LLMs | Molina et al. | 2024 (TOSEM 2025) | LLM oracle이 기존 SOTA 초과 — 종합 서베이 | arXiv 2405.12766 |
-| AutoSpec: Automated Specification Synthesis | Wen et al. | 2024 | ACSL 어노테이션(loop invariant, pre/post condition) 자동 합성 | arXiv 2404.00762 |
-| AgentGuard: Runtime Verification of AI Agents | Koohestani | 2025 (ASE) | 비침습 검사 레이어. Adaptive MDP + 확률적 모델 체킹 | arXiv 2509.23864 |
-| CodeHalu: Code Hallucinations in LLMs | Tian et al. | 2024 (AAAI 2025) | 4가지 환각 유형(mapping, naming, resource, logic). 8883 샘플 벤치마크 | arXiv 2405.00253 |
-| Detecting Hallucinations via Deterministic AST | — | 2026 (FORGE) | 비실행 AST 분석. F1=0.934, 77% 자동 교정 | arXiv 2601.19106 |
-| Mutation-Guided Test Generation at Meta | Foster, Harman et al. | 2025 | 10,795 Kotlin 클래스, 9095 mutant, 73% 테스트 수용률. Messenger/WhatsApp 배포 | arXiv 2501.12862 |
-| Comprehensive Study on LLMs for Mutation Testing | Wang et al. | 2024 | GPT-4o 93.4% fault detection. LLM mutant가 실제 버그에 111% 더 가까움 | arXiv 2406.09843 |
-| Metamorphic Testing (foundational) | T.Y. Chen et al. | 1998 | oracle 문제 해결. metamorphic relations = 다중 입력 간 필요 속성 | HKUST-CS98-01 |
-| Towards Verified AI | Seshia, Sadigh, Sastry | 2016/2022 | 5가지 도전+5가지 원칙. VerifAI, Scenic 도구 | arXiv 1606.08514 |
-
-### TDAD anti-gaming 3중 장치 (rlp-desk 흡수 대상)
-1. **Visible/Hidden test split** — Worker가 볼 수 있는 테스트 + 볼 수 없는 테스트 분리
-2. **Semantic mutation testing (MutationSmith)** — 프롬프트 변이체 생성 → 테스트가 잘못된 행동을 잡는지 검증
-3. **Spec evolution scenarios** — 명세 변경 시 기존 테스트가 regression 감지하는지 검증
-
-결과: 92% v1 성공, 97% hidden pass rate, 86-100% mutation score
-
-### 핵심 발견: 일반 TDD 지시는 오히려 해롭다
-TDAD 두 번째 논문: 일반적 "TDD를 따르세요" 지시 → regression이 6.08%에서 **9.94%로 악화**.
-의존성 그래프 기반 컨텍스트 정보 제공 시 → **1.82%로 감소**.
-→ Worker에게 "TDD 해" 보다 "이 파일 변경 시 이 테스트들이 영향받음"이 효과적.
-
----
-
-## 27. 정형 방법론
-
-| 방법론 | 창시자 | 연도 | 핵심 | rlp-desk 적용 |
-|--------|--------|------|------|--------------|
-| V-Model | — | 1980s | 개발 단계↔테스트 단계 1:1 매핑. Verification(올바르게 만들었나) vs Validation(올바른 것을 만들었나) | test-spec에 V&V 구분 |
-| STAMP/STPA | Nancy Leveson (MIT) | 2004 | 안전을 동적 제어 문제로 봄. unsafe control action 식별 | 고위험 US에 STPA 분석 |
-| Cleanroom SE | Harlan Mills (IBM) | 1987 | 결함 예방 > 결함 제거. 수학적 함수로서의 소프트웨어. 사용 기반 통계 테스트 → MTTF 인증 | Verifier의 독립 검증 철학 |
-| Design by Contract | Bertrand Meyer | 1986 | precondition, postcondition, class invariant. client-supplier 계약 | AC를 contract로 형식화 |
-| N-Version Programming | Chen, Avizienis | 1977 | 동일 명세 → 독립 구현 N개 → 다수결. consensus 기반 결함 탐지 | consensus verification 이론적 기반 |
-| Metamorphic Testing | T.Y. Chen | 1998 | oracle 없이 검증 — 다중 실행 간 관계(MR) 검증 | property-based testing과 결합 |
-
-### Design by Contract → rlp-desk AC 강화
-```
-precondition:  Given (입력 조건이 충족될 때)
-postcondition: Then (결과가 이 조건을 만족해야 함)
-invariant:     항상 성립하는 조건 (상태 불변식)
-```
-AC를 이 3요소로 분해하면 "속일 수 없는 AC"가 자연스럽게 도출됨.
-
----
-
-## 28. 산업 표준 (추가)
-
-| 표준 | 범위 | 핵심 | 출처 |
-|------|------|------|------|
-| IEC 61508 | 기능 안전 (전 산업) | SIL 1-4 리스크 등급, Part 1-4 규범+Part 5-7 가이드 | IEC |
-| ISO/IEC/IEEE 29119 | 소프트웨어 테스트 | 5개 파트(개념, 프로세스, 문서, 기법, 키워드). 가장 포괄적 테스트 표준 | ISO |
-| ISO/IEC 42001 | AI 관리 시스템 | 세계 최초 AI MS 표준 (2023). PDCA 방법론, 리스크 관리, 인증 가능 | ISO |
-| NIST AI RMF 1.0 | AI 리스크 관리 | 자발적 프레임워크. Govern→Map→Measure→Manage. 240+ 기관 참여 | NIST |
-| NIST SP 800-53 r5 | 보안 컨트롤 | 20개 패밀리 1000+ 컨트롤. 클라우드/IoT 포함. Update 1 (2024) | NIST CSRC |
-
----
-
-## 29. 테스팅 철학 / 기초 저작
-
-| 저작 | 저자 | 연도 | 핵심 원칙 |
-|------|------|------|----------|
-| The Art of Software Testing | Glenford Myers | 1979/2011 | 성공적 테스트 = 에러를 찾는 테스트. 완전 테스트는 불가능 |
-| Lessons Learned in Software Testing | Kaner, Bach, Pettichord | 2002 | 293개 경험 기반 교훈. 맥락 중심 방법론. 위험 기반+탐색적 테스트 |
-| Growing OO Software, Guided by Tests | Freeman, Pryce | 2009 | Double Loop TDD (외부 acceptance + 내부 unit). London-style mock |
-| Rapid Software Testing | James Bach, Michael Bolton | 진행중 | 인간 중심. 경량 휴리스틱. "빠른"이 아니라 "낭비 제거" |
-| Testing vs Checking | Michael Bolton | 2009/2013 | Checking=기존 믿음 확인(자동화 가능). Testing=탐구(인간 판단 필요) |
-| Continuous Delivery | Humble, Farley | 2010 | 배포 파이프라인 = 자동화된 게이트. 체크인→릴리스 전 과정 |
-| Release It! | Michael Nygard | 2007/2018 | 안정성 패턴: Circuit Breaker, Bulkhead, Timeout, Fail Fast, Back Pressure |
-| Testing on the Toilet | Google | 2007~ | DAMP over DRY. 테스트는 읽기 쉬워야. 수백 편의 실전 조언 |
-
-### Bolton의 "Testing vs Checking" → rlp-desk에 적용
-- **Checking** (자동화 가능) = L1 unit test, L2 integration, lint, type check
-- **Testing** (인간 판단 필요) = 탐색적 테스트, UX 검증, 비즈니스 로직 타당성
-- Verifier가 하는 건 주로 checking. 진짜 testing은 사용자가 해야 함.
-- → Verifier verdict에 "checked" vs "tested" 구분 필요할 수 있음
-
----
-
-## 30. 현대 테스팅 원칙
-
-### Modern Testing 7 Principles (Alan Page, Brent Jensen)
-1. 비즈니스 개선이 최우선
-2. Lean Thinking + Theory of Constraints로 팀 가속
-3. 안전망이 아닌 지속적 개선의 힘
-4. 팀의 품질 문화에 깊이 관심
-5. 고객만이 품질을 판단할 수 있음
-6. 데이터를 광범위하게 활용
-7. 팀 전체에 테스트 능력 확산
-
-### Shift Left + Shift Right
-- **Shift Left**: 테스트를 개발 초기로 이동 → 비용 절감, 품질 향상
-- **Shift Right**: 프로덕션에서 테스트 → 실제 사용자 행동, 카나리, A/B, 피처 플래그
-- 양방향 결합: 프로덕션 텔레메트리가 개발 테스트 전략에 피드백
-
-### Chaos Engineering 5원칙 (principlesofchaos.org)
-1. 정상 상태 행동에 대한 가설 수립
-2. 실세계 이벤트 변경 (하드웨어 장애, 트래픽 급증)
-3. 프로덕션에서 실험 실행
-4. 자동화된 지속 실험
-5. 폭발 반경 최소화
-
-### Observability-Driven Testing
-- 시스템 텔레메트리(로그, 메트릭, 트레이스)로 테스트 시나리오 유도 및 검증
-- OpenTelemetry 표준. 마이크로서비스/분산 시스템에 필수
-
----
-
-## 31. 기업 QE 패턴 (추가)
-
-| 기업 | 핵심 혁신 | 규모 | 출처 |
-|------|----------|------|------|
-| Netflix | FIT(장애 주입) + ChAP(chaos 자동화) + Kayenta(카나리 통계 분석) | 수억 구독자 | netflixtechblog.com |
-| Google | Mutation testing, SRE Ch.17 테스트, TotT, 80/15/5 피라미드 | 수십억 테스트/일 | testing.googleblog.com |
-| Meta | Sapienz(자동 테스트 설계) + SapFix(자동 패치) + Rich-State(ICSE 2024: +38% 커버리지, +115% 결함) | 수만 테스트/일 | engineering.fb.com |
-| Uber | BITS(E2E 샌드박스, 사고 71% 감소) + Ballast(적응형 부하) + Testopedia(flaky 관리, 600K 테스트) | 600K Go 테스트 | uber.com/blog |
-| Microsoft | 1ES CloudTest + Flaky 관리(49K flaky 탐지) + L0-L3 분류 | 100+ 제품팀 | devblogs.microsoft.com |
-| Amazon | One-box 배포 + gamma 환경 + staggered rollout + 자동 롤백 | 글로벌 | aws.amazon.com/builders-library |
-| Slack | Project Cornflake: 자동 flaky 탐지+억제. pass rate 20%→96%. 553시간 절약 | 1185 자동 PR | slack.engineering |
-| Atlassian | Flakinator: 22K 빌드 복구, 7K unique flaky 탐지. 스택 무관 | 수백만 실행/일 | atlassian.com/blog |
-| Antithesis | 결정적 시뮬레이션 테스트. 수년 프로덕션을 수시간에. Jane Street $105M 투자 | $105M Series A | antithesis.com |
-
-### DORA 2024-2025 핵심 발견
-- AI 역설: 개인 생산량 증가(21% 더 많은 task, 98% 더 많은 PR) → 조직 전달 속도 1.5% 감소, 안정성 7.2% 감소
-- "AI는 이미 있는 것을 증폭시킨다" — 프로세스가 좋으면 좋아지고, 나쁘면 나빠짐
-- 고품질 문서를 가진 팀이 목표 달성 2x 더 높음
-- 이상적 CFR(Change Failure Rate): 0-2% (8.5%만 달성)
-- 출처: dora.dev/research/2024, dora.dev/research/2025
-
----
-
-## 32. 테스트 Anti-Pattern 전체 카탈로그 (23종)
-
-| # | 패턴 | 설명 |
-|---|------|------|
-| 1 | Liar | assertion 없이 항상 통과 |
-| 2 | Giant | 수천 줄, 수십 케이스 한 파일 |
-| 3 | Mockery | mock만 테스트 |
-| 4 | Inspector | 캡슐화 위반, 리팩터시 깨짐 |
-| 5 | Excessive Setup | 설정 수백 줄 |
-| 6 | Slow Poke | 극단적으로 느린 단위 테스트 |
-| 7 | Happy Path | 성공만 테스트, boundary/exception 없음 |
-| 8 | Generous Leftovers | 정적 메모리/DB에 상태 남김 → 연쇄 실패 |
-| 9 | Local Hero | 특정 개발 환경에서만 통과 |
-| 10 | Nitpicker | 관심 없는 부분까지 전체 출력 비교 |
-| 11 | Secret Catcher | assertion 없이 예외 발생에 의존 |
-| 12 | Greedy Catcher | 아무 예외나 통과 (의도된 예외 아닐 수 있음) |
-| 13 | Sequencer | 비순서 데이터에 순서 의존 |
-| 14 | Hidden Dependency | 미문서화된 외부 의존성 |
-| 15 | Enumerator | Test1, Test2, Test3 — 의미 없는 이름 |
-| 16 | Stranger | 프로덕션 코드와 무관한 것 테스트 |
-| 17 | OS Evangelist | 특정 OS에서만 통과 |
-| 18 | Success Against All Odds | 정확히 검증하려는 게 아니라 통과하도록 작성 |
-| 19 | Free Ride | 기존 테스트에 assertion 추가 (새 테스트 안 만듦) |
-| 20 | The One | 전체 클래스를 단일 테스트로 |
-| 21 | Peeping Tom | 행동 아닌 구현 상세 테스트 |
-| 22 | Flickering | 간헐적 pass/fail (flaky) |
-| 23 | Dead Tree | 실행 안 되거나 주석 처리된 테스트 |
-
-학술 연구: **480개 distinct test smell** 카탈로그 (2024 SBQS), 86% JUnit 테스트가 최소 1개 smell 보유
-
----
-
-## 33. Flaky Test 관리
-
-| 수치 | 출처 |
-|------|------|
-| flaky 경험 팀 비율: 10%(2022)→26%(2025) | testdino.com 벤치마크 |
-| flaky 탐지 AI 시장: $512M (2024) | 산업 리포트 |
-| 가장 흔한 원인: race condition > 네트워크 > 외부 의존성 | ACM 서베이 |
-| Google: 1.5%의 테스트가 flaky, 전체 실패의 84%가 flaky 원인 | Google Testing Blog |
-| FlakyGuard(ASE 2025): 47.6% 자동 수리, 51.8% 수용 | arXiv 2511.14002 |
-
----
-
-## 34. Emerging 패러다임
-
-### Antithesis — 결정적 시뮬레이션 테스트 (DST)
-- 모든 비결정성(클럭, 스레드 인터리빙, 난수)을 결정적으로 만듦 → 완벽 재현
-- property-based + fuzzing + 결정적 시뮬레이션 결합
-- 수년 프로덕션을 수시간에 시뮬레이션
-- Jane Street, Ethereum (The Merge 검증), MongoDB 사용
-- $105M Series A (2025, Jane Street 리드)
-
-### AI 코드 테스트 자동 생성 비교
-| 도구 | 커버리지 | 컴파일 정확도 | 방식 |
-|------|---------|------------|------|
-| Diffblue Cover | 50-69% | ~99% | 강화학습 기반 Java |
-| Copilot | 5-29% | ~65% | LLM 기반 |
-| Claude Code | 7-17% | — | LLM 기반 |
-| Qodo Cover | 프로젝트별 상이 | 높음 | agentic 기반 |
-
-### Contract Testing 심화
-| 유형 | 설명 | 도구 |
-|------|------|------|
-| Consumer-Driven (CDCT) | 소비자 기대에서 시작, 실제 사용 행동만 테스트 | Pact, Spring Cloud Contract |
-| Provider-Driven | 제공자 스키마 기반, 피드백 루프 없음 | OpenAPI, Swagger |
-| Bidirectional (BDCT) | 양쪽 계약 게시 → 제3자 매칭 | PactFlow |
-| Message Pact | 비동기 이벤트 (Kafka, RabbitMQ) | Pact Message |
-| Schema Registry | Avro/Protobuf/JSON Schema 호환성 강제 | Confluent, AWS Glue |
-
-### 추가 스킬 (skills.sh)
-| 스킬 | 설치수 | 용도 |
-|------|--------|------|
-| api-contract-testing | 283 | API 계약 테스트 |
-| static-code-analysis | 209 | 정적 분석 |
-| lint-and-validate | 148 | 린트+검증 |
-| chaos-engineer | 70 | chaos engineering |
-| qa-resilience | 63 | QA 복원력 |
-| chaos-engineering-resilience | 61 | chaos+복원력 |
-| code-review | 51 | 코드 리뷰 |
-| contract-tester | 49 | 계약 테스트 |
-
----
-
-## 35. 테스트 전략 프레임워크 / 휴리스틱
-
-| 프레임워크 | 저자 | 핵심 | 출처 |
-|-----------|------|------|------|
-| PRISMA | Erik van Veenendaal | 리스크 기반 우선순위. impact × likelihood 매트릭스 → 테스트 배분 | ctqb.org PDF |
-| HTSM v6.3 | James Bach | 4 카테고리 휴리스틱: 기법, 프로젝트 요소, 제품 요소, 품질 기준 | satisfice.com (2024.12) |
-| SBTM | Jon & James Bach | 시간 박스 탐색 세션(60-120분) + PROOF 디브리프 | satisfice.com |
-| ACC | James Whittaker/Google | Attribute(형용사) × Component(명사) × Capability(동사) 교차 매트릭스 | code.google.com |
-| TPA | TMAP | Function Point → Test Point. effort = size × strategy × productivity | tmap.net |
-| Test Heuristics Cheat Sheet | Hendrickson, Lyndsay, Emery | 2페이지 입력 유형별 공격 목록. Explore It! 부록 | ministryoftesting.com |
-| Little Black Book on Test Design | Rikard Edgren | 테스트 설계 기법 + 아이디어 무료 e-book | thetesteye.com PDF |
-
-### HTSM → rlp-desk brainstorm 흡수
-US 작성 시 4 카테고리로 검증 관점 체크:
-1. **기법**: 어떤 테스트 기법이 적합한가? (EP, BVA, state transition, 탐색적)
-2. **프로젝트**: 제약 조건은? (시간, 도구, 환경, 인력)
-3. **제품**: 어떤 품질 속성이 중요한가? (기능, 성능, 보안, 사용성)
-4. **품질 기준**: pass/fail 기준은 정량적인가?
-
----
-
-## 36. 추가 테스트 기법
-
-### Combinatorial/Pairwise Testing (NIST ACTS)
-- NIST 연구: 대부분 결함은 1-6개 파라미터 상호작용에서 발생
-- ACTS 도구: t-way covering array 생성 (t=1~6), 제약 조건 지원
-- 출처: csrc.nist.gov/projects/automated-combinatorial-testing-for-software
-
-### Model-Based Testing (GraphWalker)
-- 시스템을 directed graph로 모델링 → 경로 생성 알고리즘으로 테스트 시퀀스
-- 출처: graphwalker.github.io
-
-### Fuzzing
-| 도구 | 대상 | 특징 |
-|------|------|------|
-| OSS-Fuzz (Google) | C/C++, Rust, Go, Python, Java, JS | 13,000+ 취약점, 50,000+ 버그 발견 |
-| AFL++ | C/C++ | 커버리지 기반, AFL 후속 |
-| cargo-fuzz | Rust | libFuzzer 래퍼 |
-| Bolero | Rust | property testing + fuzzing 통합 — 하나의 테스트로 양쪽 실행 |
-
-### Symbolic Execution
-| 도구 | 대상 | 용도 |
-|------|------|------|
-| KLEE | LLVM | 모든 실행 경로 추론 → 높은 커버리지 입력 생성 |
-| angr | 다중 아키텍처 바이너리 | 바이너리 분석 + symbolic execution |
-| Mythril | Ethereum EVM | 스마트 컨트랙트 reentrancy, overflow 탐지 |
-
-### Differential Testing
-- 동일 명세의 복수 구현 비교 → 불일치 = 버그
-- oracle 없이 검증 가능
-- DLLens(2024-2025): LLM으로 딥러닝 라이브러리 차분 테스트 강화
-
-### Approval/Snapshot Testing
-- ApprovalTests: 15+ 언어 지원. 복잡한 출력(PDF, XML, 이미지)의 golden master 비교
-- pdf-visual-diff: PDF → PNG 변환 후 pixel 비교
-- 출처: approvaltests.com
-
----
-
-## 37. API 테스트 도구
-
-| 도구 | 방식 | 강점 |
-|------|------|------|
-| Hurl | plain text HTTP runner (Rust) | chaining, JSONPath assertion, CI 친화 |
-| Karate | Gherkin-like DSL | API+mock+perf+UI 통합, glue code 불필요 |
-| REST Assured | Java DSL | Hamcrest matchers, method chaining |
-| Newman (Postman) | CLI collection runner | CI/CD 파이프라인, headless 실행 |
-| Schemathesis | OpenAPI/GraphQL | property-based 자동 생성, zero per-endpoint 유지보수 |
-
-### Hurl 예시 (rlp-desk test-spec에 적합)
-```hurl
-GET https://api.example.com/users
-HTTP 200
-[Asserts]
-jsonpath "$.users" count == 10
-
-POST https://api.example.com/users
-{"name": "John"}
-HTTP 201
-[Captures]
-user_id: jsonpath "$.id"
-
-GET https://api.example.com/users/{{user_id}}
-HTTP 200
-[Asserts]
-jsonpath "$.name" == "John"
-```
-
----
-
-## 38. DevOps/SRE 테스트 통합
-
-### 배포 검증 패턴
-| 패턴 | 설명 | 위험도 |
-|------|------|--------|
-| Smoke | 핵심 경로 테스트 | 최저 |
-| Canary | 2-25% 트래픽 라우팅 + 메트릭 모니터링 | 중간 |
-| Blue-Green | 동일 환경 2개, 한 번에 전환 | 중간 |
-| Shadow | 프로덕션 트래픽 미러링 (사용자 무영향) | 최저 |
-
-### Feature Flag 테스트
-- 활성화/비활성화 양쪽 코드 경로 테스트 (37%만 체계적으로 수행)
-- 플래그 서비스 불가 시 fallback 테스트
-- 10개 플래그 = 1,024 상태 → 리스크 기반 조합 선택
-- 90일 sunset 정책 → 플래그 부채 방지
-- 출처: launchdarkly.com, yrkan.com
-
-### DB 마이그레이션 테스트
-- 스키마 검증: 컬럼, 제약조건, 인덱스, 기본값
-- 데이터 무결성: FK 생존, 타입 정확도
-- 롤백: undo 마이그레이션이 스키마를 깨끗이 복원
-- 성능: 10K 행 2초 → 100M 행 4시간 가능 → 사전 측정
-- Zero-downtime: Expand-Contract 패턴 (추가→마이그레이션→제거)
-- `flyway check -drift`: 실제 DB vs 마이그레이션 이력 불일치 탐지
-
-### Compliance as Code
-| 도구 | 용도 |
-|------|------|
-| Chef InSpec | CIS, PCI DSS, SOC2 벤치마크 프로파일 실행 |
-| OPA (Rego) | K8s admission, Terraform plan, API 인가 정책 |
-| Terratest | Go로 실제 인프라 프로비저닝→검증→파괴 |
-| Pulumi Test | TypeScript/Python/Go로 인프라 unit test |
-
----
-
-## 39. 테스트 데이터 관리
-
-### 팩토리 라이브러리
-| 언어 | 라이브러리 | 특징 |
-|------|-----------|------|
-| Python | factory_boy | Django/SQLAlchemy, SubFactory |
-| Ruby | FactoryBot | build_stubbed (DB 안 침) |
-| JS/TS | Fishery | TypeScript-first, Thoughtbot |
-| Any | Faker | 다국어 가짜 데이터 |
-
-Best practice: 결정적 seed → 재현 가능, fully random 금지, lint factory, `build` > `create`
-
-### 데이터 마스킹 (GDPR)
-- EDPB 2024: 마스킹 안 된 프로덕션 데이터 dev/test 사용 = GDPR Article 5(1)(a) 위반
-- 2024-2025 벌금: 8M-22M EUR (약한 가명처리 대상)
-
-### Testcontainers
-- 테스트당 Docker 컨테이너 생성 → 자동 정리
-- 고정 포트 금지 (CI 충돌), 이미지 버전 고정 (latest 금지)
-
----
-
-## 40. 비전통 출력 테스트
-
-| 출력 유형 | 테스트 방법 | 도구 |
-|----------|-----------|------|
-| PDF | 페이지 → PNG 변환 → pixel diff | pdf-visual-diff, Applitools |
-| Email | 가짜 SMTP 서버 → API로 수신 확인 | Mailpit (MailHog 대체), Mailtrap, MailSlurp |
-| Webhook | unique URL에 수신 → payload 검사 | webhook.site, Beeceptor, Hookdeck |
-| 로그 | caplog/structlog 캡처 → assert | pytest caplog, pytest-structlog |
-| Cron | 로직 분리 → unit test + 스케줄 모니터링 | Cronitor |
-| CSV/Excel/JSON | 생성 → 파싱 → 필드/행 assert | csv, openpyxl, JSON Schema |
-| 설정 변경 | 스키마 검증 + 행동 테스트 | ctests (USENIX) |
-
----
-
-## 41. 규제 산업 검증 프레임워크
-
-### 의약품/제약 (GAMP 5)
-소프트웨어 카테고리별 검증 강도:
-| Cat | 유형 | 리스크 | 검증 |
-|-----|------|--------|------|
-| 1 | 인프라 (OS, 방화벽) | 최저 | 설치 확인 |
-| 3 | 비설정형 COTS | 중간 | 벤더 체크 + 리스크 기반 테스트 |
-| 4 | 설정형 소프트웨어 (ERP) | 중상 | Cat3 + 프로세스/데이터 흐름 |
-| 5 | 커스텀/비스포크 | 최고 | Cat4 + 공급자 감사 + 코드 리뷰 + unit test |
-
-→ AI agent 적용: 단순 설정 변경 = Cat3, 복잡 통합 = Cat4, 신규 알고리즘 = Cat5
-
-### IQ/OQ/PQ 3단계 검증
-| 단계 | 질문 | AI agent 대응 |
-|------|------|--------------|
-| IQ (설치 검증) | 올바르게 설치됐나? | 환경 설정 검증 |
-| OQ (운영 검증) | 올바르게 동작하나? | 기능 테스트 (L1+L2) |
-| PQ (성능 검증) | 실제 조건에서 작동하나? | E2E + 부하 테스트 (L3+L4) |
-
-### 자동차 (ISO 26262 ASIL)
-| ASIL | 위험 | 커버리지 요구 |
-|------|------|-------------|
-| A | 최저 | statement coverage |
-| B | 중간 | branch coverage |
-| C | 높음 | branch + function/call |
-| D | 최고 | MC/DC coverage |
-
-→ AI agent 적용: 읽기 전용 = ASIL-A, 데이터 변경 = ASIL-B/C, 금융/보안 = ASIL-D
-
-### SOTIF (ISO 21448) — AI agent에 직접 적용 가능
-"정상 작동하지만 불충분한" 시나리오 분석:
-| 영역 | 설명 |
-|------|------|
-| 알려진 안전 | 검증 완료 |
-| 알려진 위험 | 완화 완료 |
-| 미지의 안전 | 잔여 위험 수용 |
-| 미지의 위험 | 시나리오 테스트로 축소해야 함 |
-
-→ AI agent가 "설계되지 않은 상황"을 만났을 때 어떻게 되는지 명시적으로 테스트
-
-### 금융 서비스
-**SOX 4가지 테스트 방법:** Inquiry(질문) + Observation(관찰) + Inspection(검사) + Sampling(샘플링)
-→ AI agent: (1) 결정 로직 리뷰, (2) 실행 관찰, (3) 로그/산출물 검사, (4) 독립 재실행 비교
-
-**MiFID II 알고리즘 트레이딩 5가지 필수 테스트:**
-| 테스트 | AI agent 대응 |
-|--------|--------------|
-| 지연 테스트 | API 지연 시 agent 행동 |
-| 단절 테스트 | 서비스 장애 시 복구 |
-| 오류 거래 | 롤백/취소 처리 |
-| 가격 변동 스트레스 | 비정상 입력 시 행동 |
-| 메시지율 스트레스 | 고동시성 행동 |
-스트레스 기준: **최근 6개월 최대치 × 2**
-
----
-
-## 42. 보안 테스트 심화
-
-### OWASP Testing Guide v4.2 — 91 테스트 (11 카테고리)
-정보 수집(10) + 설정 관리(8) + ID 관리(7) + 인증(10) + 인가(4) + 세션(8) + 데이터 검증(16) + 에러 처리(2) + 암호화(3) + 비즈니스 로직(9) + 클라이언트(12)
-
-### STRIDE → 테스트 매핑
-| 위협 | 보안 속성 | 테스트 |
-|------|----------|--------|
-| Spoofing | 인증 | 자격 증명 검증, 세션 토큰, 위장 시도 |
-| Tampering | 무결성 | 체크섬, 디지털 서명, 비인가 수정 |
-| Repudiation | 부인 방지 | 감사 추적 완전성, 로그 변조 탐지 |
-| Info Disclosure | 기밀성 | 암호화, 접근 제어, 정보 유출 스캔 |
-| DoS | 가용성 | 부하 테스트, 자원 고갈, rate limiting |
-| Elevation | 인가 | 권한 경계 테스트, 역할 상승 시도 |
-
-### CWE Top 25 (2024) — 상위 10
-1. XSS (CWE-79), 2. Out-of-bounds Write (CWE-787), 3. SQL Injection (CWE-89), 4. CSRF (CWE-352), 5. Path Traversal (CWE-22), 6. Out-of-bounds Read (CWE-125), 7. OS Command Injection (CWE-78), 8. Use After Free (CWE-416), 9. Missing Authorization (CWE-862), 10. Unrestricted File Upload (CWE-434)
-
----
-
-## 43. 접근성 테스트 심화
-
-### WCAG 2.2 — 4원칙 (POUR) + 86 성공 기준
-- Perceivable, Operable, Understandable, Robust
-- Level A (필수), AA (권장), AAA (이상)
-- WCAG 2.2 신규 9개: Focus Not Obscured, Dragging Movements, Target Size, Consistent Help, Redundant Entry, Accessible Auth 등
-
-### DHS Trusted Tester v5.0 — 20 테스트 절차
-키보드 접근, 폼, 링크/버튼, 이미지, 반복 콘텐츠, 구조, 언어, 대비, 테이블, 미디어 등
-
-### EN 301 549 — WCAG 넘어선 요구사항
-- 실시간 텍스트 500ms 이내, 자막 100ms 동기화, 터치 범위 380-1220mm, 대체 생체 인증
-
----
-
-## 44. 국제화/지역화 테스트
-
-### i18n 체크리스트
-- UTF-8 전 계층 (DB, API, UI, 파일)
-- 비라틴 스크립트 (아랍어, 중국어, 키릴)
-- RTL 레이아웃 + 양방향 텍스트
-- 텍스트 확장 (독일어 +20%, 일부 언어 +200-400%)
-- 날짜/시간 (MM/DD vs DD/MM vs YYYY-MM-DD, 12h vs 24h)
-- 소수점 (1,234.56 vs 1.234,56)
-- 정렬 규칙 (독일어 ü, 스페인어 ñ)
-
-### Pseudo-Localization 5가지 기법
-| 기법 | 탐지 대상 |
-|------|----------|
-| Accented chars (a→ä) | 인코딩, 폰트 |
-| 40% padding | 잘림, 오버플로우 |
-| 구분자 ^...^ | 잘림, 문자열 결합 |
-| 리소스 ID 해시 | 소스 위치 추적 |
-| 다중 스크립트 padding | 폰트 fallback |
-
----
-
-## 45. 프라이버시/GDPR 테스트
-
-### 7가지 데이터 주체 권리 테스트
-| 권리 | 테스트 |
-|------|--------|
-| 접근 | 고객이 보유 개인정보 전체를 요청/수신 가능? |
-| 정정 | 부정확 데이터 수정 가능? |
-| 삭제 | 삭제 요청 → 모든 시스템에서 완전 삭제? |
-| 제한 | 특정 처리 제한 가능? |
-| 이동성 | 읽기 가능 형식으로 내보내기? |
-| 반대 | 처리(특히 마케팅) 거부 가능? |
-| 자동 결정 | 자동 의사결정에 보호장치? |
-
-### 8-Point QA 프레임워크
-데이터 최소화, 보안 처리, 접근 제어, 삭제/보존, 동의 관리, 이동성, 암호화/익명화, 로깅/모니터링
-
----
-
-## 46. QE 도서 (2023-2026)
-
-| 도서 | 저자 | 연도 | 핵심 |
-|------|------|------|------|
-| Software Testing with Generative AI | Winteringham | 2025 | LLM으로 테스트 계획, 데이터 생성, UI 자동화, 탐색적 테스트 |
-| AI and Software Testing | Rex Black et al. | 2022 | AI 신뢰성, ML 테스트, AI 기반 자동화. Independent Press Award 수상 |
-| Guide to Software Quality Engineering | Pargaonkar | 2024 | 개발/테스트/QA 종합 가이드 |
-| Full Stack Testing | Gayathri Mohan | 2022 | 10 카테고리 40+ 도구 |
-
----
-
-## 47. 추가 스킬 (skills.sh — v3)
-
-| 스킬 | 설치수 | 용도 |
-|------|--------|------|
-| security-auditor | 336 | 보안 감사 |
-| api-contract-testing | 283 | API 계약 테스트 |
-| static-code-analysis | 209 | 정적 분석 |
-| senior-secops | 204 | SecOps |
-| lint-and-validate | 148 | 린트+검증 |
-| performance-testing | 95 | 성능 테스트 |
-| security-architect | 89 | 보안 아키텍처 |
-| chaos-engineer | 70 | chaos engineering |
-| qa-resilience | 63 | QA 복원력 |
-| flyway-migrations | 62 | DB 마이그레이션 |
-| load-test-builder | 57 | 부하 테스트 |
-| audit-expert | 46 | 감사 |
-
----
-
-## 48. 규제 산업 → AI agent 테스트 7가지 보편 패턴
-
-1. **리스크 기반 강도 조절** (GAMP Cat1-5, ASIL A-D, SOX tiers)
-   → agent 액션을 리스크별 분류, 커버리지 비례 배분
-
-2. **V-Model 추적성** (ASPICE SWE.1-6, IQ/OQ/PQ)
-   → 요구사항 → 테스트 → 결과 양방향 추적
-
-3. **다중 방법 검증** (SOX 4방법, ISO 26262 5가지)
-   → 정적 분석 + 동적 테스트 + 수동 리뷰 + 모니터링
-
-4. **시나리오 기반 안전 분석** (SOTIF 4분면, STRIDE 6위협)
-   → "미지의 위험" 영역 축소
-
-5. **필수 감사 추적** (21 CFR Part 11 60+ 항목, SOX)
-   → 모든 agent 액션 who/what/when/why/prior-state 기록
-
-6. **구체적 임계값 스트레스** (MiFID II: 6개월 최대 × 2)
-   → 과거 데이터 기반 방어 가능한 스트레스 공식
-
-7. **버전별 배포 게이트** (MiFID II, GAMP 5, ASPICE)
-   → 특정 버전의 test+approval 없이 배포 불가
-
----
-
-## 49. Best Practice 강제 — 레포 & 스킬 분석
-
-### 핵심 발견: Vercel의 Rule Template 패턴이 gold standard
-
-**vercel-labs/agent-skills** (612+ installs, 원본):
-- 66개 규칙 파일, 8개 우선순위 카테고리
-- 각 규칙: title, impact(CRITICAL/HIGH/MEDIUM/LOW), tags, INCORRECT 코드, CORRECT 코드
-- 핵심: "이것은 틀렸다(anti-pattern) → 이것이 맞다(pattern)" 대비로 강제
-
-### 4가지 강제 패턴 (rlp-desk 흡수 대상)
-
-**Pattern A: Rule Template (Vercel)**
-```yaml
-title: [규칙명]
-impact: CRITICAL | HIGH | MEDIUM | LOW
-tags: [카테고리]
-## Incorrect (anti-pattern + 코드)
-## Correct (올바른 패턴 + 코드)
-```
-→ rlp-desk: 프레임워크별 rule pack으로 test-spec에 참조 가능
-
-**Pattern B: Checklist Enforcement (affaan-m/everything-claude-code, 3.1K installs)**
-반드시 통과해야 하는 체크리스트:
-- 함수 < 50줄, 파일 < 800줄, 중첩 ≤ 4단계
-- 보안 8항목: 하드코딩 시크릿 없음, SQL injection 방지, XSS 방지, CSRF, rate limit
-- 테스트 커버리지 ≥ 80% (비협상)
-- TDD: RED→GREEN→REFACTOR
-- `any` 금지 (`unknown` 사용), `console.log` 프로덕션 금지
-→ rlp-desk: Verifier가 체크리스트 통과 여부 확인
-
-**Pattern C: Test Anatomy Rules (goldbergyoni/javascript-testing-best-practices, 24K stars)**
-테스트 구조 강제:
-- 3-part 테스트명: "[Unit] [Scenario] [Expected]"
-- AAA 패턴: Arrange / Act (1줄) / Assert (1줄)
-- Black-box만: public 메서드만 테스트
-- 현실적 데이터: Faker 사용, "foo/bar" 금지
-- 5가지 결과 테스트: 응답, 상태 변경, 외부 호출, 메시지, 관찰성
-- Stub > Mock: mock 남용 방지
-- 고정 fixture 금지: 테스트별 데이터 생성
-→ rlp-desk: Worker prompt에 테스트 작성 규칙으로 포함
-
-**Pattern D: Codebase-Derived Standards (github/awesome-copilot, 7.6K installs)**
-기존 코드베이스 분석 → 규칙 자동 생성:
-- 들여쓰기, 네이밍, 주석, 조건문, 함수 구조 패턴 추출
-- 불일치 탐지 → 소수 패턴 플래그
-- 30+ 공식 스타일 가이드 참조
-→ rlp-desk: brainstorm 시 프로젝트 분석 → 프로젝트 맞춤 규칙 생성
-
----
-
-## 50. 프레임워크별 Best Practice 레포 (강제 기준 소스)
-
-### 코딩 표준
-
-| 레포 | Stars | 언어 | 규칙 수 | 강제 방식 |
-|------|-------|------|---------|----------|
-| airbnb/javascript | 143K | JS/TS | 31 섹션 | ESLint config으로 기계 강제 |
-| goldbergyoni/nodebestpractices | 100K | Node.js | 102개 | 번호+설명+Otherwise |
-| ryanmcdermott/clean-code-javascript | 91K | JS | 함수 레벨 | INCORRECT/CORRECT 대비 |
-| faif/python-patterns | 40K | Python | 35+ 패턴 | anti-pattern 포함 (Singleton, God Object) |
-| golang-standards/project-layout | 50K | Go | 디렉토리 구조 | /src 금지, /internal 강제 |
-| alibaba/p3c | 30K | Java | 49 PMD 규칙 | IDE 플러그인 자동 검사 |
-| vercel-labs/agent-skills | — | React/Next.js | 66 규칙 | impact 분류 + 코드 대비 |
-
-### 테스트 표준
-
-| 레포 | Stars | 핵심 규칙 |
-|------|-------|----------|
-| goldbergyoni/javascript-testing-best-practices | 24K | 50+ 규칙. 3-part naming, AAA, 5 outcomes |
-| testing-library/react-testing-library | 19K | 행동 테스트, role/label 쿼리, 접근성 우선 |
-| testcontainers | 9K | 실제 컨테이너로 mock 대체 |
-
-### 인프라/DevOps 표준
-
-| 레포/도구 | 강제 방식 |
-|----------|----------|
-| OPA (Rego) | K8s admission, Terraform plan 정책 |
-| Chef InSpec | CIS/PCI/SOC2 프로파일 실행 |
-| Terratest | Go 테스트로 실제 인프라 검증 |
-| tflint | Terraform 린트 |
-
-### UI/UX 표준
-
-| 레포 | 핵심 |
-|------|------|
-| vercel-labs/web-interface-guidelines | 100+ 규칙. `<div onClick>` 금지, `aria-label` 필수, zoom 비활성화 금지 |
-| a11yproject.com/checklist | WCAG 2.2 AA 체크리스트 |
-| GOV.UK govuk-frontend | 접근성 AC 템플릿 |
-
----
-
-## 51. Vercel Web Interface Guidelines — 핵심 Anti-Pattern (Worker/Verifier에 적용)
-
-### 반드시 금지 (Verifier가 탐지)
-- `user-scalable=no` 또는 `maximum-scale=1` (zoom 비활성화)
-- `onPaste` + `preventDefault` (붙여넣기 차단)
-- `transition: all` (속성 명시 필요)
-- `outline-none` without `focus-visible` 대체
-- `<div onClick>` 또는 `<span onClick>` (반드시 `<button>`)
-- 이미지 `width`/`height` 미지정
-- 50+ 항목 `.map()` without virtualization
-- 폼 입력 `<label>` 없음
-- 아이콘 버튼 `aria-label` 없음
-- 하드코딩 날짜/숫자 포맷 (`Intl.DateTimeFormat`/`Intl.NumberFormat` 사용)
-
-### 반드시 포함 (Worker가 따름)
-- `<button>` for actions, `<a>`/`<Link>` for navigation
-- `autocomplete` + meaningful `name` on inputs
-- 에러 메시지에 해결 방법 포함
-- 비동기 업데이트 시 `aria-live="polite"`
-- 숫자 컬럼 `font-variant-numeric: tabular-nums`
-
----
-
-## 52. rlp-desk 적용: Best Practice 강제 전략
-
-### brainstorm 단계
-- 프로젝트 스택 식별 → 해당 best practice 레포 참조
-- 예: React → vercel-labs/agent-skills 66 규칙, JS → airbnb/javascript
-- Pattern D: 기존 코드 분석 → 프로젝트 맞춤 규칙
-
-### PRD 템플릿
-- AC에 해당 프레임워크 규칙 참조 필드 추가
-- 예: `standards_ref: airbnb/javascript, vercel-react-best-practices`
-
-### test-spec 템플릿
-- "Standards Compliance" 섹션 추가
-- 해당 프레임워크의 lint config 실행 명령
-- anti-pattern 탐지 grep/lint 명령
-- 예: `npx eslint --config airbnb . --max-warnings 0`
-
-### Worker prompt
-- Pattern C 테스트 규칙 포함: 3-part naming, AAA, 5 outcomes, 현실적 데이터
-- 해당 프레임워크 anti-pattern 목록 제공
-
-### Verifier prompt
-- Pattern A/B 체크리스트로 준수 여부 판단
-- anti-pattern 탐지 시 FAIL + 구체적 위반 사항 보고
-- 함수 길이, 파일 크기, 중첩 깊이 정량 체크
-
-### 추가 스킬 (skills.sh 참조)
-
-| 카테고리 | 스킬 | 설치수 |
-|---------|------|--------|
-| 아키텍처 | architecture-patterns | 9.4K |
-| 코딩 표준 | coding-standards | 3.1K |
-| Playwright E2E | playwright-testing | 435 |
-| 클린 코드 | clean-code-principles | 332 |
-| 정적 분석 | static-code-analysis | 209 |
-| Playwright 초기화 | playwright-e2e-init | 91 |
-| DevOps | devops-flow | 87 |
-| 아키텍처 설계 | architecture-design | 57 |
-| API 패턴 | implementing-api-patterns | 22 |
-
----
-
-## 53. 전체 스킬 카탈로그 (도메인별)
-
-### 코딩 표준 & 아키텍처
-| 스킬 | 설치수 | 용도 |
-|------|--------|------|
-| architecture-patterns | 9.4K | 아키텍처 패턴 |
-| write-coding-standards-from-file | 7.6K | 기존 코드에서 표준 생성 |
-| coding-standards | 3.1K | 코딩 표준 템플릿 |
-| vercel-react-best-practices | 612 | React/Next.js 66 규칙 |
-| clean-code-principles | 332 | 클린 코드 원칙 |
-| coding-standards (davila7) | 288 | 코딩 표준 |
-| architecture-design | 57 | 아키텍처 설계 |
-
-### 테스트 & QA
-| 스킬 | 설치수 | 용도 |
-|------|--------|------|
-| tdd-test-writer | 857 | TDD 테스트 작성 |
-| playwright-testing | 435 | Playwright E2E |
-| playwright-visual-testing | 336 | 시각 회귀 |
-| api-contract-testing | 283 | API 계약 테스트 |
-| static-code-analysis | 209 | 정적 분석 |
-| aj-geddes/mutation-testing | 135 | mutation testing |
-| lint-and-validate | 148 | 린트+검증 |
-| performance-testing | 95 | 성능 테스트 |
-| playwright-e2e-init | 91 | Playwright 초기화 |
-| jwilger/mutation-testing | 76 | mutation + GWT 시나리오 |
-| qa-resilience | 63 | QA 복원력 |
-| chaos-engineering-resilience | 61 | chaos engineering |
-| fast-check/testing-expert | 61 | property-based (공식) |
-| hypothesis-testing | 60 | Python property-based |
-| load-test-builder | 57 | 부하 테스트 |
-| agentic-qe/mutation-testing | 51 | 학습 기반 mutation |
-| trace-check | 47 | 요구사항 추적 |
-| contract-tester | 49 | 계약 테스트 |
-| moai-workflow-tdd | 35 | RED-GREEN-REFACTOR |
-| ralph-orchestrator/tdd | 30 | ralph TDD |
-| qe-visual-accessibility | 28 | 시각+접근성 |
-| bmad-test-strategy | 19 | TEA 테스트 전략 |
-| atdd | 7 | 2-stream ATDD |
-
-### 보안
-| 스킬 | 설치수 | 용도 |
-|------|--------|------|
-| security-auditor | 336 | 보안 감사 |
-| senior-secops | 204 | SecOps |
-| security-architect | 89 | 보안 아키텍처 |
-| chaos-engineer | 70 | chaos engineering |
-| security-audit | 29 | 보안 감사 |
-| repo-sentinel | 22 | 12-표면 보안 |
-
-### 인증 & DB
-| 스킬 | 설치수 | 용도 |
-|------|--------|------|
-| create-auth-skill | 10.6K | 인증 구현 |
-| database-design | 172 | DB 설계 |
-| oauth-implementation | 185 | OAuth |
-| flyway-migrations | 62 | DB 마이그레이션 |
-
-### 모바일
-| 스킬 | 설치수 | 용도 |
-|------|--------|------|
-| senior-mobile | 276 | 모바일 종합 |
-| flutter-development | 271 | Flutter |
-| swift-expert | 112 | Swift |
-| mobile-developer | 74 | 모바일 종합 |
-
-### 데이터 & ML
-| 스킬 | 설치수 | 용도 |
-|------|--------|------|
-| senior-data-engineer | 754 | 데이터 엔지니어링 |
-| etl-pipeline | 243 | ETL |
-| data-engineer | 208 | 데이터 엔지니어 |
-| kafka-engineer | 214 | Kafka |
-
-### DevOps & 인프라
-| 스킬 | 설치수 | 용도 |
-|------|--------|------|
-| devops-flow | 87 | DevOps 워크플로우 |
-| ops-devops-platform | 73 | DevOps 플랫폼 |
-| devops-expert | 66 | DevOps 전문가 |
-| github-workflow-automation | 66 | GitHub Actions |
-| monitoring-expert | 50 | 모니터링 |
-| scaffold | 40 | 프로젝트 스캐폴드 |
-| monitoring-observability | 32 | 관찰성 |
-| terraform-iac-expert | 28 | Terraform |
-
-### 문서화
-| 스킬 | 설치수 | 용도 |
-|------|--------|------|
-| api-changelog-versioning | 136 | API 변경 이력 |
-| project-docs | 53 | 프로젝트 문서 |
-| changelog | 47 | 변경 이력 |
-| documentation-patterns | 21 | 문서화 패턴 |
-
-### 에러 처리 & 복원력
-| 스킬 | 설치수 | 용도 |
-|------|--------|------|
-| resilience-patterns | 17 | 복원력 패턴 |
-| message-queues | 21 | 메시지 큐 |
-| microservices-patterns | 30 | 마이크로서비스 |
-
----
-
-## 54. 통합 정책 체계 — 전체 리서치를 아우르는 규칙
-
-### Tier 0: 불변 원칙 (모든 프로젝트에 적용)
-
-```
-P0-1: 검증 없는 완료는 없다
-      → 모든 US는 최소 L1(unit) + L3(E2E) 검증 필수
-      → "code inspection"은 검증이 아니다
-      → TODO/빈칸이 남은 test-spec → Verifier 무조건 FAIL
-
-P0-2: AC는 속일 수 없어야 한다
-      → Given/When/Then 형식 필수
-      → 정량적 기준 필수 (숫자, 시간, 에러율)
-      → 부정 테스트(일어나면 안 되는 것) 필수
-      → 경계값 테스트 필수
-      → 도메인 언어만 사용 (기술 용어 금지)
-
-P0-3: 테스트가 실제로 버그를 잡는지 검증한다
-      → mutation testing gate (score ≥ 60%)
-      → anti-pattern 체크: Liar, Inspector, Mockery, Tautological
-      → surviving mutant에 대응 시나리오 없으면 gaming
-
-P0-4: Worker와 Verifier는 독립적이다
-      → Verifier는 Worker의 코드를 신뢰하지 않음
-      → Acceptance test는 Worker가 수정 불가
-      → 가능하면 다른 모델/엔진 사용 (consensus)
-
-P0-5: 모든 변경은 추적 가능하다
-      → 요구사항 → AC → 테스트 → 증거 traceability
-      → 감사 추적: who/what/when/why/prior-state
-```
-
-### Tier 1: 리스크 기반 확장 (프로젝트 리스크에 따라 적용)
-
-```
-리스크 분류:
-  LOW    = 읽기 전용, 문서, 설정 (→ L1+L3)
-  MEDIUM = 기능 추가, 리팩터 (→ L1+L2+L3)
-  HIGH   = 프로덕션 배포, 데이터 변경 (→ L1+L2+L3+L4)
-  CRITICAL = 금융, 보안, 의료 (→ L1+L2+L3+L4+consensus+mutation)
-
-리스크별 확장:
-  MEDIUM+: 외부 서비스 연결 시 L2 integration 필수
-  HIGH+:   deploy verification (L4) + 롤백 테스트 필수
-  CRITICAL+: consensus verification + mutation gate + 보안 체크리스트
-```
-
-### Tier 2: 도메인별 규칙 팩 (해당 도메인 시 적용)
-
-```
-[코드]
-  → 프레임워크 best practice 참조 (Vercel 66규칙, Airbnb, goldbergyoni 등)
-  → 함수 <50줄, 파일 <800줄, 중첩 ≤4
-  → TDD: RED→GREEN→REFACTOR (단, 일반 "TDD 해" 지시는 금지 — TDAD 논문)
-  → 테스트 3-part naming, AAA 패턴, 5가지 결과 테스트
-
-[API]
-  → CRUD 상태코드 완전 매핑 (200/201/204/400/401/403/404/409/422/500)
-  → 인증/인가 negative test 필수
-  → contract test (Pact/Schemathesis)
-  → rate limit + security headers
-
-[프론트엔드/UI]
-  → 반응형 4 breakpoint (320/768/1024/1920)
-  → 접근성 WCAG 2.2 AA (contrast 4.5:1, label, keyboard)
-  → visual regression (pixel diff < 5%)
-  → Vercel anti-pattern 탐지 (<div onClick> 금지 등)
-
-[데이터 파이프라인]
-  → 입출력 row count 일치
-  → NULL 처리 + 스키마 검증
-  → 멱등성 (재실행 = 동일 결과)
-  → 알려진 입력의 정량적 출력 검증
-
-[인프라]
-  → IaC로만 (수동 변경 금지)
-  → terraform validate + plan diff + Checkov
-  → health check + 모니터링 + 알림
-  → 롤백 절차 테스트 완료
-
-[배포]
-  → smoke test (5분 이내)
-  → canary (메트릭 기반 자동 판단)
-  → 롤백 <5분 가능
-  → 이전 버전 아티팩트 보존
-
-[모바일]
-  → 최소 OS 버전 지원
-  → 오프라인 모드 + 동기화
-  → 권한 요청 시점 + 거부 시 fallback
-  → 알림 딥링크 정상 동작
-
-[보안]
-  → OWASP Top 10 / CWE Top 25 체크
-  → SAST + SCA (CVSS ≥7.0 = 0건)
-  → 하드코딩 시크릿 ZERO-TOLERANCE
-  → 보안 수정 시: PoC 재현 → 수정 → 회귀 테스트
-
-[데이터/GDPR]
-  → 7가지 주체 권리 테스트 (접근/정정/삭제/제한/이동/반대/자동결정)
-  → 테스트 데이터 마스킹/익명화
-  → 동의 관리 + 철회 동작
-
-[문서]
-  → 깨진 링크 0건
-  → 코드 예제 실행 가능
-  → API 변경 시 문서 동기화
-```
-
-### Tier 3: 검증 품질 메타 규칙 (테스트 자체의 품질)
-
-```
-Q1: 테스트는 행동을 검증한다 (구현이 아닌)
-Q2: 테스트는 독립적이다 (순서 무관, 상태 공유 없음)
-Q3: 테스트는 결정적이다 (flaky 아님)
-Q4: 테스트는 빠르다 (단위 <100ms, 통합 <5s, E2E <30s)
-Q5: 테스트는 읽기 쉽다 (DAMP > DRY, 3-part naming)
-Q6: 테스트는 현실적 데이터를 사용한다 (foo/bar 금지)
-Q7: 테스트는 5가지 결과를 검증한다 (응답/상태/외부호출/메시지/관찰성)
-
-Test Quality Score (0-100):
-  0-49: 비신뢰 → FAIL
-  50-69: 기본 → 경고 후 PASS
-  70-84: 양호 → PASS
-  85-100: 고신뢰 → PASS
-```
-
-### 적용 흐름
-
-```
-brainstorm
-  │ 프로젝트 스택 식별
-  │ 리스크 분류 (LOW/MEDIUM/HIGH/CRITICAL)
-  │ 해당 도메인 규칙 팩 선택
-  │ Given/When/Then AC 작성 + 정량 기준
-  ↓
-init
-  │ PRD: Tier 0 불변 원칙 + Tier 2 도메인 규칙 참조
-  │ test-spec: L1-L4 + 도메인별 체크리스트 + anti-pattern
-  ↓
-run
-  │ Worker: Tier 2 규칙 따라 구현+테스트
-  │ Verifier: Tier 0 + Tier 1 + Tier 3 검증
-  │  → L1-L4 실행 확인
-  │  → AC 충족 확인 (Given/When/Then)
-  │  → 테스트 품질 점수
-  │  → anti-pattern 탐지
-  │  → mutation score 체크
-  ↓
-verdict
-  │ 모든 Tier 통과 → PASS
-  │ 하나라도 실패 → FAIL + 구체적 위반 사항
-```
-
----
-
-## 55. 성공 서비스 4가지 조건 → 검증 개선안
-
-### 배경
-성공 서비스 공통 조건: 명확한 범위 설정, 풍부한 테스트 케이스, 독립적인 작업 환경, 고정된 의존성 관리.
-한계: 테스트 부족하거나 문제 정의가 모호한 소프트웨어에는 적용 어렵다.
-→ rlp-desk가 이 한계를 극복하는 도구가 되어야 한다.
-
-### 개선 1: Ambiguity Gate (범위 명확성 게이트)
-- AC Quality Score 0-12 (6차원 × 0-2점): 단일 행동, 도메인 언어, 이해관계자, 이식성, 구체적 예시, 독립성
-- 0-5: REJECT (init 차단), 6-9: WARN, 10-12: PASS
-- "잘 동작", "빠르게", "안전하게" 등 모호 형용사 탐지 → 정량 기준 요구
-- boundary case 미정의 → "경계값은?" 질문
-- 적용: brainstorm + init 전 게이트
-
-### 개선 2: Test Sufficiency Gate (테스트 충분성 게이트)
-- 공식: test_count ≥ AC_count × 3 (happy + negative + boundary 최소)
-- Per-AC 최소 3개: happy path 1 + negative 1 + boundary 1
-- happy만 있고 negative 없음 → FAIL
-- EP 커버리지 + BVA 커버리지 + Decision Table 완성도 체크
-- 적용: Verifier verdict 전 체크
-
-### 개선 3: Scope Lock Enforcement (작업 환경 격리)
-- git diff --name-only로 Worker 수정 파일 vs US 범위 대조
-- 범위 밖 파일 수정 + 정당 사유 없음 → FAIL
-- 의존성 파일(package.json 등) 변경 시 AC에 명시 여부 확인
-- 적용: Verifier scope 검증
-
-### 개선 4: Reproducibility Gate (의존성 고정 & 재현성)
-- lock 파일 존재 + 커밋 포함
-- 새 의존성 exact 버전 고정 (^/~ 아닌)
-- clean install 후 빌드 성공
-- 보안 취약점 스캔 통과
-- 테스트에 외부 네트워크 의존 없음
-- 적용: test-spec Reproducibility 섹션
-
-### 한계 극복: 모호한 프로젝트에도 적용
-```
-[모호한 요청] → [Ambiguity Gate] → [Given/When/Then 생성] → [Sufficiency Gate] → [구현+검증]
-```
-Ambiguity Gate가 모호한 입력을 명확한 AC로 변환하는 과정을 강제.
-Test Sufficiency Gate가 테스트 부족을 허용하지 않음.
-
-### 기존 정책 체계에 통합
-
-| 기존 | 개선안 | 통합 위치 |
-|------|--------|----------|
-| Tier 0 P0-2 (AC 속임 방지) | + Ambiguity Gate (점수 기반 차단) | brainstorm→init 게이트 |
-| Tier 0 P0-3 (mutation gate) | + Test Sufficiency Gate (AC×3 최소) | Verifier 체크 |
-| Tier 0 P0-4 (독립 검증) | + Scope Lock Enforcement (git diff) | Verifier scope 검증 |
-| Tier 2 도메인 규칙 | + Reproducibility Gate (lock+clean install) | test-spec 섹션 |
-
----
-
-## 56. Superpowers 스킬 분석 — rlp-desk 흡수
-
-### Iron Law 패턴
-
-모든 superpowers 스킬이 **절대 위반 불가 1줄 규칙**을 가짐:
-
-| 스킬 | Iron Law |
-|------|---------|
-| TDD | `NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST` |
-| Verification | `NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE` |
-| Debugging | `NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST` |
-
-→ rlp-desk 각 게이트에 Iron Law 적용:
-- Ambiguity Gate: `NO INIT WITHOUT AC QUALITY SCORE ≥ 6`
-- Sufficiency Gate: `NO PASS WITHOUT TEST ≥ AC × 3`
-- Layer Gate: `NO PASS WITH TODO IN ANY REQUIRED L-SECTION`
-- Verification Gate: `NO COMPLETION CLAIMS WITHOUT FRESH EVIDENCE`
-
-### Verification Before Completion — 5-Step Evidence Gate
-
-```
-1. IDENTIFY: 이 주장을 증명하는 명령어는?
-2. RUN: 명령어 실행 (fresh, complete)
-3. READ: 전체 출력, exit code, 실패 수
-4. VERIFY: 출력이 주장을 확인하는가?
-5. ONLY THEN: 주장
-```
-
-금지 패턴 (Verifier가 탐지해야 함):
-- "should pass", "probably works", "seems to" → 증거 없는 주장
-- agent "success" 보고 신뢰 → 독립 검증 필수
-- 부분 검증 → 전체 증명 아님
-- "피곤해서" / "간단해서" → 면책 아님
-
-실패 교훈 (superpowers 24건):
-- 사용자가 "I don't believe you" — 신뢰 파괴
-- 미정의 함수 배포 — 런타임 크래시
-- 요구사항 누락 배포 — 불완전 기능
-
-→ Verifier 핵심 철학: **Worker가 "done"이라고 해도 직접 실행해서 증거 수집**
-
-### TDD Iron Law — 합리화 방지 12개 패턴
-
-| 합리화 | 반박 |
-|--------|------|
-| "테스트 안 해도 될 만큼 간단" | 간단한 코드도 깨짐. 테스트 30초 |
-| "나중에 테스트 추가" | 즉시 통과하는 테스트는 아무것도 증명 안 함 |
-| "이미 수동 테스트함" | 체계적 ≠ 임시. 기록 없고 재실행 불가 |
-| "X시간 작업 삭제는 낭비" | 매몰 비용 오류. 검증 안 된 코드가 진짜 낭비 |
-| "참고로 보관하고 테스트부터" | 보관하면 적응하게 됨. 삭제 = 삭제 |
-| "탐색 먼저 필요" | 탐색 OK. 버리고 TDD로 새로 시작 |
-| "테스트 어려움 = 설계 불명확" | 테스트에 귀 기울여라. 테스트 어려움 = 사용 어려움 |
-| "TDD가 느려" | TDD > 디버깅. 실용적 = 테스트 먼저 |
-| "기존 코드에 테스트 없음" | 개선하는 중. 기존 코드에 테스트 추가 |
-| "이번만 예외" | 예외 없음 |
-| "교조적이야, 실용적으로" | TDD가 실용적임 |
-| "정신이지 의식이 아니야" | tests-after는 "이게 뭘 하지?", tests-first는 "이게 뭘 해야 하지?" |
-
-→ Worker prompt에 합리화 방지 목록 포함
-
-### Writing Plans — Bite-Sized 5-Step Task
-
-```
-Step 1: 실패 테스트 작성 (코드)
-Step 2: 실행 → 실패 확인 (명령어 + 예상 출력)
-Step 3: 최소 구현 (코드)
-Step 4: 실행 → 통과 확인 (명령어 + 예상 출력)
-Step 5: 커밋
-```
-
-각 Step = 2-5분. 정확한 파일 경로, 완전한 코드, 정확한 명령어 포함.
-"validation 추가" 같은 모호한 지시 금지 → 구체적 코드 제공.
-
-→ rlp-desk PRD의 US를 이 구조로 분해하면 Worker가 따르기 쉬움
-
-### Brainstorming — Hard Gate + Scope Decomposition
-
-```
-<HARD-GATE>
-디자인 승인 전에 어떤 구현도, 코드도, 스캐폴드도 금지
-</HARD-GATE>
-```
-
-- "간단해 보인다" → 그래도 디자인 필수 (anti-pattern으로 명시)
-- 여러 독립 서브시스템 → 세부 질문 전에 즉시 분해 제안
-- 질문은 한 번에 하나 → 여러 질문 금지
-
-→ rlp-desk brainstorm Hard Gate: AC 승인 없이 init 금지
-
-### Systematic Debugging — 4-Phase + 3회 실패 에스컬레이션
-
-```
-Phase 1: Root Cause Investigation (증거)
-Phase 2: Pattern Analysis (작동 사례와 비교)
-Phase 3: Hypothesis + Minimal Test (1변수)
-Phase 4: Implementation (테스트→수정→검증)
-
-3회 수정 실패 → 아키텍처 문제 → 사용자와 논의
-```
-
-실전 데이터: 체계적 접근 15-30분, 랜덤 수정 2-3시간
-첫 번째 수정 성공률: 95% vs 40%
-
-→ rlp-desk Fix Loop 강화: 3회 consecutive failure → 단순 수정 아닌 아키텍처 재검토
-
-### Code Review — 독립 컨텍스트 리뷰
-
-리뷰어에게 세션 히스토리가 아닌 **정제된 컨텍스트만** 전달:
-- 뭘 구현했는가 (WHAT)
-- 요구사항은 무엇인가 (PLAN)
-- git diff (BASE_SHA → HEAD_SHA)
-
-→ rlp-desk Verifier도 동일: Worker의 추론 과정이 아닌 **결과물만** 보고 검증
-
-### 통합: Superpowers 파이프라인 vs rlp-desk 파이프라인
-
-```
-Superpowers:                    rlp-desk 대응:
-brainstorming (Hard Gate)    → brainstorm (Ambiguity Gate)
-writing-plans (Bite-Sized)   → init PRD (US + AC)
-executing-plans (TDD)        → run Worker (TDD + L1-L4)
-verification-before-completion → run Verifier (Evidence Gate)
-requesting-code-review       → consensus verification
-systematic-debugging         → fix loop (3회 에스컬레이션)
-finishing-branch             → COMPLETE sentinel
-```
-
-핵심 차이: superpowers는 **현재 세션 내 단일 워크플로우**, rlp-desk는 **fresh context 반복 루프**. 하지만 Iron Law, Evidence Gate, 합리화 방지는 동일하게 적용 가능.
-
----
-
-## 57. TVER Wave 1 크롤링 결과 반영 (258개 소스)
-
-### 출처
-- 논문 14편 (P0: 8, P1: 2, P2: 4)
-- 공식 문서 13건 (Claude Code, Cursor, Copilot, Devin, Playwright, Stryker, ISTQB, OWASP 등)
-- 엔지니어링 블로그 15건 (CodeRabbit, SonarSource, Kent Beck, Meta, Sentry, Trail of Bits 등)
-- GitHub 레포 15건 (Spec Kit 81K stars, Stryker, mutmut, Qodo Cover 등)
-- Medium 201개 유효 기사
-
-### Cross-Lane Convergence (3+ lane에서 공통 확인)
-
-| 주제 | 강도 |
-|------|------|
-| TDD-first가 AI 코드 품질을 높인다 | 매우 강 (TDAD, TDFlow, Claude/Cursor/Devin 공식, Kent Beck) |
-| Mutation score > Coverage | 매우 강 (MuTAP, MutGen, Meta ACH, Sentry, Trail of Bits, Stryker/mutmut) |
-| AI 코드는 구조적으로 더 많은 결함 포함 | 강 (CodeRabbit 1.7x, SonarSource 8x 중복, Qodo 76% red zone) |
-| Multi-agent 분리가 단일 agent보다 우수 | 중 (TDFlow 4 sub-agents, Cursor find issues, Osmani dual-model) |
-
-### 기존 전략 수정 3가지
-
-**수정 1: "어떻게 TDD를 해라" → "어떤 테스트를 확인해라"**
-
-TDAD 논문 (arxiv 2603.17973):
-- 일반적 "TDD를 따르세요" 지시 → regression 악화 (6.08%→9.94%)
-- code-test dependency graph로 영향 테스트 명시 → regression 70% 감소 (1.82%)
-
-→ Worker prompt 수정: 절차적 TDD 지시 대신 "이 변경이 영향주는 테스트 목록" 제공
-→ test-spec에 `impacted tests` 필드 추가
-
-**수정 2: test-spec 5개 필수 필드 추가**
-
-```
-target behavior:   이 변경이 어떤 행동을 바꾸는가
-impacted tests:    영향받는 기존 테스트 목록
-required new tests: 반드시 추가해야 할 새 테스트
-forbidden shortcuts: 금지된 우회 (mock 남용, assertion 삭제 등)
-pass/fail evidence:  통과/실패 증거 형식
-```
-
-근거: TDAD "어떤 테스트를 확인할지 > 어떻게 TDD를 할지"
-
-**수정 3: Verification checkpoint 3단계 분리**
-
-기존: 큰 verify 1회 (per-US 또는 batch)
-개선:
-```
-Checkpoint 1: Story/Unit — 각 US 완료 시 (AC 검증)
-Checkpoint 2: Integration — 외부 서비스 연결 검증 (L2)
-Checkpoint 3: Release/Readiness — 배포 전 최종 (L3+L4)
-```
-각 checkpoint: evidence required + reviewer lane + retry condition
-
-근거: Claude Code/Cursor/Devin 공식 문서 모두 "중간 checkpoint"를 강조
-
-### 신규 추가 사항
-
-**AI 코드 정량적 결함율 기준 (CodeRabbit 2025.12)**
-- AI 코드 PR당 평균 10.83 이슈 vs 인간 6.45 (1.7x)
-- 로직/정확성 오류 75% 증가
-- 보안 취약점 2.74x
-- 가독성 문제 3x+
-→ Verifier 체크리스트에 로직 정확성, 보안, 가독성 3축 검증 추가
-
-**코드 중복 임계값 (SonarSource/GitClear)**
-- 2020-2024 5줄+ 중복 블록 8배 증가
-- 2024: 역사상 처음 중복 라인 > 리팩토링 라인
-→ test-spec quality gate에 코드 중복 임계값 추가
-
-**Mock 비율 상한선 (Medium "Mocking Everything Made Our Tests Useless")**
-- 호텔 이중 예약 버그: mock 기반 테스트 통과, 프로덕션 장애
-- mock 에러: 1주차 12건 → 12주차 203건
-- "mock이 mock과 대화하며 환상이 환상과 일치하는지 검증"
-→ test-spec에 mock 비율 상한 + integration test 최소 비율
-
-**GitHub Spec Kit (81K stars)**
-- GitHub 공식 오픈소스, spec-driven development
-- "intent가 source of truth"
-- strict TDD 강제, Copilot/Claude Code/Gemini CLI 호환
-→ rlp-desk의 전체 verification 파이프라인 참고 아키텍처
-
-**Playwright AI Agents (v1.56)**
-- Planner: 앱 탐색 → Markdown 테스트 계획
-- Generator: 계획 → 실행 가능한 테스트 파일
-- Healer: 실패한 테스트 자동 수리
-- `npx playwright init-agents --loop=claude`
-→ E2E 검증 자동화 참고
-
-**4대 AI Coding Tool 공식 TDD 권장**
-- Claude Code: "Include tests — single highest-leverage thing"
-- Cursor: "Agents perform best with clear target to iterate against"
-- Copilot: "Always validate the code it suggests"
-- Devin: "Clearly articulate your testing process"
-→ rlp-desk의 test-first spec 접근법이 업계 공식 best practice와 정렬
-
-### Gaps (다음 wave에서 보강)
-1. ATDD/BDD with AI — 학술 연구 전무
-2. Visual regression — 도구 있으나 실전 경험 보고서 부재
-3. Integration/E2E AI verification — 대부분 unit test 수준
-4. Infrastructure testing (IaC) — 별도 조사 필요
-5. DORA metrics ↔ testing quality 인과관계 — 실증 연구 부재
-
----
-
-## 58. 최종 구현 우선순위 (TVER Wave 1 반영)
-
-| 순위 | 항목 | 근거 | 변경 |
-|------|------|------|------|
-| **P0** | test-spec 5개 필수 필드 (target behavior, impacted tests, required new tests, forbidden shortcuts, pass/fail evidence) | TDAD — "어떤 테스트 > 어떻게 TDD" | **신규** |
-| **P0** | Mutation score quality gate (coverage보다 상위) | MuTAP, MutGen, Meta ACH, Sentry, Trail of Bits | 기존→강화 |
-| **P0** | L1-L4 필수 섹션 + Verifier Layer Enforcement | trading 실전 장애 + 크롤링 확인 | 유지 |
-| **P0** | Iron Laws + Evidence Gate | superpowers + 크롤링 확인 | 유지 |
-| **P0** | Verification checkpoint 3단계 분리 | Claude/Cursor/Devin 공식 + TDFlow | **신규** |
-| **P1** | Ambiguity Gate + Test Sufficiency Gate | 성공 서비스 4조건 | 유지 |
-| **P1** | Worker: "영향 테스트 컨텍스트" 제공 (TDD 절차 대신) | TDAD regression 70% 감소 | **수정** |
-| **P1** | AI 코드 결함율 체크 (로직/보안/가독성 3축) | CodeRabbit 1.7x | **신규** |
-| **P1** | Mock 비율 상한 + integration test 최소 비율 | 호텔 이중 예약 사례 | **신규** |
-| **P1** | 코드 중복 임계값 | SonarSource 8x 증가 | **신규** |
-| **P2** | Scope Lock + Reproducibility Gate | 성공 서비스 4조건 | 유지 |
-| **P2** | Anti-pattern checklist (23종) | 기존 | 유지 |
-| **P2** | Domain rule packs (10개) | 기존 | 유지 |
-| **P3** | Playwright AI agents E2E | 크롤링 발견 | **신규** |
-| **P3** | Mutahunter (LLM mutation) | 크롤링 발견 | **신규** |
-| **P3** | Spec Kit 패턴 참조 | 81K stars | **신규** |