들어가며

블라이(BLAI)는 블로그 콘텐츠 분석 서비스로, 네이버 블로그 마케터들에게 네이버 블로그 상위노출 알고리즘에 알맞게 자기 글을 개선하기 위한 '형태소 분석, 비속어 검출, 이미지 분석' 기능 등을 제공한다. 이를 위해 Nest.js 백엔드와 Python 크롤링 및 분석 엔진이 협력하여 해당 처리를 진행한다. 이 글에서는 두 시스템 간 통신을 위해 RabbitMQ 메시지큐를 어떻게 활용했는지 소개한다.

왜 메시지큐를 도입했을까?

물론 처음엔 HTTP API로 Python 서버를 호출하는 방식을 고려했지만, 다음 문제가 예상되었다고 한다. (처음에 이 서비스 초기개발 하신 선임이 설명해줌)

분석 처리 시간: 평균 30초
동시 요청 100개 → 커넥션 100개 점유 (30초간)
→ 점점 더 증가할수록 신규 요청 거부 또는 타임아웃

http 요청은 응답을 리턴 받을때까지 커넥션을 유지하고 있는다. 그런데 우리 서비스 특성 상 외부 사이트들을 크롤링 해서 자모, 형태소 분석하고 노출량 검색하고 그러는데, 이는 생각보다 긴 시간을 요구한다. 이렇게 무거운 작업을 계속 커넥션을 유지하면서 처리하기보단 비동기적으로 던져놓는게 유리하다는 판단을 하셨다.

사용한 메시징 패턴

1. Fire and Forget (대부분 이걸 사용했다.)

기본적으로 프론트가 요청을 보냈을 때 백엔드는 MongoDB(우리가 쓰고있는 DB)의 새로운 문서를 만들고, 그 아이디와 분석 요청 내용들을 담아 파이썬 분석기로 넘긴다. 프론트에게는 분석 요청을 완료했다는 응답만을 리턴한다. 무거운 작업을 백엔드가 하지않고 파이썬 분석기에게 미룬다고 보면 된다. 그리고 프론트에겐 '파이썬 분석기에게 시켰으니 다시 조회해봐.'라고 말하는거다.

그러면 프론트는 성공신호를 받고, 분석결과를 받기 위한 백엔드 API로 폴링 요청을 시작하는데, 백엔드는 파이썬 분석기가 수정한 문서를 현재 파이썬이 작업을 다 완료했는지 판단해서 '분석중', '분석완료' 를 내려준다. 분석 완료가 될 때까지 프론트가 폴링해서 가져오는 방식이다.

흐름:

[클라이언트]
↓ POST /analyze
[백엔드]
├─ 1. DB 생성 (post_id: "123")
├─ 2. 메시지 발행 (request_id: "123")
├─ 3. [RabbitMQ] request.exchange 발행!
└─ 4. 프론트에 즉시 응답 ✅
↓
[Python]
├─ 5. 분석 수행 (30초)
└─ 6. 응답 발행 (request_id: "123")
└─ 7. [RabbitMQ] response.exchange
↓
[백엔드 Consumer]
8. DB 업데이트 (분석 완료 상태로 처리)

--- 프론트엔드 Polling ---

[클라이언트]
↓ GET /analyze/123 (2초마다)
[백엔드]
├─ DB 조회 (post_id: "123")
└─ 응답:
- level: 0 → "처리 중"
- level: 1 → "완료" + result_data 반환 ✅

코드 예시:

// 백엔드: 요청 발행
const post_id = await this.createAnalysisRequest({...});

await this.messageProducer.publish({
exchange: 'request.analysis.example',
routing_key: 'request.analyze.example',
send_data: {
request_id: post_id, // ✅ Python이 이걸로 응답!
url_or_text: '분석할 텍스트',
}
});

return { result: 'success', post_id }; // 즉시 응답!

# Python: 분석 및 응답
@consumer.subscribe('request.analyze.morpheme')
async def handle_analysis(message):
result = analyze(message['url_or_text'])

await producer.publish(
exchange='response.analysis.exchange',
routing_key='response.analyze.morpheme',
message={
'request_id': message['request_id'], # ✅
**result
}
)

// 백엔드 Consumer: DB 업데이트
@RabbitSubscribe({
exchange: 'response.analysis.exchange',
routingKey: 'response.analyze.morpheme',
})
async analyzeMorpheme(data) {
const { request_id, ...content } = data;

await this.postModel.updateOne(
{ _id: request_id },
{ result_data: content, level: 1 }
);
}

핵심:

request_id 포함 → Python이 어느 문서를 업데이트할지 알아야 함

즉시 응답 → 사용자는 0.2초에 응답 받음 (30초 안 기다림)

Consumer가 DB 업데이트 → Python은 DB 몰라도 됨

2. RPC (통합 분석)

포스팅 통합 분석이라는 여러 분석을 한 번에 처리해주는 기능에서 쓰는 요청방식이다. 원래 단일 분석을 할 때는 메시지 큐에 분석요청을 보내고 프론트의 요청을 완료 시켰는데, 통합분석에선 여러 분석의 결과를 받아 마지막에 '유저 맞춤 진단'을 해줘야해서 여러 분석 요청들이 제대로 다 끝난 뒤의 시점을 잡기 위해 쓰고있다.

