FEInterview Prep

Velog

추가 비용 없이 작동하는 아키텍처: 브라우저에서 전부 돌아가는 자산 관리 플랫폼을 만든 이유

Meridian 의 '브라우저만 아키텍처': WebLLM(Llama 3.2 1B) + Yjs(CRDT + IndexedDB) + R3F(InstancedMesh Monte Carlo). 서버 비용 0, 프라이버시 100% 의 설계 선택을 역산한다.

2026-01-26·6분 읽기
아키텍처성능
원문 보기 ↗

핵심 요약

Meridian 은 자산 관리 앱으로, 서버를 거의 두지 않고 다음 세 기술을 조합한다. (1) WebLLM 브라우저 내 Llama 3.2 1B 추론 — WebGPU 로 초당 수십 토큰. LLM 비용이 0. (2) Yjs CRDT + IndexedDB — 로컬 스토리지에 저장, 멀티디바이스 동기화는 선택적 피어(또는 외부 relay)로. 서버 DB 없음. (3) React Three Fiber + InstancedMesh 로 몬테카를로 시각화 — 10,000개 포트폴리오 시뮬레이션을 GPU 병렬로. 계산 서버 없음. 트레이드오프: 초기 모델 다운로드(수백 MB), 구형 기기 지원 포기, 피어 간 동기화의 일관성 복잡도. 이 아키텍처가 면접에서 유용한 이유는 '왜 서버를 안 썼는가' 질문에 기술별 근거를 댈 수 있는 구조적 사례이기 때문.

'Zero-Marginal-Cost' 를 '사용자가 늘어도 서버 청구서가 그대로' 로 본다. 핵심은 계산/스토리지/협업 세 축을 전부 클라이언트로 옮긴 아키텍처. 각 축의 선택(WebLLM/IndexedDB+Yjs/WebGPU) 이 어떤 서버 의존성을 제거했는지 역산하면 설계 근거가 보인다.

'서버리스' 면접에서 AWS Lambda 얘기만 하면 얕다. 진짜 서버리스(=서버 없음) 는 이 방향. 특히 프라이버시 데이터 (금융/자산/의료) 를 다루는 서비스에서 '데이터가 내 기기를 안 떠난다' 는 구조적 차별화가 가능하다. 면접관이 찾는 건 '어떤 트레이드오프를 받아들였는가' 다.

학습 포인트

면접 답변으로 연결할 학습 포인트입니다.

WebLLM — LLM 비용을 0 으로

WebLLM 은 ONNX/MLC 포맷의 모델을 브라우저 WebGPU 로 실행한다. 서버 호출이 없고 키 노출 문제도 없다.

import * as webllm from '@mlc-ai/web-llm';
const engine = await webllm.CreateMLCEngine('Llama-3.2-1B-Instruct-q4f32_1');
const reply = await engine.chat.completions.create({
  messages: [{ role: 'user', content: '이 포트폴리오 리스크 분석해줘' }],
});

대가: 첫 로드 400~700MB, 저사양 기기는 느림. 해법: 첫 방문 시 다운로드 진행 UI, 모델 로컬 캐시 활용.

WebLLMWebGPUMLCon-device inference
자주 하는 오해

초기 다운로드 크기를 숨기는 것 — UX 위반. 명시적 로딩 상태 를 보여주는 게 정답.

Yjs + IndexedDB — 서버 DB 없는 동기화

Yjs 는 CRDT 라이브러리로 순서 독립한 병합 을 보장한다. 로컬은 y-indexeddb 로 저장, 멀티기기 동기는 y-webrtc(피어간) 또는 y-websocket(공공 relay).

import * as Y from 'yjs';
import { IndexeddbPersistence } from 'y-indexeddb';
const doc = new Y.Doc();
new IndexeddbPersistence('portfolio', doc);
const items = doc.getArray('assets');
items.push([{ ticker: 'AAPL', qty: 10 }]);
// 다음 로드 시 자동 복원

서버 DB 스키마/마이그레이션/백업 전부 사라진다. 대가: '내 기기 고장 나면 끝' — UX 로 '클라우드 백업은 옵션' 을 제공.

