프롬프트는 길다고 좋은 것이 아닙니다. 과제의 목표, 핵심 배경, 양보할 수 없는 요구를 적고 나면 그 위에 쌓는 내용은 한계 효용이 금세 0이 되고, 오히려 결과를 해칩니다. 요구끼리 충돌하면 모델은 손쉬운 쪽을 실행하고, 중점이 묻히면 주종을 놓치며, 예시와 과제가 어긋나면 예시에 끌려갑니다. 판단 기준은 단순합니다. 한 단락을 지워도 결과가 그대로면 그 단락은 원래 없어도 되는 것이었습니다.
너무 길어서 망가지는 세 곳
첫째, 주의력이 얇게 퍼집니다. 프롬프트 하나에 요구를 십여 개 욱여넣으면 각 요구의 실행이 할인됩니다. 전형적인 증상은 형식은 맞는데 내용이 빠지거나, 앞부분은 잘하다가 마지막 요구를 통째로 잊는 것입니다. 요구가 많을수록 개별 요구가 진지하게 실행될 확률은 낮아집니다. 태도 문제가 아니라 작동 방식의 문제입니다.
둘째, 자기모순입니다. 긴 프롬프트는 대개 수정의 누적입니다. 앞에서는 간결하게 쓰라 하고 뒤에서는 자세히 펼치라 하며, 말투를 정해 놓고 뒤에 붙인 예시는 전혀 다른 문체인 식입니다. 충돌에 부딪힌 모델은 되묻지 않습니다. 하나를 무작위로 고르거나 절충해 버리고, 불안정한 출력 대부분이 여기서 옵니다.
셋째, 예시의 역효과입니다. 형식을 가르치려던 예시가 내용으로 함께 흡수됩니다. 예시 속 사실과 숫자, 말투가 본 작업에 섞여 들어가는 것입니다. 예시 세 개를 주면 예시에 나온 회사명이 정식 원고에 그대로 들어가거나, 예시의 길이만 흉내 내고 정작 처리해야 할 내용을 대충 넘길 수 있습니다.
먼저 지울 세 종류
첫째, 반복해서 말하는 부분입니다. 같은 일을 세 가지로 강조해도 모델이 더 중시하지 않고 자리만 차지합니다. 가장 구체적인 버전 하나만 남기고 나머지는 지우세요. 특히 반드시, 매우 중요, 절대 잊지 마 같은 순수 강조는 정보량이 0입니다.
둘째, 이번 과제와 무관한 배경입니다. 내가 누구인지, 회사가 무슨 일을 하는지, 일의 전후 사정 전부가 아니라 출력 판단에 실제로 영향을 주는 부분만 남기세요. 휴가 메일 하나 쓰면서 회사 소개를 한 페이지 붙이는 것이 전형적인 무게 죽음입니다.
셋째, 새 요구에 덮인 옛 요구입니다. 프롬프트를 고칠 때는 먼저 뺄셈을 하세요. 더 이상 맞지 않는 형식, 말투, 길이 지정을 지운 뒤 새것을 더합니다. 프롬프트는 여행 가방과 같아서 넣기만 하면 반드시 터집니다.
적당한 길이는 어떻게 아는가
만능 글자 수 기준은 없습니다. 뺄셈으로 판단하는 편이 확실합니다. 뒤에서부터 단락을 하나씩 지우고, 지워도 결과가 변하지 않는 단락은 계속 제거하다가, 다음을 지우면 정보가 빠지기 시작하는 지점에서 멈추세요. 남은 것이 그 과제의 적당한 길이입니다. 일상적인 글쓰기, 다듬기, 질의는 대개 몇 문장에서 두세 단락이면 충분합니다. 정말 긴 프롬프트가 필요한 경우는 고정 보고서 형식이나 다조건 심사 목록처럼 규칙 자체가 복잡한 장면이며, 그때도 요구에 번호를 매겨 하나씩 확인할 수 있게 해야 합니다. 보내기 전 마지막 자기 점검으로, 실행자 입장에서 한 번 읽고 먼저 무엇을 하고 무엇을 하면 안 되는지 한 번에 알 수 있는지 자문하세요. 스스로 읽어도 헷갈리면 모델의 안정적인 수행을 기대하기 어렵습니다.
