WMS 프로젝트

Teru·2025년 7월 23일

회고

[박건희]

WMS 개발을 하면서 처음에는 단순히 물류 흐름만 생각했지만, 진행하면서 창고는 결국 공간과 물건의 상태를 관리하는 것이 핵심이라는 걸 깨달았습니다. 물건의 크기와 적재 공간, 보관 온도 같은 물리적 조건까지 데이터로 관리해야 효율적인 창고 운영이 가능하다는 걸 배웠습니다.
처음에는 5명이서 시작했지만 팀워크가 잘 맞지 않아 의사소통이 어렵고, 회의 자체를 어려워하는 사람도 있었으며, 자기가 맡은 파트만 하겠다는 사람도 있어 프로젝트의 흐름을 하나로 맞추기가 힘들었습니다. 그래서 완성도 높은 결과물을 내기 어려웠고, 최종 시연도 어려운 상황이었습니다. 그런데 팀원이 3명으로 줄고 나서는 인원이 줄어서가 아니라 협력하고자 하는 적극적인 팀원만 남아 있었기 때문에 오히려 서로 잘 맞고 목표를 공유하며 프로젝트가 훨씬 잘 진행되었습니다. 그 과정에서 진짜 중요한 건 팀원 수가 아니라 협력하려는 자세라는 걸 배웠습니다.
협업할 때 문서화가 얼마나 중요한지 이번 프로젝트를 통해 확실히 깨달았습니다. 처음에는 기억에만 의존해도 괜찮을 줄 알았지만, 프로젝트 후 2달 뒤 다시 모여 리팩토링을 하려다 보니 문서화되지 않은 부분은 거의 기억이 나지 않아 막막했습니다. 다행히 저희는 모든 과정을 실무 단계에 맞춰 산출물로 정리하고, 기능 흐름도, 테이블 정의서, API 명세 등을 단계별로 문서화해두었기 때문에 다시 코드를 처음부터 확인하지 않고도 빠르게 업무 흐름을 파악하고 리팩토링을 완성할 수 있었습니다. 이 경험을 통해 문서화가 협업과 유지보수에서 얼마나 중요한지 체감했고, 앞으로도 어떤 프로젝트든 반드시 실천해야겠다고 다짐했습니다.
프론트엔드에서는 헤더, 푸터, 네비게이션처럼 반복되는 구조가 많은데, 이 프로젝트 초반에는 그런 공통 요소를 하나로 묶지 않고 각각의 페이지에 따로 작성했습니다. 그래서 나중에 페이지를 추가하거나 수정할 때마다 모든 페이지를 일일이 수정해야 하는 비효율이 발생했습니다. 결국 공통 레이아웃으로 묶어 문제를 해결했고, 다음 프로젝트에서는 처음부터 레이아웃 구조를 먼저 만들어 확장성과 유지보수성을 높였습니다.
처음에는 그냥 머릿속으로만 ERD를 설계했는데, 그렇게 하다 보니 수정이 반복되면서 거의 8번이나 수정하게 됐습니다. 특히 재고, 입고, 출고처럼 서로 연결되는 테이블에서는 데이터 관계가 꼬여서 문제가 많이 발생했어요. 그런데 나중에 더미 데이터를 직접 만들어 넣어보니까 어디서 문제가 발생하는지 바로 확인할 수 있었고, 설계도 훨씬 쉽게 수정할 수 있었습니다. 이 경험을 통해 ERD를 만들 때는 반드시 더미 데이터를 함께 만들어 실제 데이터 흐름까지 검증해야 한다는 걸 배웠습니다.

[고윤아]

