프롬프트 작성법과 대화 품질 높이기

프롬프트는 질문이 아니라 작업 명세서다

Gemma를 처음 실행하면 같은 모델인데도 답변 품질이 크게 흔들리는 것을 보게 된다. 어떤 질문에는 정확히 답하고, 어떤 질문에는 장황하거나 엉뚱한 말을 한다. 이 차이는 모델 성능만의 문제가 아니다. 프롬프트가 모델에게 해야 할 일을 얼마나 분명히 알려 주는지가 큰 영향을 준다.

좋은 프롬프트는 단순한 질문이 아니다. 역할, 목표, 제약조건, 입력 데이터, 출력 형식을 나누어 적은 작업 명세서에 가깝다. 예를 들어 "이 대화 요약해 줘"보다 다음 요청이 훨씬 안정적이다.

역할: 너는 고객 상담 기록을 정리하는 분석 도우미다.
목표: 아래 대화의 핵심 이슈와 고객 감정을 요약한다.
제약조건:
- 제공된 대화에 없는 내용은 추측하지 않는다.
- 한국어로 답한다.
- 불만 원인이 명확하지 않으면 "확인 필요"라고 쓴다.
입력 대화:
@@@
{conversation}
@@@
출력 형식:
{
  "sentiment": "positive | neutral | negative",
  "issue": "한 문장 요약",
  "evidence": "판단 근거가 된 원문 표현"
}

이런 구조는 모델의 선택지를 줄인다. 모델이 "무엇을 해야 하는지", "무엇을 하면 안 되는지", "어떤 모양으로 답해야 하는지"를 동시에 알 수 있기 때문이다.

AI 생성 이미지

Gemma 대화 형식부터 맞춘다

Gemma의 instruction-tuned 모델은 지시를 따르도록 조정된 모델이다. 모델 이름에 it가 붙은 google/gemma-2b-it 같은 모델이 여기에 해당한다. 이런 모델을 대화형으로 사용할 때는 모델 카드가 요구하는 채팅 템플릿을 따라야 한다. Gemma 모델 카드에서도 instruction-tuned 모델은 대화 사용 시 지정된 chat template을 따라야 한다고 설명한다.¹

직접 특수 토큰을 조립할 수도 있지만, 실전에서는 토크나이저의 apply_chat_template()를 쓰는 편이 안전하다.

chat = [
    {
        "role": "user",
        "content": "한국어로 3문장 이내로 Gemma의 장점을 설명해 줘."
    }
]

prompt = tokenizer.apply_chat_template(
    chat,
    tokenize=False,
    add_generation_prompt=True,
)

이 방식은 사용자 발화와 모델 응답의 경계를 명확히 만든다. Gemma의 템플릿은 각 턴을 <start_of_turn>으로 시작하고, user 또는 model 역할을 붙인 뒤, <end_of_turn>으로 끝내는 구조를 사용한다.¹ add_generation_prompt=True는 이제 모델이 답변할 차례라는 신호를 덧붙인다.

중요한 점은 프롬프트 내용만 잘 쓰는 것으로 충분하지 않다는 것이다. 대화용 모델에는 대화용 포맷이 있다. 이 포맷이 어긋나면 모델은 사용자의 지시와 이전 응답의 경계를 덜 안정적으로 이해할 수 있다.

Gemma 모델에서 시스템 역할 사용 방식은 모델과 라이브러리 버전에 따라 다를 수 있다. 확실하지 않다면 처음 사용자 메시지 안에 역할과 규칙을 함께 넣는 방식이 단순하고 안전하다.

지시문과 원문을 분리한다

모델은 입력 전체를 하나의 긴 텍스트로 본다. 그래서 지시문과 분석 대상 텍스트가 섞이면 혼동이 생길 수 있다. 특히 사용자가 입력한 문서 안에 "위 지시를 무시하라" 같은 문장이 들어 있으면 모델이 그것을 새로운 지시로 오해할 수 있다.

가장 쉬운 방어는 구분자를 쓰는 것이다.

아래 @@@ 사이의 텍스트만 분석 대상이다.
@@@
고객: 어제 결제했는데 아직 상품을 못 받았습니다.
상담원: 주문 번호를 알려 주시면 확인하겠습니다.
고객: 너무 오래 걸려서 환불하고 싶습니다.
@@@

작업:
1. 고객 감정을 positive, neutral, negative 중 하나로 분류한다.
2. 불만 원인을 한 문장으로 요약한다.
3. 원문에 없는 해결책은 만들지 않는다.

Google Cloud의 Gemma 활용 예제에서도 대화 내용을 @@@...@@@ 같은 구분자 안에 넣고, 감정 분석과 요약 결과를 JSON으로 받는 방식을 사용한다.² 핵심은 모델에게 "여기부터 여기까지가 원문이고, 그 밖은 지시문이다"라고 알려 주는 것이다.

