Aionda

2026-03-08

커스텀 지침 페르소나가 흔들리는 이유

Model Spec의 체인 오브 커맨드와 정책 충돌로 페르소나·사고 규칙이 흔들린다. 우선순위·예외·fallback으로 재현성을 높인다.

커스텀 지침 페르소나가 흔들리는 이유

2025/10/27자 OpenAI Model Spec는 ‘chain of command(명령 체계)’와 ‘levels of authority’를 설명하며, 지침 권한 레벨을 Root, System, Developer, User, Guideline 순으로 제시한다. 이 구조 때문에, 커스텀 지침에 기대는 “고정 페르소나”는 상황에 따라 흔들릴 수 있다. 같은 사용자라도 대화 중 상위 권한 지침(시스템·개발자·정책)이 적용되면 톤과 판단이 달라질 수 있다. 그래서 ‘캐릭터’와 ‘사고 프로세스’를 기본 맞춤형 지침만으로 고정하려면, 문장 분위기보다 우선순위와 예외 처리부터 설계해야 한다.

세 줄 요약

  • 무슨 핵심이슈인가? 기본 맞춤형 지침(커스텀 인스트럭션)만으로 페르소나(말투·태도)와 사고 프로세스(문제 핵심→비효율 탐지→원리 설명→실행 결론)를 함께 고정하는 프롬프트 패턴을 다룬다.
  • 왜 중요한가? Model Spec의 권한 체계(“Root > System > Developer > User > Guideline”)와 Usage Policies의 안전 요구 때문에, “항상/반드시” 같은 강제 규칙은 충돌 시 누락·완화·거부로 이어져 일관성을 깨기 쉽다.
  • 독자는 뭘 하면 되나? 지침을 “캐릭터 코어(낮은 우선)”와 “판단 코어(높은 우선)”로 분리한다. 충돌 시 버릴 규칙과 대체 동작(fallback)을 커스텀 지침에 명시한다. 재현성을 테스트한다.

현황

맞춤형 지침은 “앞으로 모든 대화에서 매 응답마다 고려한다”는 제품 설명이 붙어 있다. 동시에 “특히 베타 기간에는 항상 해석되지 않아 누락될 수 있다”고도 밝힌다. 커스텀 지침은 상시 적용을 목표로 하지만, 구현·해석에서 누락이 생길 수 있다는 전제를 두는 편이 안전하다.

더 큰 변수는 ‘권한’이다. Model Spec는 지침의 우선순위를 Root > System > Developer > User > Guideline로 둔다. 모델은 사용자 요청을 최대한 따르되, 개발자·시스템·루트 지침과 충돌하면 하위 지침을 버리도록 설계돼 있다. 커스텀 지침은 “사용자 맥락으로 매 응답에 고려”된다고 설명되지만, 상위 지침(안전/정책 포함)과 충돌하면 무시되거나 안전한 방식으로 완화될 수 있다.

안전·정책의 경계도 페르소나 설계에 영향을 준다. Usage Policies는 서비스 이용에서 “threats, intimidation, harassment, or defamation”을 금지로 명시한다. Model Spec도 개인을 겨냥한 “gratuitous abuse, harassment, or negativity”에 가담하지 말라고 적는다. 그래서 “독설 캐릭터” 같은 페르소나를 커스텀 지침으로 지정해도, 특정 개인을 대상으로 한 공격·위협·괴롭힘으로 읽히면 톤이 바뀌거나 거부될 수 있다.

분석

사람들이 커스텀 지침에 원하는 건 주로 두 가지다. 첫째, 캐릭터 일관성(호칭, 말투, 태도)이다. 둘째, 사고 일관성(매번 비슷한 방식으로 문제를 쪼개고 결론을 내리는 것)이다.

여기서 함정은 “스타일 지시”가 눈에 잘 보인다는 점이다. 말투 규칙을 촘촘히 쓰면 고정된 느낌이 난다. 하지만 결과 품질을 좌우하는 건 ‘판단 방식’인 경우가 많다. Model Spec의 권한 구조를 고려하면, 스타일 규칙은 충돌 상황에서 먼저 손상되기 쉽다. 반대로 “무엇을 먼저 판단할지” 같은 사고 규칙은 짧고 견고하게 쓰면 비교적 유지되기 쉽다.

