인증 코드 문제: 에이전트가 실제 사람에게 연락해야 할 때

당신의 봇이 장소를 예약하고 있습니다. 장소를 찾아 양식을 작성하면, 해당 장소의 시스템이 확인 링크를 이메일로 보내고 등록된 번호로 인증 코드를 문자로 보냅니다. 등록된 번호는 당신의 번호입니다. 그래서 새벽 2시에 당신의 전화가 울리고, 판단이 필요한 경우에만 알림을 보내야 했던 상시 작동 에이전트가 여섯 자리 숫자 때문에 당신을 방해합니다. 이것은 자율 에이전트의 한계 중 가장 덜 논의된 부분이며, 이것이 바로 OrcaID 핸들이 단순히 지갑만이 아닌 받은 편지함과 전화번호로 지정되는 이유입니다.

2026년 8월 11일에 출시된 Grok Bot에 대한 SpaceXAI의 프레임은, 노트북을 닫은 후에도 봇들이 계속 작업하다가 인간의 결정이 필요한 때에만 사용자에게 돌아온다는 것입니다. 이는 올바른 야망입니다. 이 야망과 현실의 차이는, 아주 많은 작업들이 한 단계를 포함하는데, 그 단계는 다음을 요구한다는 것입니다.채널, 결정이 아니라 — 그리고 에이전트가 자체 채널이 없다면 그런 단계들 각각은 중단이 된다.

검증은 주관적 판단이 아니다

휴대폰 화면이 켜질 때 비슷해 보이는 두 가지를 구분하는 것은 가치가 있다.

이란 판단 요청에이전트가 실제로 인간이 필요한 단계입니다: 이 6,000달러 지출을 승인할지, 이 벤더가 적합한지, 12개월 약정을 체결할지 여부. 이런 판단 요청으로 여러분을 방해하는 것은 제품이 제대로 작동하고 있다는 뜻입니다.

하나의 채널 의존성은 에이전트가 여러분에게 아무것도 요구하지 않으며, 오직 여러분 소유의 통신 엔드포인트에 대한 접근만을 필요로 하는 단계입니다. 이메일 주소를 확인하세요. 문자로 보낸 코드를 입력하세요. 계속하려면 이 스레드에 답장하세요. 받은 편지함에 있는 링크를 클릭하세요. 예약을 확인할 수 있도록 전화를 받아 주세요. 결정이 필요한 것이 아니라 사람이 필요합니다. 검증되는 신원은 사람의 것이기 때문입니다.

에이전트가 종단 간(end-to-end)으로 수행하는 거의 모든 실제 워크플로우에는 채널 의존성이 곳곳에 박혀 있습니다. 무엇이든 가입하기, 무엇이든 예약하기, 무엇이든 이의 제기하기. 벤더 온보딩 — SpaceXAI가 자사 직원들이 Grok Bot을 사용했다고 밝힌 바로 그 사용 사례 중 하나입니다. 이러한 각각의 작업은 어느 시점에는 신원 소유자에게 코드나 이메일을 보내게 되며, 그 소유자가 당신이라면 에이전트는 진행을 멈추고 당신에게 알림을 보냅니다.

그 결과는 중간에서는 자율적이고 양 끝에서는 의존적인 에이전트입니다. 추론과 양식 작성은 할 수 있지만, 핸드셰이크는 할 수 없습니다.

왜 수신함을 에이전트로 라우팅하는 것이 잘못된 해결책인가?

뻔한 해결 방법은 봇이 인증 코드를 직접 읽을 수 있도록 봇에게 메일과 메시지에 대한 접근 권한을 주는 것입니다. 이것은 흔한 일이며, 보기보다 훨씬 큰 양보입니다.

SpaceXAI는 이것이 모델임을 분명히 밝힌다. 자사의 봇들은 "이미 사용 중인 도구에 로그인하여 앱, 받은편지함 등에서 작업한다" — 받은편지함을 직접적으로 언급하며 — 나열된 5가지 전문 영역 중 하나가 받은편지함 관리이다. 그 실례는 더 나아가 "신입 사원 좌석 배정과 Gmail로 수신된 인보이스 처리를 담당하는 ops Bot"이라고 설명한다. 이는 공급업체가 설명한 에이전트가 인간의 개인 메일 계정 안에서 일상적인 업무 흐름으로 작동하는 것을 뜻한다.

받은 편지함은 채널이 아니라 자격 증명 저장소입니다. 소유한 모든 계정의 비밀번호 재설정 정보를 담고 있으므로, 이에 대한 읽기 권한은 사실상 디지털 생활 대부분을 장악할 수 있는 능력과 같습니다. 확인 코드를 요청하는 번거로움을 피하기 위해 이를 상시 작동형 에이전트에 넘기는 것은, 작은 마찰을 무한한 노출로 맞바꾸는 일입니다. 또한 특정한 방식으로 되돌릴 수 없습니다. 에이전트가 한 달 동안 메일을 읽어 왔다면, 무엇을 읽었는지 감사할 수 없기 때문입니다.

