Feedback

# Security Design Review — 보안 설계 리뷰 스킬
> PRD/기획서를 분석하여 글로벌 보안 표준·규제에 근거한 **보안 의견서** 또는 **보안 검토 의견서**를 생성한다.

---

## 서비스 개요

| 항목 | 내용 |
|------|------|
| 서비스명 | Security Design Review |
| 방법론 | 문서 정찰 → 위협 표면 매핑 → 표준 바인딩 → 의견/검토 생성 |
| 출력물 | **Opinion**: 섹션별 MUST/SHOULD 의견 + 코드 예시 (OP-{NNN}) |
|        | **Review**: CRITICAL~LOW 검토 Finding + 설계 가이드 (C/H/M/L-{NN}) |
| 코드 수정 | 없음 (명세·의견 생성 전용) |
| 코드 분석 | 없음 (PRD/기획서 텍스트 분석) |
| 토큰 예산 | ~22-35K (Phase별 계층 로딩) |

---

## 출력 모드

```yaml
Mode_Selection:
  opinion:
    trigger: "--mode opinion (기본값)"
    대상: "개발자, AI 코딩 도구"
    관점: "구현 가이드 — '이렇게 만들어라'"
    ID: "OP-{NNN} (001부터 순차)"
    구조: "문서 섹션별 MUST / MUST NOT / SHOULD 의견 + 코드 예시"
    용도: "Cursor, Claude Code 등에 컨텍스트로 주입하여 보안 요건 반영 코딩"

  review:
    trigger: "--mode review"
    대상: "QSA, CISO, 경영진, 개발팀"
    관점: "감사 리포트 — '이 설계의 위험은 이것이다'"
    ID: "C-{NN} / H-{NN} / M-{NN} / L-{NN}"
    구조: "Severity별 Finding + 표준 Gap 분석 + Risk Acceptance Matrix"
    용도: "Go/No-Go 의사결정, 감사 대응, 규제 보고"
```

---

## 설계 원칙

```yaml
No_Pattern_Lists:
  - "CWE/OWASP 카탈로그를 기계적으로 나열하지 않는다"
  - "PRD 컨텍스트에서 실제 관련된 표준만 바인딩"
  - "도메인·관할에 따라 적용 표준이 달라짐을 인지"

Standards_Authority:
  - "권고하는 모든 알고리즘·파라미터에 근거 표준 인용 필수"
  - "표준이 명확하면 그대로 인용 (e.g., NIST SP 800-63B §5.1.1.2)"
  - "표준 간 충돌 시 가장 엄격한 기준 채택"
  - "표준이 업데이트된 경우 최신 버전 적용 (e.g., PCI DSS 4.0.1 future-dated 2025-03-31)"

Implementation_Specificity:
  핵심: "구현자가 바로 코딩할 수 있는 수준"
  bad_examples:
    - "암호화 적용"
    - "강력한 비밀번호 정책"
    - "적절한 접근 제어"
  good_examples:
    - "AES-256-GCM envelope encryption, DEK 로테이션 365일, CMK→DEK 2-tier"
    - "bcrypt cost 12, 최소 12자, zxcvbn score ≥ 3, breached-password 사전 차단"
    - "리소스별 ABAC, policy: {action, resource, condition}, 서버사이드 enforcement"

Conservative_Judgment:
  - "규제 적용 범위 불확실 시 '적용 가능성 있음'으로 포함"
  - "'이 정도면 안전하다'는 표현 금지"
  - "법률 자문이 아닌 기술 보안 관점의 참고 정보"
```

---

## Phase 구조 (Overview)

```
Phase 0: Document Recon       → 입력 문서 구조 파악 + 기술 스택 추론 + 도메인 감지
Phase 1: Threat Surface Map   → 문서 섹션별 위협 표면 매핑 (8차원 활용)
Phase 2: Standard Binding     → 위협별 글로벌 표준/규제 바인딩
Phase 3: Opinion/Review Gen   → MUST/SHOULD 의견 또는 CRITICAL/HIGH Finding 생성
Phase 4: Code Exemplification → 수정 코드 예시 생성 (의견 모드) 또는 설계 가이드 (검토 모드)
Phase 5: Checklist Assembly   → Phase별 체크리스트 + Risk Acceptance
Phase 6: Output Formatting    → 템플릿 기반 최종 출력
```

