에이전트 컨테이너 격리 – 여덟 계층별 검증 항목과 도입 전 기준

TL;DR — 에이전트 컨테이너 격리는 Hermes Agent가 만든 명령을 호스트가 아니라 컨테이너 안에서 돌려 명령이 닿는 범위를 좁히는 장치입니다. 다만 여덟 계층 어디에도 실행 결과가 맞았는지 확인하는 단계는 없으므로, 도입 전에 항목별 근거와 조직이 직접 채울 빈칸을 갈라 두어야 합니다.

2026년 프로덕션 운영 환경에 Hermes Agent 도입을 검토하는 담당자라면, 공식 문서가 어디까지 밝히고 어디부터가 조직의 몫인지를 왜 먼저 갈라야 하는지, 그리고 어떻게 에이전트 컨테이너 격리를 포함한 안전장치를 점검할지를 정리해 두는 편이 안전합니다. 이 글은 클라우드네이티브TV가 공개한 영상 ‘AI Agent 시스템 반드시 갖춰야 할 것은 ?— 03. 컨테이너로 가두어야 한다.'(17분 44초)를 캡처 9장과 함께 주장 단위로 풀어, 영상을 보지 않은 독자도 검토 기준을 얻어 가도록 정리했습니다. 영상은 앞 편에서 본 표의 각 줄을 하나씩 펼쳐 수치와 기본값은 나온 그대로 옮기고 빈칸은 빈칸으로 두는 방식으로 진행되며, 이 글도 같은 순서를 따릅니다.

영상은 절차 기억부터 실행 결과 검증까지 여덟 항목을 차례로 훑으면서, 각 항목마다 공식 문서가 밝힌 근거와 문서에 없어 직접 확인해야 하는 빈칸을 나눠 보여 줍니다. 아래 영상을 먼저 보고 오셔도 되고, 글만 읽으셔도 같은 순서로 따라갈 수 있습니다.

영상에서 다루는 순서는 다음과 같습니다.

• 절차 기억(스킬)의 작동 방식과 버전 관리 (2:42)
• 채널 통합의 DM 인증 설정값 (5:24)
• 무인 실행의 전제 조건과 관측 범위 (6:10)
• 외부 연동 네 갈래와 검색 백엔드 (9:32)
• 실행 격리의 두 계층 (10:40)
• 모델 제공자 세 경로와 데이터 처리 위치 (12:14)
• 안전장치 여덟 계층과 실행 결과 검증의 공백 (15:28)

에이전트 컨테이너 격리를 중심에 놓고 영상의 설명을 질문으로 바꾸면 아홉 가지입니다. 아래 아홉 개 절이 이 순서대로 답합니다.

1. 절차 기억은 왜 도입 판단에서 가장 먼저 걸리는가?
2. DM 인증 수치 다섯 개는 어떻게 사내 기준에 대 보는가?
3. 무인 실행은 왜 설치만으로 켜지지 않는가?
4. 설정을 한 줄도 건드리지 않아도 열려 있는 외부 경로는 어디인가?
5. 에이전트 컨테이너 격리는 명령의 도달 범위를 어떻게 좁히는가?
6. 모델 제공자 세 경로는 무엇을 기준으로 가르는가?
7. 데이터가 조직 밖으로 나가는 경로는 왜 따로 확인해야 하는가?
8. 안전장치 여덟 계층은 어떤 묶음으로 읽어야 하는가?
9. 여덟 계층에 없는 실행 결과 검증은 누가 맡는가?

첫 번째 항목은 절차 기억입니다. Hermes Agent는 이 절차 기억을 스킬이라는 이름의 문서로 만듭니다. 영상이 이 항목을 가장 먼저 짚는 까닭은 반복 비용 때문입니다. 업무 절차를 매번 대화창에 다시 풀어써야 한다면 에이전트에 맡긴 시간이 직접 처리하는 시간보다 짧아지지 않고, 담당자가 바뀔 때마다 같은 설명이 처음부터 되풀이됩니다.

