백엔드 10분, 프론트엔드 10일
솔직히 말하면 저도 똑같은 경험을 했습니다. OpenAI API 연결하는 데 점심시간이면 충분한데, 채팅 UI를 '제대로' 만드는 데는 스프린트 하나가 통째로 날아갑니다. 최근 dev.to에서 화제가 된 React RAG UI Kit 오픈소스 프로젝트는 이 고통을 정확히 짚고 있습니다. 제작자 Beyza Arisoy는 "세 번째 AI 챗 인터페이스를 처음부터 다시 짤 때 깨달았다"고 했는데, 사실 이건 모든 프론트엔드 개발자의 데자뷔죠. 스트리밍 텍스트 렌더링, 마크다운 파싱, 오토스크롤, 로딩·에러·타이핑 인디케이터—이 네 가지가 매번 발목을 잡습니다.
1ms 단위로 쪼개지는 스트리밍 렌더링의 함정
사용자 입장에서는 AI가 타이핑하듯 한 글자씩 나타나는 게 '자연스러운' 경험입니다. 그런데 이걸 React로 구현하면 이야기가 달라져요. SSE(Server-Sent Events)나 WebSocket으로 들어오는 텍스트 chunk를 매번 setState로 업데이트하면, 리렌더링 폭탄이 터집니다. 100ms에 한 번 토큰이 들어온다고 쳐도, 긴 응답이면 수백 번의 상태 변경이 발생하거든요.
해당 UI Kit이 Framer Motion 기반의 'Smooth Typewriter Streaming'을 내세우는 이유가 여기 있습니다. 하지만 Figma에서 볼 때는 타이프라이터 애니메이션이 예뻤는데, 실제로 구현하면 requestAnimationFrame 타이밍과 React의 배치 업데이트가 충돌하는 순간이 옵니다. useDeferredValue나 useTransition으로 우선순위를 조정하거나, 아예 DOM 직접 조작으로 빼는 트레이드오프를 고민해야 하죠. 사실 이건 flexbox 정렬 같은 문제가 아니라, 렌더링 파이프라인 레벨의 디테일입니다.
마크다운 파싱 + 다크모드: 디자인 토큰이 깨지는 접점
AI 응답에는 코드 블록, 리스트, 볼드 텍스트가 뒤섞여 나옵니다. 문제는 이 마크다운이 '스트리밍 도중에' 파싱되어야 한다는 거예요. react-markdown이나 unified 생태계를 쓰더라도, 불완전한 마크다운—예를 들어 코드 블록이 아직 닫히지 않은 상태—을 중간에 렌더링하면 레이아웃이 춤을 춥니다.
여기에 다크모드 테마 토글까지 얹으면 상황이 복잡해집니다. Syntax highlighting 라이브러리(Prism, Shiki 등)의 테마 토큰과 Tailwind CSS의 dark: variant가 동기화되지 않으면, 코드 블록만 밝은 배경으로 남아 있는 참사가 벌어지죠. 디자인 시스템에서 Design Token을 CSS custom property로 관리하고 있다면 그나마 낫지만, 실시간 스트리밍 중 테마 전환 시 FOUC(Flash of Unstyled Content)를 1프레임이라도 허용할 것인지는 기획 단계에서 정해야 할 사안입니다.
벤치마크로 증명하라: 측정 없는 최적화는 도박
흥미롭게도 같은 시기에 Mahdi Shamlou가 dev.to에 공유한 웹 프레임워크 벤치마킹 방법론이 이 맥락에 딱 맞습니다. Docker로 CPU·메모리를 격리하고, k6로 부하 테스트를 걸고, P95 레이턴시와 요청 처리량을 측정하는 접근—이걸 그대로 프론트엔드 스트리밍 렌더링에 적용해야 합니다.
구체적으로 말하면, Lighthouse의 Total Blocking Time(TBT)이나 Interaction to Next Paint(INP)를 스트리밍 응답 시나리오에서 프로파일링해야 합니다. 100토큰, 500토큰, 2000토큰 응답에서 각각 INP가 어떻게 변하는지 측정하지 않으면, "체감상 빠르다"는 착각에 빠집니다. Shamlou가 강조한 것처럼, 워커 수와 리소스 제한을 동일하게 맞추지 않으면 벤치마크 자체가 무의미하듯, 프론트엔드도 네트워크 스로틀링과 디바이스 프로파일을 통제한 상태에서 측정해야 합니다.
시사점: 오픈소스 UI Kit은 '시작점'이지 '완성'이 아니다
React RAG UI Kit 같은 프로젝트는 분명 초기 개발 시간을 절약해 줍니다. 하지만 프로덕션에 올리는 순간, 번들 사이즈(Framer Motion만 해도 minified 기준 ~30KB), 트리셰이킹 가능 여부, 그리고 여러분의 디자인 시스템과의 토큰 충돌 문제가 기다리고 있습니다. "이 라이브러리 도입하면 bundle size가 얼마나 늘어나지?"라는 질문을 반드시 해야 해요.
전망: AI 챗 UI는 '컴포넌트'가 아니라 '시스템'으로 진화한다
앞으로 AI 챗 인터페이스는 단순한 메시지 버블을 넘어, PDF 인라인 뷰어(RAG citation용), 파일 드롭존, 멀티모달 미디어 프리뷰까지 품게 될 겁니다. 이 시점에서 필요한 건 컴포넌트 하나가 아니라, Container Queries로 반응하는 레이아웃 시스템, 스트리밍 상태를 관리하는 전용 상태 머신, 그리고 접근성(스크린리더가 실시간 생성 텍스트를 어떻게 읽어줄 것인가)까지 고려한 설계입니다.
결국 AI 챗 UI의 품질은 Figma 시안의 완성도가 아니라, 스트리밍 첫 토큰이 화면에 찍히는 그 1ms의 디테일에서 갈립니다. 그리고 그 1ms를 측정하고 개선하는 문화가, 좋은 프론트엔드 팀과 그렇지 않은 팀을 나누는 기준이 될 겁니다.