GitHub 라벨 보관 기능 정식 출시: 이력은 남기고 선택지는 줄인다
GitHub Issues의 라벨 보관과 최근·추천 라벨 기능이 정식 출시됐다. 오래된 분류 이력을 지우지 않고 라벨 선택기를 정리하는 방법과 자동화 영향, 적용 전 확인 사항을 정리했다.
GitHub가 2026년 8월 27일 Issues 라벨의 보관 기능과 라벨 추천 기능을 정식 출시했다. 오래된 라벨을 삭제해 과거 이슈에서 의미가 사라지는 문제를 피하면서, 새 이슈에 라벨을 붙일 때는 현재 쓰는 항목에 집중할 수 있게 한 변화다.
무엇이 바뀌었나
저장소 관리자는 더 이상 쓰지 않는 라벨을 보관할 수 있다. 보관된 라벨은 기존 이슈와 풀 리퀘스트의 이력에 남지만 일반 라벨 선택기에서는 빠진다. 필요하면 언제든 보관을 해제할 수 있다. 삭제와 달리 분류의 역사와 검색 맥락을 유지한다는 점이 핵심이다.
라벨 선택기에는 저장소에서 최근 자주 사용한 항목을 바탕으로 한 추천과, 사용자가 직접 최근 선택한 라벨도 나타난다. 수백 개 라벨을 가진 저장소에서 이름을 정확히 기억하거나 긴 목록을 훑는 시간을 줄이려는 기능이다. GitHub는 이를 별도 버전 업그레이드가 필요 없는 GitHub.com 기능으로 제공한다.
개발자에게 왜 중요한가
라벨은 단순 색상표가 아니라 자동화의 입력값이다. 릴리스 노트 생성, 지원 요청 분류, 프로젝트 보드 이동, Actions 워크플로, 봇과 외부 티켓 시스템이 라벨 이름을 조건으로 삼는다. 오래된 라벨을 삭제하면 과거 질의와 보고서가 달라질 수 있지만, 보관은 이력을 유지하면서 신규 사용만 줄이는 단계적 정리 수단이 된다.
추천 라벨은 입력 편의 기능이지 분류 정책을 대신하지 않는다. 최근 사용량이 많다는 이유만으로 의미가 겹치는 라벨이 자동 통합되는 것은 아니며, 잘못 쓰인 라벨이 계속 추천될 가능성도 있다. 이름·설명·적용 기준을 문서화하는 운영은 여전히 필요하다.
기존 프로젝트 영향
코드 호환성이나 런타임 버전에는 영향이 없다. 다만 라벨 목록을 API로 동기화하는 도구는 보관 상태를 어떻게 반환하고 처리하는지 확인해야 한다. GitHub Changelog는 UI 동작을 중심으로 설명하므로, GraphQL 또는 REST 응답에 의존하는 자동화는 실제 저장소에서 보관 전후 응답을 시험한 뒤 운영에 적용하는 편이 안전하다.
적용 전 확인 사항
- 최근 6~12개월 동안 새로 붙지 않았지만 과거 검색과 보고에 필요한 라벨을 후보로 뽑는다.
- Actions, 봇, 프로젝트 필터와 외부 연동에서 해당 라벨 이름을 참조하는지 코드 검색한다.
- 삭제 대신 먼저 보관하고, 팀의 라벨 선택기와 저장된 검색이 예상대로 작동하는지 확인한다.
- 이름만 다른 중복 라벨은 보관 전에 기준 라벨과 의미를 문서화한다.
- 보관 해제 절차와 담당자를 정해 잘못 정리한 경우 되돌릴 수 있게 한다.
이번 기능은 큰 마이그레이션이 아니라 분류 체계를 서서히 정리할 수 있는 안전장치에 가깝다. 작은 저장소에서는 효과가 제한적이지만, 라벨이 오래 축적된 조직에서는 이력 보존과 입력 편의 사이의 충돌을 줄여준다.
