▲

10년간의 개인 재정을 일반 텍스트 파일로 관리한 기록

 (sgoel.dev)
2P by GN⁺ 19일전 | ★ favorite | 댓글 1개
  • Beancount를 이용해 10년간 개인 재정을 일반 텍스트 파일로 기록하며, 약 45,000줄의 데이터와 10,000건의 거래를 관리
  • 매달 30~45분을 들여 은행 명세서 CSV 파일을 가져와 수동·자동으로 정리하고, 연도별 파일로 분리해 가독성을 유지
  • 독일 은행용 Python 기반 importer 라이브러리를 직접 개발해 Beancount와 연동, 일부는 현재도 유지 관리 중
  • Beancount 입문자의 어려움을 느껴 초보자용 입문서를 집필했으며, 커뮤니티에서 긍정적 평가를 받음
  • 모든 데이터가 자신의 로컬 기기와 Git 저장소에 보관되어, 특정 앱이나 서비스보다 지속성과 통제력이 높음

10년간의 Beancount 원장 구조

  • 2016년부터 Beancount로 재정 데이터를 관리해 왔으며, 총 45,011줄의 항목이 16개의 .beancount 파일에 저장
    • main.beancount 파일을 중심으로 연도별 파일을 include 방식으로 연결
    • 전체 거래는 약 9,895건, 그 안의 posting(분개) 은 19,743개
  • 총 1,086개의 계정(account) 이 존재하지만, 이는 실제 은행 계좌가 아닌 가상 분류 계정으로 구성
    • 예: 슈퍼마켓 지출, 수입, 구독 서비스 등 세부 항목별 계정 생성 가능
  • 507개의 PDF 문서가 거래에 첨부되어 있으며, 세금 신고 시 관련 영수증을 쉽게 확인 가능
  • 연도별 posting 수는 2016년 715건에서 2023년 2,651건으로 증가, 2023년이 가장 활발한 해로 기록

월별 관리 절차

  • 매달 약 30~45분을 투자해 은행 명세서를 CSV로 다운로드 후 Beancount에 가져오기
    • CSV는 PDF보다 파싱이 용이해 사용
    • Python 기반 importer가 CSV 데이터를 Beancount 형식으로 변환
  • 변환된 거래를 .beancount 파일에 추가 후, 이중부기 원칙에 따라 잔액이 0이 되도록 조정
    • 일부는 자동 분류, 일부는 수동 조정
  • 새해가 시작되면 이전 연도의 거래를 <year>.beancount 파일로 이동하고, main.beancount에 포함시켜 관리
  • 모든 거래 내역이 하나의 디렉터리 내 텍스트 파일로 정리되어 있음

독일 은행용 Beancount Importer 개발

  • Beancount는 기본적으로 은행 명세서 형식을 알지 못하므로, importer 클래스를 통해 변환 필요
  • 독일 은행 계좌를 사용하기 때문에 직접 여러 importer를 개발
  • 첫 세 라이브러리는 현재도 활발히 유지·사용 중

사용자에서 저자로

  • Beancount의 문서는 방대하지만, 초보자에게는 진입 장벽이 높음
  • 시행착오 끝에 익힌 경험을 바탕으로 입문서를 집필
    • personalfinancespython.com에서 공개
    • Beancount 공식 문서의 external contributions 페이지에 언급
    • 독자 리뷰에서 긍정적 반응을 얻음

마무리

  • 모든 재정 데이터가 Git으로 버전 관리된 로컬 텍스트 파일로 저장되어 있음
  • 데이터가 자신의 기기에 존재하고, 특정 앱이나 서비스에 종속되지 않음
  • Beancount 생태계의 도구를 활용해 자유롭게 분석 가능
  • 이러한 plaintext accounting 방식은 어떤 앱보다 오래 지속될 수 있는 강력한 재정 관리 형태임
