기술사 학습노트 | imt-log

기술사 학습노트 › 데이터베이스 › 빅데이터 아키텍처

Database · 정보관리기술사 / 컴퓨터시스템응용기술사

대규모 데이터 처리의 핵심: 빅데이터 아키텍처 설계

대량·고속·다양한 데이터를 수집, 저장, 처리, 분석, 시각화하고 데이터 거버넌스와 보안을 통합하는 확장형 데이터 플랫폼 설계 전략

정보관리기술사컴퓨터시스템응용기술사빅데이터데이터레이크데이터웨어하우스LambdaArchitectureKappaArchitectureStreamProcessingDataGovernanceMLOps

Ⅰ.개요 및 등장배경

가. 정의

빅데이터 아키텍처는 정형·반정형·비정형 데이터를 대규모로 수집하고, 분산 저장소에 안정적으로 저장하며, 배치 처리와 실시간 스트림 처리를 통해 분석 가능한 데이터로 변환하고, BI·AI·서비스 API로 활용할 수 있도록 설계한 데이터 처리 구조이다. 단순히 Hadoop이나 Spark 같은 특정 도구의 조합이 아니라 데이터 수명주기 전반을 고려한 플랫폼 설계 개념이다. 즉 데이터 소스, 수집 계층, 저장 계층, 처리 계층, 분석 계층, 서빙 계층, 운영·보안·거버넌스 계층을 체계적으로 연결하는 전체 구조를 의미한다.

나. 등장배경

• 데이터 규모 증가: 웹 로그, 모바일 이벤트, IoT 센서, 거래 데이터, 이미지·음성·영상 등 데이터 양이 폭발적으로 증가하였다.
• 데이터 유형 다양화: 관계형 DB 중심의 정형 데이터뿐 아니라 JSON, 로그, 문서, 클릭스트림, 멀티미디어 데이터 처리가 필요해졌다.
• 실시간 의사결정 요구: 금융 이상거래 탐지, 추천, 제조 설비 모니터링, 광고 입찰처럼 초·분 단위 분석 요구가 증가하였다.
• 클라우드 확산: 객체 스토리지, 서버리스, 관리형 Spark, 데이터 웨어하우스, 데이터 레이크하우스 기반으로 확장형 플랫폼 구축이 쉬워졌다.
• AI 활용 확대: 머신러닝과 생성형 AI 모델 학습을 위해 고품질·대용량·추적 가능한 데이터 파이프라인이 중요해졌다.
• 데이터 거버넌스 강화: 개인정보, 보안, 품질, 메타데이터, 계보, 권한관리, 감사 추적이 데이터 플랫폼의 필수 요건이 되었다.

다. 핵심 설계 관점

빅데이터 아키텍처는 5V, 즉 Volume, Velocity, Variety, Veracity, Value를 중심으로 설계한다. 데이터가 많아도 처리 시간이 길거나 품질이 낮으면 가치가 작고, 실시간 처리만 가능해도 저장·재처리·감사 추적이 불가능하면 운영 위험이 커진다. 따라서 좋은 빅데이터 아키텍처는 대용량 확장성, 실시간성, 데이터 품질, 비용 효율, 보안, 재처리 가능성, 분석 활용성 사이의 균형을 갖추어야 한다.

빅데이터 아키텍처는 대규모 데이터를 수집·저장·처리·분석·활용하는 전체 데이터 플랫폼 구조이다.
답안에서는 수집, 저장, 처리, 분석, 서빙, 거버넌스, 보안, 운영 자동화를 계층별로 제시해야 한다.

Ⅱ.구성도 및 구성요소

가. 빅데이터 아키텍처 구성도

나. 구성요소

구분	요소	설명
데이터 원천	Data Source	RDB, NoSQL, 로그, IoT, 모바일 이벤트, 파일, 외부 API, SaaS 데이터 등 수집 대상이다.
수집 계층	Ingestion	배치 수집, 실시간 스트리밍, CDC, API 수집, 파일 수집을 담당한다.
메시징	Event Broker	Kafka, Pulsar 등으로 이벤트를 버퍼링하고 생산자와 소비자를 분리한다.
저장 계층	Data Lake	원천 데이터를 저비용으로 대량 저장하는 영역이며 원본 보존과 재처리에 유리하다.
분석 저장	Data Warehouse	정제·모델링된 데이터를 SQL 기반 분석과 리포팅에 최적화하여 저장한다.
통합 저장	Lakehouse	데이터 레이크의 확장성과 데이터 웨어하우스의 관리성을 결합한 구조이다.
처리 계층	Batch/Stream Processing	Spark, Flink, SQL 엔진 등을 통해 대규모 데이터 변환, 집계, 조인, 실시간 처리를 수행한다.
서빙 계층	Serving Layer	데이터마트, API, 검색엔진, 캐시, 피처스토어 등을 통해 분석 결과를 사용자와 서비스에 제공한다.
분석 계층	BI/AI Analytics	대시보드, 리포트, 탐색 분석, 머신러닝, 추천, 이상탐지, 예측 모델에 활용한다.
거버넌스	Governance	메타데이터, 데이터 품질, 계보, 권한, 개인정보, 감사로그, 비용관리를 통합한다.

