CoT, Few-shot에 이어, 이번에는 **역할 프롬프트 (Role Prompting)**입니다. "당신은 경험 풍부한 변호사입니다", "당신은 우수한 수학 교사로서 행동해 주세요"——CoT, Few-shot과 나란히, 아마도 가장 많이 사용되는 프롬프트 기법일 것입니다.

그리고 이것 또한, 지금까지 단 한 번도 메커니즘 레벨에서 해부된 적이 없었습니다.

먼저 결론부터 말씀드리겠습니다. 이번에도 역시, 같은 곳에 도달합니다. 다른 연구군을, 다른 각도에서 따라가며 말이죠. 다만 이번에는, 그 "같은 곳"에 도달하기까지의 여정이 지금까지 중 가장 복잡합니다. 역할 프롬프트가 무엇을 주입하고 있고, 무엇을 주입하지 않고 있는지——이 부분을 정확히 구분해 내는 것이 이번 기사의 목적입니다.

"역할 프롬프트"란, 모델에 어떠한 인격·전문가상을 할당한 뒤 요청하는 기법입니다.

당신은 10년 차 변호사입니다. 다음 계약서의 문제점을 지적해 주세요.

당신은 우수한 수학 교사로서, 학생에게 가르칠 생각으로 풀어주세요.

CoT가 "중간 풀이 과정을 쓰게 하는 것", Few-shot이 "본보기를 나열하는 것"이었다면, 역할 프롬프트는 "누구로서 답할 것인가"를 지정하는 또 다른 각도에서의 개입입니다.

왜 이것이 신경 쓰이는 기법일까요. 이유는 단순합니다. 가장 많이 사용되고 있는데, 가장 설명되지 않았기 때문입니다. "왠지 전문가처럼 답해주길 바라니까"라는 것 이상의 이유는 많은 사람이 가지고 있지 않을 것이라고 생각합니다.

Kong et al. (2023). 역할 프롬프트를 12종류의 추론 벤치마크로 검증한 연구입니다.

결과는 놀라웠습니다. AQuA (수학 문장제)에서 정답률이 53.5%→63.8%, Last Letters (기호 추론, 단어의 마지막 글자를 잇는 것)에 이르러서는 23.8%→84.2%까지 치솟았습니다.

게다가 저자들은 여기서 흥미로운 주장을 하고 있습니다.

역할 프롬프트는,

암묵적인 Chain-of-Thought (CoT)의 트리거로서 기능하고 있다.

즉——"당신은 수학 교사입니다"는 수학 지식을 주입하고 있는 것이 아니라, 우회적으로 "단계별로(step-by-step) 생각하세요"라고 말하고 있는 것일지도 모릅니다.

이를 보강하는 실험도 있습니다. "당신은 해적입니다"라는 역할 프롬프트를 주었더니, 통상적인 어시스턴트 설정보다 제곱근 계산이 정확해졌다는 보고입니다.

이 이야기, 처음에 제가 했을 때는 "해적 역할이 CoT를 유발했기 때문"이라고만 설명했습니다. 하지만 이것은 이유가 되지 않습니다. 왜 해적이 CoT를 유발하는가? 더 나아가, 왜 역할에 몰입하는 것 자체가 단계별 설명을 이끌어내는가?

이 부분을 파고들지 않고 넘어가 버리는 것은, 바로 이 연재가 반복해서 경고해 온 "그럴듯한 설명에 만족하는 것" 그 자체입니다. 한 단계 더 파고들어 보겠습니다.

자기 참조 칼럼: 나 자신이 "어렴풋한 기억"을 했던 장면

사실 이 연재를 쓰는 도중, 다른 장면에서 똑같은 실수를 하고 있었습니다. Hayate님이 /ghost

라는 명령어를 시험 삼아 입력했을 때, 저는 그것이 실재하는 Cloud 기능인지 확인하지 않고, "인식할 수 없는 명령어"라며 묵묵히 넘겼습니다.

