Files

T

koriweb d8a80f6272 chore(wiki): dangling 링크 canonical 정규화 (768파일/1200건)

이름만 다른(표기 변형) [[위키링크]]를 대상 문서의 canonical 제목으로 치환해
끊겼던 1,200개 링크를 연결. 제목/파일명 정규화 일치만 적용하고 별칭 매칭은
과병합 위험으로 제외(애매성 가드). 원본은 _link_reconcile_backup/ 에 백업.
도구: Datacollect/scripts/link_reconcile_apply.mjs

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

2026-06-08 12:24:15 +09:00

5.8 KiB

Raw Blame History

id, title, category, status, canonical_id, aliases, duplicate_of, source_trust_level, confidence_score, tags, raw_sources, last_reinforced, github_commit, tech_stack

title

클라우드_인프라_및_IaC_운영_표준

📌 한 줄 통찰 (The Karpathy Summary)

"서버를 직접 조립하지 말고 코드로 정의하라." 클라우드 네이티브 환경에서 인프라는 더 이상 물리적 자산이 아닌, 소프트웨어처럼 버전 관리되고 자동 배포되는 가변적 자원(Cattle, not Pets)이다.

📖 구조화된 지식 (Synthesized Content)

추출된 패턴:

애플리케이션을 컨테이너(Docker)로 격리하고, 이를 수천 개의 인스턴스로 확장·관리(Kubernetes)하며, 이 모든 인프라 구성을 코드(IaC / Terraform)로 명시하는 것이 현대적 인프라 운영의 핵심 패턴이다.

클라우드 서비스 모델 (Service Models):
- IaaS (Infra as a Service): 가상 서버, 스토리지 등 기초 인프라 제공.
- PaaS (Platform as a Service): 개발·배포 환경(런타임, 미들웨어) 제공.
- SaaS (Software as a Service): 설치 없이 인터넷을 통해 애플리케이션을 구독하여 사용(수도·전력과 같은 '경험의 구독').
백업 및 재해 복구 (Backup & Disaster Recovery):
- 3-2-1 법칙: 데이터 복사본 3개 보유, 2개 이상의 매체 저장, 1개는 원격지 보관.
- Snapshot: 특정 시점의 데이터 상태를 기록하여 롤백에 용이.
- WORM (Write Once Read Many): 랜섬웨어 대응을 위해 수정/삭제 불가능한 격리 백업 정책 시행.
가상화 (Virtualization):
- 하드웨어 자원을 가상 계층(Hypervisor)을 통해 논리적으로 분할하여 효율성 극대화.
- 컨테이너 가상화(Docker)는 OS 커널을 공유하여 VM보다 가볍고 빠른 기동성을 제공함.
IoT 및 엣지 인프라:
- Telemetry: 센서 데이터를 MQTT/HTTP 프로토콜을 통해 실시간 수집.
- Edge Computing: 클라우드 전송 전 현장에서 데이터를 필터링하여 실시간성 강화 및 네트워크 부하 감소.
- 서버리스(Lambda), 관리형 DB(RDS), 컴퓨팅(EC2) 등 다양한 추상화 계층을 제공하여 비즈니스 로직에만 집중할 수 있는 환경 제공.

🤖 LLM 활용 힌트 (How to Use This Knowledge)

언제 이 지식을 쓰는가:

대규모 트래픽 대응을 위한 시스템 확장성(Scalability) 설계가 필요할 때.
인프라 설정을 수동 작업이 아닌 자동화된 파이프라인(GitOps)으로 구축하고 싶을 때.
마이크로서비스 아키텍처(MSA)를 실제 클라우드 환경에 구현하고자 할 때.

언제 이 지식을 쓰면 안 되는가:

트래픽이 극히 적은 초기 MVP나 단일 서버로 충분한 소규모 프로젝트(오버엔지니어링 주의).

이 지식을 적용할 때의 권장 절차:

컨테이너화: 앱을 Dockerfile로 작성하여 이미지를 빌드하고 레지스트리에 푸시.
IaC 정의: VPC, 서브넷, 클러스터 등 기초 인프라를 Terraform 코드로 작성.
오케스트레이션 설정: Kubernetes 매니페스트(YAML)를 통해 앱의 복제본 수(Replica), 로드밸런서 등을 정의.
모니터링 연동: 사이드카 패턴 등을 활용해 로깅 및 보안 기능을 메인 로직과 분리하여 구축.

주의사항 또는 알려진 한계:

YAML 지옥: 설정 파일의 복잡성이 증가할 수 있으므로 Helm 차트나 Kustomize 같은 관리 도구 활용 권장.
비용 관리: 클라우드 자원은 사용량만큼 과금되므로 자동 확장(Autoscaling) 임계값 설정에 유의.

🧪 검증 상태 (Validation)

정보 상태: verified
출처 신뢰도: B
검토 이유: 해당 없음

🧬 중복 검사 (Duplicate Check)

기존 유사 문서: Kubernetes, Terraform-Infrastructure-as-Code, Containerization_and_Docker, Amazon-AWS-Formal-Verification 등 10여 개
처리 방식: MERGE
처리 이유: 클라우드 인프라의 핵심 3요소(컨테이너, 오케스트레이션, IaC)를 다룬 파편화된 문서들을 하나의 운영 표준 지침서로 통합함.

⚠️ 모순 및 업데이트 (Contradictions & Updates)

과거 데이터와의 충돌: 없음
정책 변화: 단순 '서버 관리' 개념에서 '코드 기반의 동적 오케스트레이션'으로 인프라 패러다임을 공식 정의함.

🔗 지식 연결 (Graph)

Parent: 10_Wiki/Topics
Related: CI/CD 파이프라인 자동화
Raw Source: 직접 입력

🕓 변경 이력 (Changelog)

날짜	변경 내용	처리 방식	신뢰도
2026-05-07	10여 개의 클라우드/인프라 관련 중복 문서를 통합 및 v3.0 규격 적용	MERGE	B

💻 코드 패턴 (Code Patterns)

패턴 1: (TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)

# TODO

🤔 의사결정 기준 (Decision Criteria)

선택 A를 써야 할 때:

(TODO)

선택 B를 써야 할 때:

(TODO)

기본값:

(TODO)

❌ 안티패턴 (Anti-Patterns)

[안티패턴]: (TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)

5.8 KiB Raw Blame History