중소기업용 소프트웨어를 위한 임베디드 금융 및 BaaS: 버티컬 SaaS가 결제, 대출, 카드 발급 기능을 추가하는 방법

레스토랑용 POS(판매 시점 관리) 플랫폼인 토스트(Toast)는 지난해 금융 서비스에서 약 50억 달러의 수익을 올렸습니다. 원래 판매 목적으로 구축된 소프트웨어 구독 수익은 9억 3,600만 달러였습니다. 이제 핀테크라는 꼬리가 SaaS라는 몸통보다 5배나 더 커진 셈입니다.

이러한 패턴은 버티컬 소프트웨어 전반에서 반복되고 있습니다. 쇼피파이(Shopify)의 머천트 솔루션은 매출의 73%를 차지합니다. 서비스타이탄(ServiceTitan)의 IPO 믹스는 구독 71%, 핀테크 25%였지만, 순 신규 매출을 주시하는 분석가들은 결제 부문이 소프트웨어 코어보다 빠르게 성장함에 따라 그 비중이 55:45로 수렴하고 있다고 보고 있습니다. 2026년에 시리즈 B 단계에 진입하는 버티컬 SaaS 기업에 있어 투자자들의 질문은 더 이상 결제를 임베드할 것인지가 아니라, 어떤 임베디드 금융 스택을 사용할 것이며 대출과 카드 발급을 얼마나 빨리 도입할 수 있는지입니다.

업계에서는 이를 임베디드 금융(Embedded Finance) — 비금융 소프트웨어 내부에서 제공되는 금융 상품 — 이라 부르며, 그 하부 구조(배관)를 **서비스형 뱅킹(BaaS, Banking-as-a-Service)**이라고 합니다. 기회는 실재합니다. 미국의 임베디드 금융 플랫폼 매출은 2021년 약 220억 달러에서 2026년 510억 달러로 성장할 것으로 예상되며, BaaS 시장은 2031년까지 17.8%의 연평균 성장률(CAGR)을 기록할 전망입니다. 하지만 이러한 기회 옆에는 시정 조치 요구(consent orders), 프로그램 중단, 감사 실패의 무덤이 존재합니다. 그곳에 빠진 대부분의 창업자들은 규제 당국이 지적하기 전까지 자신들이 은행과 유사한 비즈니스를 운영하고 있다는 사실조차 깨닫지 못했습니다.

이 가이드에서는 임베디드 금융의 실제 의미, 왜 버티컬 SaaS가 임베디드 금융의 자연스러운 터전인지, 2026년의 기술 스택은 어떤 모습인지, 공급업체를 선택하는 방법, 그리고 유망한 출시를 실존적 위기로 몰아넣는 컴플라이언스 함정에 대해 살펴봅니다.

"임베디드 금융"의 실제 의미

임베디드 금융은 겉보기에 금융 상품이 아닌 소프트웨어 내에서 제공되는 결제, 예금 계좌, 직불 카드, 대출, 보험, 급여 관리 등의 금융 상품을 일컫는 약어입니다. 계약업자가 고객으로부터 ACH(자동 이체) 결제를 받고, 그 현금을 하위 계좌에 보관하며, 미지급 송장을 담보로 즉시 선급금을 받을 수 있도록 해주는 건설 소프트웨어 플랫폼은 임베디드 금융을 수행하고 있는 것입니다. 수의사들이 소모품을 구매할 수 있도록 브랜드 직불 카드를 발급하는 동물병원 관리 시스템도 마찬가지입니다.

이러한 기능 대부분을 뒷받침하는 기술 엔진은 **서비스형 뱅킹(BaaS)**입니다. 규제를 받는 은행("스폰서 뱅크")이 자신의 라이선스, ACH 및 카드 네트워크 접근권, FDIC(미국 연방예금보험공사) 보험이 적용되는 원장을 핀테크 미들웨어 제공업체에 대여하고, 제공업체는 이를 일반 소프트웨어 기업이 호출할 수 있는 깔끔한 API로 노출합니다. 소프트웨어 기업은 은행업 라이선스를 직접 보유하지 않습니다. 그러나 세부 조항을 읽어보면 은행 운영과 매우 흡사한 긴 목록의 운영 및 컴플라이언스 책임을 떠안게 됩니다.

