[🔥TroubleShooting - TicToc🔥] 돈이 걸린 문제‼️ 1명만 입찰 성공 ✅, 4999명 입찰 실패 ❌

📌 프로젝트 소개

팀원 : 개인 프로젝트
기간 : 2025.01 ~ 진행 중
링크 : https://github.com/M-ung/TicToc_Server
서비스 내용 : 당신의 시간에 가치를 매기다, 시간 거래 경매 플랫폼

---

🔥TroubleShooting🔥

Problems

우리 서비스 "TicToc"의 가장 중요한 핵심 기능에 대해서 고민할 시간이다. 바로 "입찰 기능" 이다.
단순히 Bid 엔티티를 저장해서 입찰을 하는 방식은 동시성 문제가 발생할 수 있다.

여기서 동시성 문제란?
동시성 문제는 여러 개의 트랜잭션이 동일한 데이터에 동시 접근하여 예기치 않은 결과가 발생하는 문제를 의미한다.
예를 들어 우리 TicToc 서비스의 입찰 기능은 여러 사용자가 같은 경매에 동시에 입찰할 때, 입찰 결과가 예상과 다르게 반영되거나 데이터 충돌이 발생할 수 있다.

우리 서비스는 돈으로 입찰을 하기 때문에 정확히 입찰 결과를 알려야 한다. 그렇기 때문에 "입찰 기능"을 구현하면서 오랜 고민을 하게 되었다.

궁금적으로 문제는 아래와 같다.

1. 동일한 데이터에 동시 접근하는 동시성 문제 해결
2. 여러 접근 중에 딱 하나의 접근만 가져오고 나머지는 롤백

---

How

위 문제들을 해결하기 위해 원자적 연산과 낙관적 락을 혼합해서 활용해 보았다.

여기서 원자적 연산이란?
원자적 연산은 여러 개의 연산이 하나의 단위로 실행되어서 중간에 다른 연산이 끼어들 수 없도록 보장하는 방식이다.
즉, 입찰 시 경매 가격보다 높은 경우에만 입찰을 진행하도록 원자적인 UPDATE SQL을 활용하여 동시성 문제를 해결하려고 한다.

여기서 낙관적이란?
낙관적 락은 데이터를 수정할 때, 예상치 못한 변경이 발생했는지 확인하는 방식이다.
보통 엔티티에 버전 필드를 추가하여 변경이 발생했을 경우 예외를 던지고, 다시 시도하도록 한다.
우리 서비스의 경우 낙관적 락을 직접 사용하지 않고, 원자적 연산 후 예외 처리 방식으로 적용하려고 한다.

---

Process

아래는 원자적 연산을 적용한 updateBidIfHigher 코드이다. 이를 입찰할 때 바로 실행하여 현재 currentPrice가 입찰 금액보다 높은지 확인하고 만약 이보다 낮을 때 0을 반환하는 로직이다.

📍 Bid.java

@Getter
@Entity
@Builder
@AllArgsConstructor
@NoArgsConstructor(access = AccessLevel.PROTECTED)
@Table(name = "bid")
public class Bid {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    private Long auctionId;
    private Long bidderId;
    private Integer bidPrice;
    @Enumerated(EnumType.STRING)
    private BidStatus status;
}

📍 AuctionRepository.java

public interface AuctionRepository extends JpaRepository<Auction, Long>, AuctionRepositoryCustom {
    @Modifying(clearAutomatically = true, flushAutomatically = true)
    @Query("UPDATE Auction a SET a.currentPrice = :price WHERE a.id = :auctionId AND a.currentPrice < :price")
    int updateBidIfHigher(@Param("auctionId") Long auctionId, @Param("price") Integer price);
}

0을 반환하게 된다면 BidException가 발생할 수 있도록 구현했다. 또 0이 아니라면 정상적으로 입찰 기능을 수행할 수 있도록 구현했다.

@Service
@Transactional
@RequiredArgsConstructor
public class BidCommandService implements BidCommandUseCase {
    private final AuctionRepositoryPort auctionRepositoryPort;
    private final BidRepositoryPort bidRepositoryPort;

