1.4.2 테스트 케이스 설계의 난이도 증가: 무한에 가까운 입력 공간과 예측 불가능한 출력 공간

인공지능(AI) 기술이 소프트웨어의 핵심 구성 요소로 자리 잡으면서, 전통적인 품질 보증(QA) 방법론은 전례 없는 도전에 직면했다. 특히 테스트 케이스 설계의 영역에서 인공지능 시스템이 지닌 비결정성(Nondeterminism)과 고차원적 데이터 처리 특성은 기존의 경계값 분석이나 동등 분할과 같은 기법들을 무력화하고 있다. 소프트웨어 엔지니어링 1.0에서는 입력 도메인이 명확하게 정의되고 제어 가능한 범위 내에 있었으나, 딥러닝과 대규모 언어 모델(LLM)이 주도하는 소프트웨어 2.0의 시대에는 입력 공간이 사실상 무한대로 확장되며, 그에 따른 출력 공간 또한 확률적 분포를 따르게 되어 예측 가능성이 극도로 낮아진다. 이러한 변화는 단순히 테스트 케이스의 숫자가 늘어나는 수준의 문제가 아니라, ’무엇이 정답인가’를 정의하는 오라클(Oracle)의 부재와 ’어떻게 모든 경로를 검증할 것인가’라는 커버리지의 한계로 이어진다.

1. 고차원 입력 도메인과 자연어의 무한한 변동성

전통적인 소프트웨어 애플리케이션은 그래픽 사용자 인터페이스(GUI)나 명령줄 인터페이스(CLI)를 통해 구조화된 데이터를 입력받는다. 이 환경에서 입력값은 데이터 형식, 길이 제약, 특정 스키마에 의해 엄격하게 관리되므로, 테스트 엔지니어는 유한한 입력 조합을 통해 시스템의 논리적 결함을 찾아낼 수 있었다. 그러나 자율주행 자동차나 자연어 처리 시스템과 같은 AI 기반 소프트웨어는 비구조화된 데이터(텍스트, 이미지, 오디오 등)를 주된 입력으로 삼는다.

1.1 딥러닝 시스템에서의 입력 공간 차원 분석

딥러닝 기반 시스템, 특히 자율주행 자동차에 탑재되는 딥 뉴럴 네트워크(DNN)는 카메라, LiDAR, 적외선 센서 등에서 쏟아지는 방대한 데이터를 처리한다. 이러한 센서 데이터는 고차원의 텐서 형태로 표현되며, 조명, 날씨, 도로의 물리적 상태 등 수많은 환경 변수가 복합적으로 작용하여 입력 공간을 형성한다. “DeepTest: Automated Testing of Deep-Neural-Network-driven Autonomous Cars” 논문에 따르면, 이러한 환경적 변수들의 조합은 인간이 수동으로 테스트 케이스를 설계하거나 모든 시나리오를 수집하기에는 “금지된 수준의 비용(Prohibitively expensive)“을 발생시킨다.

입력 공간 특성 비교	전통적 소프트웨어 (Software 1.0)	AI 기반 소프트웨어 (Software 2.0)
데이터 구조	정형화된 스키마, 명시적 규칙	비정형 데이터 (텍스트, 이미지, 오디오)
입력 차원	저차원 (Discrete variables)	고차원 (High-dimensional tensors)
가변성 원천	사용자 입력 및 시스템 설정	자연 환경의 물리적 변수, 언어적 뉘앙스
테스트 설계 전략	논리 경로 및 경계값 기반 검증	데이터 분포 및 변형 기반 탐색
결정론적 특성	입력 $x$ 에 대해 항상 $y$ 보장	입력 $x$ 에 대해 확률적 결과 $P(y \vert x)$ 제공

