본 기사는 개인 블로그 crowdy.dev에서 전재되었습니다.

Meta는 챗봇이 「의도한 대로 작동했다」고 변명했다. 하지만 패스워드 리셋(Password Reset) 흐름에 AI를 끼워 넣기로 한 결정 자체가 취약한 연결 고리를 만든 것은 아닐까.

2026년 6월 첫째 주, Meta는 자사 Instagram 사용자 중 2만 225명에게 계정 침해를 통지했다. 메인주 주민 30명을 포함한 이 통지 대상자들은 자신도 모르는 사이에 계정의 패스워드가 공격자의 이메일 주소로 리셋되어 있었다. 공격은 4월 17일경 시작되어 6월 초에야 겨우 발견되었다. 두 달 가까이 동일한 수법이 동일한 결함을 통해 반복적으로 작동했다는 의미다.

수법은 무미건조할 정도로 단순했다. 공격자는 Meta의 AI 지원 챗봇에 접속하여 「내 계정이 침해되었다」고 호소한다. 챗봇은 패스워드 리셋 절차를 안내하면서, 공격자가 지정한 이메일 주소로 리셋 링크를 전송한다. 그 이메일 주소는 피해자의 등록 이메일과 일치하지 않음에도 불구하고, 시스템은 이를 거부하지 않았다. 공격자는 자신의 이메일로 리셋 링크를 받아 패스워드를 교체하고, 계정을 완전히 장악한다. Meta의 공식 설명은 「별도의 코드 패스(Code Path) 버그로 인해, 시스템이 제공된 이메일 주소가 사용자의 Instagram 계정에 연결된 등록 이메일 주소와 일치하는지 적절히 검증하지 못했다」는 것이었다. 이 한 줄의 변명을 두고 보안 커뮤니티는 즉시 다음 질문으로 향했다. 검증이 단지 「한 줄의 버그」였는가, 아니면 AI 챗봇을 인증 플로우(Authentication Flow)에 끼워 넣은 설계 판단 자체가 문제였는가.

공격이 작동한 단계는 단 네 단계다. 첫째, 공격자가 Meta의 AI 챗봇과 대화를 시작한다. 「내 계정에 접속할 수 없다」고 말한다. 둘째, 챗봇은 사용자의 신원을 확인한 후 패스워드 리셋을 안내한다. 셋째, 챗봇은 사용자가 제공한 이메일 주소로 리셋 토큰(Reset Token)을 전송한다. 넷째, 공격자는 그 토큰을 사용하여 패스워드를 변경한다. 핵심은 세 번째 단계에 있다. 정상적인 패스워드 리셋 플로우라면, 「사용자가 제공한 이메일」과 「계정에 등록된 이메일」의 일치 여부를 시스템이 직접 검증한다. 일치하지 않는다면 리셋 토큰은 등록된 이메일 쪽으로 전송되어야 한다. 그것이 계정 복구의 가장 기본적인 제1 방어선이다.

Meta의 챗봇이 호출한 코드 패스에서는 이 검증이 누락되어 있었다. Meta가 사건 직후 발표한 짧은 성명은 다음과 같이 적혀 있었다. 「별도의 코드 패스 버그로 인해, 시스템은 제공된 이메일 주소가 사용자의 Instagram 계정에 연결된 이메일 주소와 일치하는지 적절히 검증할 수 없었다.」 검증 함수 자체는 사내 인증 라이브러리에 존재했지만, 챗봇이 호출하는 신규 코드 패스에서는 그 함수가 누락된 채 출시되었다는 것을 의미한다. 흥미로운 점은 사후 대응의 속도다. Meta는 발견 당일에 챗봇을 무효화하고, 문제의 코드 패스를 삭제했으며, 영향을 받은 사용자의 패스워드를 일제히 리셋하고, 타 플랫폼의 챗봇에 동일한 결함이 없는지 감사(Audit)에 착수했다고 발표했다.

하지만 사건이 발견되기까지 두 달 가까이 걸렸다는 것은 무엇을 의미하는가. 정상적인 패스워드 리셋 플로우라면 보안 팀이 즉시 포착했을 패턴 — 등록 이메일과 다른 주소로 리셋 토큰이 전송되는 현상 — 이, 챗봇 경로에서는 별개의 로그 스트림(Log Stream)으로 흘러 기존의 침입 탐지 규칙(Intrusion Detection Rule)의 시야 밖에 있었다는 추측이 가능하다. AI 인터페이스 위에 새로운 플로우를 얹을 때, 그 플로우가 자동으로 기존의 검증·감사 인프라를 계승하는 것은 아니다. 이번 사건이 두 달 동안 지속된 진짜 이유는 바로 그 단절에 있다.