임베디드 금융 스택에서는 다음 세 가지 제품이 주를 이룹니다:

• 임베디드 결제(Embedded payments): SaaS 플랫폼의 최종 고객을 대신하여 카드 및 ACH 결제를 수락합니다. 이는 가장 배포하기 쉽고 수익 창출이 빠르며, 다른 모든 서비스의 기초가 되는 관문과도 같습니다.
• 임베디드 대출(Embedded lending): 미래 매출채권을 담보로 한 현금 선지급, 한도 대출(line-of-credit) 상품, 플랫폼의 자체 거래 데이터를 사용하여 심사된 기간 대출 등이 있습니다. 테이크 레이트(수수료율)와 순이자 마진이 결제보다 훨씬 높습니다.
• 카드 발급 및 계좌(Issued cards and accounts): 브랜드 직불 카드, 가상 카드 및 FDIC 보험이 적용되는 운영 계좌(현장 직원을 위한 "지출 카드", 긱 워커를 위한 "수익 계좌", 구매자를 위한 "매장 크레딧 카드") 등이 있습니다.

이러한 각 계층은 서로 결합되어 더 큰 효과를 냅니다. 각 단계마다 고객의 운전자본 흐름을 더 많이 포착하기 때문입니다.

버티컬 SaaS가 가진 압도적인 우위

수평적 결제 앱은 신용카드 결제를 단편적으로만 봅니다. 하지만 버티컬 SaaS 플랫폼은 그 결제를 발생시킨 계약서, 해당 계약에 할당된 노동 시간, 금요일까지 지불해야 하는 자재 송장, 동일 지역 내 모든 고객의 과거 계절성, 그리고 오버드래프트(당좌대월) 직전인 운영자의 은행 잔고 추이까지 모두 꿰뚫고 있습니다.

이러한 맥락(Context)이 바로 해자입니다. 이는 다음 세 가지를 동시에 변화시킵니다:

1. 언더라이팅(인수 심사) 비용이 저렴해지고 정확해집니다. 건설 SaaS 기업은 어떤 업체가 대금을 제때 지급받고, 어떤 업체가 항상 90일 치 미수금을 장부에 쌓아두는지 알고 있습니다. 이 덕분에 세무 신고서만 보는 은행의 일반적인 중소기업 대출보다 현금 선지급 상품의 리스크를 훨씬 더 잘 관리할 수 있습니다.
2. 유통 비용이 급감합니다. 고객은 이미 앱 내에 있습니다. 새로운 금융 상품을 위한 별도의 획득 퍼널이 필요 없습니다. 사용자가 이미 보고 있는 화면 안에 배너를 띄우면 됩니다. 업계 분석가들은 금융 상품을 성공적으로 임베드한 플랫폼이 고객당 매출을 3~4배까지 증대시키는 것으로 추정합니다.
3. 유지율(Retention)이 강화됩니다. 급여, 결제, 한도 대출이 귀하의 소프트웨어를 통해 처리되기 시작하면 전환 비용이 엄청나게 커집니다. 핀테크 계층은 월 99달러의 구독 서비스를 연간 5,000달러 가치의 금융 서비스 계좌로 탈바꿈시킵니다.

이것이 바로 버티컬 SaaS 핀테크 플레이북이 약 4년 만에 "실험적인 부업"에서 "시리즈 B 단계의 기본 계획"으로 자리 잡은 이유입니다.

2026 스택: 역할 분담

임베디드 금융 벤더 맵은 복잡하며 카테고리가 서로 중첩됩니다. 2026년 중소기업(SMB) 소프트웨어 팀이 가장 많이 최종 후보로 올리는 제공업체들에 대한 간략한 관점은 다음과 같습니다.

결제 처리 및 오케스트레이션

