30편 · 약 15분

Phoenix 19: OAuth2 Authorization Server와 Remote MCP로 에이전트 접근 경계를 다시 그은 릴리스

왜 이번 릴리스를 봐야 하나

Phoenix는 원래 LLM 트레이스·평가·프롬프트를 모아 보는 관측성 플랫폼에 가까웠다. 하지만 코딩 에이전트와 CLI가 같은 데이터를 직접 읽기 시작하면, 단순 조회 플랫폼이 아니라 에이전트 진입점이 된다. 이때 가장 먼저 문제가 되는 것은 인증 경계다.

기존 방식은 길게 살아 있는 API 키를 배포 환경과 로컬 개발 환경에 나눠 넣는 식이었다. 사람과 에이전트가 같은 키를 공유하기 쉬웠고, 키를 하나 발급해 두면 그 키로 다시 다른 키를 만드는 흐름도 남아 있었다. Phoenix 19.0.0(2026-07-17)은 이 지점을 정면으로 바꿨다.

Phoenix가 자체 OAuth2 Authorization Server가 된다.
px CLI와 MCP 클라이언트는 브라우저 로그인으로 짧은 수명의 토큰을 받는다.
서버 안에 Remote MCP가 기본 탑재된다.
대신 API 키가 다른 API 키를 발급하는 길은 막힌다.

즉, 이번 릴리스의 핵심은 기능 추가가 아니라 누가 어떤 자격으로 Phoenix 안의 데이터와 도구에 접근하는지 다시 정의한 것이다.

변경 핵심 한눈에 보기

변화	이전	Phoenix 19 이후	운영자가 바로 확인할 것
대화형 클라이언트 인증	API 키 수동 배포	Authorization Code + PKCE 브라우저 로그인	`px auth login`, MCP 클라이언트 브라우저 로그인 동작
인증 서버 역할	Phoenix는 외부 IdP의 OAuth2 client	Phoenix가 자체 OAuth2 authorization server도 수행	`/.well-known/oauth-authorization-server` 노출 여부
MCP 연결	별도 로컬 설치/별도 도구 조합 필요	`/mcp`가 서버에 내장, 기본 활성화	`PHOENIX_ENABLE_MCP_SERVER`, `PHOENIX_ENABLE_MCP_CODE_MODE`
API 키 발급 정책	GraphQL 경로에 API-key-authenticated 발급 예외가 남아 있었음	시스템/사용자 키 모두 비전이적(non-transitive) 발급 정책으로 정리	기존 unattended key minting 스크립트 수정
에이전트 실행면	없음	MCP `execute` 도구가 Monty 샌드박스에서 Python 실행	서버에서 agent-written code를 허용할지 여부
배포 프록시 요구사항	UI/API 기준으로만 맞추면 됨	OAuth issuer·discovery·MCP challenge가 root URL에 의존	`PHOENIX_ROOT_URL`, `PHOENIX_HOST_ROOT_PATH`

아키텍처: Phoenix가 인증 서버이자 에이전트 진입점이 되는 순간

Phoenix 19의 인증·MCP·API 키 경계 재설계

이 그림에서 중요한 것은 토큰을 발급하는 경로와 데이터를 조작하는 경로가 더 명확하게 분리되었다는 점이다. Phoenix 19는 대화형 접근에는 OAuth 토큰을, 비대화형 자동화에는 시스템 키를, 부트스트랩에는 admin secret을 쓰게 한다.

OAuth2 Authorization Server: 왜 DCR + PKCE 조합인가

Phoenix 19는 인증이 켜져 있을 때 자동으로 OAuth2 authorization server를 함께 올린다. 클라이언트는 다음 순서로 붙는다.

/.well-known/oauth-authorization-server에서 메타데이터를 읽는다.
필요하면 /oauth2/register로 동적 클라이언트 등록을 한다.
/oauth2/authorize에서 사용자가 브라우저로 로그인하고 동의한다.
/oauth2/token에서 PKCE 검증을 거쳐 액세스 토큰과 리프레시 토큰을 받는다.

여기서 Phoenix가 택한 운영 관점의 포인트는 세 가지다.

1) 토큰은 짧게, 권한은 사용자 기준으로

