모든 변경을 이벤트로 쌓는 ERP
값을 덮어쓰지 않고 일어난 일을 그대로 쌓습니다. 그래서 어떤 과거 시점이든 그때 그대로 볼 수 있고, 잘못한 작업은 범위를 확인한 뒤 되돌릴 수 있으며, 쌓인 이력으로 바꾸기 전에 결과를 시험할 수 있습니다.
모듈끼리는 이벤트로만 만납니다. 그래서 판매만 쓰다가 필요할 때 재고를 켜도 판매 모듈은 달라지지 않고, 한 모듈이 멈춰도 다른 모듈은 계속 일합니다.
회사가 크는 만큼 더합니다
실제 앱을 돌려 찍은 화면입니다. 데이터는 가상 회사 가온가전입니다.
모듈
필요할 때 하나씩 켭니다
처음에는 판매만 켜져 있습니다. 어떤 조합으로도 동작하고, 켜면 메뉴와 쓸 수 있는 예측이 함께 늘어납니다.
- 장애 격리재고 모듈이 멈춰도 주문은 계속 받고, 고치면 밀린 이벤트를 누락 없이 처리합니다.
- 나중에 켜기회계를 나중에 켜도 지난 청구와 입금으로 전표를 다시 만듭니다. 켜기 전의 재고처럼 알 수 없는 것은 그렇다고 알려 줍니다.
- 플러그인SQL 파일 하나로 모듈을 더합니다. 기존 모듈을 고치지 않습니다.
업무
견적부터 입금까지, 발주부터 지급까지
견적, 주문, 출고, 재주문, 구매, 입고, 청구, 입금, 분개가 이벤트로 이어집니다.
- 재고창고, 입출고, 재고 조정, 재주문 규칙, 평균 원가.
- 청구와 회계청구서, 대변 메모, 입금, 시산표, 손익, 재무상태, 세금 집계, 기간 잠금.
- 은행명세서를 파일로 가져와 입금과 맞춰 봅니다. 은행 자동 연결은 없습니다.
시간 여행
그때 그대로 보고, 범위를 확인하고 되돌립니다
날짜를 고르면 그 시점의 주문, 재고, 미수금이 그대로 보입니다. 되돌리기는 지우지 않고 이벤트를 하나 더 남깁니다.
- 연쇄 미리보기주문을 되돌리면 함께 돌아갈 출고와 재고를 모듈을 넘어 먼저 보여 줍니다.
- 막아야 할 것은 막습니다게시된 청구서가 얽히면 막고 대변 메모를 안내합니다. 잠금일 이전도 막습니다.
- 사유와 이력누가 왜 되돌렸는지 원장에 남고, 되돌리기도 다시 되돌릴 수 있습니다.
예측과 what-if
바꾸기 전에 시험합니다
발주량, 단종, 창고 재배치, 납기, 결제 조건을 바꾸면 매출과 품절이 어떻게 달라지는지 80% 구간으로 보여 줍니다. 원장은 바뀌지 않습니다.
- 근거가 없으면 숫자를 내지 않습니다모델마다 잠김, 근거 부족, 사용 가능 중 하나로 표시합니다.
- 구분할 수 없으면 그렇게 말합니다구간이 0을 포함하면 효과를 구분할 수 없다고 먼저 말합니다.
- 모듈이 늘면 함께 늡니다판매만으로는 통계와 수요 예측, 재고를 켜면 발주 시험, 구매를 켜면 납기 시험이 열립니다.
연동
REST 와 MCP 를 따로 만들지 않습니다
유형을 정의하면 REST 자원이 생기고, 에이전트는 도구 4개로 켜져 있는 모듈의 문서를 다룹니다. 별도 서버 프로세스가 없습니다.
- REST표준 CRUD, 버전 확인, 재시도 키.
- MCP조회, 생성, 수정, 삭제 도구 4개. 상태 변경이 곧 업무 동작입니다.
- 연동 키구성원 권한을 넘지 못하고, 언제든 폐기합니다. 키는 해시로만 저장합니다.
구성과 현재 상태
무엇이 되어 있고 무엇이 아직인지 그대로 적었습니다.
| 구분 | 내용 |
|---|---|
| 앱 공개 | 앱 주소와 소스 저장소는 곧 공개합니다. 그전까지 튜토리얼과 영상으로 흐름을 볼 수 있습니다. |
| 모듈 | 판매, 재고, 구매, 청구, 회계 다섯 개입니다. 32개 조합을 모두 시험합니다. |
| 기본 기능 범위 | 주요 ERP 의 기본 기능 256개 항목과 대조했습니다. 226개 제공, 22개 일부, 3개 없음, 5개는 메일 서버가 필요합니다. 고급 기능은 주문 처리에 필요한 것만 넣었습니다. |
| 없는 것 | 메일 발송, 전자세금계산서, 은행 자동 연결, 외화 환산(외화 입력은 거부합니다), XML 가져오기, 청구서 PDF 첨부. |
| 시험 | SQL 713개, 브라우저 166개. 모두 로컬 Supabase 에서 돌렸습니다. 실제 Supabase 클라우드에서는 아직 재지 않았습니다. |
| 용량 | 무료 플랜 500 MB 에 이벤트 약 13만 건, 주문 약 1만 건이 들어갑니다(다섯 모듈을 모두 켠 기준). 하루 주문 10건이면 약 3년입니다. |
| 예측의 정확도 | 정답을 아는 가상 회사로 쟀습니다. 품절이 잦은 회사에서는 발주와 단종 what-if 가 판매 이력만 쓴 것보다 크게 맞았지만, 재고가 넉넉한 회사에서는 차이가 작고, 창고 재배치는 대부분 구분할 수 없다고 답합니다. 실제 회사에서는 더 나쁠 수 있습니다. |
| 모듈 사이 지연 | 모듈은 이벤트로 이어지므로 주문 확정과 출고 전표 사이에 짧은 지연이 있습니다. 모듈마다 따로 확장할 수는 없습니다. |
| MCP | 도구 4개를 공식 MCP SDK 로 호출해 확인했습니다. Process GPT 에 실제로 연결해 돌리지는 않았습니다. |
영상으로 보기
실제 앱을 돌리며 녹화한 영상입니다. 데이터와 수치는 가상 회사의 것입니다. 썸네일을 누르면 재생됩니다.
제품 소개
제품 소개
모듈 켜기, 시간 여행, 되돌리기, what-if 를 한 번에 봅니다.
튜토리얼
1장 판매로 시작하기
설치하고 회사를 만든 뒤, 판매만 켠 상태로 견적과 주문을 처리합니다.
2장 재고 켜기와 장애 격리
재고를 켜면 주문 이벤트로 출고 전표가 생깁니다. 재고가 멈춰도 판매는 계속됩니다.
3장 구매·청구·회계
재주문에서 입고, 청구, 입금, 시산표까지 이어 갑니다. 회계는 나중에 켜도 과거 전표를 다시 만듭니다.
4장 시간 여행과 되돌리기
과거 시점을 그대로 보고, 잘못한 작업을 모듈을 넘어 범위를 확인한 뒤 되돌립니다.
5장 예측과 what-if
근거가 있을 때만 숫자를 냅니다. 발주, 단종, 재배치, 납기, 결제 조건을 바꾸기 전에 시험합니다.
6장 플러그인과 외부 연동
SQL 파일 하나로 플러그인을 붙이고, 자동 생성 REST 와 도구 4개의 MCP 로 연결합니다.