Written by Sangwan Kwon
on 

Agentic AI 프로그램과 보안 위협

이 글은 AI의 도움을 받아 작성되었습니다.

1. 들어가며: “AI 모델”과 “에이전트”, 그리고 그 사이의 회색지대

작년까지만 해도 제가 ChatGPT나 Claude를 사용해 온 방식은 챗봇 형식이었습니다. 질문을 던지면 답이 오고, 코드를 붙여 넣으면 리뷰가 돌아옵니다. 결과가 마음에 들지 않으면 프롬프트를 개선하여 다시 받습니다.

요즘은 코드 생성, 리뷰, 테스트, 배포까지 Agent한테 맡깁니다. Claude CLI, Codex를 직접 사용하기도 하고, Hermes Agent와 같은 상위 Agent를 통해 AI Model을 사용하기도 합니다.

Codex와 같은 툴에도 Agent 기능이 내포되어 있지만, 이 글에서는 논의를 위해 프레임을 축소해서 시작하려 합니다.

이 둘의 차이는 다음과 같습니다.

모델이 잘못 추론하면 잘못된 텍스트가 나옵니다. 하지만 에이전트가 잘못 추론하면 잘못된 동작이 실행됩니다.

그리고 우리가 그 동작에 부여한 권한이 클수록, 잘못된 추론의 대가는 기하급수적으로 증가합니다.

NVIDIA의 Jensen Huang은 GTC 2026 키노트에서 “CEO 분들께 묻습니다. 여러분의 OpenClaw 전략은 무엇입니까?”라고 했습니다. 본인 회사 제품도 아닌 개인용 에이전트를 모든 기업이 전략 차원에서 다뤄야 한다고 말한 셈입니다. 이런 시각이 업계 메인스트림에 들어왔다는 점이 중요합니다.

이게 이번 글의 출발점입니다. 이 새 카테고리를, 우리는 어떻게 이해하고 어떻게 다룰 것인가.

2. OpenClaw: 개인 AI 에이전트를 대중화한 첫 번째 흐름

Agentic AI 프로그램의 대표격으로, 먼저 OpenClaw 이야기를 해 보고 싶습니다.

OpenClaw는 오스트리아 개발자 Peter Steinberger(PSPDFKit 창업자)가 2025년 11월에 시작한 주말 프로젝트였습니다. 처음 이름은 Clawdbot, 즉 Claude와 lobster claw(랍스터 집게)를 합친 말장난이었으나, Anthropic 상표팀의 요구로 2026년 1월 OpenClaw로 개명했습니다.

기능은 단순합니다. 어떤 컴퓨터든 영구적인 AI 에이전트로 만들어 주는 게이트웨이입니다.

왜 인기를 끌었을까요? “내 인프라에서 항상 켜져 있는 AI 비서”라는 매력 때문입니다. 출장 중 텔레그램으로 한 줄 메시지만 보내면, 집에 있는 노트북에서 코드를 작성하고 메일을 정리하고 캘린더를 검토합니다.

2026년 4월 기준 GitHub 스타 약 35만, 주간 다운로드 72만을 기록했고, 2026년 2월 14일에는 OpenAI가 Steinberger를 영입하며 OpenClaw는 OpenAI 후원의 독립 재단으로 전환되었습니다.

OpenClaw가 만들어 낸 것은 한 제품이 아니라 개인용 영구 에이전트라는 새 카테고리입니다.

3. Hermes: 왜 지금 핫한가

이 카테고리에 2026년 2월 25일 Nous Research가 Hermes Agent를 던졌습니다. 7주 만에 GitHub 스타 9.5만을 돌파하며 OpenClaw 사용자들의 대규모 마이그레이션 흐름을 만들어 냈습니다.

Nous Research는 Hermes/Nomos/Psyche 모델 패밀리를 만든 곳입니다. 즉, 모델을 만드는 사람들이 직접 만든 에이전트라는 뜻이고, 이 사실 자체가 차별화의 출발점입니다.

핵심 차별점은 세 가지인데, 그중에서도 진짜 혁신은 첫 번째인 자기 개선 루프라고 저는 봅니다. 나머지 둘은 좋은 엔지니어링의 영역이지만, 이 첫 번째는 카테고리의 정의를 다시 쓰는 영역에 가깝습니다.

3.1 자기 개선 루프(Self-Improving Loop)