화면 왼쪽은 점진적 공개입니다. 절차 전체를 시작할 때 통째로 읽지 않고 제목과 요약을 먼저 훑은 뒤 필요한 대목만 그때 펼칩니다. 두꺼운 요리책을 처음부터 끝까지 읽지 않고 목차에서 오늘 만들 요리만 펼치는 것과 같습니다. 그래서 스킬을 열 개 쌓은 조직과 백 개 쌓은 조직의 입력 비용 차이가 개수에 정비례하지 않습니다. 오른쪽은 공개 표준 호환입니다. 스킬 형식이 공개 표준을 따르므로 같은 규격을 읽는 다른 도구도 같은 파일을 그대로 열고, 사람이 읽는 문서라 별도 뷰어가 필요 없으며 저장소에 넣어 변경 이력을 남길 수도 있습니다.

▲ 절차 기억은 스킬 문서로 쌓이고 필요한 대목만 펼쳐진다 (영상 2:42)

이 조건이 도입 판단에 들어가는 까닭은 종속 위험의 크기 때문입니다. 표준을 따르는 문서라면 제품을 바꾸더라도 쌓아 둔 절차를 가져갈 길이 열려 있습니다. 영상은 이어서 스킬이 쌓이는 두 시점을 설명합니다. 하나는 실행 중으로, 따로 지시하지 않아도 에이전트가 방금 처리한 절차를 남길 만하다고 판단하면 그때 문서로 정리하므로 결정 근거까지 함께 남습니다. 다른 하나는 세션이 끝난 뒤로, 뒤에서 도는 자기개선 검토가 작업을 되짚어 개선할 점을 스킬로 남깁니다. 화면을 보고 있지 않은 동안에도 절차 기억이 늘어난다는 뜻입니다.

여기서 근거와 빈칸이 갈립니다. 스킬 문서에는 버전 필드가 있고 제품이 함께 주는 스킬은 원본 지문(origin hash)으로 수정 여부를 대조할 수 있으며, 갱신 명령은 한 번만 내려받아 모든 프로파일에 맞춥니다. 프로파일을 다섯 개 쓴다면 다섯 번 되풀이하던 일이 명령 한 줄로 줄어듭니다. 반면 업데이트가 로컬 수정분을 지키는지는 명시가 없어 시험 프로파일에서 확인해야 합니다. 영상은 스스로 늘어나는 기억이 스스로 굳어진 잘못도 함께 늘린다고 경고하며, 잘못 든 습관은 고치기 전까지 매일 반복된다고 비유합니다.

두 번째 항목은 채널 통합입니다. 영상은 확인할 것을 두 가지로 줄입니다. 조직이 이미 쓰는 메신저가 채널로 붙는지, 그리고 메신저 계정과 에이전트 계정을 짝짓는 절차가 보안 검토를 통과할 수 있는지입니다. 앞의 것은 공식 문서가 개관 수준까지만 밝히는 반면, 뒤의 것은 수치를 그대로 공개합니다.

화면 위쪽 다섯 칸이 그 수치입니다. 짝짓기 코드는 헷갈리는 글자를 뺀 알파벳에서 뽑은 여덟 글자이고 유효 시간은 한 시간입니다. 한 사람은 십 분에 한 번만 코드를 요청할 수 있고, 대기 중인 코드는 세 개까지 남으며, 다섯 번 실패하면 한 시간 잠깁니다.

▲ 채널 통합의 DM 인증 설정값 다섯 가지 (영상 5:24)

값 하나하나보다 중요한 것은 세 가지가 함께 걸려 있다는 점입니다. 자물쇠를 아무리 복잡하게 만들어도 열쇠를 무한히 시험할 수 있으면 언젠가 열립니다. 코드 길이만으로는 계속 새로 받아 가며 시도하는 방식을 막지 못하고, 요청을 십 분에 한 번으로 묶고 다섯 번 실패에서 잠가야 구성이 완성됩니다.

