Skip to main content

이미지 최적화와 COS 기반 CDN 자동화

1. 문제 인식 — 이미지 트래픽과 품질의 불균형

8월 초, 상품 이미지 요청량이 하루 평균 1200만 건을 넘어서면서 CDN 트래픽 비용이 급격히 증가했다. 원인은 대부분 비효율적인 이미지 크기와 중복 요청이었다. 크롤링 단계에서 원본 이미지는 고해상도 상태로 저장되었고, 프런트엔드는 단일 사이즈 이미지를 모든 기기에서 공통 사용했다.

REINDEERS 플랫폼에는 4,300개 이상의 파트너사가 등록되어 있고, 각 공급사가 올리는 상품 이미지는 평균 5~8장이다. 이 이미지들이 바이어 2,500개 이상의 검색과 조회를 통해 요청되면서 트래픽이 기하급수적으로 증가했다. 특히 태국, 말레이시아, 중국 등 여러 국가에서 동시에 접속하는 구조이기 때문에 지역별 CDN 분산도 필수였다.

초기에는 Cloud Function을 이용한 이미지 리사이징 API를 직접 운영했으나, 처리량 대비 비용이 높고, 콜드 스타트 지연이 잦았다. 평균 응답 시간이 200ms를 넘었고, 동시 요청이 몰리는 시간대에는 500ms까지 치솟았다. 따라서 Tencent COS의 내장 이미지 처리 기능을 이용한 서버리스 구조로 전환하기로 결정했다.

2. COS 서버리스 이미지 처리 구조 설계

COS(Cloud Object Storage)는 별도의 서버나 Lambda 없이도 URL 파라미터 기반으로 이미지 변환을 수행할 수 있다. 이 기능을 이용하면 단 한 번의 업로드로 모든 변환 버전을 실시간으로 생성할 수 있다. 예를 들어, 800x800 썸네일을 webp로 변환하려면 다음과 같이 요청한다. 

https://cdn.reindeers.com/images/p/12345.jpg?imageMogr2/thumbnail/800x800/quality/90/format/webp

COS는 이 요청을 받아 즉시 리사이징, 포맷 변환, 품질 조정 후 CDN 캐시에 저장한다. 원본 이미지는 절대 변경되지 않는다. 변환된 결과는 글로벌 CDN Edge에 7일간 캐싱되며, 다음 요청 시 캐시 적중률은 98% 이상으로 유지된다.

이 구조의 가장 큰 장점은 서버 측 코드가 전혀 필요 없다는 점이다. URL 파라미터만으로 변환 옵션을 지정하기 때문에 프런트엔드 개발자가 독립적으로 이미지 최적화를 제어할 수 있다. 백엔드 배포 없이도 새로운 이미지 사이즈를 즉시 적용할 수 있는 유연성이 확보되었다.

3. 프런트엔드 및 업로드 프로세스 변경

기존에는 개발자가 업로드 단계에서 직접 썸네일 파일을 생성했다. 7월 말부터 이 과정을 완전히 제거했다. 프런트엔드가 COS에 이미지를 업로드하면, 단순히 원본만 저장하고, 모든 변환은 런타임 요청 시 파라미터로 수행되도록 구조를 변경했다. 이전에는 업로드 시 4종류(원본, 대형, 중형, 소형)의 파일을 생성했는데, 이를 원본 1종류로 줄임으로써 스토리지 사용량이 즉시 60% 이상 감소했다. 

from qcloud_cos import CosConfig, CosS3Client

cfg = CosConfig(Region="ap-hongkong",
                SecretId=os.getenv("COS_SECRET_ID"),
                SecretKey=os.getenv("COS_SECRET_KEY"))
client = CosS3Client(cfg)

def upload_image(local_path, remote_key):
    client.upload_file(
        Bucket="reindeers-cdn-125xxxxxx",
        LocalFilePath=local_path,
        Key=remote_key
    )
    return f"https://cdn.reindeers.com/{remote_key}"

업로드 후 프런트엔드는 다음과 같은 형태로 이미지를 요청한다.

  • 리스트뷰: ?imageMogr2/thumbnail/400x400/quality/85/format/webp
  • 상세뷰: ?imageMogr2/thumbnail/800x800/quality/90/format/webp
  • 줌뷰: ?imageMogr2/thumbnail/1600x1600/quality/95

각 요청은 클라이언트 디바이스 해상도와 네트워크 속도에 따라 동적으로 선택된다. 모바일 환경에서는 자동으로 낮은 품질 버전으로 전환된다. Next.js의 Image 컴포넌트에서 srcSet을 동적으로 구성하여 각 뷰포트에 맞는 최적 사이즈를 자동 로딩하도록 설정했다.

