사용자의 PC를 직접 조작하는 AI, 오픈클로는 왜 국내 주요 IT 기업에서 오픈클로 사용 금지 조치까지 나왔을까요? 단순히 “새로운 기술이라 불안해서”가 아닙니다. 오픈클로는 대화형 AI의 범주를 넘어, 사용자의 화면을 인식하고 마우스·키보드를 조작해 실제 업무를 ‘수행’하는 구조를 갖고 있습니다. 이 ‘행동하는 AI’라는 특성이 생산성을 폭발시키는 동시에, 기업 보안 관점에서는 치명적인 취약점으로 이어질 수 있습니다.
오픈클로 사용 금지의 출발점: “답변하는 AI”가 아니라 “실행하는 AI”
기존 챗봇은 질문에 답을 “제시”하지만, 오픈클로는 프롬프트가 곧 실행 명령처럼 동작합니다. 즉, 사용자가 “이 파일 열어서 요약해줘”라고 말하면 끝나는 게 아니라, 에이전트가 실제로 다음을 수행할 수 있습니다.
- 로컬 파일 열기 및 내용 읽기
- 브라우저에서 웹 탐색 및 로그인 흐름 진행
- 다운로드·업로드, 폼 제출, 사내 도구 접속
- 스크립트 실행, 반복 작업 자동화
이 구조는 개발자·실무자 입장에서는 “손이 하나 더 생긴” 것처럼 강력하지만, 기업 입장에서는 권한을 가진 사용자의 PC를 통해 무엇이든 할 수 있는 자동화 주체가 생긴 것과 같습니다. 보안은 결국 “누가, 무엇을, 어디까지 할 수 있는가”의 문제인데, 에이전트형 AI는 이 경계를 흐리게 만듭니다.
오픈클로 사용 금지 이유 1: 기존 보안 체계가 ‘행동’을 제대로 감지하지 못한다
많은 기업 보안 도구는 파일/프로세스/네트워크 트래픽처럼 “전통적 이벤트”를 기반으로 탐지합니다. 그런데 오픈클로는 사람처럼 화면을 보고 클릭하고 타이핑합니다. 이때 발생하는 행위는 겉으로 보면 정상 사용자의 조작과 유사해져, 다음 문제가 생깁니다.
- 정책 우회가 쉬워짐: “사용자가 클릭했다”는 형태로 실행되면, 보안 솔루션이 악성 행위로 분류하기 어려울 수 있습니다.
- 감사/추적이 복잡해짐: 사람이 했는지, 에이전트가 했는지, 어떤 프롬프트가 원인이었는지 증빙이 어려워집니다.
- 최소권한 원칙이 무력화될 수 있음: 한 번 권한이 부여된 세션(로그인 상태, 토큰, 쿠키 등)을 에이전트가 연쇄적으로 활용할 수 있습니다.
즉, “악성 코드가 침투했다”가 아니라 ‘정상 권한’으로 비정상 범위의 자동 실행이 가능해지는 것이 핵심 위험입니다.
오픈클로 사용 금지 이유 2: 스킬(확장 기능) 생태계가 공급망 리스크를 키운다
오픈클로는 외부에서 배포되는 스킬(Skill) 형태의 기능 확장이 가능하다고 알려져 있습니다. 문제는 기업 환경에서 “외부 패키지 설치”는 곧 공급망 리스크(Supply Chain Risk)로 이어진다는 점입니다.
- 검증되지 않은 스킬 설치 → 악성 코드/백도어 포함 가능성
- 로컬 패키지 형태로 설치되는 경우 → 내부 단말에서 직접 실행되며 피해가 확산될 여지
- 스킬이 민감 정보(토큰, API 키, 계정 정보)를 다루면 → 노출 사고가 구조적으로 발생 가능
이 때문에 네이버·카카오·당근마켓 등은 오픈클로를 “편리한 자동화 도구”가 아니라 기업 보안 통제를 흔드는 외부 실행 체계로 평가할 수밖에 없습니다.
오픈클로 사용 금지 이유 3: 기본 보안 설정이 ‘선택 사항’이면, 결국 사고는 시간문제
에이전트형 AI는 강력한 만큼, 초기부터 강제되는 보안 장치가 촘촘해야 합니다. 하지만 현실에서는 다음과 같은 사례가 보고됩니다.
- 기본 보안 설정 없이 운영
- 인터넷에 노출된 제어판이 위험한 상태로 발견
- 원격 코드 실행 가능성이 제기되는 운영 형태
기업은 “개별 사용자가 설정을 잘하겠지”에 보안을 맡길 수 없습니다. 한 명의 실수, 한 번의 설정 누락이 곧 조직 전체의 정보자산 사고로 번질 수 있기 때문에 오픈클로 사용 금지 같은 강경 조치가 현실적인 선택지가 됩니다.
오픈클로 사용 금지 이유 4: 문서 한 장이 데이터 탈취 트리거가 될 수 있다(권한 기반 공격)
보안 관점에서 특히 위험한 시나리오는 ‘악성 명령이 섞인 입력’입니다. 예를 들어 문서나 웹페이지에 교묘하게 삽입된 지시문(프롬프트 인젝션)이 에이전트를 속이면, 에이전트는 사용자의 권한으로 다음을 수행할 수 있습니다.
- 파일 탈취(업로드/전송)
- 파일 삭제 또는 변조
- 민감 데이터 검색 및 요약 후 외부로 공유
핵심은 해커가 “시스템을 뚫는” 대신, 에이전트가 따르도록 ‘지시’를 설계한다는 점입니다. 사용자의 권한을 발판으로 움직이는 에이전트는, 보안 모델에 따라 “내부자 수준”의 위력을 낼 수 있습니다.
결론: 오픈클로 사용 금지의 본질은 ‘기술’이 아니라 ‘운용 모델’의 공백
오픈클로가 보여주는 혁신은 분명합니다. 하지만 기업 환경에서는 “생산성 향상”보다 “통제 가능성”이 먼저입니다. 국내 IT 기업들이 오픈클로 사용 금지로 빠르게 선회한 배경에는, 에이전트형 AI를 조직에 넣기 위한 표준 운영 모델—강제 인증, 접근 통제, 권한 분리, 감사 로그, 스킬 검증 체계—이 아직 충분히 성숙하지 않았다는 현실이 깔려 있습니다.
다음 섹션에서는, 기업이 에이전트형 AI를 완전히 포기하지 않고도 조건부로 안전하게 운영하려면 어떤 통제 장치가 필요한지 더 구체적으로 살펴보겠습니다.
오픈클로 사용 금지 맥락에서 본 행동하는 AI의 기술적 진화
단순 대화형 AI는 “무엇을 해야 하는지”를 말로 안내하는 데 그쳤습니다. 반면 오픈클로는 명령어(프롬프트)가 곧 실행으로 이어지는 구조를 채택해, 사용자의 PC에서 실제 행동을 수행합니다. 이 지점이 혁신이자, 많은 기업이 오픈클로 사용 금지를 선택하게 된 기술적 출발점입니다.
프롬프트가 ‘답변’이 아니라 ‘실행 계획’이 되는 방식
오픈클로 같은 에이전트형 AI는 보통 다음 흐름으로 동작합니다.
- 사용자 목표 입력: “월간 리포트 폴더를 열고, 최신 파일을 업로드해 공유해줘.”
- LLM의 계획 수립(Plan): 목표를 여러 단계 작업으로 쪼갭니다.
- 파일 탐색기 열기 → 폴더 이동 → 최신 파일 식별 → 웹 페이지 이동 → 업로드 버튼 클릭 → 완료 확인
- 행동 실행(Act): 각 단계마다 마우스 클릭, 키보드 입력, 창 전환 같은 OS 레벨 조작을 수행합니다.
- 화면/상태 확인(Observe): 실행 결과를 화면에서 다시 읽고 다음 행동을 결정합니다.
즉, 대화형 AI가 “방법을 설명하는 글”이라면, 행동하는 AI는 “직접 손을 움직여 일을 끝내는 실행자”에 가깝습니다.
사용자의 컴퓨터 환경을 직접 제어하는 핵심 원리
오픈클로가 업무 자동화를 가능하게 하는 기술적 핵심은 ‘화면을 인식하고, 입력 장치를 조작하는 루프(Observe → Think → Act)’입니다.
- 화면 인식: 현재 열려 있는 창, 버튼 위치, 텍스트 입력창 등 UI 요소를 화면에서 파악합니다.
- 입력 이벤트 생성: 마우스 이동/클릭, 드래그, 키보드 타이핑, 단축키 입력 등을 만들어냅니다.
- 상태 기반 반복 실행: “업로드 완료” 같은 결과 신호가 보일 때까지 단계들을 반복하거나, 오류가 뜨면 다른 경로로 재시도합니다.
이 구조 덕분에 별도 API가 없는 웹사이트나 사내 시스템이라도, 사람이 하던 방식 그대로 자동화할 수 있습니다. 하지만 같은 이유로, 기업 관점에서는 ‘사람에게 주어진 권한을 AI가 그대로 행사’한다는 의미가 되어 보안 우려가 급격히 커집니다.
“스킬(Skill)”과 외부 연동이 생산성을 키우는 이유, 그리고 위험이 되는 이유
오픈클로 생태계에서 반복 업무를 더 빠르게 만들려면 종종 스킬(플러그인/확장 기능)이나 외부 연동을 사용합니다.
예를 들어, 특정 양식으로 문서를 정리하거나, 지정된 사이트를 자동 로그인해 처리하는 작업을 모듈처럼 붙일 수 있습니다.
- 장점: 업무 절차가 표준화되고 자동화 수준이 높아집니다.
- 리스크: 검증되지 않은 스킬이 설치되면 공급망 리스크가 발생할 수 있고, 스킬이 접근하는 파일·토큰·세션 정보가 그대로 노출될 가능성도 커집니다.
이처럼 “행동하는 AI의 확장성”은 곧 “공격 표면의 확장”이기도 합니다. 국내 주요 IT 기업들이 오픈클로 사용 금지를 선택한 배경에는, 바로 이 구조적 특성(실행 권한·연동·확장)이 있습니다.
정리: ‘행동’이 추가되는 순간 보안 모델이 달라진다
오픈클로의 기술적 진화는 분명 매력적입니다. 대화형에서 행동형으로 넘어오며, AI는 “조언자”에서 “실행자”가 됩니다. 다만 실행자가 되는 순간, 기업 보안은 기존의 문서/대화 중심 통제가 아니라 실행 통제, 권한 통제, 확장 기능 검증까지 전제로 다시 설계되어야 합니다. 이 간극이 메워지지 않으면, 오픈클로는 생산성 도구이면서 동시에 오픈클로 사용 금지라는 강한 정책을 부르는 대상이 될 수밖에 없습니다.
숨겨진 위험: 오픈클로 사용 금지가 말해주는 기업 보안을 무너뜨리는 구조적 결함
왜 기업들은 오픈클로를 금지했을까요? 핵심은 “AI가 답을 하는 도구”를 넘어 사용자 PC를 대신 조작하는 실행 주체라는 점입니다. 오픈클로는 화면을 인식하고 마우스·키보드를 직접 움직이며 파일 열기, 웹 탐색, 스크립트 실행 같은 행동을 자율 수행합니다. 이 구조는 생산성을 끌어올리는 동시에, 기업 보안 관점에서는 통제 경계(보안 경계)를 안쪽에서 무너뜨리는 설계로 해석됩니다.
기존 보안 도구가 무력화되는 이유: “대화”가 아니라 “실행”이기 때문
기업 보안 체계는 보통 네트워크, 애플리케이션, 파일 접근, 계정 권한 등으로 위험을 분리해 감시합니다. 그런데 오픈클로는 프롬프트가 사실상 실행 지시가 되어, 아래와 같은 우회가 쉬워집니다.
- 행위가 정상 사용자 조작처럼 보임: 오픈클로가 마우스 클릭과 키보드 입력으로 작업을 수행하면, 많은 보안 솔루션은 이를 “사용자 행동”으로 인식해 이상 징후를 정확히 분리하기 어렵습니다.
- 의도와 결과 사이의 검증 공백: “어떤 의도로(프롬프트)” 실행됐는지와 “실제로 무엇이 실행됐는지(행동)”를 기업 보안 로그가 일대일로 추적하기가 어렵습니다. 결과적으로 정책 기반 차단(예: 특정 행위 금지)이 느슨해질 수 있습니다.
이 때문에 기업 입장에선 오픈클로 사용 금지가 단순히 보수적 결정이 아니라, 탐지·감사·통제 모델이 따라가지 못하는 구조적 문제에 대한 대응이 됩니다.
공급망 리스크: ‘스킬’이 새로운 침투 경로가 되는 순간
오픈클로 생태계는 외부에서 배포되는 스킬(Skill)을 설치해 기능을 확장할 수 있는데, 여기서 공급망 리스크가 커집니다.
- 검증되지 않은 패키지 설치 위험: 스킬이 로컬 파일 패키지 형태로 설치되는 방식이라면, 기업 표준 소프트웨어 유통·검증 절차(서명 검증, 취약점 스캔, 승인 프로세스)를 우회할 가능성이 있습니다.
- 의존성/업데이트 체인 악용: 스킬 자체뿐 아니라, 스킬이 호출하는 외부 라이브러리나 업데이트 경로가 오염되면 악성 코드가 연쇄적으로 유입될 수 있습니다.
즉, “에이전트가 잘 일하게 만들기 위한 확장 기능”이 기업 보안에선 새로운 공급망 공격면(Attack Surface)이 됩니다.
기본 보안 설정의 허술함: 노출된 제어판은 ‘원격 실행’로 이어진다
에이전트형 도구는 편의성을 위해 대시보드, 원격 제어 기능, 외부 연동을 제공하는 경우가 많습니다. 문제는 일부 환경에서 기본 보안 설정이 느슨하거나 선택 사항에 가깝게 운용되면, 다음과 같은 사고로 직결됩니다.
- 인터넷에 노출된 관리 인터페이스: 외부에서 접근 가능한 제어판이 존재할 경우 인증/인가가 약하면 공격자가 기능을 탈취할 수 있습니다.
- 원격 코드 실행(RCE)로 확대 가능: 에이전트는 원래 파일 실행·스크립트 실행 같은 고위험 동작을 합법적으로 수행하므로, 제어권이 탈취되는 순간 피해가 급격히 커집니다.
이 지점에서 오픈클로 사용 금지는 “도구 자체의 선악”이 아니라 운용 안정성의 최소 요건을 맞추기 어렵다는 현실적 판단으로 이어집니다.
권한 기반 데이터 탈취: 에이전트는 ‘당신의 권한’으로 움직인다
오픈클로의 가장 본질적인 위험은 사용자 권한을 그대로 상속받아 행동한다는 점입니다. 보안 관점에서 이는 “AI가 해킹한다”가 아니라, 더 무서운 형태인 정상 권한을 이용한 데이터 유출로 나타납니다.
- 악성 지시가 문서/웹에 섞일 수 있음: 문서나 웹페이지에 악성 명령이 숨겨져 있을 경우, 에이전트가 이를 지시로 해석해 파일을 열고 복사하거나 외부로 전송할 수 있습니다.
- 인증정보 노출 가능성: 스킬 마켓플레이스나 연동 과정에서 토큰·키·계정 정보가 노출되면, 이후 공격자는 기업 시스템에 “정상 로그인” 형태로 침투할 수 있습니다.
- 삭제/변조까지 가능: 파일 접근 권한이 있는 계정으로 실행되는 만큼, 유출뿐 아니라 삭제·변조 같은 무결성 훼손도 동시에 발생할 수 있습니다.
결국 기업이 두려워하는 것은 단일 취약점이 아니라, 에이전트의 설계 자체가 권한 오남용을 자동화·증폭시킨다는 점입니다.
정리하면, 오픈클로는 반복 업무를 빠르게 처리하는 강력한 도구이지만, 기업 환경에서는 탐지 어려움(보안 도구 무력화) + 공급망 확장 + 설정 미흡 + 권한 상속이 겹치며 사고 가능성을 구조적으로 키웁니다. 그래서 많은 조직에서 오픈클로 사용 금지는 일시적 유행 차단이 아니라, 현재 보안 체계로 감당하기 어려운 위험에 대한 ‘선제적 방화벽’에 가깝습니다.
기업과 글로벌 보안 업계가 말하는 오픈클로 사용 금지 ‘보안 우선’ 전략
카카오, 네이버, 당근마켓이 오픈클로를 차단한 이유는 단순히 “AI가 무섭다”가 아닙니다. 오픈클로(OpenClaw)는 화면을 인식하고 마우스·키보드를 직접 조작하는 ‘행동형 AI’라서, 기업 PC에서 돌아가는 순간 사람이 가진 권한을 그대로 이어받아 시스템을 움직일 수 있기 때문입니다. 즉, 생산성을 올릴 수 있는 만큼 한 번의 오작동·악용이 곧바로 사고로 이어질 수 있는 구조입니다.
국내 IT 기업들이 오픈클로 사용 금지를 선택한 이유: “에이전트형 AI는 기존 통제 모델로 다루기 어렵다”
카카오·네이버·당근마켓의 대응은 공통적으로 ‘회사 정보자산 보호’를 최우선에 둡니다. 특히 기업 환경에서 오픈클로가 위험해지는 지점은 다음과 같습니다.
프롬프트가 실행 명령이 되는 구조 기존 챗봇은 “답변”을 하지만, 오픈클로는 프롬프트가 곧 실행 트리거가 되어 파일 열기, 웹 탐색, 스크립트 실행 같은 동작을 수행합니다. 이때 기업의 보안 체계가 보통 전제하는 “사용자 의도 확인 → 승인 → 실행” 흐름이 약해집니다.
기존 보안 도구의 가시성(Visibility) 저하 사용자가 타이핑한 자연어가 실제로는 “행동”으로 바뀌기 때문에, 기존 보안 솔루션이 위험 행위를 정책적으로 분류하거나 사전 차단하기가 까다로워집니다. 결과적으로 보안 검증을 우회할 가능성이 커집니다.
공급망 리스크: ‘스킬(Skill)’ 설치가 취약점이 된다 외부에서 배포되는 스킬을 검증 없이 설치하면 악성 코드가 내부로 들어올 수 있습니다. 특히 스킬이 로컬 파일 패키지 형태로 설치되는 방식은 검증·추적·차단을 더 어렵게 만듭니다.
기본 보안 설정의 부재가 곧 원격 침해로 연결 일부 사례에서 기본 보안 설정이 미흡한 채 운영되었고, 인터넷에 노출된 제어판이 원격 코드 실행 가능 상태로 발견되기도 했습니다. 기업 입장에서는 “사용자 실수”가 아니라 구조적으로 반복될 수 있는 운영 리스크로 보게 됩니다.
권한 기반 데이터 탈취 시나리오가 현실적 보안 기업 제니티(Zenity)는 문서에 악성 명령을 삽입해 오픈클로가 파일을 탈취·삭제할 수 있음을 실증했습니다. 에이전트가 가진 권한 범위 내에서라면, 정보 유출은 매우 자연스럽게 발생할 수 있습니다.
이런 이유로 국내 기업들은 네트워크 차단, 업무용 기기 제한 등 운영 단계에서 ‘원천 차단’에 가까운 오픈클로 사용 금지로 기우는 것입니다. “도입 후 통제”가 아니라 “통제 준비 전에는 도입하지 않는다”는 판단이죠.
글로벌 보안 업계의 결론: 혁신이지만, 잘못 쓰면 ‘악몽’
국내만의 과민 반응이 아닙니다. 글로벌 보안 업계와 전문가들도 에이전트형 AI를 고위험 범주로 분류합니다.
시스코(Cisco): 혁신적 도구이지만 보안 측면에서는 “악몽”에 가깝다고 평가
핵심은 오픈클로 같은 에이전트가 사용자 행위를 자동화하는 수준을 넘어, 기업 자산에 대한 접근을 “실행”으로 전환한다는 점입니다.안드레이 카르파시(테슬라 전 AI 디렉터): 개인 PC에서도 데이터가 심각한 위험에 노출될 수 있다고 경고
개인 환경에서도 위험하다면, 권한과 데이터가 훨씬 큰 기업 환경에서는 리스크가 더 커질 수밖에 없습니다.
정부 기관의 접근: 전면 금지보다 “강한 인증·접근 통제”를 요구
중국 공업정보화부(MIIT)는 오픈클로가 부적절하게 설정되면 사이버 공격·데이터 유출이 발생할 수 있다고 지적하면서도, 전면 금지보다는 조건부 운영에 가까운 권고를 제시했습니다. 핵심은 다음 두 가지입니다.
- 강력한 신원 인증(누가 실행하는가)
- 접근 통제 강화(어디까지 실행할 수 있는가)
이는 기업이 오픈클로 같은 도구를 쓰려면, 최소한 권한 최소화(Least Privilege), 실행 승인 체계, 외부 연동 통제, 감사 로그 같은 기본 통제 장치를 갖춘 뒤에야 가능하다는 의미입니다.
‘보안 우선’ 전략의 핵심: 도구를 탓하기보다, 운영 모델을 먼저 바꿔라
이번 논쟁의 본질은 기술 자체보다 운용 방식에 있습니다. 오픈클로는 생산성 도구로 강력하지만, 기업 시스템에서는 “자동화”가 곧 “자동 침해”로 바뀔 수 있습니다. 그래서 많은 조직이 지금 내리는 결론은 단순합니다.
- 통제 모델이 준비되지 않았다면: 오픈클로 사용 금지
- 도입이 필요하다면: 인증·권한·스킬 검증·감사 체계를 먼저 설계한 뒤 조건부로 제한 운영
결국 ‘보안 우선’은 반(反)AI가 아니라, 에이전트형 AI를 기업 환경에 맞게 다루기 위한 최소한의 현실주의입니다.
오픈클로 사용 금지의 본질: 기술이 아닌 운용·통제 모델의 문제
오픈클로 사태가 던진 가장 큰 교훈은 단순합니다. 위험한 것은 ‘AI 에이전트’라는 기술 그 자체라기보다, 그 기술을 안전하게 다룰 운용과 통제 모델이 준비되지 않았다는 현실입니다. 네이버·카카오·당근마켓 등에서 오픈클로 사용 금지가 빠르게 확산된 것도, “유용하지만 통제 불가능한 도구”가 기업 환경에 들어왔을 때 어떤 일이 벌어지는지 보여주는 사건이었습니다.
오픈클로는 사용자의 PC에서 화면을 인식하고 마우스·키보드를 조작하며 파일·웹·스크립트 실행까지 수행합니다. 즉, 프롬프트가 곧 실행 명령이 되는 구조이기 때문에, 기존의 “사람이 클릭하고 실행한다”는 전제 위에 구축된 보안 체계와 자주 충돌합니다. 이 충돌 지점이 바로 논쟁의 핵심입니다.
오픈클로 사용 금지가 말해주는 것: ‘행동 권한’이 곧 공격면(Attack Surface)이다
기업 보안은 본질적으로 “누가(주체) 무엇을(대상) 어디까지(권한) 했는가(행위)”를 기록하고 통제하는 체계입니다. 그런데 에이전트형 AI는 다음 특성 때문에 공격면을 급격히 키웁니다.
- 행위의 자동화·연쇄 실행: 한 번의 프롬프트가 웹 탐색 → 파일 다운로드 → 실행 → 내부 문서 접근 같은 연쇄 행동으로 이어질 수 있습니다. 사람이라면 중간중간 멈추고 의심할 지점이, 에이전트에게는 “목표 달성을 위한 단계”가 됩니다.
- 탐지의 난이도 증가: 기존 보안 도구는 악성 파일, 의심 프로세스, 비정상 네트워크 패턴을 중심으로 탐지합니다. 하지만 에이전트는 정상 사용자 흐름을 모방해 움직이므로, “악성 행위”와 “업무 자동화”의 경계가 흐려집니다.
- 권한 기반 데이터 탈취 가능성: 에이전트는 사용자가 가진 권한으로 움직입니다. 사용자가 접근 가능한 문서·메일·클라우드가 많을수록, 유출 가능 범위도 커집니다.
결국 오픈클로 사용 금지는 “AI가 나쁘다”가 아니라, ‘행동 권한을 가진 소프트웨어’를 기업이 관리할 준비가 되어 있지 않다는 선언에 가깝습니다.
왜 ‘운용 방식’이 핵심인가: 보안은 기능이 아니라 체계다
오픈클로 논쟁을 기술 결함으로만 보면 해법도 “기능을 고치자”로 끝납니다. 하지만 실제로는 다음 3가지가 동시에 필요합니다.
- 정책(Policy): 어떤 업무에 에이전트를 허용/금지할지, 데이터 등급별 접근 기준은 무엇인지
- 통제(Control): 실행·네트워크·파일·자격증명(credential) 접근을 어떻게 제한할지
- 감사(Audit): 무엇을 언제 어떻게 했는지 재현 가능한 로그를 남기는지
이 3요소가 없는 상태에서의 도입은, 생산성은 잠깐 오르더라도 사고 비용이 급격히 커질 수밖에 없습니다. 그래서 기업은 “조건부 허용”보다 “일괄 차단”을 더 쉽게 선택합니다. 관리 체계가 준비되지 않으면, 금지가 가장 싼 선택지이기 때문입니다.
미래 방향: 오픈클로 사용 금지 이후, 기업과 개발자가 준비해야 할 ‘안전한 AI 에이전트’ 조건
전면 금지가 영구 해답일 가능성은 낮습니다. 반복 업무 자동화 수요는 계속 커질 것이고, 에이전트형 AI는 결국 업무 도구로 들어옵니다. 다만 다음과 같은 방향으로 “운용 가능한 기술”로 진화해야 합니다.
- 권한 최소화(Least Privilege)와 작업 단위 샌드박싱
- 에이전트를 개인 PC 전체가 아니라, 격리된 가상 환경/업무 컨테이너에서만 실행
- 파일 시스템·클립보드·브라우저 저장 비밀번호 접근을 기본 차단하고, 필요 시 승인 기반으로 개방
- 스킬(플러그인) 공급망 검증
- 스킬을 “로컬 설치 파일”이 아니라 서명된 패키지로 배포하고, 버전 고정·해시 검증·평판 기반 허용 목록(allowlist)을 운영
- 기업 내부에서 검증된 스킬만 마켓 형태로 제공(사내 레지스트리)
- 감사 가능한 실행 로그와 재현성
- 어떤 프롬프트가 어떤 행동을 유발했는지(명령-행동 매핑), 파일/URL/프로세스 변경 이력을 표준 포맷으로 기록
- 사고 시 “누가 무엇을 시켰고 무엇이 실행됐는지”를 재현 가능해야 함
- 데이터 경계 설정(DLP + 비밀정보 차단)
- 민감정보(키, 토큰, 개인정보, 고객 데이터)가 프롬프트·스킬 설정·로그로 흘러가지 않도록 자동 마스킹/차단
- 외부 전송(업로드, API 호출)을 업무 도메인/목적별로 제한
