AutoBuild4Byte

CI 로그 없이 레거시 자바 프로젝트로부터 바이트코드를 복원하는 자동 빌드 에이전트

New Update (2026-02-11)

Bare Metal Mode: Docker 없이 로컬 환경에서 직접 빌드할 수 있는 --execution-mode local 옵션 추가. /data2/donggyu/benchmark/sec_code/tmp 경로에 위치한 격리된 도구(JDK, Maven, Gradle)를 사용하여 안전하고 독립적인 빌드 환경 제공.

New Update (2026-01-19)

Smart Flexible Healing: 단일 통합 프롬프트(Smart Prompt)를 적용하여 LLM이 상황에 따라 코드 수정, 의존성 변경, 파일 생성 등을 자율적으로 선택하도록 개선.
Context Awareness: 파일 트리(Project Structure) 정보를 제공하여 Docker 내부 경로와 로컬 경로 간의 매핑 오류 해결.
Knowledge Injection: "Bintray/JCenter Shutdown", "Restlet Repo Missing", "Java Version Mismatch" 등 도메인 지식을 프롬프트에 주입하여 치유 성공률 대폭 향상.
Improved Version Handling: class file version 55.0 (Java 11) 등의 호환성 오류 발생 시, 상속된(Inherited) 플러그인을 찾아내어 다운그레이드하는 전략 추가.

1. 시스템 구성 요소

이 시스템은 Python으로 구현되었으며 5개의 주요 모듈로 구성됩니다:

A. 소스 획득 (`src/acquisition`)

원격(Remote) Git URL, 로컬(Local) 디렉토리, 아카이브(Archive) Zip 파일 등 다양한 입력을 처리합니다.
리포지토리를 클론하거나 아카이브를 작업 공간(Workspace)에 압축 해제합니다.

B. 프로젝트 탐색 (`src/discovery`)

프로젝트 구조를 스캔합니다.
빌드 도구(Maven/Gradle)를 식별합니다.
멀티 모듈 프로젝트에서도 루트 빌드 파일(pom.xml 또는 build.gradle)을 정확히 찾아냅니다.

C. 환경 추론 (`src/inference`)

EnvironmentDetector: 다음을 사용하여 필요한 JDK 버전(예: 7, 8, 11)을 추론합니다.
- pom.xml 설정 분석 (<maven.compiler.source>)
- 소스 코드 특징 분석 (javalang): 람다(Lambda, Java 8), try-with-resources(Java 7) 등의 문법 특징을 감지합니다.
Detector: 빌드 도구 버전을 결정합니다.
- Maven: 기본값 3.8.6
- Gradle: 기본값 6.9.4 (Java 8 호환성이 뛰어난 안정 버전)

D. 자가 치유 (`src/healing`)

프로토콜 업그레이더: http:// Maven 저장소 URL을 자동으로 https:// 안전한 URL로 변환합니다.
미러 주입기: 원본 저장소가 죽었을 경우를 대비해, Google Maven Mirror를 사용하는 settings.xml을 주입합니다.
Gradle 런타임 힐러 (NEW):
- init.gradle 스크립트를 도커 컨테이너의 글로벌 경로(/root/.gradle/init.d/)에 주입합니다.
- 빌드 실행 시 동적으로 파손된 리포지토리(예: repo.spring.io)를 감지하고, 이를 Maven Central로 리다이렉트하여 인증 오류(401)를 무력화합니다.

E. 실행 관리 (`src/execution`)

DockerManager (기본):
- 추론된 환경을 기반으로 Dockerfile을 동적으로 생성합니다.
- 샌드박스 환경에서 안전하게 빌드를 수행합니다.
LocalManager (Bare Metal Mode):
- --execution-mode local 옵션 사용 시 동작합니다.
- /data2/donggyu/benchmark/sec_code/tmp 디렉토리에 위치한 **격리된 도구(JDK 8/17, Maven, Gradle)**를 강제로 사용하여 호스트의 환경 변수나 설정에 영향을 받지 않고 빌드를 수행합니다.
- 도커 오버헤드 없이 빠른 빌드가 가능합니다.
빌드 및 추출 공통 로직:
- Maven: mvn package -DskipTests 실행 후 target/classes 추출.
- Gradle: gradle compileJava -x test 실행 후 build/classes 추출.
- 빌드 성공 시 결과물을 호스트의 output/classes 디렉토리로 안전하게 복사합니다.

