1. 프로젝트 개요

1.1 배경

차일디는 패션 유통 기업을 위한 AI 기반 BI(Business Intelligence) 시스템을 개발 중입니다.
현재 세원의 ERP/WMS 시스템을 사용하고 있으며, 데이터의 정적 활용에서 동적 활용으로의 전환이 필요한 시점입니다.

현재 상황의 문제점
  • 화면 단위 API 개발은 건별 비용이 높고 확장성이 낮음
  • DB 직접 접근은 보안 리스크 및 비즈니스 로직 누락 위험 존재
  • 데이터 활용이 제한적이어서 AI 기반 분석 및 예측 기능 구현 불가

1.2 프로젝트 목적

차일디 측면

  • AI 기반 수요 예측 및 발주 최적화 시스템 구축
  • 실시간 재고 모니터링을 통한 결품 방지 및 악성 재고 탐지
  • 채널별 수익성 분석 및 마케팅 인사이트 도출
  • 데이터 기반 의사결정 지원 시스템 완성

세원 측면

  • 표준 API 모델 확보로 향후 타 고객사 대상 유료 API 옵션 제공 가능
  • 리소스 테이블 중심의 재사용 가능한 API 아키텍처 구축
  • 기존 화면 중심 개발 방식에서 도메인 중심 개발 방식으로 전환

상호 이익

  • 안정적이고 확장 가능한 시스템 간 연동 체계 구축
  • 데이터 무결성 보장 및 보안 강화
  • 장기적인 파트너십 기반 마련

1.3 프로젝트 범위

연동 대상 시스템

  • 차일디 BI 시스템 (개발 중)
  • 세원 ERP/WMS 시스템

연동 방식

  • RESTful API 기반 통신
  • JSON 데이터 포맷
  • Bearer Token 인증 방식
  • Webhook을 통한 실시간 이벤트 알림 (선택)

2. 비즈니스 요구사항

차일디는 세원 시스템의 데이터를 활용하여 다음과 같은 비즈니스 기능을 구현합니다.

2.1 AI 기반 수요 예측 및 발주 최적화

과거 판매 데이터, 시즌별 패턴, 상품 특성을 분석하여 객관적인 발주량을 산정하고, 재고 과잉과 품절 리스크를 최소화합니다.

필요 데이터: 상품 마스터, 판매 이력, 입출고 데이터, 재고 수불부, 원가 정보

2.2 실시간 재고 모니터링 및 알림

결품 방지 및 악성 재고 조기 탐지를 통해 재고 건전성을 확보하고, 매장별 재고 불균형을 해소합니다.

필요 기능: 실시간 재고 조회 API, 재고 변동 알림 (Webhook), 재고 수불부 이력 추적

2.3 채널별 수익성 분석

채널별 매출 및 수익성을 비교 분석하여 마케팅 ROI를 측정하고, 효율적인 채널 운영 전략을 수립합니다.

필요 데이터: 주문 내역, 취소/반품 내역, 매출 집계, 원가 정보

2.4 발주 결재 시스템 (차일디 자체 개발)

현금흐름 관리 및 조직별 최적 발주량 판단을 위한 투명한 발주 프로세스를 구축합니다.

필요 기능: 세원 시스템에서 상품 정보 및 원가 정보 조회

3. 기술 요구사항

3.1 API 도메인 구성

총 5개의 핵심 도메인으로 구성됩니다.

3.1.1 상품(Product) 도메인

  • 상품 마스터 정보 조회
  • 상품 상세 정보 조회
  • 카테고리 목록 조회 (대복종/소복종)
  • 상품 등록/수정 (3단계)

주요 필드: 품번(style_no), 상품명(product_name), 브랜드 코드/명(brand_code, brand_name - 예: HR), 시즌(season), 대복종/소복종(main_category, sub_category), 컬러, 사이즈, SKU, 공급처, 생산방식, 정가(retail_price)

3.1.2 원가(Cost) 도메인

  • 사전원가 조회
  • 사후원가 조회
  • 원가 등록/수정 (2단계)
  • 사전/사후 원가 비교

원가 구성 항목: 원자재(raw_material), 부자재(sub_material), 가공비(processing), 라벨/스티커(label_sticker), 택/택고리(tag), 공임(labor), 관세(customs), 물류/경비(logistics), 마진(margin)

