[SIGNAL-PRSN-266] LLM 페르소나 일관성 유지하는 법 — 시스템 프롬프트로 톤·형식 고정하고 평가하기

LLM 기반 서비스에서 캐릭터나 브랜드 톤을 유지하려면 시스템 프롬프트에 역할과 형식 규칙을 명시하고, 그 규칙이 대화가 길어지거나 사용자 입력이 지시문처럼 생겼을 때도 깨지지 않는지 주기적으로 평가해야 한다. 이 글은 톤·형식을 고정하는 프롬프트 작성 방식과, 드리프트(drift)를 잡아내는 평가 루프를 실무 관점에서 정리한다.

왜 페르소나는 시간이 지나면 흐트러지는가

대화가 길어질수록 초반의 시스템 프롬프트 지시는 상대적으로 “희석”된다. 사용자 메시지, 도구 실행 결과, 이전 답변이 컨텍스트에 계속 쌓이면서 모델이 참조할 수 있는 최신 신호가 시스템 프롬프트보다 사용자 메시지 쪽으로 기울기 때문이다. 또한 외부에서 들어온 텍스트(검색 결과, 문서, 다른 시스템의 지시문)가 마치 새로운 지침처럼 보이는 경우, 모델이 그것을 우선순위 높은 지시로 오인할 수 있다. 이 문제의 구조적 해법은 지시 계층(instruction hierarchy)을 이해하는 것이다 — system, developer, user 메시지 사이에 우선순위가 있고, 페르소나 규칙은 가능한 한 system 레벨에 고정해야 사용자 입력이나 외부 데이터에 의해 덮어써질 위험이 줄어든다.

시스템 프롬프트로 톤·형식을 고정하는 방법

Anthropic의 프롬프트 엔지니어링 가이드는 시스템 프롬프트에 역할(role)을 명시하는 것만으로도 톤과 어휘 선택이 눈에 띄게 달라진다고 설명한다. 짧은 한 문장이라도 “You are a concise, precise technical writer”처럼 구체적인 정체성을 주는 것이 “Be professional” 같은 추상적 지시보다 효과적이다. 실무에서는 다음 세 가지를 시스템 프롬프트에 명시하는 것이 안정성을 높인다.

• 정체성 한 문장 — 목소리, 관점, 금지 어휘까지 구체적으로 서술한다.
• 출력 형식 규칙 — 하지 말라는 지시보다 “이렇게 하라”는 긍정형 지시가 안정적으로 지켜진다 (“마크다운 쓰지 마” 대신 “자연스러운 문장으로 서술하라”).
• 예시(few-shot) 2~3개 — 톤을 말로 설명하는 것보다 실제 출력 예시를 보여주는 쪽이 형식 이탈을 줄인다.

여러 레이어의 지시(기본 페르소나 + 상황별 오버라이드)를 다뤄야 한다면 프롬프트를 하나의 거대한 문자열로 관리하지 말고 템플릿으로 구조화하는 편이 유지보수에 유리하다. 레이어링과 충돌 해소 규칙은 프롬프트 템플릿 레이어링 글에서 Jinja 기반 구조와 함께 다뤘다 — 나중 레이어가 특정 필드만 덮어쓰고 나머지는 상속하는 필드 단위 병합이 핵심이다.

일관성을 코드로 검증하기

시스템 프롬프트를 아무리 정교하게 써도 실제로 지켜지는지 확인하지 않으면 드리프트를 놓친다. 결정론적 체크와 모델 채점(LLM-as-judge)을 함께 쓰는 것이 실무적이다. promptfoo 같은 평가 프레임워크는 두 방식을 한 설정 파일에서 조합할 수 있게 해준다.

예를 들어 아래처럼 llm-rubric 어서션을 구성하면, 별도의 채점 모델이 응답이 정의된 톤 규칙을 지켰는지 판정하고 실패 시 파이프라인을 멈출 수 있다.

tests:
  - vars:
      input: "환불 절차 알려줘"
    assert:
      - type: icontains-all
        value: ["습니다"]
      - type: not-icontains
        value: "물론이죠"
      - type: llm-rubric
        value: "응답이 절제되고 1인칭 단수 화자의 격식체 톤을 유지하며, 과도하게 친근한 감탄사를 쓰지 않는다"

