부분 재정렬 이후, 더 나은 정렬 방식에 대한 고민

들어가며

이전 글에서 PlaylistTrack 순서 변경 로직을 전체 재정렬 방식에서 부분 재정렬 방식으로 개선했다.

해당 개선을 통해 불필요한 DB update를 줄이고, 유니크 제약 충돌 문제도 안정적으로 처리할 수 있었다.

 

2026.04.23 - [Fivefy 프로젝트/트러블슈팅] - PlaylistTrack 순서 변경 최적화 전체 재정렬을 부분 재정렬로 개선

PlaylistTrack 순서 변경 최적화 전체 재정렬을 부분 재정렬로 개선

 

하지만 구현 이후, 현재 방식이 모든 상황에서 효율적인 구조인지에 대한 고민이 필요했다.

---

부분 재정렬 방식의 한계

부분 재정렬은 전체 재정렬보다 효율적인 방식이지만, 모든 상황에서 최적이라고 보기는 어려웠다.

 

예를 들어,

1번 트랙 → 100번 위치 이동

 

이 경우,

2 ~ 100번 트랙의 position이 모두 변경된다

 

즉, 이동 범위가 커질 경우 여전히 다수의 row update가 발생한다.

결국 구조적으로 보면 최악의 경우 O(n) update가 발생하는 한계가 있었다.

---

더 나은 방식은 없을까?

이 문제를 해결하기 위해 "이동 대상 하나만 업데이트할 수 있는 방식"에 대해 고민하게 되었고, 그 과정에서 간격 기반 정렬 방식(LexoRank)을 알게 되었다.

---

LexoRank란?

기존 방식은 단순 정수 기반이다.

position = 1, 2, 3, 4

 

반면 LexoRank는 간격을 가지는 값으로 정렬을 관리한다.

rank = 1000, 2000, 3000, 4000

 

이 구조에서는 트랙 이동 시

기존: 여러 트랙 update
LexoRank: 이동 대상 하나만 update

 

예를 들어,

2000과 3000 사이 → 2500

 

처럼 사이값을 생성하여 하나만 수정할 수 있다.

---

그렇다면 왜 적용하지 않았는가

LexoRank는 분명 장점이 있지만, 현재 구조에 바로 적용하기에는 다음과 같은 고민이 있었다.

1. 설계 복잡도 증가

• rank 생성 로직 필요
• 간격 부족 시 재정렬 정책 필요
• position 기반 응답과 rank 기반 저장 구조 분리 필요

2. 동시성 및 충돌 처리

• 동일 rank 생성 가능성
• 추가적인 제약 조건 및 예외 처리 필요

3. 현재 구조 대비 효과

이미 부분 재정렬을 통해

불필요한 update는 상당 부분 제거된 상태였다.

 

즉,

• 현재 문제는 충분히 해결된 상태였고
• 추가 복잡도를 감수할 만큼의 이점은 아니었다.

결론적으로, 현재 문제 대비 도입 비용이 더 크다고 판단했다.

---

최종 판단

따라서 현재는 position 기반 부분 재정렬 방식을 유지하기로 했다.

 

이미 변경 범위를 최소화하는 개선이 이루어졌고,

현재 서비스 규모에서는 충분히 효율적인 구조라고 판단했다.

 

다만,

• 트랙 수가 많아지거나
• 순서 변경이 빈번해지는 경우

에는 LexoRank와 같은 간격 기반 정렬 방식 도입을 고려할 수 있다.

---

느낀 점

이번 경헝을 통해 "더 좋은 기술을 적용하는 것"보다, 현재 문제에 적절한 선택을 하는 것이 더 중요하다는 것을 느꼈다.

 

전체 재정렬 → 부분 재정렬로 개선한 이후에도

• 추가적인 한계를 고민하고
• 다른 해결 방법을 탐색하고
• 최종적으로 적용 여부를 판단하는 과정까지 경험할 수 있었다.

앞으로도 문제 → 개선 → 대안 탐색 → 설계 판단 이 흐름을 기준으로 개발을 이어가고자 한다.