AI 비서의 위험한 진화…‘오픈클로’가 던진 경고
개인 개발자가 만든 LLM 기반 AI 비서 ‘오픈클로’가 폭발적인 관심을 끌고 있다. 그러나 방대한 개인정보 접근과 보안 취약성 논란이 확산되며 AI 에이전트의 위험성이 다시 주목받고 있다.
인공지능(AI) 에이전트는 본질적으로 위험을 내포한 기술이다. 대형언어모델(LLM)은 채팅창 안에서 작동할 때조차 오류를 내거나 엉뚱한 행동을 한다. 여기에 웹 브라우저나 이메일 계정처럼 외부와 직접 상호작용할 수 있는 도구까지 주어지면 작은 실수도 훨씬 큰 문제로 번질 수 있다.
이런 맥락에서 최근 가장 큰 반향을 일으키고 있는 LLM 기반 개인 비서 ‘오픈클로(OpenClaw)’가 평판과 법적 책임을 동시에 고려해야 하는 대형 AI 연구소가 아니라 상대적으로 이런 문제로부터 자유로운 개인 개발자의 손에서 나왔다는 사실은 시사하는 바가 크다. 오픈클로는 독립 소프트웨어 엔지니어 피터 슈타인베르거(Peter Steinberger)가 2025년 11월 코드 공유 플랫폼 깃허브(GitHub)에 공개하면서 지난 1월 말 온라인을 중심으로 빠르게 확산되며 단숨에 화제의 중심에 섰다.
오픈클로는 오픈소스 기반 개인용 AI 비서로, 사용자가 기존 LLM을 활용해 자신의 컴퓨터나 장치에서 실행하며 이메일 정리, 일정 관리, 웹 브라우저 조작, 파일 작업 등 실제 작업을 자동화할 수 있는 도구다. 그러나 그 편의성에는 분명한 대가가 따른다. 수년간 쌓인 이메일과 하드드라이브에 저장된 각종 파일 등 방대한 개인정보를 AI에 통째로 맡겨야 할 수도 있기 때문이다.
이 지점에서 보안 전문가들의 경고가 이어지고 있다. 최근 몇 주 사이 오픈클로의 위험성을 지적하는 보안 관련 블로그 글이 쏟아졌고, 중국 정부마저 오픈클로의 보안 취약성과 관련해 공개적으로 경고에 나설 정도다.
논란이 커지자 슈타인베르거는 엑스(X)에 “기술적 배경이 없는 사람은 이 소프트웨어를 사용하지 말아달라”고 적었다. 그는 이번 기사와 관련한 취재 요청에는 응하지 않았다. 개발자 스스로 사용을 경고할 만큼 위험성이 지적되고 있지만, 오픈클로가 제시한 개인 비서 모델에 대한 관심은 좀처럼 식지 않고 있다. 그 수요는 자체적으로 보안 점검을 수행할 수 있는 전문가 집단에만 머물지 않는다.
이 같은 흐름은 개인 개발자의 실험을 넘어 AI 업계 전반에 던지는 과제로 이어진다. 개인 비서 시장에 뛰어들려는 AI 기업이라면 사용자 데이터를 안전하게 보호할 수 있는 체계를 어떻게 구축할지부터 고민해야 한다. 이를 위해서는 에이전트 보안 연구의 최전선에서 축적된 접근법을 적극적으로 참고할 필요가 있다.
리스크 관리
오픈클로는 본질적으로 LLM에 ‘메카 슈트’, 즉 강화 장비를 입히는 구조에 가깝다. 사용자는 원하는 LLM을 ‘조종사’로 선택할 수 있고, 선택된 LLM은 확장된 메모리 기능과 함께 스스로 작업을 설정해 일정한 주기로 반복 수행하는 능력을 갖는다. 주요 AI 기업들이 선보인 에이전트형 서비스와 달리 오픈클로 에이전트는 24시간 상시 작동하도록 설계돼 있으며, 사용자는 왓츠앱 같은 메신저 앱을 통해 이들과 소통할 수 있다. 이론적으로는 매일 아침 개인 맞춤형 일정을 만들어 사용자를 깨우고, 업무 시간 동안 여행 일정을 짜며, 틈이 날 때마다 새로운 앱을 만들어 실행하는 개인 비서처럼 활용할 수 있다는 의미다.
그러나 이 같은 권한 확대에는 분명한 대가가 따른다. AI 개인 비서가 이메일함을 관리하도록 하려면 이메일 접근 권한과 그 안에 담긴 민감한 정보까지 넘겨야 한다. 대신 물건을 구매하게 하려면 신용카드 정보를 제공해야 하고, 컴퓨터에서 코드 작성과 같은 작업을 수행하게 하려면 로컬 파일에 대한 접근 권한도 허용해야 한다. 편의성과 맞바꾼 통제권의 일부를 기계에 넘기는 셈이다.
위험이 현실화되는 경로는 몇 가지로 나뉜다. 첫째는 에이전트 자체의 오류다. 실제로 한 사용자의 구글 안티그래비티(Antigravity) 코딩 에이전트가 하드드라이브 전체를 삭제한 사례가 보고되기도 했다. 둘째는 외부 공격이다. 기존 해킹 기법을 활용해 누군가 에이전트에 침투할 경우 민감한 데이터를 탈취하거나 악성 코드를 실행할 수 있다. 오픈클로가 주목을 받기 시작한 이후 보안 연구자들은 이러한 가능성을 보여주는 다수의 취약점을 공개했으며, 특히 보안에 익숙하지 않은 사용자가 위험에 노출될 수 있다고 경고하고 있다.
이 두 가지 위험은 일정 부분 통제할 수 있다. 일부 사용자는 오픈클로 에이전트를 별도의 컴퓨터나 클라우드 환경에서 실행해 하드드라이브 데이터가 삭제되는 사태를 피하고 있으며, 다른 취약점 역시 이미 검증된 보안 기법을 적용해 보완이 가능하다.
그러나 이번 취재에서 만난 전문가들이 더 우려한 지점은 더욱 교묘한 수법인 ‘프롬프트 인젝션(prompt injection)’이다. 이는 사실상 LLM을 가로채는 공격 방식으로, 모델이 참고할 수 있는 웹사이트에 악성 문구나 이미지를 숨겨두거나 LLM이 읽는 이메일함에 이를 심어두는 것만으로도 공격자는 모델의 행동을 자신이 원하는 방향으로 틀 수 있다.
문제는 해당 LLM이 사용자의 개인정보에 접근할 수 있는 권한까지 갖고 있을 경우다. 니콜라스 파페르노(Nicolas Papernot) 토론토대학교 전기·컴퓨터공학과 교수는 “오픈클로와 같은 도구를 사용하는 것은 길거리에서 만난 낯선 사람에게 지갑을 맡기는 것과 같다”며 “주요 AI 기업이 개인 비서를 안심하고 제공할 수 있을지는 이런 공격에 대해 얼마나 탄탄한 방어 체계를 갖추느냐에 달려 있다”고 말했다.
아직까지 프롬프트 인젝션이 대규모 피해로 이어졌다는 공개 보고는 없다. 그러나 인터넷상에서 수십만 개에 이를 것으로 추정되는 오픈클로 에이전트가 활동하고 있다는 점을 감안하면, 이 공격 기법은 사이버 범죄자에게 점점 더 매력적인 표적이 될 수 있다. 파페르노는 “이 같은 도구는 악의적 행위자들이 훨씬 더 광범위한 집단을 겨냥하도록 유인한다”고 지적했다.
방어선 구축
‘프롬프트 인젝션’이라는 용어는 유명 LLM 관련 블로거 사이먼 윌리슨(Simon Willison)이 2022년에 처음 사용했다. 챗GPT가 공개되기 불과 몇 달 전이었다. 당시에도 LLM이 대중화될 경우 전혀 새로운 유형의 보안 취약점이 등장할 수 있다는 점은 이미 감지되고 있었다.
LLM은 사용자가 내린 지시와 그 지시를 수행하는 데 참고하는 데이터, 예컨대 이메일이나 웹 검색 결과를 구분하지 못한다. 모델의 입장에서 이 모든 것은 그저 텍스트일 뿐이다. 따라서 공격자가 이메일에 몇 줄의 문장을 교묘히 끼워 넣고 LLM이 이를 사용자 지시로 오인할 경우 모델은 공격자가 설계한 대로 행동할 수 있다.
프롬프트 인젝션은 단기간에 해결될 문제로 보이지 않는다. 돈 송(Dawn Song) 버클리대학교 컴퓨터과학과 교수는 “현재로서는 결정적인 방어 수단이 없다”며 “다만 학계에서 이 문제를 활발히 연구하고 있으며 장기적으로는 AI 개인 비서를 보다 안전하게 만들 수 있는 방안이 축적되고 있다”고 말했다.
기술적으로만 보자면 프롬프트 인젝션 위험을 차단한 채 오픈클로를 사용할 수 있는 방법이 있다. 인터넷에 연결하지 않는 것이다. 그러나 그렇게 되면 이메일을 읽거나, 일정을 관리하고, 온라인 정보를 조사하는 등 핵심 기능을 활용할 수 없게 돼 AI 비서를 쓰는 의미가 크게 줄어든다. 결국 관건은 LLM이 외부 공격에는 반응하지 않으면서도 본래 수행해야 할 작업은 그대로 처리하도록 만드는 데 있다.
한 가지 접근법은 LLM이 프롬프트 인젝션을 무시하도록 훈련하는 것이다. LLM 개발의 핵심 단계인 사후 훈련(post-training)은 사실적인 문장을 생성하는 모델을 유용한 비서로 다듬는 과정으로, 적절한 응답에는 보상을 주고 부적절한 응답에는 제재를 가하는 방식으로 조정된다. 이는 비유적인 표현이지만 모델은 이러한 피드백을 반복적으로 학습하며 특정 유형의 프롬프트 인젝션에 반응하지 않도록 훈련될 수 있다.
그러나 여기에는 균형이 필요하다. 삽입된 명령을 지나치게 거부하도록 학습시키면 정당한 사용자 요청까지 차단할 위험이 있다. 또한 LLM의 작동에는 언제나 일정 수준의 무작위성이 내재해 있어 아무리 정교하게 훈련하더라도 간헐적인 실수를 완전히 없애기는 어렵다.
또 다른 접근법은 프롬프트 인젝션이 LLM에 도달하기 전에 차단하는 방식이다. 통상적으로는 별도의 탐지용 LLM을 활용해 원래 모델로 전달되는 데이터에 프롬프트 인젝션이 포함돼 있는지를 판별한다. 그러나 최근 연구에 따르면 가장 성능이 뛰어난 탐지기조차 특정 유형의 프롬프트 인젝션 공격을 전혀 걸러내지 못한 사례가 확인됐다.
세 번째 전략은 한층 복잡하다. 입력을 사전에 걸러내는 대신 LLM의 행동 범위를 규정하는 기준을 마련해 위험한 행위를 구조적으로 제한하는 방식이다. 예를 들어 LLM이 사전에 승인된 몇 개의 이메일 주소로만 메일을 보낼 수 있도록 설정하면 사용자 신용카드 정보가 공격자에게 전송되는 상황을 원천적으로 차단할 수 있다. 그러나 이런 제약은 사용자를 대신해 새로운 비즈니스 관계를 탐색하고 필요한 사람에게 먼저 연락하는 일처럼 유용한 기능까지 막아버릴 수 있다.
닐 공(Neil Gong) 듀크대학교 전기·컴퓨터공학과 교수는 “문제는 그 기준을 얼마나 정교하게 설계하느냐에 달려 있다”며 “결국 유용성과 보안 사이의 균형을 어디에 두느냐의 문제”라고 말했다.
더 큰 틀에서 보면 에이전트 생태계 전반이 같은 질문에 직면해 있다. 어느 시점에서 에이전트는 충분히 안전하면서도 동시에 유용해질 수 있는가. 전문가들의 견해는 엇갈린다. 에이전트 보안 플랫폼을 개발하는 스타트업 버추 AI(Virtue AI)를 이끌고 있는 돈 송 교수는 “지금도 AI 개인 비서를 안전하게 배포하는 것이 가능하다”고 본다. 반면 닐 공 교수는 “아직은 그 단계에 이르지 못했다”고 말했다.
비록 AI 에이전트를 프롬프트 인젝션으로부터 완전히 차단하기는 어렵더라도 위험을 낮출 방법은 존재한다. 일부 기술은 오픈클로에도 적용될 수 있다. 지난주 샌프란시스코에서 열린 오픈클로 행사 클로콘(ClawCon)에서 슈타인베르거는 “보안 전문가를 영입해 도구 개선 작업에 착수했다”고 밝혔다.
현재로서는 오픈클로가 여전히 취약한 상태임에도 사용자들의 관심은 이어지고 있다. 오픈클로 깃허브 저장소의 유지관리자이자 열성 사용자 조지 피켓(George Pickett)은 “사용 과정에서 몇 가지 보안 조치를 취하고 있다”며 “하드드라이브를 실수로 삭제하는 일을 막기 위해 클라우드 환경에서 오픈클로를 실행하고 있고, 타인이 접속하지 못하도록 별도의 장치도 마련해 두었다”고 말했다.
다만 그는 “프롬프트 인젝션을 막기 위한 별도의 대응은 하지 않았다”고 밝혔다. 피켓은 “위험성을 알고는 있지만 오픈클로에서 해당 공격이 실제로 발생했다는 사례는 아직 보지 못했다”며 “어리석은 생각일 수 있지만 내가 가장 먼저 해킹당할 가능성은 낮다고 본다”고 말했다.
The post AI 비서의 위험한 진화…‘오픈클로’가 던진 경고 appeared first on MIT 테크놀로지 리뷰 | MIT Technology Review Korea.