AI 개발

AI 모델은 왜 점점 커지나? 파라미터, Token, Context Window와 JSON 데이터 처리

JSONSort 게시 2026-09-05 업데이트 2026-09-07 약 16분

수천억 파라미터와 백만 토큰 창이 그 자체로 진보처럼 팔린다. JSON 개발자에게 더 크다는 것은 대개 같은 주문 객체가 더 비싸고, 더 쉽게 잘리며, 적법한 구조로 내기 어렵다는 뜻이다. 섞여 쓰이는 세 단어——파라미터, Token, Context Window——를 나누고 2026년 JSON 다루기에 착지한다.

읽기 전 요약

개념	한 줄	JSON과의 관계
파라미터	학습 가능한 가중치 수. 대략적인 「용량」	적법 JSON을 안정적으로 내는 데 영향
Token	텍스트 길이와 과금 단위	괄호·따옴표·반복 키에도 돈이 든다
Context Window	한 요청이 담을 수 있는 token 상한	큰 JSON과 다단계 tool 결과가 먼저 부딪힌다

더 큼 ≠ JSON을 더 잘함. 파라미터는 용량, Token은 청구서, Context Window는 물통이다. 물통이 커져도 첫 반응은 API 응답 전체를 붓는 것이 아니다.

대규모 모델은 왜 더 커지나

경험 법칙은 단순하다. 데이터와 연산이 따라오면 파라미터를 늘리고 더 오래 학습할수록 손실 곡선은 보통 좋아진다. 그래서 벤더는 「더 큼」을 기본 서사로 쓴다——벤치, 데모, 구매 목록에서 말하기 쉽다.

2024–2026년의 「큼」은 세 축으로 갈라졌다. 더 이상 파라미터 개수만은 아니다:

파라미터 규모: 밀집 모델은 계속 늘고, MoE는 총 파라미터는 크되 토큰마다 일부만 활성화한다.
Context Window: 8K·32K가 128K, 이어 백만. Agent와 긴 문서가 핑계다.
출력 제약: Structured Outputs / JSON Schema는 「더 큼」을 「더 안정적인 객체」로 바꾸며, 더 긴 산문으로 바꾸지 않는다.

JSON을 쓰는 사람의 질문은 「몇 B인가」가 아니다. Schema를 얼마나 안정적으로 맞추는지, 천 token당 가격, tool 결과가 창에 아직 들어가는지다.

파라미터란 무엇인가?

파라미터는 학습 후 모델에 남는 가중치다. 추론 때는 갱신되지 않고 계산에만 쓰인다. 7B, 70B, 405B(십억)는 용량이지, 이번 요청이 몇 글자를 읽었는지가 아니다.

파라미터가 늘면 보통 세 가지가 생긴다:

복잡한 제약에 맞추는 능력이 오른다. 중첩 객체, enum, required를 덜 틀린다.
추론이 더 비싸고 느리다. 같은 JSON도 큰 모델에서는 token당 지연과 단가가 높다.
더 큰 Context Window와 같지 않다. 작은 모델도 128K를 걸 수 있고, 큰 모델이 32K일 수도 있다.

2026년 제품 페이지는 MoE의 「총 파라미터」와 「활성 파라미터」를 나란히 적는다. 청구가 어느 쪽인지, 지연이 어느 쪽인지 물어라. GPT-6 Astra 가이드가 썼듯, JSON 작업에서는 안정적인 Structured Outputs가 한 단계 더 큰 밀집 모델보다 값진 경우가 많다.

Token이란 무엇인가?

Token은 토크나이저가 자른 조각이지 문자도 단어도 아니다. 영어는 1 token ≈ 4자에 가깝다. 중국어·코드·JSON 문장부호는 더 잘게 쪼개져 같은 시각 길이가 더 비싸다.

API는 token으로 과금하고 token으로 자른다. 시스템 프롬프트, 도구 정의, 대화 기록, 도구가 반환한 JSON, 모델이 낸 JSON이 같은 장부에 들어간다.

JSON은 원래 비싸다. 괄호, 따옴표, 쉼표, 들여쓰기, 반복 키가 각각 token을 먹을 수 있다. 아래 「완전한 주문」은 읽기 쉽지만 보내면 낭비다:

{
  "order": {
    "order_id": "A-1042",
    "customer": {
      "full_name": "Ada Lovelace",
      "email": "ada@example.com",
      "locale": "en-GB"
    },
    "line_items": [
      {"sku": "KB-1", "title": "Keyboard", "qty": 1, "price": 99.00}
    ],
    "shipping": {"city": "London", "method": "express"},
    "debug": {"trace_id": "tr_9f", "retries": 0}
  }
}

다음 Agent 홉에서 같은 업무는 보통 이것만 있으면 된다:

{
  "order_id": "A-1042",
  "amount": 99.00,
  "status": "paid"
}

먼저 로컬에서 포맷로 구조를 보고, JSONPath 추출로 order_id / amount / status를 뽑은 뒤 minify해서 모델에 넣는다. 디버그는 예쁘게, 추론은 날씬하게. 같은 payload가 아니다.

Context Window란 무엇인가?

Context Window는 한 요청이 동시에 담을 수 있는 token 상한이다. 어떤 벤더는 입출력을 한 창에 넣고, 어떤 벤더는 출력용 칸을 남긴다. 문서가 애매하면 「입력 + 예약한 출력 ≤ 창」으로 예산을 짠다.

8K에서 128K, 백만으로 늘어도 JSON 처리가 자동으로 쉬워지지는 않는다. 「응답 전체를 붙여 넣기」가 가능해 보일 뿐이다. 가능과 싸고 안정적인 것은 다르다.

Agent 루프에서 창은 보통 이렇게 먹힌다:

{
  "context_window": 128000,
  "spent": {
    "system": 1200,
    "tools": 3400,
    "history": 18000,
    "tool_result_json": 42000
  },
  "reserved_output": 4000,
  "remaining": 59400
}

표는 예시이지 공식 청구서가 아니다. 핵심은 tool 결과 JSON이 prompt보다 뚱뚱한 경우가 많다는 것이다. 투영과 요약을 하지 않는 다단계 AI Agent 완전 가이드는 세 번째 홉에서 객체의 절반을 자르고, 다음 홉이 그것을 완전한 주문으로 취급한다.

파라미터, Token, Context Window는 어떻게 겹치나

세 단어는 「모델이 더 크다」로 납작해진다. 역할은 다르다:

파라미터는 품질 상한: Schema를 따라갈 수 있는가, additionalProperties 밖으로 즉흥하는가.
Token은 각 홉의 청구와 지연. 같은 창의 뚱뚱한 JSON은 기록과 출력 여유를 밀어낸다.
Context Window는 한 번에 볼 수 있는 양. 물통이 커도 「파라미터가 제약을 못 버팀」이나 「token이 비싸 재시도 못 함」은 고치지 못한다.

2026년의 기본 사고: 큰 창을 사고 2MB pretty-printed JSON을 부은 뒤, 모델이 앞 필드를 「잊었다」고 탓한다. 잊지 않았다. 당신이 창을 먼저 채웠다.

JSON 데이터 처리에 무엇을 의미하나

일상 파이프라인에서 세 층은 아주 구체적이다:

사람에게는 예쁘게, 모델에게는 압축. 들여쓰기는 에디터에서는 본전이고 token 청구에서는 순수 낭비다.
원문보다 투영. 도구가 필드 80개를 반환하면 다음 홉의 required 키만 남긴다.
Schema는 재시도 보험. Structured Outputs는 검증으로 불법 JSON 생성 횟수를 줄여 출력 token을 바로 아낀다.
문자열화된 arguments는 형태를 두 번 낸다. 이스케이프된 따옴표는 읽기 어렵고 한도를 먹으며, 호스트는 다시 파싱해야 한다.
긴 컨텍스트는 데이터베이스가 아니다. 조회는 도구로, 비교는 로컬 Diff로. 5000줄 파일 두 개를 한 메시지에 넣지 마라.

AI Agent가 JSON Schema를 필요로 하기 시작한 이유는 Schema를 런타임 게이트로 만들었다. 문법은 JSON Schema 튜토리얼. 버전이 어긋나면 더 큰 모델을 사기 전에 지난주 동작하던 객체와 오늘 거절된 객체를 JSON Diff하라.

2026년에 비용을 줄이는 법 (먼저 JSON, 그다음 모델)

