본문바로가기
IZE Chat Widget
Embeddable AI Chat Solution for B2B SaaS
IZE Chat Widget
Embeddable AI Chat Solution
IZE Chat Widget
IZE Chat Widget
코드 한 줄로 웹사이트에 AI 상담 채팅을 추가하는 B2B 솔루션
  • Next.js
  • FastAPI
  • PostgreSQL
  • Redis
  • Zustand
  • Vercel AI SDK
  • TDD
  • Project
    IZE Chat Widget
  • Release Date
    2025.12
  • Type
    B2B SaaS / Embeddable Widget
  • Role
    Architecture Design & Fullstack Dev
고객사
이트라이브
프로젝트 유형
B2B SaaS / Embeddable AI Chat Widget
기술 스택
Next.js, FastAPI, PostgreSQL, Redis, Zustand, Vercel AI SDK
데모
ize-chat.vercel.app
담당 역할
아키텍처 설계부터 배포까지 전 과정 담당 (1인 개발)
개발 기간
약 4주
핵심 성과
Script Tag 한 줄로 설치 가능한 AI 채팅 시스템 구축
IZE Chat Widget - 프로젝트 개요
Project
Overview

고객사 대부분은 AI 상담 시스템을 자체 구축할 개발 리소스가 없었고, 담당자가 비개발자인 경우가 많아 기술적 이해 없이도 바로 쓸 수 있어야 했습니다.

이 문제를 해결하기 위해, 고객사가 스크립트 한 줄만 붙이면 자사 웹사이트에 AI 상담 위젯이 바로 동작하는 임베더블 SaaS를 설계부터 배포까지 단독으로 구현했습니다. 고객사의 자체 문서를 RAG 파이프라인으로 검색·주입하여 근거 있는 답변을 생성하고, 응답은 SSE 스트리밍으로 실시간 전달되어 사용자가 자연스러운 대화 경험을 느낄 수 있도록 했습니다.

IZE Chat Widget - 핵심 기능
Key
Features

핵심은 "비개발자도 쉽게 사용할 수 있게 만들자"는 목표였습니다.

설치는 Script 태그 한 줄이면 끝나고, floating·inline·fullpage 세 가지 배포 모드 중 골라 쓸 수 있습니다. 위젯은 iframe으로 완전 격리되어 고객사 페이지의 CSS·JS와 충돌하지 않으며, postMessage 크로스도메인 통신으로 안전하게 데이터를 주고받습니다.

여러 고객사가 하나의 서비스를 공유하면서도 데이터가 섞이지 않도록, API Key 식별 + 도메인 화이트리스트 인증으로 테넌트를 격리했습니다. 색상·로고·환영 메시지 등 브랜딩 커스터마이징도 지원하여, 고객사 입장에서는 마치 자체 개발한 챗봇처럼 보이게 했습니다.

Challenge 1 | 크로스 도메인 통신 설계

상황: 고객사가 자기 사이트에 AI 채팅을 넣으려면 스크립트 한 줄만 붙이면 되어야 했습니다. 그런데 고객사 사이트와 위젯은 도메인이 다르기 때문에 브라우저 보안 정책(Same-Origin Policy)상 서로 데이터를 직접 주고받을 수 없었습니다.

판단: 위젯을 고객사 페이지에 직접 심으면 CSS·JS 충돌 위험이 크고 보안 격리도 안 됩니다. iframe으로 완전히 분리한 뒤 허가된 도메인만 메시지를 주고받게 하는 구조가 설치 편의성과 보안을 동시에 잡을 수 있다고 판단했습니다.

액션: iframe + postMessage 통신 아키텍처를 설계하고, Origin 검증으로 도메인 화이트리스트에 등록된 고객사만 통신을 허용하는 프로토콜을 구현했습니다.

결과: 고객사 사이트에 코드 한 줄로 삽입 가능한 무연동 위젯이 완성되었고, CSS·JS 충돌 없이 안전한 격리 환경에서 동작합니다.

Challenge 2 | 실시간 스트리밍 응답

상황: LLM이 답변을 생성하는 데 수 초가 걸립니다. 일반적인 REST API 방식으로는 전체 답변이 완성될 때까지 사용자가 빈 화면을 보며 기다려야 해서, 체감 응답 속도가 매우 느리다는 피드백이 있었습니다.

판단: WebSocket은 양방향 통신이 가능하지만 서버 리소스 부담이 크고 연결 관리가 복잡합니다. 이 위젯은 서버→클라이언트 단방향 전송이면 충분했기 때문에, 가볍고 재연결이 자동인 SSE(Server-Sent Events)가 최적이라고 판단했습니다.

액션: SSE 기반으로 LLM 응답을 토큰 단위로 스트리밍하는 파이프라인을 구현하고, 클라이언트에서 청크를 순차적으로 렌더링하여 타이핑 효과를 구현했습니다.

결과: 첫 토큰이 도착하는 즉시 화면에 표시되어 사용자 체감 대기 시간이 크게 단축되었고, 폴링 대비 서버 부하도 감소했습니다.

Challenge 3 | B2B 멀티테넌시 격리

상황: 하나의 서비스로 여러 기업 고객을 수용해야 했습니다. 그런데 A사의 상담 데이터가 B사에 노출되거나, 한 고객사의 트래픽 폭증이 다른 고객사에 영향을 주면 B2B SaaS로서 신뢰를 잃게 됩니다.

판단: 고객사마다 별도 인스턴스를 띄우면 격리는 완벽하지만 운영 비용이 고객 수에 비례해 증가합니다. 단일 인스턴스에서 API Key로 테넌트를 식별하고 도메인 화이트리스트로 접근을 제한하는 논리적 격리가 비용 효율과 보안의 균형점이라고 판단했습니다.

액션: 모든 요청에 API Key 기반 고객 식별 + 도메인 화이트리스트 검증을 적용하고, 요금제별 Rate Limiting으로 리소스를 공정하게 배분하는 미들웨어를 구축했습니다.

결과: 다수 고객사가 하나의 서비스를 공유하면서도 데이터가 완전히 격리되었고, 신규 고객사 온보딩 시 API Key 발급과 도메인 등록만으로 즉시 서비스 제공이 가능해졌습니다.

What I Learned | 배운 점

임베더블 아키텍처: iframe + postMessage 패턴을 직접 설계하면서, 타사 사이트에 무연동으로 삽입 가능한 위젯을 만드는 격리 설계 역량을 갖추게 되었습니다
기술 선택의 근거: SSE vs WebSocket, 논리적 격리 vs 물리적 격리 등 트레이드오프를 비교하고 상황에 맞는 선택을 문서화하는 습관이 생겼습니다
설계부터 배포까지 단독 수행: 요구사항 분석, 아키텍처 설계, 구현, 테스트, 배포를 혼자 진행하며 프로젝트 전체 흐름을 주도하는 경험을 했습니다
B2B 관점의 사고: 단순 기능 구현이 아니라 "고객사가 얼마나 쉽게 쓸 수 있는가"를 기준으로 설계하는 사용자 중심 사고를 익혔습니다