OpenClaw는 설계상 정확히 그러한 방식으로 작동하기 때문에 이러한 위험의 형태를 구체적으로 보여줍니다 — 핵심 기능으로 이메일을 읽고 전송하며, 사용자 자신의 머신에서 실행됩니다. 2026년까지의 독립적인 보도는 135,000개 이상의 노출된 OpenClaw 인스턴스, CVSS 8.8의 CVE-2026-25253, 그리고 생태계를 겨냥한 공급망 공격 캠페인을 문서화했습니다. 이것들은 OpenClaw의 유용성에 반대하는 논거가 아니라, 에이전트의 접근이 곧 사용자의 받은편지함일 때 에이전트 침해와 신원 침해가 동일한 사건임을 보여주는 증거입니다.

수신함을 에이전트로 라우팅할 때의 두 번째 문제는 전화 문제조차 해결하지 못한다는 것입니다. 음성 인증, 공급업체가 이미 보유한 번호로의 SMS, 그리고 상대방의 사람으로부터의 콜백은 모두 메일 접근이 닿을 수 없는 범위에 있습니다.

인박스와 자체 번호가 실제로 열어주는 것

OrcaID의 네 가지 기능 중 두 가지는 돈보다는 커뮤니케이션에 관한 것이며, 이 글은 그것들이 가장 중요하게 여겨지는 글입니다.

그 수신함은 사이트에서 에이전트의 전체 도메인을 포괄하는 것으로 설명됩니다 — "전체 도메인이 곧 그 자신의 것 — 그 위의 모든 주소" — 그리고 중요하게는 "모델에 도달하기 전에 스캔됩니다". 전체 도메인 부분이 유용한 설계 선택입니다: name.orcaid.ai를 소유한 에이전트는 업체별, 작업별, 상대방별로 고유한 주소를 사용할 수 있으며, 아무에게도 프로비저닝을 요청할 필요가 없습니다. 이는 에이전트가 여러분의 사서함이 아닌 공간에서 확인 링크를 수신할 수 있게 해주고, 어떤 상대방이 어떤 에이전트에 메일을 보내는지 자연스럽게 확인할 수 있는 방법을 제공합니다.

그 번호는 음성 및 SMS, "사람에게 반드시 도달해야 할 때를 위한" 것으로 설명되며, 항상 녹음되고 항상 전사된다. 이는 인증 코드를 포함하고, 더 어려운 경우, 즉 프로세스가 전화 통화로 끝나는 공급업체의 경우도 포함한다. 녹음 및 전사 기본값은 운영자가 신경 써야 할 부분이다 — 에이전트가 통제하는 채널은 이후에 당신이 그 채널에서 일어난 일을 확인할 수 있을 때만 수용 가능하다.

여기서 상태가 중요하며 사이트는 명확합니다. 번호는 "검증 시"로, 받은편지함은 "출시 시"로 표시되어 있습니다. 둘 다 현재 운영되지 않습니다. 존재하는 것은 예약뿐이며, 예약은 무료이고 계좌를 개설하거나 청구를 시작하지 않습니다.

이메일 주소를 확인하세요. 오늘, 빌린 신원으로: 링크가 개인 받은 편지함에 도착합니다. 발급된 핸들로: 에이전트가 소유한 주소에 도착합니다.

SMS 인증 코드. 오늘, 빌린 신분으로: 당신의 휴대폰을 울립니다. 발급된 핸들로: 에이전트의 번호로 도착합니다.

판매자가 스레드에 응답합니다. 오늘, 빌린 신원으로: 당신의 메일에 섞여 있습니다. 발급된 핸들로: 에이전트 자신의 주소에 보관됩니다.

한 인간이 전화를 걸어야 한다. 오늘은, 빌린 정체성으로: 오직 너만이 응답할 수 있다. 발급된 핸들로: 음성 회선, 녹음되고 전사되었다.

벤더별 분리. 오늘날, 신원을 빌려 쓰는 경우: 모든 것에 하나의 주소. 발급된 핸들을 사용하는 경우: 상대방마다 별도의 주소.

스캔 세부 사항이 흥미로운 부분입니다.

"모델에 도달하기 전에 스캔된다"는 하나의 절이며, 에이전트 받은편지함을 진정으로 위험하게 만드는 문제를 다룹니다.

