AI 게이트웨이의 입력 제한을 논할 때 먼저 물어야 할 것은 “숫자를 얼마나 높일까?”가 아니다. **무엇을 보호하기 위해, 어떤 기준으로 제한하는가?**다.

현재 확인된 내용만으로는 본문 크기 8MiB, 메모리 예산 64MiB, 메시지 1,024개, 도구 128개, JSON 깊이 32단계, 노드 65,536개라는 여섯 값을 모델 능력이나 업계 공통 기준으로 볼 수 없다. 이보다 중요한 문제는 시험용 설정, 게이트웨이의 자원 예산, 상위 API의 규격, 모델의 컨텍스트 용량이 한데 섞여 있다는 점이다.

게이트웨이는 단순 중계기가 아니다

현재 구현은 모델을 직접 실행하는 추론 서버도, 요청을 바이트 단위로 그대로 전달하는 투명 프록시도 아니다. 요청 페이로드를 구성하고, 도구 호출 규격을 다루며, 대화 기록을 정리하고, 이미지를 상위 서비스의 첨부 자료 형식으로 바꾼다. 관련 구현은 internal/upstream/studioglobal/payload.go:359, internal/upstream/studioglobal/media_protocol_production.go:95에서 확인할 수 있다.

따라서 제한을 세 가지로 나눠야 한다.

• 모델 한도: 컨텍스트와 출력 토큰 용량, 지원하는 입력 형식 등이다. 게이트웨이가 임의로 다시 정의할 수 없다.
• 상위 API 한도: 요청 크기, 메시지 구조, 첨부 파일과 도구 호출 규격이다. 실제 연결 대상에 맞춰야 한다.
• 게이트웨이 한도: 요청을 받고 파싱하고 변환하는 과정에서 필요한 메모리·CPU·디스크·동시 처리량과 시간이다. 운영 환경을 보호하기 위해 필요하지만, 모델의 한도인 것처럼 설명해서는 안 된다.

입력이 결국 모델에 토큰 형태로 전달된다는 말만으로 HTTP 요청의 크기, JSON 객체 수, 토큰 수, 게이트웨이의 메모리 사용량을 같은 척도로 볼 수는 없다. 게이트웨이는 모델의 가중치나 추론 캐시를 보유하지 않더라도, 요청을 받기 전후의 파싱과 변환 비용을 감당해야 한다.

공개 사양은 무엇을 알려주나

확인된 공식 자료에 나타난 수치만 보더라도, 요청 크기와 모델 컨텍스트 용량은 별개라는 점이 분명하다.

서비스·규격	공개된 사양	게이트웨이에 주는 시사점
OpenAI GPT-5.5	컨텍스트 1,050,000토큰, 최대 출력 128,000토큰 5	큰 컨텍스트가 곧 그에 비례하는 HTTP 요청 크기를 요구하는 것은 아니다. 토큰 한도만으로 적정한 MiB 상한을 계산할 수 없다.
Anthropic Messages·Token Counting API	2026년 10월 28일, 자사 API의 최대 요청 크기를 32MB에서 128MB로 상향 10	예전 32MB 수치를 현재 공통 기준으로 취급하거나, 게이트웨이의 8MiB를 Claude의 모델 한도로 설명해서는 안 된다.
Anthropic Messages API	한 요청에 메시지 최대 100,000개 12	게이트웨이의 1,024개 제한은 업계 공통 상한이 아니다. 그렇다고 현지 운영 환경에서 무조건 100,000개를 허용해야 하는 뜻도 아니다.
Anthropic 이미지 입력	200k 컨텍스트 모델은 요청당 최대 100장, 그 외 모델은 최대 600장. 이미지 크기 제한도 별도 적용 16	이미지 개수와 크기는 따로 관리할 수 있다. 입력에 자원 제한을 두는 것 자체보다, 제한의 근거와 범위가 중요하다.
Google Vertex·AI Studio, xAI	이번 검토에서 공식 수치를 확인할 만큼의 근거를 확보하지 못함	요청 크기나 도구 수를 추정으로 채우지 않는다. 네 업체의 전체 규격 비교는 아직 완료되지 않았다.

