1편. 금융권에서 하둡(Hadoop)을 왜 쓰는가? — 도입 배경과 아키텍처의 진화

 

🟦 1편. 금융권은 왜 하둡(Hadoop)을 선택했을까? — 도입 배경부터 아키텍처 진화까지

금융권에서 데이터는 이미 ‘자산’을 넘어 ‘인프라’가 되었습니다.
그리고 이 인프라의 중심에는 여전히 하둡(Hadoop)이 존재합니다.

한때 “저렴한 분산 스토리지” 정도로 여겨졌던 하둡은 이제
대용량 비정형 데이터 처리, 규제 대응, AI·분석 인프라의 핵심 기반으로 자리 잡았습니다.

그렇다면 수많은 최신 기술이 등장한 지금도 금융권이 하둡을 고집하는 이유는 무엇일까?
실제 현장에서 마주한 경험을 바탕으로 정리해봤습니다.

---

✅ 금융권에서 하둡 도입이 가속화된 4가지 핵심 이유

1) 폭증하는 비정형 데이터

금융기관이 다루는 데이터는 더 이상 트랜잭션에서 끝나지 않습니다.

• 모바일 앱 로그
• API 호출 기록
• 서버/네트워크 로그
• 음성·문자·챗봇 기록
• 이미지 및 기타 비정형 데이터

TB 단위에서 PB 규모로 늘어나는 이러한 데이터는 RDB로 감당하기 어렵고 고비용입니다.
반면 하둡 기반 HDFS는 저비용으로 무한 확장이 가능한 구조라 금융기관 입장에서 매우 매력적입니다.

---

2) Spark 기반 실시간·대규모 분석의 요구

기존 SAS, R 기반 분석 환경은 대규모 데이터를 빠르게 처리하기에 한계가 분명했습니다.

Spark는 메모리 기반 처리 덕분에

• 실시간 이상거래 탐지(FDS)
• 실시간 리스크 분석
• 대규모 머신러닝 데이터 전처리

같은 워크로드에 적합하며, 대부분 하둡 생태계 위에서 운영됩니다.
하둡 + Spark 조합은 금융권 필수 표준에 가깝습니다.

---

3) 보관 기간 증가—규제 대응 필요성

금융 데이터는 보관 기간이 늘어나면서 스토리지 비용 문제가 대두됐습니다.
5년 보관에서 10년 이상으로 늘어난 경우도 적지 않습니다.

RDB나 SAN 스토리지는 오래 보관할수록 비용이 폭증합니다.
반면 HDFS는 저가 서버 묶음(commodity hardware)으로 확장이 가능해
규제 대응 측면에서 훨씬 경제적입니다.

---

4) 민감 데이터는 클라우드 이전이 쉽지 않다

금융권 데이터는 규제와 보안 이슈로 인해
퍼블릭 클라우드 이동이 제한되는 경우가 많습니다.

하둡은 온프레미스에서도 완전히 구축 가능하며

• 네트워크 격리
• 데이터 암호화
• 접근 제어

등의 기능을 갖춰 내부망 보안을 만족시킬 수 있어 꾸준히 채택되고 있습니다.

---

🏗️ RDB 중심에서 Data Lake 중심으로 — 아키텍처의 변화

기존 금융권 데이터 아키텍처는 다음과 같았습니다:

OLTP(RDB) → DW → 리포팅/대시보드

하지만 비정형 데이터 등장, 실시간 처리 요구 증가, 분석 방식 다양화 등으로
이 구조는 한계에 부딪혔습니다.

현재는 아래와 같은 데이터 레이크(Data Lake) 형태로 진화했습니다:

RDB → Kafka → Hadoop(HDFS) → Hive/Spark → AI·모델링·BI·RAG

하둡은 단순 저장소가 아닌
‘원천 데이터의 중앙 허브’ 역할을 하며,
AI 학습 데이터 저장소나 RAG 기반 챗봇의 지식 저장소로도 활용됩니다.

---