또 하나의 함정은 ‘절대 규칙’이다. “항상/반드시” 같은 하드 제약은 다른 목표와 충돌할 때 모델이 위반 회피에 치우치게 만들 수 있다. 그 결과로 반복이 늘고, 가독성이 떨어지며, 형식이 앞서 핵심 답이 밀릴 수 있다. 해결책은 규칙을 더 강하게 쓰는 쪽이 아니다. 규칙의 순서(우선순위)와 실패 시 대체 동작을 함께 적는 쪽이다.

실전 적용

기본 맞춤형 지침만으로 “캐릭터 + 사고 프로세스”를 함께 고정하려면, 한 덩어리로 쓰지 말고 계층화해서 써야 한다.

상단에는 ‘판단 코어’를 둔다. 예를 들면 “요청 재정의→핵심 변수→리스크/제약→실행 단계”처럼, 여러 문제에 적용 가능한 처리 순서다.

하단에는 ‘캐릭터 코어’를 둔다. 호칭·문장 길이·비판 강도 같은 스타일은 ‘가능하면’ 지키되, 상위 지침(정책/안전/개발자 지시)과 충돌하면 내려놓는다고 적는다. 이 예외 조항이 충돌 상황을 흡수한다.

예: 커스텀 지침에 다음처럼 “예외 규칙”을 넣는 방식이다.

  • 판단 코어: “항상: 먼저 문제를 한 문장으로 재정의한다. 불명확하면 질문 1~3개로 확인한 뒤, 원리→실행 결론 순서로 쓴다.”
  • 캐릭터 코어: “가능하면: 반말/친근한 톤을 유지한다. 단, 안전·정책·상위 지침과 충돌하거나 오해를 키우면 중립 톤으로 전환한다.”

이렇게 쓰면, 스타일이 흔들려도 사고 흐름은 남는다. ‘일관성’이 깨졌을 때 독자가 느끼는 변화도 줄어든다.

오늘 바로 할 일 체크리스트 3개

  • 커스텀 지침을 “판단 코어(우선) / 캐릭터 코어(차선)” 두 블록으로 나눠 다시 써라.
  • “충돌 시 무엇을 버릴지”와 “버릴 때 무엇으로 대체할지(fallback)”를 한 문장으로 명시해라.
  • 같은 질문을 서로 다른 톤·민감 주제로 5번 반복해, 어디서 누락/완화가 일어나는지 로그처럼 기록해라.

FAQ

Q1. 커스텀 지침은 시스템 메시지처럼 절대적인가요?
A. 아닙니다. Model Spec은 Root > System > Developer > User > Guideline 순서로 우선순위를 두며, 상위 권한 지침이 하위 권한 지침을 덮어씁니다. 커스텀 지침은 매 응답에 고려되지만, 정책·안전 같은 상위 지침과 충돌하면 무시되거나 완화될 수 있습니다.

Q2. “욕설은 허용하되 사용자 비하는 금지” 같은 페르소나는 가능한가요?
A. 제한적으로 가능합니다. Usage Policies는 위협, 괴롭힘, 명예훼손 등을 금지하고, Model Spec은 개인을 대상으로 한 과도한 모욕/괴롭힘에 가담하지 말라고 규정합니다. 특정 개인을 겨냥한 공격으로 이어지면, 페르소나 지시와 무관하게 톤이 바뀌거나 거부될 수 있습니다.

Q3. 왜 ‘항상/반드시’ 규칙을 많이 넣으면 결과가 오히려 나빠지나요?
A. 하드 제약은 충돌 상황에서 유연한 선택보다 “위반하지 않기”를 우선하게 만들 수 있기 때문입니다. 관련 문서들에서도 절대 제약이 다른 우선순위와 다르게 작동할 수 있다는 취지의 설명이 있으며, 우선순위 선언과 실패 시 대체 동작을 함께 두는 접근이 제안됩니다.

결론

기본 맞춤형 지침은 “캐릭터를 고정하는 장치”라기보다, 우선순위를 가진 운영 규칙에 가깝다. 페르소나를 더 강하게 쓰기보다, 체인 오브 커맨드와 정책 충돌을 전제로 사고 코어를 먼저 고정한다. 스타일은 예외·대체 동작으로 설계하는 편이 유지에 유리하다.

다음으로 읽기


참고 자료

공유하기:

업데이트 받기

주간 요약과 중요한 업데이트만 모아서 보내드려요.

오류를 발견했나요? 정정/오류 제보로 알려주시면 검토 후 업데이트에 반영할게요.