git:20260429.be76f02 to git:20260430.6fb740f

+ > PRD/기획서를 분석하여 글로벌 보안 표준·규제에 근거한 **보안 의견서** 또는 **보안 검토 의견서**를 생성한다.

+ | 방법론 | 문서 정찰 → 위협 표면 매핑 → 표준 바인딩 → 의견/검토 생성 |

+ | 출력물 | **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 의사결정, 감사 대응, 규제 보고"

+ ```

+

+ ---

+

+ 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 (입력 문서 구조 파악)

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

+ 파일_경로: "Read 도구로 파일 내용 로드 (md, pdf 지원)"

+ Confluence_URL: "WebFetch로 페이지 본문 추출"

+ 복수_입력: "각 입력을 순차 로드 후 병합. 섹션 경계 보존"

+ Step_0_2_문서_구조_파악:

+ - "문서 유형 식별 (PRD, 설계서, API 명세, 아키텍처 문서, 기능 명세)"

+ - "섹션 목차 추출 — 의견 생성 시 섹션 단위로 대응"

+ Step_0_3_기술_스택_추론:

+ 방법: "문서 내 기술 언급, 아키텍처 다이어그램, API 명세에서 추론"

+ 추론_대상:

+ - "언어/프레임워크 (문서에 명시되지 않으면 '미특정'으로 남김)"

+ - "인프라 (AWS/GCP/Azure, K8s, 서버리스 등)"

+ - "데이터베이스 유형"

+ - "인증/인가 아키텍처 (JWT, OAuth, SAML 등)"

+ 주의: "추론된 스택은 문서 근거와 함께 명시. 근거 없는 추론 금지"

+

+ Step_0_4_도메인_감지:

+ method: "tier2-overlays/registry.yaml의 시그널 패턴을 문서 텍스트에 자연어 매칭"

+ Step_0_5_관할_감지:

+ doc_recon:

+ document_type: "PRD|설계서|API 명세|..."

+ sections: ["섹션1: 제목", "섹션2: 제목", ...]

+ features: ["기능1", "기능2", ...]

+ inferred_stack:

+ languages: ["TypeScript", ...]

+ infra: ["AWS", "K8s", ...]

+ auth: "JWT + OAuth2"

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

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

+ Step_1_1_오버레이_로드:

+ - "오버레이의 Core Architecture Questions를 위협 식별 시드로 활용"

+ 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 (표준·규제 바인딩)

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

+ Unload: "tier2-overlay 파일 (Phase 1에서 시드 추출 완료)"

+ - "도메인 × 위협 차원 조합으로 적용 표준 목록 결정"

+ - "각 표준의 requirements 중 Phase 1 위협에 해당하는 항목 추출"

+ 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

+

+ 목적: "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에서 직접 마크다운을 조립한다.

+ 위 섹션 구조를 기반으로 출력. 템플릿은 가이드일 뿐 하드 의존성이 아님.

+ Phase_3_6_로드:

+ 고정: "templates/feedback-opinion.template.md 또는 feedback-spec.template.md"

+ 합계_예상: "~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"

+ ```

+

+ ---

+

+ 올바른_접근: "PRD 범위에 충실. 누락 우려 시 별도 '범위 외 권고' 메모로 분리"

+ 올바른_접근: "도메인·위협에 매칭된 파일만 조건부 Read"

+ 설명: "소스코드를 분석하거나 코드 기반 Finding을 생성"

+ 올바른_접근: "문서 텍스트만 분석. 코드 진단은 /ch015:va로 위임"

+

+ Zero_Risk_Pretense:

+ 설명: "'이 의견을 모두 반영하면 보안 완료' 등 절대 안전 암시"

+ 올바른_접근: "Risk Acceptance 섹션으로 잔여 위험 명시. 보안은 지속적 프로세스"

+

+ MUST_Inflation:

+ 설명: "대부분의 의견을 MUST로 분류하여 과잉 설계 유도"

+ 올바른_접근: "MUST ≤ 50% 품질 게이트. 방어 심층은 SHOULD로 분류"

+

+ Orphan_Threat:

+ 설명: "위협을 식별했으나 표준 근거 없이 의견만 생성"

+ 올바른_접근: "모든 MUST/MUST NOT에 CWE/OWASP/NIST 근거 필수"

+ 출력은 코드 Finding이 아닌 **보안 의견서** 또는 **보안 검토 의견서**입니다.