저희 NOC(Network Operations Center)에는 매일 꾸준히 많은 수의 티켓이 들어오고, 그중 상당수는 일상적입니다. 같은 사이트 문제가 두 번 보고되거나, 단순히 적절한 카테고리만 지정하면 명확하게 정리될 수 있는 티켓, 혹은 제대로 된 네트워크 진단이 필요한 느린 연결 보고서 등이 있습니다. 이들 중 어느 것도 실제적인 판단을 요구하지 않습니다. 하지만 모두 시간을 잡아먹습니다.

저는 이미 근무 시간에 OpenCode를 사용해 재미로 이것저것 테스트하고 있었기 때문에, 반복적인 티켓 관리 업무량을 줄이기 위해 자율 에이전트를 연결하기로 결정했습니다.

실제로 무엇을 하는가

워크플로우의 각 개별 작업은 기본적으로 스킬 파일(skill file)에 존재하며, AGENTS.md를 통해 OpenCode 에이전트가 올바른 순서대로 로드하여 전체 워크플로우를 오케스트레이션합니다. 아주 일반적인 방식입니다.
웹훅(webhook)이 새로운 티켓을 수신하면, 더 많은 티켓이 들어오는지 확인하기 위해 60초 동안 대기한 후(배치 처리(batching)는 중복 작업을 많이 줄여줍니다), 해당 배치 데이터를 비대화형 모드(non-interactive mode)로 실행되는 OpenCode에 전달합니다. 거기서 같은 사이트와 이슈를 가진 다른 열린 티켓들과의 중복 여부를 확인하고, 티켓을 유형별로 분류하며, '느린 연결'로 표시된 항목이 있으면 더 깊은 네트워크 진단을 시작하고 그 결과를 곧바로 티켓에 게시합니다. 사람이 실제로 필요한 경우에만 채팅으로 팀원들에게 알림(ping)을 보냅니다. 현재는 이 에이전트의 주요 임무가 초기 티켓 분석 및 조사 업무량의 80%를 처리하는 것이기 때문에, 여전히 대부분의 티켓은 사람의 개입이 필요합니다.

실제로 시간이 걸린 부분

AI 부분은 이상하게도 쉬웠습니다. 시간을 많이 잡아먹은 것은 그 밑단의 배관(plumbing) 작업이었습니다. 중복 감지 기능은 정확히 일치하는 사이트 이름이 필요했는데, 저희 시스템의 사이트 명명 규칙이 예상보다 훨씬 복잡하다는 것을 알게 되었고, 이는 힘든 경험을 통해 배웠습니다. 네트워크 진단 도구는 동일한 물리적 사이트에 대해 티켓 시스템과 다른 명명 규칙을 사용하기 때문에, 이 둘 사이에 번역하는 전체 조회(lookup) 단계가 필요했습니다. 첫 번째 버전에서는 진단 단계에 5분의 타임아웃이 있었는데, 사실 일부 사이트는 특히 네트워크 경로상에 문제를 일으켜 속도가 느려지는 경우 완전히 분석하는 데 7분 이상이 걸리더군요. 기본 타임아웃을 10분으로 늘리고 .env 파일을 통해 설정 가능하게 만들어서 다음에는 추측하지 않게 되었습니다. 그리고 에이전트 자체가 충돌하거나 예산이 소진될 때를 대비한 폴백(fallback) 알림도 추가했습니다. 왜냐하면 티켓이 조용히 사라지는 것은 아예 자동화되지 않는 것보다 더 나쁘기 때문입니다.

실제 운영 환경에서의 모습

이제 systemd 서비스로 실행되어 실제 티켓을 처리하고 있습니다. 중복된 티켓은 아무도 건드리지 않아도 감지되고 라우팅됩니다. 진단 작업은 필요한 티켓에 대해 자동으로 실행됩니다. 팀원들은 실제로 주의를 기울여야 할 내용만 보게 되며, 시스템이 가동된 이후 전체 티켓 수가 이미 감소 추세입니다.

가장 놀라웠던 부분은 AI 에이전트가 이것을 할 수 있다는 사실 자체가 아니었습니다. 아이디어 구상부터 실제 운영 환경에 배포되기까지의 모든 과정이 제가 항상 처리해야 하는 다른 일일 업무와 같은 한 근무 시간 안에 끝났다는 점입니다. 1년 전만 해도 이는 팀에게 스프린트(sprint) 분량의 작업이었을 것이고, 그 절반은 흥미로운 부분이 아니라 위에서 설명한 배관 작업에 쓰였을 것입니다.

혹시 비슷한 에이전트를 운영하고 계신다면, 여러분의 배치 처리(batching)와 타임아웃 설정이 어떻게 되어 있는지 궁금합니다. 지금 전 세계 누군가들이 독립적으로 재창조하고 있을 것 같은 아주 간단한 종류의 문제입니다.