은행이 데이터 플랫폼을 직접 지으면 돈은 세 곳으로 간다 — 토스뱅크 글에서 AI를 빼고 읽기

헤드라인

토스뱅크가 Data Platform Tribe를 소개한 글을 읽으면서 저는 문장을 두 색으로 나눠 읽었어요. 완료형과 계획형. "구현했어요", "검증도 마쳤어요"는 한 색, "개발 중이고", "계획이에요", "도전하고 있어요"는 다른 색. 채용 아티클이라 당연히 앞으로의 그림이 크게 그려져 있는데, 완료형만 남기면 글이 달라져요. 제목과 도입은 AX, 그러니까 AI 전환의 근간이 데이터라는 말로 시작하지만, 이 팀이 실제로 끝낸 일은 거의 전부 운영이에요. 저는 그게 실망스러운 게 아니라 정직하다고 봐요. 은행이 데이터 플랫폼을 직접 짓기로 하면 돈은 세 곳으로 가고, 이 글은 그 세 곳을 보여주는 드문 자료예요.

Data Platform Tribe의 데이터 흐름

첫 번째 자리: 장애가 나기 전에 막는 데

Data Platform 팀이 가장 집중하는 영역은 데이터센터 장애 예방이라고 못 박아요. 구체적으로는 HDFS가 기본으로 지원하지 않는 IDC 이중화를 위해 데이터 블록 배치 정책 구현체를 직접 개발했고, 로컬 IDC에 적용한 뒤 반대편 IDC로 백그라운드 복제를 돌려서 무중단 확장과 장애 시뮬레이션 검증까지 마쳤어요. 그다음 GSLB 전환과 함께 운영 클러스터 전체로 확장하는 건 계획이고요.

IDC 이중화 구조

이 대목이 제가 이 글에서 가장 높게 치는 부분이에요. 이유는 두 가지예요. 하나는 HDFS 블록 배치 정책을 직접 쓰는 건 파일시스템의 배치 로직에 손을 대는 일이라, 오픈소스를 "우리 환경에 맞게 쓴다"는 이 팀의 말이 구호가 아니라는 증거라서요. 다른 하나는 검증을 장애 시뮬레이션으로 했다는 점이에요. 이중화는 만드는 것보다 "반대편이 죽었을 때 정말 넘어가는가"를 확인하는 게 어렵고, 그걸 했다고 완료형으로 쓴 팀은 신뢰가 가요.

관측도 같은 자리에 있어요. 전 컴포넌트의 로그와 메트릭을 OTel Collector에서 Kafka를 거쳐 ClickHouse로 표준화하고, Grafana 셀프서비스 대시보드로 사용자 문의보다 먼저 장애를 보게 만들었어요. 같은 데이터를 장기 보관해서 추세 분석과 장비 증설 계획의 근거로 쓴다는 게 저는 더 눈에 들어와요. 관측 데이터를 알림에만 쓰는 팀은 많은데, 증설 근거로 쓰는 팀은 드물거든요. HDFS Small File 증가나 Iceberg 스냅샷 누적처럼 서서히 쌓이다 터지는 위험을 탐지 대상으로 잡은 것도 운영을 해본 사람의 목록이에요. 다만 그 위에 얹힌 "LLM 기반 원인 분석 리포트"는 얇은 층이에요. 실체는 표준화된 로그 파이프라인이고, LLM은 그 위에서 읽어주는 역할이죠.

두 번째 자리: 한 사람이 전체를 멈추지 못하게

공유 데이터 플랫폼의 첫 번째 장애는 하드웨어가 아니라 누군가의 무거운 쿼리예요. 이 팀은 그걸 여러 겹으로 막아요. Impala 안에서 배치·애드혹·BI를 어드미션 컨트롤 풀로 나누고, YARN과 Impala의 실행 기반을 멀티클러스터로 물리 분리하고, Spark와 Trino도 워크로드별 클러스터로 갈랐어요. 쿼리 리소스 사용을 자동으로 기록하고 Query Profile을 간소화해서, 어떤 대시보드가 무거운 작업의 원인인지 추적하는 매칭 테이블까지 뒀고요. 그 덕에 안 쓰는 대시보드를 정리하고 라이선스 관리를 자동화하는 데까지 이어졌다는 건, 격리 장치가 비용 절감 장치로도 작동했다는 뜻이에요.

Data Platform 팀의 두 개 층 구조

실시간 쪽도 같은 방식이에요. Real-Time Data 팀은 계정계·채널계에서 만들어진 데이터를 Hadoop까지 실시간으로 옮기는 흐름을 맡는데, 전사 Kafka Cluster와 Kafka Connect, Flink Cluster, ClickHouse DB를 IDC 안에서 오픈소스로 직접 운영해요. 앱 로그를 수집해 실시간으로 제공하고, 로그만으로 부족한 부분은 데이터베이스 변경 사항을 동기화하는 CDC 파이프라인으로 보완하고요. 이 흐름이 채권 추심에서 연체율을 낮추는 데 쓰인다는 건 완료형이고, 그 위에 올릴 실시간 초개인화 Product는 개발 중이에요. 여기서도 끝난 건 파이프라인이고, 앞에 있는 건 제품이죠.

