WMS(창고 관리 시스템) 프로젝트

프로젝트 개요

신세계 I&C JAVA 기반 벡엔드 개발자 양성 과정 프로젝트

 

WMS(창고 관리 시스템)란?

• 제품이 입고되어 적재되는 것.
• 재고가 선택되어 출하되는 과저에서 실시간으로 재고 수준과 위치를 추적하여 창고 공간을 최대한 활용하도록 관리 및 자동화하는 시스템

📽️프로젝트 소개📽️

• Effitopia는 B2B 창고 관리 시스템(WMS) 개발 프로젝트 입니다. 창고 내 재고를 효율적으로 관리하고, 입고부터 배송까지 신뢰성 있는 물류 운영을 지원하는 WMS(창고 관리 시스템)의 이상향을 실현하는 것을 목표로 하였습니다.
• This is our page : 팀명 'TOP'는 'This is Our Page'의 약자입니다. 직역하면 '우리의 페이지'라는 의미로 이 이름에는 프로젝트를 통해 겪게 될 수 많은 우여곡절과 기쁨을 추억의 한 페이지로 기록하겠다는 의미가 담겨 있습니다. 최근 자주 듣던 데이식스의 곡 '한 페이지가 될 수 있게'의 가사인 'This is our page'가 문득 떠올랐습니다. 또한, 이번 프로젝트의 산출물로 웹 페이지를 구현해야하는데 이 웹 페이지도 '우리의 페이지'라는 의미를 함께 내포하고 있습니다. 그리하여 팀원들과 의견을 나누면서 끝에 'TOP'라는 이름이 탄생하게 되었습니다. 이는 우리의 노력과 열정을 담아낸 하나의 페이지로, 앞으로도 프로젝트를 진행하면서, 교육과정을 진행하면서의 순간을 우리의 마음속에 한 페이지에 추억할 것입니다. 
• Effitopia : 효율성을 의미하는 'Efficieny'와 이상향을 의미하는 'Utopia'의 합성어입니다.

https://github.com/bottomsUp-99/top-wms

GitHub - bottomsUp-99/top-wms

🗓️프로젝트 일정🗓️

간트 차트

🧑‍🤝‍🧑개발 팀🧑‍🤝‍🧑

@kinggora (팀장👸)	@bottomsUp-99 (팀원👨‍✈️)	@HongYong-Woo (팀원💁‍♂️)	@PARK-TH (팀원👨‍⚖️)	@qeeeeeqeqq (팀원🧑‍💼)
로그인/회원 관리 재무 관리 대시 보드	출고 관리 차량 관리 안전점검	재고 관리 고객 센터	입고 관리 거래처 관리	창고 관리 계약 관리

 

⚒️개발 환경⚒️

• JAVA version : Java 17 JDK
• IDE : IntelliJ IDEA Ultimate
• Framework : Spring Boot 3.0.1, Spring Security 6
• Database : MySQL 8.0.21, MyBatis, Spring Data Redis
• Library : Thymeleaf, Bootstrap
• Tools : GitHub, Notion, Slack

📦프로젝트 구조📦

effitopia
 ┣ 📂config
 ┣ 📂controller
 ┣ 📂formatter
 ┣ 📂domain
 ┣ 📂dto
 ┣ 📂enumeration
 ┣ 📂exception
 ┣ 📂mapper
 ┣ 📂security
 ┗ 📂service

 

🔭주요 기능🔭

• 로그인 / 회원 관리
• 창고 관리
• 입고 관리
• 출고 관리
• 재고 관리
• 재무 관리
• 재무 관리
• 고객 센터
• 안전 점검

 

🔎커밋 메세지 컨벤션🔎

Commit Type Gitmoji
- 🐛 bug: 버그 수정
- ✨ sparkles: 새로운 기능 도입
- 🔥 fire: 코드나 파일 삭제
- 📝 memo: 문서 추가 또는 업데이트
- 🎨 art: 코드의 구조/형식 개선
- 🚧 construction: 작업 진행 중
- 🎉 tada: 프로젝트 시작
- ✅ white_check_mark: 테스트 추가, 업데이트 또는 통과
- 🔧 wrench: 설정 파일 추가 또는 업데이트
- 📦️ package: 컴파일된 파일이나 패키지 추가 또는 업데이트
- ♻️ recycle: 코드 리팩토링

 

🔎네이밍 컨벤션🔎

PascalCase	자바 클래스	ex) OutboundStatus
camelCase	변수, 메서드	ex) outboundStatus
snake_case	데이터베이스 테이블, 컬럼명	ex) outbound_status
kebab-case	디렉토리, HTML 파일명, URL 경로	ex) outbound-status

 

