[UI Test] GitHub Actions UI 테스트 실패 로그를 읽고 원인을 좁히는 순서

GitHub Actions에서 UI 테스트가 실패하면 로그가 너무 길어서 어디부터 봐야 할지 막막할 수 있습니다. 특히 Android 프로젝트에서는 Gradle 빌드 실패, androidTest 컴파일 실패, 에뮬레이터 실행 실패, 실제 테스트 assertion 실패가 한 로그 안에 섞여 보일 수 있습니다.

이럴 때는 로그를 처음부터 끝까지 모두 읽기보다 실패 유형을 먼저 나누는 편이 좋습니다. 테스트가 실제로 실행된 뒤 실패한 것인지, 아니면 테스트까지 가지 못하고 빌드나 환경 준비 단계에서 멈춘 것인지 구분해야 합니다.

막상 CI 로그를 정리해보면 마지막 줄보다 첫 번째 의미 있는 에러가 더 중요한 경우가 많습니다. 이 글에서는 GitHub Actions에서 Android UI 테스트 실패 로그를 볼 때 확인하면 좋은 순서를 정리해보겠습니다.

먼저 실패 유형을 나눈다

로그를 읽을 때 가장 먼저 할 일은 테스트가 실패한 것인지, 테스트까지 가지 못한 것인지 구분하는 것입니다. 같은 UI 테스트 실패처럼 보여도 실제 원인은 빌드, 테스트 코드 컴파일, 에뮬레이터 실행, assertion 실패로 나뉠 수 있습니다.

실패 유형	특징	먼저 볼 곳
의존성 설치 실패	패키지 다운로드, 캐시 문제	setup, install step
컴파일 실패	Kotlin/Java/TypeScript 에러	build, assemble step
androidTest 컴파일 실패	테스트 코드 import, API 변경	compileDebugAndroidTest
에뮬레이터 실패	부팅 시간, 권한, 이미지 문제	emulator, device step
테스트 assertion 실패	특정 테스트 케이스 실패	test report, stack trace

실제 테스트 assertion 실패가 아니라 컴파일 단계에서 실패했다면 테스트 시나리오를 고치기 전에 빌드 문제부터 해결해야 합니다. 화면 테스트라고 해서 항상 화면 코드가 원인인 것은 아닙니다.

로그 읽는 순서

GitHub Actions 로그는 길기 때문에 순서를 정해두고 보는 것이 좋습니다. 아래 순서대로 보면 원인을 조금 더 안정적으로 좁힐 수 있습니다.

1. 실패한 job 이름을 확인한다.
2. 실패한 step 이름을 확인한다.
3. 로그의 첫 번째 의미 있는 error 위치를 확인한다.
4. 마지막 summary만 보지 말고 원인 stack trace를 확인한다.
5. 로컬 재현 가능 여부를 판단한다.
6. 최근 변경 파일과 실패 지점을 연결해본다.
7. 민감 정보가 로그에 포함됐는지 확인한다.

마지막 줄의 Process completed with exit code 1만 보면 원인을 알기 어렵습니다. 이 메시지는 실패했다는 결과에 가깝고, 실제 원인은 그보다 위에 있는 경우가 많습니다.

실제로 로그를 따라가다 보면 마지막 에러만 보고 한참 헤매는 경우가 생기기 쉽습니다. 원인을 찾을 때는 가장 아래가 아니라 첫 번째로 의미 있는 에러를 먼저 보는 습관이 더 도움이 됩니다.

annotation과 raw log 같이 보기

GitHub Actions는 실패 위치를 annotation으로 보여주기도 합니다. annotation은 빠르게 실패 파일이나 라인을 확인하기 좋지만, 전체 맥락이 빠질 수 있습니다.

그래서 annotation으로 실패 위치를 확인한 뒤 raw log에서 앞뒤 로그를 함께 보는 편이 좋습니다. 특히 Android 빌드 로그는 하나의 에러가 여러 줄로 나뉘어 표시되는 경우가 많습니다.

보는 위치	장점	한계
Summary	실패 job을 빠르게 확인	원인 파악에는 부족
Annotation	파일/라인 확인 가능	빌드 도구별로 부정확할 수 있음
Raw log	전체 흐름 확인	길고 노이즈가 많음
Artifact	테스트 리포트/스크린샷 확인	업로드 설정 필요

운영 관점에서는 artifact도 중요합니다. UI 테스트라면 실패 시 스크린샷, 테스트 리포트, 에뮬레이터 로그가 남아 있어야 원인을 더 빠르게 확인할 수 있습니다.

예시 로그 분류

> Task :app:compileDebugAndroidTestKotlin FAILED
error: Unresolved reference: MainScreenTestRule

FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':app:compileDebugAndroidTestKotlin'.

이 경우는 UI 테스트가 실행되다 실패한 것이 아니라, 테스트 코드가 컴파일되지 않은 상태입니다. 따라서 에뮬레이터 설정이나 테스트 데이터보다 import, 테스트 유틸 변경, 모듈 의존성을 먼저 확인해야 합니다.

반대로 아래와 같은 로그라면 테스트 실행 이후의 실패로 볼 수 있습니다.

com.example.HomeScreenTest > showsTitle FAILED
java.lang.AssertionError: Expected text was not found

이 경우에는 화면 렌더링, 테스트 selector, 초기 데이터, 비동기 로딩 대기 조건을 확인해야 합니다. 로그에 테스트 케이스 이름이 나와 있다면 해당 화면이나 assertion부터 좁혀볼 수 있습니다.

로컬 재현 기준

CI 실패를 바로 수정하기 전에 로컬에서 재현 가능한지 확인하면 원인을 좁히기 쉽습니다. Android 프로젝트라면 실패 단계에 맞춰 아래 명령을 나눠 실행해볼 수 있습니다.

./gradlew assembleDebug
./gradlew compileDebugAndroidTestKotlin
./gradlew connectedDebugAndroidTest

컴파일 실패라면 connectedDebugAndroidTest까지 갈 필요 없이 컴파일 명령부터 확인하면 됩니다. 테스트 실행 이후 실패라면 에뮬레이터나 실제 기기에서 같은 조건으로 재현되는지 확인해야 합니다.

React Native나 웹 테스트라면 프로젝트 스크립트에 맞춰 test, lint, e2e 같은 명령을 확인하면 됩니다. 

민감 정보 제거 기준

CI 로그에는 생각보다 많은 정보가 들어갈 수 있습니다. 블로그에 실패 로그를 올릴 때는 원인 파악에 필요한 부분만 남기고 민감 정보는 [REDACTED]처럼 바꿔두는 편이 좋습니다.

• API URL은 공개 가능한 예시 URL로 바꾼다.
• 토큰 일부라도 보이면 마스킹한다.
• Firebase 설정 경로는 실제 프로젝트명이 드러나지 않게 바꾼다.
• keystore 경로는 공개하지 않는다.
• 내부 브랜치명이나 배포 환경명이 민감한지 확인한다.
• 테스트 계정 이메일은 예시 계정으로 바꾼다.
• 서버 응답 전문에 개인정보가 없는지 확인한다.

문제를 설명하려고 로그를 그대로 붙이면 내부 정보가 같이 노출될 수 있습니다. 원인을 보여주는 데 필요한 최소한의 로그만 남기는 것이 좋습니다.

테스트 기준

CI 로그 분석 흐름도 반복해서 확인할 수 있는 기준으로 정리해두면 좋습니다. 장애 대응이나 코드 리뷰 때 같은 순서로 보면 원인을 찾는 시간이 줄어듭니다.

• 실패한 job과 step을 구분했는지 확인한다.
• 첫 번째 의미 있는 error를 찾았는지 확인한다.
• 테스트 실행 실패와 테스트 컴파일 실패를 구분했는지 확인한다.
• 로컬 재현 명령을 확인했는지 확인한다.
• 로그에서 토큰, 서버 URL, 계정 정보가 제거됐는지 확인한다.
• artifact에 스크린샷이나 리포트가 남는지 확인한다.

자주 하는 실수

1. 로그 맨 아래만 보고 원인을 판단하는 경우가 있습니다. 맨 아래에는 종료 코드만 있고, 실제 원인은 훨씬 위에 있는 경우가 많습니다.

2. UI 테스트 실패라고 생각했지만 실제로는 테스트 코드 컴파일 실패인 경우도 있습니다. 이럴 때 화면 코드를 계속 고치면 시간이 오래 걸립니다.

3. annotation만 보고 raw log를 확인하지 않는 경우가 있습니다. annotation은 편하지만 전체 빌드 흐름이나 앞뒤 원인을 놓칠 수 있습니다.

결론

GitHub Actions 로그는 길지만, 실패 유형을 먼저 나누면 훨씬 읽기 쉬워집니다. 테스트가 실제로 실패한 것인지, 테스트 컴파일이나 에뮬레이터 실행 전에 멈춘 것인지부터 구분해야 합니다.

좋은 흐름은 job, step, 첫 번째 error, 로컬 재현, 민감 정보 제거 순서로 확인하는 것입니다. 마지막 summary만 보기보다 raw log에서 원인 stack trace를 함께 확인하면 문제를 더 안정적으로 좁힐 수 있습니다.