AI 에이전트로 서비스 운영팀을 꾸리기 전에 준비할 것

“자동수집이 며칠째 멈춘 것 같습니다.”

운영 중인 서비스에서 고객 문의가 왔습니다. 수집 대상의 상태 조건을 바꾼 뒤 대상이 0건이 된 상태였습니다. 내부 모니터링에서는 발견하지 못했고, 고객이 먼저 알려 줬습니다.

코드를 되돌려 수집을 재개했습니다. 하지만 그 작업으로 복구가 끝나지는 않았습니다. 일일 수집은 최근 기간만 조회했기 때문에 중단된 날짜의 데이터를 따로 수집하고, 실패한 건을 다시 처리해야 했습니다.

AI 에이전트가 운영 문서를 읽고 로그를 조회하며 수정안을 만드는 작업 환경을 준비할 수 있습니다. 에이전트에 자료와 실행 도구를 연결하고 권한을 관리하는 하네스를 이용하는 방식입니다.

이 환경으로 서비스를 운영하려면 이런 장애를 다룰 준비가 필요합니다. 코드를 수정할 수 있어도 무엇이 멈췄는지 알아챌 기준이 없으면 문의가 올 때까지 기다리게 됩니다. 수정 뒤 어떤 데이터를 확인해야 하는지도 운영팀이 알고 있어야 하고요.

수집 0건의 의미

당시 변경은 수집 대상에서 특정 상태의 계좌를 제외하려는 작업이었습니다. 코드에서 ‘정상’ 상태만 고르면 될 것 같았지만, 실제 운영 데이터에는 그 상태인 계좌가 없었습니다. 상태 이름만 보고 조건을 좁힌 결과 수집 대상 전체가 빠졌습니다.

이런 변경을 AI에 맡길 때는 코드와 함께 실제 상태별 건수를 확인해야 합니다. 변경 전후 대상이 몇 건인지, 빠지는 항목은 무엇인지 조회 결과를 받고 검토하는 식입니다. 개인정보가 필요 없다면 집계값만 제공해도 됩니다.

운영 점검에도 업무 결과를 넣습니다. 서버가 켜져 있는지에 더해 마지막 수집 시각과 처리 건수를 확인해야 수집 중단을 찾을 수 있습니다. 거래가 없어 정상적으로 0건인 날과, 대상을 잘못 골라 0건인 상황을 구분할 자료도 필요하죠.

복구 문서에는 누락 기간을 채우는 절차를 남깁니다. 다시 실행할 범위, 중복 처리 여부, 완료 후 확인할 값을 적어 두면 다음 담당자가 같은 조사를 반복하는 일을 줄일 수 있습니다.

고객에게 답하기 전

고객 문의를 정리하는 과정에서도 문제가 생겼습니다. 마지막으로 우리가 답한 시각 이후의 코멘트만 골라 ‘미답 문의’를 찾았는데, 그 직전에 도착한 고객 답변이 빠졌습니다. 이미 설명된 내용을 새 이슈로 만들고 조치를 요청했다가 철회했습니다.

이후 절차에 고객에게 연락하기 전 최근 대화를 시간순으로 읽는 단계를 넣었습니다. 자동 분류는 먼저 볼 이슈를 고르는 데 쓰고, 답변 여부는 원문에서 확인하도록 했습니다.

AI에 문의 요약을 맡길 때도 같은 기준을 적용할 수 있습니다. 요약에서 근거가 된 메시지와 시각을 함께 받고, 답변을 보내기 전에 원문을 확인합니다. 추가 확인이 필요한 내용은 초안에 표시하게 하고요.

운영팀의 문의 기록에는 고객 증상과 처리 결과만 남겨도 부족할 수 있습니다. 고객이 이미 확인한 내용, 우리 쪽에서 약속한 조치, 다음 회신을 맡을 사람까지 있어야 인수인계가 됩니다.

점검부터 맡길 범위

기존 쇼핑몰에서는 정합성 점검을 읽기 전용으로 운영했습니다. 주문과 잔액이 맞는지 등을 조회하고, 이상이 보이면 기록을 남겼습니다. 점검 스크립트에는 데이터를 수정하는 명령을 넣지 않았습니다.

점검 결과를 읽는 데도 업무 지식이 필요했습니다. 배송 관련 항목이 점검에 나타났지만, 담당자에게 확인하니 아직 배송하지 않은 정상 상태였습니다. 실제 출고 여부는 시스템 안의 데이터만으로 확정할 수 없었습니다.

그래서 내부 데이터만으로 오류를 확정할 수 있는 항목과 현장 확인이 필요한 항목을 구분했습니다. 모든 항목을 같은 경고로 올리면 담당자가 매번 정상 건을 확인하다가 중요한 알림까지 넘길 수 있으니까요.

처음 AI에 맡길 일로는 이 점검 결과의 정리가 적당합니다. 확정된 오류와 확인이 필요한 건을 나눠 보고하고, 데이터를 고치는 일은 담당자가 판단합니다.

