시스템 설정 및 관계 구조

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

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

문제의 원인은 큐 이름 충돌이었다. 기존 구조에서는 모든 이벤트가 default 토픽에 쌓였기 때문에, 이벤트 종류별 처리 우선순위를 분리할 수 없었다. 세션 동기화 이벤트와 상품 번역 이벤트가 같은 큐에서 경쟁하면서 지연과 이벤트 유실이 발생했다.

LavinMQ의 라우팅 키 구조를 다시 정의했다. 서비스 도메인별로 큐를 분리하여 이벤트 흐름을 명확히 구분했다.

product.*  → Translator-Agent, Classifier-Agent
session.*  → Auth-Service / Redis Sync
cache.*    → Cloud Function (Cache Invalidator)
log.*      → Ops-Agent
order.*    → Order-Service / Notification
schedule.* → Logistics Scheduler

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

2. 5개 플랫폼의 설정 관리 구조

REINDEERS는 5개의 플랫폼(Trade, Logistics, Workflow, Document AI, Delivery)을 운영한다. 각 플랫폼은 독립 배포되지만, 공통 설정과 개별 설정을 모두 가지고 있다. 예를 들어 Redis 접속 정보는 공통이지만, API Rate Limit이나 파일 업로드 최대 크기는 플랫폼별로 다르다.

설정은 3단계 계층 구조로 관리된다.

Global Config: 모든 플랫폼에 적용되는 공통 설정. DB 접속, Redis, MQ, CDN 경로 등.
Platform Config: 플랫폼별 고유 설정. Rate Limit, 기능 플래그, UI 설정 등.
Tenant Config: 파트너(조직)별 개별 설정. 언어 선호, 통화 기본값, 알림 채널 등.

설정 값을 조회할 때는 Tenant → Platform → Global 순서로 탐색하며, 가장 먼저 발견된 값이 적용된다. 이 "Override Chain" 구조 덕분에 특정 파트너에게만 특별한 설정을 적용하면서도 기본값은 플랫폼 또는 글로벌 수준에서 관리할 수 있다.

def get_config(key, org_id=None, platform=None):
    if org_id:
        val = redis.get(f"config:tenant:{org_id}:{key}")
        if val: return val
    if platform:
        val = redis.get(f"config:platform:{platform}:{key}")
        if val: return val
    return redis.get(f"config:global:{key}")

설정 변경 시에는 MQ를 통해 config.updated 이벤트가 발행되어 모든 서비스 인스턴스가 즉시 새 설정을 반영한다. 서비스를 재시작할 필요가 없다.

3. 파트너 관계 데이터 모델

REINDEERS 플랫폼의 핵심은 "관계"다. 바이어(Buyer), 공급사(Vendor), 포워더(Forwarder)가 서로 연결되어 견적, 주문, 배송, 정산이라는 비즈니스 흐름을 만든다. 이 관계를 데이터로 어떻게 표현하느냐가 시스템 설계의 핵심이었다.

파트너 관계는 partner_relationship 테이블로 관리된다. 한 조직이 다른 조직과 맺는 관계는 유형(type)과 상태(status)로 구분된다.

CREATE TABLE partner_relationship (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  from_org_id BIGINT NOT NULL,
  to_org_id BIGINT NOT NULL,
  type ENUM('BUYER_VENDOR','BUYER_FORWARDER','VENDOR_FORWARDER') NOT NULL,
  status ENUM('PENDING','ACTIVE','SUSPENDED','TERMINATED') DEFAULT 'PENDING',
  created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
  FOREIGN KEY (from_org_id) REFERENCES organization(id),
  FOREIGN KEY (to_org_id) REFERENCES organization(id),
  UNIQUE (from_org_id, to_org_id, type)
);

관계가 ACTIVE 상태일 때만 두 조직 간 거래가 가능하다. 바이어가 공급사에게 견적을 요청하려면 먼저 BUYER_VENDOR 관계가 활성화되어 있어야 한다. 포워더가 배송을 처리하려면 바이어 또는 공급사와 FORWARDER 관계가 성립되어야 한다.

이 구조는 단순한 참조 무결성을 넘어 비즈니스 규칙을 데이터 수준에서 강제한다. 관계가 TERMINATED로 변경되면 해당 조직 간의 모든 미완료 주문이 자동으로 보류 상태로 전환되고, 운영자에게 Telegram 알림이 발송된다.

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

세션 동기화는 두 리전(HK ↔ KR) 간 복제에서 가장 자주 문제가 발생하는 구간이었다. Redis의 비동기 복제는 쓰기 폭주 시 레이턴시가 발생했고, 한쪽 리전의 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})

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

5. COS 연동 및 프런트엔드 CDN 동기화

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

해결책으로 정적 자산과 이미지 자산을 물리적으로 분리했다. 정적 자산은 cos://reindeers-cdn/site/, 이미지는 cos://reindeers-cdn/images/에 저장된다. CDN은 글로벌 가속기를 사용해 국가별 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로 수행된다.

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

Translator-Agent와 Classifier-Agent가 동시에 MQ에 접근하는 과정에서 경쟁 상태(Race Condition)가 보고되었다. 상품이 등록될 때 번역과 카테고리 분류가 동시에 실행되면 DB write lock이 충돌했다.

이를 해결하기 위해 "transactional queue" 개념을 도입했다. 같은 상품 ID의 이벤트는 동일한 라우팅 그룹에서만 처리되도록 설정했다. Translator-Agent는 우선순위가 낮은 큐에서 후순위로 처리되어 Classifier-Agent의 처리를 기다린다.

# 상품 ID 기반 라우팅으로 동일 상품의 이벤트를 직렬화
routing_key = f"product.{event['id'] % 100}"
mq.basic_publish(exchange="amq.topic", routing_key=routing_key, body=json.dumps(event))

AI 간의 충돌을 사람이 조정하지 않아도 되도록 rule set을 제공했고, 충돌 횟수는 하루 평균 40회에서 3회로 감소했다. 이벤트 순서가 보장되면서 데이터 정합성도 함께 개선되었다.

7. 설정 변경 감사와 운영 투명성

시스템 설정은 운영의 근간이므로 모든 변경은 감사 로그에 기록된다. 누가, 언제, 어떤 설정을, 어떤 값에서 어떤 값으로 변경했는지가 config_audit_log 테이블에 저장된다.

설정 변경이 감지되면 Telegram으로 즉시 알림이 발송되며, 운영자는 /config history 명령으로 최근 변경 이력을 조회할 수 있다. 의도치 않은 설정 변경이 발견되면 /config revert 명령으로 이전 값으로 되돌릴 수 있다. 이 구조는 멀티 테넌트 환경에서 설정 실수로 인한 장애를 최소화한다.

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

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

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

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

9. 결론 및 현재 상태

시스템 설정과 관계 구조는 REINDEERS 플랫폼의 기반 인프라다. 5개 플랫폼의 설정이 3단계 계층으로 통합 관리되고, 4,300개 이상의 파트너 관계가 데이터 수준에서 비즈니스 규칙을 강제한다. MQ 이벤트, 세션 복제, 캐시 무효화, CDN 배포, Function 모니터링까지 모든 과정이 자동화되어 있으며, 사람은 Telegram 리포트를 통해 결과만 확인한다.

주요 지표:

세션 일치율: 99.4%
큐 누락 이벤트: 0.18%
Function cold start 지연: 75% 감소
설정 변경 반영 시간: 평균 200ms
AI 에이전트 간 충돌: 하루 3건 이하

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

Blog

Search This Blog