온라인 vs 오프라인 LLM 평가: 무엇이 필요하고, 언제 필요한가

온라인 vs 오프라인 LLM 평가: 무엇이 필요하고, 언제 필요한가

온라인 vs 오프라인 LLM 평가는 두 가지 결정이 아니라 하나의 결정입니다. 지난주 화요일에 저희 promptfoo 스위트가 그걸 증명해 줬거든요. 시스템 프롬프트를 한 번 고쳤더니, 테스트 케이스 47개에서 충실도(faithfulness)가 0.91에서 0.74로 떨어졌습니다. CI 시간으로 약 90초 만에 일어난 일이었죠. 오프라인 체크가 머지 전에 그 회귀를 잡아냈습니다. 프로덕션 모니터링이었다면 한참 뒤에, 고객 지원 스레드라는 모습으로 만났을 겁니다. 오프라인이든 온라인이든 결론은 같습니다. 두 차선, 다른 역할입니다.

오프라인 LLM 평가는 배포 전에 고정된 데이터셋으로 모델을 실행해, 변경 사항이 측정된 품질을 깨뜨리지 않았음을 증명합니다. 온라인 평가는 출시 후에 실제 프로덕션 트래픽을 채점해, 데이터셋에 애초에 들어 있지 않던 문제를 드러냅니다. 대부분의 팀은 둘 다 필요하고, 순서가 중요합니다. 오프라인이 배포를 막고, 온라인이 드리프트를 잡습니다.

핵심 요약

• 오프라인 평가는 배포 전에 고정 데이터셋으로 실행되고, 온라인 평가는 출시 후에 실제 트래픽을 채점합니다.
• 대부분의 팀은 둘 다 필요합니다. 오프라인은 배포를 막고, 온라인은 데이터셋이 놓친 것을 잡습니다.
• 오프라인은 프롬프트 회귀와 포맷 깨짐을 잡고, 온라인은 드리프트, 부하 시 레이턴시, 연동 특이 사항을 잡습니다.
• 오프라인 평가는 CI 머지 게이트로 연결하고, 온라인 점수는 프로덕션 트레이스에서 평가 세트로 흘려보내세요.

온라인 평가와 오프라인 평가는 실제로 어떻게 다른가? (9가지 차원)

두 모드는 아홉 가지 축에서 다르지만, 결정적인 차이는 데이터 소스입니다. 오프라인 평가는 배포 전에 고정된, 버전 관리되는 데이터셋을 채점하고, 온라인 평가는 출시 후에 실제 트래픽을 채점합니다. 비용, 레이턴시, 리스크, 거버넌스 등 나머지 차이는 전부 이 갈라짐에서 따라옵니다.

Label Studio의 러닝 센터는 이 둘을 경쟁 관계가 아니라 상호 보완적인 모드로 규정하는데, 저희도 동의합니다. 아래 표는 그 관점을 LLM 특화 지표까지 확장한 것입니다. 그들의 일반적인 ML 버전에는 없는 내용이죠.

저희 해석은 이렇습니다. 오프라인 열은 "이 변경이 무언가를 깨뜨렸나?"에 답하고, 온라인 열은 "프로덕션이 우리가 테스트한 것에서 벗어나고 있나?"에 답합니다. 두 모드가 가장 크게 벌어지는 행은 지표 유형 행입니다. 각 지표의 세부 내용은 LLM 평가 지표 가이드에서 풀었습니다.

각 모드는 무엇을 잡고, 무엇이 둘 다 빠져나가는가?

각 모드는 상대가 볼 수 없는 자기만의 실패 유형을 담당합니다. 오프라인은 우리가 만든 변화를 잡고, 온라인은 세상 쪽에서 우리 주변에 만든 변화를 잡습니다. 둘 다 비싸게 치르는 실패, 즉 두 그물을 모두 통과하는 실패에는 사람 리뷰어가 필요합니다. 이 분류는 각 모드가 보고하는 내용을 저희가 종합한 것이지, 공개된 표준은 아닙니다.

