AI 작업 큐 도입 판단

1. 결론

V2 AI 작업에는 Amazon SQS Standard + DLQ를 도입한다.

• 월 작업량 300만 건은 SQS가 필요할 만큼 큰 처리량이 아니다.
• 큐를 선택하는 이유는 장시간 AI 작업을 HTTP 요청에서 분리하고, 작업을 보존·재시도하기 위해서다.
• 큐가 없으면 요구하는 AI 기능을 안정적으로 제공할 수 없다고 가정한다.
• AI 기능이 기여하는 월 매출 4,500만 원이 큐의 첫해 월평균 총비용 125만 원보다 크다.
• 기존 MySQL 작업 테이블과 첫해 월평균 비용 차이는 약 7만 원으로 크지 않다.
• 비용이 비슷한 상황에서 작업 보존·재전달·DLQ를 관리형으로 제공하고 주문·결제 DB와 장애 범위를 분리할 수 있어 SQS를 선택한다.
• SQS Standard로 요구사항을 충족하므로 FIFO, Redis·Valkey, RabbitMQ, Amazon MQ, Kafka·MSK는 검토하지 않는다.

큐 도입의 월 순효과
= 큐가 보호하는 AI 기능 매출 - SQS 첫해 월평균 총비용
= 45,000,000원 - 1,250,000원
= 43,750,000원

따라서 큐 도입과 SQS 선택 모두 비용 대비 효과가 있다.

2. 의사결정 가정

실제 운영 이력이 없는 V2에서 결론을 내리기 위해 다음 값을 고정한다.

항목	적용값	사용 이유
DAU	100,000명	App·DB 인프라 문서와 동일한 V2 목표 기준
사용자당 AI 작업	하루 1건	기능 사용 가정
월 AI 작업	3,000,000건	100,000명 × 30일
월 매출	150,000,000원	제휴수수료 매출 기준
AI 기능의 매출 기여율	30%	전체 매출이 AI에 의존한다는 과대평가 방지
AI 기능 기여 매출	45,000,000원/월	150,000,000원 × 30%
AI 작업 특성	HTTP Timeout을 넘을 수 있음	비동기 실행이 필요한 조건
작업 보존	BE 재시작 후에도 필요	메모리 큐 제외 근거
재시도	일시 장애 시 필요	내구성 있는 큐 필요 근거
작업 인력	신입 주니어 개발자 2명	큐 운영 경험과 재사용 모듈이 없다고 가정
개발자 비용	1명당 시간당 30,000원	1명당 연간 회사 부담 비용 6,000만 원, 연 2,000시간 기준
비용 계산기간	12개월	최초 구현비를 12개월로 나누어 계산
메시지 크기	64 KiB 이하	SQS 요청 1회로 계산
AWS 리전	서울	서비스 배치 기준
환율	1달러당 1,378.04원	DB 인프라 문서와 동일한 비교 기준
SQS 예산	최대 10,000원/월	기본 요청 약 4,600원에 재시도·가시성 연장·DLQ 요청 여유 포함

AI 모델 호출비와 AI Worker 컴퓨팅 비용은 모든 대안에 공통으로 발생하므로 비교에서 제외한다.

큐가 없더라도 AI 기능 일부를 제공할 수 있다면 큐가 회복하는 매출 비율을 별도로 측정해야 한다. 이 문서에서는 장시간 실행, 작업 보존과 재시도가 제품 요구이므로 내구성 있는 큐가 없으면 AI 기능을 출시할 수 없다고 가정한다.

3. 판단 순서

내구성 있는 큐 자체가 필요한가?
  ↓ 비용 대비 효과 있음
최소 요구를 만족하는 구현은 무엇인가?
  ↓ SQS Standard + DLQ
순서 보장·AMQP·장기 재생 같은 상위 요구가 있는가?
  ↓ 없음
상위 사양 비교를 중단

각 단계에서 줄어드는 손실이 추가비용보다 작으면 다음 단계로 넘어가지 않는다.

4. 작업량과 SQS 비용

