요즘 주위의 많은 PM, 기획자분께서 AI를 어떻게 활용해야 하는지에 관해 자주 물어봅니다.
자주 받는 질문을 크게 두 가지로 나눠볼 수 있는데요, 첫 번째는 AI를 업무에 활용하는 방법과 두 번째는 AI를 활용한 서비스를 기획하고 구현하는 방법입니다.
이번 글에서는 후자, 즉 “프로덕트 수준에서 사용 가능한 일관된 출력을 설계하는 방법”, 그중에서도 핵심인 프롬프트 설계에 관해 이야기해보고자 합니다.
1. 프롬프트 구조의 이해
LLM을 활용한 서비스 설계에서 프롬프트는 크게 두 가지로 나뉩니다.
바로 시스템 프롬프트(System Prompt) 와 유저 프롬프트(User Prompt) 입니다.
이 둘은 단순히 입력 주체가 다르다는 뜻이 아닌, 모델이 사고를 시작하는 기준과 방향을 나누는 구조적인 단위입니다 .
1.1 시스템 프롬프트와 유저 프롬프트로 구분된다
- 시스템 프롬프트(System Prompt)
- 말 그대로 모델이 “누구로서, 어떤 관점에서 사고해야 하는가”를 규정하는 역할을 합니다.
- 모델의 사고 환경과 판단 기준을 정의하는 영역입니다.
- 유저 프롬프트(User Prompt)
- 사용자의 실제 입력으로, 모델이 수행해야 할 즉각적인 과제나 목표(Task) 를 전달합니다.
1.2 이를 어떻게 사용하나
실제 프로덕트에서는 시스템 프롬프트와 유저 프롬프트를 완전히 분리하기보다는, 시스템 프롬프트 내부에 ${user_input} 형태로 유저 입력을 삽입하는 구조가 일반적입니다.
단순히 입력을 합치는 것이 아니라, 사용자의 요청(또는 시스템이 자동 생성한 프롬프트)을 모델의 사고 문맥(Context) 안으로 포함시켜 일관되고 재현성 있는 출력을 얻기 위한 설계 방식입니다.
2. Context 중심의 사고
LLM은 Transformer 구조를 기반으로 합니다. 각 토큰은 다른 모든 토큰과의 관계(Attention Score)를 계산하며, Context Window 안에서 가장 높은 확률의 연관성을 추론합니다. 따라서 모델은 “문장의 의미”가 아니라 토큰 간 확률적 관계망을 이해합니다.
이 때문에 프롬프트 설계의 본질은 ‘명령어 작성’이 아니라 확률 분포의 중심을 어디로 이동시킬 것인가에 대한 설계가 됩니다.
예를 들어,
“이 내용을 요약해줘.”
라는 문장은 단순한 Task 중심 접근입니다.
반면,
“이 문서는 경영진 보고용이며, 핵심 의사결정 포인트만 요약해야 한다.”
라는 문장은 Context 중심 접근입니다.
전자는 명령이지만, 후자는 환경을 설정합니다.
모델은 후자일 때 훨씬 일관되고 예측 가능한 결과를 냅니다.
이것이 바로 프롬프트 설계에서 Context가 중심이 되어야 하는 이유입니다. (해당 내용의 이해가 어렵다면 이전 글을 참고하시면 LLM의 원리에 관해 조금 더 쉽게 이해하실 수 있습니다)
3. 프롬프트는 명령이 아니다
많은 기획자분들이 프롬프트를 단순한 자연어 문장 형태로 작성합니다.
시중에 돌아다니는 “명확히 써라”, “구체적으로 질문하라”는 접근은 개인용 챗봇에서는 충분히 유용하지만, 프로덕트 수준에서 일관된 품질과 재현성을 확보하기에는 한계가 있습니다.
LLM은 문맥 전체를 기반으로 확률 분포를 계산하기 때문에, 하나의 문장 안에 모든 의도를 담으면 모델이 어디에 초점을 두어야 하는지를 판단하지 못합니다.
그 결과, 작성자마다 출력 품질이 달라지고 같은 입력에서도 결과가 일정하지 않게 됩니다.
그래서 프롬프트를 문장으로 쓰지 않고 구조화된 형태로 작성하는 것을 추천드립니다.
이는 모델에게 “무엇을 하라”고 지시하는 것이 아니라, “어떤 사고 경로로 접근해야 하는가”를 설계하는 일입니다.
제가 보편적으로 사용하는 구조는 하단과 같습니다.
[Context] : 모델이 판단해야 할 환경과 기준
[Role] : 모델의 관점과 사고 시점
[Task] : 수행해야 할 목표
[Instruction] : 제약 조건과 품질 기준
[Output] : 결과 형식과 표현 방식
[Example Output] : 결과 예시
이 구조는 단순히 보기 좋게 제작한 양식이 아닌, 모델이 일관된 사고를 하도록 설계한 구조입니다.
개인적으로 저는 프롬프트를 잘 쓴다는 것은 문장을 잘 쓰는 것이 아니라, 사고의 순서를 설계하는 것이라고 생각합니다.
4. 구조 분할의 이유와 근거
최적의 구조는 LLM이 발전함에 따라 변화하겠지만, 2025년 11월 기준으로 높은 정확도와 출력을 낼 수 있습니다.
각 항목은 LLM의 내부 추론 과정과 직접적으로 대응하여 모델이 사고하는 순서에 맞춘 설계로 해당 사유를 조금 더 설명드리도록 하겠습니다.
(1) Context : 모델의 사고 환경을 설정합니다
모델은 주어진 문맥 내에서만 사고합니다.
Context는 모델이 판단할 환경과 기준을 제공합니다. 이 설정이 없으면 모델은 일반적인 언어 패턴으로 회귀하게 됩니다.
→ 확장성: 하나의 Context를 여러 프롬프트에 공통 적용하면 서비스 전체의 언어 일관성을 유지할 수 있습니다.
(2) Role : 모델의 시점을 정의합니다
모델은 자신이 누구라고 인식하느냐에 따라 Attention의 방향이 달라집니다.
Role은 단순한 역할이 아니라, “어떤 판단 기준으로 접근해야 하는가”를 명시하는 장치라고 생각합니다.
→ 확장성: 여러 Role을 병렬로 정의하면 Multi-Agent 혹은 복합 관점 프롬프트로 확장할 수 있습니다.
(3) Task : 목표를 구체적으로 제한합니다
Task는 모델의 예측 공간을 좁히는 역할을 합니다. 명확한 목표가 있을수록 출력의 중심값이 안정됩니다.
→ 확장성: Task를 단계적으로 설계하면 Chain-of-Thought나 Multi-Step Prompt로 확장할 수 있습니다.
(4) Instruction : 모델의 자유도를 제어합니다
LLM은 매우 유연하지만, 제약이 없으면 불필요한 토큰 탐색으로 리소스를 낭비합니다.
Instruction은 모델의 자유도를 통제하여 품질과 일관성을 보장하는 최소한의 규칙이 됩니다.
→ 확장성: Instruction을 구조화하면 서비스별 템플릿 시스템으로 전환할 수 있습니다.
(5) Output : 결과의 형태를 정의합니다
Output은 모델이 토큰을 어떤 형태로 수렴시킬지를 결정합니다.
형식이 명확할수록 모델은 불필요한 장식을 줄이고 결과 구조에 집중합니다.
→ 확장성: Output을 JSON이나 Markdown으로 명세화하면 결과를 다른 시스템과 쉽게 연결할 수 있습니다.
5. 실제 구조화 프롬프트 예시
앞서 설명드린 구조를 활용해, 이커머스 플랫폼의 고객 리뷰 자동 요약 시스템을 위한 프롬프트 예시를 작성해보았습니다.
단순히 “리뷰를 요약하라”는 명령이 아니라, 모델이 고객 감정과 피드백 요인을 구조적으로 분석하도록 유도하는 설계형 프롬프트로 작성해 보았습니다.
[Context]
이 프롬프트는 이커머스 플랫폼의 고객 리뷰 요약 기능에 사용됩니다.
모델은 다양한 제품 리뷰를 분석하여 **구매 의사결정에 도움이 되는 요약**을 생성해야 합니다.
모든 판단은 리뷰 텍스트에 기반해야 하며, 감정이나 의도를 임의로 추정하지 않습니다.
[Role]
당신은 고객 경험 분석 전문가입니다.
수천 건의 리뷰 데이터를 기반으로 **감정의 방향성과 핵심 피드백 요인**을 식별합니다.
[Task]
1. 입력된 리뷰를 분석하여 주요 감정(긍정 / 부정 / 중립)을 판별합니다.
2. 리뷰에서 반복적으로 언급되는 주요 키워드 3개를 추출합니다.
3. 긍정·부정 요약을 각각 2문장 이내로 작성하고, 마지막에 개선 제안을 1문장으로 정리하십시오.
[Instruction]
- 문장은 간결하고 객관적으로 작성합니다.
- 수치, 빈도, 구체적 피드백을 우선적으로 반영합니다.
[User Input]
${user_input}
[Output]
- **감정 요약:** (긍정 / 부정 / 중립 중 택1)
- **주요 키워드:** 키워드1, 키워드2, 키워드3
- **요약 결과:**
- 긍정 요약:
- 부정 요약:
- 개선 제안:
[Example Output]
- 감정 요약: 긍정
- 주요 키워드: 배송, 포장, 품질
- 요약 결과:
- 긍정 요약: 배송이 빠르고 포장 상태가 좋습니다.
- 부정 요약: 일부 제품의 품질이 기대에 미치지 않습니다.
- 개선 제안: 품질 검수 프로세스를 강화하십시오.
6. 구조화를 시스템이 이해하도록 만드는 법
제작하여 보여드린 프롬프트 구조는 사람이 읽기 좋은 형태입니다.
하지만 LLM에게는 아닙니다. LLM이 더 잘 이해할 수 있도록 시스템 친화적으로 구조화해야 합니다.
LLM은 입력된 텍스트를 토큰 단위로 분리하고, 각 토큰의 의미를 벡터 공간(Embedding Space)으로 투영합니다.
이후 Attention Head가 이 벡터 간의 관계를 계산하며 문맥적 의미를 추론합니다.
JSON이나 /br 같은 구조적 구분자는 이 Attention Head가 영역의 경계를 인식하기 쉽게 만들어, 모델이 “지침”과 “출력 대상”을 구분하도록 도와줍니다.
반대로 모든 텍스트가 하나의 덩어리로 입력되면, 모델은 동일한 확률 공간에서 의미를 해석하려 하여 명령과 맥락이 섞이는 혼동이 발생할 수 있습니다.
(1) JSON 구조 활용
가장 명확한 방법은 JSON 형태로 구조를 정의하는 것입니다.
{
"Context": "이 프롬프트는 이커머스 플랫폼의 고객 리뷰 요약 기능에 사용됩니다. 모델은 다양한 제품 리뷰를 분석하여 구매 의사결정에 도움이 되는 요약을 생성해야 합니다. 모든 판단은 리뷰 텍스트에 기반해야 하며, 감정이나 의도를 임의로 추정하지 않습니다.",
"Role": "고객 경험 분석 전문가입니다. 수천 건의 리뷰 데이터를 기반으로 감정의 방향성과 핵심 피드백 요인을 식별합니다.",
"Task": [
"입력된 리뷰를 분석하여 주요 감정(긍정 / 부정 / 중립)을 판별합니다.",
"리뷰에서 반복적으로 언급되는 주요 키워드 3개를 추출합니다.",
"긍정·부정 요약을 각각 2문장 이내로 작성하고, 마지막에 개선 제안을 1문장으로 정리합니다."
],
"Instruction": [
"문장은 간결하고 객관적으로 작성합니다.",
"수치, 빈도, 구체적 피드백을 우선적으로 반영합니다."
],
"UserInput": "${user_input}",
"OutputFormat": {
"감정요약": "긍정 / 부정 / 중립 중 택1",
"주요키워드": ["키워드1", "키워드2", "키워드3"],
"요약결과": {
"긍정요약": "",
"부정요약": "",
"개선제안": ""
}
},
"ExampleOutput": {
"감정요약": "긍정",
"주요키워드": ["배송", "포장", "품질"],
"요약결과": {
"긍정요약": "배송이 빠르고 포장 상태가 좋습니다.",
"부정요약": "일부 제품의 품질이 기대에 미치지 않습니다.",
"개선제안": "품질 검수 프로세스를 강화하십시오."
}
}
}
이 구조는 모델이 각 영역을 명확히 구분할 수 있게 하며, 영문으로 작성 시 토큰 사용량을 15~20% 절감할 수 있습니다.
(2) 경량 구분자(/br, ) 활용
아쉽게도 모든 협업하시는 분들이 JSON을 이해하는 것은 아닙니다.
특히 기획자들이 많은 환경에서는 자연어 기반 구조가 더 직관적이고, 유지보수 차원에서 적합할 수 있습니다.
이 경우 /br이나 *, ---와 같은 경량 구분자를 사용해도 JSON보다는 아니지만 효과적입니다.
*Context
이 프롬프트는 e커머스 리뷰 요약용입니다.
/br
*Role
고객 경험 분석 전문가입니다.
/br
*Task
리뷰를 감정별로 분류하고 핵심 피드백 3개를 요약하십시오.
/br
*User Input
${user_input}
/br
*Output
감정요약 / 주요키워드 / 요약결과(긍·부정·개선제안)
중요한 것은 구분 방식보다 일관성이라고 생각합니다. LLM은 형태보다는 패턴을 더 잘 인식하기 때문입니다.
(3) 선택 기준
- 협업하는 분들이 JSON을 다룰 수 있고 개발 연계가 필요한 프로덕트 → JSON 기반 구조가 적합
- 기획자 중심의 실험 환경 → 구분자 기반 자연어 구조가 유지보수에 효율적
저도 회사의 공식 시스템 프롬프트에는 자연어 기반 구조를 사용하고, 개인 프로젝트에서는 JSON 형태를 적용하고 있습니다.
중요한 건 일관된 구조 설계입니다.
7. 마무리하며
앞으로 AI는 더 정교한 추론을 통해, 단순한 문장 입력만으로도 높은 품질의 출력을 낼 수 있을 것입니다.
그러나 기업의 제품 차원에서는 이야기가 다릅니다.
AI의 성능 향상만으로는 제품의 품질이 보장되지 않습니다.
모델의 동작 원리를 이해하고, 그 기반 위에서 프롬프트를 설계해야 더 고차원의 프롬프트를 설계할 수 있다고 생각합니다.
비슷한 고민을 하고 계신 분들께 작은 힌트가 되었으면 합니다.