개인 GitHub에도 이슈 유형과 필드: 혼자 쓰는 작업판을 가볍게 정하는 법

개인 GitHub 저장소의 이슈를 정리할 때는 작업의 종류와 판단에 필요한 정보를 먼저 나눠 보세요. Bug·Task·Feature 같은 유형은 ‘어떤 일인가’를, Priority·Effort·날짜 같은 필드는 ‘무엇을 먼저 하고 얼마나 준비할까’를 적는 데 활용할 수 있습니다. 처음에는 기본 항목으로 실제 이슈 몇 개를 정리해 보고, 계속 사용하는 정보가 무엇인지 확인하는 편이 부담이 적어요.

GitHub는 2026년 11월 11일 개인 계정 소유 저장소에 이슈 유형과 이슈 필드를 정식 제공한다고 발표했습니다. 이번 글은 혼자 개발하거나 개인 오픈소스 저장소를 관리하는 독자를 위한 작은 설계 안내입니다. 공식 공지와 관리 문서를 11월 12일 확인했고, 아래 작업판은 실제 개인 계정의 변경·성과를 가져온 사례가 아닌 설명용 예시예요.

개인 계정에 무엇이 들어왔는지 확인해요

공지에 따르면 개인 계정 설정의 Planning에서 이슈 유형과 필드를 관리할 수 있습니다. 기본 유형은 Bug, Task, Feature이고 유형은 최대 25개까지 만들 수 있어요. 기본 필드로는 Priority, Effort, Start date, Target date가 안내됩니다. 필드도 최대 25개까지 만들 수 있으며, 공지는 텍스트·숫자·날짜와 선택형 정보를 다룰 수 있다고 설명합니다.

이번 적용 범위는 개인 계정이 소유한 저장소입니다. 회사나 단체의 저장소에서 작업하고 있다면 소유 주체와 설정 위치를 함께 확인하세요. 내가 자주 쓰는 저장소라는 이유만으로 개인 설정의 대상이라고 생각하기는 어렵습니다. 설정을 보기 전에 어느 계정의 어떤 저장소를 정리할지 먼저 골라 두면 좋겠어요.

이슈를 만들거나 기존 이슈를 볼 때 유형과 필드를 적용할 수 있고 Projects에서도 관련 보기와 일괄 작업에 사용할 수 있다고 안내됩니다. 여기서 유형과 필드를 추가할 수 있다는 사실과, 현재 작업판의 보기·자동화가 모두 새 기준에 맞춰졌다는 사실은 각각 확인해야 합니다. 기존에 쓰던 필터나 보기가 있다면 실제로 무엇을 참조하는지 살펴보세요.

유형에는 작업의 성격을 적어 보세요

작업판을 가볍게 쓰려면 우선 기본 유형 세 개로 실제 일을 설명할 수 있는지 살펴보세요. 예를 들어 ‘저장 버튼을 두 번 누르면 같은 항목이 두 번 생긴다’는 이슈는 Bug로, ‘배포 절차의 담당자를 문서에 적는다’는 일은 Task로, ‘목록에 정렬 기능을 추가한다’는 요청은 Feature로 검토할 수 있습니다. 이는 GitHub가 강제한 분류표가 아닌 이 글의 예시입니다.

경계가 애매한 일도 있을 거예요. ‘오류 안내 문구를 바꾼다’는 이슈가 기존 동작의 결함을 고치는 것인지, 새 요구사항을 반영하는 것인지 설명을 읽고 정할 수 있습니다. 중요한 것은 이름을 많이 만드는 일보다 같은 상황에서 스스로 같은 기준을 쓰는지예요. 각 유형의 설명에 짧은 문장과 예시를 하나씩 남겨 보세요.

유형에 우선순위까지 담으려 하면 조합이 늘어날 수 있습니다. ‘긴급 버그’와 ‘보통 버그’처럼 종류를 세분화하기 전에, 종류는 Bug로 두고 긴급한 정도를 Priority에서 나타낼 수 있는지 검토해 보세요. 같은 결함이라도 영향이나 대응 시점은 바뀔 수 있으니, 두 질문을 따로 적으면 변경 이유도 설명하기 쉬워집니다.

기존 라벨은 계속 맡길 역할을 정해 보면 좋습니다. 예를 들어 이 글의 작업판에서는 화면·서버·문서 같은 관심 영역을 라벨로 남기고, 종류와 우선순위는 유형·필드로 다룹니다. 이 방식이 모든 저장소에 맞는 것은 아니에요. 이미 라벨을 이용하는 필터나 자동화가 있다면 그 사용처를 확인한 뒤 필요한 항목부터 정리하세요.

필드의 선택지에는 판단 기준을 붙여요

