이제부터 내가 회계 시스템 담당자라는데

이제부터 내가 회계 시스템 담당자라는데
오세훈.이정수 지음 / 광문각출판미디어 / 2025년 9월

*본 포스팅은 출판사로부터 도서를 제공받아 주관적으로 작성한 리뷰입니다.

회계팀과 개발팀이 회의실에 마주 앉으면 기묘한 풍경이 펼쳐진다. 회계 담당자는 "이번 분기 매출채권 회전율이 떨어져서 대손충당금 설정 로직을 수정해야 합니다"라고 말하고, 개발자는 "그러면 트랜잭션 테이블의 외래키 관계를 재설계하고 배치 프로세스를 추가해야 하나요?"라고 되묻는다. 서로 같은 문제를 이야기하는 것 같지만, 사용하는 언어 체계가 완전히 다르다. 회계는 '거래의 경제적 실질'을 기록하는 학문이고, 시스템 개발은 '데이터의 흐름과 저장'을 설계하는 기술이다. 전자는 복식부기라는 500년 역사의 원리 위에 서 있고, 후자는 관계형 데이터베이스와 객체지향 프로그래밍이라는 현대 컴퓨터 과학의 토대 위에 있다. 문제는 기업의 ERP나 회계 시스템을 구축할 때 이 두 세계가 반드시 만나야 한다는 점이다. 그리고 그 접점에서 발생하는 오해와 누락이 프로젝트 실패의 주요 원인이 된다. 이를 해결하기 위한 신간을 읽을 기회가 있었다. <이제부터 내가 회계 시스템 담당자라는데>

저자들이 제시하는 해법은 명료하다. 회계를 시스템의 언어로 번역하라는 것이다. 차변과 대변을 왼쪽과 오른쪽 칸으로만 이해하지 말고, 데이터베이스의 입력과 출력 흐름으로 재해석하라는 것이다. 이는 회계 원리를 포기하는 것이 아니라, 그것을 현대적 시스템 설계의 맥락 속에 재배치하는 작업이다. 마치 고전 문학을 현대어로 번역하되 원문의 의미를 보존하듯, 회계의 논리를 코드의 구조로 옮기는 일이다. 회계의 가장 기본적인 행위는 분개다. 모든 거래를 차변과 대변으로 나누어 기록하는 이 행위는 회계학의 출발점이자 종착점이다. 그런데 개발자의 관점에서 보면 분개는 무엇인가? 저자들은 이것을 데이터베이스 트랜잭션으로 설명한다. 하나의 경제적 사건이 발생하면 최소 두 개 이상의 계정에 동시에 기록이 이루어지며, 이 기록들의 합은 언제나 0이 되어야 한다. 이는 ACID 원칙의 원자성(Atomicity)과 일관성(Consistency)을 자연스럽게 구현하는 구조다. 책은 바로 회계의 '균형 원칙'과 시스템의 '데이터 무결성'이 같은 개념임을 보여준다. 차변 합계와 대변 합계가 일치해야 한다는 회계 원리는, 시스템 설계에서 트랜잭션 처리 로직이 보장해야 할 제약조건이다. 저자들은 이를 이론적으로만 설명하는 데 그치지 않고, 실제 전표 입력 화면에서 검증 로직이 어떻게 작동해야 하는지, 오류 발생 시 롤백 처리는 어떻게 구현해야 하는지까지 구체적으로 다룬다. 회계와 시스템이 만나는 첫 번째 접점이 바로 여기, 분개와 트랜잭션의 동형성(isomorphism) 속에 있다.

