[DB] 좋아요 수 - 동시성 이슈와 해결 전략 : 비관적 락, 낙관적 락, 비동기 처리

정확성과 성능은 트레이드 오프 관계이다. 무결성을 높이기 위해 락을 강하게 걸면 성능이 희생되고, 반대로 성능 최적화에 집중하면 데이터 무결성이 깨질 수 있는 리스크가 발생한다. 개발자의 역할은 서비스 상황에 맞는 적절한 균형점을 찾는 것이다.

 

초당 수천 건의 요청이 쏟아지는 '좋아요' 기능을 데이터 유실 없이 처리하려면 어떻게 해야 할까? 핵심은 결국 동시성 제어에 있다. 명시적인 레코드 락으로 데이터의 정합성을 보장하는 비관적 락과, 락 없이 시스템의 처리량을 극대화하는 낙관적 락을 각각 구현하면서 두 방식의 차이를 비교하며, 서비스 상황에 맞는 최적의 선택지를 찾아가는 과정을 정리해 보려 한다.

 

먼저 좋아요 수에 대한 데이터의 특성을 이해해 보자.

첫 번째로, ‘좋아요 수’ 데이터는 아래와 같이 비교적 단순하게 처리되기 때문에 쓰기 트래픽은 그렇게 크지 않다.

1. 사용자가 게시글을 조회하고, 좋아요를 클릭한다.
2. 해당 게시물의 좋아요 수가 1 증가한다.

 

두 번째로, 데이터의 일관성이 중요하다. 100명이 좋아요 버튼을 눌렀다면, 좋아요 수는 100으로 표시되어야 한다. 아래처럼 거의 동일한 시점에서 두 트랜잭션이 실행되는 경우 문제가 발생할 수 있다.

시간	트랜잭션 A (사용자 A)	트랜잭션 B (사용자 B)	DB 상태 (like_count)
T1	게시글 100번 조회 (값: 10)		10
T2		게시글 100번 조회 (값: 10)	10
T3	10 + 1 = 11 계산		10
T4	11로 업데이트 실행(Commit)		11
T5		10 + 1 = 11 계산	11
T6		11로 업데이트 실행(Commit)	11

 

이런 특성을 가진 좋아요 수 데이터를 일관되게 관리하려면 어떻게 하면 좋을까?

 

가장 쉽게 생각할 수 있는 방법으로는 게시글 테이블에서 좋아요 수에 대한 컬럼을 추가하고 좋아요를 누를 때 해당 레코드의 락을 걸고 수정하는 방법이 있다. 즉, 게시글 테이블에 좋아요 수 컬럼을 추가하고, 좋아요가 생성되거나 삭제될 때마다 해당 컬럼을 업데이트하는 방식을 사용할 수 있다. 그러나 이처럼 게시글 테이블에서 직접 좋아요 수를 관리하면 다음과 같은 문제가 발생한다.

• 첫 번째는 레코드 락(Record Lock)으로 인한 성능 저하다.
  • 게시글과 좋아요는 생명주기와 트래픽의 성격이 완전히 다르다. 게시글은 작성자에 의해 가끔 수정되지만, 좋아요는 글을 조회하는 수많은 사용자에 의해 실시간으로 쓰기 작업이 발생한다. 만약 게시글 테이블에 좋아요 카운트가 포함되어 있다면, 초당 수천 건의 좋아요 요청이 발생할 때마다 해당 게시글 레코드에 락이 걸린다. 이로 인해 좋아요와 무관한 본문 조회나 댓글 작성을 시도하는 사용자까지 락이 해제될 때까지 대기하게 되어 시스템 전체의 성능이 저하된다.

 

