1) SeMo(Settlement + Moa = 정산 모아)

semo!!

새 사이드프로젝트 시작 — SEMO(세모), 정산을 모아모아!

SEMO(=Settlement + Moa)는 "정산을 모아~모아~모아서!" 한글 발음으로는 세모!
날카롭고 정확하게 정산을 한다는 의미입니다.

정산, 셀러도 공급사도 모두 힘들다..

NONOS를 7개월간 운영하면서 하나의 패턴을 발견했습니다.

주문 수집, 발주, 송장 처리 — 이건 NONOS로 자동화가 됐습니다.
그런데 매달 말이 되면 똑같은 고통이 반복됩니다. 바로 정산입니다.

셀러(판매사) 입장에서는 이렇습니다.

• 이번 달 A업체에 발주한 게 총 몇 건이지?
• 부분출고된 건 빼야 하나?
• 반품 2건은 차감해야 하는데 어디 적어뒀더라?
• 배송비는 누가 부담이었지?

공급사 입장도 마찬가지입니다.

• 우리가 보낸 송장 기준으로 정산해야 하는데, 판매사가 보내준 엑셀이 지난달 양식이랑 다르다
• 취소건이 빠져있는 것 같은데 확인할 방법이 없다
• 매달 전화해서 맞춰봐야 한다

결국 양쪽 다 엑셀을 열고, 발주서와 송장을 대조하고, 수작업으로 계산합니다.
매달! 거래처가 여러 곳이면 거래처 수만큼! ㄷㄷ

기존 솔루션은 왜 안 되나?

이미 시장에는 발주모아, 사방넷 같은 솔루션이 있습니다.
써봤거나 검토해본 분들은 아시겠지만, 이런 서비스들은 기능이 정말 많습니다. 많은게 문제입니다.

개발하면서 제일 좋아하는 말은.. Simple is Best

소규모 셀러 입장에서는 "이번 달 A업체에 얼마 줘야 하는지" 그게 전부인데,
이걸 위해 복잡한 시스템을 도입하고 세팅하는 건 배보다 배꼽이 더 큰 상황입니다.
월 구독료도 부담이고요.

NONOS를 쓰고 있는 셀러라면 발주 데이터가 이미 시스템에 있습니다.
여기서 정산까지 자연스럽게 이어지면 가장 이상적 입니다.

SEMO가 해결하려는 것

핵심은 단순합니다.

  발주서 (판매사 → 공급사)
  ├── 상품명, 옵션, 수량
  ├── 공급가 (거래처별 단가)
  └── 발주일

  + 송장 (공급사 → 판매사)
  ├── 송장번호, 택배사
  ├── 출고일
  └── 실제 출고 수량 (부분출고 가능)

  = 정산 데이터
  ├── 공급가 × 실출고 수량 = 공급사 지급액
  ├── + 배송비
  ├── - CS 차감 (반품/취소 건)
  └── = 최종 정산금

발주서 + 송장 = 정산. 이 공식만 시스템이 정확하게 계산해주면 됩니다.

SEMO는 이 데이터를 두 가지 경로로 받습니다.

[NONOS] ──API──→ [SEMO 정산 시스템]
                        ↑
[엑셀 업로드]    ──────────┘
[다른 쇼핑몰 연동]  ────────┘

• NONOS 사용자: API로 발주·송장 데이터가 자동 연동 — 별도 입력 없이 정산 가능
• NONOS 미사용자: 엑셀 업로드로 동일한 정산 기능 사용 가능
• 향후: 다른 쇼핑몰 연동도 확장 가능한 구조

NONOS를 사용하고 있다면 시너지가 극대화되지만, SEMO 단독으로도 동작하는 독립적인 시스템으로 설계할 예정입니다.

기술 스택 (예정)

NONOS와 동일한 기반에서 프론트엔드+백엔드 형식의 Monolith로 구성할 계획입니다.

영역기술

Backend	Kotlin + Spring Boot
Frontend	React + TypeScript
Database	MariaDB (AWS)
Messaging	Kafka (2단계 도입 예정)
인프라	Docker + Synology NAS / AWS 하이브리드
외부 연동	NONOS API, NaverStore API

NONOS와 같은 기술 스택을 사용하는 이유는 코드 공유와 유지보수 효율 때문입니다.
공통 모듈(인증, 업체 관리 등)을 재사용하고, 하나의 레포에서 두 시스템을 관리할 수 있는 구조를 목표로 합니다.

Kafka는 1단계에서는 도입하지 않습니다. 정산은 기본적으로 월 단위 배치 성격이라 REST API만으로 충분할꺼라 예상됩니다.
2단계에서 NONOS와 연동할 때, 발주 확정·출고 완료·취소 발생 같은 상태 변경을 이벤트로 발행하고 SEMO가 consume하는 구조를
시도해볼 예정입니다.
실제로 돌려보고 이 규모에서 오버스펙이라고 판단되면 과감하게 걷어낼 생각입니다.
기술은 필요할 때 도입하고, 안 맞으면 빼는 게 맞고 그 과정 자체도 블로그에 기록할 예정입니다.

앞으로의 계획

NONOS를 만들 때도 그랬지만, 일단 가장 작은 단위의 동작하는 버전을 빠르게 만드는 게 목표입니다.

1단계 — 정산 핵심 (REST API 기반)

• 월별 정산 요약 (업체별 발주 총액, 출고 수량, 차감 내역, 최종 정산금)
• 엑셀 업로드로 발주/송장 데이터 입력
• 정산서 PDF 출력

2단계 — NONOS 연동 + Kafka 도입 시도

• NONOS → SEMO 이벤트 기반 데이터 연동 (발주 확정, 출고 완료, 취소 이벤트)
• Kafka를 통한 비동기 파이프라인 구성
• 실제 운영하면서 Kafka가 이 규모에 적합한지 판단

3단계 — 확장

• 다른 쇼핑몰 연동 (쿠팡, 11번가 등)
• 공급사 전용 뷰 (정산 내역 확인·이의 제기)

개발 과정은 NONOS 때처럼 이 블로그에 계속 기록할 예정입니다.

---

NONOS가 "주문 처리의 스트레스를 없애자(No! No! Stress!)"였다면, SEMO는 "정산을 모아서 날카롭게 정리하자"입니다.
결국 같은 목표 — 소규모 셀러가 진짜 중요한 일에 집중할 수 있도록, 반복 업무를 기술로 해결하는 것!
친구야 기다려라~ㅋㅋ 너의 스트레스는 내가 해소시켜준다!!

SEMO 개발기, 시작합니다.

노노스!