긴 프롬프트를 작성하다 보면 문득 손이 멈출 때가 있습니다.

「이것은 어디까지 써도 괜찮은 걸까」

사양서를 붙여넣고, 참고 코드를 붙여넣고, 주의사항을 나열합니다. 에러는 나지 않고, 답변도 돌아옵니다. 다만, 초반부의 지시가 어쩐지 무시되고 있다는 느낌이 듭니다. 많은 분이 경험해 본 적 있는 감각이 아닐까요.

본 기사에서는 다음 4가지 질문을 순차적으로 검토합니다.

• 프롬프트는 어느 정도 길이까지 가능한가
• 경계값은 어디에 있는가
• AI가 "헤매지 않는" 범위는 어디까지인가
• 인간은 무엇을 판별해야 하는가

먼저, 이른바 "컨텍스트 윈도우 (Context Window)" 이야기부터 시작하겠습니다.

2026년 현재, 주요 모델의 대부분은 100만 토큰급의 컨텍스트에 대응하고 있으며, 몇 년 전 "긴 편"이라고 여겨졌던 200K 토큰은 이제 표준보다 한 단계 낮은 위치가 되었습니다. 100만 토큰은 일본어로 수십만~백만 자 정도의 규모입니다. 문고본 수 권 분량에 해당합니다.

첫 번째 질문에 대한 답은 사실 여기서 나옵니다.

「가능"하다는 의미라면, 손으로 쓰는 프롬프트가 상한에 도달하는 일은 거의 없습니다.

3,000 토큰 정도의 기사 1개를 100만 토큰 모델에 전달해도 그릇의 0.3%밖에 사용하지 않습니다. "길이의 상한"은 적어도 일상적인 프롬프트에 있어서는 실질적인 제약이 아닙니다.

하지만 이야기는 여기서 끝나지 않습니다. 문제는 "들어가는가"가 아니라, **"제대로 읽을 수 있는가"**이기 때문입니다.

"경계값"에는 3가지 층이 있다고 정리할 수 있습니다.

까다로운 것은 ②입니다. 2025년에 Chroma가 발표한 "Context Rot"에 관한 연구는, 모델은 컨텍스트를 균일하게 사용하지 않으며, 입력이 길어질수록 성능이 불안정하고 불균일하게 저하된다는 것을 보여주었습니다. 100만 토큰이 "들어가는" 것과 100만 토큰 분량을 "읽는" 것은 별개의 문제입니다.

또 하나, 잘 알려진 현상이 "Lost in the Middle"입니다.

프롬프트의 앞부분과 뒷부분에 놓은 정보는 잘 참조되는 반면, 중간에 묻어둔 정보는 놓치기 쉽다는 경향이 있습니다. 긴 자료의 중간 부분에 중요한 제약 사항을 적었더니 반영되지 않았다——라는 경험은 많은 분이 짐작할 수 있을 것입니다.

경계값에 대한 답은 다음과 같이 정리할 수 있습니다.

에러가 발생하는 경계(공칭 상한)보다 훨씬 앞선 지점에, "조용히 망가지기 시작하는 경계"가 있습니다. 그것은 숫자가 아니라 동작으로만 관측할 수 있습니다.

AI가 헤매기 시작하는 트리거는 토큰 수 그 자체인 경우가 많지 않습니다. 원인은 대체로 다음 3가지로 집약됩니다.

"~해 주세요"가 30개 나열된 프롬프트를 상상해 보세요. 개별 지시가 올바르더라도 우선순위가 제시되어 있지 않으면, 모델은 무엇을 중시해야 할지 판단하지 못하고 모든 것을 얕게 지키는——결과적으로 어느 하나도 제대로 되지 않는——동작에 빠지기 쉽습니다.

"간결하게. 하지만 자세히. 전문 용어는 피해서. 하지만 정확하게". 인간도 헤매는 지시입니다. 프롬프트가 길어질수록 작성자 본인이 모순을 깨닫지 못하게 됩니다. 이것이 전절의 ③ 체감 상한의 정체이며, AI가 헤매기 전에 인간이 미아가 되어 있는 케이스가 적지 않습니다.

