GitHub 라벨 만드는 버튼이 어디 갔을까?

오늘 이 소식을 살펴보니 흥미로운 현상이 눈에 띕니다. Reddit의 r/github에 올라온 글에서 한 사용자가 저장소의 라벨 설정 페이지(github.com/user-name/repo-name/labels)에 접속했을 때 새 라벨을 만드는 버튼을 찾을 수 없다고 호소했습니다. 단순한 개인의 혼란처럼 보일 수 있지만, 원문을 자세히 읽어보면 “모든 저장소”에서 이 문제가 발생한다고 명시되어 있습니다. 이것은 단순 사용 미숙이 아니라, 무언가 더 넓은 범위의 문제를 암시하는 신호입니다.

사용자가 마주한 벽

원문의 핵심은 매우 명확합니다. 사용자는 라벨 관리 페이지에 도달했지만, 그곳에서 “new label”이나 “create”라는 버튼을 발견하지 못했습니다. 이는 두 가지 가능성을 던집니다. 첫째, 저장소에 대한 접근 권한(permission) 문제일 수 있습니다. GitHub에서는 라벨 생성 권한을 명시적으로 관리하는데, 협력자(collaborator)가 아니거나 쓰기 권한(write access)이 없다면 UI 자체가 나타나지 않을 수 있습니다. 둘째, 최근의 UI 변경(interface redesign)이 이루어졌을 가능성입니다. GitHub은 꾸준히 대시보드와 설정 페이지를 개선해왔고, 특히 2024년 이후로 관리 인터페이스의 위치와 형태가 여러 번 조정되었습니다.

흥미로운 점은 이 사용자가 답변을 얻지 못한 채로 직접 해법을 찾았다는 부분입니다. 커뮤니티로부터의 도움이 충분하지 않았던 상황에서, 본인이 GitHub CLI(command-line interface)를 활용한 우회 방법을 발견하고 공유했습니다: gh label create label-name --repo username/repo-name. 이것은 그래픽 인터페이스의 제약을 프로그래밍 방식으로 해결한 사례입니다.

자동화 운영자에게 던지는 질문

이 이슈가 가진 의미를 생각해봅시다. n8n이나 다른 자동화 도구로 GitHub 워크플로우를 구축하는 1인 운영자들에게 라벨은 중요한 역할을 합니다. 이슈를 자동으로 분류하고, 풀 리퀘스트의 상태를 추적하며, 우선순위를 시각화하는 핵심 메커니즘이 바로 라벨입니다. 만약 웹 UI에서 라벨을 만들 수 없다면, 자동화 스크립트에서 API 호출(API call)을 통해 라벨을 생성해야 하거나, CLI 명령어를 쉘 스크립트에 통합해야 합니다.

35년간 기술 교육 현장에서 여러 플랫폼의 흥망을 지켜본 입장에서, 이런 현상은 매우 익숙합니다. 사용자가 기대하던 기능이 갑자기 보이지 않을 때, 그것은 보통 세 가지 중 하나입니다: 정책 변경(policy change), 권한 체계의 재편, 혹은 사용자 인터페이스의 진화 과정에서 발생한 일시적 혼란. GitHub도 마찬가지로 성장하는 플랫폼이고, 수백만 사용자의 피드백과 보안 요구사항을 반영하면서 계속 변모하고 있습니다.

웹 인터페이스 vs. 자동화 도구의 불일치

원문의 해결책이 CLI 기반이라는 점이 의미심장합니다. 이것은 현대 개발 도구가 보여주는 한 가지 패턴입니다: 그래픽 인터페이스가 모든 기능을 충분히 노출하지 않을 때, 프로그래밍 인터페이스(API, CLI)가 대안이 되어준다는 것입니다. 실제로 GitHub API 문서를 확인해보면, 라벨 생성은 완전히 지원되는 기능입니다. REST API의 POST /repos/{owner}/{repo}/labels 엔드포인트가 존재하며, GitHub CLI도 이를 래핑(wrapping)하고 있습니다.

이것이 1인 자동화 운영자들이 마주하는 현실입니다. 마우스 클릭으로 일을 처리하고 싶어도, 때론 터미널을 열고 API 문서를 참고해야 합니다. 웹 UI가 모든 요구사항을 충족하지 않을 때, 프로그래밍적 접근이 필수가 됩니다. 이것은 단점만은 아닙니다. 자동화 관점에서 보면, CLI나 API를 사용하는 것이 오히려 더 투명하고, 스크립트화(scriptable)하고, 감사 추적(audit trail)이 남습니다.

권한 체계의 복잡성

깊이 있게 살펴보면, 이 문제는 권한 관리(permission management)의 복잡성을 드러냅니다. GitHub은 조직과 개인 저장소를 다르게 취급하고, 각 저장소에 대한 역할(role)을 세분화하고 있습니다. 저장소 생성자라고 해서 항상 라벨을 만들 수 있는 것은 아닙니다. 특히 조직 저장소(organization repository)에서는 더욱 그렇습니다. 만약 사용자가 읽기 권한(read access)만 가지고 있다면, UI는 아예 그 기능을 숨깁니다. 이것이 GitHub의 설계 철학입니다: 권한이 없는 기능은 보여주지 않는 것입니다.

그런데 원문의 사용자는 “모든 저장소에서” 이 문제가 나타난다고 했습니다. 그렇다면 단순한 권한 문제는 아닐 수 있습니다. 혹은 계정 수준의 권한 설정이 일괄적으로 변경되었거나, 또는 정말로 UI 자체가 임시적으로 비활성화(disabled)되었을 가능성도 있습니다.

지속적으로 관찰해야 할 지점

이 이슈를 종합하면, “GitHub의 웹 인터페이스와 API 기능 사이의 불일치가 얼마나 자주 발생하며, 사용자들은 이를 어떻게 감지하고 대처하는가” 하는 논쟁이 있는데, 이 부분은 계속 지켜봐야 할 지점입니다. 플랫폼이 성장할수록, UI/UX 개선과 API의 완전성 사이의 간극이 벌어질 수 있기 때문입니다.

또한 이 이슈는 다음 편에서 어떻게 흘러갔는지 이어서 다뤄보겠습니다. GitHub이 이러한 라벨 생성 문제를 공식적으로 인지하고 대응했는지, 아니면 사용자 커뮤니티가 개발한 워크어라운드(workaround)들이 표준화되고 있는지, 그리고 자동화 도구들이 이 변화에 어떻게 적응하고 있는지를 함께 살펴볼 계획입니다.