외부 기능을 위해 AAR 파일 하나를 추가한 뒤 Android 빌드가 실패했다. Unity 콘솔의 마지막 줄에는 Gradle 작업 실패만 보여 처음에는 SDK 버전을 무작정 바꿔 봤다. 상세 로그를 올려 보니 같은 클래스가 두 라이브러리에 들어 있다는 메시지가 앞쪽에 있었다.
AAR은 파일 하나처럼 보이지만 내부 클래스와 리소스, 다른 라이브러리 의존성을 함께 가져올 수 있었다.
실패 단계를 먼저 구분했다
C# 컴파일, Android 프로젝트 생성, Gradle 의존성 해석, dex 병합 중 어디에서 실패했는지를 확인했다.
Duplicate class ... found in modules sdk-core-A and sdk-core-B
이 메시지는 코드 문법보다 의존성 그래프 문제라는 단서였다. 두 AAR의 포함 내용과 Gradle dependency 결과를 비교했다.
직접 포함과 전이 의존성이 겹쳤다
Unity 플러그인 폴더에 넣은 공통 라이브러리를 새 SDK도 내부 의존성으로 가져오고 있었다. 어느 쪽 버전을 기준으로 할지 정하고 중복 파일을 제거하거나 Gradle exclude 규칙을 적용했다.
implementation('com.example:sample-sdk:1.2.3') {
exclude group: 'com.example', module: 'shared-core'
}
실제 group과 module은 공급 SDK의 문서와 생성된 의존성 그래프로 확인해야 했다.
빌드 성공 뒤 런타임도 확인했다
중복을 없앴다고 필요한 클래스까지 빠지면 앱 시작 후 ClassNotFound가 날 수 있었다. SDK 초기화, 대상 기능 호출, 앱 재실행을 실제 기기에서 확인했다. ProGuard나 코드 축소가 적용되는 빌드도 따로 봤다.
라이선스와 배포 범위 때문에 AAR 원본을 저장소에 넣어도 되는지도 확인했다. 바이너리를 직접 관리할지 패키지 저장소 버전을 고정할지 팀 규칙이 필요했다.
빌드 설정을 고친 뒤에는 깨끗한 환경에서도 같은 의존성을 받을 수 있는지 확인했다. 내 PC의 Gradle 캐시에만 남은 파일 덕분에 우연히 성공하면 다른 개발자나 배포 서버에서 다시 실패할 수 있었다.
바이너리도 의존성 코드였다
처음에는 AAR을 플러그인 폴더에 넣으면 끝나는 자산처럼 생각했다. 실제로는 버전, 전이 의존성, 빌드 설정, 런타임 초기화까지 영향을 주는 코드였다.
이후 네이티브 SDK를 추가할 때는 파일 복사보다 의존성 그래프와 지원 버전을 먼저 본다. 빌드의 마지막 오류보다 처음 깨진 단계와 구체적인 클래스 충돌을 찾는 습관도 이때 생겼다.