여기서 이 팀이 진 부채도 같이 보여요. 자체 구축한 베어메탈 위에서 Hadoop 에코시스템이 저장과 쿼리를 맡고, Kubernetes 위에서 Airflow 3와 Hue, Zeppelin, 자체 Data Portal이 사용자 서비스를 맡는 두 개 층. 물리 서버 수백 대 규모이고, Hadoop, Hive, HBase, Impala, Kudu, Iceberg, Spark, Trino, Airflow 등 15종이 넘는 오픈소스를 직접 빌드해서 쓰고 필요한 패치는 최신 버전에서 백포팅해요. 저는 이걸 자유가 아니라 상시 부채로 읽어요. 15종을 직접 빌드한다는 건 15종의 보안 패치, 버전 호환, 담당자를 팀이 영원히 들고 간다는 뜻이거든요. 글이 말하지 않는 건 왜 이 길을 택했느냐예요. 은행의 망 분리와 규제 환경을 떠올리면 짐작은 가지만, 매니지드 서비스와의 비용·인력 비교는 어디에도 없어요. 격리와 관측에 이만큼 투자하는 건 그 부채를 상환하는 방식이고, 여섯 개로 흩어진 Airflow 클러스터를 Kubernetes 위 멀티테넌트 하나로 합치는 중이라는 것도 같은 맥락이에요.

세 번째 자리: 1원이 틀리면 안 되는 데

세 번째는 재무 데이터예요. Finance Data Platform 팀은 수익성분석(PA), 내부자금이전가격(FTP), 재무시뮬레이션(FSM), 생성형 AI 기반 재무 플랫폼을 맡는데, 핵심은 배부 결산이에요. 수억 건의 트랜잭션에서 배부 로직이 단 하나의 누락 없이 검증되고(Reconciliation), 장애가 나면 즉시 복구(Failover)되는 파이프라인. 활동기준원가로 조직·상품·고객 단위까지 1원 단위로 배부합니다.

이 팀의 채용 기준이 이 글에서 제일 정직한 문장이라고 봐요. 금융 도메인 경험을 강조하지 않고, 수억 건을 오차 없이 정해진 주기 안에 처리하고 실패 시 복구까지 고민해본 대용량 배치 경험이면 충분하다는 것. 커머스의 정산, 게임의 포인트, 제조의 원가처럼 정합성이 필수인 로직을 다뤄봤으면 더 좋다고요. 은행 데이터의 어려움이 금융 지식이 아니라 정합성 공학이라는 걸 채용 문장으로 인정한 셈이에요. 거버넌스 쪽도 같은 결이에요. OpenMetadata 위에 용어집을 만들고 동의어 중복을 막고 개인정보 등급과 마스킹 여부를 용어 단위로 관리하는 일. AI가 데이터를 이해하려면 테이블이 무슨 뜻인지부터 정리돼야 한다는 건 맞는 말이고, 그 정리는 지금 분류 체계를 확립하는 단계예요. 완료형이 아니라 진행형이죠.

정합성이 밖으로 드러나는 자리가 마트예요. Data Product Manager가 Bronze에서 Silver, Gold로 이어지는 메달리온 아키텍처 위에서 상품팀의 마트 스키마 표준과 오너십을 정리하는데, 사례로 든 게 인터넷은행 의무 공시 지표인 중저신용자 대출 비중을 매일 플래깅하는 마트, 그리고 KCB·NICE·Toss 신용점수를 결합해 각 팀이 같은 기준으로 리스크를 보게 만든 통합 고객 마트예요. 둘 다 "숫자가 팀마다 다르면 안 되는" 자리고, 공시 지표는 틀리면 규제 문제가 돼요. 이 팀이 정합성에 돈을 쓰는 이유가 여기서 구체화됩니다.

OpenMetadata 기반 거버넌스

AI를 빼고 남는 것

이제 계획형 문장을 모아볼게요. 실시간 초개인화 Product는 개발 중, AI-Driven Operations는 도전 중, Anomaly Detection과 Self-healing은 계획, 시맨틱 레이어는 목표. 제목이 AI로 시작하는 글에서 AI에 해당하는 문장은 하나도 완료형이 아니에요. 그리고 저는 이게 이 글의 흠이 아니라 은행 데이터 플랫폼의 정직한 모습이라고 봐요. 원장과 한 치의 오차 없이 흘러야 하는 데이터 위에서 AI를 얹는 순서는 이럴 수밖에 없어요. 이중화, 격리, 정합성이 먼저고, 그게 되고 나서야 그 위에 뭘 얹을지가 의미가 생기니까요.

아쉬운 건 결과 수치가 없다는 점이에요. 서버 수백 대, 오픈소스 15종, Airflow 6개를 1개로, 트랜잭션 수억 건, 1원 단위. 전부 규모의 숫자이고, 장애가 몇 번 줄었는지, 쿼리 대기가 얼마나 짧아졌는지, 이 구조에 몇 명이 붙어 있는지는 없어요. 채용 글이라 그렇겠지만, 이 세 자리에 투자한 팀이라면 그 숫자를 가장 자랑하고 싶었을 텐데요.

이 구조가 맞는 조직은 분명해요. 규제 때문에 매니지드 서비스를 못 쓰고, 데이터 한 건의 오차가 곧 사고인 곳. 그 조건이 아닌 팀이 이 글을 보고 15종을 직접 빌드하기 시작하면 부채만 남아요. 그리고 어느 쪽이든 이런 글은 완료형 문장만 따로 읽어보세요. 팀의 실력은 계획이 아니라 거기에 있어요.