• Stripe Connect 및 Stripe Treasury. 개발자 우선의 기본 선택지입니다. 강력한 API, 우수한 문서화, 카드 수취부터 예치금 잔액 및 카드 발급에 이르기까지 폭넓은 범위를 제공합니다. 스택의 대부분을 단일 벤더로 해결하려는 팀에 가장 적합합니다.
• Adyen for Platforms. 거래량 기반 가격 책정을 제공하며 글로벌 시장에 강점이 있습니다. 처리 결제액이 5,000만 달러 이상인 경우 경제성이 더 좋지만, 온보딩이 느리고 소규모 프로그램에는 관대하지 않습니다.
• Finix 및 Payabli. "서비스형 PayFac(PayFac-as-a-Service)" — 플랫폼이 완전한 규제 대응 체계를 구축하지 않고도 결제 대행사(또는 그와 유사한 형태)가 될 수 있도록 지원합니다.

뱅킹 및 계좌 (BaaS 미들웨어)

• Unit. 고객 잔액을 보유하거나 브랜드 카드를 발급하려는 미국 SaaS 기업이 프로그램을 출시할 수 있는 가장 빠른 경로입니다. 제품은 강력하지만, 소수의 후원 은행(sponsor bank)과 밀접하게 결합되어 있습니다.
• Treasury Prime. 멀티 뱅크 API — 특정 후원사에 종속되지 않고 FDIC 통과 보험(pass-through insurance) 및 실시간 결제와 같은 은행 수준의 기능을 원할 때 유용합니다.
• Synctera. 규제 준수를 우선시하는 미들웨어로, 개발 초기 단계부터 BSA/AML 도구를 개발자 경험에 통합하려고 노력합니다.
• Column. 자체 API를 직접 노출하는 은행으로, 미들웨어 계층을 하나 제거합니다.

카드 발급

• Marqeta, Lithic, Highnote. 브랜드 직불, 선불, 그리고 점차 늘어나고 있는 신용 카드 프로그램을 위한 카드 발급 인프라입니다. Marqeta는 확장성이 뛰어나고, Lithic은 더 간결하고 개발자 친화적인 인터페이스를 원하는 팀에 적합하며, Highnote는 신용 및 소비자 제품에 특화되어 있습니다.

대출 및 자본

• Parafin, Kanmon, Liberis. 플랫폼의 거래 데이터를 사용하여 인수를 수행하고 대출 실행, 서비스 및 (경우에 따라) 대차대조표를 관리하는 임베디드 대출 API입니다.

원장 및 자금 이동

• Modern Treasury. 플랫폼 내부의 원장 인프라를 위한 표준 구현체입니다. Gusto나 Marqeta와 같은 기업들이 자금이 은행에 도달하기 전부터 자체 장부를 정확하게 유지하기 위해 사용합니다.
• Dwolla, Moov. ACH 중심의 프로그래밍 방식 자금 이동을 지원하며, 종종 카드 프로세서와 함께 사용됩니다.

대부분의 실제 운영 프로그램은 이들 중 3~4개를 조합합니다. 예를 들어, 부동산 관리 플랫폼은 카드 수취를 위해 Stripe를 사용하고, 임대인 수익 계좌를 위해 Unit을, 부동산 관리자용 브랜드 직불 카드를 위해 Marqeta를, 임대 수입 기반의 현금 선급을 위해 Parafin을 사용할 수 있습니다.

현실적인 단계별 계획

가장 흔한 실수는 결제, 대출, 카드를 하나의 대규모 릴리스로 동시에 출시하려는 것입니다. 그렇게 하지 마십시오. 각 계층의 규제 준수, 운영 및 경제적 복잡성은 본질적으로 다르며, 거의 모든 경우에 올바른 순서는 동일합니다.

1단계 — 결제 (0~6개월). 고객의 고객을 위한 카드 수취 기능을 추가하십시오. 이는 가장 위험이 낮고 거래량이 많은 계층입니다. 플랫폼이 모든 거래의 소액(일반적으로 30~100 베이시스 포인트)을 수익으로 얻을 수 있도록 통합을 구축하십시오. 이 단계를 통해 고객 온보딩, KYB(기업 확인 제도) 체크 및 사기 모니터링을 강화하십시오.

2단계 — 계좌 및 지출 (6~12개월). 결제가 안정화되면 고객이 플랫폼 내에 잔액을 보유하고, ACH 지급을 보내고, 특정 지출 카테고리를 위한 가상 카드를 발급하는 기능을 추가하십시오. 브랜드 직불 카드는 보통 첫 번째 카드 제품이 아니라 두 번째가 되어야 합니다.

