프롬프트 패턴

이 장에서 배울 것

이번 장에서는 LLM에게 일을 더 잘 맡기기 위한 프롬프트 패턴을 배운다. 여기서 프롬프트란 사용자가 모델에게 보내는 지시문이다. 단순히 질문 한 줄을 잘 쓰는 기술이 아니다. 모델에게 역할, 작업, 배경, 제약, 출력 형식, 평가 기준을 전달하는 가장 기본적인 인터페이스다.

이 장을 마치면 다음을 할 수 있어야 한다.

• Role, Task, Context, Constraint, Output Format으로 프롬프트를 나누어 설명한다.

• 나쁜 프롬프트와 좋은 프롬프트를 같은 작업에서 비교한다.

• zero-shot, few-shot, prompt chaining, self-check, critique-and-revise 패턴을 구분한다.

• 문서 요약, 기획안 작성, 코드 설명 업무에 프롬프트 패턴을 적용한다.

• 동일한 업무 지시문을 여러 버전으로 만들고 간단히 평가한다.

왜 이 주제가 중요한가

4장에서 instruction tuning을 배웠다. 모델은 사용자의 지시를 따르도록 추가 학습된다. 하지만 지시를 따를 능력이 있다는 것과 사용자의 의도를 정확히 안다는 것은 다르다.

예를 들어 사용자가 '회의록 요약해 줘'라고 입력하면 모델은 나름대로 요약한다. 그러나 사용자가 원하는 것이 임원 보고용인지, 실무자 액션 아이템인지, 고객 공유용인지 알 수 없다. 길이는 어느 정도인지, 표로 정리해야 하는지, 불확실한 내용은 어떻게 표시해야 하는지도 모른다.

프롬프트가 중요한 이유는 여기에 있다. 좋은 프롬프트는 모델에게 더 많은 말을 시키는 문장이 아니다. 작업 조건과 성공 기준을 명확하게 전달하는 문서다. 프롬프트를 잘 쓰면 답변 품질이 안정된다. 반대로 프롬프트가 모호하면 모델은 평균적인 답을 만든다. 평균적인 답은 그럴듯해 보이지만 실제 업무에는 맞지 않는 경우가 많다.

핵심 개념 설명

프롬프트의 다섯 요소

좋은 프롬프트는 보통 다음 다섯 요소로 나눌 수 있다.

나쁜 프롬프트는 보통 이 요소 중 여러 개가 빠져 있다.

나쁜 예:

이 문서 요약해 줘.

조금 나은 예:

너는 실무 보고서를 작성하는 비즈니스 분석가다. 아래 회의록을 읽고 팀장이 바로 확인할 수 있도록 요약하라. 핵심 결정 사항, 담당자별 할 일, 다음 회의 전 확인할 위험 요소를 구분하라. 문서에 없는 내용은 추측하지 말고 '확인 필요'라고 표시하라. 출력은 표와 3줄 요약으로 작성하라.

두 프롬프트의 차이는 말투가 아니다. 두 번째 프롬프트에는 역할, 작업, 맥락, 제약, 출력 형식이 들어 있다. 그래서 모델이 어떤 답을 만들어야 하는지 더 좁은 범위 안에서 판단할 수 있다.

Zero-shot과 few-shot

Zero-shot은 예시 없이 바로 지시하는 방식이다. 간단한 분류, 짧은 요약, 일반적인 설명에는 충분히 잘 작동한다.

예:

다음 고객 문의를 '환불', '배송', '제품 문의', '기타' 중 하나로 분류하라.

Few-shot은 원하는 답변 예시를 몇 개 제공하는 방식이다. 모델에게 정답 규칙을 길게 설명하기보다, 입력과 출력의 쌍을 보여 주는 방법이다.

예:

예시 1
입력: 제품이 아직 안 왔어요.
출력: 배송

예시 2
입력: 결제 취소하고 싶습니다.
출력: 환불

이제 다음 입력을 분류하라.

Few-shot은 특히 조직마다 표현 방식이 다르거나, 답변 톤을 맞추어야 하거나, 출력 형식이 엄격할 때 유용하다. 단, 예시가 잘못되면 모델도 잘못 배운다. 예시는 적지만 대표적이어야 한다.

Prompt chaining

Prompt chaining은 하나의 큰 작업을 여러 단계의 프롬프트로 나누는 방식이다. 한 번에 모든 일을 시키지 않고, 중간 결과를 확인하면서 다음 단계로 넘긴다.

예를 들어 기획안을 만들 때 한 번에 '신규 앱 기획안 작성해 줘'라고 할 수 있다. 하지만 품질이 들쭉날쭉할 수 있다. 대신 다음처럼 나눈다.

1. 사용자 문제를 5개로 정리한다.

2. 가장 중요한 문제 2개를 고른다.

3. 해결 아이디어를 3개 제안한다.

4. 선택한 아이디어로 1페이지 기획안을 작성한다.

5. 빠진 가정과 위험 요소를 점검한다.

