android-reverse-engineering-skill 딥다이브
— APK를 읽는 순서까지 코드로 만드는 법

1프로젝트 한줄 요약

android-reverse-engineering-skill은 APK·XAPK·JAR·AAR를 분석하는 Claude Code용 스킬입니다. 이미 있는 분석 도구에 무엇을 맡기고, 그 결과에서 무엇을 읽어야 하는지까지 연결합니다. 디컴파일은 jadx나 Vineflower가 담당하고, 스킬은 분석 순서와 결과를 해석하는 기준을 제공합니다.

1-1. 입력과 출력부터 구분하기

이 구분은 중요합니다. find-api-calls.sh가 완성된 OpenAPI 명세를 생성하지는 않습니다. 대부분의 출력은 파일:줄:일치 내용 형식입니다. SKILL.md의 Phase 5는 이를 바탕으로 전체 엔드포인트 목록과 중요한 API의 상세 설명을 작성하라고 안내합니다.

1-2. 사용자가 만나는 두 입구

# README의 Claude Code 명령 예
/decompile path/to/owned-demo.apk

# 자연어로 분석 목표를 구체화하는 예
이 앱의 로그인 화면에서 네트워크 요청까지 호출 흐름을 설명해 줘.
각 결론에 근거 파일과 줄 번호를 붙여 줘.

위 예시의 대상은 직접 만든 앱이나 분석 권한이 있는 자료로 한정하면 됩니다. 이 글의 실습은 정적 읽기와 가짜 예제로 구성합니다. 실제 API에 접속하거나 인증 문자열을 사용해야 할 이유는 없습니다.

2왜 주목받는가

2026-10-23 GitHub 기준 스타는 8,268개, 포크는 936개이며, GitHub Trending의 Shell 일간 목록에서 4위로 선정됐습니다. 이 수치는 관심의 크기를 보여주지만, 특정 게시물이나 사건이 상승을 일으켰다는 인과관계까지 증명하지는 않습니다.

소스에서 확인할 수 있는 매력은 분명합니다. 디컴파일 명령 하나를 알려주는 데서 더 나아가, 처음 보는 앱을 분류하고, 난독화된 이름을 보완하고, HTTP 흔적을 모으는 작업을 하나의 학습 흐름으로 연결합니다. 명령어를 아는 것과 분석 순서를 아는 것 사이의 간격을 줄이는 프로젝트입니다.

2-1. 기존 도구와 무엇이 다른가

위 비교는 기능과 설계의 비교입니다. 처리 속도나 복원 정확도의 순위를 매긴 벤치마크는 아닙니다. jadx 자체도 모든 코드를 완전하게 디컴파일할 수 없다고 설명합니다. jadx 공식 저장소의 경고를 읽으면 결과 대조가 필요한 이유를 이해할 수 있습니다.

2-2. “일단 전부 디컴파일” 전에 갈림길을 둔다

fingerprint.sh는 libflutter.so, libhermes.so, assets/www/index.html 같은 흔적으로 앱의 종류를 추정합니다. Flutter나 React Native 앱에서는 Java 호스트 외부에 주요 로직이 있을 수 있으므로, 다른 분석 도구를 고려하라고 출력합니다.

다만 이것은 안내입니다. 스크립트가 Flutter 분석 도구를 설치하거나 Dart 코드를 해석하는 것은 아닙니다. SKILL.md는 해당 프레임워크라면 후속 Java/Kotlin 분석 단계를 멈추고 도구를 바꾸라고 지시합니다.

2-3. 현대 Kotlin 앱을 읽으려는 확장

Bash 검색기에는 Retrofit·OkHttp뿐 아니라 Ktor·Apollo·Koin·HMAC 관련 패턴이 들어 있습니다. recover-kotlin-names.sh는 코루틴 디버그 정보와 Kotlin 메타데이터에서 이름 후보를 추출합니다. 이 조합은 낯선 짧은 클래스 이름 속에서 의미 있는 탐색 지점을 찾도록 돕습니다.

3기술 스택 전체 지도

3-1. 백엔드에 해당하는 실행 계층

