2.4.5. 프롬프트 민감도에 따른 결과의 비일관성(Inconsistency) 문제

2.4.4절에서 살펴본 의미적 동등성(Semantic Equivalence) 검증은 인간의 유연한 언어를 기계가 이해할 수 있도록 만든 강력한 진보였다. 그러나 가장 완벽하게 구축된 의미적 검증 파이프라인조차도, 거대 언어 모델(LLM)이 지닌 또 다른 치명적인 기질 앞에서는 허무하게 무너져 내린다. 바로 **‘프롬프트 민감도(Prompt Sensitivity)’**다.

전통적인 API는 파라미터를 입력받을 때, 공백이나 마침표 하나가 추가되었다고 해서 내부 비즈니스 로직을 송두리째 뒤바꾸지 않는다. 그러나 LLM은 입력(Prompt) 텍스트의 아주 미세한 변동성에 극단적으로 반응하며, 동일한 의도(Intent)를 묻는 질문임에도 불구하고 매번 전혀 다른 논리 회로를 가동하여 완전히 상반된(Inconsistent) 결론을 도출해버리는 카오스(Chaos)적 양상을 띤다.

본 절에서는 “단어 하나의 차이가 어떻게 모델의 가중치를 파괴적으로 흔들어 놓는가“에 대한 민감도의 공학적 기원을 분석하고, 이것이 회귀 테스트(Regression Test) 아키텍처에 미치는 파괴적인 지진파(Tremor) 효과를 해부한다.

1. 프롬프트 민감도(Prompt Sensitivity)의 실체

프롬프트 민감도란 동일한 목적을 수행하는 함수 호출(여기서는 NLP 입력)의 어휘적, 논리적, 혹은 구조적 형태가 조금만 바뀌어도 언어 모델의 결과가 비결정적으로 변위(Drift)하는 현상을 일컫는다. 모델이 입력값을 ’수학적 인자(Argument)’가 아니라 ’통계적 확률 분포를 자극하는 트리거(Trigger)’로 받아들이기 때문에 발생한다.

테스트 자동화를 마비시키는 프롬프트 민감도는 대표적으로 다음과 같은 세 가지 양상으로 나타난다.

1.1 어휘적(Lexical) 표면 민감도

동일한 의미를 가진 동의어(Synonym) 간의 교체만으로도 모델의 성능 궤도가 완전히 뒤바뀐다.

사례: “이 리뷰의 감정을 분류해라“라는 프롬프트에서는 90%의 정확도를 보이던 모델이, “이 리뷰의 감성을 평가해라“라고 단어 하나를 바꾸는 순간 정확도가 60%로 폭락할 수 있다. 모델이 훈련 과정에서 ’분류(Classify)’라는 단어 주변에 더 밀집된 주의력(Attention)을 할당했기 때문이다.

1.2 구조적(Structural) 포맷 민감도

질문을 제시하는 마크다운(Markdown)의 구조, 예시(Few-shot)의 배치 순서, 심지어 들여쓰기나 마침표의 유무까지 결과에 거대한 영향을 미친다.

