앱 MVP Android Lint baseline: 기존 경고·새 경고·CI 게이트를 나누는 5가지 기준

앱 MVP Android Lint baseline: 기존 경고·새 경고·CI 게이트를 나누는 5가지 기준

Android MVP가 커지고 경고가 쌓이면, Lint를 꺼 둘지 아니면 모든 경고를 한 번에 고칠지 사이에서 멈추기 쉽습니다. 이 글은 `lint-baseline.xml`을 ‘문제를 없애는 파일’이 아니라 기존 부채와 새 변경을 분리하는 기록으로 다룹니다. Lint 통과가 앱의 품질이나 출시 성공을 보장하지는 않으며, 기능·보안·접근성·실기기 검증은 별도입니다.

먼저 답하기: baseline은 기존 경고를 없애는 선언이 아니라 새 경고를 보이게 하는 경계입니다

Android Developers에 따르면 Lint는 앱을 실행하지 않아도 코드와 리소스에서 구조적 품질 문제를 찾아내는 정적 분석 도구입니다. 정확성, 보안, 성능, 사용성, 접근성, 국제화와 관련된 후보를 보고하며, 문제마다 설명과 심각도도 제공합니다. 그러나 같은 화면을 실제 사용자가 끝까지 수행할 수 있는지까지 증명하지는 않습니다.

프로젝트에 이미 많은 경고가 있다면 새 기능을 추가할 때마다 과거 경고와 새 경고가 한 보고서에 섞입니다. 이때 baseline은 현재 경고 집합을 파일로 기록하고, 이후 분석에서 그 목록에 든 경고를 걸러 새로 생긴 항목에 집중하도록 돕습니다. 즉 ‘경고가 없었다’가 아니라 ‘이 경고는 baseline에 있었고, 이번 변경에서 새로 생긴 것은 무엇인가’를 구분하는 장치입니다.

Android Developers의 Lint 공식 안내는 baseline이 있을 때 새 문제만 보고할 수 있고, baseline의 경고를 다시 만들려면 파일을 수동 삭제한 뒤 분석을 실행해야 한다고 설명합니다. baseline 자체를 해결 완료 목록으로 쓰지 말아야 하는 이유입니다.

두 번째 기준: 어떤 경고를 baseline에 넣을지와 어떤 경고를 막을지 따로 정합니다

처음 baseline을 만들 때 보고된 모든 항목을 자동으로 영구 면제하면, 이후에도 중요한 신호를 놓칠 수 있습니다. 반대로 시작부터 모든 경고를 차단하면 레거시 항목 때문에 작은 변경도 배포하기 어려워질 수 있습니다. MVP 팀은 ‘현재 작업을 전진시키는 경계’와 ‘나중에 갚을 부채’를 따로 문서화하는 편이 현실적입니다.

Android Gradle Plugin의 Lint 설정에서는 이슈를 enable, disable, warning, error, fatal 등으로 조정할 수 있습니다. 공식 API는 `abortOnError`가 오류 발견 시 프로세스 종료 코드를 설정하는지, `checkReleaseBuilds`가 release 빌드에서 fatal 오류를 검사하는지를 구분합니다. 따라서 설정 한 줄을 넣었다고 모든 variant와 모든 위험이 자동으로 차단된다고 해석하면 안 됩니다.

다음처럼 기준을 남겨 두세요.

• 새 코드에서 생긴 `fatal` 또는 팀이 `error`로 올린 항목은 CI 실패 후보로 본다.

• baseline에 기록된 항목은 담당 영역, 영향, 재검토 시점과 함께 별도 부채 목록으로 관리한다.

• 특정 이슈를 끈 이유는 ‘현재 불필요’인지 ‘잘못된 탐지’인지 구분한다.

• `@SuppressLint`나 `lint.xml` 예외는 코드 위치, 이슈 ID, 근거와 복구 조건을 남긴다.

• test와 production, debug와 release가 같은 규칙인지 아닌지 명시한다.

이 규칙은 Android 공식 설정 범위를 팀의 출시 방식에 맞춰 해석한 운영 제안입니다. 심각도를 어떻게 정할지는 제품의 위험, 대상 사용자, 배포 빈도와 코드 소유 구조에 따라 달라집니다.

앱 MVP에서 개발 범위와 출시 전 확인 항목을 함께 정리해야 한다면, 유인어스에 MVP 범위 상담하기로 현재 흐름을 공유해 보세요.

세 번째 기준: 로컬 편집기 경고와 CI 보고서는 같은 관찰이 아닙니다

Android Studio에서는 편집 중 표시되는 Lint와 IDE inspection을 볼 수 있습니다. 반면 Gradle 프로젝트에서는 프로젝트 루트에서 `./gradlew lint` 또는 variant별 `./gradlew lintRelease`처럼 task를 실행하고, 결과 XML·HTML 보고서 위치를 확인할 수 있습니다. Android Developers는 Lint가 자동으로 build에 포함되는 것이 아니므로 CI build에 명시적으로 실행할 것을 권장합니다.