4.1 작업량

월 AI 작업
= 100,000명 × 30일 × 1건
= 3,000,000건

평균 처리량
= 3,000,000건 ÷ 30일 ÷ 24시간 ÷ 3,600초
= 초당 약 1.16건

초당 약 1.16건은 처리량 때문에 별도 메시징 시스템이 필요한 규모가 아니다. 큐 도입 근거는 처리량이 아니라 비동기 처리, 작업 보존과 장애 격리다. 다만 하루 평균만으로 Worker 수를 결정하지 않고 실제 시간대별 집중률과 AI 작업시간을 부하 시험으로 확인한다.

4.2 SQS 요청량

메시지마다 전송, 수신, 삭제를 한 번씩 수행한다고 가정한다.

기본 SQS 요청
= 3,000,000건 × 3회
= 9,000,000회/월

SQS는 월 100만 회의 무료 요청을 제공한다. Worker 2대가 최대 20초 Long Polling을 사용하면 작업이 없을 때 발생할 수 있는 빈 수신은 월 최대 약 25만 9,200회다.

빈 수신 요청 상한
= Worker 2대 × 분당 3회 × 43,200분
= 259,200회/월

기본 요청 + 빈 수신
= 9,000,000회 + 259,200회
= 9,259,200회/월

월 무료 요청 100만 회를 제외하면 과금 대상은 약 825만 9,200회다. 서울 리전 SQS Standard의 첫 번째 요금 구간은 100만 요청당 0.40달러이므로 기본 예상비용은 다음과 같다.

SQS 요청비
= 8,259,200회 × 0.40달러 ÷ 1,000,000회
= 약 3.30달러

원화 환산
= 3.30달러 × 1,378.04원
= 약 4,600원/월

실제 요청량에는 처리시간이 긴 작업의 Visibility Timeout 연장, 재시도와 DLQ 이동·재처리가 추가될 수 있다. 따라서 월 SQS 예산은 기본 예상비용의 약 두 배인 10,000원으로 잡는다. 메시지는 64 KiB 이하이고 SQS와 Worker가 같은 리전에 있다고 가정한다. 고객 관리형 KMS Key를 사용할 경우 발생하는 KMS 요청비는 포함하지 않는다.

5. 1단계: 큐 자체가 필요한가

5.1 큐가 없을 때

현재 AI 기능은 다음 요구를 가진다고 가정한다.

• 실행시간이 일반적인 HTTP Timeout보다 길어질 수 있다.
• 사용자가 연결을 끊어도 작업은 계속되어야 한다.
• BE 또는 Worker 재시작 후에도 접수된 작업이 남아야 한다.
• 일시적인 AI 오류는 자동으로 다시 처리해야 한다.
• 반복 실패 작업은 격리하고 확인할 수 있어야 한다.

동기 HTTP 직접 호출과 BE 메모리 큐는 이 요구를 충족하지 못한다. 따라서 큐가 없으면 AI 기능의 매출 기여분을 잃는 것으로 계산한다.

큐가 없을 때 월 손실
= 월 매출 × AI 기능의 매출 기여율
= 150,000,000원 × 30%
= 45,000,000원

5.2 SQS 방식의 구현 작업시간

작업시간은 개발자 2명의 시간을 합산한다. 두 사람이 각각 8시간씩 작업하면 작업시간 합계는 16시간이다.

공통 비동기 처리 구현

작업	2명 작업시간 합계
작업 등록·상태 조회·결과 조회 API	56시간
AI Worker·작업 상태 전이·결과 저장 처리	48시간
멱등 처리·접근 권한·민감정보 보호	32시간
통합·부하 시험·Monitoring·운영절차	40시간
합계	176시간

SQS 전용 구현

작업	2명 작업시간 합계
SQS·DLQ·IAM·암호화·자동 배포 설정	20시간
생산자·소비자·Long Polling·재시도 구현	32시간
Visibility Timeout 연장·AI 오류 분류·호출 제한	32시간
Transactional Outbox·전송 상태·정합성 복구	32시간
Alarm·추적·DLQ 조회와 재처리 기능	16시간
중복 전달·Worker 장애·배포 종료·재전달 시험	20시간
합계	152시간

