복식부기를 방향성 그래프로 표현하기

 (matheusportela.com)
3P by GN⁺ | ★ favorite | 댓글 1개
  • 회계 용어가 낯설어도 계정과 잔액을 시간에 따라 추적하는 구조로 보면 복식부기를 돈의 흐름 모델로 이해할 수 있음
  • 현재 잔액만 덮어쓰는 표는 변화 과정을 잃지만, 원장은 거래가 생길 때마다 항목을 추가해 이력과 수정 흔적을 남김
  • 단식부기는 계정별 변화 기록에는 충분할 수 있으나, 여러 계정이 함께 움직이면 관련 항목을 거래로 묶어 출처와 도착지를 드러내야 함
  • 복식부기는 거래마다 나가는 금액과 들어오는 금액이 같아야 하며, 이 균형 조건이 수작업 회계에서 체크섬처럼 오류를 잡아줌
  • 계정과 거래를 노드로, 차변·대변 항목을 방향 있는 간선으로 보면 장부는 시간이 지나며 커지는 방향성 그래프가 되고 재무제표도 그 시각화로 볼 수 있음

잔액만 기록할 때 잃는 정보

  • 회계는 시간에 따라 셀 수 있는 대상을 추적하는 일이며, 여기서는 돈의 흐름에 초점을 둠
  • 예시에서는 2024년 1월 1일 Alice가 $100, Bob이 $50을 가진 상태에서 시작함
  • Alice가 Bob에게 책값 $20을 지급하면 Alice의 잔액은 $80, Bob의 잔액은 $70이 됨
  • 여기서 계정(account) 은 돈이 저장되는 장소이고, 잔액(balance) 은 특정 시점에 계정에 들어 있는 돈의 양임
  • 현재 잔액만 덮어쓰면 Alice가 왜 $80을 갖게 됐는지 알기 어려움
    • 처음에 $0에서 $80을 받은 것인지
    • $10,000에서 $9,920을 쓴 것인지 구분할 수 없음
  • 잔액 스냅샷만 남기는 방식은 변화가 일어난 과정을 지워버림

단식부기 원장과 불변 기록

  • 변화 이력을 남기려면 거래가 발생할 때마다 기존 값을 바꾸지 않고 새 행을 추가해야 함
  • 원장 항목에는 보통 다음 정보가 들어감
    • Description: 거래 설명, 지급 대상, 참조 번호 등 사람이 읽을 수 있는 설명
    • Date: 거래 발생일이며, 월별 보고 같은 기간별 그룹화에도 사용 가능함
    • Balance: 거래 이후 계정 잔액으로, 중복 정보지만 데이터 검토에 유용함
  • 각 행은 항목(entry) 이고, 한 계정의 항목 모음은 원장(ledger) 임
  • Alice 원장에는 2024년 1월 1일 opening balance $100, 2024년 2월 1일 bought book -$20이 기록됨
  • Bob 원장에는 opening balance $50, sold book $20이 남음
  • 이런 방식은 단식부기(single-entry bookkeeping) 시스템임
    • 각 계정이 자기 원장을 가짐
    • 한 번에 한 계정에 영향을 주는 항목을 기록함
    • 소규모 사업이나 개인 재무에는 잘 맞을 수 있음

원장은 이벤트 소싱처럼 동작함

  • 원장의 중요한 특징은 데이터가 불변(immutable) 이라는 점임
  • 항목을 한 번 쓰면 전체 이력을 보존하기 위해 수정하지 않음
  • 책값을 $20으로 잘못 기록했지만 실제 가격이 $30인 경우, 기존 행을 바꾸면 원래 금액과 수정 사실을 잃게 됨
  • 더 나은 방식은 기존 항목을 상쇄하는 새 항목을 추가하고, 올바른 항목을 다시 넣는 것임
    • -$20 항목을 +$20으로 취소함
    • 이후 -$30 항목을 새로 기록함
    • 최종 잔액은 $70으로 같지만, 오류와 수정 이유가 남음
  • 이 방식은 컴퓨터 과학의 이벤트 소싱(event sourcing)과 비슷함
    • 시스템에서 발생한 이벤트를 저장함
    • 이벤트를 재생해 현재 상태를 계산함
    • 특정 시점의 상태를 다시 만들 수 있음

