에이전트 인가를 제어하는 태스크 기반 오스 동의 화면의 아키텍처
서드파티 애플리케이션이나 인공지능 도구에 사용자 계정 권한을 넘겨줄 때 우리는 늘 딜레마에 빠집니다. 클라이언트가 요구하는 권한 목록을 전부 승인하지 않으면 아예 기능을 시작조차 할 수 없고, 그렇다고 전체 권한을 덜컥 넘겨주자니 내 데이터와 인프라가 어디까지 노출될지 불안하기 때문입니다. 특히 거대언어모델(LLM) 기반의 에이전트나 모델 컨텍스트 프로토콜(MCP, Model Context Protocol) 서버처럼 여러 도구를 폭넓게 다루는 시스템이 등장하면서 이 불안은 현실적인 보안 위협이 되었습니다.
지금까지 대부분의 오스(OAuth, Open Authorization) 인가 흐름은 전부 수락하거나 전부 거절하는 이분법 구조였습니다. 사용자가 동의 화면에서 특정 스코프(Scope, 인가 범위)만 골라서 허용하고 싶어도 권한 서버가 이를 지원하지 않으면 무조건 클라이언트의 요구를 통째로 받아들여야 했습니다. 개발사 입장에서도 사용자가 일부 권한을 뺐을 때 발생할 예외 처리가 까다롭다는 핑계로 전체 승인 방식을 고수해 왔습니다.
결국 사용자는 도구를 쓰기 위해 과도한 쓰기 권한이나 조회 권한을 한꺼번에 내어주게 됩니다. 에이전트가 단지 설정 상태 하나를 읽으려 할 뿐인데 전체 인프라 스크립트를 수정할 수 있는 권한까지 위임받는 구조는 최소 권한 원칙(Principle of Least Privilege)을 정면으로 위배합니다. 권한 인프라가 세분화된 스코프를 정의하더라도 동의 화면이 작업 단위의 선택권을 보장하지 못한다면 보안 정책은 껍데기만 남습니다.
전부 아니면 전무 방식이 에이전트 환경에서 무너진 배경
클라이언트가 장기 자격 증명(Credential)이나 비밀번호를 직접 다루지 않고 안전하게 권한을 위임받는 오스 모델은 웹 생태계의 표준으로 자리 잡았습니다. 서비스형 소프트웨어(SaaS) 연동이나 명령줄 인터페이스(CLI) 도구처럼 명확하고 고정된 기능을 수행할 때는 고정된 소수의 스코프로도 권한 제어가 충분했습니다. 깃허브 저장소를 읽거나 슬랙 메시지를 전송하는 식의 정적인 연결에서는 권한 요구가 투명했기 때문입니다.
하지만 MCP 서버와 자율형 에이전트가 개입하면서 상황이 급변했습니다. 에이전트는 앞으로 어떤 도구를 호출할지 사전에 100% 확정하기 어렵습니다. 잠재적으로 데이터베이스를 읽고, 캐시 스토리지를 갱신하며, 스크립트를 배포하는 모든 작업을 수행할 수 있어야 하므로 클라이언트는 처음부터 가질 수 있는 가장 넓은 범위의 권한을 요구하게 됩니다. 사용자는 당장 파일 하나를 파싱하는 작업만 맡기고 싶어도 에이전트가 요구하는 수십 가지 권한 묶음을 통째로 승인해야만 합니다.
Cloudflare Blog에 따르면 개발자들이 클라우드플레어 상에서 수천 개의 서드파티 오스 앱을 만들고 수백만 건의 인가를 처리하는 과정에서 권한 모델은 점점 더 세분화되었습니다. 하지만 권한 모델이 아무리 정교해져도 동의 화면이 전부 아니면 전무(All-or-Nothing) 방식으로 남아있다면 사용자는 극단적인 선택에 내몰립니다. 과도한 권한을 감수하고 승인하거나, 아니면 도구 사용 자체를 포기하는 것뿐입니다.
결국 보안에 민감한 사용자는 도구 도입을 망설이고, 개발자는 사용자 이탈을 막기 위해 별도의 스코프 선택 화면을 인가 흐름 앞에 직접 구현해야 하는 비효율이 발생했습니다. 권한 위임의 신뢰를 담보해야 할 인가 서버가 사용자에게 권한 축소 권한을 주지 않음으로써 전체 아키텍처의 보안 부채를 키워온 셈입니다.
태스크 중심 스코프 커스터마이징의 동작 구조
인가 서버가 작업 중심의 동의 화면을 지원하기 위해 도입한 방식은 필수 스코프와 선택적 스코프의 분리입니다. 원래 오스 사양(OAuth 2.0 Spec) 자체는 인가 서버가 클라이언트가 요청한 것보다 좁은 범위의 스코프를 발급하는 것을 이미 허용하고 있습니다. 이번에 클라우드플레어가 공개한 방식은 이 표준의 유연성을 활용하여 클라이언트 설정과 인가 런타임을 정밀하게 결합합니다.
핵심은 클라이언트가 등록한 전체 스코프 목록을 무작정 동의 화면에 늘어놓지 않는다는 점입니다. 클라이언트 소유자는 앱을 구성할 때 특정 스코프를 필수가 아닌 선택 항목(Optional)으로 지정할 수 있습니다. 그리고 실제 인가 요청이 발생했을 때, 인가 서버는 해당 요청에 명시된 스코프만을 대상으로 필수와 선택을 평가합니다.
예를 들어 한 클라이언트가 사용자 정보 읽기(user-details.read), 워커 스크립트 쓰기(workers-scripts.write), KV 스토리지 쓰기(workers-kv-storage.write), 존 읽기(zone.read)를 지원하도록 등록되어 있고, 이 중 KV 스토리지 쓰기와 존 읽기를 선택 항목으로 지정해 두었다고 가정해 봅니다. 클라이언트가 네 가지 권한을 모두 요구하는 인가 요청을 보내면 동의 화면에는 네 가지가 모두 나타나지만, 사용자는 선택 항목인 두 가지를 체크 해제하고 나머지 두 가지만 승인할 수 있습니다.
반대로 클라이언트가 특정 워크플로에서 스크립트 쓰기와 존 읽기 두 가지만 요청한다면 동의 화면에는 이 두 가지만 평가됩니다. 요청되지 않은 사용자 정보 읽기나 KV 스토리지 쓰기는 화면에 나타나지도 않고 검증 대상에서도 빠집니다. 클라이언트가 현재 수행하려는 작업 맥락에 꼭 필요한 권한만 화면에 올리고, 그 안에서 사용자가 추가로 통제권을 행사하도록 만드는 구조입니다. 기존 클라이언트가 선택적 스코프 기능을 활성화하지 않았다면 기본 동작은 그대로 유지되어 하위 호환성도 깨지지 않습니다.
부분 인가가 백엔드 아키텍처에 요구하는 엔지니어링 비용
동의 화면에서 사용자가 스코프를 골라낼 수 있게 되면 보안 수준은 비약적으로 올라가지만, 백엔드 엔지니어링 관점에서는 새로운 트레이드오프를 감수해야 합니다. 가장 큰 변화는 인가 서버가 발급하는 액세스 토큰의 권한 집합이 클라이언트가 애초에 요청했던 것과 달라질 수 있다는 사실을 프론트엔드와 백엔드가 모두 전제해야 한다는 점입니다.
기존의 단순한 애플리케이션은 인가 흐름이 성공적으로 끝나면 요청했던 모든 스코프가 토큰에 포함되어 있다고 가정하고 코드를 짰습니다. 하지만 부분 승인이 허용되는 순간, 시스템은 토큰 파싱 단계나 인가 미들웨어에서 권한 누락을 상시로 처리해야 합니다. 사용자가 특정 스토리지 쓰기 권한을 제외하고 승인했다면, 애플리케이션은 해당 스토리지에 접근하는 로직에서 403 Forbidden 오류를 우아하게 격리하고 사용자에게 권한 부족 상태를 명확히 피드백해야 합니다.
text
[인가 요청: read, write, kv-storage]
↓
[동의 화면: kv-storage 체크 해제]
↓
[토큰 발급: read, write 만 포함]
↓
[API 호출: KV Storage 접근 시도] → [403 Scope Missing 반환]
↓
[클라이언트: 전체 장애 유발 없이 해당 기능만 비활성화]만약 에이전트 시스템이 이러한 부분 권한을 고려하지 않고 모놀리식한 파이프라인으로 설계되어 있다면, 도구 실행 중간에 권한 오류를 만나 전체 컨텍스트가 깨져버리는 장애가 발생합니다. 각 도구(Tool) 호출 단위로 권한 검증을 캡슐화하고, 권한이 없는 작업은 대안 경로를 찾거나 사용자에게 추가 권한을 단계적으로 요청(Incremental Authorization)하는 로직이 백엔드 전반에 배치되어야 합니다.
또한 감사 로그(Audit Log)와 토큰 수명 관리도 복잡해집니다. 사용자가 언제 어떤 스코프를 제외했는지 명확히 기록되어야 하며, 나중에 사용자가 추가 기능을 사용하기 위해 다시 인가 흐름을 탈 때 기존 토큰을 갱신할지 새로운 권한을 병합할지에 대한 상태 관리 정책이 명확해야 합니다. 보안의 유연성을 얻는 대가로 클라이언트와 API 게이트웨이 간의 상태 동기화 비용을 치르는 셈입니다.
태스크 기반 인가 모델 도입을 판단하는 명확한 기준
태스크 중심의 동의 화면과 선택적 스코프 모델이 모든 시스템에 무조건 정답인 것은 아닙니다. 시스템의 복잡도와 사용자 경험 사이의 명확한 손익 계산이 필요합니다.
단일 목적을 가진 단순 연동 도구라면 굳이 선택적 스코프를 도입할 이유가 없습니다. 예를 들어 특정 메신저에 단순 알림 메시지만 쏘는 웹훅 클라이언트나, 특정 데이터베이스 테이블 하나만 동기화하는 단방향 배치 작업이라면 모든 스코프가 필수적입니다. 이런 도구에 선택적 스코프를 어설프게 적용하면 사용자의 체크 해제로 인해 도구 자체가 아예 동작하지 않는 무의미한 실패율만 높아집니다.
반면 다음과 같은 환경이라면 태스크 기반 오스 동의 모델 도입을 즉시 검토해야 합니다:
첫째, 여러 기능을 한데 묶어 제공하는 통합 CLI나 개발자 도구 플랫폼입니다. 인프라 배포, 로그 조회, 시크릿 관리를 한 도구에서 처리할 때, 사용자가 읽기 전용 작업만 수행하고자 한다면 배포 권한을 제외할 수 있어야 도구 도입의 보안 심사를 통과할 수 있습니다.
둘째, MCP 서버나 LLM 기반 다중 도구 오케스트레이션 시스템입니다. 에이전트가 어떤 작업을 수행할지 사용자가 매번 확신할 수 없는 구조에서는 권한의 폭발 반경(Blast Radius)을 줄이는 것이 유일한 안전장치입니다. 사용자가 특정 세션이나 특정 프로젝트에 한해 민감한 데이터 접근 권한을 끄고 에이전트를 안전하게 실험할 수 있는 환경을 열어주어야 합니다.
셋째, 엔터프라이즈 환경을 타깃으로 하는 B2B SaaS입니다. 기업의 보안 담당자는 최소 권한을 보장하지 않는 서드파티 앱의 연동을 엄격히 차단합니다. 작업 단위로 권한을 축소할 수 있는 동의 화면을 제공하는 것 자체가 엔터프라이즈 시장 진입을 위한 필수 조건이 됩니다.
내일 출근해서 여러분의 시스템이 발급하는 오스 클라이언트 설정을 열어보십시오. 클라이언트가 요구하는 권한 중에 특정 기능에만 종속된 부가 권한이 섞여 있는지 확인하고, 만약 그렇다면 백엔드가 부분 승인 토큰을 수용할 준비가 되어 있는지 점검하는 것부터 시작해야 합니다.
이 글과 함께 읽으면 좋은 인사이트
댓글 0