업무	AI에 맡길 작업	담당자 확인
정기 점검	정해진 조회 결과 정리	정상 예외와 현장 상황
고객 문의	최근 대화 요약, 답변 초안	원문과 약속한 조치
장애 조사	로그와 변경 이력 비교	원인 후보의 근거
수정 작업	별도 브랜치에서 수정안 작성	재현 테스트와 변경 영향
인수인계	처리 기록을 바탕으로 문서 초안 작성	빠진 절차와 다음 담당자

공통 작업 기준

운영 기준은 팀이 관리하는 문서에 둡니다. 담당자의 대화에만 남겨 두면 다음 작업에서 빠지기 쉽습니다. 에이전트가 작업을 시작할 때 해당 서비스의 지침과 최근 처리 기록을 읽도록 구성하고, 실제로 참고했는지 확인합니다.

문서에는 바로 실행할 수 있는 내용을 넣습니다. ‘배포 후 확인’이라고만 쓰기보다 어떤 기능을 실행하고 어떤 결과가 나와야 하는지 적습니다. 최근 장애에서 추가한 확인 항목도 그 절차에 반영합니다.

‘운영 데이터 수정 금지’를 지침에 적었다면 계정과 실행 도구의 권한도 함께 제한합니다. 조회용 계정으로 접속하게 하고, 수정 명령을 실행할 수 있는 경로는 승인 절차 뒤에 둡니다.

하네스를 고를 때는 필요한 작업의 실행 범위를 제한할 수 있는지 확인합니다. 배포나 데이터 변경은 별도 절차로 처리하고, 고객에게 보내는 답변도 검토 후 발송하도록 구성합니다. 금지한 작업이 실제로 차단되는지까지 시험해 봅니다.

수정안 검토에는 장애 증상과 바뀐 코드를 함께 준비합니다. 이번 수집 중단처럼 데이터의 실제 상태가 원인에 영향을 준다면 조회 결과도 필요합니다. 에이전트가 제안한 원인을 테스트 환경에서 재현하고, 수정 후 같은 문제가 사라졌는지 확인합니다.

운영 담당자

작은 팀에서는 문의 접수부터 수정까지 한 사람이 맡기도 합니다. 그 사람이 자리를 비웠을 때를 생각하면 준비할 일이 보입니다.

누가 고객에게 진행 상황을 알릴지, 배포를 결정할지 정해 둡니다. 주 담당자가 응답하지 않을 때 연락할 사람도 남깁니다. 야간에 접수된 문의를 언제 확인하는지까지 고객과 맞춰 두면, 담당자가 없는 시간에 대응을 약속하는 일을 피할 수 있습니다.

새 운영 담당자를 뽑는다면 실제 장애 기록으로 업무를 설명해 보세요. 수집이 멈춘 상황에서 무엇을 먼저 확인할지, AI가 제안한 데이터 변경을 그대로 실행해도 될지 함께 살펴봅니다. 모르는 부분을 짚고 필요한 근거를 찾는 과정에서 업무를 맡길 범위가 드러납니다.

인수인계가 끝났는지는 다른 담당자가 문서만 보고 점검해 보면 알 수 있습니다. 로그 위치를 다시 묻거나 복구 후 확인할 값을 찾지 못했다면 그 부분을 보완합니다. AI 도구에 접속할 수 없는 날에도 쓸 수 있도록 기본 점검 명령과 연락처는 남겨 둡니다.

첫 시범 운영

처음부터 모든 문의와 장애를 맡기기보다, 서비스 1개의 일일 점검으로 시작할 수 있습니다. 기존 담당자가 확인한 결과와 AI가 정리한 결과를 비교합니다.

놓친 항목과 잘못 경고한 항목을 기록합니다. 초안이 나온 시간만 재지 말고 자료를 준비하고 담당자가 검토한 시간까지 포함하세요. 도구 사용 비용과 재시도한 내역도 남깁니다.

수정 작업까지 범위를 넓혔다면 개발 환경 검증 후 운영 반영 여부를 결정합니다. 배포 뒤에는 문제가 생겼던 업무를 다시 실행합니다. 수집 장애였다면 수집 재개와 누락 기간의 데이터 보충을 각각 확인해야겠죠.

점검에서 같은 설명을 반복하고 있다면 공통 지침에 반영합니다. 다음 작업에서 그 지침이 쓰였는지 확인하고, 담당자가 여전히 같은 부분을 고치고 있다면 맡긴 범위나 자료를 조정합니다.

최근 문의 기록과 현재 점검표가 있다면 운영팀 구축 준비를 시작할 수 있습니다. 프로젝트 문의로 가장 자주 반복되는 작업을 알려 주세요. 그 기록을 보고 AI에 맡길 범위와 담당자가 확인할 절차를 함께 잡겠습니다.