👋 Supabase 이사와 무자비한 캐시 최적화

초기엔 쉽고 빠르게 데이터를 관리하려고 Notion(노션) DB를 연동해 JSON 파일로 빌드 시점에 동기화하는 방식을 쓰기로 계획했지만, 유저들이 실시간으로 로고를 제보하고, 제가 어드민 페이지에서 이를 실시간으로 검증하고 반영하기엔 노션은 너무나 느리고 정적인 도구라고 판단해서 진짜 데이터베이스(DB)로 급 선회하였습니다.

1. Notion에서 Supabase로, 데이터 대이동 (Data Migration)

과감하게 GitHub Actions에 물려있던 노션 동기화 워크플로우를 통째로 날려버렸습니다. 관련 의존성 패키지(@notionhq/client)와 낡은 logos.json 파일도 가차 없이 휴지통으로 보냈죠. (삭제할 때의 쾌감이란! 🧹)

그리고 그 자리에 진짜 관계형 데이터베이스(PostgreSQL)인 Supabase를 앉혔습니다. 단순히 데이터 저장소만 바꾼 게 아니라, 데이터의 입력과 출력을 제 손으로 100% 통제하기 시작하면서 프로젝트의 체급 자체가 완전히 달라졌습니다.

• 타입 매핑 버그와 'ONLY PNG' 배지 정상화: 초기 어드민에서 "이 브랜드는 PNG만 있어요!"라고 체크를 해도 자꾸 데이터가 공중분해(undefined)되는 버그가 있었습니다. Setup SQL 마이그레이션 스크립트를 짜서 DB 컬럼을 새로 고치고, rowToBrand와 brandToRow 양방향 매핑 타입을 촘촘하게 보강했습니다. 프론트엔드가 멋대로 데이터를 추측하던 임시방편 로직을 다 걷어내고, 오직 DB 원본(단일 소스)에만 의존해 'ONLY PNG' 배지를 오차 없이 정확하게 노출시키는 짜릿함을 맛보았습니다. 🏷️
• ㄹㄱ만 쳐도 나오는 "초성 검색" 구현: 노션 API로는 상상도 할 수 없던 정교한 검색 경험도 선물했습니다. 브랜드를 등록할 때 '한글 초성 검색용 필드'가 데이터베이스에 자동으로 생성되어 함께 저장되도록 영리하게 코드를 설계했습니다. 덕분에 유저가 검색창에 초성만 툭툭 쳐도 원하는 브랜드를 번개처럼 찾아주는 대기업급 검색 UX가 완성되었습니다. 🔍

2. 1초가 아쉬운 모바일 성능 개선: 무자비한 캐싱과 렌더링 최적화

데이터베이스를 탄탄하게 다졌으니, 이제 유저에게 전달되는 속도를 극도로 끌어올릴 차례였습니다.

초기의 '로고착착' 홈 페이지는 언제 데이터가 바뀔지 모르니 매 요청마다 DB를 통째로 새로 찌르는 force-dynamic 구조였습니다. 결과는? 첫 페이지 로딩이 눈에 띄게 답답했습니다. 게다가 홈 화면에 브랜드 카드가 수십, 수백 개씩 깔리는데, 그 무거운 고화질 로고 이미지들이 한 번에 디코딩되느라 모바일 기기에서의 TTI(Time to Interactive·사용자가 실제 조작 가능한 시간)가 최악을 달리고 있었습니다.

디자이너로서 이 '버벅거림'은 절대 용납할 수 없었기에, 성능 최적화 풀코스를 밟았습니다. 👇

[ 기존 ]  매 요청마다 DB 풀쿼리 ──> 모든 이미지 동시 디코드 ──> 모바일 버벅임 🐢
[ 개선 ]  ISR (1시간 단위 캐시) ──> Lazy Loading + Async Decoding ──> 번개 같은 로딩 ⚡

• ISR(Incremental Static Regeneration) 도입: 홈 페이지와 브랜드 상세 페이지를 1시간 단위로 캐싱(ISR)되도록 전환했습니다. 매번 DB를 찌르는 대신 다이내믹하게 생성된 정적 페이지를 던져주니 속도가 압도적으로 빨라졌습니다.
• 이미지 렌더링 최적화: 브랜드 로고 <img> 태그에 loading="lazy"와 decoding="async"를 기본 장착했습니다. 유저의 화면 스크롤에 맞춰 필요한 로고만 비동기로 디코드되도록 유도하여 모바일 CPU의 부담을 싹 덜어주었습니다.
• 사용자 행동 예측 데이터 프리페치(Prefetch): 유저가 브랜드 카드에 마우스를 호버하거나 터치하는 순간, 상세 페이지 데이터를 백그라운드에서 미리 땡겨오도록(prefetch) 설정하고, React cache를 적용해 중복 API 호출을 막았습니다. 유저 입장에서는 클릭하자마자 페이지가 '착!' 하고 뜨는 마법 같은 경험을 하게 된 것이죠. 🥰

3. "어드민이 수정한 게 왜 안 바뀌죠?" 캐시 경계 설계의 깨달음

하지만 캐시(ISR)의 달콤함에 취해있다 보니 예상치 못한 운영 이슈가 터졌습니다. 어드민 대시보드에서 제가 직접 오타를 수정하거나 새 로고를 승인했는데도, 정작 홈 화면에는 1시간 동안 반영되지 않는 것이었습니다! 🤯

원인을 찾아보니, 관리자용 어드민 페이지와 일반 유저용 홈 페이지가 동일한 데이터 엔드포인트를 공유하고 있었기 때문이었습니다.

여기서 아주 값진 아키텍처적 교훈을 얻었습니다. "동일한 데이터라도 보여주는 '톤(Tone)'과 '목적'이 다르다면 캐시 경계를 명확히 분리해야 한다"는 것을요.

즉시 어드민 전용 전용 API 엔드포인트(/api/admin/brands)를 완전히 새로 파내어, 이 녀석은 캐시 없이 항상 실시간 DB 값을 긁어오는 force-dynamic으로 운영되도록 격리했습니다. 일반 유저들은 1시간 캐시된 빠른 화면을 보고, 어드민인 저는 실시간으로 완벽하게 동기화된 데이터를 보며 운영 효율을 극대화할 수 있게 되었습니다. 📊

올리브의 한 줄 요약 💡

"백엔드 아키텍처와 성능 최적화는 단순히 기술적 과시가 아닙니다. 유저에게는 지루한 '기다림의 시간'을 지워주고, 메이커에게는 '정확한 운영 데이터'를 보장해 주는 일, 이 또한 완벽한 프로덕트 경험(UX)을 완성하는 핵심 퍼즐입니다."

이어지는 [4편]에서는... 평화롭던 어느 날, 외부 스크랩봇의 무차별 핫링크 공격으로 인해 단 하루 만에 130GB 대역폭 폭탄을 맞고 Vercel 계정이 정지되었던 짜릿한(?) 위기 탈출기와 인프라 방어선 구축 스토리가 이어집니다. 💣 (진짜 눈물 없이 볼 수 없는 메이커 생존기입니다...)