핵심 재정리
예전 페르소나는 말투·캐릭터 역할 부여였지만, 발전한 페르소나는 관점·판단기준·증거기준·금지선을 정하는 사고 경로 설계입니다.
6과6-14
만류귀종 — 돌고 돌아 다시 페르소나
예전의 말투·캐릭터 페르소나를 넘어, 관점·판단기준·증거기준·금지선을 설계하는 고급 페르소나 활용법을 배웁니다. 멀티에이전트, Fable/Showrunner, GPT-5.6 Sol 사례까지 공식 확인과 적용 아이디어를 구분해 정리합니다
Practice Kit
수업 후 바로 남길 결과물
내 업무 연결
반복 업무 하나를 골라 AI에게 맡길 단위로 쪼갭니다.
작은 산출물
요약문, 체크리스트, 초안, 자동화 지시문 중 하나를 완성합니다.
AI에게 붙여넣을 복습 프롬프트
나는 비개발자 실무자입니다. "만류귀종 — 돌고 돌아 다시 페르소나" 강의를 들었습니다.
내 업무 상황:
- 반복해서 시간이 걸리는 업무:
- 지금 막히는 지점:
- 오늘 30분 안에 만들고 싶은 결과물:
요청:
1. 이 강의의 핵심을 내 업무 기준으로 3줄 요약해줘.
2. 바로 실행할 수 있는 첫 작업 3개를 순서대로 정리해줘.
3. 내가 AI에게 붙여넣을 최종 프롬프트를 하나 만들어줘.
4. 결과물을 검수할 체크리스트를 5개로 만들어줘.검수 기준
- 오늘 만들 결과물이 한 문장으로 정리됐는가
- AI에게 맡길 일과 사람이 판단할 일이 분리됐는가
- 민감정보를 제거하거나 가명 처리했는가
- 결과물을 복사해 실제 업무 파일에 붙일 수 있는가
페르소나는 다시 돌아왔습니다
초기 프롬프트엔지니어링에서 페르소나는 주로 '말투'와 '캐릭터'였습니다. '너는 친절한 선생님이야', '스티브 잡스처럼 말해줘', 'MZ세대 마케터처럼 써줘' 같은 방식입니다. 효과는 있었습니다. 답변 톤이 달라지고, 초안의 분위기가 좋아졌습니다.
그런데 2026년의 페르소나는 다른 층위로 올라왔습니다. 이제 페르소나는 캐릭터 분장이 아니라 사고 경로 설계입니다. 어떤 관점에서 보고, 어떤 증거를 인정하고, 어떤 판단기준으로 결론을 내리고, 어디까지는 하지 않을지 금지선을 정하는 장치입니다.
그래서 '만류귀종'입니다. 프롬프트, 컨텍스트, 하네스, 에이전트, 루프까지 돌고 돌아 다시 페르소나로 옵니다. 다만 예전의 페르소나가 겉모습이었다면, 발전한 페르소나는 판단 구조입니다.
TIP: 좋은 페르소나는 '누구처럼 말해'가 아니라 '무엇을 보고, 무엇을 의심하고, 어떤 기준으로 통과시킬지'를 정합니다.
예전 페르소나와 발전한 페르소나
[예전 페르소나]
- 역할: 인사팀장, 마케터, 변호사, 선생님
- 말투: 친절하게, 단호하게, 쉽게, 전문가답게
- 캐릭터: 유명인 스타일, 상담사 스타일, 코치 스타일
이 방식은 입문 단계에서 유용합니다. AI가 답변의 톤과 형식을 잡는 데 도움이 됩니다. 하지만 중요한 판단 업무에는 부족합니다. 말투가 전문가 같다고 판단이 전문가 수준이 되는 것은 아니기 때문입니다.
[발전한 페르소나]
- 관점: 사용자측, 근로자측, 감독기관, 증거검증자, 최종판단자
- 판단기준: 법적 리스크, 실무 가능성, 비용, 관계 훼손, 재발 방지
- 증거기준: 원자료 우선, 날짜·작성자·출처 확인, 추정과 확인 구분
- 금지선: 단정 금지, 미확인 판례 생성 금지, 외부 제출 전 사람 승인
발전한 페르소나는 답변의 '목소리'보다 답변이 만들어지는 '검토 절차'를 바꿉니다. AI에게 역할극을 시키는 것이 아니라, 여러 검토자 관점을 순서대로 통과하게 하는 것입니다.
멀티에이전트는 여러 페르소나의 분업입니다
멀티에이전트나 하위 전문 스레드를 어렵게 생각할 필요 없습니다. 본질은 여러 페르소나를 분업시키고, 서로 교차검증하게 하는 구조입니다.
예를 들어 노동사건 초안을 검토한다면 이렇게 돌릴 수 있습니다.
1. 사용자측 관점: 회사가 원하는 목표, 비용, 운영상 제약을 정리합니다.
2. 근로자측 관점: 상대방이 주장할 수 있는 쟁점과 감정선을 예상합니다.
3. 감독기관 관점: 노동청이나 노동위원회가 볼 핵심 사실과 법 위반 가능성을 점검합니다.
4. 증거검증자 관점: 문자, 녹취, 근태자료, 급여자료의 출처와 공백을 확인합니다.
5. 최종판단자 관점: 앞의 검토를 종합해 가능한 선택지와 리스크를 나눕니다.
한 AI에게 한 번에 모두 시킬 수도 있지만, 중요한 사안일수록 관점을 분리하는 편이 좋습니다. 각 관점이 서로 다른 질문을 던지기 때문입니다. 회사 관점은 실행 가능성을 보고, 근로자 관점은 반박 가능성을 보고, 증거검증자는 '그 말의 근거가 어디 있나'만 집요하게 봅니다.
[관점 순환 템플릿]
사안: [검토할 사건/문서]
목표: [최종적으로 결정해야 할 것]
1. 사용자측 관점으로 유리한 사실과 원하는 결론을 정리하세요.
2. 근로자측/상대방 관점으로 가능한 반박과 약점을 정리하세요.
3. 감독기관 관점으로 법 위반 의심 지점과 질문받을 부분을 정리하세요.
4. 증거검증자 관점으로 확인된 사실, 미확인 주장, 필요한 추가자료를 구분하세요.
5. 최종판단자 관점으로 선택지별 리스크와 권고안을 제시하세요.
규칙:
- 확인된 사실과 추정을 구분할 것
- 출처 없는 법률·판례·통계는 만들지 말 것
- 외부 제출 가능한 문안이 아니라 내부 검토 초안으로 작성할 것페르소나의 효용과 위험
페르소나의 효용은 분명합니다.
첫째, 빠뜨리는 질문이 줄어듭니다. 한 관점에서 보이지 않던 리스크가 다른 관점에서 드러납니다.
둘째, 산출물의 기준이 명확해집니다. '좋게 써줘'가 아니라 '증거가 확인된 것만 결론에 넣어라'가 됩니다.
셋째, 검토를 반복할 수 있습니다. 매번 다른 질문을 던지는 것이 아니라 같은 페르소나 루틴으로 문서 품질을 일정하게 유지합니다.
하지만 위험도 있습니다. 가장 큰 위험은 확증편향입니다. 사용자가 원하는 결론을 정해놓고 그 결론을 지지하는 페르소나만 돌리면, AI는 그럴듯한 자기합리화 기계가 됩니다. 그래서 레드팀이 필요합니다. 레드팀 페르소나는 일부러 반대편에 서서 '이 결론이 틀렸다면 어디서 틀렸을까', '상대방이 가장 세게 칠 지점은 어디인가'를 묻습니다.
TIP: 중요한 문서에는 반드시 '반대편 페르소나'와 '증거검증자 페르소나'를 넣으세요. 동의하는 AI보다 의심하는 AI가 더 가치 있을 때가 많습니다.
Fable/Showrunner 사례 — 캐릭터, 기억, 시뮬레이션 세계
먼저 이름을 구분해야 합니다. 여기서 말하는 Fable Studio는 Showrunner를 운영하는 별도 회사이며, Anthropic의 Claude Fable 5 모델과는 관계가 없습니다.
공식 확인(확인일 2026-07-11): Showrunner는 스스로를 'serialized AI storytelling'을 위한 새 매체로 설명하며, 사용자가 세계와 장르를 고르고 연속성 있는 쇼를 만들 수 있다고 소개합니다. Showrunner 사이트는 Sim Francisco를 시뮬레이션 안에 만든 도시로 설명하고, 수천 명의 AI 캐릭터가 그 안에 살며 사용자가 그들의 삶을 보거나 이야기 진행에 개입할 수 있다고 소개합니다.
Fable Studio의 Wizard Engine 페이지는 AI Character Engine과 SDK를 통해 감정 지능을 가진 가상 존재의 인터랙티브 스토리를 설계하고, 캐릭터가 관객과의 기억을 유지하며 emergent narrative를 만든다고 설명합니다.
적용 아이디어: 이 사례는 '페르소나'가 단순 말투가 아니라 기억, 관계, 세계 규칙, 즉흥 행동이 결합된 캐릭터 시스템으로 확장될 수 있음을 보여줍니다. 업무용 AI에서도 비슷하게 생각할 수 있습니다. 예컨대 '증거검증자'는 말투가 아니라 기억해야 할 검증 규칙과 세계관, 즉 어떤 자료를 믿고 어떤 자료를 의심할지의 운영 규칙을 가진 페르소나입니다.
한계: Showrunner 약관은 서비스와 산출물이 AS IS로 제공되고, 기능·알고리즘·아트 스타일·가격·접근 범위가 바뀔 수 있으며 특정 속성에 의존하지 말라고 고지합니다. 따라서 강의에서는 현재 공식 자료 범위 안에서만 사례로 사용하고, 실제 기능·품질·제공 조건은 변경 가능하다고 봐야 합니다.
GPT-5.6 Sol 사례 — 모델과 페르소나는 다른 층위입니다
공식 확인(확인일 2026-07-15): GPT-5.6에는 Sol(최상위), Terra(균형), Luna(빠른/저비용)가 있습니다. 일반 Chat 대화에서는 유료 대상 Sol만 선택되고, Terra와 Luna는 표준 Chat 선택지가 아닙니다. Work, Codex, API에서는 제공 조건이 다를 수 있습니다.
중요한 구분이 있습니다. GPT-5.6 Sol은 모델입니다. 페르소나 설계는 그 모델 위에서 어떤 관점과 판단기준으로 일하게 할지 정하는 운영 설계입니다. 좋은 모델은 더 많은 것을 처리할 수 있지만, 어떤 증거를 믿을지, 어떤 금지선을 지킬지, 어떤 관점을 먼저 검토할지는 사용자가 하네스와 프롬프트로 설계해야 합니다.
접근 범위도 고정값이 아닙니다. 플랜·워크스페이스 설정·제품별로 사용 가능한 옵션이 다를 수 있습니다. 따라서 '누구나 항상 GPT-5.6 Sol을 쓴다'가 아니라 '제품과 플랜에 따라 접근 범위가 다르고 변동 가능하다'고 이해해야 합니다.
실무 템플릿 — 판단형 페르소나 만들기
아래 템플릿은 말투용 페르소나가 아니라 판단형 페르소나를 만들 때 쓰는 형식입니다.
[판단형 페르소나 설계 템플릿]
이름: [예: 증거검증자]
역할: [이 페르소나가 맡는 검토 책임]
관점: [누구의 입장에서 무엇을 우선 보는가]
판단기준:
- [기준 1]
- [기준 2]
- [기준 3]
증거기준:
- 원자료와 재전달 내용을 구분한다
- 날짜, 작성자, 출처가 없는 주장은 미확인으로 표시한다
- 법령·판례·통계는 출처 확인 전 단정하지 않는다
금지선:
- 확인되지 않은 사실을 확정 표현하지 않는다
- 외부 제출·발송 문안으로 포장하지 않는다
- 사용자가 원하는 결론에 맞춰 근거를 끼워 맞추지 않는다
출력형식:
1. 확인된 사실
2. 미확인 주장
3. 핵심 리스크
4. 추가로 필요한 자료
5. 다음 검토자에게 넘길 질문점검문항 — 좋은 페르소나인지 확인하기
페르소나를 만들었다면 아래 질문으로 점검하세요.
- 이 페르소나는 말투가 아니라 판단기준을 갖고 있는가?
- 무엇을 증거로 인정할지 기준이 있는가?
- 하지 말아야 할 금지선이 명확한가?
- 반대편 관점이나 레드팀이 별도로 있는가?
- 최종 판단 전에 사람이 확인해야 할 지점이 남아 있는가?
- 모델 성능 설명과 페르소나 설계를 섞어 과장하고 있지 않은가?
이 질문에 답할 수 있으면 페르소나는 단순한 캐릭터가 아니라 업무 하네스의 일부가 됩니다.
핵심 정리
- ✓예전 페르소나는 말투·캐릭터 역할 부여였지만, 발전한 페르소나는 관점·판단기준·증거기준·금지선을 정하는 사고 경로 설계입니다.
- ✓멀티에이전트와 하위 전문 스레드는 여러 페르소나를 분업시키고 교차검증하는 구조로 이해하면 쉽습니다.
- ✓사용자측, 근로자측, 감독기관, 증거검증자, 최종판단자 관점을 순환하면 한쪽 결론에 갇히는 위험을 줄일 수 있습니다.
- ✓페르소나는 품질을 높이지만 확증편향도 키울 수 있으므로 반대편 관점과 레드팀 페르소나가 필요합니다.
- ✓Fable/Showrunner와 GPT-5.6 Sol 사례는 공식 확인 범위와 적용 아이디어를 구분해야 하며, 모델 성능과 페르소나 설계는 다른 층위입니다.
자주 묻는 질문
페르소나는 이제 낡은 프롬프트 기법 아닌가요?+
말투를 바꾸는 페르소나만 보면 낡아 보일 수 있습니다. 하지만 관점, 판단기준, 증거기준, 금지선을 설계하는 페르소나는 오히려 에이전트와 루프 설계의 핵심 부품입니다.
멀티에이전트를 꼭 기술적으로 구현해야 하나요?+
아닙니다. 한 대화 안에서도 관점을 순서대로 바꾸며 검토할 수 있습니다. 다만 중요한 업무나 반복 업무에서는 작성자, 반대편 검토자, 증거검증자를 별도 세션이나 하위 에이전트로 분리하면 품질이 더 안정됩니다.
Fable/Showrunner 사례를 업무 AI에 그대로 적용할 수 있나요?+
그대로 복제한다기보다 아이디어를 가져오는 것이 맞습니다. 공식 자료는 AI 캐릭터, 기억, 시뮬레이션 세계, emergent narrative를 설명하지만, 서비스 조건과 기능은 바뀔 수 있습니다. 업무에서는 '캐릭터가 기억과 규칙을 가진다'는 구조만 참고해 판단형 페르소나로 바꾸면 됩니다.
GPT-5.6 Sol을 쓰면 페르소나 설계가 필요 없나요?+
필요합니다. GPT-5.6 Sol은 고성능 모델이고, 페르소나 설계는 그 모델을 어떤 관점과 기준으로 움직일지 정하는 운영 설계입니다. 모델이 좋아질수록 오히려 기준과 금지선을 분명히 정해야 합니다.
더 깊이 배우기
학습 완료
현재까지 완료: 0개