당신은 그 화려한 LLM 기반 기능을 프로덕션(production)에 출시했습니다. 당신의 노트북에서는 잘 작동했습니다. 하지만 사용자들은 때때로 의미 없는 헛소리(gibberish)를 반환하고, 엣지 케이스(edge cases)에서 작동이 중단되며, 가끔 API 응답을 환각(hallucinate)한다고 보고합니다. 전형적인 상황이죠.

문제는 이겁니다. 모두가 AI를 마법처럼 취급한다는 것입니다. 때때로 작동하기 때문에 마법처럼 느껴집니다. 그래서 사람들은 테스트를 건너뜁니다. 하지만 AI 기능도 결국 코드이며, 코드에는 테스트가 필요합니다.

"나한테는 잘 되는데"의 문제점

일반적인 코드를 테스트할 때는 어떤 일이 일어날지 알고 있습니다:

• 입력 X로 함수를 호출하면 → 매번 출력 Y가 나옵니다.
• 부작용(side effects)을 예측할 수 있습니다.
• 정확성을 검증할 수 있습니다.

LLM 기능의 경우:

• 동일한 입력 → 매번 다른 출력 (온도(temperature), 무작위성(randomness))
• 환각(hallucinations)이 조용히 발생합니다.
• 모델이 스스로 "결정"하면 당신의 지침을 무시할 수도 있습니다.
• 실패 방식이 이상하고 일관성이 없습니다.

"일반적인" 기능의 테스트가 작동하는 이유는 컴퓨터가 결정론적(deterministic)이기 때문입니다. LLM은 그렇지 않습니다. 따라서 당신의 테스트 전략은 바뀌어야 합니다.

실제로 테스트해야 할 것들

1. 결정론적 입력(Deterministic inputs) → 결정론적 출력(deterministic outputs)

네, LLM은 무작위적입니다. 하지만 그것을 감싸고 있는 래퍼(wrapper)는 그렇지 않습니다. 다음 사항을 테스트하세요:

• 프롬프트 구성(prompt construction)이 제대로 작동하는지
• 올바른 변수를 전달하고 있는지
• 토큰 제한(token limits)이 중요한 부분을 잘라내지 않는지
• 온도(Temperature)/샘플링(sampling) 설정이 실제로 적용되는지

def build_summary_prompt(text, max_length):
    return f"Summarize this in {max_length} words:\n\n{text}"

...

2. 출력 파싱(Output parsing) 작동 여부

LLM은 텍스트를 반환합니다. 당신은 그것을 파싱(parse)합니다. 그 파싱 과정에서 오류가 발생할 것입니다.

# 나쁜 예: 유효한 JSON을 반환하기를 기도함
result = llm.generate(prompt)
data = json.loads(result)  # 가끔 충돌(crashes) 발생
...

3. 경계 사례(Boundary cases)

• 빈 입력(Empty input) → 어떤 일이 발생하나요?
• 매우 긴 입력 → 합리적으로 잘라내나요(truncate)?
• 특수 문자, 코드 샘플, URL → 프롬프트가 깨지나요?
• 영어가 아닌 언어 → 이를 처리하나요, 아니면 조용히 실패하나요?

사용자가 프로덕션에서 이를 마주하기 전에 테스트하세요.

4. 비용은 무한하지 않습니다

토큰 (Tokens)은 비용이 발생합니다. 만약 당신의 기능이 토큰을 낭비할 가능성이 있다면:

• API 호출 시 최대 토큰 제한 (max token limits)을 설정하세요
• 프로덕션 환경에서 토큰 사용량을 모니터링하세요
• 단 한 번의 요청에 대해 실수로 100번씩 재프롬프팅 (re-prompting)하고 있지는 않은지 테스트하세요

response = client.chat.completions.create(
    model="gpt-4",
    messages=messages,
...

실제로 테스트하기

세 가지 계층이 필요합니다:

계층 1: 모킹 (Mocking)
LLM을 알려진 출력을 반환하는 가짜 (fake)로 교체하세요. 모델이 아니라 당신의 코드 로직을 테스트하는 것입니다.

from unittest.mock import patch

@patch('openai.ChatCompletion.create')
...

계층 2: 실제 API를 사용한 통합 테스트 (저렴한 모델)
저렴한 모델(또는 로컬 모델)을 사용하여 가끔씩 실제 API를 호출하세요. 당신의 프롬프트가 실제 LLM에서 제대로 작동하는지 확인하세요.

계층 3: 스테이징 환경 (Staging environment)
프로덕션에 배포하기 전에: 저렴한 모델을 사용하여 실제 트래픽 패턴으로 기능을 실행해 보세요. 무엇이 고장 나는지 확인하세요.

Dev.to의 현실 점검

아마 이렇게 생각하고 계실 겁니다: "테스트할 시간이 없어요."

일리가 있습니다. 하지만 테스트되지 않은 AI 코드를 배포하는 것은 더 많은 시간을 낭비하게 만듭니다:

• 사용자들이 이상한 버그를 보고합니다
• 환각 (hallucinations) 현상을 디버깅하느라 몇 시간을 허비합니다
• 새벽 2시에 긴급 수정 사항 (hotfixes)을 배포합니다
• 신뢰를 잃습니다

테스트를 작성하는 데 30분을 쓰세요. 프로덕션의 혼란 속에서 8시간을 아낄 수 있습니다.

빠른 체크리스트

• 프롬프트 구성 테스트 완료 (변수가 올바르게 삽입되었는가)
• 출력 파싱 (Output parsing) 실패 처리 완료 (try/except가 존재하는가)
• 경계 사례 (Boundary cases) 테스트 완료 (빈 값, 긴 문장, 특수 문자 등)
• 토큰 제한 설정 완료 (실수로 무한 루프를 돌지 않는가)
• 모킹 (Mock) 테스트 존재 (LLM이 아닌 코드를 테스트하는가)
• 비용 모니터링 (루프 안에서 토큰을 태우고 있지는 않은가)
• 폴백 (Fallback) 동작 정의 (LLM이 실패할 경우 어떻게 할 것인가?)

그게 전부입니다. 화려할 필요는 없습니다. _실제적_이어야 합니다.

마지막으로 하나 더

이제 가서 당신의 기능들을 테스트하세요. 사용자들이 당신에게 고마워할 것입니다.

프로덕션에서 고장 난 AI 기능을 배포해 본 적이 있나요? 무엇을 놓쳤나요? 댓글로 남겨주세요. 서로의 실수로부터 함께 배워봅시다.