이 수치는 사내 기준에 바로 대 볼 수 있다는 점에서 근거가 단단한 항목입니다. 영상은 사내 규정이 코드 유효 시간을 삼십 분 안으로 묶어 두었다면 한 시간이라는 값은 규정과 어긋난다는 예를 듭니다. 반대로 빈칸은 어떤 메신저가 어디까지 붙는지에 있습니다. 개관 수준의 설명만 있으므로 우리가 쓰는 메신저가 실제로 연결되는지는 시험 환경에서 먼저 확인해야 합니다.

세 번째 항목은 무인 실행입니다. 채널이 요청을 받는 입구라면, 그 요청이 사람의 추가 승인 없이 끝까지 도는 것은 별개의 조건입니다. 퇴근한 뒤에도 일을 시킬 수 있다는 조건이 성립하려면 제품 기능만으로는 모자라고 인프라 쪽 전제가 따로 붙습니다. 화면 왼쪽 카드의 세 가지가 그 전제로, 프로세스 관리자와 재시작 정책, 그리고 로그 보존 기간입니다.

무인 실행은 요청이 들어오는 동안 프로세스가 계속 살아 있어야 성립합니다. 밤 열한 시에 들어온 요청을 받으려면 그 시각에 떠 있어야 하고, 새벽 두 시에 끝나려면 그때까지 죽지 않아야 합니다. 가게 문을 닫아 두고 야간 배달을 받겠다고 할 수는 없습니다. 중간에 호스트가 절전에 들어가면 요청은 처리되지 못한 채 남습니다.

▲ 무인 실행의 전제 조건과 환경 제약 (영상 6:10)

오른쪽 주황 카드는 윈도우 환경을 쓰는 조직에 특히 중요합니다. 공식 문서는 WSL의 상시 구동 지원이 불안정하다고 밝힙니다. 사내 표준이 윈도우이고 개발용으로 WSL을 쓴다면 밤새 돌 예정이던 작업이 아침에 멈춰 있는 상황을 만날 수 있으므로, 영상은 하룻밤 실제 구동 시험을 거친 뒤 판단하라고 권합니다.

영상은 이어서 무인 실행의 결과를 확인하는 계측을 살핍니다. 이미 갖춰진 것은 토큰 회계, 추정 비용, 세션 길이, 사용 요약의 네 가지입니다. 몇 번 돌았고 얼마를 썼는지는 아침에 볼 수 있고, 세션이 유난히 길어졌다면 그 자체가 확인할 작업을 골라내는 단서가 됩니다. 아직 없는 것은 이 계측을 하나로 모으는 층입니다. 영수증은 다 모아 두었는데 가계부가 없는 상태와 같아서, 얼마를 썼는지는 알아도 무엇을 제대로 했는지는 확인할 수 없고 무인 실행 건수가 늘수록 사람의 확인 부담이 함께 늡니다. 에이전트 컨테이너 격리를 켜 두었더라도 이 확인 부담은 줄지 않습니다.

네 번째 항목인 실행 격리로 들어가기 전에 영상은 도구가 어디까지 닿는지부터 따라갑니다. 에이전트가 도구를 부른다는 서술만으로는 판단할 것이 남지 않기 때문입니다. 필요한 정보는 어떤 연동이 미리 정해져 있는지, 그리고 요청 하나가 그 연동을 타고 어디까지 흘러가는지입니다.

공식 문서가 정해 둔 연동은 웹 검색·추출 백엔드, 메시징 플랫폼, 모델 제공자, MCP 서버의 네 갈래입니다. 그중 검색과 추출 백엔드는 여덟 종이고, 기본값은 Firecrawl이며, 조직이 직접 세워 운영할 수 있는 메타 검색 엔진 SearXNG가 초록 테두리로 표시됩니다. 외부로 나가는 웹 요청을 막아야 하는 조직이라면 이 항목부터 확정하는 편이 낫습니다.

▲ 외부 연동 네 갈래와 검색 백엔드 여덟 종 (영상 9:32)

