인증 시스템 마이그레이션: Supabase에서 Better Auth까지

Val Town의 인증 시스템 마이그레이션: Supabase에서 Better Auth까지

Val Town의 개발자 Tom MacWright가 자사의 인증(Authentication) 시스템을 Supabase에서 Clerk으로, 그리고 최종적으로 Better Auth로 마이그레이션하게 된 생생한 과정을 공유했습니다. 인프라의 변화 속에서 개발자가 마주한 현실적인 고민들을 상세히 짚어봅니다.

1단계: Supabase에서 Clerk으로의 이동

• 2023년, Val Town은 인프라 환경을 기존 Supabase에서 Render와 같은 전통적인 데이터베이스 환경으로 이전하기로 결정했습니다.
• 데이터베이스를 옮기면서 자연스럽게 기존 Supabase Auth를 대체할 솔루션이 필요했고, 그 대안으로 당시 각광받던 Clerk을 선택하게 되었습니다.

2단계: Clerk에서 겪은 치명적인 문제들

Clerk은 훌륭한 서비스임에도 불구하고, '소셜 플랫폼'이라는 Val Town의 특수한 아키텍처와는 맞지 않는 부분이 많았습니다.

① 사용자 테이블 외주의 한계

• Clerk은 자체 DB 대신 자신들의 시스템을 쓰라고 권장했지만, 이는 초당 5회라는 엄격한 호출 제한(Rate Limiting)으로 돌아와 서비스 장애의 원인이 되었습니다.
• 수많은 사용자의 아바타와 닉네임을 보여줘야 하는 소셜 기능 특성상, Clerk 데이터와 자체 DB를 웹훅(Webhook)으로 동기화해야 했고, 이 과정에서 데이터 불일치 버그가 빈번했습니다.

② 세션 관리의 단일 장애점(SPoF)

• 세션 갱신 권한을 전적으로 Clerk에 맡기다 보니, Clerk 서버가 다운되면 Val Town 웹사이트 전체가 마비되는 상황이 벌어졌습니다.
• 2025년 5월 이후 Clerk의 가동률이 불안정해지면서, 자체 서비스 신뢰도에 큰 타격을 입게 되었습니다.

3단계: 그럼에도 3년 동안 Clerk을 쓴 이유

• 개발 속도와 피로도: 잦은 기술 스택 변경은 팀 전체에 큰 스트레스와 속도 저하를 가져오기 때문이었습니다.
• 풍부한 SDK 지원: Remix, Fastify 등 다양한 프레임워크와의 연동이 매우 뛰어났고, 관리자 도구 또한 강력했습니다.
• 마땅한 대안의 부재: 당시 오픈소스 솔루션들은 관리가 소홀하거나, 다른 서비스들도 동일한 벤더 종속성 리스크를 가지고 있었습니다.

4단계: Better Auth로의 최종 정착

• 독립적인 오픈소스: 높은 코드 품질과 함께 외부 서버에 의존하지 않는 독립적인 운영이 가능하다는 점이 결정적이었습니다.
• 데이터 통제권 확보: 이제 세션 관리나 인증 처리를 위해 제3자의 서버 상태를 살피지 않아도 됩니다. 모든 데이터를 직접 관리할 수 있게 되었습니다.

5단계: 이전 과정과 교훈

• AI의 활용: 복잡한 마이그레이션 과정에서 LLM의 도움을 받아 2주 만에 Clerk과 Better Auth를 병행하는 하이브리드 마이그레이션을 무사히 완료했습니다.
• 핵심 통찰: "외부 서비스의 가동률이 곧 내 서비스의 가동률이 된다." 아무리 성공한 제품이라도 내 서비스의 유즈케이스에 맞는지 냉정하게 판단해야 합니다.

출처: blog.val.town/better-auth