# 디컴파일 프로젝트에 처음 기여하는 방법

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

관심 있는 대상과 검증 가능한 과제 하나부터 시작하세요. 첫 기여가 어려운 매칭 함수일 필요는 없습니다. 빌드 재현, 설치 설명 수정, 정확한 테스트 보고서도 다음 참여자의 수고를 줄입니다.

[프로젝트를 찾은 뒤](/ko/guides/finding-decompilation-projects) 도구, 브랜치, 기여 규칙은 그 프로젝트의 문서를 따르세요. DecompHub는 일을 배정하거나 관리자를 대신하지 않습니다.

## 환경 확인하기

[도움 주기](https://app.decomphub.com/ko/help)에서 macOS, Windows, Linux 등 가능한 환경을 지정할 수 있습니다. 비공개 매칭 설정이며 빌드 성공을 보장하지는 않습니다.

정확한 OS, 컴파일러, 대상 리비전을 확인하세요. [Super Mario 64](https://github.com/n64decomp/sm64)는 Linux, macOS, 컨테이너 절차와 버전별 입력을 구분합니다. 다른 포크용 절차로는 엉뚱한 대상에 맞춘 빌드가 만들어질 수 있습니다.

작업할 커밋과 도구 버전을 기록하세요. 원본 게임 데이터나 특정 기기가 필요한지도 미리 확인합니다. 목록 서비스는 원본 프로그램이나 에셋을 제공하지 않습니다.

## 기여 규칙 읽기

`CONTRIBUTING`, 저장소 문서, 검토 절차를 찾으세요. [GitHub 문서](https://docs.github.com/en/communities/setting-up-your-project-for-healthy-contributions/setting-guidelines-for-repository-contributors)는 이런 가이드라인이 표시되는 위치를 설명합니다.

사전 issue, 특정 브랜치, 서식, 검증 명령, AI 생성 작업에 관한 규정이 있는지 확인합니다. 다른 프로젝트의 규칙을 그대로 적용하지 마세요.

좋은 첫 과제에는 빌드 성공, 함수 하나의 일치, 잘못된 설명 하나의 수정, 재현 가능한 실패처럼 명확한 완료 조건이 있습니다.

## 기준 상태 남기기

수정 전에 공식 절차로 검증하고 명령, 대상, 도구 버전, 결과를 저장하세요. 이미 실패한다면 그 문제를 나중의 변경과 구분해야 합니다.

보고서에는 기대 결과, 실제 결과, 최소 재현 절차를 적습니다. 관련 로그만 첨부하고 단순히 “작동하지 않는다”로 끝내지 마세요.

## 근거를 보여줄 수 있는 기여

- **문서:** 직접 확인한 단계, 모호한 요구 사항, 공식 안내 링크를 수정합니다.
- **테스트:** 보유한 장비나 OS에서 공개 절차를 수행하고 버전과 결과를 기록합니다.
- **매칭 코드:** 이해할 수 있는 작은 함수부터 시작합니다. [decomp.me](https://www.decomp.me/faq)의 실험 결과도 프로젝트 자체 검증을 거쳐야 합니다.
- **도구:** 반복 작업이나 오류 메시지를 개선하되 기대 동작과 검증을 유지합니다.

[objdiff](https://github.com/encounter/objdiff)는 로컬 비교 절차를 설명합니다. 익숙하다는 이유로 다른 스택을 추가하기보다 저장소가 지정한 도구를 사용하세요.

## 작은 변경 제출하기

문제, 바뀐 동작, 확인 방법을 설명하세요. 매칭은 대상과 비교를, 문서는 실제로 따라 한 절차를 적습니다. 시험하지 못한 부분도 명시합니다.

관련 없는 파일 정리를 함께 넣지 마세요. 조용하거나 보관된 저장소라면 공식 후속 프로젝트가 있는지 확인합니다. 빠진 저장소는 [제출](https://app.decomphub.com/ko/submit)할 수 있습니다. 수치는 [진행률 가이드](/ko/guides/understanding-decompilation-progress)에서 해석하는 법을 배울 수 있습니다.