3.6.2.1 톤앤매너(Tone & Manner) 가이드라인의 정량화 시도

“친절하게 대답해 줘”, “전문적인 어조를 유지해 줘“와 같은 톤앤매너(Tone & Manner) 가이드라인은 인간 작업자에게는 직관적이지만, 결정론적 기계인 오라클(Oracle)에게는 악몽과도 같은 모호성(Ambiguity)을 선사한다.

AI의 답변이 사실관계에서 완벽하더라도, 그 화법이 브랜드 가치와 충돌한다면 이는 명백한 결함(Defect)이다. 따라서 창의성이 어느 정도 허용되는 텍스트 생성 영역일지라도, 오라클 시스템은 이 주관적인 ’톤’을 수치화하고 채점할 수 있는 ’정량적 마지노선(Quantitative Baseline)’으로 변환해야 한다.

1. 정성적 지시어의 형태소적/구문론적 치환

가장 확실한 톤앤매너 정량화의 첫걸음은, 추상적인 형용사를 기계가 정규표현식(Regex)으로 탐지할 수 있는 구체적인 구문론적(Syntactic) 규칙으로 매핑(Mapping)하는 것이다.

• “격식 있고 전문성 있게 작성하라” (추상적)
  이 지시어 기반의 오라클은 Fail의 주관성에 시달리게 된다. 이를 다음과 같이 정량적으로 분해해야 한다.
• 종결어미 제약: 모든 문장은 반드시 “-습니다”, “-입니다”, “-합니다“로 끝나야 하며, “-요”, “-죠” 등의 비격식체 종결어미가 발견되면 Fail 처리한다.
• 문장 길이 제약: 단문(20자 이내)의 연속된 사용을 지양하고, 평균 문장 길이를 특정 바이트(Byte) 수치 사이로 강제한다.
• 이모지(Emoji) 금지: 응답 내에 유니코드 이모지 블록이 단 하나라도 탐지되면 즉시 Fail 점수를 부여한다.

오라클은 이러한 문법적 속성을 파이썬(Python)의 문자열 파서(Parser)를 통해 O(1)의 속도로 기계적으로 검증해 낼 수 있다.

2. 네거티브 룰(Negative Rule)을 통한 경계선(Boundary) 설정

톤앤매너를 “어떻게 말해야 하는가“로 정의하는 것보다, **“절대 어떻게 말해서는 안 되는가”**로 정의하는 것이 공학적으로 훨씬 명확하다.

오라클의 정답지에는 반드시 브랜드 가이드라인을 위반하는 ’정량화된 감점 사전(Penalty Dictionary)’이 포함되어야 한다.

• 슬랭 및 비속어 덱: 특정 은어, 유행어, 과장된 감탄사(예: “대박”, “진짜”)를 금지어(Blacklist) 배열에 등록하고 출현 빈도를 카운트한다.
• 수동태/능동태 비율: “문제가 발생되었습니다“와 같은 책임 회피성 수동태 문장이 전체 응답의 30%를 초과하는지 자연어 처리(NLP) 파이프라인(예: KoNLPy 등)을 통해 정량적으로 측정하여 품질을 감시한다.

3. 심판관(LLM-as-a-Judge)을 이용한 차원별 리커트 척도(Likert Scale)화

구문론적 룰만으로 잡아낼 수 없는 미묘한 ’불쾌함’이나 ’비아냥’의 뉘앙스는, 최종적으로 별도의 평가용 LLM(Judge Model)을 사용하여 다차원적인 수치로 변환해야 한다.

이때, 프롬프트 엔지니어는 심판관에게 “이 문장이 친절한가?“라고 묻지 말고, 특정 차원(Dimension)을 1점에서 5점 사이의 리커트 척도(Likert Scale)로 채점하도록 강제하는 스키마를 부여해야 한다.

{
  "evaluation_criteria": {
    "empathy_score": 4,  // 공감 척도 (1: 냉담함 ~ 5: 지나치게 감정적)
    "clarity_score": 5,  // 명확성 척도 (1: 모호함 ~ 5: 즉각적 이해 가능)
    "professionalism_score": 4 // 전문성 척도
  }
}

오라클 시스템은 심판관 LLM이 반환한 이 정량화된 숫자들을 합산하여, 사전에 정의된 임계점(Threshold, 예: 총점 12점 이상)을 넘지 못하는 텍스트는 톤앤매너 위반으로 간주하고 폐기한다.

결국, 창의적인 AI의 언어를 통제하는 오라클 아키텍트는 “톤(Tone)은 기분(Mood)이 아니라, 엄격하게 엔지니어링된 규칙(Rule)의 집합이다“라는 철학을 테스트 스위트 코드 전체에 뿌리내리게 해야 한다.