Mokoco

지역 기반으로 수리 요청자와 수리자를 연결하고, 제안 → 채택 → 채팅 → 거래 → 결제 → 후기까지 하나의 흐름으로 제공하는 P2P 수리 매칭 플랫폼

사용자는 자신의 활동 지역을 기반으로 수리 요청을 등록하거나 주변의 수리 요청을 확인할 수 있다. 수리자는 예상 가격과 작업 내용을 제안하고, 의뢰자가 제안을 채택하면 전용 채팅과 거래 절차가 시작된다.

---

주요 기능

지역 기반 수리 요청

• 사용자의 활동 지역 설정
• 지역 코드 기반 수리 요청 조회
• 수리 요청 등록, 수정, 삭제
• 카테고리별 수리 요청 조회
• 게시글 이미지 첨부
• AI(Gemini) 기반 게시글 작성 도우미 — 수리를 원하는 제품·부분 사진을 등록하면 초안을 생성, 요청사항을 지정해 최대 3회까지 재작성 가능

수리 제안 및 매칭

• 수리자가 수리 요청에 예상 가격과 작업 내용을 제안
• 의뢰자가 원하는 제안을 채택
• 동일 수리 요청에서 하나의 제안만 최종 채택
• 채택 취소 및 재채택 지원
• 채택 결과에 따라 거래 상태 자동 변경

거래 관리

• 제안 채택 시 수리 거래 생성
• 상품 전달, 수리 진행, 수리 완료 요청 등 거래 단계 관리
• 거래 상태에 따른 허용 작업 제한
• 거래 완료 이후 잘못된 재진행 방지
• 중복 요청에도 동일한 거래 상태를 유지하도록 멱등성 처리

1:1 채팅

• 채택된 의뢰자와 수리자 간 전용 채팅방 제공
• 실시간 메시지 송수신
• 이미지 및 파일 첨부
• 채팅 참여자만 접근 가능
• 동일 거래 또는 제안에 대한 중복 채팅방 생성 방지

수리 계약

• 채팅방을 기반으로 수리 계약 내용 작성
• 의뢰자와 수리자가 계약 내용을 확인하고 진행
• 거래 정보와 연계된 계약 관리
• AI 기반 계약서 초안 작성 보조 기능 제공

결제

• PortOne 기반 결제 연동
• 결제 전 서버에서 주문 정보 생성
• 클라이언트가 전달한 금액 대신 서버에 저장된 주문 금액 기준으로 검증
• 결제 금액, 통화, 결제 상태를 결제사 API를 통해 재확인
• 동일 결제 요청에 대한 중복 처리 방지
• Webhook을 통한 결제 결과 처리

후기 및 사용자 기능

• 완료된 거래에 대한 후기 작성
• 평점 및 이미지 첨부
• 사용자 프로필 관리
• 활동 지역 변경
• 의뢰 및 수리 활동 내역 조회
• 알림 조회 및 읽음 처리
• 이력서 작성 및 조회

관리자 기능

• 회원/거래/신고 현황 대시보드
• 게시글 목록 조회 및 강제 삭제(진행 중인 거래가 있는 글은 제한)
• 회원 권한 변경(일반 ↔ 관리자) 및 계정 정지
• 신고 접수함 조회 및 처리(해결/기각)
• 결제·정산 상세 내역 조회

---

기술적 구현 포인트

사용자 ID 기반 인증

초기에는 이메일을 JWT의 사용자 식별값으로 사용했지만, 이메일은 변경 가능한 정보이기 때문에 서비스 간 식별자로 적합하지 않다고 판단.

JWT Subject와 인증 계층의 사용자 식별 기준을 userId로 변경하고 공통 인증 객체인 LoginUser(userId, email)를 사용하도록 개선. 인증은 전 서비스가 Authorization: Bearer 하나로 통일됨(레거시 X-User-Email 헤더는 더 이상 신뢰하지 않음).

다만 도메인 데이터의 소유권 판별 기준은 서비스마다 다름 — 채팅방/계약은 userId(Long)를 쓰지만, 게시글·제안·후기·이력서·결제·알림은 여전히 이메일을 기준으로 함(전환 작업이 일부만 완료된 상태).

동시 제안 채택 제어

하나의 수리 요청에 여러 제안이 동시에 채택될 경우 거래가 중복 생성될 수 있는 문제를 고려.

게시글 조회 시 비관적 락(PostRepository.lockById)을 적용하고, fix_deals/proposals에 활성 행만 유일하게 만드는 generated column 기반 UNIQUE 제약을 함께 사용하여 애플리케이션과 데이터베이스 양쪽에서 중복 거래 생성을 방지.

다중 스레드로 동시 채택 요청을 발생시키는 별도의 동시성 테스트는 아직 없음 — 현재는 락·제약 자체의 존재로만 방지하고 있어 추가 검증이 필요한 부분.

중복 요청에 대한 멱등성

네트워크 지연이나 사용자의 중복 클릭으로 동일 API가 여러 번 호출될 수 있는 상황을 고려.

• 동일 제안 재채택 시 거래 중복 생성 방지
• 동일 거래 단계 API 반복 호출 시 상태 유지
• 동일 채팅방 생성 요청 시 기존 채팅방 반환
• 동일 결제 요청 시 기존 결제 결과 재사용

