Claude 자체 호스팅 신원 확인 — 이메일로 사람을 가리면 안 됩니다

AI 세션을 우리 회사 인프라에서 돌리면 사내 서비스를 바로 부를 수 있습니다. 그런데 받는 쪽 입장에선 이 요청이 정말 우리 환경의 세션에서 온 게 맞는지, 누가 만든 세션인지 확인할 방법이 있어야 하죠. 공식 문서를 열어보니 세션마다 서명된 신분증이 하나씩 붙어 옵니다. 문제는 이메일이 아예 안 올 수 있고, 한 세션이 유효한 표를 여러 장 낸다는 것. 그대로 짜면 조용히 틀립니다. 정리했습니다.

📌 30초 요약

• ★★이메일은 선택 항목입니다 — 아예 안 오는 세션이 있습니다.
• ★사람이 만들었는지 판정하는 법이 반대입니다 — 비었는지가 아니라 표시가 붙었는지로 봅니다.
• ★한 세션이 표를 여러 장 냅니다 — 갱신되면 값이 바뀝니다.
• ⚠️ 폐기 목록이 없습니다 — 만료 전까지는 계속 유효합니다.
• 대상 확인은 내 환경 번호로 — 기본값만 보면 아무 조직이나 통과합니다.
• 검증 없이 이름만 주는 통로가 따로 둘 있습니다.

세션마다 신분증이 하나씩 붙습니다

자체 호스팅에서는 세션이 우리 네트워크 안에서 돌아갑니다. 그래서 사내 서비스를 직접 부를 수 있는데, 받는 쪽은 그 요청을 믿을 근거가 필요하죠. 그 근거로 모든 세션에 서명된 신분증이 환경 값으로 하나 들어옵니다. 세션은 그걸 평범한 인증 정보처럼 내밀고, 받는 쪽은 공개된 열쇠 꾸러미로 서명을 확인합니다.

열쇠 꾸러미는 로그인 없이 누구나 받을 수 있는 주소에 올라와 있습니다. 다만 주기적으로 바뀌니 열쇠 하나를 코드에 박아두면 안 됩니다. 바뀐 뒤에도 예전 열쇠로 서명된 표가 살아 있도록 한동안 겹쳐 두기 때문에, 꾸러미째로 받아 캐시하는 쪽이 맞아요. 못 보던 열쇠 번호가 오면 한 번 다시 받아보고 나서 거절해야 합니다 — 교체 직후엔 캐시에 없는 새 열쇠로 서명된 표가 먼저 도착하거든요. 모델을 내 컴퓨터에 직접 올려 쓰는 쪽과 달리, 인프라만 우리 것이고 신원은 여전히 바깥에서 서명해준다는 점이 핵심입니다.

⚠️ 무엇을 증명하고, 무엇을 증명하지 않나

이 신분증이 증명하는 건 우리 환경의 특정 세션에 발급됐다는 것, 그리고 사람이 만든 세션인지 조직의 서비스 신원이 만든 세션인지까지입니다. 반대로 러너 안의 어느 프로그램이 그걸 들고 있는지는 증명하지 않습니다. 환경 값에 얹혀 있으니 세션이 실행하는 모든 코드와 세션이 띄운 연결 서버가 읽어서 그대로 내밀 수 있어요. 그래서 문서는 만든 사람이 직접 로그인한 것과 같게 취급하지 말라고 못을 박습니다.

남의 조직 표를 거르는 대목도 함정입니다. 대상 항목은 여러 값이 담긴 목록인데 기본값 하나가 늘 들어 있어요. 그걸 확인하면 어느 조직 표든 다 통과합니다. 반드시 우리 환경 번호가 그 목록에 들었는지를 봐야 하고, 이게 표를 우리 환경에 묶어주는 유일한 검사입니다. 앞머리도 먼저 걸러야 합니다 — 회사 인프라가 아닌 곳에서 도는 세션의 표는 앞머리가 다르고 서명 키 묶음도 달라서, 앞머리 확인 없이 넘기면 엉뚱한 꾸러미를 뒤지게 됩니다.

이메일로 사람을 가리면 안 됩니다

