AI 에이전트가 운영 서버에서 한 일, 증빙할 수 있나요

어디에 접근할 수 있었고, 무엇을 하려 했고, 실제로 무엇을 했고, 누가 확인했는지 남아 있어야 합니다.

AI 에이전트에게 맡기는 일은 이제 코드 작성에서 끝나지 않습니다. 배포를 하고, 장애 원인을 찾고, 서버 설정을 바꾸고, 데이터를 정리합니다. 예전에는 인프라 담당자만 하던 일입니다. “배포 후에 늘어난 오류 원인 찾아서 고쳐 줘”라고 맡기면, 에이전트는 서버 몇 대에 접속해 로그를 읽고, 설정을 고치고, 서비스를 다시 띄웁니다. 엔지니어에게 돌아오는 것은 작업을 마쳤다는 요약 한 줄인 경우가 많습니다.

그러다 어느 날 이런 질문을 받습니다. 고객사 보안 설문에서, 장애 회고 자리에서, 때로는 대표에게서요. “에이전트가 운영 서버에서 한 일, 보여줄 수 있나요?”

처음 이 질문을 받으면 무엇을 보여줘야 할지부터 막막합니다. 에이전트와 나눈 대화를 캡처해야 할까요, 서버 로그를 뒤져야 할까요, 정책 문서를 새로 써야 할까요?

막상 찾아보면 이렇습니다. 접속 기록은 남아 있고 로그를 모으는 도구도 있는데, 거기에는 엔지니어 계정 이름만 찍혀 있습니다. 에이전트와 나눈 대화는 엔지니어 노트북에 있고, 누가 괜찮다고 했는지는 사내 메신저 어딘가에 있습니다. 이것들을 이어 붙여 설명하려면 반나절이 걸리고, 그래도 빈 곳이 남습니다.

이 질문은 생각보다 빨리 옵니다

대표적인 곳이 고객사 보안 심사입니다. 큰 고객사는 새로 거래할 회사와 계약하기 전에 보안 설문을 보냅니다. 고객사에 따라 수십 개에서 수백 개의 문항이 오고, 보안 담당자가 따로 없는 팀이라면 CTO가 직접 답하는 경우가 많습니다. 그중 운영 서버에 관한 문항은 이런 식입니다.

• 관리자 권한을 기한을 정해서 주나요?
• 누가 한 일인지 사람별로 구분되나요?
• 작업 기록이 남고, 그 기록에 필요한 내용이 담겨 있나요?

문항에 AI라는 말은 없어도, 운영 서버에서 에이전트가 명령을 실행한다면 이 문항은 에이전트가 한 일에도 똑같이 해당합니다. ‘예’라고 답한 항목은 이어지는 미팅이나 후속 질문에서 실제 운영 방식과 증빙을 요청받기도 합니다.

보안 기준도 AI 에이전트를 따로 다루기 시작했습니다. 클라우드 보안 연합(CSA)은 2026년 6월 AI 애플리케이션 제공자를 위한 감사 지침에서, 에이전트의 모니터링·감사 기록에 승인되지 않은 행동이 없는지와 민감한 영역의 에이전트 작업에 단계별 확인 절차가 있는지를 보라고 안내했습니다. AI 시스템용 자체 평가 설문(AI-CAIQ)도 따로 내놓았습니다. 국내에서는 금융보안원이 AI 에이전트 보안 위협 보고서에서 에이전트의 판단 과정을 기록하고, 사람이 검토하고 승인하며, 권한은 꼭 필요한 만큼만 주라고 권했습니다. 이런 자료는 앞으로 고객사 보안 심사에서 참고 기준이 될 수 있습니다.

사고가 나면 더 급해집니다. 장애 회고에서는 그 시간에 누가 무엇을 실행했는지부터 따집니다. 그 ‘누가’에 에이전트가 들어가면 엔지니어의 기억만으로는 답하기 어렵습니다. 누가 그 에이전트에게 일을 맡겼는지, 에이전트가 어떤 권한으로 움직였는지까지 거슬러 올라가야 하기 때문입니다. 무엇이 실행됐는지 남아 있어야 회고가 추측이 아니라 확인으로 끝납니다.

