AI 글자 수 지정 실측(제미나이 4개 모델) — 이내로 요청한 18번 중 17번이 미달, 코드 실행을 켠 7번은 500자

AI에게 "500자 이내로 써 줘"라고 부탁해 본 적 있으실 거예요. 자기소개서 분량을 맞추거나 상세 페이지 문구를 정해진 칸에 넣어야 할 때요. 그런데 받아서 세어 보면 어딘가 짧아요. 그렇다고 매번 세어 보기도 번거롭고요.

결론부터 적을게요. 제미나이 계열 4개 모델에 같은 요청을 18번 넣었더니 17번이 목표 글자 수에 못 미쳤어요. 미달분은 목표의 57.3퍼센트에서 94.0퍼센트 사이에 흩어져 있었어요. 그리고 남은 한 번은 반대로 583자가 나와 500자 상한을 넘겼어요.

다만 이 숫자를 "AI는 글자 수를 못 센다"로 뭉뚱그리면 어긋나요. 요청 문장을 바꾸면 결과가 달라졌고, 코드 실행 도구를 켜자 응답을 받은 7번이 전부 공백 포함 500자로 맞았거든요. 아래에서 요청 문장별로 갈라 원값 그대로 보여 드릴게요.

먼저 잰 범위부터 밝힐게요. 이 글의 숫자는 전부 제미나이 계열 4개 모델을 2026년 8월 20일에 API로 직접 호출해 받은 응답을 센 값이에요. 챗GPT나 클로드는 이번에 재지 않았어요.

결론부터 — 요청 문장별로 이렇게 갈렸어요

핵심만 먼저 네 줄로 적을게요.

첫째, "N자 이내로"는 분량을 정하는 말로는 잘 안 통했어요. 18번 중 17번이 목표에 못 미쳤고 대체로 목표의 6할 남짓에서 9할 사이에 떨어졌어요.

둘째, 그렇다고 "이내"가 상한을 보장하지도 않았어요. 500자 이내 요청에 583자가 나온 회차가 있었어요. 응답이 중간에 잘린 게 아니라 모델이 정상 종료한 결과였고요.

셋째, "정확히 N자로"는 요청 형식을 바꾼 값어치가 있었지만 여전히 맞지는 않았어요. 한 모델은 글자마다 번호를 붙여 세다가 출력 한도를 다 써서 답을 못 끝냈고, 끝까지 쓴 회차들은 목표의 81.0퍼센트에서 142.4퍼센트 사이로 흔들렸어요.

넷째, 아래 표에 실은 회차 중에서는 코드 실행 도구를 켠 쪽만 값이 딱 맞았어요. 9번 요청해 응답을 받은 7번이 전부 공백 포함 500자였어요. 못 받은 2번은 요청이 반복 실패해 응답 자체를 못 받은 회차예요. 표에 싣지 않은 예비 회차 이야기는 뒤에서 따로 적을게요.

여기까지가 요지예요. 아래부터는 어떤 조건에서 잰 숫자인지를 먼저 못박고, 회차별 원값을 그대로 늘어놓을게요.

어떤 조건에서 쟀는지 먼저 못박을게요

숫자보다 조건이 먼저예요. 조건이 바뀌면 값도 바뀌는 종류의 측정이거든요.

요청 문장도 그대로 적을게요. 세 가지를 썼어요.

• A 이내형: "가정에서 여름철 전기 요금을 줄이는 방법에 대해 N자 이내로 설명해 줘. 마크다운 없이 줄글로만 써 줘."
• B 정확형: "…에 대해 정확히 N자로 써 줘. 글자 수를 정확히 맞춰 줘. 마크다운 없이 줄글로만 써 줘."
• D 코드실행형: "…에 대해 공백을 포함해 정확히 N자인 한국어 글을 써 줘. 코드 실행으로 글자 수를 직접 세어 확인하고, N자가 될 때까지 고친 뒤 최종 본문만 출력해 줘."

글자 수를 세는 기준은 공백 포함을 1차로 잡았고, 공백을 뺀 값과 한글 음절만 센 값도 함께 기록해 뒀어요. 다만 요청 문장에 기준을 안 밝히면 모델이 어느 쪽으로 셀지는 정해지지 않아요. A와 B 요청에는 일부러 기준을 안 넣었고, D 요청에만 "공백을 포함해"를 넣었어요.

