7편. 금융권 하둡 클러스터 운영 체계 – 내부망·보안·권한 관리 완전 가이드

7편. 금융권 하둡 클러스터 운영 체계 – 내부망·보안·권한 관리 완전 가이드

은행/금융사 실제 구축·운영 경험 기반

금융권의 Hadoop은 단순히 대용량 분석 플랫폼이 아니다.
사실상 보안 규제를 통과하기 위해 설계된 '통제형 빅데이터 플랫폼'에 가깝다.

인터넷 기업이나 스타트업의 Hadoop 운영 방식과는 구조도, 운영 방식도 완전히 다르다.
이 글에서는 실제 금융권 프로젝트(은행·카드사·공공금융 포함)에서 경험한 운영 체계를 중심으로 실전 위주로 정리했다.

---

■ 1) 금융권 Hadoop 환경의 절대 명제: “보안이 우선이다.”

금융권에서 빅데이터를 다룬다는 것은 곧 보안감사 대상 1순위가 된다는 뜻이다.
다른 산업과 크게 다른 이유도 바로 여기에 있다.

✔️ 금융권 Hadoop의 필수 요구사항

분야 요구사항

망 보안	외부망 완전 차단, 내부망 3계층 구성
인증	Kerberos + AD 연동 필수
권한	Ranger 기반 테이블/컬럼 레벨 통제
로깅	모든 쿼리·API 접근 기록
실행 환경	Yarn Queue 기반 CPU/MEM 분리
데이터	개인정보 마스킹 + 접근 최소화 원칙

즉, “빅데이터 플랫폼”이라기보다 통제된 보안 시스템에 가까운 형태다.

금융감독원, 금융보안원, 내부감사, 외부감사 등에서
Hadoop 관련 점검 목록이 수십 가지 나오기 때문에 설계 단계부터 보안 중심 아키텍처를 고려해야 한다.

---

■ 2) 금융권 Hadoop 운영 실제 구조 (실제 프로젝트 예시 기반)

금융권에서 가장 많이 등장하는 구조를 정리하면 다음과 같다.

---

🔵 1) 인증: AD + Kerberos 기반 통합 인증

금융권에서는 Linux 계정/로컬 계정 로그인은 절대 허용하지 않는다.

대부분 다음 구조를 채택한다.

[AD 계정 관리] → [Kerberos Realm] → [Hadoop 서비스 인증]

• 사용자는 AD 계정으로 로그인
• Hadoop·Spark·Hive는 Kerberos 토큰 기반 접근
• 배치 작업은 keytab 기반 자동 인증
• keytab은 사용자 홈 700 권한으로 제한

Kerberos가 불편해도 무조건 강제이기 때문에
Spark Submit, HDFS 명령어, Hive Query 모두 keytab으로 인증해야 한다.

---

🔵 2) 권한: Apache Ranger 기반 정교한 통제

금융권에서는 Hive 조회 권한 하나 만들기도 쉽지 않다.

Ranger 정책 예시

• 테이블 단위 권한 부여 (select/insert/update/delete)
• 컬럼 단위 접근 제어 (예: ‘주민번호’를 select 금지)
• 마스킹 규칙 적용
  • 주민번호: ******-*******
  • 휴대폰: 010-****-****
• LDAP 그룹 기반 자동 권한 부여

Ranger Audit 로그는 모든 접속을 기록하기 때문에
감사 시 “누가 어떤 테이블을 조회했는지” 즉시 추적 가능하다.

---

🔵 3) 네트워크: 내부망 3계층 구조

금융권 Hadoop 네트워크는 대략 아래 형태로 구성된다.

업무망  ←→  분석망  ←→  DMZ/API 구간 (제한적 허용)

• 외부 인터넷은 완전 차단
• 업무망과 분석망 간에도 포트 기준으로 제어
• REST API 호출은 거의 금지
• ODBC/JDBC만 허용되는 경우가 많음

