⚙️ 크롤링 로직 비동기 처리 대신 Redis 캐싱을 도입한 이유
"비동기 처리가 항상 답은 아니다."
척척학사에서는 사용자가 포털 계정으로 로그인한 뒤,
학사 데이터를 크롤링하고 이를 기반으로 메인 페이지를 구성하는 구조로 동작합니다.
하지만 포털 데이터를 가져오는 과정은
Playwright 기반의 크롤러 실행 → Raw 데이터 수집 → 정제 및 가공 → DB 반영
이라는 복잡한 절차를 거치기 때문에, 요청당 5~10초 이상의 대기 시간이 발생하는 경우도 있었습니다.
이를 개선하기 위해 처음에는 비동기 처리를 검토했지만,
결과적으로 Redis 기반 캐싱 전략이 더 실용적인 대안이라는 판단을 내렸습니다.
⛔ 왜 비동기 처리만으로는 해결되지 않았을까?
처음엔 다음과 같은 접근을 생각했습니다:
/start요청에 대해 크롤링 작업은 백그라운드로 넘기고- 클라이언트는
202 Accepted를 받고 대기 - 이후 polling 또는 WebSocket 등을 통해 상태를 확인
하지만 이 구조에는 명확한 한계가 있었습니다:
-
❗ 메인 페이지가 반드시 크롤링 데이터를 필요로 함
→ 데이터 수집이 끝나기 전까진 아무것도 못 보여주는 구조 -
❗ 비동기 처리를 해도 사용자는 기다려야 함
→ 응답을 먼저 주더라도 UX적으로는 개선되지 않음 -
❗ polling/WebSocket 구현 비용이 큼
→ 단순히 비동기 처리를 위한 구조 변경이 오히려 관리 복잡도를 증가시킴
✅ Redis 캐싱이 더 나은 대안이 된 이유
기존 구조는 /start 요청 시마다 포털 데이터를 직접 수집하고,
그 결과를 바로 가공해 클라이언트에 넘겨주는 방식이었습니다.
하지만 이 데이터를 사용자 단위로 Redis에 캐싱하면 다음과 같은 장점이 생깁니다:
- 동일 사용자 요청에 대해 중복 크롤링 방지
- 메인 페이지 접근 시 캐시 우선 조회로 빠른 응답
- 비동기 작업 없이도 UX 지연 최소화
- DB Join 없이도 필요한 데이터 구성 가능
🧰 구현 전략 요약
| 항목 | 내용 |
|---|---|
| Redis Key 구조 | portal:data:{userId} |
| 저장 시점 | 크롤링 및 동기화 완료 후 |
| TTL 정책 | 일간 or 1~3시간 (사용 패턴에 따라 조정) |
| Invalidation | /start, /refresh 성공 시 캐시 삭제 |
| 사용 방식 | 메인 페이지 구성 시 Redis → 없으면 DB fallback |
현재 포털 로그인 정보도 Redis에 저장하고 있기 때문에,
이 Redis 클러스터를 확장하여 캐싱 용도로 함께 활용할 계획입니다.
🔄 전체 흐름 변경 전/후 비교
📌 변경 전
/start → 크롤링 실행 → 데이터 가공 → DB 저장 → 응답 → 메인 페이지 진입
📌 변경 후
/start → 크롤링 실행 → 데이터 가공 → DB 저장 → 응답 메인 페이지-> 특정 API 요청 시 Redis 저장 → Redis 조회(메인페이지, 졸업요건 분석 API 요청 시) → 빠른 응답
✍️ 정리하며
기술적으로는 비동기 처리도 충분히 가능한 구조였지만,
실질적인 사용자 경험 개선에는 Redis 캐싱이 훨씬 더 효과적이었습니다.
기술을 도입할 때는 항상
“문제를 가장 단순하게 해결할 수 있는 방법은 무엇인가?”
를 스스로 물어야 한다고 생각합니다.
척척학사 팀에 합류한 이후, 다양한 기술적 도전과 고민을 거치며
매일 한 걸음씩 성장하고 있는 자신을 발견할 수 있었습니다.
개발을 시작한 이래 지금처럼 즐겁고 몰입감 있게 일한 적은 없다고
자신 있게 말할 수 있는 요즘입니다.
🔗 Related
