장부를 열어 비즈니스에서 가장 단순한 질문에 답하려 합니다 — 그 프로젝트가 실제로 돈을 벌었을까? — 그런데 300줄짜리 계정과목표가 눈에 들어옵니다. "여비", "여비 - 고객 A", "여비 시드니 런칭 (구)", 그리고 어느새 가장 큰 항목 중 하나가 되어버린 "기타 비용 2"가 있습니다. 답은 어딘가에 있습니다. 사흘 밤낮의 스프레드시트 수술과 아무도 믿지 않는 각주 아래에 묻혀 있을 뿐입니다.
데이터가 더러운 게 아닙니다. 설계가 잘못된 것입니다. 비즈니스의 새로운 단면이 필요할 때마다 — 프로젝트, 고객, 지점 — 그에 맞는 새 계정을 만들었고, 계정 목록은 미로처럼 자라났습니다. 더 나은 설계가 있고, 그것은 지금보다 단순합니다: 계정과목표는 간결하게 유지하고, 프로젝트, 고객, 코스트 센터는 각 거래에 태그를 달아 추적하는 것입니다.
이 가이드는 장부를 분석 가능하게 유지하는 하나의 규칙, 일반적인 회계 도구 전반에서 태깅이 실제로 어떻게 작동하는지, 그리고 흐름을 놓치지 않고 공유 비용을 프로젝트에 배분하는 방법을 설명합니다.
계정과목표가 계속 폭발하는 이유
계정 목록 비대화는 예측 가능한 패턴을 따릅니다. 순진하게 시작됩니다: 큰 고객을 확보하고 그들이 얼마를 가져오는지 보려고 "컨설팅 수익 - 고객 A"를 만듭니다. 그다음 비용을 맞추려고 "여비 - 고객 A"를 만듭니다. 그다음 두 번째 고객, 보조금, 박람회, 사무실 이전 — 각각이 자기 계정을 갖습니다. 5년 후에는 거래가 세 건씩밖에 없는 계정이 수백 개 있고, "2023B 이벤트 비용"이 무엇이었는지 아무도 기억하지 못합니다.
설계가 실패했다는 다음 경고 신호를 주의하세요:
- 계정 이름에 숨어 있는 차원. "여비, 시드니, 프로젝트 팰컨"은 하나의 레이블에 세 가지 사실이 구겨 넣어진 것입니다. 문자열 파싱과 기도 없이는 프로젝트 전체의 여비를 합산하거나, 비용 유형 전체의 프로젝트 팰컨을 합산할 수 없습니다. 지점, 프로젝트, 부서는 차원이며, 계정 이름에 속하지 않습니다.
- 일회성 이벤트를 위한 일회성 계정. 박람회마다, 보조금마다, 사무실 이전마다 새 계정. 카디널리티가 폭발하고, 보고서가 난잡해지며, 비교 가능성이 죽습니다.
- 쓰레기장이 되어버린 "기타" 계정. 모든 장부에는 기타 계정이 있습니다. 그것이 비즈니스에서 가장 큰 항목 중 하나가 되면, 더 이상 카테고리가 아닙니다 — 분석이 죽으러 가는 곳입니다.
- 조용히 의미가 바뀌는 계정. 작년까지만 광고비만 담던 "마케팅" 계정이 대행사 수수료와 이벤트를 흡수하면, 아름답지만 아무 의미 없는 추세선을 만들어냅니다. 시계열은 정의가 고정되어 있을 때만 작동합니다.
경험 많은 스타트업 CPA는 초기 단계 회사를 위해 대략 80~150개의 계정을 목표로 합니다. 그 깔끔한 목록과 제때 마감할 수 없는 400줄짜리 계정과목표의 차이는 거의 항상 같습니다: 비대해진 쪽은 프로젝트, 고객, 부서를 태그가 아니라 계정으로 인코딩합니다.
하나의 규칙: 계정은 "무엇"에 답하고, 태그는 "누가"와 "어디서"에 답한다
이 단일 규칙이 대부분의 손상을 고칩니다: 계정은 어떤 종류의 돈이 움직였는지에 답합니다 — 임차료, 급여, 제품 판매. 나머지 전부 — 어느 지점, 어느 제품 라인, 어느 프로젝트, 어느 고객 — 는 각 거래 전표에 별도의 태그로 속합니다.
프로젝트 차원으로 태그된 하나의 "여비" 계정이 수십 개의 "여비, 프로젝트 X" 계정을 대체하며, 갑자기 모든 프로젝트를 모든 비용 유형에 걸쳐 분석할 수 있게 됩니다. 태그는 계정 트리의 가지가 아니라 거래에 붙는 메타데이터입니다. 계정 목록이 안정적으로 유지되므로 추세선은 해마다 의미를 지키고, 태그는 필요한 모든 교차 분석 뷰를 제공합니다.
회계 교과서에서 이 아이디어에는 공식 명칭이 있습니다: 책임 중심점(responsibility centers). 코스트 센터는 보고 단위입니다 — 부서, 지점, 프로젝트 — 그 관리자가 배정된 비용에 대해 책임을 집니다. 회계 부서, 정비팀, 고객 프로젝트 모두 코스트 센터가 될 수 있습니다. 태깅은 소규모 사업이 엔터프라이즈 ERP 없이 이 아이디어를 구현하는 방식일 뿐입니다: 각 전표의 태그가 그 비용이 어느 책임 중심점에 속하는지 말해줍니다.
효과는 보고 시점에 나타납니다. 프로젝트마다 별도의 계정 집합을 유지하는 대신, 태그로 필터링한 하나의 손익계산서를 실행하여 세금 신고서를 만드는 것과 동일한 장부에서 바로 프로젝트 손익을 얻습니다. 병행 스프레드시트도, 두 시스템 간의 조정도, 각주도 필요 없습니다.
태깅이 실제로 어떻게 보이는가
거의 모든 회계 도구에는 태깅 메커니즘이 있습니다 — 이름은 다르지만 개념은 동일합니다:
- QuickBooks Online에는 클래스가 있습니다 (상위 요금제에서는 태그와 고객 및 프로젝트 추적도). "엔지니어링" 또는 "제품 A" 같은 클래스를 각 거래 전표에 배정하고, 모든 보고서를 클래스별로 필터링합니다. 고객 및 작업 추적은 프로젝트 수준 손익을 위해 한 단계 더 깊이 들어갑니다.
- Xero에는 추적 카테고리가 있습니다 — 일반적으로 지역과 부서 같은 두 개의 활성 카테고리 — 그리고 상위 요금제에서는 프로젝트별 시간 및 비용 포착을 위한 프로젝트 추적이 있습니다.
- 평문 회계 (Beancount, Ledger)는 거래 전표에 직접 작성된 태그와 링크, 그리고 메타데이터 키-값 쌍과 개방적이고 유연한 계정 구조를 사용합니다.
#client-acme태그나project: falcon메타데이터 필드는 분개와 함께 이동하며, 하위 계정 증식 없이 어떤 조합으로든 조회할 수 있습니다. - 스프레드시트와 커스텀 시스템은 종종 같은 패턴을 추가 열로 구현합니다: 계정용 열 하나, 프로젝트용 열 하나, 고객용 열 하나. 오늘이 여기라면, 이미 모델을 이해하고 있는 것입니다 — 목표는 그것을 실제 장부로 옮기는 것입니다.
어떤 도구를 쓰든 원칙은 같습니다: 맥락이 생생할 때, 거래 입력 시점에 일관되게 태그하세요. 몇 달 후 기억으로 재구성한 태그는 추측이며, 추측으로 만든 프로젝트 손익은 권위 있어 보이기 때문에 없는 것보다 나쁩니다.
차원 설계하기: 생각보다 적게
가장 흔한 태깅 실수는 너무 많은 차원을 만드는 것입니다. 실제로 던지는 질문에 따라 최대 두세 개로 시작하세요:
- 프로젝트 또는 프로젝트 수행 건. 가격을 매기고, 납품하고, 수익성을 판단하려는 작업. 에이전시는 고객 프로젝트에, 계약자는 작업에, 소프트웨어 팀은 제품 라인이나 에픽에 태그합니다.
- 고객. 프로젝트 사업에서는 종종 프로젝트와 같지만, 한 고객이 관계로 평가하려는 반복 작업을 가져올 때는 구별됩니다. 개별적으로 수익성 있는 프로젝트 세 개를 만들어내는 고객도 지원과 재작업을 계산하면 전체적으로는 적자일 수 있습니다.
- 코스트 센터 또는 부서. 엔지니어링, 영업, 운영 — 예산을 세우고 검토하는 내부 단위. 계정 목록을 건드리지 않고 "번(burn)이 어디로 가는가?"에 답하는 차원입니다.
네 번째 차원은 누구나 유혹합니다 — 지점, 자금 출처, 캠페인 — 하지만 새 차원마다 모든 거래에 대한 태깅 부담이 배가됩니다. 결정이 진정으로 그것에 달려 있을 때만 추가하세요. 한 소매 사업은 단일 "매장" 태그와 고객 차원만으로 전체 분석을 돌리고, 한 에이전시는 프로젝트 태그만으로 돌립니다. 질문에 맞춰 도구를 맞추세요, 그 반대가 아니라.
각 차원 내에서는 태그 목록을 짧고 안정적으로 유지하세요. 끝난 프로젝트는 삭제하지 말고 보관하세요 (삭제는 역사를 다시 씁니다), 그리고 특이한 항목을 위한 일회성 태그는 피하세요 — 세 번 쓰인 태그는 일회성 계정과 같은 병을 새 위치에서 앓는 것입니다.
이중 계산 없이 공유 비용 배분하기
직접 비용은 태그하기 쉽습니다: 프로젝트 팰컨의 계약자 청구서에는 팰컨 태그가 붙습니다. 어려운 부분은 공유 비용입니다 — 임차료, 소프트웨어 구독료, 본인 급여 — 모든 프로젝트에 동시에 봉사하는 비용. 이를 무시하면 모든 프로젝트가 실제보다 좋아 보이고, 한 프로젝트에 몰아넣으면 부당하게 벌을 줍니다.
비용 유형별로 하나의 배분 방법을 선택하고 일관되게 적용하세요:
- 시간 기반 배분. 공유 인건비와 간접비를 각 프로젝트에 투입된 시간으로 나눕니다. 이번 달 청구 가능 시간의 60퍼센트를 팰컨에 썼다면, 팰컨이 공유 비용의 60퍼센트를 흡수합니다. 서비스 사업에 가장 공정한 방법이며 감사인이 가장 방어 가능하다고 보는 방법입니다.
- 수익 기반 배분. 각 프로젝트의 수익에 비례하여 공유 비용을 나눕니다. 단순하고 안정적이지만 가장 성공적인 프로젝트에 벌을 주고 어려움을 겪는 프로젝트를 숨깁니다 — 회계 수수료 같은 진정한 일반 비용에 사용하고, 노력에 의해 발생하는 비용에는 사용하지 마세요.
- 인원 또는 사용량 기반 배분. 소프트웨어 좌석은 사용자별로, 임차료는 면적별로, 차량 비용은 주행거리별로 나눕니다. 비용에 동인을 맞추세요: 실제로 자원을 소비하는 것에 배분하세요.
두 가지 규칙이 배분을 정직하게 유지합니다. 첫째, 배분된 합계는 장부와 일치해야 합니다 — 프로젝트 태그 비용과 태그 없는 공유 비용의 합이 총계정원장 합계와 같아야 하며, 그렇지 않으면 프로젝트 손익은 허구입니다. 둘째, 배분을 가시적으로 유지하세요: 배분 금액을 원래 거래를 조용히 수정하는 대신 자체 전표나 메모로 기록하여, 누구나 직접 태그된 것과 배분된 것을 볼 수 있게 하세요. 프로젝트 손익은 재현 가능해야 하며, 마술이 되어서는 안 됩니다.
모든 것을 배분하려는 유혹을 물리치세요. 의미 있는 동인이 없는 비용 — 연간 회계 수수료, 은행 수수료 — 은 합법적으로 태그 없는 간접비입니다. 직접 마진에 명확히 표시된 간접비 몫을 더한 프로젝트 손익이 그 차이를 숨긴 것보다 더 정직합니다.
전체 시스템을 무력화하는 실수
태깅은 예측 가능한 방식으로 실패합니다. 다음 다섯 가지를 경계하세요:
- 태그 없는 거래. 태그 없는 모든 전표는 프로젝트 보고에서 보이지 않습니다. 비용, 수익, 구매 거래에는 프로젝트 태그를 필수로 만드세요 — 다만 은행 수수료나 이체처럼 의미가 없을 곳에는 적용하지 마세요. "태그 없음" 보고서를 매주 검토하고 0을 향해 밀어붙이세요.
- 태그 난립. "Acme", "ACME Corp", "Acme - 신규"는 한 고객을 위한 세 개의 태그입니다. 한 사람만 값을 추가할 수 있도록 태그 목록을 잠그고, 중복이 역사에 화석화되기 전에 병합하세요.
- 모든 것에 태깅. 모든 거래에 모든 차원이 필요한 것은 아닙니다. 생각 없이 붙인 태그는 소음이 되고, 중요한 곳에 붙인 태그는 통찰이 됩니다. 실제 질문에 답하는 전표에 태그하세요.
- 소급적 재해석. 진행 중에 태그의 의미를 바꾸는 것 — 하위 프로젝트를 상위로 흡수하거나 부서 이름을 바꾸는 것 — 은 모든 추세를 망칩니다. 구조가 진정으로 바뀌면, 역사를 위해 옛 태그를 유지하고 새 태그를 깨끗하게 시작하세요.
- 두 개의 기록 시스템. 프로젝트 비용이 일부는 장부에, 일부는 별도 스프레드시트에 사는 순간, 어느 쪽도 신뢰할 수 없습니다. 태그된 원장을 단일 진실 공급원으로 선택하고 그림자 시스템을 폐기하세요.
이 중 어느 것도 정교한 소프트웨어를 필요로 하지 않습니다. 그것들은 합의를 필요로 합니다 — 자신, 부기 담당자, 그리고 장부를 만지는 모든 사람과의 합의 — 태그는 선택적 장식이 아니라 거래의 일부라는 합의를.
깔끔한 태그가 다른 모든 보고서를 더 낫게 만든다
태깅 원칙이 자리 잡으면 혜택은 프로젝트 수익성을 넘어 복리로 쌓입니다. 각 코스트 센터가 예산을 세울 자체 역사를 가지므로 예산 편성이 쉬워집니다. 공제 가능한 카테고리가 고객 이름과 엉키지 않고 깨끗하게 유지되므로 세금 준비가 빨라집니다. 대출 신청이 더 강해집니다 — 대출 기관에 비즈니스의 어느 부분이 현금을 창출하는지 정확히 보여줄 수 있기 때문입니다. 그리고 월말 마감이 짧아집니다: 일관된 태그가 있는 간결한 계정 목록은 몇 주가 아니라 몇 시간에 조정됩니다.
더 깊은 성과는 의사결정의 질입니다. 프로젝트 손익을 신뢰할 수 있으면, 다음 프로젝트의 가격을 본능이 아니라 증거로 매기고, 지원 부담이 마진을 갉아먹는 고객을 정리하고, 실제로 돈이 되는 작업에 집중을 배가할 수 있습니다. 숫자를 아는 비즈니스는 이런 움직임을 일찍 합니다; 300개 계정 미로에서 추측하는 비즈니스는 늦게, 혹은 전혀 하지 못합니다.
첫날부터 프로젝트 장부를 정리하세요
더 많은 고객과 프로젝트를 맡을수록, 계정과목표를 엉키게 하지 않고 각 프로젝트의 비용을 가시적으로 유지하는 것이 분석할 수 있는 장부와 그저 제출만 하는 장부를 가르는 기준입니다. 평문 회계는 이 모델에 자연스럽게 맞습니다: 태그, 링크, 메타데이터가 거래 전표에 바로 있으며, 버전 관리되고 어떤 조합으로든 조회할 수 있습니다. Beancount.io는 재무 데이터에 대한 완전한 투명성과 통제를 제공하는 평문 회계를 제공합니다 — 블랙박스도, 공급업체 종속도 없습니다. 무료로 시작하세요 그리고 개발자와 재무 전문가들이 평문 회계로 전환하는 이유를 확인하세요.
