4.4.1 시스템 메시지(System Message) vs 사용자 메시지(User Message)의 치명적인 어텐션 가중치(Attention Weight) 차이 이해

프롬프트 엔지니어링의 초기 시절을 지나, 현대의 성숙한 거대 언어 모델(LLM) API 통신 규격(특히 OpenAI의 ChatML 메시징 구조나 Llama, Claude의 네이티브 알고리즘)에서는 우리가 쏘아 보내는 입력 프롬프트를 과거 GPT-3 시절처럼 단순하고 평면적인 단일 텍스트 덩어리(String Blob)로 멍청하게 취급하지 않는다. 대신, 철저하게 각 텍스트 블록마다 권한과 ’역할(Role)’이 부여된 **메시지 객체들의 배열(Array of Message Objects)**로 구조화하여 파싱(Parsing)한다. 이때 파이프라인 아키텍처에서 가장 핵심이 되고 운명을 가르는 두 가지 계급(Role)이 바로 System과 User이다.

결정론적 오라클(Deterministic Oracle)을 위한 프롬프트를 처음 설계하는 백엔드 개발자나 주니어 프롬프트 엔지니어들이 가장 흔하게 범하는 최악의 초보적인 공학적 실수는, *“너는 지금부터 엄격하게 코드를 채점하는 무자비한 오라클 판사다. 평가 결과는 반드시 지정된 JSON 규격으로만 대답해라”*라는 가장 중요한 코어 제약(Constraint) 규칙들을, 사용자가 입력한 평가 대상 데이터(Payload)와 한데 뒤섞어서 거대한 User 메시지 안쪽에 욱여넣고 API를 호출해버리는 만행이다.

이러한 무지한 방식은 텍스트의 런타임(Runtime) 컨텍스트가 길어졌을 때 모델의 어텐션(Attention) 망각을 유발하거나, 혹은 교묘하게 조작된 악의적인 사용자 입력 데이터 문자열에 의해 뼈대 규칙 자체가 오염되어 파괴되는 치명적인 시스템 크래시(Crash) 결과를 초래한다.

1. 어텐션 메커니즘(Attention Mechanism) 내에서의 구조적 가중치 편향(Weight Bias)

최신 LLM 모델들을 훈련시키고 정렬(Alignment)할 때 필수적으로 거치는 인스트럭션 튜닝(Instruction Tuning, SFT)과 인간 피드백 기반 강화학습(RLHF) 컴파일 과정은, 애초부터 System 메시지 텐서와 User 메시지 텐서에 대해 아키텍처 구조적으로 본질적으로 다르고 불평등한 **‘어텐션 가중치(Attention Weight)’**를 강제로 편향되게 부여하도록 의도적으로 설계되어 있다.

• [시스템 메시지 (System Message) - 최상위 헌법(Constitution) 및 루트 권한]:
  시스템 메시지 배열에 캡슐화되어 부여된 텍스트는 모델의 전체 인지 공간(Cognitive Space) 트라이 내에서 가장 강력하고, 절대적이며, 영구히 지속되는 지배력(Dominance)을 갖는다. 대화의 컨텍스트 윈도우(Context Window)가 무한정 길어져 히스토리가 수만 토큰(Tokens)을 돌파하더라도, 트랜스포머 모델의 셀프 어텐션(Self-Attention) 메커니즘은 시스템 메시지에 정의된 페르소나와 제약 조건을 토큰 계산의 제일 앞단 스택에 무겁게 고정하고, 다른 가벼운 토큰들 때문에 절대로 이 규칙들을 망각하지 않도록 하드코딩 수준으로 강제된다.
  이는 컴퓨터 공학 측면에서 비유하자면 운영체제(OS)의 가장 깊숙한 ‘커널(Kernel) 모드’ 메모리 영역과 정확히 같아서, 뒤따라오는 그 어떤 기교 섞인 사용자 정보도 감히 이 시스템 룰 루트(Root) 규칙을 쉽게 조작하거나 덮어쓸(Override) 수 없다.
