AI 게이트웨이를 공개할 때 먼저 정할 것은 서버를 얼마나 더 늘릴지가 아니라 어떤 환경을 신뢰할 것인지다. 권장 구조는 게이트웨이와 상위 서비스 자격 증명을 신뢰할 수 있는 VPS에 두고, 기존 업무 백엔드가 외부 요청을 받아 게이트웨이로 전달하는 방식이다.

신뢰할 수 없는 개발 서버에는 제한된 개발 권한만 제공하고, 위챗 미니 프로그램에는 게이트웨이 자체가 아니라 특정 업무 기능만 열어 준다. 이 구성은 처음부터 로드밸런서나 서비스 메시를 추가하지 않고도 접근 경계를 나눌 수 있다. 다만 지연 시간이 전혀 늘지 않는다고 보장할 수는 없다.

먼저 확인할 코드상의 보안 공백

현재 코드 상태만으로는 게이트웨이가 안전하게 보호된다고 보기 어렵다.

• main.go의 시작 설정은 모든 네트워크 인터페이스에서 요청을 받을 수 있다. 신뢰할 수 있는 VPS에서만 쓴다면 게이트웨이가 외부에 직접 노출되지 않도록 로컬 주소에 명시적으로 바인딩하는 편이 낫다.
• internal/api/chat.go의 기본 라우트에는 호출자 인증이 연결되지 않은 상태에서 모델 목록, 통계, 채팅 경로 등이 등록돼 있다. 클라이언트가 키를 입력할 수 있다는 사실만으로 인증이 적용된 것은 아니다.
• 기존 인증 미들웨어는 Gin을 대상으로 하지만 현재 시작 경로는 표준 HTTP 라우팅을 사용한다. 확인된 메인 라우트에는 해당 미들웨어가 호출되지 않는다. middlewares/auth.go, main.go
• 기존 접근 제어 설정은 로컬 시험용이며, 클라이언트별 한도가 0이어야 한다고 명시돼 있다. 이를 여러 사용자를 위한 운영용 제한 기능으로 간주해서는 안 된다. internal/chatadmission/config.go, internal/chatadmission/config.go

따라서 기존 환경 변수만 설정하거나 클라이언트에 키 입력란을 추가하는 것으로는 보호가 끝나지 않는다. 실제 요청이 지나는 경로에서 인증과 권한 제한이 작동하는지 확인해야 한다.

신뢰할 수 없는 개발 서버에는 ‘원격 호출’만 허용

개발용 연결은 다음처럼 구성할 수 있다.

개발 VPS → HTTPS 제한 개발 API(신뢰할 수 있는 업무 백엔드) → 사설 연결 → 게이트웨이(신뢰할 수 있는 VPS)

소스 코드와 빌드 과정, 게이트웨이 실행 인스턴스, 상위 서비스 자격 증명은 신뢰할 수 있는 환경에 남긴다. 개발 VPS에는 호출 주소와 개발 전용 권한만 제공한다.

개발 API는 필요한 메서드와 경로, 모델만 허용하고 통계·관리 기능이나 임의 요청 전달은 차단한다. 개발 환경마다 별도의 자격 증명을 발급해 쉽게 취소할 수 있게 하고, 모델 허용 목록과 요청 크기, 동시 호출 수, 누적 사용 예산을 함께 제한한다. 이 자격 증명은 정식 서비스용 권한과 분리해야 한다. 인증 확인과 예산 차감도 반드시 신뢰할 수 있는 백엔드에서 처리한다.

여기에는 피할 수 없는 한계가 있다. 호스트 관리자까지 신뢰할 수 없는 환경이라면 그 서버 안의 자격 증명과 요청·응답은 읽히거나 변조될 수 있다고 봐야 한다. 짧은 만료 시간은 유출 가능성을 없애지 않는다. 다만 유출됐을 때 권한을 취소하고 피해 규모를 제한하는 데 도움이 된다. 일반 컨테이너나 바이너리 배포, 코드 난독화만으로 호스트 관리자로부터 비밀을 지킬 수 있다고 보장할 수는 없다.

