Web Worker VS. 서버 처리

이번 글은 “프론트에서 버텨볼까?”라는 마지막 유혹을 끊어내는 글다.

---

Web Worker가 아니라

아예 서버로 보내야 하는 순간

— 프론트엔드/백엔드 경계선을 그리는 기준

Web Worker까지 배웠다면
프론트엔드에는 이제 이런 유혹이 생긴다.

“이 정도면
Worker로도 처리할 수 있지 않을까?”

하지만 여기서 한 번 더 선을 넘으면,
프론트엔드는 서버 흉내를 내기 시작한다.
그리고 그 순간부터 구조는 무너진다.

이 글은 그 경계선을 명확히 긋는 글이다.

---

1. 먼저 결론부터

이 문장 하나로 시작하자.

Web Worker로도 버틸 수는 있지만,
서버로 보내야 ‘맞는’ 순간이 있다.

그 기준은 성능이 아니라
책임과 공유 범위다.

---

2. Web Worker의 한계는 “기술”이 아니라 “역할”

Web Worker는 이렇게 생긴 도구다.

• 사용자 1명
• 브라우저 1개
• 로컬 CPU
• 결과는 이 사용자만 사용

 

 

이 구조에서 벗어나는 순간,
Worker는 맞지 않는다.

---

3. 서버로 보내야 하는 첫 번째 신호

“이 결과를 다른 사용자도 써야 하는가?”

이 질문은 즉시 결정타다.

❌ Web Worker

• 사용자 A가 계산
• 사용자 B는 다시 계산

⭕ 서버

• 한 번 계산
• 여러 사용자 재사용
• 캐시 가능

👉 공유되는 순간, 프론트는 탈락

---

4. 두 번째 신호

“처리 시간이 길어질 수 있는가?”

이 질문은 UX 기준이다.

• 1초
• 5초
• 30초
• 엑셀 1000행
• 이미지 500장

이런 작업을 프론트에서 처리하면:

• 탭 닫히면 ❌
• 브라우저 죽으면 ❌
• 배터리/성능 편차 ❌

서버는 다르다.

• 백그라운드 처리 ⭕
• 재시도 ⭕
• 상태 추적 ⭕
• 실패 복구 ⭕

👉 “기다림”이 생기면 서버 영역

---

6. 세 번째 신호

“보안이 조금이라도 중요한가?”

이건 고민할 필요도 없다.

• 가격 계산
• 권한 검증
• 데이터 정합성
• 내부 규칙

보안이 필요한 로직은
프론트에서 하는 순간 이미 실패다.

Web Worker는 보안 경계가 아니다.

---

6. 네 번째 신호

“이 로직을 테스트/배포/관리해야 하는가?”

프론트에 로직을 두면:

• 브라우저별 이슈
• 사용자 환경 의존
• 버전 관리 어려움
• 장애 추적 불가

서버에 두면:

• 로그 ⭕
• 메트릭 ⭕
• 롤백 ⭕
• 재현 ⭕
• 모니터링 ⭕

👉 운영이 시작되는 순간, 서버로 가야 한다

---

7. 실무에서 가장 많이 틀리는 구간

이 패턴이 진짜 위험하다.

“프론트에서 한 번 가공하고,
서버에서 또 검증하면 되잖아요?”

❌ 아니다.

이건:

• 중복 로직
• 불일치 가능성
• 디버깅 지옥

가공은 한 곳에서만 한다

---

8. Web Worker vs 서버 판단표 (실전용)

질문	Worker	서버
사용자 1명 전용	⭕	⭕
여러 사용자 공유	❌	⭕
50ms~500ms	⭕	⭕
수초~수분	❌	⭕
보안 중요	❌	⭕
캐시 필요	❌	⭕
운영/모니터링	❌	⭕

---

9. 엑셀/리포트 예제로 딱 잘라보면

❌ 프론트 + Worker

• 엑셀 파싱
• 행 단위 보정
• API 다수 호출

→ 사용자 PC가 서버 역할

⭕ 서버

• 파일 업로드
• job 생성
• 비동기 처리
• 결과 저장
• 상태 조회

→ 프론트는 화면만 담당

---

10. 한 문장으로 개념 고정 (중요)

Web Worker는
“이 사용자 화면을 살리기 위한 도구”이고,
서버는
“시스템 전체를 책임지는 장소”다.

그래서:

• 막히면 Worker ❌
• 책임지려면 서버 ⭕

---

다음 글 예고 

프론트엔드는 왜
‘아무것도 안 할수록’
좋은 구조가 되는가
— BFF, Thin Client, 그리고 현대 웹의 방향

이제 정말로
“덜 하는 프론트엔드” 이야기로 들어간다.