빅데이터 아키텍처 구성요소는 데이터 원천, 수집, 메시징, 저장, 처리, 서빙, 분석, 거버넌스 계층으로 정리된다.
Ⅱ.가 구성도에서는 배치와 스트림이 함께 존재하고, Lambda/Kappa 선택지가 보이도록 표현하면 고득점형이다.

Ⅲ.동작방식 및 아키텍처

가. 빅데이터 처리 흐름

• 1단계 데이터 수집: 업무 DB, 로그, 이벤트, 센서, 파일, 외부 API에서 데이터를 배치 또는 실시간으로 수집한다.
• 2단계 원본 저장: 수집된 데이터를 데이터 레이크의 Raw Zone에 원형 그대로 저장하여 재처리와 감사 추적 가능성을 확보한다.
• 3단계 정제·표준화: 결측, 중복, 스키마 오류, 개인정보, 이상값을 처리하고 표준 코드와 기준정보를 적용한다.
• 4단계 변환·집계: 분석 목적에 맞게 조인, 집계, 세션화, 윈도우 처리, 피처 생성, 데이터 모델링을 수행한다.
• 5단계 분석 저장: 정제된 데이터를 Curated Zone, Data Warehouse, Data Mart, Feature Store에 저장한다.
• 6단계 서비스 제공: BI 대시보드, API, 추천 시스템, AI 모델, 경보 시스템, 검색 서비스로 데이터를 제공한다.
• 7단계 운영 모니터링: 파이프라인 지연, 데이터 품질, 처리 비용, 장애, 보안 이벤트, 접근 로그를 지속 감시한다.

나. Lambda Architecture

Lambda Architecture는 배치 계층과 속도 계층을 함께 사용하는 빅데이터 처리 구조이다. 배치 계층은 전체 원본 데이터를 대상으로 정확한 결과를 계산하고, 속도 계층은 최근 이벤트를 실시간으로 처리하여 저지연 결과를 제공한다. 서빙 계층은 배치 결과와 실시간 결과를 통합해 사용자에게 제공한다. 이 구조는 정확성과 실시간성을 동시에 추구할 수 있지만, 동일한 비즈니스 로직을 배치와 스트림 양쪽에 구현해야 하므로 개발·운영 복잡도가 증가한다.

다. Kappa Architecture

Kappa Architecture는 스트림 처리 중심으로 아키텍처를 단순화한 구조이다. 모든 데이터를 이벤트 로그로 수집하고, 실시간 처리 엔진이 이를 처리하며, 재처리가 필요할 경우 저장된 이벤트 로그를 다시 재생하여 결과를 재생성한다. Kappa는 배치 계층과 속도 계층의 중복 구현을 줄이고 운영을 단순화할 수 있지만, 장기간 이벤트 보존, 재처리 비용, 스트림 처리 로직의 안정성, 정확한 상태 관리가 중요하다.

라. 데이터 레이크·웨어하우스·레이크하우스

구분	Data Lake	Data Warehouse	Lakehouse
저장 대상	원천·정형·반정형·비정형 데이터	정제·모델링된 정형 데이터	원천성과 분석성을 결합한 데이터
장점	대용량 저비용 저장, 유연한 스키마	SQL 분석 성능, 품질 관리, 정합성	유연성, 트랜잭션, 메타데이터 관리, 분석 통합
한계	관리 부실 시 데이터 늪 발생	비정형·원천 데이터 저장에 상대적 한계	운영 기술과 메타데이터 관리 역량 필요
적합 용도	원본 보존, AI 학습, 로그 분석	경영 리포트, 정형 분석, KPI 관리	통합 분석, AI/BI 통합, 클라우드 데이터 플랫폼

마. 설계 핵심 기준

빅데이터 아키텍처 설계는 도구 선정보다 요구사항 분류가 먼저이다. 지연시간 요구가 초 단위인지, 분 단위인지, 일 단위인지에 따라 스트림 처리와 배치 처리 비중이 달라진다. 데이터가 원천 보존 중심인지, 경영 리포트 중심인지, AI 피처 생성 중심인지에 따라 데이터 레이크, 데이터 웨어하우스, 피처스토어 설계가 달라진다. 또한 개인정보가 포함되는 경우 암호화, 마스킹, 접근제어, 보존 기간, 파기 정책이 설계 초기부터 포함되어야 한다.