목표는 유출 불가능한 마스터 키를 개발 서버에 감추는 것이 아니다. 마스터 키가 그 서버에 들어가지 않게 하고, 개발용 권한이 유출돼도 취소할 수 있으며 손실에 상한이 있도록 설계하는 것이다. 민감한 개발 작업은 신뢰할 수 있는 환경에 남겨야 한다.

인증이 없는 현재 게이트웨이에 SSH 터널만 연결하는 방식도 권장하기 어렵다. 터널 접근 권한이 탈취되면 제한을 우회할 수 있기 때문이다. 터널을 써야 한다면 원래 게이트웨이나 다른 사설 서비스가 아니라 제한된 개발 API에만 도달하도록 해야 한다.

미니 프로그램에는 범용 게이트웨이 대신 업무 기능을 공개

위챗 미니 프로그램은 다음 경로로 연결하는 편이 적절하다.

위챗 미니 프로그램 → 기존 업무 백엔드(로그인·사용량 한도·Agent) → 사설 연결 → 게이트웨이 → 상위 모델

위챗 로그인 흐름에서는 클라이언트가 임시 로그인 코드(code)를 받아 서버로 보내고, 서버가 이를 사용자 식별 정보와 교환한 뒤 자체 로그인 상태를 발급할 수 있다. 세션 키는 클라이언트로 내려보내지 않아야 한다.9

미니 프로그램은 직무 설명과 요구 사항, 필요한 경력 정보만 업무 백엔드에 보낸다. 게이트웨이의 마스터 키를 보유하거나 임의의 모델·시스템 프롬프트·도구를 선택하는 구조는 피한다. 대신 백엔드에 ‘개인 강점 다듬기’ 같은 업무용 API를 두고, 사용할 모델 후보와 프롬프트 템플릿, 검색 기능, 출력 형식을 서버에서 정한다. 제한 없는 채팅 프록시로 요청을 그대로 전달해서는 안 된다.

사용자 식별은 요청 본문에 적힌 사용자 ID가 아니라 백엔드가 검증한 로그인 상태를 기준으로 해야 한다. 사용자별 작업·대화 문맥·사용량을 분리해 다른 사용자의 기록이 섞이지 않도록 한다.

무료 체험이라도 사용 한도는 필요하다. 사용자별 호출량과 작업별 모델·도구 호출 횟수, 입력·출력 길이를 제한하고, 전체 체험 예산과 긴급 중단 기능도 둔다. 여러 단계로 동작하는 Agent 역시 같은 작업 예산을 공유해야 한다. 취소, 시간 초과, 재시도까지 제한에 포함해 반복 작업이 호출량을 무한히 늘리지 않도록 한다.

백엔드가 여러 작업 프로세스로 실행된다면 기존 데이터베이스의 트랜잭션 기능을 이용해 예산을 통합 관리해야 한다. 각 프로세스가 별도로 한도를 계산하면 전체 예산을 초과할 수 있다.

미니 프로그램은 기존 HTTPS 업무 도메인을 계속 사용할 수 있다. 위챗은 미니 프로그램의 일반 네트워크 통신에 허용 도메인을 사전에 설정하도록 안내한다. 따라서 미니 프로그램에 게이트웨이 도메인을 직접 공개할 필요는 없다.7

사설 연결은 기존 SSH 터널부터 활용

백엔드와 게이트웨이가 같은 신뢰 호스트에 있다면 로컬 연결을 우선한다. 서로 다른 신뢰 호스트에 있다면 첫 단계에서는 이미 운영 중인 상시 SSH 터널을 재사용할 수 있다. 요청이 올 때마다 새 터널을 만드는 방식은 피한다.

SSH에는 포트 포워딩 전용 계정을 사용하고 연결 가능한 목적지 포트를 제한한다. 게이트웨이는 로컬 주소에 바인딩하고, 터널이 끊기면 보호되지 않은 공개 주소로 우회하지 말고 호출을 거부해야 한다. 비어 있는 호출 키는 내부 연결이 통제돼 있고 해당 호스트의 다른 프로세스도 신뢰할 수 있는 경우에만 고려할 수 있다. 신뢰할 수 없는 환경을 향한 모든 진입점은 별도의 유효한 자격 증명을 실제로 검증해야 한다.

