← 블로그 · Projects
데드링크 검수 배치: 실패 응답을 곧바로 삭제 사유로 삼지 않기
#회고 #자동화 #배치 #운영
유주환 · Founder, Full Stack Developer
토리스(Toris) · 발행
프로젝트를 돌아보는 30일 · 14/30
과거 프로젝트 경험을 날짜별로 엮은 회고입니다. 표시 날짜는 연재 기준일이며, 실제 작업일과 다를 수 있습니다.
콘텐츠 관리 업무에서 데드링크를 검수하는 배치를 다뤘다. 링크가 살아 있는지 사람이 하나씩 열어 보는 반복 작업을 줄이는 목적이었다. 처음에는 HTTP 요청을 보내 결과를 모으면 될 것처럼 보이지만, 외부 시스템의 실패를 해석하는 일이 그보다 어려웠다.
응답 실패와 콘텐츠 종료는 다르다
시간 초과는 상대 서버가 느린 것일 수 있다. 접근 제한은 자동 요청을 막은 것일 수 있다. 리다이렉트가 있다는 사실만으로 원래 콘텐츠를 볼 수 없다고 판단할 수도 없다. 검수 결과를 단순한 참·거짓으로 줄이면 운영자가 다시 확인해야 하는 이유가 사라진다.
당시 경험을 돌아보며, 자동화가 잘하는 것은 관찰이고 최종 판단은 별도라는 기준을 세우게 됐다. 모든 실패를 삭제나 비공개 처리로 즉시 연결하는 것은 지나치다. 특히 서비스 밖의 링크는 내가 서버 상태를 통제할 수 없기 때문에 결과의 불확실성을 보존해야 한다.
지금이라면 이렇게 나누겠다
| 관찰 결과 | 운영자가 할 수 있는 다음 행동 |
|---|---|
| 정상 응답 | 마지막 확인 시각 갱신 |
| 시간 초과·일시 오류 | 간격을 두고 재확인 |
| 접근 제한 | 수동 브라우저 확인 대상으로 분리 |
| 반복되는 없음 응답 | 원문 종료 여부 검토 |
이 표는 당시 배치의 정확한 구현을 재현한 것이 아니다. 같은 기능을 다시 만든다면 적용할 분류 기준이다. 응답 코드, 확인 시각, 최종 도착 주소 정도의 관찰 근거가 있어야 사람이 판단을 이어 갈 수 있다.
자동화의 결과도 검수 대상이다
한 번에 많은 주소를 확인하면 상대 사이트와 우리 시스템 양쪽에 부담을 줄 수 있다. 지금이라면 동시 실행 수와 제한 시간을 명시하고, 중간에 멈췄을 때 어디서 재개할지 정하겠다. 배치 자체가 성공했다는 것과 모든 링크를 확인했다는 것도 구분해서 보고하겠다.
내게 이 경험의 가치는 자동화로 몇 시간을 절약했다는 숫자에 있지 않다. 그 수치를 별도로 측정하지 않았다면 붙일 수 없다. 대신 사람이 반복해서 열어 보던 작업을 확인 가능한 목록으로 바꾸는 방향을 배웠다. 자동화는 결론을 서두르는 도구보다 판단에 필요한 관찰을 꾸준히 모으는 도구일 때 더 믿을 만했다.
관련 기록: 운영 프로젝트의 변경 범위
READERS / LIVE