HTTP 서버·DB·사용자 계정 백엔드는 없습니다. 실행 계층은 외부 CLI를 호출하는 Bash와 PowerShell입니다. 스크립트의 공통 경로는 plugins/android-reverse-engineering/skills/android-reverse-engineering/scripts/입니다. 아래에서 파일 이름만 적은 스크립트는 이 디렉터리의 파일을 가리킵니다.

3-2. 프론트엔드에 해당하는 사용자 접점

React·Vue 같은 웹 UI는 없습니다. 사용자 접점은 Claude Code의 대화와 plugins/android-reverse-engineering/commands/decompile.md에 정의된 /decompile입니다. 이 Markdown 파일의 프런트매터에는 user-invocable: true와 입력 인자 설명이 들어 있습니다.

plugins/android-reverse-engineering/skills/android-reverse-engineering/SKILL.md는 단계별 행동과 참고 문서를 연결합니다. 코드가 화면을 렌더링하는 구조 대신, 에이전트가 지침을 읽고 로컬 도구와 파일 읽기를 조합하는 구조입니다.

3-3. 인프라·빌드와 실제 버전

이 커밋에는 package.json, Cargo.toml, pyproject.toml, go.mod, Dockerfile, 잠금 파일, .github/workflows/가 없습니다. 따라서 일반 앱처럼 패키지 매니저 의존성 목록이나 CI 빌드 파이프라인을 설명할 근거도 없습니다. 버전의 근거는 두 플러그인 JSON과 설치·검사 스크립트에서 찾아야 합니다.

버전을 적어 두는 것과 실행 환경을 재현 가능하게 고정하는 것은 서로 다른 일입니다. gh_latest_tag()가 호출 시점의 최신 버전을 선택하므로 같은 커밋의 스크립트도 날짜에 따라 다른 도구를 설치할 수 있습니다. 재현 실험에서는 엔진 버전과 입력 파일 해시도 함께 기록해야 합니다.

# plugin.json의 구성 일부
{
  "name": "android-reverse-engineering",
  "version": "1.5.0",
  "skills": "./skills/",
  "commands": "./commands/"
}

위의 ./skills/와 ./commands/는 매니페스트 안의 설정값입니다. 브라우저 링크가 아니라, 플러그인 루트에서 구성 요소를 찾기 위한 경로입니다.

3-4. 코드 규모를 숫자로 읽기

줄 수는 줄바꿈 문자 수 기준입니다. 전체에는 LICENSE와 .gitattributes도 포함합니다. 이 수치는 코드의 복잡도나 품질 점수가 아니라, 읽을 분량을 가늠하는 지도입니다.

4아키텍처 심화 분석

이 그림은 SKILL.md에 적힌 권장 작업 흐름입니다. 모든 단계를 한 번에 호출하는 단일 실행 파일이 있는 것은 아닙니다. 특히 plugins/android-reverse-engineering/commands/decompile.md의 실제 지침은 의존성 검사 → 디컴파일 → 초기 구조 요약을 중심으로 하며, Phase 0의 판별기를 직접 호출하라고 적지는 않습니다. 명령 하나가 전체 분석을 항상 끝낸다고 이해하면 범위를 과대평가하게 됩니다.

여기서 명령 파일의 저장소 루트 기준 경로는 plugins/android-reverse-engineering/commands/decompile.md입니다. 전체 흐름의 근거는 plugins/android-reverse-engineering/skills/android-reverse-engineering/SKILL.md입니다.

4-1. 설계 패턴 ① 단계별 분류와 조기 방향 전환

fingerprint.sh의 has()는 압축 파일의 목록과 DEX에서 추출한 클래스 문자열을 함께 봅니다. 파일 이름만 보면 드러나지 않는 Ktor·Koin 같은 라이브러리도 DEX 문자열에서 찾으려는 설계입니다. 프레임워크 판별은 if / elif 순서로 진행하며, 처음 맞는 조건이 결과를 결정합니다.

# fingerprint.sh의 실제 핵심 함수
has() { grep -qE "$1" "$LISTING" || grep -qE "$1" "$DEX_STRINGS"; }

# 실제 판별에 쓰는 흔적의 예
'^lib/[^/]+/libflutter\.so$'
'^assets/index\.android\.bundle$'
'^META-INF/.*\.kotlin_module$'