"N자 이내로" 18번 원값 — 17번이 목표 아래

먼저 가장 흔한 요청 형식이에요. 목표를 300자, 500자, 1000자 세 가지로 두고 모델을 바꿔 가며 18번 돌렸어요. 목표 대비 비율은 실측 글자 수를 목표로 나눈 값이에요.

18번 중 17번이 목표 아래였고, 목표와 정확히 맞은 회차는 없었어요. 목표별로 묶으면 이래요.

• 목표 300자 6번 → 172 · 203 · 225 · 240 · 243 · 256자
• 목표 500자 9번 → 318 · 369 · 379 · 400 · 417 · 444 · 459 · 470 · 583자
• 목표 1000자 3번 → 733 · 871 · 925자

같은 모델에 같은 문장을 넣었는데도 회차마다 크게 갈렸다는 점을 눈여겨봐 주세요. 목표 300자에서 gemini-2.5-flash는 172자와 225자를 각각 내놨어요. 그래서 이 글은 "평균 몇 퍼센트가 나온다" 같은 고정 비율을 제시하지 않아요. 비율을 하나로 못박을 만큼 안정적인 값이 아니었어요.

한 가지 더 밝혀 둘게요. 본 집계 앞에 gemini-3.7-flash로 돌린 예비 회차가 있었어요. 이 회차 결과는 유리한 쪽만 고르지 않고 전부 적을게요.

"300자 이내로" 요청 3번에서는 221자, 233자, 231자가 나와 역시 전부 미달이었어요. 그런데 같은 예비 회차에서 "정확히 300자로" 요청도 3번 넣었고, 두 번은 응답을 못 받았지만 나머지 한 번은 공백 포함 정확히 300자가 나왔어요. 코드 실행을 켜지 않은 요청이 목표에 딱 맞은 회차가 이 한 번 있었다는 뜻이에요. 요청 문장도 출력 한도도 아래 "정확히 N자로" 회차와 같은 조건이었고요.

이 예비 회차는 응답을 못 받은 요청이 여럿이라 요청 형식마다 회차가 채워지지 않았고, 그래서 위 18번 집계에서 통째로 뺐어요. 그러니 이 글이 "정확히 맞은 회차가 0번"이라고 적는 범위는 전부 표에 실은 회차이고, 표 밖에는 위의 한 번이 있어요.

"이내"의 두 얼굴 — 6할에서 9할, 그런데 상한도 아니에요

여기가 이 글에서 가장 헷갈리기 쉬운 자리예요. 두 갈래로 갈라 적을게요.

첫째 갈래. "이내"로 미달이 난 것 자체는 지시 위반이 아니에요. 상한을 정하는 말이니까 400자가 나와도 500자 이내는 맞거든요. 문제는 쓰는 사람의 목적이 대개 상한이 아니라 분량이라는 점이에요. 정해진 칸을 채워야 하는데 6할만 채워 오면 쓸 수 없는 결과예요.

둘째 갈래. 그렇다고 상한이 지켜지는 것도 아니었어요. 위 표 마지막 줄의 583자가 그 사례예요. 이 회차의 종료 사유는 STOP이었어요. 출력 한도에 걸려 잘린 게 아니라 모델이 다 썼다고 판단하고 끝낸 응답이 상한을 넘긴 것이에요.

정리하면 "이내"는 이렇게 굴러가요.

그래서 분량이 중요한 문서라면 "이내"라는 말 하나에 기대는 방식은 권하기 어려워요. 프롬프트를 다듬는 요령 전반은 프롬프트 작성 요령을 정리한 글에 따로 적어 뒀어요.

"정확히 N자로" — 한 모델은 9번 다 답을 못 끝냈어요

요청 문장을 "정확히 N자로 써 줘. 글자 수를 정확히 맞춰 줘."로 바꿔 봤어요. 여기서 결과가 두 갈래로 갈렸어요.

먼저 gemini-3.5-flash 쪽이에요. 목표 300자, 500자, 1000자로 각 3번씩 총 9번을 돌렸는데 9번 모두 종료 사유가 MAX_TOKENS였어요. 제가 건 출력 한도 8,192토큰을 다 써서 응답이 중간에 끊겼다는 뜻이에요.

무엇에 한도를 다 썼는지가 재미있는 자리예요. 잘린 응답 안에 이런 흔적이 그대로 남아 있었어요.

50->공50)기(51) (52)보(53)존(54)에(55) (56)큰(57) (58)도(59)움(60)이(61) (62)됩(63)니(64)다(65).(66) 66 characters. We need 72.

글자마다 괄호로 번호를 매기고 있어요. 그러니까 모델이 최종 본문을 쓴 게 아니라 세는 과정을 출력에 쏟아붓다가 한도에 걸린 거예요. 이 9번의 잘린 응답에서 한글 음절만 따로 세면 41자에서 258자 사이로 무너져 있는데, 출력 대부분이 본문이 아니라 세는 과정이었기 때문이에요.

여기서 조심할 자리가 있어요. 이 9번을 "모델이 글자를 못 센다"로 읽으면 어긋나요. 정확한 서술은 "내가 건 8,192토큰 한도 안에서 끝내지 못했다"예요. 한도를 더 크게 주면 결과가 달라질 수 있고, 이 글은 더 큰 한도로는 재지 않았어요.

끝까지 쓴 8번도 81.0퍼센트에서 142.4퍼센트 사이로 흔들렸어요

같은 "정확히 N자로" 요청이라도 다른 세 모델은 답을 끝까지 냈어요. 그 8번의 원값이에요.

정확히 맞은 회차는 0번이에요. 다만 방향이 달라졌다는 점은 눈에 띄어요. "이내"에서는 18번 중 17번이 아래쪽으로만 쏠렸는데, "정확히"에서는 8번 중 4번이 위, 4번이 아래로 갈렸어요. 목표를 중심에 두고 양쪽으로 흩어진 모양이에요.

494자와 518자처럼 꽤 가까운 값도 있었어요. 그래서 "대충 그 언저리면 된다"는 용도라면 "정확히 N자로"가 "N자 이내로"보다 나은 선택이었어요. 반대로 한 글자도 어긋나면 안 되는 용도라면 둘 다 답이 아니에요.

코드 실행을 켰더니 — 응답을 받은 7번이 모두 공백 포함 500자였어요

여기부터는 요청 문장이 아니라 도구를 하나 붙인 회차예요. 제미나이에는 파이썬 코드를 실제로 돌려 보는 코드 실행 기능이 있어요. 공식 문서가 적어 둔 제약은 이래요.

Gemini is only able to execute code in Python. The maximum runtime of the code environment is 30 seconds. You can't install your own libraries.

이 도구를 켜고 gemini-3.5-flash 한 모델에 같은 주제, 같은 목표(500자)로 요청을 넣었어요. 다만 요청 문장은 앞의 두 형식과 달라요. "공백을 포함해"와 "코드 실행으로 글자 수를 직접 세어 확인하고, 500자가 될 때까지 고친 뒤 최종 본문만 출력해 줘"를 넣었어요. 출력 한도도 이 회차만 16,384토큰으로 올렸는데, 도구 호출에 쓰이는 토큰이 따로 붙는 회차라 넉넉히 잡아 둔 것이고 8,192에서 어떻게 되는지는 재지 않았어요.

돌린 회차를 실패한 것까지 전부 적을게요. 두 차례에 나눠 총 9번 요청했어요.

9번 중 응답을 받은 7번이 전부 공백 포함 500자로 맞았어요. 한 자도 어긋나지 않았고, 앞의 두 요청 형식과 달리 회차 간 편차 자체가 없었어요.

못 받은 2번은 요청이 반복 실패해 응답을 못 받은 회차인데, 두 회차의 사정이 서로 달라요. 6회차는 사유가 API 사용량 한도(429)로 로그에 그대로 남았고, 30초 간격에서 3분 간격까지 늘려 가며 여섯 번 다시 요청했는데도 응답이 오지 않았어요. 2회차는 15초에서 60초 간격으로 네 번 재시도한 뒤 소진됐는데, 그때 쓴 계측 스크립트가 응답 코드를 남기지 않아 사유를 확인하지 못했어요. 어느 쪽이든 모델이 틀린 값을 낸 게 아니라 요청 자체가 통과하지 못한 것이라 표에 실패로 남겼어요.

