자체 호스팅 AI 게이트웨이 운영 — 살아 있는데 통째로 잘려나갑니다

사내에 AI 관문을 직접 세우기로 했다면, 그 순간부터 장애와 보안이 우리 몫이 됩니다. 공식 운영 문서를 읽다 보니 미리 알았으면 싶은 대목이 여럿이었어요. 가장 아찔한 건 저장소가 잠깐 멈췄을 때, 멀쩡히 답을 내줄 수 있는 서버까지 한꺼번에 빠져버리는 구성이 흔하다는 겁니다. 게다가 특정 한 사람만 로그아웃시키는 방법이 없고, 보안 수정도 저절로 오지 않습니다. 정리했습니다.

📌 30초 요약

• ★★저장소가 멈추면 멀쩡한 서버까지 통째로 빠집니다.
• 기존 로그인 사용자는 원래 계속 쓸 수 있었습니다.
• ★한 사람만 끊는 방법이 없습니다 — 갈면 전원이 끊깁니다.
• ⚠️ 지출 상한은 기본이 '막지 않고 통과'입니다.
• ★보안 수정도 우리가 갱신해야 도달합니다.
• 관문을 뺏기면 기기 관리 서버를 뺏긴 것과 같습니다.

살아 있는데 통째로 잘려나갑니다

관문은 저장소를 하나 옆에 두고 돕니다. 로그인 절차와 사용량 집계 같은 걸 거기에 담아요. 그런데 이 저장소가 잠깐 멈춰도 관문 자체는 꽤 멀쩡합니다 — 이미 로그인한 사람들은 계속 쓸 수 있어요. 발급된 증표는 서버가 자체적으로 검증하고, 갱신도 저장소를 안 건드리거든요.

문제는 "준비됐냐"고 묻는 점검 통로가 이때 "안 됐다"고 답한다는 겁니다. 요즘 배포 환경은 이 답을 보고 트래픽을 넣고 빼는데, 모든 복제본이 동시에 "안 됐다"고 하니 전부 한꺼번에 명단에서 빠집니다. 결과적으로 서버는 답할 수 있는데 앞단에서 전부 막혀 아무도 못 씁니다. 새 로그인만 실패했어야 할 상황이 전면 장애로 번지는 거예요.

🩺 점검 통로를 어디로 향하게 할까

문서가 해법을 알려줍니다. "준비됐냐"가 아니라 "살아 있냐"를 묻는 통로 쪽으로 배포 설정을 돌리면, 저장소가 멈춰도 돌아가는 서버는 명단에 남습니다. 참고로 살아 있냐 쪽은 장애 중에도 계속 통과하기 때문에 복제본이 재시작되지도 않아요. 어느 쪽을 볼지 배포 설정에 한 줄인데, 그 한 줄이 장애 범위를 가릅니다.

한 사람만 끊을 수가 없습니다

보안 사고가 나서 "저 사람 세션만 지금 끊어"라는 요구가 오면 곤란해집니다. 발급된 증표는 서버가 서명 비밀로 그 자리에서 검증하는 구조라, 개별로 취소하는 장치가 아예 없습니다.

강제로 끊는 유일한 길은 서명 비밀을 통째로 갈아버리는 것인데, 그러면 그 순간 모든 사람이 한꺼번에 로그아웃됩니다. 한 명 때문에 전원을 내보내는 셈이죠. 그래서 퇴사자 처리는 신원 관리 쪽에서 계정을 지우고 수명이 다하기를 기다리는 게 정석입니다. 즉시성이 필요한 규정이 있다면 세션 수명을 짧게 잡아두는 것으로 미리 대비해야 해요.

상황	실제로 벌어지는 일
저장소 장애	기존 사용자는 계속 쓸 수 있음 — 단 배포 설정에 따라 전면 차단
신원 서버 장애	세션 수명까지는 유지 — 새 로그인·갱신만 실패
서명 비밀 교체	옛것을 남겨두면 기존 세션 유지, 지우면 전원 로그아웃
판올림	순차 재시작 안전 — 스스로 구조 갱신을 수행
이전 판으로 되돌리기	새 설정 항목을 썼다면 부팅 실패 — 먼저 빼야

보안 수정도 우리가 챙겨야 옵니다

이건 도입 결재 전에 반드시 짚어야 할 대목입니다. 관문은 우리가 만든 이미지에 판을 고정해 돌립니다. 그러니 새 판에 들어간 수정은, 보안 수정이라 해도 우리가 고정을 바꿔 다시 배포해야만 닿습니다. 저절로 오지 않아요.

문서의 표현이 정확합니다 — 운영 자격증명을 쥐고 있는 다른 서비스와 같은 주기로 패치하라는 겁니다. 남이 굴려주는 서비스를 골라 쓰던 방식과는 성격이 완전히 다르죠. 편하게 쓰다가 서비스가 없어지는 걱정은 사라지지만, 대신 패치 주기를 우리가 지켜야 합니다.

관문을 뺏기면 기기 관리를 뺏긴 겁니다

문서가 위협 범위를 솔직하게 그어둡니다. 설계 전제는 "개발자 노트북은 신뢰하지 않는다"예요. 그래서 개발자는 상류 키 대신 수명 짧은 증표만 들고, 바깥으로 나가는 요청은 내부 주소로 우회당하지 않도록 한 번 더 걸러집니다.