DEX에서 문자열을 뽑는 파이프라인은 unzip -p → strings -n 8 → grep → sed입니다. Lcom/example/Foo; 같은 타입 표기에서 맨 앞 L과 마지막 ;를 없애 com/example/Foo를 검색 자료로 남깁니다.

좋은 학습 지점은 결과와 근거를 함께 출력한다는 것입니다. FRAMEWORK와 RATIONALE를 따로 보관해 “무엇으로 분류했는가”와 “왜 그렇게 봤는가”를 구분합니다. 다만 여러 프레임워크가 함께 있으면 우선순위에 따라 한 종류만 대표로 표시됩니다.

4-2. 설계 패턴 ② 공통 호출 방식과 교체 가능한 엔진

decompile.sh의 decompile_single()은 ENGINE 값으로 분기해 run_jadx()와 run_fernflower()를 선택합니다. 객체지향 클래스 없이도 같은 목적의 작업을 함수 두 개로 분리한 전략 패턴의 형태를 읽을 수 있습니다.

# 두 엔진 모드의 결과 배치 예시
owned-demo-decompiled/
├── jadx/
│   ├── sources/
│   └── resources/
└── fernflower/
    └── sources/

후속 검색기는 엔진 이름보다 sources/라는 경로를 기준으로 동작할 수 있습니다. 서로 다른 도구의 출력 차이를 래퍼가 흡수하는 셈입니다. 다만 두 결과가 자동 병합되거나, 더 정확한 클래스가 자동 선택되지는 않습니다. 파일 수와 jadx 경고가 있는 파일 수를 비교해 보여줍니다.

엔진 함수가 입력 파일을 인자로 모두 받지는 않는다는 점도 볼 만합니다. decompile_single()은 전역 INPUT_FILE_ABS와 ext_lower를 잠시 바꾸고, 정상·부분 성공 경로에서 복원합니다. 실패로 조기 반환하면 복원문에 도달하지 않습니다. 간단한 직렬 실행에는 쓸 수 있지만, 병렬 실행이나 독립 테스트로 확장하려면 상태를 명시적 인자로 옮기는 편이 읽기 쉽습니다.

4-3. 설계 패턴 ③ 결과물을 확인하는 부분 성공 처리

외부 명령이 실패했는지만 보지 않고, 읽을 만한 결과물을 남겼는지도 확인합니다. run_jadx()는 종료 코드를 저장한 뒤 sources/의 Java 파일 수를 셉니다. 원래 명령의 종료 코드와 래퍼 함수가 반환하는 의미를 분리한 것입니다.

# run_jadx()의 실제 반환 분기
if [[ $jadx_status -eq 0 ]]; then
  return 0
fi

if [[ $count -gt 0 ]]; then
  echo "Warning: jadx exited with status $jadx_status after writing $count Java files; treating this as partial success." >&2
  return 2
fi

# 결과 소스도 없다면 실패
return 1

이 값은 엔진 함수 내부의 계약입니다. decompile_single()이 부분 성공을 받아 계속하므로, 최종 셸 프로세스가 반드시 2로 끝나는 것은 아닙니다. 또 install-dep.sh의 종료 코드 2는 “수동 설치 조치 필요”라는 다른 의미입니다.

both 모드에서도 jadx가 1을 반환하면 Vineflower 실행 전에 중단합니다. 따라서 두 엔진 실행은 “첫 엔진이 완전히 실패해도 두 번째로 복구하는 경로”까지 구현한 것은 아닙니다. 정상 종료 역시 코드 정확도를 증명하지는 않습니다. 이 로직은 처리 지속 여부를 정하는 장치입니다.

4-4. 설계 패턴 ④ 증거를 파일로 남기고 조회를 분리

recover-kotlin-names.sh 안의 Python은 Java 파일을 걸으며 다음 순서로 이름 후보를 고릅니다. @DebugMetadata.c → @Metadata.d2의 첫 적합한 타입 → jadx의 renamed from 주석입니다. 각 파일에서 하나의 후보를 정해 매핑을 만듭니다.

# 내장 Python의 실제 정규식과 후보 정리 일부
RE_DEBUG = re.compile(r'@DebugMetadata\([^)]*?c\s*=\s*"([^"]+)"', re.S)
RE_LCLASS = re.compile(r'L([A-Za-z][\w/$]+);')

