게임 SDK로 소셜 로그인과 인앱 결제를 설계할 때의 체크리스트

로그인 제공자가 늘어날수록 설정도 제품이 됩니다

소셜 로그인은 버튼을 추가하는 일보다 제공자 콘솔, 번들 ID, 서명 키, 리디렉션 URI와 계정 연결 정책을 일관되게 관리하는 일이 더 어렵습니다. 개발·스테이징·운영 환경의 자격 증명을 분리하고, 탈퇴 뒤 재가입이나 같은 이메일의 다른 제공자 계정을 어떻게 처리할지 먼저 정해야 합니다.

제공자마다 요구하는 심사와 약관도 다릅니다. Apple은 다른 소셜 로그인을 제공하는 앱에 Sign in with Apple을 함께 요구하는 정책을 두고 있고, 제공자별로 이메일 비공개 릴레이 주소를 돌려주는 경우도 있어 이메일을 사용자 식별의 유일한 키로 쓰면 나중에 충돌이 납니다.

• 제공자별 콜백·패키지·스토어 설정
• 환경별 자격 증명 분리와 키 회전 절차
• 이메일이 아닌 내부 사용자 ID를 기준 키로 사용

게스트로 시작한 사용자를 어떻게 이어줄지가 핵심입니다

많은 게임이 진입 장벽을 낮추려고 게스트 로그인을 제공합니다. 문제는 그 사용자가 나중에 소셜 계정을 연결할 때, 기기를 바꿀 때, 또는 이미 다른 계정이 있는 상태에서 연결을 시도할 때입니다. 이 세 경우의 동작을 정하지 않으면 진행 데이터가 사라졌다는 문의가 반복됩니다.

계정 연결은 되돌릴 수 있어야 하고, 두 계정 중 어느 쪽 데이터를 남길지 사용자에게 선택하게 하거나 명확한 규칙을 공지해야 합니다. 운영팀이 수동으로 복구할 수 있는 경로도 함께 준비해 두는 편이 좋습니다.

• 게스트 계정 승급 시 데이터 이전 규칙
• 이미 연결된 계정이 있을 때의 충돌 처리
• 기기 변경과 재설치 시 복구 경로

결제 성공과 아이템 지급은 같은 사건이 아닙니다

스토어가 결제를 승인해도 게임 서버의 지급 요청이 실패할 수 있습니다. 영수증 ID를 멱등 키로 사용하고, 검증·지급·응답 상태를 분리해 저장해야 재시도에서 중복 지급을 막을 수 있습니다. 취소와 환불은 별도 운영 큐로 추적합니다.

영수증 검증은 반드시 서버에서 수행해야 합니다. 클라이언트가 보낸 성공 여부를 신뢰하면 변조된 요청으로 아이템이 지급될 수 있습니다. 검증에 실패한 영수증도 폐기하지 말고 기록을 남겨야 나중에 정상 결제였는지 판단할 수 있습니다.

• 서버 영수증 검증과 검증 실패 기록 보관
• 멱등 지급과 재시도 정책
• 복원·취소·환불 이력의 분리 추적

출시 전 반드시 통과할 시나리오

정상 성공만 확인하면 운영 중 가장 비싼 문제를 놓칩니다. 네트워크 단절, 앱 강제 종료, 스토어 응답 지연, 계정 전환, 동일 영수증 재전송을 테스트하고 로그에서 한 거래의 전체 경로를 찾을 수 있어야 합니다.

특히 결제 직후 앱을 강제 종료하는 시나리오는 반드시 넣어야 합니다. 실제 사용자는 결제 창이 오래 떠 있으면 앱을 껐다 켜기 때문에, 이 경로에서 복원이 동작하지 않으면 출시 직후 문의가 몰립니다.

• 결제 직후 강제 종료 후 재실행 시 복원
• 동일 영수증 재전송과 중복 지급 방지 확인
• 계정 전환 후 이전 계정의 구매 처리

운영 단계에서 필요한 조회 경로를 미리 만듭니다

출시 후 대부분의 문의는 "결제했는데 아이템이 없다"는 내용입니다. 이때 담당자가 사용자 ID나 영수증 번호로 검증 결과와 지급 상태를 한 번에 조회할 수 없으면, 개발자가 매번 로그를 뒤져야 하고 응대 시간은 계속 길어집니다.

거래마다 공통 식별자를 남기고 그 식별자로 클라이언트 로그, 서버 로그, 지급 기록을 묶을 수 있게 하면 1차 응대가 운영팀 선에서 끝납니다. 이 준비가 개발 기간에 며칠을 더 쓰더라도 출시 후 몇 주를 아껴줍니다.

• 사용자 ID·영수증 번호로 검색 가능한 조회 화면
• 거래 단위 공통 식별자의 로그 전파
• 운영팀이 직접 처리할 수 있는 재지급 절차

자주 묻는 질문