긴 글 작성의 함정: AI의 5000자 출력 한계를 마주하다

긴 글 작성의 함정: AI의 5000자 출력 한계를 마주하다

---

이 현상을 마주하고 분석하는 과정은 AI 활용의 한계를 깨닫게 해 준 중요한 계기가 되었다.

위 화면은 AI가 긴 글을 작성하다가 문장을 채 완성하지 못하고 강제로 출력이 끊긴 모습이다. 서버 에러도, 네트워크 오류도 아닌 이 현상의 원인을 밝혀야만 했다.

"엔터 한 번에 A4 3장 분량의 안정적인 리포트가 나올까?"

회사를 운영하다 보면 가장 품이 많이 드는 일 중 하나가 '깊이 있는 텍스트'를 생산하는 것입니다. 고객을 설득하는 상세한 서비스 소개글, 기술적 인사이트를 담은 전문 블로그 포스팅, 그리고 논리 정연한 기획서까지. 비즈니스의 가치를 제대로 전달하려면 짧은 카피라이팅을 넘어 호흡이 긴 웰메이드 콘텐츠가 반드시 필요합니다.

하지만 늘 그렇듯 우리의 시간은 턱없이 부족합니다. 그래서 저는 한 가지 야심 찬 목표를 세웠습니다. '단순한 문구 작성을 넘어, 서론부터 결론까지 안전하게 짜인 긴 글을 AI가 한 번에 써내게 만들자.'

그동안 이메일 초안이나 마케팅 문구를 쓸 때 보여준 AI의 탁월한 퍼포먼스를 생각하면, 아주 정교한 프롬프트 하나만 있으면 충분히 가능할 것 같았습니다. 주제, 타깃 독자, 핵심 키워드, 심지어 글의 어조까지 세밀하게 세팅한 뒤, 가장 중요한 명령어를 덧붙였습니다.

"분량은 최대한 상세하게, 최소 A4 3장 이상으로 작성할 것."

엔터를 누르고 커피를 한 잔 내리며 기대감에 부풀었습니다. 화면을 꽉 채우는 방대한 텍스트가 마법처럼 쏟아지길 바라면서요.

허공에서 뚝 끊겨버린 마침표

하지만 모니터에 출력된 결과물은 당혹스러웠습니다. 서론은 지시한 의도대로 매끄러웠고, 본론의 논리 전개도 훌륭했습니다. 글이 한창 흥미진진해지며 핵심으로 들어가려던 바로 그 찰나, 텍스트가 갑자기 멈췄습니다.

"따라서 우리가 이 문제를 해결하기 위해서는 가장 먼저..."

마침표조차 찍히지 않은 채 출력이 강제로 종료된 것입니다. 일시적인 네트워크 오류인 줄 알고 두세 번 다시 스크립트를 돌려보았지만 결과는 같았습니다. 내용만 조금씩 바뀔 뿐, 늘 비슷한 글자 수에 도달하면 글이 절단되는 현상이 반복되었습니다. 글이 중간에 끊기는 현상이 계속되자, 문제의 진짜 원인을 찾기 위한 심층 분석에 들어갔다.

AI 자동 발행 과정에서 발생한 출력 한계를 분석하는 모습

분석 결과, 이는 프롬프트의 퀄리티 문제가 아니라 AI 모델 자체의 물리적인 출력 한계점 때문이라는 사실을 알게 되었다.

프롬프트의 문제가 아니었다

처음에는 제 프롬프트가 모호한 탓이라고 생각했습니다. AI가 '길게 쓰라'는 지시를 이해하지 못했거나 스스로 할 말을 잃었다고 착각한 것이죠.

그래서 프롬프트에 강박적인 지시어들을 추가하기 시작했습니다. * "결코 중간에 멈추지 마라." * "반드시 결론까지 도출하고 마침표를 찍어라." * 심지어 출력이 끊기면 "Continue(계속해)"를 자동 입력하는 스크립트도 짜보았습니다.

결과는 처참했습니다. 억지로 이어 쓰기를 강제하자 AI는 앞서 자신이 쓴 문맥을 잊어버리고 엉뚱한 소리를 하거나, 갑자기 문체를 바꿔버렸습니다. 글의 전체적인 품질이 와르르 무너져 내린 것입니다. 그제야 저는 깨달았습니다. 이것은 프롬프트의 문제가 아니라, 물리적인 한계라는 것을요.