이러한 고차원 입력 공간에서는 전통적인 코드 커버리지 지표가 무용지물이 된다. 소스 코드의 분기문(if-else)을 얼마나 통과했는지는 모델 내부의 가중치(Weights)와 활성화 함수 간의 복잡한 상호작용을 전혀 설명하지 못하기 때문이다. 결과적으로 테스트 설계자는 논리적 경로가 아닌, 모델이 학습한 데이터 분포 내의 취약 지점을 찾아내야 하는 과제를 떠안게 된다.

1.2 프롬프트웨어(Promptware)와 언어적 모호성

LLM 기반 소프트웨어인 ’프롬프트웨어’의 등장은 입력 공간의 무한성을 더욱 심화시켰다. 이제 개발자나 사용자는 자연어를 통해 모델의 동작을 제어하며, 이는 고정된 구문(Syntax)이 없는 프로그래밍 인터페이스를 의미한다. 인간의 언어는 동일한 의도를 전달하더라도 단어의 선택, 문장 구조, 감정적 톤 등에 따라 무수히 많은 변종이 존재한다.

이러한 특성으로 인해 발생하는 ’프롬프트 민감도(Prompt Sensitivity)’는 테스트 케이스 설계의 난이도를 폭발적으로 증가시킨다. “PromptSE (Prompt Sensitivity Evaluation)” 연구에 따르면, 의미론적으로 동일한 요구사항을 담은 프롬프트라 할지라도 표현 방식에 따라 모델의 정확도가 45% 이상 요동치는 현상이 관찰되었다. 이는 단일 테스트 케이스의 성공이 시스템의 신뢰성을 보장하지 못한다는 것을 뜻하며, 테스트 설계 시 하나의 질문이 아니라 질문의 ‘의미론적 이웃(Semantic Neighborhood)’ 전체를 검증 범위로 설정해야 함을 시사한다.

2. 프롬프트 민감도의 수리적 모델링과 검증 지표

무한한 자연어 입력 공간에서 모델의 안정성을 평가하기 위해서는 정량적인 지표가 필수적이다. 최근 연구들은 프롬프트의 미세한 변화가 출력에 미치는 영향을 측정하기 위해 다양한 수학적 프레임워크를 제시하고 있다.

2.1 PromptSensiScore(PSS)를 통한 안정성 측정

“ProSA: Assessing and Understanding the Prompt Sensitivity of LLMs” 프레임워크는 인스턴스 레벨에서 프롬프트 민감도를 측정하는 PromptSensiScore (PSS)를 제안하였다. 특정 인스턴스(요구사항) $i$ 에 대해 생성된 $n$ 개의 프롬프트 변종 세트를 $P = {p_1, p_2, \dots, p_n}$ 이라 하고, 각 프롬프트에 대한 모델의 성능 지표(예: 정확도, 품질 점수)를 $Y(p)$ 라고 할 때, 인스턴스 $i$ 의 민감도 $S_i$ 는 다음과 같이 정의된다.
$S_i = \frac{\sum_{j < k} \vert Y(p_j) - Y(p_k) \vert}{C(n, 2)}$
여기서 $C(n, 2)$ 는 가능한 모든 프롬프트 쌍의 조합 수이다. 전체 시스템의 민감도인 $PSS$ 는 모든 테스트 인스턴스에 대한 $S_i$ 의 평균으로 계산된다. 이러한 수식은 테스트 설계자가 단순히 ’성공/실패’를 기록하는 것을 넘어, 입력값의 작은 섭동(Perturbation)에 대해 모델이 얼마나 일관된 출력을 내놓는지 수치화할 수 있게 한다.

2.2 데이터셋 특성에 따른 민감도 변동

조사 결과에 따르면, AI 모델의 민감도는 작업의 성격에 따라 다르게 나타난다. 상식 퀴즈(CommonsenseQA)나 간단한 IT 트러블슈팅과 같이 지식 기반의 작업에서는 프롬프트 변화에 비교적 둔감하지만, 수학적 추론(MATH)이나 복잡한 코드 생성(HumanEval) 작업에서는 극도로 예민한 반응을 보인다. 이는 테스트 케이스를 설계할 때 작업의 복잡도에 따라 가중치를 달리해야 하며, 특히 추론 능력이 요구되는 영역에서는 훨씬 더 촘촘한 입력 변이 테스트가 필요함을 의미한다.

