Files
2nd/10_Wiki/Topics/AI_and_ML/Distributed-Systems.md
T

7.1 KiB

id, title, category, status, canonical_id, aliases, duplicate_of, source_trust_level, confidence_score, tags, raw_sources, last_reinforced, github_commit, inferred_by, tech_stack
id title category status canonical_id aliases duplicate_of source_trust_level confidence_score tags raw_sources last_reinforced github_commit inferred_by tech_stack
wiki-2026-0508-distributed-systems Distributed Systems 10_Wiki/Topics needs_review self
none A 0.92
auto-consolidated
technical-documentation
2026-05-08 pending Claude Opus 4.7 (auto-normalize 2026-05-08)
language framework
unspecified unspecified

Distributed-Systems

📌 한 줄 통찰 (The Karpathy Summary)

"하나처럼 움직이는 여럿: 여러 대의 컴퓨터가 네트워크로 연결되어 사용자에게는 하나의 시스템처럼 보이지만, 실제로는 작업을 나누어 처리하고 일부가 고장 나도 멈추지 않는 현대 인터넷 제국의 엔진이자 뼈대."

📖 구조화된 지식 (Synthesized Content)

분산 시스템(Distributed-Systems)은 독립된 다수의 컴퓨터(노드)가 서로 협력하여 하나의 공동 목표를 수행하는 하드웨어/소프트웨어 아키텍처입니다.

  1. 3대 핵심 난제 (CAP Theorem):
    • Consistency (일관성): 모든 노드가 항상 같은 데이터를 보여줘야 함.
    • Availability (가용성): 일부 노드 장애 시에도 서비스는 계속 되어야 함.
    • Partition Tolerance (분할 내성): 노드 간 네트워크 통신이 끊겨도 작동해야 함. (셋 중 둘만 완벽히 가질 수 있다는 이론)
  2. 왜 중요한가?:
    • 단일 서버로는 감당할 수 없는 빅데이터와 폭발적 트래픽을 감당하는 유일한 방법임. (Scalability의 근간)

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

  • 과거 데이터와의 충돌: 과거에는 관리의 편의를 위해 '거대 단일 서버 정책(Monolithic)'을 선호했으나, 현대 정책은 유연성과 생존력을 위해 작게 쪼개어 분산하는 '클라우드 네이티브 정책(Microservices)'으로 전환됨(RL Update).
  • 정책 변화(RL Update): AI 학습 정책에서, 수만 개의 GPU가 하나로 묶여 거대 모델을 학습하는 '분산 훈련 정책'이 국가적 경쟁력의 지표가 되고 있음.

🔗 지식 연결 (Graph)



1. 개요

분산 시스템 아키텍처는 애플리케이션의 기능을 단일 프로세스가 아닌, 네트워크를 통해 상호작용하는 자율적인 여러 노드(서비스)로 분산하여 구성하는 방식이다. 이는 시스템의 무한한 확장성과 고가용성을 제공하지만, 네트워크 지연, 부분적 장애, 데이터 일관성 유지 등 단일 노드 환경에서는 존재하지 않던 고도의 기술적 복잡성을 수반한다.

2. 분산 환경의 핵심 과제와 해결 패턴

  • 장애 대응 및 복원력 (Resilience): 네트워크 장애나 특정 노드의 다운은 '발생할 수 있는 일'이 아니라 '반드시 발생하는 일'로 간주한다.
    • 회로 차단기 (Circuit Breaker): 장애가 발생한 서비스로의 요청을 일시적으로 차단하여 연쇄 장애 전파 방지.
    • 재시도 및 타임아웃 (Retries & Timeouts): 일시적 네트워크 오류에 대응하고, 무한 대기로 인한 자원 고갈 방지.
    • 벌크헤드 (Bulkhead): 서비스 내부 자원(스레드 풀 등)을 격리하여 특정 기능의 부하가 전체 서비스에 영향을 주지 않도록 차단.
  • 데이터 일관성 (Consistency): 분산된 데이터베이스 간의 물리적 정합성을 실시간으로 유지하기 어려우므로, 결과적 일관성(Eventual Consistency)과 사가(Saga) 패턴 등을 활용한 보상 트랜잭션 설계 적용.
  • 분산 트레이싱 (Distributed Tracing): 여러 서비스를 관통하는 하나의 요청 흐름을 추적하기 위해 상관관계 ID(Correlation ID)를 활용한 전 구간 가시성 확보.

3. 엔지니어링 가치

  • 수평적 확장성 (Scalability): 트래픽 증가 시 특정 노드를 추가하는 것만으로 시스템 전체의 처리 성능을 선형적으로 증대 가능.
  • 지리적 가용성: 서버를 여러 지역(Region)에 분산 배치하여 사용자에게 낮은 지연 시간을 제공하고 지역적 재난 상황에서도 서비스 유지.
  • 기술적 유연성: 각 노드별로 비즈니스 요구사항에 최적화된 프로그래밍 언어, 프레임워크, 데이터베이스 스토리지 선택 가능.

4. 트레이드오프 및 주의사항

  • 관측의 어려움: 시스템의 논리가 여러 저장소와 프로세스에 파편화되어 있어, 전체적인 실행 흐름을 파악하기 위한 인지적 부하와 모니터링 인프라 구축 비용이 매우 높음.
  • 테스팅 복잡도: 단일 노드에서의 단위 테스트만으로는 부족하며, 서비스 간의 상호작용과 네트워크 실패 시나리오를 포함한 정교한 통합 테스트 및 카오스 엔지니어링(Chaos Engineering) 요구됨.
  • 네트워크 오버헤드: 내부 함수 호출에 비해 네트워크를 통한 통신은 수백~수천 배의 지연 시간을 발생시키므로, 빈번한 통신을 최소화하는 조립성(Cohesion) 있는 경계 설계 필수.

🧪 검증 상태 (Validation)

  • 정보 상태: 검증 완료 (Verified)
  • 출처 신뢰도: A
  • 검토 이유: 대규모 트래픽과 가용성 요구사항을 충족하기 위한 분산 컴퓨팅의 원리를 이해하고, 네트워크 불확실성에 대응하는 견고한 시스템 설계 표준 정립.

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

언제 이 지식을 쓰는가:

  • (TODO)

언제 쓰면 안 되는가:

  • (TODO)

🧬 중복 검사 (Duplicate Check)

  • 기존 유사 문서: (TODO: 인덱서 클러스터 리포트 참조)
  • 처리 방식: UPDATE (자동 정규화)
  • 처리 이유: Phase 1 정규화 — 옛 템플릿/누락 필드 보강.

🕓 변경 이력 (Changelog)

날짜 변경 내용 처리 방식 신뢰도
2026-05-08 P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) UPDATE A

💻 코드 패턴 (Code Patterns)

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

# TODO

🤔 의사결정 기준 (Decision Criteria)

선택 A를 써야 할 때:

  • (TODO)

선택 B를 써야 할 때:

  • (TODO)

기본값:

(TODO)

안티패턴 (Anti-Patterns)

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