고치기 전에 확인할 것

고치기 전에 5분 쓰면 되돌리는 데 드는 하루를 아낍니다. 실제로 눌러 가며 점검하는 목록입니다.

State 변경

• 어떤 Node 가 이 키를 읽는가?
• 어떤 Node 가 쓰는가?
• router 가 참조하는가?
• Checkpoint 호환성 문제는 없는가?
• test fixture 를 수정해야 하는가?

Tool 변경

• argument schema 가 바뀌는가?
• Agent prompt 와 Tool description 도 바꿔야 하는가?
• side effect 가 추가되는가?
• permission 이나 auth 가 달라지는가?

Prompt 변경

• label 이름이 바뀌는가?
• Structured Output schema 와 충돌하는가?
• test dataset 에서 회귀가 생기는가?

Graph 변경

• START 에서 END 로 가는 경로가 존재하는가?
• 무한 loop 가능성이 없는가?
• 병렬 갱신값에 Reducer 가 필요한가?
• HITL 이나 Persistence 에 영향은 없는가?

Model 변경

• Tool calling 을 지원하는가?
• Structured Output 을 지원하는가?
• context window 는 충분한가?
• 비용과 지연은 감당 가능한가?
• output 품질에 회귀가 없는가?

배포 전

• py_compile
• unit test
• graph test
• representative eval dataset
• secret 노출 점검

체크 상태는 저장되지 않습니다. 새로고침하면 초기화됩니다.

해 보기 — State 의 키 이름 하나 바꾸기

앞 차시의 C-1 을 피하는 순서입니다. 분석

grep -rn '"question"' src/ tests/

1. 검색으로 참조 지점을 전부 찾습니다
2. state.py, nodes.py, routing.py, tests/ 를 한 번에 수정합니다
3. Checkpoint 호환성을 판단합니다
   • 개발 중이고 기존 Thread 를 버려도 되면 → 진행
   • 운영 중이면 → 새 key 추가 · 이행 기간 · 옛 key 제거의 3단계로 나눕니다
4. py_compile + unit test + graph test 를 돌립니다

확인 필요 3단계 이행 방식은 일반적인 스키마 변경 절차이며, 학습팩에는 구체적 방법이 서술되어 있지 않습니다.

여기까지 오면

코드 구조와 변경 규칙이 끝났습니다. 4번 트랙에서는 이 규칙을 실제로 적용해 승인 없이는 위험한 일을 하지 못하는 Agent 를 만듭니다.