매출을 물었는데, 먼저 매출의 기준을 정해야 했습니다

LISA에 견적과 매출이 쌓이고, 타스에게도 물어볼 수 있게 되니 홈 화면에서 바로 확인하고 싶은 숫자가 늘었습니다.

이번 달에 어느 정도 진행되고 있는지, 실제로 발행된 매출은 얼마인지, 이익은 얼마나 남았는지를 보고 싶었습니다. 메뉴를 하나씩 열어보던 것을 한 화면에서 볼 수 있으면 편할 것 같았습니다.

그런데 숫자를 모으기 전에 기준을 다시 확인해야 했습니다. 제가 ‘이번 달 매출’이라고 말할 때도 어떤 일을 하느냐에 따라 뜻이 달랐습니다. 예상 발주일을 보고 이야기할 때가 있고, 세금계산서를 발행한 내역을 보고 이야기할 때가 있었습니다.

사람끼리는 앞뒤 상황을 보고 알아듣기도 합니다. LISA의 집계와 타스의 조회에는 그 상황을 구체적으로 적어줘야 했습니다.

같은 거래에도 날짜가 여러 개였습니다

견적을 작성한 날, 발주를 예상한 날, 계산서를 발행한 날은 다를 수 있습니다. 갱신 업무에는 라이선스 만료일도 있습니다.

예를 들어 9월에 발주를 예상했지만 계산서는 10월에 발행한 거래가 있다고 해보겠습니다. 9월의 견적 진행 상황과 10월의 발행 매출에 각각 등장할 수 있습니다. 날짜 기준을 모른 채 두 화면을 비교하면 어느 한쪽이 잘못된 것처럼 보일 수 있습니다.

현재 LISA에서 연 매출과 분기 매출은 세금계산서 발행일을 기준으로 봅니다. 반면 당월 견적 현황은 예상 발주일을 봅니다. 타스가 등록 매출을 조회할 때도 발행일을 기준으로 하도록 했습니다.

같은 거래라도 어떤 날짜로 조회하는지에 따라 보이는 달이 달라집니다. 거래와 날짜는 설명용 예시입니다.

갱신 후보는 또 다릅니다. 등록된 만료일을 찾아보는 것이므로, 그 결과를 곧바로 올해 매출이나 갱신 완료 내역으로 읽으면 안 됐습니다. 만료일이 빠졌다는 사실만으로 갱신이 누락됐다고 판단할 수도 없었습니다.

6화에서 타스의 조회 기간을 나눴던 이야기를 했는데, 기간을 정확히 잡는 것만큼 어떤 날짜를 쓰는지도 중요했습니다. 같은 고객에 같은 기간을 넣어도 기준이 다르면 서로 다른 질문이었습니다.

홈 화면의 숫자는 서로 더할 수 있는가

홈 화면은 매출 완료, 예상 매출, 연 매출, 분기 매출, 입금 기한이 지난 잔액을 보는 형태로 정리했습니다. 앞의 네 칸에는 이익도 함께 표시했습니다.

이 과정에서 ‘매출 완료’라는 이름도 다시 보게 됐습니다. 현재 그 칸은 당월 예상 발주일에 해당하는 80%와 100% 상태의 견적을 모읍니다. 계산서 발행이 끝난 매출만 뜻하는 이름으로 읽으면 실제 집계와 어긋납니다. 이 부분은 사용할 때 기준을 알고 봐야 하고, 표시명도 계속 살펴볼 부분입니다.

‘예상 매출’에는 같은 달의 60%, 80%, 100% 견적이 들어갑니다. 앞의 두 칸은 진행 범위를 다르게 보는 숫자여서 서로 겹칩니다. 이 둘을 더하면 같은 견적을 다시 셀 수 있습니다.

상태가 80%라고 금액에 0.8을 곱한 것도 아닙니다. 저희가 정한 상태 범위에 들어가는 견적의 등록 금액 전액을 봅니다. 단계 이름과 금액 계산 방식을 따로 설명해야 했습니다.

연 매출과 분기 매출도 비슷합니다. 이번 분기 매출은 올해 매출 안에 이미 들어 있으니 두 숫자를 합칠 수 없습니다. 한 화면에 나란히 놓았다고 해서 모두 합산할 수 있는 숫자는 아니었습니다.

매출과 이익은 부가세 별도로 표시하지만, 입금 기한이 지난 잔액은 부가세 포함 금액입니다. 받을 돈과 매출을 같은 금액으로 놓고 비교하지 않도록 이 기준도 구분했습니다.

Codex와 화면을 다듬을 때는 카드에 어떤 이름을 붙일지와 함께, 누르면 어떤 내역이 열리는지도 확인했습니다. 요약 금액을 보고 궁금하면 견적별로 내려가고, 그 안의 품목을 펼쳐볼 수 있게 했습니다. 상태 필터를 바꾸면 내역과 합계도 같이 바뀌도록 맞췄습니다.