현재 터널이 성능 병목이라는 측정 결과가 있을 때만, 신뢰할 수 있는 두 호스트 사이에 WireGuard를 검토하면 된다. WireGuard는 피어의 키를 바탕으로 인증과 암호화를 제공하지만, 사용한다고 해서 현재 연결보다 반드시 빨라지는 것은 아니다.1216

별도의 제3자 중계 서비스를 추가하거나 역방향 프록시를 한 겹 더 구축하는 것이 첫 단계일 필요는 없다. 업무 백엔드에서 연결을 재사용하고 스트리밍 응답을 제때 전달하며, 미니 프로그램의 연결이 끊기면 실행 중인 작업에도 취소를 전달하는 것이 중요하다.

실제 추가 지연 시간은 현재 정보만으로 판단하기 어렵다. 백엔드에서 게이트웨이까지의 네트워크 시간, 첫 출력이 도착할 때까지의 시간, 전체 작업 완료 시간을 따로 측정하고 중앙값과 상위 지연 구간을 비교해야 한다. 중국 본토에서 게이트웨이와 상위 서비스까지의 실제 네트워크 경로도 별도로 확인해야 한다.

모델 이름만 보고 ‘빠른 모델’이라고 판단해서도 안 된다. 현재 후보 테스트는 사전 설정이 여전히 깊은 추론 모드와 상세 출력을 요구하며, 실제 상위 서비스의 가용성이나 지연 시간을 입증하지 않는다고 명시돼 있다. internal/upstream/studioglobal/registry_fast_models_test.go, internal/upstream/studioglobal/registry_fast_models_test.go 기존 개발용 설정을 바로 바꾸기보다, 개인 강점 다듬기 기능을 위한 가벼운 설정을 따로 만들고 실제로 측정하는 편이 안전하다.

최소 구현 순서와 확인 항목

1. 게이트웨이가 외부에 직접 노출되지 않도록 바인딩을 제한하고, 인터넷과 신뢰할 수 없는 개발 서버에서 백엔드를 우회해 접근할 수 없는지 확인한다.
2. 업무 백엔드에서 개발용 제한 호출과 미니 프로그램용 공개 업무 호출을 별도의 권한 영역으로 나눈다. 자격 증명과 예산도 각각 관리한다.
3. Agent 작업에 호출 한도와 취소 전파, 스트리밍 출력을 적용하고 전체 사용 예산의 상한을 둔다.
4. 자격 증명이 없거나 취소된 요청이 거부되는지, 개발 권한으로 관리 경로에 접근할 수 없는지, 한도 소진 후 호출이 중단되는지 확인한다. 사용자 간 문맥 분리와 다단계 호출·재시도 시 작업 예산이 지켜지는지도 점검한다.
5. 소규모로 공개해 지연 시간을 측정한 뒤, 사설 전송 방식을 바꾸거나 인스턴스를 분리할지 결정한다.

첫 단계에서 제외할 것과 공개 전 확인할 점

이 제안은 아키텍처 권고이며, 실제 보안 배포가 검증됐다는 뜻은 아니다. 여기서 코드를 수정하거나 테스트를 실행한 것도 아니다. 첫 단계에서는 로드밸런서와 서비스 메시, 상시 운영하는 Agent 플랫폼을 새로 구축하지 않는다. 대신 단일 인스턴스의 장애와 용량 한계를 감수하는 선택이다.

상위 서비스가 공개 체험을 허용하는지, 개인 경력 정보가 실제로 어디까지 전달되는지, 관련 규정상 어떤 요건이 적용되는지는 제공된 근거만으로 확인할 수 없다. 공개 전에 확인해야 하며, 사용자에게 필요한 최소한의 정보만 요청하고 이력서 전체 내용이나 자격 증명은 기록하지 않는 것이 바람직하다.

결론은 간단하다. 소스 코드와 마스터 자격 증명은 신뢰할 수 있는 환경에 두고, 개발 서버에는 제한 권한을, 미니 프로그램에는 업무 기능을 제공한다. 인프라 계층을 먼저 늘리기보다 실제 인증과 예산, 작업 경계를 갖추는 일이 우선이다.