SQS 방식의 최초 구현시간은 총 328시간이며 개발자 1명당 164시간, 약 20.5근무일이다. 작업 사이의 선후 관계와 검토·수정 시간을 고려하면 실제 완료기간은 약 4~5주로 본다.

최초 구현 인건비
= 328시간 × 30,000원
= 9,840,000원

12개월 월 환산액
= 9,840,000원 ÷ 12개월
= 820,000원/월

5.3 SQS 반복 운영 작업시간

반복 작업	2명 월 작업시간 합계
공통 작업 상태·결과·Worker 점검	4시간
Queue Age·실패율·DLQ Alarm 확인	2시간
DLQ 원인 분석과 재처리 예비시간	4시간
Outbox 정체·재시도·권한 설정 점검	2시간
분기별 장애·부하 시험의 월 환산	2시간
합계	14시간/월

반복 운영 인건비
= 14시간 × 30,000원
= 420,000원/월

5.4 큐 도입 손익

항목	월 비용 또는 손실
최초 구현비 12개월 환산	820,000원
반복 운영 인건비	420,000원
SQS 인프라 예산	10,000원
SQS 첫해 월평균 총비용	1,250,000원
큐가 보호하는 AI 기능 매출	45,000,000원
월 순효과	+43,750,000원

SQS가 AI 기능 기여 매출의 약 2.8% 이상을 회복하면 비용을 회수한다.

손익분기 회복 비율
= 1,250,000원 ÷ 45,000,000원
= 약 2.8%

큐가 없으면 AI 기능을 출시할 수 없다는 현재 가정에서는 회복 비율이 100%이므로 손익분기점을 넘는다.

AI 기능의 매출 기여율 30%는 아직 측정값이 아닌 가정이다. 전체 월 매출을 기준으로 보면 AI 기능의 실제 매출 기여율이 약 0.84% 이상이고 큐가 그 기여분을 보존할 수 있으면 첫해 비용을 회수한다.

전체 매출 기준 손익분기 기여율
= 1,250,000원 ÷ 150,000,000원
= 약 0.84%

따라서 내구성 있는 큐를 도입하고 2단계로 넘어간다.

6. 2단계: 최소 요구를 만족하는 구현 비교

6.1 최소 요구사항

• BE 재시작과 관계없는 작업 보존
• Worker 장애 후 재전달
• 반복 실패 작업의 격리
• 중복 전달에 안전한 멱등 처리
• AI Worker의 독립 확장
• 대기시간, 실패율과 반복 실패 작업의 관측

BE 프로세스 내부의 메모리 큐는 재시작 시 작업이 사라지므로 후보에서 제외한다.

6.2 MySQL 작업 테이블

기존 MySQL을 사용하면 추가 인프라 비용은 거의 없다. 하지만 다음 기능을 직접 만들어야 한다.

• 작업 상태 전이와 재시도 횟수
• 작업을 가져간 Worker의 임대시간과 만료 처리
• 여러 Worker의 잠금 경쟁과 SKIP LOCKED
• Polling 간격과 지수형 대기
• 반복 실패 작업 격리
• 오래된 작업과 결과 정리
• 복구시험과 Monitoring

MySQL 전용 구현시간은 다음과 같이 잡는다.

작업	2명 작업시간 합계
작업 Schema·상태 전이·재시도	32시간
Lease·잠금·SKIP LOCKED·동시 Worker 제어	40시간
Polling·지수형 대기·실패 격리·정리 정책	32시간
장애·복구·동시성·부하 시험	32시간
Monitoring·관리 기능·재처리·권한 설정	24시간
합계	160시간

공통 구현 176시간을 더하면 최초 구현시간은 총 336시간이다. 반복 운영시간은 작업·Worker 점검, 잠금과 오래된 Lease 복구, 실패 작업 재처리, 정리 정책과 장애 시험을 합쳐 월 16시간으로 잡는다.

