“야, 넌 왜 맨날 야근해?”
미국에서 일하는 친구와 30분쯤 통화를 했다. 안부로 시작한 통화는 어느새 하소연이 됐다. 월말마다 야근이라고 했다. 이유를 물으니 돌아온 대답은 한마디, “경비처리”.
들어보니 이런 그림이었다. 직원들이 쓴 영수증을 실물로 모아 보관하고, 스캔해서 파일로 만들고, 엑셀에 한 줄씩 옮겨 적는다. 그걸 부서별로 정리해 내부 보고를 올리면, 재무팀은 그 엑셀을 카드 사용 내역과 한 줄 한 줄 대조한다. 숫자가 안 맞으면 다시 영수증 더미를 뒤진다. 이 과정이 며칠씩 걸린다고 했다. 매달, 빠짐없이.
전화를 끊고도 그 장면이 남았다. 2026년에, 아직도 이렇게 한다고?
“너만 그런 거 아니야?”
궁금해서 좀 찾아봤다. 결론은 — 친구만의 문제가 아니었다.
의외로 많은 회사가 그냥 엑셀로 손수 관리하고 있었다. 이걸 자동화해주는 도구가 있다는 사실 자체를 모르는 경우도 많았고, 알더라도 기존 솔루션(Expensify·Ramp 같은)은 법인카드 발급 번들이 핵심이라 직원 개인 경비 정산을 주로 하는 회사엔 잘 안 맞았다. 무엇보다, 미국에서 일하는 한국계 회사들에는 하나같이 친화적이지 않았다.
수요는 분명한데 마땅한 답이 없는 자리. 문제가 진짜였고, 생각보다 넓었다.
그래서 만들기 시작했다 — 근데 막상 만들려니
컨셉은 단순했다. “Snap it. Claim it. Done.” 영수증을 찍으면 AI(Claude Vision)가 금액·날짜·가맹점·카테고리를 알아서 채우고, 사람은 확인만 한다.
MVP는 금방 나왔다. 진짜 문제는 그다음이었다. 회사가 실제로 쓰려면 신경 쓸 게 끝이 없었다. 결재선을 어떻게 태울지, 카테고리를 얼마나 자율적으로 열어둘지, 부서별로 데이터를 어떻게 격리할지, 권한은 어디서 나눌지, 회계 시스템 연동은 붙일지 말지… 화려한 AI 한 조각을 감싸고 있는 그 지루한 나머지 전부가, 사실은 제품이었다.
여기서 한계에 부딪혔다. 검색해서 완성도를 끌어올리는 데는 분명한 벽이 있었다. 필요한 건 코드가 아니라 실제 현장의 도메인 지식이었다. 경비를 매일 처리하는 사람만 아는 디테일.
그래서 방향을 정했다. MVP를 무료로 내주고, 진짜 쓰는 사람의 피드백으로 다듬는다. 이걸 당장 상품화할 생각으로 만든 건 아니었다. 만드는 게 재밌을 것 같았고, 무엇보다 서로에게 도움이 될 수 있을 것 같았다. 시작한 이유는 그게 전부였다. 완성해서 파는 대신, 쓰게 하고 같이 고쳐나가는 쪽을 택했다.
진짜 일은 “AI가 틀렸을 때”였다
무료로 풀고 나서 배운 가장 큰 교훈은 이거였다 — AI가 영수증을 읽는 건 데모에선 마법이지만, 진짜 돈이 걸리는 순간부터는 “AI가 틀렸을 때 무엇을 하는가”가 제품의 본체가 된다.
예를 들면 이런 거다. 영수증의 날짜가 07/03/26처럼 두 자리로 찍혀 있으면, AI가 이걸 2024년으로 읽어 이번 달 지출을 두 해 전 것으로 등록해버렸다. 사람 눈엔 당연한 올해가, 기계에겐 아니었다. 이런 케이스 하나하나가 카드 내역과 자동으로 맞춰보는 걸 막았다.
카드 매칭도 처음엔 형편없었다. 금액이 정확히 같은데도 짝을 못 찾고, 엉뚱한 걸 추천했다. 이걸 실사용자와 주고받으며 하나씩 걷어냈고, 지금은 자동 매칭률을 90% 이상까지 끌어올렸다. 완벽히 안 맞는 나머지는 억지로 맞추는 대신, 마감을 막지 않는 정당한 종결 상태로 빠져나갈 길을 열어뒀다. (이 매칭을 어떻게 끌어올렸는지는 기술적으로 재미있는 이야기라, 다음 편에서 따로 풀 생각이다.)
지금, 그리고 지금 하는 고민
제품은 프로덕션에 올라가 있고, 실사용 고객이 매일 쓴다. 최근엔 “환불된 영수증(마이너스 금액)도 처리돼야 한다”는 요청이 들어와 반영했다. 이렇게 실제 요청 하나하나가 제품을 다듬는다.
지금 혼자 고민 중인 것도 하나 있다. 벌크 업로드다. 원래 이 제품의 컨셉은 “영수증을 받는 즉시 한 장 찍어 그 자리에서 처리”였다. 미루지 않게 만드는 게 핵심이었다. 그런데 사용자들은 결국 게을러서(그리고 인간적이라서) 월말에 사진을 몰아서 한 번에 올리고 싶어 한다. 제품의 철학을 지킬 것이냐, 사용자의 실제 습관을 받아들일 것이냐. 정답이 뭔지 아직 모르겠다.
참고로 이 모든 건 회계를 대체하려는 게 아니다. 미국 중소기업 회계의 사실상 표준인 QuickBooks로 넘어가기 전 단계 — 영수증·경비·카드 대사를 자동화해서 거기에 깔끔하게 연결해주는 것이 목표다.
그리고, 왜 이게 ‘윈윈’이라고 생각하는가
흥미로운 건 이 문제의 비용을 회사만 치르는 게 아니라는 점이다. 그 회사에 회계 서비스를 제공하는 회계업체도 같은 영수증 더미와 씨름한다. 경비 정리에 매달 열 시간을 쓰면, 그 열 시간을 고스란히 고객사에 청구한다. 비효율이 그대로 청구서가 되는 구조다.
ClaimBook을 쓰면 회계업체는 영수증을 헤집을 필요 없이 QuickBooks만 확인하면 된다. 가령 그 열 시간이 한 시간으로 준다면? 고객사는 청구서가 줄어서 좋고, 회계업체는 같은 시간에 열 배의 고객을 감당할 수 있다는 계산이 선다. 한쪽의 절약이 다른 쪽의 손해가 아니라 양쪽 다 이득인 구조 — 내가 붙잡고 있는 건 이 윈윈 가설이다.
그래서 요즘 더 붙잡고 고민하는 방향이 하나 더 있다. 회계사들에게 “없으면 안 되는 도구”로 자리 잡을 수 있을까 하는 것이다. 개별 회사에 하나씩 파는 것보다, 여러 고객사를 다루는 회계업체가 먼저 손에 익으면 확산은 훨씬 빠를 것 같다. 다만 이건 아직 확신이 선 계획이라기보다 검증해보고 싶은 가설에 가깝다. 정답인지는 더 지켜봐야 한다.
이 여정, 지켜봐 주세요
친구의 하소연 한 통에서 시작된 이 제품이 앞으로 어디까지 갈지는 나도 모른다. 유료로 자리 잡을지, 아니면 좋은 경험으로 남을지도 아직은 열려 있다. 확실한 건, 실제 문제를 실제 사람과 함께 푸는 이 과정 자체가 재미있다는 것이다.
이건 아직 끝나지 않은 이야기다. 그래서 한 편으로 매듭짓지 않고, 만들어가는 과정을 연재로 계속 남기려 한다. 다음 편부터는 이 제품을 제대로 이해하는 데 필요한 맥락을 먼저 풀어볼 생각이다 — 미국에서 경비를 처리한다는 게 왜 그렇게 까다로운지(IRS의 영수증·기록 보관 규칙), 그리고 왜 우리가 처음부터 감사에 대비한 통제(SOX식 설계)를 넣었는지. 그다음에야 오늘 짧게 지나간 “AI가 틀렸을 때”를 어떻게 감당했고 매칭률을 어떻게 끌어올렸는지 기술적으로 풀고, 이어서 벌크 업로드를 어떻게 결론 냈는지, 회계사 채널 가설이 맞았는지도 진행되는 대로 기록하겠다. 비슷한 걸 만들고 있거나, 그냥 이런 여정이 궁금한 분이라면 다음 이야기도 지켜봐 주시길.