PlaylistTrack reorder 동시성 테스트 검증 기준 개선

들어가며

PlaylistTrack reorder는 여러 track의 position 값을 변경하는 작업이다.

이런 구조에서는 여러 요청이 동시에 들어올 경우, 같은 position을 동시에 수정하려는 충돌 상황이 발생할 수 있다.

 

기존에는 동시성 테스트를 아래처럼 작성했었다.

assertTrue(exceptions.isEmpty(),
        () -> "동시 reorder 중 예외 발생: " + exceptions);

 

즉, 예외가 하나라도 발생하면 테스트를 실패로 처리하는 방식이었다.

2026.05.06 - [Fivefy 프로젝트/성능 개선] - PlaylistTrack 순서 변경 성능 검증 (부분 재정렬 구조의 실제 동작 측정)

PlaylistTrack 순서 변경 성능 검증 (부분 재정렬 구조의 실제 동작 측정)

 

이전 글에서는 부분 재정렬 구조의 응답 시간과 update 범위를 측정하면서, worst-case 상황에서 구조가 어떻게 동작하는지 검증하였다. 하지만 reorder처럼 여러 row의 position을 수정하는 작업에서는 동시 요청 상황에서의 데이터 정합성 역시 중요했다.

 

특히 동시에 같은 position을 수정하려는 충돌은 충분히 발생할 수 있었고, 오히려 이를 DB의 unique constraint가 감지하고 막아주는 것이 정상 동작에 가까웠다.

 

그래서 이번에는 단순히 “예외가 발생하지 않았는가”보다, “충돌 상황 이후에도 최종 데이터가 올바르게 유지되는가”를 검증하는 방향으로 테스트를 수정하였다.

---

문제 상황

기존 테스트는 단순히 아래 기준으로만 성공 여부를 판단하고 있었다.

• 예외 없음 → 성공
• 예외 발생 → 실패

즉, 예외 발생 여부 자체를 기준으로 테스트를 판단하고 있었다.

하지만 reorder는 동시에 같은 position을 수정할 가능성이 있기 때문에, 동시성 충돌 자체는 충분히 발생할 수 있는 상황이다.

 

예를 들어

• Thread A → position 3 수정
• Thread B → position 3 수정

같은 요청이 동시에 수행되면, DB에서는 unique constraint 충돌이 발생할 수 있다.

 

이 경우는 시스템이 잘못 동작한 것이 아니라, DB가 충돌을 정상적으로 감지하고 보호한 상황에 가깝다.

그런데 기존 테스트는 이런 경우까지 모두 실패 처리하고 있었다.

---

테스트 코드 수정

기존에는 아래처럼 예외가 하나도 발생하지 않아야만 테스트를 통과시켰다.

assertTrue(exceptions.isEmpty(),
        () -> "동시 reorder 중 예외 발생: " + exceptions);

 

하지만 이번에는 검증 방향을 변경했다.

if (exceptions.isEmpty()) {
    System.out.println("동시 순서 변경 요청이 예외 없이 정상 처리되었습니다.");
} else {
    System.out.println("동시 순서 변경 중 충돌이 발생했지만, DB 제약 조건으로 정상 감지되었습니다.");
}

 

이제는 단순히 예외 발생 여부로 성공/실패를 판단하지 않고,

충돌 발생 이후에도 데이터가 정상 상태를 유지하는지를 검증하도록 수정했다.

---

최종 데이터 정합성 검증 추가

예외 여부 대신, 최종 데이터 상태를 검증하는 로직을 추가했다.

position 중복 검증

long distinctPositionCount = ordered.stream()
        .map(PlaylistTrack::getPosition)
        .distinct()
        .count();

assertEquals(trackCount, distinctPositionCount);

 

최종적으로 중복된 position 값이 존재하지 않는지 검증하였다.

---

최종 순서 검증

for (int i = 0; i < ordered.size(); i++) {
    assertEquals(i + 1, ordered.get(i).getPosition());
}

 

모든 track의 position이 1 ~ N 형태로 정상 유지되는지도 함께 확인하였다.

---

테스트 결과

동시 reorder 요청 중 일부 충돌이 발생하는 경우가 있었지만,

최종 데이터에서는 다음 상태가 모두 정상적으로 유지되는 것을 확인할 수 있었다.

• position 중복 없음
• 순서 정상 유지
• track 유실 없음

즉, 충돌 자체는 발생할 수 있었지만, DB 제약 조건과 reorder 로직을 통해 최종 데이터 정합성은 안전하게 유지되었다.

---

느낀 점

이번 테스트를 수정하면서, 동시성 테스트에서는 단순히 “예외가 발생하지 않아야 한다”보다 “충돌 상황에서도 데이터 정합성이 안전하게 유지되는가”를 검증하는 것이 더 중요하다는 점을 느낄 수 있었다.

 

특히 reorder처럼 여러 row를 동시에 수정하는 작업에서는 충돌 자체를 완전히 없애는 것보다, 충돌 발생 시에도 DB 제약 조건과 애플리케이션 로직을 통해 데이터를 안전하게 보호할 수 있는지가 더 중요한 기준이라고 생각했다.

 

또한 이번 검증을 통해, 동시성 테스트 역시 단순 성공/실패 여부보다 최종 데이터 상태를 함께 검증하는 방향이 중요하다는 점을 다시 확인할 수 있었다.