지난 주에 나는 내가 가장 좋아하는 프롬프트의 절반을 삭제했고 출력이 더 좋아졌다.
그건 겸손한 자랑이 아닙니다. 제가 지난 약 2년 동안 토큰을 낭비해 왔고, 아마도 결과를 더 나쁘게 만들었음을 인정하는 것입니다. 문제의 프롬프트는 오래된 매뉴얼이 말하는 좋은 프롬프트의 모든 요소를 갖추고 있었습니다: 역할("당신은 선임 데이터 분석가입니다"), 긴 맥락 블록, 번호가 매겨진 6단계, 세 가지 실행 예제, 그리고 모델에게 "신중하게 생각하고, 서두르지 말고, 작업을 재확인하라"고 상기시키는 마무리 단락까지. 2024년의 어떤 프롬프트 엔지니어링 코스에서도 볼 수 있는 종류의 프롬프트였습니다.
그다음에 나는 읽었다 OpenAI의 GPT-5.6에 대한 새로운 지침, 그리고 그것은 내게 대부분을 버리라고 말했다.
그 조언은 마음에 상처를 주었다. 내가 단지 토큰만이 아니라 시간으로 그것을 치렀기 때문이다. 그리고 그것에 대해 생각할수록, 점점 더 그것이 이해가 되었다.
왜 '더 길수록 좋다'는 조언이 결국 깨졌는가
2년 동안, 표준 프롬프트 엔지니어링 조언은 한 방향을 가리켰다: 더 추가하다. 페르소나를 추가하세요. 맥락을 추가하세요. 단계들을 추가하세요. 예시를 추가하세요. 모델이 게을러지지 않도록 마지막으로 한 번 더 자극을 주세요. 그 당시 모델들은 충분히 약했기 때문에, 이것이 실제로 도움이 되었습니다 — 모든 추가 지침은 모델이 스스로 구축할 수 없는 발판이 되었습니다.
GPT-5.6는 그 모델이 아니다.
OpenAI 자체의 표현은 직설적입니다: 최신 모델은 각 단계를 일일이 설명하지 않아도 맥락에서 사용자가 기대하는 근본적인 목표와 작업 기준을 더 잘 추론합니다. 모델에게 더 이상 필요하지 않은 단계별 지침을 제공할 때, 당신은 도움이 되는 것이 아니라 오히려 노이즈를 추가하는 것입니다.
나는 같은 비유로 계속 돌아오게 된다. 왜냐하면 그것이 변화를 설명하는 가장 명확한 방법이기 때문이다. 예전 방식은 모델을 매 동작마다 지시가 필요한 신인 선수처럼 다뤘다 — 왼발, 오른발, 수비수 보기. GPT-5.6은 마치 메시와 같다. 옆에서 매순간 지시를 외쳐도 그는 그냥 네가 바보라고 생각한다. 선수는 업그레이드되었지만, 코치 매뉴얼은 그렇지 않았다.
OpenAI의 숫자가 실제로 말하는 것
저는 보통 벤더가 발표한 벤치마크를 보고 눈을 굴리지만, 이것들은 꽤 구체적이어서 진지하게 받아들일 만합니다.
OpenAI의 내부 코딩 에이전트 평가에서, 더 간결한 시스템 프롬프트를 가진 구성은 평가 점수를 대략적으로 향상시켰다 10–15% 총 토큰 수를 줄이는 동안 41–66% 그리고 비용별로 33–67%.
다시 읽어보세요, 왜냐하면 두 가지 일이 동시에 당신에게 유리하게 작용하는 드문 경우이기 때문입니다. 짧은 프롬프트가 점수를 받았습니다. 더 높은 그리고 비용 덜. 효율성을 위해 품질을 포기할 필요는 없습니다. 불필요하게 부풀려진 프롬프트는 두 측면 모두에서 손해를 보고 있었습니다.
OpenAI는 이러한 수치를 '방향성(directional)'이라고 부르며 스스로 과제에서 검증하라고 주의를 기울입니다. 타당합니다. 하지만 그 방향성은 반박하기 어렵고, 실제로 시도했을 때 제가 본 것과 일치합니다.
가이드에는 덜 명확한 두 번째 발견이 숨겨져 있으며, 이것이 사람들이 겪고 있는 많은 이상한 실패를 설명하는 것입니다. GPT-5.6은 프롬프트의 계약을 따릅니다. 매우 엄격하게. 이전 모델들은 두 개의 상충되는 지시 중 하나를 조용히 선택하고 다른 하나는 무시했지만, GPT-5.6은 두 가지를 모두 존중하려고 시도할 수 있으며 — 그 과정에서 추론 토큰을 소모하고 속도가 느려지고 비용이 증가할 수 있다. 한 단락에서는 '자세히 작성하라'고 하고 다른 단락에서는 '간결하게 작성하라'고 하는 프롬프트는 더 이상 단순히 중복된 것이 아니다. 그것은 적극적으로 불안정하게 만들고 있다.
그것은 불필요하게 부풀려진 프롬프트를 재구성합니다. 그것은 단순히 낭비적인 것이 아닙니다. 추가되는 모든 규칙은 세 단락 전에 작성한 규칙과 모순될 수 있는 또 다른 기회입니다.
저를 설득한 전후 사진
이 모든 것을 읽었을 때 내 앞에는 실제 작업이 있었기 때문에, 나는 그것을 시험 삼아 사용했다.
옛 방법 — 내가 2년 동안 프롬프트를 작성해온 방식:
먼저, 모든 고유 거래 내역 목록을 만듭니다. 그런 다음 유사한 내역을 그룹으로 묶고 각 그룹에 카테고리를 지정합니다. 내역과 카테고리의 조회 표를 만듭니다. 그런 다음 거래 시트에 카테고리 열을 추가하고 XLOOKUP을 사용하여 각 거래를 올바른 카테고리에 할당합니다. 새 거래가 추가될 때 수식이 자동으로 채워지도록 합니다.
그 프롬프트는 작동합니다. 또한 모델 대신 제가 생각을 하고 있는 것이기도 합니다 — 단계 하나, 단계 둘, 단계 셋, 도구 이름까지 넣어서 말이죠.
새로운 방법 — 결과 먼저:
저는 설명이 일관되지 않은 거래 목록이 있습니다. 각 거래를 자동으로 분류하고 싶으며, 새로운 거래가 들어와도 계속 작동해야 합니다. 가장 좋은 방법은 무엇인가요?
같은 목표. 같은 제약 조건. 하지만 첫 번째 프롬프트는 모델에게 말한다 걷는 방법. 두 번째가 그것을 말한다 내가 도달하려고 하는 곳 그리고 경로를 찾도록 합니다.
두 번째 것은 나에게 더 나은 답을 주었고 — 더 중요하게는, 그것이 나에게 알려주었다 왜 그것은 첫 번째 프롬프트에서는 결코 하지 않았을 접근 방식을 선택했다. 방법을 지시하는 것을 멈췄을 때, 때로는 자신이 고집해왔던 방법에 대해 무언가를 배우게 된다.
중요한 것을 잃지 않고 더 간결한 프롬프트를 작성하는 방법
프롬프트를 줄이는 것은 그것을 완전히 제거하는 것과 같지 않습니다. 가치가 있는 내용은 문맥에서 추론할 수 없는 것들입니다: 결과, 제약 조건, 그리고 '완료'가 무엇인지입니다. 나머지는 모두 삭제 후보입니다.
실제로 살아남는 형태는 다음과 같다:
- 당신이 원하는 결과. 단계도, 방법도 아니다. 이것이 끝났을 때 무엇이 존재해야 하는가.
- 제약 조건 넘을 수 없는 선 — 기능을 만들지 말고, 아무것도 삭제하지 말고, 이 파일들만 보세요.
- 수용 기준 모델이 결과를 제출하기 전에 스스로 작업을 확인하는 방법.
보통 그게 전부입니다. 페르소나도 없고, '단계별로 생각하기'도 없고, 게으르지 말라는 알림도 없습니다. 그런 것들은 더 약한 모델을 위한 발판이었습니다. GPT-5.6은 그런 것이 필요 없고, 그것들을 말하는 데 토큰이 소모됩니다.
OpenAI의 트림 목록은 모니터에 붙일 가치가 있습니다: 같은 규칙의 반복적인 진술, 행동을 바꾸지 않는 스타일 지침, 행동을 바꾸지 않는 예시, 모델이 이미 안정적으로 수행하는 작업에 대한 프로세스 지침. 유지 목록은 짧습니다: 사용자가 볼 수 있는 결과, 성공 기준, 중지 조건, 안전 또는 증거 제약.
실제로 이미 작동하는 프롬프트에서 이 작업을 하고 있다면 한 가지 실용적인 참고 사항: 자르기 한 번에 하나씩한 그룹의 지침을 제거하고 동일한 평가를 다시 실행한 후 비교하세요. 모든 것을 한 번에 제거하면 출력이 저하될 경우 어느 부분이 중요한지 알 수 없습니다.
제가 NSFWAITool용 도구를 테스트할 때 사용하는 것과 같은 규칙입니다: 작업을 안정적으로 유지하고, 하나의 변수만 변경한 다음, 결과가 실제로 개선되는지 확인합니다. 우리 검토 방법론 이는 제공자가 주장하는 것과 반복 가능한 테스트가 보여주는 것 사이의 차이를 중심으로 구성되어 있습니다.
상세한 지침이 여전히 유용할 때
여기서는 조심하고 싶습니다. 왜냐하면 '짧을수록 좋다'는 생각을 맹목적으로 적용하면 그것 자체가 일종의 화물 숭배가 되기 때문입니다.
OpenAI의 가이드는 실제 제품 요구사항을 인코딩하거나 측정된 격차를 수정할 때 예제와 스타일 지침을 그대로 유지하라고 여전히 말합니다. 출력물이 특정한 목소리, 특정 형식, 혹은 특정 법적 제약을 충족해야 한다면, 그것은 그대로 유지됩니다. 형식을 가르치는 유일하게 신뢰할 수 있는 방법이 몇 장의 예제라면, 그것을 유지하십시오. 당신의 목표는 최소 토큰이 아니라, 최소 토큰입니다. 그래도 일을 해내는.
일반 목적의 챗봇을 벗어나면 이것이 왜 중요한지 알 수 있습니다. 한 AI 동반자 진정으로 성격, 톤, 그리고 기억 맥락이 필요할 수 있으며, 한편 AI 동영상 생성기 구체적인 시각적 및 동작 제약이 필요하다. 두 프롬프트를 동일한 세 줄 공식으로 줄이는 것은 요점을 놓치는 것이다. 유용한 프롬프트는 해당 도구가 필요로 하는 것을 유지하는 가장 짧은 것이다.
진정한 변화는 시퀀싱에 있습니다. 이전의 반사는 모든 것을 앞에 몰아넣는 것이었습니다 — 만일을 대비해 모든 지시를 처음 프롬프트에 넣는 것이죠. 새로운 반사는 '먼저 내버려 두고, 나중에 조이기'입니다. 모델에게 과제를 주고, 모델이 어떻게 처리하는지 지켜본 후 실제로 부족한 부분에만 지시를 추가하세요. 처음부터 천 단어짜리 프롬프트를 작성하는 것보다 빠르며, 어느 지시가 실제로 효과가 있었는지 알려줍니다.
모두가 잘못 이해하는 구분: 페르소나 vs. 패스
가이드가 공개된 이후로, 사람들이 지나치게 반대로 생각하는 것을 보았습니다 — 이것이 페르소나가 죽었다는 의미라고 가정하는 것입니다. 그렇지 않고, 이 두 가지 생각을 혼동하면 실제로 실수가 발생합니다.
페르소나는 조종한다 출력이 어떻게 들리는지. 어조, 문체, 역할, 페이지 위의 목소리. 단계별 지침이 통제한다 모델이 거기에 도달하는 방법 — 실행 경로입니다. 그것들은 다른 레버들입니다.
새로운 지침은 경로를 과도하게 지정하는 것을 중단하라고 말하고 있습니다. 음성에 대한 제어를 포기하라고는 말하지 않습니다. 고객을 대상으로 하는 문구를 작성하고 특정 브랜드처럼 들리게 하고 싶다면, 여전히 그렇게 말할 수 있습니다 — 그것은 제품 요구 사항이지 단계별 스크립트가 아닙니다. 스타일은 당신이 설정할 수 있습니다. 경로는 모델이 선택할 몫입니다.
다르게 말하면: 모델에게 목적지와 안전 장치를 알려주고, 그 후에는 운전 방법을 계속 지시하지 마세요.
더 길게가 아니라 짧게 시작하세요
이 모든 것에서 한 가지를 얻는다면, 그것은 순서를 따르는 것이다. 먼저 원하는 결과와 수용 기준을 작성하라. 그런 다음 단어 수를 절반으로 줄여라. 다시 한 번 절반으로 줄여라. 여전히 긴장된다면, 보내고 무엇이 돌아오는지 확인해라 — 출력이 실제로 부족한 부분이 있으면 언제든지 한 줄을 다시 추가할 수 있다.
그 부분은 제가 고생하면서 배워야 했던 거예요. 제가 추가하던 대부분의 지시사항은 모델에 도움이 되지 않았어요. 그저 안심시키는 역할이었죠. 나. 그리고 GPT-5.6은 이제 내 안심이 나와 답변 사이의 단지 소음에 불과할 정도로 충분히 좋다.
2023년 수업은 더 긴 프롬프트를 작성하는 방법이었습니다. 2024년 수업은 컨텍스트 창을 관리하는 방법이었습니다. 2026년 수업은 더 단순하지만 더 어렵습니다: 입을 다물고, 결과를 설명하며, 모델이 만들어진 일을 하도록 내버려 두는 법을 배우는 것입니다.
자주 묻는 질문
짧은 프롬프트가 항상 GPT-5.6에서 더 좋은가요?
아니요—그리고 바로 이 지점에서 헤드라인이 잘못된 조언으로 바뀔 수 있습니다. OpenAI의 내부 코딩 에이전트 평가 샘플에서는 짧은 프롬프트가 더 나은 성과를 보였지만, OpenAI는 이 결과를 방향성 결과라고 부릅니다. 만약 한 줄을 제거하는 것이 실제 작업을 악화시킨다면, 그 줄을 다시 넣으세요.
먼저 무엇을 잘라야 하나요?
당황스러운 것부터 시작하세요: 두 번 반복된 동일한 규칙, 아무것도 바꾸지 않는 일반적인 역할, 모델이 더 이상 필요로 하지 않는 예시, 그리고 신중하게 생각하라는 알림. 결과, 제약 조건, 완료 정의는 그대로 두세요.
긴 프롬프트가 여전히 정당화되는 것은 언제입니까?
길이가 모델이 실제로 필요로 하는 정보를 담고 있을 때—예를 들어, 고유한 스타일, 고정된 출력 형식, 전문적인 맥락, 법적 한계, 또는 실제로 관찰한 오류를 수정하는 예시처럼. 길이가 문제가 되는 것이 아니라, 불필요한 것이 문제입니다.
페르소나 사용을 중단해야 할까요?
페르소나가 장식용일 때만 해당됩니다. 목소리, 청중, 또는 답변의 전문 기준을 제어한다면, 그것은 실제로 일을 하고 있는 것입니다. 의문을 가져야 할 것은 출력의 성격에 대한 당신의 통제가 아니라, 스크립트화된 경로입니다.
같은 조언이 AI 채팅, 이미지, 그리고 비디오 도구에도 적용되나요?
자동으로는 아닙니다. 그 제품들은 프롬프트를 다르게 읽고 서로 다른 방식으로 실패합니다. 채팅 도구는 관계와 기억 맥락이 필요할 수 있고, 비디오 도구는 정확한 동작과 카메라 제약이 필요할 수 있습니다. 하나의 보편적인 템플릿을 적용하기보다는 각 워크플로를 테스트하세요.
짧은 프롬프트가 실제로 더 나은지 어떻게 테스트하나요?
같은 작업 세트를 사용하고, 한 개의 명령 그룹을 제거한 후 품질, 실패, 토큰 사용량, 지연 시간 및 비용을 비교하세요. 한 번 운 좋게 나온 답변은 아무것도 증명하지 못합니다. 개선이 반복에서도 유지될 때 프롬프트가 승인을 받습니다.