• 두 번째는 분산 트랜잭션 처리의 복잡성이다. 좋아요 내역 저장과 카운트 업데이트가 서로 다른 데이터베이스나 마이크로서비스에서 일어날 경우, 두 작업의 원자성을 보장하기 위한 분산 트랜잭션 설계가 필요하며 이는 시스템의 복잡도를 크게 높이게 된다.
  • 단일 DB를 쓸 때는 좋아요 내역을 저장하고(A), 게시글의 좋아요 수를 +1 하는(B) 작업을 하나의 트랜잭션으로 묶기 쉽다. 하지만 서비스가 분리된 분산 환경에서는 A는 좋아요 서비스 DB에, B는 게시글 서비스 DB에 위치하게 된다.
  • 만약 좋아요 내역은 저장됐는데(A 성공), 네트워크 문제로 게시글 서비스의 카운트 업데이트가 실패하면(B 실패)? 실제 좋아요는 눌렸는데 숫자는 안 올라가는 데이터 불일치가 발생한다.
  • 이를 해결하려면 2PC(2-Phase Commit)나 Saga 패턴 같은 복잡한 기법을 도입해야 한다. 이는 개발 난이도를 높일 뿐만 아니라 시스템 전체 성능을 깎아먹는 주범이 된다.

 

• 세 번째로, 관심사의 분리 측면에서 이 설계는 적절하지 않다.
  • 좋아요라는 행위의 주인은 '좋아요 서비스'다. 그런데 좋아요 개수라는 데이터를 '게시글 서비스'가 들고 있으면, 게시글 서비스는 자기 책임도 아닌 '좋아요' 때문에 계속해서 DB 수정(Update) 요청을 받아야 한다.
  • 게시글 서비스를 수정하거나 배포할 때 좋아요 로직을 신경 써야 하고, 반대의 경우도 마찬가지다. 서비스 간의 결합도가 높아져서 나중에 서비스를 확장하거나 변경하기가 매우 힘들어진다.

 

• 네 번째로 리소스 경합의 불균형이다.
  
  • 연예인이나 유명 인플루언서의 게시글은 초당 수천 명의 사용자가 좋아요를 누른다.
  • 이때마다 게시글 테이블의 특정 행에 레코드 락(비관적 락)이 걸린다.
  • 이때 좋아요를 누르는 사람만 대기하는 게 아니라, 단순히 게시글 본문을 읽으려는 사람이나 댓글을 달려는 사람까지 게시글 테이블에 걸린 락 때문에 대기하거나 성능 저하를 겪게 된다.

결론적으로, 좋아요 수는 자주 변하는 데이터이므로, 이를 게시글이라는 무거운 본체와 분리하여 별도의 서비스에서 관리하는 것이 분산 환경의 확장성과 성능 면에서 훨씬 유리하다.

---

0. Record Lock

레코드 락은 테이블의 행 데이터에 대한 잠금을 거는 것을 말한다.

레코드 락을 통해 여러 명의 사용자가 동시에 레코드를 수정하고 조회하는 동안 데이터의 무결성, 경쟁 상태를 방지할 수 있다.

 

1. 데이터의 무결성 (Data Integrity)

데이터 무결성은 데이터베이스에 저장된 데이터가 정확성, 일관성, 유효성을 유지하는 것을 말한다. 즉, 어떤 상황에서도 데이터가 오염되지 않고 믿을 수 있는 상태여야 한다는 뜻이다.

동시성 제어 측면에서 무결성이 깨지는 사례는 다음과 같다.

• 일관성 결여: 수정 중인 데이터를 다른 사용자가 읽어갈 때 발생하는 불일치 현상이다.
• 데이터 손실: 여러 사용자가 동시에 같은 데이터를 수정하여 한 명의 수정 사항이 사라지는 경우다.

 

2. 경쟁 상태 (Race Condition)

경쟁 상태는 두 개 이상의 프로세스가 공유 자원에 동시에 접근하여 그 실행 결과가 접근 순서에 따라 달라지는 현상을 말한다.

대표적인 예시인 갱신 손실(Lost Update) 시나리오는 다음과 같다.

1. 재고가 10개인 상품을 사용자 A와 B가 동시에 조회하여 둘 다 10개로 확인한다.
2. 사용자 A가 1개를 빼서 9로 저장한다.
3. 사용자 B도 자신이 확인했던 10을 기준으로 1개를 빼서 9로 저장한다.
4. 실제로는 2개가 팔렸으나 재고는 8이 아닌 9가 되어 데이터가 틀어지게 된다.

 

