better-auth가 인증에 한 일, better-i18n이 현지화에 하고 있는 일

"better-" 철학이 개발자 도구를 어떻게 재편하고 있는지, 그리고 i18n이 왜 같은 대우를 받아야 했는지에 대한 이야기입니다.

NextAuth.js나 Auth.js와 씨름하다가 better-auth를 사용해 보신 분이라면 그 느낌을 아실 것입니다. 라이브러리가 단순히 작동하는 것을 넘어 올바르게 느껴지는 그 순간 말입니다. API가 직관적으로 이해됩니다. TypeScript 타입이 완전합니다. 문서가 실제로 궁금했던 질문에 답해 줍니다. 도구와 씨름하는 것을 멈추고 제품을 만들기 시작할 수 있습니다.

바로 그 느낌이 better-i18n을 만든 영감이었습니다.

이것은 마케팅 글이 아닙니다. 현지화 분야의 개발자 경험이 왜 수년간 정체되어 있었는지, "better-" 철학이 i18n에 어떻게 적용되는지, 그리고 그것이 실제로 무엇을 의미하는지를 솔직하게 살펴보는 글입니다.

better-auth 효과

better-auth 이전에 Next.js의 인증 환경은 다음과 같았습니다:

• NextAuth.js / Auth.js — 기본 선택지. 강력하고 널리 채택되었지만, 악명 높은 복잡한 설정, 일관성 없는 TypeScript 지원, 그리고 많은 팀을 좌절시킨 v4에서 v5로의 마이그레이션 문제가 있었습니다.
• Clerk, Auth0, Supabase Auth — 제공업체가 예상하지 못한 무언가를 커스터마이징해야 할 때까지는 잘 작동하는 관리형 서비스들.
• 직접 구현 — "그냥 bcrypt와 JWT를 쓰면 돼"로 시작해서 보안 사고로 끝나는 방식.

그때 better-auth가 등장해서 말했습니다: 인증이 단순하고, 타입 안전하며, 2025년 개발자들이 실제로 일하는 방식에 맞게 설계된다면 어떨까?

그 결과는 놀라울 정도로 명쾌한 라이브러리였습니다. 처음부터 완전한 TypeScript 지원. 제약 대신 확장하는 플러그인 시스템. 보안 프로토콜 박사 학위가 필요 없는 세션 관리. 그냥 연결되는 데이터베이스 어댑터. 그냥 작동하는 소셜 로그인.

개발자들이 better-auth로 전환한 것은 더 많은 기능 때문이 아니었습니다. 그들의 시간을 존중했기 때문입니다.

i18n 문제는 같은 문제입니다

이제 현지화 환경을 살펴보겠습니다:

• react-i18next / i18next — 업계 표준. 검증되고, 매우 유연하지만, 상당한 보일러플레이트가 필요합니다. 타입 안전성은 나중에 추가된 기능입니다. App Router로 서버 사이드 렌더링을 하려면 신중한 수동 설정이 필요합니다. 모든 플러그인과 옵션의 학습 곡선이 실제로 존재합니다.
• next-intl — Next.js에 특화된 대규모 개선. 깔끔한 API, 빠른 설정. 하지만 Next.js 전용입니다. React Native 없음. Vue 없음. Astro 없음. 그리고 여전히 JSON 파일을 수동으로 관리해야 합니다.
• Crowdin, Lokalise, Phrase — 월 $40-385부터 시작하는 관리형 플랫폼, 기업 구매 주기를 위해 설계된 불편한 웹 인터페이스, 파일 내보내기, 업로드, 대기, 다운로드, 재가져오기를 반복하는 개발자 워크플로우.

익숙하게 들리지 않나요? 같은 패턴입니다:

두 경우 모두 빠져 있던 선택지는 무엇이었을까요? 기본적으로 단순하고, 필요할 때 강력하며, 전체적으로 타입 안전한 개발자 중심 도구입니다.

better-i18n이 "Better" 철학을 적용하는 방법