⚙️개발 가이드⚙️

1. 컨트롤러 : 요청 파라미터 유효성 검증, 서비스 호출, 예외 처리
   • DTO Bean Validation Annotation + @Valid 사용
   • 커스텀 필요시 Validator 구현하여 사용
2. 서비스 : 비지니스 로직 관련 유효성 검증, 비지니스 로직 수행, 비지니스 예외 throw
3. 메서드는 가능한 작게 만든다.<- 삭제 한 개의 메서드는 하나의 기능만 가지도록 설계
4. 변수명, 메서드명은 기능을 표현하도록 네이밍 (무의미한 이름 X)
5. 특히 메서드는 캡슐화하여 따로 모듈로 사용할때 알 수 있도록 메서드명을 네이밍
6. 예외 처리에서 ErrorCode는 프런트에 보낼 메세지, 로그는 서버에 남기는 메세지 (System.out.println XX)
7. 접근 제어자: 모든 변수 private, 상수는 기능에 따라 설정, 메서드는 외부에서 사용하는 경우 public, 내부에서만 사용하는 경우 private
8. 사용자 화면(브라우저)에 IDE에 뜨는 생소한 예외 메세지가 출력되지 않도록 예외 처리
   • 커스텀 에러 페이지, alert(사용자 에러 메세지), redirect…
9. 주석은 꼭!! 필요한 내용만 기입
10. 각 class들은 독립성을 추구 할 수 있도록 외부 연관관계를 최소화
11. 서비스는 확정성을 위해 interface를 사용

👨‍💻내가 구현한 기능👨‍💻

1. 출고 관리(출고, 배차, 운송장)
2. 안전 점검

🚛출고관리🚛

• 출고관리란, WMS(Warehouse Management System, 창고관리 시스템)의 핵심 기능 중 하나로, 창고에서 재고를 출고하는 과정을 효율적으로 관리하는 기능을 의미합니다. 출고관리는 고객 주문, 출고 지시서, 화물 차량 배차, 운송 준비 등 다양한 과정을 포함하며, 재고가 창고에서 실제로 출하되기까지의 모든 과정을 관리합니다.
• 출고에서의 기본 플로우
  1. 주문 수량과 재고 수량 비교하여 출고 요청을 통해 하나의 출고 지시서가 만들어진다.
  2. 요청된 출고 지시서를 출고 현황 리스트에서 조회 가능하다.
  3. 하나의 출고 지시서를 클릭하여 상세 내용을 확인이 가능하다.
  4. 아직은 배차가 등록 되지 않은 상태이므로 출고 상태는 미승인으로 되어 있다. 배차가 승인이 되면, 출고 상태를 승인으로 변경이 가능하며, 출고 상태가 승인이 되면 운송장이 자동으로 등록되게 된다.

• 기획
  
  • 우선 회원(사업자)이 주문자의 요청에 따라 구매자의 주문 정보를 입력한다. 구매자의 이름을 입력하고 Daum우편 번호 서비스를 통해 우편번호, 도로명 주소, 지번 주소를 자동으로 입력 받게 되며 , 상세 주소까지 입력한다. 그렇게 주소를 모두 입력하게 되면 오른쪽에 주문자의 위치가  KAKAO MAP에 뜨게 된다.
  • 그 후, 상품명을 입력하여 원하는 출고할 상품의 위치랑 수량을 특정하여 입력한다. 이때 출고하려는 상품의 수량이 재고 수량보다 더 많다면 오류창으로 수량이 너무 많다고 알려준다. 그리고 '출고 요청하기' 버튼을 통해 출고 요청을 할 수 있다. 이렇게 만들어진 하나의 출고건은 '출고 지시서'라고 칭한다.
  • 이렇게 출고 요청 된 정보들은 '출고 현황'에서 확인이 가능하다. 출고 현황에서는 지금까지 요청된 모든 출고 지시서들을 리스트 형태로 확인 가능하다.
  • 리스트에서 보여지는 정보에는 출고 요청을 한 회원의 아이디, 상품명/브랜드, 상품 수량, 배차 상태, 출고 상태, 운송장 상태가 있다. 그리고 이 위에는 필터링 검색 조건이 있는데, 이 조건에는 지역, 상품명, 시작 날짜와 종료 날짜를 통한 기간 조회, 출고 상태 별로 조회가 가능하다.
  • 이 리스트 중에 하나의 지시서를 클릭하게 되면 '출고 지시서 상세 내용'으로 이동하게 된다. 여기에서는 해당 출고 지시서에 대한 모든 자세한 내용을 확인이 가능하다. 확인 가능한 내용으로서는 출고 정보, 배차 정보 운송장 정보가 확인이 가능하다.
  • 여기서 이제 해당 상품의 보관 타입(상온, 냉장, 냉동)에 따른 배차 차량을 선택하여 배차를 지정할 수 있다. 이렇게 하면, 배차 상태가 승인에서 미승인으로 변경되고, 출고 상태도 미승인에서 승인으로 변경가능하다.
  • 출고 상태가 승인으로 변경되면 운송장은 자동으로 등록되며, 운송장 상태는 미승인 -> 배송 중 -> 배송완료 순으로 변경된다.

