파이썬 자동화 스크립트 하나로 합쳤다가 발생한 치명적인 중복 사고

파이썬 자동화 스크립트 하나로 합쳤다가 발생한 치명적인 중복 사고

안녕하세요, 파이선생입니다.

지금까지 저는 블로그 자동화 시스템을 구축하면서, "하나의 완벽한 스크립트"가 모든 것을 해결해 줄 것이라는 환상에 빠져 있었습니다. 그래서 신규 글을 등록하는 기능과 기존 글을 수정하는 기능을 하나의 파이썬 파일로 합쳐서 사용하고 있었죠.

로직상으로는 아무 문제가 없어 보였습니다. 특정 값을 입력하면 수정 모드로, 입력하지 않으면 신규 발행 모드로 작동하게 만들었기 때문입니다. 그러나 이 사소한 오만이 실제 블로그 운영에서 끔찍한 대참사를 불러오고 말았습니다.

문제: 아찔했던 중복 발행 참사

사건의 발단은 단순한 오타 수정이었습니다. 이전에 올렸던 글의 오타를 발견하여, 스크립트를 통해 내용을 수정하려고 했습니다. 그런데 급한 마음에 터미널에서 명령어를 입력할 때, 기존 글을 지정하는 필수 식별값을 빼먹고 실행해버린 것입니다.

스크립트는 어떻게 반응했을까요? 식별값이 입력되지 않았으니, 스크립트는 이를 '새로운 글을 쓰라는 명령'으로 인식했습니다. 그리고는 기존 글을 수정하는 대신, 똑같은 내용의 글을 새로운 글로 다시 올려버렸습니다.

그 결과, 실제 블로그에는 아래와 같이 똑같은 제목과 내용의 글이 단 2초 간격으로 연속해서 올라가는 참사가 발생했습니다.

실제 중복 발생 사고 당시의 블로그 캡처본

글 관리 창을 열어본 순간, 저는 등골이 오싹해졌습니다. 만약 여러 개의 포스팅을 일괄적으로 수정하는 스크립트를 이런 식으로 잘못 실행했다면? 똑같은 글 수십 개가 새로 도배되면서 스팸 블로그로 낙인찍혀 애드센스 등 모든 검색 노출이 정지당할 수도 있는 치명적인 버그였습니다.

원인: 하나의 스크립트가 가진 너무 많은 책임

문제의 핵심은 하나의 스크립트가 너무 많은 권한과 역할을 가지고 있었다는 점입니다.

소프트웨어 공학에는 단일 책임 원칙이라는 것이 있습니다. 하나의 코드는 단 하나의 책임만 가져야 한다는 원칙이죠. 하지만 저의 스크립트는 새로운 글 작성과 기존 글 수정이라는, 완전히 성격이 다른 두 가지 중대한 작업을 모두 처리하고 있었습니다.

사람은 누구나 실수를 합니다. 터미널에서 명령어 하나를 빼먹는 실수는 언제든 일어날 수 있습니다. 하지만 시스템은 사람의 실수를 시스템적으로 방어할 수 있도록 설계되어야 합니다. 명시적인 식별값이 없을 때 그것을 무조건 새로운 글로 해석해버리는 암묵적인 분기 처리는 폭탄을 안고 있는 것과 같았습니다.

해결: 발행과 수정 기능의 완벽한 분리

저는 즉시 시스템 구조를 뜯어고쳤습니다. 하나로 묶여 있던 스크립트를 물리적으로 완전히 분리하여 두 개의 별도 스크립트로 나누었습니다.

1. 신규 작성 전용 스크립트: 오직 새로운 글만 작성합니다. 이 스크립트에서는 기존 글을 지정하는 식별값을 아예 받지 않으며, 만약 강제로 입력할 경우 즉시 에러를 발생시키고 멈춥니다.
2. 글 수정 전용 스크립트: 오직 기존 글 수정만 담당합니다. 이 스크립트를 실행할 때는 반드시 수정할 글의 대상을 지정해야 하며, 누락될 경우 새로운 글로 넘어가는 것이 아니라 스크립트가 실행조차 되지 않고 즉각 차단됩니다.

아래는 분리된 스크립트가 적용된 후, 제가 똑같은 실수를 저질렀을 때 시스템이 어떻게 방어해 내는지 보여주는 화면입니다.

명령어 누락 시 구조적으로 철저히 방어되는 터미널 화면

화면에서 보시다시피, 이제는 명확한 에러 메시지와 함께 스크립트가 안전하게 중단됩니다. 더 이상 오타 하나 때문에 블로그가 똑같은 글로 도배되는 악몽을 겪지 않아도 됩니다!

결과 및 배운 점: 방어벽의 중요성

글 작성과 수정을 철저히 분리하여 작업하는 모습

기능을 통합하고 합치는 것만이 능사는 아니라는 것을 뼈저리게 느꼈습니다. 때로는 명확한 책임의 분리와 물리적인 차단이 가장 훌륭한 시스템 방어책이 됩니다.

이번 트러블슈팅을 통해 저의 자동화 시스템은 한층 더 견고해졌습니다. 단순한 효율성만 좇다가 발생할 수 있는 치명적인 리스크를, 시스템 구조적인 관점에서 원천 차단하는 방법을 배웠습니다.

