메일 도우미를 다시 돌렸더니, 잠깐 낫고 또 멈춘 날

반복해서 메일을 읽음 처리하고 받은편지함을 분류하는 일을 덜려고 메일 도우미를 자동으로 돌렸어요. 그런데 2026년 10월 4일 새벽에는 재실행까지 네 번 실패했고, 다음 날 정상으로 끝난 재실행 뒤에도 세 시간쯤 지나 다시 멈췄어요.

무슨 상황이었냐면요

메일 도우미는 10분마다 켜 둔 Edge 브라우저에 붙어 메일을 처리하는 예약 작업이에요. 정해 둔 조건으로 메일을 처리하는 ‘규칙’ 단계와, 받은편지함의 새 메일을 AI로 나누는 ‘분류’ 단계가 따로 있어요. 운영 점검 에이전트는 실행 결과와 브라우저·관리 콘솔·AI 호출을 중계하는 프록시 상태를 살펴보고, 필요하면 다시 실행하도록 요청해요. 메일을 처리하는 작업과 그 작업이 잘 도는지 보는 점검이 나뉘어 있는 구조예요.

이 이야기는 원인을 찾아 고친 성공담은 아니에요. 한 번 다시 돌려서 오류가 사라졌을 때 어디까지 안심할 수 있는지, 그다음 실패가 앞선 판단을 어떻게 바꾸는지 따라가 본 복기예요. AI에게 운영 점검을 맡기면 ‘지금은 정상’이라는 관찰을 ‘문제가 해결됐다’는 결론으로 이어 붙이기 쉬워서, 그 사이를 짚어 보려고 해요.

10월 2일부터 규칙 단계가 반복해서 실패했어요

앞선 실행에서도 규칙 단계의 30초 타임아웃이 반복됐어요. 타임아웃은 요청을 보낸 뒤 정해진 시간 안에 응답이 돌아오지 않아 기다림을 끝내는 일이에요. 10월 2일에는 01:23 실행과 01:30 재실행 기록이 남았고, 이후 글 후보를 점검할 때도 원인과 해결 근거가 미확인 상태였어요. 반복 실패와 재시도가 있었다는 점까지는 확인됐지만, 그 경과만으로 특정 설정이 잘못됐다고 좁힐 수는 없었어요.

그리고 10월 4일에는 같은 오류가 더 뚜렷하게 이어졌어요. 아래 시각은 모두 한국 시각이고, 실행이 시작된 시각이에요. 종료 시각과는 달라요.

네 번의 오류 문구는 같았어요.

rules: Runtime.evaluate: 30초 안에 응답 없음

rules는 메일 규칙 단계 이름이에요. Runtime.evaluate는 브라우저 페이지 안에서 코드를 실행시키는 명령 이름이고요. 이 문구는 규칙 작업 중 그 명령의 응답을 30초 안에 받지 못했다는 뜻이에요. 메일 서버 전체가 멈췄다거나 AI 모델의 판단이 틀렸다는 설명까지 들어 있는 문구는 아니에요.

표의 1.7분과 3.7분은 30초 제한과 별개예요. 30초는 오류가 난 명령의 대기 제한이고, 분 단위 숫자는 실행 전체의 소요 시간이거든요. 실행에는 다른 단계와 대기 시간이 함께 들어갈 수 있어요. 오류 한 줄을 보고 전체 실행도 정확히 30초 만에 끝났다고 읽으면, 나중에 시간 기록을 대조할 때부터 어긋나요.

주변은 정상이라 한 번 더 돌렸어요

10월 4일 01:30 운영 점검은 직전 01:23 실행을 보고 이렇게 판단했어요.

받은편지함 분류와 로그인 유지는 정상이었고, 자동화 Edge·콘솔·프록시도 모두 정상이라 일시적 지연으로 보고 한 번만 다시 실행합니다.

