OpsDesk의 아침 브리핑은 매일 09:00에 직원 휴대폰으로 나간다. 그날의 체크인·체크아웃·재실, 준비할 것, 문 비밀번호. 청소 담당자는 이 문자 하나로 하루를 시작한다.
문자는 LMS로 나간다. 통신사는 LMS를 EUC-KR 기준 2,000바이트로 끊는다. 한글 한 글자가 2바이트니까 대략 1,000자다.
8월 15일
합주실 워크스페이스의 브리핑이 2,110바이트로 조립됐다. 통신사가 거부했고, 그날 아침 직원에게 아무것도 가지 않았다. 알림도 없었다. 다음 날 16일에야 발견했다.
원인은 조립 방식이었다. 예약 19건짜리 브리핑이 1,140바이트였는데,
- 지점 이름이 모든 행에 반복됐다.
- "뒷번호"라는 라벨이 모든 행에 붙었다.
- 손님 한 명에 두 줄을 썼다.
그리고 968바이트짜리 푸터(문 비밀번호 규칙, 연락처, 안내문)가 뒤에 붙어 한도를 넘겼다.
고친 것
- 예약 한 건에 한 줄. 열 이름은 맨 위에 한 번만 쓴다. 같은 19건이 1,140바이트에서 728바이트로 줄었다.
- 그래도 안 들어가면
_join이 푸터 블록을 뒤에서부터 통째로 뺀다. 예약 행은 절대 빼지 않는다. 문 비밀번호 안내가 잘리는 것과 손님 한 명이 사라지는 것 중 후자가 훨씬 나쁘다. - 실제 8월 15일 데이터로 다시 조립해 보니 1,390바이트. 610바이트 여유.
notify.send_text는 통신사를 부르기 전에 2,000바이트를 넘는 메시지를 거부한다. 조용히 잘라 보내는 것도 안 된다.
아직 열려 있던 것
수정은 16일 11:49에 커밋되고 15:40에 배포됐다. 그날 09:00 발송은 이미 예전 코드로 나간 뒤였다. 그러니 "고쳤다"는 17일 09:00 발송이 성공한 뒤에야 말할 수 있었다. 그리고 그 시점에 발송 실패 알림은 여전히 없었다. 실패가 사람에게 도달하지 않는 자동화는 운영이 아니다. 이건 기록에 그대로 남겨 두었다.
작은 문자 하나에 규칙이 이렇게 많다. 그래서 "AI가 문자를 보내드립니다"라고 팔지 않고, 어떤 규칙으로 언제 멈추는지를 먼저 이야기한다.