시스템 설정 및 관계 구조

요약:
본 기록은 시스템의 각 구성요소가 독립 서비스로 전환된 이후, 실제 운영 환경에서 안정적으로 동작하기 위해 설정된 구조와 관계를 다룬다. 모든 조정은 AI 에이전트 중심으로 이루어졌으며, 인프라 운영자의 수동 개입은 최소화되었다. 각 서비스 간의 데이터 연계, 글로벌 동기화, 캐시 구조, 그리고 AI 기반 검증 체계에 대해 실제 업무 진행 순서대로 기술한다.

1. 초기 상태 점검 및 서비스 간 데이터 경로 정의

프로젝트는 MCP 내부 서비스가 물리적으로 분리된 시점에서 시작되었다. 서비스는 정상적으로 기동되었지만, Redis와 MQ 사이의 데이터 경로가 불완전했다. 일부 이벤트는 발행되었으나 소비자 함수가 인식하지 못했고, 캐시 무효화 시점이 불일치했다.

문제의 원인은 큐 이름 충돌이었다. 6월 구조에서는 모든 이벤트가 default 토픽에 쌓였기 때문에, 이벤트 종류별 처리 우선순위를 분리할 수 없었다. 우리는 LavinMQ의 라우팅 키 구조를 다시 정의했다. 서비스 도메인별로 큐를 분리하여 이벤트 흐름을 시각적으로 구분했다.

product.* → Translator-Agent
session.* → Auth-Service / Redis Sync
cache.*   → Cloud Function(Cache Invalidator)
log.*     → Ops-Agent

이 설정을 적용한 후, MQ 메시지 지연은 평균 80ms 수준으로 안정화되었고, 이벤트 충돌 비율이 0.2% 미만으로 감소했다. 기존 수동 모니터링 대신 Ops-Agent가 주기적으로 큐 상태를 수집하고, 누락 이벤트가 10건 이상일 경우 자동 재전송하도록 설정했다.

2. Redis 세션 구조 재정의 및 글로벌 동기화 검증

세션 동기화는 두 리전(HK ↔ KR) 간 복제에서 가장 자주 문제가 발생하는 구간이었다. Redis의 async replication은 쓰기 폭주 시 레이턴시가 발생했고, 한쪽 리전의 TTL이 먼저 만료되는 현상이 있었다. 이를 완화하기 위해, Cloud Function을 이용한 세션 복제 검증 루프를 추가했다.

def verify_session_consistency():
    hk_keys = redis_hk.keys("SESSION:*")
    for key in hk_keys:
        data_hk = redis_hk.get(key)
        data_kr = redis_kr.get(key)
        if data_kr != data_hk:
            redis_kr.set(key, data_hk, ex=1800)
            publish("sync.repair", {"key": key})

AI Ops-Agent가 1시간 단위로 세션 일치율을 계산해 Telegram으로 보고한다. 초기에는 약 92% 수준이었으나, Function 병렬 처리 스케줄을 5분 단위로 조정한 후 99.4%까지 상승했다. Cloud Function은 평균 180ms 내에 모든 보정 작업을 완료했다.

3. COS 연동 및 프런트엔드 CDN 동기화 테스트

COS는 이미지 저장뿐 아니라 정적 자산 배포에도 사용된다. 처음에는 프런트엔드 빌드 파일과 상품 이미지가 같은 버킷에 업로드되어 캐시 갱신 시점이 어긋났다. 이로 인해 신규 빌드 후에도 사용자 브라우저가 구 버전 파일을 참조하는 현상이 발생했다.

해결책으로 정적 자산과 이미지 자산을 물리적으로 분리했다. 정적 자산은 cos://reindeers-cdn/site/, 이미지는 cos://reindeers-cdn/images/에 저장된다. CDN은 Tencent Global Accelerator를 사용해 국가별 edge cache를 분리하였고, Cache-Control 헤더를 자동 삽입하도록 Cloud Function을 확장했다.