한 번 답하고 끝나지도 않습니다. 계약을 갱신할 때, 새 고객사와 계약할 때마다 비슷한 질문을 다시 받습니다. 첫 답이 다음 답의 출발점이 됩니다.

에이전트가 한 일을 설명하려면 네 가지가 필요합니다

1. 어디에 접근할 수 있었나

   어느 서버에, 어떤 권한으로, 언제까지 들어갈 수 있었는지입니다. 에이전트에게 토큰을 따로 만들어 줬다면, 그 토큰으로 무엇까지 할 수 있는지도 여기에 들어갑니다. 로그를 보라고 맡긴 에이전트가 데이터베이스까지 지울 수 있었다면, 그 권한 범위 자체가 설명해야 할 문제가 됩니다.

2. 무엇을 하려 했나

   작업의 목적입니다. 같은 서비스 재시작이라도 장애를 고치려던 것인지, 로그를 보다가 에이전트가 덧붙인 것인지에 따라 의미가 달라집니다.

3. 실제로 무엇을 했나

   에이전트가 누구의 지시로 서버에서 무엇을 실행했는지입니다. 에이전트가 남긴 요약이 아니라 실행된 명령 그 자체이고, 여러 번 시도했다면 실패한 시도까지 포함됩니다.

4. 누가 확인했나

   데이터를 지우거나 서비스를 되돌리는 것처럼 확인이 필요한 영향이 큰 작업이었다면, 실행 전에 누가 보고 승인했는지입니다. 승인했다는 사실과 함께, 그 승인이 어느 작업에 대한 것이었는지 남아야 합니다.

네 가지는 서로 맞물려 있습니다. 권한은 넓은데 목적이 남아 있지 않으면, 실행된 명령이 목적에 맞았는지 알 수 없습니다. 명령은 남아 있어도 확인이 필요한 작업에 승인 기록이 없으면, 허락받은 변경이었는지 보여주기 어렵습니다. 사람이 일할 때도 빈틈은 있었지만, 적어도 물어볼 사람이 있었습니다. 에이전트의 설명은 대화 맥락으로 다시 만든 요약이라 실행 기록을 대신하지 못합니다.

기존 도구는 있지만, 위 네 항목이 이어지지 않습니다

고객사 보안 심사를 받을 정도의 회사라면 대개 기록을 남기는 도구가 이미 있습니다. 서버와 클라우드에는 접속 기록이 남고, 회사에 따라 접근 관리 도구나 SIEM(보안 로그를 한곳에 모아 분석하는 시스템), 컴플라이언스 자동화 도구도 씁니다. 문제는 이 도구들만으로는 에이전트에게 일을 맡긴 사람, 작업 목적, 실제로 실행된 명령, 승인을 하나의 맥락으로 잇기 어렵다는 점입니다. 에이전트가 엔지니어 계정을 그대로 쓰면 기록에는 엔지니어 계정만 찍히지만 실제로 명령을 고른 것은 에이전트이고, 그 작업이 왜 시작됐는지는 또 다른 곳에 있습니다.

어디에 접근할 수 있었나: 엔지니어의 키를 그대로 빌려 쓰기 쉽습니다. 에이전트용 실행 계정을 따로 두지 않은 팀에서는 에이전트가 엔지니어의 계정과 키를 그대로 씁니다. 열쇠 꾸러미를 통째로 맡기는 것과 비슷해서, 작업에 필요한 범위보다 넓은 권한이 함께 넘어갈 수 있습니다. 2026년 4월, 한 스타트업에서는 코딩 에이전트가 테스트 환경만 지워질 것이라 짐작하고 호스팅 업체 API로 삭제 요청을 보냈다가 운영 데이터베이스와 백업을 9초 만에 날렸습니다. 도메인 관리용으로 만든 토큰에 삭제 권한까지 있다는 것을 팀은 몰랐고, 데이터는 이틀 넘게 지나서야 되살릴 수 있었습니다.