이 판단의 출발점은 작업 전체가 무너진 모습은 아니라는 관찰이었어요. 로그인도 유지됐고 받은편지함 분류도 정상이었으니, 규칙 단계의 지연이 잠깐 나타났을 가능성을 보고 한 번 더 돌린 거예요. 다만 정상인 주변 구성 요소를 확인한 것이 규칙 단계의 지연 원인을 찾아낸 것은 아니었어요.

요청 기록에는 mail — 요청함(미확인)이라고 남았어요. 이는 메일 작업의 재실행을 요청했다는 뜻이고, 그 요청의 결과까지 확인했다는 뜻은 아니에요. 같은 01:30에 시작된 메일 도우미 기록을 따로 봐야 다음 장면이 이어져요. 그 재실행도 같은 rules 오류로 실패했어요.

이어 01:33과 01:43 실행에는 ‘할 일 없음’이 남았고, 각각 0.7분이 걸렸어요. 오전 11:33과 11:43에는 ‘규칙: 1통 읽음 처리’라는 실제 처리 결과도 나왔어요. 실패 뒤 실행이 이어졌고 규칙 작업도 처리된 적이 있다는 흔적이에요. 그렇다고 새벽에 응답이 늦었던 이유가 설명된 건 아니었어요. ‘할 일 없음’과 ‘1통 읽음 처리’도 나눠 읽었어요. 전자는 처리할 대상이 없었던 결과이고, 후자는 실제로 한 통에 규칙이 적용된 결과니까요.

다음 날 재실행은 정상으로 끝났어요

10월 5일 01:23에도 메일 규칙은 같은 오류로 실패했어요. 실행 전체에는 1.7분이 걸렸어요. 01:30 운영 점검은 같은 실행에서 받은편지함 분류가 페이지를 다시 열어 정상 완료됐고 로그인도 유지됐다고 봤어요. Edge·콘솔·프록시도 정상이어서 다시 일시적 지연으로 판단하고 한 번만 재실행을 요청했어요.

이번에는 01:30 메일 도우미가 1.2분 뒤 ‘할 일 없음’으로 끝났어요. 직전 오류가 다음 실행에 그대로 이어지지는 않았다는 점은 확인됐어요. 실패 → 주변 상태 점검 → 재실행 → 정상 종료. 여기까지만 보면 반복 실패에서 벗어난 듯한 흐름이었어요.

그런데 점검의 요약에는 이런 문장도 있었어요.

10-04에도 같은 단계가 한 번 실패했으니, 다시 실패하면 규칙 단계의 지연 처리를 점검해야 합니다.

앞날 전체 기록과 대조하면 ‘한 번’이라는 요약은 정확하지 않았어요. 10월 4일에는 01:03·01:13·01:23의 정기 실행 세 번과 01:30 재실행 한 번, 합계 네 번이 실패했거든요. 다시 실패할 때 조사하겠다는 방향과 별개로, 반복 횟수가 요약에서 줄어든 거예요. 점검 에이전트의 설명만 읽으면 단발성 오류처럼 보일 수 있었어요. 여러 실행을 함께 보는 이유가 여기에도 있었어요.

세 시간 뒤에는 분류까지 함께 멈췄어요

10월 5일 04:33에는 규칙과 받은편지함 분류가 함께 실패했어요. 오류는 두 줄로 남았어요.

rules: Runtime.evaluate: 30초 안에 응답 없음
triage: Runtime.evaluate: 30초 안에 응답 없음

triage는 받은편지함의 새 메일을 분류하는 단계예요. 앞선 01:23에는 규칙만 실패했는데, 이번에는 두 단계에서 같은 명령의 응답 제한에 걸렸어요. 실패 범위가 넓어진 관찰이에요. 두 단계가 같은 근본 원인으로 멈췄는지는 이 두 줄만으로 확정할 수 없어요.

04:43에는 규칙 단계가 다시 실패했고, 04:53에는 ‘할 일 없음’으로 끝났어요. 04:33과 04:43 실행은 각각 3.2분, 04:53 실행은 0.7분이 걸렸어요. 마지막 실행이 짧고 오류 없이 끝났다는 사실도, 바로 앞의 두 실패를 없애 주지는 않아요.

