CONNECT GOOD, VALUE CHAIN
CHAIN-G는 떡볶이 밀키트의 생산부터 유통, 가맹점 판매 및 정산까지의 전 과정을 효율적으로 관리하는 공급망 관리(SCM) 시스템입니다.
본사, 가맹점, 공장 세 주체 간의 유기적인 발주, 재고 관리, 물류 배차 및 정산 프로세스를 자동화합니다.
 |
 |
 |
 |
 |
|---|---|---|---|---|
| 김채우 | 김성은 | 김윤경 | 유찬연 | 조윤호 |
| Order / Sales / Return |
User / BusinessUnit / Notice / Notification |
Settlement | In&Outbound / Transport |
Inventory / Product |
| @chaewoo-kim | @rlatjddms | @kyk5095 | @Yoocy0 | @cho-yunho01 |
| Category | Stack |
|---|---|
| Language | Java 21 |
| Framework | Spring Boot 3.2.2 |
| Persistence | Spring Data JPA, MySQL 8.x |
| Build Tool | Gradle |
| Testing | JUnit 5, AssertJ, JaCoCo (Line Coverage 80% 이상 준수) |
| CI/CD & Tools | SonarQube, Lombok, GitHub Actions |
본 프로젝트는 유지보수성과 확장성을 위해 멀티 모듈 아키텍처를 채택하고 있으며, 도메인 중심 설계(Domain-Driven Design)를 지향합니다.
module-core: 시스템 전반에서 공통으로 사용되는 유틸리티, 예외 처리, 공통 응답 규격을 포함합니다.module-domain: 순수 비즈니스 로직과 데이터 모델(Entity)을 담당하는 핵심 모듈입니다.domain-orders: 가맹점 및 본사의 발주(Order) 프로세스domain-inventories: 공장 및 가맹점의 재고(Inventory) 관리domain-settlements: 가맹점 수익 및 본사 정산(Settlement) 로직domain-transports: 물류 및 차량 배차(Logistics) 정보domain-users: 회원 정보 및 권한 관리- 기타 도메인:
products,notices,notifications,sales,returns등
module-app:app-api: 외부 요청을 처리하는 API 엔드포인트를 제공하며 도메인 모듈을 조합하여 실제 서비스를 제공합니다.module-external-transport: 외부 시스템(물류 시스템 등)과의 연동을 담당합니다.
-
가맹점 -> 본사 발주: 가맹점에서 부족한 밀키트 품목을 본사에 요청합니다. (화/금 도착 기준)
-
본사 -> 공장 생산 요청: 본사에서 전체 가맹점의 수요를 취합하여 공장에 생산 지시를 내립니다.
-
제품 코드 체계: 제품명 + 매운맛(01~04) + 사이즈(01, 03)의 조합으로 관리됩니다.
-
박스 및 제품 식별 코드: 생산된 제품은 지역/공장/생산라인 정보가 포함된 고유 코드로 관리됩니다.
-
피킹 및 차량 배차: 출고 전 패키징 확정(피킹) 후 적재 중량을 고려하여 물류 차량에 자동/반자동 배차를 진행합니다.
- 매출 및 대금 정산: 가맹점의 판매 데이터를 기반으로 본사 대금 차감 및 수수료 정산을 수행합니다.
- 반품 관리: 하자 상품에 대한 반품 요청 및 검수 후 대금 차감을 지원합니다.
요구사항 정의서
ERD
WBS
API 테스트케이스
API 문서
- 데일리 스크럼: 평일 오전 09:00 (10분 내외)
- 지라(Jira) 연동: 작업 시작 전 이슈 생성 및 브랜치(
feat/이슈번호-도메인) 생성 필수 - 품질 관리: 모든 PR은 SonarQube 분석 및 테스트 통과를 기본으로 합니다.
1. Naming (명명 규칙)
- 패키지: 언더스코어(
_) 없이 소문자만 사용 - 클래스: 대문자 카멜 케이스 (
UpperCamelCase) - 메서드: 동사/전치사 시작, 소문자 카멜 케이스 (
lowerCamelCase) - 변수: 소문자 카멜 케이스 (
lowerCamelCase) - ENUM/상수: 대문자 및 언더스코어 (
UPPER_SNAKE_CASE) - DB 테이블: 소문자 및 언더스코어 (
lower_snake_case) - 컬렉션: 복수형 사용 혹은 명시 (
users,userList,userMap)
2. Comment & Import (주석 및 임포트)
- 주석: 한 줄 주석은
//, 여러 줄은/* ... */사용 - 파일 구조: 소스파일당 1개의 탑레벨 클래스만 포함
- Import: 와일드카드(
*) 사용 금지 (단, static import는 허용) - Annotation: 선언 후 새 줄 사용 (파라미터 없는 1개는 같은 줄 허용)
- 기타: 배열 대괄호는 타입 뒤에 (
String[]),long형 값 끝에는 대문자L사용
3. URL (RESTful API)
- 행위 배제: URL에 get, put 등 행위 표현 금지 (HTTP Method로 구분)
- 구분자:
_대신-(Kebab-case) 사용 - 형식: 소문자 사용, 마지막
/및 확장자 포함 금지
1. Git Flow & Rules
- 프로세스: Issue 생성 → Jira 티켓 관리 → feature 브랜치 생성 → add/commit/push → PR 생성 → dev 머지
- 기본 규칙:
dev브랜치 직접 작업 금지 (README 제외), 모든 작업은 정상 실행 확인 후 수행 - 브랜치 네이밍:
<Prefix>/<Ticket_Number>-<Domain>-<Description>- 예시:
feat/7-order-create-order,feat/5-settlement-monthly
- 예시:
2. Commit Message & PR
- 양식:
[<Prefix>] #<Issue_Number> <Description> - Prefix:
feat: 새로운 기능 구현fix: 버그 수정del: 코드 삭제docs: 문서 개정refactor: 리팩터링chore: 빌드 업무, 패키지 구조 변경, 의존성 추가test: 테스트 코드 작성 및 수정
프로젝트를 마치며 팀원 각자가 느낀 기술적 도전과 성장을 기록합니다.
🦫 김채우
멀티 모듈을 도입해 배포까지 진행했던 프로젝트는 이번이 처음이었습니다.
5명이서 협업을 하며 하나의 결과물을 냈습니다. 실제 도메인을 구매해 접속해 보는 과정은 새로웠습니다.
2개월간 밀도 높은 시간으로 하나의 프로젝트에 몰입한 것 자체가 즐거웠습니다. 아쉬움도 많이 남지만 이 경험을 발판으로 앞으로 더욱 뛰어난 개발자가 되도록 노력하겠습니다.
☠️ 김성은
이번 프로젝트에서는 회원, 사업장 관리, 공지사항 및 알림 기능을 담당했으며, 동시에 인프라를 맡아 CI/CD 환경을 구축했습니다.
AWS를 처음 다뤄보는 상황이라 초반에는 어려움이 있었지만, 시행착오를 거치며 점차 익숙해졌고 실제 서비스 흐름을 고려한 배포 과정을 경험할 수 있었습니다.
또한 GitHub PR과 Jira 연동을 활용해 협업 프로세스를 체계적으로 경험했고, 팀원들과의 커뮤니케이션을 통해 기능을 조율하며 협업의 중요성을 느낄 수 있었습니다.
이번 프로젝트는 새로운 기술을 직접 적용해보고 문제를 해결해 나가는 과정에서 많은 것을 배우고, 한 단계 성장할 수 있었던 의미 있는 경험이었습니다.
🐇 김윤경
단순한 기능 개발을 넘어 기획부터 설계, 개발까지 전 과정을 경험하면서 서비스가 만들어지는 흐름을 깊게 이해할 수 있는 시간이었다.
각 도메인 간 상품의 이동과 돈의 흐름을 연결하여 하나의 시스템으로 바라볼 수 있었던 점이 가장 의미 있었다. 우리가 만든 ERP 시스템을 통해 비즈니스의 전반적인 흐름을 한눈에 파악할 수 있었던 것은 매우 값진 경험이었다.
멘토님의 리뷰를 통해 부족한 점을 객관적으로 돌아볼 수 있었고, 데일리 스크럼을 통해 팀원들의 진행 상황을 공유하며 협업의 중요성도 체감할 수 있었다.
많은 공을 들인 만큼 아쉬운 부분도 있었다. 초기 기획 단계에서 요구사항을 더 구체적으로 정의하지 못했던 점과, 서로 맡은 도메인 개발에 집중하다보니 소통이 부족했던 순간들이 아쉬웠다.
이 경험을 통해 꾸준한 커뮤니케이션이 얼마나 중요한지 깨달았고, 앞으로는 이를 적극적으로 반영하여 개발을 하고싶다.
🦘 유찬연
지난 시간들동안 배운 것들을 토대로 파이널 프로젝트를 진행했다. 많은 팀 프로젝트에서 매번 중요성을 느끼게 된 것도 있었고, 반복됨에 따라 중요성을 새롭게 느끼게 된 것도 있었다.
매번 중요성을 느끼게 된 것은 역시 소통이었다. 소통을 통해 우리가 하고자 하는 것이 같은 것인지를 확인하는 것이 중요했고, 구현이 되는 것에서도 통일되어야 했다.
지난 모든 프로젝트들에서 이 소통이라는 것이 매번 조금씩은 아쉬움이 느껴졌었다. 다음 프로젝트에서는 더 잘할 수 있겠다고 생각했지만, 또 다른 부분에서 소통이 미흡함을 느껴 아쉬움을 느꼈다.
프로젝트가 반복됨에 따라 중요도를 알게 된 것은 구조를 얼마나 견고하게 만드는 것인가 였다. 구조가 견고하지 못하면 서비스 로직에도 구멍이 많이 생기게 되고 작업을 수행할 때도 로직이 더 길어지는 등의 불편함이 있었다.
그래도 미흡한 점만 있지는 않았다. 개발을 시작한 뒤로 이정도까지 몰두해서 개발을 진행한 경험이 처음이었고, 프로젝트를 진행함에 따라 개발을 어떤 식으로 진행해야 하는지 지금 당장 처한 상황에서 내가 할 수 있는 일이 무엇인지 등을 깨닫게 되었다.
이러한 성장을 토대로 이후 진행하게 될 많은 프로젝트들에서 이런 미흡한 점들을 고려해 더욱 완성도 있는 팀 프로젝트를 만들고 싶다는 생각이 들었다. 그리 길지 않은 시간이었지만 많은 것들을 배웠고 느끼며 성장하는 값진 시간이었다.
🐜 조윤호
어느 정도 익혔다고 생각하고 파이널 프로젝트에 적용했지만, 예상보다 훨씬 어려웠다. 엔티티, 기능, 테스트를 반복적으로 수정하며 “더 효율적인 방법이 있었을 텐데”라는 아쉬움이 들었다.
특히 초기 설계의 중요성을 크게 느꼈다. 기반이 탄탄하지 않으면 이후에 큰 수정이 반복된다는 것을 직접 경험했다.
비록 쉽지 않은 과정이었지만, 다양한 시행착오를 통해 한 단계 성장할 수 있었던 의미 있는 경험이었다.