4. AI 에이전트 기반 품질 검사 루프

COS는 이미지 처리 자체는 자동이지만, 변환 품질 검증은 별도의 루틴이 필요했다. 특히 원본 이미지 자체의 품질이 낮은 경우(공급사가 저해상도 이미지를 업로드한 경우), 리사이징 후 품질이 심하게 저하되는 문제가 있었다. Classifier-Agent의 서브 모듈로 "Image-Inspector-Agent"를 추가하여 이미지 품질을 주기적으로 분석했다. 이 에이전트는 샘플 이미지를 주기적으로 다운로드하여 압축 노이즈, 색상 왜곡, 비율 손실 등을 검사한다. 

def inspect_image(url):
    img = download(url)
    score = quality_estimator(img)
    if score < 0.8:
        publish("image.reprocess", {"url": url, "score": score})
    return score

평균 품질 점수는 0.92 이상을 유지했으며, 0.8 이하로 평가된 이미지는 자동으로 재처리 큐에 등록되었다. 재처리 시에는 해상도나 품질 파라미터를 동적으로 조정하여 새로운 CDN 버전을 생성했다. 품질 검증 루프는 AI Ops-Agent가 매일 03:00 UTC에 실행한다. 검사 대상은 전체 이미지가 아니라 최근 24시간 내 업로드되거나 변경된 이미지 중 무작위 샘플 500건이다. 전수 검사는 주 1회 실행된다.

5. CDN 캐시 관리 및 무효화 정책

COS에 저장된 이미지가 갱신되면 CDN 캐시가 즉시 무효화되어야 했다. 공급사가 상품 이미지를 교체하거나, AI가 품질 문제로 재처리한 경우에 해당한다. 초기에는 Cloud Function을 수동 호출했으나, 8월 중순 이후 MQ 기반 자동화가 적용되었다. image.updated 이벤트가 발행되면, Cloud Function이 해당 경로의 캐시를 무효화한다. 

def purge_cdn_cache(event):
    key = event["key"]
    region = event.get("region", "ap-hongkong")
    requests.post(
        f"https://api.cdn.tencent.com/purge",
        json={"path": key, "region": region}
    )
    log.info(f"Cache purged: {key}")

관리자나 운영자는 Telegram에서 /imagepurge <path> 명령을 입력하면 동일한 프로세스가 수동으로 트리거된다. 자동 캐시 무효화 성공률은 99.6%로 측정되었고, 수동 명령은 디버깅 시에만 사용되었다. 캐시 무효화 후 새로운 버전의 이미지가 CDN Edge에 전파되기까지의 평균 소요 시간은 약 3초였다.

6. 글로벌 트래픽 분산 및 비용 분석

CDN 설정 이후, 트래픽은 지역별로 분산되었다. 홍콩 리전 41%, 서울 27%, 싱가포르 18%, 기타 14%로 분포되었으며, 전체 전송량은 34TB에서 22TB로 감소했다. 이는 중복 요청 제거와 WebP 포맷 전환 덕분이었다. WebP 포맷은 JPEG 대비 평균 30~40% 작은 파일 크기를 제공하면서도 화질 차이는 거의 느낄 수 없는 수준이다.

또한 AI가 자동으로 품질/용량을 조정함으로써 COS 스토리지 비용이 17% 절감되었다. 홍콩 리전의 트래픽 비중이 가장 높은 이유는 메인 서버가 홍콩에 위치하고 태국과 중국 사용자가 이 리전에서 가장 낮은 지연 시간을 경험하기 때문이다. 서울 리전은 한국 바이어 트래픽을, 싱가포르 리전은 말레이시아 사용자 트래픽을 주로 처리한다.

비용 절감 효과를 구체적으로 보면, CDN 트래픽 비용은 전송량 감소에 비례하여 약 35% 줄었고, 스토리지 비용은 원본만 보관하는 방식 전환으로 17% 절감되었다. Cloud Function 호출 비용은 COS 내장 처리로 대체되면서 거의 0에 수렴했다. 전체적으로 이미지 관련 인프라 비용이 월 기준 40% 이상 감소한 것으로 집계되었다.

7. 오류 검출 및 복구 자동화

8월 25일, COS 내부 장애로 인해 일부 리사이즈 요청이 실패했다. Image-Inspector-Agent가 응답 코드 500을 2분 내 감지했고, Ops-Agent가 /cdn retry 명령을 자동으로 호출했다. 이후 Cloud Function이 큐를 재처리하여 약 15분 만에 정상화되었다. 재처리 로그는 Telegram에 실시간으로 전송되었다.