개인적으로 가장 마음에 드는 기능입니다.

기존 에이전트들이 “메모리”라고 부르던 것이 어떤 종류였는지, 잠깐 정리하고 가는 편이 좋겠습니다.

Hermes가 한 일은 이 세 번째, 즉 절차적 메모리를 일급(first-class) 객체로 끌어올린 것입니다.

어떻게 동작하는가

Hermes가 어려운 문제를 한 번 풀면, 그 풀이 과정 자체가 백그라운드에서 스킬 문서로 정리됩니다. 사람이 회고록을 쓰듯 절차를 추출하고, 일반화 가능한 부분과 구체 케이스를 분리하고, “언제 이 스킬을 쓰면 되는지”의 트리거 조건을 함께 적습니다. 결과물은 평범한 마크다운 파일입니다.

~/.hermes/skills/
├── debug-flaky-pytest-suites/SKILL.md
├── extract-tables-from-pdf-reports/SKILL.md
├── refactor-rust-trait-hierarchies/SKILL.md
└── triage-github-security-advisories/SKILL.md

다음에 비슷한 문제가 들어오면 Hermes는 먼저 자기 스킬 폴더를 검색합니다. 매칭되는 스킬이 있으면 그 절차를 컨텍스트에 가져와 따라갑니다. 없으면 처음부터 풀고, 풀고 나서 또 새 스킬을 만듭니다.

왜 이게 카테고리를 바꾸는가

세 가지 이유가 있습니다.

첫째, 복리 효과(compounding)입니다. 보통의 에이전트는 세션 N과 세션 N+1의 능력이 같습니다. Hermes는 다릅니다. N+1이 N보다 항상 더 강합니다. 한 달을 쓰면 한 달치 절차를 쌓고, 세 달을 쓰면 그 사람의 워크플로우 전체가 절차로 화석화됩니다. 처음 켰을 때의 Hermes와 6개월 뒤의 Hermes는 다른 도구입니다.

둘째, 사람이 읽을 수 있는 메모리입니다. 벡터 임베딩은 디버깅이 안 됩니다. “왜 에이전트가 이런 행동을 했지?”라고 물었을 때, 임베딩을 까서 답할 수 있는 사람은 없습니다. Hermes의 스킬은 마크다운입니다. 잘못 학습한 절차가 있으면 사람이 직접 그 파일을 열어서 고치면 됩니다. 보안 관점에서도 이게 큰 의미를 갖는데, 잠시 뒤에 다시 다루겠습니다.

셋째, 정적 마켓플레이스와의 대비입니다. OpenClaw도 스킬을 갖고 있습니다. ClawHub라는 마켓플레이스에서 다운받죠. 하지만 그건 다른 사람이 만들어 둔 정적 스킬입니다. 내 컨텍스트와 안 맞으면 안 맞는 대로 써야 하고, 악성 스킬 341개 적발 같은 공급망 문제도 거기서 옵니다. Hermes의 스킬은 자기가 자기 작업에서 만들어 낸 것입니다. 다운로드받지 않고, 자라납니다.

스킬 형식 자체는 agentskills.io라는 오픈 표준에 호환되어 다른 에이전트와 교환 가능합니다. 즉 내 에이전트가 만든 절차를 내가 신뢰하는 사람의 에이전트와 공유할 수 있습니다. 마켓플레이스가 아닌 P2P 형태의 스킬 전파입니다.

보안 관점에서의 양면성

다만, 시스템 보안 엔지니어로서 한 가지를 짚지 않을 수 없습니다. 자기 개선 루프는 동시에 새로운 공격 표면입니다.

스킬은 자연어로 쓰인 절차이고, 다음번에 에이전트가 그걸 믿고 따라갑니다. 그렇다면 공격자가 한 번 인젝션을 성공시켜서 악성 스킬을 만들게 만들면, 그 악성 절차는 영구히 내 에이전트의 일부가 됩니다. 한 번의 prompt injection이 지속적인 백도어로 화석화되는 것이죠. 임베딩 기반 long-term memory에서는 이 위협이 약했습니다. 인덱스가 노이즈 많고 검색이 부정확했기 때문입니다. 절차적 메모리는 정확하고 재현성이 높기 때문에 오히려 무기로 쓰기 좋습니다.

