AI 에이전트는 어디까지 맡길 수 있을까? 실행 공간·권한·비밀값·상태를 나누는 법

읽는 시간 약 8분

한 줄 결론: AI 에이전트의 안전성은 모델이 아니라, 실행 공간·권한·비밀값·작업 상태를 서로 섞지 않는 운영 설계에서 시작됩니다.

AI 에이전트가 파일을 읽고, 명령을 실행하고, 며칠짜리 작업을 이어서 처리하기 시작하면 질문도 달라집니다. “이 모델이 코드를 잘 짜는가?”보다 먼저 확인할 일은 어디에서 실행되는지, 무엇을 읽을 수 있는지, 작업을 다시 시작할 때 무엇이 남는지입니다.

OpenAI가 Agents SDK의 다음 단계를 소개하며 강조한 native sandbox, workspace, snapshot 같은 개념은 이 질문을 현실적인 설계 문제로 바꿉니다. 이 글은 특정 SDK 사용법을 나열하기보다, 장기 실행 에이전트를 운영할 때 분리해야 할 네 가지 경계를 정리합니다.

핵심 요약

실행 공간은 에이전트가 작업하는 파일과 명령의 범위를 제한합니다.
권한은 “할 수 있는 일”을 작업 단위로 좁혀야 합니다.
비밀값은 프롬프트나 작업 폴더에 넣지 않고, 필요한 순간에만 전달해야 합니다.
작업 상태는 재시작을 위한 기록이지, 모든 민감 정보를 담는 저장소가 아닙니다.

격리된 실행 공간과 제한된 도구 권한을 가진 AI 에이전트의 개념도 — 에이전트가 일을 많이 할수록 실행 환경의 경계를 먼저 정해야 합니다.

샌드박스는 ‘안전한 상자’가 아니라 작업 계약입니다

샌드박스라는 말을 들으면 외부 접근이 완전히 차단된 공간을 떠올리기 쉽습니다. 하지만 실제 운영에서는 그보다 구체적인 질문이 필요합니다. 이 작업은 어느 디렉터리를 읽어도 되는가? 네트워크 연결이 필요한가? 명령 실행은 어떤 도구에만 허용할 것인가? 완료된 뒤 결과물은 어디로 옮길 것인가?

OpenAI의 Agents SDK 관련 안내는 에이전트가 파일·명령·코드 편집을 다루는 환경에서 실행 환경과 하네스를 분리하고, 작업 상태를 snapshot으로 다룰 수 있는 방향을 설명합니다. 여기서 하네스는 모델에게 일을 시키고 결과를 받아 다음 단계를 결정하는 제어 계층입니다. 반면 실행 환경은 실제 파일과 명령이 움직이는 곳입니다.

둘을 한곳에 섞어 두면 작은 자동화도 위험해집니다. 예를 들어 콘텐츠 초안을 만드는 에이전트가 같은 환경에서 배포 키와 운영 로그까지 읽을 수 있다면, 초안 작성에 필요 없는 권한이 이미 열려 있는 셈입니다.

장기 실행 에이전트에서 나눠야 할 4가지 경계

실행 공간, 권한, 비밀값, 작업 상태를 네 개의 분리된 영역으로 보여주는 운영 프레임워크 — 네 경계는 한 번에 완벽하게 만들기보다, 작업별로 하나씩 좁혀 가는 것이 좋습니다.

1. 실행 공간: 파일과 명령이 움직이는 범위

작업 폴더는 가능한 한 일회성으로 만드세요. 입력 파일, 중간 결과, 최종 산출물을 구분하고 작업이 끝난 뒤 무엇을 보존할지 정합니다. 운영 서버의 홈 디렉터리 전체를 작업 공간으로 쓰는 방식은 편해 보여도, 에이전트가 예상 밖 파일을 발견할 가능성을 키웁니다.

2. 권한: 역할이 아니라 작업에 맞춰 부여하기

“이 에이전트는 배포 담당”처럼 넓은 역할로 권한을 주면 시간이 지날수록 예외가 쌓입니다. 대신 “이번 실행에서는 이 저장소의 브랜치 하나만 만들 수 있다”, “검토 대기 폴더에만 파일을 쓸 수 있다”처럼 작업 단위로 제한하세요. 읽기 권한과 쓰기 권한도 따로 생각해야 합니다.

3. 비밀값: 프롬프트와 작업 폴더에서 분리하기

API 키, SSH 키, 서비스 계정 정보는 에이전트가 보는 요구사항 문서나 대화 기록에 넣지 않는 것이 기본입니다. 필요한 도구 호출에만 안전한 전달 경로를 사용하고, 로그·오류 메시지·결과 파일에 비밀값이 남지 않는지 확인해야 합니다. “에이전트가 알아서 쓸 수 있게 환경 전체를 열어 둔다”는 편의는 나중에 가장 비싼 문제로 돌아오기 쉽습니다.