Anthropic Messages API는 상태를 저장하지 않는 방식으로 사용할 경우 매 요청에 대화 기록 전체를 보낸다. 따라서 마지막 입력이 짧더라도 누적된 기록에 따라 요청은 커질 수 있다 15.

다만 공개 사양은 호환성의 참고 자료일 뿐이다. StudioGlobal의 같은 이름 모델 라우트가 해당 업체의 공식 API와 동일한 인터페이스와 용량을 제공한다고 입증해 주지는 않는다.

시험용 여섯 수치, 하나씩 따져보기

아래 값들은 현재 생산 환경의 보편적인 계약이라기보다 시험 설정으로 정의된 것으로 확인됐다. 관련 정의와 설정 연결은 internal/chatadmission/config.go:12에 있다.

설정	이런 종류의 방어가 필요한가?	현재 수치에 대한 판단
본문 상한: 8MiB (config.go:14)	필요하다. 무제한 수신과 후속 처리의 팽창을 막는다.	시험 경계로 둘 수는 있지만 모든 모델과 입력의 영구 상한으로 삼을 근거는 부족하다. 반대로 모델의 컨텍스트가 크다는 이유만으로 반드시 낮다고 단정할 수도 없다.
본문 메모리 예산: 64MiB (config.go:15)	필요하다. 게이트웨이 내부 자원 관리 기준이다.	모델 업계의 표준 수치가 아니다. 배포 환경의 메모리, 동시 요청 수, 처리 과정의 복사본 등을 바탕으로 정해야 한다.
메시지 수: 1,024 (config.go:16)	객체 수를 제한하는 방어선으로 활용할 수 있다.	컨텍스트 크기와 같은 기준이 아니다. 짧은 메시지 다수와 긴 메시지 하나는 자원 사용 양상이 다르므로, 실제 클라이언트 호환성을 근거로 삼아야 한다.
도구 수: 128 (config.go:17)	도구 정의가 요청에 미치는 부담을 제한하는 데 쓸 수 있다.	네 업체의 공통 표준이라는 증거는 확인되지 않았다. 도구 개수와 정의의 크기, 도구 선택의 품질은 각각 살펴봐야 한다.
JSON 깊이: 32 (config.go:18)	비정상적으로 깊은 중첩 구조를 막는 데 필요하다.	모델의 이해 깊이가 아니라 게이트웨이 파서의 구조 제한이다. 적정 값은 정상적인 도구 인자와 파서 동작을 바탕으로 검증해야 한다.
JSON 노드 수: 65,536 (config.go:19)	객체가 과도하게 확장되는 상황을 막는 데 유용할 수 있다.	토큰 수가 아니며, 확인된 네 업체의 공통 기준도 아니다. 바이트·메모리 제한만으로 객체 비용을 충분히 통제하는지 함께 봐야 한다.

특히 JSON 스키마의 중첩 제한을 모든 입력 JSON에 그대로 적용해서는 안 된다. 메시지 본문 속 JSON이 단순 문자열이라면, HTTP 요청 구조를 이루는 JSON 객체와는 파싱 관점에서 다른 대상이다.

도구 정의 역시 많을수록 좋은 것은 아니다. OpenAI는 도구가 많거나 스키마가 클 때 필요한 도구 정의를 나중에 불러오는 방식을 안내한다 2. 즉, 하드 리밋을 계속 올리는 것 말고도 한 번에 요청에 싣는 내용을 줄이는 선택지가 있다.

숫자보다 구현의 실제 동작을 점검해야 한다

같은 노드 수라도 계산 방식이 달라질 수 있다

