DAU 3만명 이 구조로는 못 버텨요… 내가 직접 설계한 비동기 설문 시스템

서론

고객에게 환급금을 정확히 돌려주기 위해서는 체크리스트 설문이 필요합니다. 이 설문은 단순히 선택만 하는 게 아니라, 스프레드시트에 응답을 저장하고, 이를 분석해 결과를 추론하는 복합적인 로직을 포함하고 있습니다. 이 전체 과정에는 20초 정도의 시간이 걸리게 되기 때문에 이 과정을 처음 설계할 때부터 “이건 절대 동기식으로 처리하면 안 되겠다”고 판단했습니다.

 

왜 동기로 짜면 안 되는지, 설계 전부터 예측했습니다

당시 처리 대상은 3만 명이 넘는 사용자였고, 이 설문은 퇴근 직후, 특정 시간대에 몰리는 트래픽 특성을 갖고 있었습니다. 문제는 이 흐름이 아래와 같다는 점입니다

설문조사 순서도

단순히 생각해도,

• 20초 동안 핸들러가 점유되면?
• 수천 명이 동시에 들어오면?
• 스레드 풀 / 이벤트 루프는 버텨줄 수 있을까?

라는 질문이 들었고, "한 요청이 다른 요청을 막게 된다"는 점에서 구조적으로 위험하다고 판단했습니다.

 

그래서 아예 구조를 다르게 설계했습니다

“이건 동기로 짜지 말자”는 확신이 있었기에, 설계 초기부터 아래와 같은 아키텍처로 접근했습니다. 핵심은, 설문 응답을 받아서 처리하는 "행위" 자체를 즉시 처리하지 않고, "계획된 작업"으로 비동기화했다는 점입니다.

 

참고로 사용자의 요청 정보를 로그에 기록하지 않고, s3에 업로드하는 것은 다음과 같은 요구조건을 만족하기 위해서입니다.

 

• 서버 로그에 남기기엔 개인정보 이슈:
  서버 로그는 보안상 비식별화된 데이터만 저장해야 하며, 설문에는 이름, 계좌 정보 등 민감 데이터가 포함될 수 있습니다.
• S3는 개인정보 보호 요건을 만족하며, 장기 보존 가능:
  접근 제어가 명확하고, 감사 로그도 남길 수 있어 규제 대응이 수월합니다.
• “최후의 백업 저장소” 역할:
  Redis 큐나 워커가 실패하더라도, 최소한의 raw 데이터를 확보해 복구가 가능합니다.

기술 스택 선정 과정

비동기 처리는 "큐"만 쓰면 되는 게 아닙니다. 저는 아래 기준으로 Redis 큐를 선택했습니다 단순 성능보다 장애 대응력과 시스템 전체의 일관성을 고려한 선택이었습니다.

내구성	로컬 큐는 파드 죽으면 데이터 유실 → Redis는 AOF 설정으로 내구성 확보 가능
확장성	Redis는 워커 수평 확장 가능 → 부하에 따라 탄력적으로 대응
운영성	BullMQ 등 검증된 라이브러리 존재 → 장애 감지/재시도/지연 큐 처리까지 가능
장애 대응	Sentinel 구성 통해 장애 전환 가능

결과적으로 얻은 것들

서버 안정성	TPS 수천에서도 핸들러 점유 없음
응답 속도	설문 요청은 100ms 이내로 반환
장애 대응	작업 재시도 및 지연 큐로 안정성 확보
확장성	워커 수 늘려 쉽게 확장 가능

마무리하며: “빠르게 만들지 않고, 오래 가게 설계한다”

이 경험은 “지금 문제 없으니 나중에 고치자”가 아니라,
“지금 괜찮아 보여도, 나중에 터질 수 있는 구조는 미리 바꿔야 한다”는 교훈을 주었습니다.

단지 기술적으로 비동기 처리를 도입한 것이 아니라,

• 성능 이슈를 사전에 예측했고,
• 고객 경험을 보장할 수 있도록 흐름을 설계했으며,
• 장애에 강하고 유연한 시스템 구조를 만들었다는 점에서 이번 설계는 제가 개발자로서 한 단계 성장할 수 있었던 계기가 되었습니다.