1.4.1 전통적 단위 테스트(Unit Test)의 한계: assert(output == expected) 구문의 무력화

1. 결정론적 세계관의 붕괴와 새로운 검증 패러다임의 필요성

소프트웨어 공학의 역사에서 단위 테스트는 시스템의 최소 기능을 검증하는 가장 강력하고 기초적인 도구로 군림해 왔다. 수십 년간 개발자들은 입력 X를 함수 f에 대입했을 때 도출되는 출력 Y가 사전에 정의된 기댓값(Expected Value)과 한 치의 오차도 없이 일치할 것이라는 확신 속에 코드를 작성해 왔다. 이러한 확신은 결정론적 컴퓨팅 환경의 산물이며, 그 상징적인 표현식이 바로 assert(output == expected)이다. 그러나 거대 언어 모델(LLM)을 필두로 하는 생성형 AI의 등장은 이러한 수십 년 된 검증의 문법을 근본적으로 무너뜨리고 있다. 전통적 소프트웨어가 명시적인 조건문과 반복문을 통해 ’로직’을 직접 포함하는 것과 달리, 현대의 AI 시스템은 데이터를 통해 학습된 확률적 가중치를 기반으로 로직을 ’추론’해내기 때문이다.

이러한 패러다임의 전환은 단순히 기술적인 변화를 넘어 소프트웨어 품질 보증(QA)의 철학적 기반을 흔들고 있다. 전통적 소프트웨어에서 버그란 논리적 결함에 의해 발생하는 예측 가능한 오류를 의미하지만, 확률적 시스템인 LLM에서는 동일한 입력에 대해 매번 미세하게 다른 결과가 산출되는 것이 결함이 아닌 ’정상적인 동작’으로 간주된다. 따라서 토큰 단위의 엄격한 일치 여부를 따지는 assertEquals 방식의 테스트는 LLM이 생성하는 자연어의 유연성과 창의성을 수용하지 못하고 무수한 ’허위 실패(False Positive)’를 양산하는 병목 지점이 된다. 이는 결국 테스트 오라클(Test Oracle), 즉 테스트 결과의 옳고 그름을 판단하는 메커니즘 자체가 부재하거나 지나치게 비싸지는 ’오라클 문제(Oracle Problem)’를 심화시킨다.

2. 테스트 오라클 문제의 심화와 이론적 배경

테스트 오라클이란 특정 입력값에 대해 소프트웨어가 산출해야 하는 올바른 행동이나 결과가 무엇인지 결정하는 지침을 의미한다. 소프트웨어 테스팅의 핵심 과제는 항상 이 오라클을 어떻게 자동화할 것인가에 집중되어 왔으나, LLM의 도입으로 인해 이 문제는 새로운 국면에 접어들었다. Barr et al. (2015)의 연구에 따르면, 오라클 문제는 오라클이 아예 존재하지 않거나 이를 구현하는 데 드는 비용이 지나치게 높을 때 발생하며, 이는 전체 프로젝트 비용의 50% 이상을 차지할 만큼 치명적인 병목 현상이다.

전통적인 소프트웨어에서는 명세서(Specification)가 곧 오라클의 역할을 수행하며, 이를 코드로 옮긴 것이 assert 구문이다. 하지만 자연어를 생성하는 LLM의 경우, “어떤 요약문이 훌륭한가?“라는 질문에 대해 단 하나의 ’정답 문장’을 정의하는 것은 불가능하다. “서울은 대한민국의 수도이다“라는 문장과 “대한민국의 수도는 서울이다“라는 문장은 의미적으로 완벽히 동일하지만, 전통적 단위 테스트의 관점에서는 문장 구조와 단어의 배열이 다르다는 이유로 실패 처리된다. 이는 오라클이 물리적으로 존재하더라도 그 기준이 너무나 엄격하여 실질적인 검증 도구로서의 효용을 상실했음을 의미한다.

