[P-Reinforce] 2026-04-20: Processed 5 New Knowledge Gems (Tetris Engineering Lessons)

2026-04-20 15:00:36 +09:00
parent 46fd50381e
commit 62153b5741
19 changed files with 658 additions and 0 deletions
@@ -0,0 +1,20 @@
+---
+# 💡 Lesson Learned: Web Worker를 이용한 고성능 아키텍처 설계 (Performance)
+
+## 🎯 문제 상황 (The Problem)
+테트리스 게임과 같이 **매우 높은 빈도(High Frequency)**로 상태 변화가 발생하는 실시간 애플리케이션을 React의 메인 스레드에서 처리할 경우, UI 업데이트와 물리 계산이 충돌하여 **프레임 드롭(Jank)** 현상이나 성능 저하가 발생했습니다.
+
+## 🔬 근본 원인 (Root Cause)
+게임 엔진 로직은 CPU를 매우 많이 사용합니다. 이 무거운 계산을 메인 스레드에서 수행하면, 브라우저의 UI 업데이트 루프(`requestAnimationFrame`)와 충돌하여 사용자에게 부드럽지 않은 경험(Poor UX)을 제공하게 됩니다.
+
+## ✅ 해결책 (The Solution)
+**Web Worker**를 사용하여 게임 엔진 로직 전체를 **메인 스레드에서 완전히 분리(Isolate)** 했습니다.
+*   **원리:** Web Worker는 별도의 백그라운드 스레드에서 동작하므로, 아무리 복잡한 계산을 해도 메인 스레드의 UI 렌더링에는 영향을 주지 않습니다.
+
+## 💡 교훈 (Lesson Learned)
+> **"성능 병목 현상은 종종 '스레딩(Threading)'의 문제이다."**
+> 실시간으로 높은 연산량이 요구되는 모든 시스템은, 반드시 Web Worker 또는 별도의 백그라운드 프로세스로 로직을 분리하여 처리해야 합니다.
+
+## 🔗 관련 키워드
+`Web Worker`, `Concurrency`, `High-Frequency Updates`, `Performance Optimization`
+---
@@ -0,0 +1,19 @@
+---
+# 💡 Lesson Learned: 상태 관리의 단일 진실 공급원 원칙 (Data Consistency)
+
+## 🎯 문제 상황 (The Problem)
+테트리스 게임은 '현재 보드 상태'와 '움직이는 블록 위치'라는 두 가지 핵심 데이터를 가지고 있습니다. 이 데이터들이 여러 곳에서 독립적으로 업데이트될 위험이 있었습니다. 만약 A 부분에서 값을 바꾸고, B 부분에서 같은 값을 다르게 계산한다면 **데이터 불일치(Inconsistency)**가 발생합니다.
+
+## 🔬 근본 원인 (Root Cause)
+시스템의 핵심 상태가 분산되어 관리되고 있었기 때문입니다. 여러 컴포넌트와 로직이 각자 '진실'이라고 믿는 데이터를 가지고 충돌할 가능성이 높았습니다.
+
+## ✅ 해결책 (The Solution)
+**Redux/Zustand 패턴을 차용하여 모든 게임의 핵심 상태(State)**를 `src/TetrisGame.jsx` 컴포넌트가 관리하는 **단일 지점(Single Source of Truth)**으로 만들었습니다. 모든 데이터 변경은 이 중앙 저장소를 통해 이루어지게 했습니다.
+
+## 💡 교훈 (Lesson Learned)
+> **"상태는 오직 한 곳에서만 정의하고, 모든 로직은 그 상태를 읽고 쓰는 방식으로 동작해야 한다."**
+> 복잡한 시스템을 설계할 때, 핵심 데이터의 흐름(Data Flow)과 책임 범위(Responsibility)를 명확히 분리하는 것이 가장 중요합니다.
+
+## 🔗 관련 키워드
+`Single Source of Truth`, `Redux Pattern`, `State Management`, `Predictable State`
+---
@@ -0,0 +1,22 @@
+---
+# 💡 Lesson Learned: 시스템 아키텍처의 중요성 (The Need for Abstraction)
+
+## 🎯 문제 상황 (The Problem)
+이번 프로젝트를 진행하면서, 코드를 짜는 것이 아니라 '어떤 구조로 짤지'가 가장 어려웠습니다. 이는 단순히 기술적인 문제가 아닌 **설계 패턴(Design Pattern)**과 관련된 문제입니다.
+
+## 🔬 근본 원인 (Root Cause)
+모든 로직을 한 파일에 때려 넣으려는 유혹에 빠지는 것, 즉 '스파게티 코드'를 만들 위험이 가장 큰 문제였습니다. 모든 것을 한곳에서 처리하려 했기 때문에 유지보수성과 확장성이 0에 수렴했습니다.
+
+## ✅ 해결책 (The Solution)
+**아키텍처적 분리 원칙(Separation of Concerns, SoC)**을 적용하여 코드를 다음과 같이 역할별로 나눴습니다:
+1.  **게임 규칙:** `gameWorker.js` (논리 엔진)
+2.  **상태 관리:** `TetrisGame.jsx` (데이터의 출입구)
+3.  **렌더링:** React 컴포넌트 (화면에 보여주는 역할만 수행)
+
+## 💡 교훈 (Lesson Learned)
+> **"시스템을 구성할 때는 '책임 분리(Separation of Concerns)'를 최우선 원칙으로 삼아야 한다."**
+> 기능이 복잡해질수록, 코드는 반드시 경계가 명확한 모듈들로 분리되어야 합니다.
+
+## 🔗 관련 키워드
+`Separation of Concerns`, `Modular Design`, `Microservices Pattern`
+---
@@ -0,0 +1,22 @@
+---
+# 💡 Lesson Learned: 개발 환경 및 실행 프로세스 관리 (DevOps & DevOps)
+
+## 🎯 문제 상황 (The Problem)
+이번 프로젝트는 단순히 코드를 짜고 끝나는 것이 아니라, **'어떻게 이 코드를 구동시킬 수 있는가?'**라는 물리적 절차의 중요성을 깨달았습니다. (오류 코드: `npm audit`, `index.html` 누락, 권한 오류 등)
+
+## 🔬 근본 원인 (Root Cause)
+개발자는 종종 **'논리적 완성도(Logical Completion)'에만 집중**하고, 프로젝트를 실행하는 데 필요한 **물리적인 설정 파일(Configuration)**과 **운영체제 레벨의 환경 변수/권한** 관리에 소홀해지기 쉽습니다.
+
+## ✅ 해결책 (The Solution)
+프로젝트 시작 시점에 다음 절차를 반드시 거쳐야 함을 확립했습니다:
+1.  `npm install`: 필요한 모든 패키지를 설치한다.
+2.  환경 설정 확인: `public/index.html` 등 필수 진입점이 존재하는지 확인한다.
+3.  권한 확보: 운영체제 레벨에서 스크립트 실행 권한(Execution Policy)을 확보한다.
+
+## 💡 교훈 (Lesson Learned)
+> **"코딩 능력만큼이나 중요한 것은 '운영 환경에 대한 이해'와 '체계적인 개발 프로세스 확립'이다."**
+> 프로젝트 관리자는 항상 이 세 가지 단계를 점검해야 합니다.
+
+## 🔗 관련 키워드
+`DevOps`, `CI/CD Pipeline`, `Execution Policy`, `Build Environment`
+---
@@ -0,0 +1,19 @@
+---
+# 💡 Lesson Learned: 시스템 시뮬레이션의 핵심 원리 (Simulation Design)
+
+## 🎯 문제 상황 (The Problem)
+테트리스는 단순한 게임이 아니라, **물리 법칙(Physics)**과 **규칙 기반의 상태 변화**가 작동하는 작은 시뮬레이터였습니다. 이 경험을 통해 '시뮬레이션을 어떻게 설계해야 하는지'에 대한 깊은 이해를 얻었습니다.
+
+## 🔬 근본 원인 (Root Cause)
+단순히 UI로 그리는 것에만 집중하면, 시스템이 **규칙(Ruleset)**과 **물리 법칙(Physics Law)**을 따르는 '가상 세계'의 느낌을 놓치기 쉽습니다.
+
+## ✅ 해결책 (The Solution)
+게임 로직을 `gameWorker.js`에 완전히 분리하여, 모든 변화를 수학적 함수(`checkCollision`, `movePiece`)로 처리하고 그 결과를 상태(State)에 반영했습니다. 이는 곧 **"규칙이 물리 법칙처럼 작동하는 시스템"** 설계의 성공적인 예시입니다.
+
+## 💡 교훈 (Lesson Learned)
+> **"모든 시뮬레이션은 '물리적 규칙'을 수학적으로 정의하고, 그 규칙을 절대 우회할 수 없도록 강제해야 한다."**
+> 이를 통해 우리는 단순한 게임을 넘어, 자율주행이나 물리 엔진에 적용 가능한 고수준의 시스템 모델링 능력을 갖추게 되었습니다.
+
+## 🔗 관련 키워드
+`Simulation Design`, `Physics Engine`, `Ruleset Enforcement`, `Systemic Modeling`
+---