ESSAY · 2026.10.18
AI가 내놓은 숫자를 사업 판단에 쓰기 전에
글 | F&B 운영자 배경한
카페에서 “이 메뉴의 마진은 30%입니다”라는 답을 받았다고 해보자. 숫자를 보기 전에 확인할 것이 있다. 판매가는 부가세를 포함했는지, 배달 수수료는 어느 금액에 붙였는지, 포장비는 한 잔 기준인지 주문 한 건 기준인지다. 같은 판매 내역도 이 조건이 달라지면 다른 결론이 나온다. AI가 설명을 매끄럽게 붙여도 계산의 출발점까지 정해주지는 않는다.
나는 유니컵을 운영하며 메뉴와 원가, 판매 조건을 사업의 언어로 다룬다. 직접 만든 F&B Margin Kit과 과학·데이터 소프트웨어에 병합된 수정들을 함께 보면 공통된 관심이 드러난다. 입력값이 계산에 들어갈 수 있는 상태인지, 계산이 정한 규칙을 지켰는지, 결과를 확인하는 테스트가 실제 실행을 반영하는지다. 업종과 프로그램은 달라도 숫자를 채택하기 전에 필요한 질문은 서로 닮아 있다.
F&B Margin Kit은 메뉴별 판매가와 수량, 재료비, 포장비, 플랫폼 수수료를 받아 공헌이익을 계산한다. 부가세를 제외한 판매액에서 정해진 변동비를 차감하고, 판매 수량을 곱한다. 여기서 공헌이익은 인건비와 임대료 등을 부담할 재원을 보는 값이다. 월세까지 반영하고 싶다면 같은 기간의 고정비를 별도로 넣어야 한다. 보고서의 숫자에 어떤 이름을 붙이느냐부터 경영 판단의 일부다.
예를 들어 부가세 포함 판매가가 5,500원, 세율이 10%, 재료비가 1,200원, 포장비가 150원, 판매가 기준 수수료율이 3%인 가상 메뉴를 생각해보자. 부가세를 제외한 판매액은 5,000원이고 수수료는 165원이다. 한 개당 공헌이익은 3,485원이다. 수수료를 부가세 제외 금액에 적용하면 15원 차이가 생긴다. 어떤 기준을 쓸지는 계약과 자료에서 먼저 정해야 한다.
AI는 이 계산을 설명하거나 입력표를 정리하는 데 도움을 줄 수 있다. 사업자가 다시 계산해보려면 설명 옆에 원본 행과 적용한 규칙이 있어야 한다. 내가 만드는 도구에서는 같은 입력으로 같은 결과를 확인할 수 있게 계산 규칙을 코드와 예제로 남긴다. 가격 변경안을 비교할 때도 판매가, 원가, 판매 수량 중 무엇을 바꿨는지가 드러나야 한다. 변화의 이유를 알 수 있어야 다음 행동을 정할 수 있다.
미국 USGS의 dataretrieval-python에 기여한 #431은 값이 빠져 있을 때 생기는 문제를 다뤘다. 관측 시각을 기준으로 가까운 데이터를 찾는 함수에 결측값이 들어가면 잘못된 시간 조건이 만들어졌다. 요청이 만들어지기 전에 입력을 거절하도록 고쳤고, 유지관리자는 시각과 검색 구간의 검증을 확장했다. 이 변경은 병합됐고 v1.4.0 릴리스 노트에도 실렸다.
비개발자에게는 “날짜가 없는 매출 행으로 기간별 비교를 시작해도 되는가”라는 질문에 가깝다. 비어 있는 날짜를 오늘로 채울지, 별도로 분류할지, 작업을 멈출지는 서로 다른 선택이다. 프로그램이 조용히 하나를 택하면 나중에는 원래 비어 있었다는 사실조차 찾기 어렵다. 이 USGS 수정에서 내가 주목하는 것은 오류 문구 자체보다, 불완전한 입력이 다음 작업으로 넘어가는 지점을 정한 점이다.
결과를 검사하는 쪽에도 같은 주의가 필요하다. Rule2DRC의 #4에서는 일부 테스트 실행이 실패했는데도 전체 평가가 성공으로 표시될 수 있는 조건을 수정했다. 실행 실패가 0으로 된 예측에 섞이고, 기대값 역시 모두 0인 경우 기존 판정이 성공을 허용할 수 있었다. 모든 테스트 실행이 성공했는지 먼저 확인하도록 바꾸고, 실제 KLayout을 실행하는 재현 사례를 포함해 확인했다. 이 PR도 병합됐다.
사업 보고서에 대입하면 누락된 배달 채널의 매출을 0원으로 받아들이는 상황과 비슷하다. 보고서 합계가 맞고 표가 완성됐다는 사실만으로 원자료를 모두 읽었다고 결론 내릴 수는 없다. 자료가 없었던 것인지, 읽기에 실패한 것인지, 실제 거래가 0건이었는지를 구분해야 한다. 매장별 손익을 비교할 때 이 구분이 빠지면 문제가 적은 매장과 자료가 덜 들어온 매장을 뒤섞게 된다.
그래서 평가에는 답의 정확성뿐 아니라 실행의 완전성도 들어가야 한다. 발주 수량을 계산했다면 모든 재료를 처리했는지, 정해진 단위로 환산했는지, 이미 가진 재고를 한 번만 차감했는지 확인한다. 실패한 항목을 제외하고 남은 항목의 평균 점수만 올려서는 운영자가 빠진 주문을 알아차리기 어렵다. 실패한 항목의 이름과 원인이 결과 옆에 남아야 재작업할 대상을 정할 수 있다.
계산이 올바른 값을 내면서 자원을 적절히 쓰는지도 중요한 문제다. forest-confidence-interval의 #134에서는 랜덤 포레스트가 만든 클래스별 확률 배열 중 선택하지 않은 값들이 오래 메모리에 남는 문제를 수정했다. 필요한 열을 복사해 보관하면 나머지 배열을 더 일찍 해제할 수 있었다. 계산 결과를 바꾸지 않으면서 보관하는 데이터의 수명을 줄이는 작업이었다.
PR에 공개한 비교는 트리 50개, 클래스 20개, 테스트 행 10,000개를 사용했다. 각각 새 프로세스에서 측정한 Tracemalloc 최대 사용량은 약 84.2MB에서 8.4MB로 줄었고, 분산 출력 10,000개는 바이트 단위로 같았다. #134는 병합됐으며, 2026년 10월 18일 확인한 최신 0.9 릴리스보다 뒤에 반영된 변경이다. 이 수치는 해당 조건에서 기록한 측정값으로 읽는 것이 맞다.
forestci의 다른 병합 수정인 #128은 계산 자체를 다뤘다. 학습 자료의 일부 행만 사용하던 편향 보정식을 전체 행을 사용하도록 고쳐, 행 순서를 바꿨다는 이유로 보정 결과가 달라지던 문제를 해결했다. 사업 자료에서도 행 순서를 바꾸거나 같은 항목을 나누어 기록했을 때 합계가 유지되는지 확인해볼 수 있다. 이런 검사는 결과가 그럴듯한지 눈으로 판단하는 것보다 구체적인 기준을 준다.
운영자는 모든 코드를 읽을 필요가 없다. 대신 설명을 검토할 때 세 가지를 요구할 수 있다.
- 입력의 기준을 확인한다. 어느 기간, 어느 매장, 어떤 통화와 세금 기준인지 적는다. 빈 값과 0을 구분하고, 원본 파일에서 해당 행을 찾을 수 있게 한다.
- 계산의 경계를 확인한다. 수수료를 무엇에 곱했는지, 고정비를 포함했는지, 예상 판매량을 누가 정했는지 확인한다. 중요한 메뉴 한 개는 같은 입력으로 직접 다시 계산한다.
- 완료의 증거를 확인한다. 처리할 항목과 처리한 항목을 대조한다. 실패·누락 항목을 남기고, 사용한 규칙과 프로그램 버전도 함께 기록한다.
발주까지 이어질 때는 입력의 시간 기준이 특히 중요하다. F&B Margin Kit의 구매 계획 기능은 예정 판매량과 레시피, 수율, 원재료 재고를 받아 필요한 구매 묶음을 계산한다. 여러 메뉴가 함께 쓰는 재료를 합치고 현재 재고를 한 번 차감한 뒤 부족분을 포장 단위로 올림한다. 예정 판매량은 운영자가 제공하는 값이다. 이 값을 어떤 기간의 예상으로 넣었는지에 따라 주문할 양의 의미가 정해진다.
AI에게 다음 주 라테 판매량을 제안받았다면 그 수량을 확정하기 전에 행사, 휴무, 최근 판매 자료를 확인할 수 있다. 확정한 수량을 계산기에 넘긴 뒤에는 우유의 단위, 수율, 남은 재고, 공급업체 포장 크기를 확인한다. 추정값을 정하는 판단과 그 값으로 구매량을 계산하는 작업을 나누어 기록하면, 실제 판매가 예상과 달랐을 때 어느 부분을 바꿔야 할지 찾기 쉽다.
나는 이런 확인을 운영자가 읽을 수 있는 표와 짧은 설명으로 제공하고 싶다. 담당자가 바뀌어도 같은 파일에서 숫자의 근거를 찾고, 주문 전에 잘못된 단위를 발견하며, 다음 달에는 같은 기준으로 비교할 수 있게 만드는 일이다. AI가 제안한 숫자 옆에 입력, 계산 규칙, 실행 기록이 남아 있을 때 사업자는 그 숫자를 채택할 이유를 스스로 판단할 수 있다.
자료·코드·실행 기록 · 2026-10-18 확인