본문 바로가기

Computer Vision + Python/산업 응용 & 비즈니스활용 (전문가)

Python으로 구현한 상품 수집 서버 실시간 로그 분석 및 자동 알림 시스템

 

1. 상품 수집 서버의 안정성이 곧 비즈니스의 수익이다

해외구매대행 사업의 핵심은 수만 개의 상품 데이터를 얼마나 빠르고 정확하게 수집하느냐에 달려 있다. 나는 중국 쇼핑몰의 데이터를 24시간 수집하기 위해 파이썬 기반의 상품 수집 자동화 서버를 운영 중이다. 하지만 서버는 언제나 예기치 못한 이유로 멈출 수 있다. 네트워크 오류나 사이트 구조의 미세한 변화로 수집 스크립트가 멈췄을 때, 이를 뒤늦게 발견하는 것은 비즈니스에 있어 치명적인 기회비용 발생을 의미한다. 이를 방지하기 위해 실시간 로그 분석자동 알림 시스템 구축은 선택이 아닌 필수였다.


2. 왜 이 기술들을 선택했는가: 설계 의도

2.1. Watchdog: CPU 자원을 아끼는 이벤트 기반 감시

로그를 감시하는 가장 단순한 방법은 무한 루프를 돌며 파일을 계속 확인하는 '폴링(Polling)' 방식이다. 하지만 이 방식은 상품 수집에 써야 할 서버의 CPU 점유율을 불필요하게 갉아먹는다. 나는 대신 이벤트 기반의 Watchdog 라이브러리를 선택했다. 파일 시스템의 수정 이벤트를 운영체제로부터 직접 전달받기 때문에, 자원 낭비 없이 가장 효율적으로 실시간 로그 분석을 수행할 수 있다.

2.2. last_position: 중복 알림 방지와 성능의 균형

로그 파일이 수정될 때마다 파일 전체를 읽는 것은 매우 비효율적이다. 나는 last_position(파일 포인터 기록) 방식을 설계에 도입했다. 마지막으로 읽었던 지점을 기억해 두었다가 새로 추가된 줄만 읽어 들이는 방식이다. 이는 서버의 부하를 최소화할 뿐만 아니라, 이미 확인한 에러 메시지에 대해 중복 알림이 가는 것을 완벽하게 방지해 준다.

2.3. 텔레그램(Telegram): 이메일보다 빠른 즉시성

장애 상황에서 이메일은 너무 느리다. 상품 수집 서버의 장애는 1분 1초가 매출 손실로 직결되기에, 즉시성이 뛰어난 텔레그램 봇 API를 선택했다. 별도의 앱 설치 없이 평소 사용하던 메신저로 알림을 받을 수 있어 대응 속도가 현격히 빨라졌다.

파이썬 Watchdog 라이브러리와 텔레그램 API를 활용한 실시간 로그 모니터링 및 자동 알림 시스템 아키텍처 흐름도
[그림 1] 로그 감시부터 키워드 매칭, 텔레그램 알림까지의 전체 시스템 작동 프로세스

 


3. 실전 적용: 파이썬 기반 실시간 자동 알림 코드

이 코드는 내가 실제 해외구매대행 상품 수집 서버에 적용한 '프로 버전'의 핵심 로직이다. 2026년 최신 라이브러리 규격에 맞춰 안정성을 높였다.

Python
 
import time
import requests
from watchdog.observers import Observer
from watchdog.events import FileSystemEventHandler

# --- 환경 설정 ---
LOG_FILE = "product_collect.log"  # 모니터링 대상 상품 수집 로그
TELEGRAM_URL = "https://api.telegram.org/bot{token}/sendMessage"
# ----------------

class CollectLogHandler(FileSystemEventHandler):
    def __init__(self, filename):
        self.filename = filename
        self.last_position = self._init_position()

    def _init_position(self):
        try:
            with open(self.filename, 'r', encoding='utf-8') as f:
                f.seek(0, 2)
                return f.tell()
        except FileNotFoundError: return 0

    def on_modified(self, event):
        if not event.is_directory and event.src_path.endswith(self.filename):
            self._analyze_log()

    def _analyze_log(self):
        with open(self.filename, 'r', encoding='utf-8') as f:
            f.seek(self.last_position)
            lines = f.readlines()
            self.last_position = f.tell()
            
            for line in lines:
                if any(k in line.upper() for k in ["ERROR", "CRITICAL", "TIMEOUT"]):
                    self._send_alert(line.strip())

    def _send_alert(self, msg):
        # 텔레그램 발송 로직 (생략 가능하나 본문에 포함 추천)
        requests.post(TELEGRAM_URL, data={"chat_id": "ID", "text": f"🚨 서버 감지: {msg}"})

 

※ 위 코드는 실제 운영 환경에서 사용한 핵심 구조를 단순화한 예시이며, 서버 환경에 따라 예외 처리와 보안 설정은 별도로 고려해야 한다.


4. 비즈니스에 미친 영향: 수동 확인에서 자동 대응으로

이 시스템을 도입한 후, 나의 해외구매대행 운영 흐름은 완전히 바뀌었다. 예전에는 상품 수집이 잘 되고 있는지 하루에도 몇 번씩 원격 접속으로 서버를 확인해야 했다. 하지만 이제는 서버가 스스로 자신의 상태를 보고한다. 덕분에 나는 서버 관리의 압박에서 벗어나, 더 가치 있는 상품 소싱과 마케팅 전략에 집중할 수 있게 되었다.

복잡한 서버 로그 화면과 깔끔한 텔레그램 모바일 알림의 비교 대조 이미지 - 수동 확인과 자동 알림의 차이
[그림 2] 일일이 로그를 확인하던 기존 방식(Before)과 장애 즉시 알림을 받는 방식(After)의 비교


5. 한계와 개선 방향: 더 단단한 시스템을 위해

물론 현재 시스템이 완벽한 것은 아니다. 운영 기간이 길어지며 보완해야 할 점들이 보이기 시작했다.

  • 로그 로테이션(Rotation) 대응: 로그 파일이 너무 커지면 관리 효율이 떨어진다. 파일이 새로 생성될 때 포인터를 초기화하는 로직이 추가로 필요하다.
  • 키워드 기반의 한계: 단순 키워드 매칭은 예상치 못한 논리적 오류를 놓칠 수 있다.
  • 상태 체크(Heartbeat) 시스템: 만약 서버 자체가 완전히 다운되어 로그조차 남기지 못할 경우, 알림 시스템도 무용지물이 된다. 장기적으로는 서버가 살아있음을 주기적으로 알리는 하트비트 방식의 도입을 검토 중이다.

마무리하며

기술은 결국 비즈니스를 지탱하는 도구다. 이번 실시간 로그 분석 및 자동 알림 시스템 구축을 통해, 기술이 어떻게 실질적인 업무 효율과 심리적 안정감을 줄 수 있는지 다시 한번 체감했다. 나의 시행착오가 상품 수집 서버를 운영하는 다른 분들께도 의미 있는 참고가 되길 바란다.