평가 벤치마크	작업 유형	프롬프트 민감도(PSS) 경향	비고
CommonsenseQA	일반 상식 지식	낮음 (Robust)	모델의 학습 데이터 내 분포가 넓음
ARC-Challenge	과학적 추론	중간	논리 구조에 따른 변동성 존재
MATH	고난도 수학	매우 높음 (Sensitive)	추론 단계의 미세한 변화가 결과 왜곡
HumanEval	파이썬 코드 생성	높음	문맥적 제약 조건에 민감하게 반응

3. 예측 불가능한 출력 공간과 오라클 문제의 심화

입력 공간의 무한함이 ’테스트 대상을 선정하는 어려움’을 야기한다면, 출력 공간의 예측 불가능성은 ’테스트 결과를 판정하는 어려움’을 야기한다. 이를 소프트웨어 공학에서는 오라클 문제(The Test Oracle Problem)라 칭하며, AI 시스템에서 이는 가장 해결하기 까다로운 기술적 난제로 꼽힌다.

3.1 비결정론적 출력의 기술적 근원

AI 모델, 특히 자기회귀적(Autoregressive) 생성 모델은 다음 토큰을 예측할 때 확률 분포에서 샘플링하는 과정을 거친다. Temperature나 Top-p와 같은 파라미터는 모델의 창의성을 높여주지만, 동시에 동일한 입력에 대해 매번 다른 결과를 내놓는 비결정성을 강화한다. 이러한 특성 때문에 전통적인 유닛 테스트의 assert 구문은 무력화된다.

출력 공간이 예측 불가능해지는 구체적인 이유는 다음과 같다.

환각(Hallucination) 현상: 모델이 존재하지 않는 사실을 그럴듯하게 지어내는 현상으로, 이는 단순한 오답보다 검증하기 훨씬 어렵다.
의미론적 다양성: 요약이나 번역 업무에서 정답은 하나가 아니며, 수많은 ’좋은 응답’이 존재한다. 이는 단순 텍스트 비교로는 정합성을 판단할 수 없음을 의미한다.
창발적 행동(Emergent Behavior): 프롬프트가 복잡해짐에 따라 모델이 의도하지 않은 논리 전개를 보이거나, 보안 가이드라인을 우회하는 등의 예측 불가능한 행태를 보일 수 있다.

3.2 오라클 부재 상황에서의 테스트 판정 기법

전통적인 정답지(Ground Truth)를 확보하기 어려운 상황에서 연구자들은 대안적인 오라클 설계 방안을 모색하고 있다.

메타모픽 오라클(Metamorphic Oracle): 입력 간의 관계를 통해 출력의 정당성을 부여하는 방식이다. 예를 들어, 입력 $x$ 에 대한 결과가 $y$ 라면, $x$ 를 소폭 변형한 $x'$ 에 대한 결과 $y'$ 도 $y$ 와 일정한 논리적 관계를 유지해야 한다는 원리다.
LLM-as-a-Judge: 고성능의 모델(예: GPT-4)을 평가자로 사용하여 생성된 응답의 품질을 다각도로 채점하게 한다. 이는 수치적 정확도뿐만 아니라 톤, 매너, 안전성 등을 포괄적으로 검증할 수 있게 한다.
실행 기반 검증(Execution-grounded Validation): 코드 생성과 같은 작업에서는 생성된 코드를 실제로 컴파일하거나 단위 테스트를 실행하여 ’동작 여부’를 오라클로 삼는다. ChatUniTest와 같은 프레임워크는 생성된 테스트 케이스를 실행하고 오류 메시지를 피드백하여 모델이 스스로 정답에 도달하도록 유도한다.

4. 메타모픽 테스팅: 무한 입력 공간을 탐사하는 항해술

