[내일배움캠프] 25일 차 TIL - CodeRabbit 코드 리뷰

25일 차 TIL

우리 팀은 codeRabbit AI를 설정해서 PR시 개선할 점을 리뷰로 달아주도록 했다.

오늘은 팀프로젝트 중 위 방식이 적용된 사례를 가져와서 정리해 봤다.

PR 등록 시)
codeRabbit으로 1차 수정
팀원의 코드 리뷰로 2차 수정
=> 병합 전 더 꼼꼼하게 코드를 체크할 수 있다.

동시성 경합 문제 해결과정

사용 사례 - 중간테이블에 저장 시, 동시성 문제 해결

 
먼저 가게는 여러 개의 카테고리를 가질 수 있으니 가게와 카테고리의 중간 테이블로 p_store_category를 만들었다.

처음엔 간단하게 Store와 Category로 1개의 행을 저장하는 로직을 구현했다.

그랬더니 이미 존재하는 카테고리를 다시 저장할 필요는 없으니 체크 후 저장하라고 codeRabbit이 리뷰를 남겨줬다.

 

---

커밋 후 CodeRabbit이 저장 로직을 try-catch로 수정하라는 리뷰를 남겼다.
이유는 동시성 경합 상황에서 데이터 무결성을 안전하게 보장하기 위해서이다.

먼저 try - catch문이 왜 필요한 지부터 생각해 봤다.
동시성 경합문제 발생 시, 예외 처리를 위해 필요한 것이다.
 
DataIntegritiyViolationException은 데이터 무결성을 위반했을 때 발생하는 예외이다.
중복 pk 저장, Unique 제약, null 제약, fk제약조건 위반등이 있다.
나의 경우에는 중복 PK를 저장할 때를 체크하는 게 주목적이다.
 
 

---

동시성 경합 문제가 발생하는 시나리오를 적어보면 다음과 같다.

동시에 생성 요청을 한 경우

같은 데이터에 대해서 두 사용자가 동시에 저장요청을 할 경우,
먼저 요청한 한 명의 저장만 성공하고
뒤늦게 온 요청은 이미 존재하는 데이터로 멱등하게 처리된다.

이때 "멱등하다"는 말은 "동일한 요청을 여러 번 해도 최종 결과가 달라지지 않는다"는 말이다.
이 경우에는 이미 존재하는 데이터를 저장할 때 중복저장이 안 되게 유지하는 것을 말한다.
 
근데 DataIntegrityViolationException은 중복 PK만 처리하는 것이 아니기에
catch() 문 안에서 한번 더 체크하고 다른 무결성문제일 경우엔 예외를 날려줬다.

참고로 try문 전의 if문은 insert문이 날아가기 전에 체크해서
불필요한 쿼리를 줄여주기 위해 사용됐다.

---

Unique 제약 조건

근데 이것만으로는 부족하다. codeRabbit의 맨 아래를 보면
추가로, store_id + category_id 유니크 제약이 있어야 최종적으로 무결성이 보장된다고 한다.
 
따라서 아래 코드를 추가해 줬다.

@Table(
    name = "p_store_category",
    uniqueConstraints = {
        @UniqueConstraint(
            name = "uk_store_category",
            columnNames = {"store_id", "category_id"} // 이 두 조합은 유일해야 함!
        )
    }
)

왜 필요하냐면,
중간 테이블에 가게와 카테고리의 조합으로 데이터가 저장될 때
중간 테이블 자체의 pk 또한 랜덤 생성되는 UUID기 때문인데,
기본키만으로는 가게와 카테고리 조합의 유일성을 체크할 수 없어서
두 외래키의 조합을 체크해서 이미 있는 조합이면 저장하지 않는 로직이 필요하다.

---

이후 팀원이 코드리뷰를 남겼을 때, codeRabbit의 리뷰기록을 보고
왜 이렇게 수정했는지 답변을 남겨줄 수 있었다.

마무리

codeRabbit AI의 PR 코드리뷰 기능을 활용해서 팀프로젝트를 진행하니
사소한 에러도 찾아주고 코드리뷰 자체에 시간도 줄여주는 등 많은 이점이 있는 것 같다.