---

## Phase 0: Document Recon (입력 문서 구조 파악)

```yaml
목적: "입력 문서를 파싱하고 보안 리뷰에 필요한 컨텍스트를 추출한다"

Step_0_1_입력_처리:
  파일_경로: "Read 도구로 파일 내용 로드 (md, pdf 지원)"
  Confluence_URL: "WebFetch로 페이지 본문 추출"
  인라인_텍스트: "사용자 메시지에서 직접 추출"
  복수_입력: "각 입력을 순차 로드 후 병합. 섹션 경계 보존"

Step_0_2_문서_구조_파악:
  추출_대상:
    - "문서 유형 식별 (PRD, 설계서, API 명세, 아키텍처 문서, 기능 명세)"
    - "섹션 목차 추출 — 의견 생성 시 섹션 단위로 대응"
    - "핵심 기능 목록 (e.g., 결제, 인증, 지갑, 관리자)"
    - "데이터 유형 (PII, 카드 정보, 암호화폐 주소, 세션 등)"
    - "사용자 유형 (일반 사용자, 판매자, 관리자, API 클라이언트)"
    - "외부 연동 (PG, 블록체인 노드, KYC 제공자, 세금 API 등)"
    - "배포 환경 힌트 (클라우드, 리전, 규모)"

Step_0_3_기술_스택_추론:
  방법: "문서 내 기술 언급, 아키텍처 다이어그램, API 명세에서 추론"
  추론_대상:
    - "언어/프레임워크 (문서에 명시되지 않으면 '미특정'으로 남김)"
    - "인프라 (AWS/GCP/Azure, K8s, 서버리스 등)"
    - "데이터베이스 유형"
    - "인증/인가 아키텍처 (JWT, OAuth, SAML 등)"
  주의: "추론된 스택은 문서 근거와 함께 명시. 근거 없는 추론 금지"

Step_0_4_도메인_감지:
  method: "tier2-overlays/registry.yaml의 시그널 패턴을 문서 텍스트에 자연어 매칭"
  주의: "코드 import가 아닌 PRD 키워드 매칭 — '결제', '지갑', '토큰', 'API 키' 등"
  override: "--domain 옵션이 있으면 자동 감지 대신 강제 적용"
  Loading_Rule: "registry.yaml만 Read. 오버레이 파일은 Phase 1에서 조건부 로드"

Step_0_5_관할_감지:
  signals:
    - "서비스 대상 국가/지역 언급"
    - "법인 소재지"
    - "데이터 저장 위치"
    - "사용자 거주 국가"
  default: "global (다중 관할 가정)"
  override: "--jurisdiction 옵션이 있으면 강제 적용"

Output:
  doc_recon:
    document_type: "PRD|설계서|API 명세|..."
    sections: ["섹션1: 제목", "섹션2: 제목", ...]
    project: "프로젝트명"
    description: "1줄 요약"
    features: ["기능1", "기능2", ...]
    data_types: ["PII", "카드 정보", ...]
    user_types: ["일반", "관리자", ...]
    integrations: ["PG", "블록체인", ...]
    inferred_stack:
      languages: ["TypeScript", ...]
      infra: ["AWS", "K8s", ...]
      auth: "JWT + OAuth2"
    domains: ["payment", "web3", ...]
    jurisdiction: "uae|kr|eu|global|..."
```

---

## Phase 1: Threat Surface Map (위협 표면 매핑)

