앱 MVP 의존성 검증: 저장소·버전·검사값·업데이트를 나누는 5가지 기준

Android MVP에서 라이브러리를 추가하는 일은 implementation 한 줄로 끝나지 않습니다. 실제 빌드에는 직접 선언하지 않은 전이 의존성, Gradle 플러그인, 저장소에서 내려받는 메타데이터까지 함께 들어옵니다. 따라서 “빌드가 됐다”는 결과와 “어떤 구성요소를 어떤 근거로 받아들였는가”는 다른 기록으로 남겨야 합니다.

이 글은 특정 앱이 안전하거나 배포 가능하다고 판정하지 않습니다. 대신 작은 팀이 기능을 추가하거나 외주 결과물을 인수할 때, 의존성 변경을 확인 가능한 결정으로 바꾸는 순서를 설명합니다. 출발점은 Android Developers의 dependency verification 안내와 Gradle의 dependency locking 문서입니다.

먼저 결론: 선언·해결·검증·갱신을 한 표로 섞지 않습니다

의존성 관리에서 가장 흔한 혼선은 build.gradle에 적힌 항목과 실제로 해결된 파일, 그 파일을 확인한 근거, 다음 업데이트 때 바뀌는 범위를 한 문서에 뒤섞는 것입니다. MVP는 항목 수가 적어 보여도 플러그인과 전이 의존성이 늘어나면 담당자가 바뀐 뒤 이유를 되짚기 어렵습니다.

첫 기록은 다음 다섯 칸이면 충분합니다. 기능을 위해 직접 선언한 모듈, 그 선언으로 함께 해결된 전이 모듈, 사용한 저장소, 고정 또는 잠금된 해결 버전, 검증 메타데이터의 변경 여부입니다. 이 표는 취약점 목록이나 법적 적합성 선언이 아닙니다. 다음 빌드에서 무엇이 달라졌는지 비교하기 위한 기준선입니다.

1. 기능 요구와 외부 구성요소의 범위를 먼저 분리합니다

“알림 SDK를 넣는다”처럼 기능 이름만 남기면, 이후 어느 모듈과 플러그인이 추가됐는지 확인하기 어렵습니다. 반대로 라이브러리 이름만 모아 두면 왜 필요한지 판단할 수 없습니다. 기능 요구, 직접 의존성, 플러그인, 전이 의존성은 서로 다른 칸에 기록합니다.

예를 들어 새 화면에 필요한 기능이 있다면 먼저 해당 기능을 담당하는 앱 모듈을 적고, 그 다음에 직접 추가한 좌표와 버전을 적습니다. 의존성 트리에서 따라온 항목은 ‘직접 선택’으로 표시하지 않습니다. 전이 의존성도 최종 빌드에 포함될 수 있으므로, 확인에서 제외한다는 뜻은 아닙니다. 다만 최초 결정 책임과 실제 해결 결과를 구분하는 것입니다.

이 기준은 외부 SDK 도입 기록에서 다룬 책임·동의·제거 판단과도 이어집니다. SDK 도입 여부를 정한 뒤에는, 그 SDK와 플러그인이 빌드에 들어오는 경로를 별도로 확인해야 합니다.

2. 선언 버전과 실제 해결 버전을 같은 것으로 가정하지 않습니다

Gradle은 의존성을 해결할 때 직접 선언한 모듈뿐 아니라 전이 의존성까지 선택합니다. 같은 선언이라도 저장소 구성이나 다른 모듈의 제약에 따라 실제 해결 결과가 달라질 수 있습니다. 그래서 코드 리뷰의 입력값과 릴리스 후보의 결과값을 같은 것으로 취급하지 않는 편이 낫습니다.

Gradle의 dependency locking은 해결된 버전을 lock file에 저장해 이후 빌드가 같은 버전을 사용하도록 돕는 기능입니다. 이 기록은 단지 “최신 버전으로 올리지 말자”는 뜻이 아닙니다. 어떤 변경 요청이 실제로 버전 차이를 만들었는지 드러내는 비교 기준입니다. lock file이 바뀌었다면 기능 코드만 바뀐 작업인지, 전이 의존성까지 달라진 작업인지 함께 검토할 수 있습니다.

동적 버전이나 자주 바뀌는 의존성은 이 방식의 비교가 어렵거나 예외가 될 수 있습니다. 그러므로 자동으로 최신을 받는 표기, 별도 저장소, 임시 모듈은 “일반 경로와 다름”으로 명시합니다. 이를 숨기지 않는 것이 배포 결과를 보장하는 것은 아니지만, 검토에서 빠지는 경로를 줄이는 데 도움이 됩니다.

MVP 빌드·외주 인수 범위를 현재 상황에 맞게 점검하기

3. 검사값과 서명이 답하는 질문을 구별합니다

Android Developers와 Gradle 문서는 gradle/verification-metadata.xml에 의존성 검증 정보를 두는 방식을 안내합니다. 검사값(checksum)은 내려받은 파일 내용이 기록한 값과 같은지 확인하는 데 쓰입니다. 서명(signature)은 해당 아티팩트를 만든 주체의 공개키와 연결해 출처를 확인하는 데 쓰입니다. 둘은 같은 질문에 대한 다른 이름이 아닙니다.

