2.5.5. 의미 기반 오라클(Semantic Oracle): 임베딩 벡터 유사도(Cosine Similarity)를 활용한 비교

2.5.4절에서 다룬 구조적 오라클이 ’그릇의 형태’를 검증했다면, 이제는 그 그릇에 담긴 ’내용물의 본질’을 정량적으로 검증할 차례다. 하지만 언어의 세계에서 본질(Semantics)을 수학적으로 비교하는 것은 극도로 까다롭다. “자동차“와 “승용차“는 글자가 완전히 다르지만 같은 개념을 공유하며, 반대로 “눈(Eye)“과 “눈(Snow)“은 글자가 같지만 전혀 다른 세계에 속한다.

과거의 소프트웨어 테스트가 의존하던 문자열 일치 판독기(String Matcher)는 이러한 지시 대상의 맥락적 동치성을 전혀 이해하지 못한다. 이를 해결하기 위해 현대 AI 오라클 시스템은 텍스트를 기하학적 공간으로 투영하는 임베딩 기술을 도입하여, **의미 기반 오라클(Semantic Oracle)**이라는 새로운 지평을 열었다. 본 절에서는 임베딩 벡터(Embedding Vector)와 코사인 유사도(Cosine Similarity)를 활용하여 참조 기반 정답(Ground Truth)과 무한히 변화하는 모델 생성물 사이의 거리를 측정하는 전략을 상세히 분석한다.

1. 텍스트 임베딩(Text Embedding)과 벡터 공간(Vector Space)

자연어를 기계가 계산할 수 있는 실수형 텐서(Tensor)로 변환하는 과정을 **임베딩(Embedding)**이라고 한다. 최신의 임베딩 모델(예: text-embedding-3-small, BERT)은 단어나 문장이 지닌 맥락적, 구문적, 의미적 속성을 수백에서 수천 차원의 고차원 벡터 평면상의 한 좌표로 위치시킨다.

이 벡터 공간 내에서는 단어의 글자 모양이 아닌 ’의미적 특성’만이 좌표를 결정한다. 따라서 모델이 생성한 정답(Output)과 개발자가 설정한 모범 답안(Reference)이 의미적으로 유사할수록, 공간 상에서 두 벡터가 가리키는 화살표의 방향은 일치하게 된다.

2. 코사인 유사도(Cosine Similarity)를 통한 동치성 산출

두 텍스트가 의미적으로 얼마나 동일한가를 판별하기 위해, 오라클은 벡터 공간에서 두 벡터(화살표)가 이루는 사잇각( $\theta$ )의 코사인 값을 추적한다. 이를 **코사인 유사도(Cosine Similarity)**라 부른다.

주어진 지식 기반 참조 텍스트(Ground Truth)의 임베딩 벡터를 $A$ , 모델이 생성한 출력 텍스트의 임베딩 벡터를 $B$ 라고 할 때, 코사인 유사도 $S_c$ 는 다음 식을 통해 도출된다.

$S_c(A, B) = \cos(\theta) = \frac{A \cdot B}{\vert A \vert \vert B \vert} = \frac{\sum_{i=1}^{n} A_i B_i}{\sqrt{\sum_{i=1}^{n} A_i^2} \sqrt{\sum_{i=1}^{n} B_i^2}}$

$1.0$ (완전 일치): 두 벡터의 방향이 완벽히 동일하다( $\theta=0^{\circ}$ ). 의미가 완벽하게 일치함을 뜻한다.
$0.0$ (직교): 두 벡터가 직교한다( $\theta=90^{\circ}$ ). 두 무리의 텍스트가 의미론적으로 완전히 무관함을 뜻한다.
$-1.0$ (반대): 두 벡터가 완전히 반대 방향을 향한다( $\theta=180^{\circ}$ ). 정반대의 개념이나 상반된 주장을 담고 있음을 암시한다(단, 최신 임베딩 모델의 특성상 실제 -1.0이 나오는 경우는 드물다).

2.1. 코사인 유사도 검증 파이프라인 작동 원리

