사내 Atlassian(Confluence·Jira·Bitbucket)을 MCP(Model Context Protocol)로 AI 클라이언트에 연결했다. API 호출을 MCP 도구로 제공하는 작업보다 사용자별 접근 권한을 그대로 유지하는 일이 더 중요하고 복잡했다.

통합 MCP 서버 포털 대시보드

사용자가 등록 상태·도구 접근 권한·개인 사용량을 확인하는 MCP 포털 대시보드.

문제 정의

전사형 MCP는 보통 MCP 서버 1개에 다수 사용자가 붙는 구조다. 그런데 Confluence/Jira/Bitbucket은 사용자마다 볼 수 있는 페이지·이슈·저장소가 다르다. 서버 하나가 모든 요청을 처리하면서 각 요청을 그 사람의 권한으로 호출하게 만들어야 한다.

이걸 제대로 하려면 세 가지가 필요하다.

  • 사용자 식별 — 이 요청이 누구의 것인가
  • 사용자 권한 반영 — 그 사람의 권한으로 Atlassian API를 호출
  • 자격증명 관리 — 토큰의 등록·저장·회수·유출 대응

토큰을 요청 파라미터로 넘기면 안 되는 이유

도구 호출 인자에 사용자 토큰을 포함하는 방식을 먼저 검토했다. 그러나 이 방식은 전사 구성원이 사용하는 서비스의 표준으로 적용하기 어려웠다.

보안 측면 — 사용자 토큰이 요청 파라미터로 다니면 로그·에러·컨텍스트에 섞여 노출될 경로가 생긴다.

기술 측면 — 많은 Data Center 커넥터 구현체는 토큰을 프로세스 환경변수나 서버 설정으로 받는다. 단일 서버 프로세스의 env/config는 기본적으로 공통이므로 요청마다 사용자 토큰을 적용하는 표준 메커니즘이 없다. 파라미터 방식을 사용하려면 서버에 다음 기능을 별도로 구현해야 한다.

  • 사용자 식별 및 세션 바인딩 (요청 주체 확정)
  • 토큰의 안전 취급 (저장 여부 결정, 저장 시 암호화)
  • 로그·에러·추적 경로에서 토큰 노출 방지 (마스킹/차단)
  • 동시 요청·재시도·캐시에서 사용자 토큰 혼입 방지 (분리 처리)

토큰을 파라미터로 넘기는 방식은 보안뿐 아니라 기술적으로도 추가 구현 없이는 표준이 되기 어렵다는 뜻이다.

운영 모델 선택지

사용자별 권한을 유지할 수 있는 운영 모델을 두 가지로 정리했다.

옵션 1) 사용자별 PAT 등록 + 서버 발급키

  • 사용자가 웹에서 PAT(Personal Access Token)를 등록
  • 서버는 PAT를 암호화 저장하고, 발급키(API Key)로 사용자를 식별
  • 요청 시 발급키 → 사용자 → PAT 매핑 후, 그 사용자의 권한으로 Atlassian API 호출

필요한 것: PAT 등록 UI, 암호화 저장소(Vault/Secrets Manager/암호화 DB), 발급키 발급·검증, 회수·회전·유출 대응 절차.

옵션 2) SSO 기반 사용자 식별 (권장)

  • SSO(OIDC/SAML)로 사용자 식별을 표준화
  • 권한 반영은 (2-1) SSO + 사용자별 PAT 매핑, 또는 (2-2) 위임/대리 호출(지원되는 경우)

식별을 SSO로 표준화하면 사용자가 키를 직접 들고 다니는 부담이 줄고 온보딩도 단순해진다.

SSO는 무엇으로?

현 환경을 반영해 후보를 추렸다.

  • Entra ID(Azure AD) — 인증 표준화와 접근 통제에 유리하지만 기존 Atlassian 권한 그룹과 세분화 수준이 다를 수 있음
  • Crowd — 실질 권한 관리 기준점이 Crowd라면 권한 체계 유지에 적합

현실적인 조합은 인증은 Entra ID로 두고 권한 관리는 Crowd/Atlassian 권한 모델을 유지하는 방향이었다. (Crowd 단독으로 OIDC/SAML IdP 역할을 할 수 있는지는 환경·구성에 따라 확인이 필요하다.)

전사 적용 전에 합의할 항목

전사 구성원이 사용하기 전에 다음 네 가지 운영 기준을 합의해야 한다.

  1. 사용자 식별 — SSO(OIDC/SAML)인가, 발급키인가
  2. 권한 반영 — 사용자별 PAT 매핑인가, 위임인가
  3. 자격증명 관리 — 등록·암호화 저장·회수·유출 대응
  4. 온보딩 — 사용자 등록 절차와 표준 클라이언트 설정 방식

돌아보며

MCP 도구를 제공하는 것만으로는 전사 서비스를 운영할 수 없다. 요청한 사용자의 기존 권한 범위를 넘지 않도록 기술적으로 강제하고, 자격증명의 전체 수명 주기를 관리해야 한다. 토큰을 요청 파라미터로 전달하는 방식은 구현이 단순해 보이지만 로그·오류·추적 데이터에 노출될 가능성이 있어 제외했다.

사내 자산을 AI 클라이언트에 연결할 때는 대상 시스템뿐 아니라 요청을 누구의 권한으로 실행할지 먼저 설계해야 한다.

참고