Refactor: Consolidate directory structure into 5 main categories and update metadata

10_Wiki/Topics_Dev/Serverless_Architecture.md

@@ -1,47 +1,46 @@
 ---
-id: P-REINFORCE-WIKI-DEV-SERVERLESS-ARCHITECTURE
-title: "서버리스 아키텍처와 이벤트 기반 컴퓨팅 (Serverless Architecture)"
-category: "10_Wiki/💻 Topics_Dev"
+id: P-REINFORCE-WIKI-ARCH-SERVERLESS
+title: "서버리스 컴퓨팅과 이벤트 기반 실행 모델 (Serverless Architecture)"
+category: Dev
 status: verified
 canonical_id: ""
-aliases: ["Serverless", "FaaS", "서버리스", "이벤트 주도 컴퓨팅", "AWS Lambda", "Cloud Run"]
+aliases: ["서버리스", "Serverless", "FaaS", "함수 기반 컴퓨팅", "AWS Lambda"]
 duplicate_of: ""
 source_trust_level: A
 confidence_score: 1.0
-tags: ["Cloud_Native", "Serverless", "FaaS", "Scalability", "Cost_Optimization"]
+tags: ["Architecture", "Serverless", "Cloud_Native", "FaaS", "Scalability"]
 raw_sources: ["Datacollector_Export_2026-05-02"]
 last_reinforced: 2026-05-02
 github_commit: ""
 ---
 
-# [[서버리스 아키텍처와 이벤트 기반 컴퓨팅 (Serverless Architecture)]]
+# [[서버리스 컴퓨팅과 이벤트 기반 실행 모델 (Serverless Architecture)]]
 
 ## 1. 개요
-서버리스 컴퓨팅(Serverless Computing)은 개발자가 서버의 프로비저닝이나 인프라 관리에 신경 쓰지 않고, 코드(함수)를 배포하기만 하면 클라우드 제공자가 실행 환경을 동적으로 할당하고 관리하는 실행 모델이다. 사용한 리소스만큼만 비용을 지불하며, 트래픽에 따라 자동으로 확장 및 축소되는 클라우드 네이티브의 핵심 기술이다.
+서버리스 컴퓨팅(Serverless Computing)은 개발자가 서버 인프라를 직접 관리하지 않고, 비즈니스 로직인 '함수(Function)' 단위로 코드를 배포하여 실행하는 클라우드 네이티브 아키텍처 모델이다. 인프라의 확장, 패치, 프로비저닝은 클라우드 제공자가 전담하며, 사용자는 실제 코드가 실행된 시간과 리소스에 대해서만 비용을 지불한다.
 
-## 2. 주요 개념 및 특징
-- **FaaS (Function as a Service)**: 애플리케이션 로직을 독립적인 함수 단위로 배포하고, 이벤트(HTTP 요청, DB 변경, 메시지 큐 등)에 반응하여 실행하는 모델.
-- **BaaS (Backend as a Service)**: 데이터베이스, 인증, 스토리지 등 백엔드 기능을 서드파티 서비스 API로 대체하여 인프라 부담 최소화.
-- **자동 확장 (Auto-scaling)**: 요청량에 비례하여 인스턴스가 자동으로 생성되고, 요청이 없으면 자원을 회수하여 유휴 비용 0원 달성.
-- **무상태성 (Stateless)**: 각 함수 실행은 독립적이며 상태를 유지하지 않으므로, 상태 관리가 필요한 경우 외부 저장소(Redis, DB 등) 연동 필수.
+## 2. 핵심 메커니즘 (FaaS)
+- **이벤트 트리거 (Event-driven)**: HTTP 요청, DB 변경, 파일 업로드 등 특정 이벤트에 의해 함수가 즉시 호출됨.
+- **자동 확장 (Auto-scaling)**: 트래픽의 증감에 따라 함수 인스턴스가 0에서 무한대(플랫폼 한계까지)로 즉시 확장 및 축소됨.
+- **무상태성 (Stateless)**: 각 함수 실행은 독립적이며 이전 실행의 상태를 유지하지 않음. 상태 저장이 필요한 경우 외부 DB나 스토리지를 활용.
 