3단계 — 신용 및 자본 (2년 차). 매출 채권 기반의 현금 선급이 먼저입니다. 이는 기간이 짧고 인수가 쉬우며 들어오는 결제 대금에서 자동으로 회수됩니다. 기간 대출(Term loans)과 신용 한도(Lines of credit)는 더 심도 있는 신용 관리, 추심 및 대손 상각 운영이 필요하기 때문에 나중에 도입합니다.

Bain & Company의 데이터에 따르면, 이 순서를 따르는 플랫폼은 단계를 건너뛰는 플랫폼보다 유의미하게 높은 테이크 레이트(take rate)와 낮은 대손 상각률을 보입니다. 대출의 단위당 경제성이 결제보다 훨씬 좋기 때문에 조기 출시 유혹이 강하지만, 4%의 대손 상각률을 흡수하는 데 필요한 운영 성숙도는 실제 상황이며 1년 차에는 거의 항상 부족합니다.

아무도 말하고 싶어 하지 않는 컴플라이언스의 함정

2024년 2월, FDIC(연방예금보험공사)는 BaaS 관련 안전성 및 건전성 우려(주로 은행 비밀법(BSA) 준수 및 제3자 감독 실패)로 인해 두 은행에 대해 동의 명령(consent orders)을 내렸습니다. Piermont Bank의 명령은 Treasury Prime과 Unit을 통해 운영되는 프로그램들에 영향을 미쳤습니다. Robinhood, Square, Upgrade를 포함한 핀테크 기업들과 협력하는 Sutton Bank도 유사한 조사 결과를 받았습니다. 2024년과 2025년 내내 더 많은 명령이 이어졌습니다. FDIC는 2025년 5월 한 달 동안에만 12건의 집행 명령을 보고했습니다. 통화감독청(OCC)도 국립은행 측에 유사한 조치를 내렸습니다.

후원 은행이 동의 명령을 받으면, 하위 플랫폼은 단순히 엄중한 경고 편지를 받는 데 그치지 않습니다. 프로그램이 동결되고, 신규 고객 온보딩이 중단되며, 경우에 따라 기존 잔액을 이동하기 어려워지기도 합니다. 단순한 "SaaS 기능"을 운영하고 있다고 생각했던 창업자들은 자신의 로드맵이 한 번도 만난 적 없는 규제 기관의 인질이 되었다는 사실을 갑자기 깨닫게 됩니다.

소프트웨어 기업들이 지속적으로 어려움을 겪는 몇 가지 구체적인 의무 사항은 다음과 같습니다.

• KYC 및 KYB (고객 확인 제도 / 기업 확인 제도). 잔액을 보유하거나 카드를 발급받거나 대출을 받는 모든 최종 사용자는 제품 팀이 충분하다고 생각하는 기준이 아니라, 후원 은행이 요구하는 기준에 따라 본인 확인을 거쳐야 합니다.
• 실소유주 확인 및 CIP. 기업 고객에게는 고객 식별 프로그램(CIP) 규칙이 적용되며, 25% 지분 보유 임계값에서 실소유주 정보를 수집하는 규칙은 문자 그대로 엄격하게 집행됩니다.
• 거래 모니터링 및 SAR 보고. 의심거래보고(SAR)는 선택 사항이 아닙니다. 보통 플랫폼이 1차 모니터링을 수행하고 후원 은행이 보고를 진행합니다. 모니터링이 부실하면 은행은 규제 타격을 입고 플랫폼은 계약 해지를 당하게 됩니다.
• 마케팅 및 공시. FDIC 보험, 이자 및 신용 조건에 대해 언급하는 내용은 규제 대상입니다. 별표(주석) 없이 "FDIC 보험 적용"이라고 표현하는 것은 다른 어떤 문구보다 많은 시정 명령(cease-and-desist)의 원인이 되었습니다.
• 민원 처리 및 규정 E (Reg E). 소비자 금융 제품은 분쟁 거래 처리에 대한 특정 기한을 포함하여 소비자 보호 의무를 수반합니다.

유용한 원칙 하나는 다음과 같습니다. 만약 해당 기능을 직접 수행할 때 라이선스가 필요하다면, 설령 제품 관리자가 그렇게 생각하지 않더라도 후원 은행의 컴플라이언스 팀은 그 기능을 라이선스가 필요한 업무로 취급하고 있다는 점입니다.

