Skip to main content
시뮬레이션 은 변경이 작동하는지 아는 방법 — 프로덕션 트래픽을 먼저 가리키지 않고. 데이터셋과 제안된 변경을 주면 모든 예시에 대해 변경 실행, 각각 점수, 델타 표시.

두 큰 유스케이스

  1. 배포 방어 — 모든 Flow 변경이 회귀 데이터셋에 실행. 시뮬레이션 실패면 배포 차단.
  2. 개선 비교 — 두 후보 수정, 한 데이터셋, 나란히. 승자 선택.

시뮬레이션이 실행하는 것

무엇이든:
  • Flow 버전 — 전체 워크플로우, 엔드투엔드.
  • Draft 상태 — 언퍼블리시 변경.
  • 개선 후보 — 개선 플로우에서 온 제안.
  • 임의 변형 — 예: “같은 Flow 지만 모델 X 로”.
모든 것이 선택한 데이터셋에 실행. 결과는 저장·비교·버전 관리됨.

얻는 것

시뮬레이션 실행

앱이나 CLI 에서 킥오프.

Before/after

현재 버전과 나란히 비교.

비용 vs. 품질

트레이드오프 프론티어 — 작은 모델이지만 낮은 품질?

회귀 체크

변경이 예전에 동작하던 걸 깼나?

베이스라인

비교할 참조로 버전 고정.

속도와 비용

시뮬레이션은 데이터셋 예시당 하나의 Agent 실행, 병렬로. 속도:
  • 빠른 모델에 50 예시: ~30-60초.
  • 500 예시: 5-10분.
  • 5000 예시: 30-60분.
비용은 실제 — 모든 시뮬레이션 실행이 Agent 가 프로덕션에서 드는 만큼 비용. 예산 맞게, 반복 중에는 작은 dev 데이터셋 선호, 최종 검증에는 큰 프로덕션 데이터셋. 시뮬레이션 뷰가 진행 여부 결정할 수 있도록 전체 비용을 미리 표시.

시뮬레이션이 충분하지 않을 때

시뮬레이션은 알려진 기대 출력의 알려진 예시에 실행. 할 수 없는 것:
  • 트래픽 (안 본 인텐트) 이 어떻게 착지할지 예측.
  • 깊은 사람 판단 필요한 품질 이슈 잡기.
  • 여러 Agent 가 서로 말하는 상호작용 모델링.
이것들에는 더 작은 인구 canary 메커니즘 사용 (버전 참고): 실제 트래픽의 작은 % 에 먼저 배포, 시그널 관찰, 그 다음 100% 로 롤아웃.