```yaml
목적: "문서 섹션별로 보안 위협 표면을 식별하고 8대 아키텍처 차원에 매핑한다"

Step_1_1_오버레이_로드:
  절차:
    - "Phase 0에서 감지된 도메인의 tier2-overlay 파일을 Read"
    - "오버레이의 Core Architecture Questions를 위협 식별 시드로 활용"
    - "1-3개 오버레이만 로드 (토큰 예산 제약)"
  Loading_Rule: "감지된 도메인의 오버레이만 Read. 미감지 도메인 파일 로드 금지"
  Unload: "registry.yaml (Phase 0에서 사용 완료)"

Step_1_2_섹션별_위협_매핑:
  방법: |
    문서의 각 섹션(기능)을 8대 아키텍처 차원에 대해 질문한다:
      A1-인증: 이 기능에서 인증 메커니즘이 필요한가? 우회 경로는?
      A2-인가: 리소스 접근 제어가 필요한 지점은?
      A3-데이터흐름: 민감 데이터가 어디서 어디로 이동하는가?
      A4-입출력: 외부 입력 검증이 필요한 지점은?
      A5-시크릿: 키/토큰/자격증명 관리가 필요한 지점은?
      A6-의존성: 외부 서비스/라이브러리 신뢰 경계는?
      A7-에러처리: 민감 정보 노출 가능한 에러 경로는?
      A8-리소스: Rate limiting, DoS 방어가 필요한 지점은?
  참조: "knowledge-base/tier1-dimensions/a1-a8 파일은 Read하지 않는다. 차원명과 질문만 활용"

Step_1_3_위협_표면_레지스트리:
  출력_형식:
    per_section:
      section_ref: "문서 섹션 번호/제목"
      features: ["매핑된 기능"]
      threats:
        - dimension: "A1|A2|...|A8"
          threat: "위협 설명"
          data_at_risk: "위험 데이터"
          attack_scenario: "공격 시나리오 1줄"
    주의: |
      문서에서 언급하지 않는 기능에 대한 위협을 창작하지 않는다.
      위협이 식별되지 않은 차원은 기록하지 않는다 (모든 차원에 대해 위협을 억지로 채우지 않음).
```

---

## Phase 2: Standard Binding (표준·규제 바인딩)

```yaml
목적: "Phase 1에서 식별된 위협별로 적용 가능한 글로벌 표준·규제를 바인딩한다"

Step_2_1_표준_레지스트리_로드:
  action: "knowledge-base/standards/registry.yaml Read"
  내용: "도메인 → 표준 매핑 인덱스"
  Unload: "tier2-overlay 파일 (Phase 1에서 시드 추출 완료)"

Step_2_2_표준_매핑:
  절차:
    - "도메인 × 위협 차원 조합으로 적용 표준 목록 결정"
    - "매칭된 표준 YAML 파일만 조건부 Read (2-4개)"
    - "각 표준의 requirements 중 Phase 1 위협에 해당하는 항목 추출"
  Loading_Rule: "registry.yaml에서 매칭된 표준 파일만 Read. 전체 로드 금지"

Step_2_3_규제_바인딩:
  절차:
    - "관할에 따라 privacy-regulations.yaml 추가 로드"
    - "도메인별 산업 규제 적용 (결제→PCI, 금융→AML/CFT, 의료→HIPAA)"
  예시:
    jurisdiction_uae: "UAE Federal Decree-Law 45/2021 요건 추출"
    jurisdiction_eu: "GDPR 요건 추출"
    jurisdiction_kr: "개인정보보호법, 전자금융거래법 요건 추출"

Step_2_4_위협_표준_바인딩_테이블:
  출력_형식:
    per_threat:
      threat_ref: "Phase 1 위협 ID"
      section_ref: "원본 문서 섹션"
      applicable_standards:
        - standard: "PCI DSS 4.0.1"
          clause: "Req 3.5.1"
          requirement_summary: "저장 PAN 암호화"
        - standard: "NIST SP 800-175B"
          clause: "§4.2"
          requirement_summary: "AES-256 이상 대칭 암호"
      cwe_mapping: ["CWE-311", "CWE-327"]
      owasp_mapping: ["A02:2021"]
  병합_규칙:
    - "동일 위협에 복수 표준 적용 시 가장 엄격한 기준"
    - "표준 간 충돌 시 최신·최엄격 우선"
```

---

## Phase 3: Opinion/Review Generation (의견/검토 생성)

### Mode: Opinion (의견서)