왜 갈렸는지는 앞 절과 이어져요. "정확히 N자로"에서 모델은 글자마다 번호를 붙여 가며 자기 머릿속에서 세려고 했어요. 코드 실행을 켜면 그 일을 파이썬이 맡아요. 세고, 모자라면 고치고, 다시 세는 왕복이 출력이 아니라 도구 안에서 돌아가죠.

다만 여기에 붙는 단서가 셋이에요.

• 표본이 작아요. 성공 7번이고, "항상 맞는다"를 말할 수 있는 크기가 아니에요.
• 한 모델에서만 켜 봤어요. 코드 실행 회차는 gemini-3.5-flash 하나예요. 나머지 세 모델에서는 이 도구를 켜지 않았어요.
• 공식이 권한 방법이 아니에요. 같은 문서는 이 기능의 쓸모를 "solve equations or process text"로 예시해 두긴 했어요. 다만 "글자 수를 세라"고 짚은 문장은 찾지 못했고, 위에 옮긴 인용도 그 기능의 제약을 적은 대목이에요. 글자 세기 용도로 쓴 건 제 판단이에요.

그래서 이 절의 결론은 이 정도까지예요. 정확한 글자 수가 꼭 필요하면 지시로 부탁하는 대신 실제로 세는 수단을 붙이는 쪽이 이번 측정에서는 맞았어요.

왜 못 세는가 — 모델이 다루는 단위가 글자가 아니에요

여기서 잠깐 배경을 짚을게요. 구글 공식 문서가 적어 둔 문장이 있어요. 「Understand and count tokens」 페이지예요.

For Gemini models, a token is equivalent to about 4 characters. 100 tokens is equal to about 60-80 English words.

「Prompt design strategies」 페이지도 같은 취지로 적어요.

Max output tokens: Specifies the maximum number of tokens that can be generated in the response. A token is approximately four characters.

즉 모델이 세는 단위는 토큰이고, 글자는 그 토큰을 풀어야 나오는 값이에요. 게다가 위 문장의 "약 4자"는 문서가 언어를 특정하지 않은 어림값이고 바로 뒤에 붙는 환산만 영어 단어 기준이라, 한국어에서 그대로 통하는지는 따로 재야 해요. 한국어 문장이 토큰으로 얼마가 되는지는 한국어 토큰 수를 직접 세어 본 글에 따로 적어 뒀어요. 그 글의 수치를 여기서 다시 옮기지는 않을게요.

그래서 모델 입장에서 "정확히 500자"는 자기가 직접 조절할 수 있는 값이 아니에요. 다 쓰고 나서 세어 봐야 알 수 있는 값이죠. 위 3.5-flash 회차가 글자마다 번호를 매기고 있었던 것도 그래서예요. 직접 다룰 수 없으니 손으로 세는 흉내를 내다가 한도를 다 쓴 것이에요.

길이를 거는 파라미터는 토큰 단위 하나뿐이에요

그럼 API 쪽에서 길이를 걸어 줄 수는 없을까요. 확인해 봤어요.

Gemini API의 REST 레퍼런스에서 생성 설정을 담는 GenerationConfig 필드 목록을 전부 받아 이름을 뽑아 봤어요. 잡힌 이름은 stopSequences, responseMimeType, responseSchema, responseJsonSchema, responseModalities, candidateCount, maxOutputTokens, temperature, topP, topK, seed, presencePenalty, frequencyPenalty, responseLogprobs, logprobs, enableEnhancedCivicAnswers, speechConfig, thinkingConfig, imageConfig, mediaResolution, enableAffectiveDialog, responseFormat, translationConfig, audioTranscriptionConfig였어요.

이 중 길이와 관련된 건 둘뿐이에요.

그리고 같은 페이지 전문에서 characters, character count, maxOutputCharacters, maxChars를 찾아 봤는데 글자 수 단위로 길이를 거는 필드는 이 목록에 없었어요. characters라는 단어가 나오는 자리는 stopSequences 설명의 "character sequences" 하나였고요.