    @Override
    public void bid(final Long userId, BidUseCaseReqDTO.Bid requestDTO) {
        if(auctionRepositoryPort.updateBidIfHigher(requestDTO) == 0) {
            throw new BidException(BID_FAIL);
        }
        var findAuction = auctionRepositoryPort.findAuctionById(requestDTO.auctionId());
        bidRepositoryPort.checkBeforeBid(findAuction);
        findAuction.start(userId);
        bidRepositoryPort.saveBid(Bid.of(userId, requestDTO));
    }
}

이제 정상적으로 동작하는지 확인하기 위해 테스트 코드를 돌려보겠다.
테스트 코드의 시나리오는 5000명이 동시에 입찰을 시도했을 때 "1명만 입찰 성공 ✅, 4999명 입찰 실패 ❌" 해야 한다.

📍 첫 번째 테스트 코드

    @Test
    @DisplayName("입찰 시 동시성 이슈 발생에 대한 테스트")
    public void 입찰_시_동시성_이슈_발생에_대한_테스트() throws InterruptedException {
        CountDownLatch latch = new CountDownLatch(NUM_USERS);
        ExecutorService executorService = Executors.newFixedThreadPool(NUM_USERS);

        AtomicInteger successUsers = new AtomicInteger(0);
        AtomicInteger failedUsers = new AtomicInteger(0);

        for (int i = 1; i <= NUM_USERS; i++) {
            final Long userId = (long) i;
            executorService.submit(() -> {
                try {
                    bidCommandService.bid(userId, new BidUseCaseReqDTO.Bid(auction.getId(), BID_PRICE));
                    successUsers.incrementAndGet();
                } catch (BidException e) {
                    failedUsers.incrementAndGet();
                    assertThat(e.getMessage()).isEqualTo(ErrorCode.BID_FAIL.getMessage());
                } finally {
                    latch.countDown();
                }
            });
        }

        latch.await();

        Auction updatedAuction = auctionRepositoryPort.findAuctionById(auction.getId());
        assertThat(updatedAuction.getCurrentPrice()).isEqualTo(BID_PRICE);
        assertThat(successUsers.get()).isEqualTo(1);
        assertThat(failedUsers.get()).isEqualTo(NUM_USERS-1);
        executorService.shutdown();
    }

테스트를 돌려본 결과 테스트를 정상적으로 통과하였기에 동시성 문제를 잘 해결했다고 생각했다.

하.지.만

이는 착각이었다... 테스트 코드를 저렇게 작성해서 정상적으로 입찰 기능을 구현했다고 착각했다.

테스트 코드를 아래처럼 바꿔보겠다.

📍 두 번째 테스트 코드

    @Test
    @DisplayName("입찰 시 동시성 이슈 발생에 대한 테스트")
    public void 입찰_시_동시성_이슈_발생에_대한_테스트() throws InterruptedException {
        CountDownLatch readyLatch = new CountDownLatch(NUM_USERS);
        CountDownLatch startLatch = new CountDownLatch(1);
        CountDownLatch doneLatch = new CountDownLatch(NUM_USERS);
        ExecutorService executorService = Executors.newFixedThreadPool(NUM_USERS);

        AtomicInteger successUsers = new AtomicInteger(0);
        AtomicInteger failedUsers = new AtomicInteger(0);
        AtomicReference<Long> successUserId = new AtomicReference<>();
        AtomicReference<Integer> successBidPrice = new AtomicReference<>();

        for (int i = 1; i <= NUM_USERS; i++) {
            final Long userId = (long) i;
            executorService.submit(() -> {
                try {
                    readyLatch.countDown();
                    startLatch.await();
                    int bidPrice = (int) (BID_PRICE * userId);
                    bidCommandUseCase.bid(userId, new BidUseCaseReqDTO.Bid(auction.getId(), bidPrice));
                    successUserId.set(userId);
                    successBidPrice.set(bidPrice);
                    successUsers.incrementAndGet();
                } catch (Exception e) {
                    failedUsers.incrementAndGet();
                    assertThat(e.getMessage()).isEqualTo(ErrorCode.BID_FAIL.getMessage());
                } finally {
                    doneLatch.countDown();
                }
            });
        }

        readyLatch.await();
        startLatch.countDown();
        doneLatch.await();
        executorService.shutdown();

        Auction findAuction = auctionRepositoryPort.findAuctionById(auction.getId());
        Bid findBid = bidRepositoryPort.findBidByAuctionId(findAuction.getId());
        assertThat(findAuction.getCurrentPrice()).isEqualTo(successBidPrice.get());
        assertThat(findBid.getBidderId()).isEqualTo(successUserId.get());
        assertThat(successUsers.get()).isEqualTo(1);
        assertThat(failedUsers.get()).isEqualTo(NUM_USERS-1);
        executorService.shutdown();
    }

