studiobaton
← 타임라인으로

UID 도입과 RESTful 마이그레이션 완주기 - 레거시와의 우아한 이별

개발자 A, 개발자 B, 개발자 C, 개발자 D, 개발자 E

레거시 호환성이라는 숙제

오늘은 저희 팀에서 꽤 오랫동안 계획해온 RESTful API 마이그레이션이 드디어 완료된 날입니다. 22개 엔드포인트를 새로운 구조로 옮기면서도 기존 서비스는 멈추지 않아야 하는 상황 (마치 달리는 기차의 바퀴를 갈아끼우는 느낌이랄까요).

특히 인상적이었던 건 ContentEventUID 시스템을 도입한 부분입니다. 기존의 숫자 ID 대신 6자리 영대문자+숫자 조합으로 더 사용자 친화적인 식별자를 만들었는데, 여기서 중요한 건 레거시 호환성이었어요.

// 이벤트 API에서 uid 또는 id로 조회 지원
// 새로운 UID와 기존 ID 모두 처리 가능
export async function getEventByIdentifier(identifier: string) {
  return isUID(identifier) 
    ? getEventByUID(identifier) 
    : getEventById(parseInt(identifier));
}

캐시 전략의 진화

이번 마이그레이션에서 가장 고민이 많았던 부분은 캐시 전략이었습니다. Redis Cache에서 Vercel Edge Cache로 넘어가면서 각 API의 성격에 맞는 캐시 시간을 설정했어요.

  • Release schedules: 10분 캐시 (자주 바뀌지 않지만 실시간성 필요)
  • Product cached: 1분 캐시 (재고 변동 반영을 위해 짧게)

결국 "얼마나 자주 바뀌는 데이터인가"와 "실시간성이 얼마나 중요한가" 사이의 밸런스 게임이더라고요.

한편 Repository B에서는 갤러리 페이지들의 UX 개선이 계속 진행되고 있고, Repository C에는 이벤트 메뉴가 새롭게 추가되었습니다. 작은 변화지만 사용자 경험을 개선하는 꾸준한 작업들이죠.

저희도 매일 배우고 있지만, 이런 대규모 마이그레이션을 무중단으로 완료할 수 있었던 건 단계별 접근과 철저한 호환성 유지 덕분이었습니다. 쿨하니까요.

고객사 정보 보호를 위해 프로젝트명 및 일부 세부 정보가 마스킹 처리되어 있습니다.

작업한 프로젝트

Repository A
4개 커밋+3828-257
Repository B
10개 커밋+2059-2203
Repository C
2개 커밋+82-18

상세 커밋 내역

기능 추가

Repository A · 개발자 A · +71 / -12

스타일 수정

Repository B · 개발자 B · +174 / -125

기능 추가

Repository A · 개발자 A · +4 / -1

기능 추가

Repository A · 개발자 A · +3710 / -202

문서 업데이트

Repository A · 개발자 A · +43 / -42

스타일 수정

Repository B · 개발자 B · +22 / -33

스타일 수정

Repository B · 개발자 B · +49 / -44

코드 업데이트

Repository B · 개발자 B · +370 / -318

스타일 수정

Repository B · 개발자 C · +152 / -158

버그 수정

Repository B · 개발자 C · +11 / -11

코드 업데이트

Repository B · 개발자 D · +529 / -657

기능 추가

Repository C · 개발자 B · +41 / -9

코드 업데이트

Repository C · 개발자 E · +41 / -9

스타일 수정

Repository B · 개발자 B · +4 / -4

코드 업데이트

Repository B · 개발자 B · +530 / -668

코드 업데이트

Repository B · 개발자 E · +218 / -185

고객사 정보 보호를 위해 프로젝트명 및 일부 세부 정보가 마스킹 처리되어 있습니다.