> ## Documentation Index
> Fetch the complete documentation index at: https://docs.replit.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Clerk Auth
> Clerk Auth가 커스터마이즈 가능한 브랜딩, 독립적인 사용자 계정, SSO 제공자를 갖춘 전용 인증 시스템을 Replit 앱에 제공하는 방법을 알아보세요.
Clerk Auth는 [Clerk](https://clerk.com)가 구동하는 전용 인증 시스템을 앱에 제공합니다. Replit의 로그인 시스템을 사용하고 Replit 계정을 생성하는 [Replit Auth](/ko/features/auth-and-identity/authentication)와 달리, Clerk Auth는 앱을 위한 **별도의 Clerk 테넌트**를 프로비저닝합니다. 앱의 사용자는 Replit 계정이 아니라 앱 내에서 직접 계정을 만들며, 브랜딩, 로그인 방법, 로그인 경험을 완전히 제어할 수 있습니다.
**Clerk Auth와 Replit Auth 비교** — **Clerk Auth**(이 페이지)를 사용하면 앱은 Replit과 독립적으로 완전히 커스터마이즈 가능한 브랜딩과 사용자 계정을 갖춘 전용 인증 테넌트를 얻습니다. \*\*[Replit Auth](/ko/features/auth-and-identity/authentication)\*\*를 사용하면 사용자는 Replit 계정으로 로그인하고 Replit 브랜드의 로그인 페이지를 보게 됩니다. 로그인 경험에 자체 브랜드를 적용하거나 Replit과 별개인 사용자 계정이 필요하다면 Clerk Auth를 선택하세요.
## Clerk Auth와 Replit Auth 한눈에 비교하기
| | Clerk Auth | Replit Auth |
| ------------- | -------------------------------- | ------------------------- |
| **사용자 계정** | 사용자가 앱 내에서 계정을 만듦(Replit 계정 불필요) | 사용자가 Replit 계정으로 로그인 |
| **브랜딩** | 완전히 커스터마이즈 가능 — 앱 이름, 아이콘, 색상 | Replit 브랜드 로그인 페이지 |
| **SSO 자격 증명** | 제공자별로 자체 OAuth 자격 증명 사용 | Replit의 공유 OAuth 앱 사용 |
| **환경** | 별도의 Development 및 Production 환경 | 단일 환경 |
| **추천** | Replit 추천 통합 없음 | 가입이 Replit Referrals에 반영됨 |
| **적합한 대상** | 커스텀 브랜드 앱, 전문/상업용 제품 | 빠른 설정, Replit 브랜딩이 허용되는 앱 |
## 시작하기
앱에 Clerk Auth를 추가하려면 Agent 프롬프트에 포함하세요.
```
[여러분의 앱 아이디어]를 만들고 Clerk Auth 기능을 포함하는 앱을 만들어 주세요.
```
Agent가 Clerk 테넌트 생성, 자격 증명 저장, 라우트 구성, 미들웨어 추가 등 모든 것을 처리합니다. Clerk 계정이나 수동 설정이 필요하지 않습니다.
## Clerk Auth가 Replit과 함께 작동하는 방식
Agent가 앱에 Clerk Auth를 설정할 때, 다음 작업을 수행합니다.
1. **전용 Clerk 테넌트 생성** — 앱은 별도의 Development 및 Production 환경을 갖춘 자체 Clerk 애플리케이션을 얻습니다
2. **자격 증명 프로비저닝** — API 키와 시크릿이 환경 변수로 저장됩니다
3. **프록시 구성** — 게시된 도메인에서 인증이 원활하게 작동합니다
4. **로그인 및 가입 라우트 설정** — 미리 만들어진 Clerk React 컴포넌트가 앱에 추가됩니다
5. **서버 측 미들웨어 추가** — API 라우트가 Clerk의 Express 미들웨어로 보호됩니다
Clerk 계정을 만들거나 인프라를 관리할 필요가 없습니다. 모든 것이 Replit에 의해 자동으로 관리됩니다.
## 기능
### 지원되는 기능
Clerk Auth는 앱에 다음을 제공합니다.
* **독립적인 사용자 계정** — 앱의 사용자는 Replit 사용자가 아니며, 앱의 Clerk 테넌트 내에서만 존재합니다
* **완전히 브랜드화된 로그인 페이지** — 로그인 및 가입 페이지의 앱 이름, 로고, 색상, 글꼴, 문구는 앱의 코드에서 구성됩니다
* **커스텀 브랜드 SSO** — 제공자별로 자체 OAuth 자격 증명을 제공하면 제공자의 OAuth 동의 화면에 일반 기본값 대신 앱의 이름과 브랜딩이 표시됩니다
* **이메일 및 비밀번호 인증** — 이메일 인증이 포함된 내장 가입 및 로그인
* **소셜 로그인(SSO)** — Google, GitHub, Apple, X(Twitter)로 로그인할 수 있습니다
* **사용자 관리** — Auth 패널에서 사용자를 조회, 검색, 관리
* **세션 처리** — 자동으로 관리되는 안전한 세션 토큰
* **Development 및 Production 환경** — 실서비스 전에 개발 환경에서 인증을 테스트
대부분의 Clerk Auth 구성은 Project Editor의 **Auth** 도구에서 관리할 수 있습니다 — Clerk 계정도 필요 없고 Clerk 대시보드를 다룰 필요도 없습니다.
### 지원되지 않는 기능
다음 기능은 현재 Clerk Auth에서 사용할 수 없습니다(직접 설정한 외부 Clerk 앱과 비교했을 때). 전체 비교는 [이 FAQ](#how-does-clerk-auth-compare-to-external-clerk)를 확인하세요.
* **전화번호로 로그인** — SMS 기반 로그인 및 인증
* **MFA 지원** — 최종 사용자를 위한 다중 인증
* **전체 SSO 제공자 지원** — 현재는 Google, GitHub, Apple, X만 지원됩니다
* **조직 테넌트** — Clerk의 조직 및 팀 멤버십 기능
## Development 및 Production 환경
Clerk Auth가 적용된 모든 앱은 완전히 분리된 두 개의 Clerk 환경을 얻습니다. 빌드하는 동안 개발/프리뷰 앱을 구동하는 **Development** 환경과 게시된 앱을 구동하는 **Production** 환경입니다. 이 환경들은 의도적으로 분리되어 있습니다 — 각각 별도의 API 키와 별도의 사용자 저장소를 가집니다.
### 별도의 API 키
각 환경에는 자체 publishable 키와 secret API 키가 있습니다. 앱에 노출되는 키는 앱이 개발 환경에서 실행되는지 프로덕션 환경에서 실행되는지에 따라 자동으로 전환됩니다.
* 워크스페이스에서 `CLERK_PUBLISHABLE_KEY`와 `CLERK_SECRET_KEY` 시크릿에는 Development 환경을 가리키는 **테스트 키**(`pk_test...` 및 `sk_test...`)가 들어 있습니다.
* 앱을 게시하면 게시된 배포는 Production 환경을 가리키는 **라이브 키**(`pk_live...` 및 `sk_live...`)로 실행됩니다. 접두사를 확인하려면 **Publishing → Overview → Adjust settings**를 열고 `CLERK_PUBLISHABLE_KEY`와 `CLERK_SECRET_KEY`를 확인하세요.
환경을 전환하기 위해 별도로 해야 할 작업은 없습니다 — Replit이 Development와 Production 모두의 키를 자동으로 관리합니다. 그냥 개발하고, 테스트하고, 게시하면 됩니다.
테스트 키를 라이브 키로 교체하거나, Secrets 패널에서 수정하거나, Clerk 대시보드에서 직접 설정을 변경하지 마세요. 그렇게 하면 자동 개발/프로덕션 전환이 깨지며, Replit이 관리하는 Clerk Auth에서는 지원되지 않습니다.
### 별도의 사용자 저장소
각 환경에는 자체 사용자 저장소가 있습니다. Development 환경에서 가입한 계정은 Production 환경에 존재하지 **않으며**, 그 반대도 마찬가지입니다.
* 개발/프리뷰 앱에서 테스트하는 동안 가입한 사용자는 Development 저장소에만 생성됩니다.
* 게시된 앱에서 가입한 사용자는 Production 저장소에만 생성됩니다.
* 세션, 사용자 메타데이터, 그리고 Clerk `userId`를 키로 사용하는 모든 데이터는 마찬가지로 계정이 생성된 환경으로 범위가 제한됩니다.
이는 예상된 동작입니다. 각 환경의 사용자를 확인하려면 Workspace에서 **Auth 패널**을 열고 **Users** 탭의 환경 토글을 사용하여 Development와 Production 사이를 전환하세요.
Development는 실험하고 빌드하는 공간이고, Production은 실제 앱 사용자들에게 서비스를 제공하는 공간입니다. 이 둘은 의도적으로 분리되어 있으므로 Development에서 생성된 계정과 데이터는 Production에 나타나지 않습니다.
## 사용자 관리
Project Editor의 **Auth 패널**은 인증된 사용자에 대한 완전한 뷰를 제공합니다. Clerk Auth가 앱을 위한 별도의 사용자 저장소를 생성하므로, 여기 나열된 사용자는 앱의 계정이며 Replit 계정이 아닙니다.
**Users** 탭에서 다음을 수행할 수 있습니다.
* 이메일, 이름, 마지막 로그인, 계정 생성일 등의 세부 정보와 함께 **모든 사용자 보기**
* 특정 사용자를 찾기 위해 **검색 및 필터링**
* 앱 접근을 제어하기 위해 **사용자 차단 또는 차단 해제**
* 다양한 기준으로 **사용자 정렬**
* **환경 전환** — Development와 Production을 토글하여 각각의 사용자를 관리
## 로그인 페이지 커스터마이즈하기
로그인 및 가입 페이지의 시각적 브랜딩 — 앱 이름, 로고, 색상, 글꼴, 문구 — 은 Auth 패널이 아닌 앱의 코드에서 구성됩니다. 변경하려면 Agent에게 요청하세요.
```
로그인 페이지의 제목을 [앱 이름]으로 바꾸고, [로고 설명]을 사용하고,
사이트의 색상과 어울리게 업데이트해 줘.
```
내부적으로 이는 ``에 전달되는 `appearance` 및 `localization` prop과 앱의 `public/` 디렉터리에 있는 로고 파일을 통해 구동됩니다. Agent는 이를 앱의 나머지 테마와 동기화된 상태로 유지합니다.
**Google, Apple, GitHub, X 자체 동의 화면**(사용자가 "Sign in with Google" 등을 클릭한 후 나타나는 화면)에 표시되는 앱 이름은 별개입니다 — 이는 해당 제공자에 등록된 OAuth 앱에서 가져오며, 로그인 페이지 코드를 수정해도 **변경되지 않습니다**. 이를 변경하려면 해당 제공자에 대한 [커스텀 OAuth 자격 증명](#configuring-oauth-credentials-for-an-sso-provider)을 구성하세요.
## 로그인 제공자 구성하기
Clerk Auth는 Google, GitHub, Apple, X를 소셜 로그인 제공자로 지원합니다. Auth 패널의 **Configure** 탭에서, 로그인 페이지에 표시할 제공자와 — Production에서는 — 각 제공자가 Replit이 관리하는 OAuth 자격 증명을 사용할지 아니면 브랜드화된 로그인을 위한 자체 커스텀 자격 증명을 사용할지를 제어할 수 있습니다.
**Configure** 탭을 엽니다. 사이드바의 **SSO providers** 아래에서 **Development** 또는 **Production**을 선택합니다 — **Development**는 Workspace의 개발/프리뷰 앱을 구동하고, **Production**은 게시된 앱을 구동합니다. 각 환경은 메인 패널에 자체 목록을 가집니다. 여기서 다음을 수행할 수 있습니다.
* **제공자 활성화 또는 비활성화** — 토글을 사용하여 제공자가 로그인 페이지에 표시될지를 제어합니다. 비활성화된 제공자는 사용자에게 숨겨집니다.
* **커스텀 OAuth 자격 증명 구성(Production 전용)** — 아래 [SSO 제공자용 OAuth 자격 증명 구성하기](#configuring-oauth-credentials-for-an-sso-provider)를 참고하세요.
### SSO 제공자용 OAuth 자격 증명 구성하기
기본적으로 제공자는 **Replit이 관리하는 자격 증명**을 사용합니다 — 로그인은 별도 설정 없이 바로 작동하지만, OAuth 동의 화면에는 Replit 브랜딩이 표시됩니다. 제공자의 개발자 콘솔에서 만든 자체 OAuth 클라이언트를 사용하려면 **Custom credentials**로 전환하여 동의 화면에 앱의 이름과 브랜딩이 표시되도록 하세요.
1. Project Editor에서 **Auth 패널**을 엽니다. **Configure** 탭으로 이동한 다음, 사이드바의 **SSO providers**에서 **Production**을 선택합니다.
2. 구성하려는 제공자 옆의 **Edit** 아이콘을 선택합니다. **Replit-managed credentials**가 기본으로 선택되어 있습니다.
3. **Custom credentials**를 선택합니다. 패널이 확장되어 자격 증명 필드와, 제공자 쪽에 등록해야 하는 값들을 담은 **Provider setup** 체크리스트가 표시됩니다.
4. 설정을 완료하기 위해 안내에 따르세요. 안내에는 콘솔과 관련 도움말 문서로 바로 이동하는 링크가 포함되어 있습니다. 해당 제공자의 [추가 자료](#additional-resources) 섹션에서도 이 도움말 문서를 찾을 수 있습니다.
5. 필요한 모든 자격 증명 값을 입력하세요.
6. 제공자의 개발자 콘솔에서 **Provider setup** 체크리스트에 나열된 모든 항목을 제공자의 개발자 포털에 등록하세요. 복사 아이콘을 사용하여 각 값을 정확히 복사하고, 완료한 항목을 체크하거나 완료 시 **Mark all as done**을 선택하세요.
7. **Save changes**를 선택하세요.
### 도메인 변경 후 설정 재확인하기
새 외부 도메인 연결이나 [Replit을 통한 도메인 구매](/ko/build/domain-purchasing) 같은 도메인 관련 작업은 앱의 리디렉션 콜백 URL과 JavaScript 원본을 변경할 수 있습니다. 이런 경우, 커스텀 자격 증명으로 구성된 제공자는 개발자 콘솔에 새 값을 다시 등록해야 할 수 있습니다.
도메인 변경 후에는 **Configure** 탭으로 돌아가세요. 설정 안내는 탭, 사이드바, **SSO providers** 목록의 제공자 옆에 경고 아이콘으로 표시됩니다. 제공자 옆에 경고 아이콘과 **setup steps remaining** 문구가 표시되면, 해당 제공자의 **Provider setup** 체크리스트에 완료해야 할 새 항목이 있다는 뜻입니다.
제공자의 편집 패널을 열고, **Provider setup** 아래의 업데이트된 값을 복사하여 제공자의 개발자 콘솔에 등록한 다음, **Mark all as done**을 선택하세요.
## 이메일 인증을 위한 도메인 설정
앱이 **이메일 및 비밀번호 가입**을 제공한다면, Clerk는 새 사용자의 받은편지함으로 인증 코드를 보냅니다. 도메인을 이메일 전송용으로 구성하면, 이 코드들이 지연되거나 스팸 필터에 차단되지 않고 앱의 URL에서 도착하도록 보장됩니다.
### 이 설정이 필요한 경우
앱이 다른 제공자가 관리하는 **외부 도메인**(예: Cloudflare, GoDaddy, Namecheap 등에서 등록한 도메인)을 연결한 경우에만 DNS 레코드를 구성해야 합니다.
앱이 다음 위치에서 제공되는 경우에는 설정이 필요하지 않습니다.
* `.replit.app` 서브도메인
* [Replit을 통해 구매한](/ko/build/domain-purchasing) 도메인
두 경우 모두 Replit이 DNS 레코드를 대신 관리합니다.
### 이메일 전송을 위한 DNS 레코드 추가하기
외부 도메인에서 인증 이메일을 보낼 수 있도록 앱을 승인하려면, 도메인 제공자에 DNS 레코드 세트를 추가하세요.
1. Project Editor에서 **Publishing**을 엽니다.
2. **Domains**를 선택합니다.
3. 연결된 외부 도메인을 찾아 **Manage**를 선택합니다.
4. **Authentication DNS setup required** 아래에서, Replit이 표시하는 CNAME 레코드를 복사하세요 — 이는 Clerk가 도메인에서 인증 이메일을 보내는 데 필요한 레코드입니다.
5. DNS 제공자(Cloudflare, GoDaddy, Namecheap 등)에 로그인하여 표시된 대로 각 레코드를 정확히 추가하세요.
DNS 변경이 전파되는 데 최대 48시간이 걸릴 수 있습니다. 레코드가 적용되면, 이메일 및 비밀번호 가입은 도메인에서 자동으로 인증 코드를 전송합니다 — Auth 패널에서 추가로 작업할 필요가 없습니다.
### 문제 해결
* **인증 이메일이 도착하지 않음** — DNS 제공자가 요구하는 후행 점(trailing dot)을 포함하여 Manage 패널에 표시된 대로 모든 레코드가 정확히 추가되었는지 확인하세요. 수신자의 스팸 폴더도 확인하세요.
* **레코드가 여전히 감지되지 않음** — DNS 전파 시간을 기다리고(최대 48시간), 여전히 누락으로 표시된 레코드가 있는지 Manage 패널을 다시 확인하세요.
## 보안 모범 사례
* **항상 서버 측에서 검증하세요** — UI뿐만 아니라 API 라우트에서도 인증을 확인하세요
* **환경 변수를 사용하세요** — 코드에 키나 시크릿을 하드코딩하지 마세요
* **프록시 미들웨어를 먼저 유지하세요** — Clerk 프록시는 Express 앱에서 body parser보다 먼저 마운트되어야 합니다
* **홈페이지를 로그인 화면으로 리디렉션하지 마세요** — 인증되지 않은 방문자도 랜딩 페이지에 접근할 수 있도록 유지하세요
## FAQ
### Clerk Auth를 사용하려면 Clerk 계정이 필요한가요?
아니요. Clerk Auth를 뒷받침하는 Clerk 테넌트는 Agent가 앱을 설정할 때 Replit이 자동으로 생성하고 관리합니다 — Clerk에 가입하거나 Clerk 인프라를 직접 관리할 필요가 없습니다.
### Replit이 관리하는 Clerk 인스턴스의 Clerk 대시보드에 접근할 수 있나요?
아니요. Replit이 관리하는 Clerk 인스턴스는 Clerk 대시보드를 통해 노출되지 않습니다. 대신 Project Editor의 **Auth** 도구에서 관리하세요 — 여기서 제공자를 구성하고, 사용자를 조회하고, Development와 Production 환경을 전환할 수 있습니다.
### Clerk publishable 키가 `pk_test`로 시작합니다. 라이브 키로 어떻게 전환하나요?
전환할 필요가 없습니다. Workspace의 Secrets 패널에서 보이는 `pk_test...` 및 `sk_test...` 키는 앱의 **Development** Clerk 환경에 속하며 빌드하는 동안 사용됩니다. 앱을 게시하면 배포는 Production 환경용 `pk_live...` 및 `sk_live...` 키로 자동으로 실행됩니다. 확인하려면 Workspace에서 **Publishing → Overview → Adjust settings**를 열고 게시된 앱의 `CLERK_PUBLISHABLE_KEY` 값을 확인하세요 — `pk_live`로 시작할 것입니다. 이 키들을 수동으로 편집하지 마세요. 전체 내용은 [Development 및 Production 환경](#development-and-production-environments)을 참고하세요.
### 개발 중에 만든 계정으로 게시된 앱에 로그인할 수 없는 이유는 무엇인가요?
Clerk Auth의 **Development** 및 **Production** 환경은 별도의 사용자 저장소를 가집니다. 개발/프리뷰 앱에서 만든 계정은 Development 환경에만 존재하며, 게시할 때 Production으로 복사되지 않습니다 — 게시된 앱에서 다시 가입해야 합니다. Clerk `userId`를 키로 사용하는 모든 데이터도 마찬가지입니다. Workspace에서 **Auth 패널**을 열고 **Users** 탭의 환경 토글을 사용하여 각 환경의 사용자를 확인하세요. 자세한 내용은 [별도의 사용자 저장소](#separate-user-stores)를 참고하세요.
### Clerk Auth는 무료인가요?
Clerk Auth는 현재 무료입니다. Replit의 다른 사용량 기반 서비스와 마찬가지로 나중에 사용량 기반 요금이 도입될 수 있습니다. 앞으로 발생할 수 있는 요금은 기존 Replit 청구를 통해 적용되며, 별도의 Clerk 청구서나 결제 수단이 필요하지 않습니다.
### Clerk Auth에도 외부 Clerk 플랜처럼 MAU 제한이 있나요?
아니요. Clerk Auth는 등급별로 MAU를 제한하는 외부 Clerk 플랜과 달리, 월간 활성 사용자(MAU) 제한을 두지 않습니다.
### Clerk Auth는 외부 Clerk와 어떻게 비교되나요?
Clerk Auth를 뒷받침하는 Replit 관리형 Clerk 테넌트는 여러분이 직접 자신의 Clerk 계정에서 만드는 Clerk 앱(**외부 Clerk**)과 비교했을 때 몇 가지 차이가 있습니다. 아래 표는 현재 두 가지가 어떻게 다른지 보여줍니다 — 이는 Clerk Auth의 현재 상태를 반영하며, 지원되는 기능 범위는 계속 발전할 예정입니다.
| | Clerk Auth | 외부 Clerk |
| ----------------- | ------------------------------------- | ------------- |
| **설정** | Replit이 자동으로 프로비저닝 | 직접 설정 |
| **Clerk 테넌트 소유권** | Replit이 관리하며 앱이 소유 | Clerk 계정이 소유 |
| **요금 구조** | 현재 무료(추후 사용량 기반 요금 예정) | 구독 + 사용량 기반 |
| **청구** | Replit 청구(현재 무료) | Clerk 계정에서 청구 |
| **MAU 제한** | 무제한 | 등급별 제한 있음 |
| **프록시 및 도메인 구성** | replit.app 및 구매한 도메인은 자동, 연결된 도메인은 수동 | 수동 |
| **SSO 제공자** | 특정 제공자만 지원: Google, Apple, GitHub, X | 더 많은 제공자 지원 |
| **사용자 관리 화면** | Project Editor의 Auth 도구 | Clerk 앱 대시보드 |
| **SMS** | 지원되지 않음 | 지원됨 |
| **MFA** | 지원되지 않음 | 지원됨 |
| **조직 테넌트** | 지원되지 않음 | 지원됨 |
### 수동으로 처리해야 하는 일반적인 Clerk Auth 설정에는 어떤 것이 있나요?
대부분의 Clerk Auth 설정은 자동화되어 있지만, 몇 가지 구성은 **Auth** 도구 외부에서 직접 조치를 취해야 합니다.
* **SSO 제공자를 위한 커스텀 OAuth 자격 증명** — 제공자의 동의 화면에 (Replit의 기본값이 아닌) 앱의 이름과 브랜딩을 표시하고 싶다면, 제공자의 개발자 콘솔에 OAuth 앱을 등록하고 자격 증명을 Auth 패널에 다시 입력하세요. [SSO 제공자용 OAuth 자격 증명 구성하기](#configuring-oauth-credentials-for-an-sso-provider)를 참고하세요.
* **외부 도메인의 이메일 인증을 위한 DNS 레코드** — 앱이 다른 제공자가 관리하는 외부 도메인을 연결하고 있다면, DNS 레코드를 추가하여 인증 이메일이 도메인에서 전송되도록 해야 합니다. [이메일 인증을 위한 도메인 설정](#domain-setup-for-email-verification)을 참고하세요.
### Replit이 관리하는 Clerk 대신 자체 Clerk 앱을 사용할 수 있나요?
네. 앱에 이미 Replit이 관리하는 Clerk 앱이 프로비저닝되어 있다면, 자체 외부 Clerk 앱을 연결하기 전에 먼저 삭제하세요.
1. Project Editor에서 **Auth** 패널을 엽니다.
2. **Configure** 탭으로 이동합니다.
3. 페이지 맨 아래로 스크롤하여 **Delete Clerk app**을 클릭합니다.
Clerk 앱을 삭제하면 Replit이 관리하는 Clerk 테넌트가 제거되고 여기에 연결된 도메인이 해제되어, 이후 자체 Clerk 앱을 연결하고 해당 도메인을 재사용할 수 있습니다. 앱에 아직 Replit이 관리하는 Clerk 앱이 없다면 이 단계를 건너뛰고 외부 Clerk 앱을 직접 통합할 수 있습니다.
## 추가 자료
* [기존 앱을 Clerk Auth로 마이그레이션하기](/ko/features/auth-and-identity/clerk-auth-migration) — 계정 연속성을 깨지 않고 기존 사용자 데이터가 있는 실제 서비스 앱을 Clerk Auth로 이전하기 위한 모범 사례
* [Google SSO 구성하기](/ko/features/auth-and-identity/google) — 커스텀 Google OAuth 자격 증명 설정
* [GitHub SSO 구성하기](/ko/features/auth-and-identity/github) — 커스텀 GitHub OAuth 자격 증명 설정
* [Apple SSO 구성하기](/ko/features/auth-and-identity/apple) — 커스텀 Apple Sign In 자격 증명 설정
* [X (Twitter) SSO 구성하기](/ko/features/auth-and-identity/twitter-x) — 커스텀 X OAuth 자격 증명 설정
* [Clerk 문서](https://clerk.com/docs) — 외부 Clerk 앱을 통합하는 빌더를 위한 레퍼런스