AI 게이트웨이를 공개할 때 먼저 정할 것은 서버를 얼마나 더 늘릴지가 아니라 어떤 환경을 신뢰할 것인지다. 권장 구조는 게이트웨이와 상위 서비스 자격 증명을 신뢰할 수 있는 VPS에 두고, 기존 업무 백엔드가 외부 요청을 받아 게이트웨이로 전달하는 방식이다.

신뢰할 수 없는 개발 서버에는 제한된 개발 권한만 제공하고, 위챗 미니 프로그램에는 게이트웨이 자체가 아니라 특정 업무 기능만 열어 준다. 이 구성은 처음부터 로드밸런서나 서비스 메시를 추가하지 않고도 접근 경계를 나눌 수 있다. 다만 지연 시간이 전혀 늘지 않는다고 보장할 수는 없다.

먼저 확인할 코드상의 보안 공백

현재 코드 상태만으로는 게이트웨이가 안전하게 보호된다고 보기 어렵다.

• main.go의 시작 설정은 모든 네트워크 인터페이스에서 요청을 받을 수 있다. 신뢰할 수 있는 VPS에서만 쓴다면 게이트웨이가 외부에 직접 노출되지 않도록 로컬 주소에 명시적으로 바인딩하는 편이 낫다.
• internal/api/chat.go의 기본 라우트에는 호출자 인증이 연결되지 않은 상태에서 모델 목록, 통계, 채팅 경로 등이 등록돼 있다. 클라이언트가 키를 입력할 수 있다는 사실만으로 인증이 적용된 것은 아니다.
• 기존 인증 미들웨어는 Gin을 대상으로 하지만 현재 시작 경로는 표준 HTTP 라우팅을 사용한다. 확인된 메인 라우트에는 해당 미들웨어가 호출되지 않는다. middlewares/auth.go, main.go
• 기존 접근 제어 설정은 로컬 시험용이며, 클라이언트별 한도가 0이어야 한다고 명시돼 있다. 이를 여러 사용자를 위한 운영용 제한 기능으로 간주해서는 안 된다. internal/chatadmission/config.go, internal/chatadmission/config.go

따라서 기존 환경 변수만 설정하거나 클라이언트에 키 입력란을 추가하는 것으로는 보호가 끝나지 않는다. 실제 요청이 지나는 경로에서 인증과 권한 제한이 작동하는지 확인해야 한다.

신뢰할 수 없는 개발 서버에는 ‘원격 호출’만 허용

개발용 연결은 다음처럼 구성할 수 있다.

개발 VPS → HTTPS 제한 개발 API(신뢰할 수 있는 업무 백엔드) → 사설 연결 → 게이트웨이(신뢰할 수 있는 VPS)

소스 코드와 빌드 과정, 게이트웨이 실행 인스턴스, 상위 서비스 자격 증명은 신뢰할 수 있는 환경에 남긴다. 개발 VPS에는 호출 주소와 개발 전용 권한만 제공한다.

개발 API는 필요한 메서드와 경로, 모델만 허용하고 통계·관리 기능이나 임의 요청 전달은 차단한다. 개발 환경마다 별도의 자격 증명을 발급해 쉽게 취소할 수 있게 하고, 모델 허용 목록과 요청 크기, 동시 호출 수, 누적 사용 예산을 함께 제한한다. 이 자격 증명은 정식 서비스용 권한과 분리해야 한다. 인증 확인과 예산 차감도 반드시 신뢰할 수 있는 백엔드에서 처리한다.

여기에는 피할 수 없는 한계가 있다. 호스트 관리자까지 신뢰할 수 없는 환경이라면 그 서버 안의 자격 증명과 요청·응답은 읽히거나 변조될 수 있다고 봐야 한다. 짧은 만료 시간은 유출 가능성을 없애지 않는다. 다만 유출됐을 때 권한을 취소하고 피해 규모를 제한하는 데 도움이 된다. 일반 컨테이너나 바이너리 배포, 코드 난독화만으로 호스트 관리자로부터 비밀을 지킬 수 있다고 보장할 수는 없다.