▲
GN⁺ 19일전  [-]
Hacker News 의견들

  • OP의 책에 전적으로 동의함. 지금까지 본 것 중 Beancount / plaintext accounting을 이해하기 위한 최고의 입문서였음
    나도 평생 복식부기를 잘 이해하지 못했는데, Martin Kleppman의 "Accounting for Computer Scientists"을 읽고 나서야 감이 잡혔음. 그래프 이론으로 설명하는 방식이 놀라울 만큼 직관적이었음

    • “Quicken은 단일식 회계 시스템이라 돈이 갑자기 생기거나 사라질 수 있음. 복식부기에서는 한 계정에 돈을 넣으려면 반드시 다른 계정에서 빼야 함”이라는 요약이 정말 핵심을 잘 짚었음. quicken2beancount에서 본 문장임
    • 복식부기가 어렵다고 느꼈다는 게 흥미로움. 사실 모든 거래는 두 계정을 동시에 건드리고, 차변과 대변의 합이 같아야 한다는 단순한 원리임. 그래프 이론이 그걸 더 단순하게 만든다는 게 잘 상상이 안 감
    • 언급해줘서 고마움, Michael!

  • 예전에 Quicken을 쓰다가 버전이 바뀔 때마다 데이터를 다시 입력해야 해서 결국 GNU Cash로 옮겼음. 하지만 마이그레이션 문제도 있었음
    그러다 plaintext accounting(PTA) 을 발견하고 hledger를 선택했음 (Beancount는 성능 이슈가 있을까봐). 복식부기를 배우니 생각보다 단순했음.
    PDF로 오는 투자 명세서나 급여 명세서를 Python 스크립트로 파싱하고, 은행/카드 CSV를 자동 분류하도록 만들어서 대부분 자동화했음.
    매달 한 시간 정도만 투자해서 투자 보고서, 예산, 세금 요약을 만들고 있음.
    plain text라서 포맷이 바뀌어도 데이터가 안전하고, git으로 버전 관리도 가능함.
    단점은 모바일에서 안 되고, 약간의 기술 지식이 필요하다는 점. 하지만 돈의 흐름이 중요한 사람이라면 이게 정답임

    • “다시 입력해야 했다”는 게 무슨 뜻인지 궁금함. 나는 1992년부터 Quicken을 써왔는데, 버전이 바뀌어도 데이터를 다시 입력한 적은 없음
    • 나도 Quicken에서 벗어나고 싶지만, Intuit 종속이 너무 강함. 2000년 이후 모든 거래가 독점 포맷에 묶여 있음.
      하지만 Quicken의 자동 동기화 기능은 여전히 최고라 대체가 어려움. 27개 계좌를 매일 확인하며 사기나 오류를 잡는데, CSV를 매번 내려받아 수동으로 처리하는 건 악몽임.
      게다가 요즘 은행들이 OFX를 닫고 Intuit를 중간 허브로 쓰는 추세라 탈출이 점점 더 어려워지고 있음

  • 개인 재정을 프로젝트 빌드 시스템처럼 관리해야 한다는 아이디어를 full-fledged-hledger에서 배웠음
    금융기관에서 받은 원본 데이터를 그대로 저장하고, 스크립트로 CSV로 변환한 뒤, 규칙 파일로 PTA 항목으로 매핑함.
    이렇게 하면 변환 로직이나 분류 규칙을 바꾸면 과거 데이터 전체가 자동으로 갱신됨.
    처음엔 한 달치 데이터로 시작해서 점차 확장할 수 있음 — 예를 들어 Amazon 주문 내역이나 Paypal 영수증까지 포함 가능함

    • “PTA가 왜 학부모회(Parent Teacher Association)랑 관련 있지?”라는 농담을 던짐
    • 주택담보대출 회계 처리가 헷갈렸는데, 그 링크가 좋은 설명을 제공함. 직접 그 코드베이스를 썼는지, 아니면 원리만 참고했는지 궁금함. Haskell을 몰라서 수정이 얼마나 필요한지도 모르겠음

  • 나는 몇 년째 Beancount를 사용 중임.
    올해부터는 OP처럼 연도별 파일 구조로 바꿨음. 예전엔 200만 줄짜리 단일 파일이었는데 Emacs 플러그인이 느려졌음.
    이 방식의 장점은 모든 걸 추적할 수 있다는 점임 — 투자, 연금, RSU, 은행 계좌 등. 심지어 전력 사용량(kWh) 까지 모델링할 수도 있음.
    최근엔 LLM을 활용한 자동화 도구를 많이 만들고 있음. 예를 들어 Claude로 트랜잭션 규칙 엔진을 UI가 있는 앱으로 리팩터링했음. 예전 같으면 며칠 걸릴 일이었음

    • 나도 전기요금을 kWh 단위로 추적해봤는데, 솔직히 별 쓸모가 없었음 😂
    • 나도 LLM으로 개인 재정 도구를 만들고 싶은데, 민감한 데이터 제공이 걱정됨. 익명화된 로컬 모델로 처리하는 게 나을 듯함

  • 많은 사람들이 plain text와 복식부기를 혼동하는 것 같음.
    Beancount는 둘 다 지원하지만, 복식부기를 몰라도 plain text 회계는 가능함.
    다만 복식부기는 지식을 체계화하는 훌륭한 도구라 배우는 걸 추천함.
    plain text 자체의 효용성은 좀 회의적임. 클라우드 종속이나 벤더 락인을 피하려는 반작용으로 보이지만, 로컬에서 자유 소프트웨어로 복식부기를 하면 충분함.
    내 결론은 다음과 같음:

    • 회계: 중요
    • 복식부기: 중요
    • 클라우드/락인 회피: 중요
    • 독점 포맷 회피: 중요
    • plain text: 중요하지 않음
      나는 GnuCash를 사용 중이며, 완벽하진 않지만 위 철학에 잘 맞음
    • 회계에는 자동화가 필수라고 생각함. 수작업은 오류가 많고, 정확성이 최우선(P0) 요구사항임
    • 나도 GnuCash를 사랑하면서도 미워함. UI가 너무 낡았음. 엔진을 라이브러리로 분리해 다양한 UI에서 쓸 수 있으면 좋겠음

  • 최근 PTA를 시작했는데, 진입 장벽이 꽤 높음.
    먼저 복식부기를 배우고, ledger-cli / hledger / beancount 중 하나를 선택해야 함. 차이는 미묘하고, 커뮤니티나 문서 품질이 결정 요인임.
    이후엔 어떤 계좌부터 가져올지, 얼마나 과거 데이터를 포함할지, 자동 임포터를 어떻게 설정할지 고민해야 함.
    hledger는 DSL을, Beancount는 Python을 사용함. 대부분의 시간은 수동 편집에 쓰임.
    그다음엔 예산, 세금, 배우자와의 공유 등 새로운 질문들이 생김.
    하지만 이런 질문들을 스스로 인식하게 되는 것 자체가 PTA의 진짜 가치라고 느낌.
    매년 연금, 보험, 인터넷 요금, 새 직장 제안 등 수많은 재정 결정을 할 때, 내 경제를 세밀히 이해하고 있다는 게 큰 힘이 됨

    • 나는 수학자이자 프로그래머, 그리고 금융 전공자라 복식부기를 일찍 배웠음. 그 추상적이고 우아한 시스템이 정말 아름답다고 느낌.
      ledger-cli와 Emacs를 10년째 쓰고 있고, 예전엔 GnuCash도 사용했음.
      입문용으로 내가 쓴 복식부기 교재도 있음
    • 복식부기는 익숙해지면 쉽지만, 처음엔 학습 곡선이 가파름.
      2018년부터 PTA를 써왔는데, 시행착오 끝에 얻은 교훈이 많음.
      상용 서비스들은 일부 계좌만 보여주지만, PTA는 전체 재정의 흐름을 완전히 파악할 수 있음.
      예를 들어 회사에서 받은 주식이 팔려서 은행 계좌에 입금될 때까지의 모든 과정의 출처(provenance) 를 추적할 수 있음
    • 개인 재정에는 복식부기가 과도한 오버킬이라고 생각함.
      나에겐 엑셀 스프레드시트가 완벽한 도구임. 매주 필요한 숫자만 추가함
    • 회계는 쉬워 보이지만, 배우기는 어렵다는 데 동의함.
      문헌이 모순되고 난해하며, 심지어 회계사조차 개념적으로 잘못 이해한 경우가 많음

  • 나는 단순한 방식으로 20년째 스프레드시트로 재정을 관리함.
    매달 5분 정도 업데이트하고, 전기·난방·보험·저축 등 핵심 항목만 추적함.
    목표는 지출 추세 파악과 연간 예산 확보임. 남는 돈은 그냥 소비함

    • 나도 비슷하게 함. 월별로 계좌 잔액, 소득, 세금, 투자이체, 주거비, 보험만 기록함. 이 정도면 재정 상태를 파악하기 충분함
    • 나도 예전엔 plain text로 하다가 결혼 후 공동 관리를 위해 스프레드시트로 전환함.
      $100 이상 지출만 따로 기록해서 큰 소비만 추적함
    • 나도 가계 재정은 스프레드시트로 하지만, 타인의 자금(신탁 등) 을 관리할 땐 hledger를 씀. 복식부기와 대조가 필요하니까
    • 자동화를 원한다면 Tiller를 추천함. 은행과 연동해 거래를 자동으로 스프레드시트로 가져오고, 예산 템플릿도 제공함
    • 나도 덜 집착하는 편이지만, 독점 서비스나 유료 앱은 싫음.
      은행/카드 CSV를 매달 내려받아 Python 스크립트로 분석함.
      LLM이 작성한 코드로 상점별 지출 추세를 분석하고, 한 카드에는 정기 결제만 전용으로 넣어 변동을 쉽게 파악함

  • Fava라는 Beancount용 GUI 프론트엔드를 추천함
    https://beancount.github.io/fava/
    계좌 전체를 시각화하고, 검색/쿼리 인터페이스와 실시간 편집 기능이 매우 유용함

  • 이 시스템이 정말 멋져 보이지만, 비기술적인 파트너와 함께 재정을 관리할 때는 어떻게 해야 할지 궁금함.
    우리는 YNAB을 쓰고 있는데, UI가 깔끔하고 협업이 쉬움. Beancount에서도 그런 인터페이스를 구현할 수 있을까?

    • 바로 아래 댓글에서 Fava를 추천함
    • iPhone을 쓴다면 MoneyStats 앱을 추천함. 예쁘고 설정이 쉬워서 함께 쓰기 좋음

  • 나도 예전에 PTA에 빠져서 로그를 남기기 시작했지만, 여러 은행에서 거래를 수동으로 내려받는 게 너무 번거로움
    자동화가 답이라는데, 실제로는 어떻게 하는지 궁금함 — Plaid 같은 API를 쓰는지, 웹 스크래퍼나 PDF 파서를 만드는지?
    결국 YNAB에 연 $130을 내고 있음. 배우자 만족도도 높고, 모든 게 자동으로 연결됨.
    YNAB API로 데이터를 백업해 PTA로 병행할 수도 있을 듯함

    • 나는 PDF 명세서 파서를 직접 만들었음. 일부는 PyMuPDF로 직접 작성했고, 일부는 Claude에게 샘플 명세서를 주고 생성하게 했음.
      금융업계가 이 부분에서 너무 뒤처져 있음. 자동화가 점점 늘고 있지만, 아직은 노력 대비 효율이 낮음
    • 오늘 아침에 나도 설정을 끝냈음. 2주마다 18개 계좌를 점검하는 게 즐거움이라, 나에겐 큰 부담이 아님.
      예전엔 YNAB을 썼는데, 중복 거래 문제가 자주 발생해서 결국 포기했음.
      세 번이나 초기화했지만 계속 오류가 나서, 결국 수동 추적으로 돌아갔음.
      지금은 PTA가 훨씬 안정적이고, 내가 통제하는 느낌이 듦
답변달기