YjsCRDTIndexedDBpeer-to-peer
자주 하는 오해

CRDT 가 '모든 conflict 를 알아서 해결' 이라 오해. 실제로는 '의미 충돌' 은 여전히 수작업 (예: 같은 티커에 다른 수량).

R3F InstancedMesh — 계산 서버 없는 시뮬레이션

10,000개 포트폴리오 경로를 매 프레임 그릴 때 <mesh> 를 개별 생성하면 드로우콜 폭발. InstancedMesh 는 동일 기하를 행렬 버퍼 로 한 번에 그려 GPU 가 병렬 처리.

<instancedMesh args={[geom, mat, 10000]}>
  {paths.map((p, i) => setMatrix(i, p))}
</instancedMesh>

몬테카를로 시뮬레이션을 백엔드 배치 가 아닌 브라우저 GPU 로 이동 — 비용 0, 응답 즉시. 제약: WebGPU 지원 브라우저 필요.

InstancedMeshReact Three FiberMonte CarloWebGPU
자주 하는 오해

일반 <mesh> 10,000개를 뿌려 FPS 가 1 로 떨어진 뒤 '브라우저 한계' 라 포기. 해법은 instancing.

읽는 순서

  1. 1이론

    WebLLM / Yjs / R3F InstancedMesh 각 공식 문서 Getting Started 를 1페이지씩 정리하고 서버가 담당하던 역할 을 표로 매핑.

  2. 2구현

    간단 할일 앱을 (a) 전통 서버 DB, (b) Yjs+IndexedDB 두 버전으로 만들고 서버 코드/비용 차이 비교.

  3. 3실무

    본인 서비스에서 '검색 자동완성' 또는 '정렬/필터' 를 서버에서 클라이언트로 이관 PR 을 시도하고 LCP/TTFB 비교.

  4. 4설명

    '우리 서비스의 Zero-Marginal-Cost 후보 3가지' 를 파트너십/아키텍처 회의에 제안.

면접 연결 질문

medium**Zero Marginal Cost** 아키텍처가 가지는 **사업적 장점 세 가지** 를 말해보세요.
힌트

[좋은 답변] (1) 사용자 증가 = 비용 증가 무관(수익성 수렴), (2) 프라이버시 차별화 — 규제 산업 진입 용이, (3) 오프라인 동작 — 항공/격오지 시장 포섭. 단 DAU 가 아무리 늘어도 서버 비용 0 이 CAC 회수 기간을 극단적으로 단축.

hardYjs + IndexedDB 로 구축하면 '기기 분실 = 데이터 손실' 위험이 큽니다. 어떻게 완화하시겠어요?
힌트

[좋은 답변] (1) 옵트인 클라우드 백업(E2E 암호화), (2) 멀티기기 peer sync — 최소 2기기 권장, (3) 정기 .json export 안내, (4) CRDT snapshot 을 사용자 제공 스토리지(Dropbox/GDrive) 에 저장. 기본은 로컬, 백업은 선택.

hardWebLLM 첫 로드 500MB 가 UX 상 부담입니다. 설계적 대안을 제시해보세요.
힌트

[좋은 답변] (1) 첫 방문엔 서버 LLM fallback, 백그라운드로 다운로드, (2) 더 작은 모델(Phi-3 mini 0.5B) 로 시작, 필요시 업그레이드, (3) Service Worker 로 청크 단위 캐시 + 재시도, (4) WebGPU 미지원 브라우저 감지해 텍스트 UX 로 대체.

자기 점검

본인 프로젝트 중 **서버 비용을 클라이언트로 이전할 수 있는** 기능 한 가지를 찾아보세요 (검색/정렬/시뮬레이션/캐싱).
WebGPUIndexedDBCRDTWebLLM
자주 하는 오해

'브라우저는 약하다' — 최신 기기 성능은 2018년 서버 수준.

Zero-Marginal-Cost 아키텍처가 **적합하지 않은** 서비스 유형 두 가지를 들고 이유를 설명해보세요.
실시간 협업 대규모권한 검증서버 권한대용량 데이터
자주 하는 오해

모든 앱이 이렇게 가야 한다는 단순화. 권한/부정 방지 가 서버 필수.