목표는 유출 불가능한 마스터 키를 개발 서버에 감추는 것이 아니다. 마스터 키가 그 서버에 들어가지 않게 하고, 개발용 권한이 유출돼도 취소할 수 있으며 손실에 상한이 있도록 설계하는 것이다. 민감한 개발 작업은 신뢰할 수 있는 환경에 남겨야 한다.

인증이 없는 현재 게이트웨이에 SSH 터널만 연결하는 방식도 권장하기 어렵다. 터널 접근 권한이 탈취되면 제한을 우회할 수 있기 때문이다. 터널을 써야 한다면 원래 게이트웨이나 다른 사설 서비스가 아니라 제한된 개발 API에만 도달하도록 해야 한다.

미니 프로그램에는 범용 게이트웨이 대신 업무 기능을 공개

위챗 미니 프로그램은 다음 경로로 연결하는 편이 적절하다.

위챗 미니 프로그램 → 기존 업무 백엔드(로그인·사용량 한도·Agent) → 사설 연결 → 게이트웨이 → 상위 모델

위챗 로그인 흐름에서는 클라이언트가 임시 로그인 코드(code)를 받아 서버로 보내고, 서버가 이를 사용자 식별 정보와 교환한 뒤 자체 로그인 상태를 발급할 수 있다. 세션 키는 클라이언트로 내려보내지 않아야 한다.9

미니 프로그램은 직무 설명과 요구 사항, 필요한 경력 정보만 업무 백엔드에 보낸다. 게이트웨이의 마스터 키를 보유하거나 임의의 모델·시스템 프롬프트·도구를 선택하는 구조는 피한다. 대신 백엔드에 ‘개인 강점 다듬기’ 같은 업무용 API를 두고, 사용할 모델 후보와 프롬프트 템플릿, 검색 기능, 출력 형식을 서버에서 정한다. 제한 없는 채팅 프록시로 요청을 그대로 전달해서는 안 된다.

사용자 식별은 요청 본문에 적힌 사용자 ID가 아니라 백엔드가 검증한 로그인 상태를 기준으로 해야 한다. 사용자별 작업·대화 문맥·사용량을 분리해 다른 사용자의 기록이 섞이지 않도록 한다.

무료 체험이라도 사용 한도는 필요하다. 사용자별 호출량과 작업별 모델·도구 호출 횟수, 입력·출력 길이를 제한하고, 전체 체험 예산과 긴급 중단 기능도 둔다. 여러 단계로 동작하는 Agent 역시 같은 작업 예산을 공유해야 한다. 취소, 시간 초과, 재시도까지 제한에 포함해 반복 작업이 호출량을 무한히 늘리지 않도록 한다.

백엔드가 여러 작업 프로세스로 실행된다면 기존 데이터베이스의 트랜잭션 기능을 이용해 예산을 통합 관리해야 한다. 각 프로세스가 별도로 한도를 계산하면 전체 예산을 초과할 수 있다.

미니 프로그램은 기존 HTTPS 업무 도메인을 계속 사용할 수 있다. 위챗은 미니 프로그램의 일반 네트워크 통신에 허용 도메인을 사전에 설정하도록 안내한다. 따라서 미니 프로그램에 게이트웨이 도메인을 직접 공개할 필요는 없다.7

사설 연결은 기존 SSH 터널부터 활용

백엔드와 게이트웨이가 같은 신뢰 호스트에 있다면 로컬 연결을 우선한다. 서로 다른 신뢰 호스트에 있다면 첫 단계에서는 이미 운영 중인 상시 SSH 터널을 재사용할 수 있다. 요청이 올 때마다 새 터널을 만드는 방식은 피한다.

SSH에는 포트 포워딩 전용 계정을 사용하고 연결 가능한 목적지 포트를 제한한다. 게이트웨이는 로컬 주소에 바인딩하고, 터널이 끊기면 보호되지 않은 공개 주소로 우회하지 말고 호출을 거부해야 한다. 비어 있는 호출 키는 내부 연결이 통제돼 있고 해당 호스트의 다른 프로세스도 신뢰할 수 있는 경우에만 고려할 수 있다. 신뢰할 수 없는 환경을 향한 모든 진입점은 별도의 유효한 자격 증명을 실제로 검증해야 한다.