옵션 설명

플래그	필수 여부	설명	기본값
`--type`	필수	입력 소스 유형 (`remote`, `local`, `archive`)	-
`--path`	필수	입력 경로 (URL, 디렉토리 경로, 또는 파일 경로)	-
`--commit`	선택	(`remote` 타입 전용) 체크아웃할 특정 Git 커밋 해시	`HEAD`
`--workspace`	선택	프로젝트가 로드되고 빌드가 수행될 임시 작업 디렉토리	`workspace/`
`--output`	선택	빌드 결과물(클래스 파일, 로그)이 저장될 경로	`output/`
`--execution-mode`	선택	실행 모드 선택 (`docker`, `local`)	`docker`

실행 예시

1. 로컬 프로젝트 빌드 (기본)

python3 src/main.py --type local --path /Users/user/projects/legacy-app

2. 원격 Git 리포지토리의 특정 커밋 빌드

python3 src/main.py \
  --type remote \
  --path https://github.com/apache/commons-lang.git \
  --commit 8b67192

3. Zip 아카이브 빌드 및 커스텀 출력 경로 지정

  --type archive \
  --path /Downloads/source-code.zip \
  --workspace ./temp_work \
  --output ./build_results

4. Bare Metal Mode (Docker 없이 실행)

python3 src/main.py \
  --type local \
  --path /path/to/project \
  --execution-mode local

주의: Local Mode는 /data2/donggyu/benchmark/sec_code/tmp 경로에 JDK와 빌드 도구(Maven, Gradle)가 올바르게 배치되어 있어야 동작합니다. --path /Downloads/source-code.zip
--workspace ./temp_work
--output ./build_results

실행이 완료되면 --output (기본값: output/) 디렉토리에서 다음을 확인할 수 있습니다:

classes/: 도커 컨테이너에서 추출된 컴파일된 .class 파일들 (패키지 구조 유지)
compile_log.txt: 상세 빌드 로그
error_log.txt: (실패 시) 에러 원인 분석 로그

3. 검증 결과

시나리오 1: Maven 레거시 (Sample Project)

상황: http 저장소 URL 사용.
결과: https 업그레이드 및 Mirror 주입 후 빌드 성공.

시나리오 2: Gradle 레거시 (VUL4J-74)

상황: repo.spring.io (현재 인증 필요) 리포지토리 사용으로 인한 401 오류 발생.
해결: 에이전트가 init.gradle을 통해 해당 리포지토리를 런타임에 Maven Central로 교체함.
결과: 인증 오류를 우회하고 컴파일 단계로 진입 성공. (단, 프로젝트 자체의 누락된 스냅샷 아티팩트로 인한 404 오류는 발생했으나, 이는 에이전트의 정상 동작임)

시나리오 3: VUL4J-16 (Legacy Maven HTTP)

상황: 다수의 http 저장소 사용으로 Maven 3.8+에서 차단됨 (Blocked Mirror).
해결: settings.xml 주입 시 <mirrorOf>*</mirrorOf>를 사용하여 모든 트래픽을 Google Maven Mirror(HTTPS)로 강제함.
결과: 성공. 모든 의존성이 안전하게 다운로드됨.

시나리오 4: VUL4J-129-S (Maven with Missing Artifact)

