앱은 그대로인데 푸시가 멈췄습니다: 1년 뒤 조용히 만료되는 것들

앱을 출시하고 1년쯤 지난 시점에 비슷한 연락이 옵니다. 어제까지 잘 가던 푸시 알림이 오늘은 한 건도 나가지 않는다는 이야기입니다. 그런데 코드를 건드린 사람도, 서버를 재시작한 사람도 없습니다.

원인은 대개 앱 안에 없습니다. 앱 바깥에 있는 인증서와 키에 유효기간이 걸려 있고, 그 날짜가 조용히 지나간 것입니다. 만료 당일에 경고창이 뜨지는 않습니다. 해당 기능만 소리 없이 정지합니다.

아무도 손대지 않아도 1년 뒤에 끝나는 것들이 있습니다

모바일 앱은 코드만으로 돌아가지 않습니다. 애플과 구글이 발급한 증명서가 붙어 있어야 푸시를 보내고 스토어에 새 버전을 올릴 수 있습니다. 이 증명서에는 발급일과 만료일이 적혀 있습니다.

만료의 결과는 항목마다 다릅니다. 사용자 기능이 즉시 멈추는 것과, 사용자는 멀쩡한데 개발사만 손발이 묶이는 것이 섞여 있습니다. 1년 된 앱이라면 아래 항목부터 확인하세요.

• 푸시 인증서(.p12): 발급 1년 뒤 만료, 푸시 전면 중단
• APNs 인증 키(.p8): 만료 없음, 대신 환경당 개수 제한
• iOS 배포 인증서: 앱은 돌아가고 업데이트 업로드만 차단
• 프로비저닝 프로파일: 재발급 후 다시 서명해야 함
• 안드로이드 업로드 키와 Play Console 권한: 보유자가 외주사면 요청 자체가 불가
• 애플 개발자 멤버십과 플레이 타깃 API 레벨: 날짜 기준으로 올라감

푸시가 한 번에 전부 멈추는 쪽은 .p12 인증서입니다

푸시 서버가 애플과 연결하는 방식은 두 가지입니다. 하나는 인증서를 서버에 설치하는 방식이고, 이때 쓰는 파일이 .p12 입니다. 애플 문서는 공급자 인증서가 1년간 유효하며 통신을 계속하려면 갱신해야 한다고 명시합니다.

만료되면 알림 몇 건이 실패하는 것이 아니라 연결 자체가 거부됩니다. 푸시가 전부 멈추는 이유입니다. 게다가 이 인증서는 앱 하나에 묶입니다. 앱이 세 개면 인증서도 세 개, 챙길 만료일도 세 개입니다.

인증서 방식은 앱 개수만큼의 만료일을 매년 새로 만들어 냅니다.

.p8 인증 키는 만료가 없지만 개수 제한이 있습니다

다른 방식은 인증 키(.p8)로 토큰을 만들어 보내는 방식입니다. 애플 문서에 이 키의 유효기간은 나오지 않습니다. 갱신할 날짜가 없고, 하나의 키로 팀의 여러 앱과 여러 서버를 함께 쓸 수 있습니다.

대신 개수 제한이 걸립니다. 팀 전체를 덮는 팀 스코프 키는 Sandbox와 Production 각 환경당 최대 2개입니다. 특정 번들 ID에 묶는 토픽 지정 키는 환경당 200개까지, 키 하나에 토픽 400개까지입니다.

그리고 .p8 파일은 발급 직후 한 번만 내려받을 수 있습니다. 애플 계정에 보관되지 않으니 파일을 잃으면 폐기하고 새로 발급하는 수밖에 없습니다. 2개 제한에 걸린 팀은 쓰던 키를 폐기해야 하고, 그 키로 보내던 서비스는 그 순간 푸시가 멈춥니다.

.p8로 바꾸면 관리 대상이 날짜에서 서버 코드로 옮겨갑니다

.p8은 만료일 관리에서 벗어나는 대신 다른 조건을 요구합니다. 토큰을 20분보다 자주 갱신해도 안 되고, 60분보다 드물게 갱신해도 안 됩니다. 발급 시각이 1시간을 넘은 토큰은 403 오류로 거부됩니다.

즉 .p8은 서버가 토큰을 주기적으로 다시 만들어야 제대로 돕니다. 외주 개발사에 .p12에서 .p8로 전환해 달라고 요청할 때는 설정 변경이 아니라 서버 수정이 포함된 작업이라고 보고 일정과 비용을 잡으세요.

배포 인증서가 만료되면 앱은 돌아가는데 업로드가 막힙니다

애플 설명은 분명합니다. 멤버십이 유효하면 App Store에 올라간 기존 앱은 영향을 받지 않지만, 만료되거나 폐기된 인증서로 서명한 앱과 업데이트는 더 이상 App Store Connect에 업로드할 수 없습니다.

이미 업로드만 해 두고 심사에 넣지 않은 빌드도 위험합니다. 폐기된 인증서로 서명돼 있으면 Invalid Binary로 표시될 수 있습니다. 급한 수정이 필요한 날에 이 사실을 발견하면 수정보다 인증서 재발급이 먼저가 됩니다.

