프롬프트 구조 설계하기: 역할, 목표, 자료, 제약, 출력 형식 다섯 요소

🤔 같은 요청인데 어제와 오늘 결과가 다를 때

회의록을 붙여 넣고 "정리해 줘"라고 하면 어떤 날은 표가 나오고 어떤 날은 줄글이 나옵니다. 어떤 날은 결정 사항만 남고 어떤 날은 잡담까지 다 옮겨집니다. 모델이 바뀐 것도 아니고 자료가 바뀐 것도 아닌데 결과가 흩어지는 이유는 요청 문장에 해석할 여지가 그만큼 남아 있기 때문입니다.

프롬프트 엔지니어링 기본에서 다섯 요소가 무엇인지는 이미 정리되어 있습니다. 여기서는 그 다섯 요소를 어떤 순서로 놓고 어떻게 경계를 나누는지, 그리고 다 쓴 프롬프트를 어떻게 점검하는지를 다룹니다.

🔑 프롬프트 구조 설계의 정의

프롬프트 구조 설계는 AI에게 보내는 요청 문장을 역할과 목표, 자료, 제약, 출력 형식 다섯 요소로 나누어 적고 각 요소를 구분 표시로 분리하는 작성 방식입니다. 요소를 나누는 이유는 두 가지입니다. 모델이 지시와 자료를 섞어 읽지 않게 하고, 사람이 빠진 요소를 눈으로 확인할 수 있게 하기 위해서입니다.

앤트로픽 공식 문서는 이 방식을 한 문장으로 요약합니다. 클로드를 똑똑하지만 우리 회사의 관례를 전혀 모르는 신입 직원으로 생각하라는 것입니다. 무엇을 원하는지 정확히 설명할수록 결과가 좋아지고, 반대로 "알아서 잘"이라는 부분이 남을수록 결과가 흩어집니다.

🧱 다섯 요소가 각각 맡는 일

주문서에 메뉴와 수량, 포장 여부, 매운 정도를 칸마다 적듯 프롬프트도 요소마다 담는 내용이 정해져 있습니다.

다섯 가지를 모두 채우지 않아도 되는 때가 있습니다. 짧은 번역이나 문장 교정은 목표 하나로 충분합니다. 다섯 요소가 필요해지는 것은 같은 작업을 반복하거나 결과를 다른 사람에게 넘길 때입니다.

🏷️ 요소 사이의 경계를 나누는 두 가지 표시

요소를 나눠 적어도 한 문단에 줄줄이 이어 쓰면 모델은 어디까지가 자료이고 어디부터가 지시인지 구분하기 어렵습니다. 경계를 표시하는 방법은 두 가지이고, 앤트로픽과 OpenAI가 각각 다른 쪽을 권합니다.

• XML 태그: 꺾쇠 괄호로 감싼 이름표입니다. 앤트로픽 공식 문서는 지시와 맥락, 예시, 입력이 섞인 프롬프트를 <instructions>, <context>, <input> 같은 태그로 감싸 오해를 줄이라고 권합니다. 태그 이름은 프롬프트 전체에서 같은 것을 쓰고, 문서 여러 개를 넣을 때는 <documents> 안에 <document index="1">처럼 계층을 둡니다
• 마크다운 제목과 구분선: OpenAI 도움말은 지시를 프롬프트 맨 앞에 두고 ###이나 따옴표 세 개로 지시와 자료를 나누라고 안내합니다. 제목으로 구역을 나누면 사람도 빠진 조건을 눈으로 확인하기 쉽습니다

둘 가운데 무엇을 쓰든 원칙은 같습니다. 자료를 그대로 붙여 넣지 않고 감싸서 넣고, 감싸는 이름을 매번 같게 씁니다. 마크다운으로 구역을 나누는 이유와 문법은 AI 시대에 마크다운이 중요한 이유에 있습니다.

📐 다섯 요소를 놓는 순서

순서에도 근거가 있습니다. 앤트로픽 공식 문서는 20,000토큰이 넘는 긴 문서를 다룰 때 자료를 프롬프트 맨 위에, 질문과 지시를 맨 끝에 두라고 권하고, 이렇게 배치했을 때 시험에서 답변 품질이 최대 30%까지 올랐다고 밝힙니다. 짧은 자료에서는 차이가 작지만 습관을 같은 순서로 들여 두면 자료가 길어져도 고칠 것이 없습니다.

위에서부터 자료, 역할, 목표, 출력 형식, 제약 순서입니다. 자료가 두 개라 태그 이름을 다르게 붙였고, 지시는 전부 자료 아래에 모여 있습니다. 같은 회의록을 넣으면 매번 비슷한 형식의 결과가 나오는 구조입니다.

🔍 막연한 수식어를 확인할 수 있는 조건으로 바꾸기

다섯 요소를 다 채워도 안에 적힌 말이 막연하면 소용이 없습니다. "전문적으로", "깔끔하게", "창의적으로"는 무엇을 어떻게 하라는지 알려 주지 않습니다. 준이아빠블로그의 프로젝트 지침 쓰는 법에서 정리한 기준을 옮기면, 결과물만 보고도 그 조건이 지켜졌는지 확인할 수 있어야 잘 듣는 조건입니다.

여기에 이유를 붙이면 한 단계 더 나아갑니다. 앤트로픽 공식 문서는 "줄임표를 쓰지 마세요"보다 "이 답은 음성 합성기가 읽어 줄 것이라 줄임표를 발음하지 못하니 쓰지 마세요"가 낫다고 예를 듭니다. 이유를 알면 모델이 비슷한 다른 상황에도 같은 기준을 적용합니다.

🙋 다 쓴 프롬프트를 점검하는 방법