앞으로는 어떠한 기능을 자동화하더라도 "사람의 실수를 시스템이 어떻게 1차적으로 방어할 것인가?"를 가장 먼저 고민하게 될 것 같습니다.

안전하고 튼튼한 자동화 시스템을 구축하는 그날까지, 파이선생의 우당탕탕 트러블슈팅은 계속됩니다!

기술적 구현의 어려움과 극복 과정

이러한 분리 작업을 진행하면서 가장 먼저 맞닥뜨린 기술적 어려움은, 두 스크립트 간의 중복 코드를 어떻게 우아하게 처리할 것인가 하는 문제였습니다. 발행 스크립트와 수정 스크립트는 본질적으로 티스토리 API와 통신하고, 셀레니움을 통해 브라우저를 제어한다는 공통점을 가지고 있습니다. 만약 이 두 파일에 똑같은 로그인 코드나 브라우저 설정 코드를 복사해서 붙여넣는다면, 나중에 구조가 변경될 때 두 곳을 모두 수정해야 하는 또 다른 문제를 낳게 됩니다.

이를 해결하기 위해 저는 공통적으로 사용되는 유틸리티 함수들(예: 브라우저 초기화, 셀레니움 옵션 설정, API 토큰 검증 등)을 별도의 모듈로 추상화하였습니다. 이렇게 하면 발행과 수정 스크립트는 오직 자신만의 고유한 로직, 즉 '새로운 글을 쏠 것인가' 아니면 '기존 글의 내용을 덮어쓸 것인가'에만 집중할 수 있습니다.

단일 책임 원칙은 단순히 스크립트 파일을 나누는 것을 넘어, 코드의 내부 구조를 어떻게 모듈화할 것인지에 대한 깊은 고민을 요구합니다. 이번 작업을 통해 클래스와 함수의 책임을 명확히 구분하는 것이 장기적인 유지보수성에 얼마나 큰 영향을 미치는지 실감할 수 있었습니다. 특히 블로그 자동화와 같이 여러 단계의 파이프라인이 유기적으로 연결된 시스템에서는 이러한 원칙이 시스템의 생명줄과도 같습니다.

이 경험이 주는 시사점

파이썬을 활용한 자동화는 분명 우리의 시간을 아껴주고 생산성을 극대화해주는 강력한 무기입니다. 하지만 무기에는 항상 안전장치가 필요합니다. 제가 겪은 이번 중복 발행 사고는, 안전장치 없이 효율성만 좇았을 때 어떤 대가를 치러야 하는지를 명확히 보여주는 뼈아픈 교훈이었습니다.

우리는 종종 하나의 거대한 스크립트가 모든 것을 알아서 처리해주기를 기대합니다. 하지만 현실의 시스템은 항상 예기치 못한 변수와 인간의 실수에 노출되어 있습니다. 입력값이 누락되었을 때, 네트워크가 끊겼을 때, API 서버가 응답하지 않을 때 시스템이 어떻게 행동해야 하는지를 미리 정의해두지 않으면, 시스템은 곧바로 통제 불능의 상태에 빠집니다.

명시적인 거절과 차단은 때로는 최고의 안전 장치입니다. 조건이 맞지 않으면 과감하게 실행을 중단하고 사용자에게 경고를 보내는 시스템이야말로 진정으로 신뢰할 수 있는 시스템입니다. 이번 블로그 구조 개편은 단순한 코드 수정을 넘어, 견고한 소프트웨어 아키텍처를 설계하는 첫 걸음이 되었습니다.

앞으로 이어질 자동화 프로젝트에서도 항상 '실패를 가정한 설계(Design for Failure)'를 염두에 두고, 더 안전하고 강력한 시스템을 구축해 나가겠습니다.

개발자의 오만과 자동화의 역설

돌이켜보면, 저는 자동화 시스템을 구축하면서 무의식적으로 '나는 실수하지 않을 것'이라는 오만에 빠져 있었던 것 같습니다. 키보드 타이핑 몇 번으로 티스토리 서버에 글이 올라가는 마법 같은 경험에 취해, 그 이면에 도사리고 있는 위험성을 간과한 것이죠. 시스템이 고도화될수록 인간의 개입을 최소화하는 것이 자동화의 목표지만, 역설적이게도 그럴수록 시스템의 안전성은 더욱 철저한 인간의 통제 아래 설계되어야 한다는 점을 깨달았습니다.

제가 작성했던 스크립트처럼, 파라미터 하나의 누락이 완전히 다른 결과를 낳는 구조는 언제 폭발할지 모르는 시한폭탄과도 같습니다. 이러한 구조적 결함을 발견하고 스스로 해결해나가는 과정이야말로, 진정한 1인 개발자로 성장하는 밑거름이 될 것이라 확신합니다.

성공적인 블로그 자동화는 결코 단 한 번의 시도로 이루어지지 않습니다. 수많은 시행착오와 치명적인 실수들을 경험하고, 이를 바탕으로 시스템을 끝없이 보수해 나가는 기나긴 여정입니다. 다음 포스팅에서는, 이렇게 튼튼해진 발행 시스템 위에 또 어떤 재미있는 자동화 기능을 덧붙일지 기대해 주시기 바랍니다!