이 사건 이후 장애 감지 기준을 강화했다. HTTP 5xx 응답이 1분 내 10건 이상 발생하면 자동 알림이 트리거되고, 30건 이상이면 Ops-Agent가 자동 재처리를 시작하도록 임계값을 조정했다. 또한 COS 장애 시 원본 이미지 URL로 자동 폴백하는 로직을 프런트엔드에 추가하여, 이미지 처리 서비스가 완전히 다운되더라도 원본 이미지는 표시되도록 했다.

8. 결과 및 안정화 이후 구조

COS 기반 이미지 자동화 시스템 도입 이후, 서버 부하 없이도 고해상도 이미지를 실시간 변환/배포할 수 있게 되었다. AI 에이전트는 이미지 품질을 감시하며, 문제 발생 시 재처리 명령을 스스로 내린다. 관리자 개입은 거의 없으며, Telegram 리포트만으로 전체 상태를 파악할 수 있다.

현재 기준 주요 지표는 다음과 같다.

  • 이미지 품질 점수 평균 0.92
  • CDN 캐시 적중률 98.4%
  • Cloud Function 호출 지연 200ms에서 80ms로 개선
  • 스토리지 비용 17% 절감
  • 트래픽 전송량 34TB에서 22TB로 감소 (35% 절감)
  • 업로드 파일 수 75% 감소 (4종에서 1종으로)

이 구조는 단순 최적화 단계를 넘어, "데이터 자체가 스스로 품질을 유지하는 시스템"으로 진화했다. 이미지 업로드부터 CDN 배포, 품질 감시, 캐시 무효화, 장애 복구까지 전 과정이 자동화되어 있으며, 사람은 Telegram 대시보드로 상태만 확인하면 된다. 이후 단계에서는 이미지 데이터에 포함된 시각적 특징을 기반으로 상품 속성 자동 추출을 도입할 계획이다. 공급사 1,800개 이상이 등록한 상품 이미지에서 소재, 색상, 크기 등의 속성을 자동으로 추출하여 카탈로그 품질을 향상시키는 것이 다음 목표다.

관련 글

Labels:

Popular posts from this blog

11년의 무역 데이터가 AI를 만든다 , RAG 지식 베이스 구축 과정

AI를 제품에 넣겠다고 하면 대부분 두 가지 중 하나를 떠올린다. GPT를 fine-tuning하거나, RAG를 쓰거나. 우리는 RAG를 택했다. 이유가 있다. REINDEERS는 2015년 IMARKET Thailand 설립 이후 약 11년간 동남아시아에서 B2B 무역을 해왔다. 25,000건 이상의 거래, 4,300개 이상의 파트너, 4개국의 규제 데이터. 이 데이터가 우리의 경쟁력이다. 문제는 이 데이터를 AI가 활용할 수 있는 형태로 만드는 과정이 생각보다 훨씬 복잡했다는 거다. 이 글은 그 과정에 대한 기록이다. 한 가지를 먼저 밝히고 시작한다. 이 RAG 지식 베이스는 단순히 "챗봇이 무역 지식을 참조하는 데이터 창고"가 아니다. REINDEERS와 POP, DVRP는 지금 AI로 전환되는 구조 위에 올라서 있다. 사람은 전략과 방향을 결정하고, 실제 업무는 조직도 안에 등록된 AI Agent가 수행한다. 이 Agent들 , 구매 Agent, 물류 Agent, 통관 Agent, 재무 Agent , 이 사람 대신 판단을 내릴 때 "왜 이렇게 결정했는가"를 반드시 설명할 수 있어야 한다. 그 설명의 출처가 바로 이 RAG 지식 베이스다. 11년의 무역 데이터는 Agent가 환각 없이 결정을 내릴 수 있는 유일한 근거다. RAG를 선택한 이유 먼저 RAG(Retrieval-Augmented Generation)가 뭔지를 간단히 정리하자. LLM에 질문을 던질 때, 질문만 보내는 게 아니라 관련 데이터를 함께 보내는 방식이다. "태국산 베어링 수입 단가가 얼마야?"라고 물으면, 우리 데이터베이스에서 관련 거래 이력을 찾아서 LLM에 컨텍스트로 넘긴다. LLM은 그 컨텍스트를 바탕으로 답을 생성한다. Fine-tuning을 선택하지 않은 이유는 명확하다. 무역 데이터는 계속 바뀐다. 베어링 단가는 분기마다 변동한다. 태국 FDA 규제는 수시로 개정된다. 선사 운임은 매...
Read more