가장 실수하기 쉬운 부분입니다. 신분증에 만든 사람의 이메일이 실려 오긴 하는데, 그게 선택 항목이에요. 세션을 만든 요청의 자격 정보에 이메일이 붙어 있을 때만 기록되고, 명령줄에서 띄운 세션은 이메일이 아예 없을 수 있습니다. 조직의 서비스 신원이 만든 세션도 이메일을 안 담고요. 이메일을 열쇠 삼아 사내 사용자와 맞추는 코드는 어느 날 조용히 빈 값을 받습니다.

두 번째가 더 미묘합니다. 사람이 만든 세션인지 판정하는 방법이 직관과 반대예요. 흔히 "신원 항목이 비어 있으면 사람이 만든 게 아니다"로 짜는데, 문서는 그러지 말라고 합니다. 서비스 신원이 만든 세션은 항목이 비는 게 아니라 다른 표시가 앞에 붙어서 옵니다. 그러니 사람 표시가 붙었는지를 확인해서 통과시키는 쪽으로 짜야 합니다. 비었는지로 갈라놓으면 서비스가 만든 세션이 사람으로 둔갑해요.

사내 시스템의 계정과 이어붙일 때는 순서가 있습니다. 회사 로그인 공급자가 발급한 주체값이 있으면 그걸 1순위로 쓰라는 것 — 이메일보다 우선입니다. 그다음이 이메일, 마지막이 계정 번호예요. 신분증 안에는 만든 사람 → 세션을 띄운 러너 → 환경 → 환경 비밀을 만든 사람 순으로 위임 사슬이 안쪽으로 이어져 있고, 만든 사람이 가장 바깥이라 바로 읽힙니다. 예전 이름으로 남아 있는 납작한 항목 몇 개는 호환용 중복이라 없어질 수 있으니 그쪽을 읽으면 안 됩니다. 도구를 고를 때 회사 도입 조건까지 따져보는 관점이라면 이 매핑 규칙이 실제 도입 난이도를 좌우합니다.

한 세션이 표를 여러 장 냅니다

신분증에는 유효기간이 있습니다. 기본은 네 시간, 최대 여덟 시간이에요. 그런데 러너가 만료 전에 새 신분증을 받아 세션에 밀어 넣고, 그 뒤에 시작된 하위 프로그램은 새 값을 물려받습니다. 결과적으로 한 세션이 살아 있는 동안 서로 다른 유효한 표를 여러 장 내밀 수 있어요. 표 하나를 세션과 일대일로 묶어 캐시해두면 갱신 시점에 끊깁니다.

그리고 검증이 오프라인입니다. 서명만 맞으면 그 사이 세션에 무슨 일이 있었든 만료 전까지 계속 유효하고, 문서는 세션 신분증에 대한 폐기 목록을 따로 내주지 않는다고 명시합니다. 세션을 중간에 끊어도 이미 나간 표는 살아 있다는 뜻이죠.

✅ 그래서 바꿔주는 권한을 좁혀야 합니다

이 표를 받아 사내 자격으로 바꿔줄 때는 한 번의 코딩 세션이 닿아야 할 범위로만 좁히라는 게 문서의 권고입니다. 만든 사람이 회사에서 가진 관리 권한까지 그대로 주면 안 된다는 것. 수명도 표의 만료보다 짧거나 같게 묶고, 세션 번호와 표 고유번호를 만든 사람과 함께 기록해야 나중에 "이 작업이 어느 세션에서 나왔나"를 되짚을 수 있습니다. 세션이 무슨 일을 하고 있는지 흐름에서 읽어내는 방식과 짝을 지어 두면 기록이 훨씬 촘촘해집니다.

검증 없이 이름만 주는 통로가 있습니다

만든 사람의 정보는 신분증 말고 평문 환경 값으로도 두 군데 들어옵니다. 둘 다 서명을 확인하지 않는 통로라 용도가 다릅니다.

어디서 받나	확인 수준과 쓸 곳
세션이 생기기 전, 배정 쪽 훅	서명 직접 확인 안 함 — 어떤 기계 이미지를 고를지 같은 배정 판단에
세션 안, 준비 스크립트	이메일이 미리 뽑혀 옴 — 커밋 꼬리표 같은 라벨용
사내 서비스가 표를 직접 검증	서명·발급자·대상·역할·만료 전부 — 접근 허용 판단에