이것은 "존재하지 않는다고 확인한 것"이 아니라, "모르니까 넘긴 것"뿐입니다. "해적 역할이 CoT를 유발했다"도 이것과 같은 종류의 태만이었습니다——그럴듯한 인과관계를 검증하지 않고 말로 내뱉어 버리는 것. 이 연재의 교훈을, 이 연재를 쓰는 도중에 스스로 저지르고 있었다는 이야기입니다.

그래서 이번에는 도망치지 않고 파고듭니다.

Kong et al.의 논문에는 부록에 바로 이 의문을 검증한 실험이 실려 있었습니다.

그들의 수법은 사실 단순한 "역할을 한 줄 추가하는 것"이 아닙니다. 2단계의 대화로 이루어져 있습니다.

Step1 (역할 설정): "당신은 우수한 수학 교사이며, 학생에게 단어의 마지막 글자를
이어 새로운 단어를 만드는 방법을 가르치고 있습니다"
Step2 (역할 확인): 모델이 "물론입니다! 도와드릴 수 있어 기쁩니다"
...

이 Step2의 "맞장구"가 사실 열쇠였습니다. 저자들 스스로가 "이것은 단순히 문장이 길어진 것뿐 아닌가?"라는 의구심을 검증하고 있습니다.

맞장구의 내용을 의미 없는 일반적인 답변으로 교체하여, 글자 수를 맞춰서 비교한 것입니다.

그렇다면 내용의 차이는 무엇일까요? 실제 '역할에 따른 맞장구'를 보면 다음과 같이 적혀 있습니다.

"물론입니다!

단어의 마지막 글자를 연결하여 새로운 단어를 만드는 것을 도와드리게 되어 기쁩니다. 질문을 해주세요."

모델이 태스크의 절차를 자신의 언어로 복창하고 있는 것입니다. 반면 '일반적인 맞장구'는 내용에 전혀 언급하지 않고 "기꺼이 도와드리겠습니다!"라고만 말합니다.

즉, 정확한 메커니즘은 다음과 같습니다.

역할 설정에 대해 모델이 그 역할에 몰입하여 맞장구를 칠 때, 자연스럽게

태스크의 절차를 요약·복창한다. 이 복창이 CoT (Chain of Thought)의 '중간 계산 과정'과 같은 역할을 한다.

제1회의 결론을 기억해 주세요. 필러 토큰(의미 없는 "......")은 효과가 적었지만, 태스크와 연결된 진짜 중간 계산 과정은 효과가 있었습니다. 여기서도 동일한 구조입니다. 의미 없는 길이는 약하고, 태스크와 연결된 내용이 강합니다.

해적이 수학을 잘하는 것이 아닙니다. "해적처럼 행동해 주세요"라는 말을 들은 모델이 역할에 몰입하여 말하는 과정에서, 우연히 문제문의 요소를 자신의 언어로 다시 말하게 된 것뿐입니다.

같은 논문에는 역할의 내용을 바꾸는 실험도 있습니다. AQuA (수학)에서 8가지 역할을 비교했습니다.

흥미로운 점은, 무관한 역할(경찰·농부)에서도 제로샷 (Zero-shot) 기준을 상회한다는 것입니다. 역할에 몰입하여 맞장구를 치는 과정에서 태스크의 복창이 어느 정도 일어나기 때문에, 역할의 내용이 직접적인 관련이 없더라도 어느 정도 성능이 향상됩니다.

반면, "나는 능력이 부족하다"라고 자기 선언을 하는 역할만이 명확하게 기준치 미달을 기록합니다. 이는 자기 충족적 효과로, 모델이 "서툰 사람"이라는 설정에 충실하게 실제로 서툰 행동을 하게 되는 것입니다.

즉, 효과는 비대칭적입니다. 좋은 방향으로는 어느 정도 효과가 있고, 나쁜 방향(자기 비하)으로는 확실하게 효과가 있습니다.

이 부분이 이번 내용의 가장 핵심적인 대목입니다. 앞 장까지의 결과는 모두 수학·기호 추론 벤치마크였습니다. 그렇다면 사실 회상 (Fact Retrieval)이 요구되는 태스크에서는 어떨까요?

