도토리 창고는 사용자가 원하는 물건을 자유롭게 선택해 공동구매를 개설하고, 같은 지역의 이웃들과 함께 알뜰하게 구매할 수 있는 동네 기반 C2C 공동구매 플랫폼입니다.
기존 공동구매 서비스가 정해진 상품이나 판매자 중심으로 운영되는 경우가 많았다면, 도토리 창고는 사용자가 직접 주최자가 되어 필요한 물건의 공동구매를 열 수 있도록 구성했습니다.
또한 주소 기반으로 주변 동네까지 참여 범위를 확장하여, 한 동네에만 제한되지 않고 더 많은 이웃과 공동구매를 진행할 수 있도록 했습니다.
이를 통해 참여자는 필요한 물건을 함께 구매해 비용 부담을 줄일 수 있고, 주최자는 수량을 나누어 모집하며 공동구매 진행 부담을 줄일 수 있습니다.
📅 2026.04.23 - 2026.06.08
| 강민주 👩💻 | 이현석 👨💻 | 김윤우 👨💻 | 김민수 👨💻 |
|---|---|---|---|
 |
 |
 |
 |
- 공동구매 REST API 구현
- 공동구매 개설, 수정 및 삭제(CRUD) API 구현
- 공동구매 참여, 참여 취소 및 수량 변경 기능 구현
- 공동구매 진행 단계에 따른 비즈니스 상태 관리 로직 적용
- 공동구매 정산 기능 설계 및 협업 후 연동
- 공동구매 검색 및 필터링 구현
- 다양한 조건을 반영한 공동구매 목록 검색 및 필터링 API 구현
- Spring Security와 JWT를 활용한 API 인가(Authorization) 처리 구현
- 인증/인가 및 보안 처리
- API 요청 시 토큰 검증을 통한 사용자 식별 및 접근 권한 제어 적용
-
회원 기능 구현
- 회원가입 화면 UI 구성 및 입력값 상태 관리
- 아이디 중복확인 기능 구현
- 닉네임 중복확인 기능 구현
- 비밀번호 확인, 약관 동의 등 회원가입 입력 조건 처리
- 회원가입 요청 데이터 구성 및 백엔드 API 연동
- 회원가입 성공/실패 결과에 따른 사용자 피드백 처리
-
주소 기반 기능 구현
- 카카오 주소 검색 API 연동
- 사용자가 선택한 주소 정보를 회원가입 흐름과 연결
- 주소 기반 좌표 변환 흐름 구성
- 선택한 주소를 기준으로 주변주소 저장 기능과 연결
- 동네 기반 공동구매 참여 범위 확장을 위한 주소 데이터 처리
-
로그인 및 인증 기능 구현
- 세션 로그인 기능 구현
- JWT 로그인 기능 구현
- 로그인 요청 데이터 구성 및 백엔드 API 연동
- 로그인 성공 시 사용자 인증 상태 관리
- JWT 인증 헤더 기반 토큰 처리 흐름 구성
- 로그아웃 기능 구현
- 로그인 실패 및 인증 관련 응답에 대한 에러 처리
-
마이페이지 주소 기능 구현
- 마이페이지 내 사용자 주소 조회 기능 구현
- 사용자 주소 변경 흐름 구성
- 카카오 지도 API를 활용한 주소 확인 화면 구현
- 서버에서 받아온 주소 데이터를 화면에 렌더링
- 주소 변경 후 최신 사용자 정보가 반영되도록 프론트 흐름 처리
-
공통 UI 및 프론트엔드 구조 개선
- 공통 Input, Button, Modal 컴포넌트를 활용한 화면 구성
- 로그인, 회원가입, 주소 기능에서 공통 Modal을 활용한 사용자 피드백 처리
- 반복되는 API 요청 흐름을 정리하여 페이지별 API 연동 구조 개선
- Storybook을 활용한 공통 컴포넌트 확인 및 UI 상태 점검
-
채팅방 REST API 구현
- 채팅방 목록 조회 API 구현 (참여 중인 채팅방 전체 조회)
- N+1 문제 해결을 위한 JPQL fetch join 적용 (49→3 쿼리, 365ms→30ms)
- 채팅방 상세 조회 API 구현
- 채팅방 생성 및 참여/퇴장 API 구현
- 커서 기반 페이지네이션을 활용한 메시지 이력 조회 API 구현
-
WebSocket / STOMP 실시간 채팅 구현
- Spring WebSocket + STOMP 기반 실시간 메시지 송수신 구현
- WebSocket 연결 시 JWT 인증 처리를 위한 ‘JwtHandshakeInterceptor‘ 구현
- 구독 시점 권한 검증을 위한 ‘StompSubscriptionInterceptor‘ 구현 (2단계 보안)
- 채팅방별 구독 토픽 설계 및 메시지 브로드캐스트 흐름 구성
-
읽음 처리 및 안읽은 메시지 수 관리
- ‘lastReadMessageId‘ 기반 읽음 상태 추적 구현
- 채팅방 입장 시 읽음 처리 및 미읽음 카운트 초기화 로직 구현
- 미읽음 메시지 수 실시간 반영을 위한 프론트 상태 동기화 처리
-
프론트엔드 채팅 UI 구현
- Vite, React Query 기반 채팅 프론트엔드 구성
- 채팅방 목록 화면 구현 (참여자 수, 최근 메시지, 미읽음 뱃지 표시)
- 실시간 메시지 수신 시 채팅방 목록 자동 갱신 처리
- 호스트/참여자 역할 및 상태에 따른 UI 분기 처리
-
회원 기능 구현
- 마이페이지 화면 UI 구성 및 입력값 상태 관리
- 마이페이지 구성 및 백엔드 API 연동
-
공통 응답 구조 및 예외 처리 구현
- REST 구조와 공통 응답 바디 설계 및 아키텍처 구축
- 예외 처리 레이어를 분리한 공통 에러 처리 아키텍처 구축
-
주변 주소 인메모리 적재 리팩토링
- mysql + h2 멀티 데이터베이스 설계
- 서비스 기동 시 주변주소 저장 기능을 활용한 H2 적재 방식 구현
-
포인트 기능 구현
- 에스크로 결제 흐름 설계 후 주최자 정산 시 포인트 이전 로직 구현
- 카카오페이 테스트 API를 활용한 충전 로직 구현
- 회원가입
- 아이디 중복확인
- 닉네임 중복확인
- 로그인
- 로그아웃
- 카카오 주소 검색
- 주소 기반 좌표 변환
- 주변 주소 저장
- 마이페이지 주소 조회
- 공동구매 목록 조회
- 공동구매 상세 조회
- 공동구매 개설
- 공동구매 참여 신청
- 공동구매 진행 상태 확인
- 공동구매 시작 시 채팅방 생성
- 공동구매 참여자 간 메시지 송수신
- STOMP 기반 실시간 채팅 흐름 구성
- 내 정보 조회
- 내 주소 조회
- 내 주소 변경
- 내가 참여한 공동구매 조회
- 내가 개설한 공동구매 조회
- 포인트 충전
- Java 17 이상
- MySQL (또는 로컬 H2 Database)
src/main/resources/application.yml파일에 데이터베이스 접속 정보 및 JWT Secret Key 등 환경 변수 설정이 필요함
# 1. 저장소 클론
git clone [https://github.com/AieBestUniverse/groupBuyingServer.git](https://github.com/AieBestUniverse/groupBuyingServer.git)
# 2. 디렉토리 이동
cd groupBuyingServer
# 3. 프로젝트 실행 (Mac/Linux)
./gradlew bootRun
# 3. 프로젝트 실행 (Windows CMD/PowerShell)
gradlew.bat bootRun# Mac/Linux (테스트 제외 빌드: ./gradlew build -x test)
./gradlew build
# Windows
gradlew.bat build
src/
main/java/com/example/groupbuyingweb/
config/
controller/
service/
repository/
domain/
entity/
dto/
request/
response/
enums/
core/
api/
error/
security/
scheduler/
init/
main/resources/
application.yml
- 애플리케이션 전반 설정 관리 패키지
- Security, JWT 인증, Swagger, WebMvc, DataSource 등 환경 설정 중앙화로 유지보수성 향상
- 클라이언트 요청 최초 처리 계층
- 요청 데이터 수신 후 Service 계층 위임 및 결과 반환
- 비즈니스 로직 배제, 요청/응답 처리 집중
- 핵심 비즈니스 로직 담당 계층
- 기능별로 Service 클래스 세분화 (단일 책임 원칙, SRP 적용)
- Controller와 Repository 간 데이터 처리 및 검증 로직 수행으로 재사용성 및 유지보수성 극대화
- 데이터베이스 접근 계층
- Spring Data JPA 활용한 CRUD 및 조회 기능 구현
- 데이터 저장소 접근 로직 분리로 Service 계층 의존성 최소화
- 데이터베이스 테이블 매핑 JPA Entity 클래스 관리
- 공동구매, 회원, 채팅방, 참여 내역 등 핵심 도메인 객체 포함
- 계층 간 데이터 전달용 DTO(Data Transfer Object) 관리
- 모든 주요 기능에 대해 Request / Response DTO 별도 구성
- Entity 직접 노출 방지 및 데이터 검증/응답 형식 표준화, 계층 간 결합도 감소
- 시스템 전반 상수 값 관리 패키지
- 상태값, 카테고리 등을 Enum 클래스로 구조화하여 하드코딩 방지 및 재사용성/안정성 향상
- 애플리케이션 공통 기능 관리
api/: 공통 응답 형식(ApiResponse) 관리error/: GlobalExceptionHandler 기반 예외 처리 일원화security/: JWT 인증 및 인가 등 보안 처리scheduler/: 공동구매 상태 변경 등 스케줄링init/: 서버 시작 시 초기 데이터 마이그레이션
- 애플리케이션 실행 환경 설정(
application.yml) 및 정적 리소스 관리
-
계층형 아키텍처 적용
- Controller → Service → Repository 구조로 각 계층 책임 명확히 분리
-
Service 계층 세분화 및 역할 강화
- 핵심 비즈니스 로직을 기능별 Service 클래스로 완전히 분리하여 재사용성 향상 및 단일 책임 원칙 준수
-
기능 단위 DTO 구조화
- 요청(Request)과 응답(Response) DTO를 각 기능별로 1:1 분리 구성하여 데이터 전달 구조 명확화 및 Entity 노출 차단
-
Enum 기반 재사용성 확보
- 카테고리, 진행 상태, 권한 등 시스템 공통 기준값을 Enum 클래스로 설계해 문자열 하드코딩 제거 및 안정성 극대화
-
공통 예외 및 인증/인가 체계
- GlobalExceptionHandler 기반 일관된 예외 응답 체계 구축 및 JWT 기반 사용자 인증/권한 관리 구현
.GIF)