사용자 정보와 보안에 대한 인식 변화 CLI 환경에선 보안 이슈를 크게 느끼지 못했지만, 웹 기반 시스템으로 전환되며 로그인, 권한 분리, 데이터 노출 방지 같은 보안 요소의 중요성이 두드러지게 드러났다.Spring Security를 활용해 인증·인가 구조를 직접 구성하면서, 웹 서비스에서의 보안 설계는 선택이 아닌 필수라는 사실을 체감했다.
데이터 구조 설계의 중요성 초기에는 백엔드 로직만 처리하면 충분하다고 생각했지만, 실제로는 프론트엔드에 정확하고 구조화된 데이터를 넘기는 일이 더욱 중요했다.API 명세 작성과 DTO 설계를 반복하며, 프론트와의 데이터 교환을 염두에 둔 설계 역량이 핵심임을 깨달았다.
스프링 프레임워크에 대한 구조적 이해 부족 처음엔 Spring Boot의 편리함에만 의존했지만, 점점 더 복잡한 기능을 구현하면서 프레임워크 내부 동작 원리에 대한 궁금증이 커졌다.이에 따라 Spring MVC 흐름, DispatcherServlet, 빈 생명주기 등을 학습했고, 프레임워크를 사용하는 개발자에서 이해하고 설계하는 개발자로 성장할 수 있었다.
비어 있는 지식을 메꾸는 자기주도 학습 기본적인 교육만으로는 실무에서 마주치는 다양한 상황을 모두 커버하기 어려웠다.부족한 개념이나 생소한 라이브러리는 스스로 문서를 찾아 정리하고, 실제 코드에 적용하며 학습을 체계화했다.이를 통해 문제를 만났을 때 주도적으로 해결할 수 있는 기반을 마련했다.
문서화를 기피했던 과거에서의 전환 처음엔 매번 문서를 작성하는 일이 번거롭게 느껴졌지만, 점차 기록이 쌓일수록 팀 내 정보 격차를 줄이고, 의사결정의 기준을 명확히 하는 데 큰 도움이 되었다.정형화된 템플릿을 활용해 문서를 작성하면서, 지식의 공유와 프로젝트 회고가 쉬워졌다는 점을 직접 경험했다.

[최문규]

첫 팀 프로젝트를 시작할 당시, 팀원들은 Git과 GitHub에 대한 이해도가 낮아 단순히 버전 관리를 위한 툴 정도로만 알고 있었습니다. 그러다 보니 팀원 간 브랜치 충돌, 코드 병합 실수, 서로 다른 커밋 메시지 등의 문제가 발생해 개발 효율이 떨어지는 문제가 발생했습니다. 이를 해결하기 위해 저는 Git 학습을 통해 팀 내에 Git Flow 전략을 도입했습니다. 브랜치 전략, 커밋 메시지 컨벤션, PR 템플릿, Git 사용 흐름 등의 내용을 정리해 공유했습니다. 단순히 문서를 공유하는데 그치지 않고, 회의를 통해 팀원들에게 전략의 목적과 운영 방식을 설명했고, 이후 전원이 동일한 기준으로 작업하면서 협업 효율이 향상되었습니다. 서로의 지식을 정리하고 공유하며 설명하는 과정을 통해, 팀원 간 이해도가 높아지고 자연스럽게 시너지 효과가 생겼습니다. 그 과정에서 '공유의 문화'가 협업에서 얼마나 중요한지 실감했습니다.
WMS 창고관리시스템 프로젝트 진행시 스프링 부트가 아닌 순수 스프링 환경에서 개발을 진행했습니다. 자동 설정이 제공되지 않아 웹 설정, Bean 등록, 의존성 주입 등 많은 요소를 수동으로 구성해야 했고, 이를 통해 스프링 프레임워크의 핵심 개념에 대한 이해가 필요하다는 사실을 깨달았습니다. 관련 도서인 『전문가를 위한 스프링5』를 구매해 학습했습니다. DI, IoC 컨테이너, AOP 외 스프링의 실행 흐름, 개념을 학습하며 작동 원리를 정리하며 학습했습니다. 이후 진행한 스프링 부트 기반 프로젝트에서는 스프링의 원리를 이해하고 어떤 편리성을 제공하는지 파악할 수 있었습니다. 이 경험을 통해 저는 프레임워크를 단순히 “쓰는 것”에 그치지 않고, 그 구조와 원리를 이해하려는 태도가 전문성을 높이는 핵심이라는 것을 배웠습니다.

Ⅰ.프로젝트 개요

기획 배경

1. 건강 식품에 대한 소비자 수요 증가