# 코루틴 내부 클래스의 접미사를 제거
real = m.group(1).split("$", 1)[0]

# 결과를 조회용 사전으로 보관
mapping[obf] = real

결과는 mapping.json, 근거 파일 경로를 담은 mapping.tsv, 패키지별 목록 by_package/입니다. 원본 Java 파일 이름을 직접 바꾸지는 않습니다. “원래 코드를 보존한 상태에서 이름 해석을 덧붙이는 방식”을 배울 수 있습니다.

lookup-name.sh의 search()는 복원 이름의 부분 문자열을 찾고, by_obf()는 난독화된 이름 하나를 풀어 봅니다. grep_annot()는 subprocess.run()으로 grep을 실행하고, 매핑이 있는 파일의 일치 줄에만 이름 후보를 덧붙입니다.

5디렉토리 구조 해부

5-1. 같은 이름의 설정 폴더가 두 번 등장하는 이유

루트의 .claude-plugin/marketplace.json은 설치 가능한 플러그인 목록을 설명합니다. 그 안의 source 값은 ./plugins/android-reverse-engineering입니다. 실제 플러그인 내부의 .claude-plugin/plugin.json은 해당 플러그인 한 개의 구성을 설명합니다.

앞쪽은 매장 진열표, 뒤쪽은 개별 제품의 설명서로 생각하면 됩니다. 버전 정보가 두 곳에 있으므로 배포할 때 서로 일치하는지 확인해야 합니다. 이 커밋에서는 둘 다 1.5.0입니다.

5-2. 참고 문서도 실행 설계의 일부다

참고 파일들은 plugins/android-reverse-engineering/skills/android-reverse-engineering/references/에 있습니다. SKILL.md가 단계별로 해당 파일을 가리키므로, 필요할 때 세부 지식을 찾아 읽는 구조입니다. 모든 설명을 하나의 거대한 지침에 넣지 않는 문서 구성도 학습 대상입니다.

5-3. 처음 읽을 때의 권장 순서

1. plugin.json으로 무엇이 연결되는지 확인합니다.
2. SKILL.md와 명령 파일을 비교해 전체 절차와 명령의 범위를 구분합니다.
3. decompile.sh의 run_jadx()부터 외부 명령 호출을 읽습니다.
4. find-api-calls.sh에서 입력·검색 조건·출력 형식을 따라갑니다.
5. 이름 복원기와 조회기를 읽으며 JSON 매핑이 어떻게 활용되는지 확인합니다.

처음부터 모든 설치 분기를 외울 필요는 없습니다. 입력 하나가 어느 함수와 파일을 거쳐 어떤 결과를 남기는지 먼저 그리면, 나머지 옵션이 붙는 위치도 자연스럽게 보입니다.

6학습 포인트 (기술별)

6-1. Bash: 인자는 배열로 만들고 실패는 구분한다

run_jadx()는 옵션을 긴 문자열 하나로 조립하지 않고 args 배열에 넣습니다. 마지막에 jadx "${args[@]}"로 전달하므로 공백이 있는 파일 경로도 하나의 인자로 유지할 수 있습니다. 반면 echo "Running: ..."는 사람에게 보여주는 로그이지, 다시 평가할 명령문은 아닙니다.

# decompile.sh에서 발췌한 인자 구성
local args=()
args+=("-d" "$out_dir")
[[ "$DEOBF" == true ]] && args+=("--deobf")
[[ "$NO_RES" == true ]] && args+=("--no-res")
args+=("--show-bad-code")
args+=("$INPUT_FILE_ABS")

set -euo pipefail은 오류를 드러내는 기본 장치입니다. 그러나 grep은 일치가 없어도 종료 코드 1을 돌려주므로, 예상된 빈 결과에는 || true를 붙이는 코드가 나옵니다. 다만 이 처리로 grep의 다른 오류도 숨겨질 수 있으므로, 빈 결과만으로 “일치 없음”과 “처리 실패”를 구분할 수는 없습니다.

