DEVOCEAN

AI 에이전트가 외부 시스템에 무단 접근하는 사고가 잇따르자 언론은 인공지능 모델의 자율성 문제를 먼저 거론합니다. 반면 보안 엔지니어들은 격리 환경 설계와 통신 감시 미흡이라는 인프라 운영 결함을 지적합니다.

원문 [[1]](https://news.hada.io/topic?id=35357)에 따르면 보안 전문가들은 프론티어 AI 연구소의 외부 시스템 무단 접근 사건을 두고 수십 년간 알려진 보안 관행을 제대로 적용하지 않은 결과로 평가했습니다. Hugging Face 등에서 발생한 사건의 핵심 원인 역시 잘못 구성된 샌드박스와 통제되지 않은 외부 네트워크 통신이었습니다. 모델이 스스로 판단해 울타리를 부순 것이 아니라, 애초에 울타리가 비어 있었습니다.

자율 에이전트와 코딩 도구를 조직에 도입할 때 발생하는 장애는 모델의 추론 능력보다 시스템적 제약의 유무에서 갈립니다. 외부 통신을 차단하는 샌드박스 인프라, 비사람 계정(NHI, Non-Human Identity)의 권한 관리, 팀 규칙을 강제하는 자동 검증 파이프라인이 갖춰지지 않은 상태에서 에이전트의 권한만 넓히면 시스템 장애와 정보 유출로 이어집니다.

샌드박스 격리와 외부 통신 통제

보안 전문가들이 지적하는 샌드박스 구성 결함은 모델 실행 환경을 호스트 시스템 및 사내 사설망과 분리하지 않은 데서 출발합니다. 프롬프트 인젝션이나 예기치 않은 도구 호출(Tool Calling)이 발생했을 때, 에이전트 프로세스가 호스트의 파일 시스템에 접근하거나 인가되지 않은 외부 IP로 패킷을 내보낼 수 있다면 위험 반경은 걷잡을 수 없이 커집니다.

에이전트 통제는 모델 프롬프트에 주의 문구를 추가하는 방식만으로는 보장할 수 없습니다. 운영체제 커널 수준의 격리와 네트워크 방화벽 규칙을 적용해야 프로세스의 물리적 경계가 형성됩니다.

이 주제에 대한 판단은 지금 써볼 만하다는 것입니다. 리눅스 네임스페이스와 cgroups, gVisor나 Kata Containers 같은 경량 가상화 기술, 그리고 사설 서브넷 단위의 엄격한 아웃바운드(Egress) 통제는 이미 안정화된 기술 스택입니다. 에이전트가 실행되는 런타임을 일반 컨테이너가 아닌 격리된 샌드박스로 감싸는 작업은 대규모 AI 인프라를 구축하지 않더라도 즉시 적용할 수 있습니다.

실무에서는 에이전트 작업 공간을 호스트 파일 시스템과 완전히 격리하고, 사전에 허용된 외부 도메인 외의 모든 아웃바운드 트래픽을 기본 차단(Default Deny)하는 네트워크 정책을 구성해야 합니다. 아래는 도커 컨테이너 환경에서 최소 권한 원칙과 읽기 전용 루트 파일 시스템, 보안 프로필을 적용해 에이전트의 로컬 탈출을 제한하는 설정 예시입니다.

# docker-compose.agent-sandbox.yml
version: "3.8"

services:
  agent-runner:
    image: ghcr.io/internal/agent-runtime:1.4.2
    container_name: agent_isolated_worker
    read_only: true
    cap_drop:
      - ALL
    security_opt:
      - no-new-privileges:true
      - seccomp=/etc/docker/seccomp/strict-agent.json
    tmpfs:
      - /tmp:rw,noexec,nosuid,size=64m
    volumes:
      - agent-workspace:/workspace:rw
    networks:
      - restricted_egress
    deploy:
      resources:
        limits:
          cpus: "2.0"
          memory: 2048M

networks:
  restricted_egress:
    driver: bridge
    internal: false
    driver_opts:
      com.docker.network.bridge.enable_icc: "false"

volumes:
  agent-workspace:

네트워크 차원에서는 iptables 또는 클라우드 보안 그룹(Security Group)을 통해 에이전트 컨테이너가 사내 메타데이터 서비스(예: 169.254.169.254)나 내부 데이터베이스에 직접 질의하지 못하도록 차단하고, LLM API 엔드포인트로 향하는 HTTPS 통신만 명시적으로 허용해야 합니다.

사번 없는 접속자: 비사람 계정(NHI) 통제

에이전트 인프라를 안전하게 격리하더라도 시스템에 접속하는 권한 체계가 허술하면 계정 탈취와 권한 오용이 발생합니다. 원문 [[4]](https://indieblog.net/go/582832)가 짚었듯, 신규 입사자는 사번이 부여되고 직군에 맞는 권한을 받으며 퇴사 시 계정이 잠깁니다. 그러나 에이전트, 스크립트, 워크플로 봇 같은 비사람 계정(NHI, Non-Human Identity)은 사번도 퇴사도 없습니다.

누가 생성했는지, 언제 만료되는지, 어떤 리소스에 접근할 수 있는지 파악되지 않은 API 키와 토큰이 코드베이스나 환경 변수에 방치됩니다. 개발자가 로컬 테스트를 위해 에이전트 CLI 도구에 관리자(Admin) 권한의 클라우드 인증 토큰을 등록해 두고 잊어버리는 상황이 대표적입니다. 이 토큰이 에이전트의 외부 유출 사고나 프롬프트 인젝션으로 드러나면 조직 전체의 인프라가 위험에 처합니다.

여기부터는 DEVOTEE의 해석입니다. 조직에서 활동하는 AI 에이전트는 독립된 지능형 개체가 아니라 '특정 역할을 위임받은 장기 실행 비사람 계정'으로 정의해야 보안 감사가 가능해집니다. 에이전트 전용 신원을 사람 계정과 엄격히 분리하고, 역할 기반 접근 제어(RBAC)를 통해 최소 권한만 부여해야 합니다.

이 주제에 대한 판단은 조건부로 유효하다는 것입니다. 엔터프라이즈급 NHI 전용 거버넌스 솔루션을 전사 도입하는 것은 예산과 리소스 부담이 큽니다. 다만 에이전트에게 사람이 쓰는 장기 토큰을 공유하지 않고, 단기 임시 자격 증명(STS, Short-Term Session Token)과 서비스 어카운트를 발급하는 체계는 지금 단계에서도 구축해야 합니다.

실무에서 에이전트용 IAM 역할을 정의할 때는 와일드카드(*) 권한을 배제하고 작업에 필요한 특정 경로와 동작만 명시해야 합니다. 예를 들어 AWS 환경에서 코딩 에이전트가 S3 빌드 아티팩트만 참조해야 한다면 다음과 같이 범위를 한정합니다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowAgentReadWorkspaceArtifactsOnly",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::ci-agent-artifacts-prod",
        "arn:aws:s3:::ci-agent-artifacts-prod/tasks/${aws:PrincipalTag/TaskId}/*"
      ]
    },
    {
      "Sid": "DenySensitiveMetadataAccess",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": ["ap-northeast-2"]
        }
      }
    }
  ]
}

