웹 앱에 클라이언트 사이드 (client-side) AI 모델을 처음 도입했던 때가 기억납니다. 기능은 멋졌습니다. 사용자가 텍스트를 업로드하면 서버를 거치지 않고 브라우저 내에서 즉각적인 AI 기반 인사이트를 얻을 수 있었으니까요.

하지만 곧 불만이 터져 나오기 시작했습니다. "타이핑할 때 왜 UI가 멈추나요?" "스피너(spinner)가 영원히 돌아가요!" "느리고 반응이 없어요."

이전에도 빠른 React 앱을 만들어 본 적이 있었지만, 이번에는 달랐습니다. AI 모델은 거대한 괴물 같았습니다. CPU를 독점하며 메인 스레드 (main thread)를 차단했습니다. 로딩 상태는 투박했고, 지연 시간 (latency)을 디버깅하는 것도 간단하지 않았습니다.

만약 여러분이 TensorFlow.js, ONNX.js, 또는 WebAssembly 기반 추론 (inference)을 사용하여 프론트엔드에 AI 모델을 직접 통합하고 있다면, 아마 이 문제를 겪어보셨을 것입니다. 이는 단순히 모델 크기의 문제만이 아닙니다. 프론트엔드 아키텍처가 로딩, 응답성, 그리고 UX 피드백을 어떻게 관리하느냐의 문제입니다.

프론트엔드에서 AI 통합 지연 시간을 디버깅하고 해결하며 제가 배운 것들을 공유해 보겠습니다.

전형적인 병목 현상: AI 모델이 메인 스레드를 차단함

브라우저에서 AI 모델을 실행하면 보통 CPU 집약적이며 동기적 (synchronous)입니다. 이런 상황을 상상해 보세요. 사용자가 버튼을 클릭하여 추론 (inference)을 트리거합니다. 여러분의 JS가 모델의 predict 함수를 호출합니다. 브라우저의 메인 스레드는 수백 밀리초 또는 심지어 몇 초 동안 묶이게 됩니다.

그동안 UI는 응답할 수 없습니다. 애니메이션도, 입력 업데이트도, 스피너 업데이트도 불가능합니다. 마치 얼어붙은 것처럼 느껴집니다.

가장 단순한 접근 방식은 다음과 같습니다:

