(번역) 추가 비용 없이 작동하는 아키텍처: 브라우저에서 전부 돌아가는 자산 관리 플랫폼을 만든 이유
분산 시스템 설계 업무에서 저는 쿠버네티스 클러스터, 이그레스 비용, 가용 영역 간 상태 관리에 많은 시간을 할애합니다. AI 애플리케이션의 업계 표준 역시 이러한 복잡성을 반영합니다. 우리는 파이썬 백엔드를 가동하고, API 키를 관리하며, 방대한 양의 사용자 데이터를 중앙 집중식 추론 제공업체로 전송합니다.
최근 구축한 자산 관리 플랫폼 메리디언(Meridian)에서는 이 모델을 뒤집고자 했습니다.
금융 데이터는 방사능 같은 위험 자산입니다. 플랫폼 엔지니어로서 가장 안전한 데이터는 아예 보유하지 않는 데이터라는 점을 잘 알고 있습니다. 그래서 브라우저 내에서 완전히 실행되는 프라이버시 우선, 제로 지식 금융 자문 서비스를 구축하기로 했습니다. 백엔드 없음. API 키 없음. 월간 서버 비용 없음.
하드웨어 인식 AI 아키텍처와 타입스크립트(Algora에서 상위 1% 실력자)에 대한 제 배경을 바탕으로, 이 작업을 일반적인 프런트엔드 프로젝트가 아닌 분산 시스템 과제로 접근했습니다. 사용자의 브라우저를 분산형 네트워크 내 주권 노드로 간주했습니다.
WebLLM을 활용한 에지 추론, Yjs를 통한 로컬-퍼스트 지속성, 하드웨어 가속 시각화를 위한 리액트 트리 파이버(R3F)를 사용해 메리디언을 구축한 과정은 다음과 같습니다.
"브라우저를 런타임"으로 활용하는 패턴
기존 아키텍처는 브라우저를 단순 터미널로 취급하는 경우가 많습니다. "브라우저를 런타임으로 활용하는 패턴"은 이를 컴퓨팅 노드로 간주합니다. 이는 클라우드(운영 비용)에서 에지(사용자 하드웨어)로 무거운 작업을 이동시켜 현대적인 FinOps 원칙과 완벽히 부합합니다. 데이터가 있는 위치로 컴퓨팅을 이동시키는 것입니다.
| Zero-Trust, Zero-Cost, Zero-Latency. The anatomy of a Sovereign Cloud application.
1. WebLLM(에지 네이티브 AI)를 통한 추론 오프로딩
메리디언의 핵심은 AI 어드바이저입니다. GPT-4를 호출하는 대신, 메리디언은 WebLLM을 사용하여 Llama 3.2 1B를 브라우저에 직접 다운로드하여 실행합니다.
이는 단순한 개인 정보 보호 차원의 선택이 아닌, 지연 시간과 비용을 고려한 결정이었습니다.
- 지연 시간: M1 맥북 에어에서 Llama 3.2 1B는 초당 약 40토큰을 처리합니다. 이는 인간의 눈으로 읽을 수 있는 속도보다 빠르며, 많은 클라우드 API의 왕복 시간보다 훨씬 빠릅니다.
- 메모리 사용량: 4비트 양자화 모델의 크기는 약 1.3GB입니다. 이는 대부분의 최신 소비자용 노트북 VRAM에 충분히 수용 가능한 수준이지만, 애플리케이션에 대한 하드웨어 최소 요구사항을 설정합니다.
src/hooks/useWebLLM.ts 파일의 통합 코드는 다음과 같습니다. 저수준 WebGPU API와의 인터페이스 시 안정성 유지를 위해 필수적인 엄격한 타입 지정(strict typing)에 유의하세요.
import { CreateMLCEngine, MLCEngine } from "@mlc-ai/web-llm";
import { useState } from "react";
// 모델 선택은 브라우저 성능에 매우 중요합니다.
const SELECTED_MODEL = "Llama-3.2-1B-Instruct-q4f32_1-MLC";
export const useWebLLM = () => {
const [engine, setEngine] = useState<MLCEngine | null>(null);
const [loadingProgress, setLoadingProgress] = useState("");
const initEngine = async () => {
try {
// WebGPU 가속은 MLC에서 자동으로 처리됩니다.
const newEngine = await CreateMLCEngine(SELECTED_MODEL, {
initProgressCallback: (report) => {
setLoadingProgress(report.text);
},
});
setEngine(newEngine);
} catch (err) {
console.error("WebGPU not supported or model load failed", err);
}
};
const generateAdvice = async (
portfolioContext: string,
userQuery: string,
) => {
if (!engine) return;
// 소규모 모델은 지침이 없는 프롬프트에 취약합니다.
// 엄격한 시스템 프롬프트를 통해 구조를 강제합니다.
const messages = [
{ role: "system", content: "You are a financial advisor..." },
{
role: "user",
content: `Context: ${portfolioContext}\n\nQuestion: ${userQuery}`,
},
];
const reply = await engine.chat.completions.create({ messages });
return reply.choices[0].message;
};
return { initEngine, generateAdvice, loadingProgress };
};"소형 모델" 제약 조건: 가장 큰 기술적 난관은 모델을 실행하는 것이 아니라 제어하는 것이었습니다. 10억 개 매개변수 모델은 형식 환각 현상이 발생하기 쉽습니다. 신뢰할 수 있는 금융 조언을 얻기 위해 프롬프트 엔지니어링을 데이터베이스 스키마 정의처럼 다루어야 했고 UI가 조언자의 “생각”을 파싱할 수 있도록 JSON 출력을 엄격히 강제 적용합니다.
2. Yjs 및 IndexedDB를 활용한 분산 상태 관리
분산 시스템에서 상태 관리는 가장 어려운 과제입니다. 중앙 데이터베이스 없이, 저는 Yjs(CRDT 라이브러리)와 IndexedDB를 활용한 로컬 우선(Local-First) 아키텍처를 채택했습니다.
왜 localStorage만 사용하지 않았을까요? localStorage는 동기식이며, 차단적이며, 약 5MB로 제한되기 때문입니다. Yjs + IndexedDB는 다음을 가능하게 합니다.
- 비동기적 쓰기: 복잡한 포트폴리오 상태를 저장할 때 UI를 멈추지 않습니다.
- 델타 업데이트: Yjs는 전체 블롭이 아닌 변경 사항(업데이트)만 저장한다. 이는 매우 효율적입니다.
- 충돌 해결: 브라우저 세션을 분할 내성 데이터베이스로 효과적으로 전환합니다. 사용자가 앱을 두 개의 탭에서 동시에 열어도 데이터 손실 없이 상태가 매끄럽게 병합됩니다.
src/utils/localFirstStore.ts에서 Yjs 문서를 IndexedDB에 바인딩하여 서버 측 데이터베이스에 필적하는 안정성을 가진 영속성 계층을 생성합니다.
import * as Y from "yjs";
import { IndexeddbPersistence } from "y-indexeddb";
// Yjs 문서 생성 - 단일 진실의 원천
const ydoc = new Y.Doc();
// 문서를 IndexedDB에 저장
const provider = new IndexeddbPersistence("meridian-store", ydoc);
export const useLocalFirst = () => {
const [data, setData] = useState<AppState | null>(null);
useEffect(() => {
const yMap = ydoc.getMap("portfolioData");
// 공유 맵의 변경 사항 관찰
yMap.observe(() => {
setData(yMap.toJSON() as AppState);
});
// IndexedDB에서 데이터 로드 완료 대기
provider.on("synced", () => {
setData(yMap.toJSON() as AppState);
});
}, []);
// ... 구현 세부 사항
};3. 불확실성 시각화 (WebGPU 가속화)
금융 앱은 종종 “스프레드시트 피로감”에 시달립니다. 몬테카를로 시뮬레이션에 내재된 위험과 확률 분포를 시각화하기 위해 캔버스 차트 이상의 것이 필요했습니다.
R3F를 활용해 LLM과 동일한 GPU 파이프라인으로 10,000개 이상의 데이터 포인트를 렌더링했습니다. MonteCarloCloud 컴포넌트는 InstancedMesh를 사용합니다. 이 기술은 게임 개발에서는 흔하지만 핀테크 분야에서는 드뭅니다. 단일 드로우 콜로 수천 개의 입자를 렌더링 할 수 있어 모바일 기기에서도 60fps를 유지합니다.
// src/components/3d/MonteCarloCloud.tsx
import { useRef, useMemo } from "react";
import { useFrame } from "@react-three/fiber";
import * as THREE from "three";
export const MonteCarloCloud = ({ simulations }) => {
const meshRef = useRef<THREE.InstancedMesh>(null);
const dummy = useMemo(() => new THREE.Object3D(), []);
useFrame(({ clock }) => {
if (!meshRef.current) return;
// 시간에 따른 변동성을 시각화하기 위해 입자를 애니메이션 처리
simulations.forEach((sim, i) => {
const x = i * 0.1;
const y = sim.value * 0.001;
dummy.position.set(x, y, 0);
dummy.updateMatrix();
meshRef.current.setMatrixAt(i, dummy.matrix);
});
meshRef.current.instanceMatrix.needsUpdate = true;
});
// ... 렌더링
};아키텍처의 절충점
아키텍처는 절충의 기술입니다. 백엔드를 제거함으로써 우리는 두 가지 주요 비용을 감수했습니다.
- "콜드 스타트" 페널티: 초기 1.3GB 모델 다운로드는 상당한 장벽입니다. 이는 새 파드(pod) 프로비저닝과 유사하지만 클라이언트 측에서 단 한 번만 발생하는 비용입니다. 이는 사용자가 설정 단계를 감수하는 ‘프로’ 도구에는 적합하지만, 캐주얼 소비자 앱에는 적합하지 않은 아키텍처입니다.
- 하드웨어 의존성: 우리는 사용자에게 최소 하드웨어 사양(WebGPU 지원)을 사실상 요구합니다. 보편성을 성능과 교환한 것입니다.
결론
메리디안은 단순한 자산 관리 도구가 아닙니다. 이는 주권 클라우드 애플리케이션의 개념 증명입니다. MLOps 원칙과 브라우저 네이티브 기술을 결합함으로써, 기본적으로 비공개이며 무한 확장 가능하고 한계 인프라 비용이 없는 시스템을 구축할 수 있습니다.
하드웨어 인식 AI와 더 효율적인 CPU 아키텍처로 나아가면서 "클라이언트"와 "서버"의 경계는 계속 모호해질 것입니다. 이 분할의 양쪽을 모두 마스터하는 것이 플랫폼 엔지니어링의 미래입니다.
저자 소개: 저는 주권 컴퓨팅의 최전선에서 개발하는 엔지니어링 디렉터이자 수석 아키텍트입니다. 전 세계 타입스크립트 엔지니어 상위 1%에 선정된(Algora) 저는 특허 출원 중인 AI 하드웨어부터 분산 상태에 이르는 시스템 연구를 실제 운영 소프트웨어 출시의 실용성과 결합합니다. 차세대 위대한 소프트웨어가 클라우드에서만 실행되는 것이 아니라 어디서나 실행될 것임을 증명하기 위해 글을 씁니다. 다트머스 공학 석사, 코넬 경영학 석사.
