최적화 개요

최적화는 “문제가 있다”(신호나 클러스터)와 “문제가 고쳐졌다”(출시된 버전) 사이를 잇는 기계입니다. 구체적인 변경을 제안하고, 테스트하고, 사람이 승인하도록 넘깁니다. 꼭 써야 하는 건 아닙니다. 평소처럼 Draft를 만들고 퍼블리시하는 흐름으로 전부 손수 고쳐도 됩니다. 다만 최적화는 그 번거로운 절차, 그러니까 제안하고 테스트하고 리뷰 준비까지를 대신 해 줍니다.

​

여섯 단계 흐름

1. 진단 클러스터(또는 신호)를 고르면 Nora가 근본 원인을 찾습니다.
2. 제안 Nora가 근본 원인을 겨냥한 후보 수정을 1~3개 만듭니다.
3. 레버 선택 시스템의 어느 부분을 바꿀지 정합니다. 프롬프트, 도구, 리트리벌, 메모리 같은 것들이죠.
4. 시뮬레이션 모든 후보를 데이터셋에 돌려 before/after 숫자를 봅니다.
5. 승인 이긴 쪽을 고릅니다. 원하면 게이트(사람 리뷰, 코드 리뷰, 테스트)를 겁니다.
6. 배포 변경이 Draft에 적용되고, 여러분이 퍼블리시합니다(설정해 두면 자동으로).

​

페이지

​

자동이냐 수동이냐

위험이 낮은 변경이라면 전체 흐름을 자동으로 돌릴 수 있습니다. 임계값만 정해 두면 Nora가 여러분을 깨우지 않고 수정을 출시합니다. 아니면 단계마다 사람 승인을 받게 할 수도 있습니다. 권합니다. 시뮬레이션 결과가 탄탄하고 잘 아는 레버(작은 프롬프트 조정, 룰 추가)는 자동으로, 모델 스왑이나 도구 설정, 메모리 구조를 건드리는 건 수동으로 두세요. Flow마다 Flow settings → Improvement automation에서 정합니다.

​

재현성

모든 개선은 이런 걸 남깁니다.

• 씨앗이 된 클러스터.
• 검토한 제안들.
• 시뮬레이션 결과(타겟 대 베이스라인).
• 승인한 사람.
• 배포 시각.

몇 달 뒤에도 다 되짚어 볼 수 있습니다. 컴플라이언스 감사나 사고 리뷰, 그리고 이 Flow가 왜 지금 모습인지 이해할 때 요긴합니다.

​

개선과 버전

배포된 개선은 그때마다 개선 노트가 달린 새 Flow 버전을 만듭니다. 롤백하면 그 개선 전체가 한 번에 되돌아갑니다. 어느 버전에 어떤 개선이 붙었는지도 볼 수 있습니다. 예를 들어 “v18은 클러스터 #142(결제 환각)를 고치려고 배포됨” 처럼요.

​

개선이 자동으로 안 되는 것

최적화는 변경을 제안하지만, 어떤 수정은 최적화가 대신 못 하는 것들입니다.

• 지식에 새 문서 추가. 여러분이 올립니다.
• 새 도구 만들기. 여러분이 만듭니다.
• 깨진 상류 API 고치기. 여러분이 고칩니다.

이런 건 최적화가 신호에 근본 원인 노트만 띄우고 멈춥니다. 그다음은 여러분이 이어서 합니다.