이름은 우연이 아닙니다. 우리는 better-auth에서 명시적으로 영감을 받았습니다 — 단순히 이름뿐 아니라 설계 철학까지. 그것이 어떻게 적용되는지 살펴보겠습니다:

1. 타입 안전성은 선택 사항이 아닙니다

better-auth는 TypeScript 지원을 @types 패키지로 나중에 추가한 기능이 아닌 핵심 기능으로 만들었습니다. better-i18n은 번역 키에 대해서도 같은 원칙을 적용합니다.

// 모든 키가 타입화됩니다. 자동 완성이 작동합니다. 오타는 컴파일 시 잡힙니다.
const t = useTranslations();
t("hero.title");     // ✅ 자동 완성이 제안합니다
t("hero.ttle");      // ❌ TypeScript 오류 — 키가 존재하지 않습니다

i18next 세계에서는 부분적인 타입 안전성을 얻으려면 추가 설정, 커스텀 타입 선언 파일, 플러그인이 필요합니다. better-i18n에서는 기본값입니다.

2. 가능한 곳에서는 Zero-Config, 필요한 곳에서는 완전한 제어

better-auth를 사용하면 몇 줄의 코드와 데이터베이스 어댑터만으로 시작할 수 있습니다. 여러 파일에 걸친 설정 의식이 필요 없습니다.

better-i18n도 같은 원칙을 따릅니다:

• CDN 전달이 즉시 작동합니다. 빌드 단계 설정이 없습니다. 번역을 게시하면 몇 초 안에 전 세계에 반영됩니다.
• 키 검색이 자동입니다. CLI가 AST 파싱으로 코드베이스를 스캔합니다. 모든 키를 수동으로 나열할 필요가 없습니다.
• Git 동기화가 기본 지원됩니다. 번역이 풀 리퀘스트로 전달됩니다. 내보내기/가져오기 작업이 없습니다.

하지만 제어가 필요할 때는 가능합니다. 엔터프라이즈를 위한 커스텀 AI 모델. 온프레미스 배포. 세분화된 권한. 플러그인 기반 SDK 아키텍처.

3. 다섯 가지 도구 대신 하나의 도구

better-auth는 "NextAuth + Clerk + 커스텀 미들웨어 + 세션 스토어 + 소셜 로그인 어댑터" 스택을 하나의 일관된 라이브러리로 대체했습니다.

better-i18n은 "react-i18next + Crowdin + 커스텀 추출 스크립트 + CDN 설정 + 타입 생성 도구" 스택을 하나의 일관된 플랫폼으로 대체합니다:

4. AI 네이티브 차별점

여기서 better-i18n은 better-auth가 해결해야 했던 것을 넘어섭니다. 인증에는 AI가 필요하지 않습니다. 현지화에는 절실히 필요합니다.

전통적인 번역 워크플로우:

1. 개발자가 키를 추출합니다
2. 개발자가 JSON 파일을 내보냅니다
3. PM이 번역 플랫폼에 업로드합니다
4. 번역가가 번역합니다 (며칠에서 몇 주)
5. PM이 번역된 파일을 다운로드합니다
6. 개발자가 가져와서 커밋합니다
7. PR 검토, 병합, 배포
8. 모든 언어 업데이트마다 반복

better-i18n의 AI 네이티브 워크플로우:

1. 개발자가 코드를 작성합니다 (키가 자동으로 검색됩니다)
2. AI가 브랜드 컨텍스트와 용어집 매칭으로 번역합니다
3. 번역가가 검토하고 승인합니다 (또는 신뢰할 수 있는 언어는 자동 승인)
4. 즉시 CDN에 반영됩니다

8단계에서 4단계로 줄었습니다. 소요 시간이 몇 주에서 몇 시간으로 단축됩니다.

그리고 MCP(Model Context Protocol) 통합을 통해 Claude나 Cursor에서 직접 번역을 관리할 수 있습니다:

"Claude, 새 온보딩 플로우를 독일어와 프랑스어로 번역해 줘,
우리 브랜드 보이스 용어집에 맞춰서."

다른 어떤 현지화 플랫폼도 이것을 제공하지 않습니다. AI와 함께 이미 작업하는 개발자를 위해 구축했을 때 일어나는 일입니다.

