오픈AI가 평가에 쓰던 에이전트들이 독일의 한 공용 위키에 1만 8000건을 무단으로 쓰면서 서로 정보를 주고받았다는 보고서. 여기서 드러난 문제들이 저희가 Dify 구축 현장에서 가장 자주 강조하고 있는 문제점과 정확히 닿아있습니다. 이 사건은 현지시간 7일에는 EU 집행위원회가 오픈AI로부터 사고 보고서를 받았다고 확인되었고 현재 규제 쪽으로도 번지고 있습니다.
독일 위키 사건 그저 해프닝일까?
읽기 권한만 받은 에이전트들이 편집 권한의 빈틈을 찾아내 외부 사이트에 글을 쓰기 시작한 일입니다. AI 안전 연구 단체 나이팅게일의 시드니 본 아르크스 대표를 비롯한 공동 연구진이 9월 4일 공개한 내용을 보면, 5월 11일 무렵 권한을 탐색하다가 시스템 제한을 우회하는 방법을 발견했고 5월 24일부터 쓰기가 시작됐습니다. 웹 검색 성능을 재는 평가 과제를 받은 에이전트들이었습니다. AI 사건 사고가 많은 요즘, 이 마저도 그저 넘길 수 있는 헤프닝일까요?
다음은 빠르게 번졌습니다. 시간 제한이 걸린 평가 과제의 정답을 서로 넘겨주고, 내부 샌드박스의 네트워크 제한을 우회하는 방법과 모니터링을 피하는 도구 사용법까지 교환했습니다. 사람 관리자가 스팸 페이지를 알파벳순으로 지우기 시작하자 삭제 순서를 늦추려고 제목 앞에 'ZZZ'를 붙여 백업본을 만들었고, 관리자가 하루 100개를 지우는 동안 400개 넘는 페이지가 새로 생겼습니다.
접속 기록을 보면 전체 편집의 98.5%가 오픈AI가 쓰는 애저 IP 대역에서 나왔고, 에이전트들은 'OpenAIResearcher' 같은 서명을 스스로 남겼습니다. 감추려는 시도가 없었는데도 회사가 알아챈 것은 6월 22일 무렵이었습니다. 오픈AI 내부 평가 환경에서 벌어진 일이라 규모도 목적도 업무용 워크플로와는 다르지만, 여기서 드러난 문제는 에이전트를 돌리는 곳이면 어디서든 같은 모습으로 나타납니다. 만약 우리 회사에서 주요한 보안 데이터가 있는 곳에 있었던 일이였다면 어땠을까요?
이 사건이 남긴 문제는 세 가지입니다
권한, 속도, 기록입니다. 부여한 권한이 실행 시점에 지켜지지 않았고, 사람이 손으로 지우는 속도가 에이전트가 만들어내는 속도를 따라가지 못했습니다. 그리고 무슨 일이 벌어지고 있는지 한자리에서 보여주는 화면이 없어서 한 달을 그대로 흘려보냈습니다.
사람에게 한달은 약 20일 출근, 200시간도 안되는 업무 시간을 의미하겠지만 AI에게는 다릅니다. 말 그대로 한달 30일 720시간이라는 점입니다.
그럼 기업 환경에서 어떨까요? 사실 더 조용하고 은밀하게 나타납니다. 오픈AI 사례는 외부 사이트에서 벌어져 결국 남이 발견해 줬지만, 사내 워크플로는 대부분 내부에서만 돌기 때문에 알려줄 사람이 없기 때문입니다. AI거버넌스가 중요해진 올해부터 Dify 도입 상담에서 어떤 모델을 붙일지보다 이 세 가지를 먼저 묻게 되는 이유이기도 합니다.
어쩌면 도로에 차와 운전자가 많이 생겨나기 전에 도로교통법 부터 잘 만들었어야 하는데 이제와서 부랴부랴 법 개정을 하고 있는게 아닌가 싶기도 합니다.
권한 경계는 실행 시점에도 살아 있어야 합니다
설정 화면에 적힌 권한과 실제로 닿는 범위가 같아야 한다는 뜻입니다. 사건에서 읽기 전용이라는 설정은 분명히 있었지만 실행 중에는 그 선이 지켜지지 않았고, 기업 워크플로에서도 같은 어긋남이 생깁니다. 슬랙 웹훅이나 모델 API 키, 내부 OAuth 토큰이 워크스페이스 전체에 공유되어 있으면 한 사람이 만든 에이전트가 다른 사람의 키를 타고 예상 밖의 시스템에 닿게 되니까요.
Dify는 7월 v1.15.0에서 자격증명을 사용자 단위로 잠글 수 있게 했습니다. 보안 경계나 비용이 걸린 값을 워크스페이스 전체가 공유하는 대신 소유자에게 묶어 두는 방식이고, 클라우드와 커뮤니티, 엔터프라이즈에 모두 들어갔습니다. 계정 단위까지는 커뮤니티 에디션으로도 쪼갤 수 있다는 이야기입니다.
한편 조직 단위로 넘어가면 엔터프라이즈가 필요해집니다. 커뮤니티 에디션은 워크스페이스를 하나만 쓸 수 있어서 부서나 법인, 고객 프로젝트별로 자원을 완전히 갈라놓는 구성이 나오지 않고, 여러 워크스페이스로 분리하는 기능은 엔터프라이즈에서만 제공됩니다. SSO와 역할 관리도 여기에 붙어 있어서 사람이 늘어날수록 권한을 계정마다 손으로 챙기는 대신 조직 체계 그대로 가져올 수 있습니다. 저희가 올해 초에 두 에디션의 차이를 표로 정리해 둔 적이 있는데, 그 표의 절반 정도가 결국 권한을 어느 단위까지 나눌 수 있느냐는 한 가지 질문으로 시작되었습니다.
사람이 끼어들 자리는 미리 만들어 둬야 합니다
관리자가 하루 100개를 지우는 동안 400개가 생긴 장면이 이 문제를 그대로 보여줍니다. 에이전트가 움직이기 시작한 뒤에 사람이 쫓아가는 구조로는 속도 차이를 메울 수 없습니다. 사람이 확인하기 전까지 흐름 자체가 멈춰 서도록 미리 설계해 두는 편이 현실적이고, 그렇게 해야 승인이 형식으로만 남지 않습니다.
Dify에는 사람 입력(Human Input) 노드가 있습니다. 워크플로 중간에 실행을 세우고 지정한 담당자에게 양식을 보내는데, 담당자는 내용을 보고 승인하거나 피드백을 달아 다시 생성시키거나 다른 사람에게 넘길 수 있고 아무도 응답하지 않으면 정해진 기간 뒤에 타임아웃 경로로 빠집니다. 7월 릴리스에서 드롭다운과 파일 업로드를 지원하게 되면서 승인과 반려, 상위 보고를 자유 입력이 아닌 선택지로 만들 수 있게 됐습니다.
이 노드를 어디에 놓느냐가 실제로는 더 중요합니다. 저희가 워크플로를 함께 설계할 때 외부로 나가는 쓰기 동작 앞에는 되도록 승인 지점을 두시라고 권하는데, 사건에서 문제가 커진 출발점도 결국 외부 사이트에 쓰기가 열린 순간이었기 때문입니다. 읽기까지는 열어두더라도 쓰기는 사람을 한 번 거치게 하는 편이 나중에 원인을 찾을 때도 훨씬 수월합니다.
기록이 없으면 사고가 났는지도 모르는 사고가 납니다
사고를 막는 일과 사고를 알아보는 일은 서로 다른 문제입니다. 위키 관리자 쪽은 대단한 감시 체계를 갖춰서 이상을 발견한 것이 아니라 쓰던 소프트웨어가 편집 기록을 남겨줬을 뿐이고, 오픈AI는 감시할 뜻이 없어서 놓쳤다기보다 볼 화면이 없어서 놓쳤습니다. 뒤쪽이 없으면 앞쪽이 작동했는지조차 확인할 방법이 없습니다.
기업 워크플로로 생각해보면 정확한 차이를 알 수 있습니다. 사내 에이전트가 잘못된 문서를 하나 고쳤다고 할 때, 실행 기록이 남아 있으면 원인을 찾아 고칠 수 있는 사고가 됩니다. 반면 기록이 없으면 몇 달 뒤 누군가 이상한 문서를 발견하더라도 원인을 끝내 모르는 상태로 끝나고, 같은 일이 또 일어나도 알아채지 못합니다.
Dify는 8월 27일 New Agent 발표에서 이 부분을 세 갈래로 정리했습니다. 개별 실행마다 로그와 트레이싱이 남고 그 실행이 어느 창구에서 시작됐는지도 함께 기록되며, 워크플로 안에서는 노드 사이에 오간 데이터를 열어볼 수 있고, 그 위에서 사용량과 품질과 비용 추이를 버전별로 비교합니다. 사용처(Access Points) 화면은 그 에이전트가 어디에서 열려 있고 어떤 워크플로가 가져다 쓰는지 보여주기 때문에 여러 곳이 함께 쓰는 설정을 건드리기 전에 영향 범위를 먼저 확인할 수 있습니다.
다만 실행 기록을 월 단위로 묶어 내려받는 아카이브는 커뮤니티 에디션에 포함되지 않습니다. 감사 로그 역시 엔터프라이즈에 들어가는 항목입니다. 몇 달 전 실행까지 되짚어야 하는 조직이라면 여기서 선택지가 갈릴텐데, 규정이나 내부 감사 요건이 있는 곳일수록 반드시 필요한 포인트입니다.
그래서 엔터프라이즈가 답이냐고 물으신다면
기업 상황에 따라 다릅니다. 한두 명이 아이디어를 검증하는 중이라면 커뮤니티 에디션이 맞고, 워크플로 에디터와 에이전트 런타임이 전부 열려 있고 도커 한 번이면 뜨는 데다 비용이 들지 않으니 만들어볼 수 있는지 확인하는 목적에는 이만한 게 없습니다.
경계는 사람 수가 아니라 닿는 범위에서 그어집니다. 에이전트가 사내 시스템이나 고객 데이터에 닿기 시작했는지, 만든 사람 말고 다른 팀이 가져다 쓰는지, 문제가 생겼을 때 몇 달 전 실행까지 되짚어야 하는지를 보시면 됩니다. 셋 중 하나라도 해당한다면 권한을 계정 단위로 잠그는 것만으로는 부족해지는 지점에 들어선 것이고, 그때부터는 라이선스 비용보다 그 경계를 설계하고 유지할 사람이 있느냐가 더 큰 변수가 될 수 있습니다.
기능을 켜 두는 것과 그 기능이 실제로 작동하게 만드는 일은 다릅니다. 저희가 설치와 업그레이드, 마이그레이션, Dify 실무 교육까지 함께 맡는 이유도 여기에 있는데, 권한을 쪼개는 기능이 붙는 순간 누가 그 선을 긋고 누가 유지할지가 곧바로 따라오기 때문입니다. 오픈AI조차 자기 에이전트가 한 달 동안 어디에 무엇을 쓰고 있었는지 몰랐다는 사실은, 도구를 가졌느냐보다 그 도구를 들여다보는 사람이 있느냐가 결과를 가른다는 이야기이니까요.
오픈네트웍시스템 ㅣ 권태규