IT 운영을 위한 AI 에이전트: 내부 티켓, 접근 권한, 모니터링, 문서화

문제

내부 IT 운영은 멈추지 않지만, 이를 처리하는 팀은 멈춥니다. 지원 업계에서 자주 인용되는 Jitbit의 약 1,000개 기업 대상 분석은 2017년 기준 기술자 한 명이 처리하는 평균 티켓 수를 하루 21건으로, 평균 해결 시간을 82시간으로 집계했습니다. 오래된 데이터이며, 저자들 스스로도 현재 목표치가 아닌 과거 기준으로 제시하고 있어 최신 수치가 아닌 대략적인 규모로 받아들여야 합니다.

티켓당 처리 시간에 대해서는, 매니지드 서비스 제공업체인 Endsight가 12개월간 자체 이용자 10,923명을 대상으로 평균 63분이라는 수치를 제시합니다. 제3자 검증을 거치지 않은 단일 기업의 내부 데이터로, 업계 표준이 아니라 하나의 지표로 참고해야 합니다.

가장 확실히 뒷받침되는 사실은 접근 권한 관련입니다. The Hacker News가 전한 Wing Security의 2024년 조사에 따르면, 기업의 63%가 퇴사한 직원이 여전히 조직 데이터에 접근할 수 있는 상태를 방치하고 있으며, 43%는 GitHub나 GitLab의 코드 저장소 접근 권한도 마찬가지입니다. 내부 티켓 큐에서 지연되는 모든 접근 권한 요청이나 회수 요청은, 바로 이런 통계의 후보가 됩니다.

이 처리 지연에는 보안 위험보다 눈에 덜 띄는 두 번째 결과가 있습니다. 바로 티켓 큐 자체가 읽기 힘들어진다는 점입니다. 업무를 막는 접근 권한 문제 같은 긴급한 요청이 지식 베이스에서 이미 열 번 답변된 일상적인 질문과 뒤섞이면, IT팀은 해결만큼이나 분류에도 시간을 씁니다. 이 큐의 상당 부분은 애초에 사람에게 도달할 필요가 없습니다. 이미 존재하는 문서를 읽는 에이전트라면, 티켓이 순서를 기다리기도 전에 흡수할 수 있는 유형의 분류입니다.

에이전트가 하는 일, 단계별로

IT 운영을 전담하는 자율 AI 에이전트는 자체적으로 격리된 환경에서 계속 실행되며, 쉬지 않고 티켓 큐를 감시합니다.

먼저 Jira에 들어오는 각 티켓을 분류합니다. 기존에 알려진 질문인지, 접근 권한 요청인지, 기술 인시던트인지 구분합니다. 이미 문서화된 요청에는 팀의 Notion 지식 베이스에서 찾은 절차를 인용하며 직접 답변합니다. 도구나 저장소에 대한 접근 권한 요청이면, 직접 실행하는 대신 결정에 필요한 모든 정보를 담은 구조화된 티켓을 개설합니다.

모니터링 측면에서는 Datadog에서 올라오는 알림을 감시하고 GitHub에서 확인되는 최근 커밋이나 배포와 연관 짓습니다. 배포 직후 급증한 지연 시간은 단독 인시던트로 처리되지 않습니다. 연관성이 뚜렷하면 기술팀에 유용한 맥락을 담아 문서화된 GitHub 이슈를 개설합니다. 막힌 티켓, 심각한 알림, 대기 중인 접근 권한 요청은 IT팀에 슬랙 알림을 발생시킵니다. 개설한 티켓, 연관 지은 알림, 발송한 메시지 등 모든 행동은 정확한 상태와 함께 에이전트의 타임라인에 기록됩니다.

구체적인 사례로 이 작동 방식을 보여드리겠습니다. 한 직원이 금요일 저녁, 부서 간 협업 프로젝트를 이유로 특정 GitHub 저장소에 대한 접근 권한을 요청하는 티켓을 엽니다. 에이전트는 요청을 분류하고, 요청이 완전한지(대상 저장소, 사유, 희망 기간) 확인한 뒤, 월요일 아침 IT 담당자가 바로 승인할 수 있도록 구조화된 티켓을 준비합니다. 누군가 우연히 발견할 때까지 일반 큐에 방치되는 대신입니다.

활용되는 인테그레이션

Jira는 내부 티켓의 기준 큐로 남습니다. 에이전트는 여기서 요청을 검색하고(search_issues), 상세 내용을 조회하며(get_issue), 그랜트가 허용하는 행동 범위 안에서 새 구조화 이슈를 만들 수 있습니다.

