Automating Android Build Repair: Bridging the Reasoning-Execution Gap in LLM Agents with Domain-Specific Tools

1. 연구 배경 및 문제 제기 (Problem)

• 안드로이드 빌드 실패의 현실: 안드로이드는 세계 최대 모바일 플랫폼이지만, 오픈소스 프로젝트의 상당수 (약 68.7%) 가 초기 빌드 환경에서 바로 빌드되지 않는 문제가 있습니다. CI/CD 파이프라인이 있더라도 빌드 오류 수정 및 환경 유지보수에 막대한 노력이 소요됩니다.
• LLM 의 한계: LLM 은 코드 수정에 유망하지만, 안드로이드 빌드 오류와 같은 환경 의존적이고 일시적인 (transient) 빌드 실패를 해결하는 데는 아직 연구가 부족합니다.
• 핵심 문제: LLM 은 빌드 오류를 해결하는 고수준의 지식 (High-level knowledge) 을 가지고 있음에도 불구하고, 이를 **저수준의 명령어 시퀀스 (Low-level shell commands)**로 정확하게 변환하고 실행하는 데 어려움을 겪습니다. 즉, "무엇을 해야 하는지"는 알지만 "어떻게 명령어로 구현할지"에서 실패합니다.

2. 주요 기여 (Key Contributions)

A. AndroidBuildBench (벤치마크 데이터셋)

• 규모: 43 개의 인기 있는 오픈소스 안드로이드 프로젝트의 커밋 히스토리에서 선별된 1,019 개의 재현 가능한 빌드 실패 사례를 포함합니다.
• 검증 가능성: 각 실패 사례는 이후의 성공적인 커밋 (수정된 버전) 과 짝을 이루어, 해결책이 실제로 유효함을 보장합니다.
• 데이터 구성:
  • Human-Committed: 실제 개발자가 만든 PR过程中的 실패.
  • Augmented Dependency: 빌드 파일 (build.gradle 등) 만 변경하여 인위적으로 생성된 의존성 오류.
  • LLM-Generated: LLM 이 생성한 코드로 인한 빌드 실패 (AI 보조 개발 시나리오 반영).
• 오류 유형: 구문 오류 (Syntax), 누락된 리소스 파일, 설정 오류, 라이브러리 부재, NDK 오류 등으로 분류됩니다.

B. GradleFixer (새로운 에이전트 프레임워크)

• Tool Bridging 전략: 일반적인 쉘 명령어 대신 **도메인 특화 도구 (Domain-Specific Tools)**를 에이전트에 제공합니다.
• 구현: LLM 에이전트가 쉘을 직접 호출하는 대신, 다음과 같은 API 형태의 도구를 사용합니다.
  • run_build: 빌드 실행 및 결과 반환.
  • run_gradle: 특정 Gradle 태스크 실행.
  • change_java_version: 환경의 JDK 버전 변경.
• 목적: 복잡한 명령어 구문과 시퀀싱 부담을 줄이고, 에이전트의 추론 능력을 실제 실행에 집중시킵니다.

3. 실험 방법 및 설정 (Methodology)

• 모델: Gemini-2.5-Pro 를 코어 LLM 으로 사용.
• 비교 대상 (Baselines):
  • Coding-Assistant: 파일 수정만 가능 (명령어 실행 불가).
  • Hierarchical Agent: 2 단계 에이전트 구조.
  • Gemini-CLI (No Shell): 파일 읽기/쓰기만 가능, 쉘 불가.
  • Gemini-CLI (Shell): 일반적인 파일 조작 및 일반 쉘 명령어 사용 가능 (SOTA 기준).
  • GradleFixer (Ours): 일반 쉘 대신 도메인 특화 도구만 사용.
• 평가 지표: Pass@k (k 번의 시도 중 성공 확률).

4. 실험 결과 (Results)

• 성능 향상: GradleFixer 는 모든 오류 카테고리에서 기존 최첨단 에이전트 (Gemini-CLI with Shell) 를 크게 능가했습니다.
  • Pass@1 성공률: GradleFixer (81.4%) vs Gemini-CLI (Shell, 65.1%).
  • 특히 의존성 (Dependency) 관련 오류에서 성능 격차가 두드러졌습니다.
• 도구 구체성의 영향: 도구가 더 구체적일수록 (Shell > run_gradle > run_build) 성능이 향상되었습니다. 이는 에이전트가 불필요한 탐색을 줄이고 핵심 작업에 집중할 수 있기 때문입니다.
• 모델 크기와 비용 효율성:
  • 작은 모델 (Gemini-2.5-Flash) 을 GradleFixer 와 함께 사용했을 때, 큰 모델 (Gemini-2.5-Pro) 을 일반 쉘과 함께 사용하는 것보다 더 높은 성능을 보였습니다.
  • 이는 도메인 특화 도구가 모델의 추론 능력을 극대화하여, 더 큰 모델의 계산 비용 없이도 높은 효율을 달성할 수 있음을 시사합니다.

5. 심층 분석 및 통찰 (Analysis & Insights)

• 추론 - 실행 격차 (Reasoning-Execution Gap): 일반 쉘 에이전트는 올바른 명령어 (예: ./gradlew assembleDebug) 를 알고 있음에도 불구하고, 이를 올바른 컨텍스트와 순서로 실행하지 못해 실패했습니다. 반면, 도메인 도구는 이를 API 호출로 단순화하여 성공률을 높였습니다.
• 오류의 복잡성: 실패한 사례는 주로 변경된 코드 라인 수가 매우 많은 경우에 발생했습니다. 이는 작은 단위 변경을 자주 빌드하는 것이 자동화 복구 에이전트의 성공 확률을 높인다는 실용적인 시사점을 줍니다.
• Case Study:
  • Case 1 (Missing Parameter): GradleFixer 는 호출 체인 전체를 수정하는 체계적인 접근을 취한 반면, 쉘 에이전트는 로컬 패치만 시도하다가 실패했습니다.
  • Case 2 (Misleading Logs): GradleFixer 는 misleading warning(거짓 경고) 을 무시하고 스택 트레이스를 통해 실제 원인 (Data Binding 오류) 을 찾아냈으나, 쉘 에이전트는 경고에 매몰되어 "버전 지옥"에 빠졌습니다.

6. 결론 및 의의 (Significance)

• Tool Bridging 의 유효성: LLM 에이전트의 성능을 높이기 위해서는 단순히 더 큰 모델을 사용하는 것보다, **도메인 지식을 내포한 특화 도구 (API-like abstractions)**를 제공하는 것이 훨씬 효과적입니다. 이는 에이전트의 추론 능력을 실제 실행으로 연결하는 다리 역할을 합니다.
• 실용적 가치: 이 연구는 안드로이드 개발의 진입 장벽을 낮추고, "Vibe-coding"(비개발자나 LLM 이 빌드 실패를 두려워하지 않고 실험하는 개발 방식) 과 같은 새로운 개발 패러다임을 가능하게 합니다.
• 미래 연구 방향: 다른 개발 생태계 (iOS, 웹 등) 로의 도구 전이, 그리고 에이전트가 스스로 도메인 도구를 생성하고 개선하는 자동화 연구로 이어질 수 있습니다.

요약하자면, 이 논문은 LLM 이 가진 고수준의 지식을 저수준의 실행으로 효과적으로 연결하기 위해서는 '일반적인 도구'가 아닌 '도메인 특화 도구'가 필수적임을 실증적으로 증명했습니다.