최근에는 Remote MCP Server만 만들고 있습니다.

이번에는 2026년 6월에 출시된 Claude Tag에서 Remote MCP Server를 사용할 때, 인증 관련하여 얻은 지식을 정리합니다.

TL;DR

• Claude Tag의 「인증 정보 (Credentials)」 탭은 허가된 웹사이트 접속에 사용하는 인증 정보를 관리하는 메커니즘
• Remote MCP의 접속 설정은 플러그인의 plugin.json을 통해 배포할 수 있음 - 플러그인에는 접속 대상 URL만 작성하면 됨. 인증 정보는 탭에서 별도로 관리할 수 있음 (플러그인에 시크릿을 포함할 필요가 없음)
• MCP 인증에 사용하는 토큰과, 그 너머의 서비스 인증에 사용하는 크리덴셜 (Credentials)은 분리하여 관리해야 함
• Bearer 인증 상태로는 개선의 여지가 있음 (인증 정보 탭은 OAuth 2.0에도 대응 완료)

구성

이번에 구축한 구성은 다음과 같습니다.

Claude Tag
└── Remote MCP 서버 (Lambda Function URL + Bearer 인증)
└── Backlog API (Backlog API key는 서버 측에 설정)

MCP 서버는 youyo/logvalet (Backlog용 CLI/MCP)를 AWS Lambda + Lambda Web Adapter로 호스팅하고 있습니다.

인증 정보 탭의 역할

Claude Tag의 설정 화면에는 「인증 정보」 탭이 있습니다 (「앱 연동하기」 다이얼로그). 여기에서는 다음과 같은 인증 정보 타입을 등록할 수 있습니다.

• Bearer
• Basic
• Body parameter
• AWS SigV4
• GCP access token / GCP IAP
• OAuth 2.0 JWT bearer / client credentials / authorization code

이것은 「허가된 웹사이트 접속에 사용하는 인증 정보를 관리하는 메커니즘」입니다.

MCP 접속 대상을 직접 지정하는 곳이 아니라, 「이 호스트에 접속할 때는 이 인증 정보를 사용한다」라는 규칙을 정의합니다. MCP 서버로의 접속 자체는 플러그인이 담당합니다.

Remote MCP의 접속 설정은 플러그인으로 배포할 수 있음

배포 메커니즘

플러그인 배포에는 Claude Team / Enterprise의 조직 플러그인 기능을 사용합니다.

• plugin.json을 포함한 플러그인을 GitHub 리포지토리에 push 함
• Claude의 조직 설정에서 해당 리포지토리를 GitHub 동기화 소스로 등록함
• Claude Tag의 플러그인 탭에 조직의 플러그인이 표시되며, 활성화할 수 있음

이 메커니즘을 활용함으로써 조직 내 멤버들에게 MCP 접속 설정을 일괄 배포할 수 있습니다.

plugin.json 작성법

mcpServers 필드에 접속 대상을 작성하기만 하면 됩니다. 파일은 plugins/{name}/.claude-plugin/plugin.json에 배치합니다.

{
"name": "for-claudetag",
"description": "Backlog MCP server connection for Claude Tag",
...

플러그인에는 접속 대상 URL만 작성하고, 인증 정보는 별도로 관리할 수 있습니다.

headers: { Authorization: "Bearer ${TOKEN}" }와 같이 작성하고 싶어지지만, 인증 정보 탭에 등록한 크리덴셜 (Credentials)이 동일 호스트로의 MCP 접속 시 적용되기 때문에 플러그인에 포함할 필요가 없습니다. 실제로 headers.Authorization 없이 접속을 시도해 본 결과, 정상적으로 동작함을 확인했습니다.

접속 대상(URL)과 인증 정보를 분리하여 관리할 때의 이점:

• 플러그인을 리포지토리로 공개해도 시크릿이 포함되지 않음
• 토큰의 로테이션 (Rotate)은 플러그인과 독립적으로 수행할 수 있음

활성화하면 플러그인 탭에 표시됩니다.

2층 구조의 인증을 분리해서 생각하기

Remote MCP 구성에서는 인증이 두 개의 레이어로 나뉩니다.

이 두 가지를 분리하는 것이 중요합니다. Claude Tag (클라이언트)가 가지는 것은 MCP의 Bearer Token뿐입니다. Backlog API key는 서버 측에 머무릅니다.

만약 동일한 값을 재사용하게 되면, 클라이언트가 Backlog의 자격 증명 (Credential)을 직접 보유하게 되어 서버 측에서의 관리가 의미가 없어집니다.

실질적으로 Claude Tag 전용 서버가 됨

Backlog API key가 서버 측에 고정 설정된다는 것은, 이 서버를 사용하는 누구나 '해당 Backlog 계정으로서' Backlog를 조작하게 된다는 것을 의미합니다. 즉, 이 서버는 실질적으로 Claude Tag 전용의 Backlog 연동 서버입니다.

MCP Bearer Token을 가진 모든 사람이 동일한 Backlog 사용자로 조작한다는 설계상의 전제가 깔려 있습니다.

Bearer 인증 상태로는 개선의 여지가 있음

현재의 MCP 인증은 정적 Bearer Token입니다. 정적 토큰은 만료시키는 메커니즘이 없어 유출 시 리스크가 있습니다.

인증 정보 탭에는 OAuth 2.0 선택지가 이미 존재합니다 (JWT bearer / client credentials / authorization code). 자격 증명 위생 (Credential hygiene) 관점에서는 수명이 짧은 토큰, 자동 갱신 (Refresh), 표준화된 만료 기능을 사용할 수 있는 OAuth 2.0이 더 우수합니다. MCP 서버 측에서 이를 지원한다면 더욱 안전한 구성을 할 수 있습니다.

현재의 Bearer 인증으로 운영할 경우에는 Bearer Token의 정기적인 로테이션 (Rotate)을 철저히 하는 것이 중요합니다.

요약

Claude Tag는 출시된 지 얼마 되지 않아 정보가 적지만, 인증 정보 탭과 플러그인을 조합함으로써 시크릿 (Secret)을 클라이언트에 보유하지 않고도 Remote MCP를 이용할 수 있습니다.

마지막으로 실제로 동작하는 모습입니다. Slack에서 Backlog의 이슈에 대해 질문하면, MCP를 통해 Claude Tag가 답변을 반환합니다.

Discussion