검사값이 맞더라도 그 값 자체를 어디에서 신뢰했는지 검토할 필요가 있고, 서명이 있더라도 신뢰할 공개키와 검증 범위를 결정해야 합니다. 따라서 ‘검증 통과’라는 한 줄보다 아래처럼 변경 단위를 남기는 편이 유용합니다.

• 검증 메타데이터에 추가·수정된 모듈과 파일

• 검사값, 서명, 신뢰 키 중 실제로 사용한 근거

• 공식 배포처 또는 공식 문서와 대조한 항목

• 확인하지 못한 항목과 다음 검토 담당자

Gradle 문서는 초기 메타데이터를 생성하는 과정이 현재 저장소에서 받은 값을 바탕으로 한다고 설명합니다. 즉 생성 명령은 시작을 빠르게 하지만, 그 결과가 독립적인 신뢰 판단을 대신하지는 않습니다. 처음 생성한 파일과 갱신된 파일 모두 코드 변경처럼 리뷰 대상에 넣는 이유입니다.

4. 처음 생성한 메타데이터를 최종 승인으로 부르지 않습니다

의존성 검증을 켜면 새 라이브러리나 새 버전에서 메타데이터 부족 또는 검증 실패가 나타날 수 있습니다. 이를 곧바로 제품의 문제나 공격 발생으로 단정하면 안 됩니다. 반대로 빌드가 계속된다고 해서 새로운 구성요소의 검토가 끝난 것도 아닙니다.

실무에서는 실패 메시지를 세 갈래로 나누면 다음 작업이 분명해집니다. 첫째, 새 모듈 또는 새 버전이라 필요한 기록이 없는 경우입니다. 둘째, 저장소별 아티팩트 차이처럼 확인이 필요한 경우입니다. 셋째, 출처·키·파일이 기대와 다른 경우입니다. 세 경우 모두 같은 조치가 아니라, 변경 요청과 신뢰 근거를 다시 읽는 작업이 필요합니다.

특히 외주 인수나 여러 개발 환경에서는 “로컬에서는 통과했다”는 말만으로는 부족합니다. 어떤 커밋, 어떤 lock file, 어떤 검증 메타데이터로 빌드했는지 함께 남겨야 다른 환경에서 같은 결과를 비교할 수 있습니다. 이 글은 특정 명령 실행이나 저장소 설정을 강제하는 문서가 아니라, 그 비교 기록의 최소 단위를 제안합니다.

5. 업데이트 요청은 코드·잠금·검증 파일을 함께 확인합니다

라이브러리를 올릴 때는 기능 코드의 diff만 보고 끝내기 쉽습니다. 그러나 실제 해결 버전이 바뀌면 lock file과 verification metadata도 함께 달라질 수 있습니다. 반대로 두 파일이 바뀌었는데 제품 코드가 바뀌지 않았다면, 무엇이 추가됐는지 더 주의 깊게 읽어야 합니다.

업데이트 검토는 다음 순서로 작게 운영할 수 있습니다. 먼저 변경 목적과 직접 의존성을 확인합니다. 다음으로 해결된 버전과 전이 의존성 차이를 확인합니다. 이어서 메타데이터·키링 변경이 요청 범위와 맞는지 봅니다. 마지막으로 같은 기준 파일로 빌드한 결과와, 확인하지 못한 예외를 기록합니다. 이 순서는 버그·보안·호환성 문제가 없음을 보증하지 않습니다. 다만 “무엇을 받아들였는가”라는 질문을 다음 담당자도 다시 검토할 수 있게 만듭니다.

자주 묻는 질문

dependency locking과 dependency verification은 하나만 하면 되나요?

아닙니다. locking은 이후 빌드에서 해결되는 버전을 기록하는 데 초점이 있고, verification은 다운로드한 구성요소의 검사값 또는 서명 정보를 검증하는 데 초점이 있습니다. 프로젝트의 저장소·배포 방식에 맞게 각각의 적용 범위를 결정하고, 둘의 변경 파일을 함께 검토하는 편이 좋습니다.

초기 검증 메타데이터를 생성하면 바로 신뢰해도 되나요?

생성 과정은 현재 해결되는 의존성의 정보를 기록하는 출발점입니다. Gradle 문서도 생성된 값의 신뢰 근거를 별도로 검토해야 한다고 안내합니다. 특히 핵심 모듈, 새 저장소, 새 키는 공식 출처와 변경 이유를 함께 확인해야 합니다.

전이 의존성은 직접 추가하지 않았으니 기록하지 않아도 되나요?

전이 의존성도 최종 빌드에서 해결될 수 있습니다. 직접 선택한 항목과 구분하되, 의존성 트리와 lock file에서 실제 포함된 항목을 확인할 수 있게 남기는 편이 좋습니다.

이 절차를 따르면 앱이 안전하거나 출시 가능한가요?

아닙니다. 이 절차는 의존성 변경을 확인 가능한 기록으로 만드는 방법입니다. 보안, 법적 의무, 호환성, 스토어 심사, 출시 가능 여부는 앱의 기능과 운영 환경에 따라 별도로 검토해야 합니다.

우리 앱 MVP의 배포·인수 기준을 먼저 정리하기

출처

• Android Developers — Dependency verification

• Gradle User Manual — Verifying Dependencies

• Gradle User Manual — Locking Versions