프롬프트 엔지니어링 기초: 좋은 프롬프트는 어떻게 쓸까요?

프롬프트 표현이 중요한 이유

언어 모델은 내 상황을 모릅니다. 보내는 텍스트만 봅니다. 프롬프트가 모호하면 모델은 빈틈을 가장 전형적인 답으로 채우는데, 그 답은 대개 평범하거나 너무 길거나 엉뚱한 독자를 향합니다. 프롬프트 엔지니어링은 대부분 추측할 여지를 없애는 작업입니다.

이렇게 점검해 보세요. 나를 만난 적 없는 똑똑한 신입 동료가 내 메시지만 보고 일을 잘 해낼 수 있을까요? 먼저 세 가지를 되물어야 한다면 모델에게도 그 답이 필요합니다. OpenAI, Anthropic, Google의 공식 가이드도 표현만 다를 뿐 핵심 조언은 같습니다. 분명하고 구체적으로 쓰고, 배경을 주고, 예시를 보여 주고, 원하는 형식을 말하라는 것입니다.

좋은 프롬프트의 6가지 요소

모든 프롬프트에 여섯 가지가 다 필요하지는 않지만, 이 목록을 점검하면 약한 프롬프트 대부분이 해결됩니다.

긴 입력 자료는 XML 스타일 태그나 큰따옴표 세 개 같은 분명한 표시로 감싸세요. 그러면 모델이 내 지시문과 처리할 텍스트를 구분할 수 있습니다. 붙여 넣은 웹 페이지처럼 입력 속에 숨은 지시를 실수로 따를 위험도 줄어듭니다.

전과 후: 프롬프트 고쳐 쓰기

전형적인 약한 프롬프트입니다.

Summarize this article.

모델은 요약을 내놓겠지만, 길이는 얼마나, 누구를 위해, 어떤 형태로 쓸까요? 같은 요청에 빈틈을 채우면 이렇게 됩니다.

You are helping a busy product manager decide whether to read a research article.

Summarize the article below for that reader.
- Start with one sentence: the main finding.
- Then 3 bullet points: method, key number, main limitation.
- Use plain English. Explain any technical term in a few words.
- Under 100 words in total.
- If the article does not state a limitation, write "No limitation stated".

<article>
{paste the article here}
</article>

각 부분의 역할은 다음과 같습니다.

• 첫 줄은 독자와 목적을 정합니다. 모델은 요약이 왜 필요한지 알게 되어 무엇을 남길지 고릅니다.
• 글머리 기호 구조는 형식을 고정해 모든 요약이 같은 모양이라 비교하기 쉽습니다.
• 단어 수 제한은 모델이 분량을 늘려 채우는 것을 막습니다.
• 한계가 없을 때의 규칙은 예외 상황에서 모델이 한계를 지어내지 않고 무엇을 할지 알려 줍니다.
• 태그는 기사 본문과 지시문을 구분합니다.

말로 부족할 때는 예시를 보여 주세요

말투, 분류 체계, 특정 출력 스타일처럼 설명하기는 어렵지만 보여 주기는 쉬운 요구가 있습니다. 풀어 쓴 예시를 몇 개 더하는 방법을 퓨샷 프롬프팅(few-shot prompting)이라고 합니다. 예시 하나(원샷)만으로도 큰 도움이 되는 경우가 많습니다. 서로 다른 예시 두세 개에서 다섯 개 정도면 대개 주요 사례를 다룹니다.

Classify each support message as BILLING, SHIPPING, PRODUCT or OTHER.
Reply with the label only.

Message: I was charged twice for order 5521.
Label: BILLING

Message: The handle on my mug cracked after one week.
Label: PRODUCT

Message: Do you have a shop in Osaka?
Label: OTHER

Message: {new message}
Label:

예시는 서로 다르게 만드세요. 모두 짧고 공손하기만 하면 길고 화난 메시지를 잘 처리하지 못할 수 있습니다. 예시가 규칙과 일치하는지도 확인하세요. 모델은 글로 쓴 지시보다 예시를 더 강하게 따라 합니다.