기존 사전 검사 코드는 키와 값을 모두 노드 수에 포함하고, 본문 크기와 노드 수, 디코딩된 문자열을 바탕으로 파생 용량을 추정했다. 현재 스트리밍 검사는 주로 값이 시작되는 지점에서 노드를 센다. 따라서 65,536이라는 숫자가 같아도 두 방식이 같은 복잡도의 요청을 뜻하지 않는다. 관련 코드는 internal/chatadmission/preflight.go:91, preflight.go:156, internal/chatadmission/phase3_scan.go:71에서 확인할 수 있다.

메모리 추정치는 실제 메모리 보증이 아니다

기존 사전 검사는 본문 크기의 네 배, 노드당 512바이트, 디코딩 문자열에 대한 추가 추정치를 사용한다. 코드에도 이는 보수적인 추산이지 실제 힙 메모리나 프로세스의 RSS가 아니라고 명시돼 있다. 처리 단계에서는 요청 한 건의 파생 데이터 예산 전체를 미리 예약하기도 한다 (internal/chatadmission/preflight.go:17, internal/chatadmission/processing.go:18).

보수적인 사전 검사는 유용하다. 다만 이 추정만으로 “64MiB 예산이면 프로세스가 메모리 한도를 넘지 않는다”고 보장할 수는 없다.

현재 스트리밍 경로의 병목은 예전 8MiB가 아니다

현재 스트리밍 설정에는 전체 본문 상한이 약 53.8MiB로 잡혀 있지만, 미디어가 아닌 JSON은 512KiB로 제한돼 있다. 기본 파생 데이터 예산은 4MiB다 (internal/chatadmission/phase3.go:10).

따라서 예전 시험용 8MiB 값만 바꾸더라도 현재 텍스트 요청의 병목은 달라지지 않을 수 있다. 메타데이터 상한만 높이는 것 역시 파싱과 파생 데이터 예산이 충분하다는 보장이 아니다.

게이트웨이는 이미 자체적인 대화 기록 정책을 적용한다

현재 상위 요청 페이로드에는 안전 메시지 56개와 제출 카운트 480,000의 예산이 적용된다. 텍스트 카운트는 문자 수를 이용한 추정치이며, 각 업체의 정밀한 토크나이저 계산은 아니다. 텍스트만 있는 요청은 예산을 넘을 때 완전한 대화 묶음을 제외할 수 있지만, 미디어가 포함된 요청은 같은 압축 경로로 보내지 않는다 (internal/upstream/studioglobal/payload.go:359, payload.go:400).

즉, 이미지 지원을 더하는 일은 이미지 크기 제한뿐 아니라 긴 대화 기록을 다루는 방식도 바꾼다. 단일 이미지의 크기보다 이 변화가 더 중요한 점검 대상일 수 있다.

설계 방향에 따라 감수할 것도 달라진다

• 게이트웨이를 가벼운 프로토콜 어댑터라고 부른다면, 요청을 투명하게 전달한다고 설명하면서 실제로는 대화 기록을 삭제하거나 카운트를 다시 계산하는 동작을 숨겨서는 안 된다. 필수 프로토콜 변환과 대화 맥락 관리를 구분해야 한다.
• 현재 Docker 컨테이너 설정은 256MiB다 (docker-compose.yml:43). 이 조건에서 업체가 허용하는 최대 요청을 모두 받고, 파싱 사본을 여러 개 만들고, 동시 요청까지 늘리면서 기존 메모리 목표를 유지할 수 있다고 가정할 수는 없다. 처리 방식과 배포 용량, 허용 범위 사이의 선택이 필요하다.
• 로컬 Cline 사용이 주된 목적이라면 실제 코딩 요청과의 호환성을 우선 검증해야 한다. 범용 멀티미디어 입력에 대비한다며 정상적인 텍스트 JSON을 512KiB로 제한하는 것이 적절한지 살펴볼 필요가 있다. 로컬 수신 설정은 docker-compose.yml:29에서 확인할 수 있다. 다만 특정 클라이언트가 주된 대상이라는 이유만으로 자원 방어를 없애서는 안 된다.
• 깊이·노드·객체 수 제한을 없애려면, 작은 객체가 대량으로 들어오는 경우를 남은 바이트·시간·메모리 방어선이 어떻게 막는지 설명할 수 있어야 한다. “결국 토큰이 된다”는 말은 토큰화 전에 발생하는 파싱 비용에 대한 답이 아니다.

