[project] 굿즈 마켓 플레이스 기획 - 3차

 

📝 [Project] MSA, TDD, 요구사항 및 DB 설계 정리

📅 회의 날짜: 2025. 2. 17.

🔥 최근 프로젝트 진행 상황

요즘 일이 많아서 체력적으로도 힘들고, 요구사항도 끊임없이 쏟아지고 있어요... 🫠
그래도 해야 할 일은 해야 하니까! 지난 회의 내용을 정리하면서 앞으로의 방향을 잡아보겠습니다.

> 진짜 구라안치고 출근할 때마다 퇴사하겠다고 이야기 하는 듯 싶어요..

---

✅ 1. MSA 적용 여부

❓ 우리가 MSA를 적용해야 할까?
현재 시스템 규모를 고려하면 MSA가 필수는 아니지만, 기술적 경험을 쌓기 위해 적용을 고민해봤어요.

🔹 데이터 처리 고민

자주 호출되는 회원 정보 등은 어떻게 처리할까?

1. 중앙 Controller Server 및 DB를 통해 데이터 일괄 처리
   • ✅ 유지보수 용이
   • ⚠️ 단일 장애점(SPOF) 발생 가능
2. NoSQL 활용 → JSON 데이터 지속적 불러오기
   • ✅ 비정형 데이터 활용에 용이
   • ⚠️ 트랜잭션 관리 어려움

💡 현재 MVC 구조로 시작하고, 추후 MSA 리팩토링을 고려하기로 결정!

---

✅ 2. TDD 적용 여부

TDD를 적용하면 코드 품질을 높일 수 있고, 이직에도 유리하기 때문에 적극 활용해보기로 했어요.

🔹 Mockito / Mock 활용하여 테스트 코드 작성 연습
🔹 초기 개발 속도는 느려질 수 있지만, 장기적 유지보수성을 고려

> 사실 근데 그냥 내가 하고 싶어서 제안드렸어요(감사합니다 책임님..)

---

✅ 3. 요구사항 정리

프로젝트의 핵심 기능을 정리하고, 우선순위를 명확히 설정했어요.
🚀 1차 목표: 최소한의 기능을 구현(MVP) 후 인력 충원을 목표로!

🌟 핵심 기능 선정

1. Auth(인증/인가) 시스템 - 담당:
   • JWT, OAuth 적용 고려
2. Commision(의뢰/수주 시스템)
3. Payment(결제 시스템)

---

✅ 4. DB 설계

🛠️ 4.1 Auth(인증/인가) DB 설계

✔️ 계정과 회원 정보를 분리하여 관리하는 것이 확장성과 유지보수 측면에서 적절하다고 판단!

📌 계정 테이블 (로그인 및 인증 담당)

• userID (UUID, PK)
  • 사실 CUID도 고려 항목이다 보니... 무엇이 나을지 제안주셨음.. 좋겠다...
• 로그인 계정 (email, kakao, naver 등)
• 비밀번호
• OAuth 타입 (kakao, naver 등)

📌 회원 정보 테이블 (프로필 및 권한 관리)

• userID (PK, FK)
• 국가 코드, 닉네임, 이메일, 전화번호, 주소, 성별, 나이
• 회원 상태 (status, enum 활용)
• 인증 여부

💡 팔로워/팔로잉 기능은 추후 확장 가능하도록 고려

🥲사실 저와 책임님 둘 다 같은 회사다보니.. (둘 다 여기가 첫 회사..) 자꾸 DB에 모든 걸 다 때려박는 형식을 사용하려고 했거덩요..
하지만 암만 생각해도 한 Table에 여러번 반복 조회가 될 것 같았고 이게 맞느냐? 라고 생각하면 아닐 것 같단말이져.. 이 때문에 enum으로 제안드렸어요

---

🛠️ 4.2 Commision(의뢰) DB 설계

📌 게시글 테이블

• title, content, writer, bookmark, timestamp, fileId
• 파일 관리 방식 고민
  🔹 file, fileType을 저장할지
  🔹 fileId 값만 관리하고 별도 file 테이블에서 관리할지
  ✅ 결론: fileId를 PK로 두고, fileType, file-url을 별도 테이블에서 관리하는 것이 적절
  • 사실 애초에 file과 fileType만 있어도 table이 나뉘어질 것 같아.. 걍 fileId로 file이라는 table을 만들기루 결정~!

📌 Q&A (문의) 테이블 & 채팅 기능

• Q&A ID, 글, usr1, usr2
• WebSocket 활용하여 실시간 채팅 기능 구현 고려

💡 채팅 기능 상세 설계

1. ChatMembers 테이블 (채팅방 참여자 관리)
   • chatId, userId1, userId2
   • 채팅 목록 UI에서 활용
2. Messages 테이블 (채팅 메시지 저장)
   • chatId, messageType, timestamp, userId, msgId
   • 트랜잭션 최적화 필요

⚠️ MessageStatus 테이블(읽음 상태 관리)은 업데이트 비용을 줄이기 위해 제외 검토

---

🛠️ 4.3 Payment(결제) DB 설계

💡 에스크로(중간 보관) 시스템 도입 고민

• 구매자 → 에스크로 → 작업 완료 시 지급
• 사기 거래 방지를 위해 안전한 환경 구축 필수
  • 만약에 커미션주가.... 하청의 하청을 넣으면 어쩌지? 
    ex) https://www.khan.co.kr/article/201301171351591

일하기 싫어 중국에 하청 준 미국 회사원

 

🚀 결제 API 연동 고려 사항
✅ 가상 캐시 충전 방식이 아닌 가입시 일정 금액 지급 방식
✅ Open API 활용 (카카오페이, 네이버페이 연동 고려) -> 충전가능형식으로 간다면!!

---

✅ 5. 기술적 고민

🤔 API 서버만 개발하는 방식?

기존에는 단일 서비스에서 모든 기능을 처리했지만, 확장성을 고려하여
✅ API 서버 & 컨트롤러 서버 분리

• API 서버 → 비즈니스 로직 담당
• 컨트롤러 서버 → 클라이언트(Web, Mobile)와 직접 소통

💡 이렇게 하면 여러 클라이언트에서 동일한 API 활용 가능!
-> 추후에 msa를 사용하게 된다면 이렇게 가지 않을까?

🤔 공통 기능을 라이브러리화할까?

MSA 전환 가능성을 고려해 공통 기능을 .jar 형태로 관리
✅ OAuth 2.0 / JWT 인증 모듈화
✅ AOP 기반 로깅 및 예외 처리 적용
✅ 공통 결제 처리 모듈 구축

---

🚀 결론 및 향후 계획

여기까지 고민하는데 총 4시간 걸렸어요.. 사이드 프로젝트 기획은 정말정말정말.. 오래걸리고 즐겁고 힘겹네요ㅠ 책임님과 월화수목금토일 내내 마주하고 회의할 수 없나.. 엄청나게 고민되네요..,.

📌 우리가 배운 것!
✅ API 서버와 컨트롤러 서버 분리 → 확장성과 유지보수성 향상
✅ 공통 기능 라이브러리화 → 중복 코드 감소, 서비스 일관성 유지
✅ 배치 프로그램 활용 → 반복 작업 자동화하여 운영 효율화
✅ 에스크로 결제 시스템 도입 → 안전한 거래 환경 구축

📌 다음 단계

1. API 설계 구체화
2. DB 모델링 세부 정리
3. MVP(최소 기능) 구축 후 테스트 진행 (이거.. 가능할까..?)