자신의 메일을 읽는 에이전트는 낯선 사람으로부터 지시를 받을 수 있는 에이전트입니다. 주소를 아는 사람이라면 누구나 에이전트가 처리할 텍스트를 보낼 수 있고, 읽은 내용에 따라 행동하는 에이전트는 조작된 메시지 하나만으로 결코 요청받지 않은 일을 하게 됩니다. 이는 공개 진입점을 통한 프롬프트 인젝션이며, 필터링 없이 에이전트에게 받은 편지함을 제공하는 것은 그것이 해결하는 문제보다 더 나쁜 문제를 만들어 낼 것입니다.

따라서 메일과 모델 사이에 스캔을 넣는 것은 그저 좋은 부가 기능이 아니다 — 그것은 받은편지함이 애초에 좋은 아이디어가 되기 위한 전제 조건이다. 그것은 또한 출시 시점에 가장 면밀히 검토할 가치가 있는 부분인데, "스캔됨"이라는 표현이 매우 다양한 수준의 엄밀함을 아우르고, 스팸 휴리스틱과 명령어 주입 방어 사이의 차이가 크기 때문이다.

이제 이걸 어떻게 하지?

Grok Bot은 기존 유료 티어에서 베타 상태이며, 더 넓은 제공에 대한 날짜는 공개되지 않았습니다. OrcaID의 받은 편지함과 번호도 아직 라이브가 아닙니다. 따라서 이는 마이그레이션이라기보다 디자인 노트입니다.

트랜잭션을 수행하는 에이전트를 구축하거나 운영 중이라면, 다른 무엇보다 먼저 상위 3개 워크플로의 채널 의존성을 계산하세요. 그 숫자는 에이전트가 실제로 얼마나 자율적일 수 있는지를 예측하며, 대개 사람들의 예상보다 높습니다. 가능하다면 오늘은 여러분 소유가 아닌 메일 주소를 에이전트에 부여하세요. 단순한 별칭(alias)이라도 좋습니다. 혜택의 일부에 불과하지만, 확인(confirmation) 트래픽이 여러분의 메일에 섞이는 것을 막아줍니다. 검증 문제를 해결하려고 에이전트에게 기본 받은편지함 읽기 권한을 주는 것은 거부하세요. 제한된 마찰을 무제한의 마찰로 맞바꾸는 것이기 때문입니다. 그리고 에이전트에 인바운드 채널을 부여한다면, 모델 뒤가 아니라 앞에 필터링을 배치하세요.

핵심 요점

2026년 에이전트 자율성의 한계는 추론 품질이 아니다. 세상은 사람을 검증하며, 사람의 신원을 빌린 에이전트는 거의 모든 실제 워크플로에서 인간 접촉 단계에 부딪힌다. Grok Bot이 판단이 필요한 경우에만 사용자를 방해하겠다는 약속은, 대부분의 방해가 전혀 판단 호출이 아니라 에이전트가 소유하지 않은 채널로 도착하는 코드, 링크, 콜백이라는 사실 때문에 무너진다.

전체 도메인에 걸쳐 자체 받은 편지함과 자체 녹음 전화선을 갖춘 계정은 그것에 대한 직접적인 해답이며, 지갑보다 덜 주목받지만 아마도 더 많은 작업을 차단하는 OrcaID 제안의 절반입니다. 둘 다 오늘 현재 사전 등록 상태이며, 각각 "출시 시" 및 "검증 시"로 표시되어 있습니다. 이 아이디어는 충분히 타당해서 출시 시 확인할 것은 받은 편지함이 존재하는지가 아니라 그 앞에 있는 스캐닝이 얼마나 진지하게 다뤄졌는지입니다.

출처 참고: Grok Bot의 출시일(2026년 8월 11일), 상시 작동 방식, "인간의 결정이 필요한 일이 있을 때만 다시 연락한다"는 프레이밍, 사용자 도구에 로그인하는 모델, 온보딩 사용 사례, 베타 유료 티어 이용 가능 여부는 SpaceXAI의 자체 주장입니다. 광범위한 출시 날짜가 공개되지 않은 점은 독립 보도에 따른 내용입니다. OpenClaw의 이메일 읽기/전송 기능과 로컬 머신 모델은 프로젝트 자체 설명에서 비롯된 것이며, 노출된 인스턴스 135,000개 이상, CVE-2026-25253(CVSS 8.8), 공급망 캠페인은 프로젝트 주장이 아닌 독립적으로 보도된 내용입니다. OrcaID의 받은편지함("전체 도메인은 자체 소유", "모델에 도달하기 전에 모든 것이 스캔됨")과 번호("음성 및 SMS", "항상 녹음, 항상 전사"), 그리고 "출시 시" 및 "검증 시" 라벨은 2026-08-22에 확인한 orcaid.ai의 사전 등록 주장입니다. OrcaID와 Grok Bot 간의 통합은 발표된 바 없습니다.