목차
- 프롬프트 엔지니어링 가이드: 1. 프롬프트 기초와 LLM 설정
- 프롬프트 엔지니어링 가이드: 2. Zero-shot, Few-shot, Chain-of-Thought
- 프롬프트 엔지니어링 가이드: 3. Tree of Thoughts, Retrieval Augmented Generation
프롬프트 엔지니어링이란
프롬프트 엔지니어링은 모델에게 원하는 작업을 정확히 전달하기 위해 입력을 설계하는 일이다. 핵심은 문장을 길게 쓰는 것이 아니라, 지시와 문맥, 출력 형식을 분리해 결과를 예측 가능하게 만드는 데 있다.
필요한 이유는 간단하다. 같은 모델이라도 요청 방식이 모호하면 응답 품질이 쉽게 흔들리기 때문이다. 실무에서는 한 번 잘 나온 답보다, 같은 조건에서 비슷한 품질이 반복되는지가 더 중요하다. 프롬프트 엔지니어링은 이 반복 가능성을 높여서 검수 비용을 줄이고, 운영 중 장애 대응도 빠르게 만든다. 결국 프롬프트를 잘 설계한다는 것은 모델을 “잘 쓰는 방법”이 아니라, 서비스 품질을 안정적으로 관리하는 방법에 가깝다.
프롬프트의 기본 설계가 중요하다.
프롬프트 엔지니어링을 배우다 보면 고급 기법부터 따라 하고 싶어진다. 그런데 실제 품질은 기법 이름보다 기본 설계에서 더 크게 갈린다. 그래서 Introduction 파트가 중요하다. LLM 파라미터를 어떻게 잡는지, 프롬프트를 어떤 형식으로 쓰는지, 지시를 어떻게 구체화하는지가 결과를 좌우한다.
이 글은 promptingguide.ai의 Introduction 내용을 일부 참고해 정리했다. 흐름은 LLM 설정 같은 프롬프트 기초에서 시작해 구성 요소와 설계 팁을 거쳐, 마지막으로 활용 예시로 이어진다.
LLM 설정: temperature, top_p, max length부터 이해한다
첫 번째 핵심은 “프롬프트만 바꾸는 것이 전부는 아니다”라는 점이다. 파라미터 설정이 바뀌면 같은 프롬프트도 다른 결과를 만든다. 모델 품질이 갑자기 흔들릴 때는 프롬프트보다 설정값 차이를 먼저 확인하는 습관이 도움이 된다.
temperature와 top_p
temperature가 낮으면 더 결정론적인 결과가 나오고, 높으면 표현 다양성이 커진다. top_p도 유사한 목적을 갖는 샘플링 파라미터다.
둘 다 “다음 토큰을 얼마나 넓게 고를지”를 조절한다는 점에서 역할이 겹친다.
실무에서는 둘을 동시에 과하게 건드리기보다, 하나를 기준으로 조정하는 편이 디버깅이 쉽다.
사실 기반 질의응답: temperature 낮게
창의적 생성 작업: temperature 높게
예를 들어 고객센터 FAQ 답변처럼 일관성이 중요한 작업은 temperature를 낮게 시작하고, 슬로건 후보처럼 표현 폭이 필요한 작업은 조금 높여 본다.
top_p는 “확률이 높은 후보군 안에서만 뽑겠다”는 느낌으로 이해하면 쉽다.
정확한 답변이 필요한 구간에서는 후보군을 좁히고, 아이디어 탐색 구간에서는 후보군을 넓히는 식으로 쓴다.
주의할 점은 품질이 흔들릴 때 프롬프트를 의심하기 전에 파라미터 변경 이력을 먼저 확인하는 것이다. 같은 프롬프트라도 응답 옵션 값이 달라지면 결과가 달라질 수 있다. 그래서 문제가 생겼을 때 프롬프트 때문이라고 단정하기 전에, 설정이 바뀌었는지 먼저 확인하는 편이 안전하다.
max length와 stop sequence
max length는 응답 길이를 제한해 비용과 지연 시간을 제어한다.
stop sequence는 출력 구조를 강제로 끊는 데 유용하다.
예: 항목 10개 리스트 생성 시, stop sequence를 "11."로 지정
max length를 제한하지 않으면 모델이 불필요한 배경 설명까지 길게 이어 쓰는 경우가 많다.
이때 응답이 길어질수록 토큰 비용이 증가하고, 후처리 파싱 실패율도 같이 올라간다.
특히 API 연동에서는 길이 제한이 성능 안정성에 직접 연결된다.
stop sequence는 길이 제어뿐 아니라 출력 형식을 지키는 장치로도 쓸 수 있다.
다만 “11.” 같은 단일 패턴만 믿으면 줄바꿈이나 기호 변형 때문에 우회 출력이 나올 수 있다.
리스트 강제 같은 시나리오에서는 stop sequence와 함께 “정확히 10개만 출력” 같은 지시를 같이 두는 편이 안전하다.
penalty 옵션
frequency penalty, presence penalty는 반복 억제 성격이 다르다.
frequency penalty는 같은 단어를 여러 번 쓰는 패턴을 더 강하게 누른다.
presence penalty는 이미 한 번 등장한 주제를 다시 꺼내는 경향 자체를 줄이는 데 가깝다.
요약이나 마케팅 문구 작성처럼 표현이 반복되기 쉬운 작업에서는 유용하다. 반대로 사실 기반 질의응답에서는 값을 너무 높이면 핵심 용어를 다시 써야 할 구간에서도 회피가 걸려 답변이 어색해질 수 있다. 이 경우 두 값을 동시에 올리기보다, 한쪽만 소폭 조정하면서 결과를 비교하는 방식이 안정적이다.
프롬프트의 기초: 짧은 입력은 종종 모호하다
가이드는 아주 짧은 프롬프트 예시로 시작한다. 모델은 문장을 이어 쓰지만, 그 결과가 사용자의 의도와 항상 맞지는 않는다. 핵심은 단순하다. 모델에게 “무엇을 하라”를 명시할수록 결과 제어력이 높아진다.
나쁜 예: 하늘은
개선 예: 문장을 완성해 줘: 하늘은
또한 프롬프트 형식 자체를 일관되게 두는 것이 중요하다.
<질문>?
또는
<지시>
Q: <질문>?
A:
기초 섹션은 결국 Zero-shot/Few-shot으로 이어지는 출발점이기도 하다. 예시 없이 지시하는 방식과 예시를 붙여 패턴을 맞추는 방식의 차이는, 이어지는 다음 글에서 조금 더 자세히 다룬다.
주의할 점은 프롬프트가 길어질수록 정확도도 같이 올라간다고 생각하기 쉽다는 점이다. 실제로는 길이 자체보다 지시가 얼마나 분명한지가 더 중요하다. 불필요한 설명이 늘어나면 오히려 핵심 요구가 흐려져 응답 품질이 떨어질 수 있다.
프롬프트의 구성 요소: 네 가지를 분리해서 설계한다
가이드가 제시하는 구성 요소는 아래 네 가지다.
- 지시(Instruction)
- 문맥(Context)
- 입력 데이터(Input Data)
- 출력 지시자(Output Indicator)
실무에서는 네 요소를 한 문장에 섞기보다 분리해서 관리하는 편이 좋다.
[Instruction]
고객 문의를 분류해라.
[Context]
당신은 결제 운영팀 분류기다.
[Input]
"결제가 두 번 청구됐어요"
[Output]
severity/category/action 3개 필드만 반환
이렇게 구성하면 문제가 생겼을 때 어느 축이 실패했는지 파악하기 쉽다. 예를 들어 포맷 오류는 Output 지시자 문제일 가능성이 높고, 분류 오답은 Instruction/Context 품질 문제일 가능성이 높다.
일반적인 팁: 간단하게 시작하고, 구체화하고, 버전 관리한다
가이드의 팁은 많지만 실무에서는 세 줄로 요약된다.
1) 시작은 간단하게
처음부터 큰 작업을 한 번에 넣지 않는다. 작은 작업으로 쪼개고 결과를 보며 확장한다.
2) 지시는 명령형으로 명확하게
“작성하기, 분류하기, 요약하기, 번역하기”처럼 동작을 분명히 지정한다. 모호한 요청은 모호한 결과를 만든다.
3) 구체성 + 직접성
출력 길이, 형식, 대상 독자, 금지 조건을 구체적으로 적는다.
모호함: 간결하게 설명해 줘.
구체화: 고등학생 대상, 2~3문장, 전문용어 1개 이하로 설명해 줘.
가이드가 특히 강조하는 포인트 중 하나는 “하지 말라”만 나열하기보다 “무엇을 해야 하는지”를 분명히 쓰라는 것이다.
나쁜 지시: 개인정보를 묻지 마라.
개선 지시: 고객이 제공한 주문번호만으로 환불 가능 여부를 안내해라.
주의할 점은 프롬프트를 수정하면서 변경 이력을 남기지 않는 것이다. 버전이 없으면 품질 개선인지 우연인지 판단할 수 없다.
프롬프트 예시: 작업 유형별로 템플릿을 쌓는다
이번 절에서는 작업별 예시를 짧게 훑으면서, 지시를 어떻게 써야 출력이 달라지는지 확인해 본다. 핵심은 “좋은 프롬프트를 읽는 것”보다 “같은 작업을 조금씩 바꿔 써보는 것”에 있다.
문장 요약
문장 요약은 생성형 모델에서 가장 자주 쓰는 작업 중 하나다. 처음에는 느슨하게 요청하고, 원하는 길이와 형식을 뒤에서 추가하는 방식이 이해하기 쉽다.
Prompt:
항생제에 대해 설명해 줘
A:
Output:
항생제는 세균 감염을 치료하기 위해 사용되는 약물의 일종이다. 세균을 죽이거나 번식을 막아
신체의 면역 체계가 감염에 대응할 수 있도록 돕는다. 항생제는 보통 알약, 캡슐, 액체 형태로
복용하거나 경우에 따라 주사로 투여된다. 바이러스 감염에는 효과가 없고 남용 시 내성이 생길 수 있다.
요약 결과를 더 짧게 원한다면 길이 제약을 직접 넣는다.
Prompt:
항생제는 세균 감염을 치료하기 위해 사용되는 약물의 일종이다. 세균을 죽이거나 번식을 막아
신체의 면역 체계가 감염에 대응할 수 있도록 돕는다. 항생제는 보통 알약, 캡슐, 액체 형태로
복용하거나 경우에 따라 주사로 투여된다. 바이러스 감염에는 효과가 없고 남용 시 내성이 생길 수 있다.
위 내용을 한 문장으로 요약해 줘.
Output:
항생제는 세균 감염 치료에 쓰이지만 바이러스에는 효과가 없고 남용하면 내성을 유발할 수 있다.
정보 추출
정보 추출은 “무엇을 뽑을지”와 “어떤 형태로 반환할지”를 함께 고정해야 안정적이다.
Prompt:
다음 문장에서 장소명을 추출해라.
문장: "민수는 어제 서울역에서 회의를 마치고 부산으로 이동했다."
출력 형식: Place: <comma_separated_list>
Output:
Place: 서울역, 부산
질의응답
질의응답에서는 근거 범위를 먼저 제한하는 것이 중요하다. 모르는 내용을 억지로 채우지 않도록 “근거 없음” 규칙을 미리 선언한다.
Prompt:
아래 문서 내용만 근거로 답변해라.
근거가 없으면 "문서에서 확인할 수 없습니다"라고 답해라.
문서: 환불 신청은 결제 후 7일 이내 가능하다.
질문: 환불 신청 가능 기간은?
Output:
결제 후 7일 이내다.
텍스트 분류
분류 작업은 라벨 정의를 짧고 명확하게 적을수록 정확도가 잘 유지된다.
Prompt:
문장을 neutral/positive/negative 중 하나로 분류해라.
출력은 라벨 1개만 반환해라.
문장: "배송은 늦었지만 상담 대응은 만족스러웠다."
Output:
neutral
대화 응답
대화형 작업은 역할과 답변 길이를 같이 주면 톤이 일정해진다.
Prompt:
당신은 주문 상담 도우미다.
답변은 3문장 이내로 작성하고, 마지막 문장에는 다음 행동 1가지를 제안해라.
고객 질문: 결제 취소는 어디에서 하나요?
Output:
마이페이지의 주문 내역에서 결제 취소를 진행할 수 있다.
결제 상태가 "결제 완료"인 주문만 즉시 취소 가능하다.
지금 주문번호를 알려주면 취소 가능 여부를 바로 확인해 보길 권한다.
코드 생성
코드 생성에서는 언어 버전과 시그니처를 명시해야 결과를 바로 붙여 쓰기 쉽다.
Prompt:
Java 17로 문자열 배열에서 중복을 제거하는 메서드를 작성해라.
메서드 시그니처는 public List<String> dedupe(String[] values)로 고정해라.
null과 빈 배열 입력 처리도 포함해라.
Output:
public List<String> dedupe(String[] values) {
if (values == null || values.length == 0) {
return List.of();
}
return Arrays.stream(values).distinct().toList();
}
추론
추론은 단계 출력을 요구하되, 마지막 답 형식을 고정하면 검증이 쉬워진다.
Prompt:
아래 문제를 단계적으로 풀어라.
각 단계는 한 줄로 쓰고, 마지막 줄에는 최종 답만 출력해라.
문제: 사과 3개가 6,000원일 때 사과 5개의 가격은?
Output:
사과 1개의 가격은 6,000원 / 3 = 2,000원이다.
사과 5개의 가격은 2,000원 x 5 = 10,000원이다.
최종 답: 10,000원
이 단계에서 중요한 운영 포인트는 로그 컨텍스트다. 최소한 아래는 남겨야 추적이 된다.
requestId, promptVersion, model, temperature, maxTokens, latencyMs
응답 지연이 커질 때는 우선 max length와 입력 문맥 길이를 점검하는 편이 빠르다. 토큰 길이는 성능과 비용에 직접 영향을 준다.
마무리
좋은 결과를 만드는 출발점은 복잡한 기법보다 기본 설정과 프롬프트 구조를 안정적으로 잡는 일에 가깝다. LLM 설정을 목적에 맞게 조정하고, 지시와 문맥과 출력 형식을 분리해 관리하면 같은 작업을 훨씬 예측 가능하게 운영할 수 있다.
다음 글에서는 복잡한 작업에 적용할 수 있는 프롬프트 기법을 몇 가지 골라 정리한다.