토큰은 승인한 사용자의 권한을 그대로 계승한다. 즉, IDE 안의 에이전트가 Phoenix에 접근할 때 별도 서비스 계정처럼 동작하는 것이 아니라, 누가 승인했는지가 권한의 기준이 된다. 로컬 개발자가 자기 권한으로 최근 실패 트레이스를 읽는 데는 적합하지만, 조직 전체 권한을 가진 장기 키를 IDE에 심어 두는 방식과는 다르다.

2) 리프레시 토큰은 회전(rotating)되고 재사용이 탐지된다

Phoenix는 리프레시 토큰을 한 번 쓸 때마다 새 쌍으로 회전시키고, 이전 토큰이 다시 쓰이면 그 grant 전체를 무효화한다. CLI나 MCP 클라이언트 입장에서는 토큰을 조용히 갱신할 수 있지만, 운영자 입장에서는 유출된 리프레시 토큰이 반복 사용되는 상황을 더 빨리 끊을 수 있다는 뜻이다.

3) Dynamic Client Registration은 편의성 대신 노출면을 만든다

브라우저 기반 MCP 클라이언트들이 별도 사전 등록 없이 붙을 수 있게 하려면 DCR이 필요하다. Phoenix는 이를 위해 PHOENIX_OAUTH2_DYNAMIC_CLIENT_REGISTRATION을 disabled | local_only | enabled로 제어한다.

local_only: loopback / private-use scheme만 허용
enabled: HTTPS redirect URI도 허용
PHOENIX_OAUTH2_ALLOWED_REDIRECT_HOSTS: HTTPS redirect host allowlist로 범위 축소

즉, 기본 동작은 "붙기 쉬운 쪽"에 가깝고, 운영 환경에서는 어떤 클라이언트까지 허용할지 별도로 조여야 한다.

Remote MCP: Phoenix가 읽기용 데이터 허브를 넘어서는 지점

이번 릴리스가 단순 auth 기능 추가에 그치지 않는 이유는 /mcp가 같이 들어왔기 때문이다. Phoenix는 이제 추적/실험/프롬프트 데이터를 단순 REST API로만 노출하지 않고, MCP 클라이언트가 바로 붙을 수 있는 원격 도구 서버로도 동작한다.

기본 tool surface는 다음 다섯 가지 meta-tool 중심이다.

도구	역할
`search`	사용 가능한 작업을 의미 기반으로 찾음
`tags`	프로젝트/스팬/데이터셋 등 카테고리 탐색
`list_tools`	전체 작업 카탈로그 확인
`get_schema`	특정 작업의 파라미터 스키마 확인
`execute`	`call_tool(name, params)`를 조합해 Python으로 여러 호출을 묶음

핵심은 execute다. Phoenix는 model-written Python을 Monty 샌드박스에서 실행해, 여러 API 호출 결과를 서버 안에서 조합하게 만든다. 이 방식의 장점은 분명하다.

큰 JSON 응답을 IDE 컨텍스트 창으로 계속 밀어 넣지 않아도 된다.
여러 REST 호출을 에이전트가 서버 쪽에서 join/filter/aggregate할 수 있다.
MCP tool 폭발을 meta-tool + code mode로 눌러 토큰 비용을 줄일 수 있다.

하지만 tradeoff도 분명하다.

Monty는 파일시스템·네트워크·import가 없고 30초/100MB/50 call 제한이 있지만, 그래도 agent-written code를 서버 안에서 실행한다는 사실은 바뀌지 않는다.
그래서 Phoenix 문서도 PHOENIX_ENABLE_MCP_CODE_MODE=false로 code mode를 끄고 plain MCP tool 모드로 되돌릴 수 있게 했다.
게다가 이 릴리스의 grant-linked 토큰은 읽기 위주로 clamp되어 있다. 즉, Remote MCP는 지금 당장 "에이전트가 Phoenix를 수정하는 제어면"이라기보다, 트레이스와 평가 데이터를 읽고 분석하는 보조면에 더 가깝다.

