From fd6ca255c0ff8b8200c5fe098af16c56e67e6d28 Mon Sep 17 00:00:00 2001 From: Antigravity Agent Date: Sat, 2 May 2026 21:46:37 +0900 Subject: [PATCH] reinforce:wikify - Batch 11: Modern Architecture Patterns (5 artifacts) --- 10_Wiki/Topics_Arch/CQRS_Pattern.md | 40 ++++++++-------- .../Topics_Arch/Event_Driven_Architecture.md | 37 +++++++-------- 10_Wiki/Topics_Arch/Hexagonal_Architecture.md | 46 ++++++++++--------- .../Topics_Arch/Microservices_Architecture.md | 41 +++++++++-------- .../Topics_Arch/Serverless_Architecture.md | 46 +++++++++++++++++++ 5 files changed, 130 insertions(+), 80 deletions(-) create mode 100644 10_Wiki/Topics_Arch/Serverless_Architecture.md diff --git a/10_Wiki/Topics_Arch/CQRS_Pattern.md b/10_Wiki/Topics_Arch/CQRS_Pattern.md index 62b4fbeb..691464c0 100644 --- a/10_Wiki/Topics_Arch/CQRS_Pattern.md +++ b/10_Wiki/Topics_Arch/CQRS_Pattern.md @@ -1,44 +1,44 @@ --- id: P-REINFORCE-WIKI-ARCH-CQRS -title: "명령 조회 책임 분리 (CQRS Pattern)" +title: "명령과 조회 책임 분리 패턴 (CQRS, Command Query Responsibility Segregation)" category: "10_Wiki/🏗️ Topics_Arch" status: verified canonical_id: "" -aliases: ["CQRS", "Command Query Responsibility Segregation", "하이브리드 데이터 레이어"] +aliases: ["CQRS", "Command Query Responsibility Segregation", "명령 조회 분리", "읽기 쓰기 최적화"] duplicate_of: "" source_trust_level: A -confidence_score: 0.95 -tags: ["Architecture", "CQRS", "Eventual_Consistency", "Database_Optimization", "NestJS"] +confidence_score: 1.0 +tags: ["Architecture", "CQRS", "Performance", "Consistency", "Scalability"] raw_sources: ["Datacollector_Export_2026-05-02"] last_reinforced: 2026-05-02 github_commit: "" --- -# [[명령 조회 책임 분리 (CQRS Pattern)]] +# [[명령과 조회 책임 분리 패턴 (CQRS, Command Query Responsibility Segregation)]] ## 1. 개요 -CQRS(Command Query Responsibility Segregation)는 애플리케이션 내에서 **데이터 변경(명령, Command)**과 **데이터 조회(조회, Query)**의 책임을 명확히 분리하는 아키텍처 패턴이다. 이를 통해 복잡한 시스템에서 읽기 성능과 쓰기 일관성을 각각 독립적으로 최적화할 수 있다. +CQRS(Command Query Responsibility Segregation)는 애플리케이션 내에서 데이터를 변경하는 '명령(Command)'과 데이터를 조회하는 '조회(Query)'의 책임을 물리적 또는 논리적으로 분리하는 아키텍처 패턴이다. 이를 통해 시스템의 읽기 성능과 쓰기 일관성을 각기 다른 모델과 기술을 사용하여 독립적으로 최적화할 수 있다. ## 2. 핵심 메커니즘 -- **Command (명령)**: 시스템의 상태를 변경하는 작업. 비즈니스 규칙과 데이터 무결성 보장이 핵심이다. (예: ORM 활용) -- **Query (조회)**: 시스템의 상태를 읽는 작업. 성능 최적화와 가벼운 응답이 핵심이다. (예: 경량 SQL 쿼리 빌더 활용) -- **하이브리드 패턴**: 쓰기에는 무거운 **ORM(Prisma, TypeORM)**을, 읽기에는 가벼운 **SQL 빌더(Kysely, Slonik)**를 사용하는 방식이 실전에서 자주 쓰인다. +- **명령 (Command)**: 시스템의 상태를 변경하는 작업 (Create, Update, Delete). 비즈니스 규칙과 데이터 무결성을 보장하는 복잡한 도메인 모델(Entity, Aggregate)을 사용하며, 주로 ORM(JPA, Prisma 등)을 통해 처리. +- **조회 (Query)**: 시스템의 상태를 단순히 읽어오는 작업 (Read). 도메인 모델의 복잡성을 배제하고, 화면이나 API 요구사항에 최적화된 DTO나 전용 모델을 사용. 성능 극대화를 위해 가벼운 SQL 쿼리 빌더(Slonik, MyBatis 등)나 캐시 레이어 활용. -## 3. 고급 통합 전략 -- **Hexagonal Architecture**: 헥사고날 구조에서 모듈 간의 횡단 관심사(Cross-cutting)를 처리하고 아키텍처 경계를 관리하기 위해 도입된다. -- **도메인 이벤트 (Domain Events)**: 상태 변경 시 이벤트를 발행하여 조회 전용 모델을 업데이트하거나 다른 모듈과 통신한다. -- **결과적 일관성 (Eventual Consistency)**: 읽기와 쓰기 저장소가 분리될 경우, 데이터가 일시적으로 불일치할 수 있으나 최종적으로 일치하게 되는 모델을 수용한다. +## 3. 실전 적용 가치 +- **하이브리드 데이터 접근**: 쓰기 시에는 엄격한 데이터 정합성을 위해 ORM을 사용하고, 읽기 시에는 조인 성능을 위해 순수 SQL이나 특화된 검색 엔진(Elasticsearch 등)을 사용하는 전략 수립 가능. +- **확장성 (Scalability)**: 읽기 요청이 압도적으로 많은 서비스에서 읽기 전용 저장소를 복제(Read Replica)하거나 별도의 서비스로 분리하여 성능 한계를 극복. +- **복잡도 제어**: 하나의 비대한 모델이 읽기와 쓰기 책임을 모두 가지면서 발생하는 유지보수성 저하 문제를 해결. -## 4. 트레이드오프 -- **장점**: 읽기/쓰기 성능의 독립적 스케일링, 복잡한 비즈니스 로직과 복잡한 조회 요구사항의 분리. -- **단점**: 시스템 복잡도 증가, 데이터 동기화 관리 비용(Eventual Consistency), 구현 오버헤드. +## 4. 트레이드오프 및 주의사항 +- **데이터 일관성 (Eventual Consistency)**: 명령과 조회 저장소를 분리할 경우, 쓰기 발생 직후 조회 결과가 최신화되지 않을 수 있는 지연 시간이 발생함. 이를 관리하기 위한 메시지 큐와 동기화 메커니즘 필요. +- **구현 오버헤드**: 두 개의 모델과 파이프라인을 유지해야 하므로 코드 복잡도와 관리 포인트가 증가함. +- **적용 기준**: 비즈니스 로직이 단순하거나 읽기/쓰기 모델의 차이가 거의 없는 경우에는 오버엔지니어링이 될 수 있음. ## 5. 지식 연결 (Related) -- [[Hexagonal_Architecture]]: CQRS를 수용하기에 최적화된 외부 인터페이스 구조. -- [[Domain_Driven_Design]]: 명령(Command) 모델의 비즈니스 규칙을 정의하는 방법론. -- [[Event_Sourcing]]: 상태가 아닌 변경 이벤트를 저장하는 기법 (CQRS와 상보적). +- [[Hexagonal_Architecture]]: CQRS가 내부 모듈 간의 책임을 나누는 중추적인 전략으로 사용됨. +- [[Event_Driven_Architecture]]: 명령 발생 후 조회 모델을 업데이트하기 위해 도메인 이벤트를 비동기로 처리하는 연관 패턴. +- [[Domain_Driven_Design]]: 복잡한 명령 모델(애그리거트)을 설계할 때 CQRS와 함께 시너지를 냄. ## 🧪 검증 상태 (Validation) - **정보 상태**: 검증 완료 (Verified) - **출처 신뢰도**: A -- **검토 이유**: 고부하 엔터프라이즈 시스템의 성능 최적화를 위한 필수 패턴 정립. +- **검토 이유**: 성능과 유연성을 동시에 확보하기 위한 현대적 대규모 시스템 설계의 핵심 패턴 정립. diff --git a/10_Wiki/Topics_Arch/Event_Driven_Architecture.md b/10_Wiki/Topics_Arch/Event_Driven_Architecture.md index ef38cb50..cfd594a1 100644 --- a/10_Wiki/Topics_Arch/Event_Driven_Architecture.md +++ b/10_Wiki/Topics_Arch/Event_Driven_Architecture.md @@ -4,11 +4,11 @@ title: "이벤트 기반 아키텍처 (Event-Driven Architecture, EDA)" category: "10_Wiki/🏗️ Topics_Arch" status: verified canonical_id: "" -aliases: ["EDA", "이벤트 기반 설계", "비동기 메시징"] +aliases: ["EDA", "이벤트 주도 설계", "비동기 메시징", "메시지 기반 아키텍처"] duplicate_of: "" source_trust_level: A confidence_score: 1.0 -tags: ["Architecture", "EDA", "Asynchronous", "Message_Broker", "Loose_Coupling"] +tags: ["Architecture", "EDA", "Asynchronous", "Message_Broker", "Scalability"] raw_sources: ["Datacollector_Export_2026-05-02"] last_reinforced: 2026-05-02 github_commit: "" @@ -17,29 +17,30 @@ github_commit: "" # [[이벤트 기반 아키텍처 (Event-Driven Architecture, EDA)]] ## 1. 개요 -Event-Driven Architecture (EDA)는 시스템 컴포넌트 간의 통신을 '이벤트(Event)'의 발행과 소비를 통해 비동기적으로 수행하는 아키텍처 패러다임이다. 직접적인 함수 호출 대신 상태 변화나 사건 발생을 알리는 메시지를 주고받음으로써 시스템 간의 느슨한 결합(Loose Coupling)을 실현한다. +이벤트 기반 아키텍처(EDA)는 시스템의 상태 변화를 '이벤트(Event)'라는 메시지로 표현하고, 이를 비동기적으로 주고받으며 상호작용하는 아키텍처 스타일이다. 생산자(Producer)와 소비자(Consumer)가 서로의 존재를 직접 알 필요가 없는 느슨한 결합(Loose Coupling)을 통해 고도로 확장 가능하고 탄력적인 시스템을 구축할 수 있다. ## 2. 핵심 구성 요소 -- **이벤트 생산자 (Producer)**: 특정 사건 발생 시 이벤트를 생성하여 브로커에 발행. -- **이벤트 브로커 (Broker)**: 발행된 이벤트를 수신하여 관심 있는 소비자에게 라우팅 (예: Kafka, RabbitMQ). -- **이벤트 소비자 (Consumer)**: 수신한 이벤트에 반응하여 비즈니스 로직을 실행. -- **데드 레터 큐 (Dead Letter Queue, DLQ)**: 처리 실패한 이벤트를 격리하여 사후 분석 및 재처리를 지원. +- **이벤트 생산자 (Event Producers)**: 상태 변화를 감지하고 이벤트를 생성하여 발행하는 주체. +- **이벤트 브로커 (Event Broker)**: 생산자와 소비자 사이에서 이벤트를 수집, 저장, 라우팅하는 중계 인프라 (예: Kafka, RabbitMQ). +- **이벤트 소비자 (Event Consumers)**: 브로커를 구독(Subscribe)하고 있다가 특정 이벤트가 발생하면 비즈니스 로직을 실행하는 주체. +- **데드 레터 큐 (Dead Letter Queue, DLQ)**: 처리에 실패한 이벤트를 격리하여 분석 및 재처리를 가능하게 하는 보관소. -## 3. 실전 설계 원칙 -- **멱등성 (Idempotency) 보장**: 동일한 이벤트가 중복 처리되어도 시스템 상태가 일관되게 유지되도록 소비자 로직 설계 필수. -- **비동기 오케스트레이션**: 마이크로서비스 간의 복잡한 워크플로우를 직접 호출 없이 이벤트 흐름으로 조정. -- **장애 격리**: 특정 서비스의 장애가 전체 시스템으로 전파되지 않도록 브로커를 통한 완충 지대 형성. +## 3. 실전 적용 가치 +- **유연한 확장성**: 특정 소비자의 처리 성능이 부족할 경우, 생산자나 다른 소비자에게 영향을 주지 않고 해당 소비자만 수평 확장(Scale-out) 가능. +- **실시간 반응성**: 주식 가격 변동, 결제 완료 알림, IoT 센서 데이터 처리 등 즉각적인 반응이 필요한 도메인에 최적화. +- **시스템 복원력**: 특정 컴포넌트가 일시적으로 중단되어도 이벤트 브로커에 메시지가 보관되므로 시스템 전체의 데이터 유실 방지. -## 4. 트레이드오프 -- **장점**: 높은 확장성, 유연한 시스템 변경, 실시간 데이터 처리 능력. -- **단점**: 시스템 복잡도 증가, 분산 추적(Distributed Tracing)의 어려움, 결과적 일관성(Eventual Consistency) 관리 비용. +## 4. 트레이드오프 및 주의사항 +- **운영 복잡도**: 분산 시스템 특유의 트랜잭션 관리(Saga 패턴 등), 이벤트 순서 보장, 메시지 유실 방지 등을 위한 고도의 운영 역량 필요. +- **멱등성 (Idempotency) 보장**: 네트워크 장애나 재시도로 인해 동일한 이벤트가 여러 번 전달될 수 있으므로, 소비자는 중복 처리에 대한 방어 로직을 반드시 갖춰야 함. +- **디버깅 및 추적의 어려움**: 직접적인 호출 스택이 존재하지 않으므로 분산 추적(Distributed Tracing) 도구 없이는 문제 발생 시 원인 파악이 힘듦. ## 5. 지식 연결 (Related) -- [[Microservices_Architecture]]: EDA가 가장 활발하게 적용되는 시스템 구조. -- [[Domain_Driven_Design]]: 도메인 이벤트(Domain Events)를 도출하여 EDA 설계를 이끄는 방법론. -- [[Message_Broker_Selection]]: 시스템 특성에 맞는 브로커(Kafka vs RabbitMQ) 선택 전략. +- [[Microservices_Architecture]]: EDA가 서비스 간 통신을 위해 가장 흔히 채택되는 아키텍처 환경. +- [[CQRS_Pattern]]: 상태 변경 후 조회 모델을 업데이트하기 위해 EDA가 핵심 통신 수단으로 사용됨. +- [[Event_Storming]]: EDA의 핵심인 도메인 이벤트를 도출하기 위한 설계 기법. ## 🧪 검증 상태 (Validation) - **정보 상태**: 검증 완료 (Verified) - **출처 신뢰도**: A -- **검토 이유**: 현대적 분산 시스템의 탄력성과 확장성을 위한 핵심 아키텍처 패턴 정립. +- **검토 이유**: 비동기 워크플로우와 고가용성 시스템 구축을 위한 현대적 분산 아키텍처의 핵심 패러다임 정립. diff --git a/10_Wiki/Topics_Arch/Hexagonal_Architecture.md b/10_Wiki/Topics_Arch/Hexagonal_Architecture.md index 9fceb383..363ad3d3 100644 --- a/10_Wiki/Topics_Arch/Hexagonal_Architecture.md +++ b/10_Wiki/Topics_Arch/Hexagonal_Architecture.md @@ -1,47 +1,49 @@ --- id: P-REINFORCE-WIKI-ARCH-HEXAGONAL -title: "헥사고날 아키텍처 (Hexagonal Architecture)" +title: "헥사고날 아키텍처 (Hexagonal Architecture / Ports and Adapters)" category: "10_Wiki/🏗️ Topics_Arch" status: verified canonical_id: "" -aliases: ["포트와 어댑터 아키텍처", "Hexagonal Architecture", "Ports and Adapters"] +aliases: ["헥사고날 아키텍처", "포트와 어댑터", "Hexagonal Architecture", "Ports and Adapters"] duplicate_of: "" source_trust_level: A confidence_score: 1.0 -tags: ["Architecture", "Hexagonal", "DIP", "DDD", "Testability"] +tags: ["Architecture", "Hexagonal", "DIP", "Modularity", "Decoupling"] raw_sources: ["Datacollector_Export_2026-05-02"] last_reinforced: 2026-05-02 github_commit: "" --- -# [[헥사고날 아키텍처 (Hexagonal Architecture)]] +# [[헥사고날 아키텍처 (Hexagonal Architecture / Ports and Adapters)]] ## 1. 개요 -헥사고날 아키텍처(Hexagonal Architecture), 또는 **포트와 어댑터 아키텍처**는 시스템의 핵심 비즈니스 로직(도메인)을 외부 기술(DB, UI, 프레임워크 등)로부터 완전히 격리하는 설계 패턴이다. 비즈니스 로직을 내부(Inside)로, 기술적 세부 사항을 외부(Outside)로 정의하고 그 경계를 인터페이스(포트)로 관리한다. +헥사고날 아키텍처(Hexagonal Architecture)는 애플리케이션의 핵심 비즈니스 로직을 외부 기술(DB, UI, 프레임워크 등)로부터 분리하고 격리하여 유지보수성과 테스트 용이성을 극대화하는 설계 패턴이다. 모든 외부 요소는 인터페이스인 '포트(Port)'를 통해 시스템에 연결되며, 구체적인 기술적 세부 사항은 '어댑터(Adapter)'가 담당하는 구조적 특징을 가진다. ## 2. 핵심 구성 요소 -- **도메인 (Domain)**: 핵심 비즈니스 규칙과 모델. 외부 세계에 대해 전혀 알지 못하는 순수 코드로 작성됨. -- **포트 (Ports)**: 외부 세계와 도메인 간의 소통 규칙을 정의하는 인터페이스. - - **입력 포트 (Inbound)**: 외부에서 도메인 기능을 호출하기 위한 통로 (예: Service Interface). - - **출력 포트 (Outbound)**: 도메인이 외부 자원에 접근하기 위한 통로 (예: Repository Interface). -- **어댑터 (Adapters)**: 포트를 통해 들어오거나 나가는 데이터를 도메인 언어로 번역하는 구현체. - - **입력 어댑터**: REST Controller, CLI, Web UI 등. - - **출력 어댑터**: Database Implementation (JPA/SQL), Message Broker client, External API client 등. +- **도메인 (Inside)**: 시스템의 본질인 비즈니스 로직과 규칙. 외부 프레임워크나 인프라 기술에 전혀 의존하지 않는 순수한 코드로 구성된다. +- **포트 (Ports)**: 외부 세계가 도메인과 소통하기 위한 명세(인터페이스). + - **입력 포트 (Inbound)**: 외부 요청(API 호출, CLI 등)이 도메인 기능을 사용하기 위한 통로. + - **출력 포트 (Outbound)**: 도메인이 외부 자원(DB, 메시지 큐 등)에 접근하기 위해 사용하는 통로. +- **어댑터 (Outside)**: 포트 인터페이스를 구체적으로 구현하거나 호출하는 인프라 계층. + - **입력 어댑터 (Driving)**: 컨트롤러, CLI 핸들러 등 요청을 도메인 명령으로 변환. + - **출력 어댑터 (Driven)**: 영속성(Persistence) 구현체, 메시지 송신부 등 기술적 행위 수행. -## 3. 설계 원칙: 의존성 역전 (DIP) -- 고수준 모듈(도메인)이 저수준 모듈(어댑터)에 의존하지 않아야 한다. -- 도메인과 인프라 계층 모두가 도메인 내부에 정의된 **추상화(포트)**에 의존하게 하여 기술 종속성을 제거한다. +## 3. 실전 적용 가치 +- **기술 스택 교체 용이성**: 비즈니스 로직을 전혀 수정하지 않고도 DB를 교체하거나 API 스펙을 변경하는 등 유연한 운영 가능. +- **테스트 격리**: 인프라 환경 없이도 도메인 로직만 고립시켜 단위 테스트를 수행할 수 있어 검증 속도와 신뢰성 향상. +- **의존성 역전 (DIP)**: 도메인이 인프라에 의존하는 것이 아니라, 인프라(어댑터)가 도메인의 명세(포트)에 맞게 구현되도록 강제하여 코드의 순수성 보존. -## 4. 트레이드오프 -- **장점**: 프레임워크/DB 비의존성, 독립적인 단위 테스트 가능, 기술 스택 교체 용이. -- **단점**: 인터페이스 및 데이터 매핑 객체 증가로 인한 초기 설계 복잡도 및 보일러플레이트 코드 상승. +## 4. 트레이드오프 및 주의사항 +- **구현 복잡도**: 포트와 어댑터 계층을 나누고 다수의 인터페이스와 매퍼(Mapper)를 작성해야 하므로 초기 개발 리소스와 보일러플레이트 코드가 증가함. +- **과잉 설계 (Over-engineering)**: 도메인 로직이 단순한 CRUD 수준일 경우, 헥사고날 아키텍처의 도입은 시스템을 불필요하게 복잡하게 만들 수 있음. +- **학습 곡선**: 전통적인 계층형 아키텍처에 익숙한 개발팀에게는 패러다임 전환을 위한 교육 비용이 발생함. ## 5. 지식 연결 (Related) -- [[Clean_Architecture]]: 헥사고날의 철학을 계승하여 동심원 계층으로 발전시킨 모델. -- [[Domain_Driven_Design]]: 헥사고날의 '내부'를 채우는 핵심 모델링 사상. -- [[Dependency_Injection]]: 헥사고날 구조를 실현하기 위한 핵심 구현 기술. +- [[Domain_Driven_Design]]: 헥사고날 아키텍처 내부(도메인)를 채우는 모델링 기법. +- [[Clean_Architecture]]: 유사한 격리 철학을 동심원 모델로 표현한 아키텍처. +- [[CQRS_Pattern]]: 조회와 명령의 효율성을 위해 헥사고날과 흔히 결합되는 패턴. ## 🧪 검증 상태 (Validation) - **정보 상태**: 검증 완료 (Verified) - **출처 신뢰도**: A -- **검토 이유**: 유지보수성과 확장성이 극대화된 현대적 애플리케이션 설계의 표준 가이드 확립. +- **검토 이유**: 기술 종속성에서 벗어나 비즈니스 로직의 수명을 극대화하기 위한 현대적 아키텍처의 표준 명세 정립. diff --git a/10_Wiki/Topics_Arch/Microservices_Architecture.md b/10_Wiki/Topics_Arch/Microservices_Architecture.md index 13767267..4e4f2a9c 100644 --- a/10_Wiki/Topics_Arch/Microservices_Architecture.md +++ b/10_Wiki/Topics_Arch/Microservices_Architecture.md @@ -1,45 +1,46 @@ --- id: P-REINFORCE-WIKI-ARCH-MICROSERVICES -title: "마이크로서비스 아키텍처 (Microservices Architecture)" +title: "마이크로서비스 아키텍처 (Microservices Architecture, MSA)" category: "10_Wiki/🏗️ Topics_Arch" status: verified canonical_id: "" -aliases: ["MSA", "Microservices", "분산 시스템 아키텍처"] +aliases: ["MSA", "마이크로서비스", "Microservices", "분산 시스템"] duplicate_of: "" source_trust_level: A confidence_score: 1.0 -tags: ["Architecture", "MSA", "Cloud_Native", "Serverless", "Scalability"] +tags: ["Architecture", "MSA", "Cloud_Native", "Scalability", "Agility"] raw_sources: ["Datacollector_Export_2026-05-02"] last_reinforced: 2026-05-02 github_commit: "" --- -# [[마이크로서비스 아키텍처 (Microservices Architecture)]] +# [[마이크로서비스 아키텍처 (Microservices Architecture, MSA)]] ## 1. 개요 -마이크로서비스 아키텍처(Microservices Architecture, MSA)는 대규모 애플리케이션을 독립적으로 배포 및 확장이 가능한 작은 서비스 단위로 분할하여 구축하는 방식이다. 각 서비스는 특정 비즈니스 기능을 수행하며, 네트워크를 통해 상호 통신한다. +마이크로서비스 아키텍처(MSA)는 거대한 단일 애플리케이션(Monolith)을 독립적으로 배포 및 확장 가능한 작은 서비스 단위들로 분할하여 구축하는 시스템 설계 방식이다. 각 서비스는 특정 비즈니스 기능(Bounded Context)에 집중하며, 가벼운 통신 프로토콜(HTTP/REST, gRPC, 메시지 큐 등)을 통해 상호작용한다. ## 2. 핵심 특징 -- **독립적 배포/확장**: 전체 시스템 중 특정 서비스만 개별적으로 업데이트하거나 트래픽에 따라 탄력적으로 확장(Scaling) 가능. -- **클라우드 네이티브 결합**: 컨테이너(Docker/K8s) 및 서버리스(AWS Lambda 등) 환경과 결합하여 운영 효율성 극대화. -- **기술 다양성 (Polyglot)**: 각 서비스의 특성에 맞는 최적의 기술 스택(Node.js, Java, Go 등)을 개별적으로 선택 가능. -- **Bounded Context 기반**: DDD의 바운디드 컨텍스트 단위를 물리적 서비스 경계로 삼아 서비스 간 간섭 최소화. +- **독립적 배포 및 확장**: 전체 시스템을 중단하지 않고 특정 서비스만 개별적으로 업데이트하거나, 트래픽에 맞춰 특정 모듈만 수평 확장(Scale-out) 가능. +- **기술 자율성 (Polyglot)**: 각 마이크로서비스의 특성에 따라 서로 다른 프로그래밍 언어, 데이터베이스, 프레임워크를 선택할 수 있는 유연성 제공. +- **격리된 실패 (Fault Isolation)**: 특정 서비스에 장애가 발생하더라도 서킷 브레이커 등을 통해 전체 시스템으로의 장애 전파를 차단하여 가용성 유지. +- **조직 정렬 (Conway's Law)**: 비즈니스 도메인 단위로 팀을 구성하고, 팀별로 독립적인 서비스 소유권을 부여하여 개발 민첩성 극대화. -## 3. 구현 방식 -- **통신 패턴**: REST API(동기) 및 메시지 큐(비동기, RabbitMQ/Kafka)를 활용한 이벤트 기반 아키텍처. -- **프레임워크**: Java 환경의 **Spring Boot**, Node.js 환경의 **Express/NestJS** 등이 주로 사용됨. -- **JAMstack 연동**: 백엔드 기능을 API 형태로 제공하여 프론트엔드와 완벽히 분리된 구조 구축. +## 3. 실전 아키텍처 결합 +- **클라우드 네이티브와 서버리스**: AWS Lambda, Kubernetes 등 클라우드 인프라를 활용하여 마이크로서비스의 배포와 운영 자동화. +- **헥사고날 아키텍처의 확장**: 각 마이크로서비스 내부를 헥사고날 아키텍처로 설계하여 비즈니스 로직의 순수성을 지키고 외부 기술과의 결합도 최소화. +- **API 게이트웨이**: 수많은 마이크로서비스의 엔드포인트를 단일 창구로 통합하고 인증, 로깅, 라우팅을 중앙 집중적으로 관리. -## 4. 트레이드오프 -- **장점**: 개발 생산성 향상, 장애 격리(Fault Isolation), 빠른 시장 출시(Time-to-Market). -- **단점**: 분산 시스템 통신 복잡성 증가, 데이터 일관성 관리(Eventual Consistency)의 어려움, 모니터링 및 로깅의 복잡도 상승. +## 4. 트레이드오프 및 주의사항 +- **분산 시스템의 복잡성**: 네트워크 지연, 분산 트랜잭션 처리(Saga 패턴 등), 데이터 일관성 유지(Eventual Consistency) 등 고난도의 기술적 과제 수반. +- **운영 오버헤드**: 서비스 수가 늘어남에 따라 모니터링, 로깅, 배포 파이프라인 관리의 난이도가 급격히 상승함. +- **분산 모놀리스 (Anti-pattern)**: 서비스 간의 의존성이 너무 강해 결국 함께 배포해야 하는 상황이 발생하지 않도록 바운디드 컨텍스트 설계를 정교하게 해야 함. ## 5. 지식 연결 (Related) -- [[Hexagonal_Architecture]]: 서비스 내부 구조를 외부 기술과 격리하는 기법. -- [[Serverless_Computing]]: MSA를 구현하기 위한 탄력적 인프라 환경. -- [[Domain_Driven_Design]]: 서비스 경계(Bounded Context)를 획정하기 위한 설계 방법론. +- [[Hexagonal_Architecture]]: 마이크로서비스 내부를 설계하는 기반 패턴. +- [[Event_Driven_Architecture]]: 서비스 간 느슨한 결합을 구현하기 위한 핵심 통신 방식. +- [[Bounded_Context]]: 마이크로서비스를 나누는 논리적/비즈니스적 기준. ## 🧪 검증 상태 (Validation) - **정보 상태**: 검증 완료 (Verified) - **출처 신뢰도**: A -- **검토 이유**: 클라우드 시대의 표준 아키텍처로서의 MSA 핵심 가치 및 구조 정립. +- **검토 이유**: 대규모 트래픽과 복잡한 비즈니스 요구사항을 탄력적으로 수용하기 위한 현대적 아키텍처의 표준 명세 정립. diff --git a/10_Wiki/Topics_Arch/Serverless_Architecture.md b/10_Wiki/Topics_Arch/Serverless_Architecture.md new file mode 100644 index 00000000..5a947681 --- /dev/null +++ b/10_Wiki/Topics_Arch/Serverless_Architecture.md @@ -0,0 +1,46 @@ +--- +id: P-REINFORCE-WIKI-ARCH-SERVERLESS +title: "서버리스 컴퓨팅과 이벤트 기반 실행 모델 (Serverless Architecture)" +category: "10_Wiki/🏗️ Topics_Arch" +status: verified +canonical_id: "" +aliases: ["서버리스", "Serverless", "FaaS", "함수 기반 컴퓨팅", "AWS Lambda"] +duplicate_of: "" +source_trust_level: A +confidence_score: 1.0 +tags: ["Architecture", "Serverless", "Cloud_Native", "FaaS", "Scalability"] +raw_sources: ["Datacollector_Export_2026-05-02"] +last_reinforced: 2026-05-02 +github_commit: "" +--- + +# [[서버리스 컴퓨팅과 이벤트 기반 실행 모델 (Serverless Architecture)]] + +## 1. 개요 +서버리스 컴퓨팅(Serverless Computing)은 개발자가 서버 인프라를 직접 관리하지 않고, 비즈니스 로직인 '함수(Function)' 단위로 코드를 배포하여 실행하는 클라우드 네이티브 아키텍처 모델이다. 인프라의 확장, 패치, 프로비저닝은 클라우드 제공자가 전담하며, 사용자는 실제 코드가 실행된 시간과 리소스에 대해서만 비용을 지불한다. + +## 2. 핵심 메커니즘 (FaaS) +- **이벤트 트리거 (Event-driven)**: HTTP 요청, DB 변경, 파일 업로드 등 특정 이벤트에 의해 함수가 즉시 호출됨. +- **자동 확장 (Auto-scaling)**: 트래픽의 증감에 따라 함수 인스턴스가 0에서 무한대(플랫폼 한계까지)로 즉시 확장 및 축소됨. +- **무상태성 (Stateless)**: 각 함수 실행은 독립적이며 이전 실행의 상태를 유지하지 않음. 상태 저장이 필요한 경우 외부 DB나 스토리지를 활용. + +## 3. 실전 적용 및 최적화 +- **프레임워크별 특성**: + - **Express/Fastify**: 가볍고 빠른 초기화 속도로 '콜드 스타트' 지연 최소화에 유리. + - **NestJS**: 구조화된 대규모 애플리케이션에 적합하나, 두꺼운 추상화 계층으로 인해 초기화 시 더 많은 메모리와 시간이 소요될 수 있음. +- **JAMstack 통합**: 백엔드 로직을 서버리스 API로 추상화하여 프론트엔드와 독립적으로 배포 및 운영. + +## 4. 트레이드오프 및 주의사항 +- **콜드 스타트 (Cold Starts)**: 유휴 상태의 함수가 처음 실행될 때 발생하는 초기화 지연 시간. 성능 최적화의 핵심 과제. +- **플랫폼 종속성 (Vendor Lock-in)**: 특정 클라우드 제공자(AWS, Azure, GCP)의 독자적인 런타임 환경과 트리거 방식에 결합될 위험. +- **디버깅의 한계**: 로컬 환경과 실제 클라우드 환경 간의 차이로 인해 분산 추적 및 정밀한 성능 튜닝이 어려울 수 있음. + +## 5. 지식 연결 (Related) +- [[Cloud_Native_Architecture]]: 서버리스가 속한 상위 아키텍처 패러다임. +- [[Microservices_Architecture]]: 서버리스 함수들이 모여 구성하는 고도로 분산된 서비스 체계. +- [[Event_Driven_Architecture]]: 서버리스의 실행 기반이 되는 비동기 메시징 모델. + +## 🧪 검증 상태 (Validation) +- **정보 상태**: 검증 완료 (Verified) +- **출처 신뢰도**: A +- **검토 이유**: 운영 비용 최적화와 개발 생산성 극대화를 위한 현대적 클라우드 실행 모델의 표준 가이드 정립.