각 Agent 단계에 「컨텍스트에 넣을 수 있는 필드」 허용 목록을 쓴다. JSON.stringify(fullResponse)는 쓰지 않는다.
도구 정의도 날씬하게: description에 제약을 남기고 호출을 바꾸지 않는 산문은 지운다.
strict: true / json_schema를 켜고 재시도 대신 검증을 쓴다.
기록은 상태 객체만 남기고 tool 원문은 버린다. checkpoint는 작은 JSON이지 채팅 기록이 아니다.
비밀과 사용자 필드는 로컬에서 보고 자른다. 공개 JSON 사이트에 올리지 말고, 이유 없이 모델에도 보내지 마라.

순서는 투영 → 압축 → Schema → 그다음 더 작거나 큰 모델을 검토한다. 뒤집으면 창과 파라미터를 모두 낭비한다.

흔한 실수

파라미터 수를 Context Window로 본다. 70B와 128K는 다른 구매 항목이다. 같은 슬라이드에 있어도 묶여 있지 않다.
문자 수로 token을 어림한다. JSON 문장부호와 중국어는 「길어 보이지 않는」 객체를 먼저 천장에 붙인다.
창이 커졌다고 투영을 멈춘다. 백만 token도 과금된다. 뚱뚱한 JSON은 청구서만 길게 한다.
불법 JSON을 더 큰 모델로 고친다. 먼저 Schema와 호스트 검증을 보라. 많은 「모델이 둔해졌다」는 required가 하나 늘었을 뿐이다.
pretty JSON과 라이브 payload를 같은 것으로 본다. 에디터의 공백은 추론 요청에 나오면 안 된다.

FAQ

파라미터가 클수록 JSON이 더 적법해지나?

경향은 좋아지지만 보장은 아니다. Schema와 호스트 검증이 없으면 큰 모델도 필드를 빠뜨리고 숫자를 문자열로 쓴다. 용량은 사고율을 낮추고, 게이트는 사고가 다음 홉에 갈지를 정한다.

Token과 문자를 4:1로 환산해도 되나?

영어 산문의 경험칙으로는 된다. JSON·코드·중국어는 안 된다. 벤더 tokenizer나 공식 계수 API를 써라. 에디터 글자 수로 청구하지 마라.

Context Window에 모델 출력이 포함되나?

대부분의 Chat / Responses API는 출력을 같은 예산에 넣거나 max output을 따로 둔다. 최악은 「입력 + 예약한 출력 ≤ 창」으로 마지막 닫는 괄호가 잘리지 않게 한다.

이미 1M 창이 있다. JSON을 아직 잘라야 하나?

잘라야 한다. 창은 「들어가나」에 답하고 「감당되나」「다음 홉이 안정한가」에는 답하지 않는다. 투영과 minify는 기본 동작으로 남는다.

JSON이 컨텍스트를 터뜨릴지 로컬에서 어떻게 보나?

먼저 포맷해 구조를 보고, 필드를 투영한 뒤 실제로 보낼 문자열을 센다. JSONSort는 브라우저 로컬에서 포맷·추출·Diff하며 업로드하지 않는다.

결론

모델이 커지는 것은 더 많은 파라미터, 더 긴 창, 더 많은 데이터가 평가에서 여전히 팔리기 때문이다. JSON을 다루는 사람에게 파라미터는 용량, Token은 청구서, Context Window는 물통이다. 예쁜 JSON을 더 큰 통에 붓는 것은 다른 형태의 초과 지출일 뿐이다.

오늘부터 「이 홉에 들어와도 되는 키」를 먼저 쓰고, 그다음 더 큰 모델이 필요한지 정하라. 모델은 더 커질 것이다. 구경은 먼저 작아져야 한다.

더 읽기

AI Agent란? Tool Calling과 JSON 런타임, 도구 호출, JSON 계약
AI Agent가 JSON Schema를 필요로 하기 시작한 이유 Tool Calling에서 구조화 워크플로까지
GPT-6 Astra와 JSON / API 새 모델의 Structured Outputs
JSON Schema란 required, enum, additionalProperties
JSONSort 로컬 도구상자 포맷, 추출, Diff
모든 글 JSON과 AI 개발 노트

변경 기록: 2026-09-05 최초 게시