오프라인 전용 사분면이 CI 게이트가 제값을 하는 곳입니다. 포맷 준수율을 99%에서 91%로 조용히 떨어뜨리는 프롬프트 재작성은 코드 리뷰에서는 보이지 않지만, 47개 케이스 스위트에서는 명백합니다. 온라인 전용 사분면은 더 교묘합니다. 실제 사용자는 골든 세트에 없던 표현을 쓰고, 서드파티 API는 스테이징에서는 절대 안 걸리는 타이밍에 타임아웃을 내며, 누군가는 그냥 무슨 일이 일어나는지 보려고 챗봇에 40,000자 프롬프트를 집어넣습니다. 그쪽에는 프로덕션 에이전트 평가 가이드가 있습니다. 단일 출력이 아니라 다단계 궤적을 채점하는 방법을 다룹니다.

마지막 행이 팀들이 건너뛰는 행이고, 그래서 데이는 행입니다. 사용자를 잃게 만드는 실패는 어느 한 모드만으로는 잡히지 않는 실패입니다. 루프 안에 사람이 필요합니다.

오프라인 평가는 CI 게이트로 어떻게 연결하는가? (아무도 안 보여주는 설정)

프롬프트, 모델, 검색 설정을 건드리는 모든 풀 리퀘스트에 평가 러너를 필수 상태 체크로 추가하세요. 임계값을 단언하고, 그 아래면 머지를 막으세요. promptfoo 문서가 바로 이 CI 패턴을 다루고 있고, 저희가 운영하는 것도 이것입니다.

GitHub Actions 스텝

저희가 지금 돌리는 게이트의 축약 버전입니다.

name: llm-eval-gate

on:
  pull_request:
    paths: ["prompts/**", "evals/**", "src/rag/**"]

jobs:
  faithfulness-gate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      - name: Run offline evals, fail the PR on regression
        run: npx promptfoo@latest eval --config evals/support-agent.yaml
        env:
          OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}  # LLM-as-judge

YAML 설정이 테스트 케이스와 어설션을 선언합니다. 스위트가 임계값 아래로 떨어지면 eval이 0이 아닌 코드로 종료되고, GitHub는 필수 체크를 실패로 표시하며, 머지 버튼은 비활성화됩니다. paths 필터가 중요합니다. README 수정이 저지 토큰을 태워서는 안 되니까요.

게이트가 실제로 잡아내는 것

실제 운영 버전은 프롬프트에 영향을 주는 모든 PR에서 저희 지원 에이전트 RAG 체인을 47개 골든 케이스로 채점합니다. 전체 실행은 CI 시간으로 약 90초 걸리고, 충실도가 0.82 아래로 떨어지면 머지가 자동으로 차단됩니다. 3개월 동안, 이 게이트는 그대로 배포되었을 회귀를 두 건 잡아냈습니다. 충실도를 0.91에서 0.74로 끌어내린 시스템 프롬프트 재작성 하나, 그리고 컨텍스트 길이를 두 배로 늘려 답변 관련성을 임계값 아래로 떨어뜨린 리트리버 변경 하나였습니다. 둘 다 리뷰에서는 위험해 보이지 않았습니다.

CI의 충실도 게이트는 PR당 90초입니다. 프로덕션의 충실도 회귀는 고객 지원 스레드 한 건과 롤백 하나입니다.

이 패턴에 끼울 수 있는 러너들, promptfoo, DeepEval 등을 LLM 평가 도구 라운드업에서 비교했습니다.

어떤 도구가 어떤 모드를 돌리는가? (도구-모드 매트릭스)

