💍 Wedge 프로젝트 회고 — 2주 만에 웨딩 매칭 플랫폼 만들기

2026.06.11 ~ 06.24 | 팀 프로젝트 | 4인 개발

프로젝트 소개

Wedge는 예비부부(CLIENT)와 웨딩 전문 프리랜서(FREELANCER)를 연결하는 매칭 플랫폼이다.

웨딩홀 패키지에 묶여 있으면 비싸고 선택지도 좁다. 반대로 프리랜서 입장에서는 실력이 있어도 홍보 채널이 없으면 일감을 못 찾는다. Wedge는 이 둘을 직접 연결하는 구조다. 핵심 차별점은 역경매 방식: 예비부부가 구인글을 올리면 프리랜서가 직접 제안서를 내고, 부부가 마음에 드는 제안을 수락하면 예약이 자동 생성된다.

기능 범위가 꽤 넓었다. 인증, 프로필, 포트폴리오, 북마크, 예약, 실시간 채팅, 리뷰, 커뮤니티, 구인/제안, AI 챗봇, CI/CD까지 — 이걸 2주 안에 4명이 완성해야 했다.

배포 URL: wedge-tawny.vercel.app
시연 영상: streamable.com/6dklaq

팀원과 역할 분담

내가 맡은 파트 — 기술적 결정들

1. 인증 시스템: JWT + RTR + OAuth2

인증은 대부분의 기능이 의존하는 뿌리라서 가장 먼저, 가장 꼼꼼하게 설계했다.

RTR(Refresh Token Rotation)

일반 JWT 구조에서 Refresh Token이 탈취되면, 만료될 때까지 공격자가 계속 쓸 수 있다. RTR을 적용하면 토큰을 사용할 때마다 새 토큰으로 교체되므로, 탈취 피해를 최소화할 수 있다.

구현 방식은 간단하다. Redis에 memberId를 키로 Refresh Token 1개만 유지한다. save()를 호출하면 기존 토큰이 덮어써지면서 자동으로 무효화된다. 누가 먼저 쓰든 나머지 한쪽은 차단된다.

refreshTokenRepository.save(RefreshToken.builder()
    .memberId(memberId)
    .token(newRefreshToken)  // upsert — 기존 토큰 자동 무효화
    .build());

이메일 인증 상태 머신

Redis 키를 두 개로 분리했다: 인증 코드(TTL 5분)와 완료 플래그(TTL 30분). 역할과 만료 시간이 다르기 때문에 하나로 합칠 수 없다. 인증 코드 검증 즉시 삭제해서 1회용을 보장하고, 회원가입 완료 시 플래그도 삭제해서 중복 가입을 차단한다. DB 대신 Redis를 쓴 이유는 TTL 덕에 만료 배치 작업이 필요 없고, 조회도 ~1ms로 빠르기 때문이다.

OAuth2 (Google + Kakao) 통합

구글과 카카오는 JSON 응답 구조가 다르다. providerId, email, name의 경로가 제각각이다. OAuth2MemberService.loadUser()에서 provider별 파싱만 다르게 처리하고, 그 이후는 동일한 Member 엔티티로 통합했다. 프론트엔드는 로그인 경로와 상관없이 JWT 하나로만 통신한다.

2. Mixed Content & Caddy 리버스 프록시

배포 직전에 생각지 못한 문제가 터졌다. Vercel(HTTPS)에서 AWS EC2(HTTP, 8080) API를 호출하니 브라우저가 Mixed Content 정책으로 전부 차단했다.

브라우저 → Vercel(HTTPS) → AWS EC2:8080(HTTP) ← 차단!

해결책은 Caddy였다.

api.wedge.o-r.kr {
    reverse_proxy localhost:8080
}

이 두 줄이 전부다. 도메인을 적으면 Caddy가 Let's Encrypt에서 인증서를 자동 발급하고, 만료 30일 전에 알아서 갱신한다.

브라우저 → Vercel(HTTPS) → Caddy(HTTPS, 443) → Spring Boot(HTTP, 8080)

Spring Boot에 SSL을 직접 붙이면 keystore 설정, 인증서 갱신 시 재시작이 필요한데, Caddy로 분리하면 그 복잡함이 사라진다. 2주짜리 프로젝트에서 인프라에 쓸 수 있는 시간은 제한적이었고, Caddy 덕분에 인프라 세팅 시간을 크게 줄일 수 있었다.

3. CI/CD 파이프라인

dev 브랜치에 push되면 CI가 돌고, main에 머지되면 자동 배포된다.

CI: GitHub Actions가 MySQL 8.0 + Redis 서비스 컨테이너를 직접 띄워서 통합 테스트를 돌린다. Mock이 아니라 실제 DB에 쿼리를 날린다. 테스트가 하나라도 실패하면 PR 머지가 차단된다.

CD: bootJar 빌드 → Docker 이미지 빌드 → Docker Hub 푸시(latest + commit SHA 태그) → SSH로 EC2 접속 → 컨테이너 교체.