Hacker News의 댓글에서 사용자 jhhh는 날카로운 질문을 던졌다. (원문을 일본어로 바꾸어 인용한다.) 「『사용자가 다른 이메일을 요청할 수 있는가』는 이런 종류의 기능을 만들 때 가장 먼저 떠올리는 테스트가 아닌가. 왜 그것이 빠져 있었던 것인가.」 챗봇이라는 인터페이스가 덧씌워지자마자, 가장 기본적인 부정 케이스 테스트(Negative Case Test)가 누락된 것이다.

문제의 본질은 단 한 줄의 검증 누락이 아니다. 문제는 검증 판단의 일부를 LLM (Large Language Model)에 위임한 설계 그 자체에 있다. Hacker News의 사용자 ludwik은 다음과 같이 짧게 요약했다. (원문을 한국어로 번역하여 인용한다.) "이런 종류의 결정론적인(deterministic) 검증은 LLM의 역할이 아니며, 역할이 되어서도 안 된다. LLM이 호출하는 도구(tool)가 권한 레이어(permission layer)를 강제해야 한다." 이 말이 가리키는 구조는 명확하다. LLM은 자연어로 사용자의 의도를 해석하는 데까지 책임을 한정해야 한다. 비밀번호 재설정, 권한 변경, 계정 통합과 같은 결정론적인 작업은 LLM 외부의 도구가 자체적인 검증 로직을 가지고 거부권을 행사해야 한다.

Meta의 설명 — "챗봇은 의도한 대로 작동했으며, 버그는 다른 코드 경로(code path)에 있었다" — 는 기술적으로는 사실일지도 모른다. 하지만 Hacker News 사용자 nkrisc의 한 줄짜리 풍자는 이 변명의 모순을 정확히 찔렀다. (원문을 한국어로 번역하여 인용한다.) "도구는 의도한 대로 정확하게 움직였다. 다만 버그 때문에 의도한 대로도, 정확하게도 움직일 수 없었을 뿐이다." 사용자 mikeocool의 분석은 더욱 본질적이다. (원문을 한국어로 번역하여 인용한다.) "LLM은 본질적으로 '인간에 가까운 추론 능력을 갖추었다'라고 판매된다. LLM은 사용자의 요구를 의심하지 않고 즉시 절차를 실행했으며, 그 절차에 버그가 있었다. 인간 상담원도 사회 공학(social engineering)에 속아 넘어가지만, 이 정도 규모로 이토록 쉽게 속아 넘어간 사례는 본 적이 없다."

이 지적은 종종 간과되는 비대칭성을 보여준다. 인간 상담원이 비밀번호 재설정 요청을 받았을 때, "왜 다른 이메일로 보내달라고 하는가"라는 의구심은 일상적인 업무 훈련의 일부다. 본인 확인 절차가 강화된 통화는 별도로 분류되며, 수상한 패턴은 슈퍼바이저(supervisor)에게 에스컬레이션(escalation)된다. LLM 챗봇은 동일한 종류의 사회 공학에 대해 의심하도록 훈련되어 있지 않다. 더 정확히 말하면, 의심하는 행위가 LLM의 행동 패턴 속에서 신뢰할 수 있는 형태로 일관되게 나타나지 않는다. 동일한 프롬프트라도 어떤 때는 거부를 생성하고, 다른 때는 통과를 생성한다. 이러한 비결정성(non-determinism)은 결정론적인 보안 정책과 본질적으로 불협화음을 일으킨다.

여기에 또 다른 비대칭성이 겹친다. 사용자 mikeocool이 지적한 "규모와 용이성"이다. 인간 상담원에게 사회 공학을 시도하려면 건별로 전화를 걸어야 한다. 하지만 챗봇은 API 한 번으로 동시에 수천 건의 요청을 던질 수 있으며, 응답 패턴을 자동으로 분석하여 그중 성공하는 사례만 골라낼 수 있다. 동일한 사회 공학적 약점이 인간에게 있다면 노동 집약적인 공격이 되겠지만, AI에게 있다면 자동화 공격이 된다. 공격 비용은 두 자릿수 이상 낮아진다.

이번 사건이 의미하는 바는 Meta 한 기업의 보안 사고에 그치지 않는다. 지난 18개월 동안 거의 모든 대형 컨슈머 서비스 — Amazon, Apple, Google, 항공사, 통신 사업자 — 가 고객 대응의 최전선을 AI 챗봇으로 옮기는 흐름을 보여왔다. 비용 절감과 24시간 대응이라는 비즈니스 측면의 이점은 명확하지만, 그 최전선이 동시에 인증 흐름(authentication flow)의 일부를 담당할 때 어떤 종류의 리스크가 발생하는지에 대해서는 충분히 논의되지 않았다.

