본문으로 건너뛰기

Beancount와 Fava를 이용한 투명하고 감사 가능한 회계

소개

Beancount와 Fava는 부기를 투명하고, 추적 가능하며, 감사 가능하게 만드는 것을 목표로 설계된 오픈 소스 회계 도구입니다. Beancount는 거래를 기록하기 위해 플레인 텍스트 파일을 사용하는 복식 부기 시스템이며, Fava는 이러한 기록을 사람이 읽을 수 있는 보고서와 시각화로 제공하는 웹 인터페이스입니다. 독점적인 데이터 형식을 제거하고 버전 관리를 활용함으로써 Beancount는 기존 회계 소프트웨어가 제공하기 어려운 수준의 명확성과 책임성을 가능하게 합니다. 이 보고서는 Beancount의 플레인 텍스트 방식과 Fava의 사용자 친화적인 인터페이스가 어떻게 함께 작동하여 다양한 맥락에서 투명성, 감사 가능성 및 사용자 제어를 향상시키는지 살펴봅니다.

transparent-and-auditable

Beancount를 이용한 플레인 텍스트 부기 (기술적 측면)

플레인 텍스트 데이터: Beancount는 모든 금융 거래를 플레인 텍스트 파일에 저장합니다. 각 항목은 거래를 나타내는 사람이 읽을 수 있는 줄 (또는 줄 집합)입니다. 예를 들어 점심으로 5달러 현금 구매를 다음과 같이 기록할 수 있습니다.

2024-07-29 * "점심으로 햄버거 구매"
Assets:Cash -5.00 USD
Expenses:Food 5.00 USD

이 형식에서는 날짜, 설명 및 계정이 명확하게 표시됩니다. 모든 거래는 반드시 균형을 이루어야 (총 차변 = 총 대변)하므로 누락된 계정이나 잘못된 금액과 같은 오류는 소프트웨어의 파서에 의해 즉시 발견됩니다. 회계를 위한 이 간단한 텍스트 기반 도메인 특정 언어는 모든 텍스트 편집기로 금융 데이터를 읽거나 편집하고 간단한 스크립트 또는 명령으로 처리할 수 있음을 의미합니다.

파일 구조: Beancount 원장 파일은 일반적으로 계정을 열고, 상품 (통화)을 정의하고, 거래를 기록하고, 어설션 또는 잔액 확인을 수행하는 지시문을 포함합니다. 계정은 계층적으로 이름이 지정됩니다 (예: Assets:Bank:Checking, Expenses:Food:Grocery), 따라서 재정 구조가 명확해집니다. 항목을 연대순 또는 논리적으로 구성할 수 있으며, 더 나은 구성을 위해 원장을 여러 파일로 분할 (기본 파일에 포함)할 수도 있습니다. 데이터가 텍스트이므로 계정을 쉽게 재정렬하거나 리팩터링할 수 있습니다. 예를 들어 원장 전체에서 계정 이름을 바꾸는 것은 간단한 찾기 및 바꾸기 또는 명령줄 스크립트로 수행할 수 있습니다. Beancount의 제작자인 Martin Blais는 _"텍스트는 힘을 실어준다"_고 말합니다. sed와 같은 도구를 사용하여 전체 기록에서 계정을 몇 초 만에 재구성할 수도 있습니다.

버전 제어 (Git)와의 통합: 플레인 텍스트 회계의 가장 큰 기술적 장점은 Git과 같은 버전 제어 시스템과 얼마나 원활하게 통합되는지입니다. .beancount 파일 (또는 파일)은 Git 저장소에 존재할 수 있으므로 커밋 기록으로 모든 변경 사항을 추적할 수 있습니다. 거래의 각 추가 또는 수정 사항은 줄 단위로 검토할 수 있는 diff가 됩니다. 이는 _"감사 추적, 무제한 '실행 취소' 및 협업"_을 즉시 제공합니다. 예를 들어 항목을 편집하거나 제거하면 Git은 누가, 언제, 정확히 무엇을 변경했는지 보여줍니다. 이는 마지막 수정 날짜만 표시하거나 감사를 위해 특별 로그가 필요한 불투명한 회계 데이터베이스와는 극명한 대조를 이룹니다. Beancount를 채택한 회사는 Git을 사용하면 여러 회계사가 동시에 작업하고 "누가 언제 어디서 어떤 변경을 했는지" 알 수 있어 기존 소프트웨어에서 직면했던 협업 및 변경 추적 문제를 해결했다고 보고했습니다. 실제로 Git에서 유효성 검사를 적용할 수도 있습니다 (예: Beancount의 검사를 실행하고 균형이 맞지 않는 원장을 커밋하지 못하게 하는 pre-commit hook). 원장을 코드로 취급한다는 것은 코드 관리, 즉 diff, 풀 요청, 코드 검토를 위한 모든 강력한 도구를 회계 기록에 사용할 수 있음을 의미합니다.

