실패를 두려워하지 않고
될 때까지 덤비는 🔥
그런 프로그래머 😎

StoreOps Platform 시리즈

1. 왜 이 프로젝트를 시작했는가

편의점 운영 시스템을 주제로 백엔드 프로젝트를 정리하면서 가장 먼저 든 생각은 하나였다.

편의점 운영을 뒷받침하는 IT 시스템은 어떤 흐름으로 연결될까?

처음에는 편의점 IT라고 하면 고객이 사용하는 앱이나 POS 정도를 먼저 떠올렸다. 하지만 운영 흐름을 정리해보니, 편의점 IT는 생각보다 넓은 범위의 시스템을 다루고 있었다.

편의점 IT 시스템의 역할은 크게 세 가지로 나눠볼 수 있었다.

첫째, 그룹웨어, 물류/회계 시스템, 통합정보, RPA, DBA 등과 관련된 WEB 사내 시스템 설계 및 운영이다.
둘째, 고객 모바일 시스템 개발 기획 및 운영이다.
셋째, POS, OPC, PDA 등 점포설비 개발 및 운영이다.

구분 시스템 영역 내가 이해한 역할
WEB 사내 시스템 설계 및 운영 본사, 점주, 운영자가 사용하는 관리 시스템 개발 및 운영
APP 고객 모바일 시스템 개발 기획 및 운영 고객이 사용하는 모바일 서비스와 점포 데이터 연결
점포 시스템 POS/OPC/PDA 등 점포설비 개발 및 운영 실제 매장에서 판매, 입고, 재고 처리에 사용되는 시스템 운영

이 관점에서 편의점 운영 시스템은 단순히 하나의 웹 서비스를 만드는 일이 아니라, 편의점 운영 전반에 필요한 여러 시스템을 개발하고 안정적으로 운영하는 역할에 가깝다고 이해했다.

그래서 프로젝트를 정리하면서, 단순한 CRUD 프로젝트보다는 편의점 운영 흐름을 작게라도 반영한 프로젝트를 만들어보고 싶었다.

프로젝트 범위를 현실적으로 제한해야 했기 때문에, 모든 기능을 크게 구현하기보다는 핵심 데이터 흐름을 잘 보여주는 방향으로 범위를 잡았다.

2. 프로젝트 목표

이번 프로젝트의 이름은 StoreOps Platform으로 정했다.

목표는 편의점 운영에서 발생하는 핵심 데이터 흐름을 직접 구현해보는 것이다. 이를 위해 Spring Boot 기반의 모놀리스 백엔드 서버를 만들고, 개념적으로 다음 네 가지 클라이언트가 같은 데이터를 바라보도록 구성했다.

고객 앱
POS 판매 화면
PDA 입고 화면
관리자 대시보드

여기서 중요한 것은 클라이언트 화면의 완성도를 높이는 것이 아니었다. 실제로 보여주고 싶었던 것은 다음에 가까웠다.

POS에서 판매가 발생하면 재고가 줄어든다.
PDA에서 입고가 발생하면 재고가 늘어난다.
고객 앱은 변경된 재고를 조회한다.
관리자 화면은 재고 현황과 판매 이력을 바탕으로 결품 위험과 발주 추천을 확인한다.

즉, 여러 화면이 따로 움직이는 것처럼 보이지만 결국 같은 운영 데이터를 중심으로 연결되는 구조를 구현하고 싶었다.

완성도 높은 프론트엔드를 만드는 것보다, 작은 규모 안에서도 실제 운영 시스템의 데이터 흐름을 명확히 보여주는 것이 이번 프로젝트의 목표였다.

3. 왜 재고 데이터를 중심으로 잡았는가

프로젝트 범위를 정하면서 가장 먼저 고민한 것은 “편의점 운영에서 어떤 데이터가 가장 중요할까?”였다.

상품, 점포, 판매, 입고, 발주 등 여러 데이터가 있지만, 이 프로젝트에서는 재고를 중심 데이터로 잡았다.

편의점에서 재고는 단순히 “상품이 몇 개 남았는가”를 나타내는 숫자가 아니다. 재고 데이터는 고객 경험과 점포 운영을 동시에 좌우한다.

고객 입장에서는 앱에서 재고가 있다고 보고 점포에 방문했는데 실제로 상품이 없다면 헛걸음을 하게 된다. 반대로 실제 점포에는 상품이 있는데 앱에는 품절로 표시된다면 구매 기회를 잃게 된다.

점주 입장에서도 재고는 중요하다. 재고가 너무 적으면 결품이 발생하고, 재고가 너무 많으면 폐기나 보관 부담이 커질 수 있다. 특히 편의점은 상품 회전이 빠르고, 도시락이나 삼각김밥처럼 판매 기한이 중요한 상품도 많기 때문에 재고 관리의 정확성이 운영 효율에 직접적인 영향을 준다.

그래서 이번 프로젝트에서는 재고 데이터를 중심으로 다음 흐름을 구현하기로 했다.

POS 판매 → 재고 감소
PDA 입고 → 재고 증가
고객 앱 → 재고 조회
관리자 WEB → 재고 현황 확인
판매 이력 → 결품 위험 판단
재고/판매 데이터 → 발주 추천

이 흐름을 작게 구현하면 WEB, APP, 점포 시스템이 어떻게 하나의 운영 데이터로 연결되는지 보여줄 수 있다고 판단했다.

4. 프로젝트에서 중요하게 본 기술적 관점

이 프로젝트는 규모가 큰 시스템은 아니다. 그래서 무리하게 MSA나 복잡한 인프라 구조를 적용하기보다는, 작은 시스템 안에서도 운영 시스템다운 고민을 담는 것이 더 중요하다고 생각했다.

이번 프로젝트에서 중요하게 본 기술적 관점은 세 가지다.

4.1 재고 데이터 정합성

POS 판매가 발생하면 재고가 줄어야 하고, PDA 입고가 발생하면 재고가 늘어야 한다. 이 과정에서 재고가 음수가 되거나, 판매 이력과 재고 수량이 서로 맞지 않으면 안 된다.

예를 들어 판매 이력은 저장됐는데 재고가 줄지 않거나, 재고는 줄었는데 판매 이력이 저장되지 않으면 운영 중 원인 추적이 어려워진다.

따라서 판매 처리와 입고 처리는 트랜잭션으로 묶어 데이터 정합성을 지키는 방향으로 구현했다.

4.2 도메인 규칙 캡슐화

재고가 음수가 되면 안 된다는 규칙은 특정 API의 부가 로직이 아니라 Inventory 도메인 자체의 규칙이라고 보았다.

그래서 Service에서 단순히 수량을 직접 수정하기보다, Inventory 객체 안에 decrease()와 increase() 같은 메서드를 두고 재고 변경 규칙을 관리하도록 설계했다.

4.3 개발운영 관점

운영 시스템을 다루는 프로젝트인 만큼, 기능 구현에서 끝내지 않고 운영 관점도 함께 고려하려고 했다.

예를 들어 다음 요소를 포함했다.

표준 예외 응답
Swagger API 문서화
Actuator 헬스체크
핵심 이벤트 로그
테스트 코드
정적 클라이언트 화면

이를 통해 “로컬에서만 동작하는 코드”가 아니라, 외부에서 API 흐름을 확인하고 장애 상황도 어느 정도 파악할 수 있는 서비스 형태로 완성하고자 했다.

5. 앞으로 정리할 내용

이번 글에서는 편의점 운영 시스템를 분석하면서 왜 StoreOps Platform을 만들게 되었는지, 그리고 왜 재고 데이터를 중심으로 잡았는지 정리했다.

다음 글에서는 이 운영 흐름을 실제 도메인 모델로 어떻게 바꿨는지 정리하려고 한다.

특히 다음 내용을 다룰 예정이다.

편의점 운영 흐름 단순화
Store, Product, Inventory, Sale, Receipt 도메인 도출
현재 재고와 판매/입고 이력을 함께 저장한 이유
Inventory를 중심으로 한 관계 설계

결국 이번 프로젝트에서 보여주고 싶은 것은 “편의점 시스템을 완벽하게 구현했다”는 것이 아니다. 짧은 기간 안에서도 편의점 운영 흐름을 이해하고, 그 흐름을 데이터와 도메인 모델로 옮겨보려 했다는 점이다.

시리즈 이어보기
전체 글 목록 | 다음 글: 2. POS/PDA/고객 앱/관리자 WEB을 잇는 도메인 설계

참고