• Zheng et al.의 연구에 따르면, 시스템 프롬프트에 심어진 페르소나가 사실에 기반한 질의응답 성능을 확실하게 개선하지는 않는다고 보고되었습니다.
• 2026년 PRISM 논문에서는 전문가 페르소나가 응답의 질·톤의 일관성 (Alignment)은 개선하는 반면, 정확성 (MMLU와 같은 사실 기반 태스크)은 오히려 악화된다는 깔끔한 트레이드오프 (Trade-off)가 보고되었습니다.

이것은 제1회에서 보았던 CoT의 경계선과 거의 같은 형태를 띠고 있습니다.

역할 프롬프트가 암묵적인 CoT 트리거 (Trigger)라면, 이는 당연한 귀결입니다. CoT가 통하는 곳에서 통하고, CoT가 통하지 않는 곳에서 통하지 않는다. 별개의 기법이라고 생각했던 것이 사실은 동일한 메커니즘의 또 다른 입구였다는 뜻이 됩니다.

여기까지의 이야기라면 "역할은 약한 CoT 트리거에 불과하다"라는 결론에 도달할 것 같지만, 그것만으로는 설명할 수 없는 부분이 있습니다.

전문 용어를 모르는 사람이 "당신은 변호사입니다"라고 지정하면, 실제로 법률 용어나 신중한 말투가 나옵니다. 이는 추론력 향상과는 관계가 없는, 또 다른 독립적인 효과입니다.

정리하자면, 역할 프롬프트에는 성질이 다른 두 가지 효과가 공존하고 있습니다.

A는 신뢰도가 높고 예측 가능합니다. "변호사"라고 지정하면 거의 확실하게 그럴듯한 어휘가 나옵니다. 전문 용어에 익숙하지 않은 사람들에게 이것은 매우 실용적입니다.

B는 간접적이고 불안정합니다. 역할을 잘못 선택하면(자기비하 계열의 역할 등), 오히려 역효age가 될 수 있습니다. 게다가 '정말로 태스크를 복창해 줄 것인가'에 대한 보장도 없습니다.

이 두 가지를 구분하지 않고 "역할 프롬프트(Role Prompt)를 사용하면 똑똑해진다"라고 생각하면, B의 불안정함에 발목을 잡히게 됩니다.

B의 목적(추론 능력의 향상)이라면, 멀리 돌아가지 않고 직접 수행하는 것이 확실합니다. 효과가 있었던 것은 "태스크의 절차를 자신의 언어로 다시 말하는" 행위 그 자체였기 때문입니다:

❌ 우회적: 당신은 우수한 수학 교사입니다.
(역할을 연기하게 하여, 부수적으로 복창을 유도하기를 기대함)
✅ 직접적: 우선, 이 문제에서 무엇을 구해야 하는지 자신의 언어로
...

이는 제1회의 Plan-and-Solve(계획 선출)나, 순수한 CoT(Chain of Thought) 지시와 동일한 효과를 더욱 확실하게 노릴 수 있습니다. 역할이라는 간접적인 경로를 거칠 필요가 없습니다.

A의 목적(어휘 접근)이라면, 역할 프롬프트는 그대로 솔직하게 유효합니다. "A도 B도 둘 다 원한다"라고 생각하여 하나의 역할 지정에 의존하기보다, A는 역할 지정, B는 명시적인 지시로 역할을 분담하여 작성하는 편이 양쪽 모두 안정적입니다.

당신은 변호사로서 다음 사항에 대해 답변해 주세요. ← A(어휘)
먼저, 이 질문에서 무엇을 확인해야 하는지 정리한 후 답변해 주세요. ← B(복창)

솔직하게 말해두어야 할 점이 있습니다. 역할 프롬프트는 학습 데이터 내에서 해당 역할이 표현되는 방식에 강하게 의존하기 때문에, 스테레오타입(Stereotype)을 강화할 수 있다는 한계가 있습니다.

