솔직한 답
은행 명세서 CSV를 ChatGPT나 Claude에 올릴 수 있고, 결과도 꽤 괜찮게 나와요. 모델은 각 행을 파싱하고, 합계를 내고, 가맹점을 묶고, 파일 안에서 답을 찾아줘요. 이미 끝난 한 달에 대한 일회성 질문이라면 합리적인 선택이에요.
하지만 돈 관리 워크플로 자체를 명세서 업로드 위에 세워도 될지 묻는다면, 답은 아니오예요. 파일은 내보낸 그날부터 낡고, 이력 대부분은 안 들어가고, 카테고리는 은행이 넣고 싶은 대로 들어가 있고, 이 방식을 유지하는 한 매달 같은 잡일을 반복하게 돼요.
이 글에서는 CSV 방식이 정확히 어디서 무너지는지, 그리고 실시간 읽기 전용 연결은 무엇을 다르게 하는지 하나씩 짚어봐요. 저희는 실시간 연결(BankBridge)을 파는 입장이니 그 점을 감안해 읽어주세요. 아래에 정리한 실패 유형은 어느 쪽으로 보든 사실 그대로예요.
왜 첫 업로드는 잘 통할까
명세서를 처음 채팅에 넣으면 기분이 아주 좋아요. 모델이 수백 행을 몇 초 만에 읽고, 잊고 있던 구독을 찾아주고, 스프레드시트를 열어보지 않아도 외식 지출 합계를 알려줘요. 진짜로 유용하고, 그래서 그렇게 많은 사람들이 애초에 모델에게 '명세서를 올려도 될까?'라고 물어보는 거예요.
문제는 첫 업로드가 아니에요. 그 다음 날부터가 문제죠.
금요일이면 낡은 데이터
명세서 내보내기는 사진 한 장이에요. 그 순간에도 계좌는 계속 움직이고 있죠. 월요일에 내보내면 금요일쯤에는 대기 중인 결제, 급여 입금, 어쩌면 환불까지 생겨나 있지만, AI가 추론하고 있는 파일에는 그 어떤 것도 들어있지 않아요.
이건 생각보다 큰 문제인데, 돈에 대한 질문은 유난히 '지금 당장'에 관한 것이 많기 때문이에요. 그 결제가 실제로 승인됐어? 월세까지 얼마 남았지? 이번 주에 얼마 썼어? 한 주 지난 CSV로는 이 어떤 것도 답할 수 없어요. 더 나쁜 건, 답을 자신 있게 하긴 하는데 한 주 전 숫자로 한다는 거예요.
그래서 사람들이 다시 내보내기를 해요. 그러면 잡일 이야기로 이어져요.
잘림, 카테고리, 그리고 알아보기 힘든 표기
첫 업로드에도 조용한 문제들이 있어요. 긴 이력은 잘려요. 입출금 계좌 하나에 카드 두 장의 1년치 거래를 모으면 수천 행이 되고, 파일 크기 제한과 컨텍스트 창 한계 사이에서 모델은 큰 파일의 중간을 흔히 잘라내거나 대충 읽어요. 그 사실을 보통은 알아채기 어려워요. 합계만 미묘하게 어긋난 채로 나올 뿐이에요.
카테고리는 은행이 내보내기에 넣어준 것이 전부인데, 그게 아예 비어 있거나 애매한 한 단어인 경우가 잦아요. 모델이 원본 표기에서 다시 분류를 시도할 수는 있지만, 은행 표기 자체가 하나의 수수께끼예요. SQ *BLUE BTL 402 같은 문자열은 커피숍인데, 파일 안 어디에도 그런 정보가 없어요.
게다가 은행마다 내보내기 형식이 달라요. 열 이름도, 날짜 형식도, 부호 규칙도 제각각이에요(한 은행은 출금을 음수로 두고, 다른 은행은 별도 열로 둬요). 두 은행에 계좌가 있다면, 모델이 시작도 하기 전에 파일을 정리하고 합치는 일부터 해야 해요.
매달 반복되는 잡일
그 모든 걸 감안하고도 이 방식을 쓰기로 했다고 해봐요. 이런 한 달을 보내게 돼요. 각 은행에 로그인하고, 명세서나 거래내역 내보내기를 찾고, 날짜 범위를 고르고, 다운로드하고, 아마도 파일을 정리하고, 채팅에 올리고, 그리고 다시 상황을 설명해요. 어느 계좌가 뭔지, 어느 이체가 내부 이체인지, 어느 카드가 사업용인지.
계좌 수만큼 곱하세요. 그리고 채팅은 파일을 다음으로 안정적으로 넘기지 못한다는 사실도 잊지 마세요. 다음 달 대화는 다시 0에서 시작해요.
제일 나쁜 부분은 설명을 다시 하는 일이에요. 모델에게 계좌에 대해 가르쳐 놓은 모든 것이 파일과 함께 증발해버려요.
실시간 연결이 바꾸는 것
BankBridge는 호스팅형 MCP 서버예요. 은행을 한 번 연결하고, 저희가 문서로 정리해 둔 29개의 MCP 지원 앱 중 Claude, ChatGPT, Cursor 어디에든 이 서버를 추가하면, 에이전트가 열한 개의 읽기 전용 도구를 얻어요. 계좌, 거래, 검색, 지출 요약, 정기 결제 감지, 월간 현금 흐름, 가맹점 이력, 투자 보유 종목이에요.
모든 질문은 실시간 조회로 답해요. 저희 서버에는 아무 것도 캐시하지 않기 때문에 '이번 달'은 오늘까지, 오늘 아침 결제까지 포함한 값이에요. 같은 질문을 4월에 하고 5월에 다시 해도, 내보내기 버튼을 누르지 않고 4월의 답과 5월의 답을 각각 받게 돼요.
이번 달에 지금까지 식료품에 얼마 썼어?
세 달 전과 비교해서 오른 정기 결제가 뭐야?
지난 1년간 그 호스팅 회사에서 나간 결제 전부 보여줘.
카테고리는 은행 내보내기 파일이 아니라 은행 연결 계층의 보강 데이터에서 오기 때문에, 은행이 달라도 일관돼요. 그리고 쌓아둔 문맥(이 이체는 월세다, 저 카드는 사업용이다)도 매달 다시 입력하는 게 아니라 에이전트의 메모리 안에 살아 있을 수 있어요.
프라이버시 문제, 솔직하게
어느 쪽이든 답을 낼 때 모델은 당신의 거래 데이터를 봐요. 그러지 않는 AI 재무 지원 방식은 없어요. 진짜 차이는 범위와 통제예요.
CSV를 넘기면 파일 전체, 모든 행을 넘기는 셈이에요. 질문에 필요하든 아니든 전부요. 그리고 그건 그 뒤로도 채팅 기록에 남아요. 도구 호출 방식이라면, 에이전트는 질문이 필요로 하는 만큼만 가져와요. 한 카테고리의 한 달치, 한 가맹점의 이력, 한 계좌의 잔액 같은 식으로요.
BankBridge 자체는 설계상 읽기 전용이에요. 돈을 옮기는 도구는 없고, 앞으로도 없을 거예요. 접근은 bearer API 키 아니면 OAuth 승인으로 하고, 둘 다 언제든 취소할 수 있어요. 이건 이미 올려버려서 되돌릴 수 없는 파일보다 훨씬 깔끔한 이야기예요.
그래도 CSV가 나은 경우
이건 솔직히 말할게요. 이미 끝난 한 기간에 대한 답 하나가 필요한 거라면 업로드도 괜찮아요. 세금 시즌에 작년 명세서를 분석하거나, 이미 해지한 계좌의 한 달치를 확인하거나, 데이터 집계에서 지원하지 않는 은행을 다뤄야 하는 경우엔 그냥 내보내세요.
연결로는 데이터를 얻을 수 없는 상황에서도 CSV가 맞아요. 없어진 계좌의 명세서라든가, 다른 누군가가 보내준 스프레드시트 같은 경우예요.
그 외에는 계산이 간단해요. BankBridge는 연결한 은행 한 곳당 월 $5, 언제든 해지할 수 있어요. 그렇지 않아도 명세서를 한 달에 두 번 이상 내보내고 올리고 있다면, 실시간 연결이 첫 주 안에 그 잡일을 대체하고, 에이전트는 지난 화요일의 스냅숏을 근거로 당신의 돈을 판단하는 걸 그만두게 돼요.