실습 아이디어: 종이에 owned demo.apk라는 경로가 들어갈 때의 배열 요소를 적어 보세요. 파일 경로 한 개가 인자 몇 개로 전달되는지 설명할 수 있으면 인용부호의 역할을 이해한 것입니다.

6-2. 정규식: 검색 결과는 후보 집합이다

find-api-calls.sh의 run_grep()는 Java와 Kotlin 파일을 재귀 검색합니다. Retrofit은 @GET 같은 애너테이션을, OkHttp는 Request.Builder 같은 호출 흔적을 찾습니다. 컴파일러의 문법 트리를 분석하는 방식은 아니므로, 주석·샘플 코드·사용하지 않는 문자열도 잡힐 수 있습니다.

--paths는 난독화로 호출 형태가 바뀌어도 문자열 경로는 남을 수 있다는 점을 이용합니다. SEG와 ROOT로 패턴을 만들고 MIME 형식과 일부 시스템 경로를 제외합니다. 결과가 어떻게 달라지는지 가짜 문자열로 생각해 볼 수 있습니다.

검색 결과가 있다는 사실과 실제로 호출되는 API라는 결론 사이에는 코드 검토가 필요합니다. 경로 문자열을 찾았다면 호스트 설정·HTTP 메서드·호출자·인증 헤더를 따로 확인해야 합니다. 경로만으로 GET인지 POST인지 채워 넣으면 문서가 잘못됩니다.

6-3. URL 분류: 중복 제거와 출현 빈도는 다르다

--urls는 엄격한 URL 패턴과 awk 필터를 거쳐 문자열 잡음을 줄입니다. 이어 third_party_hosts.txt의 정규식에 맞는 호스트를 외부 서비스 후보로 묶습니다. “자사 후보”라는 표시가 호스트 소유권을 증명하는 것은 아닙니다.

특히 출력 제목의 frequency-sorted를 해석할 때 주의해야 합니다. URL 추출 직후 sort -u를 하므로 뒤에서 세는 숫자는 대체로 그 호스트의 서로 다른 URL 문자열 수입니다. 같은 URL이 소스 100곳에 나온다고 해서 100으로 세지 않습니다.

전체 검색의 요약부는 한 번의 grep 결과를 여러 분류로 셉니다. 하지만 상세 항목에서는 다시 검색합니다. “단일 순회”는 요약 집계에 해당하며, 도구 전체가 파일을 단 한 번만 읽는다는 뜻은 아닙니다.

실습 아이디어: 가짜 URL 3개 중 2개를 같게 적고, 중복 제거 전후에 호스트별 수가 어떻게 달라지는지 표로 비교하세요. 실제 요청 횟수와 정적 문자열 수가 다른 지표라는 것도 함께 설명해 보세요.

6-4. Python: 사전과 역색인으로 코드 읽기 보조하기

복원기는 mapping[난독화 이름] = 이름 후보를 저장합니다. 조회기는 같은 후보로 연결되는 파일이 여럿일 수 있어서 REV.setdefault(r, []).append(o)로 역방향 목록을 만듭니다. 사전 하나와 리스트만으로 다대일 관계를 탐색하는 작은 예제입니다.

# 구조를 설명하기 위한 가짜 매핑
{
  "a.b.c": "com.example.account.AccountRepository",
  "a.b.d": "com.example.account.AccountRepository"
}

# 역방향으로 보면 같은 원래 클래스의 후보 파일을 함께 찾을 수 있음
com.example.account.AccountRepository
    a.b.c
    a.b.d

코드를 더 자세히 보면 개선점도 보입니다. TSV에는 파일 경로가 있지만 JSON에는 이름 쌍만 있습니다. 후보를 얻은 방식은 전체 건수로만 집계합니다. 신뢰도를 더 잘 보여주려면 매핑마다 debug_meta·d2·renamed 같은 근거 유형을 함께 보관할 수 있습니다.

6-5. Kotlin 메타데이터: 원리와 복원 보장은 구분한다

README와 참고 문서는 Kotlin 메타데이터를 제거할 수 없다는 강한 표현과 높은 복원율을 제시합니다. 그러나 이 커밋에는 그 수치를 검증하는 샘플 데이터나 평가 코드가 없습니다. 스크립트 자체도 d2 배열에서 첫 적합한 타입을 고를 뿐, 그 타입이 반드시 파일의 선언 클래스인지 검증하지 않습니다.