따라서 ‘내 화면에서 경고가 안 보였다’와 ‘CI가 해당 variant를 분석해 새 경고 없이 끝났다’는 다른 기록입니다. CI가 호출한 task, Gradle/AGP 버전, 적용한 lint 설정, baseline 파일, 보고서 경로를 함께 남겨야 나중에 결과 차이를 설명할 수 있습니다.

변경 제출 → 대상 variant의 lint task 실행 → 보고서 보관
→ baseline 제외 항목과 새 항목 분리 → 차단 기준 적용
→ 기능 테스트·접근성·실기기 QA를 별도로 진행

Lint가 지적한 항목의 심각도는 우선순위를 돕지만, 특정 앱에서 장애가 발생한다는 확정 신호는 아닙니다. 반대로 Lint 결과가 깨끗해도 서버 응답, 로그인, 결제, 네트워크 전환처럼 실제 흐름에서만 보이는 문제는 남을 수 있습니다. 런타임에서의 느린 호출이나 정책 위반 후보를 살피는 기준은 Android StrictMode 점검 기준처럼 별도의 관찰 도구로 이어서 확인하세요.

네 번째 기준: baseline 갱신은 ‘정리’가 아니라 변경 검토입니다

공식 문서는 baseline을 새로 만들려면 기존 파일을 수동으로 삭제하고 Lint를 다시 실행하라고 안내합니다. 이것은 파일을 기계적으로 교체하는 절차가 아니라, 어떤 기존 항목이 사라졌고 어떤 항목이 새로 포함됐는지를 검토해야 하는 순간입니다. baseline이 줄었다면 실제 수정 때문인지, 검사 범위·variant·규칙이 바뀐 결과인지도 확인해야 합니다.

baseline 갱신 PR이나 배포 검토에는 최소한 다음을 기록하는 편이 좋습니다.

특히 baseline 파일을 버전 관리에 넣는 경우, 코드 변경 없이 파일만 크게 달라진 PR은 점검 대상이 됩니다. Android Developers도 baseline을 버전 관리에 넣어 팀과 공유할 수 있다고 설명하지만, 공유 가능하다는 사실이 모든 변경을 자동 승인한다는 뜻은 아닙니다.

다섯 번째 기준: Lint 통과, 제품 QA, 출시 관찰을 각각 닫습니다

MVP의 출시 기준은 한 개의 녹색 CI 표시로 끝나지 않습니다. Lint는 소스와 설정에서 탐지하는 구조적 문제의 후보를 다루고, 단위·통합 테스트는 정해진 동작을 확인하며, 실기기 QA는 기기·OS·네트워크·권한 상태에서 사용자가 실제 행동을 완료하는지 확인합니다. 출시 뒤에는 오류, 문의, 핵심 행동의 실패 신호를 별도 관찰해야 합니다.

출시 전 짧은 점검표

• 이번 변경이 적용되는 모듈과 variant를 정했는가

• baseline에 있던 항목과 이번 변경의 새 항목을 분리했는가

• CI가 실행한 lint task와 보고서 위치를 확인했는가

• severity·예외·차단 기준의 근거를 코드 리뷰에서 읽을 수 있는가

• 핵심 사용자 흐름의 테스트와 실제 기기 QA를 따로 수행했는가

• baseline 갱신이 있다면 항목 변화와 후속 부채 작업을 남겼는가

baseline은 경고를 숨겨 배포를 쉽게 만드는 목표가 아니라, 현재 부채를 인정한 상태에서 새 위험을 더 잘 보이게 하는 경계로 쓰는 편이 좋습니다.

자주 묻는 질문

Android Lint baseline을 만들면 기존 문제가 해결된 것인가요?

아닙니다. baseline은 기존 경고 집합을 기록하고 이후 분석에서 새 항목에 집중하도록 돕습니다. 기존 항목의 수정 여부와 영향은 별도의 부채 관리와 검토로 확인해야 합니다.

Lint가 통과하면 앱을 바로 출시해도 되나요?

그렇게 단정할 수 없습니다. Lint는 정적 분석 결과이며, 기능 테스트·서버 연동·권한·네트워크·실기기 사용 흐름은 별도로 확인해야 합니다. 팀의 출시 기준도 제품 위험에 맞춰 정해야 합니다.

baseline 파일을 언제 갱신해야 하나요?

현재 경고 집합을 다시 기준선으로 삼기로 팀이 결정했을 때 갱신을 검토할 수 있습니다. 기존 파일을 지우고 재생성하는 과정에서 검사 범위, 규칙, 추가·제거된 항목을 함께 검토하고 기록하세요.

CI에서는 어떤 Lint를 실행해야 하나요?

Android Developers는 CI build에 Lint를 명시적으로 실행하도록 권장합니다. 다만 어떤 task와 variant를 실행하고 어떤 severity를 차단할지는 앱 모듈 구성과 출시 정책에 맞춰 정해야 합니다.

Android MVP의 품질 게이트와 실제 사용자 흐름 검증을 분리해 설계하고 싶다면, 유인어스에 MVP 범위 문의하기로 문의해 보세요.