20. 람다 아키텍처 (Lambda Architecture) — 배치+실시간 이중 처리

핵심 인사이트 (3줄 요약)

본질: Lambda Architecture (람다 아키텍처)는 Nathan Marz(트위터, 2011)가 제안한 빅데이터 아키텍처 패턴으로, 모든 데이터를 완전하게 재처리하는 배치 레이어(Batch Layer), 최근 데이터를 빠르게 처리하는 스피드 레이어(Speed Layer), 두 레이어의 결과를 병합하는 서빙 레이어(Serving Layer)로 구성하여 정확성과 저지연을 동시에 달성한다.
가치: 배치 레이어는 전체 히스토리 데이터로 정확한 뷰를 생성하고, 스피드 레이어는 최근 데이터의 근사치(Approximate)를 빠르게 제공하여, 사용자는 항상 낮은 지연의 근사치를 보다가 배치 뷰가 완성되면 정확한 값으로 대체된다.
판단 포인트: Lambda 아키텍처의 핵심 문제는 **코드 이중화(Code Duplication)**다. 배치(Spark/Hadoop)와 실시간(Flink/Spark Streaming)에서 동일한 비즈니스 로직을 각각 구현·유지해야 하며, 이 운영 복잡도를 해소하기 위해 Kappa Architecture(단일 스트리밍)가 대안으로 등장했다.

Ⅰ. 개요 및 필요성

1. Lambda Architecture의 탄생 배경

2010년대 초반 빅데이터 처리의 핵심 딜레마:

배치 처리만 사용:
  → 정확하고 완전하지만 지연 시간이 수 시간
  → 사기 탐지·실시간 추천에 부적합

실시간 처리만 사용:
  → 빠르지만 시스템 장애나 버그 시 데이터 손실·오류
  → 전체 히스토리 재처리 불가 (대량 데이터)
  → 복잡한 집계(예: 전체 기간 통계)는 처리 불가

Lambda Architecture의 해결책:
  → 두 방식을 병렬 운영하여 각각의 장점을 취함

2. 3개 레이어의 역할

레이어	역할	특성	기술 예시
Batch Layer	전체 데이터 재처리, 정확한 배치 뷰 생성	고지연, 고정확도	Hadoop, Spark, Hive
Speed Layer	최근 데이터 실시간 처리, 근사치 뷰 생성	저지연, 근사값	Flink, Spark Streaming
Serving Layer	배치 뷰 + 실시간 뷰 병합, 쿼리 제공	읽기 전용	Cassandra, HBase, Elasticsearch

📢 섹션 요약 비유

Lambda Architecture는 "투표 결과 집계 시스템"과 같다. 개표 진행 중(스피드 레이어)에는 예상 집계를 보여주고, 전체 개표 완료(배치 레이어) 후 최종 정확한 결과로 교체된다. 투표 시스템(서빙 레이어)은 항상 가장 최신 결과를 보여준다.

Ⅱ. 아키텍처 및 핵심 원리

1. Lambda Architecture 다이어그램

원본 데이터 스트림
     │
     ├──────────────────────────────────────────┐
     │ 모든 데이터 (과거 + 현재)                │
     ▼                                          ▼
┌─────────────────────┐              ┌──────────────────────┐
│  Batch Layer         │              │  Speed Layer          │
│                      │              │                       │
│  • 전체 데이터 재처리 │              │  • 최근 데이터만 처리  │
│  • 주기적 실행       │              │  • 실시간 증분 처리    │
│    (예: 매 시간)     │              │  • 근사치 뷰 생성      │
│  • 정확한 배치 뷰    │              │                       │
│                      │              │  Flink / Storm        │
│  Hadoop / Spark      │              │  Spark Streaming      │
└──────────┬───────────┘              └──────────┬────────────┘
           │                                     │
           │ 배치 뷰 (정확, 낮은 신선도)          │ 실시간 뷰 (근사, 높은 신선도)
           └──────────────────┬──────────────────┘
                              ▼
                   ┌──────────────────┐
                   │  Serving Layer   │
                   │                  │
                   │  배치 뷰 + 실시간 뷰 병합│
                   │  쿼리 API 제공   │
                   │                  │
                   │  Cassandra / HBase│
                   │  Elasticsearch   │
                   └──────────────────┘
                              │
                       사용자/서비스 쿼리

2. 실제 데이터 쿼리 흐름

사용자 쿼리: "user-001의 지난 30일 구매 합계"

Serving Layer:
  1. 배치 뷰에서 어제까지의 정확한 합계 조회: 100,000원
  2. 실시간 뷰에서 오늘 현재까지 근사값 조회: 5,000원
  3. 병합: 100,000 + 5,000 = 105,000원 (표시)

6시간 후 배치 작업 완료:
  → 오늘 정확한 합계 6,000원으로 확정
  → 배치 뷰: 106,000원으로 업데이트
  → 실시간 뷰: 오늘 추가분만 다시 계산

3. Lambda Architecture 장단점

장점	단점
정확성 보장 (배치 레이어 재처리)	코드 이중화 (배치 + 실시간 동일 로직)
저지연 응답 (스피드 레이어)	운영 복잡도 2배 (두 시스템 유지)
장애 복구 용이 (배치로 재처리 가능)	결과 병합 로직 복잡
검증된 패턴	기술 스택 이질성 (Spark + Flink)

📢 섹션 요약 비유

Lambda의 코드 이중화는 "같은 서류를 영어와 한국어로 각각 만드는 것"이다. 내용(비즈니스 로직)은 같은데 형식(배치용, 실시간용)이 달라 하나가 바뀌면 둘 다 수정해야 한다.