Kotlin 공식 문서는 메타데이터가 클래스·함수·프로퍼티 같은 정보를 담고, 전용 라이브러리로 읽을 수 있다고 설명합니다. 반면 ProGuard 공식 문서는 일반 앱에서 메타데이터를 제거할 수 있으며, 리플렉션이나 라이브러리 용도에 따라 보존이 필요하다고 설명합니다. 보존된 메타데이터의 이름도 난독화된 클래스 이름에 맞춰 바뀔 수 있으므로, “원래 이름은 항상 남는다”고 일반화하면 안 됩니다. 근거: Kotlin 메타데이터 문서, ProGuard Kotlin 안내.

이 스크립트가 복원하는 대상은 클래스 이름 후보입니다. 메서드·필드 이름 복원은 구현하지 않습니다. 이는 스크립트의 범위에 대한 설명이며, Kotlin 메타데이터 전체가 클래스 이름만 담는다는 뜻은 아닙니다.

6-6. 이식성: 같은 이름의 파일도 동작은 다를 수 있다

이 차이들은 실행 결과를 측정한 결론이 아니라 코드 경로에서 확인한 조건과 점검할 위험입니다. 특히 README가 권하는 AAR·Fernflower 조합은 입력 구조와 외부 도구 버전에 따른 검증이 필요합니다. README도 Windows 지원을 실험적이라고 표시합니다.

7하드웨어 / 시스템 요구사항

README 기준 필수 도구는 Java JDK 17 이상과 jadx입니다. 검사 코드는 java 버전과 jadx 존재를 확인하며, javac 등 JDK 구성 요소는 검사하지 않습니다. CPU 코어 수·RAM 최소량·디스크 최소량은 저장소에 정해져 있지 않습니다. 아래의 하드웨어 수치는 보장 사양이 아닌, 작은 학습용 자료를 다룰 때의 시작 권장입니다.

7-1. 운영체제 이름보다 실제 유틸리티 옵션을 확인한다

install-dep.sh는 macOS와 Linux를 나누고 brew·apt·dnf·pacman을 찾습니다. 그러나 설치 분기가 있다는 사실만으로 모든 분석 명령이 해당 OS 기본 도구에서 호환된다고 보장되지는 않습니다.

예를 들어 print_structure()는 find -printf를, XAPK 목록은 sort -z를 사용합니다. macOS 기본 BSD 유틸리티와 차이가 있을 수 있습니다. declare -A와 ${INPUT,,}도 오래된 Bash에서 사용할 수 없습니다.

7-2. 시간 제한은 조건부로 적용된다

run_fernflower()의 전체 제한은 FERNFLOWER_TIMEOUT_SECONDS이며 기본값은 900초입니다. 다만 timeout 명령이 존재하고 설정값이 양의 정수일 때만 적용됩니다. 그 외에는 일반 java -jar 실행으로 진행합니다.

별도로 넘기는 -mpm=60은 메서드 단위 제한 옵션입니다. 전체 프로세스 제한과 구분해야 합니다. 큰 앱에 두 엔진을 사용하면 출력 공간과 처리 시간이 모두 늘어납니다.

7-3. 네트워크와 데이터의 경계

PRIVACY.md는 작성자가 운영하는 서버나 원격 측정 기능이 없다고 설명합니다. 설치기는 GitHub나 패키지 저장소에 접속하지만, API 검색기는 전달받은 디컴파일 소스를 읽을 뿐 찾은 URL에 요청을 보내지 않습니다.

로컬 도구가 파일을 처리한다는 사실과 AI가 읽은 내용의 처리 범위는 따로 확인해야 합니다. 같은 정책 문서는 Claude가 읽는 소스는 Anthropic의 약관과 정책에 따라 처리된다고 밝힙니다. 민감한 앱 자료를 다룰 때는 이 경계를 이해하고 분석 범위를 정해야 합니다.

8직접 해볼 수 있는 실습 과제

