앱 MVP API 키: 앱 패키지·제한·교체를 나누는 5가지 기준

앱 MVP의 API 키를 패키지 포함 여부, 서버 비밀값, 제공사 제한, 사용 관찰과 교체 절차로 나누어 점검하는 기준입니다.

Sep 21, 2026

앱 MVP에 외부 지도·알림·분석·AI API를 붙이면 “키를 앱에 넣었으니 끝”이라는 상태가 생기기 쉽습니다. 그러나 앱에서 보여도 되는 식별자와 서버에만 있어야 하는 비밀값, 호출을 제한하는 설정, 실제 사용을 읽는 화면, 교체를 준비하는 기록은 같은 문제가 아닙니다. 이 글은 특정 앱의 유출·보안 수준·비용을 판단하지 않고, 출시 전에 API 키 운영 범위를 나누어 확인하는 기준을 정리합니다.

OWASP는 APK·IPA 같은 앱 패키지에 민감한 값을 하드코딩하면 패키지를 받은 사람이 값을 복구할 수 있다고 설명하며, 예로 API 키·비밀값·자격 증명·암호화 재료를 듭니다(C001, C002). Google은 API 키에 호출 주체와 허용 API를 제한하고, 실제 사용을 확인한 뒤 제한·교체를 진행하라고 안내합니다(C004, C006). 다만 같은 이름의 “API 키”라도 제공사별 역할과 제한 방식은 다르므로, 이 글의 체크리스트를 제공사 문서 대신 사용하면 안 됩니다.

먼저 구분할 것: 앱 식별용 키와 서버 비밀값은 같은 칸에 두지 않습니다

모든 문자열이 같은 위험도를 갖는 것은 아닙니다. 일부 모바일 SDK는 패키지명·서명 인증서·번들 식별자처럼 앱 출처와 결합한 제한을 전제로 클라이언트 키를 사용합니다. 반면 서버 간 호출에 쓰는 정적 비밀값, 관리자 권한 자격 증명, 토큰 서명 재료처럼 신뢰할 수 없는 기기에서 읽히면 안 되는 값은 앱 패키지와 분리하는지부터 검토해야 합니다(C001, C002).

이 구분의 목표는 “키를 숨긴다”는 선언이 아닙니다. 제공사가 어떤 값의 클라이언트 사용을 허용하는지, 어떤 값을 서버 경계에 남겨야 하는지, 값이 노출됐을 때 무엇을 제한·교체할 수 있는지를 각각 확인하는 것입니다.

OWASP는 상태를 가진 API 서비스가 적합하지 않을 때도 프록시 또는 API 게이트웨이가 정적 비밀값을 서버 측에 남기는 한 가지 방법이 될 수 있다고 설명합니다(C003). 그 구조가 필요한지는 실제 데이터 흐름과 제공사 약관을 보고 정하세요.

기준 1: 패키지에 들어가는 값을 먼저 목록으로 확인합니다

소스 코드만 보지 말고 Android Manifest, iOS 설정 파일, 문자열 리소스, 빌드 변수, 설정 파일, 번들된 라이브러리와 생성 산출물을 함께 확인하세요. OWASP는 코드뿐 아니라 앱 자산·리소스, 라이브러리, 개발·빌드 잔여물로 민감한 값이 패키지에 들어갈 수 있다고 설명합니다(C001, C002).

목록에는 값 자체를 복사하지 않아도 됩니다. `값의 용도`, `사용 제공사`, `클라이언트 사용 허용 여부`, `현재 제한`, `소유자`, `교체 경로`, `확인 날짜`를 남기면 다음 출시 때 무엇을 다시 확인할지 알 수 있습니다.

버전 관리에서 제외한 로컬 파일로 주입하는 방식은 실수로 소스 저장소에 넣는 위험을 줄일 수 있지만, 그 자체가 패키지 포함 여부나 제공사 제한 설정까지 검증해 주지는 않습니다.

우리 앱 MVP의 외부 연동·출시 기록을 함께 점검하기

기준 2: 제한은 “어디서”와 “무엇을”을 나누어 설정합니다

Google의 API 키 가이드는 호출 주체를 제한하는 애플리케이션 제한과, 키가 호출할 수 있는 API를 좁히는 API 제한을 함께 설명합니다(C004). Android Developers도 앱별 키·환경별 키, 앱 또는 인증서 기반 사용 제한, 사용 관찰을 API 키 운영 항목으로 제시합니다(C008).

예를 들어 Android 앱에 쓰도록 설계된 키라면 해당 플랫폼·앱 식별 조건이 맞는지, 허용 API 목록이 실제 필요한 범위를 넘지 않는지 따로 읽어야 합니다. 한 키를 서로 다른 플랫폼이나 호출 방식에서 함께 쓰면 하나의 제한 유형으로 모두 보호하기 어려울 수 있다는 점도 확인 대상입니다(C004).

제한을 추가한 직후 오류가 없었다는 관찰만으로 완전하다고 말할 수는 없습니다. 실제 로그인, 검색, 지도 보기, 업로드처럼 키가 쓰이는 핵심 흐름에서 요청이 예상대로 처리되는지 확인하고, 실패하면 어떤 제한과 어느 API 호출이 충돌했는지 기록하세요.

다른 제공사의 API는 허용 도메인·앱 서명·IP·OAuth 같은 방식이 다를 수 있으므로, Google의 예시를 다른 서비스의 정답으로 옮기지 않습니다.

기준 3: 서비스·앱·환경의 역할이 다르면 키도 나눌지 검토합니다

