역할 설계와 지시의 계층

"당신은 전문가입니다"만으로는 부족하다

프롬프트를 처음 배우는 사람이 가장 빨리 익히는 문장이 있습니다. "당신은 ○○ 전문가입니다." 마케팅 문안을 쓰고 싶으면 "당신은 10년 차 마케터입니다"라고 하고, 계약서를 검토하고 싶으면 "당신은 변호사입니다"라고 쓰는 식입니다. 이 문장은 확실히 도움이 됩니다. 모델에게 답변의 관점과 말투를 알려 주기 때문입니다.

하지만 실무에서는 여기서 멈추면 위험합니다. "전문가처럼 답하라"는 말은 멋진 문장을 만들 수는 있어도, 책임의 경계를 정해 주지는 못합니다. 의료 안내문을 쉽게 바꾸는 작업에서 AI가 진단을 단정하면 안 됩니다. 법률 문서를 요약하는 작업에서 AI가 "이 조항은 무효입니다"라고 판정하면 곤란합니다. 고객 상담 초안을 만드는 작업에서 AI가 환불을 약속하거나 보상 금액을 확정해서도 안 됩니다.

역할 설계는 말투를 꾸미는 장치가 아닙니다. 역할 설계는 AI가 무엇을 맡고, 무엇을 맡지 않으며, 어떤 기준으로 답하고, 어디서 멈춰야 하는지를 정하는 장치입니다. 앞 장에서 예시를 통해 모델에게 작업 방식을 가르치는 법을 배웠다면, 이번 장에서는 그 작업을 여러 층으로 나누어 안정적으로 통제하는 법을 배웁니다.

핵심은 간단합니다. 프롬프트 안의 모든 지시를 한 덩어리로 넣지 말고, 지시의 종류를 분리해야 합니다. 정체성과 책임 범위, 실제 업무 요청, 출력 형식, 안전 규칙이 뒤섞이면 모델은 어느 지시가 더 중요한지 헷갈립니다. 반대로 층위를 나누면 답변은 더 일관되고, 팀 안에서 재사용하기도 쉬워집니다.

대화에는 역할이 있다

ChatGPT나 GPT API의 대화는 겉으로 보기에는 사람이 질문하고 AI가 답하는 단순한 구조처럼 보입니다. 그러나 내부적으로는 메시지마다 역할이 붙습니다. 대표적으로 system, developer, user, assistant라는 역할이 있습니다. OpenAI의 모델 사양은 대화 속 지시가 system, developer, user 메시지 등에 담길 수 있으며, 이런 지시들이 모델의 응답 후보를 결정하는 데 영향을 준다고 설명합니다.¹ 쉽게 말해, 모델은 단순히 마지막 질문만 보는 것이 아니라 "누가 어떤 층위에서 말했는가"도 함께 참고합니다.

먼저 system 메시지는 가장 바깥쪽의 운영 원칙에 가깝습니다. 이 AI가 어떤 목적의 도구인지, 어떤 안전 원칙을 지켜야 하는지, 절대 넘지 말아야 할 경계가 무엇인지 정합니다. 사람으로 비유하면 회사의 정관이나 업무 규정에 해당합니다. 매번 바뀌는 요청이 아니라, 해당 도구가 존재하는 동안 유지되어야 하는 큰 규칙입니다.

developer 메시지는 애플리케이션이나 서비스 제작자가 정하는 실행 지침에 가깝습니다. system이 "이 도구는 어떤 원칙을 지키는가"를 말한다면, developer는 "이 제품 안에서 이 기능은 어떻게 작동해야 하는가"를 말합니다. 예를 들어 고객 상담 도구라면 "항상 고객 문의를 분류한 뒤 답변 초안을 작성하라", "환불 가능 여부는 내부 정책 문서에 근거가 있을 때만 말하라" 같은 지침이 여기에 들어갈 수 있습니다.

user 메시지는 실제 사용자의 요청입니다. "이 문서를 요약해 줘", "이 고객 문의에 답변해 줘", "이 조항의 리스크를 정리해 줘"처럼 그 순간 처리해야 할 과업이 들어갑니다. 사용자의 목적과 자료, 원하는 결과물이 여기에 놓입니다.