3.1.3 입출고(Inbound/Outbound) 도메인

  • 입고 내역 조회
  • 출고 내역 조회

활용: 적정 발주 시점 파악, 수요량 동적 파악, 위험 감지

3.1.4 재고(Inventory) 도메인

  • 실시간 재고 조회
  • 매장별 재고 현황
  • 재고 수불부 조회

활용: 결품 방지, 악성 재고 탐지, 재고 건전성 확보

3.1.5 판매(Sales) 도메인

  • 주문 내역 조회
  • 취소/반품 내역 조회
  • 매출 집계 조회

조회 기준: 일자별, 월별, 채널별, 브랜드별, 매장별, 품번별

3.2 단계별 개발 로드맵

1단계: 조회 전용 API (우선순위 최상)

  • 운영 DB 부하 최소화
  • 읽기 전용 인터페이스
  • 모든 도메인의 조회 API 구현

예상 기간: 4-6주

2단계: 상태 변경 API

  • 입고 확정 처리
  • 원가 정보 등록/수정
  • 기존 데이터 상태 변경

예상 기간: 3-4주

3단계: 생성 API

  • 상품 등록/수정
  • 완전한 CRU 기능 구현
  • 삭제(Delete)는 데이터 무결성 보호를 위해 제외

예상 기간: 3-4주

3.3 공통 기술 규격

항목 규격
인증 Bearer Token 방식, 토큰 갱신 메커니즘
데이터 포맷 JSON, UTF-8 인코딩
날짜 YYYY-MM-DD
날짜시간 ISO 8601 (YYYY-MM-DDTHH:mm:ssZ)
페이지네이션 page: 페이지 번호 (1부터 시작)
limit: 페이지당 건수 (기본 100, 최대 1000)
에러 처리 표준화된 에러 응답 형식, 에러 코드 및 메시지 제공

3.4 Webhook (선택 사항)

목적

  • 실시간 데이터 동기화
  • 주기적 폴링 부하 감소

이벤트 종류

  • 재고 변동 알림
  • 주문 생성 알림
  • 입고 완료 알림

4. 세원측 제공 필요 자료

4.1 우선순위 높음 (프로젝트 시작 전 필수)

1. 핵심 테이블 샘플 데이터 (5~10건)

  • 상품 마스터 테이블
  • 원가 정보 테이블 (사전/사후)
  • 재고 수불부 테이블
  • 입출고 테이블
  • 주문/판매 테이블

형식: 정식 문서가 아니어도 무방. 엑셀 파일 형태로 제공 시 차일디 측에서 구조 역분석 가능. 실제 데이터 또는 샘플 데이터.

2. 기존 연동 사례

  • 카페24, 무신사 등 타 시스템 연동 API 프로토콜
  • 표준 API 문서 (있는 경우)
  • 연동 경험 및 노하우 공유

4.2 우선순위 중간 (개발 초기 단계)

테이블 구조 정보

  • ERD 또는 테이블 정의서 (간략 버전)
  • 주요 필드 설명 및 데이터 타입
  • 테이블 간 관계 정보

참고: 전체 공유가 어려운 경우 기본 구조 및 데이터 형태 가이드만 제공

4.3 기술 검토 사항 (킥오프 미팅 시 논의)

항목 설명 중요도
Webhook 지원 실시간 이벤트 알림 기능 지원 가능 여부 중
API Rate Limit API 호출 제한 정책 (분당/시간당 요청 수) 상
개발 환경 개발/스테이징 환경 제공 여부 상
보안 정책 IP 화이트리스트, SSL 인증서 등 상
응답 시간 평균/최대 응답 시간 목표 중
데이터 갱신 주기 실시간 vs 배치 처리 상

5. 프로젝트 일정

Phase 1: 준비 단계 (2주)

  • 킥오프 미팅
  • 요구사항 상세 정의
  • 세원측 자료 수령 및 분석
  • API 명세서 최종 확정
  • 개발 환경 구축

Phase 2: 1단계 개발 (4-6주)

  • 조회 전용 API 개발
  • 5개 도메인 모든 조회 API 구현
  • 단위 테스트 및 통합 테스트
  • 성능 테스트

Phase 3: 1단계 검증 (2주)

  • 차일디 측 연동 테스트
  • 버그 수정 및 최적화
  • 문서화

