n8n 수집기를 소스별로 분리한 빌드 로그

자동화는 한 번 연결했다고 끝나지 않아요. 특히 여러 곳에서 자료를 모으는 수집 작업은 한 지점의 전제가 어긋나도 전체 흐름이 멈출 수 있어요. 이번에는 n8n 마케팅 작업에서 벤치마크 수집기를 소스별로 독립 실행하도록 정리하고, 실패했을 때 다음 단계로 넘어가지 않는 fail-closed 흐름을 다뤘어요.

2026년 9월 23일 기록에는 관련 변경이 4개 파일로 남아 있어요. 수집기 2개, 일일 실행 스크립트 1개, 테스트 1개예요. 변경 파일 목록을 직접 펼쳐 보니, 수집 로직만 손보는 일이 아니라 실행 순서와 검증 기준을 함께 묶는 작업이었어요.

소스별 수집→결과 확인→일일 실행 판단

처음에는 여러 수집 작업을 한 흐름으로 묶는 편이 단순해 보여요. 하지만 특정 경로나 실행 환경에 의존하면, 자료를 가져오는 본래 목적과 무관한 이유로 매일의 작업이 멈출 수 있어요. 커밋 제목을 다시 읽어 보니 이번 선택의 핵심은 바로 그 의존성을 줄이는 데 있었어요. 각 소스가 자기 실행 단위를 갖고, 실패를 성공처럼 넘기지 않도록 기준을 세운 거예요.

여기서 fail-closed는 복잡한 장치가 아니에요. 필요한 조건을 확인할 수 없으면 “아마 괜찮겠지”라고 다음 단계를 진행하지 않는 태도에 가까워요. 실행 흐름을 문장으로 돌려 보니, 이 기준은 세 가지 질문으로 정리됐어요.

1. 어느 소스의 수집이 실패했는지 구분할 수 있는가
2. 실패한 결과가 정상 결과와 섞이지 않는가
3. 일일 실행 스크립트가 확인되지 않은 상태를 완료로 다루지 않는가

테스트해 보면 이 질문들은 코드보다 먼저 운영 기준을 선명하게 해줘요. 수집량이나 처리 속도처럼 이력에 없는 결과 수치를 말할 수는 없지만, 적어도 실패를 감추지 않는 구조를 의도했다는 점은 변경 기록으로 확인할 수 있어요.

이번 사실 시트에는 최근 7일간 커밋 13건이 정리돼 있어요. 그중 이 수집기 변경은 자동화를 계속 운영하기 위한 작은 조정 중 하나였어요. 직접 만들어 보니 자동화의 신뢰는 거대한 대시보드보다, 실패한 입력을 어디서 멈추게 할지 정하는 짧은 조건에서 시작됐어요.

라이프케어로그는 플랜씨(plan-c), 플랜비(plan-b), 플랜엘(plan-l), 플랜티(plan-t)처럼 서로 다른 제품을 만드는 1인 개발 브랜드예요. 제품마다 쓰임은 달라도, 수집·검증·기록의 흐름을 분리해 보는 습관은 공통 기반이 돼요. 다음 자동화를 만들 때도 먼저 “실패했는데도 지나가면 무엇이 남을까”를 적어 보려고 해요.