← 뉴스레터 목록

작업장 / 뉴스레터

한 방만 1분→5분 간격으로: 82초까지 늘던 카톡 봇 읽기가 밤새 최대 4.1초로

맥에 띄워 둔 카톡이 메모리를 22GB까지 썼습니다. 방마다 한 번 읽는 데 걸린 시간을 쪼개 보니 한 방만 82초까지 늘고 있었습니다. 그 방 하나의 읽기 간격을 5분으로 늘리자 밤새 최대 4.14초에 머물렀습니다. 그 사이 '읽은 횟수 때문'이라던 첫 해석은 숫자 하나로 틀린 것이 드러났습니다.

EP178 강대종 · 마이너스베타스튜디오

이번 이야기

11월 8일 오후, 맥에서 돌아가던 카톡이 메모리를 22GB나 쓰고 있었습니다. 이 카톡에는 ‘몽이’라는 봇이 붙어 있습니다. 여러 대화방을 차례로 돌며 창에 뜬 글을 읽고, 필요하면 답을 보내는 제 자동화입니다.

이상하다는 건 바로 알았습니다. 카톡은 매일 새벽 4시 17분에 자동으로 다시 켜지게 해 두었는데, 재시작 직전 메모리가 한 달 내내 0.1~1.7GB 사이였거든요. 22GB는 평소 가장 높던 값의 열 배가 넘습니다.

오후 2시 34분에 재시작을 승인했습니다. 숫자는 일단 내려갑니다. 그런데 매일 재시작하는데도 이만큼 부풀었다면, 재시작은 증상을 지울 뿐이고 원인은 그대로 남아 있다는 뜻이죠. 원인을 모르면 언제 또 부풀지 모르는 채로 지켜보는 수밖에 없습니다. 그래서 이번 일은 ‘다시 켜고 끝’이 아니라 ‘어디서 쌓이는지 좁히기’로 잡았습니다.

실마리는 메모리 숫자가 아니라 방마다 읽는 데 걸린 시간 기록에서 나왔습니다. 한 방만 혼자 느려지고 있었고, 그 방을 읽는 간격을 1분에서 5분으로 늘리는 설정 한 줄을 넣은 뒤 밤사이 이상 신호가 나오지 않았습니다. 다만 그 사이에 제 첫 해석이 한 번 틀렸습니다. 이번 글은 그 이야기입니다.

직접 겪은 일

재시작하면서 안전장치부터 깔았습니다. 5분마다 카톡 메모리를 재서 4GB를 넘으면 자동으로 다시 켜되, 한 시간에 한 번까지만 켜는 장치입니다. 여기서 실수가 하나 있었습니다. 공유 설정 파일을 바꿀 때 거치는 기록 절차를 건너뛰고 오후 3시 40분에 파일을 직접 복사해 넣었거든요. 4시 37분에 기록을 뒤늦게 맞췄고, 넣은 내용은 원본 템플릿과 같았습니다.

그다음은 관찰이었습니다. 2시 35분 재시작 뒤 방마다 한 번 읽는 데 걸린 시간을 30분 평균으로 줄 세워 보니, 한 방만 혼자 계단을 오르고 있더라고요. 4.6초 → 8.0 → 11.7 → 15.8 → 20.8 → 25.7 → 31.1 → 37.2 → 43.1 → 49.1 → 55.5초. 같은 시간에 다른 방들은 2.5~3.7초에 머물러 있었습니다. 저녁 8시 13분에는 61.6초, 8시 16분에는 82.6초까지 갔습니다. 그 방이 시간을 잡아먹으니 나머지 방 차례도 밀려서, 다른 방을 30분에 읽는 횟수가 167번에서 103번으로 줄었습니다.

8시 20분, 안전장치가 처음으로 일을 했습니다. 8시 15분 검사 때는 4GB 미만이었는데 8시 20분에 21,504MB를 잡아내 카톡을 다시 켰고, 재시작은 8시 21분에 끝났습니다. 손으로 재시작하고 여섯 시간이 안 돼 비슷한 크기로 돌아온 셈입니다. 기록을 거슬러 보니 오전에도 같은 모양이었습니다. 새벽 4시 18분부터 9시 45분 사이에도, 오후 2시 35분부터 8시 14분 사이에도 그 방을 약 250번 읽은 뒤 읽기 시간이 60초에 닿았습니다.