Ⅲ. 비교 및 연결

1. Lambda vs Kappa Architecture

비교	Lambda Architecture	Kappa Architecture
스트리밍 레이어 수	배치 + 실시간 (2개)	실시간만 (1개)
재처리 방법	배치 레이어 재실행	Kafka 리플레이
코드 중복	있음 (배치 + 실시간)	없음 (스트리밍 단일)
운영 복잡도	높음	낮음
정확도	배치로 완전 보정	리플레이로 재처리
적합 케이스	복잡한 배치 집계 + 실시간 필요	단순 스트리밍 처리

2. 현대적 대안: Lakehouse 패턴

Lambda의 현대적 재해석:
  Batch Layer → Delta Lake / Iceberg (ACID 배치)
  Speed Layer → Structured Streaming (마이크로배치)
  Serving → 동일 Delta Lake 테이블 쿼리

→ 코드 통일: 모두 Spark API 사용
→ 스토리지 통일: 모두 같은 Delta Lake 테이블

📢 섹션 요약 비유

Lambda vs Kappa는 "두 공장 운영 vs 한 공장 운영"이다. 두 공장(Lambda)은 서로 보완하지만 관리 비용이 2배다. 한 공장(Kappa)은 단순하지만 모든 생산을 감당할 수 있어야 한다.

Ⅳ. 실무 적용 및 기술사 판단

1. Lambda Architecture 적합 케이스

적합 상황	이유
복잡한 기간 집계 필수 (전체 히스토리)	스트리밍만으로는 처리 어려운 대규모 집계
스트리밍 오류 후 정확도 보정 필요	배치 재처리로 오차 수정 가능
실시간 응답 + 일별 완전 정확 리포트	두 레이어가 각각 역할 분담

2. 전환 고려 시점

Lambda → Kappa 전환 검토 시점:
  1. 배치 코드와 실시간 코드 유지보수 비용이 개발팀 부담의 30% 이상
  2. 비즈니스 로직 변경이 잦아 이중화 유지가 힘들 때
  3. Kafka 보존 기간을 전체 히스토리로 유지할 수 있을 때

📢 섹션 요약 비유

Lambda Architecture 유지 결정은 "두 지점 운영 vs 본점 확장"이다. 처음엔 두 지점이 서로 다른 고객층을 커버했지만, 본점이 충분히 커지면 두 지점을 하나로 합치는 것이 더 효율적이다.

Ⅴ. 기대효과 및 결론

1. 기대효과

효과	설명
정확도 + 저지연 동시 달성	배치 정확도 + 실시간 속도 병행
장애 복원력	실시간 오류 → 배치로 재처리하여 보정
검증된 패턴	트위터, Netflix 등 대형 플랫폼에서 검증

2. 결론

Lambda Architecture는 실시간 처리의 속도와 배치 처리의 정확성을 동시에 달성하는 검증된 빅데이터 아키텍처 패턴이다. 기술사 답안에서는 3개 레이어의 역할·기술·데이터 흐름, 코드 이중화 문제, Kappa Architecture와의 비교, 그리고 Lakehouse로의 현대적 진화를 함께 서술하면 완성도 높은 답안이 된다.

📢 섹션 요약 비유

Lambda Architecture는 "주식 시장의 실시간 전광판(스피드 레이어)과 공식 마감 시황 뉴스(배치 레이어)"를 동시에 운영하는 것이다. 전광판은 빠르지만 근사치이고, 마감 시황은 늦지만 정확하다. 투자자(서빙 레이어)는 두 정보를 합쳐서 의사결정한다.

📌 관련 개념 맵

개념	관계	설명
Kappa Architecture	대안 패턴	Lambda의 코드 이중화 문제를 해소
Apache Kafka	공통 기반	두 레이어 모두 Kafka를 원본 소스로 사용
Delta Lake / Iceberg	현대적 구현	배치+스트리밍 통합한 Lakehouse 패턴
Exactly-Once	신뢰성	스피드 레이어의 정확도 향상을 위한 보장
마이크로배치	스피드 레이어	Spark Structured Streaming의 접근 방식

📈 관련 키워드 및 발전 흐름도

[배치 vs 실시간 처리 딜레마 — 정확성(배치) vs 실시간성(스트리밍) 충돌]
    │
    ▼
[람다 아키텍처 (Lambda Architecture) — Batch Layer + Speed Layer + Serving Layer 3계층]
    │
    ▼
[카파 아키텍처 (Kappa Architecture) — 스트리밍 단일 파이프라인으로 배치 레이어 제거]
    │
    ▼
[Delta Lake / Apache Iceberg — ACID 트랜잭션 지원 오픈 테이블 포맷]
    │
    ▼
[Lakehouse 아키텍처 — 데이터 레이크 + 데이터 웨어하우스 통합]

배치와 스트리밍의 결합을 람다 아키텍처가 해결했고, 복잡성 문제를 카파 아키텍처가 단순화했으며, 최종적으로 Lakehouse가 ACID와 대규모 분석을 통합했다.

👶 어린이를 위한 3줄 비유 설명

Lambda Architecture는 "운동회 점수판"과 같아요. 실시간 점수판(스피드 레이어)은 경기 중 계속 업데이트되고, 심판의 공식 집계(배치 레이어)는 경기 끝나고 정확히 정산해요. 최종 결과(서빙 레이어)는 공식 집계가 나올 때까지는 실시간 점수를 보여주다가, 공식 집계가 나오면 그것으로 교체해요. 문제는 같은 점수 계산 규칙을 두 번 만들어야 한다는 거예요!