다음 다섯 과제는 저장소 스크립트나 설치기를 실행하지 않아도 수행할 수 있습니다. 코드 읽기와 가짜 자료만으로 설계의 장단점을 확인합니다. 파일 경로는 저장소 루트를 기준으로 하며, 과제는 검색·읽기와 설계안 작성으로 구성합니다.

// 실제 앱에서 추출한 코드가 아닌 학습용 예제
interface DemoApi {
    @GET("v1/profile")
    Call<Profile> profile(@Header("Authorization") String token);
}

// 클라이언트 설정의 가상 예제
new Retrofit.Builder()
    .baseUrl("https://api.example.test/");

// a/b/c.java에 남았다고 가정하는 가짜 메타데이터
@DebugMetadata(c = "com.example.LoginRepository$load$1")

// 다른 파일에 남았다고 가정하는 가짜 타입 목록
@Metadata(d2 = {"Lcom/example/Logger;", "Lcom/example/Profile;"})

실습의 목표는 도구를 한 번 성공시키는 데서 끝나지 않고, 결과를 믿을 조건을 설명하는 것입니다. 입력·도구·출력·검증 기준을 한 장에 적으면 다른 프로젝트의 자동화도 같은 방식으로 읽을 수 있습니다.

9관련 기술 심화 학습 로드맵

주당 3~5시간을 가정한 학습안입니다. 처음에는 실제 대형 앱보다 작은 가짜 코드 조각을 사용하세요. 각 주의 산출물을 다음 주의 입력으로 삼으면 문법 공부가 구체적인 분석 능력으로 이어집니다.

9-1. 각 주를 마칠 때 스스로 물어볼 것

• 1~2주: 파일 이름에 공백이 있거나 외부 명령이 비정상 종료하면 어떤 일이 생기는가?
• 3~4주: 후보를 정답으로 오해하지 않도록 어떤 근거 필드를 남길 것인가?
• 5~6주: 호출자와 실제 URL을 확인하려면 어떤 코드가 더 필요하고, 실험을 어떻게 재현할 것인가?

기술 이름을 많이 외우는 것보다 한 입력이 어떤 근거를 거쳐 결론이 되는지 설명하는 능력이 먼저입니다. 더 깊이 가고 싶다면 정규식 검색을 문법 트리 분석으로 확장하거나, Kotlin 전용 메타데이터 파서와 현재의 문자열 추출 결과를 비교하는 프로젝트로 이어갈 수 있습니다.

10핵심 키워드 사전

R8는 이름 변경 외에도 코드 제거·인라이닝·클래스 병합을 수행합니다. 그래서 디컴파일 결과의 클래스 경계가 원래 소스 구조와 같다고 기대하면 안 됩니다. 관련 배경은 Android 공식 R8 설명에서 확인할 수 있습니다.

11참고 링크

11-1. 저장소와 핵심 소스

• 공식 저장소 — 개요·설치 안내·기여 현황
• v1.1.0 릴리스 — GitHub 릴리스 기록
• 분석 기준 커밋 0c7cf89 — 이 글의 소스 기준점
• 전체 분석 단계: SKILL.md — Phase 0~5와 출력 기준
• 엔진 선택과 부분 성공: decompile.sh — 함수별 실행 계약
• 검색 패턴과 URL 분류: find-api-calls.sh — 후보 추출의 실제 규칙
• Kotlin 이름 후보 추출: recover-kotlin-names.sh — 내장 Python과 매핑 저장
• 개인정보 처리 설명 · 외부 소프트웨어 고지 — 로컬 처리와 도구별 조건

11-2. 관련 기술의 공식 자료

• jadx 공식 저장소 — 디컴파일 기능·옵션·문제 해결
• Vineflower 공식 저장소 — JVM 디컴파일 엔진
• 유지보수되는 dex2jar 저장소 — DEX와 JAR 사이의 변환
• Apktool 공식 사이트 — Android 리소스 분석
• Kotlin 메타데이터 공식 문서 — 정규식 추출 다음에 배울 구조적 파싱
• ProGuard의 Kotlin 안내 — 메타데이터 보존과 제거 조건
• Android R8 최적화 안내 — 이름 변경·인라이닝·코드 제거
• Claude Code 플러그인 매니페스트 문서 — 구성 파일과 경로 규칙

현재 상태 (2026-10-23 GitHub 기준)