플레인 텍스트 회계가 증명한 불변 원장의 아키텍처 가치
화려한 대시보드와 자동 계좌 연동을 내세운 수많은 금융 관리 서비스가 존재합니다. 오픈뱅킹 API나 스크래핑을 통해 거래 내역을 자동으로 긁어오고, 인공지능이 카테고리를 분류해 준다는 기능들은 겉보기에 무척 매력적입니다. 하지만 실무에서 대규모 정산 시스템이나 트랜잭션 파이프라인을 다뤄본 엔지니어라면 누구나 한 번쯤 의문을 품게 됩니다. 연결이 일방적으로 끊기는 금융사 인터페이스, 서비스 제공업체의 데이터베이스 내부에서 어떤 일이 일어나는지 알 수 없는 폐쇄성, 그리고 내 자산 데이터가 서드파티 서비스의 벤더 락인(Vendor Lock-in)에 갇히는 구조는 시스템 설계 관점에서 결코 건강하지 않습니다.
최근 엔지니어링 커뮤니티를 중심으로 데이터 소유권을 되찾으려는 움직임이 뚜렷해지고 있습니다. GeekNews에 소개된 글에 따르면, 계좌 연결이 불안정한 금융 서비스 대신 hledger 기반의 복식부기로 거래를 직접 관리하고 순자산과 지출, 저축률 보고서를 생성하는 '일반 텍스트 회계(Plain Text Accounting)' 방식이 주목받고 있습니다. 회계 원장을 바이너리 파일이나 원격 RDBMS가 아닌 사람이 읽을 수 있는 평문 텍스트 파일로 저장하고, 이를 깃(Git)과 로컬 도구로 다루는 접근법입니다.
이것은 단순히 개인의 가계부 관리 방식을 바꾼 소소한 취미 생활에 그치지 않습니다. 소프트웨어 아키텍트의 시각에서 일반 텍스트 회계는 우리가 엔터프라이즈 백엔드를 설계할 때 수없이 고민하는 불변성, 결정론적 감사 가능성, 그리고 최근 부상한 LLM 에이전트 인터페이스 최적화라는 화두와 정확히 맞닿아 있습니다.
텍스트와 복식부기 엔진이 만드는 결정론적 신뢰성
일반 텍스트 회계의 핵심은 수백 년 동안 검증된 복식부기(Double-entry Bookkeeping) 원리를 가장 단순한 데이터 포맷인 텍스트와 결합했다는 점에 있습니다. 복식부기에서는 모든 거래가 차변(Debit)과 대변(Credit)으로 나뉘며, 자산의 증가는 반드시 다른 자산의 감소나 부채의 증가, 혹은 수익의 발생과 정확히 일치해야 합니다. 즉, 하나의 트랜잭션 안에서 들어온 돈과 나간 돈의 총합은 언제나 정확히 0이 되어야 합니다.
hledger나 Ledger, Beancount 같은 도구들은 이 단순한 규칙을 엄격한 파서와 검증 엔진으로 강제합니다. 텍스트 파일에 기록된 수천, 수만 줄의 거래 내역을 읽어 들이면서 각 트랜잭션의 대차 균형이 맞지 않으면 즉시 파싱 에러를 뱉어내고 실행을 멈춥니다. 데이터베이스의 체크 제약 조건(Check Constraint)을 애플리케이션 계층이 아니라 파일 파싱 단계에서 완벽하게 강제하는 구조입니다.
text
2026-08-20 * 클라우드 인프라 비용 결제
지출:서버비:AWS 150,000 KRW
자산:보통예금:신한은행 -150,000 KRW위와 같이 평문으로 작성된 트랜잭션은 특정 데이터베이스 벤더나 특정 GUI 소프트웨어에 종속되지 않습니다. 빔(Vim), 이맥스(Emacs), VS Code 등 엔지니어가 평소 사용하는 텍스트 에디터에서 곧바로 수정할 수 있으며, 정규표현식이나 유닉스 파이프라인 도구(awk, sed, grep)를 활용해 대량의 데이터를 손쉽게 가공할 수 있습니다.
무엇보다 데이터가 텍스트라는 사실은 버전 관리 시스템과의 결합을 가능하게 만듭니다. Git을 통해 원장의 모든 변경 이력을 커밋 단위로 추적할 수 있습니다. 누가, 언제, 어떤 이유로 거래 내역을 수정했는지 git blame과 git diff를 통해 투명하게 드러납니다. 엔터프라이즈 감사 로그(Audit Log)를 별도로 구축하기 위해 복잡한 CDC(Change Data Capture) 파이프라인이나 이벤트 브로커를 붙이지 않아도, 파일 시스템과 Git만으로 완벽한 시계열 감사 추적이 완성되는 셈입니다.
LLM 에이전트와 결합하는 감사 가능한 파이프라인
일반 텍스트 회계가 2026년 현재 다시금 강력한 무기로 떠오른 배경에는 코딩 에이전트의 발전이 있습니다. GeekNews 자료에서도 언급되었듯, 텍스트로 보관된 회계 데이터는 Claude Code 같은 CLI 기반 AI 에이전트나 자체 스크립트 도구와 매끄럽게 연결됩니다.
기존의 모바일 금융 앱이나 웹 SaaS는 에이전트가 개입하기에 장벽이 높습니다. 브라우저 자동화를 쓰거나 비공식 API를 리버스 엔지니어링해야 하며, 응답 데이터 구조가 조금만 바뀌어도 파이프라인이 깨집니다. 반면 텍스트 원장은 LLM이 가장 잘 이해하는 순수 문자열 형태입니다. 은행이나 카드사에서 내려받은 CSV 파일을 에이전트에게 전달하고 "hledger 포맷 규칙에 맞춰 계정과목을 매핑하고 트랜잭션을 추가하라"고 지시하면, 에이전트는 복잡한 GUI 조작 없이 즉각적으로 원장 파일을 갱신합니다.
여기서 가장 중요한 아키텍처적 장점은 '검증의 자동화'입니다. LLM은 수치 연산에서 환각을 일으킬 위험이 항상 존재합니다. 하지만 일반 텍스트 회계 환경에서는 LLM이 생성한 결과물이 유효한지 사람이 일일이 계산기를 두드려볼 필요가 없습니다. hledger CLI를 실행하여 대차 균형 검사 명령어(hledger check)를 돌리는 순간, 에이전트가 금액을 잘못 적었거나 차변·대변의 합을 맞추지 못했을 때 즉각적인 실패 신호가 반환됩니다.
CI/CD 파이프라인에 깃허브 액션(GitHub Actions)을 걸어두고, 원장에 커밋이 발생할 때마다 린트와 밸런스 체크를 수행하도록 구성하는 것도 매우 자연스럽습니다. 데이터의 입력은 AI 에이전트가 빠르게 처리하되, 시스템의 무결성은 결정론적 규칙을 지닌 컴파일러형 도구가 검증하는 이상적인 협업 모델이 만들어지는 것입니다.
이벤트 소싱과 원장 모델을 백엔드 설계에 투영하기
백엔드 엔지니어 관점에서 일반 텍스트 회계의 구조는 이벤트 소싱(Event Sourcing) 패턴의 본질과 완벽히 일치합니다. 많은 초급 개발자들이 결제나 잔액 시스템을 설계할 때 저지르는 실수가 있습니다. 데이터베이스의 users 테이블에 balance 컬럼을 두고, 결제가 일어날 때마다 UPDATE users SET balance = balance - 1000 쿼리를 날리는 방식입니다.
이러한 상태 중심(State-oriented) 설계는 동시성 이슈가 발생하는 순간 치명적인 데이터 왜곡을 낳습니다. 레이스 컨디션으로 인해 돈이 두 번 빠져나가거나, 과거의 어떤 트랜잭션 때문에 현재 잔액이 이 숫자가 되었는지 역추적하는 것이 불가능해집니다.
반면 복식부기 기반의 원장 모델은 상태를 직접 수정하지 않습니다. 오직 '거래'라는 불변의 이벤트(Event)만을 순차적으로 쌓아 올립니다. 현재의 자산 잔액이나 손익 상태는 별도로 저장된 정적 값이 아니라, 태초부터 지금까지 발생한 모든 트랜잭션 로그를 순서대로 합산(Fold/Reduce)하여 도출되는 투영(Projection)의 결과물입니다.
text
[ 트랜잭션 로그 (불변 텍스트 원장) ]
2026-08-01: +1,000,000 (급여)
2026-08-10: - 200,000 (식비)
2026-08-20: - 150,000 (서버비)
│
▼
[ hledger / 파싱 쿼리 엔진 ]
│
┌────────────────────────┴────────────────────────┐
▼ ▼
[ 대차대조표 Projection ] [ 손익계산서 Projection ]
- 보통예금: 650,000 - 식비: 200,000
- 서버비: 150,000이벤트 소싱 아키텍처를 적용할 때 복식부기 원리를 차용하면 시스템의 견고함은 비약적으로 상승합니다. 단식부기로 이벤트만 쌓는 시스템은 이벤트 누락이나 중복 발생 시 이를 감지하기 어렵습니다. 하지만 모든 이벤트를 복식부기의 차변과 대변 쌍으로 강제하면, 전체 시스템의 계정별 합계가 0으로 수렴하는지 주기적으로 확인하는 것만으로 데이터 정합성 깨짐을 실시간 감지할 수 있습니다. 핀테크 코어 뱅킹 시스템이나 정산 플랫폼이 관계형 데이터베이스의 단순 CRUD 대신 불변 원장(Ledger) 아키텍처를 고집하는 이유가 여기에 있습니다.
현실적 트레이드오프와 도입을 피해야 하는 영역
모든 아키텍처 선택에는 비용이 따르며, 일반 텍스트 회계 역시 만능 해결책은 아닙니다. 장점이 명확한 만큼 실무에 도입하거나 개인 워크플로우에 적용할 때 감수해야 할 트레이드오프도 뚜렷합니다.
가장 먼저 맞닥뜨리는 장벽은 높은 학습 곡선과 사용 편의성의 부재입니다. 회계의 기본 원리인 복식부기를 이해하지 못하면 단 한 줄의 트랜잭션도 제대로 작성할 수 없습니다. 직관적인 GUI에 익숙한 비개발자나 일반 사용자와 협업해야 하는 환경이라면 텍스트 기반 시스템은 극심한 마찰을 유발합니다. 아무리 에이전트가 입력을 돕는다 해도 문법 오류를 해석하고 교정하는 책임은 결국 사람에게 남기 때문입니다.
동시성 제어의 한계도 분명합니다. 평문 파일과 Git 기반 구조는 단일 사용자 혹은 소규모 팀의 비동기적 협업에는 탁월하지만, 초당 수천 건의 트랜잭션이 동시다발적으로 발생하는 고성능 온라인 트랜잭션 처리(OLTP) 환경에는 적합하지 않습니다. 파일 락(File Lock)과 Git 충돌(Conflict) 해결 방식은 실시간 트래픽을 감당할 수 없습니다.
따라서 이러한 텍스트 원장 시스템은 다음과 같은 명확한 기준을 가지고 접근해야 합니다.
초고빈도 트랜잭션의 실시간 처리가 필요한 서비스의 메인 저장소로는 부적합합니다. 대신 데이터의 신뢰성과 투명한 감사가 최우선인 개인 자산 관리, 소규모 스타트업의 재무 운영, 그리고 결제 시스템의 백오피스 정산 및 대사(Reconciliation) 검증 파이프라인에는 최상의 효율을 제공합니다.
온라인 서비스에서는 고성능 분산 데이터베이스로 이벤트를 기록하더라도, 주기적인 일마감 정산이나 감사 데이터를 생성하는 배치 파이프라인에 복식부기 원장 모델을 적용하면 시스템의 데이터 무결성을 획기적으로 끌어올릴 수 있습니다.
데이터를 블랙박스 SaaS에 맡기고 불안해하는 대신, 기술의 원리를 투명하게 드러내는 텍스트와 표준 도구를 활용해 완벽한 통제권을 확보하는 경험은 엔지니어에게 매우 값진 통찰을 줍니다. 내일 당장 터미널을 열고 hledger를 설치해 지난달의 카드 지출 내역 CSV를 단 열 줄짜리 텍스트 원장으로 변환해 보시길 권합니다. 데이터의 불변성과 결정론적 검증이 주는 견고함을 직접 체감하는 순간, 백엔드 아키텍처를 바라보는 시야가 한 단계 넓어질 것입니다.
이 글과 함께 읽으면 좋은 인사이트
댓글 0