Standardize: Wikified 00_Raw and consolidated 10_Wiki/Topics into P-Reinforce v3.0 clusters. Final cleanup of ghost nodes and stubs.
This commit is contained in:
+44
@@ -0,0 +1,44 @@
|
||||
# Code Review Methodology & Cognitive Process (코드 리뷰 방법론 및 인지 과정)
|
||||
|
||||
## 📌 Brief Summary
|
||||
코드 리뷰 방법론 및 인지 과정은 리뷰어가 작성자의 변경 사항을 검토할 때 거치는 심리학적 프로세스와 이를 체계화한 전략적 프레임워크를 다룹니다 [1-3]. 코드 리뷰는 단순히 버그를 찾는 행위가 아니라, 작성자의 멘탈 모델을 이해하고 팀의 표준과 비교하여 최종 수락 여부를 결정하는 고도의 '의사결정 과정(Decision-Making)'입니다 [2]. CRCM(이해 모델)과 CRDM(의사결정 모델) 등의 이론적 프레임워크는 리뷰어의 인지 부하를 줄이고 고품질의 피드백을 생성하는 데 기여합니다 [4, 5].
|
||||
|
||||
## 📖 Core Content
|
||||
|
||||
### 1. 코드 리뷰의 2단계 프로세스 (CRDM Model)
|
||||
리뷰어는 인식 기반 의사결정(RPD) 모델에 따라 두 가지 주요 단계를 거칩니다 [4, 5]:
|
||||
* **오리엔테이션 단계 (Orientation Phase):** 변경 사항의 맥락(Context), 목적(Why), 범위를 파악하는 단계입니다. 이 단계에서는 코드 자체보다 커밋 메시지, 이슈 트래커, 작성자와의 대화 등을 통해 '기대 모델'의 기초를 형성합니다 [6, 7].
|
||||
* **분석 단계 (Analytical Phase):** 형성된 기대 모델과 실제 구현(How)을 반복적으로 비교하며 평가하는 단계입니다. '구현 이해 $\rightarrow$ 구현 평가 $\rightarrow$ 전체 영향 평가 $\rightarrow$ 행동 선택(수락/수정 요청)'의 순환 과정을 거칩니다 [9, 10].
|
||||
|
||||
### 2. 리뷰 이해의 지식 계층 (CRCM Model)
|
||||
리뷰어는 Letovsky 모델을 확장하여 다음 세 가지 계층을 매핑합니다 [1, 13]:
|
||||
* **명세 계층 (Specification):** 코드가 달성해야 할 비즈니스 목표입니다.
|
||||
* **구현 계층 (Implementation):** 실제 소스 코드의 논리와 구조입니다.
|
||||
* **주석/매핑 계층 (Annotation):** 명세와 구현 사이의 연결 고리입니다. 이 연결이 모호할 때 리뷰어는 가장 큰 인지적 과부하를 겪습니다.
|
||||
|
||||
### 3. 전략적 코드 리뷰 기법 (Strategic Approaches)
|
||||
* **리뷰 청킹 (Review Chunking):** 인지 부하 관리를 위해 PR을 기능적 단위로 나누어 검토하고, 마지막에 전체 일관성을 확인하는 방식입니다 [2].
|
||||
* **이상적 모델과의 비교:** 리뷰어는 자신의 경험을 바탕으로 '이상적인 솔루션'을 머릿속에 시뮬레이션하고, 이를 실제 PR과 대조하여 격차(Gap)를 찾아냅니다 [43-45].
|
||||
|
||||
## ⚠️ Trade-offs & Caveats
|
||||
* **도구의 한계 (Tool Misalignment):** 대부분의 코드 리뷰 도구(diff view)는 '구현 계층' 분석에는 유리하지만, '오리엔테이션(맥락 파악)'에 필요한 외부 정보 연결 기능을 충분히 제공하지 않아 인지적 단절을 유발합니다 [11].
|
||||
* **경험 의존성:** CRDM은 패턴 인식에 크게 의존하므로, 새로운 도메인이나 아키텍처에 합류한 리뷰어가 효과적인 멘탈 인덱스를 구축하는 데는 상당한 시간(최대 1년)이 소요될 수 있습니다 [5].
|
||||
* **알림 피로 vs. 정밀도:** 자동화된 리뷰 도구를 병행할 때 발생하는 과도한 경고는 리뷰어의 집중력을 분산시켜 본질적인 설계 결함을 놓치게 할 수 있습니다 [17].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
### Related Concepts
|
||||
- [[Cognitive Load & Mental Models]]: 리뷰 과정에서의 작업 기억 한계와 청킹 전략의 기반이 됩니다.
|
||||
- [[Agentic Secure Code Review (에이전트 기반 보안 코드 리뷰)]]: AI 에이전트를 활용하여 인지 부하를 경감하고 의도 기반 분석을 자동화하는 기술입니다.
|
||||
- Collaboration & Knowledge Sharing: 코드 리뷰를 통한 지식 전파 및 팀 문화 형성에 관한 주제입니다.
|
||||
|
||||
### Deeper Research Questions
|
||||
- AI 기반 리뷰 어시스턴트가 제공하는 자동화된 피드백이 리뷰어의 비판적 사고와 상황 모델 구축 능력을 장기적으로 저하시키는가?
|
||||
- 오리엔테이션 단계를 강화하기 위해 IDE 내에 이슈 트래커와 설계 문서를 어떤 시각적 인터페이스로 통합해야 하는가?
|
||||
|
||||
### Practical Application Contexts
|
||||
- **Implementation:** 리뷰어의 오리엔테이션 비용을 줄이기 위해 PR 설명란에 변경의 근거와 기대 결과(Specification)를 충실히 작성해야 합니다 [7, 21].
|
||||
- **System Design:** 아키텍처 원칙을 팀 내에 명시적으로 공유하여 리뷰어가 '기대하는 모델'과 실제 구현 사이의 정렬(Alignment)을 도와야 합니다 [22, 33].
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-02*
|
||||
@@ -0,0 +1,42 @@
|
||||
# Security & Quality Engineering (보안 및 품질 공학)
|
||||
|
||||
## 📌 Brief Summary
|
||||
보안 및 품질 공학은 소프트웨어의 신뢰성을 확보하기 위해 개발 전 과정에 걸쳐 자동화된 검증 체계와 거버넌스를 구축하는 학문적/실무적 영역입니다 [1]. 이는 코드 작성 시점부터 배포 이후까지 **SAST(정적 분석)**, **DAST(동적 분석)**, **의존성 스캐닝** 등을 통합하여 보안 취약점과 저품질 코드의 유입을 원천 차단하는 **'보안의 좌측 이동(Shift-Left)'**과 **'품질 게이트(Quality Gate)'** 전략을 핵심으로 합니다 [3, 4].
|
||||
|
||||
## 📖 Core Content
|
||||
|
||||
### 1. 자동화된 보안 테스트 (Security Testing)
|
||||
* **SAST (Static Application Security Testing):** 소스 코드를 실행하지 않고 정적으로 분석하여 OWASP Top 10 취약점, 코드 스멜, 논리적 결함을 식별합니다 [1, 11].
|
||||
* **DAST (Dynamic Application Security Testing):** 실행 중인 애플리케이션에 실제 페이로드를 주입하여 런타임 환경에서의 취약점을 탐지합니다. SAST가 찾지 못하는 환경 설정 오류나 인증 우회 등을 보완합니다 [9].
|
||||
* **의존성 스캐닝 (Dependency Scanning):** 서드파티 라이브러리의 알려진 취약점(CVE)을 데이터베이스와 대조하여 관리합니다. 단순히 취약점 유무를 넘어 실제 코드 내에서의 **도달 가능성(Reachability)** 분석이 차세대 기술의 핵심입니다 [3].
|
||||
|
||||
### 2. 품질 게이트 (Quality Gate)
|
||||
* **통과/실패 기준 강제:** 새로운 코드가 병합되기 전 반드시 충족해야 하는 보안, 커버리지, 복잡도 등의 기준을 설정합니다 [2].
|
||||
* **베이스라인 관리:** 레거시 시스템 도입 시 기존 부채는 '베이스라인'으로 설정하여 무시하고, **'새로운'** 코드에 대해서만 엄격한 기준을 적용하여 점진적 개선을 유도합니다 [2, 6].
|
||||
* **피드백 루프 단축:** CI/CD 파이프라인 및 PR 워크플로우에 직접 통합되어 개발자가 IDE를 벗어나지 않고 즉각적인 수정을 할 수 있도록 돕습니다 [5, 7].
|
||||
|
||||
### 3. 지속적 통합 및 배포 (CI/CD)
|
||||
* **Pipeline as a Gatekeeper:** 품질 및 보안 스캔을 자동화된 파이프라인의 필수 단계로 설정하여, 검증되지 않은 코드가 상용 환경에 노출되는 것을 방지합니다.
|
||||
|
||||
## ⚠️ Trade-offs & Caveats
|
||||
* **Reachability의 한계:** 많은 의존성 스캔 도구가 취약한 라이브러리의 존재 여부만 알릴 뿐, 해당 코드가 실제 실행 경로에 포함되는지(Reachability) 판단하지 못해 과도한 오탐(False Positive)을 발생시킵니다 [3].
|
||||
* **알림 피로 (Alert Fatigue):** 너무 많은 경고는 개발자의 집중력을 분산시키고 도구에 대한 신뢰를 떨어뜨립니다. '의도 인지' 엔진을 통한 정밀도(Precision) 향상이 필수적입니다.
|
||||
* **인덱싱 비용:** 대규모 저장소에서 심층적인 보안 분석을 수행할 경우 리소스 소모와 빌드 시간 지연이 발생할 수 있습니다.
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
### Related Concepts
|
||||
- [[Agentic Secure Code Review (에이전트 기반 보안 코드 리뷰)]]: AI 에이전트를 활용하여 보안 분석의 정밀도를 높이고 오탐을 줄이는 기술입니다.
|
||||
- [[Software Maintenance & Evolutionary Design]]: 기술 부채 관리와 품질 게이트의 전략적 연계 방안을 다룹니다.
|
||||
- [[SDLC & SSDLC (소프트웨어 개발 생명주기)]]: 보안이 통합된 개발 생명주기(Secure SDLC)의 전체 프레임워크입니다.
|
||||
|
||||
### Deeper Research Questions
|
||||
- AI가 생성한 코드를 검증하기 위해 기존의 규칙 기반 Quality Gate는 어떤 방식으로 개선되어야 하는가?
|
||||
- 런타임 데이터(DAST)와 정적 분석 데이터(SAST)를 결합하여 보안 위협의 우선순위를 자동 결정하는 효과적인 알고리즘은 무엇인가?
|
||||
|
||||
### Practical Application Contexts
|
||||
- **Operation:** CI/CD 파이프라인에 SonarQube나 Aikido Security를 연동하여 보안 정책 위반 시 배포를 자동 차단합니다 [1, 2].
|
||||
- **Implementation:** 개발자가 IDE 내부에서 OWASP Dependency-Check 등을 활용해 취약한 라이브러리 유입을 사전에 방어합니다 [3].
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-02*
|
||||
Reference in New Issue
Block a user