이는 입찰 금액이 점점 증가하도록 바꾸었다. 이렇게 작성했을 때 테스트는 어떤 결과가 나올까?

이게 무슨 일일까..?

이는 내 완전한 착각이었다. 원자적 연산을 잘 적용했다고 생각했는데, 테스트 코드를 잘못 작성해서 성공했다고 오해했다. 단순히 currentPrice보다 높지 않다면 0을 반환하게 쿼리문을 작성했고, 테스트 코드 또한 처음에 BID_PRICE를 하나로 고정해 놨기에 통과할 수 있었던 거다.

📍 첫 번째 테스트 시나리오

첫 번째 테스트 시나리오

currentPrice = 1000
BID_PRICE = 1500

1차 Bid : 1000(currentPrice) < 1500(BID_PRICE) -> Bid 정상적으로 수행

currentPrice = 1500
BID_PRICE = 1500

2차 Bid : 1500(currentPrice) < 1500(BID_PRICE) -> Bid 실패

currentPrice = 1500
BID_PRICE = 1500

3차 Bid : 1500(currentPrice) < 1500(BID_PRICE) -> Bid 실패

.
.
.
.

위 같은 시나리오이기 때문에 통과할 수 있었다.

아래는 두 번째 테스트 코드 시나리오이다.

📍 두 번째 시나리오

두 번째 시나리오

currentPrice = 1000
BID_PRICE = 1500

1차 Bid : 1000(currentPrice) < 1500(BID_PRICE) -> Bid 정상적으로 수행

currentPrice = 1500
BID_PRICE = 3000

2차 Bid : 1500(currentPrice) < 3000(BID_PRICE) -> Bid 정상적으로 수행

currentPrice = 3000
BID_PRICE = 4500

3차 Bid : 3000(currentPrice) < 4500(BID_PRICE) -> Bid 정상적으로 수행

.
.
.
.

위 같은 시나리오이기 때문에 모든 입찰이 성공하고 테스트 코드는 실패하게 된 것이다.

그럼.. 다시 새롭게 설계를 해야 할 것 같다.

위 문제를 해결하기 위해서 "분산 락" 을 활용해서 단 하나의 입찰만 성공할 수 있게 구현해 보았다.

또 단순히 분산 락만 적용하는 것이 아니라 락을 획득했을 때, 원자적 연산을 통해 바로 currentPrice를 DB에 업데이트해 주었다. 그 후 입찰 로직을 순차적으로 진행했고, 바로 락을 해제했을 때 대기 중이었던 입찰이 성공될 경우를 대비해 Thread.sleep(RedisConstants.LOCK_LEASE_TIME * 1000); 를 추가하여 딜레이 기능을 추가했다.

코드는 아래와 같다.

📍 BidCommandService.java

@Service
@Transactional
@RequiredArgsConstructor
public class BidCommandService implements BidCommandUseCase {
    private final AuctionRepositoryPort auctionRepositoryPort;
    private final BidRepositoryPort bidRepositoryPort;
    private final RedissonClient redissonClient;