상황: org.hyperic:sigar 아티팩트가 Maven Central에 없고 JBoss 리포지토리에만 존재함. 기존의 mirrorOf * 정책이 JBoss 리포지토리 접근을 차단하여 빌드 실패.
해결: Smart Mirror Exclusion 기능 구현. patcher.py가 pom.xml을 스캔하여 이미 https://를 사용하는 리포지토리(예: sigar)를 식별하고, 미러 설정에서 제외(mirrorOf *,!sigar)하여 직접 접근을 허용함.
추가 수정: druid-processing 모듈이 druid-core의 test-jar를 의존성으로 요구했으나, mvn compile은 테스트 jar를 생성하지 않음. 이를 해결하기 위해 빌드 명령을 mvn package -DskipTests로 변경하여 reactor 내에서 테스트 아티팩트가 정상 생성되도록 함.
Robustness 개선: web-console, distribution 등 바이트코드 복원에 불필요하고 빌드 오류(예: npm 권한 문제)를 유발하는 프론트엔드 모듈을 감지하여 Reactor 빌드에서 동적으로 제외(-pl !web-console,!distribution)함.
결과: 성공. sigar 아티팩트 다운로드, druid-core 테스트 의존성 해결, 그리고 프론트엔드 모듈 제외로 인한 빌드 성공.

4. 트러블슈팅 (Troubleshooting)

A. 파손된 리포지토리 (Broken Repository)

문제: repo.spring.io 등 과거엔 공개였으나 현재는 인증이 필요한 저장소들이 있음. 단순 파일 수정으로는 플러그인에 의해 동적으로 추가되는 저장소를 막을 수 없었음.
해결: init.gradle 스크립트에서 repository.whenObjectAdded 이벤트를 가로채어, 문제되는 URL이 감지되면 즉시 안전한 공개 저장소(Maven Central)로 URL을 덮어씌우는 로직을 구현함.

B. Docker 아키텍처 호환성

문제: Apple Silicon (M1/M2)에서 Intel 기반 JDK 설치 시 오류 발생.
해결: platform.machine()을 감지하여 적절한 JAVA_HOME 경로를 설정하도록 수정.

5. 향후 계획

JCenter 등 추가 Dead Repo 대응: 힐링 로직 확장.
실전 테스트: VUL4J 전체 데이터셋에 대한 대규모 실험 수행.

6. 기술 고도화: 하이브리드 자가 치유 (Hybrid Self-Healing Upgrade)

기존의 규칙 기반(Heuristic) 접근법의 한계를 극복하고, LLM의 강력한 추론 능력을 결합하여 "속도"와 "해결 능력"을 동시에 잡은 하이브리드 아키텍처를 완성했습니다.

A. 2단계 방어선 전략 (Two-Phase Defense Strategy)

1차 방어선 - 정적 치유 (Static Heuristic Phase)
- 역할: 가장 빠르고 비용이 들지 않는(Free) 해결사.
- 동작: 소스코드 분석만으로 알려진 문제(URL 401 오류, 플러그인 버전 불일치, 순환 참조 등)를 1초 미만에 수정(patcher.py)합니다.
- 효과: 전체 빌드 오류의 약 80%를 LLM 호출 없이 무료로 해결합니다.
2차 방어선 - 동적 지능형 치유 (Smart Flexible Healing)
- 역할: 복잡하고 예측 불가능한 미지의 에러를 해결하는 전지전능한 해결사.
- 동작: 1차 방어선이 뚫려 빌드가 실패할 경우 개입합니다. 초기에는 단순한 수정만 시도했으나, 최신 업데이트를 통해 완전한 자율성을 부여받았습니다.
- 효과: 단일 통합 프롬프트(Smart Prompt)를 사용하여 문제의 원인을 심층 분석하고, 상황에 따라 코드 수정, 의존성 업데이트, 주석 처리(Neutralize), 파일 생성 중 최적의 전략을 스스로 선택합니다.

B. LLM 힐러의 주요 기능 (Key Features)