이 방식은 결과를 통제하기 쉽다. 중간 단계에서 방향이 틀어졌을 때 바로 수정할 수 있기 때문이다. 복잡한 업무일수록 한 번의 긴 프롬프트보다 짧은 여러 단계가 안정적이다.

Self-check와 critique-and-revise

Self-check는 모델에게 자신의 답을 기준에 맞추어 점검하게 하는 방식이다. 예를 들어 요약문을 만든 뒤 다음과 같이 물을 수 있다.

위 요약문이 원문에 없는 내용을 추가했는지 점검하라. 추가된 내용이 있으면 해당 문장을 표시하고, 원문 근거가 있는 문장만 남겨라.

Critique-and-revise는 초안을 만든 뒤 비판하고 다시 고치는 방식이다.

1. 초안을 작성한다.

2. 평가 기준에 따라 문제점을 찾는다.

3. 문제점을 반영해 수정본을 만든다.

이 패턴은 보고서, 이메일, 코드 설명, 학습 자료 작성에 유용하다. 다만 self-check가 항상 정답을 보장하지는 않는다. 모델은 자기 답을 검토할 때도 실수할 수 있다. 중요한 업무에서는 원문, 데이터, 테스트 결과와 함께 확인해야 한다.

사고 과정을 안전하게 구조화하기

LLM에게 무조건 '단계별로 생각해'라고 요구하는 것은 좋은 습관이 아니다. 긴 추론문이 출력되면 그럴듯해 보이지만, 실제로는 잘못된 근거가 섞일 수 있다. 또한 업무에서는 내부 추론 전체보다 확인 가능한 근거와 최종 결론이 더 중요하다.

대신 다음처럼 구조화하는 편이 좋다.

• 먼저 문제를 하위 작업으로 나누어라.

• 각 하위 작업의 판단 근거를 한 문장으로 요약하라.

• 불확실한 부분은 '확인 필요'로 표시하라.

• 마지막에 최종 답만 별도로 정리하라.

예:

아래 요구사항을 기능, 데이터, 예외 처리, 확인 필요 사항으로 나누어 분석하라. 각 항목은 원문 근거를 1문장으로 덧붙여라. 마지막에는 개발자가 바로 확인할 체크리스트만 따로 작성하라.

이 방식은 모델의 생각을 길게 노출시키는 것이 아니라, 사람이 검토할 수 있는 중간 산출물을 만드는 데 초점이 있다.

쉬운 비유 또는 사례

프롬프트는 아르바이트생에게 일을 맡기는 요청서와 비슷하다.

'자료 정리해 주세요'라고만 말하면 상대는 무엇을 기준으로 정리해야 할지 모른다. 날짜순인지, 고객사별인지, 금액순인지, 보고용인지 알 수 없다. 결과가 마음에 들지 않아도 지시가 모호했기 때문에 다시 설명해야 한다.

반대로 이렇게 말하면 결과가 달라진다.

이 자료를 팀장 보고용으로 정리해 주세요. 고객사별 매출, 전월 대비 증감, 위험 고객을 표로 구분해 주세요. 금액은 만 원 단위로 표시하고, 원본에 없는 해석은 넣지 마세요. 마지막에 확인이 필요한 데이터를 따로 적어 주세요.

LLM도 마찬가지다. 모델은 일을 대충 하려는 것이 아니다. 사용자가 어떤 기준으로 좋은 답을 판단하는지 알지 못할 뿐이다. 프롬프트는 그 기준을 전달하는 방법이다.

직접 해보는 실습

이번 실습에서는 같은 업무를 세 가지 프롬프트로 실행하고 결과를 비교한다.

실습 주제 선택

다음 중 하나를 고른다.

1. 한국어 회의록 요약

2. 신규 서비스 기획안 작성

3. 파이썬 코드 설명

프롬프트 A: 모호한 지시

다음 내용을 정리해 줘.

프롬프트 B: 다섯 요소를 포함한 지시

너는 실무 문서를 정리하는 분석가다. 아래 내용을 읽고 팀원이 바로 행동할 수 있게 정리하라. 핵심 내용, 결정 사항, 담당자별 할 일, 확인 필요 사항을 구분하라. 원문에 없는 내용은 추측하지 말라. 출력은 표와 3줄 요약으로 작성하라.

프롬프트 C: 예시와 점검을 포함한 지시

다음 형식을 따라 정리하라.
예시 형식:

• 3줄 요약

• 결정 사항 표

• 담당자별 할 일 표

• 확인 필요 사항

작성 후, 원문에 없는 내용이 들어갔는지 스스로 점검하고 문제가 있는 문장은 삭제하라.

평가표 만들기

세 결과를 다음 기준으로 평가한다. 0점은 부족, 1점은 보통, 2점은 좋음이다.

평가할 때는 느낌만 보지 않는다. 원문에 없는 내용이 추가되었는지, 표 형식을 지켰는지, 중요한 항목이 빠졌는지 확인한다. 가능하면 같은 입력을 2~3번 반복해 일관성도 본다.

실습 결과로 짧은 회고를 작성한다.

• 어떤 프롬프트가 가장 안정적이었는가?

• 품질이 좋아진 이유는 무엇인가?

