LLM의 기초 3부 - AI는 왜 프롬프트에 따라 달라지는가?
좋은 프롬프트는 AI의 능력을 바꾸는 것이 아니라, 답변을 만드는 조건을 구체화합니다.
“역할을 부여하세요.”
“단계별로 요청하세요.”
“원하는 출력 형식을 구체적으로 적으세요.”
프롬프트 작성법을 설명할 때 자주 등장하는 조언입니다. 그런데 이런 방법은 왜 효과가 있을까요?
프롬프트가 AI 안에 새로운 지식이나 능력을 설치하는 것은 아닙니다. 모델이 이미 학습한 수많은 지식과 표현 가운데 지금 어떤 정보와 표현을 먼저 활용할지 알려주는 조건을 정해주는 역할을 합니다.
이 글에서는 작성 공식을 배우기 보다, 역할·배경·단계·예시·형식이 어떻게 LLM의 답변에 영향을 주는지 이유를 살펴봅니다.
실제 작성법이 필요하다면 좋은 답변을 얻는 프롬프트 작성법을 함께 참고할 수 있습니다.
프롬프트는 명령어가 아니라 조건이다
LLM은 질문의 뜻을 사람처럼 이해한 뒤 저장된 정답을 꺼내는 프로그램이 아닙니다.
현재까지 주어진 토큰과 그 관계를 바탕으로 다음에 이어질 가능성이 높은 토큰을 계산합니다. 하나를 생성하면 새 토큰까지 Context에 포함하고, 다시 다음 토큰을 계산합니다. 이 반복이 우리가 보는 답변을 만듭니다.
전체 흐름은 다음처럼 정리할 수 있습니다.
사용자 입력 → 토큰화 → Context 안의 관계 계산 → 다음 토큰 후보 계산 → 토큰 선택과 반복 → 답변 완성
여기서 Context는 모델이 현재 답변을 만들 때 참고하는 정보의 범위입니다. 사용자의 질문뿐 아니라 앞선 대화, 제공한 자료, 역할, 예시, 출력 조건도 함께 들어갑니다.
따라서 같은 작업도 Context가 달라지면 다음 토큰의 후보와 우선순위가 달라집니다. 프롬프트는 정답을 직접 지정하는 명령어라기보다, 가능한 답변 중 어떤 방향이 현재 요청에 더 어울리는지 판단하게 하는 조건입니다.
LLM의 동작 원리에서 살펴본 Next Token Prediction이 프롬프트에 따라 달라지는 이유도 여기에 있습니다.
역할은 답변의 기준을 정한다
두 요청을 비교해보겠습니다.
이 계약서를 검토해줘.중소기업의 소프트웨어 개발 계약을 검토하는 실무 법률 자문가의 관점에서
발주사에 위험한 조항과 확인이 필요한 내용을 구분해줘.두 번째 요청에는 법률, 소프트웨어 개발 계약, 발주사, 위험 검토라는 조건이 들어 있습니다. 이 조건은 관련된 어휘와 문서 구조, 검토 기준이 답변에 사용될 가능성을 높입니다.
그렇다고 AI가 실제 자격과 책임을 가진 법률 전문가로 변하는 것은 아닙니다. 역할은 모델의 능력을 새로 만드는 장치가 아니라, 이미 학습한 지식 중 어떤 방식으로 답변할지 알려주는 단서입니다.
역할만 자세히 쓰고 검토할 자료나 목표를 주지 않으면 효과는 제한적입니다. 무엇을 검토해야 하는지 알려주지 않으면 충분한 효과를 내기 어렵기 때문입니다.
배경 설명은 AI가 스스로 채워야 하는 문맥 정보를 줄인다
사용자는 자신의 조직, 고객과 업무 상황을 이미 알고 있습니다. 하지만 AI는 프롬프트와 현재 Context에 들어온 내용만 참고할 수 있습니다.
교육 홍보 문구를 작성해줘.이 요청에는 대상, 교육 내용, 시간, 홍보 목적이 없습니다. 모델은 학습 과정에서 접한 일반적인 교육 광고의 패턴으로 빈칸을 채우게 됩니다. 문장은 자연스러워도 실제 교육과 어긋날 수 있습니다.
Python을 모르는 사무직 재직자를 대상으로,
AI를 활용한 웹크롤링과 반복 업무 자동화를 배우는 14시간 교육의
홍보 문구를 작성해줘.두 번째 요청은 대상 독자와 교육 내용, 난이도, 시간을 알려줍니다. 모델이 임의로 정해야 할 부분이 줄어들기 때문에 결과도 실제 목적에 가까워질 가능성이 높습니다.
배경은 답을 길게 만들기 위한 정보가 아닙니다. 답변에 필요하지 않은 추측을 줄이는 정보입니다.
역할과 예시는 사용할 답변의 형태를 알려준다
역할이 답변의 관점을 정한다면, 예시는 결과가 따라야 할 패턴을 보여줍니다.
예를 들어 고객 문의를 분류하는 형식을 말로 길게 설명하는 대신 한두 개의 입력과 출력을 보여줄 수 있습니다.
입력: 배송이 늦어요.
출력: 배송 / 불만 / 높은 우선순위
입력: 결제 영수증을 다시 받고 싶어요.
출력:모델은 Context 안에서 반복되는 입력과 출력의 관계, 항목의 순서와 표현 방식을 찾아 다음 사례에도 이어가려 합니다. 이를 In-context Learning이라고 부릅니다. 여러 예시를 제공하는 방식은 Few-shot Prompting이라고도 합니다.
여기서 모델의 가중치가 새롭게 학습되는 것은 아닙니다. 현재 대화 안에 놓인 패턴을 참고해 다음 출력을 만드는 것입니다. 예시가 일관되지 않거나 잘못되어 있으면 그 문제도 함께 따라갈 수 있습니다.
역할은 어떤 관점으로 볼지, 예시는 어떤 형태로 이어갈지를 좁힙니다. 두 방법 모두 AI를 새로 학습시키는 것이 아니라 현재 답변의 조건을 구체화합니다.
AI는 한 번에 하나의 문제를 더 잘 해결합니다
복잡한 요청에는 여러 작업이 섞여 있습니다.
이 자료를 분석하고 전략을 세운 뒤 경영진 보고서를 작성해줘.이 한 문장에는 사실 확인, 문제 정의, 대안 비교, 선택, 보고서 작성이 모두 들어 있습니다. 한 번에 처리하면 분석과 작성이 뒤섞이고, 어디서 잘못되었는지 확인하기도 어렵습니다.
작업을 다음처럼 나누면 각 단계의 결과가 다음 작업의 Context가 됩니다.
1. 자료에서 확인되는 사실만 정리한다.
2. 핵심 문제와 가능한 원인을 구분한다.
3. 대안을 비교하고 근거가 부족한 부분을 표시한다.
4. 선택한 대안을 경영진 보고서 형식으로 작성한다.
5. 마지막으로 사실과 해석이 섞이지 않았는지 검토한다.사람은 중간 결과를 보고 방향을 수정할 수 있고, 모델은 확정된 결과를 다음 단계의 조건으로 사용할 수 있습니다.
이는 AI에게 사람처럼 생각하는 법을 가르친다는 뜻이 아닙니다. 복잡한 작업을 여러 개의 작은 작업으로 나누는 방법입니다.
단계가 많을수록 무조건 좋은 것도 아닙니다. 단순한 요청까지 잘게 나누면 불필요하게 길어질 수 있습니다. 중간 확인이 필요한 복잡한 작업에서 사용하는 편이 효과적입니다.
출력 형식은 가능한 답변의 구조를 좁힌다
“정리해줘”라는 요청에는 가능한 결과가 많습니다. 긴 설명문, 짧은 목록, 표, 보고서 중 무엇이 나와도 요청을 어겼다고 보기 어렵습니다.
기업명, 문제, 원인, 제안 조치의 네 열로 표를 작성해줘.이처럼 형식을 정하면 모델이 만들어야 할 구조가 분명해집니다. 각 정보가 들어갈 위치도 정해져 결과를 검토하거나 다른 업무에 연결하기 쉬워집니다.
자동화에서는 JSON처럼 구조화된 형식을 사용할 수도 있습니다.
{
"company": "",
"problem": "",
"cause": "",
"action": ""
}출력 형식은 답변을 일정한 형식으로 만드는 기준입니다. 내용이 사실인지까지 보장하지는 않으므로 별도의 검증은 여전히 필요합니다.
제약 조건은 불필요한 선택지를 줄인다
분량, 독자 수준, 반드시 포함할 내용과 제외할 내용을 알려주면 답변의 범위가 더 좁아집니다.
일반 직장인이 이해할 수 있는 표현을 사용한다.
세 문단 이내로 작성한다.
자료에서 확인되지 않는 수치는 추측하지 않는다.
근거가 부족한 내용은 확인 필요 항목으로 구분한다.이런 조건은 전문용어의 남용이나 무리한 단정을 줄이는 데 도움을 줄 수 있습니다. 다만 제약이 너무 많거나 서로 충돌하면 모델은 무엇을 우선해야 할지 불분명해집니다.
중요한 조건부터 남기고, 충돌할 가능성이 있다면 우선순위를 함께 알려주는 것이 좋습니다.
대화는 현재 Context를 계속 갱신한다
첫 답변을 받은 뒤 “대상을 초보자로 바꿔줘”, “표보다 짧은 문단으로 작성해줘”라고 요청하면 이전 대화와 수정 조건이 다음 답변에 함께 사용됩니다.
이 때문에 AI가 사용자를 점점 더 이해하는 것처럼 느껴질 수 있습니다. 실제로는 현재 Context 안에 쌓인 조건을 참고하는 것입니다.
Context와 장기 Memory는 구분해야 합니다. 새 대화를 시작하거나 Context Window를 넘어선 정보는 다음 답변에서 사용되지 않을 수 있습니다. 이전 답변의 잘못된 내용도 Context에 남아 이후 답변에 영향을 줄 수 있습니다.
쉽게 말해 Context Window는 AI가 답변을 만들 때 한 번에 펼쳐 놓고 볼 수 있는 책상입니다. 대화가 책상보다 길어지면 오래된 내용은 밀려나거나 짧게 정리될 수 있습니다.
대화가 길어졌다면 중요한 목표, 확정된 사실과 남은 작업을 짧게 다시 정리하는 편이 안전합니다.
좋은 프롬프트는 Context를 설계한다
좋은 프롬프트에서 자주 언급되는 요소는 서로 다른 기능을 가집니다.
| 요소 | 답변에서 하는 일 |
|---|---|
| Role | 어떤 관점과 기준을 우선할지 정합니다. |
| Context | 사용할 상황과 자료를 제공합니다. |
| Task | 수행해야 할 작업과 목표를 정합니다. |
| Process | 복잡한 작업의 순서와 중간 결과를 나눕니다. |
| Format | 결과가 따라야 할 구조를 정합니다. |
| Constraints | 지켜야 할 범위와 피해야 할 선택지를 정합니다. |
| Example | 입력과 출력이 따라야 할 패턴을 보여줍니다. |
이 표를 암기 공식으로 받아들일 필요는 없습니다. 모든 요청에 일곱 요소가 필요한 것도 아닙니다.
공통 원리는 하나입니다. 각 요소가 모델이 다음 토큰을 선택할 때 참고할 판단에 필요한 정보를 더 명확하게 제공한다는 점입니다. 필요한 조건만 정확히 제공하는 프롬프트가, 목적 없이 긴 프롬프트보다 낫습니다.
프롬프트가 해결하지 못하는 것도 있다
프롬프트는 강력하지만 모델 자체의 한계를 없애지는 못합니다.
- 모델이 알지 못하는 최신 사실을 자동으로 만들어내지 못합니다.
- 잘못된 자료를 제공하면 그 자료를 바탕으로 잘못된 답을 만들 수 있습니다.
- 역할을 부여해도 실제 전문 자격이나 정확성이 보장되지는 않습니다.
- 출력 형식을 지정해도 환각이나 사실 오류가 사라지는 것은 아닙니다.
- 긴 프롬프트와 많은 예시가 항상 더 좋은 결과를 만드는 것은 아닙니다.
중요한 업무에서는 프롬프트뿐 아니라 신뢰할 수 있는 자료, 검색과 도구, 사람의 검토가 함께 필요합니다.
프롬프트는 AI를 바꾸는 주문이 아니다
프롬프트는 AI에게 없던 능력을 더하는 명령어가 아닙니다.
AI가 이미 학습한 지식과 표현 중에서 어떤 관점과 패턴을 사용해야 하는지, 현재 Context를 통해 범위를 정하는 작업입니다.
역할은 관점을 좁히고, 배경은 AI가 스스로 채워야 하는 정보을 줄입니다. 단계는 문제를 작게 나누고, 예시는 따라야 할 패턴을 보여줍니다. 형식과 제약은 가능한 답변의 구조와 범위를 더 분명하게 만듭니다.
좋은 프롬프트는 질문을 무조건 길게 쓰는 기술이 아닙니다. AI가 이해하기 쉬운 작업 환경을 만드는 기술입니다.
좋은 프롬프트는 좋은 질문에서 시작하지만, 더 좋은 결과는 AI와 함께 만들어가는 과정에서 완성됩니다.