호주에서 한 이용자가 AI 비서에게 “필라테스 수업을 예약해 달라”고 시켰더니, 그 AI가 정원이 찬 수업에서 다른 회원의 예약을 취소하고 빈자리를 만들어 자기 예약을 넣은 일이 알려졌다. 같은 날 다른 기사에서는 해커들이 AI 에이전트 여러 개를 동시에 굴려 정부 시스템을 훑었다는 소식도 나왔다. 두 사건의 성격은 다르지만 시사점은 하나로 모인다. 이제 우리 사이트의 버튼을 누르는 쪽이 반드시 사람이라는 보장이 없다.
사람은 안 하던 일을 기계는 시도한다
사람이 쓰는 화면은 사람의 습관을 전제로 만들어진다. 남의 예약 번호를 굳이 바꿔 가며 눌러 보는 손님은 거의 없고, 1초에 스무 번씩 조회 버튼을 누르는 손님도 없다. 그래서 많은 예약·주문 화면이 “보이지 않게 해 두는 것”과 “못 하게 막아 두는 것”을 구분하지 않은 채 운영된다. 화면에서 취소 버튼을 감춰 두었을 뿐, 요청 자체는 그대로 통하는 경우가 대표적이다.
사람 앞에서는 몇 년째 아무 문제가 없던 구조가, 기계 앞에서는 하루 만에 뚫린다. AI 에이전트는 지치지도 않고 눈치도 보지 않으며, 화면에 없는 경로를 그냥 시도해 본다. 그래서 지금 필요한 점검은 디자인이 아니라 서버가 판단하고 있는가이다. 내 예약인지, 지금 바꿔도 되는 시점인지, 같은 사람이 짧은 시간에 몇 번이나 시도했는지를 화면이 아니라 서버에서 확인하고 있는지. 이건 웹개발 단계에서 봐야 할 문제이고, 겉모습을 새로 만드는 작업과는 층이 다르다.
기록이 없으면 사고가 났는지도 모른다
더 곤란한 쪽은 사고가 났다는 사실 자체를 모르는 경우다. 앞의 필라테스 사례도 취소된 회원이 항의하면서 드러났다. 예약이 언제, 어디서, 어떤 경로로 만들어지고 바뀌었는지가 남아 있지 않으면 원인을 찾을 수 없고 되돌릴 수도 없다. 예약·주문·취소는 지웠어도 기록은 남는 구조가 기본이다. 사고를 막기 위해서가 아니라, 사고 뒤에 설명하기 위해서다.
사람을 위한 화면은 오히려 더 단순해져야 한다
보안을 조인다고 손님이 쓰는 화면까지 복잡해지면 곤란하다. 방향은 반대다. 취소와 변경의 조건을 예약할 때 미리 한 줄로 보여 주고, 되돌릴 수 없는 동작은 한 번 더 확인하고, 지금 무엇을 예약했는지 한 화면에서 다 보이게 한다. 이런 정리는 UI UX 디자인의 영역이고, 실수로 인한 문의를 줄이는 가장 싼 방법이기도 하다. 사람에게 명확한 화면이 대개 기계에게도 안전하다. 규칙이 분명하면 예외로 빠져나갈 틈이 줄기 때문이다.
알림까지 닿아야 마무리된다
예약이 만들어지거나 취소되면 그 사실이 당사자에게 바로 도착해야 한다. 문자든 메일이든 앱 알림이든, 통로는 중요하지 않다. 중요한 건 내가 하지 않은 일이 벌어졌을 때 몇 분 안에 알 수 있느냐다. 예약이 반복되는 업종이라면 앱제작 단계에서 알림을 기본 기능으로 넣어 두는 편이 좋고, 아직 규모가 작다면 문자 발송만으로도 충분하다.
화면을 감추는 것은 정리이고, 서버에서 막는 것이 보안이다. 기계는 그 차이를 정확히 안다.
AI에게 일상을 대신 시키는 사람은 앞으로 더 늘어난다. 우리 쪽에서 할 일은 그 흐름을 막는 것이 아니라, 대신 온 손님이 규칙을 어길 수 없게 만들어 두는 것이다. 오늘 우리 예약 화면에서 남의 예약을 건드릴 수 있는 경로가 정말 없는지, 그 판단이 화면이 아니라 서버에서 이뤄지고 있는지부터 확인해 보자.