이날의 흐름은 이렇게 바뀌었어요.

01:23 규칙 실패 → 01:30 재실행, 할 일 없음
→ 04:33 규칙·분류 실패 → 04:43 규칙 실패
→ 04:53 할 일 없음

01:30과 04:33의 실행 시작 간격은 3시간 3분이에요. 정상 재실행 뒤 얼마 지나지 않아 실패가 돌아왔다는 뜻이지, 그동안 메일 처리가 계속 막혔다는 뜻은 아니에요. 중간 실행에도 ‘할 일 없음’이 남았어요. 확인된 피해는 규칙·분류 작업의 실패이고, 누락된 메일 수나 사람의 업무 지연은 이 기록으로 수치화하지 않았어요.

원인을 고친 한 줄은 아직 없어요

이번에는 원인을 가리키는 코드나 설정 한 줄을 찾았다는 결말이 없어요. 10월 2일부터 5일 아침까지 메일 작업 코드의 변경 기록을 대조해도, 이 반복 타임아웃을 해결한 변경은 확인되지 않았어요. 메일 도우미가 쓰는 자동화 Edge 쪽에는 10월 2일 08:13의 67f488f가 있었는데, 브라우저를 다시 켤 때 지난 세션을 복원해 회사 로그인이 풀리지 않게 하는 변경이었어요. 로그인 유지 문제를 다룬 기록이라 응답 지연을 고친 근거로 볼 수는 없어요. 다시 실행됐다는 사실과 코드를 고쳤다는 사실은 서로 다른 기록이에요.

메일 도우미를 만든 10월 1일에는 다른 멈춤에 대응한 기록이 있어요. 17:38:37의 bd796c5는 잠금을 쥔 프로세스의 생존 여부와 브라우저 명령 제한을 다뤘고, 18:22:17의 b1b6334에는 작업용 탭 고정과 응답이 없을 때 한 번 더 시도하는 변경이 들어 있어요. 21:10:55의 d026eeb는 브라우저가 스스로 회복하는 장치를 추가한 기록이에요. 잠금은 여러 작업이 한 브라우저를 동시에 쓰지 않도록 차례를 정하는 장치예요.

이 가운데 b1b6334의 재시도는 지금 코드에도 남아 있어요. 메일 API 호출이 30초 안에 답하지 않으면 가벼운 페이지를 다시 열고 한 번 더 불러요. 그래서 운영 점검이 요청한 ‘재실행’은 실행 안의 이 재시도와 다른 층의 재시도예요. 남은 오류 한 줄이 실행 안의 재시도까지 거친 뒤였는지는, 실행 기록에 ‘다시 시도’ 줄이 함께 남았는지로 확인해야 해요.

이 변경들은 이전에 겪은 멈춤에 대비한 흔적이에요. 하지만 그 뒤에도 지금의 오류가 반복됐으니, 당시 고친 탭 문제를 이번 사건의 진범으로 가져다 붙일 수는 없어요. 어느 코드가 언제 바뀌었는지는 알 수 있어도, 그 코드가 특정 실패의 원인이라는 연결에는 추가 근거가 필요해요. 이번에 확인한 결말은 04:53 실행이 오류 없이 끝났다는 것까지예요.

증상, 판단, 해결은 따로 놓아야 했어요

이번 사건에서 가장 쓸모 있었던 구분은 세 가지였어요. ‘30초 안에 응답 없음’은 관찰한 증상이에요. ‘일시적 지연’은 주변 상태를 보고 세운 가설이에요. 원인을 찾아 바꾼 뒤 같은 조건에서 다시 확인하는 것은 해결 검증이에요. 지금 기록에는 첫째와 둘째, 그리고 성공하거나 실패한 재시도 결과가 있어요.

