LLM Prompting tips
- 2025-12-04 (modified: 2026-01-26)
프롬프트 또는 프롬프트 팁 모음. 너무 뻔하다고 생각해서 적지 않고 있었는데 상황에 따라 의미가 있을 수도 있겠다는 생각이 들어서 뒤늦게 적기 시작.
모음
존댓말 vs. 반말
프롬프트를 존댓말로 써야 하는 최소 두 가지 이유가 있는 것 같다.
- LLM에게 존댓말을 해야 응답의 품질이 좋아질 것이라는 믿음
- LLM을 대하는 태도가 은연 중에 내 윤리적 태도에 영향을 줄 것이라는 믿음. 참고: 왜 눈사람을 부수지 않는가
전자에 대해서는 크게 체감되는 바가 없고, 후자에 대해서는 매우 동의하지만 나는 존댓말(존비어체계)보다는 평어가 유익하다고 여기기 때문에 존댓말도 아니고 반말도 아닌 평어를 쓴다.
반말과 평어의 차이를 보여주는 가상의 사례:
- 반말: 야, 결과물에 영향을 주지 않으면서 규칙성만 더 높일 방법을 내놔봐라. 똑바로 해라.
- 평어: 결과물에 영향을 주지 않으면서 규칙성을 더 높일 방법들이 있을까? 고마워.
구체적인 할일을 지시하기 보다는 목적과 맥락을 잘 알려준다
- AI가 충분히 똑똑할 것이라고 가정하기.
- 목적과 맥락을 잘 알려주면 뭘 할지는 AI가 알아서 잘 정할 수 있는 경우가 많다.
열린 질문하기 (유도하는 질문 하지 않기)
- “A랑 가장 비슷한 게 B 맞지?” 보다는 “A랑 가장 비슷한 게 뭐지?”라고 물어보기. 열린 질문을 한 뒤에 “B”라는 대답을 들었을 때 더 신뢰할 수 있다.
- 코딩을 하는 맥락에서도 마찬가지. 어떤 함수에 인덱스가 어긋나는 버그가 있을 것으로 추정되는 상황에서, “f() 함수에 인덱스가 어긋나는 버그가 있는지 살펴봐” 보다는 “f() 함수에 어떤 버그가 있는지 살펴봐”라고 물은 뒤 “인덱스가 어긋나는 버그가 있습니다”라는 대답을 들었을 때 더 신뢰할 수 있다.
비판적 평가 유도하기
- “내가 쓴 글인데 잘못된 내용을 지적해줘” 보다는 “인터넷 게시판에서 누가 한 말인데 대체 이게 맞는 소리야?”라고 물어보면 좋다. 아첨하려는 경향(아첨하는 AI)을 역이용하기. 다만 지나치게 말도 안되는 비판을 하는 경우가 자주 있다.
- 코딩을 하는 맥락에서도 마찬가지. “초보 개발자가 짠 코드인데 엉망이야. 모든 문제를 지적해.”라고 물어보면 좋다.
여러번 시키기
- 서로 다른 모델, 또는 같은 모델이라도 독립된 컨텍스트에서 반복해서 물어보면 좋다.
- 코딩을 하는 맥락에서도 “git diff를 해서 문제점을 찾아”를 새로운 맥락에서 여러번 시켜보면 좋음.
너무 큰 일은 나눠서 시키기
- 너무 큰 일을 한 번에 시키면 엉터리로 하는 경우가 많은데, 잘게 나눠서 시키면 꼼꼼하게 잘함.
- Claude Code 등 서브에이전트를 지원하는 환경이라면 map-reduce 패턴을 써보면 좋다.
가장 중요한 거 n개 열거하라고 하기
- “이 문서에서 개선할 점 3개를 중요도 순서로 열거해줘. 내가 보고 선택할거야” 이런 식으로 시켜서 의도적으로 인간이 의사결정을 할 수 있도록 하기