소개
금리보다 중요한 건 “그래서 얼마를 받는데?”
이번 작업은 예금과 적금을 제공하는 금융기관을 어떻게 분류할 수 있는지 묻는 데서 시작했어요. 범위는 은행과 저축은행으로 정했고, 다음처럼 요청했습니다.
상품은 수시로 변하므로 넷플리파이로 배포하고 현행화 기능 있는 대시보드를 만들고 싶어그런데 상품 목록과 금리만 보여주는 것으로는 부족했어요.
공시기간은 공시일자로 단순화
만기시 내가 받을수 있는 금액도 중요이후 작업의 중심은 공식 공시 데이터를 비교하면서, 내가 납입할 금액으로 만기 예상액까지 확인하는 대시보드가 됐어요.
이런 분들께 도움돼요
자연어 로 요구사항을 전달하며 실제 웹서비스를 만들고 싶은 분
API 데이터 수집과 화면 조회를 분리하고 싶은 분
AI가 만든 금융 계산 결과를 어떻게 검증할지 고민하는 분
어사이드로 유사 사례부터 찾아봤어요
어사이드를 이용해서 지피터스 사례글에 예적금 금융상품 비교 관련 사례가 있는지 먼저 검색해 보았어요. 어사이드가 매우 빠른 속도로 관련 글을 찾아주어서 무척 편리했어요. 관련 게시글들을 살펴보니, 내가 만들려는 것과 완전히 일치하지는 않는다는 판단이 들었어요.
“AI한테 예금 이자 계산 맡겨봤습니다”
ChatGPT와 Claude 등에 두 상품의 이자 계산을 맡기고, 단리·복리 계산의 오류를 비교한 사례예요. 금융 계산을 검증한다는 점은 비슷하지만, 이번 작업은 공식 API와 DB를 연결한 다상품 대시보드라는 차이가 있어요.드디어 나만의 투자 대시 보드를....
Antigravity와 Claude로 여러 계좌의 주식·ETF 등 보유자산과 수익률을 모아보는 투자 대시보드를 만든 사례예요. 금융 대시보드라는 점은 비슷하지만, 은행·저축은행 예적금의 공식 공시 비교와 월 정액 만기 계산이라는 이번 목표와는 달랐어요.60대 아버지도 3달 만에 20개 AI 투자 에이전트를 직접 구축해줄 전자책 만들기 (with. Claude Code)
Claude Code로 시니어 금융 교육용 전자책을 기획한 사례예요. 목차에 ‘전국 금리 비교 + 실질 수익률 계산’ 실습을 포함하지만, 해당 글에서 예적금 비교 웹사이트를 실제 구현한 결과가 확인되지는 않았어요.
확인한 세 사례와 이번 작업은 목적과 구현 범위가 완전히 일치하지 않았어요. 다만 공개 검색에서 확인한 범위의 비교이지, 지피터스 전체에 동일 사례가 전혀 없다는 뜻은 아니에요.
진행 방법
사용한 도구
어사이드(Aside): 요구사항 전달, 브라우저 확인, 파일·코드 수정, 테스트와 배포 후 검증
맥미니(Mac mini): 어사이드와 로컬 작업을 실행한 환경
네틀리파이(Netlify): 웹사이트 배포와 서버 함수 실행
수파베이스(Supabase): 공시 상품·금리 옵션 저장과 조회
금융감독원 금융상품통합비교공시 API: 은행·저축은행의 공식 예적금 데이터 수집
맥미니가 공개 웹사이트를 직접 호스팅하는 구조는 아니에요. 로컬 작업은 맥미니에서, 배포된 웹서비스는 Netlify에서, 데이터 저장은 Supabase에서 담당했어요.
1. 코드 답변을 받는 대신, 실제 화면을 보며 수정했어요
어사이드로 작업한 차별성은 대화와 실행·검증이 하나의 흐름으로 이어졌다는 점이에요.
제가 원하는 규칙을 말하면, 어사이드가 관련 파일을 확인하고 수정했어요. 테스트와 배포를 진행한 뒤에는 실제 브라우저에서 필터를 바꾸거나 계산 팝업을 열어 결과를 확인했습니다.
예를 들어 이런 요청을 했어요.
만기예상 금액 계산은 메인 화면에 나오지 않게, 각 은행 카드에서 클릭했을 때 팝업으로 뜨게은행별 상품 정보 보여줄 때 열 좀 맞춰
만기 예상액은 별도 줄이 아니라 같은 줄에 글자로 박아줘완료 보고만 받는 게 아니라, 배포된 화면에서 요구사항이 실제로 반영됐는지 다시 확인하는 방식이었어요. 로그인과 인증키 입력처럼 제가 해야 하는 부분은 직접 처리했습니다.
전체 필터 기준으로 상품 767개, 금리·기간 옵션 4,327개가 표시되는 실제 화면이에요.
2. 화면 수정과 공시 데이터 수집을 분리했어요
작업 도중 데이터 구조도 바꿨어요.
화면 고칠 때마다 공시정보 다시 읽어오는 것은 불합리하다. supabase에 한번에 저장하고, 이후 수정된 항목만 저장하는 구조로 변경
상단의 초록색으로 커다란 제목카드는 불필요하므로 제거
그 외 화면 곳곳의 구차한 설명문구들 모두 제거(꼭 필요한 설명은 내가 정한다)최종 구조는 다음처럼 분리했습니다.
공시 수집·동기화
금감원 API → 전체 수집 및 검증 → Supabase 저장
사용자 화면 조회
브라우저 → Netlify 서버 함수 → Supabase 저장 데이터화면 방문이나 새로고침, UI 배포가 금감원 API 재수집을 뜻하지 않도록 했어요.
동기화할 때는 전체 공시를 가져와 비교하되, DB에는 변경된 상품만 저장합니다. 상품별 해시를 비교하고, 수집에 실패하면 기존 저장 데이터를 유지하도록 했어요.
수집 예약도 Aside 루틴에 등록했어요
루틴 이름은 예적금 공시 정기 수집 · 매일 오전 9시예요. 매일 오전 9시가 되면 새 작업에서 인증된 수집 요청을 보내고, 수집·저장은 기존 Netlify 서버 함수가 처리하도록 연결했습니다. 화면 새로고침과는 별개의 실행 경로예요.
수집 요청 접수만으로 완료라고 보고하지 않도록 했어요. HTTP 202는 접수 상태이고, 저장 스냅샷의 마지막 완료 시각이 실제로 갱신된 뒤에야 수집 완료로 확인합니다. 인증정보나 실행 도구가 없어지면 실패를 알리고, 기존 데이터를 유지하는 방식이에요.
이 예약 호출은 Aside 실행 환경과 기존 Netlify 인증 연결을 사용해요. Netlify 자체에 예약 함수를 등록한 것 과는 다릅니다.
같은 실행 경로로 실제 수집·저장까지 시험했어요. 2026년 10월 5일 오후 3시 37분에 요청을 보냈고, 오후 3시 38분 4초에 저장 완료 시각이 갱신된 것을 확인했습니다. 결과는 상품 767개, 신규 0개·수정 0개·판매 중단 반영 0개·변경 없음 767개였어요.
3. “한도를 적용해줘”라는 말도 구체적인 규칙이 필요했어요
만기 예상액의 기본값은 다음처럼 정했어요.
디폴트로 적금은 월 100만원으로, 예금은 1000만원을 기준으로 만기예상액 보여줘.그런데 납입한도 처리에서 요구사항이 잘못 해석됐어요. 한도가 있다는 이유만으로 기본금액을 그 한도까지 올리는 게 아니라, 기본금액보다 한도가 낮을 때만 금액을 낮추는 것이 제가 원한 규칙이었어요.
그래서 이렇게 보완했습니다.
여기서 납입한도가 있는 상품은 적금 월100만원, 예금 1000만원 보다 낮은 금액이 한도로 설정된 경우를 의미해최종적으로는 다음처럼 동 작해요.
적금 월 한도 50만원: 기본 입력액을 50만원으로 낮춤
적금 월 한도 300만원: 기본 입력액은 100만원 유지
예금 한도 1억원: 기본 입력액은 1,000만원 유지
실제 한도를 넘는 입력: 경고하고 직전 허용 금액으로 되돌림
월 50만원 한도 상품에 60만원을 입력해 직접 확인했어요.
입력액은 50만원으로 되돌아가고, 한도 초과 경고가 표시됩니다.
4. 적금은 모든 돈이 처음부터 들어가 있는 게 아니에요
자유적립식 상품은 납입 일정이 없으면 만기액을 계산하기 어려웠어요. 이번 대시보드에서는 비교 기준을 단순화했습니다.
정기적립 방식으로만 보여줘상품 자체의 공시 분류는 유지하되, 계산은 매월 같은 금액을 납입한다는 가정으로 통일했어요.
복리 적금도 총 납입 원금 전체에 동일한 기간의 이자를 붙이지 않습니다. 각 납입액의 남은 운용 기간을 따로 계산해 합산해요.
캡처 시점의 공시 금리, 월 50만원씩 12개월 납입, 일반과세 15.4% 가정에서 기본금리 기준 예상 수령액은 6,076,250원이에요. 우대조건 충족 시 금액은 별도로 표시합니다.
5. 금융사 계산기로 연결하면 해결될 줄 알았지만, 방향을 바꿨어요
처음에는 일 적립이나 복리 같은 특이상품을 금융사 계산기로 연결하려 했어요.
하지만 연결을 점검하면서 일부 주소의 접속 오류를 만났고, 공식 홈페이지나 상품 페이지가 있다고 해서 원하는 계산기로 바로 이어지는 것도 아니었어요.
그래서 최종적으로 이렇게 요청했습니다.
모든 금융사를 연결하는 것은 좋지 않다. 특이상품(일정립)은 아예 만기 예상액 링크를 없애라. 복리 상품은 최대한 복리 계산 로직을 구현 해서 결과 나오게 해라결과적으로 금융사 외부 연결은 제거했어요.
일·주 단위 적립 상품: 월 정액 계산을 억지로 적용하지 않고 계산 링크 제거
지원 가능한 복리 상품: 내부 계산 제공
계산 기준이 불명확한 상품: 임의 금액을 만들지 않고 계산 유보
기능을 무조건 늘리는 것보다 잘못 계산할 수 있는 범위를 줄이는 선택이 필요했어요.
6. 공시된 복리 금리를 다시 복리로 계산하면 안 되는 경우가 있었어요
복리 계산에서 특히 중요한 시행착오였어요.
일부 저축은행의 공식 금리표는 약정금리와 이미 복리가 반영된 연평균수익률을 구분하고 있었어요. 이런 수익률을 다시 월복리 공식에 넣으면 이자를 중복 적용할 수 있습니다.
해당 금융사의 공식 금리표를 확인한 상품군에서는 같은 상품·기간의 약정금리를 계산에 사용하고, 화면에 두 값을 구분해 표시하도록 했어요.
우리저축은행 정기예금 예시에서는 적용 약정금리 4.00%와 공시 복리수익률 4.07%를 구분해 보여줍니다.
월복리 비교 가정은 명시하고, 실제 지급액은 입금일·일수·절사 방식·변동금리 등에 따라 달라질 수 있다는 점도 남겼어요.
결과와 배운 점
확인된 결과
2026년 10월 5일 작업·검증 기준이에요.
배포 완료: Netlify에서 실제 대시보드 운영 화면 확인
저장 데이터: 상품 767개, 금리·기간 옵션 4,327개
데이터 구조: 화면 조회와 공시 수 집 분리, 변경 상품만 DB에 저장
정기 수집: Aside에 매일 오전 9시(한국시간) 실행 루틴 등록, 첫 예약 실행은 2026년 10월 6일
계산 UI: 선택한 상품·기간의 팝업에서 만기 예상액 표시
한도 처리: 낮은 한도만 기본금액에 적용하고, 초과 입력 차단
복리 계산: 1,694개 복리 옵션 중 1,687개에서 계산값 산출
계산 유보: 명시적 일복리 2개와 금리 기준 미확인 5개
회귀 테스트: 104개 통과, 실패 0개
복리 옵션의 계산값이 나온다는 것은 설정한 비교 모델로 산출 가능하다는 뜻이에요. 모든 금융사의 실제 만기 지급액과 일치한다고 검증한 것은 아닙니다.
시행착오를 극복한 방법
이번 작업에서는 오류를 발견할 때마다 계산식을 덧붙이기보다, 먼저 규칙을 분명하게 했어요.
데이터 재수집 문제
수집·저장·조회 역할을 분리했어요.자유적립식 계산 문제
월 정액 납입이라는 비교 가정을 정했어요.한도 해석 문제
“한도를 적용한다”를 기본값 조정 규칙과 입력 차단 규칙으로 나눴어요.외부 계산기 연결 문제
모든 상품을 연결하려는 방향을 버리고, 계산 가능한 범위를 내부에서 처리했어요.복리 금리 기준 문제
공식 금리표를 확인해 약정금리와 복리수익률을 구분했어요.
Aside로 작업할 때 재사용하고 싶은 방식
이번 사례에서 어사이드의 장점은 특정 화면을 한 번 만들어준 데 있지 않았어요.
요청 → 파일 수정 → 테스트 → 배포 → 브라우저 재검증 → 요구사항 보완을 이어갈 수 있다는 점이 중요했습니다.
다른 도구로는 불가능하다는 뜻은 아니에요. 다만 이번에는 코드 답변을 받아 따로 옮기는 작업에 머무르지 않고, 실제 서비스의 동작을 확인하며 수정할 수 있었어요.
재사용하고 싶은 원칙은 세 가지예요.
“자동으로 해줘”보다 기본값·예외·실패 시 행동을 구체적으로 정하기
“완료했다”는 보고와 실제 화면에서 확인한 결과를 구분하기
금융 계산에서는 그럴듯한 숫자보다 계산 기준과 미지원 범위를 명시하기
앞으로 보완할 부분
아직 남은 부분도 있어요.
계산을 유보한 7개 복리 옵션의 세부 규정 확인
금융사 실제 계산 결과와 대조할 검증 사례 확대
등록된 정기 수집 루틴의 예약 실행 결과와 변경 로그 점검
대시보드 주소와 소스의 공개 범위 결정
예적금 계산 서비스를 만들어보신 분들은 입금일·은행별 절사 방식까지 어느 수준으로 검증하셨는지 궁금해요.
도움 받은 글 (옵션)
60대 아버지도 3달 만에 20개 AI 투자 에이전트를 직접 구축해줄 전자책 만들기 (with. Claude Code)
사례글 구성: 지아코모(안재흥)의
gpters24-giacomo-write-post학습용 스킬 참고. 원 출처는 닿님의 write-post입니다.