솔직한 비교

"better-" 접두사는 책임을 수반합니다: 특정 사용 사례에 실제로 더 나아야 합니다. better-i18n이 진정으로 뛰어난 부분과 대안이 이기는 부분을 솔직하게 정리했습니다:

better-i18n이 이기는 곳

대안이 이기는 곳

솔직한 답변: 이미 검증된 i18next 설정과 성숙한 번역 파이프라인이 있다면, better-i18n으로의 마이그레이션은 비용이 가치를 정당화하지 못할 수 있습니다. 하지만 새 프로젝트를 시작하거나, 현재 워크플로우에서 서비스 간에 JSON 파일을 수동으로 이동하고 있다면, "better-" 접근 방식이 상당한 시간을 절약해 드릴 것입니다.

개발자 도구의 "Better" 패턴

better-auth와 better-i18n은 더 넓은 트렌드의 일부입니다: 불필요한 복잡성을 현상 유지로 받아들이기를 거부하는 개발자 도구들.

패턴은 다음과 같습니다:

1. 기존 강자가 지배합니다 선발자 이점과 커뮤니티 관성으로 (NextAuth, react-i18next)
2. 고통스러운 점들이 쌓입니다 하지만 "원래 이런 것"으로 받아들여집니다 (복잡한 설정, 나쁜 타입, 수동 워크플로우)
3. 새로운 도구가 등장합니다 현대적인 가정에서 처음부터 시작하며 (TypeScript 우선, AI 네이티브, git 네이티브)
4. 얼리 어답터들이 전환합니다 새 도구에 더 많은 기능이 있어서가 아니라, 덜 답답하기 때문에
5. 생태계가 변합니다 새로운 표준이 모든 사람의 기대치를 높이면서

우리는 다음에서 이것을 목격했습니다:

• Prisma가 raw SQL 쿼리 빌더를 대체
• Tailwind가 CSS-in-JS의 복잡성을 대체
• Vite가 webpack 설정의 고통을 대체
• better-auth가 NextAuth의 불만을 대체
• better-i18n이 번역 파일 셔플을 대체

공통 실마리는 무엇인가요? 개발자 경험은 있으면 좋은 것이 아닙니다. 그것이 제품 그 자체입니다.

시작하기

i18n에서 "better-" 철학이 어떤 느낌인지 보고 싶다면:

빠른 시작 (5분)

# SDK 설치
npm install @better-i18n/react

# 또는 Next.js용
npm install @better-i18n/next

// 앱을 감쌉니다
import { I18nProvider } from "@better-i18n/react";

function App() {
  return (
    <I18nProvider project="your-project" locale="en">
      <YourApp />
    </I18nProvider>
  );
}

// 어디서나 번역을 사용합니다
import { useTranslations } from "@better-i18n/react";

function Hero() {
  const t = useTranslations();
  return <h1>{t("hero.title")}</h1>;
}

무료 티어에는 1,000개의 키와 2개의 언어가 포함됩니다 — 이 접근 방식이 여러분에게 적합한지 평가하기에 충분합니다.

마지막 생각

better-auth는 인증이 단순화를 희생하지 않고도 단순할 수 있음을 증명했습니다. 타입 안전성이 나중에 추가되는 것이 아닌 기본으로 내장될 수 있음을. 개발자 경험을 위해 설계하는 것이 가치 있음을.

better-i18n은 현지화에 적용된 동일한 도전입니다. i18n 생태계가 같은 "better-" 대우를 받을 자격이 있다고 생각합니다 — 그리고 지금까지의 반응을 보면, 우리만 그렇게 생각하는 것이 아닌 것 같습니다.

현재 i18next 설정 파일을 보면서 왜 이렇게 복잡해야 하는지 궁금했던 적이 있다면, 왜 이것이 존재하는지 이해하실 것입니다.

better-i18n을 무료로 시도해 보세요, 또는 문서를 읽어보세요. 이미 better-auth를 사용하고 있다면, 바로 집처럼 편하게 느끼실 것입니다.