Quiz: Observability and Regression Checks

규칙을 고친 뒤 골든 세트 정확도가 83퍼센트에서 83퍼센트로 그대로였다. 이것만으로 내려도 되는 결론은?

• 품질이 유지됐으므로 안전하게 내보내도 된다
• 맞힌 건수만 같을 뿐, 어느 건을 맞혔는지는 이 숫자가 말해 주지 않는다
• 고친 규칙이 아무 영향도 주지 않았다
• 골든 세트가 너무 작아 차이를 잡지 못했다

회귀를 볼 때 새로 깨진 것과 새로 고쳐진 것 중 보통 더 무겁게 다루는 쪽과 그 이유는?

• 새로 고쳐진 것 — 개선을 증명해야 배포 승인이 나기 때문
• 둘의 무게는 언제나 같다. 개수만 맞으면 된다
• 새로 깨진 것 — 사용자가 이미 그 동작에 기대고 있기 때문
• 새로 깨진 것 — 고치는 데 드는 시간이 더 길기 때문

노드를 감싸 시간도 재 두었지만 회귀 판정에는 호출 수와 크기만 쓰기로 했다. 가장 정확한 이유는?

• 시간 측정이 노드 실행을 느리게 만들기 때문
• 같은 코드·같은 입력이어도 시간은 기계와 부하에 따라 달라져 검사가 흔들리기 때문
• LangGraph 가 노드 시간을 제공하지 않기 때문
• 밀리초 단위는 정수로 저장할 수 없기 때문

골든 세트를 만들 때 이 실습이 권하는 것은?

• 지금 전부 맞는 건들로만 채워 기준선을 깨끗하게 만든다
• 실행마다 실제 트래픽에서 무작위로 뽑아 최신 분포를 반영한다
• 작아도 좋으니 고정하고, 지금 틀리는 건을 남겨 둔다
• 라벨마다 같은 수로 맞춰 균형을 맞춘다

두 판의 라벨이 모든 건에서 같은데 발자국(trace)이 달라진 건이 있다. 어떻게 보아야 하는가?

• 답이 같으므로 무시해도 되는 차이다
• 지금은 답이 같아도 다른 동작이므로, 다음 변경에서 다르게 갈라질 수 있다
• 발자국이 다르면 항상 비용이 늘어난 것이다
• 리듀서가 바뀌었다는 뜻이므로 상태 설계를 되돌려야 한다

관측을 위해 노드를 감싸는 자리를 그래프를 만들 때로 잡는 이유는?

• 나중에 붙이면 노드마다 고쳐야 하고 한 곳을 빠뜨리면 그 노드만 장부에 안 남는다
• 컴파일된 뒤에는 노드를 감쌀 방법이 전혀 없다
• 감싸는 함수는 컴파일 시점에만 상태를 읽을 수 있다
• 체크포인터가 감싼 노드만 저장하기 때문이다