프리랜서, 소기업, 개인 재무를 위한 예제 구성
이 가이드에서는 다양한 요구 사항에 맞게 Beancount 원장을 조정하는 방법을 살펴봅니다: 프리랜서 전문가, 부티크 소기업, 개인 가계 재무. 각 시나리오에는 고유한 계정 구조와 고려 사항이 있습니다. 각 설정의 근거를 설명하고, Beancount 스니펫 예제를 제공하며, 추적을 더 쉽게 만드는 유용한 기능(사용자 지정 태그, 자동 가져오기 등)을 강조합니다. 개발자, 기술에 능숙한 전문가, 재무 애호가 모두에게 유용한 실용적인 안내 톤으로 작성되었습니다.
프리랜서
프리랜서(소프트웨어 개발자나 그래픽 디자이너 등)는 여러 클라이언트와 프로젝트 지출을 동시에 관리하는 경우가 많습니다. 간단한 Beancount 설정을 통해 각 클라이언트의 수입, 사업 비용(하청업체 고용 포함), 세금을 위해 따로 떼어 둔 돈을 추적할 수 있습니다. 목표는 프리랜서 사업이 성장함에 따라 확장 가능하면서도 불필요한 복잡성 없이 간단하게 유지하는 것입니다.
프리랜서를 위한 주요 계정: 프리랜서 원장은 일반적으로 사업 재무와 개인 재무를 분리합니다. 예를 들어, 다음과 같은 계정을 사용할 수 있습니다:
- Assets:Business:Checking – 모든 고객 결제와 사업 비용을 처리하는 사업용 은행 계좌.
- Assets:Business:TaxSavings – (고용주가 세금을 원천징수하지 않으므로) 세금 납부를 위해 수입의 일부를 적립하는 저축 계좌.
- Income:Client:이름 – 고객 결제를 위한 수입 계정. 주요 고객별로 하위 계정(예:
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무슨 일이 일어나고 있는지 설명하겠습니다:
- 필요한 계정 개설 (시작 날짜 포함). Beancount는 모든 계정을 사용하기 전에 개설해야 합니다. 선언되지 않은 계정에 대한 게시는 로드 오류가 발생하므로
open지시문은 선택 사항이 아닌 필수입니다.Assets:Business:Checking및Assets:Business:TaxSavings계정은 USD 잔액을 보유합니다. 수입 및 지출 계정은 open 지시문에서 통화를 지정하지 않아도 됩니다. 거래 통화(이 경우 USD)를 상속하기 때문입니다. - 고객으로부터의 청구서 지불: _2025-08-15_에, 수입 거래는 청구서에 대한 고객 지불 $5,000를 기록합니다.
Income:Client:ACME를 크레딧(복식부기에서 수입은 음수 금액으로 증가)하고 당좌 계정을 차변에 기입합니다. 청구서 번호를 표시하기 위해 메타데이터 필드invoice: "INV-2025-08-15"가 포함되었습니다. 이는 선택 사항이지만 거래에 추가 정보를 첨부할 수 있는 방법을 보여줍니다. 빠른 필터링을 위해 이 거래에#ACME또는#client-ACME태그를 지정할 수도 있습니다. 여러 고객이 있는 경우, 많은 하위 계정을 만드는 대신 일반Income:Clients계정을 사용하고 이러한 메타데이터나 Payee 필드에 의존하여 고객을 구분할 수 있습니다. - 사업 비용(소프트웨어): _2025-08-05_에, GitHub 구독(아마도 비공개 리포지토리 또는 기타 서비스용)에 대한 $15 비용을 기록합니다. 게시는
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) 계정에서의 차감을 기록합니다. 이 이체를 보고서에서 비용으로 취급하는 것은 일반적인 함정입니다. 기억하세요. 이는 비용이 아니라 예방적 할당일 뿐입니다. 실제 세금 납부만 비용(또는 발생한 세금 부채 감소)이 됩니다.
요약: 프리랜서의 Beancount 원장은 단순성과 명확성을 강조합니다. 비즈니스와 관련된 모든 수입과 지출은 체계적으로 기록됩니다. 의미 있는 계정 이름과 선택적 태그/메타데이터를 사용하면 고객별 또는 비용 범주별 보고서를 쉽게 생성할 수 있습니다(예: 고객별 총 수입, 올해 계약자에게 지출한 총액 등). 이 설정은 확장 가능합니다. 사업이 발전함에 따라 새 고객이나 비용 범주를 추가할 수 있습니다. 자동 가져오기(은행 거래 가져오기) 및 프로젝트나 청구서에 대한 사용자 지정 태그와 같은 기능을 통해 Beancount는 프리랜서의 회계 부담을 크게 줄이면서 언제든지 재정 상태를 명확하게 파악할 수 있게 해줍니다.
소기업
다음으로, 소규모 부티크 전자상거래 비즈니스를 고려해 보겠습니다. 예를 들어, 수공예품을 판매하는 온라인 상점입니다. 이 시나리오는 재고 관리, 매출 원가(COGS), 온라인 결제 처리업체 처리와 같은 복잡성을 추가합니다. Beancount는 신중한 계정 구조와 거래 기록 방법으로 이러한 요구 사항을 수용할 수 있습니다. 재고로 제품을 추적하고, 온라인 플랫폼(예: 결제를 위한 Stripe를 사용하는 Shopify)을 통해 판매를 기록하고, 일반적인 사업 비용을 기록하는 경우를 예로 들어 설명하겠습니다.
부티크 전자상거래 비즈니스를 위한 주요 계정: 기본 은행 및 비용 계정 외에도, 소매 비즈니스 원장에는 재고와 판매 흐름을 추적하는 계정이 포함됩니다:
- Assets:Bank:Checking – 비즈니스 당좌 계정(공급업체 지불, 운영 비용, 결제 처리업체로부터의 이체 수령용).
- Assets:Stripe:Balance (또는 Assets:PayPal 등) – 아직 은행에 도착하지 않은 온라인 결제로 수집된 자금을 위한 정리 계정. 예를 들어, 고객이 Stripe를 통해 결제하면 돈은 배치로 은행에 입금되기 전에 Stripe 계정에 있을 수 있습니다.
- Assets:Inventory:제품 – 제품에 대한 재고 계정. 각 제품(또는 제품 범주)을 Beancount의 상품으로 취급하여 보유 수량을 추적할 수 있습니다. 예를 들어,
Assets:Inventory:Widgets는 현재 재고에 있는 "위젯" 항목의 수량을 원가로 평가하여 보유할 수 있습니다. - Income:Sales – 제품 판매로 인한 수익을 기록합니다. 비즈니스에 여러 채널이 있는 경우 다른 판매 채널에 대한 하위 계정(예:
Income:Sales:OnlinevsIncome: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 – (선택 사항, 해당하는 경우) 비즈니스가 판매에 대해 판매세 또는 VAT를 징수해야 하는 경우, 이 부채 계정은 징수했지만 아직 정부에 납부하지 않은 세금을 추적합니다. 각 판매는 세금 부분을 이 계정으로 분할합니다. 이렇게 하면 징수된 세금이 수입으로 간주되지 않고 세무 당국에 납부할 목적으로 지정됩니다.
- 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를 통화로 가정하고 재고에서 상품으로 추적하는 "위젯"이라는 제품을 가정합니다.
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로 선언), 핵심 수입 및 비용 계정(Sales, COGS, Fees)을 개설합니다.Assets:Inventory:Widgets WIDGET를 선언함으로써 이 계정이 "WIDGET" 상품의 수량을 보유할 것임을 알립니다. 이렇게 하면 Beancount가 해당 계정에서 상품 단위를 기대하고 해당 단위에 원가를 첨부할 수 있음을 알 수 있습니다. -
재고 구매: _2025-03-10_에, 공급업체로부터 각각 $10인 위젯 50개를 총 $500에 구매합니다. 거래는
Assets:Inventory:Widgets를50 WIDGET {10 USD}로 차변에 기입합니다. 이는 각각 10 USD의 원가가 기록된 상품 WIDGET 50단위가 재고 계정에 추가됨을 의미합니다. 크레딧은Assets:Bank:Checking -500 USD(현금 지출)입니다. 여기서 비용 계정을 직접 건드리지 않았습니다. 구매를 재고 자산으로 자본화하고 있습니다. 이제 대차 대조표에는 총 $500 가치의 위젯 50개가 재고로 있습니다. (잔액 보고서를 실행하면 재고 계정에 $500 상당의 50 WIDGET 단위가 표시됩니다.) -
판매 기록(주문 #1001): _2025-04-05_에, 온라인 상점을 통해 위젯 2개 판매를 기록합니다. 명확성을 위해 설명에 주문 번호가 포함됩니다. 이 거래에는 세 개의 게시가 포함됩니다:
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_에도, 판매된 위젯 2개의 원가를 기록하는 별도의 거래가 있습니다.
Expenses:COGS 20 USD를 차변에,Assets:Inventory:Widgets -2 WIDGET {10 USD}를 크레딧에 기입합니다. 이는 이전에 기록된 대로 각각 $10의 원가가 있는 재고에서 2단위를 제거합니다(총 $20).{10 USD}를 지정하여 Beancount가 원가 로트를 명확히 하도록 합니다. 이 경우 2025-03-10에 추가한 로트와 일치합니다. 이제 재고 계정에는 위젯 48개가 남고 관련 원가는 $480입니다. $20은 COGS 비용으로 이동하여 손익 계산서에 표시되고 상품 원가만큼 총 이익을 줄입니다. (이것을 기록하지 않으면 수입이 비용에 비해 과대 계상됩니다.) 명확성을 위해 별도의 거래를 사용했지만 판매와 COGS를 하나의 다중 라인 거래로 결합하는 것도 가능합니다. 가독성과 조정을 위해 표시된 대로 분리하는 것을 선호하는 사람들도 있습니다(각 COGS 항목을 주문에 명확하게 연결할 수 있음). 설명에 주문 번호를 반영하여 이 COGS 항목이 주문 #1001에 해당함을 쉽게 알 수 있습니다. 재고가 관련된 경우 모든 판매에 일치하는 COGS 항목이 있는지 확인하는 것이 좋은 방법입니다. 누락되면 재고 수량이 어긋날 수 있습니다. 피해야 할 함정은 판매에 대한 재고 제거를 잊어버려 대차 대조표에 유령 재고가 남고 비용이 과소 계상되는 것입니다. Beancount의 재고 기능({}원가 표기법)을 사용하면 보유 수량보다 많은 단위를 제거하려고 할 때 오류가 발생하므로 이 문제를 잡는 데 도움이 됩니다.
요약: Beancount를 사용하는 소기업은 놀라울 정도로 견고한 회계 시스템을 유지할 수 있습니다. 돈이 어디에 있는지, 어디서 오는지, 비용이 어떻게 흐르는지 추적하도록 계정을 구성하면 수익성에 대한 정확한 그림을 얻을 수 있습니다. 예제에서는 재고와 판매를 처리하는 방법을 보여주었습니다. 인터넷 요금 지불(Expenses:Operating:Internet vs. Assets:Bank:Checking), 대출이나 투자 수령(Assets:Bank vs. Liabilities:Loan 또는 Equity:OwnerEquity), 판매세 납부(Liabilities:SalesTax vs. Assets:Bank 납부 시) 등 다른 거래도 유사하게 기록합니다. 핵심은 일관성입니다: 각 유형의 거래를 동일한 패턴으로 기록하면 Beancount가 장부의 균형을 유지합니다. 자동 데이터 가져오기(예: 월별 Stripe 수수료 또는 은행 거래 가져오기) 및 사용자 지정 태그/링크(판매 및 환불과 같은 관련 거래 상호 연결)와 같은 기능을 통해 시스템은 유연하고 효율적일 수 있습니다. 결과는 비즈니스가 성장함에 따라 확장할 수 있는 체계적인 원장입니다. 새 제품 재고 계정, 새 비용 범주 또는 추가 수입원(예: 새 온라인 마켓플레이스)을 전체 시스템을 재작업하지 않고 추가할 수 있습니다.
개인 재무
마지막으로, 개인 또는 가계 재무에 Beancount를 사용하는 것을 고려해 보겠습니다. 이 설정은 일상적인 지출, 은행 계좌, 신용카드, 대출, 투자를 관리하는 개인 또는 가족을 위한 것입니다. 여기서 강조점은 돈이 어디로 가는지(지출), 어디서 오는지(수입), **어떻게 저축되거나 투자되는지(자산 및 부채)**를 추적하는 것입니다. Beancount는 이중 회계의 엄격함을 통해 아무것도 이중 계산되거나 잊혀지지 않도록 보장하면서 예산 앱을 대체하거나 보강할 수 있는 투명하고 사용자 지정 가능한 재무 보기를 제공할 수 있습니다.
개인 재무를 위한 주요 계정: 개인 재무 원장에는 일반적으로 다양한 자산, 부채, 수입, 지출 계정이 포함됩니다:
- Assets:Bank:Checking – 수입 입금과 청구서 지불을 위한 주요 당좌 계정.
- Assets:Bank:Savings – 비상 자금 또는 특정 목표를 위한 저축 계정. (여러 저축 또는 투자 계정이 있을 수 있습니다. 각각 자산 계정이 될 수 있습니다).
- Assets:Cash – 현금으로 지출하는 경우, 인출 및 현금 지출을 추적하기 위한 현금 계정이 있을 수 있습니다.
- Assets:Investments:브로커 – 투자 계정(브로커리지, 퇴직 연금 401(k)/IRA 등). 이는 투자 유형별로 더 세분화하거나 기관별로 하나의 계정으로 묶을 수 있습니다. 예:
Assets:Investments:VanguardIRA또는Assets:Investments:Robinhood. 투자 추적에는 주식이나 펀드에 대한 상품이 포함될 수 있지만, 너무 세부적이라면 기여금과 계정 잔액만 추적할 수 있습니다. - Liabilities:CreditCard:이름 – 신용카드별 계정(예:
Liabilities:CreditCard:Visa또는 은행 이름으로). 카드의 모든 구매는 여기에(동일한 비용과 함께) 기록되고, 카드에 대한 결제는 이 부채를 줄이는 이체입니다. - Liabilities:Loan:이름 – 모든 대출(학자금, 주택담보, 자동차 대출)은 부채 계정으로 추적할 수 있습니다. 원금 잔액과 이자(비용)와 원금(부채 감소)을 분리한 각 결제를 기록해야 합니다. 이는 고급 측면이지만 완전한 재무 그림에 중요합니다.
- 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는 식료품과 외식을 합산). 주요 그룹(주거, 식비, 교통, 의료 등)에 대한 계층을 두는 것이 일반적입니다. - Equity:Opening-Balances – 원장을 시작할 때 계정 잔액을 초기화하는 데 사용됩니다(모든 자산에서 부채를 뺀 값이 시작 순자산과 같도록 자본에 기록). 시작 후에는 누적 순이익을 나타내기 위해 Equity:Retained-Earnings 등을 사용할 수도 있습니다(개인 재무에서는 일반적으로 수입에서 지출을 뺀 값을 순자산으로 굴리기만 하면 됩니다). 자본 계정은 일상적으로는 덜 보이지만 회계 방정식의 균형을 보장합니다.
근거: 개인 재무 설정은 재정 생활을 하나의 일관된 시스템으로 포착하는 것입니다. 위의 각 계정은 서로 다른 종류의 재정을 분리하여 "이번 달 식비에 얼마를 썼나?"(Expenses:Food:* 합산), "남은 부채는 얼마인가?"(부채 계정 확인), "순자산은 얼마인가?"(자산에서 부채 뺌)와 같은 질문에 답할 수 있게 합니다. 이중 회계의 큰 장점은 정확성입니다. 예를 들어, 신용카드로 $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 신용카드 계정, 커피 비용 계정(식비의 하위 범주 예), 임대료 비용 계정, 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에는 자동 반복 거래 기능이 내장되어 있지 않지만 스크립트를 사용하거나 매월 복사하여 붙여넣기만 하면 됩니다. 태그는 나중에 한 달을 놓치지 않았는지 확인하거나 연간 임대료를 빠르게 합산하는 데 도움이 됩니다.) 일부 사용자는 Beancount 가져오기 프레임워크를 통해 주기적 거래 기능을 사용하여 자동으로 생성하지만, 이는 여기서 다루는 범위를 벗어나는 고급 사용법입니다. 핵심은 이 거래가 돈이 어디로 갔는지(주거 비용)와 은행 잔액 감소를 명확히 보여준다는 것입니다. 주의할 점: 비용을 분담하거나 룸메이트가 있는 경우 임대료의 일부만 지불할 수 있습니다. 이 경우 거래를 자신의 부분과 다른 사람이 지불하는 부분으로 나눌 수 있습니다(그들이 당신에게 지불하는 경우 다른 부분을Income:Reimbursements로 기록). 간단한 경우에는 전액을 지불합니다. - 퇴직 기여금: _2025-09-15_에, $500가 당좌 계정에서 401(k) 투자 계정으로 이동됩니다. 이는 비용이 아니라 자산을 한 형태(현금)에서 다른 형태(퇴직 기금)로 이전하는 것입니다. 거래는
Assets:Investment:401k를 차변에,Assets:Bank:Checking을 크레딧에 기입합니다. 명확성을 위해#retirement태그를 지정합니다. 이 후 당좌 계정 잔액은 500만큼 감소하고, 401k 계정 잔액은 500 USD가 나타내는 만큼 증가합니다(투자 추적 방법에 따라 이후 그 현금으로 뮤추얼 펀드 단위를 구매할 수 있습니다. 이는 투자 계정에서의 또 다른 거래입니다. 예: Y 가격에 펀드 X주를 구매하고 현금은 401k 자산에서 나감). 기본 개인 원장에서는 401k를 저축 계정처럼 취급하고 주기적으로 잔액을 업데이트하거나 이와 같은 기여금을 기록하고 가격 호가를 사용하여 성장을 반영할 수 있습니다. 중요한 것은 이 거래가 이체이지 비용이 아니라는 것입니다. 자산을 늘리는 것입니다. 많은 예산 도구는 퇴직 기여금을 "비용"으로 계산하지만(당좌 계정에서 나가기 때문에), 회계 용어로는 돈을 다른 주머니로 옮기는 것일 뿐입니다. 이 구분은 저축률과 지출을 이해하는 데 도움이 됩니다.
신용카드 청구서를 지불하는 거래가 있다면, Checking에서 CreditCard 부채로 돈을 이체하는 것처럼 보일 것입니다(예: Liabilities:CreditCard:Visa 100 USD / Assets:Bank:Checking -100 USD). 이렇게 하면 신용카드 잔액이 다시 줄어들고(전액 결제하면 0이 될 수 있음) 은행 잔액도 그에 따라 줄어들며, 지출 계정에는 영향이 없습니다. 구매 시점에 이미 지출을 기록했기 때문입니다. 신용카드를 이렇게 처리하는 것을 기억하는 것은 정확한 개인 재무 추적에 중요합니다. 결제에도 태그를 지정하거나(일부는 #cc-payment 또는 유사한 태그 사용) 명확성을 위해 명세서 기간을 설명에 포함할 수 있습니다.
요약: Beancount의 개인 재무 원장은 돈 추적에 규율과 구조를 부여하는 데 도움이 됩니다. 계정(및 선택적으로 태그)으로 거래를 분류하면 월별 지출, 연간 총액, 저축액 등 통찰력 있는 보고서를 생성할 수 있습니다. 이중 회계 접근 방식은 모든 달러가 설명되도록 보장합니다: 계정 잔액이 감소하면 어딘가로 갔습니다(다른 계정이 증가). 이는 오류를 잡고 단순한 추적 도구에서 흔한 "돈이 사라지는" 문제를 방지합니다. 자동화를 통해 대부분의 거래를 가져온 다음 검토하고 분류하기만 하면 유지 관리가 상당히 가능합니다. 시간이 지나면 포괄적인 재무 일기가 구축됩니다. 필요한 경우 친구와의 비용 분담(자본 계정 또는 미수금/미지급금 계정 사용), 대출 상환 추적, 투자 성과와 같은 것을 처리할 수도 있습니다. 가장 기본적인 형태(스니펫에 표시된 대로)에서도 Beancount는 일상 지출, 반복 의무, 장기 목표(예: 퇴직 저축)에 대한 진행 상황을 명확히 보여줍니다. 그리고 일반 텍스트이기 때문에 완전한 제어가 가능합니다: 스크립트, 쿼리, 다른 도구와 통합(예: 웹 인터페이스 Fava)할 수 있습니다. 요컨대, 이 설정은 개인 재무를 분석하고 신뢰할 수 있는 데이터로 바꾸면서도 일이 되지 않을 만큼 간단하게 유지합니다.
프리랜서, 소기업 운영, 개인 자금 관리 등 상황에 맞게 Beancount 원장을 조정함으로써 일반 텍스트 시스템의 유연성과 함께 체계적인 이중 회계 접근 방식의 재무 추적 이점을 얻을 수 있습니다. 이러한 예제 구성은 구축할 수 있는 핵심 패턴을 보여줍니다. 비즈니스가 성장하거나 재정 생활이 더 복잡해지면 계정 과목표를 확장하거나 필요에 따라 고급 기능(예산, 차이 분석, 다중 통화 처리)을 사용할 수 있습니다. 핵심은 깨끗하고 논리적인 구조(표시된 것과 같은)로 시작하고 거래를 일관되게 기록하는 것입니다. 이를 통해 Beancount는 산업과 개인 시나리오 전반에서 재정을 이해하고 관리하는 데 강력한 조력자가 될 것입니다. 즐거운 회계 되세요!