🧩 금융권에서 하둡이 쓰이는 실제 분야

분야 설명

비정형 데이터 저장소	로그·JSON·텍스트·이미지 등 대규모 데이터 저장
FDS(이상거래탐지)	Spark 기반 실시간/배치 분석
신용평가 모델링	방대한 고객 데이터를 기반으로 특징 엔지니어링
API 로그 분석	Open Banking·페이 등 API 관련 성능/보안 분석
보안 로그 저장(SIEM 연동)	침해 시도 및 보안 이벤트 분석
데이터 과학자 실험 공간	R&D Sandbox 역할

금융기관에서 하둡이 빠지면 돌아가지 않는 영역이 꽤 많습니다.

---

💡 실전에서 반드시 기억해야 할 하둡 운영 팁 3가지

하둡 도입보다 더 중요한 것은 운영입니다. 금융권 프로젝트에서 반복적으로 등장한 핵심 포인트는 다음과 같습니다.

1) HDFS는 ‘백업’이 아니다

3중 복제(replication)는 하드웨어 장애를 위한 기능이지,
사용자 실수나 데이터 변조 같은 논리적 오류를 막아주지 않습니다.

따라서 반드시:

• Snapshots
• DistCp
• 외부 스토리지(S3/HCP 등) 연동

같은 별도 백업 전략이 필요합니다.

---

2) Kafka → HDFS 적재 시 ‘파일 수 폭증’ 주의

초 단위로 작은 파일이 대량 생성되면 NameNode 메모리가 넘쳐
클러스터 전체가 멈출 수 있습니다.

예방책:

• Kafka Connect HDFS Sink 사용
• 파일 병합(1GB 혹은 10분 단위)
• ORC/Parquet 포맷 적용

운영 안정성을 위해 꼭 필요한 설정입니다.

---

3) DW처럼 정규화하지 마라

하둡은 Schema-on-Read 기반입니다.

데이터는 RAW로 저장하고, 분석 시 스키마를 입히는 방식이기 때문에
정규화는 오히려 성능 저하와 운영 복잡도를 초래합니다.

효율적인 방식은

Denormalized Wide Table 구조
입니다.

---

📌 마무리

하둡은 더 이상 "옛 기술"이 아니라
금융권 데이터 인프라의 중심에서 여전히 강력한 역할을 하고 있습니다.

비정형 데이터 증가, Spark 기반 분석, 보안·규제 강화, AI 활용 확대 등
현대 금융의 요구사항을 만족하는 현실적인 선택지이기도 합니다.

다음 편에서는 실제 금융 프로젝트에서의
하둡 아키텍처 설계 사례와 운영 노하우를 깊이 있게 다뤄보겠습니다.
Hive vs Iceberg 선택 기준, Kafka 적재 전략, Spark 최적화 팁 등 실무 중심으로 정리해 드릴게요.

---

#Hadoop #금융IT #DataLake #Spark #HDFS #금융데이터 #빅데이터아키텍처 #RAG #이상거래탐지

🟦 금융권 하둡(Hadoop) 아키텍처 시리즈 (전 10편)

1. 1편 — 금융권은 왜 하둡을 쓰는가: 도입 배경과 진화 (현재 글)
2. 2편 — 하둡 구성도: HDFS·YARN·Hive·Spark 운영 흐름
3. 3편 — 운영 자동화 스크립트 모음 (금융권 표준)
4. 4편 — 하둡 보안 아키텍처: 계정·권한·감사·데이터 보호
5. 5편 — Job Template·배포 체계 표준화
6. 6편 — Hadoop + Kafka 실시간 분석 아키텍처
7. 7편 — 클러스터 운영 체계: 폐쇄망·보안·권한 관리
8. 8편 — Sqoop·Oozie·Spark Batch 적재 파이프라인
9. 9편 — 실사용 ①: 신용평가 / 여신 리스크 모델링
10. 10편 — 실사용 ②: FDS 이상거래탐지 로그 분석