반대로 범위 밖이라고 못 박은 것이 둘 있습니다. 하나는 관문 서버 자체가 털리는 경우 — 상류 자격증명도 거기 있고, 연결된 모든 개발자에게 정책이 내려가는 통로이기도 해서, 문서 표현대로 기기 관리 서버를 장악당한 것과 맞먹습니다. 다른 하나는 신원 공급자가 악의를 품는 경우고요. 둘 다 "당신 인프라를 지키는 건 당신 몫"이라고 선을 긋습니다. 관문을 세우는 조건을 볼 때 이 두 가지를 함께 계산하세요.

🔁 대기업이 같은 선택을 한 사례가 나왔습니다

삼성전자가 미스트랄과 반도체 특화 모델을 자체 환경에 구축하기로 한 건이 이 글의 상황과 겹칩니다. 공정 데이터는 어떤 계약을 써도 밖에 두기 어려운 자산이라, 애초에 밖의 서비스를 부르는 선택지가 없었습니다. 다만 안으로 들이는 순간 멈춤·갱신·장비 값이 전부 자기 몫이 되는 건 규모와 무관하게 똑같습니다. 삼성은 감수할 이유와 감당할 여력이 둘 다 있는 자리였을 뿐이고, 막연한 불안으로 따라가면 이 글이 다룬 운영 부담만 떠안게 됩니다.

자주 묻는 질문 (FAQ)

Q. 장애 중에 지출 상한은 어떻게 되나요?

기본값이 "막지 않고 통과"입니다. 상한을 세어두는 곳이 그 저장소라, 멈추면 집계 없이 요청이 그대로 흘러갑니다. 서비스가 안 끊기는 건 좋은데 그동안 쓴 금액은 상한에 안 잡힙니다. 예산이 엄격한 조직이라면 "세지 못하면 차라리 막아라"로 바꿔두세요. 참고로 상한을 아예 안 쓰면 그 저장소에 거의 아무것도 안 쌓이지만, 쓰는 순간부터는 잃으면 집계까지 잃으니 정기 백업이 필요합니다.

Q. 사무실에서 단체로 로그인이 막힙니다.

주소별 속도 제한에 걸린 겁니다. 로그인 절차에는 같은 주소에서 몰려오는 시도를 제한하는 장치가 있는데, 사무실 전체가 하나의 출구 주소로 나가면 여러 사람이 한 사람처럼 보입니다. 문서도 이 경우를 짚으며 제한을 올리라고 권해요. 다행히 이 제한은 로그인에만 걸리고 실제 대화에는 안 걸립니다.

Q. 우리 데이터가 밖으로 나가나요?

관문 자체는 우리가 정한 곳으로만 보냅니다. 사용량 기록·감사 기록·신원·정책은 우리가 지정한 목적지로만 가고, 대화 내용은 우리가 고른 상류로 갑니다. 로그인한 뒤에는 도구 자체의 사용 분석과 오류 보고도 꺼져요. 다만 완전히 0은 아닌데 — 로그인하기 전 시작 시점에는 일부 신호가 나가고, 개발자 기계는 주소 확인이나 판올림 확인 같은 요청을 여전히 보냅니다. 그것까지 막으려면 별도 설정 두 가지를 더 꺼야 합니다. 개인정보가 담긴 표도 하나 있어서, 퇴사자를 즉시 지우려면 그 줄을 직접 삭제하면 됩니다.

🧾 정직하게 밝혀둘 것

• 제가 운영해본 실측이 아닙니다. 공식 운영 문서의 장애 동작·위협 범위·규정 항목을 우리말로 정리했습니다.
• ★설정 항목 이름·통로 경로·표 이름·기본 보관 기간 수치는 옮기지 않았습니다. 실제로 구축할 때는 원문을 보세요.
• ★"점검 통로를 어디로 향하게 할지가 장애 범위를 가른다"는 제 정리이고, 문서는 두 통로의 동작과 대안을 밝힐 뿐입니다.
• 배포 환경마다 동작이 다릅니다. 여기 적은 건 준비 상태를 보고 트래픽을 조절하는 일반적인 구성 기준입니다.

✨ 정리하면

직접 굴리면 장애와 패치가 우리 몫이 됩니다. 가장 아까운 사고는 저장소가 멈췄을 때 멀쩡한 서버까지 앞단에서 통째로 빠지는 것 — 점검 통로를 어디로 향하게 하느냐로 갈립니다. 한 사람만 끊을 수 없고, 지출 상한은 기본이 통과이며, 보안 수정도 우리가 갱신해야 옵니다. 관문을 세우는 조건은 자체 호스팅 게이트웨이 정리, 개발자 쪽 증상은 게이트웨이 연결 문제, 남이 굴려주는 도구를 고르는 쪽은 무료 AI 코딩 도구 정리, 전체 비용 흐름은 AI 지출 관리 허브에 모아뒀습니다.

※ 출처: Claude apps gateway 배포·운영 공식 문서(2026년 8월 31일 열람). 기본값과 보관 정책은 판올림마다 달라질 수 있습니다.