자동화
n8n / 스크립트 / 봇
-
새벽 두 시, 자동 발행 파이프라인이 조용히 죽어 있었다
새벽 두 시에 알림이 없다는 게 문제였다. 정확히는 — 알림이 와야 하는데 오지 않았고, 발행도 되지 않았다. 스케줄러가 돌고 있다는 착각 속에 파이프라인은 이미 한참 전부터 멈춰 있었다.
읽기 → -
블로그 자동화 파이프라인을 통째로 갈아엎은 새벽
왜 바꿨나 — "커밋마다 글 하나"의 한계
읽기 → -
새 도메인 rate-limit 자동 적용으로 보안 실수 없애기
신규 도메인을 온보딩할 때마다 수동으로 Cloudflare rate-limit 설정을 하던 과정을 자동화로 전환했다. 문서도 정책도 함께 정리해서 "신규 도메인은 무조건 rate-limit이 적용된다"는 명확한 기본값을 만들었다.
읽기 → -
주간 주기 자동 갱신 작업, 문서화 추가
CLAUDE.md에 주간 통계 자동갱신의 cron 스케줄과 실행 스크립트를 기록했다. 작은 변경처럼 보이지만, 팀의 자동화 작업들을 가시화하는 중요한 스텝이었다.
읽기 → -
렌더링 대량 백필을 4배 단축
렌더링 작업의 백필을 처리할 때, sleep 시간을 동적으로 조절할 수 있는 --fast 플래그를 추가했다. 1회성 대량 작업에서는 sleep을 0.7~1.5초로 단축해서 처리 시간을 크게 줄이고, 반복 실행되는 cron 작업에서는 기본값 3~5초를 그대로 유지해서 시스템 부하를 균형 있게 관리하는 구조다.
읽기 → -
백그라운드 루프 중단을 자동으로 감지하기
정기적으로 돌아야 하는 배경 작업이 조용히 멈추면 서비스는 수일간 대응 없이 데이터가 낡아간다. 이번에 학습/SEO 루프의 생사를 자동으로 감시하고 Discord와 Telegram으로 즉각 알람하는 health-monitor 기능을 추가했다. 팀이 야간이나 주말이라도 멈춤을 놓치지 않도록.
읽기 → -
자동화 장애가 사라지면 문서도 사라진다
신규 사이트를 온보딩할 때마다 체크리스트를 따라 몇십 개 항목을 확인한다. API 키 설정부터 시작해 권한, 스키마, 모니터링까지. 그런데 문서에는 없는데 실제로는 매일 도는 작업이 하나 있었다. 바로 **드리프트 감지 알림**.
읽기 → -
Featured 영역 정렬 버그 수정, 여백 제거
Featured 콘텐츠 섹션에서 불필요한 빈 공간(void)이 생겨 레이아웃이 흐트러지던 버그를 고쳤다. 단순한 여백 조정 같지만, 프론트엔드 배포에서 자주 마주치는 전형적인 문제 유형이다.
읽기 → -
단일 소스로 정보 산재 해결하기
sites.json을 단일 진실(single source of truth)로 정하고, 여기서 메인 페이지·깃헙 공개 정보를 자동으로 생성하는 자동화를 구축했다. 여러 곳에 흩어진 사이트 메타데이터를 한곳에서 관리하면서 반복 작업을 제거하고 팀의 온보딩 프로세스를 단순화한 경험을 나눈다.
읽기 → -
사이트맵 제출 자동화로 검색 인덱싱 가속화
여러 이커머스 사이트를 운영하다 보면 Google Search Console(GSC)에 사이트맵을 등록·제출하는 작업이 반복된다. 각 사이트마다 GSC 대시보드에 접속해서 사이트맵 URL을 수동으로 입력하고 제출 상태를 추적하는 것이 적지 않은 수고가 들어가곤 했다. 이번에 이 과정을 자동화하는 파이프라인을 구축해서, 신규 사이트 추가 시에도 수동 개입 없
읽기 → -
트래픽 모니터링에 신규 프로필 자동 추가
Google Search Console 인증만으로 새로운 데이터 소스가 자동 연동되도록 traffic-watcher를 확장했다. 기존 kpopdex 패턴을 그대로 가져가되, 불필요한 커스텀 로직은 없앴다.
읽기 → -
자동화 봇의 하루 3회 크론 지침 정정
CLAUDE.md에서 telebot의 자동화 크론 작업 관련 지침을 다시 정리했다. "stale 정정"이라는 표현은 간단해 보이지만, 실제로는 문서와 현실의 괴리를 메웠다는 뜻이다.
읽기 → -
자동화 봇 운영 기반 정식 문서화
인프라 자동화 시스템들이 프로덕션에서 실제로 동작하기 시작했고, 그에 따른 운영 체계를 CLAUDE.md에 정리했다. 개별 변경들은 작아 보이지만 누적되면 팀 전체의 신뢰성을 좌우하는 결정들이다.
읽기 → -
크론 스케줄과 동적 제출 로직을 하네스에 문서화
CLAUDE.md에 IndexNow 자동화 작업의 크론 스케줄과 그룹 동적 제출 로직을 기록했다. 단순해 보이는 문서 업데이트지만, 자동화 시스템을 운영하는 입장에서는 꽤 중요한 작업이다.
읽기 → -
연도 범위 한계 극복과 문서화 강화
discover_groups 봇이 그룹 데이터를 수집할 때 연도 범위가 고정돼 있었다. 이번 작업에서 그 범위를 확대하고 동시에 문서를 정리했다.
읽기 → -
API 속도 제한으로 느려지던 자동화 봇 안정화
멤버 정보를 외부 API에서 수집해 enriching 하는 봇(enrich_member_bio.py)이 Wikipedia 의 429 Too Many Requests 에러로 자주 중단되곤 했다. 이번에 요청 방식을 개별 fetch 에서 group-level fetch 로 개선해서 API 속도 제한을 회피하게 했다.
읽기 → -
자동화 작업 관리 규칙 문서화
CLAUDE.md에 discover_talents 잡과 cron 인벤토리를 반영했다. 겉보기론 단순한 문서 업데이트지만, 프로젝트의 자동화 작업을 어떻게 체계적으로 관리할지를 팀에 명시하는 작업이었다.
읽기 → -
버튜버 발견 자동화, 검증 게이트로 품질 보증하기
신규 버튜버를 수동으로 찾고 등록하는 프로세스에 자동화 기능을 들였다. discover_talents 잡을 새로 만들어서 공식 채널과 인디 크리에이터를 구분해 처리하고, 인디 경로에는 검증 게이트를 달아 오류를 줄이려고 했다.
읽기 → -
멤버 카드에 퀵팩트 정보 추가하기
멤버나 그룹의 흥미로운 사실들을 데이터베이스에서 가져와 카드 형태로 보여주는 기능을 구현했다. 커밋 메시지에 B1+B2+B3 로 표기한 건, 이 작업이 세 계층으로 명확히 분리됐다는 의도를 담은 것. 데이터베이스 스키마 설계부터 봇의 enrichment 로직, 마지막으로 프론트엔드 UI 렌더링까지 순서대로 쌓은 거다.
읽기 → -
색인요청이 support 팀 손에 닿지 않던 이유
지난주 한 서비스의 검색엔진 최적화(SEO) 운영 흐름을 점검하다가 흥미로운 병목을 찾았다. Google Search Console(GSC) 색인요청이라는 정기적인 작업이 특정 계정(dev.slecs, authuser=1)에만 가능했고, support 팀은 이 작업을 수행할 권한이 없었던 것이다. 그간 이 부분이 구두로만 전달되다 보니 새로운 팀원들이 합류
읽기 →