> ## Documentation Index
> Fetch the complete documentation index at: https://docs.nora.my/llms.txt
> Use this file to discover all available pages before exploring further.
# 시뮬레이션 개요
> 변경을 프로덕션에 내보내기 전에 데이터로 먼저 돌려봅니다
**시뮬레이션**은 변경이 잘 되는지 미리 확인하는 방법입니다. 프로덕션 트래픽을 먼저 태우지 않고도 확인할 수 있습니다. 데이터셋과 바꾸려는 내용을 주면, 모든 예시에 그 변경을 돌려서 하나하나 점수를 매기고 얼마나 달라졌는지 보여줍니다.
## 크게 두 가지로 씁니다
1. **배포를 지킵니다.** 모든 Flow 변경을 회귀 데이터셋에 돌립니다. 시뮬레이션이 실패하면 배포를 막습니다.
2. **개선안을 비교합니다.** 후보 수정 두 개를 같은 데이터셋에 나란히 놓고 돌려서 이긴 쪽을 고릅니다.
## 무엇을 돌릴 수 있나
다음 중 무엇이든 됩니다.
* **Flow 버전** 전체 워크플로우를 처음부터 끝까지.
* **Draft 상태** 아직 퍼블리시하지 않은 변경.
* **개선 후보** 개선 플로우가 내놓은 제안.
* **임의 변형** 예를 들어 "같은 Flow 인데 모델만 X로".
모두 여러분이 고른 데이터셋에 돌아갑니다. 결과는 저장되고, 서로 비교되며, 버전으로 남습니다.
## 무엇을 얻나
앱이나 CLI에서 바로 시작합니다.
현재 버전과 나란히 비교합니다.
작은 모델을 쓰면 품질은 얼마나 떨어지는지, 그 맞교환을 봅니다.
변경이 예전에 잘 되던 걸 깨뜨렸는지 봅니다.
비교 기준이 될 버전을 고정합니다.
## 속도와 비용
시뮬레이션은 데이터셋 예시 하나마다 Agent를 한 번씩, 병렬로 돌립니다. 걸리는 시간은 대략 이렇습니다.
* 빠른 모델로 예시 50개면 30초에서 1분.
* 500개면 5분에서 10분.
* 5000개면 30분에서 1시간.
비용도 실제로 나갑니다. 시뮬레이션 한 번은 그 Agent가 프로덕션에서 드는 만큼 돈이 듭니다. 그러니 예산을 감안해서, 반복하는 동안에는 작은 dev 데이터셋을 쓰고 마지막 검증에만 큰 프로덕션 데이터셋을 쓰는 편이 좋습니다. 시뮬레이션 화면이 전체 비용을 미리 알려주니, 돌릴지 말지 보고 정하면 됩니다.
## 시뮬레이션으로 부족할 때
시뮬레이션은 기대 출력이 이미 정해진 예시에만 돌아갑니다. 그래서 다음은 못 합니다.
* 처음 보는 트래픽, 즉 안 겪어 본 의도가 어떻게 나올지 예측하기.
* 사람이 깊이 판단해야 하는 품질 문제 잡기.
* 여러 Agent가 서로 대화하는 상호작용을 재현하기.
이런 건 더 좁은 범위에 먼저 내보내는 **canary** 방식으로 확인합니다([버전](/ko/reliable/versions/publish) 참고). 실제 트래픽의 일부에만 먼저 배포하고 신호를 지켜본 다음, 괜찮으면 100% 로 넓힙니다.