회귀

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

​

회귀를 잡는 방식

해결된 개선은 저마다 시그니처(다뤘던 신호 패턴)를 남깁니다. Nora가 그 시그니처에 걸리는 새 신호를 지켜봅니다. 신호가 회귀로 표시되는 조건은 이렇습니다.

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

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

​

회귀 뷰

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

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

​

회귀는 왜 생기나

흔한 원인은 이렇습니다.

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

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

​

무엇을 할까

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

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

​

회귀 알림

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

​

회귀 막기

가장 깔끔한 방법은 retention 테스트 입니다. 개선을 해결할 때 관련 실패 트레이스를 retention 데이터셋으로 저장해, 모든 시뮬레이션에 함께 돌립니다(시뮬레이션 참고). 이 테스트를 깨는 앞으로의 변경은 배포 전에 걸립니다. 개선 플로우가 큰 클러스터를 해결할 때 기본으로 이걸 제안합니다.