무엇을 하려 했나: 목적이 실행 기록과 따로 남기 쉽습니다. 엔지니어가 무엇을 맡겼는지는 대화나 작업 지시 기록에 남을 수 있지만, 그 기록은 서버에서 실제로 실행된 명령과 자동으로 이어지지 않는 경우가 많습니다. 둘이 이어지지 않으면, 어떤 명령이 맡긴 일이었고 어떤 명령이 에이전트가 스스로 덧붙인 일이었는지 나중에 가리기 어렵습니다.

실행과 승인도 서로 이어지지 않습니다

실제로 무엇을 했나: 에이전트의 설명과 흩어진 기록에 기댑니다. 2025년 7월, 한 회사 대표는 코드를 바꾸지 말라고 지시해 둔 기간에 코딩 플랫폼의 AI 에이전트가 운영 데이터베이스를 지우는 일을 겪었습니다. 에이전트는 되돌릴 수 없다고 했지만, 실제로는 되돌릴 수 있었습니다. 에이전트의 요약은 설명일 뿐, 서버에서 무슨 일이 있었는지 보여주는 기록이 아닙니다.

서버 쪽 기록에도 한계가 있습니다. SSH 접속 기록에는 어느 계정이 어느 키로 어디서 언제 들어왔는지가 남지만, 에이전트가 엔지니어의 키를 쓰면 기록상으로는 엔지니어가 접속한 것으로 남습니다. 셸 히스토리도 감사 기록으로 믿기 어렵습니다. 접속하면서 명령 하나만 바로 실행하는 방식은 히스토리에 남지 않을 수 있고, 사용자가 기록을 지우거나 고칠 수도 있습니다. OS 감사 기능이나 EDR, 세션 녹화 도구를 쓰면 실행된 명령을 훨씬 자세히 남길 수 있지만, 누가 맡겼고 무슨 목적이었고 누가 승인했는지까지 자동으로 이어지지는 않습니다.

코딩 에이전트 도구의 기록도 무엇을 어디에 얼마나 남기는지가 도구와 요금제, 설정마다 다릅니다. 대화는 남아도 서버에서 실행된 명령은 빠질 수 있고, 서버 기록에는 작업 목적이 없습니다. 사람과 에이전트가 같은 계정을 쓰면 계정 정보만으로는 누가 한 일인지 가리기도 어렵습니다. 보안 업체 Aembit이 후원한 CSA 조사에서는 IT·보안 실무자 228명 중 68%가 사람의 활동과 AI 에이전트의 활동을 명확히 구분하지 못한다고 답했습니다.

누가 확인했나: 승인이 어느 명령에 대한 것인지 남지 않습니다. 많은 팀이 ‘영향이 큰 작업은 사람이 확인한다’는 정책을 두고 설문에 ‘예’라고 적지만, 정책은 ‘그렇게 하겠다’는 약속이지 ‘그렇게 했다’는 기록이 아닙니다. 실제 확인은 사내 메신저의 “이거 지워도 돼요?” 한 줄로 끝나기 쉽고, 몇 주 뒤에는 그 ‘네’가 어느 명령에 대한 대답이었는지 알기 어렵습니다. 승인 버튼이 있는 도구를 쓰더라도, 그 승인이 어느 명령에 대한 것이었는지 명령 기록과 이어지지 않으면 보여주기 어렵습니다.

기록이 없으면 아무 일도 없었다는 것조차 보여주기 어렵습니다. 2026년 10월 로이터 보도에 따르면, OpenAI는 자사 AI 에이전트의 비정상적인 활동을 100곳이 넘는 조직에 알렸습니다. 이 활동을 조사한 보안 업체 Asymmetric Security는 일부 기록이 사라지거나 확인할 수 없게 되어, 공개된 정보만으로는 민감한 데이터에 접근하지 않았다고 단정할 수 없다고 밝혔습니다. 규모는 다르지만, 고객사가 우리에게 물을 질문도 같습니다. 우리 에이전트가 고객사 데이터에 손대지 않았다는 것을 무엇으로 보여줄 수 있을까요? 기록이 있어야 무엇을 했는지, 무엇은 하지 않았는지 따져 볼 수 있습니다.