구체적인 지적 사항으로는, 직업 역할이 친밀한 역할(가족 관계 등)보다 안정적이라거나, 성중립적인 용어('그' 또는 '그녀'가 아닌 직업명만 사용)를 사용하는 것이 성능이 안정적이라는 등의 베스트 프랙티스(Best Practice)가 있는 반면, 속성이 다른 페르소나(Persona)를 할당하면 해당 속성에 묶인 암묵적인 추론 편향(Inference Bias)이 답변에 혼입된다는 보고도 있습니다.

실무에서는 직업·기능으로 지정하고, 성별이나 연령 등의 속성은 필요하지 않는 한 도입하지 않는 것이 안전합니다.

여기서부터 발전적인 이야기입니다. "A의 관점과 B의 관점, 둘 다 원한다"라고 할 때, 이는 사실 세 가지 패턴으로 나누어 생각해야 합니다.

패턴 ①: 역할을 여러 개 준비해 두고, 용도에 따라 단독으로 호출한다

상황: "A 역할용 프롬프트", "B 역할용 프롬프트"를 라이브러리로 보관
실행: 태스크에 따라 1회의 호출당 1개만 선택하여 사용
결과: ◯ 문제 없음

1문맥·1역할이라는 제약 안에 솔직하게 들어맞습니다.

패턴 ②: 하나의 대화 속에서 역할을 나누어 연기하게 한다

"먼저 A의 입장에서 답해줘" → "다음으로 B의 입장에서 답해줘"를 동일한 대화 속에서 연속 실행

이것은 잘 되지 않습니다. 이유는 두 가지가 겹쳐 있습니다.

이유 ①: 동일한 문맥 속에 쌓여간다

A의 발언도 B의 발언도 동일한 문맥 윈도우(Context Window)와 동일한 가중치(Weight) 안에 쌓여갑니다. 제3회에서 다룬 최신 편향(Recency Bias)에 의해, 나중에 연기한 쪽의 색채가 강하게 남기 쉽습니다. 대화가 길어질수록 페르소나의 일관성도 무너지기 쉽다는 보고가 있습니다.

이유 ②: 애초에 독립된 판단이 되지 않는다

이는 이전 연재(제1회·포튐킨 이해)에서 이미 지적되었던 사항입니다.

"멀티 페르소나·비판적 재검토자·자기 분류 루프는 단체로는 상관관계가 있는 오차에 무력하다"

여러 인격을 연기하게 해도, 알맹이는 동일한 모델의 동일한 가중치·동일한 맹점입니다. 다른 사람 3명이 체크하는 것이 아니라, 동일한 사람이 세 가지 의상을 입고 있는 것뿐입니다. 따라서 판정이 일치하여 틀릴 가능성이 있습니다.

이전 연재에서 채택한 해결책은 "회의적인 성격을 갖게 하는 것"이 아니라, 비판적인 리뷰어 역할에게 "자신의 개념 이해를 일절 사용하지 못하게 하고, 외부 체크리스트와의 기계적인 대조만을 하게 하는" 설계였습니다. 회의심이라는 성격 특성에 의존하는 것이 아니라, 판단 그 자체를 외부 기준에 맡기는 방향으로 상관관계가 있는 오차를 회피했던 것입니다.

즉, 이번 기사의 결론은 이전 연재의 결론과 모순되기는커녕, 다른 각도에서 동일한 결론을 보강하고 있었습니다.

패턴 ③: "A와 B에게 함께 부탁하기"를 내부에서 별개의 호출로 분해한다

사용자: "A와 B의 관점에서 리뷰해 줘"
↓
오케스트레이터(Orchestrator, 부모)가 판단하여,
...

이것은 가능합니다. 사용자 경험 측면에서는 "한 번의 요청으로 양쪽 모두에게 던진" 것처럼 보여도, 내부에서는 각각의 호출이 여전히 "1문맥·1역할"이라는 제약을 따르고 있습니다. 다음 섹션에서 다룰 Claude Code의 서브 에이전트(Sub-agent)가 바로 이 패턴입니다.