MySQL 최초 구현비의 월 환산액
= 336시간 × 30,000원 ÷ 12개월
= 840,000원/월

MySQL 반복 운영 인건비
= 16시간 × 30,000원
= 480,000원/월

MySQL 작업 테이블 첫해 월평균 총비용
= 840,000원 + 480,000원
= 1,320,000원

6.3 SQS Standard + DLQ

SQS Standard는 다음 기능을 제공한다.

• 여러 AZ에 메시지 사본 저장
• 최소 1회 전달
• Visibility Timeout 이후 재전달
• DLQ를 통한 반복 실패 작업 격리
• 최대 20초 Long Polling
• 별도 용량 계획 없이 확장

SQS Standard는 메시지가 중복 전달되거나 순서가 바뀔 수 있다. 따라서 job_id를 기준으로 중복 실행의 부작용을 막아야 한다.

6.4 비용 비교

항목	MySQL 작업 테이블	SQS Standard + DLQ
최초 구현시간	336시간	328시간
반복 운영시간	16시간/월	14시간/월
추가 인프라 비용	거의 0원	최대 10,000원/월
첫해 월평균 총비용	1,320,000원	1,250,000원
SQS 대비 차이	+70,000원	기준

월 300만 건, 평균 초당 약 1.16건은 MySQL의 처리 성능만으로 배제할 규모가 아니다. 또한 두 방식의 추정 총비용 차이는 월 7만 원으로 작아 작업시간 오차에 따라 역전될 수 있다.

그럼에도 SQS는 작업 보존·재전달·Visibility Timeout·DLQ를 관리형으로 제공하고 작업 급증과 Worker 장애를 주문·결제 DB에서 분리한다. MySQL 작업 테이블은 작업 처리량과 잠금·Polling 부하를 같은 DB에 추가하고 Lease·실패 격리·정리 정책을 팀이 계속 관리해야 한다.

따라서 가격 차이가 아니라 관리형 복구 기능과 DB 장애 범위 분리를 근거로 최소 요구 구현에 SQS Standard + DLQ를 선택한다.

7. 3단계: 상위 사양이 필요한가

SQS Standard로 해결하지 못하는 요구가 있고, 그 요구로 인한 손실이 추가비용보다 클 때만 상위 사양을 검토한다.

추가 요구	다음 후보	현재 여부	추가 손실 회피액
같은 사용자의 작업을 반드시 순서대로 처리	SQS FIFO	없음	0원
기존 시스템이 AMQP로 통신하며 변경할 수 없음	RabbitMQ·Amazon MQ	없음	0원
큐에서 수 밀리초를 줄이면 매출이 증가함	Redis·Valkey	근거 없음	0원
여러 소비자가 과거 이벤트를 반복해서 읽어야 함	Kafka·Amazon MSK	없음	0원

여기서 AMQP 호환성은 기존 시스템이 AMQP라는 표준 메시지 프로토콜로 연결되어 있어 같은 방식으로 통신해야 한다는 뜻이다. 이벤트 장기 재생은 이벤트를 며칠 또는 몇 달간 순서대로 보관하고, 소비자가 과거 위치부터 다시 읽는 기능을 뜻한다.

현재 AI 작업은 서로 독립적이며 결과는 DB나 Object Storage에 저장한다. AMQP로 연결된 기존 시스템이 없고 과거 이벤트를 다시 읽을 요구도 없다. AI 모델 처리시간에 비해 큐의 수 밀리초 차이가 매출에 영향을 준다는 측정자료도 없다.

상위 사양의 추가 손실 회피액은 0원이고 도입비용은 0원보다 크다. 따라서 비용 대비 효과가 없다.

이에 따라 SQS FIFO, Redis·Valkey, RabbitMQ, Amazon MQ, Kafka·MSK 비교로 넘어가지 않고 검토를 종료한다.

8. 선택 구성

사용자
  ↓