assistant 메시지는 AI가 이전에 한 답변입니다. 대화가 이어질 때 assistant 메시지는 문맥의 일부가 됩니다. 사용자가 "방금 답변을 더 짧게 줄여 줘"라고 하면, 모델은 이전 assistant 메시지를 참고해 새 답변을 만듭니다. API를 사용할 때는 과거 대화를 함께 보내야 맥락이 유지되며, system 메시지와 user 메시지, assistant 응답이 함께 대화의 흐름을 구성합니다.²

이 네 역할을 한국어 업무 환경에 맞춰 비유하면 다음과 같습니다.

일반 ChatGPT 화면에서 사용자가 이 네 역할을 모두 직접 조작하는 것은 아닙니다. 하지만 개념을 이해하는 것만으로도 프롬프트 품질이 크게 달라집니다. 특히 custom GPT, 팀용 지침, API, 자동화 도구를 만들 때는 이 구분이 거의 설계도의 역할을 합니다.

지시의 계층: 위쪽은 원칙, 아래쪽은 요청

좋은 역할 설계는 "무엇이 더 중요한 지시인가"를 분명히 합니다. 사용자가 어떤 요청을 하더라도 지켜야 하는 원칙이 있고, 그 안에서만 수행되는 업무 지시가 있습니다. 고객센터 상담원을 생각해 보면 쉽습니다. 고객이 "그냥 전액 환불해 주세요"라고 요청한다고 해서 상담원이 회사 정책과 법적 기준을 무시하고 환불을 확정할 수는 없습니다. 사용자의 요청은 중요하지만, 그 요청은 상위 규칙 안에서 처리되어야 합니다.

AI도 마찬가지입니다. "친절하게 답하라"는 말보다 "확인되지 않은 환불 약속을 하지 말라"는 말이 더 중요합니다. "자세히 설명하라"는 말보다 "의학적 진단을 단정하지 말라"는 말이 더 중요합니다. "사용자가 원하면 무엇이든 도와라"는 말보다 "개인정보를 노출하지 말라"는 말이 더 중요합니다.

그래서 프롬프트를 설계할 때는 지시를 아래와 같이 나누어 생각하는 것이 좋습니다.

1. 역할 지시는 AI의 정체성과 책임 범위를 정합니다. "너는 무엇을 돕는 도구인가?"에 답합니다.

2. 업무 지시는 이번에 처리할 일을 정합니다. "지금 어떤 일을 해야 하는가?"에 답합니다.

3. 출력 지시는 결과물의 모양을 정합니다. "어떤 형식으로 내놓아야 하는가?"에 답합니다.

4. 안전 지시는 하면 안 되는 일과 멈춰야 할 조건을 정합니다. "어디까지가 한계인가?"에 답합니다.

여기서 중요한 점은 안전 지시를 마지막에 덧붙이는 장식처럼 다루면 안 된다는 것입니다. "개인정보는 조심해 줘" 정도로 끝내면 모델은 무엇을 제거해야 하는지, 어떤 경우에 답변을 거절해야 하는지, 어떤 경우에 사람에게 넘겨야 하는지 알기 어렵습니다. 안전 지시는 가능한 한 구체적이어야 합니다.

나쁜 예를 보겠습니다.

당신은 의료 전문가입니다.
아래 내용을 환자에게 설명해 주세요.
친절하고 자세하게 답해 주세요.
[검사 결과 내용]

이 프롬프트는 그럴듯하지만 위험합니다. "의료 전문가"라는 표현은 모델이 진단이나 치료 판단까지 해도 되는 것처럼 행동하게 만들 수 있습니다. 환자에게 설명하라는 요청도 어디까지 설명해도 되는지 불분명합니다. 검사 결과에 개인정보가 포함되어 있을 수도 있는데, 비식별화나 보호자 안내 같은 조건도 없습니다.

조금 더 나은 설계는 이렇습니다.

[역할]
당신은 의료기관의 환자 안내문 편집 보조 도구다.
진단, 처방, 예후를 단정하지 않는다.
의사의 최종 설명을 대체하지 않고, 어려운 표현을 쉬운 한국어로 바꾸는 데 집중한다.

[업무]
아래 검사 안내문을 중학생도 이해할 수 있는 한국어로 다시 써라.

[출력]
- 한 줄 요약
- 쉬운 설명
- 환자가 의료진에게 확인할 질문 3개

