돈을 아끼겠다고 마음먹을 때 가장 먼저 떠오르는 것은 가계부다. 지출을 입력하고 카테고리를 나누면 소비가 줄어들 것 같았다. 그런데 거래가 쌓일수록 다른 질문이 생겼다.
이번 달 얼마를 썼는지 아는 것과, 다음 달에 돈이 얼마나 필요할지 아는 것은 전혀 다른 일이다.
신용카드 결제일은 급여일과 다르고, 할부는 구매 시점과 실제 납부 시점이 다르다. 대출 원금은 부채지만 매월 전부 빠져나가는 돈은 아니다. 기록이 많아져도 정작 가장 중요한 질문, ‘앞으로 현금이 충분할까?’에는 답하기 어려웠다.
이번 작업은 그 질문에서 출발했다. Notion에 Finance OS를 만들며 복잡한 구조를 줄이고, 필요한 기능만 다시 더하고, 차트가 표시되지 않는 오류까지 해결하면서 기록하는 가계부를 판단하는 대시보드로 바꾸는 과정이었다.
이 글에는 실제 거래 내역이나 금액을 싣지 않았다. 구조를 설명하는 데 쓴 금액은 모두 가상의 예시다.
01. 복잡한 금융 시스템보다 매일 쓰는 가계부
처음에는 돈과 관련된 모든 것을 한 번에 관리하고 싶었다. 수입, 소비, 자산, 카드, 대출, 정기 결제, 심지어 다른 취미 활동의 재고까지 한 공간에 넣는 구상도 있었다. 데이터베이스를 많이 연결할수록 정교한 운영 시스템이 될 것 같았다.
하지만 핵심은 다른 곳에 있었다. 이렇게 무거운 도구를 실제로 매일 사용할 수 있을까?
속성 하나를 입력하기 위해 여러 페이지를 이동하고, 개인이 감당하기 어려운 관리 절차가 늘어난다면 시스템을 만든 목적이 사라진다. 결국 범위를 줄였다. 재고와 별도 사업 기록은 제외하고, 일상의 수입과 지출부터 안정적으로 다루기로 했다.
처음의 핵심 구성은 간단했다.
거래원장: 날짜, 거래명, 수입·지출 구분, 카테고리, 금액, 결제수단을 입력한다.
월별 예산: 거래를 월별로 연결하고 합계와 예산 대비 사용액을 계산한다.
대시보드: 원장의 상세 행 대신 수입·지출·현금흐름·예산 사용 현황을 요약한다.
이후 실제 관리 필요가 확인된 할부, 대출, 예정 거래를 각각 보조 구조로 추가했다. 처음부터 만능 시스템을 만들기보다 필요한 질문이 생겼을 때 데이터 구조를 확장하는 방식이었다.
개인에게 좋은 시스템은 복잡한 기능을 많이 가진 시스템이 아니라, 계속 사용할 수 있는 시스템이다.
02. 소비액과 현금흐름은 같은 숫자가 아니다
가장 먼저 구분해야 했던 것은 지출의 의미였다. ‘이번 달 지출’이라는 단어 안에는 소비한 금액과 실제로 빠져나갈 금액이라는 서로 다른 관점이 섞여 있다.
90만 원짜리 물건을 3개월 무이자 할부로 구매했다고 가정해 보자.
| 월 | 구매 기준 소비액 | 할부 납부 예정액 |
|---|---|---|
| 구매월 | 900,000원 | 300,000원 |
| 다음 달 | 0원 | 300,000원 |
| 그다음 달 | 0원 | 300,000원 |
이 표의 금액과 거래는 구조를 설명하기 위한 가상 사례다.
구매월에 30만 원만 소비한 것으로 표시하면 실제 소비가 작아 보인다. 반대로 구매월에 90만 원을 기록하고, 이후 할부 납부액을 모두 새로운 소비로 추가하면 같은 물건을 여러 번 구매한 것처럼 계산된다.
그래서 다음 원칙을 정했다.
구매 시점: 할부 구매라도 원금 전액을 소비로 기록한다.
납부 시점: 매월 청구되는 할부금은 현금 유출 예정액으로 관리한다.
카드대금 납부: 이미 기록한 소비와 중복 집계하지 않는다.
유이자 할부: 월 청구액과 수수료는 카드사 명세서 기준으로 확인하고 추정값과 구분한다.
이렇게 나누니 ‘얼마를 소비했나?’와 ‘앞으로 얼마를 준비해야 하나?’에 각기 다른 지표로 답할 수 있었다.
거래 한 줄을 네 개의 숫자로 읽는다
원칙을 정해도 입력할 때마다 머릿속으로 판단해야 한다면 오래가지 못한다. 그래서 판단을 입력하는 사람이 아니라 수식에 맡겼다.
거래원장에서 사람이 직접 채우는 칸은 날짜, 거래명, 금액, 카테고리, 결제수단, 그리고 구분뿐이다. 구분은 지출·수입·이체·카드대금 납부·환불 다섯 가지 중에서 고른다. 이체나 카드대금 납부처럼 ‘돈은 움직였지만 소비는 아닌’ 거래를 지출과 같은 칸에 두지 않기 위해서다.
그 위에 각 행마다 수식 속성 네 개를 붙였다.
| 수식 속성 | 답하는 질문 | 설계 의도 |
|---|---|---|
| 소비액 | 이번 달 무엇을 샀나? | 구매 시점 기준. 할부도 원금 전액, 카드대금 납부는 중복 반영하지 않음 |
| 생활비사용액 | 생활비 기준선 대비 얼마나 썼나? | 전체 소비 중 생활비로 관리할 항목만 따로 집계 |
| 수입액 | 얼마가 들어왔나? | 수입으로 구분된 거래만 반영 |
| 현금변동 | 계좌에서 실제로 얼마가 움직였나? | 들어오면 플러스, 나가면 마이너스 |
구분값 하나만 정확히 고르면 나머지는 수식이 처리한다. 같은 거래라도 ‘어떤 질문에 대한 숫자인가’에 따라 다른 칸에 반영되고, 월별 예산 DB는 이 네 숫자를 각각 합산한다. 전체 소비액과 생활비 사용액이 서로 다른 숫자가 된 것도 이 설계 때문이다.
03. 할부와 대출은 미래의 약속을 관리하는 영역
할부 결제는 단순히 신용카드로 결제했다는 사실을 넘어선다. 오늘의 소비가 미래 몇 개월의 현금을 미리 점유한다는 의미다.
그래서 거래원장에는 구매 원금을 한 번 기록하고, 별도의 할부 관리 데이터베이스에는 할부 개월 수, 첫 청구일, 납부 확인 회차, 예상 월 납입액, 남은 회차, 남은 할부 원금 등을 저장했다. 이를 기반으로 이번 달과 다음 달의 할부 부담을 요약할 수 있도록 했다.
추정값과 명세서를 나란히 두기
할부 DB에서 가장 신경 쓴 부분은 월 청구 예상액과 월 청구액(명세서)을 별도 칸으로 둔 것이다. 예상액은 구매 원금과 개월 수로 계산한 값이고, 명세서 금액은 카드사가 실제로 청구한 값이다. 둘을 비교하는 청구액 검증 수식을 두어, 추정과 실제가 어긋나는 건을 바로 찾을 수 있게 했다.
이자 구분에도 무이자·유이자 외에 확인 필요라는 선택지를 따로 뒀다. 모르는 것을 무이자로 가정하는 순간, 숫자는 조용히 틀리기 시작한다.
각 할부 건은 거래원장의 원거래와 관계형으로 연결된다. 소비는 거래원장에서 한 번, 미래 청구는 할부 DB에서 회차별로. 같은 구매를 두 관점에서 보되 각 숫자는 한 번만 잡히게 한 구조다.
대출은 DB가 아니라 기준일이 있는 스냅샷으로
대출도 구분이 필요했다. 만기일시상환은 평소 이자를 내지만 만기에는 원금 상환이 발생할 수 있다. 원리금균등은 매월 원금과 이자가 함께 나간다. 둘을 단순히 ‘대출금’ 한 줄로 적으면 미래 지급 의무를 설명할 수 없다.
별도의 대출 관리 페이지에 대출 종류, 금리, 상환 방식, 납입일, 월 부담 추정, 만기일 확인 여부를 정리했다. 대출은 건수가 많지 않고, 잔액·금리·만기처럼 금융기관에서 확인해야 하는 정보가 대부분이다. 그래서 자동 계산보다 “언제 기준의 정보인가”를 명시하는 것이 더 중요했다. 페이지 상단에 기준일과 최종 갱신일을 적고, 새 대출 조건이 확인되면 페이지를 갱신하는 동시에 현금흐름 전망에도 이자 예상액을 반영했다.
여기서 중요한 것은 확신하지 못하는 정보를 확정된 수치처럼 쓰지 않는 일이었다. 계약 만기일이나 실제 청구 이자, 변동 금리처럼 확인되지 않은 값은 미확인 또는 추정으로 분리했다.
04. 대시보드에 거래 목록을 쌓는다고 대시보드가 되지는 않는다
초기 화면에는 거래 입력표, 달력, 미검증 거래, 고정비, 할부 상세표 등이 잔뜩 있었다. 기능은 많았지만 첫 화면을 열면 숫자보다 목록이 먼저 보였다.
이 지점에서 대시보드의 역할을 다시 정했다.
원장은 기록하는 곳이고, 대시보드는 판단하는 곳이다.
거래 목록을 메인 화면에서 빼고, 다음 질문에 답하는 카드와 차트를 앞에 배치했다.
| 대시보드 영역 | 확인할 질문 |
|---|---|
| 월간 핵심 지표 | 이번 달 수입과 소비, 남은 생활비, 순현금흐름은? |
| 카테고리 차트 | 지출이 어떤 분야에 집중됐는가? |
| 6개월 전망 | 앞으로 어느 시점에 현금이 부족해질 가능성이 있는가? |
| 할부 요약 | 이번 달과 다음 달에 납부할 금액은? |
| 대출 요약 | 매월 상환 부담은 어느 정도인가? |
원본 DB와 상세 페이지는 그대로 보존했다. 다만 상세 기록을 보는 행동과 재무 상태를 파악하는 행동을 분리한 것이다.
10월 17일 개편: 거래는 한 건도 보여주지 않는다
첫 정리 이후에도 요약 차트 아래에는 상세 표가 일부 남아 있었다. 개편에서는 원칙을 한 단계 더 밀어붙였다. 대시보드에는 거래를 한 건도 표시하지 않고, 입력과 수정은 모두 원본 DB에서 한다.
최종 레이아웃은 질문의 순서를 그대로 따라 여섯 구역으로 나눴다.
이번 달 핵심 지표 — 수입, 소비액, 남은 생활비, 순현금흐름 숫자 카드 4개
카테고리별 생활비 비중 — 생활비사용액 기준 도넛 차트
롤링 6개월 현금흐름 — 예상 수입·예상 지출 막대 차트와 예상 순현금흐름 선 차트
카드 할부 부담 — 이번 달·다음 달 청구 예정 등 숫자 카드
대출·안전자금 요약 — 스냅샷 페이지의 핵심 수치만
기록·설정·상세 확인 — 원본 DB와 상세 페이지로 가는 입구
숫자 카드에는 조건부 색상을 붙였다. 소비액이 생활비 기준선을 넘거나 남은 생활비가 음수가 되면 빨간색, 순현금흐름은 플러스면 파란색·마이너스면 빨간색이다. 숫자를 읽기 전에 색으로 먼저 상태를 알 수 있게 하려는 의도다.
각 구역 아래에는 그 숫자를 어떻게 읽어야 하는지를 짧게 붙였다. 예를 들어 할부 카드 아래에는 “할부 관리 DB에 등록된 건만 집계하므로, 0원이라고 해서 실제 할부가 없다는 뜻은 아니다”라는 문구가 있다. 0원과 ‘데이터 없음’은 다르다는 것을 화면에서 바로 알 수 있어야 했다.
05. 차트에 데이터가 보이지 않는 문제를 해결하며
만든 차트가 모두 처음부터 잘 작동한 것은 아니었다. 특히 이번 달 전체 소비액 차트에서 데이터가 표시되지 않는 문제가 발생했다.
원장에 거래가 없었을까? 실제 데이터를 조회해 보니 해당 월의 거래가 존재했고 월별 예산 관계형도 연결되어 있었다. 문제는 차트가 원본 숫자가 아니라 월별 예산 DB의 롤업 집계값을 대상으로 구성되어 있었다는 점이었다.
Notion 차트에는 롤업 속성에 대한 지원 제약이 있다. 그래서 이 차트는 거래원장의 숫자 속성인 금액을 직접 합산하는 방식으로 바꿨다. 월별 날짜 필터와 지출 유형 필터를 적용하고, 실제 조회 건수와 금액 합계를 비교해 검증했다.
같은 제약은 6개월 전망 차트에서도 고려해야 했다. 월별 현금흐름 DB의 합계는 예정 거래를 롤업한 값이다. 그래서 차트 전용 수식 속성(차트용 예상수입·차트용 예상지출)을 따로 두고, 차트는 그 값만 읽도록 했다. 집계하는 속성과 보여주는 속성을 분리한 셈이다.
이 과정을 거치며 세 가지를 배웠다.
데이터가 존재하는지와 차트가 데이터를 표시할 수 있는지는 별개다.
복잡한 집계 속성을 무조건 차트에 연결하기보다, 지원되는 원본 숫자 속성을 활용하는 편이 안정적일 수 있다.
모양이 완성된 대시보드보다 숫자가 검증된 대시보드가 먼저다.
한 차트를 고쳤다고 전체가 완성된 것은 아니다. 다른 월간 지표 중에는 기존 롤업 설계나 특정 월로 고정된 필터를 추가 점검해야 하는 부분이 남았다. 구현 완료와 검증 완료를 혼동하지 않는 것도 중요한 원칙이 됐다.
06. 6개월 현금흐름을 동적으로 만드는 방법
처음의 현금흐름 계획은 특정 날짜에서 시작해 여섯 달 후 끝나는 고정 보고서였다. 급여, 월세, 관리비, 통신비, 구독, 보험, 카드, 대출, 생활비 같은 예정 거래를 월별로 연결해 합계를 만들었다.
금액이 바뀌면 합계가 갱신된다는 점은 유용했지만 시간이 지나도 같은 여섯 달이 계속 보인다는 문제가 있었다. 이 문제를 해결하기 위해 Rolling 6개월 방식을 적용했다.
월별 현금흐름 DB에 롤링 기간을 판단하는 Notion 수식을 추가했다. 이 수식은 현재 월의 첫날을 계산한 다음, 그날부터 6개월 뒤 첫날 직전까지 포함되는 월을 선택한다.
and(
prop("시작일") >= parseDate(formatDate(now(), "YYYY-MM-01")),
prop("시작일") < dateAdd(
parseDate(formatDate(now(), "YYYY-MM-01")),
6,
"months"
)
)차트에서 쓰기 편하도록 롤링 표시월이라는 텍스트 수식도 하나 더 뒀다. 6개월 구간 안에 있는 달이면 월 이름을, 아니면 빈 값을 돌려준다. 그러면 세 개의 차트 모두 ‘롤링 표시월이 비어 있지 않음’이라는 필터 하나만 걸면 된다. 날짜 필터를 매달 손으로 바꿀 필요가 없다.
이 조건을 차트에 적용해 예상 수입, 예정 지출, 예상 순현금흐름을 따로 표시했다. 예정 거래의 금액이나 처리 상태가 바뀌면 월별 집계도 달라지도록 연결했다.
예정 거래에는 두 개의 꼬리표를 단다
예정 원장의 각 행은 예상단가 × 수량으로 금액을 계산하고, 단계와 산정기준이라는 두 가지 꼬리표를 붙인다.
단계: 아이디어 → 예정 → 확정 → 완료, 또는 취소. 예정과 확정만 미래 현금흐름 합계에 들어가고 완료·취소·아이디어는 빠진다. 실제로 돈이 나가면 거래원장에 기록하고, 대응하는 예정 거래를 완료로 바꾼다. 이 한 번의 처리가 실적과 계획이 이중으로 잡히지 않게 하는 연결 고리다.
산정기준: 사용자가 확정해 준 금액인지, 기존 납입 패턴에서 가져온 값인지, 이자 계산 추정인지, 생활비 가정인지, 아직 입력을 기다리는 값인지를 고른다. 같은 ‘예정 지출’이라도 근거의 단단함이 다르다는 것을 행마다 남겨 두었다.
기존에는 91건의 예정 거래가 있었다. 원본을 유지한 채 새로운 대출 이자 추정 거래와 장래 정기지출을 추가해, 작업 당시 총 265건의 예정 거래와 18개월분의 월별 기록을 마련했다.
다만 여기서 ‘동적’이라는 말을 정확히 써야 한다. 표시할 6개월 구간은 자동으로 움직이고, 등록된 계획이 바뀌면 합계도 움직인다. 반면 아직 존재하지 않는 미래 월과 모든 결제 기록을 무한히 생성하는 완전 자동화는 구현하지 않았다. 사전 생성한 기간 이후에는 거래를 추가하는 작업이 필요하다.
07. 정확한 숫자보다 먼저 필요한 것은 정확한 의미
이 과정에서 예산을 정의하는 용어 자체도 다시 보게 됐다.
가령 한 달에 반드시 필요한 최소 생활비와 한 달에 넘지 않으려는 소비 한도는 다르다. 그런데 초기 설계에서는 이 두 개념이 혼동되어 ‘생활비 상한’이라는 속성으로 표시되기도 했다. 최소 생활비를 최대 허용 소비액으로 취급하면 계산이 맞아도 해석은 틀어진다.
대출에서도 비슷한 문제가 있다. 대출을 새로 받으면 현금 유입은 생기지만 소득이 늘어난 것은 아니다. 마이너스통장의 미사용 한도도 현금 잔액이 아니다. 또 카드대금의 예정액을 실제 지출과 무심코 더하면 중복된다.
그래서 서로 다른 데이터는 뜻부터 분리해야 한다.
실제: 이미 일어난 입금·출금, 확인된 거래
예정: 앞으로 지급하거나 받을 것으로 등록한 항목
추정: 금리·납부 패턴 등 가정으로 산출한 금액
미확인: 존재할 가능성은 있지만 아직 조건이나 금액이 확정되지 않은 항목
같은 원칙을 과거 기록에도 적용했다. 특정 날짜 기준으로 계산해 둔 수치표는 지우지 않고 ‘과거 스냅샷, 자동 갱신 안 됨’이라는 표시를 붙여 남겼다. 바로 아래에는 실시간으로 갱신되는 표와 차트를 두어, 어느 숫자가 살아 있는 값이고 어느 숫자가 그날의 기록인지 헷갈리지 않게 했다.
특히 미래에 카드 할부가 끝난 것처럼 보이면서 수입이 지출보다 커지는 경우, 그것이 실제 흑자를 의미하는지는 다시 확인해야 한다. 미확인된 카드 청구액이나 대출 만기 상환이 전망에서 누락됐기 때문일 수 있다.
08. 전체 구조: 실적 축과 계획 축
지금까지의 구조를 한 장으로 정리하면 두 개의 축으로 나뉜다.
| 축 | 구성 | 역할 |
|---|---|---|
| 실적 | 거래원장 → 월별 예산 | 이미 일어난 거래를 한 줄씩 기록하고, 네 가지 숫자로 월별 합산 |
| 실적 보조 | 할부 관리 ← 거래원장(원거래) | 과거의 구매가 만들어 낸 미래 청구를 회차별로 관리 |
| 계획 | 예정 수입·지출 원장 → 월별 현금흐름 | 앞으로 일어날 현금 이벤트와 롤링 6개월 전망 |
| 참고 | 대출 현황 페이지 | 기준일이 명시된 스냅샷 |
| 요약 | 대시보드 | 위 데이터의 차트 뷰만 배치, 직접 입력 없음 |
두 축은 아직 자동으로 연결되어 있지 않다. 실적은 실적대로, 계획은 계획대로 합산하고, 둘 사이의 다리는 ‘예정 거래를 완료로 바꾸는’ 사람의 확인 한 번이다. 불편하지만, 적어도 숫자가 어디서 넘어갔는지는 언제든 추적할 수 있다.
09. 실제로 완성된 것과 남아 있는 것
| 기능 | 현재 상태 |
|---|---|
| 거래원장·월별 예산 | 관계형 연결과 집계 구성, 거래별 소비·생활비·수입·현금변동 수식 |
| 소비액 차트 오류 | 원장 직접 합산으로 수정 및 조회 검증 |
| 대시보드 개편 | 거래 목록 제거, 6개 구역·숫자 카드·조건부 색상·해석 주의 문구 적용 |
| 할부 관리 | 구매 원금과 미래 납부 예정액 분리, 명세서 대조 칸 |
| 대출 관리 | 기준일 스냅샷 페이지, 확인·미확인 구분 |
| 롤링 6개월 전망 | 기간 자동 선택과 수입·지출·순현금흐름 차트 반영 |
| 미래 정기 거래 | 2028년 3월까지 사전 등록 |
| 이번 달 지표의 월 자동 전환 | 일부 지표의 월 필터가 고정되어 있어 매월 갱신 필요 |
| 은행·카드 자동 연동 | 미구현 |
| 실제 거래와 예정 거래 자동 매칭 | 미구현, 납부 시 직접 완료 처리 필요 |
| 무기한 반복 거래 자동 생성 | 미구현 |
| 실시간 시작 잔액 기반 잔고 예측 | 최신 현금잔액 확인과 실적 대사 필요 |
이후 개선해야 할 순서도 보인다. 가장 가까운 과제는 이번 달 지표의 월 필터다. 롤링 차트처럼 ‘이번 달인가’를 수식으로 판단하게 바꾸면 매달 손으로 날짜를 고칠 필요가 없어진다. 그다음 카드·계좌의 실제 청구와 납부를 검증하고, 예정 거래와 실제 거래를 한 번만 반영하도록 대사 체계를 만들어야 한다. 그래야 예상 월말 잔액이나 현금 부족 알림을 신뢰할 수 있다.
10. 좋은 Finance OS는 데이터베이스가 아니라 질문으로 완성된다
이번 작업에서 가장 크게 변한 것은 페이지의 모습보다 관리 기준이었다.
처음에는 많은 것을 관리하기 위해 가능한 많은 구조를 만들고 싶었다. 하지만 시스템을 줄이고 다시 확장해 보니 중요한 질문은 오히려 단순했다.
나는 얼마를 소비했는가? 앞으로 언제 얼마를 내야 하는가? 그리고 그때 현금이 충분한가?
이 세 질문을 구분하니 원장이 기록해야 할 것, 대시보드가 보여줘야 할 것, 할부와 대출이 별도로 관리되어야 할 이유가 분명해졌다.
아직 완벽한 자동화 시스템은 아니다. 하지만 최소한의 입력으로 소비를 이해하고, 몇 달 뒤의 지급 부담을 예상하고, 무엇이 확인된 숫자이고 무엇이 가정인지를 구분할 수 있는 출발점은 생겼다.
가계부의 목적은 지출을 많이 기록하는 것이 아니다. 미래의 선택을 조금 더 잘하게 만드는 것이다.
2026년 10월 15일 작업 기록, 10월 17일 대시보드 개편 내용 추가. 이 글은 개인 Notion Finance OS를 만든 과정을 일반화한 내용이며, 실제 거래 내역과 금액은 포함하지 않았다. 예시 구매 금액은 가상이다.