조용히 틀리는 버그 잡기

이 프로젝트에서 제일 크게 배운 갈래입니다. 봇은 열흘 동안 에러 없이 잘 돌았고, 그동안 계속 틀리고 있었어요. → 상위: 개발 지식 지도

초록불은 “실행됐다”는 뜻이지 “맞다”는 뜻이 아니다

• n8n은 전부 초록색, 텔레그램도 매일 도착, GitHub에 커밋도 쌓임 — 그런데 위키의 근거 기사 링크 88개 중 27개(31%)가 엉뚱한 기사를 가리키고 있었다.
• 끝을 직접 열어서 눈으로 확인해야 한다. 우연히 링크를 눌러보지 않았으면 지금도 몰랐을 것이다.
• 자동화를 만든 사람의 진짜 일은 만드는 게 아니라 계속 확인하는 것이다.

자가진단 체크리스트 — “에러는 없는데 결과가 이상할 때”

출처: n8n이 GitHub에 직접 글을 쓰게 만들기

검증은 표본이 아니라 전수로

위키에 쌓인 링크 88개를 전부 열어 항목 내용과 대조했다. 오배정 27개 중 상당수는 스무 개쯤 확인한 뒤에야 나왔다. 표본만 봤으면 “대체로 맞네” 하고 넘어갔을 것.

오류율을 유형별로 쪼개보면 원인이 보인다

매체별로 나눠 세지 않았다면 “URL 생김새” 라는 가설에 도달하지 못했을 것이다. → 결론은 자동화에서 LLM 다루기에 정리.

에러가 불친절하면, 코드가 스스로 말하게 만든다

원래 에러는 이것뿐이었다:

The first argument must be of type string or an instance of Buffer... Received undefined

사람 말로 설명하는 검사 두 줄을 넣었더니 5분 만에 원인이 나왔다:

if (metas.length !== gets.length) {
  throw new Error(`개수 불일치: Code 노드는 ${metas.length}개, GET 결과는 ${gets.length}개`);
}
if (!github.content) {
  throw new Error(`[${i}번째, ${meta && meta.path}] GET 응답에 content가 없음. 실제로 받은 값: ${JSON.stringify(github).slice(0, 300)}`);
}

Code 노드는 1개, GET 결과는 12개    ← 이 한 줄이 원인을 가리켰다

진단 코드는 지우지 않고 그대로 둔다. 자동화가 조용히 실패하는 지점마다 하나씩 심어두면 다음에 막혔을 때 나를 구해준다.

잘못된 단서에 속지 않기

• 편집기 화면에 보이는 줄은 그냥 스크롤 위치일 뿐, 에러 난 줄이 아니다. Buffer.from(...) 줄을 한참 의심했는데 아니었다.
• 숫자가 힌트다. GET 결과가 12개라는 게 저장소 최상위 파일 개수와 정확히 같았다 → 경로가 비어 있었다는 뜻. GitHub Contents API는 주소가 contents/까지만 오면 폴더 목록을 돌려준다.
• 판별법: GET 결과에 type: dir이 보이면 파일이 아니라 폴더를 읽은 것이다.

출처: 근거 기사 링크 전수 검증기

틀린 걸 지우는 것보다, 틀렸다고 적어두는 게 낫다

원문을 특정할 수 없는 링크 21건은 그냥 지우지 않고 이렇게 표시했다:

*(근거 기사 링크는 봇의 링크 오배정 버그로 유실되어 제거했습니다 — 2026-09-03 정정)*

빈칸으로 두면 나중의 내가 “원래 없었나?” 하고 헷갈린다.

추측으로 채운 자리는 공식 자료로 못 박는다

배터리 제조공정을 일반 지식으로 믹싱→코팅→건조→압연이라고만 적었다가 “슬리팅·노칭이 빠졌다”는 지적을 받고, LG에너지솔루션 공식 자료 기준으로 다시 맞췄다. 추측으로 채운 자리는 출처를 대고 고쳐야 나중에 신뢰할 수 있다.