GitHub는 기술 알림을 코드 변경과 연관 짓는 데 쓰입니다. 최근 커밋 목록(list_commits), 풀 리퀘스트 상세(get_pull_request), 그리고 연관성이 확인되면 문서화된 이슈 생성(create_issue)까지입니다.

Datadog은 모니터링의 원본 신호를 제공하며, 에이전트는 모니터링 도구 자체를 대체하지 않고 이를 조회할 뿐입니다. Notion은 에이전트가 답변 전에 참고하는 절차와 런북을 담고, Slack은 IT팀에 실시간 알림을 전달합니다.

사람이 맡는 부분

에이전트는 준비하고 알릴 뿐, 자신의 판단으로 접근 권한이나 인프라를 변경하는 일은 절대 없습니다. 접근 권한을 실제로 부여하거나 회수하는 일은 여전히 사람의 몫입니다. 에이전트가 Jira에 문서화된 요청을 개설하면, IT 담당자가 이를 실행하고 종료합니다.

식별 가능한 최근 배포와 연결되지 않는 애매한 알림의 실제 심각도는, 슬랙 알림 이상으로 에스컬레이션되기 전에 사람이 판단합니다. 코드나 인프라 수정을 결정하고 적용하는 일은, 당연히 엔지니어의 몫으로 남습니다. 그리고 모든 아타코 에이전트와 마찬가지로, 관리자는 Jira, GitHub, Datadog에 대한 그랜트를 행동 단위로 부여하고 조정해야 하며, 읽기 전용 또는 읽기·쓰기 범위를 명시적으로 정해야 합니다.

이 한계는 에이전트 자신에게도 적용됩니다. 업무 맥락이 다루지 않는 상황, 즉 이례적인 라이선스 갱신이나 문서화되지 않은 시스템에 대한 접근 권한 요청을 만나면, 에이전트는 근사한 답을 억지로 만들어내지 않습니다. IT팀에 알리고 사람이 처리하도록 티켓을 열어둔 채, 자신의 지식 베이스에 존재하지 않는 절차를 추측하지 않습니다.

측정 가능한 결과

가장 직접적인 이점은 티켓이나 알림이 발생한 시점과 첫 처리 사이의 공백 시간이 줄어든다는 것입니다. 24시간 내내 실행되는 에이전트는 일요일 저녁에 열린 티켓을 분류하고 해당 접근 권한 요청을 준비해 두어, 월요일 팀이 출근하기 전까지 요청을 큐에서 대기시키지 않을 수 있습니다.

두 번째 이점은 Wing Security가 지적한 문제와 직접 연결됩니다. 퇴사가 확인되는 즉시 회수 티켓 개설을 체계화함으로써, 에이전트는 촉발 이벤트와 IT의 조치 사이의 지연을 줄이고, 앞서 언급한 조사에 따르면 감시 없이는 몇 주에서 몇 달까지 늘어날 수 있는, 불필요하게 활성 상태로 남는 접근 권한의 위험 구간을 제한합니다.

개설된 모든 티켓, 연관 지은 모든 알림, 발송한 모든 메시지는 아타코의 감사 로그에서 계속 조회할 수 있으며, IT팀을 위해 5만 행까지 CSV로 내보낼 수 있습니다. 이 완전한 추적성은 내부 보안 감사도 수월하게 만듭니다. 누가 언제 접근 권한을 요청했는지, 어떤 근거로 요청이 문서화됐는지를 여러 도구에서 시간순으로 다시 짜맞출 필요가 없습니다.

IT 에이전트는 슬롯당 월 20유로인 스탠다드 요금제에 속하며, 모델 호출을 처리할 월 1,000크레딧이 포함되어 있습니다. 처리한 티켓 수나 에이전트와 상호작용하는 직원 수는 이 가격에 아무 영향을 주지 않습니다. 동시에 활성 상태인 에이전트 수만 중요합니다. 그래서 규모가 작은 IT팀도 하나의 에이전트만으로 사내 티켓, 모니터링 알림, 접근 권한 요청 전체를 처리할 수 있으며, 각 흐름을 따로 처리하려고 슬롯을 늘릴 필요가 없어, 에이전트의 범위가 몇 달에 걸쳐 새로운 도구나 새로운 내부 팀으로 점차 확대되더라도 비용을 예측 가능하게 유지할 수 있습니다.