두 차선을 모두 깔끔하게 담당하는 단일 도구는 없습니다. promptfoo와 DeepEval은 오프라인 우선 러너로, 내보낸 프로덕션 데이터를 스케줄에 따라 채점할 수 있습니다. Langfuse와 LangSmith는 온라인 우선 트레이스 저장소로, 수집한 트레이스에 LLM-as-judge 스코어를 덧붙입니다. 이 매트릭스는 각 벤더 문서를 읽은 저희 해석이지, 복음이 아닙니다.

첫 필요가 CI에서 나쁜 프롬프트를 막는 머지 게이트라면 promptfoo나 DeepEval을 고르세요. 첫 필요가 실제 트래픽 채점이라면 Langfuse나 LangSmith를 고르세요. 그 선택은 Langfuse vs LangSmith 비교에서 깊게 다뤘습니다. OpenAI Evals는 여전히 이단아입니다. 레지스트리 스타일의 오프라인 러너이고 프로덕션 쪽은 없습니다.

promptfoo는 PR을 막고, Langfuse는 프로덕션 트레이스를 채점합니다. 어느 쪽도 다른 쪽을 대체하지 못합니다.

피드백 루프는 온라인 실패를 어떻게 오프라인 테스트로 바꾸는가?

점수가 낮은 프로덕션 트레이스를 샘플링하고, 라벨링해서 오프라인 평가 세트에 커밋하세요. 그러면 회귀 스위트는 프로덕션이 던지는 모든 놀라움과 함께 자라고, 다음 배포는 확장된 세트로 게이트됩니다. 플라이휠이라는 프레이밍은 저희 것인데, 대부분의 팀이 절대 만들지 않는 부분이기도 합니다.

저희가 운영하는 사이클은 이렇습니다.

1. 온라인 스코어러가 저지 점수 0.7 미만 트레이스에 플래그를 겁니다.
2. 매주 플래그 걸린 트레이스를 20~30개 샘플링합니다.
3. 사람이 각 트레이스에 라벨을 붙입니다. 기대 출력과 실패 유형입니다.
4. 라벨링된 케이스가 새 골든 예제로 오프라인 평가 세트에 들어갑니다.
5. 다음 PR은 확장된 스위트로 실행되고, 루프가 다시 시작됩니다.

샘플링은 LLM 옵저버빌리티 계층에서 시작합니다. 트레이스가 원재료니까요. 주기 관련해서, 주간이 월간을 이깁니다. 드리프트는 복리로 쌓이니까요. 저희는 매주 1015개 케이스에 라벨을 붙이고, 새 라벨이 통과율을 더 이상 움직이지 않을 때 세트가 "충분히 크다"고 봅니다. 좁은 지원 에이전트 기준으로 150250개 정도입니다. 모드 사이의 경계는 계속 흐려지고 있습니다. Deepchecks가 보고한 대로, Union.ai 엔지니어들은 "오프라인" 평가를 몇 분 간격으로 스케줄해 사실상 준실시간 체크로 만들었습니다.

평가 세트는 고정된 산출물이 아닙니다. 프로덕션이 여러분을 놀라게 할 때마다 매주 자랍니다.

둘 다 필요한 시점은? (단계별 온라인 vs 오프라인 LLM 평가)

출시 주간부터 둘 다 필요하지만, 균형은 단계마다 바뀝니다. 오프라인은 배포 전 작업을 혼자 맡고, 출시 주간에는 섀도 또는 카나리 채점을 더하고, 안정기에는 온라인 모니터링을 중심으로 주기적 오프라인 재실행을 곁들이고, 드리프트 알림은 재현된 오프라인 테스트와 더 커진 평가 세트로 끝나야 합니다.

배포 전은 엄격하게 굴기에 가장 싼 곳입니다. 차단된 머지는 수 분이면 되지만, 나쁜 릴리스는 신뢰를 잃습니다. 출시 주간은 팀들이 투자를 덜 하는 곳인데, 작은 트래픽 슬라이스에 대한 섀도 채점은 비용이 거의 들지 않으면서 골든 세트가 거짓말을 했는지 드러냅니다. 안정기는 안주가 스며드는 곳이니, 재평가는 캘린더에 박아두세요.