화면 왼쪽 아래 주황 카드가 핵심입니다. web.backend 값을 비워 두면 등록된 API 키가 백엔드를 결정하므로, 설정을 한 줄도 건드리지 않아도 이 경로가 이미 살아 있습니다. 다른 업무에 쓰려고 넣어 둔 열쇠 하나 때문에 검색 요청이 예상하지 못한 곳으로 나갈 수 있습니다. 집을 비우며 현관은 잠갔는데 뒷문 열쇠를 화분 밑에 둔 것과 같습니다.

오른쪽 카드는 조직이 정해야 할 세 가지를 적습니다. 검색 백엔드를 어떤 것으로 둘지, web.backend 값을 명시하고 등록된 키와 정기적으로 대조할지, 그리고 컨테이너에 마운트할 디렉터리와 열어 줄 네트워크 범위를 어디까지로 할지입니다. 마지막 항목이 바로 다음 절의 주제입니다. 앞의 둘은 공식 문서가 선택지를 뚜렷하게 공개한 근거이고, 마지막은 조직이 정해야 하는 빈칸입니다.

영상의 제목이 말하는 장면입니다. 보안 모델은 여덟 계층으로 이루어져 있고, 그 가운데 두 계층이 도구 실행 범위를 직접 좁힙니다. 화면 왼쪽 그림에서 바깥 회색이 호스트 시스템, 가운데 파란 원이 컨테이너 격리, 안쪽 짙은 원이 파일 쓰기 안전장치입니다.

▲ 실행 격리의 두 계층, 컨테이너 격리와 파일 쓰기 안전장치 (영상 10:40)

에이전트 컨테이너 격리의 작동은 단순합니다. 에이전트가 만든 명령은 호스트에서 바로 돌지 않고 컨테이너 안에서 실행되며, 그 안에서 볼 수 있는 파일과 네트워크는 컨테이너에 주어진 범위를 넘지 못합니다. 에이전트는 무엇을 실행할지 문장으로 정하고 실행 계층이 그 문장을 컨테이너 안에서 돌립니다. 그러므로 모델이 잘못된 명령을 만들어도 그 명령이 닿는 범위는 컨테이너 경계에서 멈춥니다.

두 번째 계층인 파일 쓰기 안전장치는 방향이 다릅니다. 컨테이너 격리가 바깥으로 나가는 길을 막는다면 이쪽은 안에서도 손대면 안 되는 파일을 지킵니다. 배의 격벽처럼 한 칸에 물이 들어와도 배 전체가 잠기지 않게 나눈 구조입니다. 따로 필요한 이유는 에이전트가 파일을 다루는 빈도에 있습니다. 문서를 저장하고 설정을 고치고 산출물을 남기는 일이 모두 파일 쓰기로 일어나기 때문입니다. 두 계층은 같은 실행 경로 위에 겹쳐 있어서 하나를 넘어선 명령도 나머지에서 다시 걸러지고, 둘 다 설치 직후부터 작동하는 기준선입니다.

다만 빈칸이 하나 남습니다. 컨테이너가 쓸 수 있는 범위는 마운트한 디렉터리와 열어 준 네트워크가 정합니다. 이 두 가지를 넓게 열어 두면 에이전트도 그만큼을 그대로 쓸 수 있고, 영상 화면은 이 구성에 대한 권장 기준이 공식 문서에 없다고 적습니다. 에이전트 컨테이너 격리를 켰다는 사실보다 무엇을 안에 넣어 주었는지가 실제 보호 범위를 결정하므로, 도입 전에 조직이 직접 정해 문서로 남겨 두어야 한다는 것이 이 절의 결론입니다.

다섯 번째 항목은 데이터 처리 위치 공개입니다. 영상은 도입 결재를 준비할 때 가장 먼저 받는 질문이 대개 여기에 걸린다고 말합니다. 우리 회사 데이터가 어디로 나가느냐는 질문의 첫 갈래가 모델 제공자이고, 공식 문서가 나열한 경로는 세 가지입니다.