자체 구축, 구매 또는 파트너십 선택

세 가지 합리적인 경로가 있으며, 자본력, 규제 대응 의지, 그리고 금융 서비스가 장기 로드맵에서 얼마나 핵심적인 위치를 차지하는지에 따라 정답이 달라집니다.

순수 파트너 / 추천(Referral) 모델. 플랫폼이 고객을 금융 서비스 제공업체에 연결해주고 정액 수수료나 적은 수익 배분을 받는 방식입니다. 리스크가 가장 낮고 수익 잠재력도 가장 낮지만, 출시 속도가 가장 빠릅니다. 금융이 핵심 비즈니스가 아닌 인접 영역인 SaaS 기업에 적합합니다.

BaaS 미들웨어를 통한 임베디드 방식. 플랫폼이 고객에게는 금융 서비스 제공업체처럼 보이고 느껴지지만, 규제 대상 활동은 스폰서 은행과 미들웨어 파트너가 담당합니다. 대부분의 버티컬 SaaS 프로그램이 이 모델을 채택합니다. 유의미한 수수료율(Take rates)을 확보할 수 있고 규제 준수 부담도 실제 존재하며, 적당한 규모에서 유닛 이코노믹스(Unit economics)가 작동하기 시작합니다.

직접 인가, 면허 취득 또는 PayFac 등록. 소수의 플랫폼은 결국 송금업 면허를 취득하거나, 등록된 결제 대행업체(PayFac)가 되거나, 은행 인가를 추진합니다. 이 과정은 비용이 많이 들고 느리며, 프로그램이 수천만 달러의 금융 서비스 매출을 창출하고 미들웨어를 제거하여 절감하는 비용이 규제 준수 비용을 상회할 때만 의미가 있습니다.

간단한 테스트: 현재 또는 계획된 금융 서비스 매출이 연간 500만 달러 미만이라면 파트너십이나 미들웨어를 사용하세요. 500만 달러에서 5,000만 달러 사이라면 거의 항상 미들웨어가 유리합니다. 5,000만 달러를 초과하면 스택의 더 많은 부분을 내재화하는 데 드는 비용을 최소한 모델링해 보아야 합니다.

숫자 게임: 현실적인 경제성 지표

수익 구조는 제품별로 크게 다릅니다. 재무 계획을 세울 때 다음의 2026년 대략적인 벤치마크를 시작점으로 삼고, 귀하의 버티컬 영역에 맞게 조정하십시오:

• 카드 결제 수수료: 스폰서 은행과 미들웨어가 수수료를 가져간 후, 플랫폼에 남는 순수익은 처리 거래액의 30~100 베이시스 포인트(bps) 수준입니다.
• ACH(자동계좌이체): 수 센트에서 수 달러의 낮은 고정 수수료와 부가가치 거래 흐름에 대한 소액의 백분율 수수료율이 적용됩니다.
• 체크카드 / 지출 카드 발급: 일반적으로 카드 생산 및 프로그램 관리 비용을 제외하고 지출액의 50~100 베이시스 포인트가 플랫폼의 순이익으로 돌아오는 인터체인지 분할 방식입니다.
• 매출채권 담보 단기 자금 융통 (Cash advances): 실질 연이율(APR)은 3060% 범위이며, 심사가 잘 이루어진 자산 포트폴리오의 경우 대손 상각률은 26%입니다. 자본 비용 제외 후 순이익은 대출 실행액의 8~15%에 달할 수 있습니다.
• 기한부 대출 (Term lending): 연이율은 더 낮고 기간은 더 길며 운영 비용은 더 높습니다. 마진은 자본 비용과 추심 운영 능력에 크게 좌우됩니다.

특히 B2B 임베디드 ACH 결제의 경우, 업계 전망에 따르면 2026년까지 플랫폼들은 부가가치 서비스를 통해 약 40억 달러의 순매출을 거둘 것으로 예상되며, 임베디드 카드 거래 규모는 플랫폼 매출에 약 8억 달러를 더할 것입니다. 이러한 숫자가 가능한 이유는 결제 레일을 소유한 은행이 아니라, 고객 관계와 거래 맥락을 소유한 플랫폼이 그 수익을 가져가기 때문입니다.