on_file_upload(event):
    key = event["key"]
    if key.startswith("site/"):
        set_header("Cache-Control", "max-age=300, must-revalidate")
    elif key.startswith("images/"):
        set_header("Cache-Control", "max-age=604800, immutable")

빌드 후 프런트엔드 응답 캐시는 5분, 이미지 캐시는 7일로 조정되었고, 실시간 무효화는 Telegram 명령 /imagepurge로 수행된다.

4. AI 에이전트 협업 구조 조정

Translator-Agent와 Classifier-Agent가 동시에 MQ에 접근하는 과정에서 경쟁 상태가 보고되었다. 상품이 등록될 때 번역과 카테고리 분류가 동시에 실행되면 DB write lock이 충돌했다. 이를 해결하기 위해 “transactional queue” 개념을 도입했다. 같은 상품 ID의 이벤트는 동일한 라우팅 그룹에서만 처리되도록 설정했다.

routing_key = f"product.{event['id'] % 100}"
mq.basic_publish(exchange="amq.topic", routing_key=routing_key, body=json.dumps(event))

Translator-Agent는 우선순위가 낮은 queue에서 후순위로 처리되어 Classifier-Agent의 처리를 기다린다. AI 간의 충돌을 사람이 조정하지 않아도 되도록 학습된 rule set을 제공했고, 충돌 횟수는 하루 평균 40회에서 3회로 감소했다.

5. 로컬스토리지 세션 관리 및 클라이언트 동기화 검증

클라이언트 단의 세션은 LocalStorage를 기반으로 관리되며, 브라우저 간 동기화 이벤트를 사용해 여러 탭에서 자동 반영된다. 토큰 만료 시 자동 로그아웃 기능을 검증하기 위해 500회 이상의 시뮬레이션을 수행했다. 브라우저 탭 3개를 동시에 열고 로그인 → 토큰 만료 후 → Refresh Token을 재발급하는 시나리오를 반복 테스트했다.

window.addEventListener("storage", (e) => {
  if (e.key === "reindeers.access" && !e.newValue) {
    logout()
  }
})

Refresh Token이 만료될 때 다른 탭의 로그아웃 이벤트가 1초 이내에 반영되는 것을 확인했다. 실패 케이스 7건은 Safari 브라우저의 storage event 비동기 처리 문제였으며, 해당 브라우저는 폴링 방식으로 우회 처리했다.

6. Cloud Function 자동화 및 에러 회복 루틴

7월 중순 이후 MQ 처리량이 급격히 증가하면서 Cloud Function의 cold start 지연이 누적되었다. 평균 응답 지연은 400ms, 피크 타임에는 1.2초까지 늘었다. 이를 해결하기 위해 Functions Framework의 warm pool을 고정 풀(5개 인스턴스)로 지정하고, AI Ops-Agent가 10분 단위로 Function 상태를 점검해 자동 재시작하도록 했다.

if latency_avg > 800:
    publish("function.restart", {"name": "cache_invalidator"})
    send_telegram("⚠️ Function latency high, restart triggered")

재시작 루틴은 수동 개입 없이 작동했으며, 전체 처리량은 40% 향상되었다. 에이전트는 에러 패턴을 학습하여 비슷한 유형의 장애를 사전에 예측하도록 개선 중이다.

7. 결론 및 현재 상태

시스템은 완전히 자동화된 상태로 전환되었다. MQ 이벤트, 세션 복제, 캐시 무효화, 이미지 배포, Function 모니터링까지 모든 과정이 AI 에이전트에 의해 수행된다. 사람은 Telegram 리포트를 통해 결과만 확인한다.

주요 지표:

세션 일치율 99.4%
큐 누락 이벤트 0.18%
Function cold start 지연 75% 감소
AI 자동 조정 성공률 97%

이 기록을 기준으로 이후 단계에서는 Translator-Agent의 품질 검증과 카테고리 자동화 재구성으로 발전시킬 예정이다.

Blog of Reindeers

Search This Blog