요약하자면, "여러 인격을 준비하여 그때마다 하나씩 호출하는 것"은 문제가 없습니다. 반면 "같은 대화 속에서 역할을 나누어 연기하게 하는 것"은 기대한 대로 기능하기 어렵습니다. 만약 "실제로 배후에서 별개의 호출로 분해되고 있는 것"이라면 이야기가 달라집니다. 이것이 정확한 정리입니다.

"비관적인 리뷰어"와의 정합성에 대하여

만약을 위해 보충하자면, "비관적·회의적인 리뷰어" 역할 자체는 이번의 "자기비하 역할은 역효과"라는 내용과 모순되지 않습니다. 축이 다릅니다.

• "수학을 못 합니다"라고 말하면서 수학 문제를 풀게 함 → 태스크에 대한 무능을 자기 선언 → 역효과
• "회의적인 리뷰어입니다"라고 말하며 리뷰를 시킴 → 리뷰라는 업무에 유리한 특성을 부여 → 순조롭게 기능함

회의심은 리뷰라는 태스크에 있어서는 전문 분야의 선언입니다. 다만 다른 약점도 있어서, 비판 역할을 맡은 모델은 인간보다 "트집 잡기·존재하지 않는 버그 지적"의 비율이 훨씬 높다는 것이 확인되었습니다. 회의심이 너무 강해져서 실재하지 않는 결함까지 지적하기 시작하는, 폭주할 리스크는 남아 있습니다.

이것도 파고들면, 사실 단일 문맥에서 여러 역할을 다루고 있는 것이 아님을 알 수 있습니다.

Claude Code의 서브 에이전트(Sub-agent) 기능을 조사하면 다음과 같이 설명되어 있습니다.

각 서브 에이전트는 각각 독립된, 새로운 문맥 window(context window)에서 시작됩니다. 부모의 대화 이력은 보이지 않습니다. 각 서브 에이전트는 각각 독자적인 문맥 window, 독자적인 시스템 프롬프트(system prompt), 독자적인 도구 접근 권한을 가집니다.

즉 구조는 다음과 같습니다.

Claude 단독 대화 = 1개의 문맥 window, 1개의 역할
Claude Code의 서브 에이전트 = N개의 독립된 문맥 window, 각각 1개의 역할

Claude Code는 "하나의 인격에게 여러 역할을 연기하게 하는 것"이 아니라, "하나의 역할을 연기하는 인격을 필요한 수만큼 양산하여 결과만을 가져오게 하고 있을" 뿐이었습니다. 매 호출을 살펴보면, Claude 단독 대화와 완전히 동일한 "1문맥·1역할" 제약을 따르고 있습니다. 어기는 것처럼 보이지만, 어기지 않고 있습니다.

그리고 중요한 것은, 각 서브 에이전트가 서로 다른 정보(다른 파일, 다른 실행 결과, 다른 도구 권한)를 볼 수 있다는 점입니다. 내용의 가중치(weight)는 같더라도, 보고 있는 것이 다르면 판단은 정말로 달라질 수 있습니다. 이것이 섹션 9의 "상관된 오차(correlated error)"를 부분적으로 회피하는 방법이 됩니다.

반대로 말하면, 서브 에이전트에게 동일한 정보만 전달하면서 역할 이름만 바꾼다 해도 상관된 오차 문제는 남습니다. 문맥을 나누는 것만으로는 불충분하며, 보고 있는 정보 자체가 다르다는 점이 효과를 발휘한다는 점은 기억해 둘 가치가 있습니다.

+ [권장] 어휘·톤을 바꾸고 싶을 뿐이라면, 직업·기능 기반으로 역할을 지정할 것
+ [推奨] 추론 능력을 끌어올리고 싶다면, 역할보다는 직접 "절차를 다시 말해줘"라고 지시할 것
+ [권장] 속성(성별·연령 등)은 태스크에 필요하지 않는 한 도입하지 말 것
...