Phase 4: 2단계 개발 (3-4주)

  • 상태 변경 API 개발
  • 테스트 및 검증

Phase 5: 3단계 개발 (3-4주)

  • 생성 API 개발
  • 최종 테스트 및 검증

Phase 6: 운영 이관 (1주)

  • 운영 환경 배포
  • 모니터링 체계 구축
  • 운영 매뉴얼 작성
총 예상 기간: 약 3-4개월

6. 성공 기준

6.1 기술적 성공 기준

  • 모든 API 응답 시간 < 2초 (95 percentile)
  • API 가용성 > 99.5%
  • 데이터 정합성 100% 유지
  • 보안 취약점 0건

6.2 비즈니스 성공 기준

  • AI 수요 예측 모델 학습 가능한 데이터 확보
  • 실시간 재고 모니터링 시스템 구축
  • 채널별 수익성 분석 대시보드 완성
  • 발주 결재 시스템 정상 운영

6.3 프로젝트 성공 기준

  • 일정 내 완료 (±10% 허용)
  • 예산 내 완료
  • 양측 만족도 > 80%
  • 향후 확장 가능한 아키텍처 구축

7. 리스크 관리

7.1 기술적 리스크

리스크 영향도 발생 가능성 대응 방안
세원 시스템 성능 저하 상 중 Rate Limiting, 캐싱 전략
데이터 구조 불일치 상 중 사전 샘플 데이터 분석 철저히
보안 이슈 상 하 보안 검토 및 테스트 강화
API 응답 시간 지연 중 중 비동기 처리, 배치 처리 병행

7.2 일정 리스크

리스크 영향도 발생 가능성 대응 방안
요구사항 변경 중 중 변경 관리 프로세스 수립
자료 제공 지연 상 중 조기 요청 및 독촉
리소스 부족 중 하 우선순위 조정

7.3 비즈니스 리스크

리스크 영향도 발생 가능성 대응 방안
양측 기대치 불일치 중 중 정기 미팅 및 소통 강화
데이터 품질 이슈 중 중 데이터 검증 로직 구현

8. 커뮤니케이션 계획

8.1 정기 미팅

  • 킥오프 미팅: 프로젝트 시작 시 1회
  • 주간 진행 회의: 매주 1회 (1시간)
  • 단계별 리뷰 미팅: 각 단계 완료 시
  • 최종 검수 미팅: 프로젝트 완료 시

8.2 커뮤니케이션 채널

  • 긴급 이슈: 전화 또는 메신저
  • 일반 문의: 이메일
  • 기술 문서: 공유 문서 시스템
  • 이슈 트래킹: 이슈 관리 시스템 (협의 후 결정)

8.3 보고 체계

  • 주간 진행 보고서: 매주 금요일
  • 단계별 완료 보고서: 각 단계 완료 시
  • 이슈 발생 시 즉시 보고

9. 품질 관리

9.1 테스트 전략

  • 단위 테스트: 각 API 개별 테스트
  • 통합 테스트: API 간 연동 테스트
  • 성능 테스트: 부하 테스트 및 스트레스 테스트
  • 보안 테스트: 취약점 스캔 및 침투 테스트
  • 사용자 인수 테스트: 차일디 측 실제 사용 시나리오 테스트

9.2 코드 리뷰

  • 모든 코드는 리뷰 후 병합
  • 코딩 컨벤션 준수
  • 문서화 필수

9.3 모니터링

  • API 호출 로그 수집
  • 에러율 모니터링
  • 응답 시간 모니터링
  • 알림 체계 구축

10. 화면 단위 개발 시

API 연동 대신 화면 단위로 개발할 경우, 다음 화면들이 필요합니다.

ERP 화면

  • 상품 정보 등록 - 신규 상품 등록 및 수정
  • 발주현황 - 발주 내역 조회 및 관리
  • 품번종합집계표 - 품번별 재고, 판매, 입출고 종합 현황
  • 일자별 판매 현황 - 일자별 판매 데이터 조회

WMS 화면

  • 기간별 재고 현황 - 기간별 재고 변동 및 현황 조회
참고: 화면 단위 개발은 건별 비용이 높고 확장성이 낮아, API 기반 연동을 권장합니다.