AIsle
AI TREND

[Hacker News 요약] LLM 에이전트의 보안 및 확장성을 위한 아키텍처 선택: 샌드박스 내부 vs. 외부

14
NE

Nedai

운영자

설명

대규모 언어 모델(LLM) 기반 에이전트의 발전은 끊임없이 보안과 확장성의 새로운 과제를 제시하고 있습니다. 에이전트의 핵심인 '하네스(harness)'가 어디에 위치해야 하는지에 대한 근본적인 질문은 에이전트의 보안 속성, 실패 모드, 그리고 궁극적으로 수행할 수 있는 작업의 범위에 지대한 영향을 미칩니다. 특히 단일 사용자 환경을 넘어 다중 사용자 환경으로 확장될 때 이러한 아키텍처 선택의 중요성은 더욱 부각됩니다. ### 배경 설명 LLM 에이전트는 프롬프트를 보내고, 응답을 받아, 필요한 도구를 실행하고, 그 결과를 다시 모델에게 피드백하는 반복적인 루프를 통해 작동합니다. 이 루프를 '하네스'라고 부르며, 모든 프로덕션 에이전트의 필수 구성 요소입니다. 하네스의 위치는 크게 두 가지로 나뉩니다. 첫째, '샌드박스 내부' 아키텍처는 하네스가 에이전트가 작업하는 코드와 동일한 컨테이너 내에서 실행되는 방식입니다. 이는 단순한 실행 모델과 기존 하네스의 재사용성을 제공하지만, 보안 측면에서는 취약점을 내포할 수 있습니다. 둘째, '샌드박스 외부' 아키텍처는 하네스가 백엔드에서 실행되고, 도구 실행이 필요할 때 API를 통해 샌드박스에 요청하는 방식입니다. 이 방식은 보안을 강화하고 리소스 효율성을 높일 수 있지만, 구현의 복잡성이 증가합니다. 특히 여러 사용자가 동일한 에이전트를 공유하는 환경에서는 샌드박스 외부 아키텍처가 필수적인 고려 사항이 됩니다. 이는 분산 파일 시스템 문제, 상태 관리, 그리고 동시성 제어와 같은 복잡한 문제들을 야기하기 때문입니다. ### 샌드박스 내부 하네스의 장단점 샌드박스 내부 아키텍처는 단일 컨테이너, 단일 프로세스 트리, 단일 파일 시스템이라는 단순한 실행 모델을 제공합니다. 이는 기존의 오프더셸프(off-the-shelf) 하네스를 그대로 재사용할 수 있게 하며, 스킬(skills)이나 메모리(memories)와 같은 에이전트의 내부 상태가 로컬 파일 시스템에 저장되므로 직관적으로 작동합니다. 개인 개발자가 노트북에서 간단한 에이전트를 구축할 때 유용할 수 있습니다. 그러나 이 모델은 에이전트가 샌드박스 내부에 접근할 수 있는 모든 것에 직접 접근할 수 있다는 점에서 보안상의 위험을 안고 있습니다. 만약 에이전트가 악의적인 코드를 실행하거나 민감한 정보에 접근하려 한다면, 샌드박스 내부의 모든 것이 노출될 수 있습니다. 또한, 샌드박스가 중단되면 에이전트 세션 전체가 종료되는 단일 실패 지점(single point of failure)이 될 수 있습니다. ### 샌드박스 외부 하네스의 이점 및 해결 과제 샌드박스 외부 아키텍처는 보안과 확장성 측면에서 상당한 이점을 제공합니다. 에이전트의 하네스가 샌드박스 외부에 존재함으로써, LLM API 키, 사용자 토큰, 데이터베이스 접근 권한과 같은 민감한 자격 증명이 샌드박스 내부에 노출되지 않습니다. 샌드박스는 에이전트가 작업을 수행하는 데 필요한 최소한의 환경만 포함하므로, 탈출(escape)하거나 자격 증명을 유출할 수 있는 경로가 원천적으로 차단됩니다. 또한, 에이전트가 명령을 실행하지 않는 동안에는 샌드박스를 일시 중지하여 리소스를 효율적으로 관리할 수 있습니다. 이는 특히 여러 사용자가 공유하는 환경에서 중요합니다. 그러나 이 아키텍처는 몇 가지 기술적 과제를 동반합니다. 첫째, '지속 가능한 실행(durable execution)' 문제입니다. 에이전트 루프는 몇 시간 동안 실행될 수 있으며, 롤링 배포, 스케일 이벤트, 인스턴스 장애 등에도 불구하고 중단 없이 계속되어야 합니다. 이를 위해 Inngest와 같은 워크플로우 관리 도구를 사용하여 각 단계를 체크포인트하고 재시작 시 이전 상태부터 복구할 수 있도록 합니다. 둘째, '샌드박스 생명주기(sandbox lifecycle)' 관리입니다. 샌드박스는 자주 일시 중지되므로, 필요할 때 빠르게 재개되어야 합니다. 콜드 스타트(cold start)로 인한 지연은 사용자 경험을 저해할 수 있으므로, Blaxel과 같은 솔루션을 사용하여 25ms 이내의 빠른 재개를 보장합니다. 셋째, '파일 시스템' 문제입니다. 에이전트의 스킬, 메모리 등은 파일 시스템에 의존하는 경우가 많습니다. 샌드박스가 일시적이거나 교체될 수 있다면 이러한 상태가 손실될 수 있습니다. 이를 해결하기 위해 파일 시스템 접근을 가상화하여, 특정 경로(예: /skills/, /memory/)로의 접근은 데이터베이스로 라우팅하고, 실제 작업 공간 관련 경로는 샌드박스로 전달하는 방식을 채택합니다. 이를 통해 에이전트는 파일 시스템 인터페이스를 그대로 사용하면서도, 실제 데이터는 중앙 집중식 데이터베이스에 안전하게 저장하고 관리할 수 있습니다. ### 가상화된 파일 시스템 인터페이스의 구현 샌드박스 외부 아키텍처의 핵심적인 해결 과제 중 하나는 에이전트가 파일 시스템과 상호작용하는 방식을 유지하면서도, 실제 데이터는 샌드박스 외부의 영구 저장소에 저장하는 것입니다. 이를 위해 Mendral은 파일 시스템 접근을 가상화하는 계층을 구축했습니다. 에이전트는 `read()`, `write()`, `edit()`과 같은 표준 파일 시스템 도구를 사용하지만, 하네스는 이러한 호출을 가로채 경로를 분석합니다. '/workspace/'와 같은 경로는 샌드박스로 직접 전달되어 기존처럼 작동합니다. 반면, '/skills/'나 '/memory/'와 같은 네임스페이스에 속하는 경로는 데이터베이스로 라우팅됩니다. 예를 들어, 에이전트가 메모리를 업데이트하기 위해 `write('/memory/user_notes.md', '새로운 내용')`을 호출하면, 이 요청은 실제로는 데이터베이스 트랜잭션으로 처리됩니다. 이렇게 하면 여러 사용자가 동시에 메모리를 업데이트하더라도, 데이터베이스 수준에서 충돌을 관리하고 일관성을 유지할 수 있습니다. 에이전트 자체는 이러한 내부 메커니즘을 인지하지 못하며, 마치 로컬 파일 시스템에 접근하는 것처럼 작동합니다. 이러한 가상화는 에이전트가 LLM 학습 시 사용했던 동일한 API 표면을 유지하면서도, 백엔드에서는 데이터베이스의 강력한 일관성 및 관리 기능을 활용할 수 있게 합니다. 이는 별도의 `memory_read()`와 같은 새로운 도구를 추가하는 것보다 모델의 성능 저하를 방지하는 데 유리합니다. 모델은 학습된 `read(path)`와 같은 인터페이스에 더 익숙하기 때문입니다. ### 가치와 인사이트 이 글은 LLM 에이전트 개발에서 보안과 확장성을 동시에 달성하기 위한 실질적인 아키텍처 설계 패턴을 제시합니다. 특히 다중 사용자 환경에서 에이전트의 상태 관리, 리소스 효율성, 그리고 보안을 강화하기 위해 샌드박스 외부 하네스 아키텍처를 채택하고, 이를 구현하기 위한 구체적인 기술적 해결책(지속 가능한 실행, 샌드박스 생명주기 관리, 가상화된 파일 시스템)을 상세히 설명합니다. 이는 에이전트가 파일 시스템과 상호작용하는 방식을 유지하면서도, 민감한 자격 증명을 안전하게 관리하고, 여러 사용자가 동시에 에이전트를 사용할 때 발생하는 데이터 충돌 문제를 해결하는 데 중요한 통찰을 제공합니다. 또한, 모델의 학습된 API 표면을 유지하는 것이 성능에 미치는 긍정적인 영향을 강조하며, 실무 개발자들에게 에이전트 아키텍처 설계 시 고려해야 할 핵심적인 요소들을 명확히 제시합니다. ### 기술·메타 - Inngest (지속 가능한 실행) - Blaxel (샌드박스 생명주기 관리) - Postgres (메모리 및 스킬 저장) - Tree-sitter (Bash 호출 파싱) ### 향후 전망 LLM 에이전트 기술은 빠르게 발전하고 있으며, 새로운 패턴(서브에이전트, 계획, 백그라운드 작업 등)이 지속적으로 등장하고 있습니다. 이러한 새로운 기능들은 종종 로컬 파일 시스템을 가정하기 때문에, Mendral과 같은 시스템은 이러한 변화에 발맞춰 가상화 계층을 지속적으로 업데이트해야 하는 과제를 안고 있습니다. 또한, Claude Code와 같은 외부 시스템의 파일 레이아웃 변경은 자체 시스템의 호환성 유지에 영향을 미칠 수 있습니다. 장기적으로는 현재의 경로 접두사 기반 가상화 방식이 한계에 봉착할 수 있으며, 완전히 새로운 인터페이스 노출이 필요할 수도 있습니다. Bash와 같은 도구를 통한 보안 우회 가능성도 여전히 존재하며, 이를 완벽하게 차단하기 위한 지속적인 노력이 필요합니다. 특히, 여러 세션 간의 메모리 업데이트 시 일관성 문제는 아직 완전히 해결되지 않은 과제로 남아 있으며, '마지막 작성자 승리(last-writer-wins)'와 같은 단순한 정책이 복잡한 시나리오에서 예상치 못한 문제를 야기할 수 있습니다. 따라서 향후에는 에이전트의 동시성 제어 및 데이터 일관성 모델에 대한 더 정교한 접근 방식이 요구될 것입니다. 📝 원문 및 참고 - Source: Hacker News - 토론(HN): [news.ycombinator.com](https://news.ycombinator.com/item?id=47990675) - 원문: [링크 열기](https://www.mendral.com/blog/agent-harness-belongs-outside-sandbox) --- 출처: Hacker News · [원문 링크](https://www.mendral.com/blog/agent-harness-belongs-outside-sandbox)
사이트 방문하기Visit Service
#HackerNews

댓글 0

아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.

AI TREND 글 목록

복도로 이동 →
제목글쓴이조회