저녁 8시 50분대, 선택지 카드에서 저는 ‘3번 먼저 (추천)‘을 골랐습니다. 그 방 하나만 정기 읽기를 5분에 한 번으로 늦추는 안입니다. 각 줄에서 글자 값만 읽도록 읽는 방식 자체를 바꾸는 2번은 넣지 않았습니다.

준비하는 동안 새로운 게 보였습니다. 8시 21분 재시작 뒤 그 방 읽기 시간이 3.9초에서 9시 10분에 9.6초까지 오르다가, 새 글이 와서 창이 맨 아래로 내려갈 때마다(9시 10분·45분·48분·50분) 4초대로 떨어지더라고요. 그래서 이렇게 해석했습니다. 같은 줄을 반복해서 읽을수록 쌓이고 창 내용이 바뀌면 풀린다, 즉 ‘읽은 횟수에 비례’한다고요.

고친 건 단순했습니다. 방마다 최소 읽기 간격을 적는 목록 파일을 만들고, 그 방 번호와 ‘300’(초)을 한 줄로 넣었습니다. 방 이름 대신 알아볼 수 없게 바꾼 16자리 번호를 썼고요. 규칙도 몇 가지 붙였습니다. 간격은 60~3,600초만 받고, 판단이 안 서면 읽는 쪽으로 갑니다. 알림이 와서 먼저 읽을 때나 하던 읽기를 이어갈 때는 간격과 상관없이 읽습니다. 목록 파일이 없으면 예전과 똑같이 돌고, 되돌리려면 그 파일을 다른 폴더로 옮기기만 하면 됩니다. 밤 10시 4분, 진행 중인 답장 작업이 없고 봇이 방 순회를 마치고 쉬는 중인 걸 확인한 뒤 봇을 새로 띄웠습니다.

새벽 1시 15분, 적용 세 시간 뒤에 숫자를 쟀습니다. 카톡을 재시작하거나 키를 누르거나 대화 내용을 읽지 않고 숫자만 봤습니다. 그 방은 36번 읽혔고(간격 중앙값 309초) 읽기 시간은 3.4~4.0초에서 거의 움직이지 않았습니다. 한 번 읽을 때마다 바뀐 폭은 평균 -0.004초였습니다. 1분 간격(시간당 58번)으로 읽던 적용 전에는 한 번 읽을 때마다 0.114초씩 늘었습니다.

여기서 제 해석이 틀렸다는 게 드러났습니다. 정말 ‘읽은 횟수에 비례’했다면 36번 읽는 동안 약 4초가 붙어 7.9초쯤 돼야 했거든요. 그런데 늘지 않았습니다. 남는 설명은 ‘간격’입니다. 1분 간격으로 몰아 읽을 때만 쌓이고, 5분 간격에서는 쌓이지 않는다는 거죠. 같은 ‘새 글 없음’ 조건끼리 비교해도 그렇습니다. 적용 전 8시 22분부터 9시 10분까지, 새 글 없이 1분 간격으로 48번 읽는 동안 3.9초가 9.6초가 됐으니까요. 카톡 메모리는 1시 14분에 531MB였습니다. 그 속도로 늘면 새벽 재시작 전에 약 0.8GB로, 평소 범위 안입니다.

다음 날 아침 8시 50분쯤 마지막 점검을 했습니다. 밤사이 그 방은 122번 읽혔고(간격 301~358초) 읽기 시간은 2.47~4.14초였습니다. 15초를 넘은 적 0번, 60초를 넘은 적 0번, 안전장치가 카톡을 다시 켠 횟수도 0번이었습니다. 다른 방들이 새벽 4시 30분 2.57초에서 8시 30분 2.77초로 조금 오른 건 모든 방에 공통이라, 그 방에서만 쌓인 건 아니었습니다. 82.6초까지 갔던 한 방 읽기는 밤새 4.14초를 넘지 않았습니다. 21~22GB까지 부풀던 카톡도 4GB 기준을 한 번도 넘지 않았고, 중간중간 잰 값은 531~560MB였습니다. 8시 52분에 이 건을 닫았습니다.

