매출 0원과 수집 실패를 구분하기

한 매장의 5월 말 홀 매출이 비어 있었고 배달 플랫폼 매출은 0원으로 나왔다. 그날 매출이 정말 0원이었던 게 아니었다. 최근 날짜 데이터를 불러오지 못한 거였다.

매장 운영자가 판매와 손익을 한 화면에서 보는 서비스를 개발하고 있었다. POS 매출, 배달 플랫폼 매출과 정산, 홈택스 매입, 법인카드, 세무사가 위하고에 입력한 전표를 모아서 리포트를 만든다.

자료를 한곳에 모았다고 숫자가 곧바로 맞지는 않았다. 집계 기준과 반영 시점이 달라 같은 달 매출도 화면마다 다르게 나왔다. 차이가 생길 때마다 원천 거래까지 거슬러 올라가 확인해야 했다.

0원과 실패를 구분해야 했다

문제를 확인해 보니 로그에는 오류가 찍혀 있었다. 그런데 화면에는 0원만 보였다. 매장 운영자는 데이터를 불러오는 데 실패했다는 사실을 알 수 없었다.

진짜 0원 매출과 수집 실패를 화면에서 구분할 수 없다는 지적을 받고 실패는 에러로 보여 주기로 했다. 이후 수집 실패 유형과 상태를 보여 주는 화면이 들어갔고 배달 플랫폼 실시간 수집에서 잘못된 0원이 들어가지 않게 막는 처리도 들어갔다.

이때 손익 화면 위쪽의 상태 표시도 세 가지로 나눴다.

• 최신성: 이 숫자가 어느 원천을 언제까지 불러온 값인지
• 분개 상태: 선택한 달의 세무사 전표가 손익계산서에 반영할 수 있는 상태인지
• 수집 실패 상태: 숫자가 0이거나 비었을 때 진짜 0인지, 계정·수집기·API 실패인지

원래 있던 ‘마감 전’ 표시는 위하고 데이터를 월말 전에 마지막으로 불러왔다는 뜻이었는데, 세무사의 분개 완료 여부와 헷갈렸다. 그래서 분개 완료 상태를 따로 만들었다.

회계 손익과 배달 손익을 나눴다

손익 분석은 월별 손익계산서를 중심으로 구조를 잡았다. 판매 분석은 운영 매출을 보는 화면이고, 손익 분석은 신고·정산 기준에 맞춰야 한다. 그래서 두 화면이 쓰는 매출 원천부터 갈랐다. 같은 ‘매출’인데 두 화면 숫자가 다른 건 의도한 결과다.

배달 이익을 어디에 둘지도 논의했다. 회계 손익에 포함하는 방법과 탭을 나누는 방법을 놓고 검토했고, 별도 탭으로 분리하기로 했다. 위하고에서 읽어 오는 숫자는 세무사가 분개한 계정과목 그대로다. 배달 이익은 수수료·프로모션·배달비를 점주 입장에서 다시 묶은 숫자라서 둘을 섞으면 회계 계정과 배달 채널 이익이 한 화면에 엉킨다.

같은 회의에서 화면 이름도 바꿨다. ‘손익 요약’은 ‘회계 손익’, ‘매출 확인’과 ‘비용 확인’은 ‘매출 상세’와 ‘비용 상세’가 됐다. 계정과목 숫자를 누르면 원천 거래 내역으로 내려가는 흐름도 이때 정했다.

정산일이 아니라 주문일로

배달 손익은 처음에 배달의민족 정산 내역으로 일별·주별 값을 계산했다. 그런데 정산 내역은 정산일 기준으로 묶여 있어서 토요일·일요일 주문이 다른 요일에 몰리고 광고 관련 조정이 월초에 크게 잡혔다. 하루 단위로 보면 주말 장사가 없는 것처럼 보였다. 쿠팡이츠는 주문일 기준 자료를 준다는 차이도 있었다.