결론: 모델 능력은 막지 말고, 운영 자원은 보호해야

자원 오남용을 막는 요청 크기·파싱·동시 처리·시간 제한은 유지해야 한다. 다만 시험용으로 정의된 여섯 수치를 검증 없이 범용 운영 계약으로 굳혀서는 안 된다. 각 제한이 무엇을 보호하고, 어떤 근거로 정해졌으며, 정상 요청에 어떤 영향을 주는지 분명히 해야 한다.

우선순위는 숫자 하나를 바꾸는 데 있지 않다. 미디어 경로가 텍스트 컨텍스트에 적용하는 512KiB 제한이 적절한지, 그에 맞춰 파생 데이터 예산도 충분한지 함께 살펴야 한다. 상위 API 규격은 어댑터에서, 배포 자원 한도는 운영 설정에서 관리하는 편이 명확하다. 대화 기록 압축은 가능하면 클라이언트가 맡고, 게이트웨이가 맡는다면 그 동작을 계약에 드러내야 한다.

핵심은 근거 없이 모델이 도달할 수 있는 입력 범위를 줄이지 않되, 작은 게이트웨이를 무한한 용량을 가진 것처럼 취급하지 않는 것이다. 새 상한을 제시하려면 실제 클라이언트 요청, 연결 대상의 프로토콜, 배포 자원에 대한 추가 검증이 필요하다. 이번 검토는 코드와 공식 자료를 살핀 것이며, 파일 수정이나 실행 검증, 현재 실행 중인 바이너리 버전 확인은 하지 않았다.

AI 게이트웨이의 입력 제한을 논할 때 먼저 물어야 할 것은 “숫자를 얼마나 높일까?”가 아니다. **무엇을 보호하기 위해, 어떤 기준으로 제한하는가?**다.

현재 확인된 내용만으로는 본문 크기 8MiB, 메모리 예산 64MiB, 메시지 1,024개, 도구 128개, JSON 깊이 32단계, 노드 65,536개라는 여섯 값을 모델 능력이나 업계 공통 기준으로 볼 수 없다. 이보다 중요한 문제는 시험용 설정, 게이트웨이의 자원 예산, 상위 API의 규격, 모델의 컨텍스트 용량이 한데 섞여 있다는 점이다.

게이트웨이는 단순 중계기가 아니다

현재 구현은 모델을 직접 실행하는 추론 서버도, 요청을 바이트 단위로 그대로 전달하는 투명 프록시도 아니다. 요청 페이로드를 구성하고, 도구 호출 규격을 다루며, 대화 기록을 정리하고, 이미지를 상위 서비스의 첨부 자료 형식으로 바꾼다. 관련 구현은 internal/upstream/studioglobal/payload.go:359, internal/upstream/studioglobal/media_protocol_production.go:95에서 확인할 수 있다.

따라서 제한을 세 가지로 나눠야 한다.

• 모델 한도: 컨텍스트와 출력 토큰 용량, 지원하는 입력 형식 등이다. 게이트웨이가 임의로 다시 정의할 수 없다.
• 상위 API 한도: 요청 크기, 메시지 구조, 첨부 파일과 도구 호출 규격이다. 실제 연결 대상에 맞춰야 한다.
• 게이트웨이 한도: 요청을 받고 파싱하고 변환하는 과정에서 필요한 메모리·CPU·디스크·동시 처리량과 시간이다. 운영 환경을 보호하기 위해 필요하지만, 모델의 한도인 것처럼 설명해서는 안 된다.