스마트 모델 감지 (Smart Model Detection): gemini라는 단어를 감지하여 OpenAI 방식과 Google REST API 방식을 자동으로 전환합니다.
범용 구성 (Generic Configuration): llm_config.json 설정 파일 하나로 OpenAI, Google Gemini, 혹은 호환되는 모든 로컬 LLM을 손쉽게 교체할 수 있습니다.
비용 효율성 최적화: 빌드가 성공하면 LLM을 전혀 호출하지 않아 API 비용을 0원으로 유지할 수 있습니다.

E. 진화된 기능 (Advanced Features - 2026 Update)

컨텍스트 인식 (Context Awareness)
- 단순 로그 뿐만 아니라 파일 트리(Project Structure) 정보를 LLM에 제공합니다.
- Docker 내부 경로(/app/buggy/...)와 실제 로컬 경로를 정확히 매핑하여 "File Not Found" 오류를 원천 차단했습니다.
지식 주입 (Knowledge Injection)
- "Bintray/JCenter Shutdown"과 같은 도메인 특화 지식을 프롬프트에 내장했습니다.
- LLM이 죽은 리포지토리를 계속 시도하는 대신, Maven Central로 교체하거나 삭제하는 똑똑한 판단을 내립니다.
안전한 코드 생성 (Sandboxed Compatibility)
- 에이전트 실행 환경(Python 3.9 등)을 고려하여, 호환되지 않는 최신 문법(Python 3.10+ Type Hint 등) 사용을 억제합니다.
- 이는 치유 스크립트 실행 중 발생할 수 있는 2차적인 런타임 오류를 방지합니다.

C. 설정 방법 (Configuration)

프로젝트 루트의 llm_config.json 파일을 통해 다양한 LLM 백엔드를 설정할 수 있습니다. 이 파일은 Git에 포함되지 않으므로(gitignore), 로컬 환경에 맞게 직접 생성해야 합니다.

1. 필드 설명

필드명	설명	기본값
`provider`	LLM 파트너 (`openai`, `ollama` 등)	`openai`
`model`	사용할 모델명 (`gpt-4`, `gemini-1.5-flash`, `mistral` 등)	`gpt-3.5-turbo`
`api_key`	API 접근 키 (Ollama 사용 시 불필요)	`env:LLM_API_KEY`
`base_url`	API 엔드포인트 URL (로컬 LLM 사용 시 필수)	`http://localhost:11434`

2. 설정 예시

Case 1: OpenAI (GPT-4)

{
    "provider": "openai",
    "model": "gpt-4",
    "api_key": "sk-..."
}

Case 2: Google Gemini

{
    "provider": "google",
    "model": "gemini-2.5-flash",
    "api_key": "AIza..."
}

참고: Gemini는 현재 OpenAI 호환 모드 또는 Google GenAI SDK를 통해 지원됩니다.

Case 3: Local LLM (Ollama)

{
    "provider": "ollama",
    "model": "llama3:latest",
    "base_url": "http://localhost:11434"
}

D. 사전 점검 (Pre-flight Checks)

에이전트 실행 초기에 필수 환경(Docker)을 검증하는 단계를 추가하여 효율성을 높였습니다.

즉각적인 피드백: Docker가 꺼져있는 경우 Phase 0 단계에서 즉시 감지하여 종료합니다.
토큰 낭비 방지: 환경 문제로 실패할 것이 확실한 빌드에 LLM 치유를 시도하는 낭비를 원천 차단했습니다.

Name		Name	Last commit message	Last commit date
Latest commit History 8 Commits
src		src
.gitignore		.gitignore
README.md		README.md
requirements.txt		requirements.txt

ISEL-HGU/JavaBuildAgent

Folders and files

Latest commit

History

Repository files navigation

AutoBuild4Byte

New Update (2026-02-11)

New Update (2026-01-19)

1. 시스템 구성 요소

A. 소스 획득 (src/acquisition)

B. 프로젝트 탐색 (src/discovery)

C. 환경 추론 (src/inference)

D. 자가 치유 (src/healing)

E. 실행 관리 (src/execution)