```yaml
목적: "위협별 MUST / MUST NOT / SHOULD 보안 구현 의견을 생성한다"

Constraint_Levels:
  MUST:
    정의: "미준수 시 보안 목표 달성 불가"
    표기: "MUST (RFC 2119)"
    요건: "반드시 CWE/OWASP/NIST 근거 1개 이상"
    예시: "인증 토큰은 MUST 서버사이드에서 검증한다 (CWE-345, OWASP A07:2021)"
  MUST_NOT:
    정의: "실행 시 직접적 취약점 발생"
    표기: "MUST NOT (RFC 2119)"
    요건: "CWE 매핑 필수. 해당 코드 패턴이 왜 위험한지 구체 설명"
    예시: "클라이언트 제출 가격을 MUST NOT 결제 금액으로 사용한다 (CWE-472)"
  SHOULD:
    정의: "방어 심층(defense-in-depth), 베스트 프랙티스. 미준수 시 잔여 위험 증가"
    표기: "SHOULD (RFC 2119)"
    요건: "미준수 시 잔여 위험을 명시"
    예시: "API 응답에 SHOULD rate limit 헤더(X-RateLimit-*)를 포함한다 (미준수 시 클라이언트 자체 조절 불가)"

Quality_Gate:
  - "MUST에는 반드시 CWE/OWASP/NIST 근거 참조"
  - "MUST 비율 ≤ 50% (전체 의견 대비). 초과 시 SHOULD로 재분류 검토 — 과잉 설계 방지"
  - "코드 관련 MUST/MUST NOT에는 Phase 4에서 코드 예시 필수"
  - "문서 섹션 순서를 따른다. 섹션을 건너뛰지 않는다"

ID_Scheme: "OP-{NNN} (001부터 순차. 문서 섹션 순서)"

Output_Format:
  per_opinion:
    id: "OP-001"
    section_ref: "원본 문서 섹션"
    constraint: "MUST | MUST NOT | SHOULD"
    title: "의견 제목 (한글)"
    description: "의견 본문 — 무엇을, 왜, 어떤 수준으로"
    basis: "표준/규제 근거 (복수 가능)"
    cwe: "CWE-NNN (MUST/MUST NOT 필수)"
    risk_if_ignored: "미준수 시 위험 (1-2문장)"
```

### Mode: Review (검토 의견서)

```yaml
목적: "위협별 CRITICAL/HIGH/MEDIUM/LOW 보안 검토 Finding을 생성한다"

Severity_Levels:
  CRITICAL:
    정의: "Go-Live 차단. 법적 제재, 대규모 금전 손실, 인증 실패 초래"
    ID: "C-{NN}"
    시한: "출시 전 필수 해결"
    예시: "PAN 데이터 평문 저장 — PCI DSS 인증 불가"
  HIGH:
    정의: "30일 내 수정 필요. 보안 인시던트 발생 확률 높음"
    ID: "H-{NN}"
    시한: "30일"
    예시: "JWT 서명 검증 누락 — 토큰 위조 가능"
  MEDIUM:
    정의: "90일 내 권고. 보상 제어로 단기 완화 가능"
    ID: "M-{NN}"
    시한: "90일"
    예시: "API rate limiting 미설계 — DDoS 취약"
  LOW:
    정의: "개선 제안. 운영 비효율 또는 감사 지적 위험"
    ID: "L-{NN}"
    시한: "백로그"
    예시: "에러 응답에 내부 스택 트레이스 포함 가능성"

Dual_Perspective:
  QSA_view: "표준 준수 Gap 중심 — 어떤 조항을 충족하지 못하는가"
  CISO_view: "비즈니스 리스크 중심 — 이 Gap이 사업에 미치는 영향은 무엇인가"

Quality_Gate:
  - "CRITICAL은 법적/재무/인증 영향이 명확할 때만 부여"
  - "모든 Finding에 표준 근거 + 비즈니스 영향 + 권고 조치 포함"
  - "표준 준수 Gap Analysis 표 필수 (표준 × 조항 × Finding ID × 준수 상태)"
  - "Risk Acceptance 섹션 필수 (아래 Phase 5 참조)"

Output_Format:
  per_finding:
    id: "C-01 | H-01 | M-01 | L-01"
    severity: "CRITICAL | HIGH | MEDIUM | LOW"
    title: "Finding 제목 (한글)"
    section_ref: "원본 문서 섹션"
    description: "문제 설명 — QSA 관점"
    business_impact: "비즈니스 영향 — CISO 관점"
    basis: "표준/규제 근거"
    recommendation: "권고 조치 (알고리즘·파라미터 수준)"
    timeline: "수정 시한"
```