이 제한은 오히려 운영자 입장에서는 장점일 수 있다. 브라우저 로그인 기반 MCP를 켜더라도, 첫 단계에서는 쓰기 자동화보다 관측·디버깅·실험 비교 용도로 안전하게 시작할 수 있기 때문이다.

가장 크게 깨지는 워크플로: API 키가 API 키를 발급하던 자동화

Phoenix 19에서 가장 실무적인 breaking change는 여기다.

시스템 키

시스템 API 키는 특정 사용자 개인이 아니라 시스템 전체를 대표하는 자격증명이다. 문서상 권장 용도도 REST API 호출, traces 전송, sidecar 배포 같은 비대화형 자동화다. 하지만 이제 시스템 키 발급은 다음 둘 중 하나로만 가능하다.

관리자 access-token session
PHOENIX_ADMIN_SECRET

기존 시스템 키로 다시 시스템 키를 찍어내는 흐름은 막혔다.

사용자 키

사용자 API 키는 해당 사용자 권한으로 동작하는 개인용 자격증명이다. 노트북에서 실험을 돌리거나 개인 스크립트에서 쓰는 데 적합하다. Phoenix 19에서는 사용자 키 발급도 로그인 세션이 필요하다. Phoenix 18까지 GraphQL 경로에 남아 있던 API-key-authenticated 발급 예외가 정리됐다.

그래서 어떻게 바꿔야 하나

기존 자동화	Phoenix 19 이후 권장 경로
기존 API 키로 새 키 발급	폐기
CI에서 최초 시스템 키 bootstrap	`PHOENIX_ADMIN_SECRET`로 한 번 발급 후 secret 제거
개발자 개인 실험용 키 생성	Settings UI 또는 로그인 세션 기반 스크립트
CLI/IDE의 읽기 접근	`px auth login` 또는 MCP 브라우저 로그인

PHOENIX_ADMIN_SECRET는 여전히 강력한 우회 경로이지만, 문서도 첫 시스템 키를 만든 뒤 제거하는 편을 권장한다. 즉, admin secret은 상시 운영 자격증명이 아니라 bootstrap 도구로 보는 편이 맞다.

배포와 보안: 운영자가 놓치기 쉬운 토글

Reverse proxy 뒤에 있다면 root URL을 먼저 맞춘다

OAuth issuer, discovery URL, MCP 401 challenge는 Host 헤더를 믿지 않고 PHOENIX_ROOT_URL을 기준으로 만들어진다. Phoenix를 서브패스로 노출한다면 PHOENIX_HOST_ROOT_PATH도 함께 맞춰야 한다.

PHOENIX_ROOT_URL=https://phoenix.example.com/observability
PHOENIX_HOST_ROOT_PATH=/observability

이 둘이 틀리면 로그인은 뜨는데 redirect가 꼬이거나, /mcp 인증 challenge가 엉뚱한 origin을 가리키는 식의 문제가 생긴다.

브라우저 로그인 자체가 싫다면 authorization server를 꺼야 한다

PHOENIX_ENABLE_OAUTH2_AUTHORIZATION_SERVER=false