재시도는 당장의 작업이 다시 돌아오는지 확인할 수 있어요. 하지만 한 번 정상 종료했다고 해서 왜 실패했는지까지 알려 주지는 않아요. 특히 처리할 대상이 없는 실행은, 실패 당시와 같은 메일이나 같은 작업량으로 시험한 결과와 다를 수 있어요. 그래서 ‘할 일 없음’으로 끝난 실행을 실패한 규칙의 재현 시험과 같은 칸에 두지 않기로 했어요.

정상 표시에도 확인 범위가 있어요. Edge가 켜져 있고 콘솔이 응답하고 프록시가 정상이었다는 점검은 주변 구성 요소의 상태를 알려 줘요. 그 시점의 특정 메일 페이지 명령이 제시간에 끝났는지는 해당 단계의 실행 결과가 알려 주고요. 주변은 정상인데 실제 작업은 실패하는 두 기록이 함께 있어도 모순은 아니에요.

그래서 하지 말아야 할 것

첫째, 마지막 정상 실행 하나로 앞선 실패를 덮지 않아요. 실패 단계와 오류 문구를 시간순으로 놓으면, 규칙만 실패하다 분류까지 함께 실패한 변화가 보여요. 짧은 상태 요약보다 개별 실행을 먼저 대조하는 편이 도움이 됐어요.

둘째, 재실행 요청을 성공으로 세지 않아요. 요청 시각과 실제 실행 시작 시각, 실행 결과를 따로 확인해요. 10월 4일에는 요청 뒤 실패했고 다음 날에는 정상 종료했으니, 요청이 있었다는 기록만으로 두 날을 같게 취급하면 중요한 차이를 놓쳐요.

셋째, ‘일시적’이라는 판단에는 다음 확인을 붙여요. 주변이 정상이라 한 번 재시도할 수는 있지만, 다시 같은 오류가 나면 조사할 단계와 당시 페이지 상태를 함께 남겨요. 이번에는 04:33의 두 단계 실패가 앞선 가설을 다시 살펴볼 이유가 됐어요.

넷째, 원인을 조사할 때 실패 시각·실패 단계·브라우저와 콘솔 상태·재시도 결과를 같은 표에 놓아요. 변경 이력이 있으면 변경 전후도 비교해요. 대기 제한을 늘리거나 브라우저를 다시 켠 뒤 우연히 정상 실행됐다는 이유만으로 원인 해결이라고 이름 붙이지 않아요.

자기 자동화의 로그가 텍스트 파일로 남는다면 PowerShell에서 아래처럼 오류 주변을 뽑아 볼 수 있어요. mail-run.log는 자신이 저장한 로그 파일 이름으로 바꿔요. 이 명령은 조회만 하고 작업을 다시 실행하지 않아요.

Select-String -LiteralPath .\mail-run.log -Pattern 'Runtime.evaluate|다시 시도|rules|triage' -Context 3,3

앞뒤 세 줄도 같이 보는 건 오류 한 줄만 떼지 않기 위해서예요. ‘다시 시도’도 함께 찾으면 실행 안의 재시도가 있었는지까지 한 번에 보여요. 자기 로그가 재시도를 다른 말로 남긴다면 그 표현으로 바꿔요. 로그 형식에 따라 시각과 결과가 그보다 멀리 있으면 전체 실행 묶음을 열어 봐요. 같은 시각의 상태 점검 기록도 함께 비교하면, ‘페이지 명령 실패’와 ‘주변 정상’이 각각 무엇을 확인했는지 나눌 수 있어요. 메일 제목이나 주소, 본문은 조사에 꼭 필요한 범위로만 보고 공개 기록에서는 빼요.

마치며

이번에 메일 도우미는 다시 돌아왔지만, 왜 멈췄는지는 아직 밝혀지지 않았어요. 제가 가져갈 교훈은 재시도가 성공한 시각과 원인을 해결한 근거를 서로 다른 칸에 적는 거예요. 여러분이 맡겨 둔 자동화에서는 마지막 초록 표시를 확인할 때, 그 앞의 실패가 왜 사라졌는지도 함께 보고 계신가요?