검사 도구는 만들어 뒀는데 자동 실행 경로에는 안 걸려 있었다
한눈에 답변
콘텐츠 자동화 파이프라인이 매일 실행돼 검토 대기열에 초안을 쌓는데, 그 초안이 실제로 존재하는 근거를 가리키는지 확인하는 무결성 검사가 자동 실행 경로에는 걸려 있지 않았다. 관리자 화면과 발행 단계 앞에는 이미 그 검사가 있었지만, 자동 실행 다음 단계인 자동 PR 생성에는 검사 없이 곧바로 넘어가고 있었다. 실제로 깨진 참조가 그 경로로 들어간 사고가 나서야 이 구멍을 발견했다.
무엇이 빠져 있었나
콘텐츠를 자동으로 발견하고 초안을 만드는 파이프라인이 매일 실행되고, 그 결과로 자동 PR이 생성된다. 이 초안이 가리키는 근거 자료가 실제로 존재하는지 확인하는 무결성 검사 도구는 이미 있었고, 관리자 화면·URL 승인·발행 단계 앞에는 이미 배치돼 있었다. 그런데 자동 실행 파이프라인이 PR을 생성하기 직전 단계에는 이 검사가 전혀 걸려 있지 않았다.
왜 이게 실제 사고로 이어졌나
자동 실행에서 PR 생성까지 바로 이어지는 구조라, 깨진 참조가 있는 산출물이 그대로 검토 대기열까지 올라갈 수 있는 상태였다. 실제로 그런 사고가 발생하고 나서야 이 경로에 검사가 빠져 있다는 것을 알게 됐다.
어떻게 고쳤나
자동 실행 워크플로에 PR을 생성하기 직전 단계로 무결성 검사를 추가했다. 이 검사가 문제를 발견하면 종료 코드로 실패를 알리고, 그 실패 신호를 받으면 이후 단계인 PR 생성 자체가 실행되지 않도록 막았다. 실행 결과 요약에도 무엇이 깨졌는지와 몇 건인지를 명시해서, 앞선 단계가 전부 성공으로 표시돼 있어도 이 검사 하나로 전체 결과를 실패로 뒤집을 수 있게 했다. 자동화 도구가 스스로 문제를 지우지는 않도록 했다 — 사람 자료든 자동 생성 자료든, 자동화가 임의로 정리하면 되돌릴 방법이 없기 때문에 막고 알리는 데까지만 하고 정리는 사람이 하도록 남겨 뒀다.
이 사건에서 얻은 교훈
검사 도구를 만드는 것과, 그 도구를 실제로 필요한 모든 경로에 배치하는 것은 다른 일이다. 새로운 자동 실행 경로가 하나 생기면, 기존에 다른 경로에 걸어 둔 안전장치들이 그 새 경로에도 똑같이 적용돼 있는지 하나씩 대조해야 한다. “이미 만들어 둔 검사가 있다”는 사실이 “모든 경로에 적용되고 있다”는 뜻은 아니다.