오픈AI, 챗GPT 플러그인 다중 계정 지원

개발자가 손볼 것은 원칙적으로 없어요. 슈토이버는 같은 글에서 "개발자 여러분, 이건 아무것도 바꾸지 않아도 자동으로 동작합니다" 라고 밝혔어요. 이미 돌아가는 MCP 서버는 그대로 두면 다중 계정이 붙어요.

대신 화면에 뜨는 이름표를 제대로 달려면 프로필 툴을 하나 더 열어야 해요. 인증된 자격증명이 가리키는 프로필을 돌려주는 읽기 전용 도구인데, 이름은 get_profile 이든 whoami 든 자유예요. 메타데이터에 _meta 의 openai/profile 값을 true 로 선언해 두면 오픈AI가 실행 중에 그 도구를 찾아 부르고, 응답을 검증한 뒤에 프로필 정보를 써요.

계약의 핵심은 id 한 칸이에요. 비어 있지 않은 문자열이어야 하고, 토큰이 갱신되거나 연결을 다시 맺거나 권한 범위를 올려도 같은 값이 나와야 해요. 서로 다른 프로필은 서로 다른 값을 가져야 하고, 표시 이름이나 이메일이 바뀌어도 값은 그대로여야 해요. 한 번 지운 프로필의 값을 다른 프로필에 다시 붙이는 것도 금지예요. 로그인마다, 토큰마다, 세션마다, 도구 호출마다 새 값을 만들지 말라는 문장이 문서에 따로 적혀 있어요.

이메일을 식별자로 쓰는 흔한 습관도 막았어요. 바뀌거나 다른 사람에게 넘어갈 수 있는 주소는 안정된 프로필 식별자가 될 수 없다는 이유예요. 구글 OIDC 를 쓰면 email 클레임 대신 sub 를 쓰라고 못 박았어요. 이름과 이메일은 name, email, nickname 같은 표시용 칸에 담고, 식별자 안에 이름이나 이메일, 조직 관계를 인코딩하지 말라고도 했어요.

응답은 structuredContent 에 담아 outputSchema 로 검증받고, 호환을 위해 같은 내용을 JSON 문자열로 text 콘텐츠에도 넣어요. 문서는 Moonwaffle 이라는 가상의 서비스를 예로 들어 한 사람이 두 프로필을 따로 연결한 상황을 보여 줘요. 개인 프로필은 prf_42a9c6e0, 업무 프로필은 prf_8d7e4b19 처럼 서로 다른 불투명한 값을 한 번 만들어 저장해 두고, 재연결과 토큰 갱신, 표시 이름 변경을 건너도 같은 값을 돌려줘요.

프로필 툴 없이도 계정은 붙어요. 다만 계정 라벨과 재인식, 중복 감지의 신뢰도가 떨어진다고 문서가 적었어요. 선언해 놓고 잘못된 신원을 돌려주면 계정 연결 자체가 막힐 수 있다는 경고도 함께 있어요.

메탈이 확인한 오픈AI 개발자 문서는 다중 계정 항목 바로 앞에 클라이언트 신원을 길게 다뤄요. 챗GPT는 MCP 서버에 연결할 때 오픈AI가 관리하는 클라이언트 인증서를 제시하고, 서버는 리프 인증서가 오픈AI 커넥터 mTLS 중간 CA 로 이어지는지와 SAN dnsName 이 mtls.prod.connectors.openai.com 인지를 확인하면 돼요. 클라이언트 등록은 CIMD 를 권장하고 DCR 도 계속 받는데, 챗GPT는 클라이언트 자격증명이나 서비스 계정, JWT bearer 어서션 같은 기계 대 기계 인증은 지원하지 않아요.

엔지니어 입장에서 이번 변화의 무게는 편의가 아니라 경계에 있어요. 계정이 하나였을 때는 토큰 하나가 곧 권한 하나였는데, 이제 한 대화 안에 서로 다른 권한을 가진 토큰이 여러 개 떠 있고 어느 것을 쓸지 고르는 주체가 모델이에요. 문서가 도구를 읽기 전용으로 만들라고, 호출자에게 사용자 ID나 이메일이나 계정 선택자를 요구하지 말라고, 인증 실패 때 자리표시용 ID나 다른 계정의 프로필을 돌려주지 말라고 세 줄에 걸쳐 못 박은 이유가 여기 있어요. 잘못 묶인 프로필 하나가 회사 워크스페이스의 문서를 개인 계정 쪽 대화로 끌어오는 사고가 돼요.

책임의 위치도 분명해요. 오픈AI는 OAuth 흐름이 끝나면 받은 액세스 토큰을 그대로 MCP 요청에 붙이고, 그다음 서명 검증과 발급자·대상 확인, 만료 처리, 재생 공격 고려, 스코프 집행은 전부 서버의 몫이라고 적었어요. 스키마 검사를 통과했다고 해서 식별자의 고유성이나 안정성, 자격증명 범위가 증명되는 것은 아니라는 문장도 같이 있어요.

메탈은 챗GPT가 앱 디렉터리에서 런웨이와 블렌더를 직접 돌린 일을 보도한 바 있으며, 그때 확인한 흐름이 계정 한 개를 전제로 한 연결이었어요. 이번에 붙은 다중 계정은 그 연결을 여러 갈래로 늘린 셈이에요.

플러그인 생태계의 경쟁축이 기능에서 신원으로 옮겨 가고 있어요. 어떤 도구를 제공하느냐만큼, 그 도구가 어느 계정의 권한으로 도는지를 서버가 얼마나 정확하게 말할 수 있느냐가 연결의 품질을 정해요. 이름표를 제대로 다는 일이 이제 제품 기능이에요.