105 lines
5.6 KiB
Markdown
105 lines
5.6 KiB
Markdown
---
|
|
id: wiki-2026-0508-cloud-native
|
|
title: Cloud Native
|
|
category: Architecture
|
|
status: needs_review
|
|
canonical_id: self
|
|
aliases: [cloud_native]
|
|
duplicate_of: none
|
|
source_trust_level: A
|
|
confidence_score: 1.0
|
|
tags: [- cloud-native - containerization - kubernetes - microservices - serverless - hybrid-cloud - infrastructure-as-code]
|
|
raw_sources: [- AI_and_ML/Cloud-Native Computing.md - AI_and_ML/Cloud-Native_Architecture.md - Architecture/Hybrid-Cloud-Architectures.md]
|
|
last_reinforced: 2026-05-08
|
|
github_commit: pending
|
|
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
|
tech_stack:
|
|
language: unspecified
|
|
framework: unspecified
|
|
---
|
|
|
|
# 클라우드 네이티브 컴퓨팅 및 아키텍처 (Cloud-Native)
|
|
|
|
## 📌 한 줄 통찰 (The Karpathy Summary)
|
|
클라우드 네이티브(Cloud-Native)는 클라우드 컴퓨팅 모델의 이점을 극대화하여 애플리케이션을 구축하고 실행하는 현대적인 설계 및 운영 접근 방식입니다 [1]. 컨테이너화, 마이크로서비스, 서버리스, 그리고 자동 확장(Auto-scaling) 능력을 핵심 동력으로 삼아 탄력적이고 관리가 용이한 시스템을 구축하는 것이 목표입니다. 특히 데이터 주권은 로컬(Private)에서 지키고 연산의 확장성은 클라우드(Public)에서 빌려 쓰는 하이브리드 전략을 통해 비즈니스 유연성을 확보합니다 [12].
|
|
|
|
## 📖 구조화된 지식 (Synthesized Content)
|
|
### 1. 클라우드 네이티브의 핵심 기둥 (Core Pillars)
|
|
* **컨테이너화 (Containerization)**: 애플리케이션과 의존성을 독립된 단위로 패키징하여 환경 일관성을 보장합니다. Docker 및 Kubernetes 오케스트레이션을 통해 대규모 배포를 관리합니다 [1, 3].
|
|
* **마이크로서비스 (Microservices)**: 애플리케이션을 작고 독립적인 서비스 단위로 분해하여 독립적 배포와 확장이 가능하게 합니다 [5].
|
|
* **서버리스 (Serverless)**: 서버 관리 없이 코드만 배포하며, 사용량에 따라 자원이 자동 할당되는 모델입니다 [2].
|
|
* **상태 비저장 설계 (Stateless)**: 로컬 세션 데이터를 저장하지 않아 수평적 확장(Scale-out)과 복구(Self-healing)가 자유로운 구조를 지향합니다 [4].
|
|
|
|
### 2. 주요 아키텍처 패턴 (Architecture Patterns)
|
|
* **사이드카 패턴 (Sidecar Pattern)**: 코어 로직 수정 없이 모니터링, 보안, 로깅 기능을 메인 컨테이너 옆에 부착하는 방식입니다. 레거시 시스템의 현대화에 유용합니다 [6, 7].
|
|
* **하이브리드 클라우드 (Hybrid Cloud)**:
|
|
* **Cloud Bursting**: 트래픽 폭증 시에만 클라우드 자원을 동적으로 활용 [17].
|
|
* **Data Sovereignty**: 규제나 보안이 중요한 데이터는 온프레미스에 유지 [18].
|
|
* **인프라스트럭처 애즈 코드 (IaC)**: Terraform, CloudFormation 등을 통해 인프라를 코드로 정의하여 버전 관리와 재현성을 확보합니다 [4].
|
|
|
|
### 3. 운영 및 품질 관리 (Operational Excellence)
|
|
* **준비성 및 활성 프로브 (Health Checks)**: Liveness/Readiness 프로브를 통해 건강한 인스턴스로만 트래픽을 유도하고 실패 시 자동 재시작합니다 [4].
|
|
* **분산 트레이싱 (Distributed Tracing)**: 수많은 서비스 간의 요청 흐름을 추적하여 디버깅 복잡성을 관리합니다 [13, 14].
|
|
|
|
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
|
* **복잡성 증가**: 분산 환경에서의 디버깅, 네트워킹, 보안 관리에 대한 가파른 학습 곡선과 운영 오버헤드가 발생합니다 [13].
|
|
* **서버리스 콜드 스타트**: 비활성 함수 실행 시 발생하는 초기 지연(Cold Start) 문제 [9].
|
|
* **아키텍처 표류 (Architectural Drift)**: 빠른 배포 주기로 인해 초기 설계와 실제 구현(코드) 간의 격차가 발생하기 쉽습니다 [7].
|
|
* **벤더 락인 (Vendor Lock-in)**: 특정 클라우드 제공업체의 독점 기술에 의존하게 될 위험이 있습니다 [11].
|
|
|
|
## 🔗 지식 연결 (Graph)
|
|
- **Related Topics**: [[Microservices Architecture]], [[Serverless Architecture]], [[Infrastructure as Code (IaC)]], [[Service Mesh]]
|
|
- **Projects/Contexts**: Antigravity 하이브리드 지능 시스템 (로컬 지식 + 클라우드 연산)
|
|
- **Next Steps**: 쿠버네티스 오케스트레이션 심화 연구, 분산 트레이싱 도구(Jaeger, Zipkin) 도입 검토.
|
|
|
|
---
|
|
*Last updated: 2026-05-08*
|
|
|
|
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
|
|
|
**언제 이 지식을 쓰는가:**
|
|
- *(TODO)*
|
|
|
|
**언제 쓰면 안 되는가:**
|
|
- *(TODO)*
|
|
|
|
## 🧪 검증 상태 (Validation)
|
|
|
|
- **정보 상태:** needs_review
|
|
- **출처 신뢰도:** A
|
|
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
|
|
|
## 🧬 중복 검사 (Duplicate Check)
|
|
|
|
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
|
- **처리 방식:** UPDATE (자동 정규화)
|
|
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
|
|
|
## 🕓 변경 이력 (Changelog)
|
|
|
|
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
|
|------|-----------|-----------|--------|
|
|
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
|
|
|
## 💻 코드 패턴 (Code Patterns)
|
|
|
|
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
|
|
|
```text
|
|
# TODO
|
|
```
|
|
|
|
## 🤔 의사결정 기준 (Decision Criteria)
|
|
|
|
**선택 A를 써야 할 때:**
|
|
- *(TODO)*
|
|
|
|
**선택 B를 써야 할 때:**
|
|
- *(TODO)*
|
|
|
|
**기본값:**
|
|
> *(TODO)*
|
|
|
|
## ❌ 안티패턴 (Anti-Patterns)
|
|
|
|
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)* |