본문으로 건너뛰기

산업별 설정

프리랜서, 소규모 비즈니스 및 개인 금융을 위한 구성 예시

이 가이드에서는 프리랜서 전문가, 소규모 전문 비즈니스(부티크), 그리고 개인 가계부라는 서로 다른 요구 사항에 맞춰 Beancount 장부를 조정하는 방법을 살펴봅니다. 각 시나리오에는 고유한 계정 구조와 고려 사항이 포함되어 있습니다. 각 설정의 근거를 설명하고, Beancount 스니펫 예시를 제공하며, 추적을 더 쉽게 만들어주는 유용한 기능(커스텀 태그 및 자동 가져오기 등)을 강조할 것입니다. 이 가이드는 교육적이면서도 접근하기 쉬운 어조로 작성되었습니다. 개발자, 기술에 능숙한 전문가 또는 금융 애호가라면 이 예시들을 통해 실생활에 Beancount를 적용하는 데 도움을 받을 수 있을 것입니다.

industry-specific-setups

프리랜서​

프리랜서(소프트웨어 개발자나 그래픽 디자이너 등)는 종종 여러 클라이언트와 프로젝트 비용을 동시에 관리해야 합니다. 간단한 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의 자동 가져오기(importer) 기능을 사용하면 데이터 입력을 간소화할 수 있습니다. 예를 들어 은행이나 신용카드 명세서에 대한 가져오기 도구를 설정하여 장부로 트랜잭션을 불러온 다음, 적절한 비용 또는 수입 계정 이름만 추가하면 됩니다. 이는 소프트웨어 구독이나 출장비와 같이 자잘한 거래가 많을 때 시간을 크게 절약해 줍니다.

프리랜서 장부 예시 스니펫​

아래는 프리랜서 개발자를 위한 단순화된 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

; 클라이언트 수입 – 인보이스 대금 지급
2025-08-15 * "ACME Corp의 인보이스 대금 지급"
  invoice: "INV-2025-08-15"
  Assets:Business:Checking       5000 USD
  Income:Client:ACME           -5000 USD

; 정기 지출 – 예: 비즈니스용 소프트웨어 구독
2025-08-05 * "GitHub 구독"
  Expenses:Business:Software       15 USD
  Assets:Business:Checking       - 15 USD

; 외주 비용 – 도움을 준 외주 업체에 지급
2025-08-20 * "외주 업체 지급 – Jane Doe"
  Expenses:Business:Contractors   2000 USD
  Assets:Business:Checking      -2000 USD

; 세금 예치 – 세금 저축 계좌로 자금 이동
2025-08-31 * "3분기 세금 예치"
  Assets:Business:TaxSavings     1500 USD
  Assets:Business:Checking     -1500 USD  #tax

