# 디컴파일 진행률 보고서 읽는 법

Author: DecompHub
Updated: 2026-10-10
Language: ko
Canonical: https://decomphub.com/ko/guides/understanding-decompilation-progress

진행률은 무엇을, 어떤 빌드에서, 언제 측정했는지 알아야 의미가 있습니다. DecompHub는 지표 이름, 범위, 출처를 함께 보존합니다. 신뢰할 만한 측정값을 얻지 못했다면 알 수 없음으로 표시합니다. 이는 0%와 다릅니다.

## 코드 일치와 정상 동작은 다른 목표

매칭 디컴파일은 특정 원본 빌드와 같은 기계어를 만드는 소스를 목표로 합니다. 컴파일러와 설정도 중요합니다. [decomp.me FAQ](https://www.decomp.me/faq)는 함수 단위 scratch 비교를 설명합니다. 한 scratch의 결과가 게임 전체의 진행률은 아닙니다.

호환 구현은 동작 재현을 목표로 합니다. [ScummVM은 게임 실행 파일을 대체하고 원본 게임 데이터를 사용합니다](https://docs.scummvm.org/en/latest/help/faq.html). 게임 지원 여부를 바이너리 일치율로 바꿔 읽으면 안 됩니다. 이식, 재구현, 하드웨어 연구도 매칭 보고서 없이 가치가 있습니다.

## 분모 확인하기

함수, 바이트, 파일, 심볼, 식별된 에셋은 서로 다른 단위입니다. **가상의 예시**에서 1,000개 함수 중 900개가 일치하면 함수 수 기준 90%입니다. 하지만 나머지 함수가 코드 바이트의 절반이라면 바이트 기준으로 90%가 아닙니다. 실제 프로젝트의 측정값이 아니라 계산을 설명하는 예입니다.

다음을 확인하세요.

- 지표가 일치 코드, 디컴파일된 코드, 식별된 에셋 중 무엇인지.
- 퍼센트인지 개수인지, 개수라면 출처에 전체 수가 있는지.
- 전체 실행 파일, 라이브러리, 지역판, 플랫폼, 일부 파일 중 어디까지 측정했는지.
- 측정값을 제공한 원본 보고서를 열 수 있는지.

[objdiff](https://github.com/encounter/objdiff)는 오브젝트 파일 비교와 진행 정보 생성에 사용됩니다. 도구를 쓴다는 사실만으로 해당 저장소의 설정이나 분모가 정해지는 것은 아닙니다.

## 버전과 지표를 섞지 않기

한 지역판이나 디버그 빌드가 끝났다고 다른 버전도 끝난 것은 아닙니다. [Ocarina of Time](https://github.com/zeldaret/oot)은 지원 버전과 빌드 대상 선택을 설명합니다.

코드 일치와 에셋 식별도 별개의 작업입니다. 코드가 일치해도 모든 텍스처, 소리, 데이터 구조가 이해된 것은 아닙니다. 게시자가 통합 지표를 정의하지 않았다면 임의로 평균을 내지 마세요.

## 날짜 구분하기

**보고 날짜**는 게시자가 측정에 대해 제공한 날짜입니다. **관찰 날짜**는 DecompHub가 출처를 읽은 때입니다. 방금 수집한 페이지에 오래된 결과가 있을 수 있습니다. 저장소 메타데이터나 목록 수정 날짜도 측정이 새롭다는 증거가 아닙니다.

[데이터 문서(영어)](/data)는 출력 필드를 설명합니다. 인용할 때 프로젝트, 지표, 범위, 출처 URL, 해당 날짜를 함께 남기세요.

알 수 없음은 보고서 부재, 접근 실패, 불명확한 범위, 아직 수집되지 않은 출처 등에서 생깁니다. 100% 초과, 바뀐 분모, 충돌하는 배지는 확인이 필요합니다. 값을 몰래 잘라내거나 알 수 없음을 0이나 스타 수로 대체하지 마세요.

[측정값이 있는 프로젝트](https://app.decomphub.com/ko/explore?progress=in-progress)의 출처를 열어 비교하세요. 오류가 있다면 목록의 신고 기능으로 수정 근거가 되는 자료를 알려줄 수 있습니다.