앤트로픽 공식 문서가 황금률이라고 부르는 점검법이 있습니다. 작업 맥락을 거의 모르는 동료에게 프롬프트를 보여 주고 그대로 따라 해 보라고 합니다. 그 사람이 헷갈릴 부분이 있으면 클로드도 헷갈립니다. 동료가 "결정 사항이 확정된 것만인지 논의 중인 것도 포함인지"를 되묻는다면 그 부분이 프롬프트에 빠진 것입니다.

혼자 점검할 때는 다섯 요소를 순서대로 확인합니다.

1. 역할이 없어도 되는 작업인지, 있다면 한 문장으로 적혔는지 봅니다.
2. 목표가 한 문장인지, 두 가지 이상의 일이 한 문장에 묶여 있지는 않은지 봅니다.
3. 자료가 태그나 제목으로 감싸져 있고 지시 위에 놓였는지 봅니다.
4. 제약에 하지 말 것과 범위가 적혔는지, 그 조건을 결과물에서 확인할 수 있는지 봅니다.
5. 출력 형식이 표인지 목록인지 글자 수인지 적혔는지 봅니다.

앤트로픽 문서가 지적하는 실수가 하나 더 있습니다. 하지 말 것만 적는 것입니다. "마크다운을 쓰지 마세요"보다 "매끄럽게 이어지는 문단으로 써 주세요"가 낫습니다. 금지만 적으면 그 빈자리를 모델이 다른 것으로 채웁니다.

⚠️ 자주 하는 실수

• 한 프롬프트에 일곱 가지 넘는 작업을 묶습니다: 일부가 빠집니다. 큰 작업은 초안과 검토와 다듬기처럼 단계로 나눕니다
• 자료를 지시 뒤에 붙입니다: 자료가 길어질수록 지시가 잘 보이지 않습니다. 자료를 위에, 지시를 아래에 둡니다
• 태그 이름을 매번 다르게 씁니다: <자료>와 <문서>와 <입력>을 섞으면 모델도 사람도 구조를 알아보기 어렵습니다
• 역할만 길게 적고 목표는 짧게 적습니다: "20년 경력의 전문가"보다 "결론을 첫 문장에 쓰고 근거는 세 개로"가 결과를 바꿉니다
• 제약을 금지문으로만 적습니다: 하지 말 것 옆에 대신 할 것을 적어야 빈자리가 엉뚱하게 채워지지 않습니다

❓ 자주 묻는 질문

다섯 요소를 매번 다 적어야 하나요?

아닙니다. 번역이나 문장 교정처럼 한 번에 끝나는 짧은 작업은 목표 한 줄로 충분합니다. 다섯 요소가 필요해지는 때는 같은 작업을 반복하거나, 결과를 다른 사람에게 넘기거나, 자료가 길어질 때입니다. 처음에는 목표와 출력 형식 두 가지만 챙기고 결과가 흩어지면 제약을 더하는 순서가 부담이 적습니다.

XML 태그와 마크다운 제목 가운데 무엇을 써야 하나요?

어느 쪽이든 됩니다. 앤트로픽 문서는 XML 태그를, OpenAI 도움말은 ### 구분선을 권하지만 둘 다 지시와 자료를 섞지 말라는 뜻입니다. 채팅 화면에서는 마크다운 제목이 읽기 편하고, 코드에서 자료를 끼워 넣을 때는 태그가 경계를 분명히 합니다. 한 프롬프트 안에서 한 가지로 통일하는 것이 더 중요합니다.

역할을 적으면 정말 결과가 달라지나요?

앤트로픽 공식 문서는 시스템 프롬프트에 역할을 한 문장만 적어도 차이가 난다고 설명합니다. 다만 역할은 관점과 어조를 정하는 요소라 범위를 좁히거나 형식을 고정하지는 않습니다. 결과의 범위가 문제라면 제약을, 모양이 문제라면 출력 형식을 먼저 고칩니다. 역할을 어디에 적는지는 시스템 프롬프트와 사용자 프롬프트 차이에서 이어집니다.

자료를 위에 두라는 것은 짧은 자료에도 해당하나요?

공식 문서가 밝힌 30%라는 수치는 20,000토큰이 넘는 긴 자료와 여러 문서를 넣었을 때의 결과입니다. 짧은 자료에서는 차이가 작습니다. 다만 순서를 항상 같게 두면 자료가 길어졌을 때 프롬프트를 다시 짜지 않아도 되므로 처음부터 같은 순서로 쓰는 편이 낫습니다.

📋 3줄 요약

1. 프롬프트 구조 설계는 요청 문장을 역할과 목표, 자료, 제약, 출력 형식 다섯 요소로 나누어 적고 요소마다 XML 태그나 마크다운 제목으로 경계를 표시하는 작성 방식입니다.

2. 앤트로픽 공식 문서는 긴 자료를 프롬프트 맨 위에 두고 질문을 맨 끝에 두면 답변 품질이 시험에서 최대 30% 올랐다고 밝히고, 지시와 자료와 예시가 섞인 프롬프트는 태그로 구분하라고 권합니다.

3. 다 쓴 프롬프트는 맥락을 모르는 동료에게 보여 줘 그 사람이 그대로 따라 할 수 있는지로 점검하고, 막연한 수식어는 확인할 수 있는 조건으로 바꿉니다.

📚 참고 자료

• Prompting best practices, Claude Platform Docs
• Prompt engineering overview, Claude Platform Docs
• Best practices for prompt engineering with the OpenAI API, OpenAI Help Center
• 프롬프트 엔지니어링 기본 익히기, 준이아빠블로그
• 클로드 프로젝트 지침 쓰는 법, 준이아빠블로그

2026년 9월 28일 기준으로 공식 문서를 확인했습니다.