EU AI Act는?

EU AI Act의 고위험 의무는 2026년 8월까지 단계적으로 적용되고, 전체 마감 일정은 EUR-Lex에 공개되어 있습니다. 그리고 적합성 패턴은 두 모드에 깔끔하게 대응합니다. 문서화된 오프라인 증거는 시스템이 출시 전에 품질 목표를 충족했음을 보여주고, 지속적 온라인 모니터링은 출시 후에도 계속 충족함을 보여줍니다. 저희 해석으로는 감사 추적에 두 산출물이 다 필요합니다. 오프라인 로그만으로는 시스템이 계속 규정을 지켰는지 증명되지 않고, 대시보드만으로는 출시 시점에 규정을 지켰는지 증명되지 않으니까요. 이것은 해석이지 법률 자문이 아닙니다. 전체 요구사항 세트는 LLM 평가 파이프라인 필러에서 정리했습니다.

오프라인 평가는 증거이고, 온라인 평가는 조기 경보 시스템입니다. 규제 당국은 둘 다 원합니다.

저자 소개: Mert Batur는 Techsy.io의 공동 창업자로, 팀은 B2B 고객을 위해 AI 에이전트, 자동화 시스템, 보이스/SDR 파이프라인을 구축합니다. Techsy 팀이 실제로 프로덕션에서 사용하는 LLM 도구 스택에 대해 씁니다. LinkedIn에서 연결하세요.

자주 묻는 질문

오프라인 LLM 평가란 무엇인가요?

오프라인 LLM 평가는 배포 전에 모델이나 프롬프트를 고정된, 버전 관리되는 데이터셋으로 실행하는 것입니다. 일반적인 체크에는 검색된 컨텍스트에 대한 충실도, 답변 관련성, 포맷 준수, 벤치마크 점수가 포함됩니다. 데이터셋이 실행 도중에 바뀌지 않기 때문에 결과는 재현 가능하고 diff가 가능하며, 바로 그 이유 때문에 오프라인 스위트가 CI 머지 게이트로 작동합니다.

온라인 LLM 평가란 무엇인가요?

온라인 LLM 평가는 출시 후에 실제 프로덕션 트래픽을 채점하는 것입니다. LLM-as-judge 스코어러가 샘플링된 트레이스의 환각, 톤, 도구 호출 정확성을 평가하고, 점수는 대시보드로 스트리밍됩니다. 오프라인 테스트가 볼 수 없는 신호도 흡수합니다. 부하 시 레이턴시, 사용자 피드백, 그리고 실제 쿼리가 골든 세트와 어떻게 다른지요.

오프라인 vs 온라인 LLM 평가, 언제 무엇을 써야 하나요?

배포를 막는 데는 오프라인 평가를 쓰세요. 모든 프롬프트, 모델, 검색 변경은 머지 전에 스위트를 통과해야 합니다. 배포된 것을 모니터링하는 데는 온라인 평가를 쓰세요. 대부분의 팀은 하나를 고르기보다 둘을 순서대로 씁니다. 먼저 오프라인, 출시 주간부터 온라인, 그리고 프로덕션 실패는 오프라인 세트로 되돌립니다.

온라인 vs 오프라인 LLM 평가의 예시는?

오프라인 예시: promptfoo 스위트가 모든 풀 리퀘스트에서 200개 골든 지원 질문을 실행하고, 충실도가 0.82 아래로 떨어지면 머지를 차단합니다. 온라인 예시: Langfuse가 실제 트레이스의 10%를 LLM-as-judge 환각 체크로 채점하고 주간 평균이 미끄러지면 알림을 보냅니다. 같은 루브릭, 다른 데이터 소스입니다.

휴먼인더루프는 LLM 평가에 어떻게 들어가나요?