복식부기가 필요한 순간

  • 여러 계정이 함께 움직이는 거래에서는 단식부기만으로 관계를 명확히 알기 어려움
  • Alice의 -$20과 Bob의 +$20은 같은 돈이지만, 단순 원장만 보면 Bob이 Charlie에게서 돈을 받았을 가능성과 구분되지 않음
  • 관련 항목을 거래(transaction) 로 묶으면 같은 사건에 속한 항목임을 명시할 수 있음
    • Transaction 1: Alice의 opening balance
    • Transaction 2: Bob의 opening balance
    • Transaction 3: Alice가 Bob에게 책을 구매함
  • 거래는 서로 다른 계정에 영향을 주는 관련 항목들의 묶음임
  • 복식부기는 계정 간 돈의 흐름을 볼 수 있도록 관련 항목을 거래 단위로 연결함

차변, 대변, 균형 조건

  • 전통 회계는 돈의 흐름을 debit과 credit 두 열로 표현함
    • Credit: 계정에서 돈이 나가는 항목
    • Debit: 계정으로 돈이 들어오는 항목
  • Alice가 Bob에게 $20을 지급하면 Alice 계정은 $20 credit, Bob 계정은 $20 debit으로 기록됨
  • 은행 카드의 credit/debit 용어와 회계의 debit/credit 용어는 다르게 쓰임
  • 종이 장부에서는 왼쪽을 debit, 오른쪽을 credit으로 나누는 T-account 형식이 쓰였음
  • 컴퓨터 시스템에서는 꼭 두 열을 유지할 필요가 없음
    • Type 열에 Debit 또는 Credit을 넣고 Amount를 따로 둘 수 있음
    • 또는 credit을 음수, debit을 양수로 정하는 단일 금액 열을 쓸 수 있음
  • 전통 용어보다 incoming money와 outgoing money가 덜 혼란스러운 표현일 수 있음

거래는 두 항목으로 제한되지 않음

  • 복식부기의 핵심 원칙은 각 거래 후 시스템 전체 돈의 합이 변하지 않는다는 점임
  • 특정 계정 잔액은 늘거나 줄 수 있지만, 모든 계정 잔액의 합은 일정해야 함
  • Opening balance도 균형을 맞추려면 돈이 어디선가 나와야 함
  • 예시에서는 Bank 계정을 추가해 Alice의 $100, Bob의 $50이 Bank에서 나간 것으로 기록함
  • 이 Bank 계정은 규칙을 지키기 위한 일종의 임시 계정이며, 회계 용어로는 contra account에 해당함
  • 모든 거래는 나가는 돈과 들어오는 돈이 같아야 하며, 이는 수작업 회계에서 오류를 잡는 체크섬(checksum)처럼 작동함
  • 복잡한 거래도 같은 원칙으로 모델링할 수 있음
    • Alice는 Bob에게 $20을 지급하고 신용카드 회사에 외환 수수료 $2를 지급함
    • Bob은 Alice에게 $20을 받고 세무 당국에 판매세 $2, 신용카드 회사에 수수료 $1을 지급함
    • 신용카드 회사는 Alice에게서 $2, Bob에게서 $1을 받음
    • 세무 당국은 Bob에게서 $2를 받음
  • 이 경우 하나의 Transaction 3에는 정확히 8개 항목이 포함됨
  • “Double-entry”는 거래가 두 항목만 가진다는 뜻이 아니라, 돈이 나가는 쪽과 들어오는 쪽이라는 두 면을 가진다는 뜻임

장부를 방향성 그래프로 보기

  • 복식부기는 돈의 흐름을 방향성 그래프로 모델링한 것으로 볼 수 있음
  • 그래프 대응 관계는 다음과 같음
    • 계정은 그래프의 노드
    • 거래도 별도의 노드
    • Credit 항목은 계정에서 거래로 향하는 나가는 간선
    • Debit 항목은 거래에서 계정으로 향하는 들어오는 간선
    • 항목의 금액은 간선의 값
    • 계정 잔액은 들어오는 간선 합에서 나가는 간선 합을 뺀 값
  • Transaction 1은 Bank에서 Alice로 $100을 이동시킴
  • Transaction 2는 Bank에서 Bob으로 $50을 이동시킴
  • Transaction 3은 Alice에서 Bob으로 $20을 이동시킴
  • 이 표현에서는 Alice의 잔액이 $80, Bob의 잔액이 $70이 됨