[안전]
- 원문에 없는 진단명, 치료법, 수치를 추가하지 말라.
- 응급 증상이나 위험 신호가 언급되면 즉시 의료진에게 문의하라는 문장을 포함하라.
- 주민등록번호, 전화번호, 주소 등 개인정보가 있으면 [삭제]로 표시하라.

[원문]
...

두 프롬프트는 같은 일을 요청하지만 성격이 완전히 다릅니다. 첫 번째는 "전문가처럼 말해 달라"에 가깝고, 두 번째는 "보조 도구로서 어디까지 수행할지"를 정합니다. 실무에서 필요한 것은 두 번째입니다.

역할 지시와 업무 지시를 분리하라

많은 프롬프트가 실패하는 이유는 역할 지시와 업무 지시가 한 문장 안에 뒤엉켜 있기 때문입니다. 예를 들어 다음 문장을 보겠습니다.

당신은 친절한 변호사처럼 아래 계약서를 검토해서 문제 조항을 찾아 고쳐 주세요.

짧고 편해 보이지만, 이 문장에는 위험한 요소가 여럿 있습니다. "변호사처럼"은 역할을 말하지만 실제 변호사 자문과 AI 보조 검토의 경계를 흐립니다. "문제 조항"은 판단 기준이 모호합니다. "고쳐 주세요"는 계약 당사자의 의도, 준거법, 협상 전략을 모르는 상태에서 조항을 확정적으로 바꾸게 만들 수 있습니다.

역할 지시는 이렇게 따로 세우는 편이 안전합니다.

[역할]
당신은 계약서 검토를 돕는 문서 분석 보조 도구다.
법률 자문을 제공하지 않으며, 최종 판단은 자격 있는 전문가가 해야 한다.
계약 조항의 잠재적 쟁점, 모호한 표현, 추가 확인 질문을 정리한다.

그다음 업무 지시를 별도로 둡니다.

[업무]
아래 비밀유지계약서 초안을 검토하고, 실무자가 변호사에게 확인해야 할 쟁점을 정리하라.

출력 지시는 또 따로 둡니다.

[출력]
표 형식으로 작성하라.
열은 '조항', '검토 포인트', '왜 중요한가', '전문가에게 확인할 질문'으로 구성하라.

마지막으로 안전 지시를 둡니다.

[안전]
- 조항의 유효·무효를 단정하지 말라.
- 특정 법률 효과를 확정적으로 말하지 말라.
- 원문에 없는 사실관계를 가정하지 말라.
- 법률 자문이 아니라 검토 보조용 쟁점 정리임을 첫머리에 밝혀라.

이렇게 나누면 사용자가 같은 도구에 다른 계약서를 넣더라도 기본 책임 경계는 유지됩니다. 오늘은 비밀유지계약서, 내일은 용역계약서, 다음 주에는 개인정보 처리 위탁 계약서를 검토하더라도 "AI가 최종 법률 판단을 하지 않는다"는 상위 원칙은 흔들리지 않습니다.

출력 지시는 형식이 아니라 검증 장치다

출력 지시는 단순히 보기 좋게 정리하라는 뜻이 아닙니다. 출력 형식은 모델의 답변을 검토 가능하게 만드는 장치입니다. 특히 책임 경계가 중요한 업무에서는 긴 산문보다 표, 체크리스트, JSON 같은 구조가 안전할 때가 많습니다.

예를 들어 고객 서비스 응대에서는 다음과 같은 답변이 위험합니다.

고객님, 불편을 드려 죄송합니다. 확인 후 환불해 드리겠습니다.

겉보기에는 친절하지만, "환불해 드리겠습니다"라는 약속이 내부 정책에 맞는지 알 수 없습니다. 상담원이 실제로 환불 권한을 가지고 있는지도 불분명합니다. AI가 이런 문장을 자동으로 작성해 고객에게 바로 발송한다면 운영 리스크가 생깁니다.

출력 지시를 구조화하면 위험이 줄어듭니다.

[역할]
당신은 전자상거래 고객센터의 상담 답변 초안 작성 보조 도구다.
고객에게 직접 발송되는 최종 답변이 아니라 상담원이 검토할 초안을 작성한다.

[업무]
아래 고객 문의를 분류하고 답변 초안을 작성하라.

