케이터링·단체급식 유통은 겉으로는 "주문 받고 배송"이지만, 그 안에는 메뉴 레시피, 재료 소요량, 재고 입출고, 파트너·협력사 정산이 촘촘히 얽혀 있습니다. 이 프로젝트는 그 전체 흐름을 하나의 규칙 엔진으로 묶어 1인 개발로 실운영까지 끌어올린 케이터링 식자재 ERP입니다. 먼저 60초 소개 영상으로 전체 그림을 보여드립니다.
케이터링 식자재 ERP 소개 영상
케이터링 식자재 ERP가 풀어야 했던 문제
케이터링 식자재 ERP의 핵심 과제는 "주문 한 건이 만드는 파급"을 사람이 손으로 따라가지 않게 하는 것이었습니다. 케이터링은 주문 한 건이 곧바로 여러 갈래로 퍼집니다. 어떤 메뉴가 몇 개 나가는지에 따라 필요한 재료가 정해지고, 그 재료는 창고에서 빠져나가며, 빠져나간 만큼 재고가 줄고, 월말에는 파트너 매출과 알바비, 협력사 대금이 정산됩니다.
도입 전 이 흐름은 여러 개의 엑셀과 사람의 기억으로 이어져 있었습니다. 메뉴가 정해지면 담당자가 레시피를 보며 재료를 손으로 계산하고, 같은 재료를 여러 메뉴가 쓰면 머릿속으로 합산했습니다. 재고는 별도 장부에서 관리되니 "이 주문을 다 내보내면 무엇이 부족해지는지"는 아무도 정확히 알지 못했습니다. 월말 정산은 주문 목록과 근무 기록, 세율표를 오가며 계산기를 두드리는 일이었습니다.
문제는 단순히 손이 많이 가는 게 아니라, 각 단계가 서로 끊겨 있어 오류가 뒤로 전파된다는 점이었습니다. 재료 계산이 틀리면 발주가 틀리고, 재고 장부가 어긋나면 부족을 뒤늦게 발견하고, 정산 근거가 흩어져 있으면 파트너와의 정산이 매달 분쟁거리가 됩니다. 그래서 이 사례의 목표는 "화면을 예쁘게 만드는 것"이 아니라, 케이터링 업무의 규칙 자체를 코드로 정확히 모델링해 한 흐름으로 잇는 것이었습니다.
주문 한 건이 재료·재고·정산으로 이어지는 접근
핵심 결정은 업종 특화 규칙(레시피 BOM·단위 환산·3종 정산 세율)을 코드로 정확히 모델링하고, 콜백과 서비스 객체로 단계를 자동으로 잇는 것이었습니다. 화면에 보이는 버튼 뒤에서 주문·재고·정산이 서로를 트리거하도록 설계했습니다. 기술적으로는 Ruby on Rails와 PostgreSQL, Hotwire(Turbo·Stimulus) 조합으로 무거운 SPA 없이도 반응이 빠른 내부 운영 도구를 만들었습니다.
기능
메뉴와 수량만 고르면 필요 재료가 자동 산출
주문에 메뉴와 수량을 넣으면, 각 메뉴의 레시피를 재료 단위로 펼쳐(BOM 폭발) 품목별로 합산합니다. 여러 메뉴가 같은 재료를 쓰면 자동으로 더해져, 담당자가 레시피를 보며 손으로 재료를 세던 작업이 사라집니다.
메뉴별 필요재료 자동산출 화면
필요재료 자동산출 표 화면
재료가 정해지면 그 재료는 창고에서 빠져나갑니다. 입고와 출고를 재고에 실시간으로 반영하되, 재고 단위(box)와 사용 단위(ea)가 다른 케이터링 품목의 특성을 환산율로 통일했습니다. 출고가 끝나 주문의 모든 재료가 나가면 주문 상태가 자동으로 "출고완료"로 넘어갑니다.
기능
입고·출고가 재고에 실시간 반영
입고를 등록하면 환산율로 계산된 수량만큼 현재고가 즉시 늘고, 출고하면 그만큼 줄어듭니다. 수정·삭제 시에는 차이만큼만 다시 조정해 장부가 어긋나지 않습니다. 재고 갱신은 잠금(lock) 안에서 처리해 동시 입출고에도 값이 꼬이지 않습니다.
입고·재고 실시간 반영 화면
가장 손이 많이 가던 재고 관리는 "지금 얼마 남았나"가 아니라 "언제 부족해지나"를 아는 것이 관건이었습니다. 그래서 출고 예정 주문을 미래로 순산해 품목별 재고 소진 예상일을 계산하고, 14일 추이 차트에 안전재고선과 함께 시각화했습니다.
기능
출고 예정 주문으로 재고 소진일을 예측
아직 나가지 않은 출고대기 주문을 날짜순으로 재고에서 빼 나가면서, 각 품목이 안전재고 아래로 떨어지는 예상일을 계산합니다. 과거 실제 입출고와 미래 예상 출고를 한 타임라인에 겹쳐, 발주 타이밍을 눈으로 잡을 수 있습니다.
재고 소진 예측 화면
재고 추이 예측 차트 화면
마지막은 월말 정산입니다. 케이터링 운영에는 성격이 다른 세 정산이 함께 돕니다. 파트너 매출 정산, 알바비(비용) 정산, 협력사 정산이 각기 다른 공식과 공제 규칙을 가집니다. 이 셋을 연·월 선택 한 번으로 일괄 생성하고, 유형별 세금·수수료를 자동으로 공제해 지급액까지 계산하도록 서비스 객체로 분리했습니다.
기능
매출·알바비·협력사 3종 정산 일괄 자동생성
연도와 월을 고르면 대상자별로 세 종류의 정산이 자동으로 만들어집니다. 각 정산은 주문 매출이나 근무 기록에서 근거를 끌어와 총액을 잡고, 유형에 맞는 세금·수수료를 공제해 실지급액을 계산합니다.
다중 정산 자동화 화면
정산 목록 상태 화면
정산은 계산만큼이나 "한 번 확정한 값이 바뀌지 않는 것"이 중요합니다. 확정·지급완료된 정산은 재계산 로직이 건드리지 못하게 잠갔고, 주문이 바뀌거나 취소되면 아직 대기 상태인 정산만 다시 계산되도록 상태를 기준으로 갈랐습니다.
맞춤 ERP로 얻은 결과
메뉴·재료·재고·출고·정산으로 흩어져 있던 업무가 하나의 규칙 엔진으로 이어지면서, 주문 한 건을 넣으면 그 뒤의 재료 산출·재고 차감·소진 예측·정산 생성이 사람 손을 거의 타지 않고 흘러가게 되었습니다. 담당자는 "계산"이 아니라 "확인"을 하게 됐고, 부족은 닥쳐서가 아니라 미리 보이게 됐습니다.
이 사례에서 우리가 가장 신경 쓴 것은 화려한 기능이 아니라 업종의 규칙을 코드로 정확히 옮기는 일이었습니다. 레시피가 재료로 펼쳐지는 방식, 재고 단위와 사용 단위가 갈리는 방식, 세 정산의 공제 세율과 확정 불변성. 이런 도메인 규칙을 SaaS의 일반 틀에 억지로 맞추지 않고 코드로 모델링한 것이 이 시스템의 신뢰성을 만들었습니다.
각 기능의 설계 결정은 아래 글에서 더 자세히 풀었습니다.
- 자재명세서(BOM)로 필요 재료를 자동 산출하는 법: 레시피를 재료로 펼치는 BOM 폭발
- 재고 단위와 사용 단위를 분리한 이유: 환산율로 재고 무결성 지키기
- 출고 예정 주문으로 재고 소진일을 예측하는 법: 안전재고 부족 예측
- 다중 정산을 자동화한 방법: 3종 정산과 세금 공제
- 확정된 정산은 건드리지 않는다: 정산 데이터 불변성 설계
- 재고 SaaS와 맞춤 ERP 중 무엇을 골라야 하나: 업종 특화면 맞춤
- 근무 시간이 시급·정산으로 자동 흐르게: 근무세션에서 정산까지
형제 사례로, 같은 "맞춤 시스템" 관점의 행사·캐스팅 에이전시 CRM과 재고 주제가 인접한 유통 가격·재고 모니터링도 함께 보시면 좋습니다.
자주 묻는 질문
케이터링 식자재 ERP는 무엇을 자동화하나요?
주문 한 건에서 시작되는 파급을 자동화합니다. 메뉴·수량으로 필요 재료를 산출하고, 입출고를 재고에 반영하며, 출고 예정 주문으로 재고 소진일을 예측하고, 월말에는 매출·알바비·협력사 3종 정산을 세금 공제까지 자동으로 만듭니다. 사람은 계산 대신 확인만 하면 됩니다.
SaaS 대신 맞춤으로 개발한 이유는 무엇인가요?
케이터링에는 레시피 BOM, 재고 단위 환산, 3종 정산 세율처럼 일반 SaaS 틀에 들어가지 않는 업종 규칙이 많습니다. 이 규칙들을 코드로 정확히 모델링해야 계산과 정산이 신뢰할 수 있게 됩니다. 그래서 범용 재고 SaaS 대신 업무 규칙을 그대로 담는 맞춤 ERP를 선택했습니다.
주문이 바뀌면 재고와 정산도 알아서 맞춰지나요?
네. 주문을 수정하면 필요 재료가 다시 계산되고, 입출고 수정·삭제는 차이만큼만 재고를 조정합니다. 정산은 아직 대기 상태인 것만 다시 계산되고, 이미 확정·지급완료된 정산은 그대로 잠겨 바뀌지 않습니다.
1인 개발로 만든 시스템인데 실운영에 문제는 없나요?
재고 갱신을 잠금 안에서 처리해 동시 입출고에도 값이 꼬이지 않게 했고, 확정 정산 불변성과 상태 기반 재계산으로 데이터가 뒤늦게 어긋나는 일을 막았습니다. 화면 수 대신 규칙의 정확성에 집중해, 실제 운영에 필요한 신뢰성을 우선으로 설계했습니다.