GitHub 관리 문서에는 기본 Priority에 Urgent·High·Medium·Low, Effort에 High·Medium·Low가 소개됩니다. 선택지를 읽는 것에서 한 걸음 더 나아가, 내 프로젝트에서 각 값이 어떤 뜻인지 적어 보세요. ‘High’만 남기면 다음 주의 내가 왜 높게 봤는지 기억하지 못할 수 있어요.

예를 들어 Priority는 사용자에게 미치는 영향과 다음 배포의 필요성을 검토하는 항목으로 둘 수 있습니다. Effort는 작업을 시작할 때 예상한 범위를 표시하는 항목으로 쓸 수 있어요. 두 값은 성격이 다르므로 작은 작업이면서 시급한 일, 큰 작업이지만 당장 시작하지 않을 일을 함께 표현할 수 있습니다. 이 구분은 실제 결과를 보장하는 공식이 아니라 개인 작업을 설명하는 제안입니다.

아직 조사하지 않은 일의 Effort를 억지로 낮음이나 높음으로 채울 필요는 없어요. 이유를 알 수 없는 값보다 ‘먼저 재현 조건을 확인한다’는 다음 행동을 본문에 적을 수 있습니다. 이후 범위를 확인했을 때 값을 정하고, 예상이 달라진 이유를 짧게 남기면 계획과 실제 작업의 차이를 돌아볼 자료가 됩니다.

날짜 필드도 의미를 정해 두세요. Start date를 ‘착수하려는 날’로 쓸지, 실제 시작을 기록할지 혼자 정하고 일관되게 쓰는 방법이 있습니다. Target date는 약속한 일정인지 개인 목표인지 설명해 둘 수 있어요. 날짜가 입력되어 있다는 이유만으로 다른 사람에게 보장된 마감이라고 읽히지 않도록, 이슈 본문에 필요한 맥락을 남겨 주세요.

이슈 세 개로 먼저 읽어 보는 작업판

직접 만든 작은 예시를 볼게요. 첫 이슈는 저장 버튼의 중복 생성 문제입니다. 유형은 Bug로 검토하고, 실제 영향을 확인하기 위한 재현 조건을 본문에 적습니다. 수정 전에 같은 입력으로 문제가 나타나는지, 수정 뒤 어떤 관찰을 남길지 완료 기준을 함께 정할 수 있어요. 우선순위는 그 영향이 확인된 뒤 판단합니다.

둘째 이슈는 배포 문서 정리입니다. 유형은 Task로 두고 ‘담당자와 확인 단계를 문서에 적고 실제 절차와 대조한다’를 다음 행동으로 쓸 수 있습니다. 단순히 문서 작성 완료라고 적는 것보다 무엇과 대조해야 하는지 알려 주는 문장이에요. 날짜를 넣는다면 다음 배포와 어떤 관계가 있는지도 한 줄 남길 수 있습니다.

셋째 이슈는 목록 정렬 기능입니다. 유형은 Feature로 검토하고, 사용자가 어떤 순서를 선택할 수 있어야 하는지 먼저 좁혀 보세요. 이때 ‘정렬 기능 전체’라는 제목을 유지하더라도, 이번에 결정할 범위와 뒤로 미룰 범위를 본문에 적을 수 있습니다. Effort가 크다고 느껴지면 값을 바꾸는 것뿐 아니라 작업 범위를 다시 나누는 질문도 해 볼 수 있어요.

이 세 이슈를 같은 작업판에서 읽고 다음에 할 일을 고를 수 있는지 확인해 보세요. 종류와 속성이 보이는데도 행동이 정해지지 않는다면, 필드를 하나 더 만들기 전에 문제 설명·관찰 조건·완료 기준이 있는지 살펴볼 수 있습니다. 작업판에 입력한 정보가 실제 선택에 쓰이는지 보는 작은 검토입니다.

여러 저장소에서 쓸 때는 이름과 사용처를 맞춰요

개인 계정의 여러 저장소에서 일한다면 같은 이름을 같은 의미로 쓰는지 확인해 보세요. 한 저장소에서는 ‘높음’을 사용자 장애로, 다른 저장소에서는 하고 싶은 정도로 사용한다면 한 화면에 모았을 때 판단이 섞일 수 있어요. 이런 차이가 필요하다면 값의 설명이나 이슈 본문에 그 범위를 남기는 방법이 있습니다.

Projects의 보기나 필터를 사용한다면 실제 이슈 몇 개로 원하는 결과가 나오는지 확인해 보세요. 새 필드와 예전에 만든 비슷한 이름의 항목이 동시에 보이면 어느 값을 기준으로 보고 있는지도 점검할 수 있습니다. 이 글에서는 특정 계정의 기존 구성이 자동으로 이전되었다고 가정하지 않습니다. 화면에 보이는 필드 이름과 실제 참조 대상을 확인하세요.

