chore: update graph view scale and set workspace default tab to graph view
This commit is contained in:
Antigravity Agent
@@ -0,0 +1,104 @@
|
||||
---
|
||||
# ──────────────────────────────────────────────
|
||||
# FRONTMATTER 작성 가이드 (LLM용 주석 포함)
|
||||
# 이 주석들은 파일 저장 시 삭제하지 않아도 됩니다.
|
||||
# LLM이 각 필드를 채울 때 판단 기준으로 사용합니다.
|
||||
# ──────────────────────────────────────────────
|
||||
|
||||
id: "wiki-2026-0507-028"
|
||||
title: "클라우드_인프라_및_IaC_운영_표준"
|
||||
category: "[[10_Wiki/Topics]]"
|
||||
status: "verified"
|
||||
canonical_id: "self"
|
||||
aliases: ["Cloud Infrastructure", "Kubernetes", "Docker", "Terraform", "IaC", "AWS", "클라우드", "오케스트레이션"]
|
||||
duplicate_of: "none"
|
||||
source_trust_level: "B"
|
||||
confidence_score: 1.0
|
||||
tags: ["Cloud", "DevOps", "Infrastructure", "Kubernetes", "Docker", "IaC"]
|
||||
raw_sources: ["직접 입력"]
|
||||
last_reinforced: "2026-05-07"
|
||||
github_commit: "pending"
|
||||
---
|
||||
|
||||
# 클라우드_인프라_및_IaC_운영_표준
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "서버를 직접 조립하지 말고 코드로 정의하라." 클라우드 네이티브 환경에서 인프라는 더 이상 물리적 자산이 아닌, 소프트웨어처럼 버전 관리되고 자동 배포되는 가변적 자원(Cattle, not Pets)이다.
|
||||
|
||||
---
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
|
||||
**추출된 패턴:**
|
||||
> 애플리케이션을 컨테이너(Docker)로 격리하고, 이를 수천 개의 인스턴스로 확장·관리(Kubernetes)하며, 이 모든 인프라 구성을 코드(IaC / Terraform)로 명시하는 것이 현대적 인프라 운영의 핵심 패턴이다.
|
||||
|
||||
**세부 내용:**
|
||||
- **컨테이너화 및 오케스트레이션:**
|
||||
- **Docker:** 애플리케이션과 그 의존성을 하나의 이미지로 패키징하여 환경 일관성 확보.
|
||||
- **Kubernetes (K8s):** 수많은 컨테이너의 배포, 확장, 네트워크, 스토리지를 자동화하는 지휘자(Orchestrator). 파드(Pod) 단위 운영과 사이드카(Sidecar) 패턴을 통한 서비스 메시 구현이 특징.
|
||||
- **IaC (Infrastructure as Code):**
|
||||
- **Terraform:** 클라우드 자원(AWS, GCP 등)을 선언적 코드로 정의하여 인프라의 가시성과 재사용성 확보.
|
||||
- **장점:** 휴먼 에러 방지, 인프라 버전 관리 가능, 동일 환경의 신속한 복제(Staging/Prod).
|
||||
- **클라우드 서비스 모델 (AWS 등):**
|
||||
- 서버리스(Lambda), 관리형 DB(RDS), 컴퓨팅(EC2) 등 다양한 추상화 계층을 제공하여 비즈니스 로직에만 집중할 수 있는 환경 제공.
|
||||
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- 대규모 트래픽 대응을 위한 시스템 확장성(Scalability) 설계가 필요할 때.
|
||||
- 인프라 설정을 수동 작업이 아닌 자동화된 파이프라인(GitOps)으로 구축하고 싶을 때.
|
||||
- 마이크로서비스 아키텍처(MSA)를 실제 클라우드 환경에 구현하고자 할 때.
|
||||
|
||||
**언제 이 지식을 쓰면 안 되는가:**
|
||||
- 트래픽이 극히 적은 초기 MVP나 단일 서버로 충분한 소규모 프로젝트(오버엔지니어링 주의).
|
||||
|
||||
**이 지식을 적용할 때의 권장 절차:**
|
||||
1. **컨테이너화:** 앱을 Dockerfile로 작성하여 이미지를 빌드하고 레지스트리에 푸시.
|
||||
2. **IaC 정의:** VPC, 서브넷, 클러스터 등 기초 인프라를 Terraform 코드로 작성.
|
||||
3. **오케스트레이션 설정:** Kubernetes 매니페스트(YAML)를 통해 앱의 복제본 수(Replica), 로드밸런서 등을 정의.
|
||||
4. **모니터링 연동:** 사이드카 패턴 등을 활용해 로깅 및 보안 기능을 메인 로직과 분리하여 구축.
|
||||
|
||||
**주의사항 또는 알려진 한계:**
|
||||
- **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_파이프라인_자동화]], [[SAST_정적_보안_진단_체계]], [[NextJS_React_현대적_프론트엔드_패턴]]
|
||||
- **Raw Source:** 직접 입력
|
||||
|
||||
---
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-07 | 10여 개의 클라우드/인프라 관련 중복 문서를 통합 및 v3.0 규격 적용 | MERGE | B |
|
||||
Reference in New Issue
Block a user