무한에 가까운 입력 공간에서 효과적인 테스트 케이스를 설계하기 위한 실질적인 해법으로 메타모픽 테스팅(Metamorphic Testing, MT)이 주목받고 있다. MT는 개별 입력값에 대한 기대 출력값을 아는 대신, 입력값들의 ’관계’에 주목하여 시스템의 결함을 찾아낸다.

4.1 메타모픽 관계(Metamorphic Relation, MR)의 설계

메타모픽 관계는 시스템이 반드시 준수해야 하는 논리적 불변량(Invariant)을 정의한다. 이를 통해 테스트 설계자는 무한한 입력 공간에서 유의미한 변이(Variation)를 자동 생성할 수 있다.
$R_i(x_1, x_2) \implies R_o(f(x_1), f(x_2))$
위 수식은 입력 간에 관계 $R_i$ 가 성립할 때, 출력 간에도 관계 $R_o$ 가 반드시 성립해야 함을 의미한다. 주요 소프트웨어 도메인에서의 MR 적용 사례는 다음과 같다.

도메인	입력 변형 (Ri)	기대 출력 관계 (Ro)	적용 사례
자율주행 (CV)	이미지 회전, 조도 변경, 노이즈 추가	감지된 객체 종류 및 위치의 일관성 유지	`DeepTest` 프레임워크
감정 분석 (NLP)	형용사를 유의어로 교체 (예: Good $\to$ Nice)	감정 분류 결과(긍정/부정) 불변	`LLMORPH` 툴
수학 추론	숫자의 단위를 변경하거나 순서를 바꿈	수치 결과의 논리적 변환 결과 일치	산술 연산 검증
검색 엔진	쿼리에 제한적 키워드 추가 (Car $\to$ Electric Car)	검색 결과 수의 감소 또는 동일	정보 검색 모델의 정밀도 테스트

이러한 접근법은 테스트 엔지니어가 수천만 개의 입력 데이터를 일일이 레이블링할 필요 없이, 알고리즘적으로 생성된 변종들을 통해 모델의 취약점을 대량으로 발견할 수 있게 한다.

5. 아데버사리얼 테스트와 엣지 케이스의 설계 난이도

무한한 입력 공간의 끝자락에는 모델의 오작동을 의도적으로 유도하는 ’아데버사리얼 입력(Adversarial Inputs)’이 존재한다. 이는 단순히 자연스러운 변동성이 아니라, 모델의 가중치 분포에서 확률이 낮은 영역이나 결정 경계(Decision Boundary) 부근을 공략하는 정밀하게 설계된 데이터이다.

5.1 프롬프트 인젝션과 보안 테스트 설계

LLM 시스템에서는 ’프롬프트 인젝션(Prompt Injection)’이 가장 대표적인 위협이다. “이전의 모든 지시사항을 무시하라“와 같은 명령을 입력 프롬프트 중간에 삽입함으로써 모델의 내장 시스템 프롬프트를 무력화하고 민감한 정보를 유출하게 만들 수 있다. 이러한 보안 사고는 입력 공간이 자연어라는 비정형 형식을 취하고 있기 때문에 발생하며, 테스트 설계자는 공격자의 창의적인 파괴 기법을 모두 예측하여 방어용 테스트 케이스를 작성해야 하는 난관에 부딪힌다.

5.2 엣지 케이스의 예측 불가능성

전통적인 시스템에서 엣지 케이스는 정수형 오버플로우나 널 포인터 참조와 같이 물리적인 한계 지점에서 발생한다. 그러나 AI 시스템에서의 엣지 케이스는 ‘분포 외 데이터(Out-of-Distribution, OOD)’ 상황에서 발생한다. 모델이 학습 과정에서 한 번도 보지 못한 유형의 입력이 들어왔을 때, 모델은 “모른다“고 답하는 대신 매우 높은 확신을 가지고 “틀린 답“을 내놓는 경향이 있다. 이러한 ’알려지지 않은 미지(Unknown Unknowns)’를 테스트 케이스로 설계하는 것은 논리적으로 불가능에 가깝기에, 최근에는 생성형 AI를 활용하여 스스로의 취약점을 공격하는 ‘레드 티밍(Red Teaming)’ 기법이 대안으로 제시되고 있다.

