Chap.01 : Project Day 2 - Scrum

Ch.1 AI 활용 비즈니스 프로젝트

어제 한일, 오늘 할일,  내일 할일

장애물 개선

문서 정리 하셨다튜터님이

프로젝트 구조를 생성해주셨다. 참고자료 받아서 올려놓기

 

장소 : ZEP

 

참여자 : 서동우(튜터), 정민수, 이지언, 염금성, 노현지

 

스크럼 진행

1.  튜터님과 함께 피드백 반영

2. 각 파일 확정 (API명세서, TABLE명세서, ERD, 인프라 설계

3. 개발 과정 튜터님과 의논해서 어떻게 개발할지 진행과정 맞추기)

4. GIt컨벤션, Code컨벤션, 의사소통 방법 한번 더 진행해서 확정

+ 깃허브 생성, 공통사항추가

 

어제 작업

API명세서 작성

Table명세서 작성

ERD설계

인프라 설계

튜터님 조언 방영

 

 

튜터님과 함께 피드백 반영

---

📌 1. API 명세서에서 HTTP 메소드 결정 (PUT vs PATCH)

• 실무에서는 PUT을 주로 사용했으며, 문제는 없었음
• 응용 계층에서 PUT의 문제를 해결할 수 있음
• 현재 PUT/PATCH 선택은 보류, 추후 논의 예정

 

2. ERD 수정 (프리픽스 변경 및 관계 확인)

• 유저(User)와 오더(Order) 연관관계 대조 필요
• 어드레스(Address)의 유저와 가게(Store) 연관관계 문제 검토
  • store_user_id, address_user_id가 존재.
  • JWT 페이로드에서 user_id를 확인 가능
  • API Gateway에서 필터링, JWT 인증으로 store_user_id 조회 가능
  • 사용자는 상품(Product)까지 조회 가능해야 함

 

 

• Address는 독립적인 관계가 맞을까?
  • Address가 배송지 역할을 한다면 User와 연관관계 필요
  • 정규화 원칙 적용 → 주소 유형에 따라 분류 (유저 배송지, 가게 주소 등)
  • 바운디드 컨텍스트 개념 적용 → 환경에 따라 분류 필요
  • 칼럼명은 도, 시군구으로 분류하여 차후 확장할 수 있게 분류

 

 

📌 3. 인프라 설계

• 서비스 배포 계획
  • 도커 컨테이너를 단일 EC2에 배포 예정
  • DB: 비용 문제로 RDS 대신 EC2 내부에 PostgreSQL 설치하여 참조
  • CI/CD 배포 도구: Jenkins 선택
• AI 서비스 도입 고려
  • Spring 프로젝트 내부에 AI 서비스 추가 가능
  • AI API를 별도로 FastAPI로 경량화하기 위해 분리하여 배포할 경우 Nginx를 Reverse Proxy로 활용
  • HTTPS 적용도 Nginx 사용 예정

 

📌 4. 비용 절감 및 클라우드 활용

• EC2 내 PostgreSQL 설치로 비용 절감 고려
• 프리티어(무료 인스턴스) 활용 계획
  • AWS 프리티어: EC2 한 대 기준 750시간 제공
  • 2대 생성 시 350시간으로 나뉘므로 운영 가능 시간 감소
  • 다음 주 주말쯤 테스트 진행 예정
  • GCP 등 대체 클라우드 서비스도 고려 중
• S3 활용 계획
  • 이미지 파일 저장용으로 S3 버킷 생성 계획.

 

📌 5. Address(주소) 엔티티 설계 및 연관관계

• Address를 User(유저) 및 Store(가게)와 어떻게 연관시킬지 고민 중
• Address는 독립적인 개체로 보거나, 특정 개체(User/Store)의 속성으로 볼 수도 있음
• Embeddable(임베더블) 객체 활용 가능
  • 값 객체로써 Address를 수정 또는 대체 가능하게 설계
  • 상세 주소 정보를 임베더블(Embeddable) 객체로 저장 가능
• 엔티티(Entity)와 객체(Value Object) 구분
  • 엔티티는 식별키(ID)와 라이프사이클을 가짐
  • 객체는 불변성이 보장되며 필요할 때 가져다 쓰는 개념.
  • 예: 기차 좌석(일반석, 입석)처럼 엔티티는 식별자(ID)를 갖고 영속성을 가짐.

 

📌 6. API 명세서: PUT vs PATCH (최종 결정)

• PUT: 전체 업데이트 (리소스를 통째로 교체)
• PATCH: 일부 필드만 업데이트 가능
• 결론: PUT 메소드 사용 결정 → API 명세서 수정 진행

 

📌 7. 결제 주문 취소 요청 (POST vs UPDATE)

• 기존에는 update 방식 고려했으나, 요청(트리거) 성격이므로 POST가 적합
• 결제 취소 요청은 새로운 액션 발생 → POST 사용 결정

📌 8. API 명세서 작성 방식 통일

• 요청(Request) 및 응답(Response) 형식 통일 필요
• 헤더(Header), 바디(Body) 구분을 명확히 할 것
• Authorization 등 헤더값은 실제 값 대신 타입(형식)으로 명시하는 것이 좋음

📌 9. 빌더 패턴 vs 정적 팩토리 메서드 (생성 패턴 결정)

• 정적 팩토리 메서드 (Static Factory Method)
  • 장점:
    ✅ 객체 생성 방식 통제 가능 (임의 값 변경 불가능 → 안정적)
    ✅ 생성 로직을 숨길 수 있음
  • 단점:
    ❌ 생성 방식이 제한됨 → 필드가 많아질 경우 유연성이 떨어짐
• 빌더 패턴 (Builder Pattern)
  • 장점:
    ✅ 객체 생성 시 필수값 지정 가능 → 안정적인 생성 보장
    ✅ 가독성 높고 필드가 많을 때 유리
  • 단점:
    ❌ 모든 필드를 설정해야 객체 생성 가능
    ❌ 일부 필드를 선택적으로 설정하는 경우 불편할 수 있음
• 최종 결정:
  • 내부에서는 빌더 패턴을 사용하고, 외부에서는 정적 팩토리 메서드를 활용
  • 프라이빗 생성자를 통해 내부 객체 보호
  • 팩토리 메서드는 유연성이 높아 외부 사용에 적합

 

📌 6. 스프링 코드 컨벤션 및 JSON 규칙

• 컬렉션(Map, List) 네이밍 규칙
  • 복수형(s)을 붙이지 말고 목적에 맞게 적용
  • 예: userAddressMap (X) → userAddressById (O)

 

추가적으로 진행한 사항

• 깃허브 생성, 공통사항추가

프로젝트 진행 참고 자료

https://github.com/dannyseo9202/first-project-example

GitHub - dannyseo9202/first-project-example

---

내일 할 일

• 공통모듈 및 공통사항 적용해서 개발 시작
• 본격적인 개발 시작 - 각 기능마다 담당해서 개발!!

 

문제 사항은 피드백으로 반영 완료