[Prompt] 프롬프트 기본기 다섯 가지 — 무엇이 근거가 있고 무엇이 민담인가
프롬프트 조언 다섯 가지를 근거 강도로 다시 줄 세웁니다. 역할 부여가 성능을 올린다는 근거는 왜 약한지, 예시가 실제로 작동하는 이유는 무엇인지 논문으로 확인합니다.
파인튜닝 편에서 “일단 프롬프트부터”라고 적어놓고 정작 프롬프트 글이 없었습니다. 이번 편이 그 자리입니다.
그런데 이 주제는 이미 글이 많습니다. 하나 더 보태는 대신 다르게 가겠습니다. 어떤 조언에 근거가 있고 어떤 게 민담인지 갈라보겠습니다.
다섯 가지를 근거 강도로 줄 세우면
프롬프트 기본기로 흔히 묶이는 다섯 가지가 있습니다 — 역할, 맥락, 형식, 예시, 제약.
거의 항상 이 순서로, 역할이 맨 앞에 옵니다. “당신은 10년 경력의 마케팅 전문가입니다”로 시작하라는 조언입니다.
근거를 기준으로 다시 세우면 순서가 뒤집힙니다.
논문 근거의 강도로 직접 정리했습니다
역할 — 가장 널리 쓰이는데 근거는 가장 약합니다
역할 부여를 정면으로 시험한 논문이 있습니다. 제목부터 결론입니다.
When “A Helpful Assistant” Is Not Really Helpful — 시스템 프롬프트의 페르소나는 LLM 성능을 향상시키지 않는다.
규모가 작지 않습니다. 역할 162개(관계 유형 6종 × 전문 분야 8종), 사실 질문 2,410개, 모델 4개 계열을 놓고 비교했습니다.
시스템 프롬프트에 페르소나를 추가하는 것은, 페르소나를 넣지 않은 대조군과 비교했을 때 여러 질문에 걸쳐 모델 성능을 향상시키지 않는다.
한 가지 더 있습니다. 역할의 성격(성별·유형·분야)에 따라 정확도가 흔들리기는 했는데, 어떤 역할이 좋을지 자동으로 고르려는 시도는 무작위 선택보다 나을 게 없었습니다.
“전문가 역할을 주면 전문가처럼 답한다”는 널리 퍼진 직관인데, 적어도 사실 질문에서는 그 직관을 뒷받침하는 근거가 없습니다.
예시 — 작동합니다. 다만 이유가 통념과 다릅니다
예시를 두어 개 주는 것은 효과가 확인된 쪽입니다. 그런데 왜 효과가 있는지가 놀랍습니다.
Rethinking the Role of Demonstrations 가 이렇게 적습니다.
정답 예시는 사실 필요하지 않다. 예시의 레이블을 무작위로 바꿔도 여러 분류·객관식 과제에서 성능이 거의 떨어지지 않는다.
정답을 틀린 것으로 바꿔도 성능이 유지된다는 뜻입니다. 그럼 무엇이 작동한 걸까요. 논문이 셋을 지목합니다.
- 레이블 공간 — 어떤 답들이 가능한지
- 입력 텍스트의 분포 — 어떤 종류의 입력을 다루는지
- 전체 시퀀스의 형식 — 어떻게 생긴 덩어리인지
즉 예시는 “정답을 가르치는” 게 아니라 “판을 알려주는” 역할에 가깝습니다.
이건 실무에서 바로 쓰입니다. 예시를 만들 때 정답을 고르느라 시간을 쓰는 것보다, 형식과 답의 범위를 일관되게 맞추는 데 시간을 쓰는 편이 낫습니다.
예시의 개수와 순서가 미치는 영향은 이것대로 별개의 주제라, 여기서는 다루지 않겠습니다.
형식 — 논문이 직접 지목한 요인
위 목록의 세 번째가 형식이었습니다. 통념에서는 “출력을 JSON 으로 주세요” 정도의 부수적 요령으로 취급되는데, 실제로 작동한 요인으로 지목된 쪽입니다.
출력 형식을 명시하는 게 체감 효과가 큰 이유가 여기 있습니다. 모델에게 “무엇을 답하라”보다 “어떤 모양으로 답하라” 가 더 잘 전달됩니다.
맥락 — 넣는 것보다 어디에 넣느냐
맥락을 주라는 조언 자체는 당연합니다. 모델이 모르는 걸 알려줘야 답할 수 있으니까요.
덜 알려진 건 위치가 성능을 가른다는 점입니다. 컨텍스트 윈도우 편과 RAG 편에서 인용한 Lost in the Middle 이 이걸 측정했습니다.
관련 정보가 입력의 처음이나 끝에 있을 때 성능이 가장 높고, 긴 맥락의 중간에 있을 때 크게 떨어집니다.
그래서 맥락은 “많이 넣기”가 아니라 “핵심을 앞이나 뒤에 두기” 로 옮겨가야 합니다.
제약 — 근거보다 경험칙입니다
“300자 이내로”, “코드만 출력하고 설명은 하지 마세요” 같은 제약입니다.
정직하게 말하면, 이 항목은 통제된 실험 근거를 찾지 못했습니다. 널리 쓰이고 저도 씁니다. 다만 앞의 넷과 같은 강도로 말할 수는 없습니다.
경험칙 수준에서 하나 덧붙이면, 금지 목록을 길게 늘어놓는 것보다 원하는 결과를 서술하는 편이 대체로 낫습니다. “~하지 마세요”를 여러 줄 쌓으면 모델이 그 항목들에 오히려 주의를 뺏깁니다.
그래서 어떻게 쓰나
근거를 반영해 순서를 다시 잡으면 이렇게 됩니다.
| 순서 | 할 일 |
|---|---|
| 1 | 출력 형식을 명시한다 — 가장 확실한 지렛대 |
| 2 | 예시를 두어 개 준다 — 정답 고르기보다 형식·범위 일관성에 신경 쓴다 |
| 3 | 맥락은 앞이나 뒤에 둔다 — 중간에 묻히지 않게 |
| 4 | 제약을 더한다 — 금지보다 원하는 바를 서술 |
| 5 | 역할은 필요하면 쓴다 — 성능 향상을 기대하지는 말고 |
역할을 쓰지 말라는 뜻이 아닙니다. 말투나 시점을 정하는 데는 쓸모가 있습니다. 다만 그게 정확도를 올려줄 거라 기대하면 근거가 없습니다.
이 글의 한계
근거로 삼은 논문이 2022~2023년 자료입니다. 페르소나 논문은 2023년 11월, 예시 논문은 2022년 2월입니다. 그 뒤 모델이 크게 바뀌었으니, 같은 실험을 지금 다시 하면 결과가 다를 수 있습니다.
과제 종류가 한정돼 있습니다. 페르소나 논문은 사실 질문, 예시 논문은 분류·객관식 과제였습니다. 창작이나 코드 생성에서 같은 결론이 나오는지는 이 논문들이 답하지 않습니다.
“근거가 약하다”는 “효과가 없다”가 아닙니다. 특정 조건에서 측정했을 때 향상이 확인되지 않았다는 뜻입니다.
정리
프롬프트 조언은 많은데 근거를 따진 것은 드뭅니다.
확인된 것부터 쓰면 형식 → 예시 → 맥락 순입니다. 예시는 정답을 가르치는 게 아니라 판을 알려주는 쪽에 가깝고, 맥락은 넣는 양보다 위치가 중요합니다.
그리고 거의 모든 안내가 맨 앞에 놓는 역할 부여는, 성능 향상 근거가 가장 약합니다. 162개 역할과 2,410개 질문으로 시험했는데 대조군보다 나아지지 않았습니다.
“이 팁의 근거가 무엇인가”를 묻는 습관이 팁 다섯 개를 외우는 것보다 오래갑니다.
참고
- When “A Helpful Assistant” Is Not Really Helpful: Personas in System Prompts Do Not Improve Performances of Large Language Models — Zheng, Pei, Logeswaran, Lee, Jurgens, 2023-11-16, Findings of EMNLP 2024 (2026-08-21 arXiv 원문 확인). 역할 162개·질문 2,410개·모델 4계열 실험과 인용문의 출처입니다. 2023년 자료입니다
- Rethinking the Role of Demonstrations: What Makes In-Context Learning Work? — Min, Lyu, Holtzman, Artetxe, Lewis, Hajishirzi, Zettlemoyer, 2022-02-25, EMNLP 2022 (2026-08-21 arXiv 원문 확인). 레이블 무작위 교체 결과와 세 가지 요인의 출처입니다. 2022년 자료입니다
- Lost in the Middle: How Language Models Use Long Contexts — Liu 외, 2023-07-06, TACL 2023. 맥락 위치 효과의 출처입니다
- 파인튜닝 vs RAG vs 프롬프트 — “프롬프트부터”라고 적었던 앞 편
- 컨텍스트 윈도우 · RAG 기초 — 맥락 위치 문제를 다룬 글