-## 3. 엔지니어링 가치
-- **운영 오버헤드 감소**: OS 패치, 서버 가동 시간 모니터링 등 낮은 수준의 인프라 관리 업무에서 해방되어 비즈니스 로직에만 집중 가능.
-- **비용 최적화**: 24/7 구동되는 서버 비용 대신, 실제 요청이 처리된 시간과 메모리 사용량에 대해서만 과금되므로 경제적.
-- **지속 가능성 (Sustainability)**: 필요한 순간에만 컴퓨팅 자원을 사용함으로써 클라우드 전체의 에너지 소비와 탄소 배출 감소에 기여.
-- **빠른 시장 출시 (Time-to-Market)**: 인프라 구성 단계 없이 코드를 즉시 배포할 수 있어 아이디어를 프로토타입으로 전환하는 속도가 매우 빠름.
+## 3. 실전 적용 및 최적화
+- **프레임워크별 특성**:
+    - **Express/Fastify**: 가볍고 빠른 초기화 속도로 '콜드 스타트' 지연 최소화에 유리.
+    - **NestJS**: 구조화된 대규모 애플리케이션에 적합하나, 두꺼운 추상화 계층으로 인해 초기화 시 더 많은 메모리와 시간이 소요될 수 있음.
+- **JAMstack 통합**: 백엔드 로직을 서버리스 API로 추상화하여 프론트엔드와 독립적으로 배포 및 운영.
 
 ## 4. 트레이드오프 및 주의사항
-- **콜드 스타트 (Cold Start)**: 유휴 상태의 함수가 처음 실행될 때 런타임 초기화로 인해 발생하는 지연 시간. 응답 속도가 중요한 서비스에서는 프레임워크 경량화나 프로비저닝 설정 필요.
-- **벤더 종속성 (Vendor Lock-in)**: 특정 클라우드 사의 고유 기능이나 트리거 방식에 강하게 결합되어 다른 플랫폼으로의 이관이 어려울 수 있음.
-- **디버깅 및 관찰의 어려움**: 로컬 환경과 클라우드 환경의 차이, 분산된 함수들 간의 호출 추적(Tracing) 등 복잡한 모니터링 체계 요구.
+- **콜드 스타트 (Cold Starts)**: 유휴 상태의 함수가 처음 실행될 때 발생하는 초기화 지연 시간. 성능 최적화의 핵심 과제.
+- **플랫폼 종속성 (Vendor Lock-in)**: 특정 클라우드 제공자(AWS, Azure, GCP)의 독자적인 런타임 환경과 트리거 방식에 결합될 위험.
+- **디버깅의 한계**: 로컬 환경과 실제 클라우드 환경 간의 차이로 인해 분산 추적 및 정밀한 성능 튜닝이 어려울 수 있음.
 
 ## 5. 지식 연결 (Related)
-- [[Cloud_Native_Patterns]]: 서버리스가 지향하는 현대적 인프라 설계 패러다임.
-- [[Microservices_Architecture]]: 함수 단위로 서비스를 쪼개어 관리하는 아키텍처의 연장선.
-- [[API_Design_Principles]]: 서버리스 함수가 외부에 노출되는 주된 방식.
+- [[Cloud_Native_Architecture]]: 서버리스가 속한 상위 아키텍처 패러다임.
+- [[Microservices_Architecture]]: 서버리스 함수들이 모여 구성하는 고도로 분산된 서비스 체계.
+- [[Event_Driven_Architecture]]: 서버리스의 실행 기반이 되는 비동기 메시징 모델.
 
 ## 🧪 검증 상태 (Validation)
 - **정보 상태**: 검증 완료 (Verified)
 - **출처 신뢰도**: A
-- **검토 이유**: 인프라 관리 부담을 최소화하고 리소스 효율성을 극대화하여 민첩하고 경제적인 클라우드 기반 애플리케이션을 구축하기 위한 서버리스 아키텍처 표준 정립.
+- **검토 이유**: 운영 비용 최적화와 개발 생산성 극대화를 위한 현대적 클라우드 실행 모델의 표준 가이드 정립.