안 쓰던 가계부를 24시간 만에 다시 쓰게 만들기

안 쓰는 제품의 진짜 문제

Opus 4.6 출시와 함께 만들어본 개인용 가계부 웹 앱이 있다. 영수증 사진을 찍어 보내면 AI가 알아서 분류해주고, 텔레그램으로 "오늘 스타벅스 5,200원"이라고 말하면 거래로 등록되는 구조. 만들 때는 "와, 이제 가계부 입력이 진짜 쉬워졌네" 싶었는데 — 그런데 막상 만들고 나서 내가 잘 안쓰게 되었다.

이유는 간단했다. 사진 찍는 것도, 메시지 보내는 것도 결국 "내가 뭔가 해야 하는" 일이었다. 아무리 쉬워도, 행동이 필요한 이상 안 한다.

이게 제품에서 가장 잔인한 진실 같다. "사용자가 더 쉽게 할 수 있게" 만드는 게 아니라 "사용자가 아무것도 안 해도 되게" 만들어야 한다. 입력 마찰을 0으로 만들지 못하면, 1이든 100이든 비슷하게 안 쓴다.

가설: 데이터 소스를 바꾸자

한국에는 뱅크샐러드라는 잘 만든 PFM(개인 자산 관리) 앱이 있다. 카드사·은행·증권사를 한 번 연결해두면 거래를 알아서 모아주고, 카테고리도 자동으로 붙여준다.

문제는 뱅크샐러드 자체가 "보는 앱"이라는 것. 내가 만든 가계부에 그 데이터를 끌어다 쓰고 싶었지만, 뱅크샐러드는 외부 개발자용 API를 제공하지 않는다.

그래서 떠올린 가설: "뱅크샐러드 화면을 그냥 그대로 긁어서 내 가계부 DB로 저장해서 활용하면 되는 거 아닌가?"

마침 집에 무제한 사진 백업용으로 Mac mini에 연결해둔 구글 Pixel 1이 한 대 있었다. 거기에 뱅크샐러드를 깔고, Mac이 자동으로 폰 화면을 읽어서 데이터를 가져오게 만들면?

이 가설을 검증하는 데 반나절이 걸렸다.

한국 금융 앱이라는 벽

처음 부딪힌 벽은 본인인증이었다. 한국 금융 앱은 PASS/통신사 인증이 필수라 유심이 없는 폰에는 회원가입조차 안 된다. 내 메인 폰의 유심을 잠깐 옮겨서 가입 + 카드/계좌 연결만 마치고 다시 빼는 것으로 우회했다.

두 번째 벽은 화면 캡쳐 차단. 금융 앱은 보통 화면 캡쳐를 막아두는데, 다행히 뱅크샐러드는 비밀번호 화면에만 차단이 걸려있었다. 일반 화면은 자동화 도구로 다 읽을 수 있었고, 비밀번호 화면도 우회 방법이 있었다 (구체적인 방법은 생략 — 이건 사용자 본인의 본인 폰에서만 해야 함).

세 번째 벽은 가장 까다로웠는데, 뱅크샐러드가 본인 계좌 사이 송금을 "지출"로 분류한다는 것. 통장에서 모임통장으로 옮기는 것도 "지출"로 잡혀서, 첫 결과를 보니 한 달 지출이 비현실적으로 높게 나왔다. 휴리스틱(받는 사람이 본인 이름이거나 모임통장 키워드면 "이체"로 재분류)을 추가해서 해결.

첫 결과 → 더 큰 그림

이 정도 손을 보고 나니, 매일 30분마다 폰이 자동으로 뱅크샐러드를 열고 거래를 가져와서 내 가계부에 넣어주기 시작했다. 만들면서 더 욕심이 생겼다.

"이 데이터를 텔레그램으로 매일 아침 자산 요약 보내주면 좋겠다."
"근데 가계부의 더블엔트리 회계는 어차피 안 쓰니 다 들어내자."
"입력 UI들도 다 없애버리자, 어차피 안 쓸 거."
"AI 챗봇 붙여서 '이번 달 식비 얼마야?' 같은 거 물어보고 싶다."

여기서 두 번째 결정. 부분 개선이 아니라 아예 다시 짓자. 이미 만들어진 코드를 살려가며 점진적으로 바꾸려면 두 시스템이 공존하는 어색한 시기가 길어진다. 1인용 프로젝트니까 30분 다운타임 정도는 받아들이고 통째로 갈아엎는 게 훨씬 깔끔하다.

AI 코딩 에이전트 50명을 지휘하기

여기부터가 흥미로운 부분이다.

전체 재설계 + 새 기능 추가를 사람이 손으로 다 하면 며칠 걸리는 일이다. 대신 AI 에이전트(Claude Opus)에게 매니저 역할로 들어가서 작은 작업 50개로 쪼개서 위임했다.

내가 한 일은:

핵심 결정 ("기존 데이터는 다 버리고 다시 받자", "이체는 집계에서 제외하자")
우선순위 결정 ("backfill은 1년치만 — 그 이상은 뱅크샐러드도 못 줘")
디자인 가치판단 ("이건 이전 디자인이 더 좋아, 데이터만 가져다 써")

AI가 한 일은:

데이터 모델 설계 → 마이그레이션 → 백엔드 → 프론트엔드 → 자동화 스크립트
매 작업마다 다른 AI 에이전트가 코드를 검토하고 발견된 버그 수정
문서화

마치 작은 회사를 운영하는 느낌이었다. 내가 PM, AI들이 엔지니어. 결정을 내리고 방향을 잡는 게 사람의 일이고, 그 결정을 코드로 만드는 건 AI의 일.

