비즈니스 당좌계좌를 부기 앱에 연결하면 거래 내역이 자동으로 흘러 들어오기 시작합니다. 당신이 좀처럼 보지 못하는 것은 그 중간에 있는 회사 — 당신을 대신해 은행에 로그인하고, 거래 내역을 가져와 정리한 뒤 앱에 넘겨주는 데이터 애그리게이터입니다. 피드가 끊기거나, 구매 내역의 절반이 잘못 분류되거나, 일주일치 활동이 조용히 누락될 때 문제는 보통 당신의 앱이 아니라 그 중간 계층에 있습니다.
미국에서 이 데이터의 대부분을 움직이는 회사는 세 곳입니다: Plaid, MX, 그리고 Finicity(2020년부터 Mastercard 소유). 소규모 사업을 운영한다면, 회계 소프트웨어를 고른 순간 이미 이들 중 하나를 선택한 것입니다 — 그리고 은행 피드가 계속 말썽을 부린다면, 각 애그리게이터의 장단점을 이해하는 것이 앱을 바꾸는 게 도움이 될지, 아니면 같은 문제를 새 화면으로 옮기는 것에 불과한지를 알려줄 것입니다.
은행 데이터 애그리게이터는 실제로 무엇을 하는가
회계 앱에서 "은행 연결"을 클릭하면 일련의 사건이 시작됩니다:
- 인증. 은행 자격 증명을 입력하거나(또는 은행에서 OAuth 리디렉션을 승인)합니다. 애그리게이터는 당신의 계좌에 연결된 연결을 설정합니다.
- 검색. 애그리게이터가 잔액과 거래 내역을 가져옵니다 — 이상적으로는 은행의 직접 API를 통해, 때로는 브라우저처럼 온라인 뱅킹에 로그인하여.
- 보강.
SQ *COFFEE SHOP 000123같은 원시 은행 설명이 정리되어 가맹점 이름, 카테고리, 때로는 위치 정보로 변환됩니다. - 전달. 회계 앱이 애그리게이터의 API를 통해 정규화된 데이터를 받습니다.
2단계와 3단계에서 세 제공업체의 차이가 가장 크게 드러납니다. 검색은 어떤 은행이 연결되는지, 피드가 얼마나 자주 끊기는지를 결정합니다. 보강은 당신의 부기가 깔끔한 카테고리에서 시작할지, 아니면 손수 고쳐야 할 "미분류" 거래 더미에서 시작할지를 결정합니다.
이것이 예전보다 더 중요한 이유
수년 동안 애그리게이터는 주로 화면 스크래핑으로 데이터를 얻었습니다: 저장된 자격 증명으로 온라인 뱅킹에 로그인하여 페이지를 읽는 방식입니다. 작동은 했지만 취약했습니다 — 은행 웹사이트가 개편될 때마다 연결이 끊겼고 — 비밀번호가 다른 사람의 서버에 저장된다는 의미이기도 했습니다.
업계는 10년째 직접적인 토큰 기반 API 연결로 전환해 왔고, 이제 규제가 이 문제를 강제하고 있습니다. Dodd-Frank 법 Section 1033에 따른 소비자금융보호국(CFPB)의 오픈 뱅킹 규칙은 소비자에게 은행이 안전한 인터페이스를 통해 승인된 제3자와 데이터를 공유하도록 지시할 공식적 권리를 부여하여, 사실상 화면 스크래핑을 폐지하게 됩니다. 2024년 원래 규칙은 법정에서 차단되었고 수정 제안은 2026년 8월 백악관 검토에 들어갔으므로, 최종 형태는 아직 불확실합니다 — 하지만 방향은 한쪽입니다. 은행과 애그리게이터 간의 직접 협약과 Financial Data Exchange(FDX) 표준은 이미 대형 은행 연결 대부분이 작동하는 방식입니다.
사업주인 당신에게 이 전환은 두 가지 실질적 결과를 가져옵니다. 첫째, 대형 은행 연결은 일반적으로 5년 전보다 더 안정적입니다. OAuth 기반 API 링크가 스크래핑보다 덜 끊기기 때문입니다. 둘째, 소형 은행과 신용협동조합 — 현대적 API를 갖출 가능성이 가장 낮은 곳 — 의 연결이 바로 피드가 여전히 실패하는 지점이며, 애그리게이터 커버리지 차이가 드러나는 곳도 바로 여기입니다.
세 애그리게이터, 나란히 비교
Plaid: 가장 넓은 개발자 입지를 가진 기본 선택
Plaid는 아마 본 적이 있을 이름입니다 — 예산 관리 도구부터 결제 서비스까지 수천 개의 앱 안에 그 연결 화면이 나타납니다. 12,000개 이상의 금융 기관과의 연결을 문서화하고 있으며 개발자 경험으로 유명합니다: 명확한 문서, 빠른 통합, 그리고 "은행 데이터가 필요하다"에서 작동하는 제품까지 가장 빠른 경로.
이러한 폭넓음 덕분에 Plaid는 가능한 한 많은 다양한 은행을 연결하는 것이 우선순위일 때 가장 안전한 기본 선택입니다. 사업체가 특이한 곳 — 지역 은행, 틈새 온라인 은행 — 에 계좌를 두고 있다면, Plaid가 이미 지원할 가능성이 가장 높은 애그리게이터인 경우가 많습니다.
단점은 규모가 커질수록 드러납니다. 제3자 분석에 따르면 Plaid의 가격은 성공적인 연결당 약 $0.50에서 $2.00이며, 더 높은 등급에서 볼륨 할인이 적용됩니다 — 소규모 앱에는 친화적이지만 대규모 앱에는 진정한 비용 부담이 되는 모델입니다. 그리고 Plaid의 보강은 견고하지만, 일반적으로 최고 수준이 아니라 우수한 수준으로 평가됩니다: 가맹점 이름과 카테고리는 대개 정확하지만, 지저분하고 거래량이 많은 비즈니스는 종종 그 분류에 MX보다 더 많은 수동 수정이 필요하다고 느낍니다.
MX: 커뮤니티 은행에 뿌리를 둔 분류 전문가
MX는 지역 은행과 신용협동조합을 직접 지원하는 데서 성장했으며, 그 유산이 지금도 MX를 형성합니다. 15,000에서 16,000 범위의 연결 수를 발표하며, 특히 소규모 기관에서 강점을 보입니다 — 바로 Plaid 연결이 얇을 수 있고 Finicity의 기업 중심 접근이 덜 드러나는 롱테일에서요.
MX의 두드러진 기능은 데이터 보강입니다. 그 분류 엔진은 세 곳 중 가장 강력하다고 널리 평가받습니다: 더 깔끔한 가맹점 식별, 더 일관된 카테고리, 모호한 거래의 더 나은 처리. 회계 앱을 열었을 때 수십 건의 거래가 "기타"나 "미분류"에 쏟아져 있는 것을 본 적이 있다면, 약한 보강의 비용을 느낀 것입니다 — 그 하나하나가 월말에 당신의 1분입니다. MX의 주장은 당신의 거래 중 그곳에 떨어지는 것이 더 적다는 것입니다.
문제는 접근성입니다. MX는 주로 은행과 대형 핀테크를 대상으로 한 기업 계약을 통해 판매하므로, 소규모 사업주인 당신은 MX를 직접 선택하는 경우가 드뭅니다 — 회계 앱이나 은행 앱이 선택했기 때문에 받는 것입니다. 가격은 공개되지 않고 협상되므로 일대일 비용 비교가 어렵습니다. 그리고 미국 외 지역에서는 커버리지가 얇습니다.
Finicity: Mastercard의 검증 강자
2020년 Mastercard에 인수된 Finicity는 비슷한 15,000개 이상의 기관을 커버하며 대출 및 검증 워크플로에서 가장 강력한 위치를 차지합니다. 소득 및 자산 검증을 위한 구조화된 출력은 모기지 및 언더라이팅 프로세스에 직접 연결되며, Fannie Mae와 Freddie Mac의 승인이 실질적인 무게를 지닙니다. 최근 사업 대출이나 모기지를 신청하면서 명세서를 업로드하는 대신 "계좌를 디지털로 검증하라"는 요청을 받았다면, Finicity가 그 데이터를 옮겼을 가능성이 높습니다.
Mastercard의 지원을 받는 Finicity는 주요 은행과의 직접 데이터 공유 협약에서도 가장 깊은 기반을 갖추고 있어 대형 은행 연결이 안정적인 경향이 있습니다. MX처럼 협상된 기업 계약을 통해 판매하며, MX처럼 주로 미국 이야기입니다.
Finicity가 덜 차별화되는 부분은 일상 부기를 위한 범용 거래 보강입니다. 유능하지만, 누군가 Finicity를 선택하는 이유는 아닙니다 — 검증이 많은 워크플로를 위해 Finicity를 선택하며, 부기 피드는 따라오는 것입니다.
솔직한 비교 표
| 차원 | Plaid | MX | Finicity (Mastercard) |
|---|---|---|---|
| 공개된 기관 수 | 12,000+ | 15,000–16,000 | 15,000–16,000 |
| 소형 은행 / 신용협동조합 깊이 | 양호 | 가장 강함 | 양호 |
| 거래 보강 품질 | 양호 | 최고 | 적절 |
| 소득 / 자산 검증 | 제공 | 제공 | 최고 (GSE 승인 보고서) |
| 가격 모델 | 연결당, 대략 $0.50–$2.00 | 협상된 기업 계약 | 협상된 기업 계약 |
| 미국 외 커버리지 | 캐나다 및 제한적 유럽 | 주로 미국 | 주로 미국 |
| 구매자 | 스타트업부터 대기업까지 | 은행, 대형 핀테크 | 대출 기관, 대형 핀테크 |
모든 기관 수는 회의적으로 받아들이세요: 각 제공업체는 "연결"과 "데이터 소스"를 다르게 계산하며, 어떤 총계도 당신의 은행이 안정적으로 연결되는지에 대해서는 아무것도 말해주지 않습니다. 중요한 유일한 커버리지 질문은 당신의 것입니다 — 결정하기 전에 은행 이름과 앱 이름을 함께 검색하고, 연결은 변하기 때문에 최근 보고서를 확인하세요.
안정성: 피드가 끊기는 이유 (그리고 누구의 잘못인가)
은행 피드 실패는 세 가지 범주에 속하며, 그중 하나만 당신의 앱 잘못입니다:
- 연결 끊김. 은행이 로그인 흐름을 바꾸거나, 다단계 인증을 추가하거나, API를 교체하면 애그리게이터의 링크가 끊어집니다. "은행을 다시 연결하세요" 프롬프트가 뜹니다. OAuth 기반 API 연결은 자격 증명 기반 연결보다 훨씬 덜 끊기며, 이것이 대형 은행의 피드가 조용히 개선된 이유입니다.
- 누락 또는 중복 거래. 연결은 작동하지만 데이터가 잘못됩니다: 승인 후 확정되지 않은 대기 중 청구, 도착하지 않은 주말 활동, 또는 동일한 지급금이 두 번 가져와진 경우. 이것은 애그리게이터 검색 문제이며, 발견하기 가장 어렵습니다 — 아무 오류도 나지 않고, 당신의 장부만 틀립니다.
- 잘못된 분류. 거래는 도착하지만 잘못된 계정에 떨어집니다. 이것은 보강 문제이며, 일상 사용에서 MX의 우위가 가장 잘 드러나는 곳입니다.
사용자들이 앱이 "내 은행에 계속 연결되지 않는다"고 불평할 때, 근본 원인은 보통 애그리게이터 계층의 범주 1입니다 — 이것이 일부 앱이 이제 설정 안에서 동일한 은행에 대해 애그리게이터를 전환하도록 허용하는 이유입니다. 앱이 하나의 연결에 대해 Plaid, MX, Finicity를 상호 교환 가능한 제공업체로 제공한다면, 앱을 탓하기 전에 다른 것을 시도해 보세요. 다른 애그리게이터가 실제로 당신의 기관과 더 나은 연결을 유지할 수 있습니다.
가격: 청구서를 보지 못한 채 지불하는 것
소규모 사업체가 애그리게이터에 직접 지불하는 경우는 거의 없습니다. 비용은 회계 소프트웨어 구독 안에 묶여 도착합니다 — 이것이 "어느 애그리게이터가 가장 저렴한가"가 당신에게 잘못된 질문인 이유입니다. 올바른 질문은 가격 모델이 당신의 벤더에게 무엇을 하도록 유인하는가입니다.
연결당 가격(Plad의 공개 모델)은 연결이 설정되거나 갱신될 때마다 앱 벤더에게 비용을 청구하므로, 이 모델을 쓰는 벤더는 피드를 덜 자주 갱신하거나 저렴한 요금제에서 연결할 수 있는 계좌 수를 제한하려는 은근한 유인을 갖습니다. 기업 계약(MX와 Finicity의 세계)은 플랫폼 요금과 사용량을 묶으므로, 벤더를 계좌별 제한보다 전반적으로 더 높은 구독 등급으로 밀어붙이는 경향이 있습니다.
어느 쪽이든 당신이 지불합니다. 다른 것은 비용이 드러나는 곳입니다: 한 모델에서는 연결 한도와 갱신 빈도, 다른 모델에서는 더 높은 기본 가격. 회계 요금제를 비교할 때 "은행 계좌를 몇 개 연결할 수 있고, 피드는 얼마나 자주 갱신되는가"가 "어떤 애그리게이터를 쓰는가"보다 더 유용한 질문입니다 — 하지만 이제 답이 왜 다른지 알 것입니다.
이것이 당신의 장부에 의미하는 것
자동 피드에 관한 불편한 진실은 이것입니다: 그것들은 가져오기 파이프라인이지, 부기 담당자가 아닙니다. 모든 거래는 재무 기록의 일부가 되기 전에 여전히 한 번 더 검토되어야 합니다. 위의 실패 모드들이 조용히 일어나기 때문입니다. 사업주의 인출금을 사업 접대비로 잘못 분류하는 피드는 오류를 일으키지 않습니다 — 누군가 알아차릴 때까지 조용히 당신의 공제액을 과대 계상할 뿐입니다.
실질적인 루틴은 월말의 허둥대기가 아니라 주간 검토입니다:
- 미분류와 신뢰도가 낮은 항목을 먼저 훑어보세요. 대부분의 앱은 애그리게이터가 확신하지 못한 것을 표시합니다. 구매 기억이 아직 생생할 때 매주 이들을 정리하세요.
- 피드가 아니라 은행 잔액과 대사하세요. 월말 점검은 "내 원장이 명세서와 일치하는가"이지, 결코 "피드가 모든 것을 가져왔는가"가 아닙니다. 명세서가 권위이고, 피드는 편의입니다.
- 재연결 시 중복을 주시하세요. 은행을 다시 연결할 때마다 겹치는 구간을 확인하세요. 재연결된 피드는 이중 계산된 거래의 최대 원인입니다.
장부를 평문으로 유지한다면 같은 원칙이 적용됩니다 — 피드 출력은 당신이 검토하는 초안 항목이 되며, 당신이 받아들이는 진실이 아닙니다. 예를 들어 수수료를 포함한 동기화된 지급금은 순 입금액이 아니라 그 구성 요소들로 원장에 기록되어야 합니다:
2026-10-15 * "Shopify payout #4821" "Oct 12-14 sales, fees split out"
Assets:Checking:Business 1,842.36 USD
Expenses:Fees:Payment-Processing 58.14 USD
Income:Sales -1,900.50 USD순 입금액을 수익으로 기록하는 대신 총 매출과 수수료를 별도로 기록하는 것이 수익 수치를 정직하게 유지하고 세금 신고 시 수수료 비용을 가시화하는 방법입니다. 어떤 소프트웨어를 쓰든, 피드가 총액과 수수료를 분리할 충분한 세부 정보를 제공하도록 요구하세요; 순 입금액만 가져오는 피드는 세금 신고에 필요한 정보를 숨기고 있습니다. Beancount 문서에서 거래 구조를 자세히 다루며, Fava는 가져온 항목이 장부에 정착하기 전에 검토하는 것을 간단하게 만듭니다.
선택하는 방법 (또는 이미 가진 것을 판단하는 방법)
당신은 아마 애그리게이터를 직접 고르지 않을 것입니다 — 회계 소프트웨어를 고를 것이고, 애그리게이터는 따라옵니다. 그러니 비교를 구매 질문으로 번역하세요:
- 어디에 계좌를 두고 있나요? 상위 20개 은행이라면 세 곳 모두 잘 연결됩니다; 보강과 앱 기능으로 선택하세요. 소형 은행이나 신용협동조합이라면, 벤더에게 어떤 애그리게이터가 당신의 기관을 처리하는지, 그리고 연결이 어떻게 인증되는지(OAuth가 저장된 자격 증명보다 낫습니다) 물어보세요.
- 거래가 얼마나 지저분한가요? 거래량이 많고, 비슷한 가맹점이 많고, 현금 지출이 많은 경우 — 보강 품질이 더 중요하며, MX 기반 앱에 유리합니다.
- 대출을 받나요? 워크플로에 대출 신청과 소득 검증이 포함된다면 Finicity 기반 경로가 그 단계를 더 원활하게 만들 수 있습니다.
- 앱 안에서 제공업체를 전환할 수 있나요? 연결별 전환이 가능한 다중 애그리게이터 지원은 앱이 제공할 수 있는 단일 최고의 안정성 기능입니다. 이름을 대고 요구하세요.
그리고 오픈 뱅킹 규칙 제정을 계속 주시하세요. Section 1033이 어떤 최종 형태를 취하든, 표준화된 은행 API는 취약한 자격 증명 기반 링크를 계속 대체할 것입니다 — 즉 대형 기관과 소형 기관 사이의 커버리지 격차가 주시할 대상입니다. 당신의 피드는 대형 은행에서 먼저 계속 더 안정적으로 될 것입니다. 소형 은행에 계좌를 두고 있다면, 커뮤니티 은행에 가장 깊은 뿌리를 둔 애그리게이터가 여전히 당신의 연결을 살려둘 가능성이 가장 높은 곳입니다.