3. 레코드 락의 해결 방식

레코드 락은 특정 행(Row)에 대해 사용권을 선점하는 방식이다.

• 배타적 락: 사용자 A가 수정 중일 때 다른 사용자의 접근을 차단한다.
• 순차 처리: 나중에 온 사용자는 앞선 작업이 끝날 때까지 대기해야 하므로 경쟁 상태가 물리적으로 방지된다.
• 무결성 보장: 모든 수정이 순차적으로 이루어지므로 최종적으로 데이터의 정확성이 유지된다.

요약하자면 레코드 락은 프로세스 간의 줄 세우기를 통해 데이터가 오염되는 것을 막는 핵심적인 장치다.

• SELECT … FOR UPDATE 구문을 통해 조회된 레코드들에 대해 배타적 락을 가져갈 수 있다. 

단계	트랜잭션 A (사용자 A)	트랜잭션 B (사용자 B)	DB (like_count)
1	SELECT ... FOR UPDATE (10 읽음)		10	A가 락 선점
2		SELECT ... FOR UPDATE 시도	10	B는 대기(Waiting)
3	10 + 1 = 11 계산 및 UPDATE		11
4	COMMIT (락 해제)		11
5		SELECT 성공 (갱신된 11 읽음)	11	B가 락을 획득하고 읽음
6		11 + 1 = 12 계산 및 UPDATE	12

 

레코드 락은 데이터 무결성을 보장하지만, 잘못 사용하면 시스템 전체의 성능과 안정성을 떨어뜨리는 여러 단점이 존재한다.

---

1. Record Lock의 단점

1. 성능 저하 및 처리량 감소

가장 직접적인 단점은 시스템의 병렬 처리 능력이 떨어진다는 것이다.

• 직렬화 발생: 여러 사용자가 동시에 작업할 수 있는 환경임에도 불구하고, 락이 걸린 동안에는 다른 사용자들이 대기해야 한다. 이는 응답 시간을 늦추고 초당 처리 가능한 트랜잭션 수를 줄인다.
• 대기열 정체: 특정 인기 있는 레코드(예: 이벤트 상품 재고)에 락이 집중되면, 수많은 트랜잭션이 줄을 서게 되어 시스템 전체가 느려지는 병목 현상이 발생한다.

 

2. 데드락 (Deadlock, 교착 상태)

두 개 이상의 트랜잭션이 서로가 가진 락을 해제하기를 기다리며 무한 대기에 빠지는 상황이다.

• 예시: 트랜잭션 A가 1번 레코드를 잡고 2번을 요청하는데, 동시에 트랜잭션 B가 2번 레코드를 잡고 1번을 요청하면 두 작업 모두 영원히 멈춘다.
• 결과: DB 엔진이 이를 감지하여 강제로 하나를 종료(Rollback)시키지만, 이 과정에서 사용자 경험이 저하되고 추가적인 예외 처리 로직이 필요하다.

 

3. 락 에스컬레이션 및 범위 문제

락을 거는 과정에서 예상보다 큰 범위가 잠길 수 있다.

• 테이블 풀 스캔: WHERE 조건에 인덱스가 걸려 있지 않으면, DB는 어떤 레코드를 잠글지 모르기 때문에 테이블 전체를 훑으며 모든 행에 락을 걸거나 테이블 락을 시킨다.
• 의도치 않은 차단: 나는 행 하나만 수정하려고 했는데, 인덱스 문제로 인해 엉뚱한 레코드들까지 수정이 불가능해지는 상황이 발생할 수 있다.

 

4. 커넥션 고갈 (Connection Pool Starvation)

락을 획득하기 위해 대기하는 시간이 길어지면 해당 요청을 처리하는 DB 커넥션이 계속 점유된 상태로 남는다.

