티스토리 자동화 중 발생한 마크다운 파싱 오류와 정규식(Regex) 복구 로직

이번 글에서는 파이썬 기반으로 티스토리 자동 포스팅 봇을 운영하던 중 발생한 치명적인 '마크다운 파싱 오류'와 이를 정규식(Regex)으로 해결한 과정을 기록합니다. 자동화 시스템이 뱉어낸 반쪽짜리 원고에 당황했던 경험이 있다면, 이 트러블슈팅 과정을 주목해 주시기 바랍니다.

완벽할 줄 알았던 포스팅 봇의 배신

수십 줄의 코드를 작성하고 여러 번의 테스트를 거쳐 티스토리 자동 포스팅 파이프라인의 뼈대를 완성했습니다. 하지만 기쁨도 잠시, 봇을 가동하여 새로운 원고를 주입하자마자 에디터 화면을 보고 두 눈을 의심했습니다. 분명히 제가 넘겨준 원고는 기승전결이 갖춰진 긴 글이었는데, 정작 티스토리 에디터에는 글이 중간까지만 적히다 말고 뚝 끊겨 있었기 때문입니다.

마치 누군가 가위로 문서를 싹둑 자른 것처럼 기괴하게 잘려나간 화면이었습니다. 에러 로그도 없이 묵묵히 멈춰버린 이 현상, 도대체 어디서부터 문제가 생긴 걸까요?

에러의 진원지: 마크다운 코드 블록(```)과 파서 충돌

문제의 원인을 찾기 위해 잘려나간 지점을 유심히 살펴보니 흥미로운 공통점이 있었습니다. 바로 글이 끊긴 정확한 위치가 파이썬 코드 블록이 시작되는 바로 그 지점이었다는 사실입니다.

처음에는 티스토리 에디터의 Open API가 마크다운을 제대로 소화하지 못한 것이라 의심했습니다. 하지만 디버깅 결과, 진짜 범인은 티스토리가 아니라 제 로컬 PC의 파이썬 환경 세팅과 정규식 파서(Regex Parser)의 충돌에 있었습니다.

패키지 의존성의 나비효과

포스팅 봇 내부에는 텍스트를 HTML로 예쁘게 변환해 주는 로직이 들어있습니다. 보통 markdown이라는 검증된 파이썬 라이브러리를 사용합니다. 하지만 당시 제 PC 가상환경에는 이 변환의 핵심 엔진인 패키지가 설치되어 있지 않았습니다.

핵심 라이브러리가 없자, 봇은 내부에 예외 처리용으로 하드코딩해 둔 '임시 정규식 파서'를 가동했습니다. 이 엉성한 정규식이 여러 줄로 이루어진 파이썬 코드 블록(```)을 만나자마자 개행 문자와 특수 기호를 해석하지 못하고 렌더링에 실패하며 체해버린 것입니다. 결국 시스템은 코드 블록 이후의 모든 텍스트를 통째로 허공에 날려버렸습니다.

마크다운 파싱 오류를 분석 중인 파이선생 개발자

정규식(Regex) 처리 방식과 복구 로직 설계

이 문제를 근본적으로 해결하기 위해 두 가지 방식을 병행했습니다.

1. 정식 파서 도입: 가장 안전한 방법은 pip install markdown 명령어를 통해 정식 라이브러리를 의존성에 추가하는 것입니다.
2. 정규식(Regex) 안전장치 보강: 만약 외부 라이브러리 로드에 실패하더라도 글이 끊기지 않도록, 파이썬 코드 블록의 ``` 백틱 기호를 안전하게 이스케이프(Escape)하고 HTML <pre><code> 태그로 치환해 주는 강력한 정규식 로직으로 파서를 전면 리팩토링했습니다.

특히 다중 줄바꿈(\n)이 포함된 코드 블록을 탐지하기 위해 re.compile(r'```(.*?)```', re.DOTALL) 구문을 적용하여 정규식이 여러 줄을 정상적으로 인식하도록 방어 코드를 구축했습니다.

정규식 수정을 통해 티스토리 파싱 오류를 완벽히 해결하고 안도하는 파이선생

오늘의 교훈 및 재발 방지 체크리스트

때로는 콘솔 창에 시뻘건 에러 메시지가 뜨지 않아도 치명적인 버그가 숨어있을 수 있습니다. 데이터가 조용히 유실되는 사일런트(Silent) 에러가 가장 무섭습니다. 이 경험을 바탕으로 시스템 재발 방지를 위한 체크리스트를 정립했습니다.

• 재발 방지 체크리스트
• [ ] 프로젝트 셋업 시 requirements.txt에 마크다운 등 핵심 의존성 패키지가 누락되지 않았는지 점검할 것
• [ ] 예외 처리용 Fallback 코드를 작성할 때는 정규식(re.DOTALL 등)이 다중 행(Multi-line) 텍스트를 완벽히 커버하는지 반드시 테스트할 것
• [ ] 발행 전 파이썬 스크립트 단에서 원고의 Byte 길이와 변환된 HTML의 Byte 길이를 대조하여 데이터 유실 여부를 검증하는 방어 로직 추가할 것

1인 기업의 자동화 시스템은 결국 작은 예외 처리 하나가 전체의 안정성을 좌우합니다. 깨지기 쉬운 정규식 편법보다 견고한 정석의 파이프라인을 설계해야 한다는 중요한 교훈을 얻었습니다.