[트러블슈팅] 커뮤니티 좋아요 상태 불일치로 인한 409 오류

TROUBLESHOOTING

커뮤니티 좋아요 상태 불일치로 인한 409 오류

목차

• 1. 문제 상황
• 2. 원인 분석
• 3. 해결 방법
• 4. 적용 결과
• 5. 배운 점

1. 문제 상황

커뮤니티 게시글에서 좋아요 버튼을 클릭했을 때 간헐적으로 409 Conflict 오류가 발생했다.

처음에는 동시에 같은 요청이 여러 번 발생하는 동시성 문제를 의심했다. 하지만 재현 조건을 확인해보니 특정 상황에서 일관되게 발생하는 문제였다.

커뮤니티 댓글창에서 좋아요 버튼을 클릭하는 화면

좋아요 요청 이후 화면에서 확인된 409 Conflict 오류

브라우저 개발자 도구 Console에서 확인한 좋아요 요청 실패 로그

좋아요 요청 자체는 서버로 정상 전송되었지만, 서버 기준으로는 이미 좋아요가 존재하는 상태였기 때문에 중복 요청으로 판단되어 409 오류가 발생했다.

2. 원인 분석

원인은 좋아요 상태를 백엔드가 아닌 localStorage에 저장해 관리하고 있었기 때문이다.

localStorage를 기준으로 좋아요한 게시글 ID를 조회하고 저장하던 초기 코드

문제는 localStorage와 백엔드의 실제 좋아요 상태가 언제든 불일치할 수 있다는 점이다. 예를 들어 다음과 같은 상황에서 상태 불일치가 발생할 수 있다.

• 다른 기기나 다른 브라우저에서 이미 좋아요를 누른 경우
• 브라우저의 localStorage가 초기화된 경우
• 백엔드 DB의 좋아요 상태와 클라이언트 저장 상태가 달라진 경우

즉, localStorage에는 좋아요를 누르지 않은 상태로 저장되어 있지만, 백엔드에는 이미 좋아요 데이터가 존재할 수 있다. 이 상태에서 프론트엔드가 다시 좋아요 요청을 보내면 서버는 중복 좋아요 요청으로 판단하고 409 Conflict를 반환한다.

결국 근본 원인은 서버 상태와 동기화되어야 하는 좋아요 정보를 클라이언트 저장소인 localStorage를 기준으로 판단한 것이었다.

3. 해결 방법

해결 방법은 localStorage 기반 상태 관리를 제거하고, 백엔드에서 isLiked 필드를 직접 내려주는 방식으로 전환하는 것이었다.

 

3-1. CommunityPostResponse에 isLiked 필드 추가

먼저 게시글 응답 DTO인 CommunityPostResponse에 isLiked 필드를 추가했다. 이를 통해 프론트엔드는 localStorage가 아니라 서버가 내려준 좋아요 상태를 기준으로 버튼 상태를 렌더링할 수 있다.

CommunityPostResponse에 isLiked 필드를 추가하고, from() 메서드에서 좋아요 상태를 포함해 응답하도록 수정한 코드다.

 

3-2. 목록 조회 시 N+1 방지

게시글 목록을 조회할 때 게시글마다 existsByPostIdAndUserId()를 호출하면 게시글 수만큼 좋아요 조회 쿼리가 추가로 발생한다. 이는 전형적인 N+1 문제로 이어질 수 있다.

이를 방지하기 위해 사용자가 좋아요한 게시글 ID를 한 번에 조회하는 메서드를 추가했다.

사용자가 좋아요한 게시글 ID 목록을 한 번에 조회하는 findPostIdsByUserId() 쿼리 메서드다.

getPosts()에서 사용자가 좋아요한 게시글 ID를 Set으로 변환한 뒤, 각 게시글의 isLiked 값을 일괄 처리하는 코드다.

게시글마다 좋아요 여부를 개별 조회하지 않고, 좋아요한 게시글 ID 목록을 한 번에 가져온 뒤 Set으로 확인하면 N+1 문제를 줄일 수 있다.

 

3-3. 프론트 localStorage 제거

프론트엔드에서는 기존의 localStorage 기반 좋아요 상태 관리를 제거했다. 대신 백엔드 응답에 포함된 isLiked 값을 기준으로 좋아요 버튼 상태를 렌더링하도록 수정했다.

수정 후 toggleLike 함수다. 좋아요 상태를 localStorage가 아니라 백엔드에서 내려준 isLiked 기준으로 처리한다.

4. 적용 결과

• 좋아요 토글 시 발생하던 409 Conflict 오류가 해소되었다.
• 다른 기기나 브라우저에서도 좋아요 상태가 정확하게 반영되었다.
• 목록 조회 시 불필요한 개별 좋아요 조회 쿼리를 줄여 N+1 문제를 방지했다.
• 클라이언트 상태가 아니라 서버 상태를 기준으로 UI를 렌더링하게 되었다.

좋아요 상태의 기준을 localStorage에서 백엔드 응답의 isLiked로 변경하면서, 서버와 클라이언트 간 상태 불일치 문제를 해결할 수 있었다.

5. 배운 점

좋아요처럼 서버 상태와 동기화가 필요한 데이터는 클라이언트 저장소만으로 관리하면 안 된다. localStorage는 언제든 초기화될 수 있고, 여러 기기나 브라우저에서 접근할 경우 상태 불일치가 발생할 수 있다.

 

서버 상태는 서버가 내려주는 값을 신뢰의 기준으로 삼아야 한다. 클라이언트는 서버 응답을 받아 UI를 렌더링하고, 사용자 액션에 따라 서버에 변경 요청을 보내는 역할에 집중하는 것이 안전하다.

정리하면, 서버와 동기화되어야 하는 상태는 클라이언트 저장소를 기준으로 판단하지 말고, 백엔드 응답 값을 기준으로 관리해야 한다.