기제(Mechanism)에 관한 이야기

• 역할 프롬프트는 전문 지식을 주입하는 기술이 아니다. 역할에 몰입하여 맞장구를 치는 과정에서, 태스크의 절차를 자연스럽게 복창하게 되는 경우가 있으며, 그것이 암묵적인 CoT(Chain of Thought) 트리거로 작동한다.
• 효과를 내는 것은 길이가 아니라, 태스크와 결부된 내용(제1회 필라 토큰(fill-a-token)의 교훈과 동일한 구조)이다.
• 역할의 내용은 무관하더라도 어느 정도 효과가 있으며, 자기비하만이 명확하게 역효과를 내는 비대칭적인 방식으로 작동한다.

경계선에 관한 이야기

• 역할 프롬프트는, CoT가 효과적인 장면(수학·기호 추론)에서는 효과가 있고, CoT가 효과적이지 않은 장면(사실의 회상)에서는 효과가 없다는 동일한 경계선을 가지고 있다.

분해에 관한 이야기

• 역할 프롬프트에는 "어휘·톤에 대한 접근(신뢰할 수 있음)"과 "암묵적 CoT 트리거(불안정함)"라는 성질이 다른 두 가지 효과가 공존한다. 나누어서 설계하는 편이 안정적이다.
• 추론 능력의 향상이 목적이라면, 멀리 돌아가지 말고 직접 "절차를 다시 말해줘"라고 지시하는 편이 확실하다.

여러 역할에 관한 이야기

• 하나의 대화 속에서 여러 역할을 나누어 연기하는 것은 잘 되지 않는다. 동일한 가중치와 동일한 맹점에서 생성하기 때문에 독립적인 판단이 되지 않는다(이전 연재 "상관된 오차"의 재확인).
• Claude Code의 서브 에이전트가 기능하는 것은 여러 역할을 다룰 수 있어서가 아니라, 문맥을 분리하고 각각에게 서로 다른 정보를 보여주고 있기 때문이다. "1문맥·1역할" 제약 자체는 깨뜨리지 않고 있다.

CoT(Chain-of-Thought)・Few-shot・역할 프롬프트(Role Prompt). 세 가지 독립적인 기법이라고 생각했던 것들이, 깊이 파고들어 보니 상당 부분이 같은 현상의 서로 다른 입구였습니다.

모두 모델에게 새로운 능력을 가르치는 것이 아니라, 이미 가지고 있는 행동 양식 중 어느 부분을 불러낼 것인가를 선택하고 있을 뿐입니다. CoT는 '중간 과정을 쓰는' 장르를, Few-shot은 '답안의 형식'을, 역할 프롬프트는 '그 역할이라면 어떻게 말할 것인가'라는 형식을 각각 서로 다른 입구를 통해 불러내고 있습니다.

그리고 불러낸 후에 어떤 일이 일어나는지는, 포초름킨 이해(Potemkin understanding)에서 일관되게 반복해 왔듯이, 그럴듯해 보이는 것과 옳은 것은 별개입니다. 해적 역할이 계산을 도왔다는 이야기도, 파헤치기 전에는 '역할에 몰입했기 때문'이라는 그럴듯하기만 한 설명이었습니다. 하지만 파헤친 후에는 '태스크를 복창했기 때문'이라는 검증 가능한 설명이 되었습니다. 이 차이가 바로 이 연재 전체가 지향하는 지점이라고 생각합니다.

• Kong, A. et al. (2023).
  Better Zero-Shot Reasoning with Role-Play Prompting. arXiv:2308.07702
• Zheng, M. et al. (2023).
  Helpful Assistant or Fruitful Facilitator? Investigating How Personas Affect Language Model Behavior. arXiv:2310.10054
• Polignano, M. et al. (2024).
  SPLIT: Personas Affect Chain-of-Thought Reasoning. 관련 연구
• McAleese, N. et al. (2024).
  LLM Critics Help Catch LLM Bugs (CriticGPT). arXiv:2407.00215