이건 깨달음이 아니다.
사고 기록이다.
구글 시트의row_number 하나 때문에
이틀이 그대로 날아갔다.
사고 개요
증상은 단순했다.
워크플로우는 실행되는데
결과가 안 남았다.
혹은
엉뚱한 줄이 바뀌었다.
어제까지 되던 게
오늘은 안 됐고,
고친 것 같으면
다른 데서 또 터졌다.
에러 메시지는
항상 애매했다.
“잘못된 범위”
“매칭 실패”
“값이 없다”
없는 건 아니었다.
분명히 있었다.
사고 당시 판단
처음엔
프롬프트를 의심했다.
다음엔
OpenAI 응답을 의심했다.
그다음엔
n8n 노드를 하나씩 추가했다.
조건 분기 넣고
Set 노드로 값 찍어보고
로그 찍고
다시 실행했다.
그럴수록
상태는 더 나빠졌다.
한 번에 하나씩 고친다고 생각했는데
실제로는
한 번에 여러 개를 바꾸고 있었다.
핵심 원인
문제는
대단한 게 아니었다.
row_number.
시트에는ep_id가 있었고
그걸로 매칭한다고
굳게 믿고 있었다.
하지만
Update Row는
그걸로는 안 됐다.
겉으로는
값이 들어간 것처럼 보였고
실행도 성공처럼 보였다.
그래서 더 헷갈렸다.
사실은
업데이트 대상 줄을 못 찾고 있었던 것이다.
왜 못 봤는가
두 가지가 겹쳤다.
첫째,
“이 정도는 맞겠지”라는
확신.
둘째,
이미 며칠째 쌓인 피로.
눈앞에 있는 걸
계속 보고 있었는데
보지 못했다.
값이 틀린 게 아니라
기준이 틀린데
기준을 의심하지 않았다.
조치 내용
결국
기준을 하나로 고정했다.
- Get Row(s)에서
row_number를 받는다 - 이후 모든 Update Row는
같은 row_number만 사용한다 - id 매칭, 추정, 편의성
전부 버린다
잘 되는 방법을 찾은 게 아니라
다시는 헷갈리지 않게 만든 것이다.
사고 이후 변화
그 이후로
비슷한 에러는 다시 안 나왔다.
실력이 늘어서가 아니다.
구조가
사람을 덜 믿게 만들었기 때문이다.
이 사고 하나로
나는 확실히 알게 됐다.
자동화에서 제일 위험한 건
에러가 아니라
“대충 맞겠지”라는 생각이다.
🔜 다음 편 예고
이 사고 이후 내가 고정한 것들
다음 글에서는
이 사고 이후
내가 절대 안 바꾸기로 한 규칙들을 적는다.
- 왜 편한 방법을 일부러 버렸는지
- 왜 id 대신 row_number를 고집하게 됐는지
- 왜 “유연함”보다 “멍청한 고정”을 선택했는지
다음 화는
노하우가 아니라
운영 규칙 목록이다.
🔜 다음 편 예고
이틀이 아니라, 열흘이었다
row_number 사고는
이틀을 멈췄다.
하지만
그 이후에도
상태는 끝나지 않았다.
고친 것 같았고
넘긴 것 같았는데
다음 날이면
또 같은 데서 멈췄다.
계속 의심했던 대상은 따로 있었다
열흘 동안
나는 n8n을 의심했고
프롬프트를 의심했고
내 이해도를 의심했다.
그런데
정작 문제는
그쪽이 아니었다.
오늘에서야 꺾은 방향 하나
오늘에서야
처음으로
도구 자체를 의심했다.
그리고
구글 시트를 내려놓고
Airtable로 방향을 틀었다.
다음 글은
해결기가 아니다.
열흘 멈춤 끝에
왜 여기까지 오게 됐는지에 대한
전환 기록이다.
Leave a Reply