▲ 모델 제공자 세 경로와 캐시 재계산 (영상 12:14)

첫째는 모델 회사에 직접 연결하는 방식으로 주고받는 내용이 그 회사 서버로만 오갑니다. 둘째는 여러 제공자를 하나로 묶어 주는 중계 계층을 한 번 거치는 방식이고, 셋째는 제품을 만든 곳이 직접 운영하는 관문을 쓰는 방식입니다. 세 경로를 가르는 기준은 성능 순위보다 계약 형태에 가깝습니다. 이미 계약이 있는 조직은 첫째가 결재 절차상 가장 짧고, 여러 모델을 바꿔 가며 비교하려는 조직은 중계 계층 한 곳만 계약하면 되는 둘째가 편하며, 계약 없이 시범부터 시작하려는 조직에는 셋째의 문턱이 가장 낮습니다.

오른쪽 주황 카드는 예산 담당자가 반드시 보아야 할 부분입니다. 제공자와 모델은 명령 한 줄로 언제든 바꿀 수 있지만 바꾸는 순간 쌓아 둔 캐시가 초기화됩니다. 살던 집을 옮길 때 보증금은 돌려받아도 이사 비용은 새로 드는 것과 같습니다. 따라서 모델을 자주 바꿔 가며 비교하겠다는 계획은 그만큼의 재계산 비용을 예산에 넣고 세워야 합니다.

영상은 이어서 데이터가 나가는 경로를 전부 펼칩니다. 에이전트를 드나드는 데이터는 한 갈래로만 흐르지 않습니다. 코어를 가운데 두고 보면 서로 독립된 네 경로가 각자 다른 곳으로 데이터를 보내거나 받습니다.

▲ 데이터가 조직 밖으로 나가는 네 경로 (영상 14:06)

첫 줄은 검색과 추출 백엔드로, 설정을 지정하지 않으면 열쇠를 기준으로 알아서 고르고 여덟 종 가운데 하나로 바꿀 수 있습니다. 둘째 줄은 모델 제공자입니다. 이 경로로는 주고받는 내용과 그때까지 쌓인 맥락이 함께 오가므로 네 갈래 중 가장 많은 것을 실어 나릅니다. 화면의 핵심 문장대로 코어를 사내 서버에 올려도 네 경로의 목적지는 경로별 설정으로 따로 정해지므로, 프로세스가 어디서 도는지와 외부 호출이 어디로 가는지는 서로 다른 질문입니다.

셋째 줄이 가장 오해하기 쉽습니다. 개발 지침은 새 분석 기능을 사용자가 켜고 끌 수단이 갖춰지기 전까지 넣지 않는다고 밝힙니다. 그러나 이것은 앞으로 들어올 코드에 적용하는 기준입니다. 지금 배포판에 수집이 전혀 없다는 뜻으로 읽으면 안 됩니다. 공사 중인 건물의 설계 변경 원칙과 이미 지어진 부분은 다른 이야기이고, 공개된 이슈는 토큰과 비용과 세션 길이 같은 계측이 이미 돌고 있다고 적고 있습니다. 에이전트 컨테이너 격리가 명령의 범위를 좁혀도 이 네 경로의 목적지까지 정해 주지는 않습니다. 근거가 있는 부분과 해석이 갈리는 부분을 이렇게 따로 읽어야 결재 문서에 틀린 문장이 들어가지 않습니다.

여섯 번째와 일곱 번째 항목은 권한 분리와 위험 명령 승인입니다. 공식 문서는 안전장치를 여덟 계층으로 나눠 설명하는데, 번호 순서대로 읽으면 전체 그림이 마지막에야 잡히므로 영상은 세 묶음으로 다시 나눕니다. 실행 주체를 통제하는 앞의 두 계층, 실행 범위를 가두는 가운데 세 계층, 드나드는 데이터를 다루는 나머지 세 계층입니다.

▲ 안전장치 여덟 계층의 세 묶음 (영상 15:28)

