Sentry Admin은 왜 사라졌나

TL;DR Sentry에서 조직 Admin 역할을 신규로는 더 이상 부여할 수 없다. 팀 스코프의 Team Admin이 그 자리를 대체했다. 배경엔 “권한을 좁혀서 최소 범위로 준다”는 설계 방향이 있고, 이 방향은 UI 곳곳에 반영되어 있다 — 예를 들어 Integrations(조직 스코프)와 Alerts(프로젝트/팀 스코프)는 같은 “알림 관련”으로 보여도 접근 권한이 완전히 다르다. 핵심 열쇠는 프로젝트에 독립적인 권한 체계가 없다는 것 — 프로젝트 접근은 팀 소속으로만 결정된다.

배경

이전 글에서 Slack 통합을 붙이고 며칠 뒤, 프론트팀 리더(Owner 권한 보유)한테서 문의가 왔다.

“팀원 한 명에게 Admin 권한을 주려는데, Settings → Members에서 Admin 역할이 선택 자체가 안 돼요.”

처음엔 UI 버그로 의심했는데, 파고들어 보니 의도된 변경이었다. 그리고 이 변경이 단순한 UI 정리가 아니라 Sentry가 권한을 어떻게 바라보는지에 대한 설계 방향을 드러내고 있었다.

어떤 상황이었나

프론트팀 리더는 Owner 권한을 갖고 있었고, 팀원 한 명에게 관리 권한을 넘기고 싶어했다. 자연스럽게 Settings → Members로 가서 대상 계정의 역할을 Admin으로 바꾸려 했는데, Admin 항목이 아예 선택 불가 상태였다.

문서를 확인해봤더니 이건 버그가 아니라 정책이었다. Sentry 공식 문서는 Business·Enterprise 플랜에서 Org Admin 역할이 Team Admin으로 대체돼 신규 부여가 안 된다고 명시한다 — “This role can no longer be assigned.” 우리 self-hosted 인스턴스에서도 같은 동작이었고, 기존에 이미 Admin이던 계정만 그대로 유지된다.

개념 정리 — Sentry의 두 층 권한 모델

Sentry의 권한 구조는 이렇게 정리된다.

층	역할
조직 (전체 범위)	Owner / Manager / Member / Billing / (Admin, 레거시)
팀 (해당 팀 범위)	Team Admin
프로젝트	없음 (팀 소속을 통해서만 접근 결정)

핵심은 프로젝트에 독립적인 권한 체계가 없다는 것이다. “이 프로젝트에만 적용되는 admin”이라는 개념 자체가 Sentry에 없다. 프로젝트에 대한 권한은 그 프로젝트가 속한 팀의 소속으로만 결정된다.

Admin(레거시)이 신규 부여가 막힌 이유는 이 자리를 Team Admin이 대체하기 때문이다. 조직 전체에 걸친 관리자가 필요하면 Manager를, 특정 팀에 한정된 관리자가 필요하면 Team Admin을 쓴다.

층별 추적기

[1차] Admin 신규 부여 시도가 막혀 있다

Settings → Members에서 대상 계정의 역할을 Admin으로 바꾸려니 선택지 자체가 회색으로 잠겨 있음. 문서 확인 결과 의도된 변경.

같은 이름의 역할(Admin)이라도 스코프가 바뀌면 완전히 다른 것이 된다. 조직 Admin은 사라졌고, 그 이름은 이제 팀 스코프의 Team Admin으로만 이어진다.

[2차] Team Admin으로 대체

대안은 Team Admin. 팀 페이지(Teams → 해당 팀 → Members)에서 팀 단위로 부여한다. “이 팀의 관리자”이므로 다른 팀에는 영향이 없다.

Manager와의 차이는 스코프다. Manager는 조직 전체 관리자, Team Admin은 그 팀 안에서만 관리자. 지금 이 요청은 “특정 팀의 팀원이 그 팀 안에서 관리 권한을 갖는 것”이라 Team Admin이 맞는 그림이었다.

[3차] “이 프로젝트만” 스코프 요청은 어떻게 처리하는가

여기가 개념적으로 흥미로운 지점이다. 프로젝트에 독립 권한이 없으니 “이 프로젝트만 관리 권한”이라는 요청은 문자 그대로는 처리할 수 없다. 대신 팀 구조를 통해 표현한다.

팀이 그 프로젝트 하나만 갖고 있으면: Team Admin이 사실상 “그 프로젝트 전용 admin”이 된다. 우회로가 자연스럽게 성립.
팀이 여러 프로젝트를 갖고 있으면: Team Admin을 주는 순간 그 팀의 모든 프로젝트에 관리 권한이 생긴다. 프로젝트 단위로 격리하려면 해당 프로젝트만 소유하는 별도 팀을 새로 만드는 구조 변경이 필요.