• 여전히 남은 오류는 무엇인가?

• 다음에는 어떤 제약이나 예시를 추가할 것인가?

흔한 실수와 오류 분석

기밀 정보를 프롬프트에 넣는 실수

LLM에 회사 내부 문서, 고객 개인정보, 비공개 소스 코드, 계약 내용 등을 그대로 넣으면 안 된다. 사용하는 모델과 환경에 따라 데이터 처리 방식이 다르다. 업무에서는 먼저 보안 정책을 확인해야 한다. 필요한 경우 익명화하거나, 내부 승인된 도구를 사용해야 한다.

'정확히 해줘'라고만 요구하는 실수

'정확히', '잘', '전문적으로' 같은 말은 평가 기준이 아니다. 모델은 무엇이 정확한지 알 수 있어야 한다. '원문 문장에 근거가 없는 내용은 쓰지 말라', '날짜와 금액은 원문 그대로 유지하라', '불확실하면 확인 필요로 표시하라'처럼 행동 가능한 기준으로 바꾸어야 한다.

한 번의 긴 프롬프트로 모든 문제를 해결하려는 실수

프롬프트가 길다고 좋은 것은 아니다. 서로 충돌하는 지시가 들어가면 오히려 품질이 떨어진다. 복잡한 작업은 prompt chaining으로 나누는 편이 낫다. 초안 생성, 검토, 수정, 최종 형식화 단계를 분리하라.

예시를 잘못 주는 실수

Few-shot에서 예시는 작은 학습 데이터처럼 작동한다. 예시의 형식이 들쭉날쭉하면 결과도 흔들린다. 예시는 적어도 일관된 형식을 가져야 한다. 또한 쉬운 예시만 넣으면 실제 어려운 입력에서 약해질 수 있다.

검증 없이 결과를 복사하는 실수

프롬프트를 잘 써도 hallucination, 즉 그럴듯하지만 사실이 아닌 답이 나올 수 있다. 특히 숫자, 인용, 법률, 의료, 최신 정보, 내부 규정은 반드시 별도 확인이 필요하다. 프롬프트는 오류를 줄이는 도구이지, 검증을 대신하는 장치가 아니다.

요약

프롬프트는 LLM과 일하는 기본 인터페이스다. 좋은 프롬프트는 Role, Task, Context, Constraint, Output Format을 명확히 포함한다. 간단한 작업은 zero-shot으로 충분할 수 있지만, 형식과 톤이 중요하면 few-shot이 효과적이다. 복잡한 작업은 prompt chaining으로 나누고, self-check와 critique-and-revise로 결과를 점검한다.

중요한 것은 모델에게 '더 똑똑하게 답하라'고 요구하는 것이 아니다. 좋은 답의 조건을 사람이 먼저 정의하고, 모델이 그 조건 안에서 답하도록 만드는 것이다.

퀴즈

1. 프롬프트의 다섯 요소 Role, Task, Context, Constraint, Output Format 중 '500자 이내로 작성하라'는 어디에 해당하는가?

2. Zero-shot과 few-shot의 차이를 한 문장으로 설명하라.

3. Prompt chaining이 한 번의 긴 프롬프트보다 유리한 상황은 언제인가?

4. '정확히 요약해 줘'라는 지시가 부족한 이유는 무엇인가?

5. Self-check를 사용할 때도 사람이 검증해야 하는 이유는 무엇인가?

정답 예시:

1. Constraint에 해당한다.

2. Zero-shot은 예시 없이 지시하고, few-shot은 입력과 출력 예시를 함께 제공한다.

3. 작업이 복잡하고 중간 방향 수정이 필요할 때 유리하다.

4. 정확성의 기준이 구체적으로 제시되지 않았기 때문이다.

5. 모델은 자기 답을 검토할 때도 잘못 판단할 수 있기 때문이다.

체크리스트

• 프롬프트에 역할과 작업이 명확히 들어 있는가?

• 필요한 배경 정보가 충분히 제공되었는가?

• 지켜야 할 제약이 행동 가능한 문장으로 쓰였는가?

• 출력 형식이 구체적으로 지정되었는가?

• 예시가 필요한 작업인지 판단했는가?

• 복잡한 작업을 여러 단계로 나누었는가?

• 결과를 평가할 기준을 미리 정했는가?

• 기밀 정보나 개인정보를 넣지 않았는가?

• 원문에 없는 내용이 추가되었는지 확인했는가?

다음 장 연결

프롬프트를 잘 쓰면 LLM 답변 품질은 크게 좋아진다. 하지만 프롬프트만으로 해결할 수 없는 문제가 있다. 모델이 학습하지 않은 최신 문서, 회사 내부 규정, 고객별 계약서 내용은 프롬프트 기술만으로 정확히 알 수 없다.

다음 장에서는 이 문제를 해결하기 위한 RAG의 원리를 배운다. RAG는 모델이 모르는 정보를 외부 문서에서 찾아와 답변에 활용하는 방식이다. 프롬프트가 '어떻게 답할지'를 정한다면, RAG는 '무엇을 근거로 답할지'를 보강한다.