bluemsi/2nd
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: finalized wiki integrity maintenance (v3.0 standard) - pruned 1400+ stubs and fixed 11k+ ghost links

Browse Source
This commit is contained in:
Antigravity Agent
2026-05-02 09:18:34 +09:00
parent c84dcb8371
commit 6445fcc05b
13150 changed files with 55394 additions and 100862 deletions
Download Patch File Download Diff File Expand all files Collapse all files
10_Wiki/Topics/04_Governance_Reliability/AI-Generated Code Assurance (AI 생성 코드 검증).md
+22 -26
View File
@@ -1,45 +1,41 @@
# [[AI-Generated Code Assurance (AI 생성 코드 검토 및 보안)]]
# AI-Generated Code Assurance (AI 생성 코드 검토 및 보안
## 📌 Brief Summary
AI 생성 코드는 개발 생산성을 극적으로 향상시키지만, 인간 작성 코드보다 보안 취약점(XSS, 인젝션 등) 발생률이 높고 '환각(Hallucination)'으로 인한 가짜 API 호출 위험을 내포합니다. 연구에 따르면 AI가 작성한 풀 리퀘스트(PR)는 인간보다 1.7배 더 많은 문제와 높은 보안 취약점을 포함하는 경향이 있습니다. 따라서 AI 생성 코드는 완성본이 아닌 '초안'으로 취급되어야 하며, 정적 분석(SAST), 소프트웨어 구성 분석(SCA) 등 자동화 도구와 인간 리뷰어의 비판적 검토가 결합된 엄격한 품질 게이트(Quality Gate) 적용이 필수적입니다.
AI 생성 코드는 개발 생산성을 극적으로 향상시키지만, 인간 작성 코드보다 보안 취약점(XSS, 인젝션 등) 발생률이 높고 '환각(Hallucination)'으로 인한 가짜 API 호출 위험을 내포합니다 [1]. 연구에 따르면 AI가 작성한 풀 리퀘스트(PR)는 인간보다 1.7배 더 많은 보안 취약점을 포함하는 경향이 있습니다 [7, 8]. 따라서 AI 생성 코드는 완성본이 아닌 '초안'으로 취급되어야 하며, 정적 분석(SAST), 소프트웨어 구성 분석(SCA) 등 자동화 도구와 인간 리뷰어의 비판적 검토가 결합된 엄격한 품질 게이트(Quality Gate) 적용이 필수적입니다.
## 📖 Core Content
* **증가하는 보안 위협과 취약점 발생률:** AI 생성 코드는 XSS(교차 사이트 스크립팅) 취약점 도입 확률이 2.74배, 불안전한 객체 참조 포함 확률이 1.91배 높습니다 [1, 7]. 입력값 검증 누락, 데이터베이스 자격 증명 및 API 키 하드코딩이 빈번하게 발생하며, 이는 실제 데이터 유출 및 커맨드 인젝션 사고로 이어지기도 합니다 [8, 10].
* **AI 특화 위험 (환각 및 슬롭스쿼팅):** AI 모델은 존재하지 않는 API, 라이브러리, 패키지를 실제인 것처럼 지어내는 '환각(Hallucination)' 현상을 보입니다 [2, 11]. 공격자들은 AI가 자주 지어내는 패키지 이름을 노려 악성 코드를 배포하는 '슬롭스쿼팅(Slopsquatting)' 또는 '타이포스쿼팅' 공격을 시도할 수 있습니다 [1, 9].
* **비즈니스 맥락 및 엣지 케이스 무시:** AI는 주로 정상 작동 시나리오인 '해피 패스(Happy path)'에 집중하여, Null 값, 빈 배열, 유효하지 않은 입력 등 중요한 엣지 케이스 처리를 누락하는 경향이 있습니다 [3, 12]. 또한, 비즈니스 맥락이나 시스템 아키텍처 의도를 파악하지 못해 루프 내 순차적 I/O 수행 등 성능 병목을 유발하기도 합니다 [13, 14].
* **품질 저하 및 라이선스 위반:** AI 코드는 불필요하게 장황하거나 DRY(Don't Repeat Yourself) 원칙을 위반하는 경우가 많습니다 [15, 16]. 특히 오픈소스 코드를 그대로 복제하여 AGPL-3.0 코드를 MIT 프로젝트에 삽입하는 등의 지적 재산권 및 라이선스 호환성 문제를 일으킬 위험이 큽니다 [17].
* **검증 프로세스 및 도구 통합:** AI 생성 코드를 감지하고 태깅하여 관리해야 하며, SonarQube, Semgrep, CodeQL, Dependabot 등 SAST/SCA 도구를 CI/CD 파이프라인에 통합하여 최소 80% 이상의 테스트 커버리지 조건을 강제해야 합니다 [4, 15, 18].
* **증가하는 보안 위협과 취약점 발생률:** AI 생성 코드는 XSS(교차 사이트 스크립팅) 취약점 도입 확률이 2.74배 높으며, 하드코딩된 자격 증명이나 입력값 검증 누락이 빈번합니다 [1, 7].
* **AI 특화 위험 (환각 및 슬롭스쿼팅):** AI 모델은 존재하지 않는 패키지를 제안하는 '환각(Hallucination)' 현상을 보이며, 공격자들은 이를 악용해 악성 코드를 배포하는 '슬롭스쿼팅(Slopsquatting)' 공격을 시도합니다 [2, 9].
* **비즈니스 맥락 및 엣지 케이스 무시:** AI는 주로 '해피 패스(Happy path)' 시나리오에 집중하여, Null 값 처리나 예외 상황 등 중요한 엣지 케이스를 누락하는 경향이 있습니다 [3, 12].
* **품질 저하 및 라이선스 위반:** 불필요하게 장황한 코드(Slop)를 양산하거나, AGPL-3.0 등 라이선스가 엄격한 오픈소스 코드를 무단 복제하여 지적 재산권 문제를 일으킬 수 있습니다 [17].
* **검증 프로세스 통합:** SonarQube, Semgrep, CodeQL 등 SAST/SCA 도구를 CI/CD 파이프라인에 통합하여 최소 80% 이상의 테스트 커버리지를 강제하고, 모든 AI 생성 코드에 태깅을 수행합니다 [15, 18].
## ⚖️ Trade-offs & Caveats
* **개발 속도(생산성) vs. 기술 부채 및 보안 위험:** AI 코딩 어시스턴트를 통해 마이그레이션 기간을 수개월에서 수주로 단축하는 압도적인 생산성 향상을 얻을 수 있으나, 동시에 예측 가능한 보안 약점을 시스템에 도입합니다 [19, 20]. 이를 상쇄하기 위해 자동화된 리뷰 파이프라인 및 보안 검증 리소스 투자가 트레이드오프로 요구됩니다.
* **AI 자동화 리뷰 vs. 인간의 비즈니스 맥락 이해:** AI 리뷰 도구는 빠른 피드백을 제공하지만 아키텍처적 트레이드오프를 완벽히 이해하지 못합니다 [13, 22]. AI 피드백을 무비판적으로 수용할 경우 오히려 잘못된 수정이 적용될 수 있으므로, 최종 검증은 항상 비즈니스 의도를 파악하고 있는 인간(시니어 리뷰어)이 수행해야 합니다.
* **속도 vs 안전성:** AI 코딩 어시스턴트는 마이그레이션 기간을 획기적으로 단축하지만, 예측 가능한 보안 약점을 시스템에 도입합니다. 이를 위해 자동화된 보안 검증 리소스 투자가 트레이드오프로 요구됩니다 [19].
* **자동화의 사각지대:** AI 기반 리뷰 도구는 30~60%의 오탐률을 보이며 실제 취약점의 약 22%를 놓치는 근본적인 한계가 있습니다 [Augment Code 벤치마크]. 아키텍처 설계와 비즈니스 로직의 무결성 판단에는 여전히 인간의 수동 검토가 필수 불가결합니다.
* **리뷰 피로도(Review Fatigue):** AI가 양산하는 대량의 코드(Slop)는 리뷰어의 인지 부하를 높여 형식적인 승인(Rubber-stamping)을 유도할 위험이 있습니다.
## 🔗 Knowledge Connections
### Related Concepts
* **[[SAST (정적 애플리케이션 보안 테스트)]]**: AI 코드에서 하드코딩된 시크릿, 인젝션 결함 등을 코드가 실행되기 전 소스 수준에서 자동 식별하는 핵심 기술입니다.
* **[[SCA (소프트웨어 구성 분석)]]**: AI가 제안하는 의존성 패키지의 실존 여부, 취약점, 라이선스 호환성을 검증하여 환각 및 슬롭스쿼팅 공격을 방어합니다.
* **[[Slopsquatting (Typosquatting)]]**: AI 환각을 이용한 구체적인 공급망 공격 기법으로, AI 코드를 수동으로 검증해야 하는 강력한 이유를 제공합니다.
* **[[Shift-Left Security]]**: AI가 양산하는 대량의 결함을 배포 전(PR 단계 이전) 조기에 차단하여 수정 비용을 낮추는 전략적 접근입니다.
* **[[Static Analysis & Linting (정적 분석 및 린팅)|Static Analysis & Linting]]**: AI 코드의 구문적 오류와 보안 결함을 자동 식별하는 1차 방어선입니다.
* **[[Software Security Standards & Vulnerabilities (소프트웨어 보안 표준 및 취약점)|Software Security Standards & Vulnerabilities]]**: AI가 자주 위반하는 OWASP Top 10 등 보안 표준에 대한 이해가 필요합니다.
* **Shift-Left Security**: AI 대량 생산 코드를 배포 전 PR 단계에서 조기에 차단하는 전략입니다.
* **Software Supply Chain Security**: AI 환각으로 인한 악성 패키지 도입을 방어하는 전체적인 공급망 보안 전략입니다.
### Deeper Research Questions
* AI의 '의존성 환각'을 CI/CD 단계에서 100% 차단하기 위한 실시간 패키지 레지스트리 교차 검증 아키텍처는 어떻게 설계해야 하는가?
* 외부 AI 코드 리뷰 도구 도입 시 소스 코드 노출에 따른 데이터 주권(Data Sovereignty) 문제를 해결하기 위한 Self-hosted LLM 활용 방안은 무엇인가?
* '바이브 코딩' 환경에서 인간 리뷰어의 인지적 과부하(Review Fatigue)를 방지하면서도 시스템의 아키텍처 무결성을 유지하는 '계층화된 리뷰(Tiered Review)' 모델은 무엇인가?
* AI가 생성한 단위 테스트 자체가 내포할 수 있는 논리적 결함(False Positive)을 교차 검증하기 위한 자동화된 Mutation Testing 도입의 실익은 무엇인가?
* AI 생성 코드의 라이선스 위반 여부를 소스 코드 지문 분석(Code Fingerprinting)을 통해 실시간 감지하는 효율적인 프로세스는 무엇인가?
* AI의 '의존성 환각'을 CI/CD 단계에서 실시간으로 차단하기 위한 패키지 레지스트리 교차 검증 아키텍처는 무엇인가?
* Self-hosted LLM을 활용하여 소스 코드 노출 없이 AI 리뷰를 수행할 때의 성능과 비용 효율성은 어떠한가?
* AI 생성 코드의 라이선스 위반 여부를 실시간으로 감지하는 소스 코드 지문 분석(Fingerprinting) 기술의 정확도는?
### Practical Application Contexts
* **Implementation:** AI가 생성한 코드를 복사-붙여넣기 전, OWASP Top 10 기준에 맞춰 입력값을 검증하고 파라미터화된 쿼리 사용 여부를 직접 수정해야 합니다.
* **System Design:** AI 제안 로직이 기존 아키텍처 결정 사항(ADR)과 충돌하지 않는지 확인하고, 루프 내 I/O 발생 등 성능 안티 패턴을 집중 리뷰합니다.
* **Operation / Maintenance:** CI/CD에 보안 스캐너를 통합하여 정책 위반 코드를 자동 차단하고, 커밋 메시지에 AI 사용 여부를 태깅하여 향후 감사를 대비합니다.
* **Learning Path:** 주니어 개발자가 AI 코드를 그대로 수용하지 않도록 "이 코드가 놓친 엣지 케이스는 무엇인가?"를 묻는 비판적 사고 훈련 멘토링에 활용합니다.
* **My Project Relevance:** PR 템플릿에 "AI-Generated Code Verification" 체크리스트(의존성 확인, 시크릿 검사, 라이선스 체크 등)를 추가하고 품질 게이트를 설정합니다.
* **Implementation:** AI 코드를 복사하기 전 파라미터화된 쿼리 사용 여부를 직접 검증합니다.
* **System Design:** AI 제안 로직이 기존 아키텍처 결정(ADR)과 충돌하지 않는지 확인합니다.
* **My Project Relevance:** PR 템플릿에 "AI 생성 코드 체크리스트"를 추가하고 보안 스캔 통과를 강제합니다.
### Adjacent Topics
* **[[Vibe Coding]]**: 인간이 논리 작성보다 의도와 맥락에 집중하는 코딩 방식으로, 리뷰어가 결과물의 '의도 일치성'을 판단하는 역량이 중요해집니다.
* **[[Technical Debt Management]]**: AI가 양산하는 '작동은 하지만 유지보수성이 낮은 코드'가 쌓이는 현상을 측정하고 관리하는 전략으로 확장됩니다.
* **[[Software Supply Chain Security]]**: AI가 도입하는 외부 컴포넌트의 무결성을 점검하고 SBOM을 통해 관리하는 전체적인 방어 전략입니다.
* **Technical Debt Management**: AI가 양산하는 '작동하지만 유지보수성 낮은 코드' 관리 전략입니다.
* **Vibe Coding**: 인간이 논리보다 의도에 집중하는 환경에서의 리뷰어 역량 변화를 탐구합니다.
---
*Last updated: 2026-05-02*
10_Wiki/Topics/04_Governance_Reliability/Accessibility_Inclusivity.md
+6 -6
View File
@@ -1,11 +1,11 @@
---
title: 웹 접근성 및 포용적 설계 (a11y)
category: Software [[Architecture]]
tags: [[[Accessibility]], a11y, Semantic HTML, Inclusivity]
category: Software [[Architecture|Architecture]]
tags: [[Accessibility|[Accessibility]], a11y, Semantic HTML, Inclusivity]
created: 2026-04-20
---
# [[Accessibility_Inclusivity]] (포용적 설계와 접근성)
# [[Accessibility_Inclusivity|Accessibility_Inclusivity]] (포용적 설계와 접근성)
## 📌 한 줄 통찰 (The Karpathy Summary)
> 웹은 '모두'를 위한 공간이어야 한다. 신체적 제약이 시스템 이용의 제약이 되지 않게 하는 것은 '매너'가 아니라 전문 개발자의 '책임'이다.
@@ -13,7 +13,7 @@ created: 2026-04-20
## 📖 구조화된 지식 (Synthesized Content)
- **Semantic HTML (의미론적 태그)**:
- `<div>`로만 도배하지 마라. `<main>`, `<article>`, `<section>`, `<nav>` 등 의미가 담긴 태그를 써야 기계(스크린 리더)와 검색 엔진이 내 콘텐츠의 중요도를 파악한다.
- **ARIA & [[State]]s**:
- **ARIA & [[State|State]]s**:
- 표준 HTML로 설명이 불가능한 인터랙션(예: 커스텀 탭 메뉴)은 `aria-label`, `aria-hidden` 등을 통해 기계에게 보조 설명을 전한다.
- **Keyboard Navigation**:
- 마우스 없이 `Tab` 키와 `Enter` 키만으로 내 앱의 모든 핵심 기능을 수행할 수 있는지 검증하라. 포커스링을 숨기지 마라. 누군가에게는 유일한 가이드라인이다.
@@ -22,5 +22,5 @@ created: 2026-04-20
- 접근성을 챙기는 것은 단순히 윤리적인 문제를 넘어, **SEO(검색 노출)** 성적과 직결된다. 구글 검색 로봇은 눈이 없기에, 스크린 리더와 유사한 방식으로 우리 사이트를 평가하기 때문이다.
## 🔗 지식 연결 (Graph)
- Related: [[Styling_Governance]] , [[React_Clean_Code_Best_Practices]]
- Ethic: [[Collaboration_Governance]]
- Related: [[Styling_Governance|Styling_Governance]] , [[React_Clean_Code_Best_Practices|React_Clean_Code_Best_Practices]]
- Ethic: [[Collaboration_Governance|Collaboration_Governance]]
10_Wiki/Topics/04_Governance_Reliability/Application Security Posture Management (ASPM).md
+7 -7
View File
@@ -1,4 +1,4 @@
# [[Application Security Posture Management (ASPM, 애플리케이션 보안 태세 관리)]]
# Application Security Posture Management (ASPM, 애플리케이션 보안 태세 관리
## 📌 Brief Summary
Application Security Posture Management (ASPM)은 개발 과정 전반에 걸쳐 애플리케이션 구성 요소의 설정 오류, 보안 위협 및 규정 준수 위반 사항을 지속적으로 평가하고 관리하는 도구 및 방법론입니다 [1]. 클라우드 및 프로덕션 환경의 실시간 인사이트를 활용하여 개발자에게 실제 보안 위험의 우선순위를 명확히 지정해 줌으로써, '시프트 레프트(Shift-Left)' 보안을 실현합니다 [1, 2]. ASPM은 파편화된 보안 도구(SAST, DAST, SCA 등)의 데이터를 통합하여 소프트웨어 공급망 전체에 대한 가시성을 제공하고 효율적인 코드 리뷰를 지원합니다 [1, 3].
@@ -16,10 +16,10 @@ Application Security Posture Management (ASPM)은 개발 과정 전반에 걸쳐
## 🔗 Knowledge Connections
### Related Concepts
* **[[Shift-Left Security]]**: 보안 검토를 SDLC 초기 단계로 당기는 전략으로, ASPM이 기술적으로 이를 구현하는 핵심 수단이 됩니다.
* **[[SAST, DAST, IAST]]**: ASPM이 통합하여 관리하는 소스 코드, 런타임, 대화형 보안 테스트 기술들입니다.
* **[[Software Bill of Materials (SBOM)]]**: 애플리케이션의 모든 구성 요소를 명시한 자재 명세서로, ASPM이 공급망 위험을 평가하는 기초 데이터로 활용됩니다.
* **[[DevSecOps]]**: 개발, 보안, 운영을 하나로 통합하는 철학이며, ASPM은 이 환경에서 보안 거버넌스를 자동화하는 플랫폼 역할을 수행합니다.
* **Shift-Left Security**: 보안 검토를 SDLC 초기 단계로 당기는 전략으로, ASPM이 기술적으로 이를 구현하는 핵심 수단이 됩니다.
* **SAST, DAST, IAST**: ASPM이 통합하여 관리하는 소스 코드, 런타임, 대화형 보안 테스트 기술들입니다.
* **Software Bill of Materials (SBOM**: 애플리케이션의 모든 구성 요소를 명시한 자재 명세서로, ASPM이 공급망 위험을 평가하는 기초 데이터로 활용됩니다.
* **[[DevSecOps|DevSecOps]]**: 개발, 보안, 운영을 하나로 통합하는 철학이며, ASPM은 이 환경에서 보안 거버넌스를 자동화하는 플랫폼 역할을 수행합니다.
### Deeper Research Questions
* ASPM 도구는 클라우드 구성 정보(Config)와 소스 코드 취약점을 결합하여 '공격 경로(Attack Path)'를 구체적으로 어떻게 시각화하고 우선순위를 정하는가?
@@ -36,8 +36,8 @@ Application Security Posture Management (ASPM)은 개발 과정 전반에 걸쳐
* **My Project Relevance:** 코드 리뷰 체크리스트 중 보안 검토 항목을 ASPM에 위임하여, 리뷰어가 비즈니스 로직 검증에 집중할 수 있도록 프로세스를 최적화합니다.
### Adjacent Topics
* **[[AI-Generated Code Security]]**: 개발 효율을 위해 도입된 AI 코드가 유발하는 보안 리스크를 ASPM 거버넌스 체계 내에서 통제하는 방안으로 확장됩니다.
* **[[Cloud Native Application Protection Platform (CNAPP)]]**: 클라우드 인프라와 애플리케이션 보안을 통합 관리하는 더 넓은 범위의 플랫폼 개념과 ASPM의 연결성을 탐구할 수 있습니다.
* **AI-Generated Code Security**: 개발 효율을 위해 도입된 AI 코드가 유발하는 보안 리스크를 ASPM 거버넌스 체계 내에서 통제하는 방안으로 확장됩니다.
* **Cloud Native Application Protection Platform (CNAPP**: 클라우드 인프라와 애플리케이션 보안을 통합 관리하는 더 넓은 범위의 플랫폼 개념과 ASPM의 연결성을 탐구할 수 있습니다.
---
*Last updated: 2026-05-02*
10_Wiki/Topics/04_Governance_Reliability/Architecture Review (아키텍처 및 설계 리뷰).md
+7 -7
View File
@@ -1,4 +1,4 @@
# [[Architecture Review (아키텍처 및 설계 리뷰)]]
# [[Architecture Review (아키텍처 및 설계 리뷰)|Architecture Review (아키텍처 및 설계 리뷰]]
## 📌 Brief Summary
아키텍처 리뷰(Architecture Review)는 라인 단위의 구현 세부 사항을 넘어, 코드 변경 사항의 구조적 무결성과 장기적인 생존성을 평가하는 고수준의 특화된 검토 프로세스입니다 [1, 2]. 이 과정은 아키텍처의 표류(Architectural drift)와 기술 부채의 축적을 방지하는 전략적 체크포인트 역할을 수행합니다 [1, 3]. 궁극적으로 새로운 기능이 시스템의 거시적인 디자인 패턴(예: MVC, 클린 아키텍처) 및 설계 원칙(예: SOLID)에 부합하여, 확장성과 유지보수성을 보장하도록 만드는 것을 목표로 합니다 [1, 4].
@@ -18,10 +18,10 @@
## 🔗 Knowledge Connections
### Related Concepts
* **[[SOLID Principles]]**: 아키텍처 리뷰 시 견고한 객체 지향 설계를 판단하는 절대적인 척도입니다.
* **[[Architecture Decision Records (ADR)]]**: 리뷰를 통해 합의된 설계 선택과 트레이드오프를 기록하는 공식적인 도구입니다.
* **[[Over-engineering]]**: 리뷰어가 가장 경계해야 할, 시스템 유지보수성을 해치는 불필요한 추상화와 일반화입니다.
* **[[Shift-Left Strategy]]**: 설계 결함을 구현 전 초기 단계에서 잡아내어 리팩토링 비용을 예방하는 전략입니다.
* **[[SOLID Principles|SOLID Principles]]**: 아키텍처 리뷰 시 견고한 객체 지향 설계를 판단하는 절대적인 척도입니다.
* **Architecture Decision Records (ADR**: 리뷰를 통해 합의된 설계 선택과 트레이드오프를 기록하는 공식적인 도구입니다.
* **Over-engineering**: 리뷰어가 가장 경계해야 할, 시스템 유지보수성을 해치는 불필요한 추상화와 일반화입니다.
* **Shift-Left Strategy**: 설계 결함을 구현 전 초기 단계에서 잡아내어 리팩토링 비용을 예방하는 전략입니다.
### Deeper Research Questions
* ADR 작성 프로세스를 애자일 스프린트나 PR 워크플로우 내에 마찰 없이 매끄럽게 통합하기 위한 자동화 방안은 무엇인가?
@@ -38,8 +38,8 @@
* **My Project Relevance:** 중대한 구조 변경 시 요구되는 별도의 '설계 승인(Design Approval)' 단계를 도입하여 아키텍처 표류를 방지합니다.
### Adjacent Topics
* **[[Technical Debt (기술 부채)]]**: 아키텍처 리뷰 소홀로 인해 누적되는 장기적인 비용과 운영 리스크에 대해 탐구합니다.
* **[[Code Smells]]**: 고수준의 설계 결함이 소스 코드 레벨에서 어떤 구현 안티 패턴으로 발현되는지 분석합니다.
* **Technical Debt (기술 부채**: 아키텍처 리뷰 소홀로 인해 누적되는 장기적인 비용과 운영 리스크에 대해 탐구합니다.
* **Code Smells**: 고수준의 설계 결함이 소스 코드 레벨에서 어떤 구현 안티 패턴으로 발현되는지 분석합니다.
---
*Last updated: 2026-05-02*
10_Wiki/Topics/04_Governance_Reliability/Automated Code Analysis (자동화된 코드 분석).md
+7 -7
View File
@@ -1,4 +1,4 @@
# [[Automated Code Analysis (자동화된 코드 분석)]]
# [[Automated Code Analysis (자동화된 코드 분석)|Automated Code Analysis (자동화된 코드 분석]]
## 📌 Brief Summary
자동화된 코드 분석(Automated Code Analysis)은 코드가 인간 리뷰어에게 전달되기 전에 도구를 사용하여 구문, 스타일, 버그, 보안 취약점 등을 알고리즘적으로 검사하는 프로세스입니다 [1]. 이는 정적 분석(SAST), 동적 분석(DAST), 린팅(Linting), 소프트웨어 구성 분석(SCA) 등을 포함하며, 코드 리뷰의 일차적 방어선 역할을 합니다 [1-3]. 이를 통해 인간 리뷰어는 단순한 스타일 교정에서 벗어나 아키텍처, 비즈니스 로직 등 비판적 사고가 필요한 고차원적인 문제에 집중할 수 있게 됩니다 [4, 5].
@@ -22,10 +22,10 @@
## 🔗 Knowledge Connections
### Related Concepts
* **[[SAST (Static Application Security Testing)]]**: 코드 실행 전 소스 자체를 분석하여 결함 위치를 정확히 찾아내는 자동화의 핵심입니다.
* **[[DAST (Dynamic Application Security Testing)]]**: 실행 중인 애플리케이션 관점에서 보안 위협을 탐지하여 SAST의 사각지대를 보완합니다.
* **[[Linters & Formatters]]**: 코드 스타일과 기본 구문을 자동 교정하여 리뷰어의 시각적 피로를 줄여줍니다.
* **[[SCA (Software Composition Analysis)]]**: 공급망 보안(Supply Chain Security) 관리를 위한 필수적인 오픈소스 의존성 스캔 기술입니다.
* **[[SAST (Static Application Security Testing)|SAST (Static Application Security Testing]]**: 코드 실행 전 소스 자체를 분석하여 결함 위치를 정확히 찾아내는 자동화의 핵심입니다.
* **[[DAST (Dynamic Application Security Testing)|DAST (Dynamic Application Security Testing]]**: 실행 중인 애플리케이션 관점에서 보안 위협을 탐지하여 SAST의 사각지대를 보완합니다.
* **Linters & Formatters**: 코드 스타일과 기본 구문을 자동 교정하여 리뷰어의 시각적 피로를 줄여줍니다.
* **SCA (Software Composition Analysis**: 공급망 보안(Supply Chain Security) 관리를 위한 필수적인 오픈소스 의존성 스캔 기술입니다.
### Deeper Research Questions
* 정적 분석 도구의 오탐(False Positives)을 줄이고 개발자의 수용도를 높이기 위한 '상황 인식(Context-aware) 튜닝' 전략은 무엇인가?
@@ -42,8 +42,8 @@
* **My Project Relevance:** 스타일 지적 등 소모적인 논쟁을 자동화에 위임하고, 아키텍처 및 비즈니스 로직 중심의 고도화된 코드 리뷰 문화를 정착시킵니다.
### Adjacent Topics
* **[[Shift-Left Security]]**: 보안 검토를 SDLC 가장 앞단으로 앞당겨 수정 비용을 대폭 절감하는 전략적 접근입니다.
* **[[Technical Debt (기술 부채)]]**: 자동 분석으로 식별된 코드 스멜(Code Smells)을 정량화하고 관리하여 시스템의 건강성을 유지하는 방안으로 확장됩니다.
* **Shift-Left Security**: 보안 검토를 SDLC 가장 앞단으로 앞당겨 수정 비용을 대폭 절감하는 전략적 접근입니다.
* **Technical Debt (기술 부채**: 자동 분석으로 식별된 코드 스멜(Code Smells)을 정량화하고 관리하여 시스템의 건강성을 유지하는 방안으로 확장됩니다.
---
*Last updated: 2026-05-02*
10_Wiki/Topics/04_Governance_Reliability/CI-CD Pipeline Security (CI-CD 파이프라인 보안).md
+7 -7
View File
@@ -1,4 +1,4 @@
# [[CI/CD Pipeline Security (CI/CD 파이프라인 보안)]]
# [[CI-CD Pipeline Security (CI-CD 파이프라인 보안)|CI/CD Pipeline Security (CI/CD 파이프라인 보안]]
## 📌 Brief Summary
CI/CD 파이프라인 보안은 소프트웨어 개발의 지속적 통합 및 배포(CI/CD) 과정에서 소스 코드, 설정, 서드파티 의존성에 존재하는 보안 취약점과 결함을 자동으로 식별하고 차단하는 방어 체계를 의미합니다 [1]. 코드 리뷰 프로세스와 결합하여 정적 분석(SAST), 시크릿(Secret) 스캐닝, 의존성 검사(SCA) 등의 자동화 도구를 실행하며, 심각한 위험 감지 시 병합(Merge)을 차단하는 게이트키퍼 역할을 수행합니다 [4]. 이를 통해 개발 속도를 유지하면서도 공급망을 보호하고 전체 시스템의 안정성을 보장합니다 [5, 7].
@@ -16,10 +16,10 @@ CI/CD 파이프라인 보안은 소프트웨어 개발의 지속적 통합 및
## 🔗 Knowledge Connections
### Related Concepts
* **[[SAST (Static Application Security Testing)]]**: 코드 실행 전 소스 분석을 통해 취약점 위치를 라인 수준에서 짚어주는 핵심 스캐닝 도구입니다.
* **[[SCA (Software Composition Analysis)]]**: 서드파티 의존성 패키지의 취약점과 라이선스 위반을 검사하여 공급망 보안을 강화합니다.
* **[[Automated Quality Gates]]**: 보안 및 품질 기준을 통과해야만 병합이 가능하도록 시스템적으로 강제하는 관문입니다.
* **[[Shift-Left Security]]**: 보안 검토를 SDLC 가장 초기 단계로 앞당겨 수정 비용을 절감하려는 근본적인 전략입니다.
* **[[SAST (Static Application Security Testing)|SAST (Static Application Security Testing]]**: 코드 실행 전 소스 분석을 통해 취약점 위치를 라인 수준에서 짚어주는 핵심 스캐닝 도구입니다.
* **SCA (Software Composition Analysis**: 서드파티 의존성 패키지의 취약점과 라이선스 위반을 검사하여 공급망 보안을 강화합니다.
* **Automated Quality Gates**: 보안 및 품질 기준을 통과해야만 병합이 가능하도록 시스템적으로 강제하는 관문입니다.
* **Shift-Left Security**: 보안 검토를 SDLC 가장 초기 단계로 앞당겨 수정 비용을 절감하려는 근본적인 전략입니다.
### Deeper Research Questions
* SAST/SCA 스캔 결과의 오탐을 줄이고 리뷰어의 피로도를 낮추기 위한 '상황 인식(Context-aware) 정책 최적화' 방안은 무엇인가?
@@ -36,8 +36,8 @@ CI/CD 파이프라인 보안은 소프트웨어 개발의 지속적 통합 및
* **My Project Relevance:** 스타일 및 단순 취약점 지적을 자동화에 맡겨 리뷰어의 소모적 업무를 줄이고, 핵심 로직 및 구조적 피드백의 밀도를 높입니다.
### Adjacent Topics
* **[[Dependency Management (의존성 관리)]]**: Dependabot 등을 활용하여 외부 라이브러리의 취약점을 지속적으로 추적하고 업데이트하는 전략입니다.
* **[[Policy-as-Code (코드로서의 정책)]]**: 보안 및 거버넌스 규칙을 코드로 정의하여 자동 검증하고 버전 관리하는 최신 관리 방법론입니다.
* **Dependency Management (의존성 관리**: Dependabot 등을 활용하여 외부 라이브러리의 취약점을 지속적으로 추적하고 업데이트하는 전략입니다.
* **Policy-as-Code (코드로서의 정책**: 보안 및 거버넌스 규칙을 코드로 정의하여 자동 검증하고 버전 관리하는 최신 관리 방법론입니다.
---
*Last updated: 2026-05-02*
10_Wiki/Topics/04_Governance_Reliability/Code Quality & Health.md
+6 -6
View File
@@ -6,7 +6,7 @@ tags: [governance, code-quality, code-health, simplicity, maintainability, reada
last_reinforced: 2026-05-01
---
# [[Code Quality & Health]]
# [[Code Quality & Health|Code Quality & Health]]
## 📌 한 줄 통찰 (The Karpathy Summary)
> "코드베이스의 장기적 생존성과 팀의 개발 속도를 결정하는 핵심 자산: 인지적 부하를 최소화하는 단순성(Simplicity)과 미래의 변화를 수용하는 유지보수성(Maintainability)의 조화로운 상태."
@@ -28,9 +28,9 @@ last_reinforced: 2026-05-01
- **가독성 vs 성능**: 간결하고 읽기 쉬운 코드가 때로는 마이크로 최적화 관점에서 성능을 희생할 수 있습니다. 성능이 크리티컬한 영역이 아니라면 유지보수성을 우선하는 것이 장기적으로 유리합니다.
## 🔗 지식 연결 (Graph)
- [[Single Responsibility Principle (SRP)]]: 코드를 단순하게 만드는 구조적 원칙.
- [[Refactoring]]: 코드 건강을 회복시키는 실천적 행위.
- [[Technical Debt]]: 코드 품질 저하 시 발생하는 잠재적 비용.
- [[Over-engineering]]: 단순성을 해치는 가장 큰 위협.
- [[Testability]]: 단순한 코드가 가져오는 부가적 이득.
- [[Single Responsibility Principle (SRP)|Single Responsibility Principle (SRP]]: 코드를 단순하게 만드는 구조적 원칙.
- [[Refactoring|Refactoring]]: 코드 건강을 회복시키는 실천적 행위.
- [[Technical-Debt|Technical Debt]]: 코드 품질 저하 시 발생하는 잠재적 비용.
- Over-engineering: 단순성을 해치는 가장 큰 위협.
- [[테스트 용이성 (Testability)|Testability]]: 단순한 코드가 가져오는 부가적 이득.
---
10_Wiki/Topics/04_Governance_Reliability/Code Review Automation & Metrics (코드 리뷰 자동화 및 지표).md
+7 -7
View File
@@ -1,4 +1,4 @@
# [[Code Review Automation & Metrics (코드 리뷰 자동화 및 지표)]]
# [[Code Review Automation & Metrics (코드 리뷰 자동화 및 지표)|Code Review Automation & Metrics (코드 리뷰 자동화 및 지표]]
## 📌 Brief Summary
코드 리뷰 자동화 및 지표는 소프트웨어 개발의 품질 검증 과정을 기계적으로 가속화하고, 그 효율성을 객관적인 데이터로 측정하는 체계입니다 [1]. 정적 분석(SAST), 린팅(Linting), 단위 테스트 등을 자동화하여 인간 리뷰어의 인지 부하를 줄이고, 결함 밀도, 리뷰 주기 시간(Cycle Time), 변경 실패율 등의 지표를 통해 개발 프로세스의 병목을 식별합니다 [2, 3]. 이는 개별 개발자 평가가 아닌, 팀 전체의 생산성 향상과 고품질 소프트웨어의 신속한 배포를 위한 전략적 기반으로 기능합니다.
@@ -22,10 +22,10 @@
## 🔗 Knowledge Connections
### Related Concepts
* **[[DORA Metrics]]**: 배포 빈도, 변경 리드 타임 등 팀의 전반적인 데브옵스 성과를 측정하는 업계 표준 지표입니다.
* **[[Automated Code Analysis]]**: SAST, SCA 등 리뷰 자동화를 실질적으로 구현하는 기술적 도구 체계입니다.
* **[[Pull Request Size]]**: 리뷰 속도(Cycle Time)와 결함 발견율에 결정적 영향을 미치는 핵심 선행 지표입니다.
* **[[CI/CD Pipeline]]**: 자동화된 분석과 품질 게이트가 실제로 동작하는 물리적 인프라 환경입니다.
* **[[DORA-Metrics|DORA Metrics]]**: 배포 빈도, 변경 리드 타임 등 팀의 전반적인 데브옵스 성과를 측정하는 업계 표준 지표입니다.
* **[[Automated Code Analysis (자동화된 코드 분석)|Automated Code Analysis]]**: SAST, SCA 등 리뷰 자동화를 실질적으로 구현하는 기술적 도구 체계입니다.
* **Pull Request Size**: 리뷰 속도(Cycle Time)와 결함 발견율에 결정적 영향을 미치는 핵심 선행 지표입니다.
* **[[CI-CD Pipeline|CI/CD Pipeline]]**: 자동화된 분석과 품질 게이트가 실제로 동작하는 물리적 인프라 환경입니다.
### Deeper Research Questions
* 결함 이탈률이 높을 때, 이것이 리뷰어의 도메인 지식 부족 때문인지 테스트 자동화의 사각지대 때문인지 객관적으로 구분하여 진단하는 프레임워크는 무엇인가?
@@ -42,8 +42,8 @@
* **My Project Relevance:** 소모적인 스타일 논쟁을 자동화에 위임하고, 수집된 지표를 기반으로 팀의 리뷰 문화를 지속적으로 고도화합니다.
### Adjacent Topics
* **[[Code Review Culture]]**: 정성적인 팀 문화와 정량적인 품질 지표 사이의 상관관계 및 심리적 안전감의 영향을 탐구합니다.
* **[[Shift-Left Security]]**: 보안 검토를 조기에 자동화하여 수정 비용 지표를 낮추는 전략적 연계입니다.
* **Code Review Culture**: 정성적인 팀 문화와 정량적인 품질 지표 사이의 상관관계 및 심리적 안전감의 영향을 탐구합니다.
* **Shift-Left Security**: 보안 검토를 조기에 자동화하여 수정 비용 지표를 낮추는 전략적 연계입니다.
---
*Last updated: 2026-05-02*
10_Wiki/Topics/04_Governance_Reliability/Code Review Etiquette & Communication (코드 리뷰 에티켓 및 커뮤니케이션).md
+7 -7
View File
@@ -1,4 +1,4 @@
# [[Code Review Etiquette & Communication (코드 리뷰 에티켓 및 커뮤니케이션)]]
# [[Code Review Etiquette & Communication (코드 리뷰 에티켓 및 커뮤니케이션)|Code Review Etiquette & Communication (코드 리뷰 에티켓 및 커뮤니케이션]]
## 📌 Brief Summary
코드 리뷰 에티켓 및 커뮤니케이션은 리뷰어와 작성자 간의 상호 존중과 협력을 바탕으로 건설적인 피드백을 주고받기 위한 행동 규범입니다 [1]. 이는 단순한 결함 발견을 넘어 팀 내 심리적 안전감을 형성하고 지식 공유를 촉진하며, 시스템의 장기적인 건전성을 유지하는 데 기여합니다 [4]. 명확한 의도 전달, 객관적인 언어 사용, 긍정적인 피드백의 균형을 통해 불필요한 감정 소모 없이 효율적으로 코드 품질을 높이는 것을 핵심 목표로 합니다.
@@ -23,10 +23,10 @@
## 🔗 Knowledge Connections
### Related Concepts
* **[[심리적 안전감(Psychological Safety)]]**: 비판이 아닌 개선을 위한 협업임을 신뢰하는 효과적인 리뷰의 심리적 토대입니다.
* **[[IKEA 효과(IKEA Effect)]]**: 작성자가 자신의 코드에 과도한 가치를 부여하여 피드백을 방어적으로 받아들이게 되는 인지 편향입니다.
* **[[Conventional Comments]]**: 피드백 라벨링을 통해 소통 마찰을 줄이는 구체적인 시스템 프레임워크입니다.
* **[[Egoless Programming]]**: 개인의 자존심보다 팀의 코드 품질을 최우선으로 생각하는 개발 철학입니다.
* **[[심리적 안전감 (Psychological Safety)|심리적 안전감(Psychological Safety]]**: 비판이 아닌 개선을 위한 협업임을 신뢰하는 효과적인 리뷰의 심리적 토대입니다.
* **IKEA 효과(IKEA Effect**: 작성자가 자신의 코드에 과도한 가치를 부여하여 피드백을 방어적으로 받아들이게 되는 인지 편향입니다.
* **Conventional Comments**: 피드백 라벨링을 통해 소통 마찰을 줄이는 구체적인 시스템 프레임워크입니다.
* **Egoless Programming**: 개인의 자존심보다 팀의 코드 품질을 최우선으로 생각하는 개발 철학입니다.
### Deeper Research Questions
* 비동기 텍스트 리뷰에서 발생할 수 있는 '톤(Tone)의 오해'를 AI가 감지하여 더 부드러운 표현으로 수정을 제안해주는 도구의 효용성은 어느 정도인가?
@@ -43,8 +43,8 @@
* **My Project Relevance:** 댓글 스레드가 길어지면 "10분만 대화하시죠"라고 제안하여 감정적 핑퐁을 끊고 문제를 신속히 해결합니다.
### Adjacent Topics
* **[[Automated Static Analysis & Linters]]**: 인간 간의 스타일 논쟁을 근본적으로 제거하기 위한 자동화 도구 체계입니다.
* **[[Pair Programming]]**: 소통 지연과 오해를 실시간 대화로 즉시 해소하는 동기식 협업 방식입니다.
* **Automated Static Analysis & Linters**: 인간 간의 스타일 논쟁을 근본적으로 제거하기 위한 자동화 도구 체계입니다.
* **Pair Programming**: 소통 지연과 오해를 실시간 대화로 즉시 해소하는 동기식 협업 방식입니다.
---
*Last updated: 2026-05-02*
10_Wiki/Topics/04_Governance_Reliability/Code Review Foundations (코드 리뷰 기초).md
+7 -7
View File
@@ -1,4 +1,4 @@
# [[Code Review Foundations (코드 리뷰 기초)]]
# [[Code Review Foundations (코드 리뷰 기초)|Code Review Foundations (코드 리뷰 기초]]
## 📌 Brief Summary
코드 리뷰(Code Review)는 한 명 이상의 개발자가 다른 개발자가 작성한 소스 코드를 검토하여 버그를 찾고, 품질을 높이며, 지식을 공유하는 협업 프로세스입니다 [1]. 이는 소프트웨어 개발 생명주기(SDLC)에서 결함을 조기에 발견하여 수정 비용을 절감하고 시스템의 아키텍처적 일관성을 유지하는 핵심 방어선 역할을 합니다 [2, 3]. 리뷰 방식은 실시간으로 진행되는 '동기식(Synchronous)'과 PR/MR 도구를 활용하는 '비동기식(Asynchronous)'으로 나뉘며, 조직의 규모와 목적에 따라 상호 보완적으로 활용됩니다 [4, 5].
@@ -28,10 +28,10 @@
## 🔗 Knowledge Connections
### Related Concepts
* **[[Pair Programming]]**: 코드를 작성하면서 실시간으로 리뷰가 완료되는 가장 강력한 동기식 협업 기법입니다.
* **[[Pull Request (PR) Workflow]]**: 비동기식 리뷰가 이루어지는 현대적인 표준 개발 워크플로우입니다.
* **[[DORA Metrics]]**: 리뷰 속도와 효율성이 팀의 소프트웨어 전달 성과에 미치는 영향을 측정하는 지표 체계입니다.
* **[[Shift-Left Security]]**: 보안 검토를 코드 리뷰 단계로 앞당겨 수정 비용을 절감하려는 전략적 접근입니다.
* **Pair Programming**: 코드를 작성하면서 실시간으로 리뷰가 완료되는 가장 강력한 동기식 협업 기법입니다.
* **Pull Request (PR) Workflow**: 비동기식 리뷰가 이루어지는 현대적인 표준 개발 워크플로우입니다.
* **[[DORA-Metrics|DORA Metrics]]**: 리뷰 속도와 효율성이 팀의 소프트웨어 전달 성과에 미치는 영향을 측정하는 지표 체계입니다.
* **Shift-Left Security**: 보안 검토를 코드 리뷰 단계로 앞당겨 수정 비용을 절감하려는 전략적 접근입니다.
### Deeper Research Questions
* 비동기 리뷰 중 댓글 대화가 몇 회 이상 지속될 때 동기식 회의로 전환하는 것이 팀의 생산성 ROI 측면에서 가장 유리한가?
@@ -48,8 +48,8 @@
* **My Project Relevance:** 스타일 지적 등 기계적인 검증은 자동화 도구(CI/CD)에 맡기고, 리뷰어는 비즈니스 로직과 설계의 적합성 검증이라는 본연의 가치에 집중합니다.
### Adjacent Topics
* **[[Code Review Communication Etiquette]]**: 효율적인 피드백 전달을 위한 어조, 기술, 감정 관리 등 소프트 스킬 영역으로 확장됩니다.
* **[[Egoless Programming]]**: 개인의 자존심을 버리고 팀의 코드를 최우선으로 생각하는 개발 철학입니다.
* **Code Review Communication Etiquette**: 효율적인 피드백 전달을 위한 어조, 기술, 감정 관리 등 소프트 스킬 영역으로 확장됩니다.
* **Egoless Programming**: 개인의 자존심을 버리고 팀의 코드를 최우선으로 생각하는 개발 철학입니다.
---
*Last updated: 2026-05-02*
10_Wiki/Topics/04_Governance_Reliability/Code Review Operational Excellence (코드 리뷰 운영 우수성).md
+7 -7
View File
@@ -1,4 +1,4 @@
# [[Code Review Operational Excellence (코드 리뷰 운영 우수성)]]
# [[Code Review Operational Excellence (코드 리뷰 운영 우수성)|Code Review Operational Excellence (코드 리뷰 운영 우수성]]
## 📌 Brief Summary
코드 리뷰 운영 우수성은 리뷰 프로세스의 속도, 품질, 그리고 개발자 경험(DX)을 최적화하기 위한 운영 전략과 실행 지침입니다. 명확한 Git 커밋 메시지 작성, 체크리스트를 활용한 체계적 검토, 서비스 수준 협약(SLA) 기반의 응답 시간 관리, 그리고 컨텍스트 스위칭(Context Switching) 비용 최소화를 통해 팀의 생산성을 극대화합니다 [1, 4]. 이는 기술 부채를 통제하고 코드 건강(Code Health)을 유지하는 동시에 개발 파이프라인의 병목을 제거하는 것을 목표로 합니다.
@@ -26,10 +26,10 @@
## 🔗 Knowledge Connections
### Related Concepts
* **[[Pull Request Best Practices]]**: 작은 PR 유지와 템플릿 활용 등 PR 단계의 운영 실무입니다.
* **[[DORA Metrics]]**: 리뷰 속도가 배포 빈도와 변경 리드 타임에 미치는 영향을 측정하는 상위 지표입니다.
* **[[Code Review Automation & Metrics]]**: 운영 데이터를 수집하고 분석하는 기술적 수단입니다.
* **[[Architecture Decision Records (ADR)]]**: 중대한 설계 결정 배경을 기록하여 장기적인 운영 맥락을 제공합니다.
* **Pull Request Best Practices**: 작은 PR 유지와 템플릿 활용 등 PR 단계의 운영 실무입니다.
* **[[DORA-Metrics|DORA Metrics]]**: 리뷰 속도가 배포 빈도와 변경 리드 타임에 미치는 영향을 측정하는 상위 지표입니다.
* **[[Code Review Automation & Metrics (코드 리뷰 자동화 및 지표)|Code Review Automation & Metrics]]**: 운영 데이터를 수집하고 분석하는 기술적 수단입니다.
* **Architecture Decision Records (ADR**: 중대한 설계 결정 배경을 기록하여 장기적인 운영 맥락을 제공합니다.
### Deeper Research Questions
* 리뷰어의 컨텍스트 스위칭 비용을 최소화하기 위해, 캘린더의 '집중 시간'과 연동하여 리뷰 요청을 지연(Batching) 전달하는 시스템의 효용성은 어느 정도인가?
@@ -46,8 +46,8 @@
* **My Project Relevance:** 'SLA 기반 리뷰 문화'를 도입하여 PR이 며칠씩 방치되는 현상을 제거하고 개발 흐름을 가속화합니다 [45].
### Adjacent Topics
* **[[Cognitive Load Theory]]**: 리뷰어의 인지 부하를 줄이기 위한 정보 전달 방식의 심리학적 배경입니다.
* **[[Continuous Deployment (CD)]]**: 고도화된 리뷰 운영이 어떻게 사람의 개입 없는 자동 배포로 이어지는지에 대한 연계성입니다.
* **[[Cognitive Load Theory|Cognitive Load Theory]]**: 리뷰어의 인지 부하를 줄이기 위한 정보 전달 방식의 심리학적 배경입니다.
* **Continuous Deployment (CD**: 고도화된 리뷰 운영이 어떻게 사람의 개입 없는 자동 배포로 이어지는지에 대한 연계성입니다.
---
*Last updated: 2026-05-02*
10_Wiki/Topics/04_Governance_Reliability/Collaboration_Governance.md
+6 -6
View File
@@ -1,17 +1,17 @@
---
title: 협업 가이드라인 및 코드 거버넌스
category: Software [[Architecture]]
tags: [Collaboration, PR, [[Code Review]], Documentation, Governance]
category: Software [[Architecture|Architecture]]
tags: [Collaboration, PR, [[Code Review|Code Review]], Documentation, Governance]
created: 2026-04-20
---
# [[Collaboration_Governance]] (협업과 코드 품격)
# [[Collaboration_Governance|Collaboration_Governance]] (협업과 코드 품격)
## 📌 한 줄 통찰 (The Karpathy Summary)
> 코드는 혼자 쓰는 일기장이 아니라 함께 짓는 건축물이다. 동료의 시간을 아껴주는 문서화와 소통 방식이 당신의 가치를 증명한다.
## 📖 구조화된 지식 (Synthesized Content)
- **[[Pull Request (PR)]] 에티켓**:
- **[[Pull Request (PR)|Pull Request (PR]] 에티켓**:
- "이거 고쳤습니다"는 최악의 PR이다. 무엇을(What), 왜(Why), 어떻게(How) 했는지 명시하고 가능한 시각적 결과물(스크린샷, GIF)을 첨부하여 리뷰어의 인지 부하를 줄여라.
- **Code Review Protocol**:
- P1(필수 반영), P2(권장), P3(질문/의견) 식으로 중요도를 표시하라. 비판은 날카롭게 하되 표현은 따뜻하게 하여 팀의 심리적 안정성을 유지하라.
@@ -22,5 +22,5 @@ created: 2026-04-20
- 완벽한 거버넌스를 추구하느라 소통이 무거워지면 안 된다. 빠른 배포가 필요한 시점에는 '기술 부채'를 명문화하고 나중에 갚는 기민함(Agile)도 필요하다.
## 🔗 지식 연결 (Graph)
- Related: [[React_Clean_Code_Best_Practices]] , [[Deployment_Final_Gate]]
- Foundation: [[System_Debugging_Protocol]]
- Related: [[React_Clean_Code_Best_Practices|React_Clean_Code_Best_Practices]] , [[Deployment_Final_Gate|Deployment_Final_Gate]]
- Foundation: [[System_Debugging_Protocol|System_Debugging_Protocol]]
10_Wiki/Topics/04_Governance_Reliability/DORA Metrics (소프트웨어 전달 성과 지표).md
+7 -7
View File
@@ -1,4 +1,4 @@
# [[DORA Metrics (소프트웨어 전달 성과 지표)]]
# [[DORA Metrics (소프트웨어 전달 성과 지표)|DORA Metrics (소프트웨어 전달 성과 지표]]
## 📌 Brief Summary
DORA(DevOps Research and Assessment) 지표는 소프트웨어 개발 조직의 전달(Delivery) 성능과 운영 효율성을 측정하는 글로벌 표준 기준입니다 [1]. 코드 리뷰의 속도와 효율성은 DORA 지표에 직결되며, 빠른 리뷰 주기를 유지하는 엘리트(Elite) 팀은 그렇지 않은 팀보다 50% 더 높은 딜리버리 성과를 보입니다 [2]. DORA 지표는 배포 빈도, 변경 리드 타임, 서비스 복구 시간, 변경 실패율의 4가지 핵심 지표를 통해 조직의 역량을 객관적으로 진단합니다 [3].
@@ -24,10 +24,10 @@ DORA(DevOps Research and Assessment) 지표는 소프트웨어 개발 조직의
## 🔗 Knowledge Connections
### Related Concepts
* **[[Review-Speed Benchmarks]]**: DORA 데이터를 기반으로 리뷰 속도를 엘리트, 우수, 수용 가능 수준으로 구분하여 정량 평가하는 기준입니다.
* **[[Pull Request Size Limits (PR 크기 제한)]]**: 엘리트 등급의 리뷰 속도 달성을 위한 선제 조건으로, 리뷰어의 인지 부하를 최소화합니다.
* **[[Automation in Code Review (코드 리뷰 자동화)]]**: 기계적 검증을 자동화하여 인간 리뷰어가 고차원적 가치 창출(지식 공유 등)에 집중하게 돕습니다.
* **[[Software Delivery Performance]]**: DORA 지표가 궁극적으로 측정하고자 하는 소프트웨어 전달 역량의 종합적 성과입니다.
* **Review-Speed Benchmarks**: DORA 데이터를 기반으로 리뷰 속도를 엘리트, 우수, 수용 가능 수준으로 구분하여 정량 평가하는 기준입니다.
* **Pull Request Size Limits (PR 크기 제한**: 엘리트 등급의 리뷰 속도 달성을 위한 선제 조건으로, 리뷰어의 인지 부하를 최소화합니다.
* **Automation in Code Review (코드 리뷰 자동화**: 기계적 검증을 자동화하여 인간 리뷰어가 고차원적 가치 창출(지식 공유 등)에 집중하게 돕습니다.
* **Software Delivery Performance**: DORA 지표가 궁극적으로 측정하고자 하는 소프트웨어 전달 역량의 종합적 성과입니다.
### Deeper Research Questions
* 지리적으로 분산된 글로벌 팀이 DORA의 '첫 리뷰 1시간 이내' 기준을 달성하기 위해 비동기 협업 및 알림(Notification) 시스템을 어떻게 최적화해야 하는가?
@@ -44,8 +44,8 @@ DORA(DevOps Research and Assessment) 지표는 소프트웨어 개발 조직의
* **My Project Relevance:** 현재 팀의 평균 리드 타임과 배포 빈도 데이터를 추출하여 DORA 벤치마크와 비교 진단하고 병목 구간을 개선합니다.
### Adjacent Topics
* **[[DevOps Culture]]**: DORA 지표가 효과를 발휘하기 위해 전제되어야 할 팀의 심리적 안전감과 실험 정신 등 문화적 측면으로 확장됩니다.
* **[[Cycle Time (TTR)]]**: PR 생성부터 병합까지의 전체 주기를 측정하고 관리하는 실무적 지표 체계입니다.
* **DevOps Culture**: DORA 지표가 효과를 발휘하기 위해 전제되어야 할 팀의 심리적 안전감과 실험 정신 등 문화적 측면으로 확장됩니다.
* **Cycle Time (TTR**: PR 생성부터 병합까지의 전체 주기를 측정하고 관리하는 실무적 지표 체계입니다.
---
*Last updated: 2026-05-02*
10_Wiki/Topics/04_Governance_Reliability/Dependency & Supply Chain Security (의존성 및 공급망 보안).md
+7 -7
View File
@@ -1,4 +1,4 @@
# [[Dependency & Supply Chain Security (의존성 및 공급망 보안)]]
# [[Dependency & Supply Chain Security (의존성 및 공급망 보안)|Dependency & Supply Chain Security (의존성 및 공급망 보안]]
## 📌 Brief Summary
의존성 및 공급망 보안은 애플리케이션 개발에 사용되는 외부 오픈소스 라이브러리와 서드파티 컴포넌트의 무결성을 보장하고 보안 취약점을 관리하는 프로세스입니다 [1]. 현대 소프트웨어의 80% 이상이 외부 의존성으로 구성되므로, 직접 작성한 코드만큼이나 외부 유입 코드의 안전성을 검증하는 것이 필수적입니다 [2]. SCA(Software Composition Analysis) 도구와 Dependabot과 같은 자동화 시스템을 활용하여 알려진 취약점(CVE)과 라이선스 위반을 실시간으로 감지하고 대응합니다 [1, 2].
@@ -22,10 +22,10 @@
## 🔗 Knowledge Connections
### Related Concepts
* **[[SAST (Static Application Security Testing)]]**: 내부 작성 소스 코드의 결함을 찾는 도구로, SCA와 상호 보완적인 관계입니다.
* **[[CVE (Common Vulnerabilities and Exposures)]]**: SCA 도구가 참조하는 '알려진 취약점'의 표준 데이터베이스입니다.
* **[[SBOM (Software Bill of Materials)]]**: 애플리케이션의 모든 구성 요소를 명시한 자재 명세서로, 공급망 투명성의 핵심 자산입니다.
* **[[Shift-Left Security]]**: 보안 스캔을 개발 초기 단계로 앞당겨 리스크를 줄이는 DevSecOps의 핵심 철학입니다.
* **[[SAST (Static Application Security Testing)|SAST (Static Application Security Testing]]**: 내부 작성 소스 코드의 결함을 찾는 도구로, SCA와 상호 보완적인 관계입니다.
* **CVE (Common Vulnerabilities and Exposures**: SCA 도구가 참조하는 '알려진 취약점'의 표준 데이터베이스입니다.
* **SBOM (Software Bill of Materials**: 애플리케이션의 모든 구성 요소를 명시한 자재 명세서로, 공급망 투명성의 핵심 자산입니다.
* **Shift-Left Security**: 보안 스캔을 개발 초기 단계로 앞당겨 리스크를 줄이는 DevSecOps의 핵심 철학입니다.
### Deeper Research Questions
* SCA 도구가 수많은 전이 의존성 중 실제 애플리케이션의 실행 경로(Code Path)에 포함되어 실질적 위협이 되는 요소를 어떻게 선별적으로 식별하는가?
@@ -42,8 +42,8 @@
* **My Project Relevance:** 코드 리뷰 체크리스트에 '의존성 보안 점검' 항목을 추가하고, 자동화 도구를 통해 리뷰어의 육안 검사 부담을 해소합니다 [54].
### Adjacent Topics
* **[[Policy-as-Code]]**: 보안 차단 기준을 코드로 정의하여 파이프라인에서 자동 강제하는 전략입니다.
* **[[Vulnerability Management]]**: 발견된 취약점의 생명주기를 관리하고 조치 우선순위를 정하는 전체 프로세스로 확장됩니다.
* **Policy-as-Code**: 보안 차단 기준을 코드로 정의하여 파이프라인에서 자동 강제하는 전략입니다.
* **Vulnerability Management**: 발견된 취약점의 생명주기를 관리하고 조치 우선순위를 정하는 전체 프로세스로 확장됩니다.
---
*Last updated: 2026-05-02*
10_Wiki/Topics/04_Governance_Reliability/Engineering Metrics (DORA).md
+6 -6
View File
@@ -6,7 +6,7 @@ tags: [governance, dora-metrics, engineering-metrics, performance, devops, cycle
last_reinforced: 2026-05-01
---
# [[Engineering Metrics (DORA)]]
# [[Engineering Metrics (DORA)|Engineering Metrics (DORA]]
## 📌 한 줄 통찰 (The Karpathy Summary)
> "데이터에 기반하여 소프트웨어 인도 성과(Delivery Performance)를 정량화하고, 엘리트 팀의 벤치마크를 통해 개발 프로세스의 병목과 개선 방향을 제시하는 엔지니어링 표준 지표."
@@ -31,9 +31,9 @@ DORA 지표는 데브옵스(DevOps) 연구를 통해 입증된 고성과 팀의
- **데이터의 맥락**: 단순 수치만으로 팀을 평가하기보다, 지표의 변화 추이를 통해 팀의 프로세스 건전성을 진단하고 병목을 해결하는 도구로 활용해야 합니다.
## 🔗 지식 연결 (Graph)
- [[Review Performance & Flow]]: DORA 지표를 달성하기 위한 구체적 운영 전략.
- [[Small Pull Requests (작은 PR)]]: Lead Time을 단축하는 가장 강력한 수단.
- [[Automated Quality & Review]]: 인간의 시간을 절약하여 성과를 극대화하는 기반.
- [[CI-CD Pipeline]]: 지표 수집과 자동화가 이루어지는 인프라.
- [[DORA Metrics]]: 원본 개념 정의.
- [[Review Performance & Flow|Review Performance & Flow]]: DORA 지표를 달성하기 위한 구체적 운영 전략.
- Small Pull Requests (작은 PR: Lead Time을 단축하는 가장 강력한 수단.
- [[Automated Quality & Review|Automated Quality & Review]]: 인간의 시간을 절약하여 성과를 극대화하는 기반.
- [[CI-CD Pipeline|CI-CD Pipeline]]: 지표 수집과 자동화가 이루어지는 인프라.
- [[DORA-Metrics|DORA Metrics]]: 원본 개념 정의.
---
10_Wiki/Topics/04_Governance_Reliability/Index.md
+6 -6
View File
@@ -1,9 +1,9 @@
# Index: Topics > 04_Governance_Reliability
## 📝 Documents
- [[Accessibility_Inclusivity]]
- [[Collaboration_Governance]]
- [[Reliability_Safety_First]]
- [[Styling_Governance]]
- [[System_Debugging_Protocol]]
- [[System_Protocol_Standard]]
- [[Accessibility_Inclusivity|Accessibility_Inclusivity]]
- [[Collaboration_Governance|Collaboration_Governance]]
- [[Reliability_Safety_First|Reliability_Safety_First]]
- [[Styling_Governance|Styling_Governance]]
- [[System_Debugging_Protocol|System_Debugging_Protocol]]
- [[System_Protocol_Standard|System_Protocol_Standard]]
10_Wiki/Topics/04_Governance_Reliability/Pull Request Best Practices (PR 베스트 프랙티스).md
+7 -7
View File
@@ -1,4 +1,4 @@
# [[Pull Request Best Practices (PR 베스트 프랙티스)]]
# [[Pull Request Best Practices (PR 베스트 프랙티스)|Pull Request Best Practices (PR 베스트 프랙티스]]
## 📌 Brief Summary
Pull Request(PR) 베스트 프랙티스는 코드 변경 사항을 메인 브랜치에 통합하기 전, 리뷰와 검증 과정을 효율화하고 품질을 높이기 위한 핵심 활동 지침입니다 [1]. PR을 작고 응집력 있는 단위(200~400 LOC 이하)로 유지하고, 템플릿을 활용해 변경 맥락을 명확히 전달하며, 자동화된 도구와 결합하여 리뷰어의 인지 부하를 최소화하는 것을 목표로 합니다 [2, 5]. 이는 결함 발견율을 높이고 배포 주기를 단축하며 팀의 협업 생산성을 극대화하는 기반이 됩니다.
@@ -24,10 +24,10 @@ Pull Request(PR) 베스트 프랙티스는 코드 변경 사항을 메인 브랜
## 🔗 Knowledge Connections
### Related Concepts
* **[[Feature Flags]]**: 미완성 기능을 사용자에게 노출하지 않고 지속적으로 작은 PR을 병합할 수 있게 돕는 핵심 도구입니다.
* **[[Stacked Pull Requests]]**: 상호 의존적인 여러 변경 사항을 논리적 단계로 나누어 리뷰 흐름을 관리하는 워크플로우입니다.
* **[[Defect Density]]**: PR 크기와 결함 발견율 사이의 상관관계를 보여주는 정량적 품질 지표입니다.
* **[[Time to Review (TTR)]]**: 작은 PR을 통해 최소화하고자 하는 코드 리뷰 병목 시간 지표입니다.
* **[[Feature-Flags|Feature Flags]]**: 미완성 기능을 사용자에게 노출하지 않고 지속적으로 작은 PR을 병합할 수 있게 돕는 핵심 도구입니다.
* **Stacked Pull Requests**: 상호 의존적인 여러 변경 사항을 논리적 단계로 나누어 리뷰 흐름을 관리하는 워크플로우입니다.
* **Defect Density**: PR 크기와 결함 발견율 사이의 상관관계를 보여주는 정량적 품질 지표입니다.
* **Time to Review (TTR**: 작은 PR을 통해 최소화하고자 하는 코드 리뷰 병목 시간 지표입니다.
### Deeper Research Questions
* 언어별 표현력 차이(장황한 Java vs 간결한 Python)에 따라 '작은 PR'의 기준(LOC)을 어떻게 차등 적용하는 것이 합리적인가?
@@ -44,8 +44,8 @@ Pull Request(PR) 베스트 프랙티스는 코드 변경 사항을 메인 브랜
* **My Project Relevance:** GitHub Actions를 활용해 PR 크기가 기준을 초과할 경우 자동으로 경고를 남기거나 병합을 제한하는 품질 게이트를 적용합니다.
### Adjacent Topics
* **[[Continuous Integration (CI)]]**: 빈번하고 작은 단위의 병합이 어떻게 지속적 통합의 신뢰성을 높이는지 탐구합니다.
* **[[Conventional Commits]]**: 커밋 메시지를 표준화하여 변경 이력의 가독성을 높이는 전략으로 확장됩니다.
* **[[Continuous Integration (CI)|Continuous Integration (CI]]**: 빈번하고 작은 단위의 병합이 어떻게 지속적 통합의 신뢰성을 높이는지 탐구합니다.
* **Conventional Commits**: 커밋 메시지를 표준화하여 변경 이력의 가독성을 높이는 전략으로 확장됩니다.
---
*Last updated: 2026-05-02*
10_Wiki/Topics/04_Governance_Reliability/Reliability_Safety_First.md
+5 -5
View File
@@ -1,11 +1,11 @@
---
title: 애플리케이션 안정성 및 로깅 (Error Boundary)
category: Software [[Architecture]]
tags: [[[Reliability]], Error Boundary, Sentry, Logging, [[Stability]]]
category: Software [[Architecture|Architecture]]
tags: [[Reliability|[Reliability]], Error Boundary, Sentry, Logging, Stability]
created: 2026-04-20
---
# [[Reliability_Safety_First]] (애플리케이션 안정성)
# [[Reliability_Safety_First|Reliability_Safety_First]] (애플리케이션 안정성)
## 📌 한 줄 통찰 (The Karpathy Summary)
> 에러는 막는 것이 아니라 '우아하게 격리'하는 것이다. 컴포넌트 하나가 무너져도 전체 시스템은 안전하게 순항해야 한다.
@@ -24,5 +24,5 @@ created: 2026-04-20
- 모든 곳에 에러 바운더리를 칠 필요는 없다. 데이터와 UI가 1:1로 매칭되는 구조라면 차라리 상위에서 에러를 처리하는 것이 논리적으로 명확할 수 있다.
## 🔗 지식 연결 (Graph)
- Related: [[System_Debugging_Protocol]] , [[React_[[Testing]]_Strategy]]
- Foundation: [[System_Protocol_Standard]]
- Related: [[System_Debugging_Protocol|System_Debugging_Protocol]] , React_[[Testing Strategy|Testing_Strategy]]
- Foundation: [[System_Protocol_Standard|System_Protocol_Standard]]
10_Wiki/Topics/04_Governance_Reliability/Review Performance & Flow.md
+7 -7
View File
@@ -6,7 +6,7 @@ tags: [management, review-performance, cycle-time, context-switching, asynchrono
last_reinforced: 2026-05-01
---
# [[Review Performance & Flow]]
# [[Review Performance & Flow|Review Performance & Flow]]
## 📌 한 줄 통찰 (The Karpathy Summary)
> "팀 전체의 배포 속도(Velocity)와 개별 엔지니어의 몰입(Flow) 사이의 균형을 최적화하여, 기술적 병목을 제거하고 작업의 연속성을 보장하는 운영 전략."
@@ -20,7 +20,7 @@ last_reinforced: 2026-05-01
2. **인지적 부하 및 세션 관리**:
* **200~400 LOC**: 한 번의 리뷰 세션(60~90분)에서 가장 효율적으로 결함을 발견할 수 있는 코드 크기입니다.
* **컨텍스트 스위칭 방지**: 실시간 알림에 즉각 반응하기보다, 자연스러운 업무 중단점(Break point)에 리뷰를 모아서 처리(Batching)하여 개인의 몰입도를 보호합니다.
3. **[[Asynchronous Code Review]]**:
3. **Asynchronous Code Review**:
* 문서화와 비동기 피드백을 통해 시간대(Time zone)가 다른 팀원들과도 효율적으로 협업하며, 각자의 일정에 맞춰 고품질의 검토를 수행합니다.
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
@@ -28,9 +28,9 @@ last_reinforced: 2026-05-01
- **SLA의 유연성**: 모든 작업에 동일한 잣대를 대기보다, 긴급 핫픽스와 일반 기능 배포의 리뷰 우선순위와 SLA를 차등화하여 운영 효율성을 높여야 합니다.
## 🔗 지식 연결 (Graph)
- [[Small Pull Requests (작은 PR)]]: 리뷰 속도를 높이는 가장 근본적인 해결책.
- [[Context Switching (컨텍스트 스위칭)]]: 리뷰 활동이 개인 생산성에 미치는 비용.
- [[Time-to-Merge (Cycle Time)]]: 배포 성과를 측정하는 상위 지표.
- [[Automated Code Analysis]]: 인간의 리뷰 시간을 아껴주는 자동화 엔진.
- [[DORA Metrics]]: 엘리트 팀의 성과 기준.
- Small Pull Requests (작은 PR: 리뷰 속도를 높이는 가장 근본적인 해결책.
- Context Switching (컨텍스트 스위칭: 리뷰 활동이 개인 생산성에 미치는 비용.
- Time-to-Merge (Cycle Time: 배포 성과를 측정하는 상위 지표.
- [[Automated Code Analysis (자동화된 코드 분석)|Automated Code Analysis]]: 인간의 리뷰 시간을 아껴주는 자동화 엔진.
- [[DORA-Metrics|DORA Metrics]]: 엘리트 팀의 성과 기준.
---
10_Wiki/Topics/04_Governance_Reliability/Secure Code Review (보안 중심 코드 리뷰).md
+7 -7
View File
@@ -1,4 +1,4 @@
# [[Secure Code Review (보안 중심 코드 리뷰)]]
# [[Secure Code Review (보안 중심 코드 리뷰)|Secure Code Review (보안 중심 코드 리뷰]]
## 📌 Brief Summary
Secure Code Review(보안 코드 리뷰)는 소프트웨어가 배포되기 전에 소스 코드의 보안 취약점, 논리적 오류, 약점을 체계적으로 감사하여 애플리케이션의 안전성을 보장하는 프로세스입니다 [1]. 기능과 유지보수성에 초점을 맞추는 일반적인 코드 리뷰와 달리, 공격자의 관점(Adversarial mindset)에서 입력값 조작 가능성이나 민감 데이터 노출 여부를 중점적으로 파악합니다 [3, 4]. 자동화된 스캐닝 도구와 인간의 수동 분석을 결합하는 '시프트 레프트(Shift-Left)' 보안 전략의 핵심 단계로서 결함 수정 비용을 절감하고 규제 준수를 증명하는 필수적인 역할을 합니다 [5, 6].
@@ -23,10 +23,10 @@ Secure Code Review(보안 코드 리뷰)는 소프트웨어가 배포되기 전
## 🔗 Knowledge Connections
### Related Concepts
* **[[Shift-Left Security]]**: 보안 검토를 SDLC 가장 초기 단계로 앞당겨 지속적으로 수행하는 전략입니다.
* **[[SAST (Static Application Security Testing)]]**: 코드를 실행하지 않고 소스 수준에서 보안 결함을 찾아내는 1차 방어선입니다.
* **[[SCA (Software Composition Analysis)]]**: 외부 의존성 라이브러리의 취약점(CVE) 및 공급망 보안 위험을 관리합니다.
* **[[OWASP Top 10]]**: 보안 코드 리뷰 시 최우선으로 검증해야 할 치명적인 웹 위협 목록입니다.
* **Shift-Left Security**: 보안 검토를 SDLC 가장 초기 단계로 앞당겨 지속적으로 수행하는 전략입니다.
* **[[SAST (Static Application Security Testing)|SAST (Static Application Security Testing]]**: 코드를 실행하지 않고 소스 수준에서 보안 결함을 찾아내는 1차 방어선입니다.
* **SCA (Software Composition Analysis**: 외부 의존성 라이브러리의 취약점(CVE) 및 공급망 보안 위험을 관리합니다.
* **[[OWASP Top 10|OWASP Top 10]]**: 보안 코드 리뷰 시 최우선으로 검증해야 할 치명적인 웹 위협 목록입니다.
### Deeper Research Questions
* 일반 품질 리뷰와 보안 리뷰를 단일 워크플로우 내에서 통합할 때, 역할 분리와 최종 승인 권한(Approval Authority)을 어떻게 설계하는 것이 최적인가?
@@ -43,8 +43,8 @@ Secure Code Review(보안 코드 리뷰)는 소프트웨어가 배포되기 전
* **My Project Relevance:** 기능 중심 리뷰에서 탈피하여 보안 전용 체크리스트를 도입하고, 기계적 검토는 자동화에 위임하여 리뷰 품질을 고도화합니다.
### Adjacent Topics
* **[[Threat Modeling]]**: 코드 작성 전 설계 단계에서 잠재적 위험을 미리 식별하는 선제적 보안 기법입니다.
* **[[ASPM (Application Security Posture Management)]]**: SDLC 전반의 보안 위협을 가시화하고 우선순위를 정하는 통합 관리 플랫폼으로 확장됩니다.
* **Threat Modeling**: 코드 작성 전 설계 단계에서 잠재적 위험을 미리 식별하는 선제적 보안 기법입니다.
* **ASPM (Application Security Posture Management**: SDLC 전반의 보안 위협을 가시화하고 우선순위를 정하는 통합 관리 플랫폼으로 확장됩니다.
---
*Last updated: 2026-05-02*
10_Wiki/Topics/04_Governance_Reliability/Security Core Practices (보안 핵심 프랙티스).md
+7 -7
View File
@@ -1,4 +1,4 @@
# [[Security Core Practices (보안 핵심 프랙티스)]]
# [[Security Core Practices (보안 핵심 프랙티스)|Security Core Practices (보안 핵심 프랙티스]]
## 📌 Brief Summary
보안 핵심 프랙티스는 소프트웨어 개발 수명 주기(SDLC) 전반에 걸쳐 자산의 무결성을 보호하고 위협을 선제적으로 차단하기 위한 필수 활동들의 모음입니다. 보안 점검을 초기 단계로 앞당기는 **시프트 레프트(Shift-Left)** 전략을 중심으로, 잠재적 공격 경로를 분석하는 **위협 모델링(Threat Modeling)**, 최소 권한 원칙(Least Privilege) 준수, 그리고 시크릿 및 취약점 탐지 자동화를 통해 제품 자체에 보안을 내재화(Built-in)하는 것을 목표로 합니다 [1, 4].
@@ -25,10 +25,10 @@
## 🔗 Knowledge Connections
### Related Concepts
* **[[SDLC & SSDLC]]**: 보안 프랙티스가 실제로 통합되어 동작하는 전체 개발 프로세스 프레임워크입니다.
* **[[Secure Code Review]]**: 시프트 레프트 전략이 인간의 통찰과 결합되어 실현되는 구체적인 검토 활동입니다.
* **[[SAST & IAST]]**: 소스 코드와 런타임 환경에서 취약점을 자동으로 찾아내는 기술적 수단입니다.
* **[[OWASP Top 10]]**: 보안 프랙티스를 통해 우선적으로 방어해야 할 웹 애플리케이션의 치명적 위협 목록입니다.
* **[[SDLC & SSDLC (소프트웨어 개발 생명주기)|SDLC & SSDLC]]**: 보안 프랙티스가 실제로 통합되어 동작하는 전체 개발 프로세스 프레임워크입니다.
* **[[Secure Code Review (보안 중심 코드 리뷰)|Secure Code Review]]**: 시프트 레프트 전략이 인간의 통찰과 결합되어 실현되는 구체적인 검토 활동입니다.
* **SAST & IAST**: 소스 코드와 런타임 환경에서 취약점을 자동으로 찾아내는 기술적 수단입니다.
* **[[OWASP Top 10|OWASP Top 10]]**: 보안 프랙티스를 통해 우선적으로 방어해야 할 웹 애플리케이션의 치명적 위협 목록입니다.
### Deeper Research Questions
* 시프트 레프트 보안 도입 시 '배포 리드 타임(Lead Time)' 증가를 최소화하면서도 자동화 도구의 탐지 정확도를 높이기 위한 머신러닝 기반 필터링 기법은 무엇인가?
@@ -45,8 +45,8 @@
* **My Project Relevance:** 'OWASP Top 10' 및 '시크릿 유출 방지'를 코드 리뷰 필수 체크리스트로 편입하여 보안 기술 부채를 원천 차단합니다 [49].
### Adjacent Topics
* **[[DevSecOps]]**: 보안 프랙티스를 문화와 기술 전 영역에 끊김 없이 통합하는 거시적 방법론입니다.
* **[[Software Supply Chain Security]]**: 소스 코드를 넘어 외부 의존성 및 빌드 파이프라인 전체의 무결성을 확보하는 전략입니다.
* **[[DevSecOps|DevSecOps]]**: 보안 프랙티스를 문화와 기술 전 영역에 끊김 없이 통합하는 거시적 방법론입니다.
* **Software Supply Chain Security**: 소스 코드를 넘어 외부 의존성 및 빌드 파이프라인 전체의 무결성을 확보하는 전략입니다.
---
*Last updated: 2026-05-02*
10_Wiki/Topics/04_Governance_Reliability/Software Security Standards & Vulnerabilities (소프트웨어 보안 표준 및 취약점).md
+7 -7
View File
@@ -1,4 +1,4 @@
# [[Software Security Standards & Vulnerabilities (소프트웨어 보안 표준 및 취약점)]]
# [[Software Security Standards & Vulnerabilities (소프트웨어 보안 표준 및 취약점)|Software Security Standards & Vulnerabilities (소프트웨어 보안 표준 및 취약점]]
## 📌 Brief Summary
소프트웨어 보안 표준 및 취약점은 안전한 애플리케이션 개발을 위해 반드시 준수해야 할 지침과 방어해야 할 알려진 위협들의 모음입니다. CVE(Common Vulnerabilities and Exposures), CWE(Common Weakness Enumeration), CIS Benchmarks 등 글로벌 표준을 활용하여 보안 코드 리뷰의 기준을 수립하고, 인젝션 결함(Injection Flaws)과 같은 치명적인 약점을 사전에 식별하여 조치합니다 [1]. 이는 시프트 레프트(Shift-Left) 보안 전략의 핵심 데이터로 활용되어 공급망 보안과 시스템 무결성을 보장합니다.
@@ -22,10 +22,10 @@
## 🔗 Knowledge Connections
### Related Concepts
* **[[SCA (Software Composition Analysis)]]**: 외부 라이브러리의 CVE 및 라이선스 위반을 탐지하는 핵심 기술입니다.
* **[[SAST (Static Application Security Testing)]]**: 소스 코드 내의 CWE 패턴(인젝션 등)을 정적으로 식별하는 도구입니다.
* **[[Policy-as-code]]**: 보안 표준(CVE 차단 등)을 CI/CD 파이프라인에서 자동 강제하는 구현 방식입니다.
* **[[OWASP Top 10]]**: 웹 보안 분야에서 가장 널리 통용되는 취약점 우선순위 가이드입니다.
* **SCA (Software Composition Analysis**: 외부 라이브러리의 CVE 및 라이선스 위반을 탐지하는 핵심 기술입니다.
* **[[SAST (Static Application Security Testing)|SAST (Static Application Security Testing]]**: 소스 코드 내의 CWE 패턴(인젝션 등)을 정적으로 식별하는 도구입니다.
* **Policy-as-code**: 보안 표준(CVE 차단 등)을 CI/CD 파이프라인에서 자동 강제하는 구현 방식입니다.
* **[[OWASP Top 10|OWASP Top 10]]**: 웹 보안 분야에서 가장 널리 통용되는 취약점 우선순위 가이드입니다.
### Deeper Research Questions
* SCA 도구에서 발견된 수많은 CVE 중 '실행 경로(Exploitable Path)' 상에 존재하여 즉각적인 조치가 필요한 위험을 선별하는 효율적인 분석 기법은 무엇인가?
@@ -42,8 +42,8 @@
* **My Project Relevance:** PR 병합 전 단계에 CVE 스캔을 필수화하고, 심각한 결함 발견 시 자동으로 배포를 차단하는 보안 게이트를 설정합니다.
### Adjacent Topics
* **[[Software Supply Chain Security]]**: 소스 코드를 넘어 패키지 매니저, 빌드 도구 등 소프트웨어 공급망 전체의 무결성을 확보하는 전략으로 확장됩니다.
* **[[Zero Day Vulnerability]]**: 아직 패치가 존재하지 않는 알려지지 않은 취약점에 대한 실시간 탐지 및 대응 전략입니다.
* **Software Supply Chain Security**: 소스 코드를 넘어 패키지 매니저, 빌드 도구 등 소프트웨어 공급망 전체의 무결성을 확보하는 전략으로 확장됩니다.
* **Zero Day Vulnerability**: 아직 패치가 존재하지 않는 알려지지 않은 취약점에 대한 실시간 탐지 및 대응 전략입니다.
---
*Last updated: 2026-05-02*
10_Wiki/Topics/04_Governance_Reliability/Static Analysis & Linting (정적 분석 및 린팅).md
+9 -9
View File
@@ -1,4 +1,4 @@
# [[Static Analysis & Linting (정적 분석 및 린팅)]]
# [[Static Analysis & Linting (정적 분석 및 린팅)|Static Analysis & Linting (정적 분석 및 린팅]]
## 📌 Brief Summary
정적 분석 및 린팅은 소프트웨어를 실행하지 않고 소스 코드 자체를 알고리즘 기반으로 검사하여 스타일 위반, 문법 오류, 잠재적 버그, 보안 취약점을 자동으로 식별하는 기술입니다 [1]. 린팅(Linting)은 주로 코드 컨벤션과 포맷팅 등 스타일 이슈를 처리하여 리뷰어의 사소한 지적(Nitpicking)을 제거하며, SAST(Static Application Security Testing)는 보안 결함을 조기에 발견하는 시프트 레프트(Shift-Left)의 핵심 도구로 작동합니다 [3, 4]. 이를 통해 인간 리뷰어는 기계적인 검사에서 벗어나 아키텍처 설계와 비즈니스 로직 등 고차원적인 피드백에 집중할 수 있습니다.
@@ -13,7 +13,7 @@
* **자동화 통합 전략:**
* **Pre-commit Hooks:** 개발자가 코드를 커밋하기 직전 로컬에서 선제적으로 린팅과 기본 검사를 실행하여 부적절한 코드가 원격 저장소에 올라가는 것을 방지합니다 [32, 33].
* **CI/CD 파이프라인:** 모든 PR 단계에서 자동화된 정적 분석을 수행하여 병합 전 최종 품질을 강제합니다 [7, 8].
* **도구 생태계:** JavaScript(ESLint), Python(Pylint, Ruff), Java(Checkstyle, SonarQube) 등 언어별 표준 도구를 활용하고 Google/Airbnb 스타일 가이드를 벤치마킹합니다 [14, 17].
* **도구 생태계:** JavaScript(ESLint), Python(Pylint, Ruff), Java(Checkstyle, SonarQube) 등 언어별 표준 도구를 활용하고, 최근에는 AI가 오탐(False Positive)을 걸러주는 'AI-Driven SAST'가 도입되어 분석 정확도를 높이고 있습니다 [14, 17, 23].
## ⚖️ Trade-offs & Caveats
* **맥락 이해의 한계:** 자동화 도구는 사전에 정의된 패턴은 잘 찾지만, 코드의 비즈니스 목적이나 아키텍처적 의도, 운영 환경의 실제 영향도는 이해하지 못합니다 [19].
@@ -23,14 +23,14 @@
## 🔗 Knowledge Connections
### Related Concepts
* **[[CI/CD Pipeline]]**: 정적 분석과 린팅이 실시간으로 실행되어 품질 게이트 역할을 수행하는 물리적 환경입니다.
* **[[Nitpicking]]**: 린팅 도구가 자동화하여 인간 리뷰어의 피로를 해결해 주는 사소한 스타일 지적 행위입니다.
* **[[Shift-Left Security]]**: 보안 스캔을 개발 초기 단계로 앞당겨 리스크를 조기 차단하는 전략적 접근입니다.
* **[[Code Formatter]]**: 린트 경고를 넘어 코드를 설정된 스타일에 맞춰 기계적으로 변환(Auto-fix)해 주는 도구입니다.
* **[[CI-CD Pipeline|CI/CD Pipeline]]**: 정적 분석과 린팅이 실시간으로 실행되어 품질 게이트 역할을 수행하는 물리적 환경입니다.
* **Nitpicking**: 린팅 도구가 자동화하여 인간 리뷰어의 피로를 해결해 주는 사소한 스타일 지적 행위입니다.
* **Shift-Left Security**: 보안 스캔을 개발 초기 단계로 앞당겨 리스크를 조기 차단하는 전략적 접근입니다.
* **Code Formatter**: 린트 경고를 넘어 코드를 설정된 스타일에 맞춰 기계적으로 변환(Auto-fix)해 주는 도구입니다.
### Deeper Research Questions
* 기존 규칙이 없던 대규모 레거시 프로젝트에 엄격한 린팅과 SAST 규칙을 도입할 때, 팀의 반발을 최소화하며 점진적으로 적용하는 전략은 무엇인가?
* 규칙 기반(Rule-based) 린터와 AI 기반(LLM) 코드 분석 도구가 파이프라인 내에서 어떻게 상호 보완적으로 작동할 때 가장 높은 탐지 효율을 내는가?
* 규칙 기반(Rule-based) 린터와 AI 기반(LLM) 코드 분석 도구가 파이프라인 내에서 어떻게 상호 보완적으로 작동할 때 가장 높은 탐지 효율을 내는가? 특히 AI-Driven SAST가 오탐률을 획기적으로 줄일 수 있는가?
* 정적 분석 도구로 탐지가 불가능한 '도메인 특화 비즈니스 결함'을 잡기 위해 인간 리뷰어가 갖춰야 할 체크리스트는 어떻게 구성해야 하는가?
* 커스텀 린트 규칙(Custom Lint Rules)을 활용하여 아키텍처 계층 간의 잘못된 참조(예: Controller에서 Repository 직접 참조)를 자동 차단하는 방법은 무엇인가?
* 자동화된 스타일 교정이 PR의 변경 이력(Git Blame 등) 가독성에 미치는 영향을 최소화하기 위한 운영 팁은 무엇인가?
@@ -43,8 +43,8 @@
* **My Project Relevance:** "린팅 통과 여부"를 PR 머지의 필수 체크포인트로 설정하여 로직 무결성 검증에 집중할 수 있는 문화를 정착시킵니다.
### Adjacent Topics
* **[[Code Smells]]**: 정적 분석 도구가 감지하고자 하는 '장기적 유지보수를 저해하는 나쁜 코드 징후' 패턴들을 탐구합니다.
* **[[Dynamic Application Security Testing (DAST)]]**: 실행 중인 환경에서 취약점을 찾는 기법으로, 정적 분석과 상호 보완적입니다.
* **Code Smells**: 정적 분석 도구가 감지하고자 하는 '장기적 유지보수를 저해하는 나쁜 코드 징후' 패턴들을 탐구합니다.
* **Dynamic Application Security Testing (DAST**: 실행 중인 환경에서 취약점을 찾는 기법으로, 정적 분석과 상호 보완적입니다.
---
*Last updated: 2026-05-02*
10_Wiki/Topics/04_Governance_Reliability/Styling_Governance.md
+8 -8
View File
@@ -1,21 +1,21 @@
---
title: 스타일 거버넌스 및 디자인 시스템
category: Software [[Architecture]]
tags: [Styling, Tailwind, [[CSS-in-JS]], Design[[ system]], Responsive]
category: Software [[Architecture|Architecture]]
tags: [Styling, Tailwind, [[CSS-in-JS|CSS-in-JS]], DesignSystem, Responsive]
created: 2026-04-20
---
# [[Styling_Governance]] (스타일 매니지먼트)
# [[Styling_Governance|Styling_Governance]] (스타일 매니지먼트)
## 📌 한 줄 통찰 (The Karpathy Summary)
> 디자인은 '예쁜 픽셀'이 아니라 '일관된 약속'이다. 단 하나의 변수가 바뀌었을 때 전체 앱의 조화가 유지되는 구조가 진짜 디자인 시스템이다.
## 📖 구조화된 지식 (Synthesized Content)
- **[[Design Tokens]] (디자인 토큰)**:
- **[[Design Tokens|Design Tokens]] (디자인 토큰)**:
- 색상(#FF0000 -> `brand-primary`), 여백(16px -> `spacing-md`)을 추상화된 이름으로 정의하라. 그래야 브랜드 리뉴얼 시 코드 한 줄로 대응 가능하다.
- **Utility-First vs Runtime Style**:
- **[[Tailwind CSS]]**: 클래스명으로 스타일을 정의하여 런타임 오버헤드가 없고 개발 속도가 압도적이다.
- **[[styled-components]]**: 컴포넌트 중심의 의미론적 스타일링과 동적 Props 처리에 강점이 있다.
- **[[Tailwind CSS|Tailwind CSS]]**: 클래스명으로 스타일을 정의하여 런타임 오버헤드가 없고 개발 속도가 압도적이다.
- **[[styled-components|styled-components]]**: 컴포넌트 중심의 의미론적 스타일링과 동적 Props 처리에 강점이 있다.
- **Mobile First Responsive**:
- 작은 화면부터 디자인을 시작하여 넓은 화면으로 확장하라. 이것이 CSS 코드를 30% 이상 줄이는 지름길이다.
@@ -23,5 +23,5 @@ created: 2026-04-20
- 과도한 '공통 컴포넌트'화는 오히려 독이 될 수 있다. 버튼 하나에 옵션이 20개가 달리는 순간, 그 버튼은 유지보수의 재앙이 된다. 적절한 '복제'와 '분리'의 균형을 유지하라.
## 🔗 지식 연결 (Graph)
- Related: [[Component_Design_Patterns]] , [[Accessibility_Inclusivity]]
- Best Practice: [[React_Clean_Code_Best_Practices]]
- Related: [[Component_Design_Patterns|Component_Design_Patterns]] , [[Accessibility_Inclusivity|Accessibility_Inclusivity]]
- Best Practice: [[React_Clean_Code_Best_Practices|React_Clean_Code_Best_Practices]]
10_Wiki/Topics/04_Governance_Reliability/System_Debugging_Protocol.md
+3 -3
View File
@@ -1,6 +1,6 @@
---
title: 단계별 시스템 디버깅 체크리스트 (L1~L3)
category: Software [[Architecture]]
category: Software [[Architecture|Architecture]]
tags: [Debugging, Troubleshooting, Checklist, Process]
created: 2026-04-20
---
@@ -23,5 +23,5 @@ created: 2026-04-20
- **필수 조치**: 최소 실행 예제(MRE)를 통한 격리 테스트.
## 🔗 연결된 지식
- [[Tetris_Project_Retrospective]]
- [[DevOps_Environment_Setup]]
- [[Tetris_Project_Retrospective|Tetris_Project_Retrospective]]
- [[DevOps_Environment_Setup|DevOps_Environment_Setup]]
10_Wiki/Topics/04_Governance_Reliability/System_Protocol_Standard.md
+4 -4
View File
@@ -1,7 +1,7 @@
---
title: 표준 시스템 통신 프로토콜 및 상태 제어
category: Software [[Architecture]]
tags: [Protocol, [[State]] Machine, Data Exchange, Lifecycle]
category: Software [[Architecture|Architecture]]
tags: [Protocol, [[State|State]] Machine, Data Exchange, Lifecycle]
created: 2026-04-20
---
@@ -16,11 +16,11 @@ created: 2026-04-20
- `UPDATE`: 엔진 계산 결과의 브로드캐스트.
## 🔄 시스템 생명 주기 (Life Cycle)
시스템은 [초기화 $\rightarrow$ 활성 루프 $\rightarrow$ 종료/정리]의 명확한 단계를 거쳐야 리소스 누수([[memory]] Leak)를 방지할 수 있습니다.
시스템은 [초기화 $\rightarrow$ 활성 루프 $\rightarrow$ 종료/정리]의 명확한 단계를 거쳐야 리소스 누수([[memory|memory]] Leak)를 방지할 수 있습니다.
## 🚨 상태 머신 (State Machine) 도입
시스템 복잡도가 임계치를 넘을 경우, `READY`, `RUNNING`, `PAUSED` 등 상태를 명시적으로 제어하는 **State Machine** 적용을 원칙으로 삼습니다.
## 🔗 연결된 지식
- Project_Architecture_Guidelines
- [[Single_Source_of_Truth]]
- [[Single_Source_of_Truth|Single_Source_of_Truth]]
10_Wiki/Topics/04_Governance_Reliability/Testing Strategy.md
+7 -7
View File
@@ -6,7 +6,7 @@ tags: [development, testing-strategy, testability, tdd, automated-testing, quali
last_reinforced: 2026-05-01
---
# [[Testing Strategy]]
# [[Testing Strategy|Testing Strategy]]
## 📌 한 줄 통찰 (The Karpathy Summary)
> "코드의 의도를 명세화(Documentation)하고, 변경에 대한 즉각적인 회귀(Regression) 방지망을 구축하여 지속적인 배포와 리팩토링을 가능하게 하는 품질의 초석."
@@ -17,7 +17,7 @@ last_reinforced: 2026-05-01
1. **테스트 가능성 (Testability)**:
* **설계적 접근**: 코드가 쉽게 테스트될 수 있도록 의존성을 주입(DI)받고, 인터페이스를 통해 외부 모듈을 격리(Mocking)합니다. 정적 메서드나 싱글톤의 남용은 테스트 가능성을 저해합니다.
* **결정론적 테스트**: 테스트는 환경이나 실행 순서에 영향을 받지 않고 항상 동일한 결과를 내야 합니다.
2. **[[Test-Driven Development (TDD)]]**:
2. **Test-Driven Development (TDD**:
* 실패하는 테스트를 먼저 작성(Red) -> 기능을 구현(Green) -> 코드를 개선(Refactor)하는 사이클을 통해 테스트가 코드의 설계를 주도하게 만듭니다.
3. **리뷰 단계에서의 테스트**:
* **테스트 코드 우선 리뷰**: 테스트를 먼저 읽으면 해당 기능의 유즈케이스와 의도를 더 명확히 파악할 수 있습니다.
@@ -30,9 +30,9 @@ last_reinforced: 2026-05-01
- **유지보수 비용**: 테스트 코드 역시 관리 대상인 부채입니다. 과도하게 복잡한 테스트 로직이나 불필요한 구현 세부 사항에 결합된 테스트는 리팩토링을 방해할 수 있으므로, 테스트 자체의 품질과 단순성도 유지해야 합니다.
## 🔗 지식 연결 (Graph)
- [[Automated Quality & Review]]: 테스트가 자동으로 실행되는 환경.
- [[Dependency Injection (DI)]]: 테스트 가능성을 높이는 핵심 기술.
- [[CI-CD Pipeline]]: 테스트 결과에 따라 병합 여부를 결정하는 시스템.
- [[Refactoring]]: 테스트라는 안전망이 있을 때 비로소 가능해지는 활동.
- [[Mocking and Test Doubles]]: 외부 의존성 격리 기법.
- [[Automated Quality & Review|Automated Quality & Review]]: 테스트가 자동으로 실행되는 환경.
- [[Dependency Injection (DI)|Dependency Injection (DI]]: 테스트 가능성을 높이는 핵심 기술.
- [[CI-CD Pipeline|CI-CD Pipeline]]: 테스트 결과에 따라 병합 여부를 결정하는 시스템.
- [[Refactoring|Refactoring]]: 테스트라는 안전망이 있을 때 비로소 가능해지는 활동.
- Mocking and Test Doubles: 외부 의존성 격리 기법.
---