1. 컨테이너 가상화 기술의 이해
가상화 기술의 진화
전통적인 가상화 기술은 하이퍼바이저를 통해 하드웨어 레벨에서 가상 머신(VM, Virtual Machine)을 생성했습니다. 각 VM은 완전한 게스트 OS를 포함하여 상당한 오버헤드가 발생했고, 컨테이너 가상화는 이러한 문제를 해결하기 위해 등장했습니다.
컨테이너는 OS 레벨 가상화를 통해 애플리케이션과 그 종속성을 격리된 환경에서 실행합니다. 호스트 OS의 커널을 공유하면서도 프로세스, 네트워크, 파일시스템을 독립적으로 운영할 수 있습니다.
컨테이너 vs 가상 머신
| 비교기준 | 가상머신(VM) | 컨테이너 |
| 부팅속도 | 느림 | 매우 빠름 |
| 자원 효율성 | 각 VM마다 OS 필요메모리/디스크 오버헤드 큼 | 호스트 OS커널 공유최소한의 리소스만 사용 |
| 격리 수준 | 완전한 하드웨어 가상화높은 보안 격리 | 커널 수준 격리VM보다 낮은 격리도 |
| 이식성 | 무거운 이미지플랫폼 의존성 있음 | 경량 이미지“어디서나 동일 실행” |
| 운영 복잡도 | OS 패치/업데이트 필요인프라 중심 운영 | 오케스트레이션 도구 필요애플리케이션 중심 운영 |
| 밀도(서버 당) | 낮음(수~수십 VM) | 높음(수백~수천 컨테이너) |
Docker와 컨테이너 런타임
Docker는 컨테이너 기술을 대중화한 플랫폼입니다. 주요 구성 요소는 다음과 같습니다.
Docker 아키텍처:
Docker의 핵심 구성요소인 이미지, 레이어, 레지스트리는 효율적인 컨테이너 관리와 배포의 기반이 됩니다.
컨테이너 핵심 개념:
- 이미지(Image): 애플리케이션 실행에 필요한 모든 것을 포함하는 읽기 전용 템플릿
- 컨테이너(Container): 이미지의 실행 가능한 인스턴스
- 레지스트리(Registry): 이미지를 저장하고 배포하는 저장소
- 레이어(Layer): 이미지를 구성하는 읽기 전용 파일시스템 계층
Docker 기본 명령어 예시:
Docker file 기초 예시:
이미지 태깅/버저닝 전략
- latest 태그 사용 지양: latest 태그는 언제든 변경될 수 있어 예측 가능성이 떨어집니다. 명시적 버전 태그1.4.2를 사용하여 정확히 어떤 버전이 실행되는지 항상 알 수 있게 합니다.
- 불변 태그 + Digest SHA 활용: 태그는 재사용될 수 있으므로, 배포에는 다이제스트 해시(SHA256)를 함께 사용하여 정확한 이미지를 참조합니다.image@sha256:a2c…def
- 의미론적 버전(SemVer) 채택: 메이저.마이너.패치 형식을 사용하여 변경 규모와 호환성 정보를 명확히 전달합니다. 예: 2.1.5
- 릴리스 채널 병행 운영: 여러 환경과 사용자 그룹을 위해 다양한 안정성 수준의 채널을 제공합니다: stable, rc(릴리스 후보), beta, canary
- 환경/빌드 정보 포함: 필요한 경우 배포 환경이나 빌드 정보를 태그에 포함시킵니다: 1.4.2-alpine 또는 1.4.2-20231105
레지스트리 옵션 비교
| 레지스트리 | 가격 | 프라이빗 | 정책 | 지역 | IAM연동 | 이미지서명 |
| Docker Hub | 무료~$5/월~ | △ 제한적 | 속도 제한, 보존 정책 | 글로벌 | ✕ 없음 | ✓ Docker Content Trust |
| GitHub (GHCR) | 무료~, 사용량 기준 | ✓ 지원 | GitHub 액션 통합 | 글로벌 | △ GitHub 권한 | ✓ Cosign |
| AWS ECR | 스토리지 + 전송 기준 | ✓ 지원 | 수명주기 정책 | 리전별 | ✓ AWS IAM | ✓ 이미지 스캔 |
| Google GAR | 스토리지 + 전송 기준 | ✓ 지원 | Artifact Analysis | 리전/멀티 | ✓ Google IAM | ✓ Binary Auth |
| Azure ACR | Basic~Premium | ✓ 지원 | 지리적 복제 | 리전/복제 | ✓ Azure AD | ✓ AKV 연동 |
✓: 완전 지원, △: 부분 지원, ✕: 지원 안 함
* 클라우드 레지스트리(ECR, GAR, ACR)는 해당 클라우드 서비스와의 통합이 강점
핵심 요약
이식성과 일관성:
• 컨테이너는 애플리케이션과 종속성을 함께 패키징하여 어떤 환경에서도 동일하게 실행할 수 있
도록 보장합니다. 개발, 테스트, 프로덕션 간의 환경 차이 문제를 해결합니다.
핵심 전략과 도구:
• 효율적인 Dockerfile 작성, 계층화된 이미지 관리, 안전한 레지스트리 활용이 컨테이너 배포의
핵심입니다. 태그 전략과 멀티스테이지 빌드로 배포 파이프라인을 최적화합니다.
2. 분산 시스템의 데이터 일관성 보장 방법
분산 시스템에서의 트랜잭션 문제
모놀리식 애플리케이션에서는 ACID 트랜잭션을 데이터베이스가 보장합니다. 하지만 마이크로서비스 아키텍처(MSA, Microservices Architecture)에서는 여러 서비스가 각자의 데이터베이스를 가지므로 전통적인 트랜잭션 관리가 불가능합니다.
주요 도전 과제:
- 부분 실패/네트워크 지연
- 재시도/백오프/멱등성
- 데이터 일관성
- 시간 동기화/클록 스큐
- 관찰 가능성
- 장애 허용성
CAP 정리: 분산 시스템은 Consistency(일관성), Availability(가용성), Partition Tolerance(분할 내성) 중 두 가지만 동시에 보장할 수 있습니다.
- Partition Tolerance(P)는 전제: 분산 시스템에서 네트워크 분할은 불가피
- CP 시스템 : 일관성 우선 – 모든 노드가 동일한 데이터 제공, 네트워크 분할 시 일부 요청 거부 (MongoDB)
- AP 시스템 : 가용성 우선 – 항상 응답 가능, 최종 일관성(Eventual Consistency) 제공 (Cassandra)
가용성 (Availability): 서버가 죽거나 문제가 생겨도, 사용자는 항상 응답을 받을 수 있어야 합니다.
분할 허용성 (Partition Tolerance): 여러 서버가 분산되어 있다 보면, 네트워크가 끊길 수 있습니다 (예: 한 서버와의 연결이 끊김) 그럴 때 일부 서버끼리만이라도 계속 작동할 수 있는 능력을 말합니다.
일관성 (Consistency): 분산 시스템은 여러 서버가 같은 데이터를 나눠 관리합니다. 이때 사용자가 어느 서버에 요청하든, 항상 동일한 결과를 받아야 한다는 의미입니다.
CP vs AP 비교와 예시
CP 시스템 예시: 은행 시스템 → 일관성이 중요! 잠시 연결이 끊기더라도 데이터가 틀리면 안됩니다.
AP 시스템 예시: 인스타그램 좋아요 수 → 잠시 동안 좋아요 숫자가 달라도 나중에 맞춰지면 됩니다.
ACID vs BASE
ACID 모델: 주로 은행, 결제, 회계 등 정확성이 필수인 시스템에서 사용
BASE 모델: 대규모 분산 시스템(SNS, IoT, 로그 처리 등)에서 사용
핵심 요약
비즈니스별 요구 수준 정의가 핵심:
• 모든 기능에 강한 일관성은 불필요
• 도메인별 전략 수립이 중요
3. MSA 환경 트랜잭션 패턴
분산 트랜잭션이 필요한 순간
분산 트랜잭션은 여러 서비스와 데이터베이스에 걸쳐 발생하는 트랜잭션으로, 모두 성공하거나 모두 실패해야 하는 경우에 필요합니다.
MSA는 여러 서비스(예: 주문, 결제, 고객 등)가 각각 독립된 DB를 가지고 있습니다. 그래서 “하나의 거래(트랜잭션)”가 여러 DB에 걸쳐 일어날 수 있습니다.
문제는, 한쪽 서비스가 성공하고 다른 쪽은 실패하면 데이터가 불일치하게 된다는 점입니다.
이를 해결하기 위한 방식이 바로 2PC와 Saga입니다.
2-Phase Commit(2PC) 개요
여러 서비스에 걸친 트랜잭션을 한 번에 성공하거나 한 번에 실패시키는 기법
Phase 1: Prepare (준비 단계)
- 중앙 조정자(Coordinator)가 모든 서비스(Participants)에게 “이 트랜잭션을 실행할 준비가 되었나요?” 하고 물어봅니다.
- 각 서비스는 작업을 미리 수행해보고, 가능하면 “Yes”, 실패할 것 같으면 “No”라고 답합니다.
Phase 2: Commit / Rollback 단계 (커밋/롤백 단계)
- 모든 서비스가 “Yes”라고 답하면 Coordinator가 Commit 명령을 내려 실제로 반영.
- 누군가 “No”라고 하면 Rollback 명령을 내려 전부 되돌립니다.
장점:
- 강한 일관성 보장
- ACID 속성 유지
단점:
- 동기적이고 블로킹 방식
- 코디네이터가 단일 장애점(SPOF)
- 성능 저하 (네트워크 왕복, 리소스 잠금)
- 확장성 제한
Saga 패턴 개요
MSA에서는 2PC가 너무 무겁고 느리기 때문에, 비동기 메시지(event) 기반으로 트랜잭션을 관리하는 Saga 패턴을 사용합니다.
SAGA 패턴은 1987년 Hector Garcia㎼Molina 등이 발표한 논문 “Sagas” 에서 처음 제안되었습니다. 그들은 “긴 트랜잭션(Long-lived Transaction)”을 여러 개의 작은 로컬 트랜잭션(Local Transaction) 으로 나누어 관리하기 위해 이 개념을 도입했습니다. 당시에는 데이터베이스 간 분산 트랜잭션의 복잡성을 줄이기 위한 연구였습니다.
동작 방식: Choreography vs Orchestration
| 구분 | Choreography 코레오그래피 | Orchestration 오케스트레이션 |
| 구조 | 지휘자 없이 각자가 스텝에 맞춰 함께 춤추는 댄스 | 지휘자가 있는 오케스트라 |
| 흐름 제어 | 각 서비스가 스스로 이벤트에 반응 | 중앙 오케스트레이터가 명령 |
| 조정자(Coordinator) | 없음 | 존재 |
| 결합도 | 느슨함 (loosely coupled) | 상대적으로 강함 |
| 장점 | 확장성 높고, SPOF 없음 | 흐름이 명확하고 디버깅 쉬움 |
| 단점 | 흐름 파악/디버깅 어려움 | 중앙 장애 시 전체 영향(SPOF) |
| 사용 예시 | 전자상거래 주문, 회원가입 후 포인트 지급 | 항공권 예약, 금융거래, 복잡한 롤백 |
언제 무엇을 선택해야 하나?:
| 비즈니스 시나리오 | 추천 방식 |
| 플로우가 단순하고 이벤트 흐름으로 자연스럽게 이어지는 경우 | Choreography |
| 다양한 조건/에러 처리, 병렬 작업 등 복잡한 로직이 있는 경우 | Orchestration |
| 실시간 처리/이벤트 드리븐 아키텍처(Kafka 중심) | Choreography |
| 워크플로우 엔진이나 BPM 도입을 고려 중 | Orchestration |
핵심 요약
• 컨테이너 표준화 : 개발-테스트-운영 환경 일관성, 빠른 배포 사이클
• CAP 트레이드오프 : 분산 시스템 설계 시 일관성-가용성 균형점 결정
• 2PC vs Saga : 데이터 정합성 요구 수준에 따른 트랜잭션 관리 전략 선택
• Choreography vs Orchestration : 서비스 간 협조 방식-이벤트 기반 자율 흐름 vs 중앙 집중 제어
4. 결론
컨테이너 가상화와 분산 트랜잭션 처리는 현대 클라우드 네이티브 애플리케이션을 구성하는 핵심 기술입니다.
- 컨테이너는 가볍고 이식성이 높은 실행 환경을 제공합니다.
- Kubernetes는 컨테이너 오케스트레이션의 사실상 표준으로 자리 잡았습니다.
- 분산 트랜잭션은 주로 Saga 패턴이나 Event Sourcing 같은 방식으로 구현합니다.
- 완벽한 동기화를 유지하기보다는, 최종적으로 일관된 상태를 보장하도록 설계해야 합니다.
- 이를 위해 보상 트랜잭션을 함께 고려하고, 같은 요청이 반복되어도 결과가 달라지지 않는 ‘멱등성(idempotency)’을 확보해야 합니다.
- 재시도, Circuit Breaker 등 안정성과 신뢰성을 높이는 패턴들도 중요합니다.
마이크로서비스 아키텍처(MSA)에서는 완전한 ACID 트랜잭션보다 시스템의 가용성과 확장성을 우선시하는 경우가 많습니다.
따라서 각 서비스의 특성과 요구사항에 맞춰 일관성과 성능 사이에서 균형 잡힌 선택을 하는 것이 핵심입니다.
참고문헌
- 쿠버네티스 알아보기 1편: 쿠버네티스와 컨테이너, 도커에 대한 기본 개념 – 삼성SDS (2022)
- 컨테이너 기반 가상화와 도커의 이해 – F-Lab (2025)Saga 분산 트랜잭션 패턴 – Microsoft Azure (2025)
- 마이크로서비스 사가 패턴 – Greg Shiny, Medium (2024)
- MSA 환경에서 SAGA 패턴으로 안전한 분산 트랜잭션 구현하기 – Haon Blog (2025)
- 사가 패턴(saga pattern)과 분산 트랜잭션(distributed transaction) – Junhyunny’s Devlogs (2025)
- LG CNS 대중소상생아카데미 교육 AM전문가 과정 교재- MSA/클라우드 기술 기본 프로그램 (2025, 비공개)
그림 출처
- https://www.amplework.com/blog/10-best-devops-tools/
- https://dongwooklee96.github.io/post/2021/03/26/cap-%EC%9D%B4%EB%A1%A0%EC%9D%B4%EB%9E%80.html
- https://dongwooklee96.github.io/post/2021/03/26/two-phase-commit-%EC%9D%B4%EB%9E%80.html
- https://joobly.tistory.com/69