팀이 어떤 프로젝트를 갖고 있는지 확인하는 곳: Settings → Teams → 해당 팀 → Projects 탭.

이번 케이스에서는 프론트팀의 Projects 탭에 <프로젝트> 하나만 소속되어 있음을 확인. Team Admin을 줘도 다른 프로젝트로 권한이 새지 않는다는 걸 확인하고 부여했다.

프로젝트에 독립 권한이 없다는 건 “권한을 좁힐 수 없다”가 아니라 “권한을 팀 구조로 표현하라”는 뜻이다. 프로젝트 하나만 소유한 팀을 만들면 사실상 프로젝트 전용 권한이 된다.

[4차 — 후속] Team Admin으로도 Integrations 페이지엔 못 들어간다

며칠 뒤 같은 팀원한테서 문의가 왔다. “Team Admin 받았는데 Settings → Integrations 페이지가 안 보여요. 알림도 팀 단위로 관리되는 건가요?”

확인해보니 두 개가 완전히 다른 스코프였다.

페이지	스코프	접근 권한
Settings → Integrations (Slack 워크스페이스 연결 자체 관리)	조직 전체	Owner / Manager
Alerts (Alert Rule에서 어느 채널로 보낼지 설정)	프로젝트/팀	Team Admin 이상

같은 “Slack 관련” 화면인데 스코프가 다르다. Integrations는 조직이 어떤 외부 서비스를 연결할지 자체를 다루므로 조직 관리자가, Alerts는 이미 연결된 것을 어떻게 활용할지를 다루므로 팀 관리자가 처리한다.

“Slack 알림” 하나 다루는 데도 두 스코프가 섞인다 — 워크스페이스 연결 자체(조직) vs 그 워크스페이스를 어떻게 사용할지(프로젝트/팀). 문의 받았을 때 어느 쪽 얘기인지부터 구분하지 않으면 엉뚱한 곳에서 헤맨다.

정리

요청 유형별로 어느 층에서 처리하는지 한 번에 정리하면 이렇다.

요청	처리 층	필요 권한
조직 전체 관리	조직	Manager (Admin 신규 부여 불가)
특정 팀 안에서만 관리	팀	Team Admin
“이 프로젝트만” 관리	팀 구조 확인 후 결정	Team Admin (팀이 그 프로젝트만 소유해야 안전)
Slack 워크스페이스 연결 자체	조직 (Integrations)	Owner / Manager
Alert Rule 관리 (채널·조건 등)	프로젝트/팀 (Alerts)	Team Admin

문의는 늘 “권한 좀 주세요”라는 한 문장으로 오지만, 실제로는 이 표의 어느 행인지부터 구분해야 정확한 응답이 나온다.

최종 결정 (실제 케이스)

프론트팀 Projects 탭 확인 → <프로젝트> 하나만 소속
팀원에게 Team Admin 부여 → 사실상 그 프로젝트 전용 관리자와 동일한 효과
안내: 앞으로 이 팀에 다른 프로젝트가 추가되면, 그 시점부터 이 Team Admin들이 새 프로젝트에도 자동으로 권한을 갖게 된다. 팀에 프로젝트 추가할 때마다 이 점 재검토 필요.
Integrations 자체 관리는 여전히 Owner/Manager가 처리하고, Alert Rule은 Team Admin으로 충분하다는 것도 함께 안내.

권한 요청 받았을 때 순서

같은 유형의 요청을 받을 때, 다음 순서를 밟으면 대부분의 헛발질이 앞단에서 걸러진다.

“조직 전체가 필요한가, 팀/프로젝트 한정이면 되는가”부터 확인한다. 조직 전체면 Manager, 팀/프로젝트 한정이면 Team Admin.
“이 프로젝트만” 요청이면 팀 구조부터 확인한다 (Teams → 해당 팀 → Projects 탭). 팀이 그 프로젝트만 소유하면 Team Admin 안전, 여러 개 소유면 새 팀을 만들거나 요청 자체를 재조정.
Team Admin 부여 후 그 팀에 프로젝트가 추가될 때마다 재검토한다. 팀 소속이 확장되면 자동으로 권한도 확장된다는 사실을 인수인계 문서에 명시.
“권한이 없다” 문의 오면 Integrations인지 Alerts인지 먼저 구분한다. 둘은 완전히 다른 스코프.
가능한 한 좁은 범위(Team Admin)로 준다. 필요할 때 넓히는 게, 넓게 줬다 좁히는 것보다 훨씬 쉽다.

참고

환경: Sentry self-hosted (Docker Compose) · 내부망 전용 도메인
관련 문서: Sentry Membership · Team-level Roles
선행 글: 이 이슈는 Slack 통합 편에서 파생된 후속. Slack 통합을 붙인 뒤 팀 리더가 팀원에게 관리 권한을 넘기려다 발견한 케이스.