사내 배포용 인하우스 인증서는 반대입니다. 이 인증서로 서명한 앱은 실행 자체가 안 되고, 새 인증서로 서명한 버전을 다시 배포해야 합니다. 스토어 배포와 사내 배포의 위험도를 같은 칸에 적어 두면 안 되는 이유입니다.

프로비저닝 프로파일은 재발급한 뒤 다시 서명해야 합니다

프로파일이 만료되면 수정이 아니라 재발급입니다. 애플 안내는 Profiles에서 해당 프로파일을 고르고 Edit를 누른 뒤 Generate로 다시 만들라고 적혀 있습니다. 그다음 기기에서 옛 프로파일을 지우고 앱을 다시 서명해야 합니다.

까다로운 부분은 보관 위치입니다. Xcode가 자동으로 만든 개발용과 배포용 프로파일은 개발자 계정 화면에 나타나지 않습니다. 외주사 맥 안에만 존재하고 계정에서는 보이지 않는 상태가 생깁니다. 대장에 누구의 장비인지까지 적어야 합니다.

안드로이드는 업로드 키보다 콘솔 소유권이 더 위험합니다

구글 플레이는 업로드 키와 앱 서명 키를 분리합니다. 구글 문서는 업로드 키를 잃거나 유출돼도 앱에서 잠기는 것은 아니라고 말합니다. 새 키를 만들어 인증서를 PEM으로 내보낸 뒤 Play Console에서 재설정을 요청하면 됩니다.

단, 그 요청은 Play Console에서 관리자 권한으로 넣어야 합니다. 개발자 계정이 외주사 명의면 발주사에는 요청을 넣을 사람이 없습니다. 반대로 앱 서명 키를 직접 관리하다 분실한 경우에는 재설정 자체가 불가능합니다.

위험한 쪽은 키 파일이 아니라 계정 명의입니다. 파일은 다시 만들 수 있지만, 남의 명의로 된 콘솔에는 요청을 넣을 수 없습니다.

안드로이드는 타깃 API 레벨도 날짜로 만료됩니다

플레이는 기준을 매년 올립니다. 2026년 8월 31일부터 신규 앱과 업데이트는 Android 16(API 36) 이상을 타깃해야 제출할 수 있습니다. 기존 앱은 Android 15(API 35) 이상이어야 신규 사용자에게 계속 노출됩니다.

기준에 못 미치는 앱은 자기 타깃과 같거나 낮은 OS 기기에서만 보입니다. 이미 설치한 사용자는 계속 씁니다. 구글은 2026년 11월 1일까지 연장 신청을 받는다고 안내했으니, 이 글이 나가는 10월 29일 기준으로는 사실상 마감입니다.

만료일은 사람이 아니라 자리에 붙여서 적으세요

실패는 담당자 기억에 맡겼을 때 일어납니다. 그 담당자가 퇴사하거나 외주 계약이 끝나면 만료일도 같이 사라집니다. 대장은 사람 이름이 아니라 역할과 계정을 기준으로 적어야 살아남습니다.

대장은 파일을 넣어 두는 곳이 아닙니다. .p8과 키스토어는 잠긴 보관소에 두고, 대장에는 무엇이 어디에 있고 누가 꺼낼 수 있는지만 적으세요. 확인 주기는 월 1회로 잡으면 충분합니다.

이 대장이 과한 경우와, 대장으로도 못 막는 것이 있습니다

푸시를 쓰지 않고 사내 배포도 없는 앱이라면 줄이 두세 개로 줄어듭니다. 운영 주체가 한 명이고 앱이 하나면 캘린더 알림 몇 개로 끝납니다. 양식을 다 채우는 것이 목적이 아닙니다.

반대로 대장으로 못 막는 것도 있습니다. 결제 수단입니다. 애플 개발자 프로그램은 멤버십 연 99 USD이고, 카드가 만료되면 날짜 관리와 무관하게 결제가 실패합니다. 계정 명의자와 결제 수단 담당을 함께 정해 두세요.

비슷한 운영 점검 글은 운영 노트에 모아 두었습니다. 애플 기준은 Apple 인증서 개요 문서에서 직접 확인할 수 있고, 인수인계와 계정 정리가 필요하면 Codeforest로 문의하세요.

결론: 만료일은 앱 밖에 있으니 밖에서 관리하세요

푸시가 멈추면 .p12 만료를 먼저 보고, 업데이트를 못 올리면 배포 인증서와 프로파일을 보세요. 푸시 연결을 .p8로 옮기면 만료일 한 줄이 사라지지만 서버가 토큰을 갱신해야 하고, 환경당 2개라는 제한이 새로 생깁니다.

안드로이드는 키 파일보다 계정 명의가 먼저입니다. 업로드 키는 구글이 재설정해 주지만, 요청을 넣을 권한이 발주사에 없으면 그 길도 막힙니다. 오늘 할 일은 위 표를 한 장 만들고, 각 줄의 담당 역할을 비워 두지 않는 것입니다.