flowchart LR
    Ref[Reference Text \n "The baby is crying."] --> Embed1(Embedding Model)
    Output[Model Output \n "An infant is weeping."] --> Embed2(Embedding Model)
    
    Embed1 --> VectorA["Vector A \n [0.42, -0.11, ..., 0.88]"]
    Embed2 --> VectorB["Vector B \n [0.44, -0.09, ..., 0.82]"]
    
    VectorA --> Cosine{Cosine \n Similarity \n Calculation}
    VectorB --> Cosine
    
    Cosine --> Score["Score: 0.94"]
    
    Score --> Threshold{"Score >= Threshold \n (e.g., 0.85)?"}
    Threshold --> |Yes| Pass((PASS))
    Threshold --> |No| Fail((FAIL))
    
    style Pass fill:#efe,stroke:#3c3,stroke-width:2px;
    style Fail fill:#fdd,stroke:#d00,stroke-width:2px;

3. 의미 기반 오라클의 실무적 한계와 취약성

코사인 유사도를 활용한 의미 기반 오라클은 기존의 단순 문자열 비교 도구에 비해 놀라운 유연성을 부여하며, 프롬프트 엔지니어링의 숨통을 트여준다. 그러나 실무 배포(Production) 환경에서는 치명적인 맹점들을 드러내곤 하는데, 이에 대한 명확한 인지와 대비가 필수적이다.

3.1. 부정어(Negation)에 대한 공간적 맹목성 (Spatial Blindness)

임베딩 공간의 가장 큰 약점은 부정어를 구별하는 능력이 형편없다는 것이다.
“이 약은 환자에게 투여해야 한다.“와 “이 약은 환자에게 투여해서는 안 된다.“라는 두 문장은, 의미론적으로는 극과 극의 정반대(생사를 가름) 사실이지만, 임베딩 벡터 공간에서는 단어 구성이 너무나 비슷하기 때문에 코사인 유사도 $0.95$ 이상의 ’완벽한 정답(PASS)’으로 처리되어 버린다. 문서의 키워드가 중복될수록, 모델은 부정어 하나가 뒤집은 팩트를 캐치해내지 못한다.

3.2. 문맥 외 노이즈(Out-of-context Noise) 희석

모델이 장황하게 500자를 답변하면서 450자의 헛소리를 하고 50자의 정답을 끼워 넣었을 때, 전체 벡터의 무게 중심은 정답에서 멀어지게 되어 억울하게 FAIL 판정을 받는 위음성(False Negative) 이슈가 발생한다. 반대로, 참조 텍스트 자체가 짧거나 모호할 경우에는 오라클의 기준점 자체가 흔들리게 된다.

3.3. 임베딩 모델 의존성에 따른 부채(Debt)

오라클을 임의의 임베딩 엔진(예: 모델 A)으로 세팅하여 임계치 $\tau=0.88$ 로 간신히 튜닝해 놓았는데, 인프라 고도화 등의 이유로 엔진을 성능이 더 좋은 모델 B로 교체해야 하는 상황이 온다면, 기존의 측정 기준(Threshold)은 전부 무용지물이 되어 오라클 부채(Oracle Debt)가 폭발적으로 증가한다. 차원이 다르면 내적도 할 수 없고 호환도 되지 않기 때문이다.

4. 소결: 보조 지표로서의 의미론적 접근

의미 기반 오라클(Semantic Oracle)은 표현의 다양성을 허용하는 매우 우아한 검증 툴킷임은 분명하다. 그러나 부정어 체킹 등 결정적인 팩트 검증에서 치명적인 하자를 지니고 있으므로, 단일한 진리로 사용(Single Source of Truth)되기보다는 인간의 직관(Heuristics)을 모방하는 보조 지표로 격하시켜 파이프라인의 중간 방어막 중 하나로만 사용해야만 한다.

이어지는 **2.5.6절(메타모픽 테스팅)**에서는 이러한 절대적인 정답(Reference)과의 거리 측정이 불가능할 때, 프로그램의 관계적 불변성(Relational Invariant)을 활용하여 교묘하게 오라클을 구축해내는 기법을 다룬다.