특정 오류 메시지뿐만 아니라 다음과 같은 일반 디버깅 기법을 활용하면 문제를 더 빠르게 진단하고 해결할 수 있습니다.

1. RevenueCat 대시보드 활용하기

대시보드는 가장 먼저 사용하는 디버깅 도구입니다. 구성과 사용자 활동에 관한 실시간 데이터를 보여 줍니다.

고객 이력

1. RevenueCat 대시보드로 이동합니다.
2. Customer lists로 이동합니다.
3. 다음 항목으로 사용자를 검색합니다.
   • App User ID.
   • 이메일(설정한 경우).
   • 거래 ID.
4. 해당 사용자의 전체 구매 이력, 활성 Entitlement, 구독 상태를 확인합니다.

이를 통해 다음을 확인할 수 있습니다.

• 구매가 실제로 처리되었는가?
• 사용자가 어떤 Entitlement를 보유하고 있는가?
• 구독이 언제 만료되었는가?
• 실패한 거래가 있는가?

구성 검증

대시보드는 구성 문제에 대한 경고를 보여 줍니다.

• 서비스 자격 증명 누락.
• 스토어에서 상품을 찾을 수 없음.
• 패키지가 없는 Offering.
• 게시되지 않은 페이월.

2. 샌드박스와 프로덕션에서 테스트하기

환경별 문제를 잡아내려면 항상 두 환경 모두에서 테스트해야 합니다.

샌드박스 테스트(iOS)

장점

• 실제 결제가 발생하지 않습니다.
• 구독 갱신이 더 빠릅니다(5분 = 1개월).
• 구독 수명 주기를 손쉽게 테스트할 수 있습니다.

단점

• 샌드박스 계정 설정이 필요합니다.
• 가끔 불안정하거나 느립니다.
• 프로덕션과 동작이 다릅니다.

프로덕션 테스트

iOS의 경우: 샌드박스 계정으로 TestFlight를 사용하거나 별도의 "테스트용" 빌드를 만듭니다

Android의 경우: 라이선스 테스터와 함께 내부 테스트 트랙을 사용합니다

프로덕션에서 테스트해야 하는 시점

• 주요 출시 전.
• 구성을 크게 변경한 후.
• 전체 엔드 투 엔드 흐름을 검증할 때.

3. 더 빠른 테스트를 위해 Test Store 사용하기

RevenueCat Test Store는 샌드박스에서 겪는 여러 골칫거리를 없애 줍니다.

• 실제 스토어 의존성 없음: App Store Connect나 Google Play 없이도 동작합니다.
• 예측 가능한 결과: 구매의 성공/실패 여부를 직접 제어할 수 있습니다.
• 시뮬레이터/에뮬레이터에서 동작: 실기기가 필요 없습니다.
• CI/CD 친화적: 자동화된 테스트에 안성맞춤입니다.

자세한 내용은 다음을 참고하세요.

• iOS용 Test Store
• Android용 Test Store

4. 이상 동작이 발생하면 캐시 비우기

캐시된 데이터가 이상한 동작을 일으킬 때가 있습니다.

RevenueCat 고객 정보 캐시 비우기

iOS:

// SDK가 최신 데이터를 가져오도록 강제
Purchases.shared.invalidateCustomerInfoCache()

Android:

// SDK가 최신 데이터를 가져오도록 강제
Purchases.sharedInstance.invalidateCustomerInfoCache()

기기/앱 캐시 비우기

iOS:

1. 앱을 삭제합니다.
2. 기기를 재시작합니다.
3. 앱을 다시 설치합니다.

Android:

1. 설정 → 앱으로 이동합니다.
2. 대상 앱을 찾습니다.
3. 저장공간 → 캐시 삭제를 탭합니다.
4. Google Play 스토어 캐시도 함께 비웁니다.

5. RevenueCat 커뮤니티 확인하기

같은 문제를 이미 겪은 사람이 있을 가능성이 높습니다.

• RevenueCat 커뮤니티 포럼: 발생한 오류를 검색해 봅니다.
• RevenueCat 문서: 공식 문서와 가이드입니다.
• GitHub 저장소: 이슈와 PR을 확인합니다.

6. 프록시를 활용한 네트워크 디버깅

Charles Proxy나 유사한 도구로 네트워크 트래픽을 검사할 수 있습니다.

확인해야 할 항목

• api.revenuecat.com으로 향하는 API 요청.
• HTTP 상태 코드(200 = 성공, 401 = 인증 문제 등).
• 요청/응답 페이로드.
• 요청 소요 시간(느린 요청은 네트워크 문제를 시사합니다).

Charles Proxy 설정하기

1. Charles Proxy를 다운로드합니다.
2. 기기가 Charles를 프록시로 사용하도록 설정합니다.
3. 기기에 Charles 인증서를 설치합니다.
4. 앱을 실행하고 요청을 살펴봅니다.

7. 문제 범위 좁히기

디버깅할 때는 무엇이 문제를 일으키는지 범위를 좁혀 보세요.

최소 테스트 케이스 만들기

// SDK 초기화만 테스트
Purchases.logLevel = .debug
Purchases.configure(withAPIKey: "appl_xxx")
print("SDK initialized")

// Offering 가져오기만 테스트
Task {
    do {
        let offerings = try await Purchases.shared.offerings()
        print("Offerings fetched: \(offerings.all.count)")
    } catch {
        print("Error: \(error)")
    }
}

이를 통해 문제가 다음 중 어디에 있는지 판단할 수 있습니다.

• SDK 초기화.
• 네트워크/API 접근.
• 상품 구성.
• 앱의 UI/로직.

8. 샘플 앱과 비교하기

RevenueCat은 정상 동작이 확인된 공식 샘플 앱을 제공합니다.

• iOS 예제
• Android 예제
• Flutter 예제

샘플 앱을 클론한 다음 아래 단계를 진행하세요.

1. API 키를 본인 것으로 교체합니다.
2. 본인 구성으로도 정상 동작하는지 확인합니다.
3. 본인 구현을 샘플 코드와 비교합니다.

자주 발생하는 디버깅 시나리오 빠른 참조

디버깅 체크리스트

도움을 요청하기 전에 다음 단계를 모두 마쳤는지 확인하세요.

• 디버그 로깅을 활성화했는가(Purchases.logLevel = .debug).
• RevenueCat 대시보드에서 구성 경고를 확인했는가.
• 대시보드에서 고객을 확인했는가(해당하는 경우).
• 스토어와 RevenueCat 간에 상품 ID가 일치하는지 확인했는가.
• 플랫폼에 맞는 올바른 API 키인지 확인했는가.
• 샌드박스와 프로덕션 양쪽에서 테스트했는가(가능한 경우).
• 캐시를 비우고 앱을 재시작했는가.
• 커뮤니티 포럼에서 비슷한 문제를 검색했는가.
• 문제를 분리하기 위해 최소 테스트 케이스를 만들었는가.
• 공식 문서를 확인했는가.