BE
  ↓ 하나의 DB Transaction
DB에 job_id·PENDING 상태와 Outbox Event 저장
  ↓
Outbox Publisher
  ├─ SQS Standard에 job_id 전송
  └─ Outbox 전송 완료 표시
             ↓
          AI Worker
             ↓
          AI 작업 실행
             ↓
   DB 또는 Object Storage에 결과 저장
             ↓
       SQS 메시지 삭제

반복 실패
  ↓
DLQ

구현 원칙은 다음과 같다.

• 메시지에는 Prompt 전체나 결과 대신 job_id와 객체 참조만 넣는다.
• BE는 202 Accepted와 job_id를 반환한다.
• 작업 상태와 Outbox Event를 하나의 DB Transaction에 저장해 DB 저장 후 SQS 전송이 누락되는 문제를 줄인다.
• Outbox Publisher는 미전송 Event를 반복 조회해 SQS로 보내며, 중복 전송을 허용하는 대신 Worker를 멱등하게 구현한다.
• Worker는 Long Polling을 사용한다.
• Visibility Timeout은 정상 처리시간보다 길게 설정하고 필요하면 연장한다.
• 처리에 실패한 메시지는 삭제하지 않아 다시 전달되도록 한다.
• 일정 횟수 이상 실패한 메시지는 DLQ로 이동한다.
• job_id를 중복 처리 방지 기준으로 사용한다.
• 결과 조회는 Polling, SSE 또는 WebSocket 중 제품 요구에 맞게 선택한다.
• 민감정보는 메시지에 직접 넣지 않고 SQS 관리형 암호화를 사용한다.
• Queue Age, 처리 성공률, 재시도율과 DLQ 유입 건수를 Monitoring한다.

9. 운영 전 검증

• 정상 작업, Worker 종료와 Timeout 상황에서 재전달을 시험한다.
• 동일 메시지가 두 번 전달돼도 결과가 한 번만 반영되는지 확인한다.
• 긴 AI 작업에서 Visibility Timeout 연장이 정상 동작하는지 확인한다.
• DLQ 이동과 수동 재처리 절차를 시험한다.
• 월 300만 건과 시간대별 순간 집중 트래픽을 사용해 Worker 수를 결정한다.
• Outbox 저장 후 SQS 전송 전 장애가 발생해도 복구 후 메시지가 발행되는지 확인한다.
• 운영 3개월 뒤 실제 AI 매출 기여율, 작업 실패율과 작업시간으로 손익을 다시 계산한다.

10. 최종 결정 기록

결정 항목	결론	핵심 근거
큐 도입	적용	AI 기능 기여 매출 4,500만 원이 첫해 월평균 비용 125만 원보다 큼
최소 구현	SQS Standard + DLQ	MySQL 방식과 비용은 비슷하지만 관리형 재전달·DLQ와 DB 장애 범위 분리가 유리함
DB·SQS 정합성	Transactional Outbox	DB 저장 후 SQS 전송이 누락되는 이중 쓰기 문제를 줄임
중복 처리	Application에서 방지	SQS Standard는 최소 1회 전달 방식임
SQS FIFO	제외	작업 순서 보장 요구가 없음
RabbitMQ·Amazon MQ	제외	AMQP 호환 요구가 없음
Redis·Valkey	제외	큐 지연이 매출에 영향을 준다는 근거가 없음
Kafka·MSK	제외	여러 소비자와 이벤트 장기 재생 요구가 없음

따라서 V2 AI 작업 큐는 Amazon SQS Standard + DLQ로 확정한다.

참고 자료

아래 자료는 2026년 9월 21일 기준으로 확인했다.

• 요금: Amazon SQS Pricing, Amazon SQS FAQ
• 큐 특성: Amazon SQS 소개, SQS Standard와 FIFO 비교
• 실패 처리: SQS Visibility Timeout, SQS 장애 복구 시나리오
• Polling: SQS Short Polling과 Long Polling
• 서비스 선택: Amazon SQS, SNS, EventBridge 비교