"만약을 위해" 붙여넣은 과거 로그나 별개의 자료. 롱 컨텍스트(Long Context) 시대의 함정은 여기에 있으며, 관련성이 낮은 정보를 채워 넣으면 Context Rot에 의해 오히려 정밀도가 떨어진다는 것이 알려져 있습니다. "전부 넣어두면 안심"은 안티 패턴(Anti-pattern)입니다.

그렇다면 헤매지 않는 범위는 어디까지일까요. 기준을 굳이 한마디로 한다면,

작성자 본인이 모든 지시와 그 우선순위를 설명할 수 있는 범위까지입니다.

본인이 파악하지 못하는 지시의 묶음은 모델에게도 우선순위를 읽을 수 없는 지시의 묶음입니다. 헤드라인이나 불렛 포인트, XML 태그를 이용한 구조화는 이 한계를 넓혀주지만, 그럼에도 "길고 정리된 지시"가 "짧고 명확한 지시"를 이기는 상황은 많지 않습니다.

마지막 질문입니다. 인간 측은 무엇을 판별해야 할까요.

실무에서는 정보를 넣기 전에 다음 3점을 확인하는 것이 유효합니다.

이 정보가 없어도 답이 바뀌는가 → 바뀌지 않는다면 삭제한다. "만약을 위해"를 의심한다 -
최우선 지시는 앞부분이나 뒷부분에 있는가 → 중간에 묻혀 있다면 이동시킨다 (그림 1 참조) -
모순이 없다고 스스로 설명할 수 있는가 → 설명할 수 없는 양이라면 이미 너무 길다

또 다른 설계상의 판단 기준을 하나 더 제시하겠습니다. 방대한 자료를 다룰 때 선택지는 '전문 투입 (Full-text injection)'만 있는 것이 아닙니다. 먼저 RAG나 요약으로 범위를 좁히고, 범위를 좁힐 때 손실되는 문맥이 있는 경우에만 롱 컨텍스트 (Long Context)에 의존한다 —— 이것이 2026년 시점에서도 비용과 정밀도 양면에서 정석적인 방법으로 여겨집니다. 롱 컨텍스트는 일상적인 도구가 아니라, 히든카드(切り札)입니다.

컨텍스트 윈도우 (Context Window)의 확대는 '무엇이든 넣을 수 있는 자유'를 가져다주었습니다. 그것은 동시에, '무엇을 넣지 않을지를 결정하는 책임'이 인간 측으로 옮겨졌음을 의미하기도 합니다.

프롬프트 설계란, 쓰는 기술인 동시에 깎아내는 기술입니다.

어디까지 가능한가 → 공칭 상한은 100만 토큰급. 수기로 작성하는 프롬프트로 도달하는 일은 거의 없다
경계값은 → 에러가 발생하는 경계 직전에 '조용히 정밀도가 떨어지는 경계'가 존재한다 (Context Rot / Lost in the Middle)
AI가 헤매지 않는 기준은 → 길이보다는 지시의 수, 모순, 노이즈에 달려 있음. 기준은 '자신이 모든 지시를 설명할 수 있는 범위'
인간의 판단 기준은 → '들어가는가'가 아니라 '필요한가'를 묻는 것

당신의 프롬프트 중 정말로 필요한 정보는 몇 할입니까? 저 자신도 이 글을 다 쓰고 나면 자신의 템플릿을 다시 검토할 생각입니다.

• Chroma 「Context Rot: How Increasing Input Tokens Impacts LLM Performance」(2025)
• Liu et al. 「Lost in the Middle: How Language Models Use Long Contexts」(2023)
• 각 사 모델의 공칭 컨텍스트 길이 (2026년 시점의 공식 문서. 수치는 업데이트되므로 최신 정보는 각 사의 공식 정보를 참조)

※ 그림 1·그림 2는 실측 데이터가 아니라, 경향을 설명하기 위한 개념도입니다.