가설 검증부터 시스템 갈아엎기까지, 모니터 앞에서 보낸 시간을 합치면 반나절 남짓이었다.

그런데 디자인이 엉망이 되어 있었다

여기서 한 번 크게 꺾였다.

전체 재설계가 끝나고 결과를 리뷰하는 과정에서 발견했다. 작동은 잘 되는데 디자인이 자동으로 단순해져 있었다. 특히 가장 공들였던 "경제적 자유 시뮬레이터" (은퇴 시뮬레이션 + 자녀 독립 + 경제 위기 같은 이벤트가 표시되는 풀폼)가 매우 단순한 폼으로 대체되어 있었다.

AI가 데이터 모델을 갈아엎으면서 그에 맞춰 UI도 "단순한 버전"으로 재작성한 거였다. 새 데이터를 잘 보여주긴 하는데, 이전 시뮬레이터의 풍부함이 사라져 있었다.

여기서 사용자(나)가 본인에게 했던 말:

"데이터만 가져다 써야지 아예 다 바꾸면 어떻게 해."

이게 LLM과 함께 일할 때 늘 마주치는 함정이다. AI는 "이게 더 깔끔합니다" 같은 판단을 자기 식대로 한다. 사용자가 명시적으로 "이건 그대로 둬"라고 안 하면, 자기가 보기에 "더 단순한" 방향으로 자동 정리한다.

그래서 두 번째 라운드: AI에게 다시 위임했다. 이번 지시사항은 명확했다.

"이전 디자인 코드를 그대로 복원하고, 데이터를 가져오는 부분만 새 구조에 맞게 바꿔. 디자인은 절대 손대지 마."

복원이 끝나니 옛 디자인 + 새 데이터 조합이 완성됐다. 시뮬레이터의 차트와 이벤트 표시가 다시 살아났다.

AI 챗봇은 보너스

이 과정에서 사용자가 한 가지 추가 요구를 했다.

"AI 챗봇도 살려줘. 입력용이 아니라, 내 가계부 데이터에 대해 자연어로 물어볼 수 있게."

이를테면 "이번 달 식비 얼마야?", "테슬라 수익률은?", "지난 분기 카드 청구액 합계는?" 같은 질문에 AI가 진짜 내 데이터를 보고 답하는 것.

이미 다른 프로젝트에서 쓰던 AI 챗봇 인프라가 있었는데 — 이건 공개 웹사이트 방문자용으로 만든 거라 "개인 가계부 같은 사적인 내용은 답 못해요"라고 거절하도록 되어 있었다.

여기에 mode=moneybook 플래그를 추가해서 "이 모드에서는 개인 데이터 분석을 도와줘도 됨"이라고 가르쳤다. 작은 변경이지만 결과는 즉시 동작했다.

"이번 달 식비 얼마야?"
"이번 달 식비는 약 OOO만원이야. 외식이 70%, 식료품이 30%로 — 지난달 대비 약간 줄었어."

24시간 뒤 풍경

이제 가계부에 직접 입력하는 일이 없다. 매일 아침 7시에 텔레그램으로 자산 현황이 도착하고, 궁금한 게 있으면 사이트의 챗봇에 물어본다. 매 30분마다 안 쓰는 폰이 자동으로 새 거래를 가져와 채워준다.

처음 가계부를 만들 때 했던 가정 — "내가 매일 입력하겠지" — 이 틀렸다는 걸 인정하고 나니, 같은 가계부가 완전히 다른 제품이 됐다.

제품을 만들면서 배운 점

1. 마찰은 1과 100이 비슷하게 안 쓴다. 사용자가 의식적으로 "이 앱을 켜야지"라고 결정하는 순간 이미 진 게임이다. 데이터가 자동으로 들어와야 진짜 도구가 된다.

2. "데이터 입력"과 "데이터 활용"은 완전히 다른 제품이다. 입력에 집중한 가계부는 결국 안 쓰게 되고, 활용(분석·알림·시뮬레이션)에 집중한 가계부가 살아남는다. 입력은 기계가 하게 두자.

3. 사용자의 "이건 더 안 좋아"를 무시하지 말 것. AI든 사람이든, 객관적으로는 더 "깔끔한" 디자인이 사용자에게는 더 안 좋게 느껴질 수 있다. 사용자 검증 없이 디자인을 바꾸는 건 위험하다.

4. AI 협업의 핵심은 명확한 지시다. "재설계해줘"와 "데이터 부분만 새 구조로 바꿔, 디자인은 절대 손대지 마"는 결과가 완전히 다르다. AI가 알아서 잘 하길 바라지 말고, 가치판단을 사람이 명시적으로 박아넣어야 한다.

5. 갈아엎는 게 차라리 깔끔할 때가 있다. 점진적 개선이 항상 답은 아니다. 1인용 도구라면 30분 다운타임을 받아들이고 통째로 바꾸는 게 결과적으로 빠르다.

6. 외부 데이터 소스에 의존할 때는 그 데이터의 "원래 의미"를 이해해야 한다. 뱅크샐러드가 분류한 "지출"이 실제로는 본인 계좌간 송금이라는 걸 처음에 몰라서, 첫 리포트의 저축률이 비현실적으로 나왔다. 데이터를 받기만 하지 말고, 그 데이터의 가정과 한계를 직접 검증해야 한다.

이 글은 사람이 결정·디자인·검증을 하고, AI 코딩 에이전트(Claude Opus)가 실제 구현 작업을 맡은 24시간의 기록이다. 코드 변경과 디버깅의 90%는 AI가 했고, "뭘 만들지"와 "이게 맞는지"는 사람이 했다.