https://thomas-wiegold.com/blog/prompt-engineering-best-practices-2026/
Prompt Engineering Best Practices 2026
Prompt engineering best practices have fundamentally changed. Learn what works in 2026—context engineering, model-specific tactics, and why longer prompts often hurt.
thomas-wiegold.com
요약: "2023년식 프롬프트(고정 인사말 + 대문자 강조)는 이제 안 통한다. 짧고 명확하게 쓰고, 모델별 특성에 맞추고, 핵심은 영리한 표현이 아니라 자료(맥락)를 잘 챙기는 것"이라는 글입니다. 실무자가 쓴 글이라 구체적이고 괜찮습니다.
쓸모 있는 핵심만 추리면:
- 짧게 시작해서 부족한 것만 추가하세요. 처음부터 장문으로 쓰지 말고, 의도만 짧게 던진 뒤 결과 보고 필요한 것만 덧붙이는 방식. 글에서는 150~300단어가 대부분 작업의 적정선이라고 합니다 (3,000토큰 넘으면 모델 추론력이 떨어진다는 연구 근거 제시).
- 긴 프롬프트는 오히려 독입니다. 길수록 모델이 뭐가 중요한지 헷갈려하고, 나중에 고치기도 어렵습니다. 그리고 (지난번에 말한) 중요한 지시는 맨 앞·맨 뒤에 두라는 얘기 반복.
- Claude한테는 XML 태그가 최고의 정리 방법입니다. <지시>, <자료>, <예시> 같은 태그로 묶으면 효과가 측정 가능할 만큼 좋아집니다. 반대로 "절대!", "반드시!" 같은 공격적 표현은 최신 Claude엔 역효과 — 그냥 차분하게 원하는 걸 말하면 됩니다.
- 부정형보다 긍정형으로. "가짜 데이터 쓰지 마"보다 "진짜 데이터만 써"가 더 잘 통합니다 ("코끼리를 생각하지 마"라고 하면 코끼리부터 떠올리는 것과 같은 원리).
- few-shot(예시 3~5개 보여주기)은 가성비 최고 기법입니다. 예시가 완벽할 필요는 없고, 다양한 경우를 커버하는 게 더 중요하다고 합니다.
글 후반부(프롬프트 버전 관리, 캐싱, 테스트셋, 모델 버전 고정 등)는 같은 프롬프트를 수천 번 돌리는 개발·자동화 시스템 얘기라 지금 단계에선 지금 안 보셔도 됩니다.
한 줄로: 위 다섯 개 중 "짧게, XML 태그, 긍정형, 예시 3~5개" 네 가지만 본인 업무 프롬프트에 적용해보셔도 체감 차이가 날 겁니다.