실행 주체 묶음의 첫 계층은 사용자 인가로, 요청을 보낸 사람에게 쓸 자격이 있는지를 실행 이전에 확인합니다. 둘째는 위험 명령 승인으로, 삭제나 전송처럼 되돌리기 어려운 명령을 실행 직전에 멈추고 사람의 승인을 요구합니다. 무인 실행과 승인 관문이 부딪히는 것처럼 보이지만 두 계층은 적용 범위가 다릅니다. 사용자 인가는 건물 입구의 출입증처럼 한 번 열리고 닫히고, 위험 명령 승인은 그 안에서도 금고를 열 때만 따로 열쇠를 요구하는 장치입니다.

그래서 야간에 무인으로 도는 작업이라도 파일을 지우거나 밖으로 무언가를 내보내는 명령을 만나면 그 순간 승인을 기다립니다. 영상은 무인 실행이 뜻하는 바를 확인해야 할 명령만 골라 사람에게 넘기는 운영 방식이라고 정리합니다. 가운데 묶음에는 앞서 본 파일 쓰기 안전장치와 에이전트 컨테이너 격리가 들어갑니다. 즉 여덟 계층을 번호로 외우기보다 누가 시작하는가, 어디까지 닿는가, 무엇이 드나드는가의 세 물음으로 읽으면 점검표가 훨씬 짧아집니다.

마지막 여덟 번째 항목은 실행 결과 검증입니다. 지금까지 짚은 여덟 계층에는 공통점이 하나 있습니다. 모두 누가, 무엇을, 어디까지 할 수 있는가를 통제하고, 작동 시점도 실행 이전이거나 실행 도중입니다. 실행이 끝난 뒤 결과가 맞았는지 확인하는 계층은 여덟 가운데 하나도 없습니다.

▲ 여덟 계층이 다루지 않는 실행 결과 검증 (영상 17:25)

이유는 승인 관문이 걸러 내는 대상에 있습니다. 관문은 삭제나 전송처럼 정해진 형태에 들어맞는 명령을 잡는데, 보고서를 잘못 요약하거나 숫자를 잘못 더한 산출물은 명령 자체가 안전하므로 관문에 아예 걸리지 않습니다. 공항 검색대가 위험한 물건은 찾아내지만 가방 안 서류의 내용이 맞는지는 보지 않는 것과 같습니다. 명령이 규칙을 지켜 돌았는지와 결과가 옳은지는 서로 다른 질문이고, 여덟 계층은 앞의 질문에만 답합니다.

영상은 이 공백을 제품의 결함으로 읽을 이유는 없다고 선을 긋습니다. 여덟 계층은 처음부터 누가 실행을 시작하고 어디까지 손댈 수 있는가를 설계 범위로 삼았고, 공식 문서도 이 체계를 보안 모델이라고 부를 뿐 결과 품질을 보증한다고 말하지 않습니다. 따라서 결과를 사람이 읽고 확인하는 절차는 조직이 따로 마련해야 합니다.

컨테이너는 호스트 커널을 공유하는 격리라는 점이 일반적인 컨테이너 보안 문서(Docker Engine security)의 출발점입니다. 그래서 에이전트 컨테이너 격리를 도입할 때는 격리가 켜져 있는지보다 컨테이너에 무엇을 넣어 주었는지를 목록으로 남기는 일이 중요합니다. 영상이 가른 항목별 근거와 빈칸을 도입 점검표로 바꾸면 다음과 같습니다.

이 표의 모든 칸은 공식 문서에 기준이 없어 조직이 직접 정해야 하는 값입니다. 담당자가 바뀌어도 같은 기준으로 점검해야 하므로 표를 사내 문서에 옮겨 두고, 시험 프로파일에서 하룻밤 실제 구동을 거친 뒤 값을 확정하는 순서를 권합니다.

에이전트 컨테이너 격리는 명령의 도달 범위를 좁히는 든든한 기준선이지만, 그 범위를 정하는 마운트와 네트워크는 조직의 몫이며 결과가 맞는지는 여덟 계층 밖에 있습니다. 영상이 가른 항목별 근거와 빈칸은 아래와 같습니다.

