LLM에게 "당신은 10년 경력의 보안 전문가입니다"처럼 역할을 줘서 그 관점과 말투로 답하게 하는 기법으로, 답의 톤·관점·집중할 부분을 정하고 싶을 때 가장 간단하게 쓴다. 다만 정답률이 오르는지는 작업마다 달라서 역할 하나로 모든 답이 좋아진다고 기대하면 안 된다.
| 목적 | 역할의 효과 |
|---|---|
| 말투·문체 맞추기 | 잘 맞는다 |
| 특정 관점으로 검토하기 | 잘 맞는다 (보안, 성능 등) |
| 사실 정확도 올리기 | 효과가 일정하지 않다 |
| 단순 분류·추출 | 차이가 거의 없다 |
역할 이름만 주면 결과가 들쭉날쭉하다. 누구인지, 무엇을 목표로 하는지, 무엇은 하지 말아야 하는지를 함께 적을수록 답이 일관된다.
| 구성 | 약한 예 | 강한 예 |
|---|---|---|
| 역할 | "개발자" | "보안을 최우선으로 보는 시니어 백엔드 개발자" |
| 목표 | 없음 | "배포 전에 취약점을 찾는다" |
| 제약 | 없음 | "SQL 인젝션·인증만 본다, 코드 스타일 지적은 뺀다" |
| 독자 | 없음 | "주니어도 이해하게 설명한다" |
채팅 앱에서는 대화 첫 메시지에 역할을 적거나, 맞춤 지침이나 프로젝트 지침 같은 설정에 넣어 두면 된다. API에서는 시스템 프롬프트에 역할을 넣으면 대화 전체에 똑같이 적용되므로, 질문할 때마다 역할을 다시 말할 필요가 없다.
프롬프트는 역할과 목표, 작업 내용과 자료, 원하는 출력 형식 순서로 쓰면 된다. 같은 코드를 "보안 담당"과 "성능 담당"에게 따로 검토시키면 서로 다른 관점의 피드백을 받을 수 있다.
역할을 줘도 모델이 모르는 지식이 새로 생기지는 않는다. "당신은 의사입니다"라고 해도 실제 의사의 판단을 대신할 수 없다. 오히려 자신 있는 말투 때문에 틀린 답이 더 그럴듯해 보일 수 있으니, 의료·법률·금융처럼 중요한 내용은 반드시 따로 확인한다.
역할과 지시가 서로 부딪치지 않게도 해야 한다. "친절한 상담원" 역할에 "짧고 단호하게"라는 지시를 섞으면 답이 흔들린다. 정확도가 가장 중요하다면 역할보다 구체적인 지시나 예시, 참고 자료를 주는 편이 효과가 크다.
가장 흔한 건 같은 자료를 다른 관점으로 다시 보게 하는 방식이다. 정답을 맞히는 일보다 말투와 시선을 정하는 일에 쓸 때 효과가 분명하다.
| 어디서 | 어떻게 쓰나 |
|---|---|
| 코드 리뷰 | 보안 담당·성능 담당 역할로 같은 코드를 따로 검토시켜 관점별 피드백을 모은다 |
| 글쓰기·편집 | 편집자 역할과 독자 수준을 정해 문체와 용어 난이도를 맞춘다 |
| 학습·연습 | 면접관이나 회화 상대 역할을 맡겨 질문을 받으며 연습한다 |
| 챗봇·사내 도구 | 시스템 프롬프트에 역할과 하지 말 것을 적어 대화 내내 같은 말투를 유지한다 |