최근 건강을 중시하는 식습관이 확산되면서, 고단백·저당·글루텐프리 등 건강 지향 간식에 대한 수요가 증가하고 있다.

그러나 기존 도넛 시장은 여전히 고열량 중심으로 구성되어 있어, 건강까지 고려한 프리미엄 도넛 브랜드의 필요성이 부각되고 있다.

이에 따라 맛과 건강을 모두 만족시키는 새로운 도넛 시장의 가능성이 주목받고 있다.

2. 왜 도넛이어야 했는가 – 유통 특성과 시스템화의 적합성

도넛은 완제품 단위로 유통되며 유통기한과 보관 조건이 중요한 제품이기 때문에, 정밀한 재고 추적이 필수적이다.표준화된 생산과 납품 구조를 가지고 있어 자동화 시스템 적용에 적합하며,이에 따라 도넛은 WMS 설계와 구현에 실용적인 품목으로 적절하다.

3. 중앙 집중형 물류 관리 시스템의 중요성

글로벌 식품 브랜드들은 WMS를 통해 바코드 입출고, 유통기한 알림, 자동 발주 등 물류를 IT 기반으로 통제하고 있다.Prokin’ Donuts도 초기 단계부터 중앙 집중형 WMS를 도입해 확장성과 실시간 재고 관리를 동시에 실현하고자 한다.

4. 프로젝트 개발의 실무적 가치

팀 Donut은 건강한 도넛 브랜드 ‘Prokin’ Donuts’를 위한 통합 창고 관리 시스템

을 자체 개발하며, 자동화된 재고 관리와 실제 물류 환경 적용을 목표로 했다.단순 CRUD를 넘어 Spring MVC, 정규화 DB, 권한 인증, 바코드 등 실무 중심 기술 스택

을 적용했으며, GitHub·Notion·ERD cloud 기반의 협업과 문서화 도 함께 수행했다.

Ⅱ.목표

가맹점 중심의 발주 시스템 구현 점포별 발주 요청 → 창고 관리자 승인 → 출고까지 이어지는 전산화된 물류 흐름 구축
권한별 업무 분리 및 사용자 인증 처리 본사·창고·가맹점 역할을 구분하고, Spring Security 기반 인증·인가 기능 직접 구현
웹 기반 창고 관리 자동화 입출고 이력 관리, 창고별 재고 현황 확인 등 핵심 업무를 웹에서 처리할 수 있도록 시스템화
바코드 기반 재고 식별 시스템 도입 창고 내 자산(재고, 위치 등)에 대해 바코드 생성 → 실물 스캔만으로 DB 정보 조회 및 입출고 처리 가능

Ⅲ.협업전략

NOTION : 산발적으로 관리되던 문서를 Notion으로 통합해 최신 버전 관리와 협업 효율을 크게 높였습니다.

초기에는 슬랙, 구글 드라이브, 블로그 등으로 문서를 공유했지만 최신 버전 관리가 어려워 협업 효율이 떨어졌습니다. 문서가 여러 곳에 분산되고 가독성도 낮아 중요한 산출물을 찾는 데 시간이 많이 걸렸습니다. 이를 해결하기 위해 Notion을 도입하여 모든 문서를 최신 상태로 통합 관리하고, 표와 링크, 파일 첨부 등 협업 기능을 적극 활용했습니다. 덕분에 누구나 최신 버전을 쉽게 확인하고 공유할 수 있게 되었고, 자료 검색과 커뮤니케이션 과정이 크게 간소화되었습니다. 결과적으로 Notion이 협업의 중심 허브가 되어 문서 관리 및 공유 효율이 크게 향상되었습니다.

회의록 : 애자일 스크럼과 Notion으로 일정을 공유해 협업 효율과 개발 완성도를 높였습니다.

초기에는 각자 맡은 파트만 관리해 내 작업이 전체 작업 흐름상 어느 위치에 있는지 알기 어려웠습니다. 그래서 필요할 때마다 다른 팀원에게 진척도를 직접 물어보고 일정을 맞춰야 했고, 데드라인 관리나 우선순위 조정이 번거로웠습니다. 이를 개선하기 위해 애자일 스크럼 방식을 도입해 매일 회의에서 WBS 기반 전체 일정을 확인하고 이슈와 앞으로 할 일을 공유하며 작업 일정을 조율했습니다. 회의 내용과 마일스톤 계획은 Notion에 기록해 모두가 같은 기준으로 일정과 목표를 관리했습니다. 그 결과 협업 과정이 효율적으로 정리되고, 전체 개발 속도와 완성도가 높아졌습니다.