• 기능
  • 출고 요청 : 회원(사업자) 출고 요청
  • 출고 요청 승인 : 총관리자, 창고 관리자는 출고 요청 내용을 확인하고 배차가 등록된 경우에 대해서만 출고 요청 승인
  • 출고 지시서 리스트 조회 : 총관리자, 창고관리자, 회원, 배송기사는 출고 지시서 전체 및 필터링(특정 단어, 기간 조회, 출고 상태) 조회 가능
  • 출고 지시서 조회 : 출고 지시서 리스트 조회를 통해 하나의 출고 지시서에 대한 상세 내용(출고&배차&운송장 정보) 확인 가능
  • 출고 지시서 수정 : 배차가 아직 지정되지 않은 경우, 출고 요청의 내용을 수정 가능
  • 출고 지시서 반려 : 배차가 아직 지정되지 않은 경우, 출고 상태를 반려로 변경 가능(삭제는 불가능 - 기존 WMS 플로우 상 부적절하다고 함)
  • 배차 조회 : 출고 지시서 상세 내용을 통해 해당 출고 건에 대한 운송장 정보 조회 가능
  • 배차 등록 : 출고 승인 이루어지지 않은 건에 대하여 새로운 배차 정보를 등록
  • 배차 수정 : 출고 승인 이루어지지 않은 건에 대하여 기존 배차 정보를 수정
  • 배차 취소 : 출고 승인 이루어지지 않은 건에 대하여 기존 배차 정보를 취소
  • 운송장 등록 : 출고 요청 승인이 이루어지면, 자동으로 운송장이 등록된다.
  • 운송장 조회 : 운송장 조회라는 기능은 없지만, 출고 지시서 상세 내용을 통해 해당 출고 건에 대한 운송장 정보 조회 가능
• 유스 케이스 다이어 그램

출고 유스케이스

• 플로우 차트

출고 플로우 차트

• ERD

출고 ERD

• Figma

•  시연영상
  • https://www.youtube.com/watch?v=GdDujOxOLRc

 

 

👷‍♂️안전점검👷‍♂️

• WMS(Warehouse Management System, 창고관리 시스템)의 핵심 기능 중 하나로, 안전점검(Safety Inspection) 기능은 창고 내에서 이루어지는 다양한 작업 환경과 설비의 안전성을 관리하고 사고나 문제 발생을 예방하는 데 중점을 둡니다. 이 기능은 창고의 작업자가 안전하게 작업을 수행할 수 있도록 하고, 재고나 설비에 손상이 발생하지 않도록 지속적인 점검 및 관리를 자동화하는 중요한 역할을 합니다.
• 안전점검 기본 플로우
  1. 안전 점검 작성 버튼을 통해 새로운 안전점검을 작성할 수 있다.
  2. 총 11가지의 질문에 대해 상태 체크를 하고, 마지막으로 추후 조치사항을 기입할 수 있다.
  3. 그렇게 완성된 안전점검은 다시 안전 점검 리스트에서 확인이 가능하다.
  4. 안전점검 리스트에서는 지금까지 작성된 모든 안전점검의 내용이 리스트 형태로 조회가 가능하며, 창고 코드&관리자 아이디&기간조회를 통해 필터링 검색을 할 수 있다.

