[G1-Sync] Manual knowledge update
This commit is contained in:
Antigravity Agent
@@ -0,0 +1,36 @@
|
||||
---
|
||||
id: P-REINFORCE-AUTO-WIKI-AUTO-001
|
||||
category: "10_Wiki/💡 Topics/Automation"
|
||||
confidence_score: 0.95
|
||||
tags: [automation, code-review, static-analysis, linting, quality-gate, dev-tools, p-reinforce]
|
||||
last_reinforced: 2026-05-01
|
||||
---
|
||||
|
||||
# [[Automated Quality & Review]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "인간 리뷰어보다 먼저 코드의 구문, 스타일, 알려진 취약점을 필터링하여 품질의 최소 기준을 강제하고, 리뷰 시간을 고부가가치 설계 토론에 집중시키는 지능형 자동화 방어선."
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
자동화된 품질 관리는 현대 엔지니어링의 생산성을 결정짓는 필수 인프라입니다.
|
||||
|
||||
1. **정적 분석 및 린팅 (Static Analysis & Linting)**:
|
||||
* **구문 및 스타일 강제**: 린터(Linter)와 포매터(Formatter)를 통해 팀의 컨벤션을 자동으로 유지하며 소모적인 스타일 논쟁을 제거합니다.
|
||||
* **[[SAST (Static Application Security Testing)]]**: 소스 코드 레벨에서 OWASP Top 10 등의 보안 결함을 조기에 탐지합니다.
|
||||
2. **리뷰 자동화 (Review Automation)**:
|
||||
* **품질 게이트 (Quality Gate)**: CI/CD 파이프라인과 연동하여 테스트 커버리지, 코드 복잡도, 보안 기준을 충족하지 못한 PR의 병합을 시스템적으로 차단합니다.
|
||||
* **사전 커밋 훅 (Pre-commit Hooks)**: 코드가 원격 저장소에 푸시되기 전 로컬에서 즉각적인 피드백을 제공하여 수정 주기를 단축합니다.
|
||||
3. **도구 통합 (Tools Integration)**:
|
||||
* GitHub Actions, SonarQube, CodeClimate 등 다양한 분석 도구를 PR 워크플로우에 통합하여 코드 건강 상태를 가시화하고 추적합니다.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **오탐(False Positive)의 노이즈**: 자동화 도구가 실제 위협이 아닌 코드를 결함으로 지적할 경우 개발자의 피로도가 증가합니다. 프로젝트 맥락에 맞는 규칙 커스터마이징과 예외 처리 정책이 중요합니다.
|
||||
- **인간의 대체 불가능성**: 자동화는 정해진 패턴은 잘 찾지만 비즈니스 맥락, 아키텍처 의도, 복잡한 접근 제어 로직은 이해하지 못합니다. 기계는 '규칙 준수'를, 인간은 '의도와 설계'를 검증하는 분업 구조를 유지해야 합니다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[SAST (Static Application Security Testing)]]: 정적 보안 분석의 심화.
|
||||
- [[CI-CD Pipeline]]: 자동화 검증이 실행되는 핵심 환경.
|
||||
- [[Code Review Checklist]]: 자동화가 처리하지 못하는 인간의 영역.
|
||||
- [[Shift-Left Security]]: 보안 점검을 자동화로 조기 도입하는 전략.
|
||||
- [[Technical Debt]]: 자동화된 대시보드를 통해 관리되는 부채.
|
||||
---
|
||||
@@ -0,0 +1,35 @@
|
||||
---
|
||||
id: P-REINFORCE-AUTO-WIKI-DEV-003
|
||||
category: "10_Wiki/💡 Topics/Development"
|
||||
confidence_score: 0.95
|
||||
tags: [development, ci-cd, automation, quality-gate, devops, p-reinforce]
|
||||
last_reinforced: 2026-05-01
|
||||
---
|
||||
|
||||
# [[CI-CD Pipeline]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "소프트웨어의 빌드, 테스트, 배포 전 과정을 자동화하여, 인간 리뷰어보다 먼저 결함을 찾아내는 '기계적 파수꾼'이자 배포의 신뢰성을 보장하는 핵심 인프라."
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
CI-CD는 현대적 개발 워크플로우에서 품질과 속도를 동시에 잡는 핵심 엔진입니다.
|
||||
|
||||
1. **자동화된 품질 게이트 (Quality Gates)**:
|
||||
* **CI (Continuous Integration)**: 코드 변경 시마다 빌드와 테스트를 자동으로 수행합니다. 린터, SAST, SCA 등이 통합되어 인간 리뷰어에게 도달하기 전 기초 결함을 필터링합니다.
|
||||
* **CD (Continuous Delivery/Deployment)**: 검증된 코드를 스테이징이나 프로덕션 환경으로 자동 배포합니다.
|
||||
2. **병합 차단 (Blocking Merges)**:
|
||||
* 자동화 테스트가 실패하거나 보안 스캔에서 취약점이 발견되면 메인 브랜치로의 병합을 시스템적으로 차단하여 안전성을 확보합니다.
|
||||
3. **인지 부하 감소**:
|
||||
* 사소한 스타일 위반이나 오타 등은 기계가 처리하므로, 인간 리뷰어는 아키텍처와 비즈니스 로직 같은 고차원적 검토에 집중할 수 있습니다.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **파이프라인 지연의 역설**: 품질 검증을 위해 너무 많은 단계(무거운 E2E 테스트 등)를 추가하면 파이프라인 속도가 느려져 개발 피드백 루프를 저해합니다. 검증 강도와 실행 속도 사이의 정교한 밸런싱이 필수적입니다.
|
||||
- **자동화의 한계**: CI-CD는 정해진 패턴은 잘 찾지만 비즈니스적 맥락이나 설계상의 논리적 오류는 잡지 못합니다. 기계적 검증과 인간의 정성적 리뷰가 결합된 상호 보완 구조를 유지해야 합니다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Shift-Left Security]]: 보안 점검을 CI 단계로 앞당기는 전략.
|
||||
- [[Automated Testing]]: 파이프라인의 핵심 관문.
|
||||
- [[Pull Request Workflow]]: CI-CD가 트리거되는 지점.
|
||||
- [[DevSecOps]]: 보안이 내재화된 자동화 철학.
|
||||
- [[Infrastructure as Code (IaC)]]: 인프라 배포의 자동화 확장.
|
||||
---
|
||||
@@ -0,0 +1,35 @@
|
||||
---
|
||||
id: P-REINFORCE-AUTO-WIKI-DEV-002
|
||||
category: "10_Wiki/💡 Topics/Development"
|
||||
confidence_score: 0.95
|
||||
tags: [development, refactoring, code-quality, maintainability, technical-debt, p-reinforce]
|
||||
last_reinforced: 2026-05-01
|
||||
---
|
||||
|
||||
# [[Code Refactoring]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "시스템의 겉보기 동작(Behavior)은 유지한 채 내부 구조를 개선하여, 인간에게는 더 읽기 쉽고 시스템에게는 더 변화에 유연하게 만드는 지속적인 코드 정제 작업."
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
리팩토링은 기술 부채를 관리하고 소프트웨어의 생명력을 유지하는 핵심 활동입니다.
|
||||
|
||||
1. **목적의 분리 (Separation of Concerns)**:
|
||||
* **기능 추가와 리팩토링의 분리**: 새로운 기능 구현과 코드 구조 개선은 반드시 별도의 풀 리퀘스트(PR)로 진행해야 합니다. 섞일 경우 리뷰어의 인지 부하가 급증하고 검증의 정확도가 떨어집니다.
|
||||
* **스타일 수정의 독립성**: 포맷팅이나 명칭 변경과 같은 리팩토링도 기능 변경과 섞지 않는 것이 원칙입니다.
|
||||
2. **안전망 확보**:
|
||||
* 리팩토링의 전제 조건은 견고한 **자동화 테스트**입니다. 로직 개선 후에도 기존 기능이 완벽히 작동함을 증명할 수 있어야 합니다.
|
||||
3. **효율적 전략**:
|
||||
* 대규모 리팩토링은 한 번에 처리하기보다 200~400줄 단위로 잘게 쪼개어(Decomposition) 단계적으로 진행하는 것이 리뷰 품질과 속도 면에서 유리합니다.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **리뷰 지연의 부작용**: 코드 리뷰 프로세스가 너무 느리면 개발자들은 리팩토링이나 코드 정리를 기피하게 되어 장기적으로 기술 부채가 누적됩니다. 빠른 리뷰 피드백 루프가 건강한 리팩토링 문화를 만듭니다.
|
||||
- **사후 비용 vs 사전 설계**: 개발 완료 후의 리팩토링은 비용이 많이 듭니다. 아키텍처 리뷰를 통한 사전 설계 검토(Shift-Left)가 대규모 리팩토링을 예방하는 가장 효율적인 정책입니다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Technical Debt]]: 리팩토링이 상환하고자 하는 비용.
|
||||
- [[Automated Testing]]: 리팩토링을 가능하게 하는 안전망.
|
||||
- [[Code Health]]: 리팩토링의 궁극적인 지향점.
|
||||
- [[Single-purpose PR]]: 리팩토링 시 준수해야 할 PR 정책.
|
||||
- [[Architecture Review]]: 대규모 리팩토링을 예방하는 선제적 대응.
|
||||
---
|
||||
@@ -0,0 +1,38 @@
|
||||
---
|
||||
id: P-REINFORCE-AUTO-WIKI-DEV-001
|
||||
category: "10_Wiki/💡 Topics/Development"
|
||||
confidence_score: 0.95
|
||||
tags: [development, code-review, checklist, quality-assurance, best-practices, p-reinforce]
|
||||
last_reinforced: 2026-05-01
|
||||
---
|
||||
|
||||
# [[Code Review Checklist]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "주관적인 코드 검토를 객관적이고 반복 가능한 품질 보증 프로세스로 전환하여, 인간의 실수를 방지하고 팀의 기술적 부채를 조기에 차단하는 체계적인 가이드라인."
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
코드 리뷰 체크리스트는 일관된 품질을 유지하기 위한 팀의 합의된 기준입니다.
|
||||
|
||||
1. **핵심 점검 영역**:
|
||||
* **기능 및 논리**: 요구사항 충족 여부 및 엣지 케이스 처리 확인.
|
||||
* **아키텍처**: [[SOLID Principles]] 준수 및 과도한 엔지니어링 방지.
|
||||
* **보안**: [[OWASP Top 10]] 기준 위반 및 민감 데이터 노출 여부 점검.
|
||||
* **가독성**: 네이밍 컨벤션, 중복 코드 제거, 유지보수 용이성 확보.
|
||||
* **테스트 및 문서화**: 유의미한 테스트 코드 포함 및 '왜'에 대한 주석/문서 업데이트.
|
||||
2. **자동화와의 분업**:
|
||||
* 스타일, 포맷팅, 단순 보안 패턴은 린터(Linter)와 SAST에 맡기고, 인간은 비즈니스 로직과 구조적 무결성에 집중합니다.
|
||||
3. **현대적 확장 (AI 생성 코드)**:
|
||||
* AI가 제안한 존재하지 않는 API(Hallucination)나 보안 권한 누락 등을 별도로 검증해야 합니다.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **고무 도장(Rubber-stamping)의 위험**: 체크리스트가 너무 길어지면 기계적으로 체크만 하고 넘어가는 현상이 발생합니다. 필수 점검 항목을 정예화하고 운영 효율성을 고려한 유연한 적용 정책이 필요합니다.
|
||||
- **살아있는 문서화**: 기술 스택과 팀의 성숙도에 따라 체크리스트는 주기적으로 업데이트되어야 하며, 불필요해진 항목은 과감히 자동화 로직으로 이관해야 합니다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[SOLID Principles]]: 아키텍처 점검의 근간.
|
||||
- [[OWASP Top 10]]: 보안 점검의 표준.
|
||||
- [[Pull Request Templates]]: 체크리스트를 워크플로우에 내장하는 도구.
|
||||
- [[Automated Code Analysis]]: 수동 체크리스트의 부담을 줄이는 자동화 기법.
|
||||
- [[Technical Debt]]: 체크리스트 부실 시 발생하는 비용.
|
||||
---
|
||||
@@ -0,0 +1,36 @@
|
||||
---
|
||||
id: P-REINFORCE-AUTO-WIKI-DEV-004
|
||||
category: "10_Wiki/💡 Topics/Development"
|
||||
confidence_score: 0.95
|
||||
tags: [development, pair-programming, mob-programming, collaboration, synchronous-review, p-reinforce]
|
||||
last_reinforced: 2026-05-01
|
||||
---
|
||||
|
||||
# [[Collaborative Programming (Pair & Mob)]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "코드 작성과 리뷰를 실시간으로 통합하여 피드백 루프를 극단적으로 단축시키고, 집단 지성을 통해 고난도 문제 해결과 지식 전파를 가속화하는 동기식 협업 모델."
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
동기식 협업 프로그래밍은 비동기 리뷰의 지연을 제거하고 코드의 즉각적인 무결성을 확보합니다.
|
||||
|
||||
1. **[[Pair Programming]]**:
|
||||
* **Driver & Navigator**: 한 명은 코드를 작성(Driver)하고, 다른 한 명은 로직과 설계 방향을 검토(Navigator)합니다.
|
||||
* **실시간 피드백**: 코드 작성 시점에 즉시 리뷰가 이루어지므로, PR 대기 시간 없이 높은 신뢰도의 코드를 생산합니다.
|
||||
2. **[[Mob Programming]]**:
|
||||
* 팀 전체가 하나의 컴퓨터로 하나의 문제를 해결합니다.
|
||||
* 아키텍처 결정이나 익숙하지 않은 복잡한 도메인을 다룰 때 지식 사일로를 제거하는 데 탁월합니다.
|
||||
3. **지식 전파 및 온보딩**:
|
||||
* 시니어의 암묵지 전수와 팀 컨벤션의 자연스러운 체득을 돕는 강력한 교육 도구로 활용됩니다.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **리소스와 피로도**: 두 명 이상의 개발자가 동시에 투입되므로 자원 소모가 크며, 높은 집중력 요구로 인해 번아웃이 발생할 수 있습니다. 60~90분 단위의 타임박스 세션과 정기적인 휴식 정책이 필수입니다.
|
||||
- **하이브리드 전략**: 모든 작업에 적용하기보다 고위험군(복잡한 아키텍처, 보안 민감 기능)에 집중하고, 단순 작업은 비동기 리뷰로 처리하는 선별적 적용이 효율적입니다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Asynchronous Code Review]]: 동기식 모델과 대비되는 일반적 방식.
|
||||
- [[Knowledge Sharing]]: 협업을 통한 지식 전파 효과.
|
||||
- [[Shift-Left Security]]: 작성 시점에 보안을 검토하는 최전선 전략.
|
||||
- [[Agile Development]]: 빠른 피드백과 소통을 중시하는 철학적 배경.
|
||||
- [[Pull Request Workflow]]: 최종 결과물이 시스템에 통합되는 통로.
|
||||
---
|
||||
@@ -0,0 +1,36 @@
|
||||
---
|
||||
id: P-REINFORCE-AUTO-WIKI-DEV-005
|
||||
category: "10_Wiki/💡 Topics/Development"
|
||||
confidence_score: 0.95
|
||||
tags: [development, communication, conventional-commits, conventional-comments, standardization, p-reinforce]
|
||||
last_reinforced: 2026-05-01
|
||||
---
|
||||
|
||||
# [[Development Communication Standards (Conventional Commits & Comments)]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "코드와 피드백의 의도를 라벨링하여 인간 간의 오해를 줄이고 기계적 처리를 가능하게 하는 텍스트 표준화 전략: 명확한 소통이 개발 속도와 심리적 안전감을 결정한다."
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
개발 과정에서 발생하는 텍스트 기반 소통을 규격화하여 협업 효율을 극대화합니다.
|
||||
|
||||
1. **[[Conventional Commits]]**:
|
||||
* 커밋 메시지에 유형(예: `feat:`, `fix:`, `chore:`, `refactor:`)을 명시합니다.
|
||||
* 자동화된 릴리스 노트 생성과 버전 관리(Semantic Versioning)의 기반이 됩니다.
|
||||
2. **[[Conventional Comments]]**:
|
||||
* 코드 리뷰 시 코멘트 앞에 라벨(예: `suggestion:`, `issue:`, `nitpicked:`, `praise:`)을 붙입니다.
|
||||
* **Decorations**: `(blocking)` vs `(non-blocking)`을 통해 즉각적인 수정 필요 여부를 명시하여 작성자의 혼란을 제거합니다.
|
||||
3. **심리적 안전감과 효율성**:
|
||||
* 라벨링은 피드백을 '공격'이 아닌 '객관적 분류'로 인지하게 도와주며, 사소한 트집(Nitpicking)에 낭비되는 시간을 줄여줍니다.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과도한 형식주의**: 형식 준수에 매몰되어 본질적인 피드백의 질이 떨어지는 것을 경계해야 합니다. 도구(브라우저 확장 등)를 활용하여 형식 입력의 마찰을 최소화하는 것이 중요합니다.
|
||||
- **자동화와의 병행**: `nit:`(사소한 스타일) 코멘트가 많아지면 중요한 로직 피드백이 가려질 수 있습니다. 스타일 이슈는 린터가, 비즈니스 로직은 인간이 담당하는 역할 분담이 전제되어야 합니다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Constructive Feedback]]: 건설적 피드백의 구체적 실천법.
|
||||
- [[Non-blocking Feedback]]: 개발 속도를 유지하는 리뷰 전략.
|
||||
- [[Automated Code Analysis]]: 사소한 지적을 자동화로 이관하는 구조.
|
||||
- [[Pull Request Workflow]]: 표준화된 소통이 이루어지는 주무대.
|
||||
- [[Non-violent Communication]]: 커뮤니케이션의 심리학적 배경.
|
||||
---
|
||||
@@ -0,0 +1,38 @@
|
||||
---
|
||||
id: P-REINFORCE-AUTO-WIKI-DEV-007
|
||||
category: "10_Wiki/💡 Topics/Development"
|
||||
confidence_score: 0.95
|
||||
tags: [development, pull-request, review-workflow, pr-size-limits, architecture-review, agile, p-reinforce]
|
||||
last_reinforced: 2026-05-01
|
||||
---
|
||||
|
||||
# [[Modern Review Workflow]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "작고 집중된 변경(Small Batches)을 통해 인지 부하를 줄이고, 사전 설계 검토와 자동화 게이트를 결합하여 개발 속도와 아키텍처 무결성을 동시에 확보하는 협업 프로세스."
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
현대적인 리뷰 워크플로우는 단순히 코드를 검사하는 단계를 넘어 배포의 안전성과 팀의 민첩성을 보장하는 핵심 프로세스입니다.
|
||||
|
||||
1. **풀 리퀘스트 (Pull Request / Merge Request)**:
|
||||
* 코드 변경 사항을 메인 브랜치에 병합하기 전, 동료들의 검토와 자동화 테스트를 거치는 공식적인 관문입니다.
|
||||
* **단일 목적 지향**: 하나의 PR은 기능 추가, 버그 수정, 리팩토링 중 단 하나의 명확한 목적만 가져야 합니다.
|
||||
2. **[[PR Size Limits]] (작은 PR의 원칙)**:
|
||||
* **인지적 한계**: 리뷰어는 200~400 LOC(Lines of Code) 사이에서 가장 높은 결함 발견율을 보입니다. 400줄을 초과하면 집중력이 급격히 저하되어 '고무 도장(Rubber-stamping)' 리뷰가 될 위험이 큽니다.
|
||||
* **분할 전략**: 거대 기능은 **기능 플래그(Feature Flags)**나 **누적 PR(Stacked PRs)**을 활용하여 작은 단위로 나누어 병합합니다.
|
||||
3. **[[Architecture Review]] (Shift-Left)**:
|
||||
* 코드를 작성하기 전, 설계 문서나 ADR(Architecture Decision Record)을 통해 방향성을 먼저 합의합니다. 이는 대규모 리팩토링 비용을 사전에 차단하는 가장 효율적인 전략입니다.
|
||||
4. **애자일 개발과의 조화**:
|
||||
* 지속적 통합(CI)과 빈번한 병합을 통해 코드 노후화(Stale)를 방지하고 피드백 루프를 극단적으로 단축합니다.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **전체 맥락의 상실**: PR을 너무 작게 쪼개면 시스템의 '큰 그림'을 놓칠 수 있습니다. 이를 보완하기 위해 PR 설명에 상위 목표와의 연결성을 명시하거나, 사전 설계 리뷰를 병행해야 합니다.
|
||||
- **분할 오버헤드**: 작은 PR로 나누는 작업 자체가 개발자에게 추가적인 부담이 될 수 있습니다. 이는 시스템을 느슨하게 결합(Loosely Coupled)된 모듈로 설계하여 자연스럽게 작은 변경이 가능하도록 아키텍처 수준에서 해결해야 합니다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Effective Code Review Feedback]]: 워크플로우 내에서의 구체적 소통법.
|
||||
- [[Automated Quality & Review]]: 인간의 리뷰 전 수행되는 자동화 관문.
|
||||
- [[Engineering Metrics (DORA)]]: 워크플로우 효율성을 측정하는 지표.
|
||||
- [[Feature Flags]]: 큰 기능을 안전하게 나누어 배포하는 기술.
|
||||
- [[Technical Debt]]: 비대해진 PR이 유발하는 잠재적 위험.
|
||||
---
|
||||
@@ -0,0 +1,38 @@
|
||||
---
|
||||
id: P-REINFORCE-AUTO-WIKI-DEV-008
|
||||
category: "10_Wiki/💡 Topics/Development"
|
||||
confidence_score: 0.95
|
||||
tags: [development, testing-strategy, testability, tdd, automated-testing, quality-assurance, p-reinforce]
|
||||
last_reinforced: 2026-05-01
|
||||
---
|
||||
|
||||
# [[Testing Strategy]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "코드의 의도를 명세화(Documentation)하고, 변경에 대한 즉각적인 회귀(Regression) 방지망을 구축하여 지속적인 배포와 리팩토링을 가능하게 하는 품질의 초석."
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
테스트 전략은 단순한 버그 탐지를 넘어 설계의 무결성과 개발 속도를 보장하는 핵심 활동입니다.
|
||||
|
||||
1. **테스트 가능성 (Testability)**:
|
||||
* **설계적 접근**: 코드가 쉽게 테스트될 수 있도록 의존성을 주입(DI)받고, 인터페이스를 통해 외부 모듈을 격리(Mocking)합니다. 정적 메서드나 싱글톤의 남용은 테스트 가능성을 저해합니다.
|
||||
* **결정론적 테스트**: 테스트는 환경이나 실행 순서에 영향을 받지 않고 항상 동일한 결과를 내야 합니다.
|
||||
2. **[[Test-Driven Development (TDD)]]**:
|
||||
* 실패하는 테스트를 먼저 작성(Red) -> 기능을 구현(Green) -> 코드를 개선(Refactor)하는 사이클을 통해 테스트가 코드의 설계를 주도하게 만듭니다.
|
||||
3. **리뷰 단계에서의 테스트**:
|
||||
* **테스트 코드 우선 리뷰**: 테스트를 먼저 읽으면 해당 기능의 유즈케이스와 의도를 더 명확히 파악할 수 있습니다.
|
||||
* **병합 차단 원칙**: 새로운 기능이나 버그 수정은 반드시 관련 테스트를 포함해야 하며, 테스트 부재는 머지를 차단하는 중대한 사유입니다.
|
||||
4. **엣지 케이스 및 실패 경로**:
|
||||
* 정상 동작뿐만 아니라 Null 입력, 빈 배열, 유효하지 않은 데이터 타입 등 다양한 실패 시나리오를 포괄적으로 검증합니다.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **커버리지의 함정**: 100% 테스트 커버리지라는 수치에 매몰되면 의미 없는 테스트 작성에 시간을 낭비하게 됩니다. 수치보다 '중요한 비즈니스 로직이 충분히 보호되고 있는가'라는 질적 지표가 우선되어야 합니다.
|
||||
- **유지보수 비용**: 테스트 코드 역시 관리 대상인 부채입니다. 과도하게 복잡한 테스트 로직이나 불필요한 구현 세부 사항에 결합된 테스트는 리팩토링을 방해할 수 있으므로, 테스트 자체의 품질과 단순성도 유지해야 합니다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Automated Quality & Review]]: 테스트가 자동으로 실행되는 환경.
|
||||
- [[Dependency Injection (DI)]]: 테스트 가능성을 높이는 핵심 기술.
|
||||
- [[CI-CD Pipeline]]: 테스트 결과에 따라 병합 여부를 결정하는 시스템.
|
||||
- [[Refactoring]]: 테스트라는 안전망이 있을 때 비로소 가능해지는 활동.
|
||||
- [[Mocking and Test Doubles]]: 외부 의존성 격리 기법.
|
||||
---
|
||||
Reference in New Issue
Block a user