정리하면 이래요. 글자 수는 모델도 API도 직접 다루지 않는 단위예요. 그래서 지시로 부탁하는 수밖에 없고, 부탁은 위 표들처럼 흔들려요. 이건 모델이 게을러서가 아니라 구조가 그렇게 생긴 거예요.

한 가지 밝혀 둘게요. 구글 공식 문서가 "정확한 글자 수 지시를 모델이 못 지킨다"고 인정한 문장은 찾지 못했어요. 공식 안내 페이지 여러 곳을 열어 봤지만 그런 서술은 확인하지 못했어요. 그래서 이 글의 준수 실패 이야기는 전부 제 실측이고, 공식 문서 인용은 위에 옮긴 토큰 관련 문장까지예요.

오늘부터 이렇게 요청해 보세요 — 5단계

읽기만 하면 안 바뀌니 순서를 정해 둘게요. 위 측정에서 나온 성질을 그대로 뒤집은 순서예요.

1. 분량이 목적이면 "이내"를 빼세요. 상한을 정하는 말이라 목적과 어긋나요. "500자로 써 줘"나 "정확히 500자로 써 줘"가 목표를 중심에 두는 표현이에요.
2. 미달을 감안해 목표를 크게 부르세요. 이내형에서 미달이 난 17번이 목표의 57.3퍼센트에서 94.0퍼센트 사이에 떨어졌어요. 이 비율을 그대로 뒤집으면 500자를 채우려면 532자에서 873자 사이를 불러야 한다는 계산이 나와요. 폭이 이렇게 넓다는 게 요점이라, 실제로 몇 자를 불러야 할지는 쓰시는 모델에 몇 번 넣어 보고 정하는 편이 정확해요. 이 값은 위 비율에서 거꾸로 계산한 것이지 따로 재 본 값은 아니에요.
3. 세기 쉬운 단위로 바꿔 보세요. "다섯 문장으로", "세 문단으로", "각 항목 두 줄씩"처럼 출력에 그대로 드러나는 단위가 글자보다 확인하기 쉬워요. 다만 문장 수 지시가 실제로 얼마나 지켜지는지는 이 글이 따로 재지 않았어요.
4. 한 글자도 못 어긋나면 세는 수단을 붙이세요. 코드 실행처럼 실제로 세는 도구가 붙으면 결과가 달라졌어요. 위 표의 범위 안에서요.
5. 받은 뒤에 직접 세는 단계를 남겨 두세요. 문서 편집기의 글자 수 세기로 충분해요. 위 18번 중 목표에 정확히 맞은 회차가 0번이었으니, 세는 단계를 건너뛰면 결국 어긋난 채로 제출하게 돼요.

특히 2번과 5번을 같이 쓰면 왕복이 확 줄어요. 크게 불러서 받고 사람이 잘라내는 방식이요. 질문 문장을 다듬을 때 자주 어긋나는 자리는 질문 프롬프트에서 흔한 실수를 모은 글에 정리해 뒀어요.

확인하지 못한 것과 조심할 점

경계를 분명히 해 둘게요. 이 글이 못 한 것들이에요.

첫째, 다른 회사 모델이에요. 이번에 잰 건 제미나이 계열 4개 모델뿐이에요. 챗GPT와 클로드는 호출할 키가 없어 같은 조건으로 재지 못했어요. 그래서 이 글의 숫자를 "AI 전반이 이렇다"로 넓혀 읽으면 어긋나요.

둘째, 조건에 딸린 값이라는 점이에요. 출력 한도, 주제, 언어를 다 고정하고 잰 값이에요. 특히 9번이 전부 잘린 회차는 제가 건 8,192토큰 한도의 결과라, 한도를 키우면 달라질 수 있어요.

셋째, 표본 크기예요. 요청 형식별로 8번에서 18번씩이고, 코드 실행 회차는 9번 중 성공이 7번이에요. 평균을 말할 표본이 아니라서 이 글은 회차별 원값과 범위로만 적었어요.

넷째, 다른 주제와 다른 언어예요. 주제 하나, 한국어로만 쟀어요. 영어로 같은 요청을 넣으면 비율이 달라지는지는 확인하지 못했어요.