• 기획
  
  • 안전점검은 창고와 창고에 보관되고 있는 상품들의 최고의 상태와 품질을 유지함에 있어서 중요한 내용이므로 이에 관련된 것들로 질문을 만들었다.
  • 질문은 총 11가지로서, 아래와 같다.
    1. 모든 소화기가 적절한 위치에 비치되어 있고, 사용 가능한 상태입니까?
    2. 스프링 쿨러 시스템이 정상적으로 작동하고 점검일자가 유효합니까?
    3. 화재 경보 시스템이 작동 상태이며, 점검이 완료되었습니까?
    4. 전기 배선이 안전하게 설치되어 있고, 과부하나 손상된 부분이 없습니까?
    5. 비상 전원 시스템이 정상적으로 작동하며, 정기적인 점검이 이루어졌습니까?
    6. 안전 보호구(헬멧, 장갑 등)가 적절한 상태로 비치되어 있고, 직원들이 이를 착용하고 있습니까?
    7. 구급 장비가 완비되어 있으며, 사용 기한이 유효합니까?
    8. 온도 및 습도 조절기가 정상적으로 작동하며, 설정 범위 내에서 유지되고 있습니까?
    9. 물막이 장치 및 배수 시스템이 손상 없이 정상적으로 작동하고 있습니까?
    10. CCTV 시스템이 정상적으로 작동하며, 모든 영역이 모니터링되고 있습니까?
    11. 출입 보안 시스템이 적절하게 설정되어 있고, 출입 기록이 관리되고 있습니까?
  • 이러한 질문에 대해 모두 양호 혹은 불량으로 체크를 하고 추후 조치사항을 기입하여 하나의 안전점검을 작성한다.
  • 이렇게 작성된 안전점검들을 리스트 형태로 확인 할 수 있다. 리스트 형태에서 보여지는 정보는 창고 코드, 관리자 아이디, 조치사항, 안전 점수(양호 체크 수 / 11), 점검 날짜이다.
  • 또한, 리스트에서 하나를 선택하면, 해당 안전점검에 대한 상세 정보를 확인할 수 있다.

• 기능
  • 안전점검 등록 : 창고 별 안전점검 실시 내용 등록
  • 안전점검 내역 조회 : 안전 점검 내역 전체 및 창고별, 관리자별, 기간별 조회 가능
  • 안전점검 내역 수정 : 안전점검 했던 내역 중 추후 조치사항을 수정 가능
  • 안전점검 내역 삭제 : 안전점검의 기록은 삭제 할 수 없음.
  • 추후 조치 사항 : 후속 조치 및 필요 조치 사항 별도 기입 가능
• 피그마

안전점검 리스트

안전 점검 작성

안전 점검 상세 내용

🔧Refacotoring🔧

• 차량 관리 CRUD(온도별 차량 타입)
• 동시성 제어가 필요한 부분
  • 재고 초과 할당 문제 : 여러 사용자가 동시에 동일한 제품에 대해 출고 요청을 할 경우, 재고보다 많은 수량을 출고하려는 시도가 발생할 수 있다. 이를 방지하지 않으면 재고 초과 할당 문제가 발생하여, 시스템에서 재고가 부족한데도 출고가 이루어지는 상황이 생길 수 있다.
  •  중복 출고 문제 : 같은 제품이 여러 출고 요청에서 동시에 처리될 경우, 중복 출고가 발생할 수 있다. 예를 들어, 두 개의 출고 지시서가 동시에 생성되고, 이들이 같은 재고를 참조할 때 중복 출고가 발생하여 고객에게 중복된 제품이 배송될 가능성이 있다.
  • 재고 감소의 순서 문제 : 출고 작업이 여러 개 동시에 진행될 때, 재고 감소가 올바른 순서로 처리되지 않으면 재고 데이터가 불일치할 수 있다. 예를 들어, A 출고 요청이 B 요청보다 먼저 처리되어야 하지만, 시스템의 동시성 문제로 순서가 뒤바뀌어 B가 먼저 처리되는 상황이 발생할 수 있다.
  • 피킹 작업의 충돌 : 피킹 작업은 작업자가 창고에서 물품을 실제로 꺼내는 작업이다. 동시에 여러 작업자가 같은 상품을 피킹할 경우 피킹 충돌이 발생할 수 있으며, 이는 물리적 문제나 재고 관리 문제로 이어질 수 있다.

🔚마무리 및 느낀 점🔚

