🏦 모임 벌금 통장 서비스 갓생루팅

목차 바로가기

🏦 프로젝트 개요
🧩 주요 문제 해결 사례
└ 문제 1: 이체 시 중복 처리
└ 문제 2: 잔액 업데이트 동시성
└ 문제 3: 이체 중 오류 발생

📅 2024.09 ~ 2024.10👥 6명🛠 Spring Boot, Kafka, Redis

1) 프로젝트 개요

목표: 모임 구성원의 미션 수행을 기반으로 벌금·상금이 자동 정산되는 금융형 협업 서비스 백엔드 구축
배경: 혼자 습관 형성에 도전했지만 실패 경험이 반복됨 → 벌금·보상을 팀 단위로 묶어 상호 견제가 되면 효과적이라는 경험에서 출발해 서비스화
핵심 가치: 정확한 정산(ACID) · 중복 없는 이벤트 처리(idempotency) · 안전한 인증/인가(HTTP-Only Cookie, JWT)
프론트 요구사항 요약(연동):
- GPS/사진 기반 미션 판별
- 카카오톡 초대(링크) & 카카오맵 위치 표시
- 팀별 배팅 → 결과 반영 → 자동 정산/캘린더/갤러리

2) 아키텍처 개요

기술 스택:

Spring Boot · Java · MySQL · Redis(분산락/캐시) · Kafka(비동기 이벤트) · Docker · Jenkins

(배포: AWS EC2, Nginx 리버스 프록시)


[Client(Web/App)]
   │ REST API
   ▼
[Spring Boot Backend]
   ├─ Auth Service (JWT/쿠키)
   ├─ Mission Service (GPS/사진 메타)
   ├─ Betting Service (배팅/정산 대기)
   ├─ Settlement Service (정산/원장)
   ├─ Notification Service (Kafka 이벤트)
   └─ Media Service (S3 업로드/처리)

3) 핵심 시퀀스 설계

A. 초대 및 가입

백엔드 → 초대 토큰 생성
카카오톡 링크로 전달
신규 사용자가 링크 클릭 → 회원가입 & 그룹 등록

B. 미션 판별

미션 생성 (missions)
사용자가 GPS/사진 업로드 → 서버 저장 → mission_proofs 생성
관리자 검증 또는 자동 검증 → verified='Y'

C. 배팅

사용자들이 특정 팀원의 미션 성공/실패에 베팅 (bets)
마감 시점까지 수정 가능

D. 정산

정산 트리거 (스케줄러/관리자 실행)
Redis 분산락으로 중복 실행 방지

4) ERD

5) 문제 및 해결 방법

문제 1: 이체 시 중복 처리 및 데이터 충돌 발생

상황

이체시 하나의 사용자가 빠르게 버튼을 여러 번 누를 때, 정산하기 요청이 여러 번 가는 경우가 있어서 하나의 이체 요청에 대해 중복 트랜잭션이 생성되는 문제가 있었습니다. 이로 인해 사용자가 원하지 않는 이체가 발생하거나, 오류가 발생하는 경우가 있었습니다.

선택지

선택지	장점	단점
1. 프론트엔드에서 요청 제한	단순하고, 요청이 두 번 들어올 경우를 원천차단	타 클라이언트 확장시 같은 문제 발생할 수 있음
2. 거래 고유 ID(ref_id) + Unique 제약조건	멱등성 보장	예외 처리 필요
3. 레디스 캐시 키로 요청 추적	빠름	TTL 설정 관리 필요

판단 근거

일단 요청 그 자체가 여러 번 오는 경우를 최소화 하기 위해서 1번은 우선적으로 적용하고 이체 트랜잭션에서 중요한 것은 데이터의 신뢰성이라고 생각하여 가장 안정적인 DB단에서 제약을 걸어서 체크하는 방식으로 중복을 방지하였습니다.

해결 방법

클라이언트 요청마다 UUID 기반 ref_id 생성
동일 ref_id 재요청 시, “이미 처리된 요청입니다.”를 최종적으로 반환

결과

중복 이체 0건
네트워크 재전송 상황에서도 안정적인 처리

문제 2 : 잔액 업데이트 동시성 충돌

상황

다른 사용자의 이체와 동시에 같은 계좌에 접근하면 잔액 계산이 꼬이는 경우가 발생하였습니다.

선택지	장점	단점
1. 낙관적 락	성능 우수, 락 경합 없음	충돌 시 재시도 필요
2. 비관적 락	완벽한 일관성 보장	락 대기시간 증가
3. Redis 분산락	확장성 좋음	인프라 관리 부담

판단 근거

서비스 트래픽이 낮고 단일 인스턴스 환경이었기 때문에

② 비관적 락 을 적용했습니다.

동시에 하나의 계좌에 접근하는 요청은 대기시켜 일관성 확보.

해결 방법


@Lock(LockModeType.PESSIMISTIC_WRITE)
Account findByIdForUpdate(Long id);

결과

동시 이체 요청 50건 테스트에서도 정확한 최종 잔액 유지
평균 이체 처리시간 1.0s → 1.3s (일부 증가했으나 안정성 확보)

문제 3: 이체 중 오류 발생 시 잔액 불일치 문제

상황

벌금 납부나 상금 배분 과정에서, 한 사용자의 잔액 차감이 성공하고 다른 사용자의 입금이 실패하면 총 계좌합 이 맞지 않는 불일치 문제가 생겼습니다.

선택지

선택지	장점	단점
① 단순 두 번의 DB UPDATE	구현 간단	원자성 보장 불가 (한쪽만 성공 가능)
② Spring @Transactional (단일 트랜잭션)	원자성 보장	서비스 계층 복잡도 증가
③ SAGA 패턴 (보상 트랜잭션)	분산 트랜잭션 대체 가능	구현 복잡, 서비스 규모 대비 과함

판단 근거

서비스가 단일 DB 내에서 동작했기 때문에 ② @Transactional 기반의 단일 트랜잭션이 가장 적절했습니다. 단, 트랜잭션 안에서 예외 발생 시 보상 로직을 구현하여, 모든 이체가 실패 시 이전 상태로 완전히 복구되도록 설계했습니다.

해결 방법


@Transactional
public void transfer(Long fromId, Long toId, BigDecimal amount) {
    Account from = accountRepository.findById(fromId)
        .orElseThrow(() -> new AccountNotFoundException());
    Account to = accountRepository.findById(toId)
        .orElseThrow(() -> new AccountNotFoundException());
 
    if (from.getBalance().compareTo(amount) < 0) {
        throw new InsufficientBalanceException();
    }
 
    from.withdraw(amount);
    to.deposit(amount);
 
    transactionRepository.save(new Transaction(from, to, amount, LocalDateTime.now()));
}