사례: JSON 형식으로 결과를 출력하라고 지시했을 때, 프롬프트의 끝에 “```json” 이라는 기호를 열어주는 것만으로도 모델이 형식을 지킬 확률이 기하급수적으로 치솟는다. 반대로 빈 줄 하나가 추가되면 모델은 맥락을 잃고 횡설수설하기 시작한다.

1.3. 역할(Persona) 및 모멘텀 민감도

“너는 20년 차 시니어 엔지니어다“라는 문자열 하나가 모델 내부의 활성화 벡터를 완전히 다른 군집(Cluster)으로 스위칭시킨다. 이 모멘텀 하나에 의해 이후에 출력되는 모든 텍스트의 논리와 어조가 비결정적으로 요동친다.

2. 민감도가 파괴하는 테스팅의 신뢰성: 깨진 그릇(Fragile Pipe)의 딜레마

이러한 프롬프트 민감도는 지속적 통합(CI) 파이프라인 환경에서는 그 자체가 재앙으로 작용한다.

어느 날 챗봇의 응답 포맷을 약간 개선하고자 프롬프트의 첫 문장을 “친절하게 대답해 줘“에서 “가장 다정하게 답변해 줘“로 변경하였다고 가정하자. 이 사소한 변경(Minor Patch) 하나 때문에, 어제까지 완벽히 통과(Pass)했던 5,000개의 테스트 케이스 중 절반이 전혀 다른 구조의 텍스트를 뱉어내어 전부 실패(Fail)할 수 있다.

graph TD
subgraph The Fragility of Prompting
direction TB
BasePrompt["Base Prompt:\n'이 문서를 요약하라'"]

Patch1["Patch A: \n'이 문서를 3줄로 요약하라'"]
Patch2["Patch B: \n'이 문서를 요약하라.' (마침표 추가)"]

BasePrompt --> |Test Suite Run (100% Pass)| SUT_LLM(LLM Engine)

Patch1 -.-> |Minor Update| SUT_LLM
Patch2 -.-> |Trivial Update| SUT_LLM
end

subgraph Butterfly Effect in Testing
SUT_LLM --> Output1["Consistent Output"]
SUT_LLM --> Output2[/"Completely Broken JSON \n & Logic"/]
SUT_LLM --> Output3[/"Suddenly Declines to Answer"/]
end

style BasePrompt fill:#efe,stroke:#3c3,stroke-width:2px;
style Patch1 fill:#ffc,stroke:#f0a020,stroke-width:2px;
style Patch2 fill:#fdd,stroke:#d00,stroke-width:2px;
style Output2 fill:#fdd,stroke:#d00;
style Output3 fill:#fdd,stroke:#d00;

기존의 소프트웨어 공학에서는 코드의 영향도(Impact Scope)를 격리하기 위해 모듈 분리 및 캡슐화(Encapsulation)를 활용했다. 그러나 단 하나의 거대한 텍스트로 뭉쳐진 프롬프트 세계에서는 **‘조그마한 국소적 변경이 전역적인(Global) 파멸적 붕괴’**를 가져온다. 테스트가 깨졌을 때, 도대체 프롬프트의 어느 단어가 이 연쇄 붕괴를 촉발했는지 디버깅(Debugging)하는 것은 사실상 불가능함에 가깝다.

3. 소결: 프롬프트 엔지니어링의 오라클 종속

프롬프트 민감도는 생성형 AI를 활용하는 플랫폼이 단순한 스크립트로 구동될 수 없는 본질적인 이유를 명확하게 짚어 준다. 프롬프트는 더 이상 사용자 입력이 아니라, 시스템의 행동을 규정하는 역동적인 ‘소스 코드(Source Code)’ 그 자체로 격상되었다.

그리고 이 소스 코드가 지닌 극단적 민감성과 비일관성 문제로 인하여 우리는 “테스트를 통과하기 위해 프롬프트를 무한정 깎아내는 사투(Chapter 4에서 다룰 예정)“를 벌이게 되었다.

그러나 공학자들을 가장 무기력하게 만드는 것은 프롬프트 민감도 현상 이면에 짙게 드리워진 거대한 그림자다. 바로 **“도대체 왜 프롬프트의 마침표 하나가 결과를 뒤집어 놓는지, 모델의 설계자조차 설명할 방법이 없다”**는 참담한 현실이다.
다음 절(2.4.6. 블랙박스로서의 AI 모델과 설명 불가능성)에서는 AI 모델의 내부 연산을 역추적할 수 없는 이 본질적인 ’블랙박스’의 특성이 테스트 오라클 구축 시에 어떠한 공학적 절망을 안겨주는지, 그 치명상을 심층적으로 추적한다.