물리적 장벽, '최대 출력 토큰(Max Tokens)'의 비밀

API 공식 문서와 시스템 로그를 파고든 끝에 진짜 원인을 찾았습니다. 모든 AI 모델에는 한 번의 요청으로 뱉어낼 수 있는 텍스트의 상한선, 즉 '최대 출력 토큰(Max Tokens)' 제한이 하드코딩되어 있었습니다.

한국어 기준으로 이 한계치는 대략 5,000자 내외에서 형성됩니다. 아무리 프롬프트를 화려하게 깎아도 시스템이 허용하는 데이터의 최대치를 넘을 수는 없었던 것입니다. 더 치명적인 것은, AI가 이 한계치에 가까워질수록 연산 능력이 떨어져 같은 말을 반복하거나 논리가 빈약해지는 '품질 저하' 현상까지 발생한다는 점이었습니다.

시스템의 명확한 제약을 이해하지 못한 채 무작정 "길게 써!"라고 윽박지른 제 접근 방식은 시작부터 틀려있었습니다.

한계를 돌파하는 기술: '쪼개고 합치는' 파이프라인

원인을 알았으니 해결책은 명확해졌습니다. 한 번의 호출로 모든 것을 끝내겠다는 탐욕을 버리고, 작업을 영리하게 쪼개는 '청킹(Chunking)' 방식을 도입했습니다.

저는 단일 프롬프트를 버리고, 다음과 같은 단계별 파이프라인을 구축했습니다.

1. 개요 생성 (Outline): AI에게 전체 글의 목차(서론, 본론 1, 2, 결론)만 먼저 짜도록 지시합니다.
2. 단락별 독립 생성: 파이썬 스크립트를 통해 각 목차별로 API를 따로 호출합니다. 이때 "이전에 작성된 서론의 내용은 이러하다. 이 문맥을 이어받아 본론 1을 작성해라"라며 이전 단락의 요약본을 함께 넘겨줍니다.
3. 병합 (Merge): 생성된 각 단락을 하나의 글로 자연스럽게 합칩니다.

결과는 대성공이었습니다. 글이 중간에 끊기는 불상사는 성공적히 사라졌고, AI가 한 번에 집중해야 할 분량이 줄어들다 보니 각 단락의 깊이와 논리는 이전보다 훨씬 풍부해졌습니다.

AI는 요술봉이 아니라 '설계'의 영역이다

이번 삽질(?)을 통해 얻은 가장 큰 교훈은 "AI는 요술봉이 아니다"라는 사실입니다. 무거운 짐을 한 번에 들게 하면 쓰러지지만, 작게 나누어 들게 하면 에베레스트산 꼭대기라도 옮길 수 있습니다.

단 하나의 안정적인 프롬프트를 찾으려는 노력은 초보적인 단계입니다. 실무에서 진짜 의미 있는 자동화를 이루어내려면, AI 모델의 기술적 한계를 명확히 이해하고 이를 우회할 수 있는 '시스템'을 설계해야 합니다. 작업의 단계를 정의하고 각 단계에 맞는 역할을 부여해 조립하는 것, 그것이 진정한 AI 엔지니어링의 핵심입니다.

다음을 위한 남겨진 과제: '윤문'의 마법

출력 제한이라는 거대한 산은 넘었지만, 파이프라인의 완성도를 높이기 위해 해결해야 할 디테일이 하나 남았습니다. 여러 번 나누어 쓴 글을 기계적으로 합치다 보니, 단락과 단락 사이의 접속사가 어색하거나 톤앤매너가 미묘하게 튀는 현상이 발생한 것입니다.

그래서 다음 스텝으로는 이 파이프라인의 맨 마지막에 '윤문 전용 프롬프트' 단계를 추가해 보려 합니다. 내용의 훼손 없이, 마치 한 사람의 전문가가 처음부터 끝까지 한 호흡으로 유려하게 써 내려간 듯한 연결고리를 만드는 로직입니다.

기계의 한계를 극복하는 과정은 늘 피곤하고 지난합니다. 하지만 그 끝에 얻어지는 '압도적인 생산성'이라는 결과물은, 이 모든 과정을 감내할 만큼 충분히 매력적입니다. 다음 에피소드에서는 이 투박한 글을 매끄럽게 다듬어내는 '윤문 파이프라인'의 비밀을 공유해 드리겠습니다.