입력이 결국 모델에 토큰 형태로 전달된다는 말만으로 HTTP 요청의 크기, JSON 객체 수, 토큰 수, 게이트웨이의 메모리 사용량을 같은 척도로 볼 수는 없다. 게이트웨이는 모델의 가중치나 추론 캐시를 보유하지 않더라도, 요청을 받기 전후의 파싱과 변환 비용을 감당해야 한다.

공개 사양은 무엇을 알려주나

확인된 공식 자료에 나타난 수치만 보더라도, 요청 크기와 모델 컨텍스트 용량은 별개라는 점이 분명하다.

서비스·규격	공개된 사양	게이트웨이에 주는 시사점
OpenAI GPT-5.5	컨텍스트 1,050,000토큰, 최대 출력 128,000토큰 5	큰 컨텍스트가 곧 그에 비례하는 HTTP 요청 크기를 요구하는 것은 아니다. 토큰 한도만으로 적정한 MiB 상한을 계산할 수 없다.
Anthropic Messages·Token Counting API	2026년 10월 28일, 자사 API의 최대 요청 크기를 32MB에서 128MB로 상향 10	예전 32MB 수치를 현재 공통 기준으로 취급하거나, 게이트웨이의 8MiB를 Claude의 모델 한도로 설명해서는 안 된다.
Anthropic Messages API	한 요청에 메시지 최대 100,000개 12	게이트웨이의 1,024개 제한은 업계 공통 상한이 아니다. 그렇다고 현지 운영 환경에서 무조건 100,000개를 허용해야 하는 뜻도 아니다.
Anthropic 이미지 입력	200k 컨텍스트 모델은 요청당 최대 100장, 그 외 모델은 최대 600장. 이미지 크기 제한도 별도 적용 16	이미지 개수와 크기는 따로 관리할 수 있다. 입력에 자원 제한을 두는 것 자체보다, 제한의 근거와 범위가 중요하다.
Google Vertex·AI Studio, xAI	이번 검토에서 공식 수치를 확인할 만큼의 근거를 확보하지 못함	요청 크기나 도구 수를 추정으로 채우지 않는다. 네 업체의 전체 규격 비교는 아직 완료되지 않았다.

Anthropic Messages API는 상태를 저장하지 않는 방식으로 사용할 경우 매 요청에 대화 기록 전체를 보낸다. 따라서 마지막 입력이 짧더라도 누적된 기록에 따라 요청은 커질 수 있다 15.

다만 공개 사양은 호환성의 참고 자료일 뿐이다. StudioGlobal의 같은 이름 모델 라우트가 해당 업체의 공식 API와 동일한 인터페이스와 용량을 제공한다고 입증해 주지는 않는다.

시험용 여섯 수치, 하나씩 따져보기

아래 값들은 현재 생산 환경의 보편적인 계약이라기보다 시험 설정으로 정의된 것으로 확인됐다. 관련 정의와 설정 연결은 internal/chatadmission/config.go:12에 있다.