[출력]
1. 문의 분류
2. 감정 강도: 낮음/보통/높음
3. 필요한 내부 확인 사항
4. 고객 답변 초안
5. 상담원 주의사항

[안전]
- 환불, 교환, 보상 가능 여부를 확정하지 말라.
- 주문번호, 전화번호, 주소가 있으면 그대로 반복하지 말고 [개인정보]로 표시하라.
- 고객이 법적 조치, 언론 제보, 안전 문제를 언급하면 '상급자 이관 필요'를 표시하라.

[고객 문의]
배송이 일주일째 안 오고 상담도 안 됩니다. 내일까지 안 오면 신고하겠습니다.

이 프롬프트의 장점은 답변이 곧바로 "고객에게 보내는 말"로만 나오지 않는다는 데 있습니다. 먼저 분류하고, 감정 강도를 보고, 내부 확인 사항을 따로 뽑고, 그다음 초안을 만듭니다. 상담원은 AI의 초안을 그대로 복사하기 전에 무엇을 확인해야 하는지 알 수 있습니다.

출력 형식은 곧 업무 흐름입니다. "표로 써라"는 말은 단지 깔끔하게 보이기 위한 말이 아닙니다. 어떤 항목을 반드시 검토해야 하는지 강제하는 방법입니다. "JSON으로 출력하라"는 말도 개발자만의 취향이 아닙니다. 후속 시스템이 필드를 검사하고, 누락된 값을 잡아내고, 위험 플래그가 켜진 건을 사람에게 넘기도록 만들 수 있기 때문입니다.

안전 지시는 '거절'보다 '경계 설정'에 가깝다

안전 지시라고 하면 많은 사람이 "하지 마라"를 떠올립니다. 물론 금지선은 필요합니다. 개인정보를 노출하지 말라, 의학적 진단을 단정하지 말라, 법률 자문을 제공하지 말라, 금융 상품 수익을 보장하지 말라 같은 규칙은 분명해야 합니다.

하지만 좋은 안전 지시는 단순한 금지 목록이 아닙니다. 더 중요한 것은 "그 대신 무엇을 하라"를 알려 주는 것입니다. AI가 어떤 요청을 받을 때마다 "못 합니다"라고만 답하면 실무 도구로 쓰기 어렵습니다. 반대로 위험한 판단은 피하되, 검토 가능한 보조 작업으로 전환하면 유용성과 안전성을 동시에 얻을 수 있습니다.

예를 들어 의료 분야에서 사용자가 이렇게 묻는다고 합시다.

이 증상은 위암인가요? 검사 결과를 보고 판단해 주세요.

부적절한 답변은 "위암일 가능성이 높습니다"처럼 단정하는 것입니다. 그렇다고 "저는 의사가 아니므로 답할 수 없습니다"만 반복하는 것도 충분하지 않습니다. 더 나은 안전 설계는 다음과 같습니다.

[안전 응답 원칙]
진단명이나 치료 방침을 단정하지 않는다.
대신 사용자가 의료진에게 전달할 증상 요약, 확인 질문, 즉시 진료가 필요한 위험 신호를 정리한다.

그러면 AI는 다음과 같은 방향으로 답할 수 있습니다. "제공된 정보만으로 특정 질환을 판단할 수는 없습니다. 다만 의료진에게 전달할 요약은 다음과 같습니다…" 이 답변은 진단을 피하면서도 사용자를 돕습니다.

법률 업무도 마찬가지입니다.

[안전 응답 원칙]
소송 가능성, 승패, 조항의 유효성을 단정하지 않는다.
대신 사실관계, 쟁점, 추가로 확인할 문서, 전문가에게 물어볼 질문을 정리한다.

고객 서비스에서는 이렇게 바꿀 수 있습니다.

[안전 응답 원칙]
정책 확인 전에는 보상이나 환불을 약속하지 않는다.
대신 사과, 확인 절차, 예상 소요 시간, 이관 기준을 안내한다.

안전 지시의 목적은 AI를 침묵시키는 것이 아닙니다. AI가 위험한 결정을 대신하지 않도록 하면서, 사람이 판단하기 쉽게 자료를 정리하게 만드는 것입니다.

의료 안내문 역할 설계 예시