빅데이터 처리 흐름은 수집, 원본 저장, 정제, 변환, 분석 저장, 서빙, 운영 모니터링 순서로 구성된다.
Lambda는 정확성과 실시간성의 병행, Kappa는 스트림 중심 단순화가 핵심 차이이다.

Ⅳ.실무적용 및 사례

가. 산업별 적용 사례

산업	적용 방식	효과
금융	거래 이벤트를 실시간 수집하여 이상거래 탐지와 신용 리스크 분석을 수행한다.	금융사기 탐지, 리스크 관리, 규제 보고 자동화
제조	설비 센서와 공정 로그를 수집하여 예지보전과 품질 이상탐지를 수행한다.	불량률 감소, 설비 가동률 향상, 유지보수 비용 절감
유통	구매, 클릭, 재고, 배송 데이터를 통합해 추천과 수요예측을 수행한다.	개인화 추천, 재고 최적화, 매출 증대
통신	네트워크 트래픽, 장애 로그, 고객 사용량을 분석한다.	장애 예측, 네트워크 품질 개선, 고객 이탈 방지
공공	민원, 교통, 환경, 안전 데이터를 통합 분석한다.	정책 의사결정 지원, 도시 운영 최적화, 공공 서비스 개선
의료	진료기록, 검사결과, 의료영상, 웨어러블 데이터를 통합한다.	임상 연구 지원, 질병 예측, 개인 맞춤 의료 기반 마련

나. 구축 절차

• 요구사항 정의: 분석 목적, 사용자, 데이터 소스, 지연시간, 보존 기간, 보안 등급, 비용 한계를 정의한다.
• 데이터 인벤토리 작성: 데이터 원천, 소유자, 스키마, 품질 수준, 개인정보 포함 여부, 수집 주기를 식별한다.
• 아키텍처 패턴 선택: 배치 중심, 스트림 중심, Lambda, Kappa, Lakehouse 중 적합한 구조를 선택한다.
• 데이터 존 설계: Raw, Cleansed, Curated, Mart, Sandbox 영역을 나누어 데이터 수명주기를 관리한다.
• 파이프라인 구현: 수집, 정제, 변환, 품질검사, 적재, 서빙 파이프라인을 자동화한다.
• 거버넌스 적용: 메타데이터 카탈로그, 데이터 계보, 품질지표, 권한관리, 마스킹, 감사로그를 적용한다.
• 운영 체계 구축: 모니터링, 장애 대응, 재처리, 배포 자동화, 비용 최적화, SLA 관리를 수행한다.

다. 주요 리스크와 대응

리스크	원인	대응 방안
데이터 늪	원천 데이터만 쌓고 메타데이터와 품질관리를 하지 않음	데이터 카탈로그, 계보, 품질지표, 소유자 관리 적용
스키마 변경 장애	소스 시스템 변경이 파이프라인 실패로 전파	Schema Registry, 계약 기반 데이터 인터페이스, CDC 검증 적용
실시간 처리 지연	이벤트 급증, 컨슈머 병목, 상태 저장소 과부하	파티셔닝, 오토스케일링, 백프레셔, 처리율 모니터링 적용
개인정보 유출	원천 데이터와 분석 데이터에 민감정보 포함	암호화, 마스킹, 토큰화, 접근통제, 보존·파기 정책 적용
비용 폭증	무제한 저장, 비효율 쿼리, 중복 파이프라인	수명주기 정책, 압축·파티셔닝, 쿼리 최적화, 비용 태깅 적용
품질 저하	결측, 중복, 이상값, 기준정보 불일치	품질 규칙, 데이터 테스트, DQ 대시보드, 오류 데이터 격리 적용

라. 실무 설계 팁

빅데이터 아키텍처는 처음부터 모든 기술을 도입하는 방식보다 핵심 사용 사례 중심으로 단계적으로 확장하는 것이 좋다. 예를 들어 초기에는 데이터 레이크와 배치 분석으로 시작하고, 실시간 탐지가 필요한 영역에만 Kafka와 Flink를 적용할 수 있다. 또한 데이터 레이크를 구축할 때 원천 데이터만 저장하면 데이터 늪이 되기 쉽기 때문에 데이터 카탈로그, 계보, 품질 규칙, 접근권한을 동시에 설계해야 한다. 분석계와 운영계의 성능 요구가 다르므로 OLTP 시스템에 직접 대량 분석을 수행하지 말고 CDC, 복제, 이벤트 스트림을 통해 분석 플랫폼으로 분리하는 것이 안정적이다.

