제가 Nirvana Browser를 만들기 시작했을 때, 제 목표는 단순했습니다:

사용자의 데이터를 클라우드로 전송하지 않고, 모든 보안 결정이 로컬에서 이루어지는 오프라인 중심의 프라이버시 우선 AI 브라우저를 만드는 것.

비전은 흥미로웠습니다.

하지만 구현은... 그렇지 않았습니다.

문제점

저의 첫 번째 프로토타입은 데스크톱 애플리케이션 내부에서 PyTorch 모델을 직접 실행하는 방식에 의존했습니다.

작동은 했지만, 세 가지 주요 문제를 야기했습니다:

• 📦 거대한 설치 파일 크기 — 거의 2.9GB
• 🧠 로컬 추론 (Inference) 중 높은 RAM 소비
• ⚠️ 도메인 보안 평가 중 처리되지 않은 예외로 인한 렌더러 프리징 (Renderer freezes)

데스크톱 브라우저로서 이러한 문제들은 용납할 수 없는 수준이었습니다.

사용자들은 애플리케이션이 즉시 실행되고, 최소한의 리소스를 소비하며, 반응성을 유지하기를 기대합니다. 수 기가바이트에 달하는 설치 파일을 배포하는 것은 선택지에 없었습니다.

최적화 전략

점진적인 개선을 시도하는 대신, 저는 추론 파이프라인 (Inference pipeline)을 근본부터 다시 설계했습니다.

1. PyTorch를 ONNX Runtime으로 교체

가장 큰 최적화는 프로덕션 환경에서 무거운 Python 런타임 (Runtime)을 제거하는 것에서 시작되었습니다.

PyTorch를 번들링하는 대신, 추론 모델을 ONNX Runtime으로 변환하고 배포에 최적화했습니다.

import torch.onnx

def convert_to_onnx(model, dummy_input, export_path):
...

변환 후, 모델은 메모리 사용량을 줄이고 추론 효율성을 높이기 위해 양자화 (Quantization)를 통해 추가로 최적화되었습니다.

그 결과, 배포 규모가 극적으로 줄어들었으며 시작 시간도 현저히 빨라졌습니다.

2. 대규모 도메인 리스트를 스마트 규칙 엔진으로 교체

초기에는 악성 도메인의 대규모 데이터베이스를 유지하는 방식을 실험했습니다.

기능적으로는 작동했지만, 방대한 데이터셋을 메모리에 로드하는 것은 불필요한 오버헤드 (Overhead)를 발생시켰습니다.

대신, 저는 safe.py 내부에 경량화된 **패턴 기반 필터링 엔진 (Pattern-based filtering engine)**을 설계했습니다.

모든 가능한 악성 도메인을 저장하는 대신, 엔진은 다음 항목들을 평가합니다:

• 의심스러운 키워드 패턴 (Suspicious keyword patterns)
• 고위험 도메인 구조 (High-risk domain structures)
• 콘텐츠 기반 지표 (Content-based indicators)

이를 통해 브라우저는 메모리 사용량을 낮게 유지하면서도, 상수 시간 조회 로직 (constant-time lookup logic)을 사용하여 잠재적으로 위험한 도메인을 식별할 수 있습니다.

필터링 프로세스는 데이터셋 크기에 따라 확장되는 대신, 가볍고 예측 가능한 상태를 유지합니다.

3. Sentry를 통한 런타임 안정성 모니터링

최적화는 단순히 속도에 관한 것만이 아닙니다.

신뢰성 또한 그만큼 중요합니다.

테스트 중 발생하는 충돌(crash)과 예기치 않은 실행 경로를 식별하기 위해, 런타임 모니터링을 위한 Sentry를 통합했습니다.

import sentry_sdk

sentry_sdk.init(
...

이를 통해 로컬에서 재현하기 어려웠던 지연 시간 급증 (latency spikes), 렌더러 예외 (renderer exceptions), 그리고 비동기 실패 (asynchronous failures)를 드러낼 수 있었습니다.

이러한 에지 케이스 (edge cases)들을 해결함으로써 브라우저 안정성이 눈에 띄게 향상되었습니다.

핵심 요약 (Key Takeaways)

이 프로젝트는 여러 엔지니어링 교훈을 강화해 주었습니다.

양자화 (Quantization)의 중요성

프로덕션 애플리케이션에 항상 무거운 머신러닝 프레임워크가 필요한 것은 아닙니다.

최적화된 ONNX Runtime 배포는 애플리케이션 크기를 획기적으로 줄이면서도 뛰어난 성능을 제공할 수 있습니다.

알고리즘이 원시 데이터보다 낫다

정교하게 설계된 규칙 엔진 (rule engine)은 방대한 정적 데이터셋을 메모리에 로드하는 것보다 종종 더 나은 성능을 발휘합니다.

더 나은 알고리즘은 단순히 더 많은 데이터를 추가하는 것보다 빈번하게 더 큰 이득을 제공합니다.

프라이버시는 느릴 필요가 없다

오프라인 우선 (offline-first) AI 브라우저를 구축하며, 배포 아키텍처를 신중하게 설계한다면 로컬 추론 (local inference)이 프라이버시와 성능을 모두 잡을 수 있다는 것을 배웠습니다.

마치며

성능 최적화는 벤치마크를 쫓는 것이 아닙니다.

소프트웨어를 사용하는 것이 수월하게 느껴질 때까지 불필요한 복잡성을 제거하는 과정입니다.

Nirvana Browser가 비대한 프로토타입에서 가벼운 데스크톱 애플리케이션으로 진화하는 과정을 지켜보는 것은 이 프로젝트에서 가장 보람찬 엔지니어링 경험 중 하나였습니다.

앞으로 개선해야 할 점이 여전히 많이 남아있지만, 이번 최적화 과제를 해결하면서 엔드 유저 디바이스 (end-user devices)에 AI를 배포하는 방식에 대한 저의 사고방식이 근본적으로 바뀌었습니다.

유용한 링크

Microsoft Store

https://apps.microsoft.com/detail/9mvcm5j0ldcx?ocid=webpdpshare

Anoop Singh에 의해 공개적으로 제작되었습니다.