특정 상황에서 도움이 되는 기법

• 답변 전에 단계를 쓰게 하세요. 수학, 논리, 여러 부분으로 된 결정에서는 최종 답 전에 문제를 풀어 나가게 하면 정확도가 올라갑니다. 이를 생각의 사슬(chain-of-thought) 프롬프팅이라고 합니다. 요즘 모델 중에는 이를 내부에서 하는 것이 많아(흔히 추론 또는 생각 모드), 신중하게 답해 달라는 한마디로 충분할 수도 있습니다.
• 큰 작업을 나누세요. "조사하고, 개요를 짜고, 보고서를 써 줘"를 한 프롬프트에 넣지 말고 프롬프트 세 개로 나눠 각 결과를 확인하세요. 이것을 프롬프트 체이닝(prompt chaining)이라고 합니다.
• 정보를 더할 때만 역할을 주세요. "당신은 베트남의 세무사입니다"는 단어 선택과 전제를 바꿉니다. "당신은 세계 최고의 천재입니다"는 아무것도 더하지 않습니다.
• 피할 것만이 아니라 할 것을 말하세요. "짧은 문장으로 쓰세요"가 "장황하게 쓰지 마세요"보다 잘 먹힙니다.
• "모르겠다"를 허용하세요. 정보가 없다고 말해도 된다고 알려 주세요. 지어낸 사실이 줄지만 완전히 사라지지는 않습니다.
• 코드가 출력을 읽을 때는 기계가 읽을 수 있는 형식을 요청하세요. 예를 들어 필드 이름이 정해진 JSON입니다. 대부분의 API는 JSON 스키마를 직접 강제할 수도 있습니다.

프롬프트도 코드처럼 테스트하세요

예시 하나에서 잘 되는 프롬프트도 다음 예시에서는 실패할 수 있습니다. 프롬프트를 다시 쓰거나 다른 사람이 쓸 거라면 테스트하세요.

1. 좋은 결과가 어떤 모습인지 적어 두세요. 길이, 형식, 반드시 맞아야 하는 사실입니다.
2. 실제 입력 10~20개를 모으세요. 아주 짧은 것, 아주 긴 것, 주제에서 벗어난 것, 다른 언어 같은 어려운 경우도 넣습니다.
3. 전부에 프롬프트를 돌려 결과를 하나하나 읽으세요.
4. 한 번에 하나만 바꾸고 전체 세트를 다시 돌려, 어떤 변경이 도움이 됐는지 확인하세요.
5. 최종 프롬프트와 테스트 세트를 함께 보관하세요. 모델을 바꾸거나 모델이 업데이트되면 세트를 다시 돌립니다.

마지막 단계가 중요한 이유는, 같은 프롬프트도 모델마다, 같은 모델의 새 버전에서도 다르게 동작할 수 있기 때문입니다. 모델 제작사들의 프롬프트 엔지니어링 가이드가 시간이 지나며 바뀌는 것도 이 때문입니다.

흔한 실수

• 한 프롬프트에 목표가 너무 많습니다. 비중이 같은 규칙 열 개는 일부가 무시됩니다. 가장 중요한 규칙을 앞에 두고 목록을 짧게 하세요.
• "자세히 쓰세요"와 "50단어 이내로"처럼 서로 모순됩니다. 모델은 하나를 만족시키고 다른 하나를 어깁니다.
• 분명한 이유 대신 대문자나 협박조("반드시 해야 합니다")에 기댑니다. 규칙이 왜 있는지 짧게 설명하는 편이 대개 더 잘 통합니다.
• 입력과 지시문을 구분하지 않아서, 모델이 문서의 일부를 명령으로 받아들입니다.
• 결과 속 사실을 그대로 믿습니다. 잘 쓴 프롬프트도 자신 있는 실수를 만듭니다. 이름, 숫자, 인용문, 링크를 확인하세요.