> ## 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.

# 회귀

> 예전에 고친 문제가 되돌아옵니다. 빨리 잡아냅니다

가장 무서운 신호는 이미 해결한 줄 알았던 것입니다. **회귀 감지**는 바로 이걸 노려 지킵니다. 예전에 고친 것과 닮은 새 신호 말이죠.

## 회귀를 잡는 방식

해결된 개선은 저마다 시그니처(다뤘던 신호 패턴)를 남깁니다. Nora가 그 시그니처에 걸리는 새 신호를 지켜봅니다.

신호가 **회귀**로 표시되는 조건은 이렇습니다.

* 예전에 해결된 개선의 시그니처와 맞음.
* 그 개선이 배포된 뒤에 걸림.
* 같은 Flow 안에서 걸림(회귀는 Flow 사이보다 Flow 안에서 훨씬 흔함).

회귀 표시는 평소 신호 묶기에 덧붙는 것입니다. 회귀도 자기 클러스터 안의 평범한 신호이기도 합니다.

## 회귀 뷰

신호의 필터 뷰인 **Signals → Regressions**에서 봅니다. 이렇게 보여줍니다.

* 회귀한 신호.
* 그걸 고쳤다고 여겨진 개선(개선 이력 링크와 함께).
* 회귀가 나타난 버전.
* 수정과 회귀 사이에 며칠이 벌어졌는지.

## 회귀는 왜 생기나

흔한 원인은 이렇습니다.

* **Flow 변경이 수정을 되돌림** 누군가 같은 프롬프트나 설정을 다시 손봄.
* **데이터 변경** 문서가 대체되거나 지워져, 그 데이터에 기대던 수정이 무너짐.
* **바깥 변경** 도구 API가 바뀜, 모델 제공자 업데이트, 상류 소스가 흘러감.
* **새 인접 동작** Agent가 새 영역으로 넓어지며, 새 맥락에서 옛 패턴을 다시 만듦.
* **수정이 너무 좁음** 개선이 특정 경우는 덮었지만 살짝 다른 변형을 놓침.

회귀 뷰가, 수정과 회귀 사이에 무엇이 바뀌었는지를 근거로 Nora의 최선 추측을 보여줍니다.

## 무엇을 할까

1. **진짜 회귀인지 확인** 그냥 오래된 시그니처가 우연히 맞은 게 아닌지.
2. **무엇이 바뀌었는지 보기** flow diff, 데이터 변경, 바깥 공지.
3. **수정을 넓히거나 다시 적용** 대개 맨땅이 아니라 기존 개선을 다듬습니다.

수정이 프롬프트 변경이었는데 누가 프롬프트를 손댔다면 되돌리거나 다시 짭니다. 수정이 데이터 추가였는데 데이터가 지워졌다면 되살립니다. 수정이 너무 좁았다면, 그 회귀를 새 예시로 삼아 더 넓은 패턴으로 개선 플로우를 다시 돌립니다.

## 회귀 알림

회귀는 기본적으로 우선순위가 높습니다. 회귀 신호만 따로 Slack/이메일 알림을 켜세요. 신호 설정 → **Regression alerts** 입니다. 회귀는 드무니 잡음을 더하지 않으면서, 생기면 바로 알려 줍니다.

## 회귀 막기

가장 깔끔한 방법은 **retention 테스트** 입니다. 개선을 해결할 때 관련 실패 트레이스를 **retention 데이터셋**으로 저장해, 모든 시뮬레이션에 함께 돌립니다([시뮬레이션](/ko/reliable/simulation/regressions) 참고). 이 테스트를 깨는 앞으로의 변경은 배포 전에 걸립니다.

개선 플로우가 큰 클러스터를 해결할 때 기본으로 이걸 제안합니다.