• [사용자 메시지 (User Message) - 휘발성 있는 처리 대상 평문 데이터(Payload)]:
  반면 사용자(User) 메시지는 OS 애플리케이션 계층에서 모델이 현재 휘발성 메모리에 올려 실제로 읽고, 처리하고, 변환한 뒤 응답해야 하는 임시적인 ’작업 데이터(Task Data)’에 불과하다. 이 계층의 정보 텐서는 본질적으로 변동성이 극도로 크며, 악의적인 공격자에 의한 우회적인 프롬프트 인젝션(Prompt Injection)이나 탈옥(Jailbreak) 시도가 가장 빈번하고 더럽게 일어나는 모래사장 같은 공간이다.
  만약 MLOps 엔지니어가 시스템이 절대적으로 지켜야 하는 ’출력 제약 지시(Instruction)’를 이 더러운 데이터 공간에 함께 버무려 배치해 버리면, 모델의 신경망은 어느 것이 지시이고 어느 것이 데이터인지 혼동(Confusion)하게 된다. 결과적으로 데이터 층에 슬쩍 섞여 들어온 예외적인 문장 구조나 인젝션 명령에 의해, 모델 스스로가 자신의 출력 제약 규칙을 가볍게 무시하고 쓰레기 텍스트를 내뱉는 끔찍한 구조적 취약점(Vulnerability)을 영원히 안게 된다.

2. 프롬프트 내 규칙 하드코딩의 물리적 분리(Separation of Concerns)

따라서 결정론적인 결과를 토해내는 결함 없는 무결성 오라클을 구축하기 위한 모델 호출 프롬프트 템플릿은, 전통적인 소프트웨어 공학의 가장 위대한 아키텍처 원칙 중 하나인 ‘관심사의 분리(Separation of Concerns, SoC)’ 원칙을 API 호출 레벨에서 소름 끼치도록 철저하게 지키고 따라야 한다.

• [불변의 규칙과 제약은 오직 System 메시지에 밀봉할 것]:
  모델의 영구적인 행동 강령(Code of Conduct), 절대 불변의 출력 형식(예: 엄격한 JSON Schema 강제), 금지어 및 안전성 필터, 그리고 오라클로서 평가를 수행할 채점 루브릭(Rubric) 등 모델이 추론 과정 내내 절대 잊어서는 안 되는 모든 코어 무결점 로직은, 반드시 API의 system role 요소 계층에 단단히 하드코딩하여 밀봉해야 한다.
• [가변적인 검증 대상은 순수 User 메시지에 격리할 것]:
  소프트웨어 버전마다 끊임없이 변화하는 타겟 소스 코드 베이스 텍스트, 실시간으로 쏟아지는 지저분한 서버 오류 로그 데이터, 그리고 오늘 새롭게 테스팅하려는 유저 스토리 기능의 스펙 등은 반드시 user role 계층에 어떠한 명령어(Instruction)도 포함되지 않은 ‘순수한 상태의 텍스트 데이터(Pure Data)’ 형태로만 철저히 격리(Isolation)하여 제한적으로 전달해야 한다.

이러한 칼 같은 2티어(2-Tier) 분리 아키텍처를 통해 LLM 메모리 스코프 내에서 통치 헌법(시스템 프롬프트)과 처리 대상(사용자 데이터)을 완벽하게 물리적으로 격리해 내면, 외부 데이터의 오염 시도를 원천 차단하면서 동시에 개발자가 설계한 결정론적인 JSON 출력을 무자비하게 강제할 수 있다. 이는 일관성을 유지하는 트랜스포머 모델 본연의 프레임워크적 안정성(Stability)을 최고 한계치(Maximum Limit)로 끌어올리는, 엔터프라이즈 MLOps의 가장 기초적이고 위대한 패턴이다.