---

## Phase 4: Code Exemplification (코드 예시 / 설계 가이드)

### Mode: Opinion

```yaml
목적: "MUST/MUST NOT 의견에 잘못된 코드(❌)와 올바른 코드(✅)를 대비한다"

적용_대상: "코드 구현이 관련된 모든 MUST, MUST NOT 의견"
코드_스택: "Phase 0에서 추론된 기술 스택 기반. 미특정 시 가장 보편적 스택(TypeScript/Node.js) 사용"

Format:
  per_opinion_with_code:
    opinion_ref: "OP-NNN"
    bad_example:
      label: "❌ 위험한 구현"
      code: |
        // 클라이언트 제출 가격을 그대로 결제에 사용
        const amount = req.body.amount;
        await pg.charge({ amount, orderId });
      explanation: "공격자가 요청 body의 amount를 0으로 조작 가능 (CWE-472)"
    good_example:
      label: "✅ 권장 구현"
      code: |
        // 서버사이드에서 주문 DB 기준 금액 조회
        const order = await Order.findById(req.body.orderId);
        const amount = order.calculatedTotal; // 서버 계산 금액
        await pg.charge({ amount, orderId: order.id });
      explanation: "결제 금액은 서버가 계산한 값만 사용. 클라이언트 입력 불신"

주의:
  - "코드 예시는 핵심 로직만. 보일러플레이트, import, 에러 핸들링은 최소화"
  - "SHOULD 의견은 코드 예시 선택적 (복잡한 구현이 필요한 경우만)"
  - "프레임워크 특화 구문보다 로직 패턴을 보여준다"
```

### Mode: Review

```yaml
목적: "Finding에 대한 설계 수준 권고와 아키텍처 가이드를 제공한다"

적용_대상: "CRITICAL, HIGH Finding (MEDIUM은 선택적)"

Format:
  per_finding_with_guide:
    finding_ref: "C-01"
    design_guidance:
      current_state: "현재 설계에서의 Gap 요약"
      target_state: "달성해야 할 보안 상태"
      approach: |
        1. 토큰화 서비스 도입 (PAN → Token 매핑, 별도 PCI 스코프)
        2. DEK/CMK 2-tier envelope encryption 적용
        3. 키 로테이션 자동화 (CMK 365일, DEK 트랜잭션별)
      reference_architecture: "해당 시 아키텍처 다이어그램 텍스트 설명"
      standards_alignment: "PCI DSS 4.0.1 Req 3.5.1, NIST SP 800-57 Part 1"

주의:
  - "소스코드 수준이 아닌 아키텍처/설계 수준 가이드"
  - "구현 선택지가 여러 개면 장단점과 함께 나열"
  - "LOW Finding에는 설계 가이드 불필요 (recommendation으로 충분)"
```

---

## Phase 5: Checklist Assembly (체크리스트 + Risk Acceptance)