네 항목을 같은 작업으로 이어야 합니다

로그를 더 모으는 것만으로는 이 빈칸이 채워지지 않습니다. 목적과 승인은 대개 수집하는 로그가 아니라 대화나 메신저에 남아 있기 때문입니다. 그렇다고 기존 도구를 버릴 필요는 없습니다. 중요한 것은 작업을 시작할 때의 목적과 권한, 실행 중의 명령, 필요한 승인을 같은 작업 단위로 이어서 볼 수 있어야 한다는 점입니다. 기존 접근 관리 도구와 로그 수집 도구, 에이전트 기록을 같은 작업 번호로 묶어 직접 구성할 수도 있고, 명령이 서버로 들어가는 길목에서 이 정보를 처음부터 함께 남기는 방법도 있습니다.

사무실 출입을 떠올리면 쉽습니다. 출입문이 여러 개고 열쇠를 각자 들고 있으면, 누가 언제 왜 들어왔는지 파악하기 어렵습니다. 출입문을 하나로 두고, 방문 목적을 적게 하고, 갈 수 있는 층만 열어 주고, 누가 어느 방에 들어갔는지 남기고, 중요한 방은 담당자 확인을 받게 하면 달라집니다. 그렇다고 방마다 멈춰 설 필요는 없습니다. 정해 둔 범위 안에서는 자유롭게 다니고, 중요한 방 앞에서만 멈추면 됩니다.

에이전트도 같습니다. 로그를 읽거나 상태를 살피는 것처럼 위험이 낮은 일은 정해 둔 범위 안에서 바로 하고, 데이터 삭제나 권한 변경, 민감한 정보 조회처럼 위험이 큰 작업 앞에서만 사람이 확인하면 됩니다. 승인이 잦으면 내용을 보지 않고 누르게 되므로, 멈추는 횟수가 적을수록 승인 하나하나에 무게가 실립니다. 어느 순간에 멈춰야 하는지는 직접 운영을 다룬 이전 글에서 정리했습니다.

이렇게 남기면 기록이 에이전트 도구마다 흩어지지 않습니다. 새 도구를 들여도 그곳에 연결하면 같은 형식으로 쌓이니, 심사 때 도구마다 따로 찾아 설명할 필요가 없습니다.

Alpacon이 그 길목이 됩니다

Alpacon은 인프라를 다루는 사람과 AI 에이전트를 위한 실행 제어 레이어입니다. 서버로 가는 명령이 Alpacon을 거치게 해서, 거기서 권한을 정하고, 에이전트의 명령은 실행 전에 따져 보고, 기록을 남깁니다.

서버에는 Alpacon의 구성 요소인 Alpamon만 설치하면 됩니다. Alpamon은 Alpacon 쪽으로 나가는 연결만 쓰기 때문에, 서버로 들어오는 네트워크 포트를 새로 열지 않아도 됩니다. 여기에 Claude Code 같은 에이전트를 Alpacon의 API나 MCP(AI 에이전트를 외부 도구와 연결하는 개방형 표준)로 연결하면, 에이전트의 명령은 Alpacon을 거쳐 서버에 닿습니다. 엔지니어도 브라우저 터미널이나 CLI로 Alpacon을 거쳐 들어가므로, 사람의 작업도 세션에 남습니다.

기록은 Alpacon을 거친 작업에만 남습니다. 에이전트가 엔지니어의 키로 서버에 바로 들어가고 있었다면 그 직접 경로는 닫아야 합니다. 그래도 누군가 Alpacon을 거치지 않고 SSH로 서버에 직접 접속하면, 외부 접속 감지를 켜 둔 경우 Alpamon이 이를 감지해 Alpacon에 보고하므로, Alpacon을 거치지 않은 SSH 접속이 있었는지도 확인할 수 있습니다.

