API Gateway 인가 체인 설계 - 인증 뒤에 남는 진짜 권한 문제를 어디서 풀 것인가

인증을 붙였는데 권한 문제는 왜 계속 남을까

API Gateway를 도입하면 많은 팀이 “이제 보안이 정리되겠다”는 기대를 합니다.
실제로 인증은 꽤 많이 정리됩니다.

토큰 검증
공통 헤더 처리
라우팅
rate limit

하지만 시간이 지나면 다시 비슷한 문제가 생깁니다.

어떤 사용자가 어떤 리소스에 접근 가능한가
조직별로 허용 범위가 다르다
관리자는 되는데 운영자는 안 된다
서비스마다 권한 로직이 조금씩 다르다

즉, 인증은 게이트웨이에서 정리되지만 인가는 그대로 남습니다.
그리고 이 인가를 어디서 처리할지 모호해지는 순간 시스템은 빠르게 복잡해집니다.

권한 검사를 한 곳에 몰아넣으면 왜 힘든가

게이트웨이에 다 넣는 경우

장점:

공통 규칙을 한 번에 통제 가능
외부 요청 차단이 빠름

단점:

도메인 문맥을 모르기 때문에 세밀한 판단이 어렵다
서비스별 예외가 늘수록 정책이 비대해진다
배포가 게이트웨이 병목으로 몰린다

각 서비스에 전부 맡기는 경우

장점:

도메인에 가장 가까운 판단 가능
서비스 독립성 유지

단점:

같은 권한 규칙이 여러 서비스에 중복된다
구현 방식이 팀마다 달라진다
감사와 변경 추적이 어렵다

현실적으로는 둘 중 하나가 아니라 체인 구조로 나눠야 합니다.

인가 체인을 나눌 때 기준이 되는 질문

권한 로직이 생겼을 때 아래 질문으로 위치를 결정하면 비교적 명확해집니다.

질문 1. 이 판단에 도메인 데이터가 필요한가

필요 없다면 Gateway 또는 BFF
필요하다면 서비스 내부

질문 2. 여러 서비스에서 반복되는 규칙인가

반복된다면 상위 계층에서 공통화
서비스 고유 규칙이면 내부 유지

질문 3. 이 규칙이 UI 흐름과 강하게 연결되는가

그렇다면 BFF 쪽이 자연스럽다

즉, 인가는 보안 규칙인 동시에 제품 경험 규칙이기도 합니다.

권한 모델은 코드보다 용어가 먼저다

인가 로직이 망가지는 가장 큰 이유는 구현보다 용어가 불명확하기 때문입니다.

예를 들어 아래 용어가 섞이면 금방 혼란이 옵니다.

role
permission
scope
policy
ownership

좋은 구조는 보통 이렇게 나뉩니다.

Role: 사용자 집합의 책임 단위
Permission: 가능한 행위
Resource Scope: 어떤 자원 범위에 적용되는가
Policy: 허용/거부 규칙 조합

이 용어 구분이 명확해야 게이트웨이, BFF, 서비스 간 역할 분리가 쉬워집니다.

마무리

API Gateway를 도입했다고 해서 인가 문제가 저절로 사라지지는 않습니다.
오히려 인증과 인가를 구분하지 않으면 더 복잡해질 수 있습니다.

핵심은 아래 세 가지입니다.

게이트웨이는 거친 1차 필터에 집중할 것
UI 흐름 기반 권한은 BFF나 API 계층에서 조합할 것
자원 수준 최종 권한은 반드시 도메인 서비스가 판단할 것

인가 체계가 잘 설계된 시스템은 보안이 강한 것뿐 아니라 변경에도 강합니다.
어디서 어떤 권한 판단이 일어나는지가 선명하면, 서비스가 늘어나도 구조가 쉽게 무너지지 않습니다.