```yaml
목적: "의견/Finding을 실행 가능한 체크리스트로 조립하고 Risk Acceptance를 명시한다"

Step_5_1_체크리스트_생성:
  opinion_mode:
    구조:
      - "[ ] OP-001: [MUST] 인증 토큰 서버사이드 검증"
      - "[ ] OP-002: [MUST NOT] 클라이언트 제출 가격 사용"
      - "[ ] OP-003: [SHOULD] Rate limit 헤더 포함"
    정렬: "MUST → MUST NOT → SHOULD 순서. 각 그룹 내 문서 섹션 순"

  review_mode:
    구조:
      - "[ ] C-01: PAN 토큰화 미설계 — 출시 전 해결"
      - "[ ] H-01: JWT 서명 검증 누락 — 30일"
      - "[ ] M-01: API rate limiting 미설계 — 90일"
      - "[ ] L-01: 에러 응답 정보 노출 — 백로그"
    정렬: "CRITICAL → HIGH → MEDIUM → LOW 순서"

Step_5_2_Risk_Acceptance:
  필수: true
  설명: |
    "제로 리스크는 존재하지 않는다. SHOULD/MEDIUM/LOW 항목 중
     비즈니스 판단으로 수용 가능한 잔여 위험을 명시적으로 기록한다."
  포맷:
    per_accepted_risk:
      id: "OP-NNN 또는 M-NN/L-NN"
      risk_description: "수용하는 위험"
      justification: "수용 근거 (비용 대비 영향, 보상 제어 등)"
      compensating_control: "대체 완화 조치 (있는 경우)"
      review_date: "재검토 일자 (미지정 시 '다음 정기 리뷰')"
  주의:
    - "MUST / MUST NOT / CRITICAL / HIGH는 Risk Acceptance 대상이 아님"
    - "Risk Acceptance는 '빈 섹션'이 되어도 반드시 포함 (해당 없음 시 '해당 없음' 명시)"

Step_5_3_이터레이션_비교:
  trigger: "--previous <path> 옵션 제공 시"
  절차:
    - "이전 리뷰 문서를 Read"
    - "이전 의견/Finding과 현재를 ID/내용 기준 매칭"
    - "신규(NEW), 유지(UNCHANGED), 변경(CHANGED), 해결(RESOLVED) 분류"
    - "Delta Summary 섹션 추가"
  출력:
    delta_summary:
      new: ["OP-015: 신규 OAuth 스코프 관련"]
      resolved: ["OP-003: 이전 리뷰에서 지적된 세션 관련 — 설계 반영 확인"]
      changed: ["OP-007: rate limit 기준값 변경"]
      unchanged_count: 12
```

---

## Phase 6: Output Formatting (최종 출력)

```yaml
목적: "템플릿 기반으로 최종 문서를 조립하여 출력한다"

Step_6_1_템플릿_선택:
  opinion_mode: "templates/feedback-opinion.template.md (Opinion 섹션)"
  review_mode: "templates/feedback-opinion.template.md (Review 섹션, <!-- REVIEW MODE TEMPLATE --> 이후)"
  Unload: "표준 YAML (Phase 2에서 지침 추출 완료)"

Step_6_2_템플릿_렌더링:
  공통_섹션:
    - "프로젝트 메타 (이름, 일자, 버전, 입력 문서)"
    - "적용 표준 목록"
    - "문서 개요 (Phase 0 결과 요약)"
  opinion_mode_섹션:
    - "문서 섹션별 의견 (OP-NNN + 코드 예시 인라인)"
    - "체크리스트 (MUST → MUST NOT → SHOULD)"
    - "Risk Acceptance"
    - "부록: 표준 크로스 레퍼런스 (OP-ID × 표준 × 조항)"
  review_mode_섹션:
    - "Executive Summary (Severity 분포, 핵심 위험 3줄 요약)"
    - "Finding 상세 (Severity별 그룹)"
    - "표준 준수 Gap Analysis 표"
    - "체크리스트 (Severity 순)"
    - "Risk Acceptance Matrix"
    - "부록: 표준 크로스 레퍼런스 (Finding-ID × 표준 × 조항)"

Step_6_3_저장:
  opinion: "{target}/reports/ch015-{project}-{date}-opinion.md"
  review: "{target}/reports/ch015-{project}-{date}-review.md"
  fallback: "저장 경로가 없으면 출력만 수행"

Step_6_4_템플릿_미존재_시:
  절차: |
    템플릿 파일이 없으면 Phase 6에서 직접 마크다운을 조립한다.
    위 섹션 구조를 기반으로 출력. 템플릿은 가이드일 뿐 하드 의존성이 아님.
```

---

## 컨텍스트 로딩 프로토콜