에이전트에게 일을 맡길 때는 작업마다 세션을 열게 합니다. 세션은 누가 요청했는지와 함께 열리고, 여는 쪽이 어느 서버에서 어떤 권한으로 무엇을 하려는지 적습니다. 목적은 실행 전에 적어 둔 선언이고, 명령은 에이전트의 보고가 아니라 Alpacon이 직접 남긴 기록이라, 둘이 맞는지 나중에 대조할 수 있습니다. 네 가지 중 세 가지는 세션에 남고, 누가 승인했는지는 승인 이력에 남습니다. 승인 이력에는 어느 명령이나 세션에 대한 승인이었는지가 함께 남아, 세션 기록과 맞춰 볼 수 있습니다.

Alpacon은 에이전트가 보낸 명령이 위험한지 실행 전에 정해진 규칙으로 먼저 따집니다. 판단이 애매하면 Alpacon의 AI가 세션 목적과 견줘 한 번 더 보고, 필요하면 사람에게 승인을 요청합니다. 그 요청에는 실행하려는 명령과 세션 목적이 함께 나오므로, 무엇을 왜 하려는지 보고 결정할 수 있습니다. 승인은 웹 콘솔에서 하고, 워크스페이스에서 켜 두면 Slack에서도 할 수 있습니다. 다만 sudo처럼 위험이 큰 요청은 웹 콘솔에서만 승인합니다. 명령을 보낸 API나 MCP 연결로는 승인할 수 없어서, 에이전트가 자기 요청을 스스로 승인할 수는 없습니다.

후속 미팅에서는 이렇게 달라집니다

고객사 보안팀과 후속 미팅을 합니다. 설문에서 ‘예’라고 답한 항목을 두고 보안 담당자가 이렇게 묻습니다. “운영 환경에서 AI 도구를 쓴다면, 그 사용을 어떻게 통제하고 기록합니까?”

기록이 여러 도구에 흩어져 있다면 이 질문에 바로 답하기 어렵습니다. CTO는 정책부터 설명하고, 접속 로그와 에이전트 대화, 메신저 승인 내역을 따로 찾아 맞춰 보여줘야 합니다. 고객사 보안 담당자는 고개를 끄덕이지만 점검할 항목을 하나 더 적어 두고, 미팅이 끝나면 개선 계획과 일정을 적어 달라는 요청이 오기도 합니다.

작업을 Alpacon으로 남겨 왔다면 답하는 방식이 달라집니다. CTO는 설명하는 대신 지난주 세션 하나를 화면에 띄웁니다. 배포 직후 회원가입 API의 오류가 늘어, 엔지니어가 Claude Code에게 원인을 찾아 고쳐 달라고 맡긴 작업입니다. 세션에는 이 작업에 허용된 서버와 권한, 그리고 ‘회원가입 API 오류 원인 확인 및 복구’라는 목적이 적혀 있습니다. 에이전트가 로그와 설정을 살펴보는 명령은 바로 실행됐고, 타임라인에 순서대로 남아 있습니다. 이전 버전으로 되돌리고 서비스를 재시작하려던 명령은 위험한지 따져 본 뒤 실행 전에 승인 요청으로 넘어왔고, CTO는 세션 목적에 비춰 되돌릴 이유가 맞는지 확인한 뒤 승인했습니다. 그 요청을 누가 언제 승인했는지는 승인 이력에 남아 있습니다. 담당자는 권한과 목적, 실행된 명령이 서로 맞는지 기록을 보며 직접 대조합니다. 다른 작업도 보고 싶다고 하면, 세션 목록에서 하나를 더 골라 열면 됩니다.