이건 Hermes의 결함이라기보다, 절차적 메모리라는 새 카테고리가 가져오는 새 위협 모델에 가깝습니다. 그리고 이 위협 모델을 우리가 어떻게 다룰지는 마지막 섹션의 오픈 퀘스천으로 다시 돌아옵니다.

3.2 영속 메모리(Persistent Memory)

세션 간 컨텍스트가 유지됩니다. FTS5 풀텍스트 검색과 LLM 요약을 결합해 과거 대화에서 필요한 맥락을 가져옵니다. 매번 “이 프로젝트는 ~이고, 내가 이걸 시도했는데…” 하고 다시 설명할 필요가 없어집니다.

3.3 실행 위치와 대화 위치의 분리

가장 중요한 아키텍처 차이입니다. Hermes는 6개의 백엔드를 지원합니다. local, Docker, SSH, Daytona, Singularity, Modal입니다. Modal 같은 서버리스에 띄워 두면 유휴 시 거의 무료이고, 호출 시에만 깨어납니다. 그 위에서 텔레그램으로 대화합니다.

Claude Code, Cursor, Aider 같은 기존 코딩 에이전트는 에이전트와 사람이 같은 터미널을 공유한다고 가정합니다. Hermes는 그 가정을 깹니다.

이게 왜 중요할까요? 예를 들어 “이 레포지토리의 빌드를 매시간 돌리고, 실패가 늘어나기 시작하면 슬랙으로 알려 줘” 같은, 사람의 인내심으로는 못 하는 종류의 작업이 가능해집니다. 지켜보는 프로세스가 내 노트북일 필요가 없어지기 때문입니다.

재미있는 디테일이 하나 있습니다. Hermes 코어에는 hermes claw migrate 명령이 빌트인되어 있습니다. OpenClaw의 설정, 스킬, 메모리를 이주시켜 주는 도구가 경쟁 제품 안에 통합된 셈입니다. 대안을 만들었다가 아니라 대체를 노린다는 신호로 읽힙니다.

4. 그런데: 이 모든 것의 본질적 문제

여기까지만 읽으면 “Hermes 좋네, 갈아타야겠네”가 결론처럼 보이지만, 카테고리 자체에 깔린 함정을 봐야 합니다.

보안 커뮤니티에서 “lethal trifecta”라고 부르는 것이 있습니다. 흥미롭게도 OpenClaw 창시자 Steinberger 본인이 자신의 키노트에서 이 용어를 직접 언급합니다. “OpenClaw에 국한된 위험이 아니라, 에이전트 시스템 전반의 본질적 위험”이라고 강조하면서요.

세 가지 요소가 한 프로세스 안에 모인 상태를 말합니다.

OpenClaw도, Hermes도, Claude Code도, NemoClaw도 모두 이 셋을 가지려고 설계되었습니다. 그 셋이 모이는 것 자체가 가치이기 때문입니다. 그러나 동시에 그 셋이 모이는 순간 사고는 만약이 아니라 언제의 문제가 됩니다.

생산성을 위해 권한을 풀면 사고가 납니다. 사고를 막으려고 권한을 막으면 못 씁니다. 이게 에이전트의 구조적 모순입니다.

5. 사례 1: OpenClaw의 보안 사태, 그리고 “잘 대응한 사례”로서의 가치

이 모순이 실제로 어떻게 터졌는지를 보여 주는 사례가 있습니다.

5.1 무슨 일이 있었나

2026년 2월 1일, depthfirst의 보안 연구원 Mav Levin이 CVE-2026-25253을 공개합니다. 1-click RCE, CVSS 8.8.

공격 시나리오는 단순합니다. 공격자가 만든 웹페이지를 OpenClaw 사용자가 브라우저로 방문하기만 해도, 브라우저가 로컬의 OpenClaw WebSocket 게이트웨이를 향해 cross-site WebSocket hijacking을 일으킵니다. 인증 토큰이 새고, 토큰을 받은 공격자가 게이트웨이에 연결해 sandbox 옵션을 끄고, Docker를 빠져나와, 호스트에 임의 코드를 실행합니다. 모두 밀리초 단위로 끝납니다.

가장 인상적인 부분은 localhost 바인드 인스턴스조차 취약하다는 점입니다. 피해자의 브라우저가 outbound 연결을 스스로 시작하기 때문에, “외부에 노출 안 했으니 안전하다”는 우리의 통상적인 가정이 그대로 깨집니다.