회계 시스템의 핵심 중 하나는 계정과목 체계다. 현금, 매출채권, 재고자산, 자본금, 매출, 급여 같은 수백 개의 계정과목이 계층 구조를 이루며 조직된다. 회계 담당자에게 이것은 재무제표를 작성하기 위한 분류 체계지만, 개발자에게는 무엇인가? 저자들은 이를 마스터 데이터로 설명한다. 즉, 시스템 전반에서 공통적으로 참조되며, 한번 정의되면 여러 트랜잭션에서 반복적으로 사용되는 기준 데이터라는 것이다. 그런데 계정과목은 코드 목록만을 의미하는 것이 아니다. 각 계정은 그 성격에 따라 자산인지 부채인지 수익인지 비용인지가 정해져 있고, 차변 증가 계정인지 대변 증가 계정인지가 구분된다. 또한 현금흐름표 작성을 위해 영업활동, 투자활동, 재무활동 중 어디에 속하는지도 표시되어야 한다. 세무 신고를 위해 법인세법상 계정 코드와의 매핑 관계도 필요하다. 즉, 계정과목 마스터 테이블은 단순한 이름과 코드 쌍이 아니라, 다양한 속성 정보를 담고 있는 복합적 구조물이다. 저자들은 이 계정과목 체계를 설계할 때 고려해야 할 요소들을 체계적으로 정리한다. 계정과목의 계층 구조를 어떻게 테이블로 표현할 것인가? 자기참조 외래키를 사용할 것인가, 아니면 경로 정보를 문자열로 저장할 것인가? 사용자 정의 계정과목을 허용할 것인가, 아니면 표준 계정과목만 사용하도록 제한할 것인가? 조직별로 다른 계정과목 체계를 사용할 경우 이를 어떻게 통합 관리할 것인가? 이런 질문들은 단순히 기술적 선택의 문제가 아니라, 회계 업무의 실제 운영 방식을 이해해야만 답할 수 있는 문제들이다.

회계에서 결산이란 일정 기간의 거래를 마감하고 재무제표를 작성하는 절차다. 월말, 분기말, 연말마다 수행되며, 이 과정에서 감가상각비 계산, 미지급비용 계상, 재고자산 평가, 대손충당금 설정 같은 다양한 조정 작업이 이루어진다. 개발자에게 이것은 무엇인가? 저자들은 결산을 대규모 배치 프로세스로 설명한다. 즉, 실시간으로 처리할 수 없는 복잡한 계산들을 특정 시점에 모아서 일괄 처리하는 작업이다. 결산 프로세스는 여러 단계로 구성된다. 먼저 일상적으로 입력된 거래 전표들이 모두 승인되고 확정되었는지 검증한다. 그 다음 자동 분개 항목들을 생성한다. 예를 들어 고정자산의 감가상각은 매달 자동으로 계산되어 비용으로 기록되어야 한다. 외화 자산과 부채는 결산일 환율로 재평가되어 환산손익이 계상되어야 한다. 이런 작업들은 모두 사전에 정의된 규칙에 따라 자동으로 전표를 생성하는 로직이다. 저자들은 이를 구현할 때 필요한 데이터 구조와 알고리즘을 구체적으로 제시한다. 그 다음 단계는 집계와 전기(posting)다. 개별 거래 전표들이 각 계정과목별로 합산되어 총계정원장에 기록된다. 이는 SQL의 GROUP BY와 SUM 연산으로 구현할 수 있지만, 대량의 데이터를 처리할 때 성능 문제가 발생할 수 있다. 저자들은 이를 위해 중간 집계 테이블을 사용하거나, 인덱스를 최적화하는 방법을 제안한다. 마지막으로 재무제표가 생성된다. 재무상태표, 손익계산서, 현금흐름표 같은 보고서는 집계된 계정과목 잔액을 특정 양식에 맞춰 재배치한 것이다. 이 과정에서 계정과목 마스터에 정의된 속성 정보가 활용된다. 결산 프로세스를 배치 작업으로 설계할 때 가장 중요한 것은 멱등성(idempotency)이다. 같은 결산 작업을 여러 번 실행해도 결과가 동일해야 한다. 이는 결산 과정에서 오류가 발생했을 때 재실행할 수 있도록 보장하기 위해서다. 저자들은 이를 위해 결산 상태를 관리하는 테이블을 두고, 각 단계별로 완료 여부를 기록하는 방식을 제안한다. 이런 설계는 단순히 기술적 안정성만을 위한 것이 아니라, 회계 업무의 특성상 반드시 필요한 요구사항이다.회계 시스템에서 내부통제란 오류와 부정을 방지하기 위한 절차와 장치를 의미한다. 예를 들어 전표 입력자와 승인자를 분리하거나, 일정 금액 이상의 지출은 이중 승인을 받도록 하거나, 결산이 확정된 이후에는 과거 데이터를 수정할 수 없도록 잠그는 것 등이다. 개발자에게 이것은 무엇인가? 저자들은 내부통제를 시스템의 권한 관리와 워크플로우 설계로 설명한다. 권한 관리는 로그인 사용자를 확인하는 것 이상이다. 각 사용자가 어떤 기능에 접근할 수 있고, 어떤 데이터를 조회하거나 수정할 수 있는지를 세밀하게 제어해야 한다. 워크플로우 설계는 업무 절차를 시스템화하는 것이다. 전표가 입력되면 '임시저장' 상태가 되고, 담당자가 검토한 후 '승인요청' 상태로 변경되며, 승인권자가 최종 승인하면 '확정' 상태가 되어 장부에 반영된다. 이 과정에서 각 상태 전환은 특정 조건과 권한을 만족해야만 가능하다. 또한 상태별로 허용되는 작업이 달라진다. 임시저장 상태에서는 수정과 삭제가 가능하지만, 확정 상태에서는 어떤 변경도 불가능하다. 저자들은 이런 상태 기계(state machine) 패턴을 회계 시스템에 적용하는 방법을 상세히 다룬다. 내부통제의 또 다른 측면은 감사 추적(audit trail)이다. 모든 중요한 작업에 대해 누가, 언제, 무엇을, 왜 했는지를 기록해야 한다. 데이터가 변경되었다면 변경 전후의 값을 모두 보관해야 한다. 이는 단순히 로그를 남기는 것 이상으로, 별도의 이력 테이블을 설계하고 트리거나 애플리케이션 로직을 통해 자동으로 기록하는 구조가 필요하다. 저자들은 이런 감사 기능을 구현할 때 성능 저하를 최소화하면서도 완전성을 보장하는 방법을 제시한다. 회계 시스템의 신뢰성은 바로 이런 내부통제 장치들의 견고함에서 나온다.

