#dev 수정: 2026-11-09 글 Vullean

텔레그램으로 블로그에 글 올리기 4: 원고 전송과 발행 확인

텔레그램으로 보낸 Markdown 원고를 GitHub에 직접 커밋하는 방식과 발행 결과를 확인하는 방법을 정리합니다.

개발 / IT 발행일: 2026-11-09 예상 읽기 시간: 약 3분 작성: Vullean 텔레그램 GitHub Actions Markdown 블로그

텔레그램으로 받은 Markdown 원고를 GitHub 저장소의 게시글 폴더에 커밋하면 기존 사이트 빌드 흐름을 이용해 발행할 수 있습니다. 여기서는 DevBJ의 Cloudflare Worker와 GitHub Actions 구성을 기준으로 원고 형식과 확인할 지점을 정리합니다.

시리즈 목차

  1. 봇과 웹훅 준비
  2. Worker와 GitHub 연결
  3. Worker에 웹훅 등록
  4. 원고 전송과 발행 확인

원고와 저장 경로

Worker는 YAML front matter로 시작하는 메시지 또는 .md 파일을 게시글로 처리합니다. 예를 들어 다음 원고는 content/posts/dev/first-note.md에 저장됩니다.

---
title: '첫 번째 노트'
nav_title: '첫 번째 노트'
description: '첫 번째 노트를 소개합니다.'
published_date: '2026-11-09'
updated_date: '2026-11-09'
category: dev
tags:
- 개발
slug: first-note
---

게시할 내용을 여기에 작성합니다.

title, nav_title, description, published_date, updated_date, category, tags, slug가 필요합니다. 날짜는 유효한 YYYY-MM-DD 형식으로 입력하고, slug는 영문 소문자와 숫자를 하이픈으로 연결해 작성합니다.

fpga/asic 카테고리는 fpga 폴더에 저장합니다. 지원하지 않는 카테고리나 빈 값은 blog로 바뀌고 텔레그램 알림에 표시되므로, 오타가 없는지 확인해야 합니다.

텍스트 또는 파일로 보내기

개인 채팅에서 원고 전체를 하나의 텍스트 메시지로 보내거나 UTF-8로 저장한 .md 파일을 첨부합니다. 원고는 첫 줄의 ---부터 본문 끝까지 보내고, 채팅 안내 문구를 앞에 붙이지 않습니다. 코드 블록이 포함된 글은 전송 후 GitHub의 파일에서 여는 펜스와 닫는 펜스가 모두 남았는지 확인하세요.

현재 Worker는 전송 내용의 맨 끝에 있는 백틱 세 개를 제거합니다. 코드 블록의 닫는 펜스가 원고의 마지막 줄이면 함께 제거될 수 있으므로, 코드 블록 뒤에 설명 문단을 두고 GitHub에 저장된 결과를 확인하세요. 이 주의점은 .md 첨부파일에도 적용됩니다.

긴 원고를 여러 메시지로 나누면 Worker가 각 메시지를 별도로 처리하므로 한 편으로 합쳐지지 않습니다. 이 경우 메시지를 쪼개지 말고 .md 파일 하나로 보내는 편이 안전합니다. 이 Worker는 첨부파일을 최대 512 KiB, 웹훅 요청 본문을 최대 64 KiB까지 읽습니다. 이 수치는 Worker의 제한이며 텔레그램 앱의 메시지 길이 제한과는 다릅니다.

직접 커밋할 때의 확인 사항

Worker는 기존 게시글과 slug가 겹치거나 같은 경로에 다른 내용이 있으면 덮어쓰지 않습니다. 저장 중 다른 커밋이 발생하면 최신 트리에서 다시 검사합니다. 같은 경로에 같은 내용이 이미 있으면 중복 커밋 대신 기존 내용을 알립니다.

GitHub 토큰에는 대상 저장소의 Contents 쓰기 권한이 필요합니다. 권한은 필요한 저장소에만 부여하고, 토큰은 Worker의 Secret에 보관하세요.

이 구성은 front matter가 없는 텍스트나 .md 파일을 게시글이 아닌 메모로 저장합니다. 메모도 공개 저장소에 커밋되므로 누구나 볼 수 있습니다. 글과 메모 모두 민감한 정보를 포함하지 않도록 주의하세요.

발행 결과 확인하기

게시글을 보낸 뒤에는 다음 순서로 확인합니다.

  1. 텔레그램 알림에서 저장 경로와 카테고리를 확인합니다.
  2. GitHub 저장소의 main 브랜치에 원고 파일이 생겼는지 확인합니다.
  3. GitHub Actions에서 사이트 빌드와 배포 결과를 확인합니다.
  4. 실제 사이트에서 글, 이미지와 링크가 정상인지 확인합니다.

Worker의 저장 완료는 커밋 완료를 뜻하며, 사이트 배포 성공까지 보장하지 않습니다. Worker는 사이트 전체 빌드나 이미지 파일 존재 여부를 확인하지 않으므로, 배포 실패 시 Actions 로그를 살펴봐야 합니다.

GitHub 토큰과 저장소 설정에 따라 커밋 또는 배포가 실패할 수 있습니다. 알림이 없으면 Worker 로그와 웹훅 상태를 확인하고, 저장 실패 알림이 오면 권한과 slug 충돌을 확인합니다. 커밋은 됐지만 빌드가 실패했다면 원고를 저장소에서 수정하고 다시 배포해야 합니다.

광고