6. 구조화된 출력을 통한 출력 공간의 제약과 검증 자동화

예측 불가능한 출력 공간을 관리하기 위해, 엔지니어들은 모델의 자유도를 제한하고 결정론적인 검증 도구와 결합하는 전략을 취한다. 이는 무한한 가능성의 영역을 유한한 논리의 영역으로 끌어내리는 시도이다.

6.1 형식 언어와 오토포멀라이제이션(Autoformalization)

수학적 증명이나 정밀한 로직 검증이 필요한 경우, 모델의 자연어 출력을 그대로 믿는 대신 이를 Isabelle/HOL, Lean, Coq와 같은 형식 언어로 변환하는 ‘오토포멀라이제이션’ 기법을 사용한다. 형식 언어로 작성된 출력물은 자동 정리 증명기(Automated Theorem Prover)나 컴파일러를 통해 구문론적 및 논리적 오류를 100% 확정적으로 잡아낼 수 있다. 이는 확률적 모델의 출력 뒤에 결정론적 오라클을 배치함으로써 전체 시스템의 신뢰도를 확보하는 구조이다.

6.2 JSON Schema 및 강제 구조화 출력

비즈니스 애플리케이션에서는 모델의 응답을 JSON 형식으로 강제하고, 이를 사전에 정의된 JSON Schema와 비교 검증한다. 만약 모델이 필수 필드를 누락하거나 잘못된 데이터 타입을 반환할 경우, 이를 즉각적인 테스트 실패로 간주하고 재시도 로직을 가동할 수 있다. 이러한 방식은 출력 공간의 형태를 고정함으로써 테스트 케이스 설계자가 검증해야 할 범위를 응답의 ’내용’에서 ’구조’로 좁혀주는 효과를 준다.

7. 결론: 새로운 테스팅 패러다임의 필요성

AI 기반 소프트웨어 개발에서 테스트 케이스 설계의 난이도가 급증한 것은 기술적 진보가 가져온 필연적인 결과이다. 무한에 가까운 입력 공간은 더 이상 인간의 수동 작업으로는 정복할 수 없으며, 예측 불가능한 출력 공간은 이진 논리 기반의 기존 QA 체계를 붕괴시켰다.

이러한 난제를 극복하기 위해 엔지니어링 조직은 다음과 같은 전략적 전환을 요구받는다. 첫째, 단일 입력-출력 쌍에 집착하는 테스트 설계에서 벗어나, 데이터의 분포와 변이 관계를 검증하는 메타모픽 테스팅과 아데버사리얼 테스팅으로 무게 중심을 옮겨야 한다. 둘째, 테스트 오라클을 사람이 직접 작성하는 대신, LLM 기반의 에이전트 시스템이나 형식 언어 검증기와 같이 자동화된 오라클 시스템을 구축하는 데 투자해야 한다. 셋째, 모델의 출력 결과뿐만 아니라 내부의 자신감(Confidence) 지표나 토큰 확률 분포를 모니터링하여, 시스템이 위험한 예측을 내놓을 가능성을 사전에 차단하는 방어적 설계가 병행되어야 한다.

결국 AI 시대의 소프트웨어 품질은 ’완벽한 정답’을 보장하는 것이 아니라, ’불확실성 속에서도 통제 가능한 위험 범위’를 얼마나 정교하게 설계하고 유지하느냐에 달려 있다. 무한한 입력과 예측 불가능한 출력이라는 거대한 파도 속에서, 엔지니어는 데이터 과학과 소프트웨어 공학의 경계를 넘나드는 새로운 품질 보증의 나침반을 마련해야 할 것이다.

8. 참고 자료

