UID 도입과 RESTful 마이그레이션 완주기 - 레거시와의 우아한 이별
레거시 호환성이라는 숙제
오늘은 저희 팀에서 꽤 오랫동안 계획해온 RESTful API 마이그레이션이 드디어 완료된 날입니다. 22개 엔드포인트를 새로운 구조로 옮기면서도 기존 서비스는 멈추지 않아야 하는 상황 (마치 달리는 기차의 바퀴를 갈아끼우는 느낌이랄까요).
특히 인상적이었던 건 ContentEvent에 UID 시스템을 도입한 부분입니다. 기존의 숫자 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 · 개발자 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
고객사 정보 보호를 위해 프로젝트명 및 일부 세부 정보가 마스킹 처리되어 있습니다.