4. 작업 상태: 재개 정보와 민감 정보를 구별하기

장기 작업은 중단될 수 있으므로 상태를 저장해야 합니다. 다만 상태 파일에는 작업 ID, 입력 버전, 완료 단계, 재시도 횟수처럼 재개에 필요한 최소 정보만 넣는 편이 좋습니다. 이전 대화 전문, 접근 토큰, 불필요한 원본 데이터까지 함께 보관하면 복구 장치는 곧 위험한 보관함이 됩니다.

FLOWIT 운영 관점
모델을 바꾸는 일보다 먼저, 자동화 작업을 “초안 생성”, “검토”, “배포”로 나누고 각 단계의 파일 경로와 권한을 다르게 두세요. 문제가 생겼을 때 어느 단계에서 멈춰야 하는지도 훨씬 분명해집니다.

작업 하나를 네 경계로 나누는 예시

예를 들어 매일 자료를 모아 블로그 초안을 만드는 자동화를 생각해 보겠습니다. 수집 단계는 공개 웹 문서와 임시 폴더만 사용합니다. 작성 단계는 수집 결과를 읽되 운영 서버 설정은 볼 수 없습니다. 검토 단계는 초안을 바꿀 수 있지만 공개 발행은 하지 않습니다. 마지막 배포 단계만 제한된 자격증명으로 승인된 결과물을 전달합니다.

단계	허용할 것	피할 것
수집	공개 출처, 임시 파일	운영 비밀값, 전체 서버 파일
작성	검증된 입력, 초안 폴더	직접 배포 권한
검토	수정 제안, 품질 확인	승인 없는 공개 전환
배포	승인된 산출물, 좁은 배포 권한	원본 데이터 전체 접근

이 구조의 장점은 에이전트가 실수하지 않는다고 가정하지 않아도 된다는 점입니다. 예상과 다른 명령이 나왔을 때 피해 범위를 좁히고, 재시도할 때도 어느 산출물을 신뢰할지 판단하기 쉬워집니다.

AI 에이전트 자동화에서 수집, 작성, 검토, 배포 단계를 구분해 확인하는 체크리스트 장면 — 권한을 넓게 주는 대신, 단계마다 승인과 기록을 남기는 흐름이 운영에 유리합니다.

배포 전에 확인할 체크리스트

이 작업이 읽고 쓸 폴더를 한 문장으로 설명할 수 있나요?
실행 명령과 네트워크 연결이 꼭 필요한 범위로 제한됐나요?
비밀값이 프롬프트, 상태 파일, 오류 로그에 남지 않나요?
중단 뒤 재개할 때 필요한 정보만 상태로 남기나요?
공개 배포나 비용 발생 작업 앞에 사람의 확인 지점이 있나요?
실패했을 때 자동 재시도보다 먼저 중단해야 할 조건이 정의돼 있나요?

모든 항목을 첫날부터 자동화할 필요는 없습니다. 가장 자주 실행하는 작업 하나를 골라, 작업 폴더와 비밀값 분리부터 적용해 보세요. 그 작은 경계가 나중에 에이전트를 더 많이 맡길 수 있는 기반이 됩니다.

자주 묻는 질문

샌드박스를 쓰면 에이전트 보안 문제가 모두 해결되나요?

아닙니다. 샌드박스는 실행 범위를 줄이는 장치일 뿐입니다. 권한 설계, 비밀값 관리, 승인 절차, 로그 점검을 함께 운영해야 합니다.

상태를 저장하지 않으면 장기 작업을 운영할 수 없나요?

상태 저장은 필요할 수 있습니다. 다만 재개에 필요한 최소 정보만 남기고, 민감한 원본이나 자격증명까지 상태에 넣지 않는 것이 중요합니다.

작은 개인 자동화에도 이런 분리가 필요한가요?

처음에는 폴더 하나와 별도 환경 변수만 나누어도 충분합니다. 자동화가 외부 서비스나 실제 파일을 다루기 시작한다면, 그때부터는 작은 작업도 경계를 갖추는 편이 안전합니다.

마무리

에이전트가 일을 잘하게 만드는 방법은 더 강한 모델을 고르는 데만 있지 않습니다. 무엇을 할 수 있는지보다 무엇을 못 하게 할지를 먼저 설계하면, 자동화는 더 오래 안정적으로 운영될 수 있습니다.

참고 자료

이 글이 마음에 드세요?

RSS 피드를 구독하세요!

FLOWIT on YouTube

영상으로도 FLOWIT을 이어서 보세요

AI 자동화, Claude Code, n8n, 데이터 분석 흐름을 블로그와 영상으로 함께 정리하고 있습니다.

YouTube 채널 보기