거의 모든 어려움을 겪고 있는 소규모 기업의 계정 과목표를 열어보면 똑같은 현상을 발견할 수 있습니다: 280개의 계정, 그중 90개는 단 한 번만 사용되었고, '사무용품비'의 수십 가지 변형, 그리고 아무도 설명할 수 없는 3개의 계정들이 그것입니다. 기업주는 2022년에 특정 업체에 정확히 얼마를 썼는지는 말할 수 있지만, 지난 분기에 사업이 수익을 냈는지 여부는 말하지 못합니다.
이것이 바로 부풀려진 계정 과목표의 역설입니다. 계정이 많을수록 정보가 더 많다고 느껴지지만, 실제로는 정반대의 결과를 초래합니다. 즉, 너무나 세분화되어 있고 일관성이 없어서 아무도 읽을 수 없는 손익계산서가 만들어지는 것입니다. 좋은 계정 과목표는 모든 것을 담는 서랍이 있는 파일 캐비닛이 아닙니다. 그것은 보고를 위한 도구이며, 다른 모든 도구와 마찬가지로 특정 질문에 답하기 위해 설계되었을 때 가장 효과적으로 작동합니다.
이 가이드는 실제로 무언가를 알려주는 계정 과목표를 설계하는 방법을 설명합니다. 번호를 매기는 법, 계층 구조의 깊이를 설정하는 법, 하위 계정 대신 부서나 클래스를 사용해야 하는 시점, 그리고 재무제표를 무용지물로 만드는 비대함을 인식하고 제거하는 방법을 다룹니다.
계정 과목표의 진짜 목적
계정 과목표(COA)는 비즈니스에서 자금을 기록하는 데 사용하는 모든 범주의 마스터 목록입니다. 예약된 모든 거래는 이러한 계정 중 하나에 기록되며, 모든 계정은 재무상태표 또는 손익계산서 중 하나의 보고서로 합산됩니다.
계정은 다섯 가지 제품군으로 나뉘며, 그 순서는 임의적인 것이 아닙니다. 이는 재무제표의 구조를 반영합니다:
- 자산(Assets) — 현금, 매출채권, 비품, 재고 등 비즈니스가 소유한 것.
- 부채(Liabilities) — 외상매입금, 대출금, 신용카드, 미납 세금 등 비즈니스가 갚아야 할 것.
- 자본(Equity) — 자본금, 이익잉여금, 배당금 등 소유자의 잔여 지분.
- 수익(Revenue) — 비즈니스 활동을 통해 벌어들인 것.
- 비용(Expenses) — 판매된 제품의 직접 원가를 포함하여 비즈니스 운영을 위해 지출하는 것.
처음 세 가지 제품군은 재무상태표를 구성합니다. 마지막 두 가지는 손익계산서를 구성합니다. 계정 과목표를 설계할 때 하는 모든 작업은 이 두 보고서를 한눈에 읽기 쉽게 만들기 위한 것입니다.
좋은 계정 과목표를 테스트하는 방법은 간단합니다. 손익계산서를 출력했을 때, 어떤 항목을 보더라도 그에 대해 무엇을 해야 할지 알 수 있습니까? 만약 특정 항목이 "기타 비용 — $14,200"이라고 되어 있다면, 대답은 "아니오"입니다. 그 계정은 당신에게 아무것도 알려주지 않습니다. 무언가를 숨기고 있을 뿐입니다.
번호 매기기: 무언가를 걸기 전에 프레임부터 구축하기
계정 번호는 뼈대입니다. 회계 소프트웨어에서 이름만으로 작업할 수 있더라도, 번호 체계를 사용하면 계정을 예측 가능한 순서로 유지하고 계정 과목표를 쉽게 훑어볼 수 있습니다.
거의 전 세계적으로 통용되는 관습은 계정 제품군을 천 단위로 그룹화하는 것입니다:
| 범위 | 계정 분류 |
|---|---|
| 1000–1999 | 자산 |
| 2000–2999 | 부채 |
| 3000–3999 | 자본 |
| 4000–4999 | 수익 |
| 5000–5999 | 매출원가 |
| 6000–7999 | 판매비와 관리비 |
| 8000–9999 | 영업외수익 및 비용 |
대부분의 소규모 기업은 4자리 숫자로 충분합니다. 규모가 매우 작고 그 상태를 유지할 계획이라면 3자리 체계도 작동하지만, 4자리는 추가 비용 없이 훨씬 더 많은 여유를 제공합니다.
두 가지 규칙을 지키면 번호 체계가 현실의 변화에도 살아남을 수 있습니다:
간격을 두고 번호를 매기십시오. 6000, 6001, 6002로 지정하지 마십시오. 6000, 6010, 6020으로 지정하거나 주요 그룹의 경우 6100, 6200, 6300으로 지정하십시오. 기존의 두 계정 사이에 새로운 계정이 반드시 필요해질 때, 아래의 모든 번호를 다시 매기는 대신 그 간격 사이에 끼워 넣을 수 있습니다. 여유를 두는 것은 계정 과목표 설계에서 가장 비용이 적게 드는 결정이며, 이를 잊는 것은 가장 흔한 후회 중 하나입니다.
첫 번째 자리의 일관성을 유지하십시오. 6000번대 번호는 항상 판매비와 관리비여야 합니다. 누군가가 "가까우니까"라는 이유로 5000번대 번호 아래에 부채를 기록하는 순간, 보고서의 정합성이 깨지고 번호 체계는 유일한 제 역할을 하지 못하게 됩니다.
얼마나 깊어야 할까? 비대화 문제
이 지점이 대부분의 계정 과목표가 잘못되는 곳입니다. 사업체의 누군가가 "소프트웨어에 얼마를 쓰고 있나요?"라는 타당한 질문을 던지면, 반사적으로 새로운 계정을 만듭니다. 그러다 또 다른 계정을 만듭니다. 그러다 각 소프트웨어 벤더별로 별도의 계정을 만듭니다. 계정 과목표는 매번 선의로 추가된 계정들로 인해 읽을 수 없게 될 때까지 반응적으로 늘어납니다.
이것이 **계정 과목표 비대화(COA bloat)**입니다. 다른 방식으로 처리했어야 할 보고 요구 사항을 충족하기 위해 원장 계정이 통제 불가능하게 늘어나는 현상입니다. 그 메커니즘은 항상 동일합니다. 누군가가 새로운 데이터 조각을 원할 때, 새로운 *속성(attribute)*을 추가하는 대신 새로운 계정을 추가하는 것입니다.
비대화는 놓치기 쉬운 방식으로 큰 비용을 발생시킵니다:
- 일관성 없는 코딩. 소프트웨어 비용을 기록할 수 있는 그럴듯한 장소가 12곳이나 있다면, 두 명의 장부 담당자(또는 다른 날의 동일한 담당자)는 서로 다른 선택을 할 것입니다. 추세선은 의미 없는 노이즈가 됩니다.
- 읽기 힘든 재무제표. 140개의 비용 항목이 있는 손익계산서는 30개가 있는 것보다 더 유익하지 않습니다. 어떤 인간도 140개의 숫자를 한꺼번에 머릿속에 담을 수 없기 때문에 오히려 정보 가치가 떨어집니다.
- 결산 지연. 모든 계정은 검토하고 조정하고 설명해야 할 대상입니다. 비대화는 5일이면 끝날 결산을 3주로 늘려버립니다.
- 휴면 계정. 비대해진 계정 과목표의 절반은 한 번 사용하고 방치된 계정들이며, 각각은 미래에 잘못된 코딩을 유발하는 작은 함정이 됩니다.
대략적인 기준점으로, 대부분의 소규모 기업은 총 30개에서 60개 사이의 계정만 있으면 됩니다. 몇 개의 수익 계정, 깔끔하게 분리된 매출원가, 20~30개의 판관비 계정, 그리고 실제로 비즈니스가 보유한 재무상태표 계정들입니다. 만약 당신의 계정 과목표에 200개의 계정이 있는데 직원이 8명뿐이라면, 그 표는 당신의 비즈니스를 묘사하는 것이 아닙니다. 그것은 지금까지 누군가가 던졌던 모든 질문을 묘사하고 있는 것입니다.
비대화를 방지하는 훈련은 새로운 계정을 만들기 전에 단 하나의 질문을 던지는 것입니다: "이 항목이 존재함으로 인해 내가 다른 의사결정을 내리게 될 것인가?" 만약 "마케팅"을 "페이스북 광고"와 "구글 광고"로 나누는 것이 예산 배분 방식을 바꾼다면, 나누십시오. 만약 두 수치를 대충 훑어보고 지나칠 뿐이라면, 하나로 유지하십시오. 계정은 이론적으로 구별된다는 이유가 아니라, 의사결정을 변화시킴으로써 그 자리를 차지할 가치를 증명해야 합니다.
구조를 위한 계정, 상세 정보를 위한 차원
대부분의 계정과목표 비대화는 한 가지 실수에서 비롯됩니다. 계정의 성격에 맞지 않는 항목을 기록하기 위해 계정을 사용하는 것입니다.
기업은 단순히 돈을 무엇에 썼는지만 알고 싶어 하지 않습니다. 어디에서, 어떤 프로젝트를 위해, 어느 지점에서, 어떤 고객을 위해 썼는지 알고 싶어 합니다. 이러한 질문에 답하기 위해 다음과 같이 계정을 늘려가는 것은 잘못된 방식입니다:
6100 급여 — 영업
6101 급여 — 엔지니어링
6102 급여 — 운영
6110 여비교통비 — 영업
6111 여비교통비 — 엔지니어링
6112 여비교통비 — 운영
6120 소프트웨어 — 영업
...세 개의 부서와 세 개의 비용 유형만으로 벌써 아홉 개의 계정이 생겼지만, 계정과목표(COA) 상에서는 합산하지 않고는 전체 급여를 바로 알 수 없습니다. 네 번째 부서가 추가되면 계정과목표를 다시 수정해야 합니다.
올바른 방법은 비용 유형별로 하나의 계정을 유지하고, 각 거래에 다른 세부 사항을 태그로 지정하는 것입니다:
6100 급여
6110 여비교통비
6120 소프트웨어영업, 엔지니어링, 운영과 같은 부서는 거래의 별도 필드가 됩니다. 회계 소프트웨어마다 이 필드를 부르는 명칭이 다릅니다. QuickBooks에서는 클래스(class) 또는 위치(location), Xero에서는 추적 카테고리(tracking category), Sage Intacct나 NetSuite에서는 **차원(dimension)**이라고 부릅니다. 원칙은 동일합니다. 계정은 어떤 종류의 비용인가에 답하고, 차원은 비즈니스의 어느 부분인가에 답합니다.
이러한 분리는 복합적인 이점을 제공합니다. 하나의 급여 계정과 부서 차원을 사용하면 전체 급여, 부서별 급여, 전체 여비교통비, 부서별 여비교통비, 부서별 전체 지출을 모두 동일한 데이터에서 별도의 합산 작업 없이 추출할 수 있습니다. 반면 아홉 개의 중복된 계정을 사용하면 이 중 단 하나의 뷰만 볼 수 있으며 나머지는 수동으로 합산해야 합니다.
유용한 실무 원칙: 라벨이 자금의 성격을 설명한다면 그것은 계정입니다. 부서, 프로젝트, 위치, 고객, 보조금, 펀딩 라운드와 같이 자금이 발생한 맥락을 설명한다면 그것은 차원입니다. 텍스트 기반 회계 도구는 이 개념을 직접적으로 활용합니다. Beancount에서는 모든 조합을 계정과목표에 하드코딩하는 대신, 포스팅에 메타데이터를 태그하거나 계정 계층 구조를 사용하여 리포팅 계층에서 데이터를 슬라이싱할 수 있도록 합니다.
하위 계정: 적당할 때 유용함
부모 계정 아래에 자식 계정을 중첩하는 하위 계정은 상세 정보를 담는 정당하고 구조적인 방식입니다. 6200 보험료 아래에 6210 일반배상책임, 6220 산재보험, 6230 건강보험을 두는 것은 합리적입니다. 이들은 실제로 성격이 다른 비용이며, 관리 방식이 다르고, 관리자가 각각에 대해 의사결정을 내릴 수 있기 때문입니다.
하위 계정은 다음과 같은 경우에 제 역할을 다합니다:
- 부모 계정의 총계가 보고 대상이며, 동시에
- 각 자식 계정이 별도로 조사하거나 조치를 취해야 할 대상인 경우.
하지만 실제 의사결정 수준보다 더 세분화되기 시작하면 불필요한 비대화가 됩니다. 사무용품비를 종이, 펜, 토너, 포스트잇으로 나누는 것은 이 테스트를 통과하지 못합니다. 아무도 포스트잇 예산을 따로 관리하지 않기 때문입니다. 하나의 사무용품비 계정을 유지하는 것이 정직한 수준의 상세 정보입니다.
두 가지 실질적인 제한 사항: 중첩은 부모와 자식이라는 최대 2단계까지만 유지하세요. 3단계부터는 거의 항상 차원이 계정의 탈을 쓰고 있는 경우이기 때문입니다. 또한, 자식 계정이 있는 부모 계정에는 절대 거래를 직접 기입하지 마세요. 자식 계정에 기입하고 부모 계정은 합계만 보여주도록 해야 보고서에서 중복 계산되는 것을 방지할 수 있습니다.
매출원가와 운영 비용의 분리
제품을 판매하거나 청구 가능한 서비스를 제공하는 비즈니스에서 다른 어떤 것보다 중요한 구조적 결정이 있습니다. 매출원가는 운영 비용과 분리된 별도의 블록이어야 합니다.
매출원가(COGS)는 판매하는 제품이나 서비스를 인도하는 데 직접적으로 연관된 비용입니다. 재료비, 제품을 만드는 인건비, 결제 수수료, 프로젝트에 투입된 외주비 등이 이에 해당합니다. 운영 비용(판관비)은 단순히 사업을 유지하기 위해 발생하는 비용으로, 임대료, 회계 소프트웨어 구독료, 관리 직원의 급여 등이 포함됩니다.
이 둘을 분리해야만 소규모 비즈니스 손익계산서에서 가장 중요한 숫자인 매출총이익(매출에서 매출원가를 뺀 금액)을 산출할 수 있습니다. 매출총이익은 간접비를 제외하고 비즈니스의 핵심 모델이 수익성이 있는지를 알려줍니다. 매출원가가 임대료와 함께 6000번대 계정에 흩어져 있다면 매출총이익을 파악할 수 없으며, 보고서에서 가장 실행 가능한 지표를 잃게 됩니다. 매출원가는 5000번대에, 운영 비용은 6000번대에 유지하면 보고서가 이 계산을 자동으로 수행해 줍니다.
첫날부터 장부를 깨끗하게 유지하세요
계정과목표는 거래가 흐르기 시작하기 전에 구축될 때 가장 가치 있으며, 나중에 수정하려면 매우 고통스럽습니다. 운영 중인 계정과목표를 재구조화하는 것은 과거 데이터를 다시 매핑해야 함을 의미하며, 늦게 시작할수록 다시 매핑해야 할 과거 데이터는 많아집니다.
이 지점에서 텍스트 기반 회계는 실질적인 이점을 제공합니다. Beancount.io는 전체 원장을 읽을 수 있고 버전 관리가 가능한 텍스트로 저장하므로, 계정과목표 재구조화는 블랙박스 마이그레이션이 아닌 투명하고 검토 가능한 변경 작업이 됩니다. 또한 계층 구조와 메타데이터를 통해 '구조를 위한 계정, 상세 정보를 위한 차원'의 분리를 설계 단계부터 지원합니다. 시각적 대시보드인 Fava에서 수치를 탐색하면서도, 무엇이 왜 변경되었는지 정확히 확인할 수 있는 능력을 유지할 수 있습니다. 지금 무료로 시작하여 질문을 숨기는 대신 답을 주는 계정과목표를 구축해 보세요.
빠른 체크리스트
계정 과목표(Chart of Accounts)를 완성하기 전에 다음 항목들을 점검해 보세요:
- 계정은 그룹별로 번호가 매겨져 있으며, 향후 확장을 위해 번호 사이에 여유를 두었습니다.
- 매출원가(COGS)는 영업 비용과 분리되어 별도의 번호 대역을 가집니다.
- 전체 계정 수는 비즈니스 규모에 비례합니다. 수백 개가 아니라 수십 개 수준이어야 합니다.
- 모든 계정은 의사 결정에 영향을 미칠 수 있어야 하며, '혹시 몰라서' 존재하는 계정은 없어야 합니다.
- 부서, 프로젝트, 위치 등은 중복된 계정이 아닌 차원(Dimensions)으로 관리됩니다.
- 하위 계정은 최대 2단계까지만 구성하며, 상위 계정에는 직접 거래를 기록하지 않습니다.
- 최소 1년에 한 번 전체 계정 과목표를 검토하고 사용하지 않는 계정은 정리합니다.
이 원칙들을 잘 지키면 손익계산서는 단순한 숫자 나열이 아닌 본연의 목적을 달성하게 됩니다. 즉, 무엇이 잘되고 있고 무엇이 문제인지, 그리고 다음으로 어디를 살펴봐야 할지 알려주는 짧고 정직한 보고서가 됩니다.