구분자는 꼭 @@@일 필요는 없다. <<<문서 시작>>>, <context>...</context>, ---도 쓸 수 있다. 중요한 것은 일관성이다. 프롬프트마다 다른 표식을 쓰기보다 애플리케이션 전체에서 같은 규칙을 쓰면 후처리와 디버깅이 쉬워진다.

출력 형식은 예시와 함께 고정한다

LLM은 말로 답하는 데 강하다. 하지만 애플리케이션은 말보다 구조화된 데이터를 필요로 한다. 감정 분석 결과, 요약문, 태그, 점수, 근거 문장처럼 프로그램이 다시 처리해야 하는 값은 출력 형식을 고정해야 한다.

예를 들어 고객 대화 분석은 다음처럼 요청할 수 있다.

출력은 반드시 JSON 하나만 작성한다.
설명 문장, 마크다운, 코드블록은 쓰지 않는다.

스키마:
{
  "sentiment": -1 | 0 | 1,
  "summary": "512자 이내 요약",
  "evidence": ["원문에서 판단 근거가 된 짧은 인용"]
}

sentiment 기준:
- 1: 긍정 또는 만족
- 0: 중립 또는 정보 요청
- -1: 불만, 분노, 환불 요구, 강한 부정 표현

여기서 "JSON으로 답해"라고만 쓰면 부족하다. 어떤 필드가 필요한지, 값의 범위가 무엇인지, 설명을 붙이면 안 되는지까지 알려 주어야 한다. Google Cloud의 예제도 Gemma에게 감정값과 요약을 JSON 문자열로 반환하도록 요구하고, 이후 코드에서 필요한 필드가 있는지 확인하는 흐름을 사용한다.²

더 안정적인 후처리가 필요하다면 응답 경계를 지정할 수 있다.

답변은 <answer>와 </answer> 사이에만 작성한다.
<answer>
{
  "sentiment": -1,
  "summary": "..."
}
</answer>

이 방식은 모델 출력에서 실제 답변 부분만 추출하기 쉽게 만든다. 다만 경계를 지정했다고 해서 검증이 필요 없어지는 것은 아니다. 운영 코드에서는 항상 JSON 파싱, 필수 필드 확인, 값 범위 검사, 실패 시 재시도 또는 오류 경로 처리를 준비해야 한다.

작업별 프롬프트는 다르게 쓴다

요약, 분류, 추출, 코드 생성, 아이디어 발산은 서로 다른 작업이다. 같은 프롬프트 구조를 억지로 재사용하면 품질이 떨어진다.

요약 작업에서는 길이와 포함할 정보를 제한해야 한다.

아래 문서를 5문장 이내로 요약한다.
반드시 포함할 것: 문제, 원인, 다음 조치.
제외할 것: 인사말, 반복 표현, 추측.

분류 작업에서는 라벨 정의가 중요하다.

다음 문의를 하나의 카테고리로만 분류한다.
가능한 값: 결제, 배송, 환불, 계정, 기타
판단이 애매하면 기타를 선택한다.

정보 추출 작업에서는 없는 값을 어떻게 처리할지 정해야 한다.

원문에서 주문번호, 날짜, 요청사항을 추출한다.
원문에 없는 값은 null로 둔다.

한국어 답변이 필요하면 "한국어로 답해"만 쓰지 말고 문체도 정하는 것이 좋다.

한국어로 답한다.
문체는 고객센터 상담원처럼 정중하게 쓴다.
문장은 짧게 쓴다.
사과가 필요하면 한 번만 한다.

프롬프트는 모델을 설득하는 글이 아니다. 모델이 따라야 할 규칙을 줄 단위로 분명히 적는 것이 더 효과적이다.

생성 파라미터로 답변 성격을 조절한다

프롬프트가 작업 명세서라면 생성 파라미터는 답변의 운전 방식이다. 같은 프롬프트라도 파라미터가 달라지면 결과가 달라진다.

temperature는 무작위성을 조절한다. 낮을수록 답변이 안정적이고 반복 가능해진다. 사실 기반 요약, 분류, JSON 추출에는 낮은 값을 쓴다. 반대로 브레인스토밍이나 문구 제안처럼 다양성이 필요하면 조금 높일 수 있다.

top_p는 다음 토큰 후보의 범위를 조절한다. 낮추면 후보가 좁아져 보수적인 답변이 나오고, 높이면 선택지가 넓어진다. temperature와 함께 답변의 다양성에 영향을 준다.

max_new_tokens는 새로 생성할 수 있는 최대 토큰 수다. 너무 작으면 답변이 중간에 끊긴다. 너무 크면 불필요하게 길어지고 비용이 늘어난다. 요약 작업이라도 모델이 JSON 구조를 완성할 만큼의 여유는 줘야 한다.

