---
id: [[P-Reinforce|P-Reinforce]]-AUTO-CATY-001
category: Unified
confidence_score: 0.97
tags: [auto-reinforced, clean-[[Architecture|Architecture]], typescript, software-design, decoupling, layered-architecture]
last_reinforced: 2026-04-20
---

# [[Clean-Architecture-TypeScript|Clean-Architecture-TypeScript]]

## 📌 한 줄 통찰 (The Karpathy Summary)
> "기술은 바뀌어도 본질은 변하지 않게: 데이터베이스나 웹 프레임워크 같은 저수준 기술에 비즈니스 로직이 오염되지 않도록 층(Layer)을 나누어 격리함으로써, 10년 뒤에도 유지보수가 가능한 단단한 소프트웨어를 만드는 설계 도면."

## 📖 구조화된 지식 (Synthesized Content)
클린 아키텍처(Clean Architecture)는 소프트웨어 전문성을 유지하기 위해 관심사를 계층별로 분리하는 설계 원칙입니다. (로버트 C. 마틴 제안)

1.  **4대 계층 (TypeScript 관점)**:
    *   **Entities**: 순수한 비즈니스 규칙과 데이터 구조 (가장 안쪽, 변화가 거의 없음).
    *   **Use Cases**: 애플리케이션의 동작 시나리오.
    *   **Interface Adapters**: Controller, Presenter 등 외부 통신을 Use Case에 맞게 변환.
    *   **Frameworks & Drivers**: DB, React, Express 등 외부 라이브러리 (가장 바깥쪽, 언제든 교체 가능).
2.  **핵심 원칙 - 의존성 규칙**:
    *   의존성은 반드시 안쪽(Entity)으로만 향해야 함. 안쪽은 바깥쪽이 무엇을 쓰는지 몰라야 함.

## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
- **과거 데이터와의 충돌**: 과거의 개발 정책은 프레임워크(예: Spring, [[Next.js|Next.js]])가 제공하는 구조에 모든 코드를 넣는 정책이었으나, 현대 정책은 프레임워크를 단순한 '도구'로 취급하고 비즈니스 로직을 독립적으로 유지하는 '프레임워크 독립 정책'을 추구함(RL Update).
- **정책 변화(RL Update)**: 타입스크립트의 강력한 타입 시스템 정책을 활용하여, 컴파일 타임에 계층 간 의존성 위반을 체크하거나 '도메인 기반 타입 정의 정책'을 통해 아키텍처의 강건함을 코드 레벨에서 보장함. (Domain-Driven-Design과 시너지)

## 🔗 지식 연결 (Graph)
- Domain-Driven-Design (DDD), [[Technical-Architecture|Technical-Architecture]], [[Optimization|Optimization]], [[Backend|Backend]], Workflow-InteGrity
- **Modern Tech/Tools**: TypeDI, InversifyJS, Hexagonal Architecture patterns, Microservices.
---