에이전트 컨테이너 격리는 무엇을 막나요?

에이전트가 만든 명령이 호스트에서 바로 실행되지 않고 컨테이너 안에서만 돌게 하여 닿는 범위를 제한합니다. 영상은 모델이 잘못된 명령을 만들어도 그 범위가 컨테이너 경계에서 멈춘다고 설명합니다.

컨테이너 격리만 켜면 안전한가요?

아닙니다. 컨테이너가 쓸 수 있는 범위는 마운트한 디렉터리와 열어 준 네트워크가 정하므로, 이를 넓게 열면 에이전트도 그만큼을 그대로 쓸 수 있습니다. 이 구성에 대한 권장 기준은 공식 문서에 없어 조직이 직접 정해야 합니다.

파일 쓰기 안전장치는 컨테이너 격리와 어떻게 다른가요?

컨테이너 격리가 바깥으로 나가는 길을 막는다면 파일 쓰기 안전장치는 안에서도 손대면 안 되는 파일을 지킵니다. 두 계층이 같은 실행 경로 위에 겹쳐 있어 하나를 넘은 명령도 다른 하나에서 걸러집니다.

무인 실행은 설치만 하면 되나요?

아닙니다. 프로세스 관리자, 재시작 정책, 로그 보존 기간이라는 인프라 전제가 따로 필요합니다. 특히 WSL은 상시 구동 지원이 불안정하다고 공식 문서가 밝혀 하룻밤 구동 시험이 필요합니다.

설정을 안 바꿔도 데이터가 밖으로 나갈 수 있나요?

네. web.backend 값을 비워 두면 등록된 API 키가 검색 백엔드를 정하므로, 다른 업무용 키 때문에 검색 요청이 예상하지 못한 곳으로 나갈 수 있습니다. 값을 명시하고 키와 정기적으로 대조해야 합니다.

모델 제공자를 바꾸면 무엇이 달라지나요?

명령 한 줄로 바꿀 수 있지만 바꾸는 순간 쌓아 둔 캐시가 초기화되어 비용이 새로 듭니다. 세 경로는 성능 순위보다 계약 형태로 가르며, 이미 계약이 있다면 직접 연결이 결재 절차상 가장 짧습니다.

여덟 계층이 실행 결과가 맞는지도 확인하나요?

아닙니다. 여덟 계층은 누가 무엇을 어디까지 할 수 있는지만 통제하고, 결과가 맞았는지 확인하는 계층은 없습니다. 잘못 요약한 보고서는 명령 자체가 안전해 승인 관문에 걸리지 않으므로 사람의 검수 절차가 필요합니다.

에이전트 컨테이너 격리를 더 깊이 살펴볼 때 볼 원 영상과 이어서 읽을 글, 개념 문서를 모았습니다.

• AI Agent 시스템 반드시 갖춰야 할 것은 ?— 03. 컨테이너로 가두어야 한다. — 클라우드네이티브TV, 이 글이 정리한 원 영상
• AI 에이전트란 무엇인가 — 에이전트 구조의 기본 개념
• 에이전틱 AI란 무엇인가 — 에이전트가 판단과 실행을 나누는 방식
• 에이전틱 AI 거버넌스 가이드 — 승인과 감사 절차 설계
• LLM이란 무엇인가 — 모델 제공자 선택의 배경 개념
• MSAP.ai 솔루션 문의 — 도입 검토 상담
• MSAP.ai 홈페이지 — 제품과 자료 모음
• Docker Engine security — 컨테이너 격리의 일반 보안 문서
• Hermes Agent 공식 저장소 — 제품 코드와 문서
• Container isolation (OS-level virtualization) — 컨테이너 격리의 일반 개념
• Principle of least privilege — 최소 권한 원칙의 일반 개념
• Sandbox (computer security) — 샌드박스의 일반 개념