설정	이런 종류의 방어가 필요한가?	현재 수치에 대한 판단
본문 상한: 8MiB (config.go:14)	필요하다. 무제한 수신과 후속 처리의 팽창을 막는다.	시험 경계로 둘 수는 있지만 모든 모델과 입력의 영구 상한으로 삼을 근거는 부족하다. 반대로 모델의 컨텍스트가 크다는 이유만으로 반드시 낮다고 단정할 수도 없다.
본문 메모리 예산: 64MiB (config.go:15)	필요하다. 게이트웨이 내부 자원 관리 기준이다.	모델 업계의 표준 수치가 아니다. 배포 환경의 메모리, 동시 요청 수, 처리 과정의 복사본 등을 바탕으로 정해야 한다.
메시지 수: 1,024 (config.go:16)	객체 수를 제한하는 방어선으로 활용할 수 있다.	컨텍스트 크기와 같은 기준이 아니다. 짧은 메시지 다수와 긴 메시지 하나는 자원 사용 양상이 다르므로, 실제 클라이언트 호환성을 근거로 삼아야 한다.
도구 수: 128 (config.go:17)	도구 정의가 요청에 미치는 부담을 제한하는 데 쓸 수 있다.	네 업체의 공통 표준이라는 증거는 확인되지 않았다. 도구 개수와 정의의 크기, 도구 선택의 품질은 각각 살펴봐야 한다.
JSON 깊이: 32 (config.go:18)	비정상적으로 깊은 중첩 구조를 막는 데 필요하다.	모델의 이해 깊이가 아니라 게이트웨이 파서의 구조 제한이다. 적정 값은 정상적인 도구 인자와 파서 동작을 바탕으로 검증해야 한다.
JSON 노드 수: 65,536 (config.go:19)	객체가 과도하게 확장되는 상황을 막는 데 유용할 수 있다.	토큰 수가 아니며, 확인된 네 업체의 공통 기준도 아니다. 바이트·메모리 제한만으로 객체 비용을 충분히 통제하는지 함께 봐야 한다.

특히 JSON 스키마의 중첩 제한을 모든 입력 JSON에 그대로 적용해서는 안 된다. 메시지 본문 속 JSON이 단순 문자열이라면, HTTP 요청 구조를 이루는 JSON 객체와는 파싱 관점에서 다른 대상이다.

도구 정의 역시 많을수록 좋은 것은 아니다. OpenAI는 도구가 많거나 스키마가 클 때 필요한 도구 정의를 나중에 불러오는 방식을 안내한다 2. 즉, 하드 리밋을 계속 올리는 것 말고도 한 번에 요청에 싣는 내용을 줄이는 선택지가 있다.

숫자보다 구현의 실제 동작을 점검해야 한다

같은 노드 수라도 계산 방식이 달라질 수 있다

기존 사전 검사 코드는 키와 값을 모두 노드 수에 포함하고, 본문 크기와 노드 수, 디코딩된 문자열을 바탕으로 파생 용량을 추정했다. 현재 스트리밍 검사는 주로 값이 시작되는 지점에서 노드를 센다. 따라서 65,536이라는 숫자가 같아도 두 방식이 같은 복잡도의 요청을 뜻하지 않는다. 관련 코드는 internal/chatadmission/preflight.go:91, preflight.go:156, internal/chatadmission/phase3_scan.go:71에서 확인할 수 있다.

메모리 추정치는 실제 메모리 보증이 아니다

기존 사전 검사는 본문 크기의 네 배, 노드당 512바이트, 디코딩 문자열에 대한 추가 추정치를 사용한다. 코드에도 이는 보수적인 추산이지 실제 힙 메모리나 프로세스의 RSS가 아니라고 명시돼 있다. 처리 단계에서는 요청 한 건의 파생 데이터 예산 전체를 미리 예약하기도 한다 (internal/chatadmission/preflight.go:17, internal/chatadmission/processing.go:18).

보수적인 사전 검사는 유용하다. 다만 이 추정만으로 “64MiB 예산이면 프로세스가 메모리 한도를 넘지 않는다”고 보장할 수는 없다.

현재 스트리밍 경로의 병목은 예전 8MiB가 아니다

현재 스트리밍 설정에는 전체 본문 상한이 약 53.8MiB로 잡혀 있지만, 미디어가 아닌 JSON은 512KiB로 제한돼 있다. 기본 파생 데이터 예산은 4MiB다 (internal/chatadmission/phase3.go:10).

따라서 예전 시험용 8MiB 값만 바꾸더라도 현재 텍스트 요청의 병목은 달라지지 않을 수 있다. 메타데이터 상한만 높이는 것 역시 파싱과 파생 데이터 예산이 충분하다는 보장이 아니다.

게이트웨이는 이미 자체적인 대화 기록 정책을 적용한다

