3. 고쳐도 안 깨지는 코드

바꿔도 되는 것, 그리고 함정 일곱

이 차시를 마치면

바꿔도 되는 것과 임의로 고치면 안 되는 일곱 가지를 구분합니다.

자유롭게 바꿔도 되는 것과, 바꾸면 안 되는 일곱 가지입니다.

B — 유연하게 변경 가능한 것

대체로 다음은 바꿔도 됩니다.

다만 학습팩은 여기에 단서를 붙입니다. 연결된 contract 가 있으면 같이 수정해야 합니다.

이 단서가 B 와 C 를 가릅니다. 같은 "threshold 변경"이라도 숫자만 바꾸면 B 이고, 그 threshold 가 Structured Output 의 label 기준과 연결되어 있는데 한쪽만 바꾸면 C 가 됩니다. 분석

#	행위	무엇이 깨지는가 분석
C-1	이름 하나만 변경 — `question` → `query` 를 `state.py` 에서만	A-1. Node 와 router 가 옛 이름을 참조해 실행 시점에 실패합니다
C-2	Node 반환값 삭제 — downstream 이 참조하는 key 제거	A-1
C-3	Router branch 변경 — graph Node 등록을 같이 바꾸지 않음	A-1. route 이름과 Node 이름의 계약
C-4	Structured Output schema 변경 — migration 이나 parser 변경 없이 field 삭제	A-1. DB 와 API 계약
C-5	HITL 앞에 side effect 삽입 — 재개 시 Node 가 처음부터 다시 실행될 수 있어 중복 동작 위험	A-2, A-4
C-6	테스트 삭제 — 기능 실패를 숨기려고 regression test 를 제거	A 전체의 검증 수단
C-7	비밀값 하드코딩 — API key 등을 source 에 직접 넣음	A-2. 개인정보와 비밀값 보호

C 는 "하면 안 되는 새로운 목록"이 아닙니다. A 를 부분적으로만 고쳤을 때 나타나는 결과입니다. 그래서 C 를 저지른 사람은 대부분 자기가 B 를 하고 있다고 생각합니다. 분석

C-7 비밀값 하드코딩은 유출로 이어집니다. 한 번 commit 되면 나중에 지워도 Git 이력에 남습니다.

C-5 승인 앞 side effect는 승인 게이트를 무력화합니다. 승인 절차를 만들어 두고도 승인 전에 일이 벌어지는 상태가 됩니다.

비유

C-5 는 금고 문을 잠가 두고 뒷벽에 구멍을 낸 것과 같습니다. 문은 정상으로 보이고 열쇠도 잘 작동합니다. 그래서 문제를 발견하기 어렵습니다.

"급하니까 승인 단계를 빼 달라"는 요청은 A-2 를 바꾸겠다는 요청입니다. prompt 나 Node 하나를 지워서 처리하면 C-5 가 됩니다.

요지는 안전 규칙을 "빼는" 대신 "범위를 다시 정의"하도록 유도하는 것입니다. 전자는 흔적이 남지 않고, 후자는 판단 근거가 문서에 남습니다. 분석

오해	실제
"A 는 코드를 절대 못 고친다는 뜻"	아닙니다. 함께 고쳐야 한다는 뜻입니다
"테스트가 실패하니 테스트가 낡았다"	C-6 일 수 있습니다. 원인 확인 전 삭제는 금지입니다
"prompt 는 자유 영역이다"	label, safety rule, Tool 사용 조건은 계약입니다
"Checkpointer 는 성능 옵션이다"	HITL 에서는 기능의 전제 조건입니다

문항을 불러오는 중입니다.