Cohe

[project] 굿즈 마켓 플레이스 기획 - 2차 본문

사이드 프로젝트 이모저모/굿즈 마켓플레이스 프로젝트

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

코헤0121 2025. 2. 20. 16:07
728x90
반응형

회의 날짜 : 2025. 2. 17.

 

회사 일도 많고, 체력적으로도 지치고, 요구사항도 끝없이 쏟아지는 요즘... 진짜 왜 사는 걸까 싶은 시기입니다. 🫠 그래도 해야 할 건 해야 하니까, 회의 내용과 앞으로의 방향을 정리해 봅니다.

진짜 힘들어요..

 


📌 지난 회의 리뷰

지난 회의에서는 굿즈 마켓플레이스를 위한 두 가지 핵심 기능을 정리했어요.

  1. 비즈니스 부담 없는 테스트 마켓
    • 창작자들이 정식 커미션을 시작하기 전에 창작물 판매 경험을 쌓을 수 있는 기회 제공
  2. 커뮤니티 기능
    • 창작자들이 작품을 올리고 리뷰를 받을 수 있는 공간

이 두 가지를 목표로, 각자 Notion에 요구사항 명세서를 정리하기로 했습니다. 그 결과... 🫠 요구사항이 너무 많아 보이더라고요.


하나씩 추려보면서 우선순위를 정하다 보니, “둘이서 할 수 있을까?” 싶었어요.

그래서 결국, 1차 목표는 최소한의 기능을 구현하고 인원 충원을 노리는 것으로 결정했습니다.

이 글을 보고 있는 당신!! 당신도 합류하라

 


📌 1차 목표: 최소 기능으로 MVP 구축

우리 서비스의 핵심 요구사항을 다시 정리해 봤어요.

1. 결제 시스템 (필수)

  • 에스크로(중간 보관) 시스템 도입 (선입금 후 작업 완료 시 지급)

2. 커뮤니티 기능 → 문의함으로 대체 (우선순위 하향)

  • 간단한 CRUD 기능을 배제하고, 꼭 필요한 기능만 남기기로 결정

이렇게 하면 서비스를 빠르게 출시할 수 있고, 최소한의 리소스로 운영이 가능할 거라 판단했습니다.


📌 기술적 고민: API 개발과 MSA 적용 가능성

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

기존에는 단일 서비스에서 모든 기능을 처리하는 방식이 익숙했지만, 확장성과 유지보수성을 고려해 API 서버와 컨트롤러 서버를 분리하는 방식으로 고민했습니다.

API 서버:

  • 비즈니스 로직 처리
  • 데이터베이스와 직접 연결
  • 확장성을 고려해 여러 개로 확장 가능

컨트롤러 서버:

  • API 서버를 호출하여 데이터 제공
  • 클라이언트(Web, Mobile 등)와 직접 소통

이 방식을 적용하면 확장성과 유지보수성이 향상되고, 여러 클라이언트에서 동일한 API를 활용할 수 있는 유연성이 생깁니다.

-> 이 경우로 가게 된다면 API 서버만 개발을 하고 다른 프론트엔드 개발자분께서 알아서 스스로의 포폴을 만들 수 있지 않을까? 싶어지더라고요

 

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

MSA(마이크로서비스 아키텍처)로 전환할 가능성을 고려해 공통 기능을 라이브러리(.jar)로 관리하는 방안을 고민했어요.

✅ 예제:

  • OAuth 2.0 / JWT 인증 라이브러리화
  • AOP 기반 로깅 및 예외 처리 적용
  • 공통 결제 처리 모듈 구축

이렇게 하면 중복 코드를 줄이고, 서비스 간 일관성을 유지하면서도 독립적 배포가 가능해집니다.


📌 결제 시스템과 배치 프로그램 도입

이번 프로젝트는 단순한 CRUD 서비스가 아니라 결제 시스템과 배치 프로그램도 필요해요.

1. 배치 프로그램(Scheduler) 도입

배치 프로그램을 활용하면 반복적인 작업을 자동화할 수 있어요.

✅ 적용 예시:

  • 구매 내역 정리 및 분석 (추천 시스템과 연계 가능)
  • 에스크로 금액 자동 지급 (조건 충족 시 자동 처리)
  • 유저 활동 분석 및 추천 시스템

우리는 이를 위해 Spring Batch를 활용할 계획입니다.

2. 결제 API와 에스크로 시스템

안전한 거래 환경을 위해 에스크로 결제를 도입할 예정이에요.

✅ 핵심 요소:

  • 가상 캐시 충전 방식
  • 즉시 인출 불가, 일정 조건 충족 시 지급
  • Open API 활용 (카카오페이, 네이버페이 연동 고려)

이 방식을 적용하면 사기 거래를 방지하고, 보다 안전한 환경을 구축할 수 있다 생각해요.

-> 하지만 지금 당장 1차 개발 목표가 맞나..? 싶어지더라고요.. 🥲 일단 이번주 회의 때 제대로 정리를 해볼까 싶어요..


🚀 결론 – 우리가 배운 것

하지만 위의 설명들이 전부 다 1차 때 완성하기 어려울 것이라고 생각해요  때문에 더더욱! 단순히 "API를 만든다"는 수준을 넘어서, 확장성과 유지보수성을 고려한 아키텍처 설계가 얼마나 중요한지.. 어려운지 힘든지 알게되었어요..

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

다음 단계에서는 API 설계와 DB 모델링을 구체화할거에욤....

아직 갈 길이 멀지만, 한 걸음씩 나아가다 보면 좋은 결과가 있을 거라 믿어요! 😊

 

728x90
반응형