최근의 연구들은 이러한 오라클 문제를 해결하기 위해 부분적 오라클(Partial Oracle)이나 변형 테스트(Metamorphic Testing)와 같은 기법을 제안하고 있다. 이는 결과값의 ’정확성’을 직접 검증하기보다, 입력의 변화에 따른 출력의 ’관계’나 ’성질’을 검증함으로써 정답이 없는 환경에서도 최소한의 신뢰성을 확보하려는 시도이다.

3. 소프트맥스 온도와 비결정론의 메커니즘

LLM이 전통적 assert 구문을 무력화시키는 가장 근본적인 이유는 모델의 출력층에서 발생하는 확률적 샘플링 과정에 있다. LLM은 다음 토큰을 예측할 때 단순히 가장 확률이 높은 단어 하나를 선택하는 것이 아니라, 전체 어휘 집합에 대한 확률 분포를 계산한 뒤 그 안에서 무작위 샘플링을 수행한다. 이 과정에서 ‘온도(Temperature)’ 파라미터는 결과의 무작위성을 결정하는 핵심 변수로 작용한다.

수학적으로 소프트맥스 함수는 로짓(Logits) z_i를 확률 P(i)로 변환하며, 온도 T가 도입된 수식은 다음과 같다 :
P(i) = \frac{\exp(\frac{z_i}{T})}{\sum_{j} \exp(\frac{z_j}{T})}
이 식에서 T가 0에 가까워지면 확률 분포는 가장 높은 로짓값을 가진 토큰에 극단적으로 집중되는 ‘샤프닝(Sharpening)’ 현상이 발생하여 결과가 결정론적으로 변한다. 반대로 T가 1보다 커지면 확률 분포가 평탄해지며(Flattening), 낮은 확률을 가졌던 토큰들이 선택될 기회가 늘어나 창의적이고 예측 불가능한 답변이 생성된다. 테스트 관점에서 이는 심각한 혼란을 야기한다. T=0.7과 같은 일반적인 환경에서 수행되는 단위 테스트는 동일한 코드임에도 불구하고 실행할 때마다 결과가 달라지며, 이는 테스트의 재현 가능성을 담보할 수 없게 만든다.

심지어 온도를 0으로 설정하여 탐욕적 디코딩(Greedy Decoding)을 강제하더라도, 분산 컴퓨팅 환경에서의 부동 소수점 연산 오차나 하드웨어 아키텍처의 미세한 차이로 인해 미세한 출력 변동이 발생할 수 있다는 연구 결과가 존재한다. 결국 ’절대적인 기댓값’을 상정하는 전통적 테스트 방식은 현대 AI 시스템의 아키텍처와 정면으로 충돌하고 있는 것이다.

4. 전통적 Assertion의 형태학적 붕괴 원인

전통적인 assertEquals(expected, actual) 구문이 LLM 테스트에서 실패하는 구체적인 원인은 텍스트의 형태적(Morphological) 변동성 때문이다. 언어 모델은 인간의 언어를 모사하므로 문법적으로 완벽하면서도 형태적으로는 다양한 변종을 만들어낸다.

첫째, 공백과 구두점의 처리 문제이다. LLM은 답변의 시작이나 끝에 예상치 못한 줄바꿈(\n)이나 공백문자를 포함하는 경우가 잦으며, 특정 단어를 강조하기 위해 마크다운 문법(예: **결과**)을 임의로 적용하기도 한다. 전통적 문자열 비교 로직은 이러한 미세한 차이를 ’완전한 불일치’로 간주하여 테스트 실패를 선언한다.

둘째, 유의어와 문장 구조의 다양성이다. “사용자가 로그인했습니다“와 “로그인이 성공적으로 완료되었습니다“는 동일한 상태를 나타내는 올바른 정답이지만, 형태소 분석 없이 단순 문자열을 비교하는 assert 구문은 두 문장 사이의 공통점을 발견하지 못한다. 이는 모델의 성능이 향상되어 더 자연스럽고 풍부한 표현을 사용할수록 오히려 기존의 단위 테스트는 더 많이 실패하게 되는 역설적인 상황을 초래한다.