이 경우 /oauth2/*와 authorization server discovery는 404가 되며, px auth login도 API 키 사용 경로로 안내된다. 이미 발급된 OAuth 토큰은 만료 시점까지는 살 수 있지만, 더 이상 refresh는 되지 않는다.

MCP는 켜되 code mode만 끄는 선택도 가능하다

PHOENIX_ENABLE_MCP_SERVER=true
PHOENIX_ENABLE_MCP_CODE_MODE=false

이 설정은 /mcp를 유지하면서도 execute와 Monty를 제거한다. 보안팀이 "agent-written code는 서버 안에서 절대 금지"라고 보는 환경이라면 가장 현실적인 타협안이다.

동적 등록 허용 범위를 좁혀야 한다

PHOENIX_OAUTH2_DYNAMIC_CLIENT_REGISTRATION=enabled
PHOENIX_OAUTH2_ALLOWED_REDIRECT_HOSTS=www.cursor.com

Cursor 같은 HTTPS callback 기반 클라이언트를 살리려면 enabled가 필요할 수 있다. 하지만 그대로 두면 HTTPS redirect host 범위가 넓어진다. 운영 환경에서는 allowlist를 같이 두는 편이 안전하다.

도입 전에 해볼 검증 체크리스트

[ ] /.well-known/oauth-authorization-server와 /.well-known/oauth-protected-resource가 기대한 PHOENIX_ROOT_URL 기준으로 노출되는지 확인한다.
[ ] px auth login → px auth status가 성공하고, 브라우저 로그인 후 토큰이 정상 갱신되는지 본다.
[ ] Claude Code나 Cursor에서 /mcp를 연결해 search와 list_tools가 동작하는지 확인한다.
[ ] PHOENIX_ENABLE_MCP_CODE_MODE=true일 때 execute가 실제로 30초/100MB/50 call 한도를 지키는지 테스트한다.
[ ] 기존 API 키로 system/user key 발급 API를 호출해 실패하는지 확인한다. 실패해야 정상이다.
[ ] 관리자 세션 또는 PHOENIX_ADMIN_SECRET로만 system key 발급이 되는지 검증한다.
[ ] reverse proxy 환경이라면 로그인 redirect, consent, logout, /mcp 401 challenge까지 서브패스가 맞는지 브라우저와 MCP Inspector 둘 다로 본다.
[ ] code mode를 켜는 경우, 서버에 남는 감사 로그와 grant revoke 경로(Authorized Applications / admin grant management)가 운영 절차에 포함됐는지 확인한다.

어디에 특히 잘 맞는가

이 릴리스는 다음 같은 팀에 특히 잘 맞는다.

Phoenix를 이미 쓰고 있고, 개발자가 Claude Code·Cursor 같은 도구에서 최근 실패 트레이스와 실험 결과를 직접 읽고 싶었던 팀
지금까지 개인 API 키를 IDE 설정 파일에 뿌리는 방식이 불편했던 팀
시스템 키와 사용자 키의 경계를 분리하고 싶었던 팀
MCP를 붙이되, 일단은 읽기 중심으로 시작하고 싶은 팀

반대로 아래 환경이라면 바로 기본값을 받아들이기보다 먼저 토글을 검토해야 한다.

모든 클라이언트가 비대화형 서비스 계정으로만 붙어야 하는 환경
agent-written code가 서버 안에서 단 1초도 돌면 안 되는 환경
reverse proxy / sub-path / custom origin이 복잡해 URL 정합성이 자주 깨지는 환경

Phoenix 19를 한 문장으로

Phoenix 19는 LLM 관측성 플랫폼에 OAuth2 authorization server와 Remote MCP를 붙여, 사람과 코딩 에이전트가 같은 데이터를 더 짧은 토큰으로 안전하게 읽게 만든 릴리스다. 대신 그 대가로, 예전처럼 API 키가 또 다른 API 키를 발급하는 느슨한 자동화는 더 이상 허용하지 않는다.

References

Phoenix v19.0.0 Release (GitHub): https://github.com/Arize-ai/phoenix/releases/tag/arize-phoenix-v19.0.0
Phoenix 19 release note — OAuth2 Authorization Server & Remote MCP (tagged docs): https://raw.githubusercontent.com/Arize-ai/phoenix/arize-phoenix-v19.0.0/docs/phoenix/release-notes/07-2026/07-17-2026-oauth2-authorization-server.mdx
Phoenix MIGRATION.md for v18 → v19 (tagged docs): https://raw.githubusercontent.com/Arize-ai/phoenix/arize-phoenix-v19.0.0/MIGRATION.md
Phoenix Remote MCP Server documentation (tagged docs): https://raw.githubusercontent.com/Arize-ai/phoenix/arize-phoenix-v19.0.0/docs/phoenix/integrations/remote-mcp.mdx
Phoenix Authentication documentation (tagged docs): https://raw.githubusercontent.com/Arize-ai/phoenix/arize-phoenix-v19.0.0/docs/phoenix/self-hosting/features/authentication.mdx
Phoenix API Keys documentation (tagged docs): https://raw.githubusercontent.com/Arize-ai/phoenix/arize-phoenix-v19.0.0/docs/phoenix/settings/api-keys.mdx
PR #14175 — feat(auth)!: add OAuth2 authorization server and CLI login: https://github.com/Arize-ai/phoenix/pull/14175