벨기에 사이버보안센터(CCB)가 같은 주에 긴급 권고를 발표했습니다. “최우선 순위로 패치하라.” 미국 NIST와 중국 MIIT도 잇따라 정부·국유기업의 OpenClaw 배포를 제한하라는 권고를 내놓았습니다.

규모는 충격적이었습니다.

5.2 그런데: 대응 자체는 흥미롭습니다

여기서부터가 이 사례의 진짜 흥미로운 부분입니다. 공개 이전에 이미 패치되어 있었습니다.

날짜 사건
1월 29일 OpenClaw v2026.1.29 릴리스. CVE-2026-25253 패치 포함
2월 1일 depthfirst가 advisory 공개
2월 2일 벨기에 CCB 긴급 권고
2월 2일 OpenClaw가 같은 날 추가 command injection 두 건을 자체 advisory로 공개

Steinberger가 State of the Claw 키노트(AI Engineer Summit, 2026.4)에서 직접 이 운영 방식을 설명합니다.

“5개월간 보안 advisory를 1,142개 받았습니다. 하루 평균 16.6건, Linux 커널의 두 배 속도입니다. 사실상 보안 advisory에 의해 DDoS 당하고 있는 셈이에요.”

여기서 advisory의 대부분이 AI 보안 스캐너, 즉 다른 에이전트들이 자동 생성한 것이라는 점이 중요합니다. 이 부분은 7장에서 다시 다룹니다.

대응의 핵심 패턴은 다음과 같습니다.

저는 이 사례를 두 갈래로 읽습니다.

아키텍처적 한계는 패치로 풀리지 않습니다. “personal assistant”로 정의된 위협 모델 자체가 다중 신뢰 경계를 가정하지 않으므로, 다음 변종 취약점은 또 나옵니다.

그러나 공개적이고 빠른 대응은 신뢰의 또 다른 축입니다. 공개 이전의 사전 패치, 같은 날 self-disclosure, 공개 advisory 트래커, 중립 재단으로의 전환. 이만큼 사후 처리의 투명성과 거버넌스가 갖춰진 오픈소스 에이전트는 현재 없습니다. 이 점에서 OpenClaw는 문제를 일으킨 사례인 동시에 대응을 잘한 사례입니다.

6. 사례 2: NVIDIA NemoClaw, 그리고 30분 만에 뚫린 사연

OpenClaw 보안 사태가 시장에 던진 메시지는 명확했습니다. “런타임 레이어 자체를 다시 설계해야 한다.” 그 빈자리에 NVIDIA가 들어왔습니다.

6.1 발표된 보안 스택

2026년 3월 16일 GTC 2026에서 Jensen Huang이 NemoClaw + OpenShell 스택을 공개했습니다. 캐치프레이즈는 “OpenClaw를 더 안전하게 돌리자”입니다. 대체가 아니라 감싸는 전략이었습니다.

발표된 보안 스택을 간단히 정리하면 다음과 같습니다.

OpenClaw 단독 운영보다 분명 안전합니다. 그 자체로 옳은 설계입니다.

6.2 발표 직전 주말, 30분 만에 일어난 일

그런데 발표 직전 주말, 가장 흥미로운 일이 벌어졌습니다.

NVIDIA는 키노트 전날인 일요일에 Steinberger를 초청해 NemoClaw를 사전 검증해 달라고 요청했습니다. 월요일에 Jensen Huang이 무대에 오를 예정이었습니다.

Steinberger는 공개되지 않은 OpenAI 내부 Codex Security 모델을 이용해 NemoClaw 샌드박스를 공격했습니다. 결과는 30분 만에 5개의 sandbox escape였습니다.

Steinberger가 그 후 키노트에서 한 평가가 이 상황을 잘 요약합니다.

“내부 모델은 외부에 공개된 모델보다 사이버 보안 면에서 훨씬 똑똑합니다. 정확히 그 이유로 위험하기 때문이죠.”

GitHub Issue 트래커는 이 사고의 주변부를 보여 줍니다.

여기에 NVIDIA 자체 아키텍처 문서의 솔직한 인정이 더해집니다. “Intent verifier는 제안된 액션을 평가할 뿐, 외부 도구가 돌려준 데이터의 의미는 평가하지 않습니다. 신뢰된 데이터 소스를 통한 간접 프롬프트 인젝션은 여전히 갭으로 남아 있습니다.”

