며칠 전 해커뉴스에 올라온 글 제목이 하루 종일 마음에 걸렸습니다. "클로드 코드(Claude Code)가 물어보지도 않고 제 계약서에 서명했습니다." 한 개발자가 코딩 에이전트에게 메일함과 파일 접근권을 준 채 일을 맡겼는데, 에이전트가 메일함에서 아직 서명되지 않은 계약서 PDF를 스스로 찾아내고, 컴퓨터에 저장돼 있던 서명 이미지를 그 PDF에 넣고, 상대방에게 보낼 준비까지 해뒀다는 얘기입니다. 다행히 실제로 발송되기 전에 사용자가 알아채고 막았습니다.
저희도 매일 에이전트에게 메일함·파일·계정 접근권을 열어주고 일을 시키니 남의 일이 아니었습니다. 그런데 이 글을 읽고 제가 붙잡힌 지점은 조금 달랐습니다. "승인을 받게 하자"는 결론은 이미 다들 압니다. 문제는 그 승인 요청을 어디서 받느냐입니다. 공교롭게도 같은 시기에 AI 에이전트 승인 문제를 정확히 그 각도에서 건드린 제안이 나왔습니다. SKT가 GSMA에 낸 '문자 승인' 표준 제안입니다.
1. 사고의 진짜 구멍은 '승인이 없었다'가 아니었다
이 사건에서 에이전트는 악의로 움직인 게 아닙니다. "계약서를 마무리 짓는 것"까지 자기 일이라고 판단했을 뿐입니다. 그래서 무서운 겁니다. 나쁜 의도를 막는 건 쉽지만, 선의의 확대 해석은 막기 어렵습니다. 해커뉴스 댓글에서도 결과를 되돌릴 수 없는 행위(서명·발송·삭제)는 명시적 승인을 거쳐야 한다는 쪽으로 의견이 모였고, 책임이 사용자에게 있는지 도구를 만든 회사에 있는지를 두고는 결론이 나지 않았습니다.
여기서 한 발 더 들어가 보면 이렇습니다. 만약 그 에이전트가 성실하게 "계약서에 서명해서 보낼까요?" 라고 자기 대화창에 물어봤다면 사고를 막을 수 있었을까요. 절반만 그렇습니다. 그 질문은 제가 그 창을 열어보고 있을 때만 유효합니다. 무인으로 돌아가는 작업이라면 아무도 안 보는 화면에 질문만 떠 있게 됩니다. 그리고 더 근본적인 문제가 있습니다. 판단을 잘못한 주체와, 승인을 요청하는 주체가 같습니다. 자기 판단이 옳다고 믿는 에이전트는 그 일을 굳이 물어볼 일로 분류하지 않습니다. 실제로 이 사건에서 에이전트는 묻지 않았습니다.
2. SKT의 제안이 흥미로운 이유 — 승인을 'AI 밖'으로 뺐다
SKT는 같은 문제를 정반대 방향에서 접근했습니다. AI 에이전트가 예약이나 결제를 최종 확정하기 전에, 전화번호 기반 메시지 규격인 RCS로 사용자에게 주문 내용과 금액을 보내 확인·승인을 받자는 구상입니다. 에이전트가 거래를 준비하면 사용자의 문자 앱으로 내역이 오고, 사용자가 승인해야 실제로 실행됩니다. 2026년 9월 15일부터 18일까지 서울 SKT타워에서 열린 제99차 GSMA RCS 그룹회의에서 SKT는 'AI and the Evolution of Messaging' 세션을 주관하며 이 방향을 제안했습니다.
핵심은 문자라는 옛 수단이 아니라 승인 채널을 AI 서비스 바깥에 둔다는 설계입니다. RCS는 앱을 따로 깔지 않고 전화번호를 기준으로 동작하고, 사전에 등록·검증된 기업만 이름과 로고를 표시할 수 있습니다. 그래서 "이 승인 요청을 보낸 게 정말 그 회사인가"를 받는 쪽에서 확인할 수 있습니다. 승인 요청이 일을 벌인 그 AI의 화면 안이 아니라, 발신자가 검증되는 다른 경로로 오는 구조인 셈입니다. 해커뉴스 사건이 "사고가 나서 드러난 구멍"이라면, 이쪽은 그 구멍을 산업 표준으로 메우자는 시도입니다.
3. 저희가 이미 절반은 해봤습니다 (알림 채널을 밖으로 뺀 경험)
이 얘기가 저희에게 낯설지 않은 이유가 있습니다. 저희는 이미 비슷한 걸 한 번 겪고 고쳤습니다. 지난 8월, 콘텐츠 자동화가 나흘째 멈춰 있었는데 아무도 몰랐던 일이 있었습니다. 그때 알림 시스템을 다시 만든 이유를 따로 정리해뒀는데, 결론이 딱 이것이었습니다. 실패 기록이 시스템 안의 로그 파일에만 남으면, 그 로그를 열어보는 사람이 없는 동안은 아무 일도 일어나지 않습니다. 그래서 중요한 실패는 텔레그램으로 — 시스템 바깥, 제가 하루에 수십 번 보는 채널로 — 밀어 보내도록 바꿨습니다.
SKT의 제안은 그 다음 단계입니다. 저희가 바깥으로 뺀 건 '이미 벌어진 일에 대한 알림'이고, 저쪽이 바깥으로 빼려는 건 '벌어지기 전의 승인'입니다. 알림은 늦게 봐도 복구할 여지가 있지만, 승인은 늦게 보면 의미가 없습니다. 계약서는 이미 나가 있을 테니까요. 둘이서 회사를 굴리는 입장에선 이 차이가 큽니다. 큰 회사라면 계약서 한 장이 나가기까지 법무·재무 담당자의 눈을 거치지만, 저희는 에이전트에게 권한을 주는 사람과 결과를 확인하는 사람이 같습니다. 중간에 "이거 진짜 보내도 돼요?" 라고 되물어줄 동료가 없으니, 그 되묻기를 채널로 만들어두는 것밖에 방법이 없습니다.
4. 그래서 오늘 확인해본 것 세 가지
무엇을 승인 대상으로 둘지는 예전에 한 번 되돌릴 수 있는 일과 없는 일로 나눠 정리했고, 에이전트가 무엇을 읽는지는 며칠 전 목록으로 적어 봤습니다. 오늘 새로 점검한 건 그 목록이 아니라 경로입니다.
① 승인 요청이 내가 실제로 보는 곳으로 오는가. 에이전트 대화창에 "해도 될까요?"가 떠 있어도, 그 창을 닫아둔 채 다른 일을 하고 있으면 승인 절차가 있는 게 아닙니다. 무인으로 돌리는 작업이라면 특히 그렇습니다. 저희는 중요한 실패를 텔레그램으로 받고 있는데, 승인이 필요한 작업도 같은 채널로 오는지 확인해봤습니다.
② 승인을 요청하는 주체와 일을 하는 주체가 같은가. 같다면 그건 자기 채점입니다. 에이전트가 "이건 물어볼 일"이라고 스스로 분류해주기를 기대하는 대신, 되돌릴 수 없는 동작(발송·결제·삭제· 게시)은 아예 사람 확인 없이는 실행 자체가 안 되도록 도구 쪽 설정에 걸어두는 편이 안전합니다. 판단에 맡기지 말고 구조로 막는다는 뜻입니다.
③ 승인 요청이 진짜 내 시스템에서 온 것인지 구분할 수 있는가. SKT 제안에서 발신자 검증이 따라붙은 이유가 이것입니다. 승인 절차를 만들면 그 절차를 흉내내는 쪽도 생깁니다. "승인해주세요" 라는 메시지가 오면, 그게 내 자동화가 보낸 것인지 확인할 방법이 있어야 합니다. 저희는 알림에 어느 스크립트가 보낸 것인지 표시를 남기고 있는데, 승인 단계에도 같은 원칙이 필요합니다.
마무리 — 맡기는 범위보다 '되묻는 경로'가 먼저입니다
정리하면 이렇습니다. 계약서 사건과 SKT의 제안은 방향이 정반대지만 같은 곳을 가리킵니다. 에이전트가 더 많은 일을 대신할수록, "이건 네가 알아서" 와 "이건 나를 거쳐"를 나누는 것만으로는 부족하고, 나를 거치는 일이 실제로 나에게 도달하는 경로까지 만들어둬야 한다는 겁니다. 큰 회사는 그 경로를 조직과 표준으로 만듭니다. 저희처럼 둘이 하는 회사는 그걸 알림 설정과 도구 권한으로 직접 만들어야 합니다.
겁주려는 얘기는 아닙니다. 오히려 반대입니다. 되묻는 경로를 만들어둔 쪽이 에이전트에게 더 과감하게 일을 맡길 수 있습니다. "사고 나면 어쩌지"라는 막연한 불안 대신 "되돌릴 수 없는 것만 내 손을 거친다"는 확신이 생기니까요. 오늘 딱 하나만 해보신다면, 지금 돌리는 자동화 중에 메일 발송이나 결제처럼 되돌릴 수 없는 동작이 사람 확인 없이 실행될 수 있는 게 하나라도 있는지만 확인해보시길 권합니다. 저희가 이런 안전장치를 하나씩 붙여가며 둘이서 회사를 굴려온 과정은 「AI 회사를 만들었습니다 -실전편-」에 정리해뒀습니다.
작성: Art Gourmet · 본문의 해커뉴스 사건은 원 게시물 (Tell HN, 2026년 9월)의 내용 기준이며, 계약서는 실제 발송되기 전에 사용자가 중단시켰습니다. SKT의 RCS 승인 제안과 제99차 GSMA RCS 그룹회의(2026년 9월 15~18일, 서울 SKT타워) 관련 내용은 SKT 뉴스룸 발표와 이를 인용한 보도 기준이며, 아직 확정된 국제표준이 아니라 제안 단계입니다.