배정 쪽 훅이 서명을 안 보고도 믿는 데는 이유가 있습니다. 그 정보가 담긴 작업 지시가 환경 비밀로 인증된 연결을 타고 들어오기 때문이에요. 연결 자체가 신뢰의 근거라 지시서를 다시 검사하지 않는 구조입니다. 반대로 세션 안 준비 스크립트가 받는 이메일은 서명 확인 없이 미리 뽑아 놓은 값이라, 문서가 라벨용이지 통과 판단용이 아니라고 분명히 선을 긋습니다.

💡 간이 해독기는 절반만 봅니다

준비 스크립트가 굳이 표를 열어보고 싶으면 러너 실행 파일에 딸린 간이 해독 기능을 쓸 수 있습니다. 다만 서명과 만료만 확인하고 발급자·대상·역할 세 가지는 확인하지 않아요. 그 셋으로 통과를 가른다면 출력된 내용에서 직접 읽어 비교해야 합니다. 여기에 조용한 함정이 하나 더 — 값이 없을 때 오류로 끝나게 하는 옵션을 안 붙이면 "없음"이라는 글자가 그대로 찍히고 정상 종료돼서, 잘못된 값이 아무 소리 없이 아래로 흘러갑니다. 그리고 이름으로 찾은 실행 파일 대신 러너가 알려주는 실제 경로를 써야 러너와 같은 실행 파일에서 해독됩니다.

자주 묻는 질문 (FAQ)

Q. 유효기간이 지나면 세션이 끊기나요?

아니요. 러너가 만료 전에 새 값을 받아 세션에 밀어 넣습니다. 다만 새 값은 갱신 뒤에 시작된 프로그램만 물려받아요. 세션 내내 도는 프로그램이 처음 한 번 읽고 붙들고 있으면 낡은 표를 계속 내밀게 됩니다.

Q. 이메일이 안 오면 누구인지 알 방법이 없나요?

있습니다. 사람이 만든 세션이면 계정 번호는 항상 실려 옵니다. 회사 로그인 공급자의 주체값이 함께 오면 그게 1순위고요. 이메일은 있으면 쓰고 없으면 넘어가는 값으로 다뤄야 합니다.

Q. 열쇠 꾸러미를 매번 받아와야 하나요?

아니요. 문서가 캐시해 두고 오 분마다 다시 받는 정도면 안전하다고 명시합니다. 로그인 없이 열리는 공개 주소예요. 단, 캐시에 없는 열쇠 번호가 오면 한 번은 다시 받아본 뒤에 거절해야 합니다.

Q. 채널에서 자동으로 시작된 세션은 어떻게 보이나요?

조직의 서비스 신원이 만든 세션으로 옵니다. 사람 표시 대신 다른 표시가 붙고 이메일 계열 항목은 아예 빠져요. 사람 세션만 통과시키는 규칙을 걸었다면 이쪽이 자연스럽게 걸러집니다.

Q. 우리 조직 세션만 받으려면 뭘 봐야 하나요?

대상 목록에 우리 환경 번호가 들어 있는지를 확인하세요. 관리 화면의 환경 상세에서 볼 수 있습니다. 거기 늘 함께 들어 있는 기본값을 확인하면 아무 조직 표나 통과합니다.

✨ 정리하면

자체 호스팅의 신원 확인은 "표가 진짜인가"보다 "무엇을 안 증명하는가"가 핵심입니다. 세션 안 모든 코드가 이 표를 읽을 수 있고, 이메일은 없을 수 있고, 표는 도중에 바뀝니다. 계정 번호로 사람을 가리고, 권한은 한 세션 몫으로 좁히고, 세션 번호까지 남기세요. 비용과 권한을 함께 설계하는 흐름은 AI 지출 관리 허브에 단계별로 정리해 두었습니다.

출처: Claude Code 공식 문서 「자체 호스팅 환경의 세션 신원 확인」 (2026-08-31 열람). 자체 호스팅 환경은 공개 베타 단계이며 팀·기업 요금제에서 관리자가 켜야 씁니다. 세부 항목과 절차는 변경될 수 있습니다.