Google은 앱별로 별도의 키를 사용하면 한 키의 문제가 다른 앱까지 미치는 범위를 줄이는 데 도움이 된다고 안내합니다(C005). MVP에서는 최소한 운영 앱, 테스트 앱, 서버 호출처럼 책임과 제한 방식이 다른 경로가 같은 키를 공유하는지 확인해 볼 수 있습니다. 이 기준은 키 수를 늘리는 일이 아니라, 어떤 경로가 같은 권한·제한·소유자·교체 일정에 묶여 있는지 드러내는 일입니다.

각 키의 이름이나 별칭에 서비스·환경·소유 팀을 표시하고, 콘솔의 실제 사용 보고서에서 예상하지 못한 API 또는 플랫폼이 보이는지 관찰하세요. 관찰한 사용이 정당한지 확인하기 전 자동 추천 제한을 바로 적용하면 기존 기능을 끊을 수 있습니다(C006).

따라서 “제한 후보 확인”, “핵심 흐름 QA”, “적용”, “적용 뒤 관찰”을 하나의 완료 표시로 합치지 않는 편이 안전합니다.

기준 4: 로그·URL·문서에서 키가 다시 퍼지는 경로를 분리합니다

API 키를 URL 쿼리 파라미터로 전달하면 URL 스캔 과정에서 노출될 수 있으므로, Google Cloud는 지원되는 경우 헤더나 클라이언트 라이브러리 사용을 권장합니다(C007). 이는 모든 API가 같은 전달 방식을 지원한다는 뜻은 아닙니다. 제공사 문서가 쿼리 방식을 요구한다면, 값을 그대로 복사하는 화면·로그·오류 보고·지원 티켓·문서 링크를 어디까지 남기는지 별도로 검토해야 합니다.

여기서 해야 할 일은 기존 로그를 무단 삭제하는 것이 아니라, 새 로그와 공유 자료에 값 전체를 남기지 않는 규칙을 정하는 것입니다. 오류를 조사할 때는 키 값 대신 키 식별자, 발생 시각, 호출한 기능, 응답 코드, 적용된 제한과 앱 버전을 남기면 원인을 좁히는 데 도움이 됩니다.

이미 공개·공유된 값이 의심되면 노출 사실을 단정하거나 자체적으로 폐기하지 말고, 제공사의 사고 대응 문서와 조직의 승인 경로를 확인하세요.

기준 5: 교체는 새 값 생성이 아니라 전환을 확인하고 닫습니다

사용 중인 키를 제한·삭제·교체하기 전에는 실제 사용을 관찰해야 합니다. Google은 한 키가 여러 플랫폼에서 쓰이는지 확인하고, 이전 키의 트래픽이 옮겨간 것을 확인한 뒤 제한 또는 삭제를 판단하라고 안내합니다(C006). 모바일 앱은 사용자가 업데이트해야 새 값으로 바뀔 수 있으므로, 새 키를 만들었다는 사실과 기존 버전을 가진 사용자가 어떤 상태인지도 구분해야 합니다(C006).

값의 역할과 클라이언트·서버 경계를 기록합니다.
현재 사용 중인 앱·환경·API·제한을 콘솔과 배포 설정에서 확인합니다.
새 제한 또는 새 키를 적용할 대상과 필요한 앱 업데이트를 정합니다.
핵심 흐름 QA와 사용 관찰 결과를 같은 전환 기록에 연결합니다.
기존 키의 제한·비활성화·삭제 여부는 실제 전환 확인 뒤 제공사 절차와 승인 경로에 따라 결정합니다.

관련 글 앱 MVP 민감 화면 보호: 캡처·앱 전환 화면을 나누는 5가지 기준은 화면 전환 때 보이는 정보 범위를 다룹니다. 이번 글은 화면이 아니라 앱 패키지·API 설정·서버 경계·운영 전환 기록을 어떻게 분리할지에 초점을 둡니다.

앱 MVP의 API 연동·제한·전환 기록을 함께 설계하기

자주 묻는 질문

앱에 API 키가 있으면 모두 서버로 옮겨야 하나요?

그렇게 일반화할 수 없습니다. 제공사가 모바일 SDK와 앱 제한을 전제로 한 클라이언트 키 사용을 허용하는 경우도 있습니다. 반면 서버 간 호출용 정적 비밀값처럼 기기에 두지 않아야 하는 값은 앱 패키지와 분리하는지 검토해야 합니다. 각 제공사의 인증·제한 문서를 기준으로 역할을 나누세요.

제한을 걸면 키가 외부에 보여도 괜찮아지나요?

제한은 한 키가 사용할 수 있는 호출 주체와 API 범위를 줄이는 수단입니다. 특정 앱이 안전하거나 비용·데이터 접근 문제가 없다는 보장은 아닙니다. 값의 역할, 제공사의 제한 지원, 실제 사용 관찰과 교체 절차를 함께 확인하세요.

키를 새로 만들면 기존 키는 바로 지워도 되나요?

바로 지우기 전에 전환 상태를 확인하세요. 특히 모바일 앱은 사용자가 업데이트해야 새 키를 쓰게 될 수 있습니다. 기존 키가 쓰이는 플랫폼·API와 새 키로 옮겨간 사용을 관찰한 뒤, 제공사 절차와 조직의 승인 경로에 따라 제한·비활성화 또는 삭제를 결정합니다.

키가 URL이나 로그에 보이면 어떻게 해야 하나요?

값의 성격과 제공사의 사고 대응 절차를 먼저 확인하세요. 지원되는 API라면 키를 URL 쿼리에 넣지 않는 전달 방식을 검토하고, 새 로그와 공유 자료에는 키 전체를 남기지 않는 규칙을 적용합니다. 노출 사실을 추정만으로 단정하거나 승인 없이 기존 기록을 삭제하지 마세요.