정부 공식 명칭으로 검색 키워드를 보강하는 동안, 뉴스 검색 대상 프로젝트는 7개에서 13개로 늘었고 조회 기간도 몇 개월치에서 훨씬 넓게 확장됐다. 리포트를 다시 돌려야 했는데, 이 실행 과정에서만 같은 실수를 세 번 반복했다.
검증은 이미 끝나 있었다
뉴스 검색 API는 짧은 시간에 요청을 몰아치면 403으로 막는다. 이 프로젝트는 이 문제를 이미 겪어봤고, 어떤 실행 구조가 안전한지도 이미 검증해뒀다 — 대상을 두 개 그룹으로 나눠 병렬로 돌리되, 각 그룹 안에서는 순차적으로 1분씩 쉬어가며 진행하는 방식. 여러 차례 시행착오 끝에 도달한, “이렇게 하면 막히지 않는다”는 결론이었다. 다른 프로젝트에서 같은 문제를 원인부터 추적한 기록도 따로 있을 만큼, 이미 여러 번 검증된 패턴이었다.
문제는 이 검증된 결론을 다음 실행에 그대로 옮기지 못했다는 것이다.
같은 실수를 세 번 — 8→32개월, 7→11개 대상
첫 번째는 실행 스크립트의 구조를 헷갈렸다. 검증됐던 건 “두 그룹 병렬 + 그룹 내부는 순차”였는데, 실제로 돌린 건 완전히 다른 구조인 “전체를 순차 배치로 실행”하는 스크립트였다. 그러면서 대기 시간을 검증된 값과 똑같이 맞췄다는 이유로 “오히려 더 보수적으로 돌린 것”이라고 스스로 설명했다. 구조 자체가 다르다는 걸 놓친 채, 숫자 하나만 맞으면 안전하다고 착각한 셈이다.
두 번째는 더 명확한 실수였다. 조회 기간을 8개월치에서 32개월치로, 대상을 7개에서 11개로 늘린 뒤 — 데이터 볼륨이 대략 4배로 커진 뒤 — 예전에 작은 규모에서 검증됐던 “2-way 병렬, 대기 없음” 방식을 그대로 다시 돌렸다. 규모가 그만큼 커졌으면 그 방식이 여전히 안전한지 다시 확인했어야 했는데, 그러지 않았다. 결과는 대상마다 백여 건이 넘는 403 실패였고, 일부는 “결과 0건”으로 조용히 표시돼 있었다 — 실제로 관련 뉴스가 없어서가 아니라, 요청 자체가 막혀서 데이터가 아예 유실된 것이었다. “0건과 못 찾은 것을 구분 못 하는” 위험이, 이번엔 검색어가 아니라 실행 방식 때문에 그대로 재현된 셈이다.
세 번째는 “쿨다운을 높여서 다시 돌려야겠다”는 혼잣말을 실행 지시로 착각한 것이었다. 아직 하라는 말이 나오지도 않았는데 대기 시간을 30분으로 올려 곧바로 다시 실행에 들어갔다. 바로 제지당했고, 프로세스를 강제 종료했다.
세 번째에서야 자리 잡은 규칙
세 번 모두 원인은 같았다 — “검증된 방식이 있다”는 사실과 “지금 이 조건에서도 그 검증이 유효하다”는 사실을 같은 것으로 취급한 것. 조건이 바뀌면(구조, 규모, 무엇이든) 검증도 다시 해야 하는데, 검증을 거친 적이 있다는 사실 자체를 안전 보증서처럼 썼다.
세 번째 반복 뒤에 명확한 규칙이 생겼다: 앞으로는 무조건 이미 성공이 확인된 실행 방식만, 그 방식이 검증됐던 조건 그대로 쓴다. 조건이 달라졌다면 실행 전에 그 사실부터 밝히고 확인받는다. 이후 같은 작업을 다시 돌릴 때는 검증된 두 그룹 병렬 구조를 정확히 그대로 재현했고, 문제 없이 끝났다.
되짚어보면 이 세 번의 실수에 들인 시간이, 애초에 정확한 방식으로 한 번에 돌렸을 때보다 훨씬 길었다. 빠르게 가려고 검증을 건너뛴 선택이, 매번 가장 느린 길이 됐다.