docs: finalized wiki integrity maintenance (v3.0 standard) - pruned 1400+ stubs and fixed 11k+ ghost links
This commit is contained in:
Antigravity Agent
@@ -1,4 +1,4 @@
|
||||
# [[CI/CD Pipeline (지속적 통합 및 배포)]]
|
||||
# [[CI-CD Pipeline (지속적 통합 및 배포)|CI/CD Pipeline (지속적 통합 및 배포]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
CI/CD(Continuous Integration and Continuous Deployment) 파이프라인은 소프트웨어의 빌드, 테스트 및 배포 과정을 자동화하여 코드 변경 사항을 신속하고 신뢰할 수 있게 통합하고 배포하는 시스템입니다 [1]. 코드 리뷰 과정에서 CI/CD 파이프라인은 인간 리뷰어가 검토하기 전에 린팅(Linting), 스타일 검사, 단위 테스트, 정적 코드 분석 등을 기계적으로 먼저 수행하는 자동화된 1차 방어선 역할을 합니다 [2, 3]. 이를 통해 자동화된 품질 및 보안 게이트를 구축함으로써 전체 개발 프로세스의 속도와 안정성을 비약적으로 향상시킵니다 [5, 6].
|
||||
@@ -20,10 +20,10 @@ CI/CD(Continuous Integration and Continuous Deployment) 파이프라인은 소
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
### Related Concepts
|
||||
* **[[Automated Testing]]**: CI/CD 파이프라인 내에서 코드의 기능적 정확성을 기계적으로 확인하는 핵심 단계입니다.
|
||||
* **[[Linters and Formatters]]**: 스타일 논쟁(Nitpicking)을 제거하고 코드 일관성을 유지하기 위해 파이프라인 초기 단계에 통합되는 도구들입니다.
|
||||
* **[[SAST (Static Application Security Testing)]]**: 배포 전 소스 코드 수준에서 보안 취약점을 자동으로 스캔하는 기술입니다.
|
||||
* **[[Pull Request (PR) Workflow]]**: 코드 병합 전 리뷰를 요청하는 프로세스로, CI/CD 파이프라인을 동작시키는 주요 트리거입니다.
|
||||
* **Automated Testing**: CI/CD 파이프라인 내에서 코드의 기능적 정확성을 기계적으로 확인하는 핵심 단계입니다.
|
||||
* **Linters and Formatters**: 스타일 논쟁(Nitpicking)을 제거하고 코드 일관성을 유지하기 위해 파이프라인 초기 단계에 통합되는 도구들입니다.
|
||||
* **[[SAST (Static Application Security Testing)|SAST (Static Application Security Testing]]**: 배포 전 소스 코드 수준에서 보안 취약점을 자동으로 스캔하는 기술입니다.
|
||||
* **Pull Request (PR) Workflow**: 코드 병합 전 리뷰를 요청하는 프로세스로, CI/CD 파이프라인을 동작시키는 주요 트리거입니다.
|
||||
|
||||
### Deeper Research Questions
|
||||
* 대규모 모노레포(Monorepo) 환경에서 변경된 영역에 대해서만 선택적으로 자동화 검증을 수행(Impact Analysis)하도록 파이프라인을 최적화하는 기술적 방법은 무엇인가?
|
||||
@@ -39,8 +39,8 @@ CI/CD(Continuous Integration and Continuous Deployment) 파이프라인은 소
|
||||
* **My Project Relevance:** 리뷰 대기 시간이 길거나 반복적인 스타일 지적이 많을 때, 가장 먼저 도입하여 리뷰 프로세스의 병목을 해소해야 할 최우선 인프라입니다.
|
||||
|
||||
### Adjacent Topics
|
||||
* **[[Feature Flags]]**: CI/CD를 통해 코드를 자주 병합하면서도 실제 기능 노출은 런타임에 제어하는 고급 배포 기법으로 확장됩니다.
|
||||
* **[[DORA Metrics]]**: 배포 빈도, 변경 실패율 등 CI/CD 파이프라인의 성능을 측정하고 개선하는 지표로 연결됩니다.
|
||||
* **[[Feature-Flags|Feature Flags]]**: CI/CD를 통해 코드를 자주 병합하면서도 실제 기능 노출은 런타임에 제어하는 고급 배포 기법으로 확장됩니다.
|
||||
* **[[DORA-Metrics|DORA Metrics]]**: 배포 빈도, 변경 실패율 등 CI/CD 파이프라인의 성능을 측정하고 개선하는 지표로 연결됩니다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-02*
|
||||
|
||||
@@ -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]]: 인프라 배포의 자동화 확장.
|
||||
---
|
||||
|
||||
@@ -1,11 +1,11 @@
|
||||
---
|
||||
title: 배포 프로토콜 및 CI/CD 자동화
|
||||
category: Software [[Architecture]]
|
||||
tags: [Deployment, CI/CD, [[GitHub Actions]], Vercel, DevOps]
|
||||
category: Software [[Architecture|Architecture]]
|
||||
tags: [Deployment, CI/CD, [[GitHub Actions|GitHub Actions]], Vercel, DevOps]
|
||||
created: 2026-04-20
|
||||
---
|
||||
|
||||
# [[Deployment_Final_Gate]] (배포 및 자동화)
|
||||
# [[Deployment_Final_Gate|Deployment_Final_Gate]] (배포 및 자동화)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 수동 배포는 '실버 불렛'이 아니라 '시한폭탄'이다. 인간의 손을 거치지 않는 자동화된 보급로만이 시스템의 영속성을 보장한다.
|
||||
@@ -22,5 +22,5 @@ created: 2026-04-20
|
||||
- 무조건적인 '자동 배포'가 늘 정답은 아니다. 운영 단계에서는 '블루-그린 배포'나 '카나리 배포'처럼 트래픽을 조금씩 흘려보내며 안정성을 확인하는 고급 전략이 필요하다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Related: [[Modern_Environment_Ecosystem]] , [[Collaboration_Governance]]
|
||||
- Pre-requisite: [[React_[[Testing]]_Strategy]]
|
||||
- Related: [[Modern_Environment_Ecosystem|Modern_Environment_Ecosystem]] , [[Collaboration_Governance|Collaboration_Governance]]
|
||||
- Pre-requisite: [[React_Testing_Strategy|React_Testing_Strategy]]
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
title: 개발 환경 및 실행 프로세스 관리 (DevOps & Setup)
|
||||
category: DevOps
|
||||
tags: [DevOps, Environment, CI/CD, Process [[Management]]]
|
||||
tags: [DevOps, Environment, CI/CD, Process [[Management|Management]]]
|
||||
created: 2026-04-20
|
||||
---
|
||||
|
||||
@@ -21,4 +21,4 @@ created: 2026-04-20
|
||||
> 논리적 로직의 완성뿐만 아니라, 그것이 실제로 구동되는 물리적 인프라 설정을 문서화하고 자동화하는 능력이 필수적입니다.
|
||||
|
||||
## 🔗 연결된 지식
|
||||
- [[Systemic_Simulation_Principles]]
|
||||
- [[Systemic_Simulation_Principles|Systemic_Simulation_Principles]]
|
||||
|
||||
@@ -6,7 +6,7 @@ tags: [governance, dora-metrics, engineering-metrics, performance, devops, cycle
|
||||
last_reinforced: 2026-05-01
|
||||
---
|
||||
|
||||
# [[Engineering Metrics (DORA)]]
|
||||
# [[Engineering Metrics (DORA)|Engineering Metrics (DORA]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "데이터에 기반하여 소프트웨어 인도 성과(Delivery Performance)를 정량화하고, 엘리트 팀의 벤치마크를 통해 개발 프로세스의 병목과 개선 방향을 제시하는 엔지니어링 표준 지표."
|
||||
@@ -31,9 +31,9 @@ DORA 지표는 데브옵스(DevOps) 연구를 통해 입증된 고성과 팀의
|
||||
- **데이터의 맥락**: 단순 수치만으로 팀을 평가하기보다, 지표의 변화 추이를 통해 팀의 프로세스 건전성을 진단하고 병목을 해결하는 도구로 활용해야 합니다.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Review Performance & Flow]]: DORA 지표를 달성하기 위한 구체적 운영 전략.
|
||||
- [[Small Pull Requests (작은 PR)]]: Lead Time을 단축하는 가장 강력한 수단.
|
||||
- [[Automated Quality & Review]]: 인간의 시간을 절약하여 성과를 극대화하는 기반.
|
||||
- [[CI-CD Pipeline]]: 지표 수집과 자동화가 이루어지는 인프라.
|
||||
- [[DORA Metrics]]: 원본 개념 정의.
|
||||
- [[Review Performance & Flow|Review Performance & Flow]]: DORA 지표를 달성하기 위한 구체적 운영 전략.
|
||||
- Small Pull Requests (작은 PR: Lead Time을 단축하는 가장 강력한 수단.
|
||||
- [[Automated Quality & Review|Automated Quality & Review]]: 인간의 시간을 절약하여 성과를 극대화하는 기반.
|
||||
- [[CI-CD Pipeline|CI-CD Pipeline]]: 지표 수집과 자동화가 이루어지는 인프라.
|
||||
- [[DORA-Metrics|DORA Metrics]]: 원본 개념 정의.
|
||||
---
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# 🛠️ Git [[Opera]]tion & Work Log Protocol (Git 작업 및 기록 지침)
|
||||
# 🛠️ Git [[Opera|Opera]]tion & Work Log Protocol (Git 작업 및 기록 지침)
|
||||
|
||||
> **카테고리**: 03_DevOps_Environment, Automation
|
||||
> **상태**: 🟢 활성화 (Active)
|
||||
@@ -9,7 +9,7 @@
|
||||
## 📌 개요 (Overview)
|
||||
본 문서는 Skybound 프로젝트를 포함한 4개 주요 개발 거점의 원격 저장소 동기화 정합성을 유지하고, 모든 AI 작업 과정을 체계적으로 문서화하기 위한 Git 운영 규정 및 작업 로그(Work Log) 시스템을 정의한다.
|
||||
|
||||
## 🔗 프로젝트별 Git 맵핑 ([[Repository]] Mapping)
|
||||
## 🔗 프로젝트별 Git 맵핑 ([[Repository|Repository]] Mapping)
|
||||
대표님의 명령 한마디로 정확한 경로에서 작업을 수행하기 위해 각 폴더별로 독립적인 Git 설정을 유지한다.
|
||||
|
||||
| 프로젝트 | 로컬 경로 | 원격 저장소 (Remote URL) | 리모트 명칭 |
|
||||
@@ -17,7 +17,7 @@
|
||||
| **Wiki (2nd)** | `E:\Wiki\2nd` | `https://github.com/wonseokjung/solopreneur-ai-agents.git` | `lm_sync` |
|
||||
| **Skybound** | `E:\Wiki\skybound` | `https://github.com/wonseokjung/skybound-protocol.git` | `origin` |
|
||||
| **Legal** | `E:\Wiki\legal-bridge` | `https://github.com/wonseokjung/legal-bridge.git` | `origin` |
|
||||
| **Agent** | `E:\Wiki\auto-[[Research]]-agent`| `https://github.com/wonseokjung/auto-re[[Search]]-agent.git` | `origin` |
|
||||
| **Agent** | `E:\Wiki\auto-[[Research|Research]]-agent`| `https://github.com/wonseokjung/auto-re[[Search|Search]]-agent.git` | `origin` |
|
||||
|
||||
## 🛠️ 운영 지침 (Operational Guidelines)
|
||||
|
||||
@@ -37,7 +37,7 @@
|
||||
- **Result**: 최종 결과 및 관련 연결 지식.
|
||||
|
||||
### 3. 위키화 (Wikification)
|
||||
- `00_Raw`에 축적된 로그는 주기적으로 `10_Wiki\Topics` 하위 카테고리로 고도화([[Refinement]])되어 이동된다.
|
||||
- `00_Raw`에 축적된 로그는 주기적으로 `10_Wiki\Topics` 하위 카테고리로 고도화([[Refinement|Refinement]])되어 이동된다.
|
||||
- 위키화가 완료된 원본 로그는 삭제하여 지식 베이스의 정결성을 유지한다.
|
||||
|
||||
## 🚀 기대 효과
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
# Index: Topics > 03_DevOps_Environment
|
||||
|
||||
## 📝 Documents
|
||||
- [[Deployment_Final_Gate]]
|
||||
- [[DevOps_Environment_Setup]]
|
||||
- [[Git_Operation_Protocol]]
|
||||
- [[Modern_Environment_Ecosystem]]
|
||||
- [[Tetris_Project_Retrospective]]
|
||||
- [[Deployment_Final_Gate|Deployment_Final_Gate]]
|
||||
- [[DevOps_Environment_Setup|DevOps_Environment_Setup]]
|
||||
- [[Git_Operation_Protocol|Git_Operation_Protocol]]
|
||||
- [[Modern_Environment_Ecosystem|Modern_Environment_Ecosystem]]
|
||||
- [[Tetris_Project_Retrospective|Tetris_Project_Retrospective]]
|
||||
|
||||
@@ -1,11 +1,11 @@
|
||||
---
|
||||
title: 모던 개발 환경 및 프레임워크 생태계
|
||||
category: Software [[Architecture]]
|
||||
tags: [Vite, [[Next.js]], Ecosystem, Modern Stack]
|
||||
category: Software [[Architecture|Architecture]]
|
||||
tags: [Vite, [[Next.js|Next.js]], Ecosystem, Modern Stack]
|
||||
created: 2026-04-20
|
||||
---
|
||||
|
||||
# [[Modern_Environment_Ecosystem]] (모던 개발 생태계)
|
||||
# [[Modern_Environment_Ecosystem|Modern_Environment_Ecosystem]] (모던 개발 생태계)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 도구는 목적이 아니라 '생산성'을 위한 수단이다. 하지만 최신 생태계의 변화를 놓치는 것은 스스로 생산성을 깎아내는 것과 같다.
|
||||
@@ -16,11 +16,11 @@ created: 2026-04-20
|
||||
- **Framework: Next.js (The Fullstack Edge)**:
|
||||
- 단순히 SEO를 위한 SSR 도구가 아니다. API Routes를 통한 서버리스 함수 구현, 데이터 캐싱 전략(ISR/SSG) 등 현대 웹이 요구하는 거의 모든 기능을 탑재한 '거버넌스' 그 자체다.
|
||||
- **패키지 매니저의 선택**:
|
||||
- `pnpm` 또는 `npm v7+`의 워크스페이스 기능을 통해 모노레포([[Monorepo]]) 구조를 효율적으로 관리하고, 패키지 중복 설치를 최소화하여 빌드 성능을 최적화한다.
|
||||
- `pnpm` 또는 `npm v7+`의 워크스페이스 기능을 통해 모노레포([[Monorepo|Monorepo]]) 구조를 효율적으로 관리하고, 패키지 중복 설치를 최소화하여 빌드 성능을 최적화한다.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (RL Update)
|
||||
- 최신 기술이 항상 정답은 아니다. 안정성이 최우선인 기업 환경에서는 검증된 `CRA` 혹은 `Webpack` 기반의 설정을 유지하는 것이 보수적인 면에서 유리할 수 있다. 기술 부채(Tech Debt)와 도입 비용을 항상 저울질하라.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Related: [[Deployment_Final_Gate]] , Project_Architecture_Guidelines
|
||||
- Foundation: [[TypeScript_Type_Safety]]
|
||||
- Related: [[Deployment_Final_Gate|Deployment_Final_Gate]] , Project_Architecture_Guidelines
|
||||
- Foundation: [[TypeScript_Type_Safety|TypeScript_Type_Safety]]
|
||||
|
||||
@@ -1,21 +1,21 @@
|
||||
---
|
||||
title: 프로젝트 회고: 고성능 테트리스 아키텍처
|
||||
category: Projects
|
||||
tags: [Retrospective, Tetris, [[Architecture]], Performance]
|
||||
tags: [Retrospective, Tetris, [[Architecture|Architecture]], Performance]
|
||||
created: 2026-04-20
|
||||
---
|
||||
|
||||
# 프로젝트 회고: 고성능 테트리스 아키텍처 ([[P-Reinforce]])
|
||||
# 프로젝트 회고: 고성능 테트리스 아키텍처 ([[P-Reinforce|P-Reinforce]])
|
||||
|
||||
## 🌊 프로젝트 아키텍처 요약
|
||||
본 프로젝트는 **Web Worker**를 활용한 완전한 연산-렌더링 분리를 실현하여, 실시간 게임 환경에서 극강의 부드러움을 확보하는 데 성공했습니다.
|
||||
|
||||
### 🧩 컴포넌트별 기술적 역할
|
||||
- **Game Engine**: 물리 계산 및 상태 전이 (`public/gameWorker.js`).
|
||||
- **[[State]] Manager**: UI의 유일한 진실 공급원 (`src/App.js`).
|
||||
- **[[State|State]] Manager**: UI의 유일한 진실 공급원 (`src/App.js`).
|
||||
- **Renderer**: Props 기반의 순수 매핑 렌더러 (`src/components/GameBoard.jsx`).
|
||||
|
||||
## ⚠️ 핵심 교훈 ([[Lessons Learned]])
|
||||
## ⚠️ 핵심 교훈 ([[Lessons Learned|Lessons Learned]])
|
||||
> [!IMPORTANT]
|
||||
> **"논리가 완벽해도 실행 환경이 무너지면 아무 의미가 없다."**
|
||||
> 아키텍처 설계만큼이나 '파일 무결성 검증'과 '환경 재설정 루틴'이 개발 생산성에 지대한 영향을 미친다는 것을 확인했습니다.
|
||||
@@ -26,5 +26,5 @@ created: 2026-04-20
|
||||
- [x] 체계적인 디버깅 프로토콜 수립.
|
||||
|
||||
## 🔗 연결된 지식
|
||||
- [[System_Debugging_Protocol]]
|
||||
- [[System_Debugging_Protocol|System_Debugging_Protocol]]
|
||||
- Project_Architecture_Guidelines
|
||||
|
||||
Reference in New Issue
Block a user