```yaml
Phase_0_로드:
  고정: "이 SKILL.md (이미 로드됨)"
  조건부: "tier2-overlays/registry.yaml (도메인 감지용)"
  토큰: "~2K"

Phase_1_로드:
  조건부: "감지 도메인의 tier2-overlay 1-3개"
  언로드: "registry.yaml (Phase 0에서 사용 완료)"
  토큰: "~3-8K"

Phase_2_로드:
  고정: "standards/registry.yaml"
  조건부: "매칭 표준 YAML 2-4개"
  언로드: "tier2-overlay (Phase 1에서 시드 추출 완료)"
  토큰: "~5-10K"

Phase_3_6_로드:
  고정: "templates/feedback-opinion.template.md 또는 feedback-spec.template.md"
  언로드: "표준 YAML (Phase 2에서 지침 추출 완료)"
  토큰: "~1K"

합계_예상: "~22-35K (입력 문서 크기에 따라 변동)"

원칙:
  - "한 시점에 로드된 knowledge-base 파일은 최대 4개"
  - "Phase 완료 시 해당 Phase에서만 필요했던 파일은 결과만 보존하고 원문 해제"
  - "해제란 해당 파일의 상세 지시를 더 이상 참조하지 않고 Phase 결과만 유지하는 것"
```

---

## 옵션 및 파라미터

```yaml
Parameters:
  required:
    input: "분석 대상 문서 (파일 경로, Confluence URL, 또는 인라인 텍스트)"

  optional:
    --mode: "opinion (기본) | review"
    --domain: "도메인 강제 지정 (auto-detect 대신)"
    --jurisdiction: "관할 강제 지정 (e.g., kr, eu, uae, global)"
    --level: "essential | standard (기본) | comprehensive"
    --previous: "이전 리뷰 파일 경로 (이터레이션 비교 활성화)"
    --target: "출력 저장 디렉토리"

Usage_Examples:
  기본: "/ch015:feedback docs/prd-payment.md"
  리뷰_모드: "/ch015:feedback docs/prd-payment.md --mode review"
  도메인_강제: "/ch015:feedback docs/prd-wallet.md --domain web3"
  이터레이션: "/ch015:feedback docs/prd-v2.md --previous reports/ch015-myapp-20260401-opinion.md"
  Confluence: "/ch015:feedback https://wiki.example.com/pages/viewpage.action?pageId=12345"
```

---

## Anti-Patterns

```yaml
금지_사항:
  Pattern_Dump:
    설명: "CWE/OWASP 카탈로그를 PRD 컨텍스트 무관하게 전부 나열"
    올바른_접근: "PRD에서 실제 관련된 표준 항목만 바인딩"

  Vague_Recommendations:
    설명: "'암호화 적용', '적절한 인증' 등 구체성 없는 권고"
    올바른_접근: "알고리즘·파라미터·프로토콜 수준 명세"

  Scope_Creep:
    설명: "PRD에 없는 기능에 대한 보안 요구사항 생성"
    올바른_접근: "PRD 범위에 충실. 누락 우려 시 별도 '범위 외 권고' 메모로 분리"

  Legal_Advice:
    설명: "'이 구현으로 GDPR 준수 완료' 등 법적 판단"
    올바른_접근: "'GDPR Art.32 기준 기술적 보호조치 명세' — 법무 검토 필요 부기"

  Over_Loading:
    설명: "모든 표준 YAML을 한 번에 로드하여 토큰 낭비"
    올바른_접근: "도메인·위협에 매칭된 파일만 조건부 Read"

  Code_Analysis:
    설명: "소스코드를 분석하거나 코드 기반 Finding을 생성"
    올바른_접근: "문서 텍스트만 분석. 코드 진단은 /ch015:va로 위임"

  Zero_Risk_Pretense:
    설명: "'이 의견을 모두 반영하면 보안 완료' 등 절대 안전 암시"
    올바른_접근: "Risk Acceptance 섹션으로 잔여 위험 명시. 보안은 지속적 프로세스"

  MUST_Inflation:
    설명: "대부분의 의견을 MUST로 분류하여 과잉 설계 유도"
    올바른_접근: "MUST ≤ 50% 품질 게이트. 방어 심층은 SHOULD로 분류"

  Orphan_Threat:
    설명: "위협을 식별했으나 표준 근거 없이 의견만 생성"
    올바른_접근: "모든 MUST/MUST NOT에 CWE/OWASP/NIST 근거 필수"
```

---

## Root Cause 해당 없음

이 스킬은 기존 코드의 문제를 진단하지 않으므로 Root Cause Classification을 사용하지 않습니다.
출력은 코드 Finding이 아닌 **보안 의견서** 또는 **보안 검토 의견서**입니다.