docs: finalized wiki integrity maintenance (v3.0 standard) - pruned 1400+ stubs and fixed 11k+ ghost links
This commit is contained in:
Antigravity Agent
@@ -1,13 +1,13 @@
|
||||
---
|
||||
id: f6a5b4c3-d2e1-4f0a-9b8c-7d6e5f4a3b2c
|
||||
category: "[[10_Wiki/Topics/Development]]"
|
||||
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|Agentic Software Engineering]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 에이전틱 소프트웨어 엔지니어링은 개발자가 구현자(Implementer)에서 자율적으로 계획·코딩·디버깅하는 에이전트를 조율하는 오케스트레이터(Orchestrator)로 진화하는 패러다임이다.
|
||||
@@ -31,9 +31,9 @@ github_commit: "wikification-agentic-se"
|
||||
- **하네스 편향성**: 에이전트의 성능 지표는 모델 지능뿐만 아니라 하네스의 도구 설계 및 에러 처리 방식에 크게 좌우된다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Parent**: [[10_Wiki/Topics/Development]]
|
||||
- **Related**: [[Agent Harness]], [[Model Context Protocol (MCP)]], [[Plan-Execute-Verify (PEV) Loop]], [[SWE-World]]
|
||||
- **Raw Source**: [[00_Raw/Agentic Software Engineering]]
|
||||
- **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 .
|
||||
|
||||
@@ -1,13 +1,13 @@
|
||||
---
|
||||
id: a1g2i3l4-e5t6-4e8a-m9c0-1o2l3l4a5b6c
|
||||
category: "[[10_Wiki/Topics/Development]]"
|
||||
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]]
|
||||
# Agile Development & Team Collaboration
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 애자일 소프트웨어 개발은 완벽한 계획보다 빠른 피드백과 점진적 개선을 중시하며, 팀 규모에 최적화된 협업 도구와 코드 리뷰 문화를 통해 지식의 파편화를 방지하고 제품의 품질을 상시 유지하는 것이다.
|
||||
@@ -32,9 +32,9 @@ github_commit: "wikification-agile-collaboration"
|
||||
- **리뷰 지연**: 과도하게 꼼꼼한 코드 리뷰는 릴리즈 속도를 늦출 수 있다. 자동화된 툴(Lint, Test)로 걸러낼 부분과 인간이 판단할 부분을 명확히 구분해야 한다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Parent**: [[10_Wiki/Topics/Development]]
|
||||
- **Related**: [[Engineering Principles (SOLID, DRY, KISS, YAGNI)]], [[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]]
|
||||
- **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 .
|
||||
|
||||
@@ -6,7 +6,7 @@ tags: [automation, code-review, static-analysis, linting, quality-gate, dev-tool
|
||||
last_reinforced: 2026-05-01
|
||||
---
|
||||
|
||||
# [[Automated Quality & Review]]
|
||||
# [[Automated Quality & Review|Automated Quality & Review]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "인간 리뷰어보다 먼저 코드의 구문, 스타일, 알려진 취약점을 필터링하여 품질의 최소 기준을 강제하고, 리뷰 시간을 고부가가치 설계 토론에 집중시키는 지능형 자동화 방어선."
|
||||
@@ -16,7 +16,7 @@ last_reinforced: 2026-05-01
|
||||
|
||||
1. **정적 분석 및 린팅 (Static Analysis & Linting)**:
|
||||
* **구문 및 스타일 강제**: 린터(Linter)와 포매터(Formatter)를 통해 팀의 컨벤션을 자동으로 유지하며 소모적인 스타일 논쟁을 제거합니다.
|
||||
* **[[SAST (Static Application Security Testing)]]**: 소스 코드 레벨에서 OWASP Top 10 등의 보안 결함을 조기에 탐지합니다.
|
||||
* **[[SAST (Static Application Security Testing)|SAST (Static Application Security Testing]]**: 소스 코드 레벨에서 OWASP Top 10 등의 보안 결함을 조기에 탐지합니다.
|
||||
2. **리뷰 자동화 (Review Automation)**:
|
||||
* **품질 게이트 (Quality Gate)**: CI/CD 파이프라인과 연동하여 테스트 커버리지, 코드 복잡도, 보안 기준을 충족하지 못한 PR의 병합을 시스템적으로 차단합니다.
|
||||
* **사전 커밋 훅 (Pre-commit Hooks)**: 코드가 원격 저장소에 푸시되기 전 로컬에서 즉각적인 피드백을 제공하여 수정 주기를 단축합니다.
|
||||
@@ -28,9 +28,9 @@ last_reinforced: 2026-05-01
|
||||
- **인간의 대체 불가능성**: 자동화는 정해진 패턴은 잘 찾지만 비즈니스 맥락, 아키텍처 의도, 복잡한 접근 제어 로직은 이해하지 못합니다. 기계는 '규칙 준수'를, 인간은 '의도와 설계'를 검증하는 분업 구조를 유지해야 합니다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[SAST (Static Application Security Testing)]]: 정적 보안 분석의 심화.
|
||||
- [[CI-CD Pipeline]]: 자동화 검증이 실행되는 핵심 환경.
|
||||
- [[Code Review Checklist]]: 자동화가 처리하지 못하는 인간의 영역.
|
||||
- [[Shift-Left Security]]: 보안 점검을 자동화로 조기 도입하는 전략.
|
||||
- [[Technical Debt]]: 자동화된 대시보드를 통해 관리되는 부채.
|
||||
- [[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]]: 자동화된 대시보드를 통해 관리되는 부채.
|
||||
---
|
||||
|
||||
@@ -6,7 +6,7 @@ tags: [development, ci-cd, automation, quality-gate, devops, p-reinforce]
|
||||
last_reinforced: 2026-05-01
|
||||
---
|
||||
|
||||
# [[CI-CD Pipeline]]
|
||||
# [[CI-CD Pipeline|CI-CD Pipeline]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "소프트웨어의 빌드, 테스트, 배포 전 과정을 자동화하여, 인간 리뷰어보다 먼저 결함을 찾아내는 '기계적 파수꾼'이자 배포의 신뢰성을 보장하는 핵심 인프라."
|
||||
@@ -27,9 +27,9 @@ CI-CD는 현대적 개발 워크플로우에서 품질과 속도를 동시에
|
||||
- **자동화의 한계**: CI-CD는 정해진 패턴은 잘 찾지만 비즈니스적 맥락이나 설계상의 논리적 오류는 잡지 못합니다. 기계적 검증과 인간의 정성적 리뷰가 결합된 상호 보완 구조를 유지해야 합니다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Shift-Left Security]]: 보안 점검을 CI 단계로 앞당기는 전략.
|
||||
- [[Automated Testing]]: 파이프라인의 핵심 관문.
|
||||
- [[Pull Request Workflow]]: CI-CD가 트리거되는 지점.
|
||||
- [[DevSecOps]]: 보안이 내재화된 자동화 철학.
|
||||
- [[Infrastructure as Code (IaC)]]: 인프라 배포의 자동화 확장.
|
||||
- Shift-Left Security: 보안 점검을 CI 단계로 앞당기는 전략.
|
||||
- Automated Testing: 파이프라인의 핵심 관문.
|
||||
- Pull Request Workflow: CI-CD가 트리거되는 지점.
|
||||
- [[DevSecOps|DevSecOps]]: 보안이 내재화된 자동화 철학.
|
||||
- [[Infrastructure-as-Code-IaC|Infrastructure as Code (IaC]]: 인프라 배포의 자동화 확장.
|
||||
---
|
||||
|
||||
@@ -6,7 +6,7 @@ tags: [development, refactoring, code-quality, maintainability, technical-debt,
|
||||
last_reinforced: 2026-05-01
|
||||
---
|
||||
|
||||
# [[Code Refactoring]]
|
||||
# [[Code Refactoring|Code Refactoring]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "시스템의 겉보기 동작(Behavior)은 유지한 채 내부 구조를 개선하여, 인간에게는 더 읽기 쉽고 시스템에게는 더 변화에 유연하게 만드는 지속적인 코드 정제 작업."
|
||||
@@ -27,9 +27,9 @@ last_reinforced: 2026-05-01
|
||||
- **사후 비용 vs 사전 설계**: 개발 완료 후의 리팩토링은 비용이 많이 듭니다. 아키텍처 리뷰를 통한 사전 설계 검토(Shift-Left)가 대규모 리팩토링을 예방하는 가장 효율적인 정책입니다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Technical Debt]]: 리팩토링이 상환하고자 하는 비용.
|
||||
- [[Automated Testing]]: 리팩토링을 가능하게 하는 안전망.
|
||||
- [[Code Health]]: 리팩토링의 궁극적인 지향점.
|
||||
- [[Single-purpose PR]]: 리팩토링 시 준수해야 할 PR 정책.
|
||||
- [[Architecture Review]]: 대규모 리팩토링을 예방하는 선제적 대응.
|
||||
- [[Technical-Debt|Technical Debt]]: 리팩토링이 상환하고자 하는 비용.
|
||||
- Automated Testing: 리팩토링을 가능하게 하는 안전망.
|
||||
- Code Health: 리팩토링의 궁극적인 지향점.
|
||||
- Single-purpose PR: 리팩토링 시 준수해야 할 PR 정책.
|
||||
- [[Architecture Review (아키텍처 및 설계 리뷰)|Architecture Review]]: 대규모 리팩토링을 예방하는 선제적 대응.
|
||||
---
|
||||
|
||||
@@ -6,7 +6,7 @@ tags: [development, code-review, checklist, quality-assurance, best-practices, p
|
||||
last_reinforced: 2026-05-01
|
||||
---
|
||||
|
||||
# [[Code Review Checklist]]
|
||||
# [[Code Review Checklist|Code Review Checklist]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "주관적인 코드 검토를 객관적이고 반복 가능한 품질 보증 프로세스로 전환하여, 인간의 실수를 방지하고 팀의 기술적 부채를 조기에 차단하는 체계적인 가이드라인."
|
||||
@@ -16,8 +16,8 @@ last_reinforced: 2026-05-01
|
||||
|
||||
1. **핵심 점검 영역**:
|
||||
* **기능 및 논리**: 요구사항 충족 여부 및 엣지 케이스 처리 확인.
|
||||
* **아키텍처**: [[SOLID Principles]] 준수 및 과도한 엔지니어링 방지.
|
||||
* **보안**: [[OWASP Top 10]] 기준 위반 및 민감 데이터 노출 여부 점검.
|
||||
* **아키텍처**: [[SOLID Principles|SOLID Principles]] 준수 및 과도한 엔지니어링 방지.
|
||||
* **보안**: [[OWASP Top 10|OWASP Top 10]] 기준 위반 및 민감 데이터 노출 여부 점검.
|
||||
* **가독성**: 네이밍 컨벤션, 중복 코드 제거, 유지보수 용이성 확보.
|
||||
* **테스트 및 문서화**: 유의미한 테스트 코드 포함 및 '왜'에 대한 주석/문서 업데이트.
|
||||
2. **자동화와의 분업**:
|
||||
@@ -30,9 +30,9 @@ last_reinforced: 2026-05-01
|
||||
- **살아있는 문서화**: 기술 스택과 팀의 성숙도에 따라 체크리스트는 주기적으로 업데이트되어야 하며, 불필요해진 항목은 과감히 자동화 로직으로 이관해야 합니다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[SOLID Principles]]: 아키텍처 점검의 근간.
|
||||
- [[OWASP Top 10]]: 보안 점검의 표준.
|
||||
- [[Pull Request Templates]]: 체크리스트를 워크플로우에 내장하는 도구.
|
||||
- [[Automated Code Analysis]]: 수동 체크리스트의 부담을 줄이는 자동화 기법.
|
||||
- [[Technical Debt]]: 체크리스트 부실 시 발생하는 비용.
|
||||
- [[SOLID Principles|SOLID Principles]]: 아키텍처 점검의 근간.
|
||||
- [[OWASP Top 10|OWASP Top 10]]: 보안 점검의 표준.
|
||||
- Pull Request Templates: 체크리스트를 워크플로우에 내장하는 도구.
|
||||
- [[Automated Code Analysis (자동화된 코드 분석)|Automated Code Analysis]]: 수동 체크리스트의 부담을 줄이는 자동화 기법.
|
||||
- [[Technical-Debt|Technical Debt]]: 체크리스트 부실 시 발생하는 비용.
|
||||
---
|
||||
|
||||
@@ -6,7 +6,7 @@ tags: [development, pair-programming, mob-programming, collaboration, synchronou
|
||||
last_reinforced: 2026-05-01
|
||||
---
|
||||
|
||||
# [[Collaborative Programming (Pair & Mob)]]
|
||||
# [[Collaborative Programming (Pair & Mob)|Collaborative Programming (Pair & Mob]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "코드 작성과 리뷰를 실시간으로 통합하여 피드백 루프를 극단적으로 단축시키고, 집단 지성을 통해 고난도 문제 해결과 지식 전파를 가속화하는 동기식 협업 모델."
|
||||
@@ -14,10 +14,10 @@ last_reinforced: 2026-05-01
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
동기식 협업 프로그래밍은 비동기 리뷰의 지연을 제거하고 코드의 즉각적인 무결성을 확보합니다.
|
||||
|
||||
1. **[[Pair Programming]]**:
|
||||
1. **Pair Programming**:
|
||||
* **Driver & Navigator**: 한 명은 코드를 작성(Driver)하고, 다른 한 명은 로직과 설계 방향을 검토(Navigator)합니다.
|
||||
* **실시간 피드백**: 코드 작성 시점에 즉시 리뷰가 이루어지므로, PR 대기 시간 없이 높은 신뢰도의 코드를 생산합니다.
|
||||
2. **[[Mob Programming]]**:
|
||||
2. **Mob Programming**:
|
||||
* 팀 전체가 하나의 컴퓨터로 하나의 문제를 해결합니다.
|
||||
* 아키텍처 결정이나 익숙하지 않은 복잡한 도메인을 다룰 때 지식 사일로를 제거하는 데 탁월합니다.
|
||||
3. **지식 전파 및 온보딩**:
|
||||
@@ -28,9 +28,9 @@ last_reinforced: 2026-05-01
|
||||
- **하이브리드 전략**: 모든 작업에 적용하기보다 고위험군(복잡한 아키텍처, 보안 민감 기능)에 집중하고, 단순 작업은 비동기 리뷰로 처리하는 선별적 적용이 효율적입니다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Asynchronous Code Review]]: 동기식 모델과 대비되는 일반적 방식.
|
||||
- [[Knowledge Sharing]]: 협업을 통한 지식 전파 효과.
|
||||
- [[Shift-Left Security]]: 작성 시점에 보안을 검토하는 최전선 전략.
|
||||
- [[Agile Development]]: 빠른 피드백과 소통을 중시하는 철학적 배경.
|
||||
- [[Pull Request Workflow]]: 최종 결과물이 시스템에 통합되는 통로.
|
||||
- Asynchronous Code Review: 동기식 모델과 대비되는 일반적 방식.
|
||||
- Knowledge Sharing: 협업을 통한 지식 전파 효과.
|
||||
- Shift-Left Security: 작성 시점에 보안을 검토하는 최전선 전략.
|
||||
- [[Agile Development|Agile Development]]: 빠른 피드백과 소통을 중시하는 철학적 배경.
|
||||
- Pull Request Workflow: 최종 결과물이 시스템에 통합되는 통로.
|
||||
---
|
||||
|
||||
@@ -6,7 +6,7 @@ tags: [development, communication, conventional-commits, conventional-comments,
|
||||
last_reinforced: 2026-05-01
|
||||
---
|
||||
|
||||
# [[Development Communication Standards (Conventional Commits & Comments)]]
|
||||
# Development Communication Standards (Conventional Commits & Comments
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "코드와 피드백의 의도를 라벨링하여 인간 간의 오해를 줄이고 기계적 처리를 가능하게 하는 텍스트 표준화 전략: 명확한 소통이 개발 속도와 심리적 안전감을 결정한다."
|
||||
@@ -14,10 +14,10 @@ last_reinforced: 2026-05-01
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
개발 과정에서 발생하는 텍스트 기반 소통을 규격화하여 협업 효율을 극대화합니다.
|
||||
|
||||
1. **[[Conventional Commits]]**:
|
||||
1. **Conventional Commits**:
|
||||
* 커밋 메시지에 유형(예: `feat:`, `fix:`, `chore:`, `refactor:`)을 명시합니다.
|
||||
* 자동화된 릴리스 노트 생성과 버전 관리(Semantic Versioning)의 기반이 됩니다.
|
||||
2. **[[Conventional Comments]]**:
|
||||
2. **Conventional Comments**:
|
||||
* 코드 리뷰 시 코멘트 앞에 라벨(예: `suggestion:`, `issue:`, `nitpicked:`, `praise:`)을 붙입니다.
|
||||
* **Decorations**: `(blocking)` vs `(non-blocking)`을 통해 즉각적인 수정 필요 여부를 명시하여 작성자의 혼란을 제거합니다.
|
||||
3. **심리적 안전감과 효율성**:
|
||||
@@ -28,9 +28,9 @@ last_reinforced: 2026-05-01
|
||||
- **자동화와의 병행**: `nit:`(사소한 스타일) 코멘트가 많아지면 중요한 로직 피드백이 가려질 수 있습니다. 스타일 이슈는 린터가, 비즈니스 로직은 인간이 담당하는 역할 분담이 전제되어야 합니다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Constructive Feedback]]: 건설적 피드백의 구체적 실천법.
|
||||
- [[Non-blocking Feedback]]: 개발 속도를 유지하는 리뷰 전략.
|
||||
- [[Automated Code Analysis]]: 사소한 지적을 자동화로 이관하는 구조.
|
||||
- [[Pull Request Workflow]]: 표준화된 소통이 이루어지는 주무대.
|
||||
- [[Non-violent Communication]]: 커뮤니케이션의 심리학적 배경.
|
||||
- Constructive Feedback: 건설적 피드백의 구체적 실천법.
|
||||
- Non-blocking Feedback: 개발 속도를 유지하는 리뷰 전략.
|
||||
- [[Automated Code Analysis (자동화된 코드 분석)|Automated Code Analysis]]: 사소한 지적을 자동화로 이관하는 구조.
|
||||
- Pull Request Workflow: 표준화된 소통이 이루어지는 주무대.
|
||||
- Non-violent Communication: 커뮤니케이션의 심리학적 배경.
|
||||
---
|
||||
|
||||
@@ -1,13 +1,13 @@
|
||||
---
|
||||
id: a1b2c3d4-e5f6-4a7b-8c9d-0e1f2a3b4c5d
|
||||
category: "[[10_Wiki/Topics/Development]]"
|
||||
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)]]
|
||||
# Engineering Principles (SOLID, DRY, KISS, YAGNI
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 소프트웨어 엔지니어링의 핵심 원칙들은 코드의 복잡성을 통제하고 유지보수성을 극대화하기 위한 도구이며, 특히 SOLID와 DRY/KISS/YAGNI는 '단순함'과 '유연함' 사이의 최적의 균형점을 찾기 위한 지침이다.
|
||||
@@ -35,9 +35,9 @@ github_commit: "wikification-engineering-principles"
|
||||
- **YAGNI vs 확장성**: 미래를 무시하는 것과 유연한 구조를 설계하는 것은 다르다. YAGNI는 '기능'에 대한 것이고, SOLID는 '구조'에 대한 것이다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Parent**: [[10_Wiki/Topics/Development]]
|
||||
- **Related**: [[Legacy React Migration & Refactoring Standard]], [[Custom Hooks]], [[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]]
|
||||
- **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 .
|
||||
|
||||
@@ -1,13 +1,13 @@
|
||||
---
|
||||
id: e1r2r3o4-h5a6-4n7d-l8i9-n0g1s2t3a4b5
|
||||
category: "[[10_Wiki/Topics/Development]]"
|
||||
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]]
|
||||
# Frontend Error Handling & Application Stability
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 프론트엔드 안정성은 모든 에러를 막는 것이 아니라, 발생한 에러가 전체 앱의 화이트 스크린으로 번지지 않도록 구획을 나누고(Error Boundary), 실시간 모니터링을 통해 빠르게 인지하고 복구하는 회복 탄력성(Resilience)에 있다.
|
||||
@@ -31,9 +31,9 @@ github_commit: "wikification-error-handling"
|
||||
- **에러 바운더리의 한계**: 이벤트 핸들러나 비동기 코드 내부의 에러는 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]]
|
||||
- **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 .
|
||||
|
||||
@@ -1,13 +1,13 @@
|
||||
---
|
||||
id: g1o2v3e4-r5n6-4a7b-8c9d-0e1f2a3b4c5d
|
||||
category: "[[10_Wiki/Topics/Development]]"
|
||||
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]]
|
||||
# Frontend Governance & Observability
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 프론트엔드 운영의 핵심은 '보이지 않는 에러'를 가시화하는 것이며, 엄격한 CI/CD 거버넌스와 실시간 모니터링(Sentry, RUM)을 통해 사용자 경험의 신뢰성을 정량적으로 관리하는 것이다.
|
||||
@@ -32,9 +32,9 @@ github_commit: "wikification-governance-obs"
|
||||
- **프라이버시**: 모니터링 시 민감 정보(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/프론트엔드 클라우드 로깅 도구 도입 및 프로덕션 모니터링]]
|
||||
- **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 .
|
||||
|
||||
@@ -1,13 +1,13 @@
|
||||
---
|
||||
id: b2c3d4e5-f6a7-4b8c-9d0e-1f2a3b4c5d6e
|
||||
category: "[[10_Wiki/Topics/Development]]"
|
||||
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]]
|
||||
# Modern Git Workflows & Branching Strategies
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 효율적인 Git 워크플로우는 팀의 규모와 릴리즈 주기에 맞춰 선택되어야 하며, Trunk-based Development와 짧은 생명주기의 Feature Branch를 통해 지속적 통합(CI)의 가치를 실현하는 데 목적이 있다.
|
||||
@@ -33,9 +33,9 @@ github_commit: "wikification-git-workflow"
|
||||
- **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)]]
|
||||
- **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 .
|
||||
|
||||
@@ -1,13 +1,13 @@
|
||||
---
|
||||
id: 7f8e9d2c-b1a3-4e5f-a0b2-c1d2e3f4a5b6
|
||||
category: "[[10_Wiki/Topics/Development]]"
|
||||
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]]
|
||||
# Legacy React Migration & Refactoring Standard
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 레거시 React 코드베이스의 현대화는 '전면 재작성(Rewrite)'이 아닌 '점진적 리팩토링(Incremental Refactor)'을 원칙으로 하며, 테스트 안전망 구축, 커스텀 훅을 통한 로직 분리, 그리고 FSD 아키텍처 도입을 통해 기술 부채를 체계적으로 해결하는 과정이다.
|
||||
@@ -37,9 +37,9 @@ github_commit: "wikification-legacy-react"
|
||||
- **초기 오버헤드**: FSD 등의 엄격한 구조는 소규모 프로젝트에서는 과도한 설계(Overkill)가 될 수 있으므로 프로젝트 규모에 맞춰 유연하게 적용한다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Parent**: [[10_Wiki/Topics/Development]]
|
||||
- **Related**: [[Feature-Sliced Design]], [[TanStack Query]], [[Zustand]], [[Unit Testing]], [[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/프론트엔드 리팩토링 및 코드 유지보수]]
|
||||
- **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 .
|
||||
|
||||
@@ -6,7 +6,7 @@ tags: [development, pull-request, review-workflow, pr-size-limits, architecture-
|
||||
last_reinforced: 2026-05-01
|
||||
---
|
||||
|
||||
# [[Modern Review Workflow]]
|
||||
# [[Modern Review Workflow|Modern Review Workflow]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "작고 집중된 변경(Small Batches)을 통해 인지 부하를 줄이고, 사전 설계 검토와 자동화 게이트를 결합하여 개발 속도와 아키텍처 무결성을 동시에 확보하는 협업 프로세스."
|
||||
@@ -17,10 +17,10 @@ last_reinforced: 2026-05-01
|
||||
1. **풀 리퀘스트 (Pull Request / Merge Request)**:
|
||||
* 코드 변경 사항을 메인 브랜치에 병합하기 전, 동료들의 검토와 자동화 테스트를 거치는 공식적인 관문입니다.
|
||||
* **단일 목적 지향**: 하나의 PR은 기능 추가, 버그 수정, 리팩토링 중 단 하나의 명확한 목적만 가져야 합니다.
|
||||
2. **[[PR Size Limits]] (작은 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)**:
|
||||
3. **[[Architecture Review (아키텍처 및 설계 리뷰)|Architecture Review]] (Shift-Left)**:
|
||||
* 코드를 작성하기 전, 설계 문서나 ADR(Architecture Decision Record)을 통해 방향성을 먼저 합의합니다. 이는 대규모 리팩토링 비용을 사전에 차단하는 가장 효율적인 전략입니다.
|
||||
4. **애자일 개발과의 조화**:
|
||||
* 지속적 통합(CI)과 빈번한 병합을 통해 코드 노후화(Stale)를 방지하고 피드백 루프를 극단적으로 단축합니다.
|
||||
@@ -30,9 +30,9 @@ last_reinforced: 2026-05-01
|
||||
- **분할 오버헤드**: 작은 PR로 나누는 작업 자체가 개발자에게 추가적인 부담이 될 수 있습니다. 이는 시스템을 느슨하게 결합(Loosely Coupled)된 모듈로 설계하여 자연스럽게 작은 변경이 가능하도록 아키텍처 수준에서 해결해야 합니다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Effective Code Review Feedback]]: 워크플로우 내에서의 구체적 소통법.
|
||||
- [[Automated Quality & Review]]: 인간의 리뷰 전 수행되는 자동화 관문.
|
||||
- [[Engineering Metrics (DORA)]]: 워크플로우 효율성을 측정하는 지표.
|
||||
- [[Feature Flags]]: 큰 기능을 안전하게 나누어 배포하는 기술.
|
||||
- [[Technical Debt]]: 비대해진 PR이 유발하는 잠재적 위험.
|
||||
- [[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,13 +1,13 @@
|
||||
---
|
||||
id: 5e8f4a2b-1c9d-4e8b-a2f3-7d9e1c6b4a2d
|
||||
category: "[[10_Wiki/Topics/Development]]"
|
||||
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)]]
|
||||
# Modern React & Frontend Engineering Standard (2025
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 2025년의 프론트엔드 엔지니어링은 단순한 UI 개발을 넘어, FSD 아키텍처, 빌드 타임 자동화(React Compiler), 그리고 목적별로 파편화된 상태 관리 체계를 통해 확장성과 안정성을 극대화하는 정교한 분산 시스템 엔지니어링으로 진화했다.
|
||||
@@ -40,9 +40,9 @@ github_commit: "initial-wikification"
|
||||
- **Compiler 블랙박스**: 자동 최적화가 동작하지 않는 엣지 케이스(불안정한 참조 반환 등)에 대한 개발자의 수동 대응 패턴이 여전히 필요하다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Parent**: [[10_Wiki/Topics/Development]]
|
||||
- **Related**: [[Feature-Sliced Design]], [[Zustand]], [[React Compiler]], [[Error Boundaries]]
|
||||
- **Raw Source**: [[00_Raw/2025 프론트엔드 엔지니어링 표준 확립]], [[00_Raw/대규모 React 애플리케이션 개발]], [[00_Raw/Modern React Application Development (2025)]]
|
||||
- **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 .
|
||||
|
||||
@@ -1,13 +1,13 @@
|
||||
---
|
||||
id: n1e2x3t4-j5s6-4a7b-8c9d-0e1f2a3b4c5d
|
||||
category: "[[10_Wiki/Topics/Development]]"
|
||||
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]]
|
||||
# Next.js & Modern React Design Patterns
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 현대 React 개발은 Next.js의 App Router와 Server Components를 통해 클라이언트-서버 경계를 재정의하며, 선언적 UI와 함수형 프로그래밍 패러다임을 결합하여 성능과 개발 생산성을 동시에 극대화하고 있다.
|
||||
@@ -31,9 +31,9 @@ github_commit: "wikification-nextjs-modern-react"
|
||||
- **추상화 오버헤드**: 함수형 패턴과 합성은 강력하지만, 과도하게 복잡한 합성은 컴포넌트 구조를 파악하기 어렵게 만든다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Parent**: [[10_Wiki/Topics/Development]]
|
||||
- **Related**: [[Modern React & Frontend Engineering Standard (2025)]], [[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]]
|
||||
- **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 .
|
||||
|
||||
@@ -1,13 +1,13 @@
|
||||
---
|
||||
id: p5e4r3f2-a1b2-4c3d-8e9f-0a1b2c3d4e5f
|
||||
category: "[[10_Wiki/Topics/Development]]"
|
||||
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]]
|
||||
# Frontend Performance & Memory Management
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 프론트엔드 성능 최적화는 단순히 렌더링을 줄이는 것이 아니라, 사용자 체감 성능(LCP, CLS, FID)을 개선하고 크롬 개발자 도구 및 프로파일러를 통해 메모리 누수와 메인 스레드 점유율을 정밀하게 타격하는 엔지니어링이다.
|
||||
@@ -32,9 +32,9 @@ github_commit: "wikification-performance-memory"
|
||||
- **가비지 컬렉션의 한계**: JS는 자동 GC를 지원하지만, 개발자가 참조 고리(Reference chain)를 끊어주지 않으면 GC는 이를 회수할 수 없다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Parent**: [[10_Wiki/Topics/Development]]
|
||||
- **Related**: [[Vite Build System]], [[Zustand]], [[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]]
|
||||
- **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 .
|
||||
|
||||
@@ -1,13 +1,13 @@
|
||||
---
|
||||
id: s1c2a3l4-e5f6-4a7b-8c9d-0e1f2a3b4c5d
|
||||
category: "[[10_Wiki/Topics/Development]]"
|
||||
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]]
|
||||
# Scalable Frontend Architecture & System Design
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 대규모 프론트엔드 시스템의 확장은 단순히 코드 양을 늘리는 것이 아니라, Feature-Sliced Design(FSD)과 같은 계층적 관심사 분리를 통해 모듈 간 결합도를 제어하고 단방향 의존성을 강제함으로써 예측 가능한 유지보수성을 확보하는 것이다.
|
||||
@@ -32,9 +32,9 @@ github_commit: "wikification-scalable-architecture"
|
||||
- **Shared 계층의 비대화**: 모든 것을 `shared`에 넣으려는 유혹을 뿌리쳐야 한다. 최대한 하위 엔티티나 기능으로 분산시켜야 한다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Parent**: [[10_Wiki/Topics/Development]]
|
||||
- **Related**: [[Legacy React Migration & Refactoring Standard]], [[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]]
|
||||
- **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 .
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# [[Software Engineering Agents (SWE)]]
|
||||
# [[Software Engineering Agents (SWE)|Software Engineering Agents (SWE]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
Software Engineering Agents(SWE Agents)는 코드 작성, 버그 수정, 테스트 실행, 리팩토링 등 소프트웨어 개발 생명주기(SDLC) 전반의 작업을 자율적으로 수행하도록 특화된 AI 에이전트이다. 단순한 코드 완성을 넘어, 대규모 코드베이스의 구조를 파악하고, 터미널 도구를 활용하며, 실제 실행 환경에서 검증을 거치는 '자율 엔지니어' 역할을 수행한다.
|
||||
@@ -18,11 +18,11 @@ Software Engineering Agents(SWE Agents)는 코드 작성, 버그 수정, 테스
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
### Related Concepts
|
||||
* [[Agent Harness]]
|
||||
* [[Agent Harness|Agent Harness]]
|
||||
* 연결 이유: SWE 에이전트가 실제 파일을 수정하고 명령을 내리는 런타임 기반이다.
|
||||
* [[Execution Environment (Sandbox)]]
|
||||
* [[Execution Environment (Sandbox)|Execution Environment (Sandbox]]
|
||||
* 연결 이유: 코드를 안전하게 실행하고 검증하기 위한 필수 공간이다.
|
||||
* [[Reasoning & Planning]]
|
||||
* [[Reasoning & Planning|Reasoning & Planning]]
|
||||
* 연결 이유: 복잡한 버그 수정 계획을 세우는 에이전트의 지능적 기반이다.
|
||||
|
||||
### Deeper Research Questions
|
||||
|
||||
@@ -1,13 +1,13 @@
|
||||
---
|
||||
id: m1a2n3a4-g5e6-4a7b-8c9d-0e1f2a3b4c5d
|
||||
category: "[[10_Wiki/Topics/Development]]"
|
||||
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]]
|
||||
# Modern State Management & Concurrent React
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 현대 React 상태 관리는 목적에 따른 파편화(전역/서버/URL)가 핵심이며, Concurrent Features와 Suspense를 통해 비동기 데이터 흐름을 선언적으로 제어하여 사용자 경험의 끊김을 최소화하는 방향으로 진화했다.
|
||||
@@ -32,9 +32,9 @@ github_commit: "wikification-state-concurrent"
|
||||
- **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]]
|
||||
- **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 .
|
||||
|
||||
@@ -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: 외부 의존성 격리 기법.
|
||||
---
|
||||
|
||||
Reference in New Issue
Block a user