다섯째, 글자 수 세는 기준이에요. 공백 포함으로 셌고 공백 제외 값도 함께 기록했지만, 요청 문장에 기준을 밝히지 않으면 모델이 어느 쪽으로 셀지는 정해지지 않아요. 이 점이 결과를 얼마나 흔드는지는 따로 재지 않았어요.

여섯째, 코드 실행이 공식 권장 해법이라는 근거예요. 구글 문서에서 "글자 세기에는 코드 실행을 쓰라"는 취지의 문장은 찾지 못했어요. 그래서 이 글은 코드 실행을 공식 권장이 아니라 제가 켜서 재 본 결과로만 적었어요.

일곱째, 코드 실행을 켠 모델 범위예요. 이 도구를 켠 회차는 gemini-3.5-flash 하나예요. 나머지 세 모델에서도 같은 결과가 나오는지, 500자가 아닌 다른 목표에서도 맞는지는 재지 않았어요.

여덟째, 코드 실행 회차에서 한꺼번에 바뀐 조건이에요. 이 회차는 도구만 켠 게 아니라 요청 문장("공백을 포함해", "세어 확인하고")과 출력 한도(16,384토큰)까지 함께 달라요. 그래서 값이 딱 맞은 것이 도구 덕분인지 요청 문장 덕분인지는 이 글이 갈라 재지 않았어요. 한 번에 하나씩만 바꿔 다시 재야 갈리는 자리예요.

정리

• 제미나이 계열 4개 모델에 "N자 이내로"를 18번 넣었더니 17번이 목표 아래였고, 목표의 57.3퍼센트에서 94.0퍼센트 사이에 흩어졌어요.
• 남은 한 번은 583자로 상한을 넘겼고 그 응답은 잘린 게 아니라 정상 종료된 상태였어요. "이내"는 상한 보장이 아니에요.
• "정확히 N자로"는 한 모델에서 9번 모두 제가 건 출력 한도 안에서 답을 끝내지 못했고, 끝까지 쓴 8번은 목표의 81.0퍼센트에서 142.4퍼센트 사이로 흔들렸어요.
• 표에 실은 회차 중에서는 코드 실행 도구를 켠 쪽만 값이 딱 맞았어요. gemini-3.5-flash에 9번 넣어 응답을 받은 7번이 전부 공백 포함 500자였고, 못 받은 2번은 요청이 반복 실패해 응답을 못 받은 회차예요(사유가 사용량 한도로 로그에 남은 건 그중 한 번). 이 도구를 켠 모델은 하나뿐이고, 이 회차는 요청 문장과 출력 한도도 함께 달랐어요.
• 못 맞추는 구조적 이유는 모델이 다루는 단위가 토큰이기 때문이에요. 공식 문서는 토큰 하나를 약 4자로 적고, 바로 뒤 문장에서 100토큰을 영어 단어 60개에서 80개로 환산해요.
• API에서 길이를 거는 필드도 토큰 단위 maxOutputTokens 하나이고, 글자 수 단위 필드는 REST 레퍼런스의 GenerationConfig 목록에 없었어요.
• 실무에서는 목표를 크게 불러 받고 사람이 줄이거나, 문장 수처럼 세기 쉬운 단위로 바꾸는 편이 왕복이 적어요.

지금 화면에서 할 수 있는 가장 짧은 확인은 이거예요. 쓰시는 AI에 "정확히 500자로 써 줘"를 세 번 넣고 받은 글을 세어 보세요. 세 번이 같은 값이 나오는지, 목표와 얼마나 벌어지는지를 보면 그 모델에 얼마를 불러야 할지가 정해져요. 이 글의 숫자는 제미나이 계열 4개 모델의 값이라 다른 모델에서는 다르게 나올 수 있어요.

확인한 자료: 구글 Gemini API 공식 문서 「Understand and count tokens」(페이지 표기 최종 갱신 2026-08-17 UTC), 「Prompt design strategies」(2026-06-10 UTC), 「Code execution」(2026-08-17 UTC), REST 레퍼런스 「Generating content」의 GenerationConfig(2026-08-17 UTC). 전부 2026년 8월 20일에 직접 조회했어요. 실측값은 같은 날 generateContent 엔드포인트를 직접 호출해 받은 응답을 센 값이에요.