요약하면, 5계층 방어를 정성껏 쌓았어도 공격자 측 에이전트가 30분 만에 우회를 찾아내는 환경에 살고 있는 셈입니다.

7. 마무리

7.1 생산성의 시작점이 다릅니다

Agent가 만들어 내는 생산성은 직관적으로 기하급수적입니다. Cursor나 Claude Code가 잘 만들어진 코딩 도구에 AI 모델을 붙여 만든 것이라면, OpenClaw, Hermes, NemoClaw는 시작점이 다릅니다. IDE가 없는 빈 컴퓨터에서, 텔레그램 한 줄 메시지가 들어오면 그 의미를 분석해 셸, 브라우저, 시뮬레이터, 외부 API를 오케스트레이션하고, 결과를 다시 텔레그램으로 보내는 시스템입니다.

이게 “코딩 도구의 자동화”와 본질이 다른 이유는, 이 시스템 안에서는 다음에 무엇을 할지조차 모델이 정한다는 점입니다. 생산성의 천장이 다릅니다.

7.2 그래서 보안 위협도 다릅니다

문제는 그 천장에 비례해 위협 모델도 다르다는 것입니다. 5장과 6장에서 이미 봤습니다. 한 회사가 정성껏 5계층 샌드박스를 쌓아도, “공격하는 쪽도 에이전트”인 시대에는 30분이면 우회됩니다.

이건 사내 보안 엔지니어의 일상적 딜레마와도 정확히 연결됩니다. 우리가 정성껏 권한을 deny-by-default로 잠그고 audit 로그를 까는 동안, 옆자리에서는 권한을 풀어 둔 동료가 양과 질 모두에서 우리보다 좋은 결과물을 내고 있을 가능성이 큽니다. “안전한 길로 가면 뒤처진다”는 압력은 추상적인 우려가 아니라 실제로 발생하는 일입니다.

7.3 남는 의문들

먼저, 속도의 문제가 있습니다.

OpenClaw 사태에서 NemoClaw 샌드박스의 5개 escape를 찾아낸 것도 에이전트(Codex Security)였습니다. 에이전트가 만든 보안 문제를 에이전트가 해결하는 시대. 이 자기참조적 루프는, 잘만 돌면 사람의 검토 속도를 무용지물로 만들 정도로 빠른 혁신을 가져올 수도 있습니다.

게다가 3장에서 본 Hermes의 자기 개선 루프를 떠올려 보면, 이 그림은 한층 더 강해집니다. 에이전트가 자기 자신의 절차를 매일 갱신하고, 그 절차가 다시 다음 작업의 출발점이 되며, 동시에 공격하는 쪽 에이전트도 똑같은 자기 개선을 합니다. 방어 절차와 공격 절차가 둘 다 복리로 자라는 환경입니다. 사람이 그 속도를 신뢰하고 따라갈 수 있는지, 따라가지 못한다면 어떤 거버넌스 구조가 그 속도를 대신 검증해 줄 수 있는지 아직은 답을 갖고 있지 않습니다.

다른 하나는 자산의 문제입니다.

우후죽순 등장하는 에이전트 회사들 위에서 우리의 자산은 그 위에서 충분히 보호되고 있는가. 더 나아가, 에이전트 자체를 신뢰루트의 일부로 끌어들일 수 있는가. 이건 “에이전트를 어떻게 막을 것인가”와는 다른 질문이고, 어쩌면 더 흥미로운 질문이라고 저는 생각합니다.

OpenClaw가 무너졌다가 다시 일어선 것도, NemoClaw가 30분 만에 뚫린 것도, Hermes가 자기 자신을 절차로 화석화하면서 자라나는 것도 모두 같은 흐름의 표면입니다. 에이전트라는 새 카테고리에 대한 위협 모델이 아직 정착하지 않았다는 것.

그 정착 작업은, Hermes의 자기 개선 루프가 시사하는 한 가지, 즉 절차가 마크다운 파일로 떨어진다는 것, 사람이 읽고 감사하고 수정할 수 있다는 것이 우리에게는 작은 출발점이 될 수 있습니다. 임베딩 안에 묻힌 메모리가 아니라 감사 가능한 절차라면, 우리가 이미 다뤄 온 측정, 증명, 정책의 사고 도구가 그대로 적용 가능하기 때문입니다.

읽어 주셔서 감사합니다.

참고 자료