활용 팁 · 운영 자동화

모니터링 메일을 AI 장애 보고서로 바꾸는 자동화

2026. 7. 7. · AI 노트랩

메일 라벨에서 Python 서비스, SQLite, 규칙, AI 의견, 텔레그램 알림과 메일 보고서로 이어지는 밝은 시스템 흐름도
메일 수집부터 보고까지의 흐름을 한눈에 볼 수 있도록, 메일 시작점을 명확히 표시했습니다.

운영 메일함에는 비슷한 알림이 계속 쌓입니다. 30분마다 들어오는 모니터링 메일, 짧은 시간에 반복되는 알림, 자동 복구된 로그, 가끔 섞여 들어오는 높은 등급 장애까지 사람이 매번 읽기에는 피로도가 높습니다. 이번 글은 실제로 만든 작은 자동화 사례입니다. Gmail 라벨에 들어온 모니터링 메일을 읽고, 장애 이벤트를 분류하고, 필요할 때만 AI 의견을 붙여 텔레그램과 메일로 보고하는 구조입니다. 단순히 “이런 것도 된다”는 이야기가 아니라, 민감정보를 제외하고 실제로 어떤 순서로 만들면 되는지까지 정리했습니다.

Codex 프로젝트, Google Cloud, OpenAI API, Telegram BotFather, Python 서버 서비스, 보고서 발송으로 이어지는 구축 순서
핵심 순서는 프로젝트를 만들고, 메일 API와 알림 채널을 연결한 뒤, 서버에서 계속 실행되게 만드는 것입니다.

전체 구축 순서

이 자동화는 한 번에 거대한 시스템을 만드는 방식이 아닙니다. Codex로 작은 Python 프로젝트를 만들고, Google과 OpenAI, Telegram에서 필요한 키와 권한을 받은 뒤, 내 서버에서 30분마다 실행되는 백그라운드 서비스로 올리는 순서입니다.

  1. Codex에서 프로젝트를 만듭니다. 예를 들어 monitor-mail-reporter 같은 중립적인 폴더를 만들고, “Gmail 라벨의 메일을 읽어 장애 이벤트를 분류하고 텔레그램과 메일로 보고하는 Python 서비스”를 만들어 달라고 요청합니다. 이때 설정 파일, 로그 파일, SQLite DB, systemd 서비스 파일까지 같이 만들게 하면 나중에 서버에 올리기 쉽습니다.
  2. Google Cloud에서 Gmail API를 준비합니다. Google Cloud Console에서 프로젝트를 만들고 Gmail API를 활성화합니다. OAuth 동의 화면을 구성한 뒤, OAuth 클라이언트 ID를 “데스크톱 앱” 유형으로 생성합니다. 범위는 메일 읽기, 메일 발송, 라벨 수정/휴지통 이동이 가능해야 하므로 Gmail 읽기와 수정 권한을 사용합니다. 테스트 상태라면 실제 사용하는 Gmail 주소를 테스트 사용자에 추가해야 인증 차단을 피할 수 있습니다.
  3. OAuth 인증 파일을 서버 프로젝트에 넣습니다. Google에서 받은 클라이언트 JSON 파일은 공개 저장소에 올리면 안 됩니다. 서버의 프로젝트 디렉터리 안에 두고, 최초 1회 인증 URL을 열어 Gmail 계정으로 승인하면 토큰 파일이 생성됩니다. 이후에는 프로그램이 토큰을 사용해 지정한 라벨의 새 메일만 읽습니다.
  4. OpenAI API 키를 환경변수로 연결합니다. OpenAI 플랫폼에서 API 키를 만들고 서버의 .env 파일에 저장합니다. 코드에는 키를 직접 쓰지 않습니다. 이 자동화에서는 모든 메일을 AI에 보내지 않고, 규칙상 보고 대상이 된 장애 묶음만 AI에 보내 비용과 잡음을 줄입니다.
  5. Telegram BotFather로 봇을 만듭니다. 텔레그램에서 BotFather를 열고 /newbot으로 봇을 생성합니다. 만들어진 봇을 검색해 채팅을 열고 /start를 보낸 뒤, 서버에서 Telegram API의 getUpdates를 호출해 chat_id를 확인합니다. 봇 토큰과 chat_id 역시 .env에 저장합니다.
  6. 서버에서 Python 서비스를 계속 실행합니다. Python 가상환경을 만들고 필요한 패키지를 설치한 뒤, systemd 서비스로 등록합니다. 서비스는 30분마다 Gmail의 특정 라벨을 검색하고, 처리한 메일 ID를 SQLite에 기록하고, 원본 메일은 휴지통으로 이동합니다. 이렇게 해야 같은 메일을 반복 처리하지 않고 메일함도 계속 비워집니다.
  7. 보고 채널을 나눕니다. 즉시 봐야 하는 장애는 텔레그램으로 짧게 보냅니다. 상세한 분석과 보관이 필요한 내용은 메일 보고서로 보냅니다. 아침 보고, 18시 보고, 일일 보고처럼 정해진 보고서는 텔레그램에는 요약만, 메일에는 자세한 내용을 남기는 방식이 좋습니다.