숫자가 예상과 다를 때 설명을 듣는 것보다, 어떤 기록이 포함됐는지 직접 열어보는 편이 확인하기 쉬웠습니다.

원가가 비어 있으면 이익도 아직 모르는 것입니다

이익을 함께 표시하면서는 빈 값 처리부터 확인했습니다.

매출액은 있는데 원가가 등록되지 않은 품목이 있을 수 있습니다. 원가를 0원으로 넣으면 매출액 전체가 이익처럼 보입니다. 원가가 없는 것과 아직 원가를 모르는 것은 달랐습니다.

품목 중 일부의 원가나 이익이 빠졌을 때, 알고 있는 값만 더해 전체 이익처럼 표시하지 않도록 했습니다. 필요한 값이 없으면 미등록으로 남기고, 매출이 0원이면 이익률을 계산할 수 없다고 표시했습니다. 손실이 난 거래는 음수로 보여줘야 했습니다.

견적에 등록한 매입액과 실제 매입 내역도 구분해야 했습니다. 견적을 만들 때 계산한 원가가 실제 발주·정산 자료까지 대조됐다는 뜻은 아닙니다. 타스가 표를 잘 만들었다고 그 안의 금액이 별도 검증 없이 확정되는 것도 아니었습니다.

이익률 합계도 따로 봤습니다. 예를 들어 가상의 두 거래가 있다고 해보겠습니다. 매출 100만원에서 이익 12만원이 난 거래와, 매출 900만원에서 이익 72만원이 난 거래입니다. 각각 이익률은 12%와 8%지만, 둘을 평균 낸 10%가 전체 이익률은 아닙니다.

두 거래의 매출 1,000만원과 이익 84만원을 놓고 계산하면 전체 이익률은 8.4%입니다. 품목별 비율을 단순히 평균 내지 않고 합계 금액으로 계산하도록 했습니다.

실제 거래가 아닌 가상 데이터입니다. 개별 이익률의 평균 대신 전체 매출과 이익으로 계산한 값은 8.4%입니다.

설명만 들으면 당연한 계산인데, 화면에 합계 행을 붙일 때는 이런 규칙을 하나씩 확인해야 했습니다.

묶어서 보여줘도 되는 기록

상세 화면을 만들면서는 어느 기록을 같은 견적으로 묶을지도 정했습니다.

같은 고객명이라고 모두 같은 거래는 아니었습니다. 견적 ID가 있으면 그 기준으로 품목을 묶고, 이관된 자료에 ID가 없으면 고객명이 같다는 이유로 임의로 합치지 않도록 했습니다.

타스가 고객별 매출을 찾을 때는 두 회사 이름이 함께 적힌 내역도 있었습니다. 검색어에 걸린다고 그 금액 전체를 한 회사만의 실적으로 단정할 수는 없었습니다. 등록된 이름을 따로 보여주고 확인할 수 있게 했습니다.

비슷해 보이는 행도 바로 중복으로 지우지 않았습니다. 날짜와 등록 정보가 다른 거래일 수 있기 때문입니다. 보기 좋은 표를 만들려고 기록의 의미를 바꾸지 않도록 신경 썼습니다.

운영에 반영한 뒤에는 홈의 합계와 상세 내역, 타스의 표를 각각 원본과 대조했습니다. 화면이 열리는 것 외에 필터를 바꿨을 때 포함되는 품목, 빈 원가 처리, 합계 이익률까지 확인했습니다.

제가 업무를 설명하는 방식도 바뀌었습니다

처음 Codex에게 요청할 때는 ‘매출을 보여줘’, ‘이익도 같이 넣어줘’처럼 말했습니다. 작업하다 보니 제가 결정해야 하는 내용이 계속 나왔습니다. 어느 날짜를 쓸지, 어떤 상태를 포함할지, 비용이 없을 때 무엇을 보여줄지였습니다.

AI가 코드를 만들어주는 속도와 별개로, 이 기준은 제가 확인해야 했습니다. 답이 마음에 들지 않으면 질문을 다시 쓰기 전에 제가 같은 단어를 여러 뜻으로 쓰고 있지는 않았는지도 보게 됐습니다.

아직 화면의 이름과 실제 기준이 충분히 직관적인지는 더 써봐야 합니다. 등록 자료가 빠졌다면 조회 기능이 정상이어도 결과는 부족할 수 있습니다. LISA와 타스를 쓰면서 그런 부분을 찾아 고치고 있습니다.

이제 새로운 숫자를 추가할 때는 포함할 기록과 날짜부터 적어보려고 합니다. 화면에서 그 숫자를 눌렀을 때, 제가 확인하려던 내역으로 내려갈 수 있는지도 함께 봅니다.