공개 저장소에 올린 이슈가 나만 보인다고? GitHub의 권한 문제를 들여다보다

문제 상황: 보이지 않는 이슈들

Reddit의 r/github에 올라온 글을 살펴보니, 한 사용자가 공개(public) 저장소에 만든 이슈(issue)를 다른 사람에게 공유했을 때 404 에러를 받았다고 합니다. 흥미로운 점은 이슈를 만든 본인 계정에서는 완벽하게 보이지만, 링크를 받은 다른 사람들은 “페이지를 찾을 수 없다”는 메시지를 본다는 것입니다. 그리고 새 계정을 만들어보니 그 계정에서는 정상 작동했다는 언급도 있습니다.

이것은 단순한 UI 버그가 아니라 GitHub의 권한 검증(permission validation) 체계와 관련된 문제처럼 보입니다. 공개 저장소라는 것이 “누구나 읽을 수 있다”는 뜻이라고 생각하는 것이 일반적인데, 실제 동작에서는 계정의 상태나 이슈 생성 경로에 따라 다른 결과가 나타난다는 신호입니다.

자동화 시대에 걸리기 쉬운 함정

원문을 확인해본 결과, 이 문제는 특히 1인 자동화 운영자나 n8n 같은 워크플로우 엔진을 통해 GitHub API를 다루는 사람들에게 중요한 의미를 가집니다. 왜냐하면 자동화된 스크립트(automated script)나 액션(action)으로 이슈를 생성할 때, 이런 권한 캐싱(permission caching) 문제가 숨어있을 수 있기 때문입니다.

35년을 기술 교육 현장에서 지켜보며 느낀 것은, 시스템이 점점 복잡해질수록 “당연히 작동할 것 같은” 부분에 예상 밖의 구멍이 생긴다는 점입니다. GitHub이 공개 저장소라는 개념을 정의할 때는 분명 “누구나 볼 수 있다”는 의도였을 텐데, 서버 캐시, 세션 상태, API 토큰의 권한 범위(scope) 같은 여러 계층이 겹치면서 이런 모순 상황이 발생합니다.

특히 n8n을 통해 GitHub 자동화를 구축하는 입장에서는, 이슈가 정상적으로 생성되었다는 응답(response)을 받아도 실제로 다른 사용자가 접근할 수 없다면 워크플로우 자체의 신뢰도에 영향을 미칩니다. 테스트 환경에서는 문제가 없었지만 본 환경에서 터지는 버그의 전형적인 패턴입니다.

근본 원인을 추적하려면

원문에서 “새 계정에서는 잘 작동한다”는 언급이 주목할 만합니다. 이것은 문제가 이슈 자체의 생성 로직이 아니라, 기존 계정의 상태나 이력(history)과 관련이 있을 수 있음을 시사합니다. 생각할 수 있는 원인들을 나열해보면:

• 계정 권한 캐시가 오래된 상태로 남아있음
• 이전에 차단(block)되거나 제한(restrict)된 이력이 남아있음
• API 토큰의 권한 범위가 불완전하게 설정됨
• 저장소 설정에서 특정 사용자를 명시적으로 제외했을 가능성
• GitHub의 스팸 필터(spam filter)나 자동 모니터링 시스템이 그 계정을 의심하고 있을 가능성

이런 복합적인 원인들을 하나하나 배제하려면, GitHub의 공식 문서(official documentation)에서 이슈 권한(issue permissions)에 관한 섹션을 정독하고, 설정 페이지에서 계정-저장소 간 권한 관계를 직접 확인해봐야 합니다.

지켜봐야 할 지점

GitHub 커뮤니티에서 이 문제가 얼마나 널리 보고되고 있으며, GitHub 공식팀이 어떤 입장을 취하고 있는지가 중요한 논쟁 지점입니다. 만약 이것이 특정 계정 상태에만 나타나는 edge case라면 개별 지원으로 해결될 테지만, 더 광범위한 권한 검증 로직의 문제라면 플랫폼 전체에 영향을 미칠 수 있습니다.

이 이슈는 다음 편에서 어떻게 흘러갔는지, 사용자들이 제시한 해결책이 무엇이었는지, 그리고 GitHub이 공식 입장을 낸 후속 전개를 이어서 다뤄보겠습니다.