어떤 시스템을 점검했나 — 자동 답글 봇의 다섯 가지 안전장치
SGK 스튜디오는 스레드(Threads)에서 다른 계정의 게시물에 자동으로 댓글을 남기는 봇을 운영합니다. 사람이 매번 글을 찾아 답글을 다는 대신, 정해진 시각마다 스스로 후보 게시물을 고르고 검사를 거쳐 댓글을 보냅니다. 이 봇에는 스팸으로 오인받지 않도록 안전장치 다섯 가지가 걸려 있습니다 — 발송 전 원래 게시물과 내용을 대조하는 검사, 하루에 보낼 수 있는 발송 건수를 제한하는 상한, 접근할 수 없는 계정을 걸러내는 목록, 반응(좋아요·답글 수)을 매일 수집하는 예약 작업, 그리고 위험 신호가 보이면 이미 보낸 댓글을 회수 대상으로 표시하는 규칙입니다.
다섯 가지는 한 번 만들면 끝나는 장치가 아닙니다. 코드가 바뀌고 운영 방식이 바뀌면서 장치가 원래 의도대로 계속 작동하는지 주기적으로 다시 확인해야 합니다. 8월 27일, 다섯 가지를 전부 다시 확인하자는 점검 항목이 만들어졌습니다. 그런데 이 점검은 곧바로 시작되지 않았습니다.
이런 점검이 만들어지는 배경도 짚어 둘 만합니다. 자동화 봇은 사람이 매번 눈으로 확인하지 않아도 스스로 돌아간다는 게 장점이지만, 거꾸로 말하면 사람이 일부러 시간을 내어 들여다보지 않는 한 어딘가 어긋나 있어도 아무도 먼저 알아차리지 못한다는 뜻이기도 합니다. 그래서 이런 자동화일수록 「지금 다섯 가지가 전부 의도대로 돌고 있나」를 정기적으로 되묻는 절차가 필요하고, 그 절차 자체가 이번 이야기의 출발점입니다.
다섯 가지 안전장치는 각자 역할이 나뉘어 있습니다. 검사와 차단 목록은 「보내면 안 되는 대상을 막는」 역할이고, 발송 상한과 반응 수집은 「얼마나·어떻게 보냈는지 재는」 역할이고, 회수 규칙은 「이미 보낸 뒤에도 위험하면 되돌리는」 역할입니다. 세 가지 역할이 서로 다른 시점에서 작동하기 때문에, 점검도 한 항목만 보고 끝내지 않고 다섯 가지를 전부 같이 확인해야 전체 그림이 맞는지 알 수 있습니다.
같은 봇에서 이전에도 겉으로는 정상 작동하는 듯 보이지만 실제로는 의도와 다르게 움직이는 결함이 나온 적이 있습니다. 이번 점검에서 드러난 문제는 방향이 조금 다릅니다 — 봇 자체는 멀쩡했고, 대신 봇을 설명하는 문서 한 줄이 실제 코드를 따라가지 못하고 있었습니다.
무엇이 문제였나 — 나흘째 멈춰 있던 점검 항목
점검 항목이 만들어진 날짜는 8월 27일이었지만, 실제로 점검을 시작한 날짜는 8월 31일이었습니다. 그사이 나흘이 흘렀고, 같은 기간 동안 이 프로젝트에는 다른 커밋 24건이 쌓였습니다. 다른 작업은 계속 진행되는 동안 이 점검 항목만 대기 목록에 멈춰 있었던 셈입니다.
나흘이라는 기간 자체가 위험한 이유는 단순합니다. 안전장치 다섯 가지 중 어느 하나라도 실제로 망가져 있었다면, 그 나흘 동안 문제는 아무에게도 알려지지 않은 채 그대로 이어집니다. 발송 상한이 풀려 있었다면 나흘 동안 과다 발송이 쌓이고, 차단 계정 처리가 잘못돼 있었다면 나흘 동안 같은 오류가 반복됩니다. 점검을 미루는 비용은 점검 자체의 수고가 아니라, 문제가 있었을 경우 그 문제가 들키지 않고 이어지는 기간입니다.
이 프로젝트는 자동화를 새로 만들 때마다 점검 항목을 대기 목록에 등록하는 습관 자체는 이미 갖고 있었습니다. 8월 27일에 다섯 축을 다시 재겠다는 항목을 목록에 올려 둔 배경도 그 습관에서 나왔습니다. 그런데 목록에 올리는 일과 실제로 그 항목을 먼저 집어 드는 일은 서로 다른 문제였습니다. 다른 작업 24건이 먼저 처리되는 동안 이 항목은 순서가 밀리기만 했고, 결과적으로 「점검하기로 했다」는 결정과 「실제로 점검했다」는 사실 사이에 나흘의 간격이 생겼습니다.
처음 잰 숫자 — 다섯 축을 다시 재보니
8월 31일, 점검을 시작하며 다섯 가지 항목을 하나씩 실제 기록과 대조했습니다.
- 발송 전 검사: 발송 기록에 「검사 불통과」로 남은 건수가 93건 누적돼 있었습니다. 이 검사가 실제로 무언가를 걸러내고 있다는 뜻입니다.
- 하루 발송 상한: 최근 13일 치 발송 기록을 보면 대부분 하루 5건에서 9건 사이였습니다. 다만 8월 27일만 1건으로 유독 적었습니다.
- 차단 계정 처리: 접근이 막힌 계정 한 곳에서 「원글을 확보하지 못한 경우」가 1건 정확히 잡혔습니다.
- 반응 수집 예약 작업: 8월 29일과 8월 30일 실행 기록에 각각 46건, 44건의 반응이 정상적으로 남아 있었고 오류 기록은 0건이었습니다.
- 회수 규칙: 8월 25일부터 8월 31일까지 리포트를 봐도 회수 대상으로 표시된 건이 0건이었습니다.
다섯 항목 중 넷은 숫자만 보면 바로 정상이라고 판단할 수 있었습니다. 문제는 두 번째, 하루 발송 상한이었습니다. 8월 27일 1건이라는 숫자가 다른 날의 5건에서 9건과 차이가 커서, 이 숫자 하나만 따로 확인이 필요했습니다.
다섯 항목을 한 번에 다시 재는 방식에도 장점이 있습니다. 항목 하나씩 따로따로 확인하면 그날 눈에 띈 것만 보고 넘어가기 쉬운데, 다섯 가지를 나란히 놓고 보면 서로 비교가 됩니다. 이번에도 발송 전 검사·차단 계정 처리·반응 수집·회수 규칙 네 가지가 전부 깔끔하게 정상으로 나왔기 때문에, 유독 발송 상한 하나만 이상해 보이는 게 더 뚜렷하게 드러났습니다. 넷이 전부 정상이 아니었다면 이 이상값 하나가 다른 잡음 속에 묻혔을 수도 있습니다.
가설 — 발송량이 무너지고 있는 걸까?
8월 27일 발송 건수가 1건이라는 사실 앞에서 세운 가설은 하나였습니다 — 발송 상한을 지키는 장치 어딘가가 고장 나서, 봇이 점점 덜 발송하는 방향으로 무너지고 있는 것 아니냐는 가설입니다. 이 가설이 맞다면 다음 날에도, 그다음 날에도 발송 건수는 계속 낮은 수준에 머물러야 합니다.
이 가설을 세운 근거는 단순한 우연이 아니었습니다. 13일 치 기록 중 유독 8월 27일 하루만 다른 모든 날과 다르게 움직였고, 그 시점이 마침 점검을 시작한 시점과 가까웠습니다. 무언가 최근에 바뀌어서 발송량이 줄어드는 추세로 접어든 것 아니냐는 의심이 자연스러웠습니다.
이 가설이 특히 신경 쓰였던 이유는, 하루 발송 상한이라는 장치가 원래 과다 발송을 막으려고 만든 장치이기 때문입니다. 그 장치가 반대로 지나치게 적게 내보내는 쪽으로 고장 났다면, 지금까지 봐 왔던 안전장치의 성격 자체가 다르게 읽힙니다. 상한선이 문제가 아니라 상한을 계산하는 로직, 혹은 후보를 골라 오는 단계 어딘가가 조용히 막혀 있을 가능성도 함께 검토해야 했습니다.
가설이 틀린 지점 — 사흘 만에 회복된 숫자
8월 28일부터 8월 30일까지 사흘 치 기록을 이어서 확인했습니다. 발송 건수는 8월 28일 5건, 8월 29일 8건, 8월 30일 3건이었습니다. 지속적으로 무너지는 추세가 아니라, 낮았다가 곧바로 회복하는 흐름이었습니다.
결국 8월 27일의 낮은 숫자는 상한 장치의 고장이 아니라, 그날그날 검사를 통과하는 후보 게시물 수 자체가 들쭉날쭉했기 때문이었습니다. 발송 상한 장치는 발송 건수를 강제로 누르고 있던 게 아니라, 애초에 발송할 후보가 적으면 적게 나가고 많으면 많이 나가도록 정상적으로 동작하고 있었습니다. 지속적 붕괴 가설은 사흘 치 숫자 앞에서 성립하지 않았습니다.
사흘만 더 지켜보고 판단을 내린 데는 이유가 있습니다. 이 시스템은 발송 전 검사를 통과하는 후보가 매일 똑같이 공급되지 않습니다. 어떤 날은 관심사와 맞는 새 게시물이 많이 올라오고, 어떤 날은 적게 올라옵니다. 하루치 숫자만 보고 결론을 내렸다면 8월 27일의 1건은 「무언가 고장 났다」는 증거로 남았을 테고, 그 뒤로 존재하지도 않는 원인을 찾아 헤맸을 수 있습니다. 최소 사흘의 연속 관측이 이 가설을 확실하게 기각한 지점입니다.
진짜 원인은 무엇이었나 — 주석은 8, 코드는 이미 12였다
발송 상한 자체는 무너지지 않았지만, 이 항목을 확인하는 과정에서 예상 밖의 것이 하나 나왔습니다. 이 봇은 정해진 시각마다 자동으로 실행되도록 크론탭이라는 예약 설정 파일에 등록돼 있는데, 그 설정 파일에는 사람이 알아볼 수 있도록 「하루 8건 상한」이라는 주석이 달려 있었습니다.
그런데 실제로 코드 안에서 하루 발송 건수를 제한하는 값은 8이 아니라 12였습니다. 이 값은 8월 17일에 이미 8에서 12로 올라간 상태였습니다. 실제 시스템은 보름 가까이 하루 12건 기준으로 돌아가고 있었는데, 설정 파일에 남은 주석만 옛날 숫자인 8을 그대로 가리키고 있었습니다.
이게 왜 문제가 되냐면, 크론탭 주석은 이 시스템을 나중에 들여다볼 사람이 가장 먼저 읽는 설명이기 때문입니다. 누군가 「오늘 왜 발송이 9건이나 됐지, 상한이 8건 아니었나」라고 의심하며 주석을 봤다면, 실제로는 아무 문제가 없는데도 상한이 깨졌다고 오판합니다. 반대로 실제 문제가 생겨서 발송량을 8건 밑으로 맞춰야 한다고 판단했다면, 주석만 믿고 잘못된 기준으로 원인을 찾게 됩니다. 코드와 설정 문서가 서로 다른 숫자를 가리키는 상태, 이것이 이번에 발견한 설정값 드리프트입니다.
크론탭은 정해진 시각마다 특정 명령을 자동으로 실행하도록 예약해 두는 설정 파일을 말합니다. 사람이 매번 수동으로 프로그램을 켜지 않아도, 이 파일에 적힌 시각표대로 서버가 알아서 명령을 실행합니다. 이 파일에는 실행 명령 옆에 짧은 주석을 달아 둘 수 있는데, 그 주석은 코드를 실행하는 데는 아무 영향이 없고 오직 사람이 읽기 위한 설명일 뿐입니다. 코드를 고칠 때 주석까지 같이 고치는 일은 전적으로 사람의 습관에 달려 있고, 이번처럼 코드만 바뀌고 주석은 그대로 남는 경우가 실제로 생깁니다.
8월 17일에 하루 상한을 8에서 12로 올린 결정 자체는 잘못이 아니었습니다. 문제는 그 결정이 코드에는 반영되고 주석에는 반영되지 않은 채로 남은 2주 가까운 기간이었습니다. 이 기간 동안 시스템은 정확히 12건 기준으로 잘 작동했지만, 그 사실을 문서만 보고 이해하려던 사람은 8이라는 틀린 숫자에서 출발할 수밖에 없었습니다.
회사 업무로 옮겨 보면 이런 상황과 비슷합니다. 사내 규정에는 「출장비 정산은 영수증 5장까지」라고 적혀 있는데, 실제로 회계팀은 이미 몇 달 전부터 10장까지 처리해 주고 있는 경우입니다. 규정을 실제로 바꿔서 운영하는 사람과, 옛 규정 문서만 보고 「5장이 맞다」고 알고 있는 사람 사이에 서로 다른 기준이 동시에 존재합니다. 코드와 주석 사이에서도 똑같은 일이 일어났습니다 — 실제로 동작을 정하는 쪽(코드)과 사람에게 설명하는 쪽(주석)이 같은 날 같이 바뀌지 않으면, 둘 중 하나는 반드시 낡은 정보를 들고 있게 됩니다.
조치 — 주석 한 줄을 코드에 맞춰 고치다
고치는 작업 자체는 크지 않았습니다. 크론탭 주석을 실행당 발송 건수와 하루 상한, 그리고 문제가 생기면 즉시 멈출 수 있는 설정이 어디 있는지까지 담은 문구로 바꿔서, 지금 코드가 실제로 쓰는 값과 주석이 가리키는 값을 일치시켰습니다.
주석을 고치면서 원래 있던 「하루 8건」이라는 숫자를 그냥 지우고 「하루 12건」만 남기지는 않았습니다. 대신 실행 한 번에 발송되는 건수, 하루 전체 상한, 그리고 문제가 생겼을 때 자동화를 멈추는 설정이 코드 어디에 있는지까지 한 줄에 담았습니다. 다음에 이 시스템을 열어 볼 사람이 숫자 하나만 보고 끝내지 않고, 그 숫자가 어디서 왔는지·문제가 생기면 어떻게 멈출 수 있는지까지 같은 자리에서 바로 확인하게 하려는 목적이었습니다.
다만 이 조치 하나로 끝내지 않았습니다. 코드는 바뀌었는데 그 옆의 설명이 따라가지 못하는 문제는 이번 한 번으로 끝난다는 보장이 없습니다. 그래서 다섯 가지 항목 전체를 마무리하면서, 2026년 8월 19일부터 적용하기 시작한 재접촉 규칙도 같이 다시 확인하기로 했습니다.
재접촉 규칙은 앞서 나온 다섯 가지 안전장치와는 별도로, 8월 19일에 새로 추가된 장치입니다. 한 번 답글을 받은 계정을 너무 자주 다시 찾아가면 반가운 이웃이 아니라 따라다니는 계정으로 보일 위험이 있어서, 재접촉까지 걸리는 최소 간격과 평생 접촉할 수 있는 최대 횟수를 정해 둔 규칙입니다. 이 규칙은 이번 점검의 원래 대상 다섯 가지에는 포함되지 않았지만, 크론탭 주석을 고치는 김에 최근에 추가한 다른 장치도 실제로 지켜지고 있는지 함께 확인하는 쪽이 합리적이라고 판단했습니다.
재측정 결과 — 다섯 축 전부 정상, 재접촉 규칙도 지켜지고 있었다
다섯 가지 안전장치를 다시 확인한 결과는 전부 정상이었습니다. 발송 전 검사는 93건을 실제로 걸러내고 있었고, 차단 계정 처리는 예정된 대로 1건을 정확히 잡아냈고, 반응 수집 예약 작업은 이틀 연속 오류 없이 완주했으며, 회수 규칙은 발동할 조건 자체가 이 기간에 없었을 뿐 그 로직은 63개 테스트 사례로 이미 검증돼 있었습니다. 63개 사례 중에는 회귀(과거에 고친 결함이 다시 나타나는 것) 0건, 원래 게시물과 대조하는 시나리오 6종, 화면 요소를 확인하는 시나리오 6종이 포함돼 있었습니다.
8월 31일 점검에는 원래 대상이 아니었던 항목도 하나 더 확인했습니다. 8월 19일부터 적용하기 시작한 재접촉 규칙, 즉 한 번 답글을 받은 계정을 다시 찾아가기까지 최소 며칠을 기다리게 하고 평생 접촉 횟수에도 상한을 두는 규칙이 실제로 지켜지고 있는지였습니다. 발송 기록 전체를 이 규칙이 적용된 시점 전후로 나눠서 재접촉 간격과 누적 접촉 횟수를 계산했습니다.
규칙을 적용하기 전인 8월 17일부터 8월 18일까지는 5일이 안 돼 다시 접촉한 경우가 8건, 평생 3회 넘게 접촉한 계정이 5명 있었습니다. 규칙을 적용한 뒤에는 재접촉이 일어난 5쌍 전부에서 5일 미만 위반이 0건, 평생 2회를 넘긴 경우도 0명이었습니다. 표본이 아직 5쌍으로 많지 않지만, 방향 자체는 규칙이 의도한 대로 정확히 작동하고 있다는 뜻입니다.
이 재접촉 확인은 원래 8월 31일 점검의 대상이 아니었다는 점에서 특히 의미가 있습니다. 크론탭 주석 하나를 고치려고 열어 본 설정 파일이, 결과적으로 최근에 추가한 다른 규칙까지 실제로 지켜지는지 되짚어 보게 만든 셈입니다. 점검이라는 절차는 원래 확인하려던 항목만 확인하고 끝나지 않고, 그 과정에서 옆에 있던 다른 장치까지 같이 들여다보게 만드는 효과가 있었습니다.
남는 한계 — 사람이 챙기지 않으면 또 나흘이 흐른다
이번 점검에서 실제로 망가진 채로 발견된 안전장치는 없습니다. 다섯 가지는 전부 정상이었고, 설정 파일의 주석 하나만 실제 값을 따라가지 못하고 있었습니다. 그런데 이 결과를 그대로 안심할 근거로만 쓰기는 어렵습니다. 「전부 정상」이라는 결론은 이번 한 번 점검 시점의 사진일 뿐, 다음 점검 때도 똑같은 결론이 나온다는 보장은 전혀 아니기 때문입니다.
이번 점검이 애초에 나흘 늦게 시작됐다는 사실 자체가 한계입니다. 점검 항목은 만들어졌지만 누가 먼저 챙기기 전까지는 스스로 움직이지 않았고, 이번에는 우연히 나흘 만에 챙겨졌을 뿐입니다. 다음 점검은 1주 리듬으로 9월 7일에 다시 하기로 미뤄 뒀는데, 이 기한도 사람이 다시 확인하러 오지 않으면 이번처럼 그냥 흘러갈 수 있습니다.
결국 이번 점검이 확인한 것은 시스템 자체의 정상 여부만이 아니라, 정기 점검이라는 절차가 사람의 손을 계속 타야 한다는 사실이었습니다. 다섯 가지 안전장치가 정상이라는 결론과, 정기 점검이 나흘 밀린 채 방치될 뻔했다는 사실은 서로 다른 층에 있는 문제이고, 둘 다 같이 다뤄야 이번 점검이 완결됩니다. 설정값과 코드가 갈라지는 문제, 즉 설정값 드리프트는 한 번 고친다고 다시는 안 생기는 문제가 아닙니다. 코드를 바꿀 때마다 그 옆의 설명도 같이 바꾸는 습관이 없으면 같은 종류의 드리프트는 다른 파일, 다른 숫자로, 어쩌면 더 늦게 발견되는 형태로 또 나타날 수 있습니다. 겉으로는 계속 정상으로 보이는 자동화가 실은 오래된 설명을 달고 도는 사례는 크론 실패 감지 — 감시기가 4일 내내 정상이라고 말했다에도 정리해 두었습니다.
이번 사례를 코딩 이야기로만 읽으면 아쉽습니다. 크론탭 주석을 예약 설정 문서로, 하루 상한 값을 회사가 정한 운영 규칙으로 바꿔 놓으면 어느 업종에서나 똑같이 일어나는 일입니다. 규정을 8건에서 12건으로 바꾸기로 결정했는데 안내문이나 매뉴얼은 그대로 8건으로 남아 있는 상황, 담당자가 바뀌면서 예전 기준을 그대로 따르는 상황과 본질이 다르지 않습니다. 값을 바꾸는 결정보다, 그 결정이 관련된 모든 자리에 실제로 반영됐는지 확인하는 절차가 더 자주 빠집니다.
정기 점검을 만들어 두고도 실제로는 며칠씩 밀리거나, 설정과 실제 코드가 조용히 갈라져 있는 상태로 운영되는 자동화는 이 사례만의 이야기가 아닙니다. 회사가 크든 작든 자동화 도구나 예약 작업을 여러 개 굴리다 보면, 값을 바꾼 기록과 그 값을 설명하는 문서가 서로 다른 속도로 갱신되는 순간이 반드시 생깁니다. 문제는 그 순간을 얼마나 빨리 알아차리느냐이고, 이번처럼 정기 점검이 나흘 늦게라도 돌아가면 문서와 코드가 갈라진 채로 몇 달씩 방치되는 상황은 막을 수 있습니다. 이런 자동화 운영 상태를 점검받고 싶다면 상담에서 이야기를 나눠 볼 수 있습니다.