• 대기하는 트랜잭션이 많아지면 사용 가능한 커넥션 풀이 바닥나서, 락과 상관없는 다른 단순 조회 서비스들까지 모두 먹통이 되는 연쇄 장애로 이어질 수 있다.

 

5. 관리 및 설계의 복잡도 증가

락을 효율적으로 사용하려면 개발자가 고려해야 할 것이 많아진다.

• 트랜잭션을 최대한 짧게 유지해야 하고, 락을 거는 순서를 모든 로직에서 통일해야 데드락을 피할 수 있다.
• 서비스가 커질수록 어떤 로직에서 락을 잡고 있는지 추적하고 디버깅하기가 매우 까다로워진다.

---

2. 해결 방안

이러한 단점을 보완하기 위해 다음과 같은 전략을 섞어서 사용할 수 있다.

• 낙관적 락(Optimistic Lock): 락을 직접 걸지 않고 버전 번호 등을 통해 충돌 여부만 확인한다. (충돌이 적은 경우 유리)
• Redis 등의 캐시 사용: DB까지 오기 전에 분산 락을 통해 처리 속도를 높인다.
• 짧은 트랜잭션: 락을 잡는 시간을 최소화하도록 로직을 분리한다.

낙관적 락과 비관적 락을 사용하여 좋아요 서비스를 게시글 서비스와 분리하여 구현해 보자.

• 테이블 설계 : 먼저 분산 트랜잭션 환경 내에서, 좋아요 수 서비스는 게시글과 1 : 1 되는 서비스이기 때문에 샤드 키는 게시글 아이디인 ArticleId를 사용한다.
  • article_id : 기본 키이자 샤드 키(Shard Key)로 사용한다.
  • like_count : 실제 좋아요 수를 저장한다.
  • version : 낙관적 락을 위한 버전 관리 컬럼이다.