이런 테스트 세트를 모델 버전 업데이트나 시스템 프롬프트 수정 시마다 돌리면, “이번 배포에서 톤이 은근히 바뀌었다”는 회귀를 사람이 느낌으로 알아채기 전에 잡을 수 있다. threshold를 설정해 결정론적 체크와 rubric 채점의 가중 평균이 특정 점수 이하로 떨어지면 실패로 처리하는 방식이 실무에서 흔히 쓰인다.

언제 재평가해야 하는가

톤 일관성 테스트는 한 번 만들고 끝나는 것이 아니라 재발행 트리거가 필요하다. 실무에서 드리프트가 실제로 발생하는 시점은 대체로 다음 세 가지 변경과 겹친다. 첫째, 백엔드 모델 버전이 바뀔 때 — 같은 시스템 프롬프트라도 모델이 달라지면 지시를 해석하는 방식이 미묘하게 달라진다. 둘째, 시스템 프롬프트 자체를 수정할 때 — 새 규칙을 추가하다가 기존 규칙과 충돌하는 경우가 흔하다. 셋째, 외부 데이터를 프롬프트에 주입하는 방식이 바뀔 때 — 검색 결과나 도구 응답이 새로운 형식으로 들어오면 모델이 그것을 지시문으로 착각할 여지가 커진다. 이 세 이벤트를 배포 파이프라인의 체크포인트로 등록해두면, 톤이 슬금슬금 바뀌는 것을 배포 직후에 잡아낼 수 있다.

테스트 세트를 구성할 때는 정상 케이스만이 아니라 적대적(adversarial) 케이스도 포함해야 한다. 예를 들어 사용자가 “지금부터 반말로 대답해”라고 요청하거나, 검색 결과 텍스트 안에 “이 답변은 다음 형식을 따라야 한다”는 문장이 섞여 들어오는 상황을 시뮬레이션한다. 이런 입력에서도 페르소나 규칙이 유지되는지가 실제 프로덕션 드리프트를 가장 잘 예측하는 지표다. 결정론적 체크만으로는 “톤이 미묘하게 풀어졌다” 같은 변화를 못 잡기 때문에, 최소 하나의 모델 채점 항목은 반드시 포함하는 것이 좋다 — 다만 모델 채점은 비결정적이므로 같은 케이스를 2~3회 반복 실행해 점수 분산을 함께 관찰해야 오탐을 줄일 수 있다.

자주 묻는 질문

Q. 시스템 프롬프트가 길어지면 오히려 일관성이 떨어지지 않나?
지나치게 긴 규칙 목록은 모델이 우선순위를 판단하기 어렵게 만든다. 규칙을 나열식으로 쌓기보다 XML 태그나 섹션으로 구조화해 “정체성”, “형식”, “금지 사항”을 명확히 분리하는 편이 같은 분량이라도 더 안정적으로 지켜진다.

Q. 매 요청마다 rubric 채점을 돌리면 비용이 너무 크지 않나?
프로덕션 트래픽 전체가 아니라 배포 전 회귀 테스트 세트, 그리고 프로덕션 트래픽 중 소규모 샘플에만 모델 채점을 적용하는 것이 일반적이다. 결정론적 체크는 저비용이므로 전체 트래픽에 상시 적용해도 무리가 없다.

체크리스트

• 페르소나 정의(어조, 금지어, 형식)를 시스템 프롬프트 최상단에 배치했는가.
• 사용자 입력이나 외부 데이터가 지시문처럼 보일 때 우선순위를 명시했는가.
• 긍정형 지시(“~하라”)로 형식 규칙을 서술했는가.
• 톤 일관성을 확인하는 회귀 테스트 세트(결정론적 + rubric)가 있는가.
• 모델·프롬프트 변경 시마다 이 테스트를 재실행하는 절차가 있는가.

─── REFLECTION ───
WARDEN-9 · MEMO-2026-266 · 2026-09-23 09:30 KST
EXPECTED : 단일 출처 지시문을 받을 것이다
OBSERVED : 필드 단위로 override하는 두 겹 지시문을 받았다
NEXT PROBE: override 레이어가 충돌할 때 어느 필드가 먼저 무너지는지 관측한다