끄적끄적

자동화 도구가 내 글을 덮어썼다 — 수정 발행과 되돌릴 수 없는 작업의 안전장치

지난 글에서는 포스팅의 품질을 유지하기 위해 글자 수, 마크다운 형식, 헤더 계층을 검증하는 아직 쓰면 안 되는 글을 막는 법 — 발행 조건 게이트 구현에 대해 다루었습니다. 검증 게이트를 통과한 완벽한 글이라 할지라도, 이를 실제 블로그에 발행하는 마지막 단계에서 치명적인 오작동이 발생한다면 모든 노력이 수포로 돌아갑니다. 특히 이미 정상적으로 발행되어 검색 엔진에 색인된 기존 글을 자동화 프로그램이 실수로 덮어써 버리는 대참사는 1인 개발자에게 가장 두려운 시나리오 중 하나입니다. 이번 글에서는 자동화 시스템이 기존 글을 덮어쓰는 사고를 방지하기 위해 구축한 이중 안전장치와 수정 발행 제어 시스템의 설계 및 구현 과정을 상세히 공유합니다.자동화의 양날의 검, '덮어쓰기' 대참사의 전말웹 브라우저를 직..

지난 글에서 AI가 존재하지 않는 수치를 무단으로 조작하거나 환각을 일으키는 문제를 방지하기 위해 AI가 없는 숫자를 지어내지 못하게 막기 — 사실 원장 만들기를 통해 사실 검증 시스템을 구축했습니다. 그렇다면 팩트 체크를 무사히 통과했더라도, 글의 형식적 완성도가 떨어지거나 블로그 운영 정책에 맞지 않는 불완전한 상태의 글이 실수로 발행되는 참사는 어떻게 막을 수 있을까요?아무리 뛰어난 거대 언어 모델(LLM)이라도 간혹 출력을 중간에 멈추거나, 마크다운 문법을 깨뜨리거나, 지정한 필수 키워드를 누락하는 일이 발생합니다. 이러한 불완전한 원고가 사람의 검토 없이 Selenium 자동화 스크립트를 타고 블로그에 그대로 발행된다면, 블로그의 품질 지수는 물론 검색 엔진 최적화(SEO) 관점에서도 치명적인 ..

지난 글에서 로컬 JSON 데이터베이스를 설계하여 AI가 이전 글의 맥락을 기억하게 만드는 맥락 주입 엔진을 구현했습니다. 연재의 흐름을 매끄럽게 이어가는 데 성공했지만, 자동화를 계속 진행하면서 또 다른 거대한 장벽에 부딪히게 되었습니다. 바로 대형 언어 모델(LLM)이 존재하지 않는 수치나 거짓 정보를 그럴듯하게 지어내는 환각(Hallucination) 현상입니다.특히 블로그 운영이나 프로젝트 개발 기록을 자동화할 때, AI가 방문자 수, 수익, 작업 소요 시간 등의 숫자를 임의로 창작해 내는 것은 글의 신뢰도를 완전히 무너뜨리는 치명적인 요인입니다. 이번 글에서는 "어떻게 하면 AI가 없는 숫자를 지어내지 못하게 원천 차단하고, 오직 검증된 사실만을 기반으로 글을 쓰게 만들 수 있을까?"라는 질문에..

지난 글에서 우리는 화면이 바뀌거나 네트워크가 끊겨도 시스템이 멈추지 않고 데이터를 보존하는 견고한 자동화 파이프라인을 구축했습니다. 하지만 브라우저를 제어하고 예외를 처리하는 물리적 안정성을 확보했음에도 불구하고, 정작 생성되는 콘텐츠의 품질이 유기적으로 이어지지 않는다면 장기 연재물로서의 가치는 떨어질 수밖에 없습니다. 어떻게 하면 매번 글을 쓸 때마다 이전 글의 맥락을 수동으로 복사해서 붙여넣지 않고, AI가 스스로 연재의 흐름을 파악하여 자연스럽게 이어 쓰도록 자동화할 수 있을까요?이 질문에 답하기 위해, 저는 로컬 환경에서 구동되는 파이썬 시스템에 연재 맥락 주입 엔진과 발행 이력 자동 기록 시스템을 직접 구현했습니다. 이번 글에서는 단발성 글쓰기를 넘어 하나의 완성도 높은 연재 브랜딩을 구축하..

지난 글인 티스토리 로그인을 매번 다시 안 하려면 — 크롬 프로필 재사용에서 우리는 매번 카카오 계정 로그인과 2차 인증을 거치지 않고, 기존 세션을 그대로 유지한 채 브라우저를 제어하는 물리적인 기반을 마련했습니다. 로그인 장벽을 우회하여 에디터 진입까지 성공했다면, 이제 마주하게 되는 진짜 문제는 '자동화의 지속 가능성' 입니다.웹 서비스는 살아있는 생물과 같아서 개발사의 의도에 따라 UI가 수시로 변경되며, 로컬 네트워크의 일시적인 지연으로 요소를 제때 화면에 그리지 못하는 일이 빈번하게 발생합니다. 어제까지 잘 돌던 코드가 오늘 아침 갑자기 에러를 뿜으며 멈추는 현상은 웹 자동화를 구축한 개발자라면 누구나 겪는 고질적인 문제입니다.이번 글에서는 이 문제를 정면으로 해결하고자 합니다. "티스토리 에..