등의 방식으로 주요 거래 API가 중복 요청에도 안정적으로 동작하도록 구현.

실제 MySQL 기반 테스트

개발 환경과 테스트 환경의 DB 차이로 인해 발생할 수 있는 문제를 줄이기 위해 주요 서비스의 통합 테스트에 Testcontainers를 적용.

테스트 실행 시 실제 MySQL 컨테이너를 생성하고 Flyway Migration을 실행한 뒤 JPA Entity와 DB Schema가 일치하는지 검증.

이를 통해 단순 H2 테스트가 아닌 실제 운영 DB 환경과 가까운 조건에서 다음 항목을 검증.

• Flyway Migration (4개 서비스 공통 FlywaySchemaTest)
• 취소 후 재매칭처럼 "한 postId에 여러 행"이 남는 케이스에서 단순 조회가 깨지는 문제 (FixDealRepositoryTest)
• AI 재작성 횟수 한도의 원자적 차감/환불 (AiPostDraftRepositoryTest)

결제 검증(PaymentVerificationTest)이나 동시 요청 관련 테스트(제안 채택 동시성, 회원가입 중복, 채팅방 중복 생성)는 현재 코드베이스에 아직 없음 — 해당 로직 자체(PortOne 재조회, DB 제약)는 존재하지만 전용 테스트로 검증되지는 않은 상태.

서비스별 데이터 소유권 분리

각 서비스는 자신의 데이터베이스에 속한 Entity만 직접 관리하고, 다른 서비스의 데이터는 ID를 통해 참조하도록 구성.

현재는 데이터 보존을 위해 물리 DB를 공유하는 transitional architecture이며, 논리적 소유권 분리.

ex) 채팅 서비스는 Post, Proposal, FixDeal, User Entity를 직접 참조하지 않고 다음 식별값만 저장.

• postId
• proposalId
• fixDealId
• requesterId
• repairerId

---

Backend 구성

서비스	주요 역할
api-gateway	API 요청 라우팅 및 외부 요청 진입점
user-service	회원가입, 로그인, JWT, 사용자 정보, 지역 관리
post-service	수리 요청, 제안, 거래, 후기, 알림, 계약 관리
chat-service	채팅방, 실시간 메시지, 첨부파일 관리
payment-service	결제 주문, 결제 검증, Webhook 처리
common	공통 인증 객체 및 서비스 간 공유 계약

---

기술 스택

Backend

• Java 21
• Spring Boot
• Spring Security
• Spring Data JPA
• Spring Cloud OpenFeign
• Spring Cloud Gateway
• WebSocket / STOMP
• Gradle

Database

• MySQL
• Flyway

Test

• JUnit 5
• Mockito
• Testcontainers
• AssertJ

Frontend

• Next.js
• React
• Zustand

Infra / External API

• Docker
• Docker Compose
• GitHub Actions
• PortOne

---

테스트한 주요 시나리오

• 취소 후 재매칭된 거래에서 결제/후기/상태 조회가 깨지던 문제 재현 (FixDealRepositoryTest)
• 본인 게시글에 본인이 제안을 등록하려는 시도
• 요청자와 수리자가 동일 인물인 채팅방 생성 시도, 비참여자의 채팅방·메시지·첨부파일 접근
• 양측 서명 전 작업 시작/완료 확정 시도, 결제 미완료 상태에서 작업 시작 시도
• 계약 서명이 중복 요청돼도 서명 내용이 바뀌지 않는지(멱등성)
• 확장자가 아니라 실제 파일 바이트로 이미지/영상 여부를 판별해 위장 업로드(HTML을 이미지로 위장 등)를 막는지
• 변조·만료된 토큰, 다른 사용자 이메일로 토큰 재발급을 시도하는 상황
• 내부 서비스 키 없이 내부 전용 API를 직접 호출하는 상황

제안 채택/채팅방 생성/회원가입에 대한 동시 요청(다중 스레드) 테스트와 결제 검증 테스트는 아직 없음 — 위 목록은 실제 존재하는 테스트 기준으로 정리한 것.

---

프로젝트에서 중점적으로 다룬 부분

• 여러 요청이 동시에 들어올 때 발생하는 Race Condition
• API 중복 요청에 대한 멱등성
• 서비스 간 사용자 식별 기준 통일
• MSA 환경에서의 데이터 소유권 분리
• 실제 DB Constraint와 애플리케이션 로직의 이중 검증
• 결제 데이터 위변조 방지
• 서비스 간 책임 분리

팀과 기여

멋쟁이사자처럼 백엔드 24기 — 5팀 (FindAnswer)

이름	역할	담당 도메인
곽승욱	팀장	로그인(JWT·OAuth), 게시글 CRUD, CI/CD 배포(EC2·GitHub Actions)
변재웅	부팀장	후기 시스템, 프로필 및 거래 내역, 수리자 이력서, 결제 및 수수료 정산
박준성	팀원	1:1 실시간 채팅, 지역 정보 연동 조회, AI 전자계약서 및 게시글 초안 보조
정선우	팀원	실시간 알림 파이프라인, 카테고리/필터 검색 엔진, 서비스 정책 및 약관 페이지