현재 상위 요청 페이로드에는 안전 메시지 56개와 제출 카운트 480,000의 예산이 적용된다. 텍스트 카운트는 문자 수를 이용한 추정치이며, 각 업체의 정밀한 토크나이저 계산은 아니다. 텍스트만 있는 요청은 예산을 넘을 때 완전한 대화 묶음을 제외할 수 있지만, 미디어가 포함된 요청은 같은 압축 경로로 보내지 않는다 (internal/upstream/studioglobal/payload.go:359, payload.go:400).

즉, 이미지 지원을 더하는 일은 이미지 크기 제한뿐 아니라 긴 대화 기록을 다루는 방식도 바꾼다. 단일 이미지의 크기보다 이 변화가 더 중요한 점검 대상일 수 있다.

설계 방향에 따라 감수할 것도 달라진다

• 게이트웨이를 가벼운 프로토콜 어댑터라고 부른다면, 요청을 투명하게 전달한다고 설명하면서 실제로는 대화 기록을 삭제하거나 카운트를 다시 계산하는 동작을 숨겨서는 안 된다. 필수 프로토콜 변환과 대화 맥락 관리를 구분해야 한다.
• 현재 Docker 컨테이너 설정은 256MiB다 (docker-compose.yml:43). 이 조건에서 업체가 허용하는 최대 요청을 모두 받고, 파싱 사본을 여러 개 만들고, 동시 요청까지 늘리면서 기존 메모리 목표를 유지할 수 있다고 가정할 수는 없다. 처리 방식과 배포 용량, 허용 범위 사이의 선택이 필요하다.
• 로컬 Cline 사용이 주된 목적이라면 실제 코딩 요청과의 호환성을 우선 검증해야 한다. 범용 멀티미디어 입력에 대비한다며 정상적인 텍스트 JSON을 512KiB로 제한하는 것이 적절한지 살펴볼 필요가 있다. 로컬 수신 설정은 docker-compose.yml:29에서 확인할 수 있다. 다만 특정 클라이언트가 주된 대상이라는 이유만으로 자원 방어를 없애서는 안 된다.
• 깊이·노드·객체 수 제한을 없애려면, 작은 객체가 대량으로 들어오는 경우를 남은 바이트·시간·메모리 방어선이 어떻게 막는지 설명할 수 있어야 한다. “결국 토큰이 된다”는 말은 토큰화 전에 발생하는 파싱 비용에 대한 답이 아니다.

결론: 모델 능력은 막지 말고, 운영 자원은 보호해야

자원 오남용을 막는 요청 크기·파싱·동시 처리·시간 제한은 유지해야 한다. 다만 시험용으로 정의된 여섯 수치를 검증 없이 범용 운영 계약으로 굳혀서는 안 된다. 각 제한이 무엇을 보호하고, 어떤 근거로 정해졌으며, 정상 요청에 어떤 영향을 주는지 분명히 해야 한다.

우선순위는 숫자 하나를 바꾸는 데 있지 않다. 미디어 경로가 텍스트 컨텍스트에 적용하는 512KiB 제한이 적절한지, 그에 맞춰 파생 데이터 예산도 충분한지 함께 살펴야 한다. 상위 API 규격은 어댑터에서, 배포 자원 한도는 운영 설정에서 관리하는 편이 명확하다. 대화 기록 압축은 가능하면 클라이언트가 맡고, 게이트웨이가 맡는다면 그 동작을 계약에 드러내야 한다.

핵심은 근거 없이 모델이 도달할 수 있는 입력 범위를 줄이지 않되, 작은 게이트웨이를 무한한 용량을 가진 것처럼 취급하지 않는 것이다. 새 상한을 제시하려면 실제 클라이언트 요청, 연결 대상의 프로토콜, 배포 자원에 대한 추가 검증이 필요하다. 이번 검토는 코드와 공식 자료를 살핀 것이며, 파일 수정이나 실행 검증, 현재 실행 중인 바이너리 버전 확인은 하지 않았다.