function handlePredict() {
  setLoading(true); // 스피너 표시
  const result = model.predict(inputData); // 메인 스레드 차단
...

하지만 model.predict는 동기적으로 실행되며 메인 스레드를 독점합니다. React는 predict가 완료될 때까지 CPU 사이클을 할당받지 못하므로 스피너를 업데이트할 수 없습니다.

결과적으로 스피너가 아예 나타나지 않거나, 차단이 끝난 후에야 나타나 사용자에게 혼란을 줍니다.

비차단형 (non-blocking) AI 추론을 위한 아키텍처 설계

핵심은 _절대로 메인 스레드를 차단하지 않는 것_입니다. 만약 모델 API가 동기적이라면, React 이벤트 핸들러에서 단순히 직접 호출해서는 안 됩니다.

몇 가지 옵션이 있습니다:

1. Web Workers로 오프로드 (Offload to Web Workers)

Web Workers는 별도의 스레드에서 실행됩니다. 모델 추론 (Inference)을 그곳으로 옮기면 메인 UI 스레드의 응답성을 유지할 수 있습니다.

이는 다음을 의미합니다:

• AI 모델을 로드하는 워커 스크립트 (Worker script)를 생성합니다.
• postMessage를 사용하여 입력 데이터를 비동기적으로 전송하고 결과를 수신합니다.
• 워커가 응답할 때만 React 상태 (State)를 업데이트합니다.

예시:

// 메인 스레드 (main thread)
worker.postMessage({ input: inputData });
worker.onmessage = (e) => {
...

이 방식은 차단 (Blocking) 문제를 해결하지만, 워커 생명주기 (Lifecycle), 메시지 직렬화 (Serialization), 모델 로딩 중복과 같은 복잡성을 추가합니다.

2. 추론을 청크 단위로 분할 (Break inference into chunks)

일부 모델은 더 작은 단계나 배치 (Batch) 단위로 추론을 실행할 수 있습니다. requestIdleCallback을 사용하거나 마이크로태스크 (Microtask)를 스케줄링하면 작업을 청크 (Chunk) 단위로 나눌 수 있어 UI가 숨 쉴 틈을 얻을 수 있습니다.

이는 고급 기술이며 모델 API의 지원 여부에 따라 달라집니다.

3. 모델 지연 로딩 및 캐싱 (Lazy load and cache models)

모델을 로드하는 것 또한 느릴 수 있습니다. 초기 지연을 피하기 위해 모델이 필요할 때만 지연 로딩 (Lazy load)을 수행하세요.

모델 인스턴스 (Instance)를 캐싱하여 반복적인 추론 호출 시 가중치 (Weights)를 다시 로드하지 않도록 합니다.

UX 트레이드오프: 로딩 상태와 인지된 성능 (UX tradeoffs: Loading states and perceived performance)

추론 중에 스피너 (Spinner)를 보여주는 것은 기본적인 방법이지만, 동기적으로 차단이 발생하면 제대로 작동하지 않는 경우가 많습니다.

대신 다음을 고려해 보세요:

• 낙관적 UI (Optimistic UI): 예비 결과나 플레이스홀더 (Placeholder)를 즉시 보여줍니다.
• 점진적 피드백 (Progressive feedback): 추론이 200ms를 초과하는 경우 미세한 로딩 인디케이터 (Indicator)를 표시합니다.
• 입력 비활성화 (Disable input): 혼란을 방지하기 위해 추론 중에는 추가 입력을 막습니다.
• 타임아웃 및 취소 (Timeouts and cancelation): 사용자가 오래 걸리는 추론을 취소할 수 있도록 허용합니다.

예를 들어, 저는 스피너를 흐릿한 오버레이 (Dimmed overlay)와 추론이 300ms를 넘을 때만 나타나는 "생각 중...(Thinking...)" 메시지로 교체했습니다. 이렇게 하면 실행 속도가 빠를 때 발생하는 깜빡임 (Flicker) 현상을 방지할 수 있습니다.

느리거나 차단을 유발하는 AI 기능 디버깅

무엇이 차단을 일으키고 있는지 추적하는 방법은 다음과 같습니다:

• Chrome DevTools Performance tab: 추론 (Inference) 동안 프로파일을 기록(Record)하세요. 메인 스레드 (Main thread)를 차단하는 긴 작업 (Long tasks)을 찾으세요.
• Flame charts: model.predict 호출을 식별하고 실행되는 데 시간이 얼마나 걸리는지 확인하세요.
• React DevTools 확인: 상태 업데이트 (State updates)나 렌더링 (Renders)이 지연되는지 확인하세요.
• Network tab: 모델 가중치 (Model weights)가 반복적으로 페치 (Fetch)되고 있지 않은지 확인하세요.

프로파일링 결과, 일반적인 입력에 대해 모델의 predict가 600ms가 소요되어 React의 렌더링 업데이트를 차단한다는 것을 발견했습니다.

종합하기: 실무 예시

function AIComponent() {
  const [loading, setLoading] = React.useState(false);
  const [result, setResult] = React.useState(null);
...

워커 스크립트 (aiWorker.js)는 모델을 한 번 로드하고 추론 (Inference)을 비동기적으로 실행하는 역할을 처리합니다.

마치며

프론트엔드에서 AI 모델을 통합하는 것은 단순히 플러그 앤 플레이 (Plug-and-play) 방식이 아닙니다. 모델이 메인 스레드를 점유하면 전체 UX가 저하됩니다.

가장 좋은 방법은 다음과 같습니다:

• Web Workers 또는 이와 유사한 메인 스레드 외 (Off-main-thread) 메커니즘을 사용하세요.
• 깜빡임 (Flicker)과 프리징 (Freezing)을 방지하기 위해 로딩 상태 (Loading states)를 신중하게 설계하세요.
• 프로파일링 도구로 디버깅하여 차단 작업 (Blocking tasks)을 찾아내세요.
• 반복적인 지연을 피하기 위해 모델을 지연 로딩 (Lazy load)하고 캐싱 (Cache)하세요.

이러한 방법을 통해 귀하의 AI 기능은 단순히 작동하는 것을 넘어, 사용자가 진정으로 중요하게 생각하는 부드럽고 반응성 있는 (Responsive) 경험을 제공할 것입니다.

유용한 학습 리소스

• MDN Web Docs
• web.dev performance guidance