서버 프로젝트는 이렇게 나누면 관리하기 쉽습니다

실제 구현에서는 코드와 비밀값을 섞지 않는 것이 중요합니다. 예를 들면 다음처럼 나눕니다.

monitor-mail-reporter/
  src/
    main.py
    gmail_client.py
    parser.py
    reporter.py
    openai_client.py
    telegram_client.py
    storage.py
  config.yaml
  .env
  credentials.json
  token.json
  monitor.db
  logs/
  monitor-mail-reporter.service

config.yaml에는 “어떤 라벨을 읽을지, 몇 분마다 확인할지, 몇 건 이상이면 반복 장애로 볼지” 같은 운영 설정을 둡니다. .env에는 OpenAI API 키, Telegram 봇 토큰, 보고서 수신 메일 주소처럼 외부에 공개하면 안 되는 값을 둡니다. monitor.db에는 처리한 메일 ID와 장애 이벤트를 저장합니다. 원본 메일을 휴지통으로 보내도 DB에 이벤트가 남기 때문에 아침 보고와 일일 보고를 만들 수 있습니다.

Python 프로그램은 어떤 일을 하나

프로그램의 흐름은 다음과 같습니다. 먼저 Gmail에서 label:monitoring newer_than:30m처럼 검색 범위를 좁혀 새 메일만 가져옵니다. 이미 처리한 Gmail 메시지 ID인지 DB에서 확인하고, 처음 보는 메일만 본문을 텍스트로 바꿉니다. 그다음 제목과 본문에서 시간, 호스트명, 장애명, 상태, 장애 등급을 추출합니다.

추출한 이벤트는 바로 보고하지 않고 DB에 저장합니다. 이후 규칙 엔진이 “즉시 보고할 것인지, 누적만 할 것인지, 자동 복구성 로그로 볼 것인지”를 판단합니다. 즉시 보고 대상이면 AI에 구조화된 이벤트 목록을 보내고, AI는 운영자가 놓칠 수 있는 부분을 의견으로 정리합니다. 예를 들어 “동일 호스트에서 짧은 시간에 반복된다”, “DB 또는 WAS 계열 장애로 묶인다”, “복구 로그는 있으나 같은 장애가 다시 발생했다” 같은 내용입니다.

마지막으로 프로그램은 텔레그램과 메일을 나눠 보냅니다. 텔레그램은 짧게 “어떤 호스트에서 어떤 장애가 몇 건 발생했는지”만 보내고, 메일은 상세 보고서 형태로 보냅니다. 발송한 보고서에는 별도 라벨을 붙이면 나중에 Gmail에서 보고서만 모아 볼 수 있습니다.

왜 단순 전달이 아니라 분류가 먼저인가

처음에는 “새 메일이 오면 요약해서 보내면 되지 않을까?”라고 생각하기 쉽습니다. 하지만 모니터링 알림은 일반 메일과 다릅니다. 같은 유형의 낮은 등급 알림이 여러 번 반복될 때 의미가 생기고, 반대로 RECOVERY는 30초 자동복구성 로그가 많아 단독으로 과장하면 안 됩니다. 그래서 AI에게 바로 원문을 던지기보다 먼저 규칙으로 구조화했습니다.