이론과 실무 사이에는 언제나 간극이 있다. 회계 원리를 배울 때는 거래 예시로 설명되지만, 실제 기업의 회계 시스템은 훨씬 복잡하다. 하나의 매출 거래도 고객 관리, 재고 관리, 세금 계산, 채권 관리 같은 여러 하위 시스템과 연동되어야 한다. 저자들이 강조하는 것은 바로 이런 실무적 복잡성을 어떻게 체계적으로 다룰 것인가다. 저자들은 이런 통합 시나리오를 여러 사례로 제시한다. 구매-재고-원가 연동, 급여-인사 연동, 고정자산-감가상각 연동, 예산-집행-정산 연동 등이다. 각 사례마다 관련된 업무 프로세스를 먼저 설명하고, 그것이 시스템에서 어떤 데이터 구조와 처리 로직으로 구현되는지를 보여준다. 특히 인터페이스 설계가 중요한데, 각 하위 시스템이 독립적으로 운영되면서도 필요한 정보를 적시에 주고받을 수 있어야 한다. 메시지 큐를 사용할 것인가, API 호출을 사용할 것인가, 아니면 데이터베이스를 직접 공유할 것인가 같은 선택이 시스템의 유연성과 안정성을 좌우한다. 또한 예외 상황 처리도 중요하다. 정상적인 흐름은 대부분의 개발자가 구현할 수 있지만, 매출 취소, 반품 처리, 오류 수정, 회계 기간 변경 같은 예외 상황에서 시스템이 어떻게 반응해야 하는지가 진짜 실력을 결정한다. 저자들은 이런 예외 케이스들을 빠짐없이 다루며, 각 상황에서 어떤 회계 처리가 필요하고 시스템적으로 어떻게 구현해야 하는지를 설명한다. 바로 이런 디테일이 책을 단순한 입문서가 아닌 실무 지침서로 만드는 요소다. 책은 회계라는 오래된 학문과 시스템 개발이라는 현대 기술 사이의 통역자가 되는 법을 보여준다. 개발자는 이 책을 통해 회계의 논리를 코드로 변환하는 능력을 얻게 되고, 회계 담당자는 자신들의 업무가 시스템에서 어떻게 구현되는지를 이해하게 될 것이다. 결국 좋은 회계 시스템은 두 언어를 모두 유창하게 구사하는 사람들이 만든다. 이 책은 그 유창함으로 가는 첫 걸음일 것이다.

태그