4.11.3 다음 장(유닛 테스트)으로의 연결: 프롬프트가 곧 테스트 코드다

본 장을 통해 우리는 하이퍼파라미터 제어(Temperature=0, Seed)부터 퓨샷(Few-shot) 예제의 투입, 추론 과정의 강제(CoT)에 이르기까지, 거대 언어 모델(LLM)이 지닌 확률론적 발산(Divergence)을 시스템 아키텍처 내부에서 최대한 수렴(Convergence)시키고 억압하는 프롬프트 엔지니어링 전략을 논의했다. 이러한 정밀 제어의 본질적인 목적은 단 하나, 바로 “다음 번 호출 시에도 똑같은 로직과 형태의 응답을 반환할 것“이라는 **일관성(Consistency)**의 확보에 있다.

그러나 아무리 프롬프트를 공학적으로 조판하고 모든 임의성을 차단했다 하더라도, AI 모델 자체를 ’완벽하게 제어된 블랙박스’로 간주할 수는 없다. API 제공자의 백그라운드 모델 가중치 업데이트, 컨텍스트 윈도우(Context Window) 한계점 도달, 또는 예상치 못한 예외적 프롬프트 주입(Prompt Injection) 시도로 인해 예측 불가능한 돌연변이(Mutation) 응답은 언제든 우리의 파이프라인을 뚫고 나올 수 있다.

이 지점에서 전통적인 소프트웨어 공학과 AI 엔지니어링 간의 철학적 교차가 발생한다. 우리가 시스템 프롬프트(System Prompt)에 “반드시 JSON 포맷으로 응답하라”, “수치 데이터를 포함하라“고 지시했다면, 이 프롬프트는 단순한 ’요구사항 명세서’를 넘어 시스템이 반드시 통과해야 하는 **‘테스트 코드(Test Code)의 서술적 형태’**로 취급되어야 한다.

• 프롬프트가 “주민등록번호 패턴을 검열하라“고 지시했다면, 우리는 후속 파이프라인에서 응답에 주민등록번호가 없는지를 기계적으로 증명(Assert)해야 한다.
• 프롬프트에 2개의 Expected Output 예제(Few-shot)를 주입했다면, 이 예제들은 파이프라인의 **골든 데이터셋(Golden Dataset)**으로 즉각 승격되어야 한다.

본 장에서 다져놓은 ’일관된 출력 구조’라는 토대가 없다면, 다음 장에서 다룰 결정론적 유닛 테스트(Unit Test) 오라클은 성립할 수 없다. 출력이 매번 요동친다면 Assert 구문은 모든 케이스마다 Fail을 뱉어낼 것이기 때문이다.

이제 우리는 AI가 반환한 일관되지만 본질적으로 불완전한 결과물을 낚아채어, T/F(True/False)로 명확히 판별되는 O(1)의 확정적 파이프라인으로 넘길 준비가 되었다. 다음 장에서는 프롬프트가 선언한 약속(Contract)을 코드가 어떻게 엄격하게 검증해 내는지, **‘유닛 테스트 기반의 확정적 검증 오라클 구축 기법’**을 본격적으로 해부한다.