셋째, 형식 위반과 마크다운 펜스 문제이다. JSON이나 SQL 같은 구조화된 데이터를 출력하도록 요청했을 때, LLM은 종종 설명 텍스트를 앞뒤에 붙이거나 코드 블록 기호(```)로 감싸는 습성이 있다. 이 경우 정규 표현식이나 복잡한 파싱 로직 없이는 단순한 비교 구문으로 데이터의 유효성을 검증할 수 없다.

샘플링 파라미터의 상호작용과 테스트 가변성

단순히 온도뿐만 아니라 Top-k, Top-p, 그리고 최근 부상하는 Min-p와 같은 샘플링 파라미터들은 테스트 결과의 가변성을 더욱 증폭시킨다. Top-k 샘플링은 확률이 높은 상위 k개의 토큰으로 후보군을 제한하며, Top-p(핵심 샘플링)는 누적 확률이 p를 넘는 토큰 집합만을 고려한다. 이러한 파라미터들은 문맥에 따라 동적으로 후보군의 크기를 변화시키기 때문에, 테스트 엔지니어가 예측해야 할 출력의 경우의 수를 기하급수적으로 늘린다.

예를 들어, 확신이 높은 문맥(“프랑스의 수도는…”)에서는 소수의 토큰만이 후보가 되지만, 개방적인 질문(“가장 좋아하는 음식은…”)에서는 수백 개의 유효한 토큰이 경쟁한다. 이처럼 문맥에 따라 변화하는 가변성은 고정된 테스트 케이스를 기반으로 하는 전통적 QA 체계를 무력화시키는 핵심 요인이다. 최신 연구에서는 이러한 불확실성을 측정하기 위해 몬테카를로 온도(Monte Carlo Temperature) 샘플링이나 자가 일관성(Self-Consistency) 평가 전략을 도입하고 있으나, 이는 단일 assert 구문에 비해 훨씬 많은 컴퓨팅 자원과 복잡한 로직을 요구한다.

환각과 보안: 텍스트 일치 뒤에 숨은 거짓 음성

전통적 assert 구문이 가진 가장 치명적인 약점은 결과가 ‘그럴듯해 보이면’ 통과시킨다는 점이다. 이는 LLM의 고질적인 문제인 환각(Hallucination) 현상과 결합하여 심각한 ’거짓 음성(False Negative)’을 발생시킨다. 모델이 매우 유창하고 문법적으로 완벽한 문장을 생성했으나, 그 안의 사실관계가 틀린 경우 문자열 일치나 키워드 기반의 테스트는 이를 잡아낼 수 없다.

특히 코드 생성 분야에서 발생하는 ’패키지 환각’은 보안상의 위협으로까지 번진다. LLM이 존재하지 않는 라이브러리 함수를 호출하는 코드를 작성했을 때, 단위 테스트가 실행 환경(Sandboxed environment)에서 실제로 코드를 돌려보지 않고 텍스트 구조만 확인한다면 이 오류는 배포 단계까지 발견되지 않는다. 공격자는 이러한 모델의 특성을 악용하여 환각된 이름의 악성 패키지를 등록하는 ’공급망 공격’을 시도할 수 있으며, 이는 전통적 테스트 방식으로는 방어할 수 없는 영역이다.

또한, 모델이 시스템 프롬프트의 제약 조건을 교묘하게 위반하거나 편향된 답변을 내놓는 경우에도, 기댓값을 미리 정의하기 어려운 자연어의 특성상 assert 구문은 무력하게 침묵할 수밖에 없다. 이는 테스트의 목적이 단순히 ’형식적 일치’가 아니라 ’내용적 진실성’과 ’안전성’으로 확장되어야 함을 시사한다.

시맨틱 유사도: 토큰 일치를 대체하는 벡터 공간의 검증

assert(output == expected)를 대체하기 위한 첫 번째 대안은 텍스트를 고차원 벡터로 변환하여 의미적 거리를 측정하는 시맨틱 유사도(Semantic Similarity) 메트릭이다. 이는 단어의 형태가 다르더라도 벡터 공간상에서 근접해 있다면 이를 정답으로 인정하는 방식이다.

BERTScore는 이러한 흐름을 대변하는 지표로, 사전 학습된 트랜스포머 모델의 내부 표현을 사용하여 두 문장의 토큰 간 코사인 유사도를 계산한다. 이는 n-gram 중첩에 의존하는 BLEU나 ROUGE가 해결하지 못한 문맥적 의미 파악 문제를 상당 부분 해소한다. 이제 개발자는 assertEquals 대신 assertCosineSimilarity(actual, expected) > 0.85와 같은 임계값 기반 검증을 도입하고 있다.

하지만 임베딩 기반 방식 역시 완벽하지는 않다. “나는 사과를 먹었다“와 “나는 사과를 먹지 않았다“는 단 한 단어의 차이지만 벡터 공간에서는 매우 가깝게 위치할 수 있으며, 이는 논리적 반대 의미를 구분하지 못하는 한계로 이어진다. 따라서 더욱 정교한 논리적 검증을 위해 자연어 추론(NLI)이나 함의(Entailment) 메트릭이 추가로 요구된다.

변형 테스트와 속성 기반 테스트의 재발견

정답(Ground Truth)을 정의하기 어려운 환경에서 소프트웨어 엔지니어들이 주목한 또 다른 전략은 변형 테스트(Metamorphic Testing)이다. 1990년대에 처음 제안된 이 기법은 결과값의 절대적 정확성 대신, 여러 입력 간의 상관관계(Metamorphic Relation)를 검증한다.

예를 들어, “기존 고객에게 10% 할인을 적용하라“는 지시를 받은 LLM의 응답을 테스트할 때, 고객의 이름을 ’Alice’에서 ’Bob’으로 바꾸더라도 할인율은 10%로 유지되어야 한다는 관계를 설정할 수 있다. 만약 이름만 바꿨는데 모델의 논리적 결론이 변한다면, 구체적인 정답 문구와 상관없이 이 모델은 일관성 테스트를 실패한 것으로 간주된다. 이는 전통적 단위 테스트가 상정하는 ‘입력-출력’ 쌍의 정적 검증에서 벗어나, 시스템의 ’행동 양식’을 검증하는 동적 패러다임으로의 전환을 의미한다.

이와 병행하여 속성 기반 테스트(Property-based Testing)는 출력이 반드시 만족해야 하는 불변의 규칙들을 정의한다. 요약문은 반드시 원문보다 짧아야 한다는 ‘길이 속성’, 특정 금칙어가 포함되지 않아야 한다는 ‘안전성 속성’, 그리고 결과가 유효한 JSON 형식이어야 한다는 ‘구조적 속성’ 등이 이에 해당한다. 이러한 방식은 assert 구문의 대상을 ’값’에서 ’성질’로 옮김으로써 모델의 확률적 변동성을 포용한다.

LLM-as-a-Judge: 재귀적 검증의 명암

가장 현대적이고 논란이 많은 대안은 더 우수한 성능을 가진 모델(예: GPT-4o, Claude 3.5 Sonnet)을 검증 오라클로 사용하는 ‘LLM-as-a-judge’ 방식이다. 이는 인간 테스터의 주관적 평가를 자동화하려는 시도로, 정밀한 루브릭(Rubric)을 통해 응답의 품질, 어조, 정확성, 사실 부합 여부 등을 다각도로 평가한다.

G-Eval과 같은 프레임워크는 모델에게 평가 기준을 제시하고 1점에서 5점 사이의 점수를 부여하게 함으로써, 단순한 이진 비교(Pass/Fail)를 넘어서는 연속적인 품질 지표를 제공한다. 이는 전통적 단위 테스트가 잡아내지 못하는 ’답변의 전문성’이나 ‘공감 능력’ 같은 추상적인 속성까지도 검증 범위에 포함시킨다.

그러나 이러한 재귀적 검증은 심각한 부작용을 동반한다. 첫째, 비용과 지연 시간의 급격한 상승이다. 로컬 환경에서 무료로 수행되던 assert 구문과 달리, 모든 테스트 케이스마다 고성능 모델의 API 호출 비용이 발생하며, 이는 대규모 CI/CD 파이프라인에서 상당한 경제적 부담이 된다. 둘째, 평가 모델 자체의 편향성이다. 심사위원 모델은 응답의 내용보다 문장의 길이나 구성 방식을 선호하는 경향(Verbosity bias)을 보이거나, 자신이 생성한 스타일의 답변에 높은 점수를 주는 자기 선호 편향(Self-preference bias)을 보일 수 있다. 결국 ’누가 감시자를 감시할 것인가’라는 고전적인 질문이 소프트웨어 테스트 분야에서 다시 제기되고 있는 셈이다.

현대적 소프트웨어 테스팅의 4대 Facet: 2025년의 전망

최신 연구(2025)에 따르면, LLM 기반 시스템의 테스트 케이스 설계는 네 가지 핵심 차원(Facet)으로 구성되어야 한다. 이는 전통적 소프트웨어 테스트가 입력과 기댓값이라는 두 축으로만 이루어졌던 것과 대조적이다.

1. 시스템 하위 테스트(SUT Variance): 테스트 대상이 되는 모델의 버전, 하드웨어 설정, 양자화 수준 등을 명시적으로 관리해야 한다.
2. 목표 지향적 테스트(Goal-oriented): 단순히 코드가 돌아가는지가 아니라, 비즈니스 목적(예: 고객 이탈 방지 추론)을 달성했는지를 평가 목표로 삼는다.
3. 원자적 및 집합적 오라클(Atomic & Aggregated Oracles): 단일 응답에 대한 검증(Atomic)뿐만 아니라, 수백 번의 반복 실행을 통해 얻은 통계적 분포(Aggregated)가 신뢰 구간 내에 있는지를 확인한다.
4. 입력 가변성 관리(Input Variability): 프롬프트의 미세한 문구 변화가 결과에 미치는 영향을 측정하는 강건성 테스트를 포함한다.

이러한 Taxonomy는 테스팅이 단순한 ‘사후 확인’ 단계에서 ‘지속적인 성능 관리’ 단계로 진화하고 있음을 보여준다. 전통적인 단위 테스트 파일에 존재하던 수천 개의 assert 문은 이제 대규모 평가 데이터셋과 복잡한 평가 파이프라인으로 대체되고 있다.

경제적 관점에서의 품질 비용 재산정

전통적 단위 테스트의 무력화는 기업의 테스트 경제학에도 지대한 영향을 미친다. 과거에는 테스트 자동화 도구를 구축하는 초기 비용만 투자하면 실행 비용은 거의 0에 수렴했다. 그러나 LLM 테스팅은 실행할 때마다 비용이 발생하는 ’가변 비용 모델’로 전환되었다.

Oracle과 같은 거대 IT 기업들이 AI 추론 인프라에 천문학적인 투자를 단행하는 이유 중 하나는, 이러한 테스트와 검증 과정이 AI 서비스 운영 비용의 상당 부분을 차지하게 될 것임을 인지하고 있기 때문이다. 개발팀은 이제 “이 테스트 케이스 하나를 검증하기 위해 0.05달러를 지불할 가치가 있는가?“라는 경제적 판단을 매 순간 내려야 한다. 이는 테스트의 우선순위를 정하는 전략(Test Case Selection)이 과거보다 훨씬 중요해졌음을 의미하며, 불필요하게 모든 것을 assert 하던 습관은 이제 기술 부채가 아닌 재무 부채로 이어진다.

결론: 이진 논리의 종말과 확률적 신뢰의 탄생

결론적으로, assert(output == expected) 구문의 무력화는 소프트웨어 공학이 직면한 일시적인 장애물이 아니라, 컴퓨팅의 패러다임이 결정론에서 확률론으로 이동하고 있음을 알리는 신호탄이다. 우리는 이제 ’완벽한 일치’라는 환상에서 벗어나, ‘통계적으로 허용 가능한 오차 범위’ 내에서 시스템의 신뢰성을 확보하는 법을 배워야 한다.

현대적인 단위 테스트는 더 이상 코드의 한 줄 한 줄이 정답과 같은지를 따지는 핀셋이 아니다. 대신, 모델이 생성하는 무한한 가능성의 바다 위에서 시스템이 비즈니스의 가드레일을 벗어나지 않도록 감시하는 레이더망이 되어야 한다. 변형 테스트를 통해 일관성을 확인하고, 시맨틱 유사도를 통해 의미를 파악하며, 상위 모델을 통해 품질을 심사하는 계층적 검증 체계를 구축하는 것만이, 우리가 AI 시대의 소프트웨어에 대해 “이 시스템은 신뢰할 수 있다“라고 말할 수 있는 유일한 근거가 될 것이다.

결국 소프트웨어 테스팅의 본질은 변하지 않았다. 그것은 불확실성을 관리하고 위험을 최소화하는 과정이다. 다만 그 불확실성의 정체가 ’개발자의 실수’에서 ’모델의 확률적 본성’으로 바뀌었을 뿐이다. 이러한 변화를 겸허히 수용하고 새로운 검증의 도구들을 연마하는 개발자만이, 거대 언어 모델이라는 강력하지만 길들이기 어려운 도구를 진정으로 통제하고 혁신을 이끌어낼 수 있을 것이다. 현대 소프트웨어 공학의 신뢰는 이제 고정된 정답이 아니라, 끊임없이 변화하는 확률 분포 속에서 균형을 잡는 지혜로부터 시작된다.

참고 자료

1. Using Machine Learning to Generate Test Oracles: A … - Gregory Gay, 2월 15, 2026에 액세스, https://greg4cr.github.io/pdf/21oracleslr.pdf
2. Implementing Automated Rules-Based Evaluations for LLM, 2월 15, 2026에 액세스, https://dev.to/kalio/implementing-automated-rules-based-evaluations-for-llm-applications-468j
3. Don’t Mock Machine Learning Models In Unit Tests - Eugene Yan, 2월 15, 2026에 액세스, https://eugeneyan.com/writing/unit-testing-ml/
4. From Heuristics to Intelligence: Large Language Model-Driven Test, 2월 15, 2026에 액세스, https://www.computer.org/csdl/magazine/co/2025/12/11285930/2ckeVAQkNIQ
5. Handling Flaky Tests in LLM-powered Applications - Semaphore CI, 2월 15, 2026에 액세스, https://semaphore.io/blog/llms-flaky-tests
6. How effectively does metamorphic testing alleviate the oracle …, 2월 15, 2026에 액세스, https://vuir.vu.edu.au/33046/1/TSEmt.pdf
7. (PDF) The Oracle Problem in Software Testing: A Survey, 2월 15, 2026에 액세스, https://www.researchgate.net/publication/276255185_The_Oracle_Problem_in_Software_Testing_A_Survey
8. The Oracle Problem in Software Testing: A Survey - IEEE Xplore, 2월 15, 2026에 액세스, https://ieeexplore.ieee.org/iel7/32/7106034/06963470.pdf
9. Challenges in Testing Large Language Model Based Software - arXiv, 2월 15, 2026에 액세스, https://arxiv.org/html/2503.00481v1
10. LLM Testing in 2026: Top Methods and Strategies - Confident AI, 2월 15, 2026에 액세스, https://www.confident-ai.com/blog/llm-testing-in-2024-top-methods-and-strategies
11. Artificial Intelligence in Software Testing : Impact, Problems … - arXiv, 2월 15, 2026에 액세스, https://arxiv.org/pdf/2201.05371
12. The oracle problem in software testing: A survey, 2월 15, 2026에 액세스, https://pure.kaist.ac.kr/en/publications/the-oracle-problem-in-software-testing-a-survey
13. Strategies of Automated Test Oracle – A Survey - Academia.edu, 2월 15, 2026에 액세스, https://www.academia.edu/31915336/Strategies_of_Automated_Test_Oracle_A_Survey
14. Exact Match - Phoenix - Arize AI, 2월 15, 2026에 액세스, https://arize.com/docs/phoenix/evaluation/pre-built-metrics/exact-match
15. The Oracle Problem in Software Testing: A Survey - EECS 481, 2월 15, 2026에 액세스, https://eecs481.org/readings/testoracles.pdf
16. Metamorphic Testing: A Review of Challenges and Opportunities, 2월 15, 2026에 액세스, https://scispace.com/pdf/metamorphic-testing-a-review-of-challenges-and-opportunities-32h35onaoz.pdf
17. What is Temperature in LLMs and Its Impact on Output Quality, 2월 15, 2026에 액세스, https://www.cognativ.com/blogs/post/what-is-temperature-in-llms-and-its-impact-on-output-quality/315
18. Analytical Softmax Temperature Setting from Feature Dimensions for, 2월 15, 2026에 액세스, https://arxiv.org/html/2504.15594v1
19. Unpacking LLM Temperature - Vapi AI Blog, 2월 15, 2026에 액세스, https://vapi.ai/blog/llm-temperature
20. LLM Temperature - The Secret Sauce to Tuning AI Responses, 2월 15, 2026에 액세스, https://www.projectpro.io/article/llm-temperature/1073
21. LLM Temperature Settings: A Complete Guide for Developers - Tetrate, 2월 15, 2026에 액세스, https://tetrate.io/learn/ai/llm-temperature-guide
22. A Comprehensive Guide to LLM Temperature 🌡️, 2월 15, 2026에 액세스, https://towardsdatascience.com/a-comprehensive-guide-to-llm-temperature/
23. Essential LLM Parameters Every AI Team Needs | Galileo, 2월 15, 2026에 액세스, https://galileo.ai/blog/llm-parameters-model-evaluation
24. Understanding LLM Evaluation Metrics: BLEU, ROUGE, Exact Match, 2월 15, 2026에 액세스, https://medium.com/@pur4v/understanding-llm-evaluation-metrics-bleu-rouge-exact-match-and-bertscore-716487e40bdd
25. LLM Sampling: Temperature, Top-K, Top-P, and Min-P Explained, 2월 15, 2026에 액세스, https://www.letsdatascience.com/blog/llm-sampling-temperature-top-k-top-p-and-min-p-explained
26. Temperature, Top-k, Top-p: Ultimate Guide to AI Text Control, 2월 15, 2026에 액세스, https://www.dataunboxed.io/blog/controlling-ai-text-generation-understanding-parameters-that-shape-output
27. Monte Carlo Temperature: a robust sampling strategy for LLM’s, 2월 15, 2026에 액세스, https://aclanthology.org/2025.trustnlp-main.21.pdf
28. A Practical Guide for Evaluating LLMs and LLM-Reliant Systems, 2월 15, 2026에 액세스, https://arxiv.org/html/2506.13023v1
29. HFuzzer: Testing Large Language Models for Package … - arXiv, 2월 15, 2026에 액세스, https://arxiv.org/pdf/2509.23835
30. Assertions and Metrics - LLM Output Validation | Promptfoo, 2월 15, 2026에 액세스, https://www.promptfoo.dev/docs/configuration/expected-outputs/
31. How to evaluate LLM outputs: A practical guide to AI Evals - Futurice, 2월 15, 2026에 액세스, https://www.futurice.com/sv/blog/ai-evals-practical-guide-part-1
32. (PDF) Testing Large Language Models on Driving Theory, 2월 15, 2026에 액세스, https://www.researchgate.net/publication/382526490_Testing_Large_Language_Models_on_Driving_Theory_Knowledge_and_Skills_for_Connected_Autonomous_Vehicles
33. Adaptive and Trustworthy Software Testing in the Era of Large, 2월 15, 2026에 액세스, https://www.theamericanjournals.com/index.php/tajet/article/download/7053/6449/10028
34. Oracle expands India cloud footprint on infra biz boom, 2월 15, 2026에 액세스, https://m.economictimes.com/tech/technology/oracle-expands-india-cloud-footprint-on-infra-biz-boom/articleshow/128283571.cms