집계 기준을 정할 때는 일·주·월을 전부 정산일 기준으로 맞추는 안, 일·주는 주문일 기준 추정치로 보고 월은 정산 기준 확정치로 보는 안, 월별 값만 보여 주는 안이 나왔다. 일·주는 추정치, 월은 확정치를 보여 주는 방식으로 정했다. 일별과 주별에는 ‘추정’, 월별에는 ‘확정’ 라벨을 붙였다. 매출 기준도 ‘주문 금액’에서 ‘결제 금액’으로 바꿨다. 주문 금액은 할인 전 정가 합계일 수 있어서 손익률이 틀어질 수 있었다. 논의한 기준에 맞춰 주문 내역으로 추정치를 계산하도록 구현했다.

미확정 전표가 22건에서 25건으로

데이터를 새로 불러오자 미확정 전표가 22건에서 25건으로 늘었다. 4월은 이미 마감됐을 텐데 왜 늘었느냐는 질문이 나왔다. 확인해 보니 미확정 건수를 선택한 달과 상관없이 전체 기간으로 세고 있었다. 4월에는 미확정 전표가 없었고, 늘어난 건 5월 이후 전표였다. 선택한 달 기준으로 ‘확정 n건 / 미확정 n건’을 보여 주고 그 달 미확정 전표를 열어 볼 수 있게 바꿨다.

다음 날에는 한 달 확정 전표가 1,000건이 넘게 나온다는 질문이 나왔다. 카드 매출 입금은 카드사마다, 거의 매일 따로 전표가 생겨서 건수가 크게 부풀어 보인다고 설명했다. 그 뒤로 확정과 미확정 건수를 항상 같이 보여 주기로 했다.

이후에는 중복 집계 문제도 나왔다. 세무사는 5월 미확정 전표 22건을 이미 처리했다고 했는데, 그 금액이 손익에 벌써 들어가 있었다. 확정 전표와 미확정 전표를 따로 불러오다 보니, 확정된 뒤에도 미확정 목록에서 빠지지 않은 내역이 두 번 잡히고 있었다. 확정 목록에 있는 전표는 미확정 목록에 중복으로 남지 않도록 고쳤다.

코드로 고치지 않은 것들

모든 불일치가 코드 문제는 아니었다. 5월 매출이 낮게 나와서 따라가 보니, 홀 POS와 키오스크 카드 매출은 들어와 있었고 배달 플랫폼 매출, 현금 수령, 개인 매출이 세무사 장부에 아직 기록되지 않은 상태였다. 이건 세무사·위하고 쪽 확인으로 넘겼다.

월중에 당월 매출이 안 보이는 경우도 있었다. 세무사가 매출을 월말에 한꺼번에 입력해서였다. 이 경우에는 담당자가 세무사와 결산 일정을 맞추도록 정리했다.

판관비를 고정비와 변동비로 나눠 보자는 요구도 있었는데, 당시 원천 자료로는 나눌 수 없어 제외했다.

모바일에서 차트가 기간을 바꿔 버렸다

배달 손익 위쪽 요약이 어떤 날을 골라도 한 날짜에 멈춰 있었다. 데이터는 잘 불러오는데 위쪽 달력과 아래쪽 차트 연동이 불안정했다.

모바일에서는 페이지를 위아래로 스크롤하다가 차트가 같이 눌리면서 선택 기간이 2025년 7월 같은 엉뚱한 구간으로 넘어갔다. 드래그를 아예 없애거나 그대로 두는 방법도 있었지만 차트를 한 번 탭해서 활성화한 뒤에만 움직이게 하기로 했다. 그래프를 한 번 누르면 활성 상태가 표시되고, 그때부터 조작할 수 있도록 바꿨다.

내가 맡은 부분

서비스 기획과 화면 구성은 기획 담당자와 협의하고, 기술 판단과 구현은 내가 맡았다. 매장과 세무사의 의견도 담당자를 통해 함께 확인했다. 숫자가 맞지 않을 때는 거래 단위까지 따라가서 수집 문제인지, 집계 방식의 차이인지, 아직 입력되지 않은 자료인지 구분했다.

화면에 숫자를 보여 주는 것만으로는 부족했다. 어느 시점의 자료이고 어떤 기준으로 계산했는지, 비어 있다면 왜 비어 있는지까지 보여 줘야 매장에서 판단에 쓸 수 있었다.