GitHub 개인 저장소도 이슈 유형·필드 지원, 버그와 우선순위를 나눕니다

개인 GitHub 계정으로 여러 프로젝트를 운영할 때, 저장소마다 다른 라벨로 업무를 분류해야 할까요? GitHub는 2026년 11월 11일 개인 계정 소유 저장소에도 이슈 유형과 필드를 정식 제공한다고 발표했습니다. 버그인지 기능 요청인지 같은 업무 종류와, 우선순위·예상 노력 같은 관리 항목을 계정 차원에서 정리할 수 있습니다. 공식 발표

이번 변화는 혼자 개발하는 사람이나 오픈소스 관리자가 여러 저장소의 일을 같은 기준으로 비교하는 데 의미가 있습니다. 다만 분류 항목이 생겼다고 업무 순서까지 자동으로 정해지는 것은 아닙니다. 먼저 어떤 정보를 일관되게 남길지 결정해야 합니다.

라벨 하나에 업무 종류와 긴급도를 함께 담지 않아도 됩니다

기본 이슈 유형은 Bug·Task·Feature입니다. 개인 계정 설정의 Planning에서 수정할 수 있으며, 여러 저장소에 적용할 공통 분류로 사용할 수 있습니다. 이슈 유형 관리

예를 들어 웹사이트와 자동화 도구를 별도 저장소에서 관리한다고 가정해 보겠습니다. 한쪽은 urgent-bug, 다른 쪽은 fix-now 같은 라벨로 긴급한 오류를 표시했다면, 두 저장소의 할 일을 함께 볼 때 의미부터 다시 해석해야 합니다. 유형에는 Bug를, 우선순위에는 별도의 값을 두면 ‘무슨 일인가’와 ‘얼마나 먼저 할 것인가’를 구분할 수 있습니다.

라벨을 없애야 한다는 뜻은 아닙니다. 화면 영역이나 담당 주제처럼 함께 붙여야 하는 표시는 남기고, 반복해서 비교하는 기준을 필드로 옮기는 방식부터 검토할 수 있습니다. 중요한 것은 이름을 통일하는 것뿐 아니라 같은 값이 같은 판단을 뜻하도록 설명을 정하는 일입니다.

자주 비교할 값만 정하고, 화면 표시와 자동 입력을 구분합니다

기본 필드는 Priority·Effort·Start date·Target date입니다. 필드 정의는 계정의 저장소 전반에 적용되며, 같은 이슈가 여러 프로젝트에 들어가도 이슈 필드 값은 일관되게 사용됩니다. 프로젝트마다 다른 값을 둘 수 있는 기존 커스텀 필드와는 범위가 다릅니다. 필드 관리 안내

다만 같은 소유자의 이슈와 프로젝트가 적용 범위입니다. 프로젝트에 다른 소유자의 이슈나 초안 이슈, pull request를 섞으면 해당 필드 칸은 비어 있습니다. 빈칸을 모두 입력 누락으로 처리하면 안 됩니다. 프로젝트 적용 범위

예를 들어 Priority는 이번 주에 처리할 순서를, Effort는 예상 작업 부담을 나타내도록 정의할 수 있습니다. 긴급하지만 짧은 수정과, 중요하지만 오래 걸리는 개선을 구분하려는 목적입니다. 실제 소요 시간을 측정하지 않았다면 예상값을 실측 기록처럼 다루지 않아야 합니다.

유형에 필드를 고정하면 해당 이슈를 만들거나 볼 때 입력 항목이 나타납니다. 하지만 값까지 미리 채워지는 기능은 아닙니다. 현재 이슈 템플릿이나 URL 매개변수로 필드 값을 사전 입력할 수도 없습니다. 필드 입력 방식

Projects에서는 이슈 필드로 할 일을 필터링하거나 묶어 볼 수 있습니다. 예를 들어 두 저장소의 Bug 중 우선순위가 높은 항목만 모아 점검하는 식입니다.

따라서 ‘버그를 등록하면 우선순위가 자동 판정된다’고 기대해서는 안 됩니다. 우선은 이슈 몇 개에 직접 값을 넣어 보고, 나중에 다시 읽었을 때 판단 근거를 이해할 수 있는지 확인하는 편이 좋습니다.

공개 저장소에서는 누가 필드를 볼지도 함께 정합니다

공개 저장소의 필드는 Restricted와 Public으로 공개 범위를 정할 수 있으며 기본값은 Restricted입니다. 개인 소유 저장소에서 Restricted 필드는 소유자와 읽기 권한 이상 협업자에게 보입니다. 공개 이슈라고 모든 필드가 모든 방문자에게 표시되는 것은 아닙니다. 공개 범위 안내

또한 public·internal 프로젝트에는 Public 필드만 나타나고 Restricted 필드는 숨겨집니다. 필드가 보이지 않을 때 값을 다시 입력하기 전에 프로젝트의 공개 범위를 확인할 필요가 있습니다. 프로젝트 표시 조건

예를 들어 외부 기여자가 오류를 제보하는 저장소라면, 제보자가 알아야 할 처리 기준과 운영자가 내부적으로 판단할 정보를 먼저 나눠 보세요. 공개 여부를 확인하지 않은 채 민감한 고객 정보나 내부 사정을 입력하지 않는 것이 좋습니다. 필드에 제한을 걸었다고 이슈 본문이나 댓글까지 비공개가 되는 것도 아닙니다.

이슈 필드는 현재 이슈에만 적용되고 pull request에는 지원되지 않습니다. 코드 변경 검토까지 같은 항목으로 관리하려면 이 범위를 고려해야 합니다. 지원 대상

도입할 때는 유형과 우선순위처럼 자주 쓰는 기준부터 시작해 보세요. 기존 프로젝트 필드와 같은 의미의 항목이 겹치는지 확인하고, 공개 화면과 협업자 화면에서 필요한 정보가 보이는지 점검하면 됩니다. 필드를 많이 만드는 것보다 다음 작업을 선택할 때 실제로 도움이 되는지가 판단 기준입니다.

이어볼 뉴스

이슈를 분류한 뒤 알림과 후속 작업을 연결한다면, Teams용 GitHub 앱의 변경도 함께 살펴보세요.

Teams 속 GitHub, 어느 앱을 쓰고 있나요? 구형 앱은 11월 16일 종료

#GitHub #GitHubIssues #개인개발 #프로젝트관리 #업무분류