낮은 등급 반복, 심각 키워드, 자동 복구 로그를 구분하는 장애 분류 흐름
RECOVERY가 많다고 바로 심각한 것은 아닙니다. 보고 기준은 PROBLEM, 반복, 심각 표현, 미복구 의심을 함께 봐야 합니다.

전체 구조

구조는 단순합니다. Gmail에서 특정 라벨의 최근 메일만 읽고, 이미 처리한 메일은 SQLite에 기록해 다시 처리하지 않습니다. 새 메일에서 이벤트를 뽑아 DB에 저장한 뒤, 즉시 보고가 필요한지 판단합니다.

단계역할주의할 점
Gmail 수집특정 라벨의 최근 메일만 확인전체 메일함을 훑지 않고 범위를 좁힙니다.
이벤트 파싱상태, 호스트, 장애명, 등급 추출HTML 메일도 텍스트로 변환합니다.
규칙 판단즉시보고/누적보고/무시 구분낮은 등급은 반복 기준을 둡니다.
AI 의견위험도와 우선 확인 항목 작성보고 대상일 때만 호출해 비용을 줄입니다.
보고텔레그램 요약, 메일 상세 보고짧은 알림과 보관용 보고서를 분리합니다.

텔레그램과 메일의 역할을 나눈 이유

모든 보고를 텔레그램으로 보내면 읽기 어렵고, 모든 보고를 메일로만 보내면 긴급성이 떨어집니다. 그래서 채널을 나눴습니다. 즉시 장애는 텔레그램으로 짧게 알리고, 자세한 내용은 메일 보고서로 남깁니다. 아침, 18시, 일일 마감 보고는 텔레그램에는 요약만 보내고 메일에는 상세 리포트를 보냅니다.

텔레그램은 짧은 즉시 알림, 메일은 상세 보고서와 보관용으로 나누는 구조
운영 알림은 빠른 채널과 보관 채널을 분리해야 피로도가 줄어듭니다.

보고 기준

이번 자동화에서 가장 중요한 부분은 “언제 보고할 것인가”였습니다. 너무 민감하면 매번 울리고, 너무 둔하면 진짜 장애를 놓칩니다. 그래서 다음처럼 나눴습니다.

운영 자동화에서 중요한 것은 “모든 알림을 놓치지 않는 것”이 아니라 “사람이 봐야 할 알림만 남기는 것”입니다. 자동화가 시끄러우면 결국 사람이 무시하게 됩니다.

AI는 어디에 쓰는 것이 좋은가

AI에게 모든 메일을 매번 그대로 보내는 방식은 비효율적입니다. 대신 규칙 기반으로 1차 필터링을 하고, 보고할 가치가 있는 묶음만 AI에게 보냅니다. AI의 역할은 장애 여부를 처음부터 맞히는 것이 아니라, 이미 구조화된 이벤트를 바탕으로 사람이 읽기 좋은 의견을 만드는 것입니다.

작게 시작할 수 있는 구성

이런 자동화를 만들 때 처음부터 거대한 관제 시스템을 만들 필요는 없습니다. 작은 서버 한 대에서도 충분히 시작할 수 있습니다.

  1. Gmail 라벨 하나를 정합니다.
  2. 30분마다 새 메일만 읽습니다.
  3. 처리 기록을 SQLite에 남깁니다.
  4. 이벤트를 DB에 저장한 뒤 원본 메일은 휴지통으로 보냅니다.
  5. 즉시 알림은 텔레그램, 상세 보고서는 메일로 보냅니다.
  6. AI 분석은 보고 대상일 때만 호출합니다.

결론

이 자동화의 목적은 사람을 빼는 것이 아닙니다. 사람이 매번 같은 메일을 뒤지지 않아도 되도록, 반복되는 알림을 정리하고 중요한 것만 앞으로 꺼내는 것입니다. 실제 구축 순서는 Codex로 프로젝트를 만들고, Google Cloud에서 Gmail API 인증을 만들고, OpenAI API와 Telegram 봇을 환경변수로 연결하고, 서버에서 Python 서비스를 계속 실행시키는 흐름입니다. 작은 운영 환경에서도 이 정도만 연결하면 “메일함에 쌓이는 알림”을 “운영자가 읽을 수 있는 장애 보고서”로 바꿀 수 있습니다.

← 이전 글 · AI 마스터로 가는 5단계