100곳에 한 번에 보내는 버튼
부가세 신고 기한이 다가오면 등록된 업체 전부에 서류 요청 알림톡을 보내야 한다. 지금까지는 한 곳씩 보내는 화면만 있었다. 100곳을 하나씩 누르는 건 실무자가 반나절을 쓴다는 뜻이고, 그러다 몇 곳을 빠뜨린다.
그래서 일괄 발송을 붙였다.
보내는 부분은 금방 됐다. 한 곳씩 보내는 경로가 이미 있으니, 대상 목록을 만들어 그 경로를 여러 번 태우면 된다. 굳이 "여러 건 한 번에" 방식을 새로 쓰지 않았다 — 건별로 상태가 남고 실패한 것만 다시 보낼 수 있는 지금 구조가 운영에는 더 낫다고 봤다.
시간이 걸린 건 그다음이었다. 한 번에 100곳에 나간다는 건, 실수도 한 번에 100배가 된다는 뜻이다.
밤에는 버튼 자체를 막았다
알림톡은 밤에 보내지 않는다. 받는 사람이 놀란다.
원래는 밤에 보내려 하면 개별 건이 "밤이라 보류" 상태로 대기했다가 다음 날 나가는 구조였다. 한 건일 때는 괜찮다. 100건이면 아니다. 밤에 일괄 버튼을 누르면 보류 100개가 한꺼번에 쌓이고, 그걸 다음 날 하나씩 풀어야 한다.
그래서 일괄 발송은 밤에 버튼 자체를 거절하도록 했다. 개별 발송의 보류 규칙은 그대로 두고, 일괄만 다르게 취급한 것이다.
같은 규칙이라도 100배가 되면 다른 문제가 된다 — 이게 이 작업 내내 반복된 패턴이었다.
대표님이 짚은 것
일이 거의 끝났을 때 대표님이 하나를 짚었다.
업체마다 금액이 다른 알림톡이 있다. 종소세 환급이나 납부 안내 같은 것들이다. 그건 일괄 목록에 뜨면 안 된다는 거였다. 공통 문구 하나로 100곳에 보내면 금액이 전부 남의 것이 되니까 — 100건 전부 오발송이다.
되돌릴 방법도 없다. 카카오톡으로 이미 나간 메시지다.
우연히 막히는 것과 막아둔 것
솔직히 처음엔 그럴 일이 없다고 생각했다. 그런 템플릿은 구조상 다른 조건에 걸려서 일괄로 보내려 해도 어차피 막힐 가능성이 높았다.
실제로 그럴 가능성이 높았다는 것까지는 맞다. 그런데 그건 우연히 막히는 것이지 막아둔 게 아니다.
우연히 막히는 것에는 세 가지 문제가 있다. 조건이 바뀌면 사라진다. 사라져도 아무도 모른다. 그리고 사라졌다는 걸 알게 되는 시점이 대개 사고가 난 뒤다.
"실수로 누를 일이 없다"는 것도 같은 종류의 방어다. 오늘은 맞고 내일은 모른다.
데이터로 박았다
그래서 알림톡 템플릿마다 "일괄 발송 가능" 여부를 데이터로 넣었다. 기본값은 불가다. 새 템플릿을 만들면 자동으로 막혀 있고, 검토해서 안전하다고 확인한 것만 켠다.
막는 자리는 두 군데다. 발송 화면의 템플릿 목록에서 아예 안 보이게 거르고, 그걸 우회해서 서버에 직접 요청해도 서버가 거절한다. 화면만 막으면 화면을 안 거치는 경로가 남는다.
그리고 판정 기준을 세 문장짜리 체크리스트로 적어서 문서에 남겼다. 다음에 새 템플릿을 만들 때 이 판단을 다시 하게 되는데, 그때 기준이 기억에만 있으면 흔들린다. "이건 괜찮겠지"가 한 번 통과하면 그다음부터는 기준이 없는 것과 같다.
남길 것
자동화에서 무서운 건 안 되는 게 아니다. 안 되면 사람이 안다. 화면에 에러가 뜨고, 실무자가 전화를 하고, 내가 고친다.
되면 안 되는 게 되는 게 무섭다. 100곳에 잘못된 내용이 나가면 되돌릴 방법이 없다. 시스템은 성공했다고 보고할 것이고, 로그에는 아무 문제도 안 남는다. 알게 되는 건 고객이 전화를 걸어올 때다.
그래서 자동화를 만들 때 "무엇을 되게 할까"만큼 "무엇을 절대 안 되게 할까"에 시간을 쓰게 됐다. 후자는 요구사항에 안 적혀 있다. 적히지 않는 이유는 간단하다 — 사람이 하던 시절에는 그런 실수를 할 방법 자체가 없었기 때문이다. 한 곳씩 보내던 시절에 "100곳에 남의 금액을 보내지 마세요"라는 규칙이 있었을 리 없다.
그리고 이걸 짚은 건 내가 아니라 그 일을 해본 사람이다. 코드를 쓰는 건 점점 쉬워지는데, 무엇을 막아야 하는지는 여전히 그 일을 해본 사람에게서 나온다.