흐름:

[클라이언트]
↓ POST /comprehensive/analyze
[백엔드]
├─ 1. DB 생성
├─ 2. 프론트엔 즉시 응답
└─ 3. 백그라운드 처리 (consumer가 파이썬 분석기의 producer의 응답이 올때까지 대기)
├─ RPC: 형태소 (10초)
├─ RPC: 비속어 (8초) } 병렬!
└─ RPC: 이미지 (15초)
└─ 4. 결과 통합 및 진단 생성 → DB 저장

코드 예시:

// ✅ RPC 방식
const [morpheme, slang, image] = await Promise.all([
rpcProducer.send({ routing_key: 'morpheme' }), // 대기!
rpcProducer.send({ routing_key: 'slang' }), // 대기!
rpcProducer.send({ routing_key: 'image' }) // 대기!
]);

// 모든 결과를 받았음!
// 이제 진단 생성 가능!
const diagnosis = generateDiagnosis(morpheme, slang, image);

// 한 번에 저장!
await db.update(post_id, {
morpheme_analysis: morpheme,
slang_analysis: slang,
image_analysis: image,
diagnosis: diagnosis // ← 결과 조합!
});

Fire and Forget으로는 힘든 이유:

3개 분석이 각각 언제 끝날지 모름

모두 완료되었는지 확인하는 로직 필요

Consumer가 3번 호출되는데, 어느 시점에 진단을 만들지?

그러나 불가능하진 않긴 하다. 3개의 분석 -> 3개의 문서가 만들어질테고, 프론트에서 "다 됐어?" 물어볼때마다 3개의 문서를 다 조회해서 상태 체크하고, 3개 다 완료 됐으면 그때 진단을 만들어주면 될테지.

그러나 아무렴 호출을 줄이는 것도 좋고 복잡성을 없애기 위해서라도 3개의 분석이 다 완료되는 시점에 딱 한 번 문서 업데이트 해주는 식으로 처리했다.

패턴 비교

구분	Fire and Forget	RPC
request_id	✅ 포함	❌ 미포함
응답 매칭	request_id	correlation_id
DB 업데이트	Consumer	요청한 함수
병렬 처리	어려움	쉬움
사용 예시	단일 분석	통합 분석

Exchange와 Routing

Exchange 구조

request.analysis.exchange (topic)
→ API → Python 분석 요청

response.analysis.exchange (topic)
→ Python → API 분석 결과

failed.exchange (topic)
→ 실패한 메시지 처리

Routing Keys

요청:
- request.analyze.morpheme (형태소)
- request.analyze.badword (비속어)
- request.analyze.posting.image (이미지)

응답:
- response.analyze.morpheme
- response.analyze.badword
- response.analyze.posting.image

성능 최적화

1. 병렬 처리

// ❌ 순차: 33초
const morpheme = await analyzeMorpheme(); // 10초
const slang = await analyzeSlang(); // 8초
const image = await analyzeImage(); // 15초

// ✅ 병렬: 15초
const [morpheme, slang, image] = await Promise.all([
analyzeMorpheme(),
analyzeSlang(),
analyzeImage()
]);

2. Worker 수평 확장

# Kubernetes
apiVersion: apps/v1
kind: Deployment
metadata:
name: python-worker
spec:
replicas: 5 # Worker 5대!

효과:

1대: 초당 10개 처리
5대: 초당 50개 처리 (5배!)

3. 진행률 업데이트

await this.updateProgress(post_id, 0, 10); // 10%
// 형태소 분석...
await this.updateProgress(post_id, 0, 40); // 40%
// 비속어 분석...
await this.updateProgress(post_id, 0, 100); // 100%

배운 점과 개선 사항

잘한 점

시스템 분리: Node.js와 Python 역할 명확히 구분

확장성: Worker 추가만으로 처리량 증가

사용자 경험: 즉시 응답 + Polling

장애 복구: Dead Letter Exchange로 자동 처리

개선 가능한 점

1. WebSocket 도입

// 현재: Polling (2초마다)
setInterval(() => checkResult(), 2000);

// 개선: WebSocket (실시간)
socket.on('progress', (data) => {
console.log(`${data.percent}%`);
});

2. gRPC 검토

RPC 지연: 20-100ms
gRPC 지연: 1-5ms (20배 빠름!)
→ 트래픽 증가 시 고려

마치며

각기 다른 언어, 다른 역할로 짜여진 시스템인데, 느슨한 결합으로 일을 처리하는 과정 자체가 너무 재밌다. 프론트는 유저 요청 받아서 열심히 폴링하고, 백엔드는 파이썬에게 일시키고 완료되면 받으면서 프론트가 닦달할때마다 완료됐는지 응답해주고, 파이썬은 열심히 크롤링해서 블로그 분석한다.

이 모든 시스템은 쿠버네티스 위에서 구현되어 있는데, 이 deployment들이 요청량에 따라 pod이 늘어나고 이걸 service가 로드밸런싱 해주고... 이러는 역학까지 추가되니 꽤 복잡한 시스템이라고 새삼 느낀다. 사실 쿠버네티스는 어렴풋한 느낌으로 이해하는 수준이라... 제대로 이해하면 후속 포스팅으로는 쿠버네티스 위에 블라이가 어떻게 구현되어 있는지 한 번 적어보겠다.