Refactor: Consolidate directory structure into 5 main categories and update metadata
This commit is contained in:
Antigravity Agent
@@ -1,41 +0,0 @@
|
||||
---
|
||||
id: f6a5b4c3-d2e1-4f0a-9b8c-7d6e5f4a3b2c
|
||||
category: "10_Wiki/Topics/Development"
|
||||
confidence_score: 0.99
|
||||
tags: [agentic-se, software-engineering, ai-agent, harness, automation, development]
|
||||
last_reinforced: 2026-05-01
|
||||
github_commit: "wikification-agentic-se"
|
||||
---
|
||||
|
||||
# [[Agentic_Software_Engineering|Agentic Software Engineering]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 에이전틱 소프트웨어 엔지니어링은 개발자가 구현자(Implementer)에서 자율적으로 계획·코딩·디버깅하는 에이전트를 조율하는 오케스트레이터(Orchestrator)로 진화하는 패러다임이다.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
|
||||
### 1. 개발 패러다임의 전환
|
||||
- **오케스트레이션**: 인간은 시스템 아키텍처 설계와 전략적 방향 지시에 집중하고, 에이전트는 하네스 제어 하에 전술적 구현을 담당한다.
|
||||
- **PEV 루프 (Plan-Execute-Verify)**: 계획, 실행, 검증의 단계를 명시적으로 분리하여 에이전트의 작업 신뢰성을 확보한다.
|
||||
|
||||
### 2. 에이전트 하네스 인프라
|
||||
- **런타임 거버넌스**: 모델을 자율 에이전트로 변환하기 위해 실행 루프(E), 도구(T), 컨텍스트(C), 상태(S), 수명주기(L), 평가(V)를 제공하는 하네스가 필수적이다.
|
||||
- **격리된 실행**: 샌드박스(MicroVM/Container) 내에서 파일 시스템 접근, 명령어 실행, 시맨틱 분석을 안전하게 수행한다.
|
||||
|
||||
### 3. 가상 피드백 (SWE-World)
|
||||
- **효율적 학습**: 무거운 물리적 환경 대신 시뮬레이션된 피드백을 활용하여 에이전트의 강화학습 및 평가 효율을 극대화한다.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **자율성 vs 보안**: 셸 접근 등 강력한 도구는 유용하지만 인젝션 및 샌드박스 탈출 위험을 동반하므로 Pareto 최적점을 찾는 설계가 필요하다.
|
||||
- **컨텍스트 경제성**: 장기 작업 기록 보존은 추론에 유리하나 토큰 비용 급증과 '컨텍스트 부패'를 유발하므로 적응형 압축이 요구된다.
|
||||
- **하네스 편향성**: 에이전트의 성능 지표는 모델 지능뿐만 아니라 하네스의 도구 설계 및 에러 처리 방식에 크게 좌우된다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Parent**: 10_Wiki/Topics/Development
|
||||
- **Related**: [[Agent Harness|Agent Harness]], Model Context Protocol (MCP), Plan-Execute-Verify (PEV) Loop, SWE-World
|
||||
- **Raw Source**: 00_Raw/Agentic Software Engineering
|
||||
|
||||
## 💻 GitHub 동기화 자동화 워크플로우
|
||||
1. Stage: git add .
|
||||
2. Commit: `git commit -m "[P-Reinforce] Wikify Agentic Software Engineering Paradigm"`
|
||||
3. Push: `git push origin main`
|
||||
@@ -1,42 +0,0 @@
|
||||
---
|
||||
id: a1g2i3l4-e5t6-4e8a-m9c0-1o2l3l4a5b6c
|
||||
category: "10_Wiki/Topics/Development"
|
||||
confidence_score: 0.95
|
||||
tags: [agile, collaboration, team, project-management, small-teams, code-review]
|
||||
last_reinforced: 2026-05-01
|
||||
github_commit: "wikification-agile-collaboration"
|
||||
---
|
||||
|
||||
# Agile Development & Team Collaboration
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 애자일 소프트웨어 개발은 완벽한 계획보다 빠른 피드백과 점진적 개선을 중시하며, 팀 규모에 최적화된 협업 도구와 코드 리뷰 문화를 통해 지식의 파편화를 방지하고 제품의 품질을 상시 유지하는 것이다.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
|
||||
### 1. 소규모 팀을 위한 애자일
|
||||
- **Lean 접근**: 불필요한 미팅과 문서를 최소화하고 실제 작동하는 코드와 기능을 우선한다.
|
||||
- **다기능 협업 (Cross-functional)**: 기획, 디자인, 개발 경계를 허물고 공동의 목표 달성에 집중한다.
|
||||
- **빠른 이터레이션**: 짧은 스프린트와 데일리 스크럼을 통해 병목 지점을 조기에 발견하고 해결한다.
|
||||
|
||||
### 2. 효율적인 코드 리뷰 및 지식 공유
|
||||
- **코드 리뷰**: 단순히 오타를 찾는 과정이 아니라, 설계 의도를 공유하고 팀의 기술적 상향 평준화를 도모하는 시간이다.
|
||||
- **Context Sharing**: 작업 배경과 의사 결정 과정을 기록하여 부재 시에도 업무 연속성을 유지한다.
|
||||
|
||||
### 3. 규모별 팀 역학 (Small vs Large)
|
||||
- **Small Teams**: 의사소통 속도가 빠르며 높은 자율성을 기반으로 유연하게 대처한다.
|
||||
- **Large Teams**: 역할 분담이 명확하며, 시스템적 거버넌스와 문서화된 표준이 협업의 핵심이 된다.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **Agile의 형식화**: 단순히 스크럼을 수행하는 것(Doing Agile)과 애자일 가치를 내재화하는 것(Being Agile)은 다르다. 형식에 치우친 애자일은 오히려 생산성을 저해한다.
|
||||
- **리뷰 지연**: 과도하게 꼼꼼한 코드 리뷰는 릴리즈 속도를 늦출 수 있다. 자동화된 툴(Lint, Test)로 걸러낼 부분과 인간이 판단할 부분을 명확히 구분해야 한다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Parent**: 10_Wiki/Topics/Development
|
||||
- **Related**: Engineering Principles (SOLID, DRY, KISS, YAGNI, [[Git_Workflows|Git Workflows]]
|
||||
- **Raw Source**: 00_Raw/Agile Software Development in Small Teams, 00_Raw/Agile Environments, 00_Raw/Team Collaboration, 00_Raw/Code Review, 00_Raw/Small vs Large Frontend Teams
|
||||
|
||||
## 💻 GitHub 동기화 자동화 워크플로우
|
||||
1. Stage: git add .
|
||||
2. Commit: `git commit -m "[P-Reinforce] Wikify Agile Development and Team Collaboration Standard"`
|
||||
3. Push: `git push origin main`
|
||||
@@ -1,36 +0,0 @@
|
||||
---
|
||||
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|Automated Quality & Review]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "인간 리뷰어보다 먼저 코드의 구문, 스타일, 알려진 취약점을 필터링하여 품질의 최소 기준을 강제하고, 리뷰 시간을 고부가가치 설계 토론에 집중시키는 지능형 자동화 방어선."
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
자동화된 품질 관리는 현대 엔지니어링의 생산성을 결정짓는 필수 인프라입니다.
|
||||
|
||||
1. **정적 분석 및 린팅 (Static Analysis & Linting)**:
|
||||
* **구문 및 스타일 강제**: 린터(Linter)와 포매터(Formatter)를 통해 팀의 컨벤션을 자동으로 유지하며 소모적인 스타일 논쟁을 제거합니다.
|
||||
* **[[SAST (Static Application Security Testing)|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)|SAST (Static Application Security Testing]]: 정적 보안 분석의 심화.
|
||||
- [[CI-CD Pipeline|CI-CD Pipeline]]: 자동화 검증이 실행되는 핵심 환경.
|
||||
- [[Code Review Checklist|Code Review Checklist]]: 자동화가 처리하지 못하는 인간의 영역.
|
||||
- Shift-Left Security: 보안 점검을 자동화로 조기 도입하는 전략.
|
||||
- [[Technical-Debt|Technical Debt]]: 자동화된 대시보드를 통해 관리되는 부채.
|
||||
---
|
||||
@@ -1,35 +0,0 @@
|
||||
---
|
||||
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|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|DevSecOps]]: 보안이 내재화된 자동화 철학.
|
||||
- [[Infrastructure-as-Code-IaC|Infrastructure as Code (IaC]]: 인프라 배포의 자동화 확장.
|
||||
---
|
||||
@@ -1,35 +0,0 @@
|
||||
---
|
||||
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|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|Technical Debt]]: 리팩토링이 상환하고자 하는 비용.
|
||||
- Automated Testing: 리팩토링을 가능하게 하는 안전망.
|
||||
- Code Health: 리팩토링의 궁극적인 지향점.
|
||||
- Single-purpose PR: 리팩토링 시 준수해야 할 PR 정책.
|
||||
- [[Architecture Review (아키텍처 및 설계 리뷰)|Architecture Review]]: 대규모 리팩토링을 예방하는 선제적 대응.
|
||||
---
|
||||
@@ -1,38 +0,0 @@
|
||||
---
|
||||
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|Code Review Checklist]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "주관적인 코드 검토를 객관적이고 반복 가능한 품질 보증 프로세스로 전환하여, 인간의 실수를 방지하고 팀의 기술적 부채를 조기에 차단하는 체계적인 가이드라인."
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
코드 리뷰 체크리스트는 일관된 품질을 유지하기 위한 팀의 합의된 기준입니다.
|
||||
|
||||
1. **핵심 점검 영역**:
|
||||
* **기능 및 논리**: 요구사항 충족 여부 및 엣지 케이스 처리 확인.
|
||||
* **아키텍처**: [[SOLID Principles|SOLID Principles]] 준수 및 과도한 엔지니어링 방지.
|
||||
* **보안**: [[OWASP Top 10|OWASP Top 10]] 기준 위반 및 민감 데이터 노출 여부 점검.
|
||||
* **가독성**: 네이밍 컨벤션, 중복 코드 제거, 유지보수 용이성 확보.
|
||||
* **테스트 및 문서화**: 유의미한 테스트 코드 포함 및 '왜'에 대한 주석/문서 업데이트.
|
||||
2. **자동화와의 분업**:
|
||||
* 스타일, 포맷팅, 단순 보안 패턴은 린터(Linter)와 SAST에 맡기고, 인간은 비즈니스 로직과 구조적 무결성에 집중합니다.
|
||||
3. **현대적 확장 (AI 생성 코드)**:
|
||||
* AI가 제안한 존재하지 않는 API(Hallucination)나 보안 권한 누락 등을 별도로 검증해야 합니다.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **고무 도장(Rubber-stamping)의 위험**: 체크리스트가 너무 길어지면 기계적으로 체크만 하고 넘어가는 현상이 발생합니다. 필수 점검 항목을 정예화하고 운영 효율성을 고려한 유연한 적용 정책이 필요합니다.
|
||||
- **살아있는 문서화**: 기술 스택과 팀의 성숙도에 따라 체크리스트는 주기적으로 업데이트되어야 하며, 불필요해진 항목은 과감히 자동화 로직으로 이관해야 합니다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[SOLID Principles|SOLID Principles]]: 아키텍처 점검의 근간.
|
||||
- [[OWASP Top 10|OWASP Top 10]]: 보안 점검의 표준.
|
||||
- Pull Request Templates: 체크리스트를 워크플로우에 내장하는 도구.
|
||||
- [[Automated Code Analysis (자동화된 코드 분석)|Automated Code Analysis]]: 수동 체크리스트의 부담을 줄이는 자동화 기법.
|
||||
- [[Technical-Debt|Technical Debt]]: 체크리스트 부실 시 발생하는 비용.
|
||||
---
|
||||
@@ -1,36 +0,0 @@
|
||||
---
|
||||
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)|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|Agile Development]]: 빠른 피드백과 소통을 중시하는 철학적 배경.
|
||||
- Pull Request Workflow: 최종 결과물이 시스템에 통합되는 통로.
|
||||
---
|
||||
@@ -1,36 +0,0 @@
|
||||
---
|
||||
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 (자동화된 코드 분석)|Automated Code Analysis]]: 사소한 지적을 자동화로 이관하는 구조.
|
||||
- Pull Request Workflow: 표준화된 소통이 이루어지는 주무대.
|
||||
- Non-violent Communication: 커뮤니케이션의 심리학적 배경.
|
||||
---
|
||||
@@ -1,45 +0,0 @@
|
||||
---
|
||||
id: a1b2c3d4-e5f6-4a7b-8c9d-0e1f2a3b4c5d
|
||||
category: "10_Wiki/Topics/Development"
|
||||
confidence_score: 0.99
|
||||
tags: [engineering-principles, solid, dry, kiss, yagni, clean-code, software-engineering]
|
||||
last_reinforced: 2026-05-01
|
||||
github_commit: "wikification-engineering-principles"
|
||||
---
|
||||
|
||||
# Engineering Principles (SOLID, DRY, KISS, YAGNI
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 소프트웨어 엔지니어링의 핵심 원칙들은 코드의 복잡성을 통제하고 유지보수성을 극대화하기 위한 도구이며, 특히 SOLID와 DRY/KISS/YAGNI는 '단순함'과 '유연함' 사이의 최적의 균형점을 찾기 위한 지침이다.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
|
||||
### 1. SOLID 원칙 (Object-Oriented Design)
|
||||
- **SRP (단일 책임 원칙)**: 하나의 모듈/컴포넌트는 오직 하나의 책임(변경 이유)만 가져야 한다. React에서는 거대한 컴포넌트를 기능별로 쪼개는 핵심 근거가 된다.
|
||||
- **OCP (개방-폐쇄 원칙)**: 확장에는 열려 있고 수정에는 닫혀 있어야 한다. 컴포넌트 합성을 통해 기존 코드를 건드리지 않고 기능을 확장한다.
|
||||
- **LSP (리스코프 치환 원칙)**: 자식 클래스(또는 서브 컴포넌트)는 부모의 역할을 온전히 수행할 수 있어야 한다.
|
||||
- **ISP (인터페이스 분리 원칙)**: 사용하지 않는 인터페이스(Props)에 의존하지 않도록 잘게 쪼갠다.
|
||||
- **DIP (의존성 역전 원칙)**: 구체적인 구현이 아닌 추상화에 의존하여 결합도를 낮춘다.
|
||||
|
||||
### 2. Pragmatic Principles (DRY, KISS, YAGNI)
|
||||
- **DRY (Don't Repeat Yourself)**: 지식의 중복을 피한다. 반복되는 로직은 커스텀 훅이나 유틸리티로 추출한다.
|
||||
- **KISS (Keep It Simple, Stupid)**: 단순함이 궁극의 정교함이다. 과도한 추상화보다 직관적인 코드를 우선한다.
|
||||
- **YAGNI (You Aren't Gonna Need It)**: 실제로 필요하기 전까지는 기능을 미리 구현하지 않는다. 미래를 대비한 오버엔지니어링을 경계한다.
|
||||
|
||||
### 3. Clean Code 실무
|
||||
- **가독성 우선**: 코드는 컴퓨터가 읽기 위함이 아니라 사람이 읽기 위해 작성된다. 명확한 변수명과 함수 크기 조절이 필수적이다.
|
||||
- **단위 테스트 가능성**: 원칙을 준수한 코드는 자연스럽게 테스트하기 쉬운(Testable) 구조가 된다.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **DRY vs KISS**: 중복을 제거하기 위한 무리한 추상화는 코드를 더 이해하기 어렵게 만든다. '세 번 반복될 때까지 기다리기(Rule of Three)'가 좋은 절충안이다.
|
||||
- **YAGNI vs 확장성**: 미래를 무시하는 것과 유연한 구조를 설계하는 것은 다르다. YAGNI는 '기능'에 대한 것이고, SOLID는 '구조'에 대한 것이다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Parent**: 10_Wiki/Topics/Development
|
||||
- **Related**: Legacy React Migration & Refactoring Standard, Custom Hooks, [[Feature-Sliced Design|Feature-Sliced Design]]
|
||||
- **Raw Source**: 00_Raw/DRY, 00_Raw/KISS, 00_Raw/YAGNI, 00_Raw/Single Responsibility Principle, 00_Raw/Clean Code and SOLID Principles
|
||||
|
||||
## 💻 GitHub 동기화 자동화 워크플로우
|
||||
1. Stage: git add .
|
||||
2. Commit: `git commit -m "[P-Reinforce] Wikify Core Engineering Principles (SOLID, DRY, KISS, YAGNI)"`
|
||||
3. Push: `git push origin main`
|
||||
@@ -1,41 +0,0 @@
|
||||
---
|
||||
id: e1r2r3o4-h5a6-4n7d-l8i9-n0g1s2t3a4b5
|
||||
category: "10_Wiki/Topics/Development"
|
||||
confidence_score: 0.99
|
||||
tags: [react, error-handling, stability, error-boundary, monitoring, resilience]
|
||||
last_reinforced: 2026-05-01
|
||||
github_commit: "wikification-error-handling"
|
||||
---
|
||||
|
||||
# Frontend Error Handling & Application Stability
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 프론트엔드 안정성은 모든 에러를 막는 것이 아니라, 발생한 에러가 전체 앱의 화이트 스크린으로 번지지 않도록 구획을 나누고(Error Boundary), 실시간 모니터링을 통해 빠르게 인지하고 복구하는 회복 탄력성(Resilience)에 있다.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
|
||||
### 1. 계층적 에러 처리 전략
|
||||
- **Error Boundaries**: React 컴포넌트 트리 상위에서 하위 컴포넌트의 런타임 에러를 캡처하여 사용자에게 대체 UI를 보여준다. 핵심 비즈니스 영역별로 안전장치를 배치한다.
|
||||
- **Global Error Handling**: `window.onerror`, `unhandledrejection` 이벤트를 구독하여 예기치 못한 비동기 에러를 전역에서 캡처하고 서버로 전송한다.
|
||||
- **Local Error Handling**: `try-catch` 블록과 API 요청 계층의 인터셉터를 활용하여 사용자에게 즉각적인 피드백을 제공한다.
|
||||
|
||||
### 2. 애플리케이션 안정성 확보
|
||||
- **Fallback UI**: 에러 발생 시 단순히 앱을 중단시키는 대신, 새로고침 버튼이나 고객센터 연결 등 다음 행동을 유도하는 UI를 제공한다.
|
||||
- **Graceful Degradation**: 일부 기능(예: 추천 목록)이 실패하더라도 핵심 기능(예: 결제)은 유지될 수 있도록 모듈 간 결합도를 낮춘다.
|
||||
|
||||
### 3. 모니터링 및 분석
|
||||
- **Sentry 통합**: 에러 발생 시점의 사용자 세션, 기기 정보, 스택 트레이스를 수집하여 재현 및 수정을 용이하게 한다.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과도한 에러 무시**: 모든 에러를 묵묵히 처리하면 실제 심각한 논리 오류를 놓칠 수 있다. 로그 수집과 경고 알림(Alerting) 체계가 병행되어야 한다.
|
||||
- **에러 바운더리의 한계**: 이벤트 핸들러나 비동기 코드 내부의 에러는 Error Boundary가 직접 캡처하지 못하므로 별도의 처리가 필요하다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Parent**: 10_Wiki/Topics/Development
|
||||
- **Related**: Frontend Governance & Observability, Sentry and LogRocket Integration
|
||||
- **Raw Source**: 00_Raw/Error Handling, 00_Raw/Frontend Application Stability, 00_Raw/React 애플리케이션 예\354\231\270 \353\260\217 \354\227\220\353\237\254 \354\262\230\353\246\254
|
||||
|
||||
## 💻 GitHub 동기화 자동화 워크플로우
|
||||
1. Stage: git add .
|
||||
2. Commit: `git commit -m "[P-Reinforce] Wikify Frontend Error Handling and Application Stability Standard"`
|
||||
3. Push: `git push origin main`
|
||||
@@ -1,42 +0,0 @@
|
||||
---
|
||||
id: g1o2v3e4-r5n6-4a7b-8c9d-0e1f2a3b4c5d
|
||||
category: "10_Wiki/Topics/Development"
|
||||
confidence_score: 0.99
|
||||
tags: [governance, observability, monitoring, sentry, ci-cd, logging, rum, frontend-ops]
|
||||
last_reinforced: 2026-05-01
|
||||
github_commit: "wikification-governance-obs"
|
||||
---
|
||||
|
||||
# Frontend Governance & Observability
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 프론트엔드 운영의 핵심은 '보이지 않는 에러'를 가시화하는 것이며, 엄격한 CI/CD 거버넌스와 실시간 모니터링(Sentry, RUM)을 통해 사용자 경험의 신뢰성을 정량적으로 관리하는 것이다.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
|
||||
### 1. 프론트엔드 거버넌스 (Governance)
|
||||
- **자동화된 규칙 강제**: ESLint, Prettier, Husky를 통해 커밋 전 코드 품질과 아키텍처 경계 위반을 자동으로 검사한다.
|
||||
- **표준화된 워크플로우**: Conventional Commits와 엄격한 PR 템플릿을 사용하여 변경 이력을 투명하게 관리한다.
|
||||
|
||||
### 2. 가시성 및 모니터링 (Observability)
|
||||
- **에러 트래킹 (Sentry)**: 런타임 에러의 스택 트레이스와 사용자 세션 문맥을 캡처하여 디버깅 속도를 극대화한다.
|
||||
- **세션 리플레이 (LogRocket)**: 실제 사용자의 화면 조작 과정을 시각적으로 재현하여 재현하기 어려운 버그를 식별한다.
|
||||
- **RUM (Real User Monitoring)**: 실제 사용자의 환경(기기, 네트워크 등)에서 측정된 Core Web Vitals 지표를 수집하여 최적화 우선순위를 정한다.
|
||||
|
||||
### 3. CI/CD 파이프라인 통합
|
||||
- **안전한 배포**: 단위 테스트, 통합 테스트, 시각적 회귀 테스트를 파이프라인에 통합하여 배포 리스크를 최소화한다.
|
||||
- **Cloud Logging**: 클라이언트 측 로그를 중앙 집중화하여 프로덕션 환경의 이상 징후를 조기에 감지한다.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **로깅 오버헤드**: 과도한 로깅은 네트워크 대역폭을 점유하고 사용자 비용(데이터)을 발생시킨다. 샘플링 전략이 필요하다.
|
||||
- **프라이버시**: 모니터링 시 민감 정보(PII)가 포함되지 않도록 마스킹 처리가 필수적이다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Parent**: 10_Wiki/Topics/Development
|
||||
- **Related**: Engineering Principles (SOLID, DRY, KISS, YAGNI, Performance & Memory Management
|
||||
- **Raw Source**: 00_Raw/Frontend Engineering Governance, 00_Raw/Automated Governance, 00_Raw/CI-CD Pipeline Integration, 00_Raw/Observability, 00_Raw/Production Monitoring and Observability, 00_Raw/Sentry and LogRocket Integration, 00_Raw/프론트엔드 클라우드 로깅 도구 도입 및 프로덕션 모니터링
|
||||
|
||||
## 💻 GitHub 동기화 자동화 워크플로우
|
||||
1. Stage: git add .
|
||||
2. Commit: `git commit -m "[P-Reinforce] Wikify Frontend Governance and Observability Standard"`
|
||||
3. Push: `git push origin main`
|
||||
@@ -1,43 +0,0 @@
|
||||
---
|
||||
id: b2c3d4e5-f6a7-4b8c-9d0e-1f2a3b4c5d6e
|
||||
category: "10_Wiki/Topics/Development"
|
||||
confidence_score: 0.98
|
||||
tags: [git, workflow, branching, github-flow, git-flow, trunk-based-development, devops]
|
||||
last_reinforced: 2026-05-01
|
||||
github_commit: "wikification-git-workflow"
|
||||
---
|
||||
|
||||
# Modern Git Workflows & Branching Strategies
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 효율적인 Git 워크플로우는 팀의 규모와 릴리즈 주기에 맞춰 선택되어야 하며, Trunk-based Development와 짧은 생명주기의 Feature Branch를 통해 지속적 통합(CI)의 가치를 실현하는 데 목적이 있다.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
|
||||
### 1. 주요 전략별 특징
|
||||
- **Git Flow**: 정기적인 릴리즈 주기가 있는 대규모 프로젝트에 적합. `master`, `develop`, `feature`, `release`, `hotfix` 브랜치를 엄격히 관리한다.
|
||||
- **GitHub Flow**: 지속적 배포(CD)에 최적화된 단순한 모델. `main` 브랜치와 짧은 수명의 `feature` 브랜치만 사용하며, PR을 통해 상시 배포한다.
|
||||
- **Trunk-based Development**: 모든 개발자가 하루에도 여러 번 `main`에 직접 병합하는 방식. 충돌을 최소화하고 피드백 루프를 극대화한다.
|
||||
|
||||
### 2. 협업 및 품질 관리
|
||||
- **Pull Request (PR)**: 코드 리뷰를 위한 필수 관문. 변경 사항의 의도를 설명하고 자동화된 테스트를 통과해야 병합된다.
|
||||
- **Conventional Commits**: `feat:`, `fix:`, `refactor:` 등 규격화된 접두사를 사용하여 커밋 메시지의 가독성을 높이고 릴리즈 노트를 자동화한다.
|
||||
- **Atomic Commits**: 하나의 커밋은 하나의 논리적 변경만 담아야 한다. 이는 롤백과 디버깅(bisect)을 용이하게 한다.
|
||||
|
||||
### 3. 프론트엔드 팀을 위한 전략
|
||||
- **짧은 생명주기**: 브랜치가 며칠씩 유지되는 것을 지양하고, 가능한 빠르게 `main`에 통합하여 'Merge Hell'을 방지한다.
|
||||
- **Feature Flags**: 대규모 기능을 개발할 때 코드는 병합하되 런타임에 기능을 비활성화하여 Trunk-based 방식을 지원한다.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **복잡도 vs 제어**: Git Flow는 안전하지만 브랜치 관리 비용이 크며, GitHub Flow는 빠르지만 대규모 팀의 릴리즈 관리가 난해할 수 있다.
|
||||
- **Merge vs Rebase**: Rebase는 깨끗한 히스토리를 제공하지만 강제 푸시(force push) 위험이 있고, Merge는 보수적이지만 히스토리가 복잡해질 수 있다. 팀의 컨벤션 합의가 중요하다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Parent**: 10_Wiki/Topics/Development
|
||||
- **Related**: Engineering Principles (SOLID, DRY, KISS, YAGNI, CI-CD Pipeline Integration
|
||||
- **Raw Source**: 00_Raw/Git Flow, 00_Raw/Git Workflow, 00_Raw/GitHub Flow, 00_Raw/Branching Strategies, 00_Raw/Trunk-based Development, 00_Raw/Atomic Commits, 00_Raw/Pull Request (PR
|
||||
|
||||
## 💻 GitHub 동기화 자동화 워크플로우
|
||||
1. Stage: git add .
|
||||
2. Commit: `git commit -m "[P-Reinforce] Wikify Modern Git Workflows and Branching Strategies"`
|
||||
3. Push: `git push origin main`
|
||||
@@ -1,47 +0,0 @@
|
||||
---
|
||||
id: 7f8e9d2c-b1a3-4e5f-a0b2-c1d2e3f4a5b6
|
||||
category: "10_Wiki/Topics/Development"
|
||||
confidence_score: 0.98
|
||||
tags: [react, legacy, migration, refactoring, incremental-migration, architecture, frontend]
|
||||
last_reinforced: 2026-05-01
|
||||
github_commit: "wikification-legacy-react"
|
||||
---
|
||||
|
||||
# Legacy React Migration & Refactoring Standard
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 레거시 React 코드베이스의 현대화는 '전면 재작성(Rewrite)'이 아닌 '점진적 리팩토링(Incremental Refactor)'을 원칙으로 하며, 테스트 안전망 구축, 커스텀 훅을 통한 로직 분리, 그리고 FSD 아키텍처 도입을 통해 기술 부채를 체계적으로 해결하는 과정이다.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
|
||||
### 1. 리팩토링의 황금률: Refactor, Do Not Rewrite
|
||||
- **안전망 선구축**: 코드 수정 전 유닛 테스트 및 시각적 회귀 테스트(Storybook, Chromatic 등)를 통해 기존 기능의 무결성을 보장한다.
|
||||
- **점진적 마이그레이션**: 시스템 전체를 한 번에 바꾸는 대신, 알림이나 작은 기능 단위의 스토어부터 하나씩 최신 상태(Zustand, TanStack Query 등)로 전환한다.
|
||||
|
||||
### 2. 컴포넌트 및 언어의 현대화
|
||||
- **함수형 전환**: 클래스형 컴포넌트를 함수형 컴포넌트와 훅(Hooks) 기반으로 전환하며, 불필요한 `useEffect` 안티패턴을 제거한다.
|
||||
- **TypeScript 도입**: 정적 타이핑을 통해 코드의 예측 가능성을 높이며, 파일 단위로 점진적으로 적용한다.
|
||||
- **관심사 분리**: 비대한 컴포넌트(300줄 이상)에서 비즈니스 로직을 **커스텀 훅**으로 추출하여 UI와 로직을 분리한다.
|
||||
|
||||
### 3. 상태 관리 및 아키텍처 개편
|
||||
- **상태 분할**: 서버 데이터(TanStack Query), 전역 클라이언트 상태(Zustand), URL 상태 등으로 목적에 맞게 파편화하여 관리한다.
|
||||
- **FSD 아키텍처 도입**: 기술적 파일 유형(Type-based) 구조에서 비즈니스 도메인 중심의 **Feature-Sliced Design**으로 개편하여 모듈 간 결합도를 낮추고 응집도를 높인다.
|
||||
|
||||
### 4. 코드 거버넌스 및 표준화
|
||||
- **네이밍 규칙**: `kebab-case`(파일명/폴더명), `PascalCase`(컴포넌트), `camelCase`(훅/변수) 등 운영체제 및 팀 협업 표준을 수립한다.
|
||||
- **자동화**: ESLint, Prettier, Husky를 활용하여 커밋 시점에 아키텍처 경계 위반 및 포맷팅을 자동으로 검사한다.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **추상화의 함정 (DRY vs KISS)**: 중복 제거를 위한 과도한 추상화는 오히려 코드를 블랙박스화하여 디버깅을 어렵게 한다. '세 번 반복될 때까지 기다리기(Rule of Three)' 원칙을 준수해야 한다.
|
||||
- **과도기적 복잡성**: 점진적 마이그레이션 중에는 레거시와 신규 상태 관리 시스템이 공존하여 일시적으로 구조가 복잡해질 수 있음을 인지하고 마이그레이션 로드맵을 명확히 해야 한다.
|
||||
- **초기 오버헤드**: FSD 등의 엄격한 구조는 소규모 프로젝트에서는 과도한 설계(Overkill)가 될 수 있으므로 프로젝트 규모에 맞춰 유연하게 적용한다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Parent**: 10_Wiki/Topics/Development
|
||||
- **Related**: [[Feature-Sliced Design|Feature-Sliced Design]], TanStack Query, Zustand, Unit Testing, [[SOLID Principles|SOLID Principles]]
|
||||
- **Raw Source**: 00_Raw/레거시 React 코드베이스 마이그레이션, 00_Raw/Incremental Migration, 00_Raw/Legacy React Codebase Modernization, 00_Raw/Legacy React Codebase Refactoring, 00_Raw/React Codebase Refactoring, 00_Raw/프론트엔드 리팩토링 및 코드 유지보수
|
||||
|
||||
## 💻 GitHub 동기화 자동화 워크플로우
|
||||
1. Stage: git add .
|
||||
2. Commit: `git commit -m "[P-Reinforce] Wikify Legacy React Migration & Refactoring Standard"`
|
||||
3. Push: `git push origin main`
|
||||
@@ -1,38 +0,0 @@
|
||||
---
|
||||
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|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 (아키텍처 및 설계 리뷰)|Architecture Review]] (Shift-Left)**:
|
||||
* 코드를 작성하기 전, 설계 문서나 ADR(Architecture Decision Record)을 통해 방향성을 먼저 합의합니다. 이는 대규모 리팩토링 비용을 사전에 차단하는 가장 효율적인 전략입니다.
|
||||
4. **애자일 개발과의 조화**:
|
||||
* 지속적 통합(CI)과 빈번한 병합을 통해 코드 노후화(Stale)를 방지하고 피드백 루프를 극단적으로 단축합니다.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **전체 맥락의 상실**: PR을 너무 작게 쪼개면 시스템의 '큰 그림'을 놓칠 수 있습니다. 이를 보완하기 위해 PR 설명에 상위 목표와의 연결성을 명시하거나, 사전 설계 리뷰를 병행해야 합니다.
|
||||
- **분할 오버헤드**: 작은 PR로 나누는 작업 자체가 개발자에게 추가적인 부담이 될 수 있습니다. 이는 시스템을 느슨하게 결합(Loosely Coupled)된 모듈로 설계하여 자연스럽게 작은 변경이 가능하도록 아키텍처 수준에서 해결해야 합니다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Effective Code Review Feedback|Effective Code Review Feedback]]: 워크플로우 내에서의 구체적 소통법.
|
||||
- [[Automated Quality & Review|Automated Quality & Review]]: 인간의 리뷰 전 수행되는 자동화 관문.
|
||||
- [[Engineering Metrics (DORA)|Engineering Metrics (DORA]]: 워크플로우 효율성을 측정하는 지표.
|
||||
- [[Feature-Flags|Feature Flags]]: 큰 기능을 안전하게 나누어 배포하는 기술.
|
||||
- [[Technical-Debt|Technical Debt]]: 비대해진 PR이 유발하는 잠재적 위험.
|
||||
---
|
||||
@@ -1,50 +0,0 @@
|
||||
---
|
||||
id: 5e8f4a2b-1c9d-4e8b-a2f3-7d9e1c6b4a2d
|
||||
category: "10_Wiki/Topics/Development"
|
||||
confidence_score: 0.95
|
||||
tags: [react, frontend, engineering, standard, 2025, performance, architecture]
|
||||
last_reinforced: 2026-05-01
|
||||
github_commit: "initial-wikification"
|
||||
---
|
||||
|
||||
# Modern React & Frontend Engineering Standard (2025
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 2025년의 프론트엔드 엔지니어링은 단순한 UI 개발을 넘어, FSD 아키텍처, 빌드 타임 자동화(React Compiler), 그리고 목적별로 파편화된 상태 관리 체계를 통해 확장성과 안정성을 극대화하는 정교한 분산 시스템 엔지니어링으로 진화했다.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
|
||||
### 1. 확장 가능한 아키텍처: Feature-Sliced Design (FSD)
|
||||
- **계층적 구조화**: `app` -> `pages` -> `widgets` -> `features` -> `entities` -> `shared` 순의 레이어링을 통해 관심사를 분리한다.
|
||||
- **단방향 의존성**: 상위 레이어는 하위 레이어만 참조할 수 있도록 강제하여 순환 참조를 원천 차단하고 모듈 간 결합도를 낮춘다.
|
||||
- **Public API (index.ts)**: 각 슬라이스는 `index.ts`를 통해서만 외부와 소통하여 내부 구현을 캡슐화한다.
|
||||
|
||||
### 2. 상태 관리의 전문화 및 파편화
|
||||
- **서버 상태**: TanStack Query (React Query)를 사용하여 캐싱, 동기화, 비동기 상태를 전담 관리한다.
|
||||
- **전역 애플리케이션 상태**: Zustand를 활용하여 Selector 기반의 세밀한 리렌더링 제어를 수행하며, Redux는 복잡도가 극도로 높은 대규모 협업 환경에서만 제한적으로 채택한다.
|
||||
- **로컬 및 UI 상태**: `useState`, `useReducer`, 또는 정적인 설정값의 경우 `Context API`를 적재적소에 배치한다.
|
||||
|
||||
### 3. 성능 엔지니어링 (Build & Runtime)
|
||||
- **Vite & ESM**: 기존 번들러 대비 비약적으로 빠른 HMR과 개발 서버 속도를 보장한다.
|
||||
- **React Compiler**: 빌드 타임에 AST 분석을 통해 `useMemo`, `useCallback` 등을 자동으로 주입하여 수동 메모이제이션의 오버헤드를 제거한다.
|
||||
- **코드 스플리팅**: `React.lazy`와 Vite의 `manualChunks` 설정을 통해 라우트 단위로 번들을 쪼개어 초기 로딩 속도(LCP)를 개선한다.
|
||||
|
||||
### 4. 운영 회복성 및 거버넌스
|
||||
- **Error Boundaries**: 특정 컴포넌트의 런타임 에러가 전체 앱 중단(White Screen)으로 번지지 않도록 구획별로 안전장치를 배치한다.
|
||||
- **Observability**: Sentry, LogRocket 등을 연동하여 실제 사용자의 세션 리플레이 및 에러 로그를 실시간 모니터링한다.
|
||||
- **엄격한 컨벤션**: `kebab-case`(파일명), `PascalCase`(컴포넌트), `camelCase`(훅/변수) 네이밍을 자동화 훅(Husky, ESLint)으로 강제한다.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **메모이제이션의 함정**: `React.memo`의 얕은 비교 비용이 실제 렌더링 비용보다 클 수 있으므로, React Profiler 측정 없는 무분별한 최적화는 지양해야 한다.
|
||||
- **FSD vs Flat Structure**: 소규모 프로젝트에서는 FSD가 오버엔지니어링이 될 수 있으며, 팀의 숙련도에 따라 `shared` 레이어 비대화 문제가 발생할 수 있다.
|
||||
- **Compiler 블랙박스**: 자동 최적화가 동작하지 않는 엣지 케이스(불안정한 참조 반환 등)에 대한 개발자의 수동 대응 패턴이 여전히 필요하다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Parent**: 10_Wiki/Topics/Development
|
||||
- **Related**: [[Feature-Sliced Design|Feature-Sliced Design]], Zustand, React Compiler, [[Error Boundaries|Error Boundaries]]
|
||||
- **Raw Source**: 00_Raw/2025 프론트엔드 엔지니어링 표준 확립, 00_Raw/대규모 React 애플리케이션 개발, 00_Raw/Modern React Application Development (2025
|
||||
|
||||
## 💻 GitHub 동기화 자동화 워크플로우
|
||||
1. Stage: git add .
|
||||
2. Commit: `git commit -m "[P-Reinforce] Wikify Modern React Engineering Standard 2025"`
|
||||
3. Push: `git push origin main`
|
||||
@@ -1,41 +0,0 @@
|
||||
---
|
||||
id: n1e2x3t4-j5s6-4a7b-8c9d-0e1f2a3b4c5d
|
||||
category: "10_Wiki/Topics/Development"
|
||||
confidence_score: 0.98
|
||||
tags: [nextjs, app-router, server-components, react, functional-programming, modern-web]
|
||||
last_reinforced: 2026-05-01
|
||||
github_commit: "wikification-nextjs-modern-react"
|
||||
---
|
||||
|
||||
# Next.js & Modern React Design Patterns
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 현대 React 개발은 Next.js의 App Router와 Server Components를 통해 클라이언트-서버 경계를 재정의하며, 선언적 UI와 함수형 프로그래밍 패러다임을 결합하여 성능과 개발 생산성을 동시에 극대화하고 있다.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
|
||||
### 1. Next.js App Router 및 RSC
|
||||
- **React Server Components (RSC)**: 서버에서 데이터를 직접 페칭하고 렌더링하여 클라이언트로 전송함으로써 자바스크립트 번들 크기를 줄이고 초기 로딩 속도를 향상시킨다.
|
||||
- **App Router**: 파일 시스템 기반 라우팅을 넘어 레이아웃, 에러 핸들링, 로딩 상태를 선언적으로 관리하는 아키텍처를 제공한다.
|
||||
|
||||
### 2. 현대적 React 패턴
|
||||
- **함수형 컴포넌트 우선**: 모든 컴포넌트와 비즈니스 로직을 함수형으로 작성하며, 고차 컴포넌트(HOC) 대신 커스텀 훅과 합성을 사용하여 코드 재사용성을 높인다.
|
||||
- **Props Drilling 방지**: 컴포넌트 합성(Composition)과 Context API, 또는 상태 관리 라이브러리를 통해 데이터 흐름을 최적화한다.
|
||||
- **Rules of React**: 훅의 호출 순서 준수 등 React의 기본 원칙을 엄격히 지켜 예측 가능한 상태 전이를 보장한다.
|
||||
|
||||
### 3. 비동기 데이터 관리
|
||||
- **Server Actions**: 별도의 API 엔드포인트 없이 서버 측 함수를 직접 호출하여 데이터 변조(Mutation) 및 폼 처리를 수행한다.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **클라이언트 vs 서버 경계**: 모든 것을 서버 컴포넌트로 만들 수는 없다. 상호작용(Event, State)이 필요한 부분은 'use client' 지시어를 사용하여 명확히 분리해야 한다.
|
||||
- **추상화 오버헤드**: 함수형 패턴과 합성은 강력하지만, 과도하게 복잡한 합성은 컴포넌트 구조를 파악하기 어렵게 만든다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Parent**: 10_Wiki/Topics/Development
|
||||
- **Related**: Modern React & Frontend Engineering Standard (2025, [[Scalable Frontend Architecture|Scalable Frontend Architecture]]
|
||||
- **Raw Source**: 00_Raw/Next.js App Router, 00_Raw/Next.js 및 Server Components 적용 프로젝트, 00_Raw/Functional Components, 00_Raw/Functional Programming in React
|
||||
|
||||
## 💻 GitHub 동기화 자동화 워크플로우
|
||||
1. Stage: git add .
|
||||
2. Commit: `git commit -m "[P-Reinforce] Wikify Next.js and Modern React Design Patterns"`
|
||||
3. Push: `git push origin main`
|
||||
@@ -1,42 +0,0 @@
|
||||
---
|
||||
id: p5e4r3f2-a1b2-4c3d-8e9f-0a1b2c3d4e5f
|
||||
category: "10_Wiki/Topics/Development"
|
||||
confidence_score: 0.99
|
||||
tags: [performance, memory-leak, debugging, optimization, react, devtools, core-web-vitals]
|
||||
last_reinforced: 2026-05-01
|
||||
github_commit: "wikification-performance-memory"
|
||||
---
|
||||
|
||||
# Frontend Performance & Memory Management
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 프론트엔드 성능 최적화는 단순히 렌더링을 줄이는 것이 아니라, 사용자 체감 성능(LCP, CLS, FID)을 개선하고 크롬 개발자 도구 및 프로파일러를 통해 메모리 누수와 메인 스레드 점유율을 정밀하게 타격하는 엔지니어링이다.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
|
||||
### 1. 런타임 성능 및 리렌더링 최적화
|
||||
- **메모이제이션**: `React.memo`, `useMemo`, `useCallback`을 적재적소에 배치하여 불필요한 가상 DOM 연산을 방지한다.
|
||||
- **Concurrent Mode**: React 18의 `useTransition`, `useDeferredValue`를 활용하여 우선순위가 낮은 업데이트를 뒤로 미룸으로써 UI 반응성을 유지한다.
|
||||
- **Code Splitting**: `React.lazy`와 동적 임포트를 통해 초기 번들 크기를 줄이고 필요한 시점에 코드를 로드한다.
|
||||
|
||||
### 2. 메모리 관리 및 누수 탐지
|
||||
- **메모리 누수 유형**: 전역 변수 남용, 해제되지 않은 타이머/이벤트 리스너, 클로저에 의한 참조 유지, **Detached DOM Nodes** 등이 주요 원인이다.
|
||||
- **Heap Snapshot**: 크롬 개발자 도구의 Memory 탭을 통해 힙 스냅샷을 비교하고, 객체가 의도치 않게 메모리에 남아 있는지 확인한다.
|
||||
|
||||
### 3. 디버깅 및 분석 도구
|
||||
- **React DevTools Profiler**: 컴포넌트별 렌더링 시간과 원인을 파악하여 병목 지점을 찾는다.
|
||||
- **Lighthouse & Core Web Vitals**: LCP(최대 콘텐츠 페인트), CLS(누적 레이아웃 이동), INP(다음 상호작용에 대한 응답) 지표를 측정하고 최적화한다.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **무분별한 메모이제이션**: 모든 곳에 `useMemo`를 쓰는 것은 오히려 메모리 점유율을 높이고 얕은 비교 비용을 발생시킨다. 측정(Profiling) 후 적용하는 것이 원칙이다.
|
||||
- **가비지 컬렉션의 한계**: JS는 자동 GC를 지원하지만, 개발자가 참조 고리(Reference chain)를 끊어주지 않으면 GC는 이를 회수할 수 없다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Parent**: 10_Wiki/Topics/Development
|
||||
- **Related**: [[Vite Build System|Vite Build System]], Zustand, [[React Compiler|React Compiler]]
|
||||
- **Raw Source**: 00_Raw/웹 성능 최적화(Core Web Vitals) 개선 작업, 00_Raw/Vite + React 성능 최적화, 00_Raw/Frontend Performance Debugging, 00_Raw/JavaScript Memory Management, 00_Raw/Memory Leak Detection, 00_Raw/Detached DOM Nodes
|
||||
|
||||
## 💻 GitHub 동기화 자동화 워크플로우
|
||||
1. Stage: git add .
|
||||
2. Commit: `git commit -m "[P-Reinforce] Wikify Frontend Performance and Memory Management Guide"`
|
||||
3. Push: `git push origin main`
|
||||
@@ -1,42 +0,0 @@
|
||||
---
|
||||
id: s1c2a3l4-e5f6-4a7b-8c9d-0e1f2a3b4c5d
|
||||
category: "10_Wiki/Topics/Development"
|
||||
confidence_score: 0.99
|
||||
tags: [react, architecture, scalability, large-scale, fsd, folder-structure]
|
||||
last_reinforced: 2026-05-01
|
||||
github_commit: "wikification-scalable-architecture"
|
||||
---
|
||||
|
||||
# Scalable Frontend Architecture & System Design
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 대규모 프론트엔드 시스템의 확장은 단순히 코드 양을 늘리는 것이 아니라, Feature-Sliced Design(FSD)과 같은 계층적 관심사 분리를 통해 모듈 간 결합도를 제어하고 단방향 의존성을 강제함으로써 예측 가능한 유지보수성을 확보하는 것이다.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
|
||||
### 1. 계층적 관심사 분리 (FSD 도입)
|
||||
- **Layered Architecture**: `app` (설정), `pages` (라우트), `widgets` (조합), `features` (비즈니스 가치), `entities` (데이터 모델), `shared` (공통 유틸)로 계층을 나눈다.
|
||||
- **단방향 의존성**: 상위 계층은 하위 계층만 참조할 수 있도록 제한하여 순환 참조를 차단한다.
|
||||
- **Public API**: 각 슬라이스는 `index.ts`를 통해서만 내부 로직을 노출하여 캡슐화를 실현한다.
|
||||
|
||||
### 2. 폴더 구조 및 모듈화
|
||||
- **기능 중심 분리 (Feature-based)**: 기술적 유형(components, hooks)이 아닌 도메인과 기능 단위로 폴더를 구성하여 응집도를 높인다.
|
||||
- **마이크로 프론트엔드 대비**: 시스템이 극도로 비대해질 경우 모노레포(Nx, Turborepo)를 활용하여 모듈별 독립 배포 및 빌드를 준비한다.
|
||||
|
||||
### 3. 기술 부채 및 확장성 관리
|
||||
- **추상화 게이트**: 성급한 공통화(Over-generalization)를 경계하고, 도메인 로직이 유출되지 않도록 경계를 엄격히 관리한다.
|
||||
- **거버넌스 자동화**: ESLint 규칙(예: `eslint-plugin-import`)을 통해 계층 위반을 빌드 타임에 감지한다.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **오버엔지니어링**: 소규모 프로젝트에서는 FSD가 불필요한 보일러플레이트와 인지 부하를 발생시킨다. 프로젝트 성숙도에 따른 단계적 도입이 필요하다.
|
||||
- **Shared 계층의 비대화**: 모든 것을 `shared`에 넣으려는 유혹을 뿌리쳐야 한다. 최대한 하위 엔티티나 기능으로 분산시켜야 한다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Parent**: 10_Wiki/Topics/Development
|
||||
- **Related**: Legacy React Migration & Refactoring Standard, [[Feature-Sliced Design|Feature-Sliced Design]]
|
||||
- **Raw Source**: 00_Raw/Scalable React Apps, 00_Raw/Frontend Scalable Architecture, 00_Raw/Large-scale React Applications, 00_Raw/대규모 React 애플리케이션 아키텍처 구성, 00_Raw/확장 가능한 React 아키텍처 및 폴\353\215\224 \352\265\254\354\241\260 \354\204\244\352\263\204
|
||||
|
||||
## 💻 GitHub 동기화 자동화 워크플로우
|
||||
1. Stage: git add .
|
||||
2. Commit: `git commit -m "[P-Reinforce] Wikify Scalable Frontend Architecture and System Design"`
|
||||
3. Push: `git push origin main`
|
||||
@@ -1,38 +0,0 @@
|
||||
# [[Software Engineering Agents (SWE)|Software Engineering Agents (SWE]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
Software Engineering Agents(SWE Agents)는 코드 작성, 버그 수정, 테스트 실행, 리팩토링 등 소프트웨어 개발 생명주기(SDLC) 전반의 작업을 자율적으로 수행하도록 특화된 AI 에이전트이다. 단순한 코드 완성을 넘어, 대규모 코드베이스의 구조를 파악하고, 터미널 도구를 활용하며, 실제 실행 환경에서 검증을 거치는 '자율 엔지니어' 역할을 수행한다.
|
||||
|
||||
## 📖 Core Content
|
||||
* **SWE-agent 및 프레임워크**: Princeton의 SWE-agent와 같이 모델이 파일 탐색기, 편집기, 셸을 효율적으로 사용할 수 있도록 인터페이스를 최적화한 시스템.
|
||||
* **SWE-World (Docker-Free Environment)**: 복잡한 Docker 설정 없이도 에이전트가 안전하고 격리된 환경에서 코드를 실행하고 테스트할 수 있게 지원하는 초경량 실행 환경.
|
||||
* **코드베이스 탐색 (Navigation)**: 대규모 프로젝트에서 관련 있는 파일과 클래스를 찾기 위해 시맨틱 검색(RAG)과 구문 분석(AST)을 결합하여 컨텍스트를 구성.
|
||||
* **자율 디버깅 루프**: 에러 로그 분석 -> 가설 수립 -> 코드 수정 -> 테스트 실행 -> 결과 확인의 과정을 반복하며 버그를 해결.
|
||||
* **도구 활용 표준화**: 에이전트가 `grep`, `find`, `sed`와 같은 표준 유닉스 도구나 `Language Server Protocol (LSP)`을 활용하여 정밀한 코드 조작을 수행.
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
* **파괴적 수정의 위험**: 에이전트가 잘못된 판단으로 코드베이스 전체의 아키텍처를 망가뜨리거나 중요한 데이터를 삭제할 위험이 있다. (강력한 샌드박싱과 Git 기반 롤백 필수)
|
||||
* **지연 시간**: 대규모 코드베이스를 분석하고 수십 번의 테스트를 돌리는 과정에서 인간 개발자보다 작업 완료 속도가 느려질 수 있다.
|
||||
* **기술 부채 생성**: 에이전트가 작성한 코드가 작동은 하지만 가독성이 떨어지거나 확장성이 부족한 경우 장기적인 기술 부채로 남을 수 있다.
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
### Related Concepts
|
||||
* [[Agent Harness|Agent Harness]]
|
||||
* 연결 이유: SWE 에이전트가 실제 파일을 수정하고 명령을 내리는 런타임 기반이다.
|
||||
* [[Execution Environment (Sandbox)|Execution Environment (Sandbox]]
|
||||
* 연결 이유: 코드를 안전하게 실행하고 검증하기 위한 필수 공간이다.
|
||||
* [[Reasoning & Planning|Reasoning & Planning]]
|
||||
* 연결 이유: 복잡한 버그 수정 계획을 세우는 에이전트의 지능적 기반이다.
|
||||
|
||||
### Deeper Research Questions
|
||||
* 에이전트가 작성한 코드의 '유지보수성'과 '가독성'을 수치화하여 V-component에서 자동으로 평가하는 기준은 무엇인가?
|
||||
* 다수의 개발자가 참여하는 프로젝트에서 에이전트가 PR(Pull Request) 리뷰 피드백을 이해하고 자율적으로 수정본을 제출하는 협업 워크플로우의 한계는 어디인가?
|
||||
* 특정 프로그래밍 언어나 프레임워크에 특화된 '도메인 지식 그래프'를 결합했을 때 SWE 에이전트의 버그 해결률 상승 폭은 어느 정도인가?
|
||||
|
||||
### Practical Application Contexts
|
||||
* **Implementation:** 오픈소스 프로젝트의 Issue를 입력받아 에이전트가 자동으로 수정 코드와 유닛 테스트를 포함한 PR을 생성하는 자동화 파이프라인을 구축한다.
|
||||
* **System Design:** 사내 레거시 코드의 기술 부채 해결을 위해 에이전트가 점진적으로 리팩토링을 수행하고, 변경 전후의 성능 및 안정성을 비교 리포트로 제출하게 한다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-01*
|
||||
@@ -1,42 +0,0 @@
|
||||
---
|
||||
id: m1a2n3a4-g5e6-4a7b-8c9d-0e1f2a3b4c5d
|
||||
category: "10_Wiki/Topics/Development"
|
||||
confidence_score: 0.99
|
||||
tags: [react, state-management, zustand, redux, context-api, concurrent-mode, suspense, server-state]
|
||||
last_reinforced: 2026-05-01
|
||||
github_commit: "wikification-state-concurrent"
|
||||
---
|
||||
|
||||
# Modern State Management & Concurrent React
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 현대 React 상태 관리는 목적에 따른 파편화(전역/서버/URL)가 핵심이며, Concurrent Features와 Suspense를 통해 비동기 데이터 흐름을 선언적으로 제어하여 사용자 경험의 끊김을 최소화하는 방향으로 진화했다.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
|
||||
### 1. 상태 관리의 전문화
|
||||
- **서버 상태 (Server State)**: TanStack Query를 통해 캐싱, 동기화, 낙관적 업데이트를 관리하며 보일러플레이트를 획기적으로 줄인다.
|
||||
- **애플리케이션 전역 상태**: Zustand를 활용하여 가벼우면서도 세밀한 리렌더링 제어를 수행한다. Redux는 복잡도가 매우 높은 대규모 데이터 흐름에 한해 채택한다.
|
||||
- **Context API**: 주로 정적인 설정값이나 테마 전달에 사용하며, 잦은 업데이트가 발생하는 상태에는 성능 이슈로 인해 지양한다.
|
||||
|
||||
### 2. Concurrent React 및 선언적 UI
|
||||
- **Suspense**: 컴포넌트가 렌더링 준비가 될 때까지 기다리는 동안 대체 UI(Skeleton 등)를 보여주는 선언적 비동기 처리 방식이다.
|
||||
- **Concurrent Rendering**: 우선순위 기반 렌더링(Interruptible Rendering)을 통해 메인 스레드 차단을 방지하고 입력 반응성을 보장한다.
|
||||
- **Transitions**: `startTransition`을 사용하여 상태 업데이트의 우선순위를 낮춤으로써 긴급한 UI 상호작용(타이핑 등)을 보호한다.
|
||||
|
||||
### 3. 마이그레이션 전략
|
||||
- **Context to Zustand**: 불필요한 전체 리렌더링을 방지하기 위해 Context에서 Zustand의 Selector 기반 시스템으로 점진적으로 전환한다.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과도한 상태 분리**: 상태를 너무 잘게 쪼개면 데이터 일관성 유지가 어려워질 수 있다. 도메인 단위의 적절한 응집도가 필요하다.
|
||||
- **Suspense Waterfall**: 중첩된 Suspense는 네트워크 워터폴 현상을 유발할 수 있으므로, 데이터 페칭을 상위로 끌어올리거나(Fetch-then-render) 병렬로 처리해야 한다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Parent**: 10_Wiki/Topics/Development
|
||||
- **Related**: TanStack Query, Zustand, Performance & Memory Management
|
||||
- **Raw Source**: 00_Raw/State Management Libraries, 00_Raw/Context API to Zustand Migration, 00_Raw/Concurrent Rendering in React 18+, 00_Raw/React Suspense, 00_Raw/Server State
|
||||
|
||||
## 💻 GitHub 동기화 자동화 워크플로우
|
||||
1. Stage: git add .
|
||||
2. Commit: `git commit -m "[P-Reinforce] Wikify Modern State Management and Concurrent React Features"`
|
||||
3. Push: `git push origin main`
|
||||
@@ -1,38 +0,0 @@
|
||||
---
|
||||
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|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|Automated Quality & Review]]: 테스트가 자동으로 실행되는 환경.
|
||||
- [[Dependency Injection (DI)|Dependency Injection (DI]]: 테스트 가능성을 높이는 핵심 기술.
|
||||
- [[CI-CD Pipeline|CI-CD Pipeline]]: 테스트 결과에 따라 병합 여부를 결정하는 시스템.
|
||||
- [[Refactoring|Refactoring]]: 테스트라는 안전망이 있을 때 비로소 가능해지는 활동.
|
||||
- Mocking and Test Doubles: 외부 의존성 격리 기법.
|
||||
---
|
||||
Reference in New Issue
Block a user