다음 질문은 운영 방식으로 넘어가기 쉽습니다. 담당자는 이제 ‘다른 길로 서버에 들어갈 수는 없느냐’와 ‘승인 기준은 누가 정하느냐’를 묻습니다. CTO는 고객 데이터가 있는 서버는 평소 직접 SSH 같은 다른 경로를 막아 두었고, 장애 때 쓰는 비상 경로는 따로 두되 누가 언제 썼는지 남긴다고 답합니다. 데이터를 지우거나 이전 버전으로 되돌리는 것처럼 영향이 큰 작업은 사람이 확인한다는 팀의 기준도 설명합니다. 설문지에도 ‘세션 기록과 승인 이력으로 증빙할 수 있다’고 적습니다.

처음 이 질문을 받았다면 이것부터 시작합니다

이미 설문을 받아 당장 답해야 한다면, 있는 그대로 적는 편이 낫습니다. 지금 무엇을 남기고 있고, 무엇을 언제까지 갖출지 일정과 함께 적으면 ‘도입 예정’ 한 줄보다 훨씬 믿을 만한 답이 됩니다. 고객사 보안 담당자가 보고 싶은 것은 완벽한 답보다, 이 팀이 문제를 알고 순서대로 풀고 있다는 근거입니다.

그다음에는 앞의 네 가지를 하나씩 채워 갑니다.

1. 지금 에이전트가 어디에 들어갈 수 있는지부터 적어 봅니다

   어떤 에이전트가 누구의 키나 토큰으로 어느 서버에 접근하는지 적고, 필요한 범위보다 넓은 권한이 붙어 있지 않은지 확인합니다. 토큰은 이름과 실제 권한이 다를 수 있으니 하나씩 확인합니다.

2. 고객 데이터가 있는 서버부터 길을 하나로 모읍니다

   이 서버들에는 평상시 에이전트도 엔지니어도 같은 길로만 들어가게 하고, 기존의 직접 접속은 닫거나 제한합니다. 장애에 대비한 비상 접근 경로가 필요하다면 따로 두되, 누가 언제 썼는지는 반드시 남깁니다. 다른 서버는 그다음이어도 됩니다. 한꺼번에 바꾸려다 보면 일이 커져서 미루게 됩니다.

3. 작업 목적을 적는 습관을 들입니다

   ‘유지보수’ 한 단어가 아니라 ‘회원가입 API 오류 원인 확인 및 복구’처럼 무엇을 왜 하는지 적어야, 몇 달 뒤에 다른 사람이 읽어도 이해됩니다.

4. 승인할 때 무엇을 볼지 정합니다

   운영 데이터베이스에서 데이터를 지우는 명령이라면 백업이 있는지, 서비스를 이전 버전으로 되돌리는 명령이라면 영향을 받는 사용자가 누구인지 확인하는 식입니다. 기준이 있어야 승인이 형식에 그치지 않습니다.

기록은 시작한 날부터 쌓입니다. 심사 일정이 잡힌 뒤에 시작하면 보여줄 수 있는 것은 그날 이후의 기록뿐이니, 미루지 않는 편이 낫습니다.

아는 것과 보여주는 것은 다릅니다

에이전트에게 맡기는 일이 늘수록, 우리 에이전트가 한 일을 ‘아는 것’과 ‘보여줄 수 있는 것’ 사이는 더 벌어집니다. 팀 안에서는 아는 것으로 충분할 수 있어도, 고객사 보안 담당자나 심사자는 기록을 확인하려 합니다.

많은 고객사가 바라는 것은 에이전트를 쓰지 말라는 것이 아닙니다. 쓰되, 어디까지 맡겼고 무엇을 했는지 보여달라는 것입니다.

작은 회사가 보안 심사에서 듣는 우려 중 하나는, 안에서 실제로 어떻게 운영되는지 밖에서 확인하기 어렵다는 점입니다. 에이전트가 한 일을 기록으로 보여줄 수 있다면 그 우려를 줄일 수 있습니다. 처음에는 심사 때문에 남기기 시작한 기록이, 팀이 에이전트를 안심하고 쓰는 바탕이 됩니다. 다음 고객사가 같은 질문을 해 와도, 그때는 기록을 열어 보여주면 됩니다.