우리 서버에는 사내 직원뿐 아니라 유지보수 업체, 관리형 서비스 제공업체(MSP), 외주 개발사, 설치형 소프트웨어 공급사의 엔지니어도 접속합니다. 이들도 업무에 AI를 쓰기 시작했습니다. 엔지니어에게 키와 계정을 건넸다면, 그들이 쓰는 AI 에이전트도 같은 키로 서버에서 명령을 실행할 수 있습니다.
이 글은 자사 서버를 관리하는 보안팀과 운영팀을 위해 썼습니다. 외부 업체의 AI가 서버에 접근하면 무엇이 달라지는지, 기존의 키 관리와 승인 절차, PAM으로 어디까지 대응할 수 있는지 짚습니다. 이어서 외부 인력과 AI 에이전트가 서버에서 실행하는 명령을 우리가 통제하는 방법을 살펴봅니다.
업체의 AI는 이미 운영 업무에 들어와 있습니다
MSP용 IT 관리 소프트웨어를 만드는 Kaseya가 2026년 4월 발표한 조사에서 전 세계 MSP 1,000여 곳 가운데 53%가 티켓 처리, 패치, 모니터링 자동화에 AI를 쓰고 있다고 답했습니다. 에이전트가 로그를 읽고 원인을 좁히며 반복 작업을 처리하면, 업체는 기존 인력으로 더 많은 고객사를 맡을 수 있습니다.
우리가 살펴야 할 것은 에이전트의 접속 경로입니다. 에이전트가 업체에 건넨 키나 계정을 함께 쓰면 사람이 한 작업과 에이전트가 한 작업을 구분할 수 없습니다. 엔지니어가 회사에서 지정한 도구 외에 개인적으로 쓰는 에이전트까지 있다면, 소속 회사도 어떤 에이전트가 우리 서버에 접속했는지 모를 수 있습니다. 에이전트는 사람보다 훨씬 많은 명령을 빠르게 실행하므로, 나중에 기록을 검토하는 것만으로는 작업 내역을 따라가기 어렵습니다.
보안팀은 이제 외부 업체의 AI가 서버에 접속하는 경로와 실행 내역도 파악해야 합니다. Vanta 같은 보안 플랫폼이 외부 업체 보안 설문에 AI 관련 질문을 추가한 것도 같은 흐름입니다. 하지만 설문으로 알 수 있는 것은 업체의 답변까지입니다. 우리 서버에서 실제로 실행된 명령은 별도로 확인해야 합니다(설문에 더할 질문은 AI 벤더 리스크 평가에서 빠진 런타임 질문에서 다뤘습니다). 실행 내역을 확인할 수 없다면, AI 사용을 금지하거나 무엇을 하는지 모르는 채 허용하는 수밖에 없습니다. 금지하면 AI로 작업 속도를 높일 기회를 포기해야 하고, 업체가 금지 방침을 지키는지도 알기 어렵습니다.
사람의 접속을 전제로 만든 세 가지 접근 관리 방식
외부 인력의 접근은 대개 세 가지 방식으로 관리합니다. 모두 사람이 접속하는 상황을 전제로 만들어졌습니다.
업체에 키를 건넵니다. 시스템을 구축할 때 포트를 열고 관리자 계정의 SSH 키를 건네면, 업체 엔지니어는 장애 대응이나 정기 점검 때마다 그 키로 접속합니다. 작업마다 계정을 발급하고 승인을 받기가 번거로운 데다, 맡긴 업체를 신뢰하기 때문입니다. 하지만 관리자 키로 접속하면 로그 하나를 읽을 때도 서버 전체를 바꿀 수 있는 권한을 갖습니다. 거래하는 업체가 늘수록 외부에 나간 키도 늘어납니다. 업체 안에서 키가 공유되거나 담당자가 바뀌어도 우리는 알기 어렵고, 접속 후 실행한 작업도 기록으로 남지 않습니다. 지금 외부 인력 중 누가 우리 서버의 관리자 키를 갖고 있는지 바로 답할 수 있을까요?
작업마다 승인 절차를 거칩니다. 보안 요구가 높은 회사는 업체의 작업계획서를 받아 승인한 뒤, 해당 작업에만 쓸 계정과 VPN을 내줍니다. 금융과 공공 분야에서 특히 일반적인 방식입니다. 보안 인증 기준과 규정도 계정 회수, 원격 접근 승인, 접근 기간 제한, 작업 기록 관리를 강조합니다. 하지만 새벽 2시에 서비스가 멈췄는데 승인이 끝나야 접속할 수 있다면, “이번만”이라는 예외가 생깁니다. 회수하지 않은 임시 계정은 상시 접근 수단이 됩니다. 승인 대기는 그대로 서비스의 장애 시간에 더해지고, 남는 것은 작업계획과 승인 내역뿐입니다. 업체가 실제로 실행한 명령은 따로 기록되지 않습니다.
PAM을 도입합니다. 특권 접근 관리(PAM, Privileged Access Management) 제품으로 이런 절차를 관리합니다. 접속 경로를 한곳으로 모으고, 비밀번호와 키를 보관하며, 접근 시간과 범위를 제한하고 세션을 기록합니다. CyberArk, BeyondTrust, Delinea 같은 전통적인 PAM은 키의 중앙 보관과 자동 교체를 중심으로 발전해 왔습니다. Imprivata처럼 외부 업체 접근에 특화된 제품도 있습니다. Teleport나 StrongDM 같은 모던 PAM은 주로 사내 팀의 접근 관리에 초점을 둡니다. 외부에 건넨 키와 공유 계정의 문제는 이런 제품으로 상당 부분 해결할 수 있습니다. 다만 도입과 운영에 별도 프로젝트가 필요한 경우가 많습니다. 명령을 실행 전에 차단하는 기능도 대개 미리 정한 규칙에 따릅니다. 같은 명령도 작업 목적에 따라 필요할 수도, 위험할 수도 있어 규칙만으로는 그 차이를 판단하기 어렵습니다.
AI 에이전트가 접속하면 세 방식의 한계가 더 커집니다. 에이전트도 건넨 키를 쓸 수 있고, 승인 절차는 쏟아지는 명령의 속도를 따라가지 못합니다. 세션 녹화도 사람이 검토할 수 있는 분량을 넘어섭니다.
사고는 너무 넓거나 오래 유지된 접근 권한에서 커집니다
이런 빈틈은 실제 사고에서도 드러납니다.
미국의 교육 소프트웨어 회사 PowerSchool은 2024년 말 고객 지원 포털 계정 하나를 통해 침해를 당했습니다. 이 포털에는 지원 담당자가 유지보수를 위해 고객사 데이터베이스에 접근하는 기능이 있었고, 당시에는 다중 인증(MFA)도 지원하지 않았습니다. 고객사의 데이터에 접근하는 데 쓰인 것은 공급사의 계정이었습니다.
2026년 4월에는 보안 업체 Huntress가 한 MSP의 원격 지원 도구가 공격에 악용된 사고를 보고했습니다. 공격자는 이 도구의 고권한 계정으로 도메인 컨트롤러에 원격 접속 도구를 설치했습니다. 이 사고로 78개 기업의 시스템이 격리됐고, 이어서 MSP의 고객사 네 곳에서도 공격이 이어졌습니다. Huntress는 이 도구를 노린 일련의 공격이 알려진 취약점을 악용했을 가능성이 높다고 봤습니다.
국내에서는 쿠팡의 퇴사자가 재직 당시 관리하던 인증 시스템의 서명키를 빼내 이용자 정보에 접근했습니다. 2026년 2월 정부 조사 결과에 따르면 유출된 이용자 정보는 3,300만 건이 넘었습니다. 퇴사자가 생겼을 때 키를 바꾸는 체계와 절차가 미비했고, 키 이력을 관리하지 않아 목적 외 사용을 파악할 수 없었습니다. 이는 외부 업체가 아닌 내부 직원의 사례이며, 서버 접속 키와는 종류도 다릅니다. 그래도 사람이 떠난 뒤 키가 남고 그 사용 내역을 추적하기 어렵다는 문제는 외부에 건넨 키에서도 똑같이 생길 수 있습니다.
침입 경로는 달랐지만, 세 사고에는 공통점이 있습니다. 업체의 지원 포털 계정 하나로 고객사 데이터베이스에 접근했고, 업체의 원격 지원 도구 하나가 여러 기업에 영향을 미쳤으며, 퇴사자가 가진 키도 계속 유효했습니다. Verizon의 2026년 데이터 침해 조사 보고서(DBIR)에서도 제3자가 관여한 침해는 전체의 48%로, 전년 30%에서 크게 늘었습니다. 업체의 계정과 도구를 쓰는 주체에 AI 에이전트까지 더해지면, 같은 경로가 더 빠르고 더 넓게 쓰입니다.
사고가 나면 답해야 하는 것은 서버를 소유한 회사입니다. 경영진과 감사인, 규제 기관은 “그 시간에 누가 접속해 있었나요?” “무엇을 실행했나요?” “그 작업은 누가 승인했나요?”라고 묻습니다. 업체가 보내주는 로그와 설명에만 의존하면 원인과 피해 범위를 파악하기 어렵습니다.
서버를 가진 쪽이 던질 질문은 하나입니다
업체의 설문 답변과 설명만으로는 충분하지 않습니다. 우리가 답해야 할 질문은 하나입니다.
“외부 인력에게 작업에 필요한 만큼만 접근을 허용하고, 에이전트의 명령은 작업 목적에 비춰 실행 전에 판단하며, 실제 실행 내역을 직접 볼 수 있습니까?”
이를 위해 다음 다섯 가지가 필요합니다.
- 에이전트의 명령은 실행 전에 작업 목적에 비춰 판단합니다. 같은 명령도 작업 목적에 따라 필요할 수도, 위험할 수도 있습니다. 미리 정한 규칙에 더해 세션에서 밝힌 작업 목적도 판단 기준으로 삼고, 사람이 검토해야 할 명령은 승인 요청으로 넘깁니다.
- AI 에이전트도 사람과 같은 절차로 접근하게 합니다. 업체 엔지니어의 키나 계정을 빌려 쓰지 않고, 정해진 접속 경로와 절차를 따르게 합니다. 그래야 에이전트의 작업도 사람과 같은 승인 절차를 거치고 기록에 남습니다.
- 필요한 만큼만 권한을 주고, 작업 주체에 따라 다르게 점검합니다. 로그를 읽는 데 서버 전체를 바꿀 권한은 필요 없습니다. 모든 명령을 사람이 승인할 필요도 없습니다. 사람의 작업은 승인한 목적과 범위 안으로 제한하고, 에이전트가 보내는 명령은 하나씩 판단하는 방식으로 나눌 수 있습니다.
- 키를 건네지 않고 작업마다 접근을 허용합니다. 업체 엔지니어는 관리자 키를 보유하는 대신 어느 서버에서, 어떤 목적으로, 얼마 동안 일할지 밝히고 해당 작업에 필요한 접근을 받습니다.
- 실행 기록은 우리가 보유합니다. 작업이 끝난 뒤 누가 어떤 목적으로 접속해 무엇을 실행했고 누가 승인했는지, 업체에 묻지 않고도 볼 수 있어야 합니다.
이 절차는 번거롭지 않아야 합니다. 처음에 키를 건넨 것도 작업마다 접근을 허용하기가 번거로웠기 때문입니다. 요청과 승인이 키로 직접 접속하는 것보다 훨씬 불편하면 “이번만”이라는 예외가 다시 생깁니다. 모든 서버에 같은 승인 절차를 적용할 필요는 없습니다. 운영에 미치는 영향이 비교적 작은 서버는 작업 목적을 밝히면 바로 접속하게 하고, 결제나 개인정보를 다루는 중요한 서버는 승인을 거치게 할 수 있습니다.
이 조건을 갖추면 업체의 AI를 막아야 할 이유도 줄어듭니다. 업체가 AI 에이전트를 쓰겠다고 하면 금지할지 고민하는 대신 허용 범위를 정하면 됩니다. 감사에서 외부 인력의 접근을 물으면 우리가 보유한 기록으로 답할 수 있습니다. 보안팀은 모든 작업을 지켜볼 필요 없이 승인 요청과 작업 후 기록을 검토하면 됩니다.
Alpacon은 이 질문에 이렇게 답합니다
Alpacon은 서버에서 일하는 사람과 AI 에이전트를 위한 실행 제어 레이어입니다. 작업마다 접근을 허용하고, Alpacon을 거쳐 실행된 명령을 기록하며, 필요한 순간에는 사람의 승인을 받게 합니다.
- 에이전트의 명령은 실행 전에 규칙과 AI로 판단합니다. 에이전트는 Alpacon Cloud의 API나 MCP(AI 에이전트가 외부 도구를 쓰는 표준 연결 방식)로 명령을 보냅니다. 명령은 먼저 규칙으로 걸러지고, 규칙만으로 판단하기 애매하면 AI가 세션의 작업 목적까지 살펴 다시 판단합니다. 사람이 검토해야 한다고 판단된 명령은 실행 전에 승인 요청으로 넘어갈 수 있습니다. 승인은 명령을 보낸 경로와 분리된 웹 콘솔에서 하며, 워크스페이스에서 켜두면 Slack에서도 할 수 있습니다(Essentials 이상). Alpacon Cloud에서는 에이전트의 CLI나 API 토큰이 자기 요청을 스스로 승인할 수 없습니다.
- 작업마다 세션을 엽니다. 업체 엔지니어나 에이전트는 키를 보유하는 대신 작업마다 세션(작업 목적과 권한 범위를 정해 여는 접속 단위)을 요청하고 신원을 밝힙니다. 세션을 열 때 승인을 받도록 설정하면, 업체가 요청한 세션은 우리 쪽 승인자가 허용해야 열립니다.
- 세션마다 권한의 상한을 정합니다. 기본 설정에서는 작업 도중 범위를 넓히려면 다시 승인을 받아야 합니다. Alpacon이 sudo를 관리하는 서버라면, 엔지니어 개인에게 연결된 서버 계정으로 sudo를 쓸 때마다 세션에서 정한 범위 안인지 확인합니다.
- 실행 기록은 우리가 보유합니다. Alpacon을 거쳐 실행된 명령은 세션 타임라인에 모이고, 세션을 열 때 밝힌 작업 목적도 함께 남습니다. 누가 승인했는지는 워크스페이스 관리자가 볼 수 있는 별도의 승인 이력에 남습니다(Essentials 이상).
- Alpacon을 거치지 않은 접속도 탐지합니다. 외부 접근 탐지를 켜두면, 키로 서버에 직접 SSH 접속한 기록을 찾아 Alpacon을 거치지 않은 접속으로 보여줍니다. 탐지를 켠 뒤부터 로그인으로 들어온 접속만 잡으며, 접속을 막지는 않습니다. 따라서 업체에 이미 건넨 키는 따로 회수해야 합니다.
- 서버로 들어오는 포트를 열지 않아도 됩니다. 서버에 설치하는 Alpacon 구성 요소는 밖으로만 연결하므로 서버로 들어오는 네트워크 포트를 열 필요가 없습니다.
모든 변경 작업을 사람이 하나하나 승인하는 방식은 아닙니다. 명령 단위 판단은 에이전트가 API나 MCP로 서버에서 명령을 실행할 때 적용되며, 그중 승인이 필요하다고 본 명령만 사람에게 넘어옵니다. 엔지니어의 작업은 세션 승인과 권한 범위로 관리합니다. 이 두 가지를 바탕으로 우리가 직접 통제할 범위를 정합니다.
세션 밖에서 실행되는 연동은 별도로 관리해야 합니다. 서비스 토큰으로 실행되는 연동은 세션을 열지 않으므로 세션 승인을 거치지 않고, 토큰 발급 시 관리자가 승인한 권한 목록 안에서 실행됩니다. 업체에 어떤 토큰을 어떤 권한으로 내줄지는 세션과 별개로 정해야 합니다.
통제권을 유지하려면 구성도 중요합니다. 서버와 사용자를 묶어 관리하는 워크스페이스는 우리가 소유하고, 승인 권한은 사내 보안팀과 운영 담당자에게만 줍니다. 업체 계정은 세션 요청에만 사용합니다.
바뀐 뒤에는 이런 그림이 됩니다
새벽 2시, 결제 서비스의 응답이 느려졌다는 알림이 옵니다. 이 서비스의 운영은 외부 업체에 맡기고 있습니다.
기존 방식이라면 업체 엔지니어가 건네받은 키로 접속하거나, 작업계획서를 보내 승인과 계정 발급을 기다립니다. 어느 쪽이든 다음 날 아침 우리가 받는 것은 “조치했습니다”라는 메시지 정도입니다.
새 방식에서도 접근 요청과 승인은 필요합니다. 달라지는 것은 요청과 승인에 드는 수고, 그리고 작업 후 우리가 보유하는 기록입니다.
업체 엔지니어는 작업계획서 대신 ‘결제 서비스 응답 지연 원인 확인’이라는 한 줄로 세션을 요청합니다. 당직 중인 사내 보안팀 담당자는 웹 콘솔에서 요청을 보고 승인합니다. 워크스페이스에서 켜두었다면 Slack에서도 승인할 수 있습니다(Essentials 이상). 승인되면 이 작업에 맞춘 범위로 세션이 열립니다.
업체는 AI 에이전트에게 원인 분석을 맡깁니다. 에이전트도 같은 목적으로 별도 세션을 요청합니다. 기본 설정에서는 에이전트가 요청한 세션도 사람의 승인이 필요하므로 담당자가 이 요청도 검토해 승인합니다. 에이전트가 로그를 읽고 디스크 공간 부족을 찾아내는 동안, 업체 엔지니어는 결과를 검토하며 다음 조치를 정합니다. 에이전트가 오래된 로그를 지우려 할 때 규칙과 AI가 사람의 확인이 필요하다고 판단하면, 그 명령은 실행 전에 사내 담당자에게 승인 요청으로 넘어올 수 있습니다. 담당자는 요청을 확인하고 판단합니다.
다음 날 아침에는 기록이 남아 있습니다. 업체의 누가 어떤 목적으로 접속해 무엇을 실행했는지는 세션 기록에서, 누가 승인했는지는 승인 이력(Essentials 이상)에서 볼 수 있습니다.
이런 신호가 보이면 접근 방식을 다시 볼 때입니다
함께 일하는 업체가 한 곳이고, 접속하는 서버가 적으며, 민감한 데이터를 다루지 않는다면 지금 방식으로도 충분할 수 있습니다. 다음과 같은 상황이라면 외부 인력의 접근 방식을 다시 살펴볼 때입니다.
- 외부 인력 중 누가 우리 서버의 키나 계정을 갖고 있는지 목록으로 답하기 어려울 때
- 업체가 AI 에이전트로 운영을 자동화하겠다고 제안했거나, 이미 사용 중이라는 사실을 알게 됐을 때
- 감사나 규제 대응 과정에서 외부 인력의 접근 승인과 작업 기록을 요구받았을 때
- 장애 후 실행 내역을 요청했지만 업체의 설명만 받았을 때
- 계약을 갱신하거나 새 업체에 결제·개인정보 서버를 맡기게 됐을 때
모든 업체의 접근 방식을 한꺼번에 바꿀 필요는 없습니다. 이런 상황에 해당하는 업체와 서버부터 시작하면 됩니다.
업체의 AI를 막을지보다 실행을 볼 수 있는지가 먼저입니다
외부 업체의 AI 에이전트를 받아들일지는 각 회사가 정할 일입니다. 판단 근거는 우리 서버에서 실제로 실행된 내역이어야 합니다. 업체의 설명에만 의존하지 않고 업체의 사람과 에이전트가 실행한 명령을 직접 볼 수 있다면, AI 사용을 막을지 고민하는 데서 나아가 맡길 범위를 정할 수 있습니다.