• 개인적으로 정말 아쉬움이 많이 남은 프로젝트였다. 서버 측에서 페이지를 렌더링 한다는 의미이며, 서버에서 브라우저에 보일 HTML 파일을 미리 준비해서 응답해 주는 형식인 SSR을 활용하여 web 페이지까지 제작을 하였다. 평소에도 기획에 관련한 직업을 희망하였기에, 이번 기회에 좀 더 기획에 집중을 해보았다. 상세 기능 정의서부터 UX를 고려한 UI까지 정말 섬세하고 깊게 팀원들과 논의하면서 프로젝트를 구상했다.
• 그렇지만 데이터들을 파싱해서 프론트로 띄우는 것이 처음이다 보니 오류를 정말 수도 없이 만난 것 같다. 벡엔드와 프론트를 연결하는 구현 과정에서 소요된 시간 중 반 이상이 오류를 해결하는데 쩔쩔맸던 것 같다. 그래도 오류를 해결하고 났을 때는 기분이 좋았다. 내가 생각하고 기획했던 대로 데이터가 뿌려지고 화면이 렌더링 되는 과정은 내게 있어서 정말로 뿌듯하고 재밌었다.
• 그리고 이번에는 Spring Boot의 MVC 패턴을 활용하여 웹 애플리케이션을 구조화하였다. 아래는 내가 몸소 느꼈던 장점들이다.
  1. 구조적 분리로 인한 유지보수성 향상 : Model, View, Controller가 각각의 역할로 명확하게 분리되어 있어, 비즈니스 로직과 프레젠테이션 로직이 섞이지 않게 하였다.
  2. 효율적인 개발 및 코드 관리 : 개발을 빠르고 쉽게 설정할 수 있도록 기본적인 설정과 의존성을 제공하고 있기에 기본 설정으로도 바로 MVC 패턴을 사용할 수 있으며, 필요에 따라 쉽게 커스터마이징이 가능하다. 예를 등어, Controller는 요청을 처리하는 핵심 비즈니스 로직에 집중하고, View는 화면 출력에만 신경 쓰기 때문에 각 역할이 명확히 나뉘어 코드 관리가 용이하였다.
  3. 테스트 용이성 : MVC 패턴에서는 각 부분이 분리되어 있기 때문에 단위 테스트를 작성하기가 용이하였다.
  4. 간결하고 유연한 요청 처리 : @RequestMapping, @GetMapping, @PostMapping 등 다양한 애노테이션을 사용하여 HTTP 요청을 Controller에서 간결하게 처리할 수 있었다. 또한, @ModelAttribute, @PathVariable, @RequestParam 등의 애노테이션을 사용하여 요청 파라미터를 쉽게 추출하고 바인딩할 수 있어 요청 처리의 유연성이 높았다.
• 또한, Mybatis를 처음 사용해보는 것이었지만 join이 많은 경우에 resultmap을 복잡하게 하는 거 말고는 굉장히 유익했던 것 같다. 아래는 내가 몸소 느꼈던 장점들이다.
  1. 코드의 간소화 및 생산성 향상 : DAO 클래스를 따로 만들지 않으면, 개발 단계에서 반복적으로 DAO 계층을 작성할 필요가 없어졌다. 이전에서의 프로젝트에서는 DAO 패턴에서 데이터베이스와 상호작용하기 위해 각 테이블 또는 엔티티별로 DAO 클래스를 만들어야 하며, 각 메서드에서 SQL 쿼리를 작성하거나 호출했었다. MyBatis는 Mapper 인터페이스와 XML 파일 또는 어노테이션을 통해 쿼리를 정의하고 호출할 수 있으므로, DAO 계층을 생략하고 바로 데이터베이스 쿼리를 실행할 수 있다는 장점이 있다. 매퍼 인터페이스 자체가 쿼리 메서드의 정의 역할을 하며, MyBatis가 이를 자동으로 매핑하고 처리하므로 중간의 DAO 계층이 불필요해졌다.
  2. Mapper 인터페이스로 데이터 접근 간편화 : MyBatis Mapper 인터페이스는 기본적으로 자동으로 동작하는 DAO 역할을 수행하는데, @Mapper 애노테이션을 붙이면 Spring과 통합할 경우 MyBatis는 해당 인터페이스를 기반으로 자동으로 매퍼 인스턴스를 생성하고, 데이터베이스와 상호작용할 수 있었다. DAO 클래스를 직접 구현할 필요 없이 Mapper 인터페이스만 정의하면 되므로, 코드가 더 간결하고 개발 속도가 빨라졌던 것 같다.
  3. 간단한 유지보수 : MyBatis는 SQL을 직접 XML 파일에 명시적으로 작성하거나 어노테이션으로 구현할 수 있기 때문에, DAO 클래스에서 구현한 여러 메서드를 별도로 관리하지 않아도 된다. 코드 유지보수가 간단해지며, SQL 쿼리를 수정하거나 확장해야 할 때 Mapper 인터페이스나 XML 파일을 수정하는 것만으로 처리가 가능하여 변경이 수월해서 굉장히 수월했던 것 같다.