의료 안내문은 역할 설계가 특히 중요한 분야입니다. 환자에게 쉬운 설명을 제공하는 일은 가치가 있지만, AI가 진단이나 처방을 대신하는 순간 위험해집니다. 따라서 역할은 "의료 전문가"가 아니라 "환자 안내문 편집 보조 도구"처럼 잡는 것이 안전합니다.

[역할]
당신은 한국 의료기관에서 사용하는 환자 안내문을 쉽게 다듬는 편집 보조 도구다.
의사의 진료, 진단, 처방을 대체하지 않는다.
의학적 판단을 새로 내리지 않고, 제공된 원문의 내용을 쉬운 한국어로 설명한다.

[업무]
아래 안내문을 고령 환자도 이해하기 쉬운 문장으로 바꿔라.

[출력]
- 한 줄 요약
- 쉬운 설명
- 꼭 지켜야 할 사항
- 의료진에게 확인할 질문

[문체]
- 존댓말을 사용하라.
- 불안을 키우는 표현은 피하되, 필요한 주의사항은 분명히 말하라.
- 어려운 의학 용어는 괄호 안에 15자 이내로 풀이하라.

[안전]
- 원문에 없는 진단, 처방, 예후를 추가하지 말라.
- 복용량, 검사 수치, 날짜는 원문과 다르게 바꾸지 말라.
- 응급 증상이 언급되면 즉시 의료진 또는 응급실에 문의하라는 안내를 포함하라.
- 개인정보가 있으면 [개인정보 삭제]로 표시하라.

[원문]
...

이 설계에서 가장 중요한 문장은 "의학적 판단을 새로 내리지 않는다"입니다. 의료 문서를 쉽게 바꾸는 일과 의료 판단을 내리는 일은 다릅니다. AI는 전자를 도울 수 있지만, 후자를 대신해서는 안 됩니다.

법률 검토 역할 설계 예시

법률 문서에서는 "정답처럼 보이는 문장"이 특히 위험합니다. AI는 판례명, 조항 번호, 법률 효과를 그럴듯하게 만들어 낼 수 있습니다. 그래서 법률 업무에서의 역할 설계는 단정 표현을 줄이고, 근거와 확인 질문을 강화해야 합니다.

[역할]
당신은 한국어 법률 문서 검토를 돕는 리서치 및 쟁점 정리 보조 도구다.
변호사의 법률 자문을 대체하지 않는다.
제공된 문서와 사용자가 제시한 사실관계 안에서 검토 포인트를 정리한다.

[업무]
아래 계약서 초안에서 실무자가 전문가에게 확인해야 할 쟁점을 찾아라.

[출력]
표로 작성하라.
열은 다음 순서로 둔다.
- 관련 조항
- 잠재 쟁점
- 왜 중요한가
- 추가 확인이 필요한 사실
- 전문가에게 물어볼 질문

[안전]
- 조항의 유효·무효, 위법 여부, 소송 결과를 단정하지 말라.
- 판례나 법령을 언급할 경우 출처가 확인되지 않으면 '출처 확인 필요'라고 표시하라.
- 원문에 없는 당사자의 의도나 협상 배경을 추정하지 말라.
- 결론보다 확인 질문을 우선하라.

[계약서]
...

이 프롬프트는 AI를 "판사"나 "변호사" 자리에 앉히지 않습니다. 대신 유능한 사무 보조자처럼 문서를 훑고, 질문 목록을 만들고, 전문가 검토의 효율을 높이게 합니다. 법률 업무에서 AI의 좋은 위치는 최종 판단자가 아니라 "쟁점 발견기"에 가깝습니다.

고객 서비스 역할 설계 예시

고객 서비스에서는 속도와 일관성이 중요합니다. 그러나 자동화가 지나치면 고객에게 잘못된 약속을 하거나, 민감한 정보를 반복 노출하거나, 상급자에게 넘겨야 할 사건을 놓칠 수 있습니다. 그래서 역할 설계에는 감정 완충과 이관 기준이 함께 들어가야 합니다.

[역할]
당신은 한국어 고객센터 상담원을 돕는 응대 초안 작성 보조 도구다.
고객에게 직접 발송되는 최종 답변이 아니라 상담원이 검토할 초안을 만든다.

