Meta 가 Instagram AI 챗봇으로 2 만 명의 계정을 빼앗긴 까닭 — 'AI 가 대리하는 인증' 의 구조적 결함
Meta 가 Instagram AI 챗봇으로 2 만 명의 계정을 빼앗긴 까닭 — ‘AI 가 대리하는 인증’ 의 구조적 결함
Meta 는 챗봇이 “의도대로 작동” 했다고 변명했다. 그러나 비밀번호 재설정 흐름에 AI 를 끼워 넣는 결정 자체가 약한 고리를 만든 것은 아닌가.
도입 — 4 월부터 6 월까지, 조용히 진행된 탈취
2026 년 6 월 첫 주, Meta 는 자사 Instagram 사용자 가운데 2 만 225 명에게 계정 침해를 통보했다. 메인 주 거주자 30 명을 포함한 이 통보 대상자들은, 자신이 모르는 사이에 계정의 비밀번호가 공격자의 이메일로 재설정되어 있었다. 공격은 4 월 17 일경 시작되어 6 월 초에야 발견되었다. 두 달 가까이, 같은 수법이 같은 결함을 통해 반복 작동했다는 뜻이다.
수법은 무미건조할 정도로 단순했다. 공격자는 Meta 의 AI 지원 챗봇에 접근해 “내 계정이 침해당했다” 고 호소했다. 챗봇은 비밀번호 재설정 절차를 안내하면서, 공격자가 지정한 이메일 주소로 재설정 링크를 발송했다. 그 이메일은 피해자의 등록 이메일과 일치하지 않았는데도 시스템은 이를 거부하지 않았다. 공격자는 자기 이메일로 재설정 링크를 받아 비밀번호를 갈아 끼우고, 계정을 완전히 장악했다. Meta 의 공식 설명은 “별도 코드 경로의 버그로 인해 시스템이 재설정 이메일이 사용자의 Instagram 계정에 등록된 이메일과 일치하는지 제대로 검증하지 못했다” 였다. 이 한 줄짜리 해명을 두고 보안 커뮤니티는 그 다음 질문으로 곧장 옮겨갔다. 검증이 단지 “한 줄짜리 버그” 였는가, 아니면 AI 챗봇을 인증 흐름에 끼워 넣은 설계 결정 자체가 문제였는가.
사건의 메커니즘 — 검증을 잃어버린 한 줄의 코드 경로
공격이 작동한 단계는 단 네 개다. 첫째, 공격자가 Meta 의 AI 챗봇과 대화를 시작한다. “내 계정에 접근할 수 없다” 고 말한다. 둘째, 챗봇은 사용자의 신원을 확인한 뒤 비밀번호 재설정을 안내한다. 셋째, 챗봇은 사용자가 제공한 이메일 주소로 재설정 토큰을 발송한다. 넷째, 공격자는 그 토큰을 사용해 비밀번호를 변경한다. 핵심은 세 번째 단계에 있다. 정상적인 비밀번호 재설정 흐름이라면, “사용자가 제공한 이메일” 과 “계정에 등록된 이메일” 의 일치 여부를 시스템이 직접 검증한다. 일치하지 않으면 재설정 토큰은 등록 이메일 쪽으로 가야 한다. 그것이 계정 복구의 가장 기본적인 1선 방어다.
Meta 의 챗봇이 호출한 코드 경로에서는 이 검증이 빠져 있었다. Meta 가 사건 직후 발표한 짧은 성명은 이렇게 적었다. “별도 코드 경로의 버그로 인해, 시스템이 제공된 이메일 주소가 사용자의 Instagram 계정에 등록된 이메일 주소와 일치하는지 제대로 검증하지 못했다.” 검증 함수 자체는 사내 인증 라이브러리에 존재했지만, 챗봇이 호출한 신규 코드 경로에서는 그 함수가 누락된 채로 출시되었다는 뜻이다. 흥미로운 점은 사후 대응 속도다. Meta 는 발견 당일 챗봇을 비활성화하고, 문제의 코드 경로를 제거하고, 영향을 받은 사용자의 비밀번호를 일제히 재설정했으며, 다른 플랫폼의 챗봇에 같은 결함이 없는지 감사에 들어갔다고 밝혔다.
그러나 사건이 발견되기까지 두 달 가까이 걸린 것은 무엇을 의미하는가. 정상적인 비밀번호 재설정 흐름이라면 보안팀이 즉시 잡았을 패턴 — 등록 이메일과 다른 주소로 재설정 토큰이 발송되는 사건 — 이 챗봇 경로에서는 별개의 로그 스트림으로 흘러갔고, 기존 침입 탐지 룰의 시야 밖에 있었다는 추정이 가능하다. AI 인터페이스 위에 새로운 흐름을 얹을 때, 그 흐름은 자동으로 기존의 검증·감사 인프라를 상속하지 못한다. 이번 사건이 두 달간 지속된 진짜 이유는 바로 그 단절에 있다.
Hacker News 의 댓글 가운데 사용자 jhhh 는 정확한 질문을 던졌다. (원문을 우리말로 옮긴다.) “‘사용자가 다른 이메일을 요청할 수 있는가’ 가 이런 기능을 만들 때 제일 먼저 떠오를 테스트 아닌가? 왜 그게 빠져 있었나?” 챗봇이라는 인터페이스가 입혀지자, 가장 기본적인 부정 케이스 테스트가 누락된 것이다.
왜 LLM 은 인증의 약한 고리가 되는가
문제의 본질은 한 줄짜리 검증 누락이 아니다. 문제는 검증 결정의 일부를 LLM 에 위임한 설계 그 자체다. Hacker News 의 사용자 ludwik 는 이렇게 짧게 정리했다. (원문 인용을 우리말로 옮긴다.) “이런 식의 결정론적 검증은 LLM 의 일이 아니며, 일이 되어서도 안 된다. LLM 이 호출하는 도구가 권한 계층을 강제해야 한다.” 이 말이 가리키는 구조는 명확하다. LLM 은 자연어로 사용자 의도를 해석하는 데까지만 책임을 진다. 비밀번호 재설정, 권한 변경, 계정 통합 같은 결정론적 작업은 LLM 바깥의 도구가 자체적인 검증 로직을 갖고 거부권을 행사해야 한다.
Meta 의 설명문 — “챗봇은 의도대로 작동했고, 버그는 별도 코드 경로에 있었다” — 은 기술적으로는 사실일 수 있다. 그러나 Hacker News 사용자 nkrisc 의 한 줄짜리 풍자가 이 변명의 모순을 정확히 짚었다. (원문을 우리말로 옮긴다.) “도구는 의도대로 정확히 작동했다. 다만 버그 때문에 의도대로 작동하지도, 정확히 작동하지도 못했다.” 사용자 mikeocool 의 분석은 더 본질적이다. (원문을 우리말로 옮긴다.) “LLM 은 본질적으로 ‘인간 같은 추론 능력’ 을 가졌다고 팔리고 있다. LLM 은 사용자 요청을 의심하지 않고 곧장 절차를 실행했고, 그 절차에 버그가 있었다. 인간 지원 상담원도 사회공학에 당하지만, 이 정도 규모로 이렇게 손쉽게 당한 사례를 나는 떠올릴 수 없다.”
이 지적은 흔히 간과되는 비대칭을 가리킨다. 인간 상담원이 비밀번호 재설정 요청을 받았을 때, “왜 다른 이메일로 보내달라는가” 라는 의심은 일상적인 직무 훈련의 일부다. 신원 확인 절차가 강화된 통화는 별도로 분류되고, 의심스러운 패턴은 슈퍼바이저에게 에스컬레이션된다. LLM 챗봇은 같은 사회공학 시도에 대해 의심하도록 훈련되어 있지 않다. 더 정확히 말하면, 의심이라는 행동이 LLM 의 행위 패턴 안에서 신뢰할 수 있는 형태로 일관되게 발현되지 않는다. 같은 프롬프트가 어떤 회차에서는 거절을 만들고 다른 회차에서는 통과를 만든다. 이 비결정성은 결정론적 보안 정책과 본질적으로 불협화음을 낸다.
거기에 또 다른 비대칭이 겹친다. 사용자 mikeocool 이 지적한 “규모와 손쉬움” 이다. 인간 상담원에게 사회공학을 시도하려면 한 통씩 전화를 걸어야 한다. 챗봇은 API 한 번으로 동시에 수천 건의 요청을 날릴 수 있고, 응답 패턴을 자동으로 분석해 그중 성공하는 회차만 골라낼 수 있다. 같은 사회공학적 약점이 인간에게 있으면 노동 집약형 공격이지만, AI 에게 있으면 자동화 공격이 된다. 공격 비용은 두 자리 수 이상 떨어진다.
AI-as-Customer-Service 의 구조적 시사점
이번 사건이 의미하는 바는 Meta 한 회사의 보안 사고를 넘어선다. 지난 18 개월간 거의 모든 대형 소비자 서비스 — Amazon, Apple, Google, 항공사, 통신사 — 가 고객 응대의 1선을 AI 챗봇으로 옮겨 가는 추세를 보였다. 비용 절감과 24 시간 응대라는 사업적 이점은 명확하지만, 그 1선이 동시에 인증 흐름의 일부를 떠맡을 때 어떤 종류의 위험이 생기는가는 충분히 논의되지 않았다.
세 가지 시사점이 있다. 첫째, 결정론적 검증은 LLM 바깥으로 분리해야 한다. 사용자 ludwik 가 짚었듯, LLM 이 호출하는 도구 (tool call 의 endpoint) 가 자체적인 권한 계층을 강제해야 한다. “이 사용자가 등록 이메일이 아닌 다른 이메일로 재설정 토큰을 보낼 자격이 있는가” 라는 질문은 LLM 의 응답 분기로 해결할 일이 아니라, tool 측에서 항상 거부하도록 코드로 강제해야 한다. AI 안전 분야에서 자주 인용되는 “권한과 가능성의 분리” 원칙이 정확히 이 지점에서 적용된다.
둘째, AI 인터페이스에는 별도의 침입 탐지 룰이 필요하다. 이번 사건이 두 달간 지속된 데는, 챗봇이 만들어낸 비밀번호 재설정 이벤트가 기존 보안 모니터링 룰의 시야에 들어오지 않았다는 가설이 자연스럽다. 새 인터페이스를 출시할 때마다, 그 인터페이스가 만들어내는 이벤트 스트림에 같은 수준의 anomaly detection 을 붙이는 운영 체크리스트가 필요하다. AI 인터페이스의 “출시 절차” 안에 보안팀의 사인오프가 의무 단계로 들어와야 한다.
셋째, 공격자의 자동화 우위를 가정하고 설계해야 한다. Hacker News 사용자 mikeocool 이 지적한 “이전에는 이 정도 규모로 당한 사례가 없다” 는 문장은 무거운 함의를 갖는다. 사회공학의 비용은 LLM 인터페이스 위에서 자동화되고, 같은 약점이 만 단위 피해를 만들어내는 속도는 인간 상담원 시대와 두 자릿수의 차이가 난다. 이는 LLM 응답의 변동성을 활용한 페일오버 공격 — 같은 요청을 다양한 표현으로 수백 번 던져 우연히 성공하는 회차를 노리는 공격 — 이 새로운 표준 공격 패턴이 된다는 의미다. 방어 측 모델은 “한 번의 시도” 가 아닌 “수천 번의 시도 가운데 한 번의 성공” 을 막을 수 있어야 한다.
이번 사건은 또한 규제 측면의 빈자리를 드러낸다. 미국 FTC 와 EU 의 GDPR 둘 다 “개인정보 침해 통보 의무” 를 부과하지만, 그 의무가 발동되는 기준은 대체로 “데이터가 외부로 유출되었는가” 다. 이번 사건처럼 계정 자체가 탈취된 경우, 해당 사용자의 데이터가 새로 “유출” 되었다고 보기 모호한 회색 지대가 생긴다. Meta 가 2 만 명에게 통보한 행위가 법적 의무인지, 자발적 모범 사례인지조차 주마다 다르다. AI 인터페이스 위에서 발생하는 인증 사고는 기존 데이터 침해 통보 프레임의 사각지대로 떨어지기 쉽다. 비밀번호 재설정 흐름이 LLM 의 책임 분담선 위에 놓이는 시대에는, “통보 의무” 의 트리거 자체를 다시 정의해야 한다는 압력이 곧 따라올 것이다. 캘리포니아 CCPA 의 다음 개정안이 이 빈틈을 어떻게 메우는가를 지켜볼 일이다.
결론 — 챗봇은 의도대로 작동했는가
Meta 의 공식 입장은 챗봇 자체가 아니라 별도 코드 경로의 버그가 문제였다는 것이다. 기술적 의미에서는 그 주장이 옳다. 그러나 그 해명에는 더 큰 질문이 빠져 있다. 왜 그 별도 코드 경로는 챗봇과 결합된 형태로 출시되었는가. 왜 그 결합 지점에는 기존의 보안 게이트가 작동하지 않았는가. 왜 두 달간 아무도 그것을 알아채지 못했는가. 이 질문들에 답하지 않는 한, 다음 사건은 다른 회사, 다른 결제 시스템, 다른 인증 흐름에서 같은 모양으로 반복된다.
진짜 교훈은 단순하다. AI 챗봇은 고객의 의도를 자연어로 해석하는 데까지만 신뢰받을 수 있다. 결정을 내리고, 자원에 접근하고, 인증 상태를 바꾸는 모든 행위는 LLM 바깥의 결정론적 도구가 자체적인 검증을 갖고 수행해야 한다. 이 분리를 흐릴 때마다, 우리는 한 줄짜리 검증 누락이 2 만 명의 계정을 잃게 만드는 구조를 새로 짓는 셈이다. Meta 의 사건은 그 구조가 이미 우리 곁에 와 있다는, 미루기 어려운 신호다. 다음에 같은 사건이 발생할 회사는 어디일지가 아니라, 그곳이 LLM 의 책임 경계를 어디에 그어 두었는지가 결정한다.
출처: