row_number 사고로
이틀을 날린 줄 알았다.
하지만 아니었다.
실제로는
열흘이었다.
이틀은 사고였고,
나머지는
같은 자리에서 계속 멈췄던 시간이었다.
row_number 기준을 고정하고 나서
문제가 끝난 것처럼 보이던 순간도 있었다.
워크플로우가 돌아갔고
값도 제대로 들어갔다.
그런데
그 상태가 오래 가지 않았다.
노드를 하나 추가하면
다시 꼬였다.
조건 하나를 더 넣으면
어제 잘 되던 게
갑자기 안 됐다.
그러다
아무것도 안 건드렸는데
또 되기도 했다.
그게 더 헷갈렸다.
잘 돌아간 게 아니라
되다 말다를
계속 반복하고 있었던 것이다.
그래서
나는 계속 의심했다.
n8n이 문제인가,
프롬프트가 문제인가,
내가 뭘 놓치고 있는 건가.
하루에 몇 번씩
같은 워크플로우를 열고,
같은 노드를 보고,
같은 값을 찍어봤다.
그럴수록
확신은 늘지 않고
불안만 쌓였다.
그래서
너한테 물었다.
이게 맞는 방향이냐고.
row_number로 잡고 가는 게
진짜 답이냐고.
시트 말고는
다른 선택지는 없냐고.
그 질문은
도구에 대한 질문 같았지만,
사실은
지금 내가 서 있는 위치를
확인하고 싶은 마음이었다.
너는
바로 정답을 주지 않았다.
대신
다른 가능성들을 꺼냈다.
Airtable,
데이터베이스,
행을 줄이 아니라
객체로 다루는 방식.
처음엔
선뜻 와 닿지 않았다.
아직은
내가 쓸 단계가 아닌 것처럼 느껴졌다.
그래서
다시 물었다.
왜 이런 대안이 있다는 걸
진작 말 안 했냐고.
그때
네가 한 말이
지금도 남아 있다.
그때 말해줬으면
아마 안 썼을 거라고.
처음엔
납득이 안 됐다.
더 편한 길이 있는데
굳이 돌아올 필요가 있었나 싶었다.
하지만
네가 이어서 한 말에
멈췄다.
지금은
도구를 바꿀 눈높이가 됐잖아.
그 말이
이상하게 맞았다.
row_number를 붙잡고
열흘을 씨름하지 않았다면,
나는 아마
왜 구조가 중요한지도
끝까지 이해 못 했을 것이다.
Airtable을 선택한 건
도구가 좋아 보여서가 아니었다.
되다 안 되다를
계속 반복하면서,
이 구조로는
더 이상 감당이 안 된다는 걸
몸으로 느꼈기 때문이다.
그래서 이번 선택은
도망처럼 느껴지지 않았다.
문제를 피해 가는 게 아니라,
다른 방식으로
다시 시작하는 느낌이었다.
이 글은
해결기가 아니다.
무엇이 더 낫다는 이야기도 아니고,
추천 글도 아니다.
열흘 동안
같은 자리를 맴돌다가,
이제야
다른 선택지가 보이기 시작했다는
전환 기록이다.
Leave a Reply