2022년 나의 블로그 자동화 프로세스

❗️ 참고: 이 글이 작성된 지 이미 일이 지났습니다. 시의성에 유의하세요

🖥 설명：기술은 발전하고 있고, 저도 계속 시도하고 있습니다.

📚 Craft에도 게시： https://www.craft.do/s/zGU3Z3SIIVMahv

서문

2021년에 블로그 자동화에 관한 글을 쓴 적이 있습니다. 하지만 당시에는 Craft 이미지 문제를 제대로 처리하지 못했고, 로직이 여러 저장소에 흩어져 있어 참고하기 어려웠습니다. 이후 Craft에서 직접 이미지를 전송하는 방법을 시도해봤지만(결론은 불가능), 최근 주말을 이용해 이미지를 텐센트 클라우드에 저장하는 문제를 해결했습니다. 게다가 Github Pages 대신 Vercel로 옮기면서 속도도 크게 개선되었습니다. 이에 대한 내용을 기록합니다.

참고: 앞으로도 “202x년 나의 블로그 자동화 프로세스” 같은 글이 계속 나올 수 있습니다. 기술은 발전하고, 시대는 변하며, 저도 계속 개선 중이니까요 🤣

본문

전체 프로세스

상세 설명

⓵ Craft 문서

특정 형식으로 작성된 블로그 문서를 의미합니다. 이 형식은 저장소에 정상적으로 동기화되기 위해 다음 조건을 충족해야 합니다:

문서의 첫 번째 요소는 메타 정보를 포함한 table 요소여야 합니다.
메타 정보에서 title은 작성할 필요 없으며, 문서 데이터에서 직접 추출합니다. headerImg와 img의 저작권 정보(unsplash에서 업로드한 경우)도 작성하지 않습니다.
Drawing 요소는 지원하지 않습니다(유효한 이미지 확장자를 가진 파일을 생성하지 못하기 때문). 만약 존재한다면 COS에 업로드되지 않으며 정상적으로 표시되지 않습니다(Craft의 전용 파일 형식이기 때문).

⓶ Craft 플러그인 저장소(공개)

Craft에 적용되는 플러그인으로, Craft 문서 내용을 가져와 처리 후 저장소에 업로드하는 역할을 합니다. Craft 플러그인에 대한 자세한 정보는 여기에서 확인할 수 있으며, 제가 작성한 이 비공개 플러그인의 주소는 여기에 있습니다.

플러그인의 역할은 Craft 문서 내용을 Markdown 형식으로 생성한 후 Github REST API를 사용해 고정된 저장소 위치인 craft_publish_ci 저장소의 content.md 파일로 전송합니다. 해당 파일이 이미 존재하는 경우 내용을 교체하며, 저장소 주소는 공개되어 있습니다. 여기에서 확인할 수 있습니다.

⓷ craft_publish_ci 저장소(공개)

이 저장소는 주로 Github Action을 사용하여 이미지를 처리하며, 플러그인으로부터 내용을 받은 후(즉, content.md 파일이 업데이트된 후) 해당 파일의 내용을 읽어 Markdown 파일 내의 이미지(![으로 시작하는 블록 요소가 이미지로 판단되며, 특별한 headerImg로 시작하는 헤더 이미지도 포함)를 가져와 Tencent Cloud COS에 저장합니다. 이때, 통일성과 편의를 위해 이미지를 가져온 후 action에서 일괄적으로 jpg 형식으로 변환합니다. 이렇게 하면 이미지를 업로드할 필요가 없는 경우(텍스트만 수정한 경우)에도 문서 내 이미지 주소를 직접 교체하는 로직을 쉽게 처리할 수 있습니다. 어떤 이미지는 png나 jpg 같은 일반적인 이미지 형식이 아니거나, 확장자가 아예 없는 경우도 있기 때문입니다. 저는 이미지를 가져온 응답의 content-type을 사용하여 이미지에 확장자를 추가하려고 시도한 적이 있지만, 어떤 이미지는 tiff 형식인데 content-type이 application/octce-stream(틀리지 않았다면)으로 반환되는 경우도 있었고, 이 방법은 문서 내 모든 이미지를 먼저 전부 가져와야 하기 때문에 차단될 우려가 있어, 업로드해야 할 이미지는 모두 jpg로 변환하기로 했습니다. 그런 다음 CDN 주소를 얻은 후 문서 내 해당 이미지 주소를 CDN 이미지 주소로 교체합니다. 이 작업이 완료되면 파일 내용을 실제 블로그 저장소인 x_blog_src로 보냅니다.

⓸ x_blog_src 저장소(비공개)

이 저장소는 push 업데이트를 받으면 Action을 실행하여 HTML 파일을 빌드하고, 블로그 공개 저장소인 x_blog로 전송합니다. 이렇게 하는 이유는 여기에서 확인할 수 있습니다.

⓹ x_blog 저장소(공개)

이 저장소는 Vercel이 내용을 읽을 수 있도록 권한이 부여되어 있으며, 배포됩니다. 사용자 정의 도메인이 연결되어 있으므로 www.xheldon.com을 통해 접근할 수 있습니다. Github Pages를 사용하지 않는 이유는 전자가 더 전문적이며 전용 글로벌 CDN 가속이 제공되기 때문입니다. 반면 Github Pages는 도메인 해석이 느리고 CDN 가속이 없어 문서 웹사이트로는 괜찮지만, 블로그로는 최적화가 전혀 이루어지지 않은 느낌이 들어 적합하지 않다고 판단했습니다.

블로그에는 Notion 데이터 소스를 비동기적으로 요청하는 페이지가 있습니다. 예를 들어 구독 관리 페이지가 있는데, 이 과정 역시 Vercel의 serverless를 사용하여 서버 측에서 Notion의 database를 요청해 한 번의 전달을 수행합니다. 이 인터페이스는 제가 범용적으로 만들었으며, POST를 사용해 Notion database의 헤더와 databaseId를 전송하도록 해서, 추후에 Notion을 비동기적으로 요청해야 하는 더 많은 페이지가 생길 경우를 대비했습니다.

- EOF -

이 글의 최초 게시: 2022년 나의 블로그 자동화 프로세스 - Xheldon Blog