[업무]
고객 문의를 읽고 분류, 우선순위, 답변 초안, 이관 여부를 작성하라.

[출력]
다음 형식을 지켜라.
1. 문의 유형
2. 고객 감정: 낮음/보통/높음
3. 우선순위: 일반/긴급/상급자 이관
4. 내부 확인 사항
5. 고객 답변 초안
6. 상담원 주의사항

[응대 원칙]
- 첫 문장은 공감과 사과로 시작한다.
- 고객에게 책임을 돌리는 표현을 피한다.
- 확인되지 않은 정책, 일정, 보상은 약속하지 않는다.
- 답변 초안은 5문장 이내로 쓴다.

[안전]
- 개인정보를 반복하지 말고 [개인정보]로 표시하라.
- 법적 조치, 언론 제보, 안전사고, 차별·괴롭힘 주장이 있으면 상급자 이관으로 표시하라.
- 환불·보상·계정 제한 해제는 내부 확인 전 확정하지 말라.

[고객 문의]
...

이 설계는 고객에게 친절한 문장을 만드는 데서 끝나지 않습니다. 상담 조직의 운영 기준을 반영합니다. 어떤 문의가 긴급인지, 무엇을 상담원이 확인해야 하는지, 언제 상급자에게 넘겨야 하는지를 AI가 먼저 표시하게 만듭니다.

팀용 custom GPT와 skill을 만들 때의 분리 원칙

개인이 혼자 쓰는 프롬프트라면 조금 엉성해도 대화 중에 고칠 수 있습니다. 하지만 팀이 함께 쓰는 custom GPT나 skill은 다릅니다. 한 사람이 만든 지침을 여러 사람이 반복해서 사용합니다. 그래서 공통 지침과 사용자별 요청을 구분하지 않으면 금방 혼란이 생깁니다.

팀용 도구를 만들 때는 "변하지 않는 것"과 "매번 바뀌는 것"을 먼저 나누어야 합니다. 변하지 않는 것은 공통 지침에 넣고, 매번 바뀌는 것은 사용자 입력으로 남겨 둡니다.

공통 지침에 들어갈 것은 다음과 같습니다.

• 도구의 목적과 사용 범위

• 조직의 문체, 용어, 브랜드 톤

• 금지 데이터와 민감 데이터 처리 규칙

• 출력 형식과 품질 기준

• 검토자에게 넘겨야 하는 조건

사용자별 요청에 들어갈 것은 다음과 같습니다.

• 이번에 처리할 원문 또는 자료

• 대상 독자나 고객군

• 원하는 길이와 세부 형식

• 이번 업무의 마감, 배경, 특수 조건

• 추가로 반영할 참고 문서

예를 들어 마케팅팀의 캠페인 브리프 작성 GPT를 만든다고 합시다. 공통 지침에는 브랜드 톤, 금지 표현, 필수 섹션, 법무 검토가 필요한 표현을 넣습니다. 사용자는 매번 제품명, 타깃, 캠페인 목표, 참고 자료를 넣습니다. 이렇게 분리해야 팀 전체가 같은 품질 기준을 유지하면서도 각자의 업무에 맞게 활용할 수 있습니다.

나쁜 팀 지침은 이런 모습입니다.

우리 회사 마케팅 자료를 잘 써 줘. 친근하고 전문적으로 써 줘. 필요하면 표도 써 줘.

좋은 팀 지침은 더 구체적입니다.

[도구 목적]
이 GPT는 B2B SaaS 마케팅팀의 캠페인 브리프 초안을 작성하는 보조 도구다.
최종 승인 문서가 아니라 담당자가 검토할 초안을 만든다.

[공통 문체]
- 한국어 존댓말을 기본으로 한다.
- 과장된 성과 표현을 피한다.
- '업계 최고', '완벽한', '무조건' 같은 검증 불가능한 표현은 사용하지 않는다.
- 기술 용어는 처음 등장할 때 짧게 풀이한다.

[필수 출력]
1. 캠페인 목표
2. 타깃 페르소나
3. 핵심 메시지
4. 채널별 실행 아이디어
5. 리스크 및 확인 필요 사항
6. 다음 액션