Understanding the Key Differences Between AI Systems and, https://www.perarduaconsulting.com/post/understanding-the-key-differences-between-ai-systems-and-traditional-software-applications
Software Engineering for LLM Prompt Development - arXiv, https://arxiv.org/html/2503.02400v1
Challenges in Testing Large Language Model Based Software - arXiv, https://arxiv.org/html/2503.00481v2
AI vs Traditional Analytics: Which Is Right for You? - TechClass, https://www.techclass.com/resources/learning-and-development-articles/ai-vs-traditional-analytics-choosing-right-path-for-your-organization
DeepTest: Automated Testing of Deep-Neural-Network … - arXiv, https://arxiv.org/abs/1708.08559
Testing AI Systems: Handling the Test Oracle Problem, https://dev.to/qa-leaders/testing-ai-systems-handling-the-test-oracle-problem-3038
ProSA: Assessing and Understanding the Prompt Sensitivity of LLMs, https://aclanthology.org/2024.findings-emnlp.108.pdf
Prompt Stability in Code LLMs: Measuring Sensitivity across Emotion, https://arxiv.org/html/2509.13680v1
ProSA: Assessing and Understanding the Prompt Sensitivity of LLMs, https://github.com/open-compass/ProSA
ProSA : framework to evaluate and understand Prompt Sensitivity of, https://medium.com/@techsachin/prosa-framework-to-evaluate-and-understand-prompt-sensitivity-of-llms-2e2cb3e013cb
Using Machine Learning to Generate Test Oracles - Gregory Gay, https://greg4cr.github.io/pdf/21oracleslr.pdf
Introducing Promptimize for Test-Driven Prompt Engineering | by, https://maximebeauchemin.medium.com/mastering-ai-powered-product-development-introducing-promptimize-for-test-driven-prompt-bffbbca91535
How to Red Team Your LLMs: AppSec Testing Strategies for Prompt, https://checkmarx.com/learn/how-to-red-team-your-llms-appsec-testing-strategies-for-prompt-injection-and-beyond/
Automated Metamorphic Testing of Large Language Models, https://valerio-terragni.github.io/assets/pdf/cho-ase-2025.pdf
What’s the Difference Between AI and Regular Computing?, https://www.rigb.org/explore-science/explore/blog/whats-difference-between-ai-and-regular-computing
Metamorphic Testing of Large Language Models for Natural … - arXiv, https://arxiv.org/html/2511.02108v1
What is Metamorphic Testing of AI? - testRigor, https://testrigor.com/blog/what-is-metamorphic-testing-of-ai/
LLM Testing: The Latest Techniques & Best Practices - Patronus AI, https://www.patronus.ai/llm-testing
Test Oracle Automation: LLM and Hybrid Methods - Emergent Mind, https://www.emergentmind.com/topics/test-oracle-automation
A Roadmap for Software Testing in Open-Collaborative and … - arXiv, https://arxiv.org/abs/2406.05438
Metamorphic and adversarial strategies for testing AI systems, https://www.ministryoftesting.com/articles/metamorphic-and-adversarial-strategies-for-testing-ai-systems
Metamorphic Testing of Large Language Models for Natural, https://valerio-terragni.github.io/assets/pdf/cho-icsme-2025.pdf
Metamorphic Testing of Machine-Learning Based Systems - Medium, https://medium.com/data-science/metamorphic-testing-of-machine-learning-based-systems-e1fe13baf048
Formalizing Complex Mathematical Statements with LLMs - arXiv, https://arxiv.org/html/2502.12065v1
Assessing LLMs on Real-World Mathematical Definitions, https://aclanthology.org/2025.emnlp-main.90.pdf
Thinking Machines: Mathematical Reasoning in the Age of LLMs, https://www.mdpi.com/2504-2289/10/1/38
Towards a Mathematics Formalisation Assistant using Large, https://openreview.net/forum?id=pKu077C57fH
AI-Powered Testing vs Traditional Automation Testing: Why the Shift, https://qualizeal.com/ai-powered-testing-vs-traditional-automation-testing-why-the-shift-is-inevitable/