마이데이터 2천만 사용자라는 숫자는 IR 자료에서 보면 멋지다. 그 데이터를 실제로 굴리는 엔지니어 입장에서는 완전히 다른 이야기가 된다.

카카오페이 마이데이터 플랫폼팀이 기술 블로그에 올린 글 하나가 눈에 들어왔다. 제목은 무난하게 "대용량 데이터 처리 개선"인데, 열어보면 꽤 날것의 전투 기록이 담겨 있다. 핵심은 이거다 — 데이터가 너무 커서 테이블 하나로 안 되니까 쪼갰고, 쪼개니까 통계를 못 뽑겠더라, 그래서 사내 쿼리 엔진을 붙여 해결했다.

세 가지가 동시에 터졌다

마이데이터 서비스가 성장하면서 병목 세 개가 한꺼번에 올라왔다.

QPS부터. 은행, 카드, 보험 — 여러 금융기관 데이터를 주기적으로 끌어오는 구조인데, 수집 트래픽이 DB에 직접 부하를 건다. 사용자 수천만이면 수집 주기마다 쿼리 폭탄이 터지는 셈이다.

저장 용량도 바닥을 쳤다. 금융 데이터는 법적 보존 의무가 걸려 있어서 "오래된 거 지우자"가 안 통한다. 쌓이기만 한다.

가장 치명적이었던 건 통계 배치다. 하루 한 번 돌아야 하는 잡이 하루 안에 안 끝나기 시작했다. 어제 기준 자산 현황을 오늘 아침에 보여줘야 하는데 배치가 아직 돌고 있으면, 그건 곧 서비스 장애다.

쪼개면 해결? 반만 맞다

대응의 첫 수는 교과서적이었다. 데이터를 분산 저장하고, 오래된 건 파일로 백업한다. created_at 기준으로 파티셔닝하고 콜드 데이터를 별도 스토리지로 넘긴다. 여기까진 대부분의 팀이 비슷하게 접근한다.

진짜 문제는 그 다음에 터진다. 분산된 데이터에서 통계를 어떻게 뽑느냐.

COUNT나 SUM 같은 건 부분 결과를 합산하면 되니까 그나마 낫다. 하지만 표준편차는? 전체 데이터를 한 번에 봐야만 계산 가능한 집계 함수다. 데이터가 세 군데에 흩어져 있는데 각각에서 부분 표준편차를 구해서 합칠 수는 없다. 수학적으로 불가능하다.

분산 시스템을 설계해 본 사람이면 안다. 나누는 건 쉽다. 나눈 걸 다시 하나처럼 보이게 만드는 게 진짜 난이도다.

Palsonic이라는 카드

여기서 등장한 게 Palsonic이다. 카카오페이 데이터팀이 만든 내부 쿼리 서비스로, 여러 데이터 소스를 연결해 결과를 단일 뷰로 보여준다. 일종의 가상 통합 레이어.

플랫폼팀은 이 도구를 통계 배치에 연결했다. 물리적으로 흩어진 테이블들이 논리적으로 하나로 묶이니, 기존 통계 로직을 크게 고칠 필요가 없었다. Spring Batch 쪽도 JDBC Driver 커넥션을 Palsonic 커넥션으로 교체하는 수준의 변경만으로 돌아갔다고 한다.

이 부분이 실무적으로 가장 중요하다. 레거시 배치를 대규모로 리팩터링하는 건 그 자체가 장애 리스크다. 최소한의 코드 변경으로 인프라를 교체한 건 영리한 선택이었다.

한국 핀테크가 공유하는 시한폭탄

이 사례를 단순히 "카카오페이의 성능 튜닝 이야기"로만 읽으면 절반을 놓친다.

한국의 마이데이터 사업자는 구조적으로 데이터 폭증을 피할 수 없다. 고객 금융 데이터를 수집할 의무와 보존할 의무를 동시에 지기 때문이다. 사용자가 늘어날수록 삭제 불가능한 데이터가 누적된다. 단일 RDB로 버틸 수 있는 한계점이 2025~2026년 사이에 집중적으로 도래하고 있고, 이건 카카오페이만의 문제가 아니다.

토스나 뱅크샐러드도 비슷한 시기에 아키텍처 재설계를 했거나 검토 중일 가능성이 높다. 흥미로운 건 접근법의 차이다. 외부 MPP 엔진을 도입할 수도 있고(Trino, Presto 계열), 클라우드 네이티브 분석 서비스를 쓸 수도 있다. 카카오페이는 자사 데이터팀의 기존 자산인 Palsonic을 재활용했다. 이미 사내에서 검증된 도구를 새 문제 영역에 적용한 것이니, 기술적 리스크를 줄이면서 도입 속도를 높이는 실리적 판단이다.

다만 기술 블로그에서 빠진 부분이 있다. Palsonic이 분산 쿼리의 정합성을 어떻게 보장하는지, 특정 데이터 소스가 응답하지 않을 때 부분 결과를 허용하는지 아니면 전체를 실패 처리하는지. 금융 데이터 통계에서 정합성 이슈는 꽤 민감한 영역인데, 이 부분은 후속 글을 기대해야 할 것 같다.

배치 = 서비스

"배치는 새벽에 돌려놓으면 되니까 좀 느려도 괜찮다." 이 말이 통하던 시절은 끝났다. 실시간 자산 조회, 일일 리포트, 신용 점수 갱신 — 배치 결과가 곧 사용자가 보는 화면이 된 지 오래다.

카카오페이 팀의 글에서 하나 배울 점이 있다면, 분산 전략과 통합 쿼리 레이어를 동시에 설계했다는 것이다. 쪼개는 것만 생각하고 다시 합치는 걸 나중으로 미루면, 나중에 훨씬 비싼 대가를 치른다.