배운 점

첫째, 전체가 무거워지면 평균보다 ‘혼자 움직이는 줄’을 먼저 찾습니다. 카톡 메모리 22GB라는 숫자만으로는 어디서 쌓이는지 보이지 않았습니다. 방별로 쪼개자 다른 방은 평평하고 한 방만 계단을 오르는 그림이 나왔고, 거기서 실마리가 잡혔습니다.

둘째, 가설은 ‘맞다면 숫자가 얼마여야 하나’로 시험합니다. ‘약 250번 읽으면 60초’가 두 번 겹쳤고 새 글이 오면 풀리는 모습까지 보이니, ‘읽은 횟수 탓’이 그럴듯했습니다. 그런데 그 가설대로라면 7.9초가 나와야 할 자리에 3.4~4.0초가 찍혔습니다. 고친 게 효과가 있다는 것과 원인 설명이 맞다는 건 다른 문제더라고요. 예측 숫자를 미리 적어 두면 그 둘이 갈립니다.

셋째, 고치는 장치와 받치는 장치를 따로 둡니다. 고치기는 가장 좁게 합니다. 지우면 원래대로 돌아가는 한 줄로, 애매하면 예전 동작 쪽으로 가게 하는 거죠. 받치기는 원인과 상관없이 숫자만 보고 움직이게 합니다. 4GB를 넘으면 재시작, 한 시간에 한 번까지. 저녁 8시 20분에 21GB를 사람 손 없이 잡은 건 원인을 찾기 전에 깔아 둔 이 안전장치였습니다.

한계도 적어 둡니다. 지켜본 밤 동안 그 방에는 새 글이 거의 없었습니다(창이 내려간 건 새벽 재시작 직후 한 번, 봇이 보낸 글 0건). 대화가 몰리는 시간에도 읽기 시간이 평평할지, 메모리가 왜 그렇게 한꺼번에 부풀었는지는 아직 밝히지 못했고, 그래서 안전장치는 그대로 남겨 두었습니다.

독자에게

먼저 반복해서 도는 자동화 하나를 골라 ‘항목별 1회 소요 시간’을 하루치 모아 보세요. 시각, 항목, 걸린 초, 이렇게 세 칸이면 됩니다. 30분 단위로 항목별 평균을 내 나란히 놓고, 다른 줄은 평평한데 혼자 오르는 줄이 있는지 봅니다.

다음으로 평소 범위를 적어 두세요. 제가 22GB를 바로 이상으로 본 건 ‘재시작 직전 0.1~1.7GB’라는 한 달치 기록이 있어서였습니다. 맥이라면 ‘활동 상태 보기’에서 의심 가는 앱의 메모리를 매일 같은 시각에 일주일만 적어도 비교할 기준이 생깁니다.

세 번째로, 간격을 바꾸는 실험은 실제 대상 말고 빈 테스트 대상에 먼저 걸어 보세요. 카톡 봇이라면 혼자 들어가 있는 테스트 방, 폴더를 감시하는 자동화라면 빈 테스트 폴더 하나면 됩니다. 거기서 간격 설정을 넣었다 빼 보고, 빼면 예전처럼 도는지부터 확인하세요. 그러면 실제 대상에서는 되돌리기가 한 번의 동작으로 끝납니다.

네 번째로, 바꾸기 전에 예측을 한 줄 적으세요. ‘내 생각이 맞다면 세 시간 뒤 이 숫자는 ○○여야 한다.’ 이번에는 7.9초가 그 한 줄이었습니다. 결과가 예측과 다르면 고친 건 그대로 두되 원인 메모는 다시 씁니다.

마지막으로, 안전장치에는 기준값과 횟수 제한, 그리고 ‘작동할 때마다 한 줄 기록’을 붙이세요. 다음 날 아침 그 기록에 새 줄이 생겼는지만 봐도 밤사이 무슨 일이 있었는지 압니다. 이번 마지막 점검에서도 가장 중요하게 본 건 안전장치 기록에 새 줄이 하나도 없다는 사실이었습니다.

기록은 다음 시작이 돼요.뉴스레터 더 읽기 ↗이 작업장의 제품 ↗
작업장 전체 페이지 목적에 맞는 페이지 찾기