CREATE TABLE `article_like_count` (
  `article_id` bigint NOT NULL,
  `like_count` bigint NOT NULL,
  `version` bigint NOT NULL,
  PRIMARY KEY (`article_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;

 

① 비관적 락 (Pessimistic Lock)

데이터 충돌이 발생할 것이라고 가정하고, 락을 걸어 다른 트랜잭션의 접근을 차단하는 방식이다.

• 방법 1 (직접 업데이트): update ... set like_count = like_count + 1 쿼리를 바로 실행한다. 락 점유 시간이 짧아 효율적이다. 수정 시점에 락을 거는 방식이다.

@Query(
    value = "update article_like_count set like_count = like_count + 1 where article_id = :articleId",
    nativeQuery = true
)
@Modifying
int increase(@Param("articleId") Long articleId);

/**
 * update 구문
 */
@Transactional
public void likePessimisticLock1(Long articleId, Long userId) {
    int result = articleLikeCountRepository.increase(articleId);

    if (result == 0) {
        articleLikeCountRepository.save(
            ArticleLikeCount.init(articleId, 1L)
        );
    }
}

• 방법 2 (조회 후 업데이트): SELECT ... FOR UPDATE로 먼저 락을 잡고 조회한 뒤, 애플리케이션에서 계산된 값을 UPDATE 한다. 락을 조회 시점부터 점유하므로 비교적 락 점유 시간이 길다. JPA 환경에서는 레포지토리 메서드에@Lock(LockModeType.PESSIMISTIC_WRITE) 어노테이션을 선언하여 간단히 구현할 수 있다.

@Query(
    value = "update article_like_count set like_count = like_count + 1 where article_id = :articleId",
    nativeQuery = true
)
@Modifying
int increase(@Param("articleId") Long articleId);

/**
 * update 구문
 */
@Transactional
public void likePessimisticLock1(Long articleId, Long userId) {
    int result = articleLikeCountRepository.increase(articleId);

    if (result == 0) {
        articleLikeCountRepository.save(
            ArticleLikeCount.init(articleId, 1L)
        );
    }
}

 

② 낙관적 락 (Optimistic Lock)

충돌이 거의 없다 가정하고, 락 대신 버전(Version) 관리를 통해 정합성을 유지하는 방식이다.

• 동작 원리: 데이터를 읽을 때 버전 번호를 함께 가져오고, 수정할 때 WHERE version = 현재버전 조건을 건다. 성공하면 버전을 올리고, 실패하면 다른 사용자가 이미 수정한 것으로 판단해 롤백한다.
• 특징: DB 락을 잡지 않아 성능상 유리하지만, 충돌 발생 시 애플리케이션에서 후처리(재시도 등)가 필요하다. JPA에서는 @Version 어노테이션으로 간단히 구현 가능하다.
• 아래 코드에서는 increase() 시점에 엔티티의 변경이 발생하고, 이를 감지하여 WHERE 조건에 의해 version이 이 전 버전인지 검사하여 UPDTAE를 수행한다.
• 다만 버전 충돌 발생 시 예외 처리할 지, 재시도 로직을 통해 처리할 것인지에 대한 추가적인 처리가 필요하다. 낙관적 락은 데이터의 무결성을 보장할 뿐,

/**
 * optimistic Lock - 변경 시점(increase() 수행 시점)에서 version 체크해서 update
 * UPDATE article_like_count SET like_count = ?, version = ? (새 버전) WHERE article_id = ? AND version = ? (기존 버전)
 */
@Transactional
public void likeOptimisticLock(Long articleId, Long userId) {
    ArticleLikeCount articleLikeCount = articleLikeCountRepository.findById(articleId)
        .orElseGet(() -> ArticleLikeCount.init(articleId, 0L));

    articleLikeCount.increase(); // dirty check
    // articleLikeCountRepository.save(articleLikeCount);
}

 

③ 비동기 순차 처리

요청을 대기열(Queue)에 넣고 별도 스레드에서 순차적으로 처리하는 방식이다.

1. 구현 원리: 사용자의 요청(Producer)과 실제 DB 반영(Consumer)을 완전히 분리한다.
2. 큐(Queue)를 통해 요청을 일렬로 줄 세우기 때문에, DB 레벨의 복잡한 락 없이도 정합성을 유지할 수 있다.

• 장점
  • 빠른 쓰기 속도: DB 트랜잭션을 기다리지 않고 메모리(Redis)에 쓰고 바로 응답하므로 사용자 체감 속도가 매우 빠르다.
  • 부하 조절: 갑자기 좋아요가 몇만 개가 몰려도 DB가 터지지 않고 큐에 쌓였다가 서버가 처리 가능한 속도로 차근차근 반영할 수 있다.

• 단점
  • 사용자가 버튼을 눌렀는데 화면 숫자가 0.5~1초 뒤에 올라갈 수 있다.
  • Redis나 Kafka 같은 별도의 메시지 브로커를 운영해야 한다.

• 장점: 동시성 문제 자체를 원천 차단하며 DB 부하가 적다.
• 단점: 시스템 구축 비용이 크고 실시간 응답이 어려워 후 조치가 필요하다.

사용자의 요청을 즉시 DB에 반영하지 않고 메시지 큐(Message Queue)에 쌓아둔 뒤, 별도의 워커(Worker)가 하나씩 꺼내어 처리하는 것이 핵심이다. 여기서는 Redis를 대기열로 사용하여 작성했다.

1. 서비스 레이어: 요청을 큐에 쌓기 (Producer)

사용자는 대기열에 메시지가 들어가는 것만 확인하고 바로 응답을 받는다. 이 시점에는 DB 업데이트가 일어나지 않으므로 성능이 빠르다.

@Service
@RequiredArgsConstructor
public class ArticleLikeService {
    private final RedisTemplate<String, String> redisTemplate;
    private static final String LIKE_QUEUE = "article_like_task_queue";

    /**
     * 비동기 순차 처리 방식 - 요청 접수
     */
    public void likeAsync(Long articleId, Long userId) {
        // "articleId:userId:TYPE" 형태로 메시지 생성
        String message = articleId + ":" + userId + ":LIKE";
        
        // Redis List의 오른쪽(뒤)에 삽입 (Queue 역할)
        redisTemplate.opsForList().rightPush(LIKE_QUEUE, message);
    }
}

 

2. 워커(Worker): 큐에서 꺼내어 순차 처리 (Consumer)

백그라운드에서 실행되는 스레드가 큐를 감시하다가 데이터가 들어오면 하나씩 꺼내어 처리한다. 한 번에 하나씩 처리하기 때문에 동시성 충돌이 발생하지 않는다.

@Component
@RequiredArgsConstructor
public class LikeWorker {

    private final RedisTemplate<String, String> redisTemplate;
    private final ArticleLikeRepository articleLikeRepository;
    private final ArticleLikeCountRepository articleLikeCountRepository;
    private final Snowflake snowflake = new Snowflake();
    private static final String LIKE_QUEUE = "article_like_task_queue";

    // 0.1초마다 큐를 확인하여 처리 (혹은 무한 루프로 대기)
    @Scheduled(fixedDelay = 100)
    @Transactional
    public void processLikeQueue() {
        // 왼쪽(앞)에서 하나 꺼내오기
        String message = redisTemplate.opsForList().leftPop(LIKE_QUEUE);
        
        if (message == null) return;

        String[] data = message.split(":");
        Long articleId = Long.parseLong(data[0]);
        Long userId = Long.parseLong(data[1]);
        String type = data[2];

        if ("LIKE".equals(type)) {
            // 좋아요 내역 저장
            articleLikeRepository.save(ArticleLike.create(snowflake.nextId(), articleId, userId));
            // 좋아요 수 카운트 업데이트 (비관적 락 없이 일반 update로도 안전)
            articleLikeCountRepository.increase(articleId);
        } else {
            // 좋아요 취소 
        }
    }
}

 

 세 가지 전략에 대해 표로 정리하자면 다음과 같다.

구분	비관적 락 (방법 1)	비관적 락 (방법 2)	낙관적 락	비동기 순차 처리
락 점유	UPDATE 시점에만 짧게	조회부터 커밋까지	없음 (버전 체크만 함)	없음 (메시지 큐 활용)
속도	빠름	보통	매우 빠름 (충돌 없을 시)	가장 빠름 (응답 위주)
난이도	낮음 (SQL 위주)	보통 (JPA 활용)	보통 (충돌 후처리 필요)	높음 (인프라 구축 필요)
안전성	매우 높음	매우 높음	충돌 시 사용자 실패 응답	매우 높음 (순차 보장)
데이터 반영	즉시 반영	즉시 반영	즉시 반영	지연 반영 (최종 일관성)

• 데이터 무결성이 최우선이며, 로직이 단순하다면?
  • 데이터베이스의 원자적 연산을 활용하는 비관적 락(방법 1)이 가장 효율적이다. 락 점유 시간을 최소화하면서도 정확한 카운팅을 보장할 수 있기 때문이다
• 객체지향적인 코드 유지와 강력한 정합성이 모두 중요하다면?
  • JPA의 강점을 살릴 수 있는 비관적 락(방법 2)인 SELECT FOR UPDATE를 고려할 수 있다. 다만, 락 점유 시간이 길어질 수 있으므로 트랜잭션의 범위를 최대한 짧게 가져가는 설계가 필요하다.
• 충돌 빈도가 낮고 시스템의 전반적인 처리량이 중요하다면?
  • 물리적인 락 오버헤드가 없는 낙관적 락이 좋은 대안이 된다. 다만 버전 충돌 발생 시 사용자에게 실패를 알릴 것인지, 혹은 재시도 로직을 통해 처리할 것인지에 대한 추가적인 처리가 필요하다.

좋아요 수 동시성 문제를 해결하기 위한 세 가지 전략을 살펴보았다. 결론은 세 가지 전략에 대해 모든 상황에 완벽하게 들어맞는 정답은 없다. 결국 처해진 비즈니스 상황과 트래픽 특성에 따라 최적의 지점을 선택해야 한다.