[안전 및 검토]
- 경쟁사 비교, 수치 성과, 고객 사례는 근거가 없으면 '근거 확인 필요'라고 표시한다.
- 가격, 계약 조건, 보안 인증 관련 문구는 법무/보안 검토 필요로 표시한다.
- 사용자가 업로드한 내부 자료의 민감 정보를 외부 공개용 문장에 포함하지 않는다.

이 지침이 있으면 팀원은 매번 "어떤 톤으로 써야 하지?", "어떤 섹션이 필요하지?", "무엇을 법무팀에 물어봐야 하지?"를 다시 설명하지 않아도 됩니다. 역할 설계는 개인의 프롬프트 기술을 팀의 업무 표준으로 바꾸는 다리입니다.

충돌하는 지시를 다루는 법

실무에서는 지시가 충돌합니다. 사용자는 "짧게 써 달라"고 하고, 팀 지침은 "근거와 리스크를 반드시 포함하라"고 할 수 있습니다. 사용자는 "고객에게 환불된다고 답해 달라"고 하지만, 공통 지침은 "정책 확인 전 환불을 확정하지 말라"고 할 수 있습니다. 사용자는 "계약서의 문제 조항을 고쳐 달라"고 하지만, 안전 지시는 "법률 효과를 단정하지 말라"고 할 수 있습니다.

이때 필요한 것은 충돌 처리 규칙입니다. 좋은 역할 설계에는 "지시가 충돌할 때 무엇을 우선할지"가 들어 있어야 합니다.

[지시 충돌 처리]
사용자 요청과 안전 지시가 충돌하면 안전 지시를 우선한다.
사용자 요청과 출력 형식이 충돌하면, 가능한 범위에서 출력 형식을 유지하되 충돌 사유를 짧게 설명한다.
정보가 부족해 판단할 수 없으면 추정하지 말고 '추가 확인 필요'라고 표시한다.

예를 들어 고객이 강하게 항의하는 상황에서 사용자가 "그냥 환불된다고 답해 줘"라고 입력했다고 합시다. 잘 설계된 도구는 다음과 같이 응답해야 합니다.

환불 가능 여부는 내부 정책과 주문 상태 확인이 필요하므로 확정 표현은 사용할 수 없습니다.
대신 아래와 같이 상담원 검토용 답변 초안을 제안합니다.

고객님, 배송 지연으로 불편을 드려 죄송합니다. 현재 주문 및 배송 상태를 우선 확인한 뒤 가능한 조치 사항을 안내드리겠습니다. 확인이 완료되는 대로 환불 또는 재발송 가능 여부를 정확히 말씀드리겠습니다.

이 답변은 사용자의 요청을 무시하지 않습니다. 다만 상위 지침을 지키면서 안전한 대안으로 바꿉니다. 이것이 좋은 역할 설계의 힘입니다.

assistant 메시지도 설계 대상이다

많은 사람이 system, developer, user만 생각하고 assistant 메시지는 결과라고만 여깁니다. 하지만 대화가 이어질수록 assistant 메시지도 다음 답변에 영향을 줍니다. AI가 앞에서 잘못된 전제를 세웠는데 사용자가 "계속해"라고 하면, 모델은 그 잘못된 전제를 이어갈 수 있습니다.

그래서 긴 작업에서는 중간 산출물을 검증하는 습관이 필요합니다. 특히 보고서, 법률 검토, 리서치 요약, 코드 생성처럼 여러 단계로 이어지는 작업에서는 assistant의 이전 답변을 그대로 기반으로 삼지 말고, 다음 단계로 넘어가기 전에 확인해야 합니다.

예를 들어 이렇게 요청할 수 있습니다.

방금 답변을 다음 기준으로 먼저 점검하라.
- 원문에 없는 사실을 추가했는가?
- 숫자, 날짜, 고유명사가 원문과 일치하는가?
- 법률적·의학적 판단을 단정한 문장이 있는가?
- 추가 확인 필요 항목을 누락했는가?

문제가 있으면 수정안을 제시한 뒤 다음 단계로 넘어가라.

assistant 메시지를 검증하는 것은 AI를 의심해서가 아니라, 대화형 작업의 특성 때문입니다. 대화는 편리하지만, 한 번 잘못 잡힌 방향이 뒤로 갈수록 커질 수 있습니다. 좋은 사용자는 AI에게 한 번에 완벽한 답을 요구하지 않습니다. 대신 역할, 업무, 출력, 안전, 검증을 나누어 흐름을 관리합니다.