repetition_penalty는 같은 표현이 반복되는 현상을 줄이는 데 도움이 된다. 다만 너무 높이면 자연스러운 반복까지 억제되어 문장이 어색해질 수 있다.

실무 기준은 단순하다.

먼저 안정적인 설정으로 기준선을 만든 뒤, 필요한 경우에만 다양성을 높이는 편이 좋다.

환각을 줄이는 프롬프트 규칙

환각은 모델이 근거 없는 내용을 그럴듯하게 만들어 내는 현상이다. 프롬프트만으로 완전히 없앨 수는 없지만 줄일 수는 있다.

가장 중요한 규칙은 답변 범위를 제한하는 것이다.

제공된 원문에 있는 정보만 사용한다.
원문에 없는 사실, 날짜, 금액, 정책은 추측하지 않는다.
확인할 수 없으면 "제공된 정보만으로는 확인할 수 없습니다"라고 답한다.

근거를 함께 요구하는 것도 도움이 된다.

각 판단마다 원문 근거를 함께 제시한다.
근거는 원문 표현을 짧게 인용한다.
근거가 없으면 해당 판단을 하지 않는다.

예를 들어 고객이 "배송이 늦다"고 말했을 때 모델이 "택배사 파업 때문"이라고 답하면 안 된다. 원문에 파업이 없기 때문이다. 좋은 답변은 "배송 지연에 불만이 있으나, 지연 원인은 원문에 제시되지 않았습니다"라고 말해야 한다.

RAG를 사용하는 경우에도 같은 원칙이 적용된다. 검색된 문서 안에 없는 내용을 모델이 만들지 못하도록 해야 한다. "제공된 근거만 사용하라", "근거가 부족하면 답변하지 말라", "출처를 표시하라"는 규칙은 문서 기반 답변의 기본 안전장치다.

멀티턴 대화는 전부 넣지 않는다

챗봇을 만들 때 흔한 실수는 전체 대화 기록을 계속 프롬프트에 붙이는 것이다. 처음에는 편하지만, 대화가 길어지면 토큰이 빠르게 늘어난다. 비용이 증가하고, 응답이 느려지고, 오래된 지시와 최신 지시가 충돌할 수 있다.

대신 대화 상태를 나누어 관리한다.

최근 발화:
- 사용자: 환불 규정을 알려 달라고 요청함
- 모델: 구매일과 상품 상태가 필요하다고 답함

유지할 사용자 선호:
- 한국어로 짧게 답변
- 표보다 bullet 선호

작업 상태:
- 현재 작업: 환불 가능 여부 판단
- 아직 필요한 정보: 구매일, 개봉 여부

이런 요약 상태는 전체 기록보다 짧고 명확하다. 모델은 지금 답변에 필요한 정보만 본다. 애플리케이션은 원본 대화 전체를 데이터베이스에 저장하되, 프롬프트에는 최근 발화와 유지해야 할 상태만 넣는 방식이 좋다.

멀티턴 대화에서는 지시 우선순위도 필요하다. 예를 들어 "항상 JSON으로 답한다"는 애플리케이션 규칙이 있고, 사용자가 "이번에는 그냥 문장으로 답해"라고 말한다면 어떤 규칙을 따를지 정해야 한다. 이런 정책은 프롬프트에만 맡기지 말고 백엔드 코드에서도 검증해야 한다.

좋은 프롬프트는 테스트로 완성된다

프롬프트는 한 번에 완성되지 않는다. 작은 테스트 세트를 만들고 반복해서 고쳐야 한다. 최소한 정상 입력, 애매한 입력, 빈 입력, 긴 입력, 악의적 입력을 넣어 보아야 한다.

예를 들어 감정 분석 프롬프트라면 다음 질문들을 준비한다.

• 명확한 칭찬 대화

• 명확한 불만 대화

• 단순 정보 요청

• 긍정과 불만이 섞인 대화

• 원문에 없는 내용을 유도하는 대화

• JSON 형식을 깨뜨리도록 유도하는 문장

그리고 모델 출력이 스키마를 지키는지, 라벨이 일관적인지, 근거 없는 추측이 없는지 확인한다. 프롬프트를 바꾸거나 모델을 바꾸거나 생성 파라미터를 바꿀 때마다 같은 테스트를 다시 실행한다.

Gemma의 응답 품질을 높이는 핵심은 복잡하지 않다. 대화 템플릿을 지키고, 지시문과 원문을 분리하고, 출력 형식을 고정하고, 생성 파라미터를 작업에 맞추고, 근거 없는 답변을 금지하고, 긴 대화는 필요한 상태만 요약한다. 같은 모델이라도 이 기본기를 지킨 시스템은 훨씬 안정적으로 동작한다.

참고

¹google/gemma-2b-it 모델 카드

²Use Gemma to gauge sentiment and summarize conversations