금융 데이터 연동이라는 늪
회계 자동화, 경비 관리, 대출 심사, 세금 신고. 금융 데이터가 필요한 서비스는 셀 수 없이 많다. 그런데 정작 그 데이터를 가져오려고 하면, 대부분의 팀이 같은 늪에 빠진다.
은행마다 인증 방식이 다르다. 카드사마다 응답 포맷이 다르다. 홈택스는 자기만의 세계를 구축하고 있다. 겨우 연동에 성공해도, 기관 인터페이스가 예고 없이 바뀌면 새벽에 장애 알림이 울린다. 3개월에서 6개월을 연동에 쏟고도 유지보수에 허덕이는 팀을 수없이 봐왔다. 우리도 그중 하나였다.
우리가 이 문제를 풀 수밖에 없었던 이유
볼타를 운영하면서 우리는 수십억 건의 비정형 거래내역을 수집하고, 정규화하고, 서비스에 연결해왔다. "카드매출내역"이라는 단순해 보이는 데이터 하나만 해도, 기관마다 필드명이 다르고 날짜 포맷이 다르고 금액의 부호 규칙이 전부 다르다. 이걸 일관된 형태로 만드는 건 기술이라기보다 노하우다. 문서에 적혀 있지 않은, 실전에서만 쌓이는 종류의 경험.
에러 핸들링도 마찬가지다. 기관마다 에러 코드가 다르고, 장애 패턴이 다르고, 대응 방법이 다르다. 어떤 기관은 타임아웃 직전에 응답을 주고, 어떤 기관은 성공 코드와 함께 빈 데이터를 내려보낸다. 이런 것들을 일일이 학습하고 대응하는 건, 어떤 팀이든 쉽지 않은 일이다.
그리고 확신하게 됐다. 이 인프라를 모든 팀이 매번 새로 만드는 건 낭비라는 것을.
Headless Finance Platform — 우리의 답
그래서 만들었다. 헤드리스(Headless Finance Platform). 금융 데이터 수집의 복잡성을 추상화하고, 하나의 API로 제공하는 플랫폼이다.
78개 금융기관. 은행, 카드사, 홈택스를 아우른다. 31개 데이터 액션. 계좌 조회부터 세금계산서 다운로드까지. 12개 표준 스키마. 어떤 기관에서 가져오든 동일한 형태의 데이터.
워크플로우는 세 단계로 이루어진다.
첫째, 연결(Connect). 인증 정보를 등록하고 커넥터를 설정한다. 기관별로 천차만별인 인증 방식을 하나의 인터페이스로 추상화했다.
둘째, 수집(Collect). API 한 줄로 데이터를 수집한다. 대용량 데이터는 자동으로 청킹되고, 실패하면 자동으로 재시도한다.
셋째, 정규화(Normalize). 어떤 기관의 데이터든 동일한 표준 스키마로 변환된다. 원본 내역은 그대로 보존하면서, AI가 가맹점명의 브랜드와 카테고리를 자동으로 매핑해준다.
스크래핑이라는 구조적 딜레마
잠깐, 한 발 물러서서 생각해보자. 지금까지 대부분의 팀이 금융 데이터를 가져오던 방식은 스크래핑이다. 그리고 스크래핑에는 기술적 난이도 이전에, 더 근본적인 문제가 있다.
스크래핑으로 금융기관 데이터를 수집하려면, 사용자의 인증서 정보를 개발팀이 직접 보유해야 한다. 공동인증서든, 금융인증서든, 그 인증서는 단순한 로그인 수단이 아니다. 계좌 조회, 이체, 거래 — 금융 행위 전반에 대한 권한 그 자체다. 그걸 외부 개발팀에 넘긴다는 건, 금고 열쇠를 복사해서 건네는 것과 다르지 않다.
문제는 여기서 끝나지 않는다. 서비스가 성장하면 인증서를 보관하는 주체가 늘어난다. 개발 서버, 스테이징 환경, 배포 파이프라인, 로그 시스템. 보관 지점이 하나 늘어날 때마다 유출 표면(attack surface)이 함께 넓어진다. 인증서 하나가 탈취되면 조회가 아니라 실제 거래까지 가능하다는 점에서, 이건 단순한 데이터 유출과 차원이 다른 리스크다.
그래서 많은 팀이 딜레마에 빠진다. 금융 데이터가 필요하니까 스크래핑을 해야 하는데, 스크래핑을 하려면 인증서를 맡겨야 하고, 인증서를 맡기는 순간 보안 책임의 무게가 감당하기 어려운 수준으로 커진다. 규모가 작을 땐 눈 감을 수 있지만, 고객이 늘어나고 감사가 들어오는 순간 이 구조는 지속 불가능해진다.
기존 방식과 뭐가 다른가
핵심은 메타데이터 드리븐 아키텍처다. 새로운 금융기관을 추가할 때 코드를 한 줄도 고치지 않는다. 데이터베이스에 메타데이터를 넣는 것만으로 즉시 지원된다. 78개 기관이 동일한 스펙으로 동작하는 이유가 여기에 있다. 5개의 범용 핸들러가 모든 기관의 요청을 처리한다.
기관 인터페이스가 변경되면 플랫폼이 자동으로 대응한다. 여러분의 새벽 잠을 깨우는 건 우리의 일이지, 여러분의 일이 아니다.
보안은 기능이 아니라 전제다. 앞서 말한 스크래핑의 딜레마 — 인증서를 개발팀이 직접 들고 있어야 하는 구조 — 를 헤드리스는 근본적으로 다른 방식으로 해결한다. 인증 정보는 격리된 보안 환경에서만 사용되고, 고객사의 코드나 서버에 인증서가 노출되지 않는다. 모든 민감 데이터는 AES-256으로 암호화되며, Live 환경과 Sandbox 환경은 완전히 분리되어 있다. 인증서를 맡기는 것이 아니라, 인증서가 필요 없는 구조를 만든 것이다.
5분이면 시작할 수 있다
curl 한 줄이면 된다. 좀 더 편하게 쓰고 싶다면 Node.js, Python, Java, Kotlin, Go SDK를 제공한다. 콘솔에서 직접 테스트할 수도 있고, API로 자동화할 수도 있다. 같은 엔드포인트, 같은 스키마. 테스트에서 프로덕션까지 달라지는 건 없다.
연동 방식도 강제하지 않는다. 동기 HTTP로 즉시 응답을 받을 수도 있고, 비동기 HTTP로 폴링하거나 웹훅 콜백을 받을 수도 있다. 대량 처리가 필요하다면 SQS나 Kafka 같은 메시지 큐 기반 연동도 지원한다. 시스템 아키텍처에 맞는 인터페이스를 고르면 된다. 플랫폼이 거기에 맞춰준다.
사람이 아니라 AI가 먼저 이해하는 API
우리는 API를 설계할 때 한 가지를 더 기준으로 삼았다. 사람이 읽기 좋은 API는, AI 에이전트도 읽기 좋아야 한다는 것.
12개의 표준 스키마, 일관된 엔드포인트, 예측 가능한 응답 구조. 이 원칙들은 개발자의 인지 부하를 줄이기 위해 만든 것이지만, 동시에 AI 에이전트가 별도의 학습 없이 API를 이해하고 호출할 수 있는 조건이기도 하다. 실제로 Claude Code 같은 AI 코딩 에이전트에게 헤드리스 API 문서를 넘기면, 연동 코드를 스스로 작성한다. 기관별 분기도, 스키마 변환도 필요 없으니까.
이것은 부가 기능이 아니다. 우리가 처음부터 추구해온 표준화와 추상화의 자연스러운 귀결이다. 잘 정돈된 인터페이스는 사람에게든 기계에게든 같은 방식으로 작동한다. 학습 곡선이 5분이 아니라, 경우에 따라서는 0에 수렴할 수 있다는 뜻이다.
같이 만들어가고 싶습니다
현재 헤드리스는 Invite Only로 운영하고 있다. 소수의 팀과 함께 시작하며, 피드백을 통해 다듬어갈 것이다. 완성된 제품을 내놓겠다는 것이 아니라, 함께 만들어가겠다는 선언이다.
금융 데이터가 필요한 서비스를 만들고 있다면, 더 이상 인프라에 시간을 쏟지 않아도 된다. 수십억 건의 데이터를 다루며 쌓아온 경험 위에서, 당신의 제품에만 집중할 수 있도록. 그것이 우리가 헤드리스를 만든 이유다.
초대를 요청하려면 h6s.ai를 방문해주세요.