발행 후 검색 엔진 등록 자동화로 수동 작업 제거

지난주에 인덱싱 핑과 팀 알림을 발행 파이프라인과 한 곳에 묶어냈다. 내용 발행 직후 검색 엔진에 자동으로 크롤링을 요청하고, 동시에 Discord에도 현황을 보고하도록 흐름을 통합한 작업이다.

왜 필요했나

지금까지는 내용을 발행한 뒤, 검색 엔진(특히 Bing의 IndexNow API)에 등록해달라고 수동으로 요청하거나 한 발 늦게 처리하곤 했다. SEO 관점에서는 발행과 인덱싱 요청 사이의 지연이 결국 검색 결과 노출 시간으로 이어지고, 팀 입장에서도 "지금 뭐 발행됐나" 같은 상황 공유가 Slack이나 구두로만 이루어져 추적이 어려웠다. 결국 두 가지 수동 작업이 있었고, 이게 자동화 대상이 명확했다.

파이프라인에 두 개 층을 한 번에 추가

설계는 간단하게 했다. publish.sh는 기존에 "내용을 생성하고 배포하는" 일을 담당했다. 여기에 한 줄만 추가해서 발행 완료 후 IndexNow 핑을 날리고, 동시에 Discord 메시지(제목, 발행 시각, 링크 등)를 보내도록 했다. 별도의 크론(cron) 작업이나 webhook을 만들지 않고, 기존 발행 흐름의 "끝에 덧붙이는" 구조를 택한 이유는 두 가지다:

• 강한 인과관계: 발행이 이루어지지 않은 상태에서 인덱싱 핑을 날릴 이유가 없다. 파이프라인 안에서 순차적으로 처리해야 실패 케이스도 명확하다.
• 팀의 가시성: Discord 메시지가 정확히 언제 나갈지가 명확하고, 누가 뭘 발행했는지 이력이 한 곳에 모인다.

물론 이 방식은 발행 스크립트가 조금 더 무거워진다는 단점이 있다. indexnow-ping.js가 시간 초과(timeout)되거나 실패하면 전체 발행 프로세스를 고려해야 하니까. 그래서 구현할 때는:

# publish.sh 의사 흐름
1. 내용 빌드
2. 배포
3. indexnow-ping.js 호출 (실패해도 경고만 함)
4. Discord 메시지 전송 (실패해도 스크립트 자체는 성공 취급)

발행이 이미 완료된 상태에서 핑이나 알림이 실패하는 것보다는, 발행 자체를 막기보다는 "느슨한 연결"로 처리했다. 즉, indexnow-ping 실패가 배포 전체 실패로 이어지지 않도록.

회고 포인트

처음에는 "IndexNow와 Discord 알림을 별도 서비스로 두고 publish 완료 후 각각을 async로 호출"할 생각도 했다. 하지만 팀 규모와 운영 복잡도를 생각하면, 현재 구조(publish.sh 안에 순차 호출)가 낫다고 판단했다. 나중에 알림이 늘어나면(Slack, 이메일, 대시보드 등) 그때 별도 서비스로 분리해도 된다. 지금 당장 하는 건 과설계다.

또 하나 배운 건, 이런 자동화를 추가할 때 "어느 단계에 끼워넣을지"가 매우 중요하다는 것. 너무 일찍 끼워넣으면(빌드 중간) 실패 처리가 복잡해지고, 너무 늦게 끼워넣으면(배포 후 별도 크론) 발행과 인덱싱이 "같은 이벤트"로 추적되지 않는다. 이번 경우는 배포 직후, "모든 게 성공했을 때만"이라는 보장 하에서 호출하는 게 맞았다.

앞으로 publish 흐름에 단계가 더 추가되면, 각 단계의 성공/실패를 더 세밀하게 로깅하는 방향으로 갈 것 같다. 지금은 간단한 echo로 충분하지만, 나중엔 structured log와 error tracking이 필요할 테니까.

🛒 이 글과 어울리는 추천 상품

• 모니터 쿠팡에서 보기 →
• 외장SSD 쿠팡에서 보기 →
• 기계식키보드 쿠팡에서 보기 →

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.