EC2에서 직접 Gradle 빌드하면 t2.micro(메모리 1GB)가 OOM으로 죽는다. 그래서 GitHub Actions에서 빌드해서 완성된 이미지만 EC2로 당겨오는 구조를 택했다. commit SHA 태그를 따로 붙여두는 이유는 롤백을 위해서다. latest만 있으면 이전 버전으로 돌아가기 어렵다.

Docker 멀티 스테이지 빌드도 적용했다. Stage 1(JDK + Gradle)에서 빌드하고, Stage 2(JRE만)에서 jar를 복사해 실행한다. 최종 이미지에 JDK와 소스코드가 들어가지 않아서 이미지가 ~300MB 가벼워진다.

배포 흐름 전체:

조직 레포 dev → main 머지
    ↓ (포크 자동 동기화)
개인 포크 main 업데이트
    ↓ (CD 트리거)
GitHub Actions: 빌드 → Docker Hub
    ↓ (SSH)
AWS EC2: pull → 컨테이너 교체 → 완료

4. 구인/제안 시스템

구인글에서 제안서 수락까지 이어지는 흐름을 설계했다. 제안서가 수락되면 예약이 자동 생성된다. DB 제약도 꼼꼼하게 걸었다: 구인글 동시 등록 최대 3건, 제안서 동시 제출 최대 5건. 마감된 구인글은 수정 차단, proposals 테이블에 (recruit_post_id, freelancer_profile_id) 복합 UNIQUE 키로 중복 제안을 막았다.

5. 커뮤니티 게시판

REVIEW/TIP 카테고리로 분리된 커뮤니티 게시판을 구현했다. 소프트 삭제(is_deleted)를 적용해서 데이터는 남기고 노출만 끄는 구조다. 후반에 이미지 첨부 기능과 프리랜서 언급 기능까지 추가됐다.

팀 협업: 잘 된 것들

Git 전략이 단순하고 명확했다. dev 브랜치에서 기능 브랜치를 따고, PR을 통해 합쳤다. CI가 붙어 있으니 깨진 코드가 dev에 섞이는 일이 거의 없었다.

역할 분리가 깔끔했다. 백엔드 4명이 도메인 단위로 나눠서 작업했는데, 인터페이스(API 스펙)만 맞추면 서로 크게 충돌하지 않았다. 프론트는 이민서 님이 디자인 시스템과 마이페이지를 담당하면서 UI 일관성을 잡아줬다.

Mock 없이 통합 테스트. CI에서 실제 MySQL과 Redis를 띄워서 테스트했기 때문에 "로컬에서는 됐는데 서버에서 안 됨" 같은 상황이 훨씬 줄었다.

아쉬운 것들

t2.micro의 한계. 메모리 1GB로 MySQL + Redis + Spring Boot를 동시에 돌리니 가끔 OOM이 났다. Swap 2GB를 추가해서 겨우 버텼는데, 실제 서비스라면 인스턴스 스펙을 올려야 한다.

테스트 커버리지. CI에서 통합 테스트를 돌리긴 했지만, 작성된 테스트의 양이 충분하지 않았다. 빠르게 기능을 만드는 데 집중하다 보니 엣지 케이스 테스트가 부족했다.

AI 기능과 채팅이 후순위로 밀렸다. 원래 MVP 우선순위에서 하위였던 기능들이 마지막에 붙었다. 완성은 됐지만 더 다듬을 시간이 없었다.

배포 자동화의 빈틈. 조직 레포 → 개인 포크 동기화를 GitHub Actions로 자동화했는데, 간혹 sync가 늦거나 실패하는 케이스가 있었다. 더 견고한 파이프라인이 필요하다.

배운 것

2주는 생각보다 훨씬 짧다. 기능을 처음부터 완벽하게 만들려고 하면 아무것도 완성되지 않는다. MVP 우선순위를 정하고, 핵심이 아닌 것은 과감하게 뒤로 미루는 판단이 중요했다.

인증 시스템은 프로젝트 초반에 완성도 있게 설계해두길 잘했다. 모든 기능이 인증에 의존하기 때문에, 이게 불안정하면 팀 전체가 흔들린다.

Caddy는 정말 좋은 도구다. 단, ACME 챌린지를 위해 80포트가 열려 있어야 한다는 걸 처음에 몰라서 삽질했다.

CI/CD를 처음부터 구성해둔 게 팀 전체 생산성에 크게 기여했다. 수동으로 배포하느라 시간을 쓰지 않아도 됐고, 테스트가 자동으로 돌아가니 서로 코드를 합치는 데 덜 불안했다.

마무리

2주 안에 이 정도 규모의 서비스를 완성한 게 신기하게 느껴진다. 팀원 각자가 맡은 영역을 끝까지 책임졌고, 덕분에 배포 URL이 실제로 돌아간다.

다음에는 테스트 커버리지를 처음부터 챙기면서 만들고 싶다.

GitHub | 배포 URL | 시연 영상