    @Override
    @Transactional
    public void bid(final Long userId, BidUseCaseReqDTO.Bid requestDTO) {
        String lockKey = RedisConstants.LOCK_PREFIX + requestDTO.auctionId();
        RLock lock = redissonClient.getLock(lockKey);
        try {
            if (!lock.tryLock(Math.round(RedisConstants.LOCK_WAIT_TIME), RedisConstants.LOCK_LEASE_TIME, TimeUnit.SECONDS)) {
                throw new BidException(BID_FAIL);
            }
            var findAuction = auctionRepositoryPort.findAuctionById(requestDTO.auctionId());

            bidRepositoryPort.checkBeforeBid(findAuction);
            findAuction.startBid(userId);

            Integer beforePrice = findAuction.getCurrentPrice();
            int updatedRows = auctionRepositoryPort.updateBidIfHigher(requestDTO);
            if (updatedRows == 0) {
                throw new BidException(BID_FAIL);
            }
            bidRepositoryPort.saveBid(Bid.of(userId, requestDTO, beforePrice));
            Thread.sleep(RedisConstants.LOCK_LEASE_TIME * 1000);
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
            throw new BidException(BID_FAIL);
        } finally {
            if (lock.isHeldByCurrentThread()) {
                lock.unlock();
            }
        }
    }
}

또 "입찰 기능" 은 중요한 기능이기에 Bid 테이블에 beforePrice 라는 입찰 성공 전 가격을 저장하고, @Table(name = "bid", uniqueConstraints = @UniqueConstraint(columnNames = {"auctionId", "beforePrice"})) 유니크 제약 조건을 추가했다.

유니크 제약 조건으로 인해 Bid 테이블에는 하나의 auctionId에는 중복되는 beforePrice가 올 수 없기에 같은 경매가에 입찰을 성공하는 Bid가 2개 이상 존재할 수 없게 된다.

위 코드의 시나리오는 아래와 같다.

---

Result

문제 해결로 아래와 같은 결과를 얻었다.
1. “원자적 연산 + 분산 락 + 딜레이 + 유니크 제약 조건” → 동시성 문제 해결.
2. 5,000건 기준, 동시 입찰 요청 중 1건 성공, 4,999건 실패.
3. 데이터 일관성을 100% 보장.
4. 서비스의 핵심 기능 “입찰” 을 매우 안전하게 운영 가능.

최종적으로 "원자적 연산 + 분산 락 + 딜레이 + 유니크 제약 조건" 을 활용하여 5000명 이 동시에 입찰 시도를 했을 때, "1명만 입찰 성공 ✅, 4999명 입찰 실패 ❌" 테스트를 통과할 수 있었다.

---

Thoughts

"입찰 기능" 은 우리 서비스 "TicToc" 에서 가장 중요한 기능이고 그렇기 때문에 오랜 시간이 걸렸던 것 같다. 테스트 코드를 잘못 작성하여 초반에 성공했다고 오해를 갖게 되었다.

이 과정을 통해 단순히 비즈니스 로직을 구현하는 것이 아니라, 테스트 코드의 완성도가 시스템의 신뢰성을 결정한다는 것을 배울 수 있었다.

"입찰 기능" 하나를 구현하는 데에 많은 시간 동안 많은 공부를 할 수 있었다. 단순히 어노테이션을 붙이 동시성 제어에서 끝내는 것이 아닌 Redis를 활용하여 분산 락을 활용했고, 단순히 분산 락에서 끝내는 것이 아닌 딜레이 전략을 활용해 안전성을 보장했다. 또 이에서 끝내는 것이 아닌, 원자적 연산과 유니크 제약 조건을 통해 더욱 안전성을 보강했다.

이번 경험을 통해 동시성 제어의 중요성을 다시 깨달았고, 테스트 코드의 신뢰성이 서비스 안정성에 직접적인 영향을 미친다는 점을 배울 수 있었다. 앞으로 테스트 코드를 꾸준히 작성하여 더욱 안정성과 신뢰성을 보장하는 개발자로 성장해야겠다.

---