역할 부여와 컨텍스트 설정

역할 부여(role prompting)는 모델에게 "너는 누구이며 어떤 관점에서 답하는가"를 지정해 어조, 전문성 수준, 행동 경계를 한꺼번에 정렬하는 기법이다. Anthropic은 시스템 프롬프트를 통한 역할 부여를 모델 행동을 조종하는 가장 효과적인 방법 중 하나로 든다. 시험은 이 도메인에서 두 가지를 묻는다. 첫째, 역할 정보를 어디에 두어야 하는가(시스템 프롬프트 대 사용자 메시지). 둘째, 역할 부여가 도움이 되는 상황과 오히려 해가 되는 상황의 구분이다.

시스템 프롬프트의 자리

Anthropic API의 messages 호출에서 역할·정체성·전역 규칙은 system 파라미터에 둔다. system은 대화 전반에 일관되게 적용되는 지속적 지시의 자리이고, messages 배열은 실제 주고받는 대화의 자리다. 시험에서 흔한 함정은 "역할 설명을 매 사용자 메시지마다 반복해서 붙인다"는 선택지다. 이는 토큰을 낭비하고 일관성을 떨어뜨린다. 전역적으로 유지되어야 할 정체성과 규칙은 system에 한 번만 두고, 변하는 작업 입력만 messages에 넣는 것이 정답이다.

# /examples/13/role_system.pyimport anthropicclient = anthropic.Anthropic()response = client.messages.create(    model="claude-opus-4-8",    max_tokens=1024,    system=(        "너는 항공우주 부품 공급사의 품질 보증 감사관이다. "        "모든 답변은 관련 규격 조항을 먼저 인용한 뒤 판정을 내리고, "        "근거가 불충분하면 단정하지 말고 추가 확인이 필요한 항목을 명시한다. "        "추측으로 합격 판정을 내리지 않는다."    ),    messages=[        {"role": "user", "content": "이 용접 검사 보고서로 부품을 출하해도 됩니까?"}    ],)print(response.content[0].text)

여기서 역할은 단순한 호칭이 아니라 행동 규약을 포함한다. "규격을 먼저 인용하고", "근거가 부족하면 단정하지 않는다"는 절차가 역할에 묶여 있어 답변의 신뢰성 기준까지 함께 설정된다. 역할 부여가 강력한 이유는 호칭 그 자체가 아니라, 그 호칭에 결부된 행동 규약을 명시할 수 있기 때문이다. 시험에서 "전문가 역할만 붙였는데 품질이 안 올라갔다"는 시나리오가 나오면, 역할 호칭에 더해 그 역할이 따라야 할 절차와 출력 기준을 명시하라는 선택지가 정답이다.

컨텍스트 배치와 순서

역할과 함께 제공되는 배경 정보(컨텍스트)의 배치도 출제 대상이다. 모델은 작업 지시와 처리 대상 자료를 구분할 수 있어야 하므로, 긴 참고 문서는 구분자로 감싸고 그 문서를 어떻게 다룰지에 대한 지시를 분명히 둔다. 긴 입력을 다룰 때는 자료를 앞쪽에, 그 자료에 대한 구체적 질문이나 지시를 뒤쪽에 두는 배치가 일반적으로 더 안정적이다. 또한 컨텍스트에는 "이 정보를 어떤 목적에 쓰는가"를 함께 적어 주어야 모델이 관련 부분만 선택적으로 활용한다. 목적 없이 자료만 던지면 모델이 무엇이 중요한지 판단하지 못해 엉뚱한 부분을 인용한다.

복잡한 추론이 필요한 작업에서는 모델이 단계적으로 사고하도록 유도할 수 있다. 최신 모델에서는 확장 사고를 adaptive 모드로 사용하며, 과거 모델에서 쓰던 budget_tokens, temperature, top_p 같은 수동 조정 파라미터는 사용하지 않는다. 시험에서 "추론 품질을 높이기 위해 thinking 예산을 수동으로 키운다"거나 "temperature를 조정한다"는 선택지가 보이면 이는 최신 모델 기준에서 제거된 방식이므로 함정이다. 역할과 컨텍스트를 명확히 설정하고 adaptive 사고에 맡기는 선택지가 정답에 가깝다.

역할 부여가 해가 되는 경우

역할 부여는 만능이 아니다. 사실 추출이나 분류처럼 정답이 자료에 고정되어 있는 작업에 과도한 페르소나를 입히면, 모델이 그 페르소나의 어조에 맞추느라 불필요한 수식이나 추정을 덧붙여 정확도를 떨어뜨릴 수 있다. 시험에서 "단순 데이터 추출 작업에 '창의적인 카피라이터' 역할을 부여했더니 출력에 군더더기가 생겼다"는 시나리오가 나오면, 역할을 작업 성격에 맞게 중립적·절차적으로 바꾸거나 제거하라는 선택지가 정답이다. 역할은 어조와 관점이 결과에 영향을 주는 작업에서 가치가 크고, 결정적 정답이 정해진 기계적 작업에서는 절제해야 한다.

정리

• 역할·정체성·전역 규칙은 system 파라미터에 한 번 두고, 변하는 작업 입력만 messages에 넣는다. 매 메시지마다 역할을 반복하는 것은 함정이다.
• 역할 부여의 힘은 호칭이 아니라 그 호칭에 결부된 행동 규약(인용 절차, 단정 금지 등)에서 나온다. 호칭만 붙이면 품질은 오르지 않는다.
• 긴 참고 자료는 구분자로 감싸 앞쪽에 두고, 그 자료를 어떤 목적에 쓰는지와 구체적 지시를 뒤쪽에 둔다.
• 확장 사고는 adaptive로만 쓰며, budget_tokens·temperature·top_p 수동 조정 선택지는 최신 모델에서 제거된 함정이다.
• 역할 부여는 어조·관점이 중요한 작업에 적합하고, 정답이 고정된 추출·분류 작업에는 절제하거나 중립적으로 둔다.