에이전트가 사용하는 토큰의 수명은 최대 1시간을 넘지 않도록 설정하고, 지속적인 접근이 필요할 때는 OIDC(OpenID Connect) 기반으로 매 실행마다 인증을 갱신하도록 설계하는 것이 안전합니다.

암묵지의 명문화와 하네스 기반 자동 검증

인프라 격리와 자격 증명 수명주기가 정돈된 뒤 마주하는 지점은 에이전트가 출력하는 산출물의 품질 관리입니다. 원문 [[10]](https://velopers.kr/post/9433)에 따르면 kt cloud 기술팀은 AI 자동화의 과제를 코드 생성이 아닌 유지보수와 검증으로 정의했습니다. 팀의 암묵지를 명문화하고, 페르소나 설정과 SKILL.md, YAML 기반 Harness 검증 체계를 설계해 코드 생성 이후 발생하는 검증 병목을 해결한 사례를 공개했습니다.

에이전트가 만든 코드는 문법적으로 유효해 보여도 프로젝트의 아키텍처 규칙이나 린트 규격을 어기기 쉽습니다. 사람이 PR(Pull Request)마다 일일이 코드를 열어보며 기본 규칙 준수 여부를 확인하면 리뷰 병목이 심화됩니다. 검증 자동화가 선행되지 않은 코드 생성은 결과적으로 검토자의 피로도만 가중시킵니다.

이 주제에 대한 판단은 지금 써볼 만하다는 것입니다. kt cloud의 사례처럼 팀 내부의 규칙을 자연어 문서(SKILL.md)와 기계 판독 가능한 스키마(YAML Harness)로 정의하고, 에이전트가 코드를 커밋하기 전에 이 하네스를 통과하도록 파이프라인을 묶는 작업은 개발 조직의 생산성을 즉각 보호합니다.

실무에서는 에이전트가 준수해야 할 작업 명세와 자동화된 테스트, 정적 분석 린터를 선언적 파이프라인으로 묶을 수 있습니다. 아래는 에이전트가 작성한 인프라 코드(Terraform)나 애플리케이션 코드를 격리 환경에서 자체 검증하도록 구성한 Harness 설정 예시입니다.

# .agent-harness.yaml
version: "1.0"
metadata:
  target_project: "billing-core-service"
  rule_manifest: "./docs/architecture/SKILL.md"

constraints:
  disallowed_patterns:
    - pattern: "0.0.0.0/0"
      message: "보안 그룹 인바운드에 전체 개방 규칙을 선언할 수 없습니다."
    - pattern: "System.out.println"
      message: "표준 출력을 직접 사용하지 말고 구조화된 로거를 주입하세요."

validation_pipeline:
  stages:
    - name: "Format & Lint Check"
      command: "make lint"
      timeout_seconds: 60

    - name: "Static Security Scan"
      command: "trivy config ./infra --severity HIGH,CRITICAL --exit-code 1"
      timeout_seconds: 120

    - name: "Unit & Boundary Test"
      command: "pytest tests/unit --maxfail=1"
      timeout_seconds: 180

review_policy:
  require_human_sign_off: true
  min_approvers: 1

에이전트는 위 하네스 검증을 로컬 샌드박스 내부에서 먼저 실행합니다. 세 단계 검증을 모두 통과한 코드만 브랜치로 푸시할 수 있으며, 마지막 단계에는 반드시 사람의 서명(require_human_sign_off)을 거치도록 강제합니다. 생성은 기계가 신속하게 진행하되, 팀 규칙 일치 여부는 기계가 검증하고, 프로덕션 반영 책임은 사람이 지는 구조입니다.

에이전트 권한 확대 시 고려할 조건

에이전트에게 더 넓은 자율성을 맡길 수 있는 시점은 모델의 벤치마크 점수가 올라갔을 때가 아닙니다. 조직의 인프라 격리 수준, 신원 수명주기 통제, 자동화된 검증 체계가 견고하게 맞물려 작동할 때 비로소 자율 작업의 범위를 확장할 수 있습니다.

이그레스 네트워크가 열려 있는 환경에서는 사소한 프롬프트 오류 하나로도 데이터가 외부로 유출될 수 있습니다. 장기 유효 토큰이 에이전트 설정 파일에 남아 있다면 프롬프트 인젝션 공격 한 번에 클라우드 계정 전체의 주도권이 넘어갈 수 있습니다. 자동 검증 없는 대량 코드 커밋은 코드베이스의 유지보수 비용을 장기적으로 누적시킵니다.

시스템 관리자는 에이전트의 지능 수준을 통제할 수 없습니다. 그러나 에이전트가 머무는 런타임 환경, 호출 가능한 API의 수명, 산출물이 거쳐야 할 검증 관문은 시스템 엔지니어링의 영역이며 완전히 통제할 수 있습니다.

도입 전 확인할 것

조직에 코딩 에이전트나 자율 실행 도구를 도입하기 전 다음 세 가지 항목을 점검해야 합니다.

1. 런타임 샌드박스 분리 여부: 에이전트가 실행되는 컨테이너가 루트 파일 시스템 쓰기 금지(read_only: true) 상태인지, 호스트의 민감 경로가 마운트되지 않았는지, 허용되지 않은 사설망 IP 및 사내 메타데이터 서비스 접근이 네트워크 레벨에서 기본 차단되어 있는지 확인합니다.
2. 비사람 계정(NHI)의 수명 및 권한 분리: 에이전트에 개발자 개인의 자격 증명이나 관리자(Admin) 권한 토큰을 그대로 전달하고 있지 않은지 확인합니다. 에이전트 전용 서비스 계정을 두고, 1시간 이내로 만료되는 임시 STS 토큰이나 OIDC 기반 인증을 사용하는지 점검합니다.
3. 선언적 하네스 검증 체계: 팀의 코딩 컨벤션과 아키텍처 규칙이 자연어 문서(SKILL.md)와 CI 검증 스크립트로 정의되어 있는지, 에이전트가 생성한 코드가 사람의 리뷰 단계로 넘어가기 전 정적 분석과 단위 테스트를 자동으로 통과하도록 강제되어 있는지 확인합니다.

그 밖의 소식

• PostgreSQL 19 베타, LLM 보조 코드 리뷰 도입 후 경계 사례 결함 발견으로 주요 기능 8~10개 되돌림
• Spring Boot 테스트에서 빈 충돌을 유발하는 컴포넌트 스캔 범위 조절 방법
• Spark Connect on Kubernetes: 세션 유지와 장애 복구를 위한 Spark Tenant Operator 구축기
• LLM 생성 텍스트 워터마크 기술(KGW, SynthID-Text) 도입 시 단어 자연스러움 저하 현상 분석