실무 빅데이터 아키텍처는 산업별 핵심 사용 사례에서 출발해 수집·저장·처리·분석·거버넌스를 단계적으로 확장해야 한다.
데이터 늪, 스키마 변경, 실시간 지연, 개인정보 유출, 비용 폭증을 주요 리스크로 보고 설계 단계에서 통제해야 한다.

Ⅴ.비교분석 및 발전전망

가. Lambda와 Kappa 비교

구분	Lambda Architecture	Kappa Architecture
구조	Batch Layer, Speed Layer, Serving Layer로 구성	Stream Processing 중심 단일 파이프라인 구조
장점	정확한 배치 결과와 저지연 실시간 결과를 함께 제공	구조가 단순하고 중복 로직이 줄어듦
한계	배치와 스트림 로직 중복, 운영 복잡도 증가	이벤트 로그 보존과 재처리 설계가 중요
적합 상황	대규모 이력 재계산과 실시간 지표가 모두 중요한 경우	이벤트 기반 시스템과 실시간 처리 중심 업무
대표 활용	대형 포털 로그 분석, 금융 리스크 집계, 광고 분석	실시간 추천, IoT 스트림, 이상탐지, 클릭스트림 분석

나. ETL과 ELT 비교

구분	ETL	ELT
흐름	추출 → 변환 → 적재	추출 → 적재 → 변환
변환 위치	중간 처리 서버 또는 ETL 도구	데이터 웨어하우스, 레이크하우스, 분산 SQL 엔진
장점	적재 전 품질 통제와 표준화가 명확	원본 보존과 유연한 재처리가 가능
한계	변환 요구가 바뀌면 원천 재수집 부담 발생	저장소 내부 비용과 권한 통제 설계가 중요
적합 환경	전통적 DW, 강한 품질 통제	클라우드 데이터 레이크, 레이크하우스, 애자일 분석

다. 발전전망

• Lakehouse 확산: 데이터 레이크와 웨어하우스의 장점을 결합해 BI와 AI를 하나의 플랫폼에서 처리하는 구조가 확대된다.
• Real-time Analytics 강화: 배치 리포팅 중심에서 실시간 이벤트 기반 의사결정과 자동화로 발전한다.
• Data Mesh 도입: 중앙 집중 데이터팀만이 아니라 도메인별 데이터 제품 책임을 분산하는 구조가 확산된다.
• Data Fabric 고도화: 메타데이터, 카탈로그, 계보, 품질, 접근정책을 자동 연결하는 통합 데이터 관리가 강화된다.
• AI와 MLOps 연계: 피처스토어, 모델 학습 데이터 버전관리, 데이터 드리프트 모니터링이 중요해진다.
• 보안·프라이버시 강화: 개인정보 보호, 비식별화, 접근통제, 데이터 클린룸, 감사 추적이 표준 요건이 된다.
• FinOps 기반 비용 최적화: 클라우드 저장·처리 비용이 커지면서 파티셔닝, 압축, 수명주기, 쿼리 최적화가 중요해진다.

라. 기술사 답안 정리

빅데이터 아키텍처 설계 답안은 “정의 → 등장배경 → 구성도 → 구성요소 → 처리 흐름 → Lambda/Kappa 비교 → 실무 적용 → 리스크 대응 → 발전전망” 순서로 작성하면 안정적이다. 구성도에는 데이터 소스, 수집, 메시징, 데이터 레이크, 데이터 웨어하우스, 레이크하우스, 배치·스트림 처리, 서빙, BI, AI/ML, 거버넌스를 포함해야 한다. 비교표에서는 Lambda와 Kappa, ETL과 ELT, Data Lake와 DW와 Lakehouse를 정리하면 좋다. 마지막에는 Data Mesh, Data Fabric, Real-time Analytics, MLOps, 데이터 거버넌스, FinOps까지 언급하면 최신성과 실무성을 모두 확보할 수 있다.

답안 암기 포인트: “수집 → 저장 → 처리 → 분석 → 서빙 → 거버넌스” 흐름에 “Lambda/Kappa, Data Lake/DW/Lakehouse, 보안·품질·비용”을 붙이면 된다.

빅데이터 아키텍처는 대규모 데이터를 가치로 전환하기 위한 데이터 플랫폼 설계 구조이다.
향후에는 Lakehouse, 실시간 분석, Data Mesh, Data Fabric, MLOps, 보안·비용 거버넌스 중심으로 발전한다.

블로그: 기술사 학습노트 · imt-log.tistory.com

← [데이터베이스] 목록