GitHub OAuth가 조용히 바꾼 것들: 토큰 유효기간과 리다이렉트 주소 다중화

이번 업데이트가 조용하지 않은 까닭

GitHub Changelog에서 어제 공개한 이 업데이트(2026-08-14)를 살펴보니, 겉으로는 “보안 강화”라는 낡은 표현 뒤에 꽤 실질적인 세 가지 변화가 숨어 있습니다. OAuth 앱의 토큰 유효기간(expiring access tokens), 리다이렉트 주소 다중화(multiple redirect URIs), 그리고 와일드카드 매칭(wildcard matching)입니다. 개별 개발자 입장에서 이들이 왜 동시에 움직였는지를 먼저 생각해봐야 합니다.

35년간 교육 현장에서 웹 기술의 물결을 지켜본 경험상, 이런 “동시 정책 변경”은 보통 한 가지 깊은 이유가 있습니다. 이 경우 원문을 읽어보니 명확합니다: GitHub이 OAuth 앱 개발자들에게 “지금 당신의 보안 모델을 재검토할 때”라고 신호를 보내고 있는 것입니다.

먼저 토큰 문제부터 풀어보기

원문에 따르면 OAuth 앱들은 이제 다음 두 가지 방식 중 하나를 선택할 수 있습니다:

첫 번째는 옵트인 방식: offline_access 스코프를 인증 요청에 포함시키면, 8시간짜리 단기 토큰(access token)과 6개월짜리 갱신 토큰(refresh token)을 받게 됩니다. 토큰이 만료되면 갱신 토큰으로 새로운 토큰 쌍을 얻습니다.

두 번째는 강제 방식: 앱 등록 설정에서 “항상 단기 토큰 사용”을 활성화하면, 오래된 클라이언트까지 강제로 업데이트되도록 만들 수 있습니다.

이것이 의미하는 바는 무엇일까요? 원문을 그대로 읽으면 “단기 토큰은 모든 새로운 애플리케이션에서 기본값으로 활성화됩니다”라고 명시되어 있습니다. 즉, GitHub은 기존의 “한 번 발급받으면 무기한 유효한” 토큰 모델을 천천히 폐기하겠다는 신호를 던지고 있습니다.

n8n 같은 자동화 인프라를 직접 구축해본 입장에서 보면, 이것은 꽤 신경 써야 할 부분입니다. 자동화 워크플로가 중간에 토큰 갱신 로직을 처리해야 하기 때문입니다. SDK가 이를 지원하지 않으면 일단 비활성화할 수 있다는 원문의 문장(“If your authentication SDK doesn’t support the refresh token flow, you can disable this while updating the SDK”)이 있으니, 여유가 있습니다. 하지만 언제까지인지는 명확하지 않습니다.

리다이렉트 주소 문제의 현실적 의미

두 번째 개편은 더 직관적입니다. 원문에 따르면 OAuth 앱이 이제 최대 10개의 리다이렉트 URI(callback URI)를 등록할 수 있게 되었습니다. 이전에는 한 앱당 하나 또는 매우 제한된 수의 주소만 가능했다는 뜻입니다.

이것이 개발자 경험(DX)에 미치는 영향은 실제입니다. 지금까지는 다양한 배포 환경(로컬, 개발, 스테이징, 프로덕션)이나 서로 다른 도메인을 지원하려면 여러 개의 앱을 등록해야 했습니다. 각각을 관리하는 것은 번거로웠고, 토큰 관리도 복잡했습니다.

원문에서 제시한 와일드카드 매칭(wildcard matching) 기능까지 합쳐지면, “테넌트형 서브도메인”(예: tenant-a.example.com, tenant-b.example.com)처럼 동적 리다이렉트가 필요한 상황도 한 앱으로 처리할 수 있게 됩니다. 이는 특히 SaaS 형태의 자동화 도구를 만드는 팀에게 매력적인 변화입니다.

누구에게 먼저 영향을 미칠까?

이 세 가지 변화를 종합하면, 가장 먼저 감지할 그룹은:

• n8n, Zapier 같은 자동화 플랫폼: 사용자마다 다른 환경에서 워크플로를 실행해야 하므로, 다중 리다이렉트 URI와 토큰 갱신 로직이 즉시 필요합니다.
• 멀티테넌트 SaaS 앱: 각 고객이 고유의 배포 도메인을 가진 경우, 이제 앱 하나로 모두 처리할 수 있습니다.
• 엔터프라이즈 자동화 팀: 여러 환경(on-premise, 클라우드, 하이브리드)을 동시에 관리하는 팀에게는 관리 복잡도가 줄어듭니다.

반면 단순한 개인 프로젝트나 소규모 내부 도구의 경우, 이 변화가 즉시 필요하지는 않습니다. 다만 언젠가는 대응해야 한다는 신호는 명확합니다.

아직 남은 질문들

원문을 정독해본 결과, 명확하지 않은 부분도 있습니다. 예를 들어 토큰 갱신 정책의 “강제 전환” 시점은 언제일까요? 옵트인 방식으로는 얼마나 오래 지원할까요? 그리고 와일드카드 매칭이 보안 구멍이 되지 않을까 하는 우려는 계속 모니터링해야 할 지점입니다. 원문에서는 “wildcard matching if needed”라고만 표현했지만, 실제 배포 과정에서 공격 벡터가 될 가능성까지 고려한 가이드라인이 충분한지는 확인이 필요합니다.

이 정책 전환이 GitHub의 보안 아키텍처를 어떻게 개선했고, 혹은 어떤 새로운 취약점을 만들었는지는 다음 편에서 실제 사례와 함께 이어서 다뤄보겠습니다.