# 상태 정리

워크플로가 여러 단계를 거치면 누적된 상태가 커질 수 있습니다. 상태 정리는 오래된 단계 출력을 자동으로 삭제해 중요한 데이터를 보존하면서 상태 JSON의 크기를 제한합니다.

## 상태 정리 활성화

워크플로 빌더에서 `prune_state_after()`을 호출하세요. 인수는 출력을 유지할 최근 단계의 수입니다:

```php
use Queuety\Queuety;

Queuety::workflow( 'long_pipeline' )
    ->then( StepA::class )
    ->then( StepB::class )
    ->then( StepC::class )
    ->then( StepD::class )
    ->then( StepE::class )
    ->prune_state_after( 2 )
    ->dispatch( [ 'input' => $data ] );
```

`prune_state_after( 2 )`을 사용하면 D 단계가 끝난 후 A 및 B 단계의 출력이 상태에서 제거됩니다. 최근 두 단계인 C와 D의 출력은 보존됩니다.

## 정리 작동 방식

상태 정리가 활성화되면 Queuety은 예약된 `_step_outputs` 배열에 각 단계가 상태에 추가하는 키를 기록합니다. 새 단계로 넘어간 뒤에는 기준보다 오래된 단계에서 추가된 키를 모두 삭제합니다.

예를 들어 `prune_state_after( 2 )`을 사용하면 다음과 같습니다:

```
After step 0 (StepA): state has keys from StepA + initial payload
After step 1 (StepB): state has keys from StepA + StepB + initial payload
After step 2 (StepC): state has keys from StepA + StepB + StepC + initial payload
  -> prune: StepA output removed (only 2 most recent kept)
After step 3 (StepD): state has keys from StepB + StepC + StepD + initial payload
  -> prune: StepB output removed
```

## 보존되는 항목

Queuety은 `_`로 시작하는 예약 키를 절대 정리하지 않습니다. 예를 들면 `_steps`, `_queue`, `_priority`, `_max_attempts`, `_on_cancel`, `_prune_state_after` 및 `_step_outputs`이 있습니다. `dispatch()`에 전달된 초기 페이로드 키도 처음부터 단계 출력으로 추적되지 않으므로 보존됩니다. 그 외에는 Queuety이 설정한 기준에 따라 최근 N개 단계의 출력을 유지합니다.

## 사용 시점

상태 정리는 각 단계가 이후 단계에서 실제로 필요하지 않은 데이터를 생성하는 긴 워크플로에 유용합니다. 일반적인 예로는 각 단계에서 직전 한두 단계의 출력만 필요한 긴 파이프라인, 대량의 중간 구조를 생성하는 ETL 워크플로, 반복되는 상태가 계속 쌓일 수 있는 재귀 또는 반복 워크플로가 있습니다. 단계가 몇 개뿐이거나 후반 단계에서 초기 출력을 계속 사용한다면 정리가 필요하지 않을 수 있습니다.

## 기본 동작

상태 정리는 기본적으로 비활성화되어 있습니다. `prune_state_after()` 메서드는 정수 인수를 받습니다. 인수 없이 호출하면 기본값은 2입니다:

```php
->prune_state_after()     // keeps the 2 most recent step outputs
->prune_state_after( 5 )  // keeps the 5 most recent step outputs
```