Prompt Engineering : 고급 기법

기본 프롬프트 템플릿을 갖췄다면, 이제 더 고급 기법을 시도할 수 있다. 이번 편은 in-context learning, 단계적 추론·chain of thought, 추론 모델(reasoning model), 그리고 context window 관리를 정리한다.

 

 

1. In-Context Learning (예시로 가르치기)

In-context learning은 원하는 출력의 예시를 프롬프트에 넣어 LLM에게 무엇을 생성할지 학습시키는 기법이다. 예로 고객 응대 챗봇이라면, 이전 고객 문의와 모범 답변을 예시로 넣는다. 이 예시가 LLM이 새 응답을 만들 때 쓸 구조와 톤을 알려준다. RAG처럼, 응답 방식을 근거화(ground)하려고 정보를 프롬프트에 더하는 셈이다.

그림 1. In-context learning — 모범 예시(질문·답변)를 프롬프트에 넣어 원하는 구조·톤을 학습시킨다.

 

예시를 여러 개 넣으면 few-shot learning, 하나만 넣으면 one-shot learning이다.

그림 2. 예시 다수 = few-shot, 예시 하나 = one-shot.

 

구현 방법은 두 가지다. 예시 몇 개를 프롬프트에 하드코딩하면 안정적인 동작이 필요할 때 유용하다. 매번 예시를 바꾸고 싶다면 RAG로 예시를 검색한다 — 성공적인 고객 대화를 벡터 DB에 색인해 두고, 새 문의가 오면 같은 주제의 이전 대화를 검색해 프롬프트에 주입한다. 사실상 일반 RAG지만, 예시 답변을 콕 집어 검색한다는 점이 응답 품질을 더 높인다.

그림 3. RAG 기반 ICL — 성공 대화를 색인하고, 주제가 맞는 예시를 검색해 프롬프트에 주입한다.

 

 

 

2. 단계적 추론과 Chain of Thought

또 다른 강력한 기법군은 LLM이 단계적으로 추론하도록 유도한다. 답을 내기 전에 먼저 소리 내어 생각(think aloud)하거나 단계별로(step-by-step) 접근하게 시키는 것이다. LLM에게 답하기 전 생각을 정리할 스크래치패드(scratchpad)를 주는 셈이다. 흔한 방식은 scratchpad 태그 안의 토큰은 생각·브레인스토밍 공간이고 최종 답이 아니라고 알려주는 것이다.

그림 4. 단계적 추론 — 답하기 전 scratchpad에 생각을 정리하게 한다.

 

비슷한 방식이 chain-of-thought(CoT) 프롬프팅이다. 즉답 대신 단계적으로 풀게 지시한다 — 먼저 필요한 단계들을 생성하고 그 단계를 따르게 한다. 이렇게 계획적·점진적으로 접근하면 최종 답의 정확도가 오를 가능성이 높고, 모델이 "풀이를 보여주므로" 추론이 어긋난 지점을 추적하기도 쉽다.

그림 5. Chain of Thought — 답의 단계를 먼저 만들고 그 단계를 따라가며 정확도를 높인다.

 

 

 

3. 추론 모델 (Reasoning Models)

이런 추론 전략이 워낙 효과적이라, 많은 LLM이 아예 추론 모델로 설계돼 나온다. 추론 모델은 코딩·수학·계획·퍼즐 등 복잡한 다단계 추론에 강하다. 내부적으로 먼저 reasoning token(계획·선택지 검토 — 앞의 scratchpad 같은)을 생성한 뒤, 사용자에게 줄 response token을 출력한다. 제공사에 따라 최종 response token만 주기도, reasoning token까지 열어주기도 한다. reasoning token은 정확도를 높이지만 일반 토큰과 똑같이 비용이 들어, 추론 모델은 대체로 느리고 비싸다.

그림 6. 추론 모델 — 먼저 reasoning token으로 계획하고, 이어서 최종 response token을 낸다.

 

RAG에서는 이 비용이 충분히 값어치할 수 있다 — 추론 모델은 검색된 문서의 관련성 판단과, 복잡한 추론이 필요한 답에 정보를 어떻게 녹일지 결정하는 데 특히 뛰어나다. 다만 여러 프롬프트 기법이 추론 모델엔 잘 안 통한다. 이미 단계적으로 생각하도록 학습돼 있어 "step-by-step으로 생각하라"고 시킬 필요가 없고, in-context learning의 예시 답변을 현재 질문에 섞어 넣으려다 오히려 성능이 떨어질 수 있다. 대신 명확한 목표와 원하는 출력 형식을 구체적으로 주고, 상위 가이드 원칙(피할/취할 접근)을 밝힌 뒤 검색 문서를 통째로 던져주는 편이 낫다. 새 모델은 계속 나오니, 제공사가 안내하는 프롬프트 방법을 참고한다.

그림 7. 추론 모델 주의 — ICL·예시 혼합에 약하고, 명확한 목표·형식·전체 맥락 제공이 유리하다.

 

 

 

4. Context Window 관리

기법을 많이 쓸수록 context window 관리가 중요해진다. 초기 프롬프트와 생성 토큰이 모두 context window를 소모하는데, 검색 문서 주입·ICL 예시·추론 모델의 계획 토큰은 모두 프롬프트나 응답 길이를 늘린다. 방심하면 금세 window가 찬다.

그림 8. 고급 기법(검색 문서·ICL·reasoning token)은 context window를 빠르게 소모한다.

 

싱글턴이라면 가장 좋은 처방은 그 기법이 실제로 값어치가 있는지 검증하는 것 — CoT나 ICL이 성능을 못 높이면 차라리 빼는 게 낫다. 멀티턴은 매 메시지를 프롬프트에 넣어야 해 window를 빨리 잡아먹는다. 이를 다루는 기법을 통틀어 context pruning이라 한다. 단순하게는 최근 N개 메시지만 유지하고(예: 마지막 5개), 더 정교하게는 별도 LLM으로 오래된 메시지를 요약해 크기는 줄이되 핵심은 보존한다.

그림 9. Context pruning — 최근 메시지만 유지하거나, 별도 LLM으로 옛 메시지를 요약해 축소한다.

 

추론 모델을 멀티턴에 쓴다면 reasoning token은 이력에서 빼고 response token만 남기는 게 거의 필수다. RAG에서도 보통 가장 최근 질문을 뒷받침하는 chunk만 넣고 이전 질문의 chunk는 넣지 않는다. 깊고 풍부한 맥락이 필요하면 더 긴 context window 모델로 바꿀 수 있지만, 긴 프롬프트는 여전히 느리고 비싸므로 신중하게 설계해야 한다.

그림 10. 관리 전략 — 최근 질문에 관련된 chunk만 포함, 필요하면 long-context 모델로 전환(그래도 효율은 신경).

 

조언. 프롬프트 기법이 성능을 높일 수 있지만 반드시 필요한 건 아니다. 단순한 템플릿 + 잘 쓴 시스템 프롬프트면 충분한 경우도 많다. 고급 기법은 필요가 분명해진 뒤에 더하고, 프롬프팅은 과학보다 예술에 가까우니 여러 프롬프트를 실험해 내 시스템에 맞는 것을 찾는다.

 

다음 글에서는 RAG의 핵심 난제 중 하나 — 환각(hallucination)을 다루고 통제하는 법을 살펴본다.