이관 작업과 스키마 정규화 사이에서 살아남기

이관의 계절이 왔다2

오늘은 여러 프로젝트에서 이관 작업이 동시에 진행된 하루였습니다. Repository A과 Repository B에서 이관 문서를 작성하고 파일을 정리하는 작업이 한창이었는데요. 사실 이런 작업들이 개발할 때는 별로 눈에 안 띄지만, 나중에 "아 그때 문서 좀 제대로 써뒀으면..." 하고 후회하게 되는 그런 일들이죠 (경험담).

특히 Repository B에서 IAM 계정 정보를 환경변수로 분리한 건 작은 변경이지만 보안 측면에서는 꽤 중요한 개선이었습니다. 하드코딩된 인증 정보만큼 무서운 게 없으니까요.

하이츠 스토어의 대공사

그런데 오늘의 하이라이트는 역시 Repository E였습니다. +694/-602라는 숫자가 보여주듯이, 정말 대대적인 리팩토링이 있었거든요.

가장 큰 변화는 정규화된 스키마에 맞춰 API 라우트를 전면 수정한 것이었습니다. 기존에 createMany로 한 번에 처리하던 배너 데이터들을 findMany로 개별 조회하는 방식으로 바꾸고, Redis 캐시 엔드포인트도 /api/edge에서 /api/cached로 이동시켰습니다.

// 이런 식으로 개별 레코드 생성 방식으로 변경
const categoryBanners = await prisma.categoryBanner.findMany({
  where: { is_active: true },
  orderBy: { order_index: 'asc' }
});

마이그레이션 로직도 완전히 뜯어고쳤는데, 솔직히 말하면 처음에는 "이게 꼭 필요한가?" 싶었지만 막상 해보니 데이터 무결성 면에서 훨씬 안전해졌더라고요.

작은 디테일들의 승리

Repository D에서는 통화 변환 앱의 CSS 조정 작업이 있었습니다. 앱을 설치한 후 테마에 맞춰 스타일을 다시 잡는 작업인데, 이런 게 의외로 까다롭죠. 특히 모달 안에서 통화 변환기 위치를 조정하는 것 같은 디테일들 말이에요.

Repository C에서는 텍스트 변경 같은 작은 수정들이 있었는데, 가끔 이런 "한 글자 바꾸기" 커밋이 생각보다 중요할 때가 많습니다 (사용자는 그런 디테일을 다 느끼거든요).

이관과 리팩토링