상세 내용을 분석해 보겠습니다:

  • 상단에서 필요한 계정들을 open 명령어로 개설합니다(시작 날짜 포함). Beancount에서는 반드시 미리 개설할 필요는 없지만(개설하지 않아도 처음 사용 시 생성됨), 명시적으로 선언하는 것이 좋은 관례입니다. 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의 지출을 기록합니다. 이 기입은 Expenses:Business:Software로 이동하고 비즈니스 당좌 계좌 잔액을 줄입니다. 이러한 소액의 반복 지출에는 태그를 달 수 있습니다(예를 들어, 아래 세금 트랜잭션에 #tax를 추가한 것처럼, 매달 발생하는 지출에는 #recurring 태그를 달 수 있습니다). 이 경우 계정 이름(Software) 자체가 용도를 명확히 설명해 줍니다.
  • 외주 업체 지급: _2025-08-20_에 프리랜서가 외주 업체(Jane Doe)에게 $2,000를 지급했습니다. 이는 Expenses:Business:Contractors 계정의 비용과 당좌 계좌의 현금 유출로 기록됩니다. 설명(Narration) 부분에 외주 업체의 이름을 포함하거나(위 예시처럼) 메타데이터 필드(예: contractor: "Jane Doe")로 포함할 수 있습니다. 이렇게 하면 누구에게 왜 지급했는지에 대한 감사 추적을 유지할 수 있어 세금 신고나 예산 관리 시 유용합니다.
  • 세금 예치 이체: _2025-08-31_에 프리랜서는 주 당좌 계좌에서 전용 세금 저축 계좌로 $1,500를 이체합니다. 가독성을 위해 이 트랜잭션에 #tax 태그를 달았습니다. 이것은 비용 지출이 아니라 자신의 돈을 옮기는 것이므로 두 자산 계정 사이에서 이동합니다. 매달 또는 분기마다 이렇게 함으로써 예상 세금을 납부할 자금을 축적합니다. 실제로 정부에 세금을 납부할 때가 되면 비용(예: Expenses:Taxes)으로 기록하고 TaxSavings(또는 Checking) 계정에서 차감하게 됩니다. 흔한 실수는 이 이체 자체를 보고서에서 비용으로 처리하는 것입니다. 이것은 비용이 아니라 만약을 대비한 할당임을 기억하십시오. 국세청 등 과세 당국에 실제로 납부하는 세금만이 비용(또는 부채를 추적하는 경우 발생한 세금 부채의 감소)이 됩니다.

요약: 프리랜서의 Beancount 장부는 단순함과 명확성을 강조합니다. 비즈니스와 관련된 모든 수입과 지출은 체계적으로 기록됩니다. 의미 있는 계정 이름과 적절한 태그/메타데이터를 사용하면 클라이언트별 또는 비용 카테고리별 보고서(예: 클라이언트당 총수입, 올해 외주 업체에 지출한 총액 등)를 쉽게 생성할 수 있습니다. 이 설정은 확장 가능하여 비즈니스가 변화함에 따라 새로운 클라이언트나 비용 카테고리를 추가할 수 있습니다. 자동 가져오기(은행 트랜잭션 불러오기) 및 프로젝트/인보이스를 위한 커스텀 태깅 기능을 활용하면, 프리랜서는 장부 관리 부담을 크게 줄이면서도 언제든지 재무 상태를 명확하게 파악할 수 있습니다.

소규모 사업​

다음으로 소규모 부티크 이커머스 사업, 예를 들어 수공예품을 판매하는 온라인 쇼핑몰을 생각해 보겠습니다. 이 시나리오에는 재고 관리, 매출원가(COGS), 온라인 결제 대행사 처리와 같은 복잡한 요소들이 추가됩니다. Beancount는 세심한 계정 구조와 거래 기록 방법을 통해 이러한 요구사항을 수용할 수 있습니다. 여기서는 사업체가 재고 제품을 추적하고, 온라인 플랫폼(예: Stripe 결제를 사용하는 Shopify)을 통해 매출을 기록하며, 일반적인 사업 비용을 로깅하는 사례를 사용하겠습니다.

부티크 이커머스 사업의 주요 계정: 기본적인 은행 및 비용 계정 외에도, 소매업 장부에는 재고 및 매출 흐름을 추적하기 위한 계정들이 포함됩니다:

  • Assets:Bank:Checking – 사업용 당좌예금 계좌 (공급업체 대금 결제, 운영비 지출, 결제 대행사로부터의 송금 수령 용도).
  • Assets:Stripe:Balance (또는 Assets:PayPal 등) – 온라인 결제를 통해 수집되었지만 아직 은행에 입금되지 않은 자금을 위한 미결제(Clearing) 계정입니다. 예를 들어, 고객이 Stripe로 결제하면 돈은 은행에 일괄 입금되기 전까지 Stripe 계정에 머물게 됩니다.
  • Assets:Inventory:*Product*** – 제품별 재고 계정입니다. 보유 수량을 추적하기 위해 Beancount에서 각 제품(또는 제품 카테고리)을 하나의 상품(Commodity)으로 취급할 수 있습니다. 예를 들어, Assets:Inventory:Widgets에는 현재 재고로 보유 중인 "Widget" 품목의 수량이 원가로 평가되어 기록됩니다.
  • Income:Sales – 제품 판매로 인한 수익을 기록합니다. 판매 채널이 여러 개인 경우 하위 계정(예: Income:Sales:Online 대 Income:Sales:InStore)을 사용할 수 있지만, 여기서는 하나의 매출 수익 계정으로 단순하게 유지하겠습니다.
  • Expenses:COGS – 매출원가 계정으로, 제품이 판매될 때 해당 재고 품목의 원가 기준을 포착합니다. 이 계정은 일정 기간 동안 판매된 재고가 (사업주 입장에서) 얼마의 비용이 들었는지 효과적으로 보여줍니다. 이는 매출총이익(Gross Profit)을 계산하는 핵심 요소입니다.
  • Expenses:Fees – 결제 처리 수수료 및 플랫폼 수수료(Stripe 수수료, Shopify 수수료, PayPal 수수료 등)를 여기에 기록할 수 있습니다. 원하는 경우 더 상세한 계정(예: Expenses:Fees:Stripe 및 Expenses:Fees:Shopify)으로 분리할 수 있지만, 모든 거래 수수료에 대해 하나의 계정으로도 충분할 수 있습니다.
  • Expenses:Operating – 마케팅, 웹 호스팅, 소프트웨어, 배송 자재 등 매출원가와 직접 연결되지 않는 일반 사업 비용입니다. 이를 하위 계정(예: Expenses:Marketing, Expenses:WebHosting, Expenses:Shipping)으로 나누어 다양한 원가 중심점(Cost Center)을 분석할 수 있습니다.
  • Liabilities:SalesTax – (해당하는 경우 선택 사항) 사업자가 판매 시 판매세나 부가세(VAT)를 징수해야 하는 경우, 이 부채 계정은 징수되었지만 아직 정부에 납부하지 않은 세금을 추적합니다. 각 판매 시 세금 부분은 이 계정으로 분리되어 기록됩니다. 이를 통해 징수된 세금이 수입으로 간주되지 않고 세무 당국에 납부할 용도로 별도 관리되도록 합니다.
  • Equity:OwnerEquity – (선택 사항) 소유주의 투자금 및 이익잉여금을 나타냅니다. 사업을 시작할 때 소유주가 제공한 초기 자금은 여기에 대변(Credit)으로 기록됩니다 (현금이나 재고를 기부한 경우 은행이나 재고 계정이 차변(Debit)에 기록됨). 또한 소유주가 이익을 인출(배당)하는 경우 이 자본 계정에 기록할 수 있습니다. 이는 대차대조표의 균형을 유지하지만, 일상적인 운영에서는 자주 사용되지 않습니다.

근거: 이 설정은 물품의 흐름과 돈의 흐름을 분리합니다. 재고 매입은 즉시 비용으로 처리되지 않고 먼저 대차대조표에 자산으로 기록됩니다. 제품을 판매할 때만 해당 원가를 비용(매출원가)으로 처리하여, 적절한 이익 계산을 위해 수익과 관련 비용을 대응시킵니다. 판매 수입은 총 판매 가격으로 기록되는 반면, 수수료는 별도로 기록되어 총매출과 지급 수수료(따라서 순매출)를 모두 확인할 수 있습니다. Assets:Stripe:Balance와 같은 미결제 계정을 사용하면 입금액 조정(Reconciliation)에 도움이 됩니다. 돈은 Stripe에서 은행으로 뭉칫돈으로 이동하며, 혼동 없이 해당 이체를 기록할 수 있습니다. 초보 상점 주인들이 흔히 저지르는 실수는 재고를 제대로 기록하지 않는 것입니다. 예를 들어, 모든 재고 구매를 즉시 비용으로 처리하는 식입니다. 이는 현금 흐름 추적에는 괜찮을지 모르지만, 이익을 왜곡합니다. 재고를 많이 비축한 달에는 이익이 적어 보이고, 재고를 미리 사두고 판매만 하는 달에는 이익이 많아 보이기 때문입니다. 재고 자산 계정과 매출원가(COGS)를 사용함으로써 비용을 판매 시점에 맞출 수 있습니다. 또 다른 실수는 수수료나 환불을 제대로 회계 처리하지 않아 은행이나 Stripe 잔액이 기록된 수입과 일치하지 않게 되는 것입니다. 우리는 수수료를 명시적으로 기록하고 Stripe 자산 계정을 사용하여 Stripe가 지급해야 하거나 지급한 금액을 추적함으로써 이를 방지합니다.

강조할 Beancount 기능: Beancount의 재고 추적 기능은 상품(Commodity)과 원가(Cost)를 처리하는 능력을 활용합니다. 각 제품은 상품 기호(예: WIDGET)가 될 수 있으며, 수량과 단위당 원가를 모두 기록할 수 있습니다. 품목을 판매할 때 Beancount의 재고 로직(기본값은 선입선출, FIFO)은 재고 로트(Lot)에서 올바른 원가를 자동으로 선택할 수 있습니다. 예시에서 이를 확인하게 될 것입니다. 또한 메타데이터나 링크를 사용하여 매출과 그에 해당하는 매출원가(COGS) 항목을 연결할 수 있습니다 (예: 두 거래 모두에 동일한 주문 번호를 사용하거나, 매출과 재고 감소 거래에 #order1001과 같은 공유 태그를 사용하여 각 매출에 일치하는 매출원가 항목이 있는지 쉽게 쿼리하거나 재확인할 수 있습니다). 또한 자동 임포트 기능이 도움이 될 수 있습니다. 스크립트를 사용하여 Shopify 또는 Stripe 지급 보고서에서 매출 데이터를 가져오거나, 은행 거래 내역서를 가져와 비용 거래 및 지급액을 파악할 수 있습니다. 이러한 반복적인 데이터 입력 작업을 자동화하면 숫자를 입력하는 시간은 줄이고 분석하는 데 더 많은 시간을 할애할 수 있습니다.

소규모 비즈니스 원장 예시 코드​

다음은 소규모 이커머스 비즈니스를 위한 간략한 Beancount 예시입니다. 재고 구매, 매출 기록(결제 대행사 수수료를 차감한 순수익), 그리고 해당 매출에 대한 매출원가(COGS) 기록 과정을 보여줍니다. 실제로는 플랫폼 수수료, 광고비 등 다른 비용도 표시된 수수료 예시와 유사하게 기록하게 됩니다. 통화는 USD로 가정하며, "Widget"이라는 제품을 재고 내 상품(commodity)으로 추적합니다.

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

; 재고 구매 (Widget 50개를 개당 $10 비용으로 구매)
2025-03-10 * "SupplierCo에서 Widget 50개 구매"
  Assets:Inventory:Widgets      50 WIDGET {10 USD}
  Assets:Bank:Checking        -500 USD

; 고객 판매 (온라인 스토어를 통한 주문 #1001, Widget 2개 판매)
2025-04-05 * "판매 주문 #1001 (Shopify를 통한 Widget 2개)"
  Assets:Stripe:Balance         58 USD   ; 수수료 제외 후 수령한 순 결제 금액
  Expenses:Fees                  2 USD   ; 결제 수수료 (Stripe)
  Income:Sales                 -60 USD   ; Widget 2개에 대한 매출 (개당 $30)

; 위 판매에 대한 매출원가 (Widget 2개를 개당 $10 비용으로 계산)
2025-04-05 * "주문 #1001에 대한 매출원가 (Widget 2개)"
  Expenses:COGS                 20 USD
  Assets:Inventory:Widgets     -2 WIDGET {10 USD}

단계별 설명은 다음과 같습니다:

  • 계정 개설: 당좌 예금 계좌, Stripe 잔액 계좌, Widget 재고 계좌(단위 추적을 위해 상품 WIDGET으로 선언), 그리고 핵심 수익 및 비용 계좌(매출, 매출원가, 수수료)를 개설합니다. Assets:Inventory:Widgets WIDGET을 선언함으로써 이 계좌가 "WIDGET"이라는 상품의 수량을 보유함을 나타냅니다. 이를 통해 Beancount는 해당 계좌에 상품 단위가 올 것을 인지하고, 우리는 해당 단위에 취득 원가를 부여할 수 있습니다.

  • 재고 구매: _2025-03-10_에 공급업체로부터 개당 $10인 Widget 50개를 총 $500에 구매합니다. 거래는 Assets:Inventory:Widgets에 50 WIDGET {10 USD}를 차변 기입합니다. 이는 취득 원가가 10 USD인 WIDGET 상품 50개가 재고 계좌에 추가되었음을 의미합니다. 대변 기입은 Assets:Bank:Checking -500 USD(현금 지출)입니다. 여기서 비용 계좌를 직접 건드리지 않았음에 유의하세요. 구매 금액을 재고 자산으로 자산화한 것입니다. 이제 재무상태표의 재고 항목에는 총 $500 가치의 Widget 50개가 표시됩니다. (잔액 보고서를 실행하면 재고 계좌에 $500 상당의 50 WIDGET 단위가 나타납니다.)

  • 매출 기록 (주문 #1001): _2025-04-05_에 온라인 스토어를 통한 Widget 2개의 판매를 기록합니다. 명확성을 위해 적요(narration)에 주문 번호를 포함했습니다. 이 거래는 세 개의 분개 항목(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에게 어떤 가격대의 재고(lot)를 꺼낼지 알려줍니다. 이 경우 2025-03-10에 추가한 항목과 일치합니다. 이제 재고 계좌에는 48개의 Widget이 남게 되며 관련 원가는 $480가 됩니다. $20는 매출원가(COGS) 비용으로 이동하여 손익계산서에 나타나며, 해당 상품의 원가만큼 매출 총이익을 감소시킵니다. (이를 기록하지 않으면 비용 대비 수익이 과대 계상됩니다.) 명확성을 위해 별도의 거래로 분리했지만, 매출과 매출원가를 하나의 다중 행 거래로 결합할 수도 있습니다. 가독성과 대조(각 매출원가 항목을 주문과 명확히 연결할 수 있음)를 위해 여기에서 보여준 것처럼 분리하는 것을 선호하기도 합니다. 또한 적요에 주문 번호를 다시 기입하여 이 매출원가 항목이 주문 #1001에 해당함을 쉽게 알 수 있게 했습니다. 재고가 포함된 경우 모든 매출에 대응하는 매출원가 항목이 있는지 확인하는 것이 좋은 관행입니다. 이를 누락하면 재고 수량이 틀어지게 됩니다. 피해야 할 실수 중 하나는 매출 발생 시 재고 차감을 잊어버리는 것인데, 이는 재무상태표에 가공의 재고를 남기고 비용은 과소 계상하게 만듭니다. 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 등이 있습니다. 투자 추적에는 주식이나 펀드를 위한 상품(commodities) 기능이 포함될 수 있지만, 너무 복잡하다면 단순히 불입금과 계좌 잔액만 추적할 수도 있습니다.
  • 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는 식재료와 외식을 모두 합산함). 대분류(주거, 식비, 교통, 의료 등)로 계층을 구성하는 것이 일반적입니다.
  • Equity:Opening-Balances – 장부를 처음 시작할 때 계좌 잔액을 초기화하는 데 사용됩니다(모든 자산에서 부채를 뺀 값이 자본에 기록된 시작 순자산과 같아지도록 함). 시작 후에는 누적된 순이익을 나타내기 위해 Equity:Retained-Earnings 등을 사용할 수 있습니다(단, 개인 재무에서는 보통 수익에서 비용을 뺀 금액이 순자산으로 자연스럽게 전환되도록 둡니다). 자본 계정은 일상적으로 자주 보이지는 않지만, 회계 등식이 균형을 이루도록 보장합니다.

근거: 개인 재무 설정은 개인의 경제 생활을 하나의 일관된 시스템에 담는 것입니다. 위의 각 계정은 다양한 종류의 재무 항목을 구분하여, "이번 달 식비로 얼마를 썼는가?"(Expenses:Food:* 합산), "부채가 얼마나 남았는가?"(부채 계정 확인), "나의 순자산은 얼마인가?"(자산 - 부채)와 같은 질문에 답할 수 있게 해줍니다. 여기서 복식부기의 큰 장점은 정확성입니다. 예를 들어, 신용카드로 100달러어치 식재료를 구매하면, 이를 비용의 발생 동시에 부채의 증가로 기록합니다. 나중에 카드 대금을 납부할 때, 은행 계좌에서 카드로의 이체를 기록합니다. 이는 부채를 갚는 것이지 이미 기록된 식비 비용을 중복해서 계산하지 않습니다. 복식부기를 사용하지 않을 때 흔히 발생하는 실수는 카드 대금 납부 자체를 비용으로 처리하여 결과적으로 100달러를 두 번 계산하는 것입니다. Beancount는 설계상 이러한 오류를 방지합니다. 피해야 할 또 다른 실수는 계좌 대조(reconciliation)를 소홀히 하는 것입니다. Beancount에서는 잔액 확인(balance assertion)이나 balance 지시어를 사용하여 장부상의 입출금 계좌 잔액이 실제 은행 명세서와 일치하는지 확인할 수 있습니다. 이를 통해 누락되거나 중복된 항목을 찾아낼 수 있습니다.

주요 Beancount 기능: 개인 재무의 경우, 거래량이 많기 때문에 자동 가져오기(automated imports) 기능이 특히 유용합니다. Beancount의 임포터 프레임워크나 커뮤니티 스크립트를 사용하여 CSV, OFX 또는 API 소스로부터 은행 거래, 신용카드 명세서, 투자 거래 내역까지 가져올 수 있습니다. 이를 통해 매번 커피를 마실 때마다 일일이 수동으로 입력하는 시간을 줄일 수 있습니다. 사용자 정의 **태그(tags)**는 계정만으로는 불가능한 방식으로 데이터를 분류하는 데 유용합니다. 예를 들어, 항공권, 호텔, 식사 여부와 관계없이 모든 휴가 관련 비용에 #vacation2025 태그를 달면 해당 휴가에 든 총비용을 쉽게 조회할 수 있습니다. 또는 나중에 참고하기 위해 소득공제 항목을 추적해야 한다면 특정 비용에 #deductible 태그를 달 수 있습니다. 반복되는 청구서(예: #monthly)에 태그를 달아 매년 구독료와 고정 비용을 검토할 수도 있습니다. 메타데이터를 사용하여 메모나 영수증을 첨부할 수 있습니다(예: 저장된 영수증 이미지가 있음을 나타내는 receipt: "path/to/file.jpg", 또는 환급 가능한 항목을 추적하기 위한 category: "Work Expense" 등). 태그와 메타데이터의 유연성 덕분에 수십 개의 추가 계정을 만들지 않고도 개인적인 추적 요구 사항에 맞춰 시스템을 조정할 수 있습니다.

개인 재무 예시 원장 스니펫​

아래는 몇 가지 전형적인 거래를 포착한 개인 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"
  Expenses:Food:Coffee       5.50 USD
  Liabilities:CreditCard:Visa   -5.50 USD  #daily

; Recurring monthly bill (rent paid from checking)
2025-09-01 * "Apartment Rent September"
  Expenses:Housing:Rent    1200 USD
  Assets:Bank:Checking    -1200 USD  #recurring

; Retirement contribution (transfer from checking to 401k investment)
2025-09-15 * "401(k) Contribution"
  Assets:Investment:401k    500 USD
  Assets:Bank:Checking     -500 USD  #retirement

이 거래들을 해석해 보겠습니다:

  • 계좌 개설: 입출금 계좌(Checking), 비자 신용카드 계좌, 커피 비용 계좌(식비 지출의 하위 카테고리 예시), 월세 비용 계좌, 그리고 401(k) 투자 계좌를 개설합니다. 실제 원장에서는 저축, 다른 비용 카테고리, 수입 등 사용하려는 모든 계좌를 개설하게 됩니다. 여기서는 스니펫에 필요한 계좌만 포함했습니다.
  • 일상 지출 – 커피: _2025-09-10_에 5.50달러의 커피 구매가 기록되었습니다. 이 비용은 Expenses:Food:Coffee로 분류되며, 비자 신용카드로 결제했으므로 Liabilities:CreditCard:Visa에 대변(부채 증가) 기록합니다. #daily 태그는 이것이 일상적인 지출 항목임을 나타내기 위해 추가되었습니다. 나중에 모든 일상적인 재량 지출을 필터링하고 싶을 때 유용합니다. 이 거래 후 신용카드 계좌 잔액은 5.50달러로 표시됩니다(비자에 5.50달러를 갚아야 함을 의미). 만약 이 커피값을 현금으로 결제했다면, 거래는 대신 Assets:Cash에 대변 기록(보유 현금 감소)되었을 것입니다. 체크카드로 구매했다면 Assets:Bank:Checking에 대변 기록되었을 것입니다. 원리는 비슷하며 계좌만 달라집니다.
  • 정기 공과금 – 월세: _2025-09-01_에 1200달러의 월세 납부를 기록합니다. 이는 입출금 계좌에서 출금(Assets:Bank:Checking 대변 기록)되어 Expenses:Housing:Rent로 분류됩니다. 이 항목이 반복되는 청구서임을 표시하기 위해 #recurring 태그를 달았습니다. 전체 원장에서는 매달 이와 같은 항목이 있을 것입니다. (Beancount에는 자동 반복 거래 기능이 내장되어 있지 않지만, 스크립트를 사용하거나 매달 복사하여 붙여넣는 방식으로 처리할 수 있습니다. 태그를 사용하면 나중에 누락된 달이 없는지 확인하거나 한 해의 월세 합계를 빠르게 계산하는 데 도움이 됩니다.) 일부 사용자는 Beancount 임포터 프레임워크의 정기 거래(periodic transaction) 기능을 사용하여 이를 자동으로 생성하기도 하지만, 이는 여기서 다루는 범위를 벗어난 고급 활용법입니다. 핵심은 이 거래가 돈이 어디로 갔는지(주거 비용)와 줄어든 은행 잔액을 명확히 보여준다는 점입니다. 주의할 점: 비용을 공유하거나 룸메이트가 있는 경우 월세의 일부만 지불할 수 있습니다. 이 경우 거래를 본인 몫과 다른 사람이 내는 몫으로 분할할 수 있습니다(상대방이 본인에게 돈을 주는 경우 해당 몫을 Income:Reimbursements로 기록할 수 있음). 이 간단한 예시에서는 전액을 지불하는 것으로 가정합니다.
  • 퇴직 연금 납입: _2025-09-15_에 500달러가 입출금 계좌에서 401(k) 투자 계좌로 이동합니다. 이것은 비용이 아니라 자산을 한 형태(현금)에서 다른 형태(퇴직 연금)로 이전하는 것입니다. 거래는 Assets:Investment:401k를 차변에, Assets:Bank:Checking을 대변에 기록합니다. 명확성을 위해 #retirement 태그를 추가했습니다. 이 거래 후 입출금 계좌 잔액은 500만큼 줄어들고, 원장상의 401(k) 계좌 잔액은 500 USD가 나타내는 가치만큼 증가합니다(투자 추적 방식에 따라 그 현금으로 뮤추얼 펀드 유닛을 구매할 수 있으며, 이는 투자 계좌에서의 또 다른 거래가 됩니다. 예: 401(k) 자산에서 현금이 나가면서 X 가격으로 Y 주의 펀드를 매수). 기본적인 개인 원장에서는 401(k)를 저축 계좌처럼 취급하고 정기적으로 잔액을 업데이트하거나, 이와 같이 납입금을 기록하고 성장을 위해 가격 시세를 사용할 수 있습니다. 중요한 점은 이 거래가 비용이 아닌 **이체(transfer)**라는 것입니다. 즉, 자산을 쌓는 과정입니다. 많은 예산 관리 도구는 퇴직 연금 납입을 (입출금 계좌에서 나가기 때문에) "비용"으로 간주하지만, 회계 관점에서는 돈을 다른 주머니로 옮기는 것뿐입니다. 이러한 구분을 통해 지출 대비 저축률을 제대로 이해할 수 있습니다.

신용카드 대금을 결제하는 거래의 경우, 입출금 계좌에서 신용카드 부채로 돈을 옮기는 형태가 됩니다 (예: Liabilities:CreditCard:Visa 100 USD / Assets:Bank:Checking -100 USD). 이렇게 하면 신용카드 잔액이 줄어들고(전액 결제 시 0이 됨) 그에 따라 은행 잔액도 줄어듭니다. 이때 비용 계좌에는 영향이 없는데, 구매 시점에 이미 비용을 기록했기 때문입니다. 정확한 개인 재무 추적을 위해서는 신용카드를 이런 방식으로 처리하는 것이 매우 중요합니다. 결제 거래에도 태그를 달거나(일부는 #cc-payment 등 사용), 명확성을 위해 적요(narration)에 명세서 기간을 포함할 수 있습니다.

요약: Beancount의 개인 재무 원장은 돈 관리의 규율과 구조를 세우는 데 도움이 됩니다. 계좌(및 선택적으로 태그)를 사용하여 거래를 분류함으로써, 카테고리별 월간 지출, 연간 합계, 저축액 등 통찰력 있는 보고서를 생성할 수 있습니다. 복식부기 방식은 모든 달러가 계산됨을 의미합니다. 즉, 한 계좌의 잔액이 줄어들면 그것은 어딘가로 간 것입니다(다른 계좌의 잔액 증가). 이는 오류를 잡아내고 단순한 가계부 도구에서 흔히 발생하는 "사라진 돈" 문제를 방지합니다. 자동화를 통해 대부분의 거래를 가져온 다음 검토 및 분류만 하면 되므로 유지 관리가 매우 수월합니다. 시간이 지나면서 포괄적인 재무 일기가 쌓이게 됩니다. 여기에는 친구와 비용 분담(자본 계좌나 미수/미지급 계좌 사용), 대출 상환 추적, 투자 성과 측정 등 원하는 만큼 확장할 수도 있습니다. 이 스니펫에 나타난 가장 기본적인 수준에서도 Beancount는 일상 지출, 정기적인 의무, 퇴직 저축과 같은 장기 목표에 대한 진척 상황을 명확하게 보여줍니다. 또한 일반 텍스트 형식이므로 스크립트를 짜거나 쿼리를 날리고, Fava와 같은 웹 인터페이스와 통합하는 등 모든 제어권을 사용자가 갖게 됩니다. 요컨대, 이 설정을 통해 개인 재무를 분석 가능하고 신뢰할 수 있는 데이터로 바꾸는 동시에, 관리가 번거롭지 않을 만큼 단순함을 유지할 수 있습니다.

프리랜서, 소규모 비즈니스 운영, 또는 개인 자금 관리 등 귀하의 상황에 맞게 Beancount 원장을 조정함으로써, 일반 텍스트 시스템의 유연성과 함께 체계적인 복식부기 방식의 이점을 누릴 수 있습니다. 이러한 예시 설정은 여러분이 기반으로 삼을 수 있는 핵심 패턴을 보여줍니다. 비즈니스가 성장하거나 재정 생활이 복잡해짐에 따라 계좌 체계를 확장하거나 예산 관리, 차이 분석, 다중 통화 처리와 같은 고급 기능을 필요에 따라 추가할 수 있습니다. 핵심은 (위에서 보여드린 것과 같이) 깔끔하고 논리적인 구조로 시작하여 일관되게 거래를 기록하는 것입니다. 이것이 뒷받침된다면 Beancount는 업종이나 개인 상황에 관계없이 재정 상태를 이해하고 관리하는 데 강력한 아군이 될 것입니다. 즐거운 회계 처리 되세요!

Share on TwitterFollow @beancount_io

Beancount.io 시작하기

오픈 소스 복식부기 시스템으로 자산을 관리하세요. 오늘 바로 원장 작성을 시작해 보세요.

무료로 시작하기요금제 보기

시작하기

    주요 기능

      커뮤니티

        법적 고지

          Beancount.io© 2019 - 2026 Beancount.io
          App Store에서 다운로드Google Play에서 다운로드
          투명한 설계 • 버전 관리 지원 • AI 기반