{"meta":{"title":"사용자 지정 작업 관리","intro":"고유한 작업을 만들고 관리하고 커뮤니티에서 공유하는 작업을 사용자 지정하는 GitHub 방법을 알아봅니다.","product":"GitHub Actions","breadcrumbs":[{"href":"/ko/actions","title":"GitHub Actions"},{"href":"/ko/actions/how-tos","title":"사용법"},{"href":"/ko/actions/how-tos/create-and-publish-actions","title":"작업 만들기 및 게시"},{"href":"/ko/actions/how-tos/create-and-publish-actions/manage-custom-actions","title":"사용자 지정 작업 관리"}],"documentType":"article"},"body":"# 사용자 지정 작업 관리\n\n고유한 작업을 만들고 관리하고 커뮤니티에서 공유하는 작업을 사용자 지정하는 GitHub 방법을 알아봅니다.\n\n## 작업 위치 선택\n\n다른 사람이 사용할 작업을 개발하는 경우 작업을 다른 애플리케이션 코드와 함께 묶는 대신 자체 리포지토리에 유지하는 것이 좋습니다. 이를 통해 다른 소프트웨어처럼 작업을 버전 관리하고, 추적하고, 릴리스할 수 있습니다.\n\n작업을 자체 리포지토리에 저장하면 커뮤니티에서 작업을 보다 GitHub 쉽게 검색할 수 있고, 개발자가 문제를 수정하고 작업을 확장할 수 있는 코드 베이스의 범위를 좁히고, 작업의 버전 관리가 다른 애플리케이션 코드의 버전 관리와 분리됩니다.\n\n다른  사용자가 사용할 수 없도록 하려는 작업을 빌드하는 경우 리포지토리의 모든 위치에 작업의 파일을 저장할 수 있습니다. 단일 리포지토리에서 작업, 워크플로, 애플리케이션 코드를 결합하려는 경우 작업을 `.github` 디렉터리에 저장하는 것이 좋습니다. 예를 들어 `.github/actions/action-a` 및 `.github/actions/action-b`를 지정합니다.\n\n## 다른 플랫폼과의 호환성 보장\n\n많은 사람들이 에 대한 사용자 지정 도메인과 같은 GitHub 도메인 이외의 GitHub.com도메인에 액세스 GHE.com 합니다GitHub Enterprise Server.\n\n작업이 다른 플랫폼과 호환되도록 하려면 `https://api.github.com`과(와) 같은 API URL에 대한 하드 코딩된 참조를 사용하지 마세요. 대신 다음을 수행할 수 있습니다:\n\n* 환경 변수를 사용합니다([변수 참조](/ko/actions/reference/workflows-and-actions/variables#default-environment-variables) 참조):\n\n  * REST API의 경우 `GITHUB_API_URL` 환경 변수를 사용합니다.\n  * GraphQL의 경우 `GITHUB_GRAPHQL_URL` 환경 변수를 사용합니다.\n\n* [\n  `@actions/github`\n  ](https://github.com/actions/toolkit/tree/main/packages/github)와 같은 도구 키트를 사용하여 올바른 URL을 자동으로 설정할 수 있습니다.\n\n## 작업에 릴리스 관리 사용\n\n다른 사람이 사용할 작업을 개발하는 경우 릴리스 관리를 사용하여 업데이트를 배포하는 방법을 제어하는 것이 좋습니다. 사용자는 작업의 패치 버전에 필요한 중요 수정 사항 및 보안 패치가 포함되어 있으면서도 기존 워크플로와 계속 호환될 것으로 기대할 수 있습니다. 변경 내용이 호환성에 영향을 미칠 때마다 새 주 버전을 릴리스하는 것이 좋습니다.\n\n이 릴리스 관리 접근 방식에서는 사용자가 작업의 기본 분기를 참조해서는 안 됩니다. 최신 코드를 포함할 가능성이 크고 결과적으로 불안정할 수 있기 때문입니다. 대신, 사용자가 작업을 사용할 때 주 버전을 지정하고 문제가 발생하는 경우에만 더 구체적인 버전으로 안내하도록 하는 것이 좋습니다.\n\n특정 작업 버전을 사용하기 위해 사용자는 태그, 커밋의 SHA 또는 릴리스의 이름을 지정하는 분기를 대상으로 하는 워크플로를 구성할 GitHub Actions 수 있습니다.\n\n### 릴리스 관리에 태그 사용\n\n> \\[!NOTE] 공급망 공격 및 릴리스의 실수로 인한 변경을 방지하기 위해 변경 불가능한 릴리스를 사용하도록 설정한 경우에는 대신 [변경이 불가능한 릴리스 및 태그를 사용하여 작업 릴리스 관리](/ko/actions/how-tos/create-and-publish-actions/using-immutable-releases-and-tags-to-manage-your-actions-releases)을(를) 참조하세요.\n\n작업 릴리스 관리에 태그를 사용하는 것이 좋습니다. 이 방법을 사용하면 사용자가 주 버전과 부 버전을 쉽게 구분할 수 있습니다.\n\n1. 릴리스 분기에서 릴리스를 개발 및 검증합니다(예: `release/v1`).\n2. 의미 체계 버전 관리를 사용하여 릴리스 태그가 포함된 릴리스를 만드세요(예: `v1.0.1`). 자세한 내용은 [리포지토리에서 릴리스 관리](/ko/repositories/releasing-projects-on-github/managing-releases-in-a-repository)을(를) 참조하세요.\n3. 주 버전 태그(예: `v1`)를 현재 릴리스의 Git 참조를 가리키도록 이동시키세요. 자세한 내용은 [Git 기본 사항 - 태그 지정](https://git-scm.com/book/en/v2/Git-Basics-Tagging)을 참조하세요.\n4. 작업 입력 변경처럼 기존 워크플로를 중단시킬 변경 사항의 경우, `v2`과(와) 같은 새 주 버전 태그를 도입합니다.\n\n#### 태그 참조 구문\n\n이 예제는 사용자가 주 버전 태그를 참조하는 방법을 보여 줍니다:\n\n```yaml\nsteps:\n    - uses: actions/javascript-action@v1\n```\n\n이 예제에서는 사용자가 특정 패치 릴리스 태그를 참조하는 방법을 보여 줍니다.\n\n```yaml\nsteps:\n    - uses: actions/javascript-action@v1.0.1\n```\n\n### 릴리스 관리에 분기 사용\n\n릴리스 관리에 분기 이름을 사용하려는 경우 이 예제에서는 명명된 분기를 참조하는 방법을 보여 줍니다.\n\n```yaml\nsteps:\n    - uses: actions/javascript-action@v1-beta\n```\n\n### 릴리스 관리에 커밋의 SHA 사용\n\n각 Git 커밋은 고유하고 변경할 수 없는 계산된 SHA 값을 수신합니다. 이 방법은 삭제되거나 이동할 수 있는 태그를 지정하는 것보다 더 안정적일 수 있으므로 작업의 사용자는 커밋의 SHA 값에 의존하는 것을 선호할 수 있습니다. 그러나 이는 사용자가 작업에 대한 추가 업데이트를 받지 못한다는 것을 의미합니다. 약식 값이 아닌 커밋의 전체 SHA 값을 사용해야 합니다.\n\n```yaml\nsteps:\n    - uses: actions/javascript-action@a824008085750b8e136effc585c3cd6082bd575f\n```\n\n## 작업에 대한 추가 정보 파일 만들기\n\n사용자가 작업을 사용하는 방법을 배울 수 있도록 추가 정보 파일을 만드는 것이 좋습니다. 이 정보를 `README.md`에 포함할 수 있습니다.\n\n* 작업이 수행하는 작업에 대한 자세한 설명\n* 필수 입력 및 출력 인수\n* 선택적 입력 및 출력 인수\n* 작업에서 사용하는 비밀\n* 작업에서 사용하는 환경 변수\n* 워크플로에서 작업을 사용하는 방법의 예제"}