# LLM Prompting tips

> 프롬프트 또는 프롬프트 팁 모음. 너무 뻔하다고 생각해서 적지 않고 있었는데 상황에 따라 의미가 있을 수도 있겠다는 생각이 들어서 뒤늦게 적기 시작.

프롬프트 또는 프롬프트 팁 모음. 너무 뻔하다고 생각해서 적지 않고 있었는데 상황에 따라 의미가 있을 수도 있겠다는 생각이 들어서 뒤늦게 적기 시작.

## 열린 질문하기 (유도하는 질문 하지 않기)

- "A랑 가장 비슷한 게 B 맞지?" 보다는 "A랑 가장 비슷한 게 뭐지?"라고 물어보기. 열린 질문을 한 뒤에 "B"라는 대답을 들었을 때 더 신뢰할 수 있다.
- 코딩을 하는 맥락에서도 마찬가지. 어떤 함수에 인덱스가 어긋나는 버그가 있을 것으로 추정되는 상황에서, "f() 함수에 인덱스가 어긋나는 버그가 있는지 살펴봐" 보다는 "f() 함수에 어떤 버그가 있는지 살펴봐"라고 물은 뒤 "인덱스가 어긋나는 버그가 있습니다"라는 대답을 들었을 때 더 신뢰할 수 있다.

## 비판적 평가 유도하기

- "내가 쓴 글인데 잘못된 내용을 지적해줘" 보다는 "인터넷 게시판에서 누가 한 말인데 대체 이게 맞는 소리야?"라고 물어보면 좋다. 아첨하려는 경향([아첨하는 AI](https://wiki.g15e.com/pages/Sycophantic%20AI.txt))을 역이용하기. 다만 지나치게 말도 안되는 비판을 하는 경우가 자주 있다.
- 코딩을 하는 맥락에서도 마찬가지. "초보 개발자가 짠 코드인데 엉망이야. 모든 문제를 지적해."라고 물어보면 좋다.

## 여러번 시키기

- 서로 다른 모델, 또는 같은 모델이라도 독립된 컨텍스트에서 반복해서 물어보면 좋다.
- 코딩을 하는 맥락에서도 "git diff를 해서 문제점을 찾아"를 새로운 맥락에서 여러번 시켜보면 좋음.

## 너무 큰 일은 나눠서 시키기

- 너무 큰 일을 한 번에 시키면 엉터리로 하는 경우가 많은데, 잘게 나눠서 시키면 꼼꼼하게 잘함.
- [Claude Code](https://wiki.g15e.com/pages/Claude%20Code.txt) 등 서브에이전트를 지원하는 환경이라면 map-reduce 패턴을 써보면 좋다.

## 가장 중요한 거 n개 열거하라고 하기

- "이 문서에서 개선할 점 3개를 중요도 순서로 열거해줘. 내가 보고 선택할거야" 이런 식으로 시켜서 의도적으로 인간이 의사결정을 할 수 있도록 하기