앱 MVP Android 네트워크 보안 구성: 기본값·도메인·디버그를 나누는 5가지 기준
Android 앱 MVP에서 API 서버를 연결할 때 “HTTPS를 쓰고 있으니 끝났다”라고 정리하면, 실제로 무엇이 앱 전체 기본값이고 특정 도메인만의 예외인지, 개발용 신뢰 설정이 출시 빌드에 섞이지 않았는지를 확인하기 어렵습니다. Android의 Network Security Configuration은 코드 변경 없이 XML과 manifest 연결로 이 경계를 선언할 수 있게 합니다. 다만 선언 파일을 만들었다는 사실은 서비스 전체의 안전성이나 출시 승인을 뜻하지 않습니다.
이 글은 Android 앱 MVP의 네트워크 구성을 기본 연결 규칙, 도메인별 예외, 디버그 전용 신뢰, 인증서 선택, 릴리스 검수로 나누는 기록법입니다. 실제 API·인증서·SDK마다 허용 범위와 장애 대응은 다르므로, 각 제공사의 문서와 운영 책임자를 함께 확인해야 합니다.
먼저, 네트워크 설정 파일이 답하는 질문을 좁힙니다
Network Security Configuration은 앱의 네트워크 보안 설정을 XML 파일로 선언하고, manifest의 android:networkSecurityConfig 속성으로 연결하는 기능입니다. Android 공식 문서는 이 설정으로 신뢰할 인증 기관, 디버그 전용 재정의, 평문 트래픽, 인증서 투명성, 인증서 고정과 관련된 규칙을 구성할 수 있다고 설명합니다.
따라서 MVP의 첫 질문은 “보안 설정을 추가할까”가 아니라 “어느 연결에 어떤 규칙이 필요한가”입니다. 예를 들어 일반 API, 사내 개발 서버, 별도 CDN, 결제·인증 제공자는 같은 규칙을 쓸 수도 있고 서로 다른 조건을 가질 수도 있습니다. 아직 서비스가 정해지지 않았다면 예외를 미리 넓히기보다, 연결 대상과 데이터 성격을 UNKNOWN으로 남기는 편이 낫습니다.
1. 앱 전체 기본값과 특정 도메인을 한 규칙으로 섞지 않습니다
base-config는 특정 domain-config에 포함되지 않는 연결에 적용되는 기본 설정입니다. 반면 domain-config는 명시한 도메인에 적용되며, 여러 규칙이 겹치면 가장 구체적인 도메인 규칙이 사용됩니다. 이 차이를 기록하지 않으면 테스트 서버 하나를 위한 예외가 의도하지 않은 연결 범위로 퍼졌는지 판단하기 어렵습니다.
출시 후보를 검토할 때는 API 호스트, 인증 호스트, 파일·이미지 호스트, 분석·오류 보고 SDK의 실제 연결 대상을 목록으로 분리하세요. 각 행에는 “기본값 적용”, “도메인별 규칙”, “제공사 SDK가 별도로 관리”, “아직 확인 안 됨” 중 하나만 적습니다. 이 표는 방어 효과를 보장하는 문서가 아니라, 예외의 소유자와 다음 확인 지점을 남기는 운영 기록입니다.
2. HTTP 예외는 기능 요구와 출시 범위를 함께 적습니다
Android 공식 문서에 따르면 Android 9(API 28) 이상을 대상으로 하는 앱은 기본적으로 평문 HTTP 트래픽이 비활성화되어 있으며, HTTP 연결이 꼭 필요한 경우 이를 명시적으로 허용할 수 있습니다. 하지만 base-config에 넓게 허용하는 방식은 여러 도메인에 영향을 줄 수 있으므로, 단순한 연결 오류 해결책으로 쓰기보다 왜 해당 목적지가 HTTPS를 제공하지 않는지부터 확인해야 합니다.
예외가 필요한 경우에는 목적지 호스트, 필요한 기능, 임시인지 상시인지, HTTPS 전환 또는 제거 조건, 검토 책임자를 같은 변경 기록에 남기세요. 개발 기기에서 한 번 연결됐다는 관찰은 운영 사용자 환경에서도 같은 통신이 적절하다는 증거가 아닙니다. 민감한 데이터를 다루는 경우 Android 보안 체크리스트도 가능한 곳에서는 HTTP보다 HTTPS 사용을 권고합니다.
앱 MVP의 외부 연동 범위와 출시 점검 기록을 함께 정리하기
3. 개발용 인증서 신뢰는 debug-only로 분리합니다
개발 환경에서 HTTPS 연결을 시험해야 하지만 운영 인증서와 다른 인증 기관을 쓰는 경우가 있습니다. Android는 debug-overrides로 android:debuggable이 true일 때만 신뢰할 인증서를 지정하는 방법을 제공합니다. 공식 문서는 스토어가 debuggable 앱을 허용하지 않는다고도 설명합니다.
여기서 중요한 판단은 “개발에서 접속된다”와 “릴리스에서 신뢰 범위를 넓혀도 된다”를 같은 완료로 보지 않는 것입니다. 개발용 CA 파일의 위치, 적용 빌드 유형, 실제 테스트 대상, 릴리스 후보에서 해당 경로가 제외됐는지를 따로 확인하세요. 디버그 예외가 작동했다는 사실만으로 특정 API가 안전하거나 운영 서버 인증서가 올바르다고 결론 내릴 수는 없습니다.
4. 신뢰 앵커·인증서 고정은 장애 복구 계획 없이 추가하지 않습니다
기본적으로 Android의 보안 연결은 시스템에 사전 설치된 인증 기관을 신뢰합니다. 특정 도메인에서 자체 또는 제한된 인증 기관을 써야 한다면 trust-anchors를 구성할 수 있지만, 이 선택은 인증서 교체와 장기 운영에도 영향을 줍니다. 어떤 CA를 왜 신뢰하는지, PEM·DER 파일의 출처와 갱신 책임이 누구인지 기록해야 합니다.
인증서 고정은 허용할 공개키 해시를 제한하는 선택지입니다. Android 문서는 고정을 사용할 때 키나 CA를 바꿔야 해도 연결이 끊기지 않도록 백업 키를 포함하라고 안내합니다. 그러므로 “고정을 추가했다”는 체크 표시보다, 백업 키, 만료 처리의 의미, 인증서 교체 시 앱 업데이트 의존성, 연결 실패 시 사용자 안내와 되돌림 경로를 먼저 검토하는 것이 현실적인 MVP 기준입니다.
5. 릴리스 검수는 설정 파일·manifest·실제 목적지를 함께 봅니다
릴리스 전에 XML 한 파일만 읽고 끝내지 마세요. manifest가 올바른 설정 파일을 가리키는지, product flavor나 build type마다 어떤 리소스가 병합되는지, 실제 호출 대상이 도메인 규칙과 맞는지, 예외가 의도한 빌드에만 적용되는지를 같은 후보 빌드에서 확인합니다. Android의 application 요소 문서도 manifest의 애플리케이션 속성이 앱 전체 설정을 담는다는 점을 보여 줍니다.
아래 다섯 칸을 릴리스 기록에 남기면, 다음 담당자가 “연결 실패”와 “규칙 변경”을 분리해 볼 수 있습니다.
대상: 앱 전체 또는 정확한 호스트·하위 도메인
규칙: 기본값, 평문 예외, 신뢰 앵커, 디버그 재정의 중 무엇인지
근거: 기능 요구와 직접 읽은 제공사·플랫폼 문서
적용 빌드: 개발·테스트·릴리스 중 실제로 검증한 후보
복구 조건: 인증서 교체, 호스트 변경, 연결 실패 때 담당자와 재검토 시점
네트워크 설정은 앱 패키지에 들어가는 API 키의 역할과도 맞물릴 수 있지만 같은 문제는 아닙니다. 키의 역할·제한·교체 기록은 앱 MVP API 키 점검 기준에서 따로 확인할 수 있습니다. 설정 파일이 존재한다는 사실과 키 제한이 적절하다는 판단을 하나의 검수 결과로 합치지 마세요.
자주 묻는 질문
Network Security Configuration을 넣으면 모든 통신 문제가 해결되나요?
아닙니다. 이 설정은 Android 앱의 네트워크 보안 관련 규칙을 선언하는 수단입니다. 서버 인증서, DNS, 제공사 SDK, 사용자 네트워크, 앱 코드의 요청 처리까지 정상이라는 증거는 아닙니다. 실제 실패는 대상 호스트와 빌드 후보를 기준으로 별도로 재현·기록하세요.
개발 서버 때문에 HTTP를 앱 전체에 허용해도 되나요?
그렇게 일반화하지 않는 편이 좋습니다. Android 9 이상 대상 앱의 기본 동작과 실제 기능 요구를 먼저 확인하고, 예외가 필요하다면 정확한 도메인·기간·제거 조건을 남기세요. 광범위한 허용은 다른 연결에도 영향을 줄 수 있습니다.
인증서 고정은 MVP에 반드시 필요한가요?
필수라고 단정할 수 없습니다. Android는 인증서 고정을 지원하지만, 키·CA 교체 때 연결이 끊기지 않도록 백업 키를 포함하라고 안내합니다. 서비스의 위협 모델, 인증서 운영 책임, 장애 복구와 업데이트 경로를 검토한 뒤 결정하세요.
디버그 인증서를 신뢰하면 출시 빌드도 그 인증서를 믿나요?
debug-overrides는 android:debuggable이 true일 때만 적용되도록 설계되어 있습니다. 그래도 실제 빌드 변형과 manifest·리소스 병합 결과를 확인해야 하며, 개발 환경에서의 연결 성공을 릴리스 검수 완료로 보아서는 안 됩니다.
다음 결정: 규칙을 늘리기 전에 연결 목록을 확정합니다
첫 MVP에서는 모든 보안 기능을 한 번에 추가하는 것보다, 앱이 연결하는 목적지와 예외의 이유를 정확히 구분하는 편이 더 재현 가능한 출발점입니다. 기본값, 도메인별 예외, 디버그 전용 설정, 인증서 교체·복구를 각각 다른 완료 조건으로 두고, 실제 출시 후보에서 다시 읽어 보세요.
앱 MVP의 연동·출시 점검 기준을 유인어스와 함께 정리하기