표준 RSpec 어설션(assertions)은 정확한 값을 기대합니다: expect(user.name).to eq("Alice").

LLM은 이러한 계약을 즉시 깨뜨립니다. Temperature 0.2에서 프롬프트를 세 번 실행하면, 세 가지 서로 다른 표현의 변형을 얻게 됩니다.

팀들이 Rails 앱에 AI 기능을 추가할 때, 보통 다음 두 가지 패턴 중 하나에 빠집니다:

• 모델이 유의어를 선택하거나 문장 구조를 바꿀 때마다 산산조각 나는 취약한 정규 표현식(regex) 어설션을 작성합니다.
• 로컬 bundle exec rspec 실행 및 CI 파이프라인과 완전히 단절된 채, 매주 배치 작업(batch jobs)을 실행하는 제3자 SaaS 대시보드에 평가(evals)를 떠넘깁니다.

둘 다 프로덕션 규모에서는 작동하지 않습니다. 단어 하나하나 일치하는 문자열 매칭 테스트는 잊으세요. AI 파이프라인이 무엇을 할 수 있고, 무엇을 해야 하며, 무엇을 해서는 안 되는지를 강제해야 합니다.

저는 Ruby와 Rails를 위해 이 문제를 해결하고자 **AISpec**을 만들었습니다. 이는 불변의 행동 계약(invariant behavioral contracts), 통계적 신뢰 구간(statistical confidence bounds), 그리고 네이티브 RSpec 어설션을 테스트 스위트에 도입하는 오픈 소스 gem입니다.

행동 불변성(Behavioral invariants) vs. 정적 텍스트 어설션(static text assertions)

전통적인 코드는 결정론적(deterministic) 공간에 존재합니다. LLM은 확률론적(probabilistically)으로 작동하지만, 제품의 제약 조건은 여전히 이진적(binary)입니다.

LLM 기능은 다음 두 가지 유형의 경계(bounds)를 충족해야 합니다:

                    ┌─────────────────────────────────────┐
                    │     LLM Application Constraints     │
                    └──────────────────┬──────────────────┘
...

결정론적 경계(Deterministic bounds)는 합격/불합격(pass/fail)입니다. 응답이 JSON 스키마(schema)와 일치하거나 일치하지 않거나 둘 중 하나입니다. 실행이 2,500ms 이내에 완료되었거나, 예산을 초과했거나. 앱이 process_refund 전에 fetch_account_status를 호출했거나, 시퀀스(sequence)에 실패했거나 하는 식입니다.

확률론적 경계(Probabilistic bounds)는 응답 품질을 평가합니다. LLM 심판(judge)은 출력이 제공된 컨텍스트(context)에 대해 사실 관계를 유지하는지, 또는 기대되는 톤(tone) 임계값에 도달하는지를 평가합니다.

AISpec은 이 두 가지를 단일 계약 파일 아래 통합합니다.

AISpec에서 행동 계약(behavioral contracts) 정의하기

계약(Contracts)은 코드베이스와 함께 YAML 파일에 존재합니다. 여기서 제공자(provider), 모델(model), 입력 데이터셋(input dataset), 그리고 불변 규칙(invariant rules)을 선언합니다.

다음은 고객 지원 봇을 위한 계약 예시(contracts/support.yml)입니다:

version: 1
name: support-bot

...

또한 인라인 단축 규칙(inline shorthand rules)을 사용할 수도 있습니다:

contracts:
  - must_return_valid_json
  - latency < 2500ms
...

터미널에서 aispec run contracts/support.yml을 실행하여 데이터셋을 실행하고 모든 규칙을 확인하세요:

$ aispec run contracts/support.yml

Running 12 contracts for support-bot (openai / gpt-4o)...
...

AISpec은 95% 신뢰 구간(confidence interval)의 Wilson score를 계산하고 실행 간의 분산(variance)을 추적합니다. 만약 작은 샘플 크기나 급격한 출력 변동이 신뢰성을 위협할 경우, AISpec은 잘못된 프롬프트 수정 사항이 프로덕션(production)에 반영되기 전에 불안정성을 표시(flag)합니다.

모델 간 벤치마킹 (Benchmarking across models)

gpt-4o에서 claude-3-5-sonnet 또는 로컬 llama3 인스턴스로 전환하는 것은 보통 추측에 의존하는 것처럼 느껴집니다. 모델 이름을 바꾸고, 몇 개의 수동 프롬프트를 실행한 뒤, 아무것도 망가지지 않기를 바랄 뿐입니다.

AISpec을 사용하면 단 한 번의 터미널 명령으로 정확한 계약 스위트(contract suite)에 대해 후보 모델들을 벤치마킹할 수 있습니다:

$ aispec compare gpt-4o claude-3-5-sonnet llama3

이를 통해 모델 선택은 주관적인 느낌(vibe checks)에서 명확한 지표(metrics)로 전환됩니다. 더 저렴하거나 오픈 웨이트(open-weights) 모델이 지연 시간 및 안전성 예산(safety budgets)을 충족하는지 즉시 확인할 수 있습니다.

Rails 통합 (Rails integration)

AI 평가(evals)를 위해 별도의 Python 툴체인(toolchain)이나 외부 대시보드가 필요해서는 안 됩니다. Rails 애플리케이션에서 행동 계약(behavioral contracts)은 spec/contracts/ 내부에 위치해야 합니다.

1. 초기화 도구(Initializer) 및 커스텀 단언(custom assertions)

config/initializers/aispec.rb에서 기본 제공자를 설정하고 커스텀 도메인 규칙을 등록하세요:

# config/initializers/aispec.rb
AISpec.configure do |config|
  config.default_provider = ENV.fetch("AISPEC_PROVIDER", "openai")
...

2. RSpec에서 컨트랙트(contracts) 실행하기

표준 RSpec 테스트 내부에서 YAML 컨트랙트(contracts)를 직접 실행하세요:

# spec/contracts/support_contract_spec.rb
require "rails_helper"

...

GitHub Actions를 통한 지속적 검증 (Continuous verification)

AISpec은 JSON, JUnit XML, Markdown 테이블을 출력하므로, GitHub Actions를 사용하여 모든 풀 리퀘스트(pull request)에서 컨트랙트 체크를 실행할 수 있습니다:

# .github/workflows/ai_contracts.yml
name: AI Behavioral Verification

...

풀 리퀘스트에서 누군가 프롬프트(prompt)를 수정하면, CI가 지연 시간(latency)이 급증했는지, 비용이 상승했는지, 또는 점수 범위(score bounds)를 벗어났는지를 보여주는 테이블과 함께 댓글을 남깁니다.

AI 도구는 코드 작성을 쉽게 만들지만, 시스템의 신뢰성(reliability)을 유지하는 것이 진정한 작업입니다.

명시적인 행동 경계(behavioral boundaries)가 없다면, 모든 프롬프트 변경은 리스크를 동반합니다. 스키마 체크(schema checks), 지연 시간 예산(latency budgets), 도구 시퀀스(tool sequences), 통계적 임계값(statistical thresholds)과 같은 불변 규칙(invariant rules)을 정의하면, 예측 불가능한 모델 출력(model outputs)을 신뢰할 수 있는 시스템 구성 요소로 바꿀 수 있습니다.

**GitHub의 AISpec**을 확인하거나 gem install aispec을 실행하여 Rails 애플리케이션에 행동 사양(behavioral specs)을 추가해 보세요.