목록 좋아요 수는 단순한 조회부터 시작하라

출처 및 AI 안내: 이 글은 제미니의 개발실무 유튜브를 기반으로 작성되었습니다. gpt-5.6-sol 모델을 사용해 생성·편집했습니다.

페이징 목록 한 장을 보여 주려고 전체 좋아요 카운트 시스템부터 만들 필요는 없다. 페이지를 조회하고, 그 항목 아이디의 좋아요 수를 센 뒤, 응답을 만들 때 두 결과를 합친다. 이 흐름이면 제안된 설계의 카운터 행 경합과 너무 이른 Redis 도입을 모두 피할 수 있다.

페이지 범위의 두 번째 쿼리로 개수를 만든다

리뷰나 상품을 먼저 조회한다. 그 아이디를 좋아요 테이블의 IN 조건으로 넘기고 항목별로 그룹화해 아이디와 개수의 맵을 받는다. 프레젠테이션 계층에서는 목록 응답을 만들면서 각 아이디의 개수를 찾아 넣는다.

원문의 20개짜리 페이지 예제라면 그룹 쿼리에도 그 20개 아이디만 들어간다. 이 숫자가 모든 데이터베이스와 스키마의 성능을 보장하는 것은 아니지만 핵심은 조회 모양이 제한돼 있다는 점이다. 전체 항목을 집계하지 않고 페이지를 따라간다. 다른 저장 모델을 추가하기 전에 이 직접적인 구현부터 만들고 실제 동작을 확인한다.

리뷰 행 업데이트가 처음의 경합을 만든다

좋아요를 한 행 추가하고 리뷰의 like_count도 올리면 쓰기가 두 번 발생한다. 인기 있는 리뷰 하나에 업데이트가 몰리면서 질문에 나온 동시성 문제가 생긴다. 좋아요 수가 리뷰의 핵심 책임인지도 불분명하다. 집계 하나를 소유하기 시작하면 추천·비추천 수, 구매 수, 취소 수 같은 부가 통계가 뒤따를 수 있다.

좋아요를 각각 추가되는 데이터로 두면 사용자 반응과 리뷰가 분리된다. 읽을 때 집계 쿼리가 하나 생기지만 현재 페이지가 이미 범위를 제한한다. 다른 상황에서는 저장된 카운터가 맞을 수도 있다. 아직 제한 조회를 시도하지 않은 상태에서 자동으로 첫 설계가 될 필요가 없다는 뜻이다.

단순 조회가 부족해진 뒤에 Redis를 검토한다

개수를 Redis로 옮기면 팀이 운영할 저장소가 하나 늘어난다. 값이 사라지면 무엇으로 다시 채울지, 데이터베이스에도 개수가 있다면 둘을 어떻게 동기화할지 정해야 한다. 페이지 범위의 DB 조회만으로 충분했어도 이 질문과 비용은 생긴다.

규모가 커지면 값을 다시 채우고 동기화하며 관리하는 비용을 감수하고 캐시를 쓸 이유가 생길 수 있다. 그 결정은 서비스가 단순한 추가 모델과 페이지 그룹 쿼리를 넘어선 뒤에 내린다. 그전에는 이미 가진 자원을 쓰고 좋아요 개수 관심사를 핵심 리뷰 행 밖에 둔다.