데이터 입력 및 이식성: Beancount의 형식이 플레인 텍스트이므로 다른 소스에서 데이터를 쉽게 가져오거나 다른 용도로 내보낼 수 있습니다. 항목을 수동으로 작성하거나 은행 명세서를 Beancount 형식으로 변환하는 스크립트를 작성할 수 있습니다. Beancount 커뮤니티는 일반적인 형식에 대한 임포터를 제공하며 다른 플레인 텍스트 회계 도구 (Ledger, hledger)는 유사한 형식을 가지며 변환기를 사용할 수 있습니다. 한 가이드에서 강조하듯이 "거래 데이터가 알 수 없는 형식의 이진 블롭에 있는 상황에 처하게 되지 않습니다". 실제로 필요한 경우 Beancount 파일을 가져와서 간단한 파서를 작성하거나 다른 도구를 사용하여 읽을 수 있습니다. 이를 통해 기술적 기반을 매우 미래 지향적으로 만들 수 있습니다.

플레인 텍스트 원장의 감사 가능성 이점

금융 기록을 플레인 텍스트로 저장하면 감사 가능성 및 오류 확인에 상당한 이점이 있습니다.

  • 세분화된 변경 기록: 장부에 대한 모든 변경 사항은 버전 제어 커밋을 통해 추적됩니다. 이를 통해 GitHub와 같은 서비스를 사용하거나 서명된 커밋 관행을 사용하는 경우 변조하기 어려운 편집 기록이 시간 순서대로 생성됩니다. 이는 모든 거래에 대한 자세한 감사 로그를 갖는 것과 같습니다. 실수는 이를 도입한 정확한 커밋으로 다시 추적할 수 있으며 장부의 이전 버전을 쉽게 검색할 수 있습니다. 플레인 텍스트 원장에서는 "데이터를 효과적으로 버전 제어할 수 있어 수정에 대한 감사 추적 및 무제한 '실행 취소'를 제공합니다". 대조적으로 많은 기존 회계 시스템은 전체 편집 기록을 보관하지 않거나 데이터를 조정과 섞어 구분하기 어렵게 만듭니다.

  • 추적 가능성 및 동료 검토: 원장이 텍스트이므로 여러 사람이 코드를 검토하는 것처럼 검토할 수 있습니다. 예를 들어 소규모 조직에서는 한 사람이 원장 변경 사항을 제안 (거래 추가, 항목 조정)하고 다른 사람이 검토할 수 있도록 풀 요청을 열 수 있습니다. 이 동료 검토 프로세스는 코드 검토가 버그를 잡는 것처럼 오류나 불일치를 허용하기 전에 잡을 수 있습니다. 위에서 언급한 협업 워크플로는 QuickBooks를 사용하는 팀에게는 불가능했으며 더 나은 다중 사용자 지원을 위해 Beancount로 마이그레이션하게 되었습니다. 플레인 텍스트 방식은 _협업_을 자연스럽게 만듭니다. 차이점을 조정하고 다른 회계사의 변경 사항을 병합하는 것이 간단하며 일부 데스크톱 회계 파일의 "파일 잠금" 또는 단일 사용자 제한을 피할 수 있습니다.

  • 자동 오류 확인: Beancount에는 강력한 내장 유효성 검사가 포함되어 있습니다. 파일을 처리할 때 거래가 균형을 이루지 않거나 (차변 ≠ 대변), 계정의 거래가 어설션된 잔액과 일치하지 않거나, 중복 거래 식별자와 같은 불일치가 있는 경우 오류가 발생합니다. 한 사용자는 _"Beancount의 내부 검사로 인해 [내 기록]이 원장에 입력되면 올바른지 확신합니다. 실패할 가능성이 없습니다..."_라고 말합니다. 다시 말해 Beancount 파일이 오류 없이 가져오면 기본 회계 무결성 (예: 모든 거래 잔액)이 그대로 유지된다는 높은 확신을 가질 수 있습니다. 예를 들어 은행 명세서에서 월별 잔액 어설션을 추가할 수 있으며 Beancount는 "거래가 예상되는 최종 잔액과 일치하지 않으면 오류를 발생시킵니다". 이를 통해 누락 또는 오타를 즉시 잡을 수 있습니다. 기존 소프트웨어는 복식 부기 잔액을 적용할 수도 있지만 Beancount는 사용자에게 더 많은 것을 노출하므로 명시적 검사 (잔액 어설션과 같은)를 추가하고 해당 검사 결과를 직접 보는 것이 좋습니다.

  • 수정 항목은 기록을 보존합니다: 적절한 회계에서는 잘못된 거래를 삭제하는 대신 수정 항목을 추가합니다. 플레인 텍스트 원장은 이러한 관행을 장려합니다 (그리고 Git을 사용하면 과거 항목을 _변경_하더라도 이전 버전은 기록에 남아 있습니다). 감사자는 데이터가 기록 없이 변경되었다고 의심하기보다는 수정 사항의 추적을 명확하게 볼 수 있습니다. 사용자가 액세스 권한이 있는 경우 기술적으로 텍스트 파일의 기록을 편집하는 것을 막는 것은 없지만 커밋 무결성이 있는 Git을 사용하거나 커밋에 서명하는 것은 무단 또는 추적되지 않은 변경 사항을 완화할 수 있습니다. 개방성은 또한 좋은 습관을 조성합니다. 한 토론에서는 플레인 텍스트 회계에서 _"항목을 [단순히] 수정할 수 없습니다"_라고 지적했습니다. 감사 추적을 보존하기 위해 "수정 항목을 만들어야 합니다...". 요컨대 시스템 자체가 투명하므로 장부를 조작하려는 시도는 흔적을 남길 가능성이 큽니다.

  • 외부 감사자를 위한 감사 추적: 공식 감사 (비즈니스 또는 비영리 단체)를 받아야 하는 경우 Beancount 원장을 제공하는 것은 전체 버전 기록이 있는 소스 코드를 제공하는 것과 같습니다. 감사자는 원시 거래 로그를 검토하거나 소스 데이터에서 직접 지원 문서를 생성 (예: 저널 보고서 또는 대차 대조표)하여 일관성을 확인할 수 있습니다. 세금 계산을 당국에 정당화해야 했던 한 Beancount 사용자는 각 자산 로트의 _"전체 기록"_이 있어 수치를 "매우 쉽게 지적하고" 파생 방법을 증명할 수 있었습니다. 플레인 텍스트 기록의 명확성과 내보낸 보고서의 결합은 소프트웨어 뒤에 숨겨진 것이 없으므로 보고서의 모든 숫자를 원장 파일의 줄로 다시 추적할 수 있으므로 감사를 신속하게 처리할 수 있습니다.

  • 무제한 실행 취소 및 실험: 텍스트 + 버전 제어의 조합으로 인해 두려움 없이 계정을 재구성하거나 리팩터링할 수 있습니다. 아이디어가 효과가 없으면 이전 커밋으로 되돌릴 수 있습니다. 이러한 자유는 시간이 지남에 따라 회계 구조를 개선하고 조정하는 것을 장려합니다 (예: 하나의 계정을 여러 개로 분할하거나 새 범주 추가). 기존 시스템에서는 거래가 입력되면 위험하거나 되돌릴 수 없을 수 있습니다. 사용자는 Git 체크포인트로 인해 원장 변경 사항을 "실험하는 동안 무언가를 망칠 염려가 없습니다", 언제든지 롤백할 수 있기 때문이라고 지적했습니다. 이는 회계 시스템이 정상적으로 진화할 수 있고 각 단계에서 감사 가능한 기록이 보존됨을 의미합니다.

