최적화 개요

최적화 는 “문제가 있음” (시그널이나 클러스터) 과 “문제가 고쳐짐” (출시된 버전) 사이 기계. 구체적 변경 제안, 테스트, 승인 위해 사람에게 전달. 써야 하는 건 아님 — 정상 Draft-and-Publish 플로우로 모든 걸 손으로 고칠 수 있음. 하지만 최적화가 의식을 자동화: 제안, 테스트, 리뷰 준비.

​

여섯 스텝의 플로우

1. 진단 — 클러스터 (또는 시그널) 선택. Nora 가 근본 원인 위치 파악.
2. 제안 — Nora 가 근본 원인 타겟한 1-3 후보 수정 생성.
3. 레버 선택 — 시스템의 어느 부분을 바꿀지 결정: 프롬프트·도구·리트리벌·메모리 등.
4. 시뮬레이션 — 모든 후보가 데이터셋에 실행. Before/after 숫자.
5. 승인 — 승자 선택. 옵션 게이트 (사람 리뷰, 코드 리뷰, 테스트).
6. 배포 — 변경이 Draft 에 적용; 배포 (또는 설정되면 자동 배포).

​

페이지

​

자동 vs. 수동

전체 플로우가 저위험 변경에는 자동 실행 가능 — 임계값 설정하면 Nora 가 여러분 깨우지 않고 수정 출시. 또는 매 스텝 사람 승인 요구 가능. 권장: 강한 시뮬레이션 결과 있는 잘 이해된 레버 (작은 프롬프트 조정, 룰 추가) 는 자동. 모델 스왑, 도구 설정, 메모리 구조 관련은 수동. Flow 별 설정: Flow settings → Improvement automation.

​

재현성

모든 개선이 유지:

• 시드한 클러스터.
• 고려된 제안.
• 시뮬레이션 결과 (타겟 vs. 베이스라인).
• 승인자.
• 배포 타임스탬프.

모두가 몇 달 후에도 리뷰 가능. 컴플라이언스 감사, 인시던트 리뷰, Flow 가 왜 그런지 이해에 좋음.

​

개선과 버전

배포된 모든 개선이 개선 노트가 있는 새 Flow 버전 생성. 롤백이 전체 개선을 원자적으로 롤백. 어느 버전에든 붙은 개선 확인 가능 — “v18 이 클러스터 #142 (결제 환각) 를 고치려 배포됨.”

​

개선이 자동이 아닐 때

최적화는 변경 을 제안하지만 일부 수정은 최적화가 하지 않는 것들 필요:

• 지식에 새 문서 추가 — 여러분이 업로드.
• 새 도구 빌드 — 여러분이 빌드.
• 깨진 상류 API 수정 — 여러분이 수정.

이것들에는 최적화가 시그널에 근본 원인 노트 표면화하고 정지. 여러분이 거기서 이어감.