API 목록 정렬: createdAt과 updatedAt 어느 쪽을 기본으로 할까

목록 API를 만들 때 정렬 기준을 createdAt DESC로 할지 updatedAt DESC로 할지 매번 잠깐 고민한다. 둘의 차이는 단순해 보이지만 페이지네이션과 UX에서 실질적인 차이가 생긴다.

createdAt 기준 정렬

생성 시각은 한 번 기록되면 바뀌지 않는다. 이 속성 덕분에 커서 기반 페이지네이션에서 안정적으로 쓸 수 있다.

SELECT * FROM posts
ORDER BY created_at DESC
LIMIT 20 OFFSET 0;

같은 시각에 생성된 레코드가 많지 않다면, 이미 본 목록에 새 항목이 끼어들거나 항목이 중복되는 문제 없이 다음 페이지를 안정적으로 가져올 수 있다.

사용 예: 공지사항, 거래 내역, 블로그 글처럼 작성 순서 자체가 의미를 가지는 경우.

updatedAt 기준 정렬

수정 시각 기준은 최근에 변경된 항목이 상단에 오게 한다. 게시물을 수정하면 순서가 바뀌므로, 무한 스크롤이나 오프셋 페이지네이션에서 사용자가 스크롤하는 동안 목록 순서가 달라지는 문제가 생길 수 있다.

SELECT * FROM posts
ORDER BY updated_at DESC
LIMIT 20 OFFSET 0;

사용 예: 위키, 협업 문서, 이슈 트래커처럼 "최근에 활동이 있었던 것"을 우선 보여줄 때.

Prisma에서 쓸 때

// createdAt 기준
const posts = await prisma.post.findMany({
  orderBy: { createdAt: 'desc' },
  take: 20,
  skip: page * 20,
})

// updatedAt 기준 + 커서 페이지네이션 (위험 — 수정 시 순서 바뀜)
const posts = await prisma.post.findMany({
  orderBy: { updatedAt: 'desc' },
  cursor: { id: lastId },
  take: 20,
})

updatedAt으로 정렬하면서 커서 기반 페이지네이션을 쓰면, 수정된 항목이 커서보다 앞에 끼어들어 중복이나 누락이 생길 수 있다. 이 경우엔 커서를 updatedAt + id 복합 키로 만들거나, 페이지 번호 방식으로 대신 쓰는 게 낫다.

선택 기준 정리

기준	createdAt	updatedAt
순서 변동	없음	수정 시 변동
페이지네이션	안정적	주의 필요
적합한 용도	작성 순서가 중요할 때	최근 활동 우선할 때

정렬 기준을 API 설계 초기에 명확히 해두지 않으면, 프론트엔드에서 이상한 순서를 발견하고 나서야 뒤늦게 바꾸게 된다. 그 시점엔 이미 페이지네이션 로직까지 함께 손봐야 한다.