B2B 견적의 AI Agent화 , 고객사·공급사·포워더가 AI로 견적을 주고받는 구조

B2B 거래에서 견적은 단순한 가격표가 아니다. 바이어의 구매 이력, 공급사의 재고 상황, 물류 비용, 인코텀즈, 납기일, 결제 조건 , 이 모든 변수가 얽힌 협상의 산물이다. 현재 이 과정은 이메일과 전화, 스프레드시트로 이루어진다. 바이어가 RFQ를 보내면 공급사가 검토하고, 포워더에게 물류 견적을 받아 합산하고, 다시 바이어에게 회신한다. 건당 수일이 걸리는 이 과정을 AI Agent가 대신할 수 있다면 어떨까. REINDEERS는 이 구조를 설계하고 있다. 먼저 이 글의 전제를 분명히 한다. REINDEERS·POP·DVRP는 지금 AI로 전환되는 구조 위에 올라서 있다. 조직도 안에서 직원을 등록할 때 '사람', 'AI Agent', '로봇' 중에서 선택할 수 있고, 사람은 전략과 방향을 결정하고, 실제 업무는 조직도 안에 등록된 AI Agent가 수행한다. 이 글의 Buyer Agent / Supplier Agent / Forwarder Agent는 외부 AI 도구가 아니라, 각 회사의 조직도 안에 '구매팀 담당자', '영업팀 담당자', '물류팀 담당자'로 실제 등록되는 AI 직원이다. 사람 직원과 동일한 권한 모델, 동일한 예산 한도, 동일한 감사 로그 위에서 일한다. B2B 견적의 AI Agent 간 통신 시퀀스 # Buyer Agent → Supplier Agent → Forwarder Agent 1 RFQ 발송 → RFQ 수신 2 물류 견적 요청 → 요청 수신 3 견적 수신 ← 상품 견적 발송 4 물류 견적 수신 ← 물류 견적 발송 ★ 비교표 생성 → 담당자 승인 5 PO 발행 → 주문 확정 6 부킹 요청 → 부킹 확정 왜 견적에 AI Agent인가 견적 업무가 느린 이유는 복잡해서가 아니다. 반복적인 정보 수집과 조합이 사람의 시간을 잡아먹기 때문이다. 공급사 담당자가 바이어의 과거 주문 이력을 ...
Read more

Reindeers Workflow: B2B 파트너 업무 효율과 자동화를 위한 워크플로우 플랫폼

B2B 국제 무역에서 하나의 거래가 완료되기까지 관여하는 시스템과 사람의 수는 예상보다 훨씬 많다. 견적 요청에서 시작해 공급사 선정, 발주, 포워딩 비딩, 통관 서류 준비, 출하, 배송, 정산까지 — 각 단계마다 서로 다른 담당자가 서로 다른 도구에서 수작업을 반복한다. 이 현장에서 반복적으로 발생하는 비효율은 분명하다. 바이어가 견적을 확정하면 공급사에게 이메일이나 메신저로 직접 통보해야 하고, 결제가 완료되면 수동으로 정산 시트에 옮기면서 1~3일이 소요된다. 출하 후에는 선적 정보를 기반으로 CI, PL, CO를 수동 생성하며 누락이 발생하고, 배송 완료 후 공급사/포워더 정산을 수작업으로 대조하면서 오차가 누적된다. ERP, 이메일, 스프레드시트, CRM에 같은 데이터를 반복 입력하는 것도 일상이다. 이 문제들의 공통점은 명확하다. "이벤트가 발생했을 때 후속 작업이 자동으로 실행되지 않는다" 는 것이다. 견적이 확정되었다는 '사실'은 시스템에 기록되지만, 그 사실이 다음 단계의 업무를 자동으로 트리거하지는 않는다. Reindeers Workflow는 이 문제를 해결하기 위해 만들어졌다. 단순히 "자동화 도구를 제공한다"가 아니라, REINDEERS 플랫폼에서 발생하는 실제 거래 이벤트를 기반으로 후속 업무가 자동 실행되는 구조를 만드는 것이다. REINDEERS 플랫폼과의 연결: 거래 이벤트가 워크플로우를 트리거한다 Reindeers Workflow의 가장 중요한 차별점은 범용 자동화 도구가 아니라 REINDEERS 본 플랫폼의 거래 이벤트에 직접 연결 된다는 것이다. REINDEERS에서 발생하는 핵심 거래 이벤트가 MQ(Message Queue)를 통해 워크플로우의 트리거가 된다. 거래 이벤트 트리거되는 워크플로우 실행 내용 quote.confirmed 공...
Read more