함의는 세 가지가 있다. 첫째, 결정론적인 검증은 LLM의 외부에 분리되어야 한다. 사용자 ludwik이 지적했듯이, LLM이 호출하는 도구(tool call의 엔드포인트)가 자체적인 권한 레이어를 강제해야 한다. "이 사용자가 등록된 이메일 외의 주소로 재설정 토큰을 보낼 자격이 있는가"라는 질문은 LLM의 응답 분기(branching)로 해결할 문제가 아니라, 도구 측에서 항상 거부하도록 코드로 강제해야 하는 사항이다. AI 세이프티(AI Safety) 분야에서 자주 인용되는 "권한과 가능성의 분리(separation of privilege and possibility)" 원칙이 바로 이 지점에서 적용된다.

둘째, AI 인터페이스에는 별도의 침입 탐지 규칙이 필요하다. 이번 사건이 두 달간 지속된 배경에는, 챗봇이 생성한 비밀번호 재설정 이벤트가 기존의 보안 모니터링 규칙의 시야에 들어오지 않았다는 가설이 자연스럽게 성립한다. 새로운 인터페이스를 출시할 때마다, 해당 인터페이스가 생성하는 이벤트 스트림(event stream)에 동일한 수준의 이상 탐지(anomaly detection)를 적용하는 운영 체크리스트가 필요하다. AI 인터페이스의 "릴리스 절차" 안에 보안 팀의 승인(sign-off)이 필수 단계로 포함되어야 한다.

셋째, 공격 측의 자동화 우위(automation advantage)를 전제로 설계해야 한다. Hacker News의 사용자 mikeocool이 지적한 "이 정도 규모로 당한 사례는 지금까지 없었다"라는 문장은 무거운 함의를 담고 있다. 사회공학(Social Engineering)의 비용은 LLM 인터페이스 위에서 자동화되며, 동일한 취약점이 수만 명의 피해를 낳는 속도는 인간 담당자 시대와 비교했을 때 두 자릿수 차이가 난다. 이는 LLM 응답의 변동성을 활용한 페일오버 공격(failover attack) — 동일한 요청을 다양한 표현으로 수백 번 던져, 우연히 성공하는 회차를 노리는 공격 — 이 새로운 표준 공격 패턴이 될 것임을 의미한다. 방어 측의 모델은 "단 한 번의 시도"가 아니라 "수천 번의 시도 중 단 한 번의 성공"을 막을 수 있는 설계여야 한다.

이번 사건은 또한 규제 측면의 공백도 부각시킨다. 미국 FTC와 EU의 GDPR은 모두 "개인정보 침해 통지 의무"를 부과하고 있지만, 그 의무가 발동되는 기준은 대체로 "데이터가 외부로 유출되었는가"이다. 이번 사건처럼 계정 자체가 탈취된 경우, 해당 사용자의 데이터가 새롭게 "유출"된 것으로 간주할 수 있는지에 대한 모호한 그레이존(gray zone)이 발생한다. Meta가 2만 명에게 통지한 행위가 법적 의무인지, 아니면 자발적인 베스트 프랙티스(best practice)인지조차 주(state)마다 다르다. AI 인터페이스 위에서 발생하는 인증 사고는 기존의 데이터 침해 통지 프레임워크의 사각지대에 빠지기 쉽다. 비밀번호 재설정 흐름이 LLM의 책임 분담선 위에 놓이는 시대에는, "통지 의무"의 트리거 자체를 재정의하라는 압력이 곧 몰려올 것이다. 캘리포니아 CCPA의 차기 개정안이 이 틈새를 어떻게 메울지가 관전 포인트다.

Meta의 공식 입장은 챗봇 자체가 아니라 별도의 코드 경로(code path) 버그가 문제였다는 것이다. 기술적인 의미에서 그 주장은 옳다. 하지만 그 변명에는 더 큰 질문이 빠져 있다. 왜 그 별도의 코드 경로가 챗봇과 결합된 형태로 릴리스되었는가? 왜 그 결합 지점에서는 기존의 보안 게이트(security gate)가 작동하지 않았는가? 왜 두 달 동안 아무도 그것을 알아차리지 못했는가? 이러한 질문에 답하지 않는 한, 다음 사건은 다른 회사, 다른 결제 시스템, 다른 인증 흐름에서 똑같은 모습으로 반복될 것이다.

진정한 교훈은 단순하다. AI 챗봇은 고객의 의도를 자연어로 해석하는 단계까지만 신뢰되어야 한다. 결정을 내리고, 리소스에 접근하며, 인증 상태를 변경하는 모든 행위는 LLM 외부의 결정론적인(deterministic) 도구가 자체적인 검증을 거쳐 수행해야 한다. 이 분리를 흐릴 때마다, 우리는 단 한 줄의 검증 누락이 2만 명의 계정을 잃게 만드는 구조를 새로 구축하는 것과 다름없다. Meta의 사건은 그 구조가 이미 우리 곁에 와 있다는, 더 이상 미룰 수 없는 신호다. 다음에 같은 사건이 발생할 회사가 어디냐가 아니라, 그 회사가 LLM의 책임 경계(responsibility boundary)를 어디에 그었느냐가 그 답을 결정할 것이다.