GITHUB : 브랜치 전략과 커밋 규칙을 정해 Git 관리 효율과 협업 품질을 높였습니다.

초기에는 main, dev 정도만 구분하고 브랜치나 커밋 메시지를 각자 알아서 작성해, 어떤 작업인지 명확히 알기 어려웠습니다. 브랜치 이름과 커밋 메시지가 제각각이어서 PR 승인 시에도 변경 내용을 파악하는 데 시간이 오래 걸렸습니다. 이를 개선하기 위해 작업 목적별로 브랜치 이름을 구분하고, 커밋 메시지 형식을 통일해 개발 내용을 명확히 드러냈습니다. 브랜치 전략과 커밋 규칙을 정한 후에는 누구나 작업 내용을 쉽게 이해하고, PR 검토 및 승인 과정이 간결해졌습니다. 결과적으로 Git 관리 효율이 높아지고 코드 리뷰 및 협업 품질이 향상되었습니다.

이슈 공유 : GitHub 이슈로 문제와 해결 과정을 공유해 반복 이슈를 줄이고 협업 효율을 높였습니다.

프로젝트 초반에는 발생한 문제를 구두나 개인 메모로만 공유해 팀원 간 동일한 이슈가 반복 발생하고, 해결 방법도 일일이 전달해야 하는 비효율이 있었습니다. 이를 개선하기 위해 GitHub 이슈를 도입해 발생 원인과 해결 과정을 기록하고 공유했습니다. 그 결과 누구나 이전 이슈와 해결책을 쉽게 찾아볼 수 있어 반복되는 문제를 빠르게 해결하고, 팀 전체의 문제 해결력과 협업 효율이 높아졌습니다.

Ⅳ.기술스택 및 개발환경

Ⅴ.Prokin’ Donuts WMS 프로세스

1) 창고

창고 수: 전국 2개 (남양주, 대전)
구조: 창고당 3개의 보관 섹션으로 구성됨
- 냉장(010℃), 냉동(-18℃ 이하), 실온(135℃)
입고 단위: 품목당 1,000개
창고 용량 분배 비율:
- 냉장 60% / 냉동 20% / 실온 20%
등록 방식:
- 창고 등록 시 안전재고 기준을 설정함 (전월 출고량의 20%)

2) 제품 및 재고

제품 분류 체계:
- 대분류 > 중분류 > 품목
- 예) 도넛 > 저당 도넛 > 저당 초코 도넛
보관 온도에 따른 입출고 규정:
- 냉장: 1주 전부터 정정 불가
- 냉동: 2일 전부터 정정 불가
- 실온: 1일 전부터 정정 불가
입출고 단위:
- 입출고는 품목 단위
- 재고는 섹션 수용 가능 수량을 초과할 수 없음

3) 발주 및 입출고 프로세스

발주 요청 주체: 점주(Franchise Manager, fm)
발주 요건:
- 수도권: 하루 100개 이상
- 비수도권: 하루 50개 이상
처리 흐름:
1. 점주 발주 요청
2. 본사(HQ, hq)가 오후 2시 발주 승인
3. 창고 관리자(WM, wm)가 오후 4시 요청서 확인
4. 재고 확인 후 승인 or 본사에 입고 요청
5. 본사 오후 3시 입고 요청 일괄 승인
6. 입고 → 바코드 부여 → 출고
처리 상태:
- 처리대기중 | 승인 | 반려 (입고/출고 동일하게 사용)

4) 권한 및 사용자 구분

구분	명칭	설명
본사 관리자	HQ	전체 발주 승인 및 입고 승인 담당
창고 관리자	WM	창고 1개 전담, 재고/입출고 담당
점주 (가맹점)	FM	발주 요청, 재고 확인 주체