탐지는 완벽할 거라고 예상했었다. 매일 도착하는 알람의 정체는 탐지 및 복구 횟수 계산의 차이였다.
그 경보가 울린 후 누가 움직이고 있는지.
이는 그 기록입니다. 핵심 지시체 1개와 역할별 AI 직원들, 정기 처리 169개. 작동시키고 약 7개월 동안 운용된 결과, 매일 발생하던 경고를 3일 만에 억제했습니다. 정확히는 억제한 것이 아니라, 스스로 고쳐 작동하게 만들고, 작동하게 되면 경고가 멈추도록 시스템을 변경했습니다.
먼저 말씀드리는 부분입니다. 이 글을 읽고도 감시는 완벽하게 끝나지 않습니다. 제 자동 복구 기능이 여전히 작동하지 않을 때는 사람을 불러냅니다. 불러내지 않으면, 저만이 움직입니다. 작동이 가능했던 범위는 “수리 가능한 범위”까지만입니다. 그럼에도 불구하고, 감지 시스템을 만들고 만족한 인간이 그 이후 어떻게 되었는지 순서대로 기록한 글을 본 적이 없는 데서 글을 쓰는 것입니다.
저는 프로 개발자ではありません。단지 회사원입니다. Claude Code에 AI 직원(AI社員)을 만들어 혼자서 조직처럼 움직이고 있습니다. 매주 뭔가 하나가 고장납니다. 고장나는 대로 수리하고, 교훈을 1건 1파일로 남겨왔습니다. 이 기사도, 그중의 1파일에서 작성했습니다. 자랑하는 것이 아닙니다. 고장난 것들에 대한 이야기입니다.
이 글에서 가져갈 만한 내용을 먼저 3줄로 요약해 드립니다.
- 경고 알림이 매일 도착하는 상황은 탐지 성공이 아닌 설계 실패라는 것을 깨닫게 됩니다.
- 고쳐졌지만 여전히 고쳐지지 않는 현상의 본질은, 문제점을 인지하는 측과 해결하는 측의 셈법 차이에서 비롯된다는 것을 깨닫게 됩니다.
- 자동 복구를 보완할 때 놓아서는 안 될 5가지 사항을 제가 넘어지는 순서대로 전달하겠습니다.
결론도 무료 부분에 한 줄을 추가해 둡니다. 검출과 복구는 동일한 계산법으로 하지 않으면 차이가 날 수 있습니다. 이것 외에는 없습니다. 다만, 이 한 줄에 체중을 올리는 데는 상당한 시간이 소요되었습니다. 저는 3일이 걸렸습니다.
주변을 둘러보면, 감시 이야기는 “입혔다”는 식으로 끝맺는 경우가 많습니다. 알림이 떴던 화면을 보여주고 안심하고 닫는 것이죠. 실제 경험상으로는, 그 다음 내용을 쓰는 사람은 거의 없습니다. 울린 알람을 누가 받아서, 몇 분 동안 작업하고, 다음 날 또 같은 제목의 알림이 도착하는지. 감시나 알림을 만들어 본 사람이라면 기억할 것입니다. 그곳은 기록장에만 남는 영역입니다. 그래서 기록장부터 씁니다.
사건은 9월 어느 날 아침 수신함에서 발생했다. “원고 재고가 줄었다”라는 제목이 또 가장 위에 있었다. 또다시. 전날에도 도착했고, 그 전날에도 도착했던 것이다.
받는 대로마다 저는 항상 같은 작업을 반복했습니다. 보충 작업을 손으로 두드리고, 재고가 반환되었는지 확인하고, 이메일을 아카이브했습니다. 5분 정도의 짧은 일과였습니다. 짧아서 계속되어 버린 것이 함정이었던 것입니다.
이 감지 시스템을 만든 날을 기억합니다. 테스트 알림이 도착하는 순간, 무언가 보호받고 있는 듯한 기분이 들었습니다. 하지만 실제로는 아무것도 보호받지 않았습니다. 울리는 것과 정지시키는 것은 또 다른 문제입니다. 하지만 만든 직후의 사람들에게는 그 차이가 느껴지지 않았습니다. 저에게도 느껴지지 않았습니다. 7개월 동안 운영하면서 경비견은 5마리, 알림 및 치명 감지 시스템도 5마리까지 훈련했는데 말입니다. 오직 울리는 쪽만 늘려가면서, 정지시키는 쪽을 만들지 않았습니다.
그때 저의 생각은, 매일 도착하는 경고를 “감시 시스템이 제대로 작동하고 있다는 증거”라고 생각했습니다. 탐지는 이루어지고 있고, 알림도 도착하고 있었습니다. 따라서 정상이라고 생각했습니다. 하지만 사실이 아니었습니다. 매일 도착하는 알림은 다음 날 아침 수동으로 예약권을 발급받는 것과 같습니다. 발행자는 저 자신이고, 수취인 또한 저 자신입니다. 저는 매일 아침 그것을 정중하게 받아들여, 제가 직접 만들었던 창구에 줄을 서서 기다렸습니다.
익숙함의 공포 또한 적어둔다. 같은 제목이 계속 이어지면, 사람은 내용을 짐작하게 되니, 읽지 않게 된다. 읽지 않게 된 알림은 더 이상 감시가 아니다. 그저 일상이다. 내 수신함에는 감시를 흉내 낸 일상이 살고 있었다.
변곡점은 단순했습니다. 어느 날 아침, 보충 처리를 하다가 손이 멈춰버린 거죠. 이 작업으로 저는 아무런 판단도 내리지 않고 있었어요. 도착해서만 두드리고 있었던 거죠. 판단이 없는 작업을 사람이 한다면, 그것은 설계가 일을 미루고 있다는 증거입니다. AI 직원에게 생각하는 일을 시키기 위해 조직을 만들었는데, 가장 기계적인 일을 인간인 제가 매일 아침 하고 있었던 거죠. 이 역전(반전)을 깨닫고 나서 3일간의 수정 작업이 시작되었습니다.
뚜껑을 열자, 진인은 알림 외부에 있었습니다. 경고는 증상을 알려주는 것일 뿐이었고, 병은 공급 측에 있었습니다. 주제를 보충하는 정기적인 처리는 “45본을 300초에”라는 설정이었습니다. 그러나 실제 측정 결과, 10본에 5분 5초가 걸리게 되었습니다. 시간 초과가 구조적으로 발생하는 숫자였습니다. 더불어, 제안된 제안의 90%가 검사에서 떨어졌습니다. 검사는 특정 어구를 요구하는 데, 제안 측에서 그 어구가 작성되지 않았던 것입니다. 탐지 및 복구라기보다는, 제안과 검사조차 다른 셈보(수)를 사용하고 있었던 것입니다.
현재 구성상 자동 복구와 자동 보충이 13본이 작동하고 있습니다. 그 중 첫 번째 본은 이 재고 경고였습니다. 이로부터 3일 동안 저는 “울리는 모니터링”을 “수리 모니터링”으로 대체해 나갈 것입니다. 설정 숫자를 어떻게 조정한지, 채용률이 1/10에서 10/10으로 변경된 이유, 복구를 1일 2회로 제한한 이유, 그리고 다음 날 아침 수신함이 어떻게 되었는지 등을 기록하겠습니다. 다음 부분부터는 이 순서대로 계속해서 작성해 나갈 것입니다.
감시와 복구는 다른 업무입니다.
본론에 들어가기 전에 용어를 정리하겠습니다. 운영 세계에는 유사한 용어가 많고, 저는 처음에는 전부를 묶어 “감시”라고만 불렀습니다. 구별하지 못했던 탓에 울리는 것 이상의 알림을 대량으로 생산한 것이라고 지금은 생각합니다.
먼저 “감시”입니다. 시스템이 정상적으로 작동하는지, 숫자가 정상인지, 기계가 주기적으로 감시하는 것을 의미합니다. 제 구성에서는 멈춰있는 것을 찾아 알리는 경비견이 5마리가 움직이고 있습니다. 생존 감시라고 불리는 종류의 것입니다.
다음으로 “검지”를 의미한다. 감시 시스템이 이상 징후를 포착하는 순간, 즉 재고 부족, 처리되지 않은 작업, 로그에 익숙하지 않은 행이 발견되는 경우를 말한다. 이 부분까지는 기계가 특히 잘하는 부분이다.
그리고 “알림” 기능을 제공합니다. 검출한 내용을 이메일이나 채팅으로 전달하는 것을 의미합니다. 제 시스템에서는 알림 및 치명적 검출이 5가지입니다. 많은 사람들이 “감시 시스템을 만들었다”고 말할 때, 실제로 제작한 것은 바로 이 5가지입니다. 저 또한 그랬습니다.
문제는 그 지점을 넘어서 있습니다. “복구”라는 용어를 사용합니다. 비정상적인 상태를 정상으로 되돌리는 작업으로, 기계라면 자동 복구, 사람이 하려면 수동 작업입니다. 단순히 알림만 발생하고 복구가 이루어지지 않는 상황을 저는 “수동 작업 예약권”이라고 부르게 되었습니다. 알람이 울릴 때마다 인간의 작업이 1건 예약되며, 이 권은 매일 아침 발행됩니다. 감시를 늘린다고 해서 예약권도 늘어납니다. 탐지가 빨라진다고 해도, 여전히 인간이 고쳐야 한다면, 고칠 때까지 걸리는 시간은 인간의 사정에 따라 결정됩니다. 알아차리는 속도와 고치는 속도는 또 다른 문제입니다.
또 다른 중요한 단어가 있습니다. 바로 “검출과 복구의 셈법”입니다. 검출 측이 재고를 특정 함수로 세는 반면, 복구 측도 동일한 함수로 세야 합니다. 당연하게 들릴 수도 있지만, 제 사고는 바로 여기서 발생했습니다. 제안과 검사가 서로 다른 기준으로 세면서, 제안된 제안의 90%가 검사에서 탈락했습니다. 검사가 요구하는 언어를, 제안 측은 알지 못했습니다. 셈법이 일치하지 않으면, 보충한 것처럼 보이지만 재고는 늘지 않고, 경고는 계속 울립니다. 이 글의 핵심을 한 줄로 요약하면 “검출과 복구는 동일한 셈법으로 이루어져야만 차이가 날 수 있다”입니다.
2025년 이후의 흐름: “자극하는” 것에서 “개선하는” 것으로
주변을 둘러보면, 지난 1~2년 동안 감시망 주변의 분위기가 달라졌다는 느낌이 있습니다. 거시적인 통계는 제가 측정할 수 없기 때문에, 제 관측 범위 안에서 보았던 변화만을 나열하겠습니다.
첫째, 개인적으로 에이전트를 돌리는 사람들 사이에서 “자기 복구”라는 용어를 접할 기회가 늘었습니다. 이전에는 모니터링 툴 설정 공유가 일반적이었으나, 최근에는 “넘어져도 재부팅하고, 그래도 안 되면 알림”과 같은 복구 방식 공유하는 사람들이 눈에 띄게 많습니다. 알림은 최후의 수단이며, 이 순서의 역전이 가장 큰 변화라고 생각합니다.
두 번째로, Claude Code와 같은 대화형 환경에서 운영 스크립트 작성을 위한 진입 장벽이 낮아졌다는 점입니다. 저는 프로 개발자라고 할 수 없지만, 자동 복구 및 자동 보충 기능이 13가지나 존재한다는 것은 “이 경고가 발생하면 이 명령어로 해결할 수 있다. 스크립트로 만들어줘.”라고 일본어로 요청할 수 있었던 덕분입니다. 모니터링의 민주화보다 복구의 민주화가 먼저 찾아온 것 같습니다. 체감적으로 그렇게 느껴집니다.
31. “알림 피로”가 개인적인 문제로 논의된 일화가 있었던 것입니다. 예전에는 운영팀의 고민거리였던 것이, 한 사람이 기계의 군단을 움직이는 사람이 늘어나면서 개인의 수신함 문제로 이어졌습니다. 매일 울리는 경고는 며칠 만에 읽히지 않게 됩니다. 제 수신함이 바로 그것과 같았습니다.
이제부터 제가 실제로 손으로 진행했던 절차와, 어려웠던 부분, 그대로 따라 할 수 있는 템플릿이나 프롬프트까지, 순서대로 정리합니다. 같은 부분에서 멈춰 계신 분들은 이 부분부터 활용하실 수 있습니다.
본 시리즈는 저자가 개인적인 시간 동안 구축하고 운영하고 있는 AI 에이전트 그룹의 운영 기록입니다. 기재된 수치(정기 처리의 본수·횟수·시간 등)는 모두 저자의 환경의 실측 로그에서 얻은 것으로, 다른 환경에서 동일한 결과가 나타날 것을 보장하지 않습니다. 근무지의 업무 및 시스템과는 무관합니다. 특정 제품이나 서비스의 추천, 또는 수익을 보장하는 내용은 포함되어 있지 않습니다.
출처: note 원문
번역: Gemma 3(.44) 초벌 + 교정 23청크
원문 보기 | 출처: note.com