인도 VC $550M, 정산 파이프라인이 먼저 읽을 것

인도로 VC 자금이 이렇게 빠르게 쌓인 적은 드물다. Accel이 $550M짜리 인도 전용 펀드를 불과 몇 주 만에 클로즈했다. oversubscribed로. 직전 $650M 펀드가 닫힌 지 19개월 만이다.

결제·정산 파이프라인을 직접 운영하는 팀 입장에서 이 뉴스를 한 줄로 정리하면: 우리가 매일 굴리는 결제 스택의 상당 부분은 이미 인도 핀테크 위에 서 있고, 그 스택에 투자 속도가 붙으면 정산 복잡도도 같이 올라온다. 단, 이걸 단순히 "인도 핀테크가 뜬다"는 낙관으로 읽으면 정작 어디서 마찰이 생기는지를 놓친다.

55% 미집행의 역설 — 수치 하나가 묘하다

전 펀드($650M)의 55% 이상이 아직 집행되지 않았다. 대략 $357M이 인도 스타트업으로 나가지 않은 상태에서 $550M을 추가로 모았다는 이야기다.

이 구조가 의미하는 바는 간단하다. 좋은 딜이 펀드 소진 속도보다 빠르게 쌓이고 있다는 것. LP 입장에서 oversubscribed는 "이 흐름에 올라타지 못하면 기회를 잃는다"는 판단이다. 그러면 Accel은 집행 속도를 높여야 한다. 전 펀드 나머지 45%와 새 펀드 $550M을 동시에 소화하면, 향후 2년 인도 스타트업 생태계로 들어오는 자금 속도는 역대급이 된다.

결제팀에게 이 속도가 왜 중요하냐. 투자 속도는 해당 스타트업의 제품 변경 속도와 직결된다. API 버전, 가격 구조, 계약 조건이 빠르게 바뀐다. Razorpay는 2023년에서 2025년 사이에만 결제 API를 두 차례 메이저 업데이트했다. 성장 자금이 더 들어오면 이 주기는 짧아진다. 정산 자동화 로직을 짜놓은 팀이라면, 외부 API가 조용히 바뀌는 순간이 가장 위험하다.

우리 벤더 목록 안에 이미 Accel 포트폴리오가 있다

Accel India 포트폴리오를 보면 낯선 이름이 없다. Razorpay, Chargebee, Freshworks, BrowserStack, Postman. 결제 게이트웨이, 구독 청구, CRM, API 개발 도구로 소규모 팀이 실제로 쓰는 것들이다.

우리 팀 이야기를 하자면, 구독 정산 로직을 설계할 때 Chargebee의 레퍼런스 케이스를 참고했고, 인도 결제 게이트웨이를 비교할 때 Razorpay API 문서를 꽤 뜯어봤다. 이 툴들이 전부 Accel이 올인하고 있는 인도 핀테크다. 그들이 더 빠르게 성장하는 건 좋은 일이지만, 우리가 의존하는 인프라가 더 빠르게 변한다는 뜻이기도 하다.

벤더 의존도가 높을수록 변경 주기 추적이 중요해진다. 지금은 Chargebee 웹훅 하나가 바뀌어도 정산 파이프라인 전체를 점검해야 하는 구조다. Accel 자금이 이 회사들의 성장을 가속하면, 이 점검 빈도가 늘어난다. 수동으로 따라가기엔 한계가 있다.

인도향 정산의 실제 마찰 — TDS, GST, 환율

인도와 결제·정산을 엮으면 구체적인 마찰 지점이 세 곳이다.

첫 번째는 TDS(Tax Deducted at Source)다. 인도 법인이 해외 벤더에게 소프트웨어 대금이나 기술 서비스비를 지급할 때 10~20% 원천징수가 붙는다. 한-인도 DTAA(조세조약)로 세율을 낮출 수 있지만, Form 10F 제출과 TRC(Tax Residency Certificate) 발급 절차가 따라온다. 직접 해보기 전엔 "세금 항목 하나 추가하면 끝"인 줄 알았는데, 실제론 인도 세무서 관련 서류까지 엮인 흐름이었다. 정산 금액이 예상보다 작게 들어오는 상황을 처음 맞닥뜨리면 당황스럽다. TDS가 빠진 건지 환율 차이인지 바로 구분이 안 되기 때문이다.