현재 터널이 성능 병목이라는 측정 결과가 있을 때만, 신뢰할 수 있는 두 호스트 사이에 WireGuard를 검토하면 된다. WireGuard는 피어의 키를 바탕으로 인증과 암호화를 제공하지만, 사용한다고 해서 현재 연결보다 반드시 빨라지는 것은 아니다.1216

별도의 제3자 중계 서비스를 추가하거나 역방향 프록시를 한 겹 더 구축하는 것이 첫 단계일 필요는 없다. 업무 백엔드에서 연결을 재사용하고 스트리밍 응답을 제때 전달하며, 미니 프로그램의 연결이 끊기면 실행 중인 작업에도 취소를 전달하는 것이 중요하다.

실제 추가 지연 시간은 현재 정보만으로 판단하기 어렵다. 백엔드에서 게이트웨이까지의 네트워크 시간, 첫 출력이 도착할 때까지의 시간, 전체 작업 완료 시간을 따로 측정하고 중앙값과 상위 지연 구간을 비교해야 한다. 중국 본토에서 게이트웨이와 상위 서비스까지의 실제 네트워크 경로도 별도로 확인해야 한다.

모델 이름만 보고 ‘빠른 모델’이라고 판단해서도 안 된다. 현재 후보 테스트는 사전 설정이 여전히 깊은 추론 모드와 상세 출력을 요구하며, 실제 상위 서비스의 가용성이나 지연 시간을 입증하지 않는다고 명시돼 있다. internal/upstream/studioglobal/registry_fast_models_test.go, internal/upstream/studioglobal/registry_fast_models_test.go 기존 개발용 설정을 바로 바꾸기보다, 개인 강점 다듬기 기능을 위한 가벼운 설정을 따로 만들고 실제로 측정하는 편이 안전하다.

최소 구현 순서와 확인 항목

1. 게이트웨이가 외부에 직접 노출되지 않도록 바인딩을 제한하고, 인터넷과 신뢰할 수 없는 개발 서버에서 백엔드를 우회해 접근할 수 없는지 확인한다.
2. 업무 백엔드에서 개발용 제한 호출과 미니 프로그램용 공개 업무 호출을 별도의 권한 영역으로 나눈다. 자격 증명과 예산도 각각 관리한다.
3. Agent 작업에 호출 한도와 취소 전파, 스트리밍 출력을 적용하고 전체 사용 예산의 상한을 둔다.
4. 자격 증명이 없거나 취소된 요청이 거부되는지, 개발 권한으로 관리 경로에 접근할 수 없는지, 한도 소진 후 호출이 중단되는지 확인한다. 사용자 간 문맥 분리와 다단계 호출·재시도 시 작업 예산이 지켜지는지도 점검한다.
5. 소규모로 공개해 지연 시간을 측정한 뒤, 사설 전송 방식을 바꾸거나 인스턴스를 분리할지 결정한다.

첫 단계에서 제외할 것과 공개 전 확인할 점

이 제안은 아키텍처 권고이며, 실제 보안 배포가 검증됐다는 뜻은 아니다. 여기서 코드를 수정하거나 테스트를 실행한 것도 아니다. 첫 단계에서는 로드밸런서와 서비스 메시, 상시 운영하는 Agent 플랫폼을 새로 구축하지 않는다. 대신 단일 인스턴스의 장애와 용량 한계를 감수하는 선택이다.

상위 서비스가 공개 체험을 허용하는지, 개인 경력 정보가 실제로 어디까지 전달되는지, 관련 규정상 어떤 요건이 적용되는지는 제공된 근거만으로 확인할 수 없다. 공개 전에 확인해야 하며, 사용자에게 필요한 최소한의 정보만 요청하고 이력서 전체 내용이나 자격 증명은 기록하지 않는 것이 바람직하다.

결론은 간단하다. 소스 코드와 마스터 자격 증명은 신뢰할 수 있는 환경에 두고, 개발 서버에는 제한 권한을, 미니 프로그램에는 업무 기능을 제공한다. 인프라 계층을 먼저 늘리기보다 실제 인증과 예산, 작업 경계를 갖추는 일이 우선이다.