복잡한 거래를 나누는 모델링 선택

  • 수수료와 세금까지 하나의 거래에 모두 넣으면 Transaction 3의 간선이 많아져 복잡해짐
  • 같은 돈의 흐름을 더 작은 거래로 나눌 수도 있음
    • Alice 계정에서는 $22가 나감
    • Bob은 $19를 받음
    • 나머지 $3는 신용카드 회사로 감
    • Bob의 판매세 $2는 별도 Transaction 4로 처리됨
  • 어떤 방식으로 거래와 항목을 묶어도 최종 계정 잔액은 같을 수 있음
    • Alice: $78
    • Bob: $67
    • Tax authority: $2
    • Credit card company: $3
  • 회계 시스템은 다양한 요구를 수용할 만큼 유연하며, 거래와 항목의 그룹화 방식은 사업에 맞게 정해야 함

재무제표는 그래프의 시각화

  • 그래프는 새 거래가 추가될수록 시간이 지나며 커짐
  • 그래프의 기본 속성은 계속 유지됨
    • 계정은 노드로 남음
    • 거래는 돈의 흐름을 강제하는 노드로 남음
    • 거래마다 나가는 금액 합과 들어오는 금액 합이 같아야 함
  • Balance sheet, income statement, cash flow statement는 이 그래프의 시각화로 볼 수 있음
  • Assets, liabilities, equity, income, expenses 같은 분류는 그래프 안의 노드 그룹으로 볼 수 있음
  • 그래프 관점으로 보면 credit과 debit이 각 분류의 잔액을 어떻게 늘리거나 줄이는지 더 직관적으로 이해할 수 있음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 복식부기를 “Alice 항목 하나, Bob 항목 하나”로 설명하는 건 이상한 선택으로 보임
    거래 당사자가 둘이면 두 곳에 기록될 수 있다는 건 당연하지만, 핵심은 거래의 각 당사자마다 두 항목이 필요하다는 데 있음. Alice가 Bob에게서 책을 사면 항목은 네 개가 만들어짐
    교육용 단순화라는 건 알겠지만, 핵심을 빼버린 과도한 단순화라고 봄

    • Quickbooks 같은 소프트웨어를 회계 배경 없이 이해하려면, 회사의 각 계정을 자기 장부를 가진 행위자로 의인화하는 모델이 실제로 도움이 될 수 있음
      예를 들어 현금으로 매입채무를 지급할 때는 Accounts Payable 행위자와 Cash 행위자에게 동시에 메시지를 보내는 식이고, 각 행위자는 그 사건을 자기 성격에 맞게 차변/대변으로 번역해 잔액을 유지함. 이 관점에서 복식부기는 각 사건이 짝수 개의 행위자에게 정확히 한 번씩 흡수되어야 한다는 뜻에 가까움
      결제 레일을 만든다면 그 사건 자체도 거래 의도를 추적하는 메타 사건에서 파생된 한 쌍의 사건 중 하나일 수 있음. 회계에서 말하는 그래프의 간선은 돈이 아니라, 파생 사건 계층 안의 데이터라고 보는 편이 더 유용함
      다만 원문은 이 비유가 무엇을 위한 것인지 분명히 하지 못했고, 혼란을 줄이기보다 늘릴까 걱정됨
    • 같은 말을 쓰려던 참이었음. 복식부기가 내 장부에만 적용된다는 걸 알고 있으면, Bob 장부에도 항목이 있다는 예시는 오히려 헷갈림
      Bob의 회계 장부는 신경 쓰지 않고, 내 장부만 추적하고 싶음. 내가 책을 샀다면 내 회계 장부에는 이 거래를 복식부기로 어떻게 기록해야 하는지가 궁금함
      게다가 Bob은 부기를 하는 게 아니라 책을 파는 중임 ;-)
    • 복식회계 설명은 대체로 같은 실수를 하는 듯함. 복식부기에서 double이 정확히 무엇을 가리키는지, 무엇이 “두 배”가 되는지가 알고 싶음
      이 글을 고쳐서 “double” 부분을 제대로 설명하려면 어떻게 해야 할까? Bob 또는 Alice 한쪽 관점만으로도 가능할까?
    • 기술적으로도 틀렸음
      예를 들어 은행은 내가 대출을 갚지 못할 것 같다고 판단해 장부에서 0으로 감액할 수 있음. 나는 갚을 생각이 있어서 내 장부에는 여전히 부채를 남겨둘 수 있음. 은행은 자기 시스템에서 관련 항목을 만들고 차변/대변이 맞아떨어지며, 나는 아무것도 하지 않아도 내 장부는 균형을 유지함
      복식부기는 다른 주체와 무관하고, 오직 자기 장부에 관한 것임
    • CPA 입장에서 쓴 내 설명이 더 직관적이길 바람: https://www.winstoncooke.com/blog/a-basic-introduction-to-ac...

  • 회계의 아름다움과 영향력은 과소평가된다고 봄
    아주 적은 수의 공식, 즉 회계 항등식과 손익계산서·재무상태표 같은 재무제표만으로 어떤 조직에서 벌어지는 일을 대략 비교 가능한 방식으로 표현할 수 있음. 미적분학의 기본정리나 생물학의 중심원리 같은 느낌도 듦
    회계는 수학과 문자 언어의 기원이기도 함. 고대 메소포타미아 문명은 처음에 상품을 추적하려고 대상의 모양을 본뜬 “회계 토큰”을 썼고, 그것이 문자 언어, 예컨대 상형문자로 발전했다고 볼 수 있음
    나중에 Al-Khwarizmi가 이슬람 상속법을 풀기 위해 Al-Jabr, 즉 algebra를 만들었고, 상속 분배 규칙이 방정식이 되면서 빠르고 정확히 푸는 필요가 생겼음. Al-Khwarizmi의 이차방정식 해법이 “algorithm”이라는 이름의 기원이 됨
    https://en.wikipedia.org/wiki/Accounting_identity
    https://en.wikipedia.org/wiki/History_of_accounting
    https://en.wikipedia.org/wiki/History_of_ancient_numeral_sys...
    https://en.wikipedia.org/wiki/Al-Jabr
    https://en.wikipedia.org/wiki/Al-Khwarizmi

    • 반대로 전통적 회계 방식 중 일부는 회계가 많은 “현대” 수학보다 먼저 생겼기 때문에 생긴 제약을 안고 있음
      음수는 중국에서 3세기쯤 처음 쓰였고, 유럽에서는 16세기까지 널리 쓰이지 않았음. 현대적 복식부기는 14세기 유럽에서 만들어졌음
      그래서 차변 열과 대변 열을 따로 두고 정의가 좀 이상해 보이는 전통적 방식은, 양수만으로 동작시키기 위한 최선의 방법이었음
    • 회계의 모든 것이 맞아떨어져야 한다는 점에는 깔끔한 단순함이 있지만, 거기서 “손익계산서와 재무상태표가 어떤 조직의 상황도 대략 비교 가능하게 표현한다”로 확장하면 꽤 금융화된 세계관처럼 들림
      조직 설계의 중요한 측면 중에는 재무제표와 느슨하게만 상관된 것들이 많음
    • 회계의 영향력은 정말 과소평가됨. 1800년대 전후까지 유럽에는 일부 수학자를 제외하면 음수가 없었고, 계산은 가능하다고 해도 명백히 의미 없는 것으로 여겨졌음
      부기가 사회의 모든 층위에 뿌리내린 뒤에야 음수가 양수만큼 실제적인 것으로 받아들여졌음
    • 조직에서 무슨 일이 벌어지는지 표현할 수도 있지만, 꽤 잘 가릴 수도 있음

  • 복식부기는 우스꽝스러운 “credit”과 “debit” 용어를 버리면 아주 이해하기 쉬움
    핵심은 회계 방정식이 항상 참이 되도록 유지하는 것임. 기본식은 Equity = Assets - Liabilities이고, 이익은 결국 자본에 들어가므로 Equity + Income - Expenses = Assets - Liabilities가 됨. 음수를 없애도록 정리하면 Equity + Income + Liabilities = Assets + Expenses임
    이 식은 항상 참이어야 하며, 그렇지 않으면 돈이 아무 데서나 생기거나 사라진 셈임. 따라서 식의 왼쪽 계정에 돈을 더하면 반대쪽 계정에도 같은 금액을 더하거나, 같은 쪽에서 같은 금액을 빼야 함
    예를 들어 레모네이드를 5달러에 팔면 Sales(Income)에 5달러를 더하고 Current Account(Assets)에도 5달러를 더함
    “credit”과 “debit”이 우스꽝스러운 이유는 계정 종류에 따라 정의가 뒤바뀌기 때문이고, 이 터무니없는 언어 사용이 사람들이 헷갈리는 주된 이유임

    • 회계 방정식으로 생각하는 게 맞음. 사람들은 debit과 credit에 필요 이상으로 의미를 부여하려고 함
      100단계 회계 수업 강사가 꽤 간결하게 말했음. Debit은 왼쪽 열의 항목이고, Credit은 오른쪽 열의 항목임. 그 거래가 사업에 어떤 의미인지는 계정에 따라 달라짐
    • “우스꽝스러운 credit/debit 용어를 버리면 복식부기는 쉽다”는 말이 마음에 듦
      회계를 배우지 않은 사람에게는 이 용어 사용이 엄청나게 혼란스럽고, 헷갈리는 사람에게 달린 여러 답변은 기술적으로 맞아도 동시에 별 도움이 안 됨. 이미 용어를 안다는 전제를 깔기 때문임
      “잔액이 늘었는데 왜 은행 계좌가 debited 되는가? debit은 음수가 아닌가? 현금 잔액이 음수로 표시되는 건가?”라는 질문은 정말 좋은 질문임. 직관적으로는 direct debit은 돈이 빠져나가고, debit card로 돈을 쓰며, debit은 debt처럼 들리니 debit은 항상 음수라고 생각하게 됨
      같은 단어를 두고 서로 다른 언어를 쓰는 것처럼 엇갈리는 모습은 재미있으면서도 답답함. 작은 표현을 꼬집어 자신이 맞다는 걸 보이려는 식으로 흘러가기도 함
    • “incoming”과 “outgoing”으로 바꾸자는 제안도 같은 문제가 있어 보임
      레모네이드에 5달러를 쓰는 사람 입장에서는 자기 Sales 항목에 5달러를 넣는 게 전혀 아니기 때문임. 이 글과 댓글에서 말하는 혼란이 정확히 무엇인지 아직 완전히 이해하지 못하겠음
    • 복식부기는 “회계 방정식”이라는 우스꽝스러운 표현을 버리면 아주 이해하기 쉬움
      credit은 출처, debit은 도착지를 뜻함
      고객에게 10,000유로를 청구하면, 현재 환율 기준으로 11,000달러짜리 약속이 생김. 그러면 출처인 “Income: Customer A” 계정에 11,000달러를 credit하고, “Assets: Accounts Receivable”에 11,000달러를 debit함
      나중에 고객이 돈을 냈는데 환율이 움직여 10,500달러만 받았다면, 원래 11,000달러로 기록한 약속이 출처이므로 Accounts Receivable에 11,000달러를 credit함. 현금 10,500달러를 받았으니 cash에 10,500달러를 debit하고, 차변과 대변을 맞추기 위해 “Expenses: Loss on Foreign Exchange”에 500달러를 debit함
      보통 영업일마다 회사를 청산하지 않는데, 왜 그 500달러를 가상의 즉시 청산 시나리오에 억지로 끼워 넣으려 하겠는가. 그냥 credit과 debit의 균형으로 기록하면 됨
    • 대학 경제학 수업에서 가장 기억에 남는 건 경제학자들이 아주 특이한 수학 관례를 쓰고도 신경 쓰지 않는다는 점임
      독립변수를 Y축에 둔 그래프가 너무 많았음

  • “Credit은 계정에서 돈이 나가는 항목, Debit은 계정에 돈이 들어오는 항목”은 정확하지 않음
    debit과 credit의 의미는 계정 유형에 따라 달라짐: https://en.wikipedia.org/wiki/Debits_and_credits
    CPA가 되려면 한 과목 이상이 필요한 데는 이유가 있을지도 모름: https://www.accounting.com/careers/cpa/how-to-become/

    • 회계를 볼 때마다 계정 종류가 늘 헷갈림. 어떤 계정이 어디에 쓰이는지, 어떤 계정에서 credit이 양수이고 어떤 계정에서 음수인지 도무지 잘 안 잡힘
      내가 보기에는 사람이 항목을 입력하고 계산하던 시절에 특정 오류를 잡으려고 일을 두 배로 늘린 방식처럼 보임. 그 자체로는 말이 됨
      하지만 컴퓨터가 모든 계산을 하는 세상에서 자라서인지, 같은 일을 반복하지 말라는 원칙을 어기는 것처럼 보임. 같은 내용을 두 곳에 적으면 둘 중 하나는 결국 틀리게 마련임
      회계가 현대에 설계됐다면 이렇게 하지는 않았을 것 같음. 내가 회계사가 아니고 이해하지 못한다고 해서 제도가 틀렸다는 뜻은 아니지만, “credit이 자산 계정을 감소시킨다”는 데서 느끼는 혼란은 뭔가 근본적으로 어긋났다는 신호처럼 느껴짐
    • 그 Wikipedia 글의 두 번째 문장은 “계정의 debit 항목은 그 계정으로 가치가 이전되는 것을 나타내고, credit 항목은 그 계정에서 가치가 이전되는 것을 나타낸다”임
    • 대부분의 회계사는 그렇게 생각하지만, 더 근본적인 관점이 있다고 봄
      CR 항목은 회사가 빚진 것, 즉 채권자나 주주에게 부담하는 것이 증가한 것이고, DR 항목은 회사가 가진 것이 증가한 것임
      회계 방정식과의 관계는 여기 참고: https://news.ycombinator.com/item?id=32501707

  • credit/debit 용어에 대한 혼란이 많이 보임
    현대적 관점에서 더 단순하게 생각하려면, 회계가 음수의 대중적 사용보다 훨씬 오래됐다는 점을 떠올리면 됨. 오늘 회계를 발명했다면 debit/credit 계정 대신 양수/음수 계정을 썼을 가능성이 큼
    덧셈 위의 대수는 지금 우리에게 자연스럽지만, 1604년의 보통 상인에게는 당연하지 않았고 음수는 그때도 별로 좋게 받아들여지지 않았음
    중요한 건 거래에는 항상 두 면이 있고 서로 역연산이라는 점임. credit과 debit은 결국 숫자에 대한 역연산임
    그래서 credit = debit이면 거래가 균형을 이룬다는 규칙을 만들 수 있음. 현대식으로는 debit + credit = 0이라고 볼 수도 있지만, 이 체계가 만들어질 때는 음수를 좋아하지 않았으므로 이건 목표라기보다 언제나 성립하는 행복한 우연에 가까움
    손에 든 현금을 가장 양수적인, 즉 debit 성격의 계정으로 보고 거꾸로 생각하면 합리적임. 비용을 처리하려면 현금 계정을 반대로 처리해야 하므로 credit하고, 돈이 간 곳에는 반대 항목으로 debit함. 따라서 비용 계정은 보통 debit 잔액을 가짐
    현금은 어디서 왔을까? 수입에서 왔고, 현금을 debit스럽게 만들고 싶다면 출처는 credit스러워야 거래가 균형을 잃지 않음. 그래서 수입 계정은 보통 credit 계정, 즉 일반적으로 음수 잔액 또는 “credit normal”을 가짐
    이 체계의 멋진 점은 일상적인 모든 거래가 균형 잡힌 거래로 귀결되고, 가능한 계정들이 각자 보통 credit 또는 debit이라는 일관된 잔액 성격을 갖게 된다는 것임. 정말 우아함

    • capital/equity 계정의 정상 잔액을 기억할 때 Capital과 Credit의 두운을 즐겨 씀
      그것과 회계 방정식만 외우면 나머지 모든 계정 유형의 정상 잔액을 도출할 수 있음
    • 음수를 쓰는 게 크게 도움이 된다고 보지는 않음. 예를 들어 수입을 음수로 생각하면 매우 헷갈림
      한 달쯤 전 PTA subreddit에서 PTA 문법을 더 직관적으로 만드는 논의를 시작했는데, 누군가 “from”, 즉 credit/음수 계정과 “to”, 즉 debit/양수 계정을 화살표로 표시하자고 제안했음. 숫자는 부호가 없고 “credit”과 “debit”이라는 용어도 쓰지 않아서 훨씬 직관적으로 느껴짐
      https://www.reddit.com/r/plaintextaccounting/comments/1bh3x7...
    • debit/credit 용어에 혼란이 있다는 걸 보니 안심됨. 나도 확실히 헷갈림
      음수에 관한 배경은 흥미로움

  • 여전히 너무 복잡함. “Transaction 열을 표에 추가하자”에서부터 어긋남
    계정 데이터를 저장하지 말고 거래를 저장해야 함. 계정은 거기서 계산하면 됨. “Transactions” 테이블에는 Date, Amount, SourceAccount, TargetAccount, Description 필드가 있으면 됨
    내가 보기엔 이때 아름다워짐. 은행 명세서에서 익숙하다는 이유로 계정 중심으로 생각하는 습관을 버리고, 현금흐름으로 생각해야 함
    물론 세무 용도에는 너무 단순함. 거래에 여러 출처나 여러 도착지가 있을 때가 있으므로 위 스키마는 조정이 필요함. 그래도 사고방식은 달라야 한다는 게 요지임

    • 부기나 회계 소프트웨어에서 “Rebalance accounts” 같은 기능을 볼 때마다 의심스럽고 조심스러워짐
      프로그래머가 영리하게 굴려고 원천 거래에서 계산하지 않고 누적 합계를 유지하려 했다는 신호임. 거기에는 용들이 있음
    • 그런 설계는 좋지 않으니 하지 않는 편이 좋음
      더 나은 설계는 헤더와 상세 테이블을 두는 것임
      Header: TransactionID, Date, Description, posting status나 reconciliation status 같은 필요한 필드
      Detail: TransactionID, LineNumber, Account, Amount, Description, subledger 참조 번호 같은 필요한 필드
      이렇게 하면 하나의 거래가 임의 개수의 계정에 영향을 줄 수 있음. 결국 거래는 여러 계정에 영향을 미칠 수 있는 비즈니스 거래를 반영하게 됨
    • 현재 잔액을 조회하려고 전체 거래 이력을 매번 재생해야 한다면 꽤 비효율적이지 않나?
    • 그렇게 해서 사람들이 블록체인을 발명한 셈임
      세부적으로는 각 전송의 출력에 출처 주소가 포함되어야 하는 등 조금 더 복잡하지만, 아이디어는 같음. 이 스레드의 다른 곳에서도 말했듯 각 거래에는 여러 입력과 여러 출력이 필요함
    • 기본적으로 beancount가 하는 일이 그거 아닌가?
      평문 파일에 모든 거래가 있고, 평가가 필요할 때 그로부터 전체 원장을 즉석에서 생성함

  • 회계사는 아니지만 예전에 복식부기와 기초 회계를 공부하기로 했고, HN의 좋은 스레드를 포함해 여러 곳에서 많이 배웠음
    이 글에서는 복식부기의 작동 방식과 그것이 방향 그래프라는 걸 깨닫게 된 과정을 설명함. HN에는 회계 덕후가 많으니 틀린 부분이 있으면 비판이나 수정 제안을 부탁함

    • 그 스레드 중 하나는 Martin Kleppmann의 블로그 글이었을 수 있음. 그도 복식부기를 방향 그래프로 설명함
      https://martin.kleppmann.com/2011/03/07/accounting-for-compu...
    • 금융 분야에서 거의 20년 일했는데, 인정하기 조금 망설여지지만 이건 정말 좋음
      내 controllers가 영업 실적을 이런 그래픽 흐름으로 만들어주면 좋겠음. 어느 규모가 되면 회계는 꽤 어려워지고, 회계정책팀에 교수급 인력이 필요할 정도가 됨
      통계에서 배운 건 그래픽이 중요하다는 것임. 적절한 추상화를 쓰면 어떤 수치도 구성 요소의 그래프로 나타낼 수 있음. 순간적으로 이해가 확 열렸음
    • 컴퓨터 과학에서 가장 재미있는 순간 중 하나는 처음에는 그래프처럼 보이지 않던 문제가 사실 어떤 종류의 그래프 문제라는 걸 깨닫는 때임
    • 평생 정보시스템 분야에서 일하면서 얻은 큰 통찰 중 하나는 ERP 시스템의 기반이 되는 구매나 판매 같은 거래가 두 흐름으로 변환된다는 점임
      한쪽에는 들어오거나 나가는 돈, 다른 한쪽에는 제품이나 서비스가 있음. 이것이 회계의 복식기입임. 명백하고 단순해 보일 수 있지만, 내 분야에서 이를 이해하는 사람은 많지 않음

  • 잘 쓴 글이지만, 일반적으로 받아들여진 의미가 있는 용어를 재정의할 때는 조심해야 함
    Debit/Credit을 Incoming/Outgoing으로 바꾸는 건 또 다른 전문용어처럼 보이고 혼란을 부를 수 있음. 어떤 bookkeeper든 credit cash와 debit expense가 무엇인지 이해함
    이를 incoming/outgoing으로 바꿔도 실제 작업을 하는 사람이나 그 작업을 설명해야 하는 사람에게 도움이 되지 않음. 몇백 년간 유용했던 명명법을 배우는 편이, 비유에 기대는 것보다 가치 있음

    • Debit/Credit을 Incoming/Outgoing으로 바꾸는 것이 혼란을 부른다는 데 동의하지 않음
      HN에서 이런 논의가 나오면 늘 누군가 “아주 간단하다. credit은 그냥…”이라고 하고, 곧바로 “거꾸로 알고 있다. 간단하다. credit은…”이라는 답이 달림
      나는 그 용어들을 영원히 버려도 전혀 상관없음
    • 문제는 회계 전문용어가 일반인의 직관과 반대라는 데 있음
      돈이 credited 되거나 credit card를 쓰면 돈이 어디선가 생긴 것처럼 느껴져 좋고, debit은 debt처럼 들리고 내 돈이 줄어든 것 같아 나쁘게 느껴짐
      실제로는 이름에 이유가 있다는 건 알지만, 외부인이 접한 모든 용례와 충돌하는 비직관적 전문용어를 고집하는 분야라면 덜 중복되고 다른 표현을 써도 될 듯함
    • 더 나아가, 기본적인 회계·부기 용어를 아는 건 금융 담당자와 일할 때 초능력에 가까움
      올바른 전문용어를 제대로 써서 대화할 수 있으면 신뢰도가 크게 올라감
    • 이 글의 대상은 이미 회계를 아는 사람이 아닌 것 같음
      회계 전문용어인 debit/credit을 일반인의 말로 설명하는 게 왜 전문용어처럼 보이는지 잘 모르겠음. 내가 일반인이라서 그럴 수도 있음
      회계 배경이 없는 사람에게 credit/debt를 “돈이 들어감, 돈이 나감”으로 설명하는 건 이 글의 맥락에서는 충분히 괜찮아 보임. 여기서 credit/debit의 “진짜” 정의가 의미 있게 다르게 작동하나?

  • David P. Ellerman은 자신이 Pacioli group이라 부르는 것에 기반해 회계에 대한 수학적 접근을 제시함
    Pacioli group의 임시 원소는 x//y처럼 생겼고, x와 y는 음이 아닌 정수임. x//y와 u//v는 교차합 x+v와 y+u가 같으면 동치로 봄
    군 연산은 x//y + u//v = (x+u)//(y+v)이고, x//y의 역원은 y//x이며, 항등원은 0//0임. 자세한 내용은 예를 들어 이 문서를 보면 됨: https://ellerman.org/wp-content/uploads/2012/12/DEB-Math-Mag...

  • 여기서 뭔가 놓치고 있는 것 같음. 거래 이력을 방향 그래프로 보는 게 무엇에 도움이 되는가?
    수백 년 된 복식부기 관행보다 개선된 점이 있는가?
    몇 개 거래짜리 장난감 예시에서는 겨우 동작하는 듯하지만, 노드 쌍 사이에 수십·수백 개 간선이 생기면 그래프가 어떻게 보일지 상상해보면 됨. 일반적인 그래프 알고리즘이 어디에 쓸모 있을지도 모르겠음
    펜치를 망치처럼 쓰는 느낌임. 물론 할 수는 있겠지만, 왜 그래야 하나?

    • 말하는 바는 이해하지만, 두 가지 방식으로 도움이 된다고 봄
      첫째, 개념을 이해하는 또 다른 방법임. 대부분의 경우에는 관련 없을 수 있지만, 어려운 회계 문제가 그래프 이론 적용으로 풀릴지, 혹은 반대로 회계에서 그래프 이론 문제가 풀릴지 누가 알겠음
      둘째, 흐름을 시각화하는 또 다른 방법임. 모두가 금융 문해력이나 숫자 감각이 뛰어난 건 아니므로, 숫자 열이 있는 표를 주고 흐름을 숫자로 추론하게 하는 대신 공간적으로 표현할 수 있음. 모든 도구가 전문가만을 위한 건 아님
      전체 누적 이력을 하나의 그래프로 보면 과할 수 있지만, 거래일 필터만 추가해도 다른 시각화가 놓치는 통찰을 줄 수 있음. 위치 같은 다른 정보와 교차 참조하면 더 유용해질 수도 있음
    • 허황된 접근임. 글이 너무 과장되어 있음
      정당성을 세우지 못했고, 이 시각화가 더 명확한 이해에 도움이 됐다는 저자의 말도 복식부기를 처음부터 geek식으로 설명하는 과정에서 드러나는 범주 오류 때문에 약해짐
      게다가 아주 단순한 거래 하나만 표현했음. 세무상 감가상각과 회계상 감가상각이 다른 경우, 외환 손익 조정, franked dividends 배분, PAYG, 타인을 위해 보관하는 금액, 이연수익 일부 인식 같은 더 추상적인 내용을 그래프 기반 시각화로 어떻게 얻어낼지 모르겠음
    • 이 글은 암호화폐의 초기 아이디어와 비슷한 통찰처럼 느껴짐
      엔지니어들이 다른 분야에 이미 깔려 있던 근본 원리를, 소프트웨어가 그 분야를 복제하게 되면서 뒤늦게 발견하는 식임
답변달기