Skip to content

ADR-04: OAuth 토큰 Graceful Degradation ​

🇺🇸 English Version

날짜작성자리포지토리
2024-12-18@KubrickCodeworker

배경 ​

비공개 저장소 과제 ​

저장소 분석 서비스는 공개 및 비공개 저장소 모두 지원해야 함:

공개 저장소:

  • 인증 없이 접근 가능
  • 모든 사용자 이용 가능

비공개 저장소:

  • 사용자 인증 필요 (OAuth 토큰)
  • 권한 있는 사용자만 접근 가능

설계 긴장 ​

모든 분석에 인증을 요구하는 순진한 접근은 마찰을 만든다:

접근 방식공개 저장소비공개 저장소사용자 경험
항상 인증 필요동작 (하지만 불필요)동작높은 마찰
인증 절대 없음동작실패제한된 기능
가능할 때 인증동작권한 시 동작최적

목표: 자격 증명이 있을 때 비공개 저장소 접근을 지원하면서 접근성을 최대화.

에러 처리 복잡성 ​

토큰 관련 실패는 근본적으로 다른 원인을 가짐:

예상된 조건:

  • 사용자가 계정 연결 안 함 (저장된 토큰 없음)
  • 공개 전용 접근을 위해 토큰을 의도적으로 제공 안 함

인프라 실패:

  • 토큰 저장소 서비스 불가
  • 복호화 실패
  • 토큰 조회 중 네트워크 타임아웃

이들은 다른 처리 전략이 필요함—모든 토큰 에러를 동일하게 처리하면 사용자를 불필요하게 차단하거나 실제 문제를 가림.

결정 ​

명시적 에러 분류와 함께 OAuth 토큰 처리를 위한 graceful degradation 채택.

핵심 원칙 ​

1. 도메인 예외 분리

예상된 조건과 인프라 실패 구분:

예외 유형의미처리
Token Not Found저장된 토큰 없음 (예상됨)공개로 대체
Token Lookup Failed인프라 에러 (예상치 못함)작업 실패

이것이 중요한 이유:

  • 예상된 조건은 시스템 문제를 나타내지 않음
  • 인프라 실패는 알림과 조사 필요
  • 로그 레벨이 다름 (info vs error)
  • 재시도 전략이 다름 (재시도 없음 vs 백오프로 재시도)

2. 공개 접근 대체

토큰이 없을 때 (예상된 조건):

  • 비인증 접근으로 진행
  • 관측성을 위해 info 레벨 로그
  • 공개 저장소 정상 동작
  • 비공개 저장소는 clone 시 실패 (예상됨)

3. 인프라 에러 시 빠른 실패

토큰 조회가 예상치 않게 실패할 때:

  • 즉시 작업 실패
  • error 레벨 로그
  • 모니터링/알림 활성화
  • 잠재적으로 손상된 상태로 진행 안 함

4. 선택적 토큰 조회

토큰 저장소 없는 배포 지원:

  • 토큰 조회 미설정 시 공개 접근만 사용
  • 공개 전용 사용 케이스를 위한 단순 배포 가능
  • 미설정 컴포넌트에 대한 런타임 에러 없음

검토한 옵션 ​

옵션 A: 예외 분리를 가진 Graceful Degradation (선택) ​

설명:

토큰 관련 에러를 예상됨 vs 예상치 못함으로 분류. 예상된 조건에는 공개 접근으로 대체, 인프라 에러는 실패.

장점:

  • 공개 저장소를 위한 최적의 사용자 경험
  • 명확한 에러 의미론으로 적절한 모니터링 가능
  • 인증 및 비인증 사용 케이스 모두 지원
  • 인프라 문제 즉시 표면화

단점:

  • 더 복잡한 에러 처리 로직
  • 신중한 예외 설계 필요
  • 테스트가 여러 경로 커버 필요

옵션 B: 필수 인증 ​

설명:

모든 분석 요청에 유효한 인증 필요.

토큰 없음 → 요청 거부
유효하지 않은 토큰 → 요청 거부

장점:

  • 단순한 로직 (토큰 필수, 끝)
  • 모든 요청에 더 높은 속도 제한
  • 일관된 동작

단점:

  • 공개 저장소 분석만 원하는 사용자 차단
  • 일반적인 사용 케이스에 불필요한 마찰
  • 첫 사용 전 계정 연결 강제

옵션 C: 모든 토큰 에러를 치명적이지 않게 처리 ​

설명:

모든 토큰 관련 에러에 공개 접근으로 대체.

토큰 없음 → 공개 접근
조회 실패 → 공개 접근
복호화 실패 → 공개 접근

장점:

  • 최대 가용성
  • 단순한 대체 로직

단점:

  • 인프라 문제 가림
  • 복호화 실패가 보안 문제 나타낼 수 있음
  • 알림/모니터링에서 차별화 없음
  • 손상된 상태로 진행할 수 있음

구현 원칙 ​

예외 계층 ​

의도를 전달하는 도메인 예외 설계:

예외의미액션
TokenNotFound토큰 없음 (비즈니스 조건)Info 로그 + 대체
TokenLookupFailed저장소/인프라 에러 (시스템 문제)Error 로그 + 실패

토큰 처리 흐름 ​

요청 도착
  └── 토큰 조회 설정됨?
        ├── 아니오 → 공개 접근 사용
        └── 예 → 토큰 조회 시도
                    ├── 성공 → 인증된 접근 사용
                    ├── 미발견 → 공개 접근 사용 (info)
                    └── 조회 실패 → 작업 실패 (error)

암호화 고려사항 ​

토큰이 암호화되어 저장될 때:

  • 복호화 실패는 인프라 에러 ("토큰 미발견" 아님)
  • 키 불일치는 설정 문제 나타냄
  • 빠르게 실패해야 함, 조용히 저하되면 안 됨

로깅 전략 ​

시나리오레벨내용
토큰 미발견INFO사용자 ID, 공개 접근으로 진행
토큰 발견DEBUG사용자 ID, 인증된 접근 사용
조회 실패ERROR사용자 ID, 에러 상세, 작업 실패

결과 ​

긍정적 ​

사용자 경험:

  • 공개 저장소에 강제 인증 없음
  • 자격 증명 있을 때 비공개 저장소 지원
  • 누락된 자격 증명의 우아한 처리

운영 명확성:

  • 예상된 조건과 에러 조건의 명확한 구분
  • 적절한 알림 (예상된 조건에 거짓 경보 없음)
  • 인프라 문제 즉시 표면화

유연성:

  • 공개 전용 배포 지원
  • 인증된 배포 지원
  • 점진적 롤아웃 가능

보안:

  • 복호화 실패가 조용히 저하되지 않음
  • 토큰 저장소 문제가 플래그됨
  • 에러 시 인증 우회 없음

부정적 ​

복잡도:

  • 하나 대신 두 가지 예외 유형
  • 테스트할 여러 코드 경로
  • 동작에 대한 문서 필요

잠재적 혼란:

  • "토큰 미발견" vs "조회 실패" 구분 설명 필요
  • 개발자가 올바른 예외 유형 선택 필요
  • 로그 분석에 차이 이해 필요

조용한 저하 위험:

  • 공개 대체는 일부 비공개 저장소 실패가 "예상됨"을 의미
  • 사용자가 공개 제한에 도달했음을 인식 못할 수 있음
  • 저하 발생 시 명확한 피드백 필요

참고 자료 ​

Open-source test coverage insights