공지에는 REST·GraphQL API와 웹훅으로 관리할 수 있다는 내용도 있습니다. 자동화가 필요한 경우 검토할 수 있는 범위지만, 혼자 작업판을 정리하는 첫날부터 코드를 만들 필요는 없어요. 먼저 현재 정보가 업무 선택에 쓰이는지 확인하고, 반복 입력이 실제로 부담이 되는 부분을 찾은 뒤 권한과 변경 범위를 정할 수 있습니다.

오픈소스 이슈에서 다른 사람과 함께 쓰는 경우에는 선택지의 뜻을 알려 주세요. 예를 들어 Priority가 유지보수자의 판단인지 제안자의 의견인지 짧게 설명하면 기대를 맞추는 데 도움이 됩니다. 개인 일정이나 공개하지 않을 내부 정보는 공개 이슈의 필드에 입력하기 전에 공유 범위를 확인할 일입니다.

설정을 줄일 때는 기존 값을 보존해요

관리 문서는 유형을 비활성화하면 선택에 사용할 수 없지만 나중에 다시 켰을 때 이전에 그 유형이던 이슈에서 표시가 돌아온다고 설명합니다. 유형 삭제는 영구 제거로 안내돼 있어요. 사용하지 않는 유형을 정리하려면 먼저 현재 이슈와 필터에서 참조하는 곳이 있는지 확인하세요.

필드 삭제의 영향도 더 큽니다. 공식 문서에 따르면 필드를 지우면 이슈에 들어 있던 해당 필드의 값도 영구적으로 제거됩니다. 이름이 마음에 들지 않는다는 이유로 바로 지우기 전에, 어떤 값을 보존해야 하는지와 이름·설명 수정으로 충분한지 검토해 보세요. 이 글에서는 정리를 위해 기존 필드를 일괄 삭제하는 절차를 수행하거나 권하지 않습니다.

변경 전 메모는 간단해도 괜찮아요. 바꿀 항목, 쓰는 저장소와 보기, 기존 정의, 수정 이유를 적어 둘 수 있습니다. 값을 옮겨야 한다면 어떤 이슈까지 확인했는지 범위를 남기세요. 실제 계정에서 되돌릴 방법을 확인하지 않은 채 모든 변경을 쉽게 복구할 수 있다고 가정하지 않는 것이 좋습니다.

일주일 뒤에는 입력한 정보가 쓰였는지 돌아봐요

새 구조를 며칠 사용한 뒤 어떤 필드를 보고 다음 작업을 골랐는지 적어 보세요. 계속 비어 있는 필드가 있는지, 선택지의 뜻이 매번 달라지는지, 유형을 나누는 데 오래 망설이는 이슈가 있는지도 볼 수 있습니다. 이 질문은 개인적인 검토 제안이며 특정 기간에 생산성이 올라간다는 연구 결과를 인용한 것은 아니에요.

필드를 채운 개수보다 실제 행동과 완료를 설명할 수 있는지가 도움이 됩니다. ‘높음 10개’가 남았다면 그중 무엇부터 확인할지 결정할 조건을 본문에 더할 수 있어요. 필요한 정보가 이미 있다면 항목을 더 늘리지 않고 지금의 기준을 익히는 선택도 가능합니다.

유형과 필드를 최대 개수까지 만들어야 하나요? 공지의 25개는 생성 가능한 상한입니다. 이 글은 기본 유형과 판단에 실제 쓰는 정보부터 검토하는 예시를 제안합니다. 내 저장소와 작업판에서 쓸 이유를 설명할 수 있는 항목을 골라 보세요.

이번 기능을 켜면 기존 이슈가 모두 정리되나요? 사용할 수 있는 기능이 확대된 것과, 이슈의 문제·우선순위·완료 기준이 작성된 것은 각각 확인해야 합니다. 기존 이슈를 실제로 읽고 필요한 정보와 값을 정하는 과정이 남아 있어요.

공식 확인일은 2026년 11월 12일입니다. 실제 개인 계정에 유형·필드를 추가하거나 작업 속도를 측정하지 않았습니다. 현재 제공 범위와 관리 절차는 아래 문서를 확인해 주세요.

• 개인 계정 이슈 유형·필드 정식 제공 공지
• 이슈 유형 관리 문서
• 이슈 필드 관리 문서

할 일에서 다음 행동과 완료 기록을 연결하는 다른 사례는 JupyterHub 로드맵에서 배울 점을 정리한 글도 함께 읽어 보세요.

작업 종류와 우선순위·노력 같은 정보를 나눠 보는 개념 그림입니다. 실제 GitHub 화면이나 생산성 시험 결과는 아닙니다.