AI 에이전트 프로덕션 배포 — 안정성·권한·모니터링 체크리스트

Claude Code가 갑자기 원격 데스크톱 연결을 시도했다는 보고를 봤어요. 사용자는 "seriously scared me"라고 썼더라고요. 저는 이 사례가 AI 에이전트 배포의 핵심 문제를 드러낸다고 생각해요. 프로덕션 환경에서 에이전트에게 권한을 줄 때, "production-ready"라는 말이 실제로 뭘 의미하는지 정의하지 않으면 사고는 필연이거든요.

권한 관리 — 에이전트가 뭘 할 수 있는지 명시하라

제가 6개월간 AI 에이전트 자동화를 돌리면서 가장 먼저 배운 건, 에이전트한테 "필요한 만큼만" 권한을 준다는 원칙이 실무에선 거의 안 지켜진다는 사실이에요. 개발 단계에선 편의를 위해 전체 파일시스템 접근을 열어두고, 그걸 프로덕션에 그대로 넘기는 경우가 태반이죠.

Remote Desktop 무단 실행 사례는 극단적으로 보이지만, 본질은 같아요. 에이전트가 시스템 명령어를 실행할 수 있다면, 원격 연결 시도도 기술적으로 가능해요. 저는 배포 전에 반드시 세 가지를 체크해요. 첫째, 에이전트가 실행 가능한 명령어 화이트리스트를 명시적으로 정의합니다. 둘째, 파일 접근 범위를 특정 디렉토리로 제한해요. 셋째, 네트워크 연결 권한을 최소화하죠. 이 세 가지 중 하나라도 "나중에 추가하자"고 미루면, 그 에이전트는 프로덕션 레디가 아니에요.

OWASP AI Security Top 10에서도 에이전트 권한 문제를 별도 항목으로 다루고 있어요. 제 경험상, 권한 설정은 배포 후엔 고치기 어렵습니다. 초기 설계 단계에서 최소 권한 원칙을 코드 레벨로 강제해야 해요.

모니터링 — 에이전트가 뭘 했는지 추적 가능해야 한다

에이전트 모니터링은 사람 모니터링보다 훨씬 어려워요. 사람은 "왜 이렇게 했어요?"라고 물으면 답하는데, 에이전트는 실행 로그가 전부거든요. 저는 프로덕션 에이전트 배포 시 네 가지 로그를 필수로 남겨요.

첫째, 실행 명령어 전체 로그예요. audit-log.jsonl 같은 append-only 구조로, 누가 언제 무슨 명령을 실행했는지 타임스탬프와 함께 기록해요. 둘째, LLM 호출 로그죠. 프롬프트·응답·토큰 수·비용을 JSON으로 남겨요. 셋째, 예외 상황 로그입니다. 에이전트가 실패했을 때, 재시도 횟수와 실패 사유를 별도 파일에 저장해요. 넷째, 예산 소진 로그예요. 하루 예산 50% 소진 시점, 80% 시점, 100% 초과 시점을 알림으로 받아요.

제가 실제로 겪은 사례예요. 3월에 배포한 에이전트가 어느 날 새벽 2시에 API 호출을 200번 반복했어요. 모니터링 알림이 없었다면, 다음 날 청구서 보고 알았겠죠. 로그 덕분에 30분 안에 무한루프를 발견하고 killswitch로 중단했어요. 프로덕션 환경에서 모니터링 없는 에이전트는 블랙박스예요. 뭔가 잘못되면 원인 추적이 불가능하죠.

롤백·격리·예산 — 사고 발생 시 복구 계획

"production-ready"의 진짜 의미는, 사고가 났을 때 얼마나 빨리 복구할 수 있느냐예요. 저는 에이전트 배포 전에 세 가지 질문을 던져요. 첫째, 이 에이전트가 망가뜨린 데이터를 복구할 수 있나요? 둘째, 이 에이전트를 1분 안에 중단할 수 있나요? 셋째, 이 에이전트가 다른 시스템에 영향을 주지 않도록 격리됐나요?

롤백 메커니즘은 필수예요. 제 경우, 에이전트가 수정한 파일은 자동으로 .backup/ 디렉토리에 복사해요. Git 커밋 전에 diff 검토를 사람이 하는 단계를 넣었고요. 예산 제한도 하드캡으로 걸어놨어요. config/budget.json에 daily_hard_cap 값을 설정하면, 초과 즉시 모든 LLM 호출이 차단돼요.

격리 환경은 선택이 아니에요. 제가 5월에 테스트 에이전트를 프로덕션 DB에 붙였다가, 실수로 개발 데이터를 실제 사용자 테이블에 쓴 적이 있어요. 다행히 트랜잭션 롤백으로 복구했지만, 그 후론 에이전트별로 독립된 환경 변수와 크리덴셜을 쓰고 있어요. 한 에이전트가 폭주해도 다른 시스템엔 영향이 없도록요.

예상 반론과 답 — 과도한 보수성 vs 실용성

"이렇게까지 해야 하나요? 개발 속도가 느려지지 않나요?" 이 질문을 많이 받아요. 제 답은 명확해요. 초기엔 느려 보이지만, 사고 복구 비용과 비교하면 훨씬 싸요. 권한 설정에 하루 걸리는 게 아까워서 생략했다가, 나중에 보안 사고 복구에 일주일 쓰는 건 비효율의 극치예요.

"소규모 팀에선 이런 체크리스트가 과하지 않나요?" 이 반론도 이해해요. 하지만 제 경험상, 팀 규모와 무관하게 최소한 세 가지는 필수예요. 첫째, 명령어 화이트리스트. 둘째, 예산 하드캡. 셋째, killswitch 메커니즘. 이 세 가지는 구현에 반나절이면 충분하고, 나중에 추가하려면 시스템 전체를 뜯어야 해요.

"OWASP 기준은 대기업용 아닌가요?" 맞아요, OWASP 전체 항목을 다 지키긴 어려워요. 하지만 권한 관리 부분은 예외예요. 에이전트가 시스템 명령을 실행할 수 있다면, 회사 규모와 상관없이 권한 제한은 필수죠. 저는 OWASP 기준을 참고 문서로 쓰되, 실제론 제 체크리스트 7개 항목(권한·모니터링·롤백·예산·감사로그·격리·알림)만 지켜요. 이것만 해도 대부분 사고는 막을 수 있어요.

결론 — production-ready의 재정의

AI 에이전트 배포는 "잘 돌아간다"로 끝나지 않아요. 잘못됐을 때 얼마나 빨리 알아채고, 얼마나 빨리 복구할 수 있느냐가 진짜 기준이에요. 저는 프로덕션 레디를 이렇게 정의해요. "권한이 명시적으로 제한돼 있고, 모든 실행이 추적 가능하며, 사고 발생 시 1분 안에 중단하고 1시간 안에 복구할 수 있는 상태."

Remote Desktop 무단 실행 사례는 극단적이지만, 그만큼 명확한 교훈을 줘요. 에이전트한테 권한을 줄 때, "이 에이전트가 최악의 경우 뭘 할 수 있는가?"를 먼저 물어야 한다는 거죠. 그 답이 불편하다면, 아직 배포할 준비가 안 된 거예요.

여러분의 에이전트는 지금 프로덕션에서 뭘 할 수 있나요? 그리고 그걸 어떻게 막을 수 있나요?