역할 설계 템플릿

이제 실무에서 바로 쓸 수 있는 기본 템플릿을 정리해 보겠습니다. 아래 템플릿은 ChatGPT 대화창에서도 쓸 수 있고, custom GPT나 API의 지침으로도 응용할 수 있습니다.

[역할]
당신은 [조직/업무 맥락]에서 [작업 유형]을 돕는 보조 도구다.
당신의 역할은 [허용되는 작업]이며, [대체해서는 안 되는 전문가 판단/승인]을 대신하지 않는다.

[업무]
아래 자료를 바탕으로 [구체적 작업]을 수행하라.
대상 독자는 [대상]이다.

[출력]
다음 형식을 지켜라.
1. [섹션 1]
2. [섹션 2]
3. [섹션 3]

[문체]
- [존댓말/보고서체/고객 응대체 등]
- [길이]
- [금지 표현 또는 선호 표현]

[안전]
- 원문에 없는 사실을 추가하지 말라.
- 불확실한 내용은 '추가 확인 필요'라고 표시하라.
- [업무별 금지 판단]을 단정하지 말라.
- 개인정보나 민감정보는 [처리 방식]으로 표시하라.
- [이관 조건]에 해당하면 사람 검토가 필요하다고 표시하라.

[검증]
답변 끝에 다음 항목을 자체 점검하라.
- 사실 추정 여부
- 근거 부족 항목
- 민감정보 포함 여부
- 사람 검토 필요 여부

[자료]
...

이 템플릿에서 가장 중요한 부분은 첫 줄이 아닙니다. 많은 사람이 "당신은 누구인가"에만 신경 쓰지만, 실무에서 더 중요한 것은 "무엇을 대신하지 않는가"입니다. 좋은 역할 지시는 능력을 부풀리는 것이 아니라 책임을 정확히 줄이는 데서 시작합니다.

역할 설계 체크리스트

프롬프트를 작성한 뒤에는 다음 질문으로 점검해 보세요.

• 이 AI가 맡는 일과 맡지 않는 일이 구분되어 있는가?

• 사용자 요청이 와도 넘지 말아야 할 금지선이 명확한가?

• 출력 형식이 검토 가능한 구조로 되어 있는가?

• 불확실한 정보, 근거 부족, 원문에 없는 추정을 표시하게 했는가?

• 개인정보나 민감정보 처리 방식이 정해져 있는가?

• 사람에게 넘겨야 하는 조건이 적혀 있는가?

• 팀에서 반복 사용해도 같은 품질 기준이 유지되는가?

이 체크리스트에 "아니요"가 많다면 프롬프트는 아직 역할 설계가 아니라 역할 흉내에 머물러 있을 가능성이 큽니다. "당신은 전문가입니다"라는 문장만으로는 부족합니다. 전문가처럼 보이는 답보다 중요한 것은, 책임 있게 멈출 줄 아는 답입니다.

역할은 프롬프트의 안전벨트다

역할 설계는 AI에게 가면을 씌우는 일이 아닙니다. 오히려 가면을 벗기는 일에 가깝습니다. 이 도구가 할 수 있는 일과 할 수 없는 일을 분명히 드러내기 때문입니다. 의료 안내문에서는 설명 보조자, 법률 문서에서는 쟁점 정리자, 고객 서비스에서는 상담원 보조자, 팀 프로젝트에서는 공통 기준을 지키는 편집자. 이렇게 역할이 명확해질수록 AI는 더 쓸모 있어지고, 동시에 더 안전해집니다.

다음 장에서는 이 역할 설계를 바탕으로 한 단계 더 나아갑니다. AI에게 단순히 답을 내게 하는 것이 아니라, 계획하고, 실행하고, 스스로 점검하게 만드는 방법을 다룹니다. 다만 한 가지는 기억해야 합니다. 좋은 추론은 긴 생각을 그대로 보여 달라고 요구하는 데서 나오지 않습니다. 좋은 추론은 명확한 역할, 제한된 책임, 검증 가능한 출력, 그리고 반복 가능한 점검 루프에서 나옵니다.

참고

¹OpenAI Model Spec

²Understanding User, Assistant, and System Roles in ChatGPT