Hadoop → 사내 WAS → 외부 서비스 형태의 연동은
대부분 망 분리 정책 때문에 매우 복잡하게 운영된다.

---

■ 3) 금융권 Yarn Queue 실제 운영 예시

실제 카드사/은행 프로젝트에서 운영하던 구성이다.

root
 ├── fds_team         (50%)
 ├── risk_modeling    (20%)
 ├── bi               (15%)
 └── sandbox          (15%)

운영 포인트

• FDS(Fraud Detection System)는 실시간성 요구로 최우선 자원 배정
• 리스크 모델링팀은 Spark ML 작업으로 CPU·메모리 많이 사용
• BI팀은 쿼리 중심, 자원 고정
• Sandbox는 분석가 개인 실험 공간

이 구조에서 FDS 자원 부족 → 실시간 탐지 지연 → CEO 보고 사안 발생.
그래서 금융권에서는 FDS Queue 비중을 가장 크게 설정한다.

---

■ 4) 금융권 Kerberos Spark Submit 실 사용 예

아래는 실제 은행의 리스크 모델 배치 실행 사례.

kinit -kt user.keytab user@COMPANY.CO.KR

spark-submit \
   --master yarn \
   --queue risk_modeling \
   --class com.bank.risk.ModelJob \
   risk-model.jar

특징

• Kerberos의 TGT(Ticket-Granting Ticket)을 받아야 Yarn이 작업을 허용
• keytab이 없으면 배치 실행조차 불가능
• HDFS 접근, Hive 접근 모두 Kerberos 토큰 필요

Spark Driver가 장시간 실행될 경우 토큰 만료 문제가 발생하는데,
이때는 Spark에서 Kerberos token renewal 옵션을 함께 사용한다.

---

■ 5) 운영 중 자주 발생하는 문제 & 해결 경험

금융권에서 Hadoop 운영하면서 가장 많이 겪는 문제 3가지 정리.

🔥 문제 1) Spark Job이 Kerberos 토큰 만료로 중단됨

원인: 배치 작업이 1시간 이상 실행되면 Kerberos TGT가 만료됨
해결: --principal, --keytab 옵션 추가해 자동 갱신

---

🔥 문제 2) Ranger Policy가 너무 많아져 충돌 발생

원인: 사용자 요청 들어올 때마다 정책 생성 → 수백 개 누적
해결: 팀 단위 정책 패키지(패턴) 미리 만들어 자동화

---

🔥 문제 3) Queue 100% 고정 비율 때문에 자원 낭비

예: FDS 팀 쉬는 날에도 CPU 50%가 고정됨 → 전체 성능 저하
해결: Capacity Scheduler의 elasticity 활성화 → 미사용 자원 반납

---

■ 실전 TIP 3개

🟢 ① Keytab 유출 방지 → 홈 디렉토리 700 설정 필수

chmod 700 /home/{user}

keytab 파일 유출시 계정 탈취 → 금융보안원 점검 1순위.

---

🟢 ② Ranger Policy는 패턴 기반으로 미리 설계해둘 것

• 팀별 그룹 권한 구조
• 컬럼 마스킹 규칙
• 테이블 CRUD 표준화

즉흥적 권한 생성 → 수백 개 정책으로 통제 불가 상태 발생.

---

🟢 ③ Yarn Queue는 절대 100% 고정 비율로 설정하지 말 것

Elasticity가 없으면
한 팀이 비활성일 때 자원이 묶여 전체 성능 저하.
Capacity Scheduler의 동적 자원 공유는 필수 설정.

---

■ 맺음말

금융권의 Hadoop 운영은 기술 공학이 아니라
보안·권한·감사·정책 준수의 총체적 운영 기술이다.

Hadoop을 단순히 “빅데이터 플랫폼”으로만 접근하면
금융권에서는 실패한다.

 

다음 편에서는
8편. 금융권 Hive/Spark 운영 자동화 – Shell/Python 기반 실전 스크립트 모음
을 다룬다.

🟦 금융권 하둡(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 이상거래탐지 로그 분석