GitHub 빌드 에러부터 n8n 자동화 개선까지: 하루 종일 삽질한 67세 교수의 기록

오늘은 정말 긴 하루였습니다. 아침에 GitHub Actions를 열었더니 빨간 X 표시가 저를 맞이했습니다. 560개가 넘는 워크플로우 실패 기록. 순간 멍해졌습니다. “이게 다 뭔가…”

GitHub 빌드 실패, 알고 보니 단순한 문제였다

에러 로그를 들여다보니 범인은 하나였습니다.

Liquid Exception: Could not find document
'/assets/img/posts/2026-05-13/my-image.png' in tag 'link'

포스트 안에 {% link %} 태그로 존재하지 않는 이미지를 참조하고 있었습니다. Jekyll은 이 태그를 실제 명령으로 실행하려다 파일을 찾지 못해 빌드 전체를 멈춰버린 것입니다. 해결은 간단했습니다. {% link 경로 %} 에서 {%와 %} 를 제거하고 경로만 남기면 됩니다.

그런데 문제가 하나가 아니었습니다. n8n으로 자동 생성된 포스트들 곳곳에 {{$json.target_category}} 같은 n8n 표현식이 그대로 박혀있었습니다. Jekyll이 이것을 Liquid 문법으로 오해해 경고를 쏟아낸 것입니다. 또 날짜가 2026-054-16 처럼 잘못 생성된 파일도 있었고, 파일명에 한글이 포함된 것도 여럿이었습니다.

Python 스크립트로 129개 파일 일괄 수정

수작업으로 하나씩 고치는 건 불가능했습니다. GitHub API를 활용한 Python 스크립트를 작성했습니다. 스크립트는 _posts 폴더의 모든 파일을 순서대로 읽어 네 가지 수정을 자동으로 처리했습니다.

첫째, {% link %} 태그 제거. 둘째, {{$json...}} 표현식을 백틱으로 감싸기. 셋째, 잘못된 날짜를 파일명 날짜로 강제 교체. 넷째, 한글이 포함된 파일명을 영문으로 변경.

결과는 명확했습니다. 내용 수정 11개, 파일명 변경 6개, 수정 불필요 112개. 스크립트 실행 후 GitHub Actions에서 초록불이 켜졌을 때의 그 안도감이란.

n8n 자동화를 더 똑똑하게 개선했다

빌드를 살리고 나니 자동화 자체를 개선하고 싶어졌습니다. 기존 n8n 워크플로우는 Claude가 날짜를 직접 생성하다 보니 2026-054-16 같은 오타가 나올 수 있었습니다. 파일 인코딩 노드에서 날짜를 강제 교체하는 코드를 추가했습니다.

파일명도 개선했습니다. 기존의 auto-post-타임스탬프.md 방식 대신, Claude에게 영문 슬러그를 함께 생성하도록 프롬프트를 수정했습니다. 이제 2026-05-17-jekyll-build-error-fix.md 처럼 의미 있는 파일명이 만들어집니다. SEO에도 유리하고 관리하기도 훨씬 편합니다.

포스트 길이도 조정했습니다. 기존 프롬프트에는 상한선이 없어 내용이 중간에 잘리는 일이 있었습니다. “2300자 이상 2800자 이내, 반드시 완성된 문장으로 끝낼 것”이라는 조건을 추가했더니 훨씬 안정적인 결과가 나옵니다.

artsense.kr SEO 문제도 함께 손봤다

오래 방치된 artsense.kr WordPress 사이트의 SEO 문제도 정리했습니다. 가장 큰 문제는 URL이었습니다. 한국어 제목이 그대로 URL이 되면 /%eb%b6%80%ec%a0%95... 같은 암호문이 됩니다. 고유주소 설정을 /%post_id%/ 로 바꾸니 762개 포스트가 즉시 artsense.kr/123/ 형태의 깔끔한 URL로 바뀌었습니다.

카테고리도 전부 ‘Uncategorized’ 였던 것을 리더십, 자기계발, AI활용, 비즈니스, 시니어IT 다섯 개로 정리했습니다. Google이 사이트 주제를 명확하게 파악할 수 있도록 구조를 잡았습니다.

35년 교수 생활 동안 이런 기술적 도전을 해본 적이 없었습니다. 처음엔 에러 메시지 하나가 두려웠지만, 하나씩 해결하다 보니 어느새 하루가 지났습니다. 내일은 또 어떤 문제가 기다릴지 모르지만, 이제는 조금 기대가 됩니다.

혹시 비슷한 Jekyll 빌드 에러로 고생하고 계신다면 댓글로 알려주세요. 같이 해결해 보겠습니다.