피해야 할 다섯 가지 실수

실패하거나 난항을 겪는 프로그램들의 사후 분석에서 반복적으로 나타나는 패턴들입니다:

1. 규제 준수 인력을 확보하기 전에 구축부터 시작하는 것. 임베디드 금융 프로그램의 첫 번째 고용 대상은 엔지니어나 제품 관리자가 아닙니다. 실제 BSA/AML 경험이 있고, 가급적 스폰서 은행과의 관계 경험이 있는 사람이어야 합니다.
2. 스폰서 은행을 파트너가 아닌 단순 공급업체로 취급하는 것. 스폰서 은행의 규제 준수 팀은 귀사의 로드맵에 대해 실질적인 거부권을 행사할 수 있습니다. 반드시 그래야 할 상황이 아니더라도 초기 단계부터 그들을 참여시키세요.
3. "소규모" 고객에 대한 기업 고객 확인(KYB)을 건너뛰는 것. 소규모 고객이라고 예외는 없습니다. "우리가 잘 아는 고객"이라는 예외도 없습니다. 규칙은 모든 계좌 보유자에게 적용됩니다.
4. 대출을 위한 자본 비용을 과소평가하는 것. 단기 자금 융통의 순이자 마진은 스프레드시트상으로는 아름다워 보이지만, 신용 공여 시설(Credit facility) 비용, 대손 상각, 관리 비용, 그리고 실패한 코호트에 대한 주기적인 상각 비용을 더하는 순간 달라집니다.
5. 마케팅이 법무 검토보다 앞서 나가게 두는 것. 대부분의 소비자 금융 서비스 집행 조치는 광고 한 줄, 웹 페이지 하나, 또는 인앱 배너 하나에서 시작됩니다. 금융 상품의 마케팅 문구에는 반드시 검토 프로세스와 기록이 필요합니다.

텍스트 기반 회계(Plain-Text Accounting)가 필요한 이유

임베디드 금융은 문제가 발생하기 전까지는 거의 아무도 언급하지 않는 기술적 난제를 야기합니다. 바로 **원장 데이터의 폭증(Ledger explosion)**입니다. 모든 고객 잔액, 모든 카드 결제, 모든 지급, 모든 대출 실행, 모든 회수 및 모든 차지백(Chargeback)은 이제 은행 시스템뿐만 아니라 귀사의 시스템에서도 회계 이벤트가 됩니다. 스폰서 은행의 명세서, 카드 프로세서의 정산 파일, 대출 관리 서비스의 보고서와 귀사의 장부를 대조하여 종종 매일 조정(Reconciliation) 작업을 수행해야 합니다.

Modern Treasury와 같은 벤더가 존재하는 이유는 기존의 회계 원장이 자금 이동 속도를 따라가지 못하기 때문입니다. CFO가 인증해야 하는 귀사 자체의 내부 재무 장부에도 동일한 원칙이 적용됩니다. 금융 서비스가 플랫폼을 통해 흐르기 시작하면, 순수 SaaS 구독 모델이었을 때보다 원장의 투명성, 감사 추적(Audit trails), 외부 소스에 대한 스크립트 기반 조정 능력이 훨씬 더 중요해집니다.

귀사의 제품만큼 투명하게 회계 장부를 관리하세요

임베디드 금융은 소프트웨어 기업을 자금을 이동시키는 기업으로 변화시킵니다. 따라서 비즈니스의 근간이 되는 회계 시스템은 고객에게 제공하는 금융 제품만큼이나 뛰어나야 합니다. Beancount.io는 완전히 투명하고 스크립트 작성이 가능하며, 버전 관리가 가능한 텍스트 기반 회계를 제공합니다. 이는 핀테크 성격의 SaaS 기업들이 필요로 하는 고속 대조(reconciliation) 작업을 위해 구축되었습니다. 블랙박스나 벤더 종속이 전혀 없으며, 장부는 텍스트 파일에 저장되어 한 줄씩 직접 감사할 수 있습니다. 무료로 시작하기를 통해 금융 스택이 복잡해질수록 왜 많은 개발자와 재무 팀이 텍스트 기반 회계로 전환하고 있는지 확인해 보세요.