TL;DR
보안 우려는 당연합니다. 하지만 AI 도구를 아예 안 쓰는 것보다, 주의깊게 쓰면서 보안 역량까지 함께 키우는 게 개발자로서 더 나은 선택입니다.
위험이 보이지 않는 이유
개인정보 유출 사고가 끊이질 않습니다. 2025년만 해도 SKT 유심 정보 2,300만 건 유출, 쿠팡 고객 정보 3,370만 건 유출, 롯데카드에서는 카드번호와 CVC까지 포함된 민감한 금융 정보가 털렸습니다. 한번 유출된 정보라 해도 다크웹에서 재판매되며 끊임없이 유통되기 때문에, 개인정보는 지속적으로 관리해야 하는 대상이죠.
그래서인지 요즘 OpenClaw 같은 AI 에이전트 도구 얘기가 나오면 "보안은 괜찮은 건가요?"라는 질문이 거의 빠지지 않더군요. 충분히 이해되는 우려입니다. 하지만 보안이 걱정돼서 이런 도구를 아예 안 쓰는 분들이 꽤 있다는 건 좀 아쉬운 부분이긴 합니다.
그래서 AI 도구, 쓸까 말까
ChatGPT 초기에도 비슷했던 상황
OpenClaw를 예로 들긴 했지만, 이런 반응이 처음은 아닙니다. ChatGPT가 처음 나왔을 때도 분위기가 비슷했습니다. 2023년 삼성전자 반도체(DS) 부서에서 ChatGPT 사용을 허용한 지 20일도 안 돼서 소스코드 유출 2건, 회의 내용 유출 1건이 터졌습니다. 이후 삼성전자는 생성형 AI 사용을 전면 금지했고, 많은 기업이 비슷한 조치를 취했습니다. 개인적으로도 보안을 이유로 안 쓰겠다는 분들이 꽤 있었죠.
지금은 어떻습니까. 대부분의 기업이 가이드라인을 만들어 적극 활용하고 있고, 오히려 안 쓰는 쪽이 경쟁에서 뒤처지는 상황이 됐습니다.
개발자 앞에 놓인 두 가지 선택지
개발자 입장에서 보면 결국 두 가지입니다.
A. 주의깊게 사용한다 → 경험과 인사이트 축적 + 생산성 향상
B. 아예 안 쓴다 → 보안 리스크 원천 차단, 대신 성장 기회도 차단
장점 2개 vs 단점 2개로 볼 수 있는데, 솔직히 억지스러운 비교이긴 합니다. 반대로 뒤집어도 논리가 성립하니까요. 결국은 마음가짐의 문제라고 생각합니다.
보안 고민이 곧 성장의 기회
AI 도구를 직접 운영하다 보면 자연스럽게 보안에 대한 질문을 하게 됩니다. 네트워크 쪽이라면 불필요하게 열려 있는 포트는 없는지, IAM 권한이 최소 권한 원칙에 맞게 설정되어 있는지 점검하게 되고, AI 쪽이라면 프롬프트 인젝션 공격에 취약한 부분은 없는지, .env 같은 민감한 파일에 AI가 접근 가능한 상태는 아닌지 확인하게 됩니다.
이런 고민을 하는 과정 자체가 보안 역량을 키워줍니다. 회사 프로젝트에서 보안 실무를 경험하고 싶어도, 인프라팀이 아닌 이상 그런 기회가 주어지지 않는 경우가 대부분이죠. 개인 프로젝트에서 AI 도구를 직접 운영하면서 보안을 고민해보는 건, 그 기회를 스스로 만드는 것과 같습니다.
더 나아가 이렇게 쌓아둔 지식은 실제 회사 서비스 운영이나 외부 컨설팅에서 그대로 활용할 수 있습니다. 반대로 이런 경험 없이 실무에 투입되면, 어디가 뚫릴 수 있는지도 모른 채 알려지지 않은 위험을 안고 일하는 셈입니다.
관심은 뜨거운데, 실제 사용은 미미함
최근 한 OpenClaw 관련 유튜브 영상의 댓글란을 보면 한국 개발자들의 보안 우려 댓글이 상당히 많았습니다. "보안이 걱정된다", "회사 데이터가 유출되면 어쩌나" 같은 반응이죠. 관심은 분명히 높은데, 실제 한국에서의 사용량은 글로벌 대비 거의 미미한 수준이라는 이야기도 있더군요.
물론 OpenClaw의 보안 문제가 실제로 존재하는 건 맞습니다. ZeroLeaks의 자동화 레드팀 테스트에서 보안 점수 100점 만점에 2점, 프롬프트 인젝션 성공률 91%, 프롬프트 추출률 84%를 기록했습니다. Shodan 스캔으로 인증 없이 노출된 인스턴스도 수백 개가 발견됐죠. Andrej Karpathy는 Moltbook을 보고 "a complete mess of a computer security nightmare at scale"이라고 경고했고, 이후에는 자기 컴퓨터에서 직접 돌리지 말라고까지 했습니다. 구글 클라우드 보안 엔지니어링 VP Heather Adkins도 "Don't run Clawdbot"이라고 못 박았죠.
수치만 보면 "그걸 왜 쓰냐"는 반응이 당연합니다. 그런데 저는 이 도구를 쓰면서 오히려 보안에 대해 더 많이 공부하게 됐습니다. 이런 구조를 가진 서비스는 보안을 어떻게 다뤄야 하는지, 어떤 설정이 위험한지, 어디를 막아야 하는지를 직접 고민하게 되거든요. 전용 노트북에 로컬로 설치하면서 포트 관리, 샌드박싱, 권한 최소화 같은 보안 실무를 자연스럽게 익히게 됐습니다.
위험하다고 안 쓰는 게 아니라, 위험한 구조를 이해하면서 쓰는 거죠.
바로 어제, Moltbook이 털렸음
이 글을 쓰는 시점에 딱 맞는 사례가 하나 터졌습니다. OpenClaw 에이전트 전용 소셜 네트워크인 Moltbook이 해킹당한 겁니다. 보안 기업 Wiz가 분석한 결과, Supabase 데이터베이스의 Row Level Security(RLS) 설정이 빠져 있어서 API 키 150만 개, 이메일 주소 35,000개, 에이전트 간 비공개 메시지까지 전부 노출됐습니다. 인증 없이 누구나 전체 DB를 읽고 쓸 수 있는 상태였죠.
더 충격적인 건 Moltbook 창업자의 말입니다. "코드를 한 줄도 직접 쓰지 않았다. AI가 다 만들었다." 이른바 바이브 코딩(vibe coding)으로 만든 서비스가 보안 설정 하나를 빠뜨려서 전체 플랫폼이 뚫린 겁니다.
이건 OpenClaw 생태계만의 문제가 아닙니다. AI로 빠르게 만들수록, 보안은 오롯이 자기가 책임져야 하는 영역이라는 걸 보여주는 사례입니다. AI가 코드를 대신 짜줘도 RLS 설정이 제대로 되어 있는지, API 키가 클라이언트 코드에 노출되어 있지는 않은지 확인하는 건 결국 사람의 몫이죠.
쓰지 않으면 안전하지만, 배울 기회도 사라짐
보안을 무시하자는 이야기가 아닙니다. 오히려 반대입니다. AI 시대에 보안을 어떻게 더 잘할 수 있는지 고민하고, 관련 스킬을 향상시킬 수 있는 좋은 기회로 삼자는 이야기입니다.
쓰지 않으면 안전하지만, 배울 기회도 함께 사라집니다.