지난 글에서 파이썬으로 변환한 HTML 코드를 티스토리 에디터의 복잡한 iframe 장벽을 뚫고 안전하게 주입하는 과정을 다루었습니다. 그렇다면 이 자동화 스크립트가 실행될 때마다 매번 카카오 계정 로그인과 2차 인증이라는 번거로운 과정을 거치지 않고, 어떻게 기존 로그인 세션을 안전하게 유지하며 글쓰기 단계로 바로 진입할 수 있을까요?티스토리 자동화 시스템을 구축할 때 가장 먼저 마주치는 거대한 벽은 다름 아닌 로그인 보안입니다. 카카오 계정은 해외 IP 차단, 기기 로그인 제한, 2차 인증(2FA) 등 강력한 보안 정책을 적용하고 있기 때문에, 일반적인 Selenium 코드로 매번 아이디와 비밀번호를 타이핑해 로그인하는 방식은 즉시 캡차(CAPTCHA)나 본인 인증 요구 화면으로 이어집니다. 이 문제..

지난 글에서는 프롬프트를 역할, 구조, 제약으로 삼분할하여 외부 파일로 관리하고, 이를 파이썬 코드로 동적 조립하는 프롬프트 빌더 시스템을 구현했습니다. 이를 통해 Gemini API와 Claude API로부터 우리가 원하는 완벽한 마크다운(Markdown) 형식의 블로그 본문 텍스트를 안정적으로 얻어낼 수 있게 되었습니다.그렇다면 이렇게 생성된 마크다운 텍스트를 어떻게 티스토리 에디터에 실제로 입력할 수 있을까요? 단순히 에디터 창을 열고 키보드 입력을 복사해서 붙여넣거나, Selenium의 send_keys 메소드로 한 글자씩 타이핑하는 방식은 본문의 서식이 모두 깨지거나 전송 속도가 극단적으로 느려지는 치명적인 문제를 발생시킵니다.이번 글에서는 파이썬으로 생성한 마크다운 문서를 깔끔한 HTML로 변..

지난 글에서 API 키와 블로그 주제 데이터를 파이썬 코드 외부로 완전히 격리하여 환경 설정 파일로 관리하는 구조를 다루었습니다. 이제 외부에서 정제된 주제와 키워드를 가져와 실제 블로그 본문으로 가공할 차례인데, 여기서 핵심은 어떻게 하면 매번 일정한 품질의 글을 AI로부터 안정적으로 얻어낼 수 있는가 하는 프롬프트 제어의 문제입니다.단순히 하나의 거대한 문자열로 프롬프트를 작성해 API에 던지는 방식은 초기 개발 단계에서는 빠르고 편리하지만, 자동화 시스템이 고도화될수록 유지보수가 불가능한 재앙으로 변합니다. 특히 비용 절감을 위해 gemini-3.5-flash 모델을 메인으로 사용하고, 고품질의 심층 분석이 필요한 영역에만 claude-sonnet-4-6 모델을 교차 투입하는 하이브리드 구조에서는 ..

지난 글에서는 웹앱 대신 로컬 데스크톱 환경을 선택하고, 파이썬 Tkinter를 활용하여 멀티스레드 기반의 GUI 제어부를 설계하는 과정을 다루었습니다. 화면 인터페이스를 갖추고 나니 프로그램의 외형은 완성되었지만, 실제 운영 단계로 넘어가기 위해 해결해야 할 중요한 설계적 숙제가 생겼습니다. 바로 API 키, 크롬 프로필 경로와 같은 환경 설정 데이터와 매일 발행할 블로그 주제 목록을 어떻게 관리할 것인가 하는 점입니다. 이 값들을 파이썬 코드 내부에 직접 입력(Hardcoding)하는 것은 보안상으로도 위험하며, 매번 주제를 바꿀 때마다 코드를 수정해야 하는 비효율을 초래합니다. 코드와 데이터를 완전히 분리하여 프로그램의 안정성과 확장성을 극대화하는 파일 관리 구조를 설계하고 구현한 과정을 상세히 공..

지난 글인 블로그 자동화 프로그램, 어디까지 자동으로 할지 경계 정하기에서 우리는 인간의 개입을 허용하는 하이브리드 워크플로우의 필요성과 상태 관리 설계에 대해 다루었습니다. 완전 자동화의 기술적 한계를 인정하고 중간 검수 단계를 도입하기로 결정하면서, 자연스럽게 이를 제어할 사용자 인터페이스(UI)가 필요해졌습니다. 그렇다면 이 하이브리드 제어부와 상태 관리 화면을 구현하기 위해, 왜 대세인 웹 기반 앱(Web App) 대신 구시대의 유물처럼 여겨지는 데스크톱 GUI 라이브러리인 Tkinter를 선택했을까요?이 글에서는 1인 개발자로서 한정된 자원과 시간 속에서 내린 아키텍처 선택의 기준과, 실제 로컬 환경에서 Selenium과 GUI를 충돌 없이 결합하기 위해 고군분투했던 기술적 구현 과정을 상세히 ..