공개 데이터 및 오픈 소스를 통한 투명성

Beancount의 접근 방식은 데이터와 논리 모두에서 투명성을 극대화합니다.

  • 불투명한 형식 제거: Beancount는 누구나 읽을 수 있는 일반적이고 공개된 형식을 사용합니다. 독점적인 이진 파일 또는 잠긴 데이터베이스에 데이터를 저장할 수 있는 일반적인 회계 소프트웨어와 달리 Beancount 원장은 텍스트일 뿐입니다. 이 _"공개 형식"_은 _"데이터가 공개되어 있으며 영원히 공개 상태로 유지됩니다"_를 의미합니다. 데이터를 이해하기 위해 Beancount가 필요하지 않습니다. 필요할 경우 텍스트 편집기에서 원장을 열거나 인쇄할 수 있습니다. 독점적인 데이터 사일로를 제거함으로써 Beancount는 사용자가 자신의 금융 기록에 액세스하기 위해 특정 공급업체의 소프트웨어에 의존하지 않도록 합니다. 예를 들어 많은 QuickBooks 사용자가 모든 데이터를 내보내거나 새 시스템으로 변환하는 데 어려움을 겪었습니다. Beancount를 사용하면 변환이 간단합니다. 데이터가 이미 범용 형식으로 되어 있습니다. Beancount 문서에 따르면 "공개 형식을 사용하면 알 수 없는 형식의 이진 블롭에 데이터가 있고 소프트웨어가 지원되지 않는 상황에 처하게 되지 않습니다".

  • 회계 논리의 명확성: 기존 회계 프로그램은 계정 합산, 환율 적용, 잔액 계산 등 많은 계산을 백그라운드에서 수행합니다. Beancount도 이 작업을 수행하지만 논리가 사용자에게 숨겨져 있지 않습니다. 복식 부기 규칙은 투명하고 일관적입니다. 예를 들어 잔액이 맞지 않으면 Beancount는 정확히 어떤 계정과 어떤 거래가 이를 유발했는지 알려줍니다. 또한 Beancount 자체는 오픈 소스 Python 코드입니다. 누군가가 투자에 대한 평균 원가를 계산하는 방법 또는 대차 대조표를 생성하는 _방법_을 감사하고 싶다면 소스를 검사하거나 해당 코드에 대한 커뮤니티 조사를 사용할 수 있습니다. 소프트웨어의 동작은 문서화되고 결정적입니다. 항목의 자동 수정 또는 공개되지 않은 가정은 없습니다. 이는 사용자의 완전한 인식 없이 항목을 자동 조정 (숨겨진 "반올림 차이" 계정 생성 등)할 수 있는 일부 금융 소프트웨어와 대조됩니다. Beancount를 사용하면 모든 보고서의 모든 숫자가 사용자