프리랜서, 소규모 사업자, 개인 재무를 위한 예시 구성
이 가이드에서는 다양한 요구에 맞게 Beancount 원장을 조정하는 방법을 살펴봅니다: 프리랜서 전문가, 부티크 소규모 사업자, 그리고 개인 가계 재무입니다. 각 시나리오에는 고유한 계정 구조와 고려 사항이 따릅니다. 각 설정의 근거를 설명하고, 예시 Beancount 스니펫을 제공하며, 추적을 더 쉽게 만들어 주는 유용한 기능(사용자 정의 태그, 자동 가져오기 등)을 강조합니다. 어조는 교육적이면서도 친근합니다 – 개발자든, 기술에 능숙한 전문가든, 재무 애호가든, 이 예시들은 Beancount를 실제 세계에 적용하는 데 도움이 될 것입니다.
프리랜서
프리랜서(소프트웨어 개발자나 그래픽 디자이너 등)는 종종 여러 클라이언트와 프로젝트 비용을 동시에 다룹니다. 간단한 Beancount 설정은 각 클라이언트로부터의 수입, 사업 비용(고용한 하청업체 포함), 그리고 세금을 위해 따로 떼어 둔 자금을 추적하는 데 도움이 됩니다. 목표는 프리랜서 사업이 성장함에 따라 확장될 수 있도록 불필요한 복잡성 없이 간결하게 유지하는 것입니다.
프리랜서를 위한 핵심 계정: 프리랜서 원장은 일반적으로 사업 재무와 개인 재무를 분리합니다. 예를 들어 다음과 같이 사용할 수 있습니다:
- Assets:Business:Checking – 모든 클라이언트 지급금과 사업 비용을 위한 사업용 은행 계좌.
- Assets:Business:TaxSavings – 세금 납부를 위해 수입의 일부를 따로 떼어 두는 저축 계좌(고용주가 세금을 원천징수해 주지 않기 때문입니다).
- Income:Client:Name – 클라이언트 지급금을 위한 수입 계정. 주요 클라이언트별로 하위 계정을 만들거나(예:
Income:Client:ACME), 단일Income:Freelance계정을 사용하고 거래에 클라이언트 이름을 태그할 수 있습니다. - Expenses:Business:Contractors – 하청업체나 외주 작업에 대한 지급금.
- Expenses:Business:Software (그리고 Travel, Supplies와 같은 다른 카테고리) – 정기적인 사업 비용(소프트웨어 구독, 장비, 클라이언트 사이트 방문 여행 등)을 위한 계정.
- Equity:OwnerDraw – (선택 사항) 사업 이익을 개인적으로 자신에게 이전한 것을 기록합니다. 자신에게 급여를 지급할 때 사업 자금과 개인 자금을 구분하는 데 도움이 됩니다.
근거: 이 구조는 모든 사업 관련 자금이 전용 계정에 추적되도록 보장합니다. 각 클라이언트로부터의 수입이 기록되고(주요 클라이언트가 누구인지 쉽게 확인 가능), 비용은 세금 공제를 위해 분류됩니다. 별도의 자산 계정에 세금을 따로 떼어 두거나(또는 납부해야 할 세금에 대한 부채를 기록함으로써) 정부에 납부해야 할 자금을 실수로 지출하는 것을 방지합니다. 원장은 간결하게 유지됩니다: 새로운 클라이언트나 비용 카테고리가 생기면 모든 것을 재구성할 필요 없이 새 계정을 추가하거나 태그를 사용할 수 있습니다. 흔한 함정은 개인 거래와 사업 거래를 한 계정에서 섞는 것입니다. 전용 사업용 당좌 계좌(그리고 그에 대응하는 자산 계정)를 유지함으로써 조정과 보고가 더 깔끔해집니다. 피해야 할 또 다른 함정은 세금이나 사업주 인출을 위한 현금 이체를 기록하는 것을 잊는 것입니다 – TaxSavings와 OwnerDraw 같은 계정을 사용하면 모든 달러가 설명됩니다.
강조할 Beancount 기능: 태그와 메타데이터는 프리랜서에게 매우 유용합니다. 예를 들어, 거래에 프로젝트나 인보이스 번호를 태그하거나, 클라이언트별로 별도의 수입 계정을 사용하지 않기로 선택한 경우 메타데이터 필드를 사용해 클라이언트 이름을 기록할 수 있습니다. 이렇게 하면 특정 클라이언트나 프로젝트에 대한 거래를 쉽게 필터링하거나 쿼리할 수 있습니다(예: #ProjectX로 태그된 모든 비용 합산). 또한, Beancount의 자동 가져오기 도구는 데이터 입력을 간소화할 수 있습니다 – 예를 들어, 은행이나 신용카드 명세서용 가져오기를 설정하여 거래를 원장으로 가져온 다음 적절한 비용 또는 수입 계정 이름만 추가할 수 있습니다. 이는 많은 소액 거래(소프트웨어 구독이나 여행 비용 등)가 있을 때 시간을 절약해 줍니다.
프리랜서 예제 원장 스니펫
다음은 프리랜서 개발자를 위한 간단한 Beancount 스니펫입니다. 몇 가지 핵심 계정을 열고, 클라이언트로부터의 지급금, 하청업체에 대한 지급금, 일반적인 사업 비용, 그리고 세금 저축 계좌로의 자금 이체를 보여줍니다. (실제로는 여행이나 장비 구매와 같은 다른 비용도 비슷하게 기록하게 됩니다.)
1970-01-01 open Assets:Business:Checking
1970-01-01 open Assets:Business:TaxSavings
1970-01-01 open Income:Client:ACME
1970-01-01 open Expenses:Business:Contractors
1970-01-01 open Expenses:Business:Software
; Client income – payment for an invoice
2025-08-15 * "Invoice payment from ACME Corp"
invoice: "INV-2025-08-15"
Assets:Business:Checking 5000 USD
Income:Client:ACME -5000 USD
; Regular expense – e.g. software subscription for the business
2025-08-05 * "GitHub Subscription"
Expenses:Business:Software 15 USD
Assets:Business:Checking -15 USD
; Contractor expense – paying a subcontractor for help
2025-08-20 * "Contractor payment – Jane Doe"
Expenses:Business:Contractors 2000 USD
Assets:Business:Checking -2000 USD
; Tax withholding – moving money to tax savings
2025-08-31 * "Set aside Q3 taxes" #tax
Assets:Business:TaxSavings 1500 USD
Assets:Business:Checking -1500 USD무슨 일이 일어나고 있는지 분석해 봅시다:
- 맨 위에서 필요한 계정을 open 합니다(시작 날짜와 함께). Beancount는 사용되기 전에 모든 계정이 열려 있어야 합니다 — 선언되지 않은 계정에 대한 posting은 로드 오류입니다 — 따라서 이
open지시문은 선택적 스타일이 아니라 필수입니다.Assets:Business:Checking과Assets:Business:TaxSavings계정은 USD 잔액을 보유합니다. 수입 및 비용 계정은 거래 통화를 상속받으므로(이 경우 USD) open 지시문에서 통화를 생략할 수 있습니다. - 클라이언트로부터의 인보이스 지급: _2025-08-15_에 수입 거래가 인보이스에 대한 클라이언트 지급금 $5,000을 기록합니다.
Income:Client:ACME를 크레딧하고(복식부기에서 수입은 음수 금액으로 증가), 당좌 계좌를 차변에 기입합니다. 인보이스 번호를 기록하기 위해 메타데이터 필드invoice: "INV-2025-08-15"가 포함됩니다 – 이는 선택 사항이지만 거래에 추가 정보를 첨부하는 방법을 보여줍니다. 빠른 필터링을 위해 이 거래를#ACME또는#client-ACME로 태그할 수도 있습니다. 여러 클라이언트가 있다면, 많은 하위 계정을 만드는 대신 일반Income:Clients계정을 사용하고 그러한 메타데이터나 Payee 필드에 의존하여 클라이언트를 구분할 수 있습니다. - 사업 비용(소프트웨어): _2025-08-05_에 GitHub 구독(비공개 저장소나 기타 서비스를 위한 것일 수 있음)에 $15의 비용을 기록합니다. posting은
Expenses:Business:Software로 가고 사업용 당좌 계좌를 줄입니다. 이와 같은 소액의 반복 비용은 태그될 수 있습니다(예를 들어, 아래 세금 거래에#tax를 추가했습니다. 마찬가지로 매월 발생하는 특정 비용을#recurring으로 태그할 수 있습니다 등). 이 경우 계정 이름 자체(Software)가 명확하게 해 줍니다. - 하청업체 지급: _2025-08-20_에 프리랜서가 하청업체(Jane Doe)에게 $2,000을 지급했습니다. 이는
Expenses:Business:Contractors의 비용으로 기록되고 당좌 계좌에서 현금이 나갑니다. 내레이션에 하청업체 이름을 포함하거나(우리가 그랬듯이) 메타데이터 필드(예:contractor: "Jane Doe")로 포함할 수 있습니다. 이는 누구에게 왜 지급했는지에 대한 감사 추적을 유지합니다(세금 신고나 예산 편성 중 세부 정보가 필요할 때 유용합니다). - 세금 저축 이체: _2025-08-31_에 프리랜서가 주 당좌 계좌에서 전용 세금 저축 계좌로 $1,500을 이체합니다. 가시성을 위해 이 거래를
#tax로 태그했습니다. 이것은 비용이 아니고(자신의 돈을 옮기는 것일 뿐), 두 자산 계정 사이를 이동합니다. 매월 또는 분기마다 이렇게 함으로써 추정 세금을 충당할 자금을 축적합니다. 실제로 정부에 세금을 납부할 때가 되면 비용(예:Expenses:Taxes)과 TaxSavings(또는 Checking) 계정에서의 차감을 기록하게 됩니다. 흔한 함정은 이 이체를 보고서에서 비용으로 취급하는 것입니다 – 기억하세요, 이것은 비용이 아니라 예방적 배분일 뿐입니다. IRS/세무 당국에 대한 실제 세금 납부만이 비용입니다(또는 그렇게 추적한다면 발생 세금 부채의 감소).
요약: 프리랜서의 Beancount 원장은 단순성과 명확성을 강조합니다. 사업과 관련된 모든 수입과 유출은 체계적으로 기록됩니다. 의미 있는 계정 이름과 때때로 태그/메타데이터를 사용하면 클라이언트별 또는 비용 카테고리별 보고서를 쉽게 생성할 수 있습니다(예: 클라이언트별 총 수입, 올해 하청업체에 지출한 총액 등). 이 설정은 확장 가능합니다 – 사업이 발전함에 따라 새로운 클라이언트나 비용 카테고리를 추가할 수 있습니다. 자동 가져오기(은행 거래를 가져오기 위한)와 프로젝트나 인보이스용 사용자 정의 태그 같은 기능을 통해 Beancount는 프리랜서의 회계 부담을 크게 줄이면서 언제든 재무 상태를 명확하게 보여줄 수 있습니다.
소기업
다음으로, 작은 부티크 전자상거래 사업을 고려해 봅시다 – 예를 들어, 수공예품을 판매하는 온라인 상점입니다. 이 시나리오는 재고 관리, 매출원가(COGS), 그리고 온라인 결제 처리업체 처리를 비롯한 복잡성을 추가합니다. Beancount는 사려 깊은 계정 구조와 거래 기록 방법으로 이를 수용할 수 있습니다. 사업이 재고에 있는 제품을 추적하고, 온라인 플랫폼(결제를 위한 Stripe가 있는 Shopify 등)을 통해 판매를 기록하며, 일반적인 사업 비용을 기록하는 사례를 사용하겠습니다.
부티크 전자상거래 사업을 위한 핵심 계정: 기본 은행 및 비용 계정 외에도, 소매 사업 원장은 재고와 판매 흐름을 추적하기 위한 계정을 포함합니다:
- Assets:Bank:Checking – 사업의 당좌 계좌(공급업체 지급, 운영 비용 지불, 결제 처리업체로부터의 이체 수령용).
- Assets:Stripe:Balance (또는 Assets:PayPal 등) – 아직 은행에 도달하지 않은 온라인 결제로 수집된 자금을 위한 청산 계정. 예를 들어, 고객이 Stripe를 통해 결제하면 돈이 은행에 일괄 입금되기 전에 Stripe 계정에 남아 있을 수 있습니다.
- Assets:Inventory:Product – 제품용 재고 계정. 각 제품(또는 제품 카테고리)을 Beancount의 상품으로 취급하여 보유 수량을 추적할 수 있습니다. 예를 들어,
Assets:Inventory:Widgets는 현재 재고에 있는 "Widget" 품목의 수량을 원가로 평가하여 보유할 수 있습니다. - Income:Sales – 제품 판매 수익을 기록합니다. 사업이 여러 채널을 가지고 있다면 다른 판매 채널용 하위 계정(예:
Income:Sales:Online대Income:Sales:InStore)을 사용할 수 있지만, 하나의 판매 수입 계정으로 간단하게 유지하겠습니다. - Expenses:COGS – 매출원가, 판매될 때 재고 품목의 원가 기준을 포착합니다. 이 계정은 일정 기간 동안 판매된 재고가 (사업주인) 당신에게 얼마의 비용이 들었는지 효과적으로 보여줍니다. 매출총이익을 계산하는 핵심 구성 요소입니다.
- Expenses:Fees – 결제 처리 수수료와 플랫폼 수수료용(Stripe 수수료, Shopify 수수료, PayPal 수수료 등 모두 여기에 기록될 수 있음). 원한다면 이를 더 세분화된 계정(예:
Expenses:Fees:Stripe와Expenses:Fees:Shopify)으로 나눌 수 있지만, 모든 거래 수수료에 대해 하나의 계정으로 충분할 수 있습니다. - Expenses:Operating – COGS에 직접 연결되지 않은 일반 사업 비용(마케팅, 웹 호스팅, 소프트웨어, 배송 용품 등). 이러한 항목은 다양한 비용 센터를 분석하기 위해 하위 계정(예:
Expenses:Marketing,Expenses:WebHosting,Expenses:Shipping)으로 나눌 수 있습니다. - Liabilities:SalesTax – (선택 사항, 해당하는 경우) 사업이 판매에 대한 판매세나 부가가치세를 징수해야 하는 경우, 이 부채 계정은 징수되었지만 아직 정부에 납부되지 않은 세금을 추적합니다. 그러면 각 판매는 세금 부분을 이 계정으로 분리하게 됩니다. 이렇게 하면 징수된 세금이 수입으로 계산되지 않고 세무 당국에 납부하기 위해 배정됩니다.
- Equity:OwnerEquity – (선택 사항) 사업주의 투자와 유보 이익을 나타냅니다. 사업이 시작되었을 때 사업주가 한 초기 자금 조달은 여기에 크레딧됩니다(현금이나 재고를 출자한 경우 은행이나 재고에 차변). 또한 사업주가 이익을 인출(분배)하는 경우 이 자본 계정에 대해 기록될 수 있습니다. 이렇게 하면 대차대조표가 균형을 유지하지만 일상적인 운영에서는 자주 등장하지 않습니다.
근거: 이 설정은 상품과 자금의 흐름을 분리합니다. 재고 구매는 즉시 비용으로 처리되지 않고 처음에는 대차대조표(자산으로)에 기록됩니다. 제품을 판매할 때만 그 원가를 비용 처리(COGS)하여, 적절한 이익 계산을 위해 수익과 관련 비용을 매칭합니다. 판매 수입은 총 판매 가격으로 기록되는 반면, 수수료는 별도로 기록되어 총 수익과 지불된 수수료를 모두 볼 수 있습니다(따라서 순 수익도). Assets:Stripe:Balance와 같은 청산 계정을 사용하면 입금을 조정하는 데 도움이 됩니다 – 돈은 Stripe에서 은행으로 일괄적으로 이동하며, 혼란 없이 그러한 이체를 기록할 수 있습니다. 새 상점 주인에게 흔한 함정은 재고를 제대로 기록하는 것을 소홀히 하는 것입니다 – 예를 들어, 모든 재고 구매를 즉시 비용 처리하는 것입니다. 이는 현금 흐름 추적에는 괜찮을 수 있지만 이익을 왜곡합니다: 재고를 비축하는 달에는 수익성이 낮아 보이고, 판매하는 달에는 재고가 더 일찍 구매되었음에도 불구하고 수익성이 더 높아 보입니다. 재고 자산 계정과 COGS를 사용함으로써 원가를 판매와 일치시킵니다. 또 다른 함정은 수수료나 환불을 회계 처리하지 않는 것으로, 이는 은행이나 Stripe 잔액이 기록된 수입과 일치하지 않게 할 수 있습니다. 우리는 수수료를 명시적으로 기록하고 Stripe 자산 계정을 사용하여 Stripe가 지불해야 하거나 지불한 것을 추적함으로써 이를 피합니다.
강조할 Beancount 기능: Beancount의 재고 추적은 상품과 원가를 처리하는 능력을 활용합니다. 각 제품은 상품 기호(예: WIDGET)가 될 수 있어 수량과 단위 원가를 모두 기록할 수 있습니다. 항목을 판매할 때 어떤 원가 로트를 줄이는지 지정하면 Beancount가 그것에서 인출합니다 — 전체 내용은 재고 및 예약 방법을 참조하세요. 기본 예약 방법은 STRICT이며, 이는 로트가 명확해야 함을 요구합니다. 그래서 예시에서 {10 USD}로 명시적으로 이름을 지정합니다. Beancount가 로트를 자동으로 선택하도록(가장 오래된 것 먼저) 하려면 open 지시문에서 계정을 FIFO로 설정하세요: open Assets:Inventory:Widgets WIDGET "FIFO". 예시에서는 명시적인 STRICT 형식을 사용하겠습니다. 메타데이터나 링크를 사용하여 판매와 해당 COGS 항목을 연결할 수도 있습니다(예: 두 거래에 동일한 주문 번호 사용, 또는 판매와 재고 감소에 #order1001과 같은 공유 태그를 사용하여 각 판매에 일치하는 COGS 항목이 있는지 쉽게 쿼리하거나 재확인). 또한 자동 가져오기가 여기에 도움이 될 수 있습니다: 스크립트를 사용하여 Shopify나 Stripe 지급 보고서에서 판매 데이터를 가져오거나, 은행 명세서를 가져와 비용 거래와 지급금을 포착할 수 있습니다. 이러한 반복적인 데이터 입력 작업을 자동화하면 분석에 더 많은 시간을 쓰고 숫자를 입력하는 시간을 줄일 수 있습니다.
소기업 예제 원장 스니펫
다음은 부티크 전자상거래 사업을 위한 간략한 Beancount 예시입니다. 재고 구매, 판매 기록(결제 처리 수수료가 차감된 상태), 그리고 해당 판매의 매출원가 기록을 보여줍니다. 실제로는 표시된 수수료 예시와 유사하게 다른 비용(플랫폼 수수료, 광고비 등)도 기록하게 됩니다. 통화는 USD이고 재고에서 상품으로 추적하는 "Widget"이라는 제품을 가정합니다.
1970-01-01 open Assets:Bank:Checking
1970-01-01 open Assets:Stripe:Balance
1970-01-01 open Assets:Inventory:Widgets WIDGET
1970-01-01 open Income:Sales
1970-01-01 open Expenses:COGS
1970-01-01 open Expenses:Fees
; Purchase inventory (50 units of Widget at $10 cost each)
2025-03-10 * "Bought 50 Widgets from SupplierCo"
Assets:Inventory:Widgets 50 WIDGET {10 USD}
Assets:Bank:Checking -500 USD
; Sale to customer (Order #1001 via online store, 2 Widgets sold)
2025-04-05 * "Sale Order #1001 (2x Widget via Shopify)"
Assets:Stripe:Balance 58 USD ; net payment received after fees
Expenses:Fees 2 USD ; processing fee (Stripe)
Income:Sales -60 USD ; revenue for 2 Widgets (@ $30 each)
; Cost of goods sold for the above sale (2 Widgets at $10 cost each)
2025-04-05 * "COGS for Order #1001 (2x Widget)"
Expenses:COGS 20 USD
Assets:Inventory:Widgets -2 WIDGET {10 USD}단계별로 무슨 일이 일어나는지 봅시다:
-
계정 열기: 당좌 계좌, Stripe 잔액 계좌, Widget용 재고 계좌(단위 추적을 위해 상품
WIDGET으로 선언됨), 그리고 핵심 수입 및 비용 계정(Sales, COGS, Fees)을 엽니다.Assets:Inventory:Widgets WIDGET을 선언함으로써 이 계정이 상품 "WIDGET"의 수량을 보유할 것임을 알립니다. 이는 Beancount가 여기서 상품 단위를 예상하도록 보장하며, 해당 단위에 원가를 첨부할 수 있습니다. -
재고 구매: _2025-03-10_에 재고를 구매합니다 – 공급업체로부터 Widget 50개를 개당 $10에 사서 총 $500의 비용이 듭니다. 거래는
Assets:Inventory:Widgets에50 WIDGET {10 USD}로 차변합니다. 이는 상품 WIDGET 50단위를 의미하며, 각각 10 USD의 기록된 원가로 재고 계정에 추가됩니다. 크레딧은Assets:Bank:Checking -500 USD(현금 지출)입니다. 여기서 비용 계정을 직접 건드리지 않았다는 점에 주목하세요. 우리는 구매를 재고 자산으로 자본화하고 있습니다. 이제 우리 대차대조표에는 $500 가치의 Widget 50개가 재고로 있습니다. (잔액 보고서를 실행하면 재고 계정은 $500 상당의 50 WIDGET 단위를 보여줄 것입니다.) -
판매 기록(주문 #1001): _2025-04-05_에 온라인 상점을 통해 Widget 2개 판매를 기록합니다. 내레이션에는 명확성을 위해 주문 번호가 포함됩니다. 이 거래는 세 개의 posting을 포함합니다:
Assets:Stripe:Balance 58 USD: 판매에서 받은 돈이지만 현재 Stripe에 있습니다(수수료 차감 후). 고객이 총 $60을 지불했다고 가정합시다. Stripe가 $2의 수수료를 가져갔고 $58이 이제 우리 Stripe 계정에 있습니다(나중에 은행으로 이체될 예정). $58을 Stripe의 자산으로 기록합니다.Expenses:Fees 2 USD: $2의 수수료가 사업 비용으로 기록됩니다. 이렇게 하면 손익계산서에 해당 비용이 반영되고, Stripe 자산과 수수료 비용을 합치면 총 고객 지불액과 같아집니다.Income:Sales -60 USD: 판매에서 $60의 수입을 기록합니다. (수입 계정은 크레딧으로 증가하므로 Beancount 표기법에서는 음수 금액입니다.)
이 거래 후 순 효과는: Income:Sales 60 증가, $58의 추가 자산(Stripe로부터의 미수금), 수수료에 대한 $2 비용입니다. Stripe가 나중에 $58을 우리 은행에 입금하면, 지급 날짜에
Assets:Bank:Checking 58 USD / Assets:Stripe:Balance -58 USD와 같은 간단한 이체를 기록하게 됩니다 – 이는 Stripe 계정에서 은행으로 자산을 이동시키며, 수입이나 비용에 영향을 미치지 않습니다(자산을 옮길 뿐입니다). 위에서 그 이체를 보여주지 않았지만, 모든 것이 이체된 후 Stripe 계정을 $0으로 유지하는 것은 실제 회계에서 중요한 단계입니다. -
판매에 대한 COGS 기록: 또한 _2025-04-05_에 판매된 Widget 2개의 원가를 기록하는 별도의 거래가 있습니다.
Expenses:COGS 20 USD를 차변하고Assets:Inventory:Widgets -2 WIDGET {10 USD}를 크레딧합니다. 이것이 하는 일은 재고에서 2단위를 제거하는 것입니다(각각 이전에 기록된 대로 $10의 원가가 있었으므로 총 $20). 우리는{10 USD}를 지정하여 Beancount에 어떤 원가 로트에서 인출할지 알립니다 – 이 경우 2025-03-10에 추가한 로트와 일치합니다. 이제 재고 계정에는 48개의 Widget이 남아 있고 $480의 관련 원가가 있습니다. $20은 COGS 비용으로 이동하며, 이는 손익계산서에 나타나 해당 상품의 원가만큼 매출총이익을 줄입니다. (이것을 기록하지 않으면 수입이 비용에 비해 과대 계상될 것입니다.) 명확성을 위해 별도의 거래를 사용하지만, 판매와 COGS를 하나의 다중 라인 거래로 결합하는 것도 가능합니다. 일부는 가독성과 조정을 위해 표시된 대로 분할하는 것을 선호합니다(각 COGS 항목을 주문에 명확하게 연결할 수 있습니다). 또한 이 COGS 항목이 주문 #1001에 해당함을 쉽게 볼 수 있도록 내레이션에 주문 번호를 반영했습니다. 재고가 관련된 경우 모든 판매에 일치하는 COGS 항목이 있는지 확인하는 것이 좋은 관행입니다 – 하나를 놓치면 재고 수량이 틀어집니다. 피해야 할 함정은 판매에 대한 재고 제거를 잊는 것으로, 이는 대차대조표에 유령 재고를 남기고 비용을 과소 계상합니다. Beancount의 재고 기능({}원가 표기법)을 사용하면 보유한 것보다 더 많은 단위를 제거하려고 할 때 이를 잡아내는 데 도움이 됩니다(이 경우 소프트웨어가 오류를 발생시킵니다).
요약: Beancount를 사용하는 소규모 사업은 놀랍도록 견고한 회계 시스템을 유지할 수 있습니다. 돈이 어디에 있고, 어디서 오며, 비용이 어떻게 흐르는지 추적하도록 계정을 구조화함으로써 수익성에 대한 정확한 그림을 얻습니다. 우리 예시는 재고와 판매를 처리하는 방법을 보여주었습니다. 인터넷 요금 지불(Expenses:Operating:Internet 대 Assets:Bank:Checking), 대출이나 투자 수령(Assets:Bank 대 Liabilities:Loan 또는 Equity:OwnerEquity), 또는 판매세 납부(납부 시 Liabilities:SalesTax 대 Assets:Bank)와 같은 다른 거래도 비슷하게 기록하게 됩니다. 핵심은 일관성입니다: 각 유형의 거래를 동일한 패턴으로 기록하면 Beancount가 장부의 균형을 유지합니다. 자동 데이터 가져오기(예: 월별 Stripe 수수료나 은행 거래 가져오기)와 사용자 정의 태그/링크(판매와 환불 같은 관련 거래를 연관시키기 위해) 같은 기능을 통해 시스템은 유연하면서도 효율적일 수 있습니다. 그 결과는 사업이 성장함에 따라 확장될 수 있는 정리된 원장입니다 – 전체 시스템을 재작업할 필요 없이 새로운 제품 재고 계정, 새로운 비용 카테고리, 또는 추가 수입원(예: 새로운 온라인 마켓플레이스)을 추가할 수 있습니다.
개인 재무
마지막으로, 개인 또는 가계 재무를 위해 Beancount를 사용하는 것을 고려해 봅시다. 이 설정은 일상 비용, 은행 계좌, 신용카드, 대출, 투자를 관리하는 개인이나 가족을 위한 것입니다. 여기서 강조점은 돈이 어디로 가는지(비용), 어디서 오는지(수입), 그리고 어떻게 저축되거나 투자되는지(자산과 부채) 추적하는 것입니다. Beancount는 복식부기의 엄격함으로 이중 계산이나 누락이 없도록 보장하면서, 재무에 대한 투명하고 사용자 정의 가능한 뷰를 제공함으로써 예산 앱을 대체하거나 보완할 수 있습니다.
개인 재무를 위한 핵심 계정: 개인 재무 원장은 일반적으로 다양한 자산, 부채, 수입, 비용 계정을 포함합니다:
- Assets:Bank:Checking – 수입 입금과 청구서 지불을 위한 주 당좌 계좌.
- Assets:Bank:Savings – 비상금이나 특정 목표를 위한 저축 계좌. (여러 저축이나 투자 계좌가 있을 수 있습니다 – 각각이 자산 계정이 될 수 있습니다.)
- Assets:Cash – 비용에 현금을 사용한다면, 인출과 현금 지출을 추적하기 위한 현금 계정이 있을 수 있습니다.
- Assets:Investments:Broker – 브로커리지, 퇴직 401(k)/IRA 등과 같은 투자 계좌. 이러한 계좌는 투자 유형별로 더 세분화되거나 기관당 하나의 계정으로 뭉칠 수 있습니다. 예를 들어,
Assets:Investments:VanguardIRA또는Assets:Investments:Robinhood. 투자 추적은 주식이나 펀드에 대한 상품을 포함할 수도 있지만, 너무 세부적이라면 기여금과 계정 잔액만 추적할 수 있습니다. - Liabilities:CreditCard:Name – 신용카드당 하나의 계정(예:
Liabilities:CreditCard:Visa또는 은행 이름별). 카드의 모든 구매가 여기에 기록되고(동일한 비용과 함께), 카드에 대한 지불은 이 부채를 줄이는 이체입니다. - Liabilities:Loan:Name – 모든 대출(학자금 대출, 모기지, 자동차 대출)은 부채 계정으로 추적될 수 있습니다. 원금 잔액과 각 지불에서 이자(비용)와 원금(부채 감소)을 분할하여 기록하게 됩니다. 이는 고급 측면이지만 완전한 재무 그림을 위해 중요합니다.
- Income:Salary (그리고/또는 Income:Bonus, Income:Interest 등) – 급여, 보너스, 이자 수입, 배당금 등을 기록하기 위해. 수입 계정을 통해 다양한 출처의 총 소득을 볼 수 있습니다. (급여에서 이미 세금이 원천징수된 경우, 당좌 계좌로의 순 입금을 수입으로 기록하거나, 총액과 원천징수 세금을 비용이나 부채로 기록할 수 있습니다 – 다양한 접근 방식이 있지만, 많은 사람은 개인 장부의 단순성을 위해 순 급여를 수입으로 기록합니다.)
- Expenses: 일반적으로 많으며, 자신에게 의미 있는 카테고리로 나뉩니다. 예를 들어: Expenses:Housing:Rent, Expenses:Food:Groceries, Expenses:Food:DiningOut, Expenses:Utilities:Electricity, Expenses:Entertainment, Expenses:Travel, Expenses:Taxes, Expenses:Misc – 지출 습관을 반영하는 모든 카테고리. 원하는 만큼 세분화하거나 일반화할 수 있습니다. 계정 계층은 집계에 도움이 됩니다(예:
Expenses:Food는 식료품과 외식을 모두 합산합니다). 일반적인 관행은 주요 그룹(Housing, Food, Transportation, Healthcare 등)에 대한 계층을 두는 것입니다. - Equity:Opening-Balances – 원장을 시작할 때 계정 잔액을 초기화하는 데 사용됩니다(모든 자산에서 부채를 뺀 값이 자본에 기록된 시작 순자산과 같도록). 시작 후에는 누적 순이익을 나타내기 위해 Equity:Retained-Earnings 또는 유사한 것을 사용할 수도 있습니다(개인 재무에서는 일반적으로 수입에서 비용을 뺀 값이 순자산으로 굴러가도록 합니다). 자본 계정은 일상적으로 덜 보이지만 회계 방정식의 균형을 보장합니다.
근거: 개인 재무 설정은 재무 생활을 하나의 일관된 시스템으로 포착하는 것입니다. 위의 각 계정은 다양한 종류의 재무를 분리하여 "이번 달에 음식에 얼마를 썼는가?"(Expenses:Food:* 합산), "얼마의 부채가 남았는가?"(Liabilities 계정 확인), 또는 "내 순자산은 얼마인가?"(자산 빼기 부채)와 같은 질문에 답할 수 있게 해줍니다. 여기서 복식부기의 큰 장점은 정확성입니다: 예를 들어, $100의 식료품 청구서를 신용카드로 청구하면 비용 그리고 부채 증가로 기록합니다. 나중에 신용카드를 지불하면 은행에서 카드로의 이체를 기록합니다 – 이는 부채를 갚지만 이미 기록된 식료품 비용을 이중 계산하지 않습니다. 복식부기 없이 흔한 함정은 신용카드 지불 자체를 비용으로 취급하여 $100을 효과적으로 두 번 계산하는 것입니다. Beancount는 설계상 이를 방지합니다. 피해야 할 또 다른 함정은 계정 조정 실패입니다: Beancount를 사용하면 잔액 검증이나 balance 지시문을 사용하여 예를 들어 원장의 당좌 계좌 잔액이 실제 은행 명세서와 일치하는지 확인할 수 있습니다. 이는 누락되거나 중복된 항목을 잡아냅니다.
강조할 Beancount 기능: 개인 재무의 경우 거래량 때문에 자동 가져오기가 특히 유용합니다. Beancount의 가져오기 프레임워크나 커뮤니티 스크립트를 사용하여 은행 거래, 신용카드 명세서, 심지어 투자 거래를 CSV, OFX 또는 API 소스에서 가져올 수 있습니다. 이는 모든 커피 구매를 수동으로 입력하는 시간을 줄여줍니다. 사용자 정의 태그는 계정이 할 수 없는 방식으로 데이터를 잘라내는 데 유용합니다. 예를 들어, 항공편, 호텔, 외식 여부에 관계없이 모든 휴가 관련 비용을 #vacation2025로 태그 – 그러면 그 휴가의 총 비용을 쉽게 쿼리할 수 있습니다. 또는 나중에 참조할 수 있도록 세금 공제 대상 항목을 추적해야 하는 경우 특정 비용을 #deductible로 태그할 수 있습니다. 반복 청구서(예: #monthly)를 태그하여 모든 구독과 고정 비용을 매년 검토할 수도 있습니다. 메타데이터는 메모나 영수증을 첨부하는 데 사용될 수 있습니다(예: 저장된 영수증 이미지가 있음을 나타내는 receipt: "path/to/file.jpg", 또는 상환 가능 항목을 추적하는 경우 category: "Work Expense"). 태그와 메타데이터의 유연성은 수십 개의 추가 계정을 만들지 않고도 개인 추적 요구에 맞게 시스템을 조정할 수 있음을 의미합니다.
지난달 은행 내보내기를 CSV to Beancount 변환기를 통해, 또는 .ofx, .qfx 또는 .qif 다운로드를 OFX & QIF to Beancount를 통해 실행하세요. 대부분의 개인 원장에는 이것으로 충분하며, 사용자 정의 가져오기가 생성해야 할 항목 형태를 보여줍니다.
개인 재무 예제 원장 스니펫
다음은 몇 가지 일반적인 거래를 포착한 개인 Beancount 원장의 예시 스니펫입니다: 신용카드로 청구된 일상 비용, 당좌 계좌에서 지불한 반복 청구서, 그리고 퇴직 투자 계좌에 대한 기여금. (간결성을 위해 계정을 열고 급여 수입을 기록하는 초기 설정은 이미 완료되었다고 가정합니다. 여기서는 지출과 저축 측면에 초점을 맞춥니다.)
1970-01-01 open Assets:Bank:Checking
1970-01-01 open Liabilities:CreditCard:Visa
1970-01-01 open Expenses:Food:Coffee
1970-01-01 open Expenses:Housing:Rent
1970-01-01 open Assets:Investment:401k
; Daily spending example (coffee on a credit card)
2025-09-10 * "Starbucks Coffee" #daily
Expenses:Food:Coffee 5.50 USD
Liabilities:CreditCard:Visa -5.50 USD
; Recurring monthly bill (rent paid from checking)
2025-09-01 * "Apartment Rent September" #recurring
Expenses:Housing:Rent 1200 USD
Assets:Bank:Checking -1200 USD
; Retirement contribution (transfer from checking to 401k investment)
2025-09-15 * "401(k) Contribution" #retirement
Assets:Investment:401k 500 USD
Assets:Bank:Checking -500 USD이 거래들을 해석해 봅시다:
- 계정 열기: 당좌 계좌, Visa 신용카드 계좌, Coffee 비용 계좌(Food 비용의 하위 카테고리 예시), Rent 비용 계좌, 401k 투자 계좌를 엽니다. 실제 원장에서는 사용할 계획인 모든 계정(저축, 기타 비용 카테고리, 수입 등)을 열게 됩니다. 우리는 스니펫에 필요한 것만으로 유지합니다.
- 일상 비용 – 커피: _2025-09-10_에 $5.50의 커피 구매가 기록됩니다. 비용은
Expenses:Food:Coffee아래에 분류되고, Visa 신용카드로 지불되었으므로Liabilities:CreditCard:Visa를 크레딧(증가)합니다.#daily태그가 추가되어 일상적인 지출 항목임을 나타냅니다 – 나중에 모든 일상적 재량 지출을 필터링하고 싶을 수 있습니다. 이 후 신용카드 계좌는 $5.50의 잔액을 표시할 것입니다(Visa에 $5.50을 빚지고 있음을 의미). 이 커피를 현금으로 지불했다면, 거래는 대신Assets:Cash를 크레딧(보유 현금 감소)할 것입니다. 직불카드 구매였다면Assets:Bank:Checking을 크레딧할 것입니다. 메커니즘은 비슷하고 계정만 다릅니다. - 반복 청구서 – 임대료: _2025-09-01_에 월 임대료 $1200 지불을 기록합니다. 이는 당좌 계좌에서 나오고(
Assets:Bank:Checking을 크레딧)Expenses:Housing:Rent로 분류됩니다. 반복 청구서임을 표시하기 위해#recurring으로 태그했습니다. 전체 원장에서는 매월 이와 똑같은 항목이 있을 수 있습니다. (Beancount에는 내장된 자동 반복 거래 기능이 없지만, 스크립트로 달성하거나 매월 복사-붙여넣기할 수 있습니다. 태그는 나중에 한 달을 놓치지 않았는지 확인하거나 1년 임대료를 빠르게 합산하는 데 도움이 됩니다.) 일부 사용자는 Beancount 가져오기 프레임워크를 통해 주기적 거래 기능을 사용하여 이를 자동으로 생성하지만, 이는 여기서 다루는 범위를 벗어나는 고급 사용법입니다. 핵심은 이 거래가 돈이 어디로 갔는지(주거 비용)와 감소된 은행 잔액을 명확하게 보여준다는 것입니다. 주의할 함정: 비용을 공유하거나 룸메이트가 있다면 임대료의 일부만 지불할 수 있습니다. 그 경우 거래를 자신의 몫과 다른 사람이 지불하는 몫으로 나눌 수 있습니다(다른 사람이 당신에게 지불하면 다른 몫을Income:Reimbursements로 기록할 수 있습니다). 우리의 간단한 경우에는 전액을 지불합니다. - 퇴직 기여금: _2025-09-15_에 $500이 당좌 계좌에서 401(k) 투자 계좌로 이동합니다. 이것은 비용이 아니라 자산을 한 형태(현금)에서 다른 형태(퇴직 기금)로 이전하는 것입니다. 거래는
Assets:Investment:401k를 차변하고Assets:Bank:Checking을 크레딧합니다. 명확성을 위해#retirement로 태그했습니다. 이 후 당좌 계좌 잔액은 500만큼 줄어들고, 원장의 401k 계좌 잔액은 500 USD가 나타내는 만큼 증가합니다(투자를 추적하는 방법에 따라 이후 그 현금으로 뮤추얼 펀드 단위를 구매할 수 있습니다 – 이는 투자 계좌의 또 다른 거래가 될 것입니다. 예: Y 가격에 펀드 X주 구매, 현금은 401k 자산에서 나감). 기본 개인 원장에서는 401k를 저축 계좌처럼 취급하고 주기적으로 잔액을 업데이트하거나 이와 같이 기여금을 기록하고 성장을 위해 가격 시세를 사용할 수 있습니다. 중요한 것은 이 거래가 이체이지 비용이 아니라는 것입니다 – 자산을 쌓는 것입니다. 많은 예산 도구는 퇴직 기여금을 "비용"으로 계산하지만(당좌 계좌에서 나가므로), 회계 용어로는 다른 주머니로 돈을 옮기는 것일 뿐입니다. 이 구분은 저축률과 지출을 이해하는 데 도움이 됩니다.
지원되는 증권의 단위로 기록된 투자의 경우, 실시간 가격이 호스팅된 원장에서 평가 시세를 유지할 수 있습니다. 현금만 있는 퇴직 잔액은 피드에서 증권 시장 가치를 얻을 수 없습니다. 실제 보유 자산을 기록하고 구매 원가를 명시적으로 유지하세요.
신용카드 청구서 지불 거래가 있었다면, 당좌 계좌에서 CreditCard 부채로 돈을 이체하는 것처럼 보일 것입니다(예: Liabilities:CreditCard:Visa 100 USD / Assets:Bank:Checking -100 USD). 이는 신용카드 잔액을 다시 낮추고(전액 지불했다면 아마 0으로) 그에 따라 은행 잔액을 줄이며, 비용 계정에는 영향을 미치지 않습니다 – 구매 시점에 이미 비용을 기록했기 때문입니다. 신용카드를 이런 방식으로 처리하는 것을 기억하는 것이 정확한 개인 재무 추적에 중요합니다. 지불을 태그하거나(일부는 #cc-payment 또는 유사한 것을 사용) 명확성을 위해 내레이션에 명세서 기간을 포함할 수도 있습니다.
요약: Beancount의 개인 재무 원장은 돈 추적에 규율과 구조를 부여하는 데 도움이 됩니다. 계정(그리고 선택적으로 태그)으로 거래를 분류함으로써 통찰력 있는 보고서를 생성할 수 있습니다: 카테고리별 월별 지출, 연간 총액, 얼마를 저축했는지 등. 복식부기 접근 방식은 모든 달러가 설명된다는 것을 의미합니다: 계정 잔액이 줄어들면 어딘가로 간 것입니다(다른 계정이 증가). 이는 오류를 잡아내고 더 단순한 추적 도구에서 흔한 "사라진 돈" 문제를 방지합니다. 자동화를 통해 대부분의 거래를 가져온 다음 검토하고 분류하기만 하면 되므로 유지 관리가 매우 실현 가능합니다. 시간이 지남에 따라 포괄적인 재무 일기를 만들게 됩니다 – 친구와 청구서를 나누거나(자본 계정이나 미지급금/미수금 계정 사용), 대출 상환 또는 투자 성과를 추적하는 것과 같은 영역으로 확장하기로 선택하면 그러한 것도 처리할 수 있습니다. 가장 기본적인 수준에서도(스니펫에 표시된 대로) Beancount는 일상 지출, 반복 의무, 장기 목표(퇴직 저축 등)를 향한 진행 상황에 대한 명확성을 제공합니다. 그리고 평문이므로 완전한 통제권을 가집니다: 스크립트를 작성하거나, 쿼리하거나, 다른 도구(친근한 뷰를 위한 웹 인터페이스 Fava 등)와 통합할 수 있습니다. 요컨대, 이 설정은 개인 재무를 분석하고 신뢰할 수 있는 데이터로 바꾸면서도 부담이 되지 않을 만큼 간단하게 유지합니다.
프리랜서든, 소규모 사업을 운영하든, 개인 자금을 관리하든, 상황에 맞게 Beancount 원장을 조정함으로써 평문 시스템의 유연성과 함께 체계적인 복식부기 접근 방식의 재무 추적 이점을 얻을 수 있습니다. 이러한 예시 구성은 여러분이 기반으로 삼을 수 있는 핵심 패턴을 보여줍니다. 사업이 성장하거나 재무 생활이 더 복잡해짐에 따라 필요에 따라 계정과목표를 확장하거나 고급 기능(예산, 차이 분석, 다중 통화 처리 등)을 사용할 수 있습니다. 핵심은 (표시된 것과 같은) 깔끔하고 논리적인 구조로 시작하여 일관되게 거래를 기록하는 것입니다. 그것이 갖춰지면 Beancount는 업종과 개인 시나리오 전반에 걸쳐 재무를 이해하고 관리하는 강력한 동반자가 될 것입니다. 즐거운 회계 되세요!