사람은 어느 모드도 커버하지 못하는 격차를 메웁니다. 새로운 엣지 케이스, 주관적 품질 판단, 브랜드 보이스 드리프트입니다. 실용적인 주기는 매주 샘플링된 저점 트레이스 10~20개에 라벨을 붙여 오프라인 평가 세트에 커밋하는 것입니다. 리뷰 큐는 부업이 아니라 파이프라인 입력입니다.

온라인 채점에서 Langfuse 평가는 어떻게 작동하나요?

Langfuse는 애플리케이션에서 트레이스를 수집한 뒤, 각 트레이스를 루브릭으로 채점하는 LLM-as-judge 평가자를 붙입니다. 환각, 관련성, 유해성, 또는 커스텀 프롬프트입니다. 점수는 세션과 사용자 키로 대시보드에 쌓입니다. 팀은 지속적으로 점수가 낮은 트레이스를 오프라인 데이터셋으로 내보내 회귀 테스트에 씁니다. 이 패턴에 공급되는 트레이스 저장소는 옵저버빌리티 플랫폼 라운드업에서 비교했습니다.

오프라인 평가는 CI/CD 파이프라인에 어떻게 추가하나요?

프롬프트, 모델, 검색 설정을 건드리는 풀 리퀘스트에 평가 러너를 필수 상태 체크로 추가하세요. promptfoo와 DeepEval 둘 다 헤드리스로 실행되고 어설션 실패 시 0이 아닌 코드로 종료되어 머지를 자동으로 차단합니다. 이 글 앞부분의 YAML 게이트가 작동하는 템플릿입니다. 30~50개 케이스로 시작하세요.

EU AI Act는 오프라인 평가와 온라인 평가 중 무엇을 요구하나요?

사실상 둘 다입니다. 고위험 시스템에 대해, 이 법은 출시 전에 품질 목표가 충족되었다는 문서화된 증거, 즉 오프라인 산출물을 기대하고, 배포 후 지속적 모니터링, 즉 온라인 텔레메트리를 기대합니다. EUR-Lex 기준 단계적 마감은 2026년 8월까지 이어집니다. 이것은 적합성 패턴에 대한 저희 해석이지 법률 자문이 아닙니다.

LLM-as-a-judge는 오프라인과 온라인 모드 둘 다에서 실행할 수 있나요?

예, 그리고 그래야 합니다. 루브릭이 그대로 옮겨지니까요. 오프라인에서는 저지가 CI 동안 평가 세트의 모든 출력을 배치로 채점합니다. 온라인에서는 같은 저지 프롬프트가 샘플링된 프로덕션 트레이스를 준실시간으로 채점합니다. 두 모드에서 하나의 루브릭을 유지해야 오프라인 베이스라인과 온라인 드리프트 신호가 비교 가능해집니다.

오프라인 평가와 온라인 평가 사이에 어떤 지표가 다른가요?

오프라인 지표는 그라운드 트루스 대비 출력 품질을 잽니다. 충실도, 답변 관련성, 포맷 준수, 벤치마크 점수입니다. 온라인 지표는 운영·행동 신호를 더합니다. p95 레이턴시, 오류율, 실제 트래픽의 환각률, 드리프트 점수, 사용자 만족도입니다. 오프라인 목록은 "좋은가?"를 묻고, 온라인 목록은 "여전히 좋은가?"를 묻습니다.

짧은 버전

• 오프라인 평가와 온라인 평가는 양자택일이 아니라 보완적인 차선입니다. 하나는 배포하는 것을 막고, 다른 하나는 배포된 것을 감시합니다.
• 이번 주에 CI 게이트부터 시작하고, 출시 시점에 온라인 트레이스 채점을 더하고, 평가 세트가 낡기 전에 피드백 루프를 연결하세요.
• 루프가 시스템입니다. 정적인 골든 데이터셋은 썩고, 자라는 데이터셋은 복리로 쌓입니다.

평가 파이프라인에 제2의 시선이 필요하다면, 무료 상담을 받아보세요.