두 번째는 GST다. 인도 B2B 서비스에 18% GST가 붙는다. 인도 법인과의 구독 계약이나 서비스 정산을 처리할 때, 인보이스 항목 분류가 틀리면 월말 리컨실리에이션에서 뒤집어진다. Reverse Charge Mechanism이 적용되는 항목이 따로 있고, GSTIN 유효성 검증을 자동화하지 않으면 수동 검수가 계속 붙는다.

세 번째는 환율이다. INR 자체는 비교적 안정적이지만, 인도 SaaS들이 USD 기준으로 가격을 책정하는 특성상 USD/INR 변동이 결제 금액에 그대로 반영된다. 정산 주기(통상 월말 마감) 안에서 환율이 2~3% 흔들리면 소규모 팀 기준으로는 무시하기 어려운 차이다. 특히 월 구독료 규모가 커질수록 이 오차는 선형으로 늘어난다.

우리 팀이라면 지금 무엇을 점검하나

Accel 뉴스를 접하고 팀에서 실제로 짚어본 순서가 있다.

먼저, 현재 결제 스택에서 인도 본사 또는 인도 VC 주요 투자 기업 목록을 뽑았다. SaaS 툴, 결제 게이트웨이 파트너, API 서비스를 전부 포함하면 생각보다 많다. 이 목록을 기반으로 다음 계약 갱신 전에 가격 정책 변경 이력과 API 지원 주기를 확인하는 리뷰 일정을 별도로 잡아뒀다. 의존도가 높은 벤더가 갑자기 가격을 올리거나 API를 deprecated 처리하면, 정산 자동화 로직이 조용히 무너지는 상황이 생기기 때문이다.

그다음은 인도 법인과 직접 정산하는 흐름이 있는지 확인이다. 지금은 소액이라 수작업으로 넘어가도 되지만, 상대방이 Accel 투자를 받아 두 배로 성장하면 거래 건수가 따라서 늘고 수작업 한계가 갑자기 온다. TDS 처리 흐름을 지금 문서화해두면 나중에 자동화로 전환할 때 훨씬 빠르다. 나중에 몰아서 정리하려면 소급 서류 작업이 훨씬 번거롭다.

마지막으로 UPI 연동 로드맵을 현재 게이트웨이 파트너에 확인해뒀다. UPI는 이미 싱가포르, UAE, 프랑스까지 수락처가 확장됐다. 동남아 결제를 처리하거나 그 방향으로 넓힐 계획이 있다면, UPI 지원 여부는 게이트웨이 선택 기준에 지금 당장 들어가야 한다.

지금 바로 쓸 수 있는 점검 항목

첫째, 현재 팀이 구독 중인 SaaS·API 서비스 목록을 뽑고 인도 본사 여부를 체크하라. Freshworks, Zoho, Chargebee, Razorpay, Clevertap, MoEngage 등이 대표적이다. 이 벤더들의 가격 정책 변경 주기와 API deprecation 공지 채널을 구독해두는 게 기본이다. 변경 감지는 사람이 추적하는 것보다 공식 changelog RSS나 상태 페이지 알림으로 자동화하는 편이 낫다.

둘째, 인도 법인과 인보이스를 주고받는 거래가 있다면 TDS 처리 흐름을 지금 문서화하라. DTAA 혜택 신청을 위한 TRC 발급 절차를 CFO 또는 세무사와 확인하는 데 오래 걸리지 않는다. 지금 준비하면 거래가 커질 때 소급 정리를 피할 수 있고, 정산 금액 오차 원인을 빠르게 특정할 수 있다.

셋째, 정산 자동화 스크립트에 인도 관련 거래의 세금 항목이 명시적으로 분리돼 있는지 확인하라. GST나 TDS가 정산 금액에서 빠지는 구조라면, 리컨실리에이션 로직에 해당 예외 처리가 코드로 들어가 있어야 한다. 월말 마감에서 터지는 정산 오류의 상당수는 이 항목 분리가 빠진 데서 시작한다.

마지막, UPI를 지원하는 결제 게이트웨이를 지금 백업 옵션으로 조사해두라. 메인 게이트웨이에 장애가 생겼을 때 인도·동남아 결제를 유지할 수 있는 두 번째 레일이 있어야 한다. Accel 자금이 풀리는 속도만큼 UPI 수락처는 빠르게 넓어질 것이고, 그때 가서 연동을 시작하면 이미 늦다.

원문: AI News & Artificial Intelligence | TechCrunch