무슨 일이 있었냐면
claude.ai를 만드는 팀이 웹 앱을 2주 만에 3배 빠르게 만든 과정을 글로 공개했어요. 서버의 모델 추론 속도가 아니라 브라우저에서 돌아가는 화면, 즉 프론트엔드 얘기예요. 요즘 AI 채팅 서비스는 모델 성능만큼이나 「타이핑할 때 버벅이지 않는가」, 「긴 대화를 스크롤할 때 끊기지 않는가」 같은 체감 속도가 중요하거든요. 모델 답변이 아무리 빨라도 화면이 렌더링을 못 따라가면 사용자는 그냥 느리다고 느껴요.
이 글이 흥미로운 건 두 가지 때문이에요. 하나는 2주라는 짧은 기간에 3배라는 큰 숫자가 나왔다는 것. 다른 하나는 여기서 쓰이는 기법들이 특별한 비밀이 아니라, 우리가 만드는 React 앱에도 그대로 적용할 수 있는 것들이라는 점이에요. 그래서 오늘은 채팅 앱이 느려지는 구조적인 이유와, 이런 종류의 최적화가 어떻게 이루어지는지를 풀어볼게요.
채팅 앱은 왜 유독 느려질까요
일반 웹페이지와 달리 AI 채팅 앱에는 스트리밍이라는 독특한 부하가 있어요. 이게 뭐냐면, 모델이 답변을 다 만들 때까지 기다리지 않고 토큰이 생성되는 대로 한 조각씩 화면에 뿌려주는 방식이에요. 초당 수십 개의 조각이 도착하고, 조각이 올 때마다 화면을 갱신해야 하죠. 여기서 문제가 시작돼요.
React 같은 프레임워크는 상태가 바뀌면 관련 컴포넌트를 다시 그려요. 그런데 대화 전체를 하나의 큰 상태로 들고 있으면, 토큰 하나가 추가될 때마다 대화 전체가 다시 렌더링되는 일이 벌어져요. 메시지가 5개일 때는 티가 안 나지만, 100개짜리 긴 대화에서는 토큰 하나당 100개 메시지를 다시 계산하는 셈이라 금방 버벅이기 시작하죠.
여기에 마크다운 렌더링이 얹혀요. 모델 답변은 마크다운이니까 매번 파싱해서 HTML로 바꿔야 하는데, 코드 블록이 있으면 문법 강조까지 돌려야 해요. 토큰이 하나 올 때마다 3000자짜리 마크다운을 처음부터 다시 파싱하고 있다면, CPU가 그걸 초당 수십 번 하는 거예요. 브라우저의 메인 스레드는 하나뿐이라서, 이 작업이 밀리면 타이핑 입력조차 늦게 반응하게 돼요.
어떤 종류의 수정이 3배를 만드나
이런 문제를 고치는 작업은 대체로 다음 순서로 진행돼요. 첫 번째는 측정이에요. 브라우저 개발자 도구의 Performance 탭이나 React Profiler로 실제로 어디서 시간이 새는지 확인하는 거죠. 감으로 고치면 열에 아홉은 엉뚱한 곳을 손대게 되거든요. 2주라는 기간의 상당 부분은 여기에 쓰였을 가능성이 높아요.
두 번째는 렌더링 범위를 좁히는 거예요. 스트리밍 중인 마지막 메시지만 자주 갱신되고, 나머지 완료된 메시지는 건드리지 않도록 컴포넌트를 쪼개고 메모이제이션을 걸어요. 이게 뭐냐면, 입력값이 같으면 이전 계산 결과를 그대로 재사용하는 기법이에요. 완료된 메시지는 내용이 안 바뀌니 다시 그릴 이유가 없죠.
세 번째는 갱신 빈도를 조절하는 거예요. 토큰이 올 때마다 화면을 그리는 대신, 화면 주사율에 맞춰 16밀리초에 한 번씩 모아서 그리면 사람 눈에는 차이가 없는데 렌더링 횟수는 크게 줄어요. 네 번째는 가상화예요. 긴 대화에서 화면에 보이는 메시지만 DOM에 올리고 나머지는 스크롤할 때 그리는 방식이죠. 마지막으로 초기 로딩 쪽에서는 번들 쪼개기가 있어요. 문법 강조 라이브러리처럼 무거운 코드를 처음부터 다 내려받지 않고 필요할 때 불러오는 거예요.
이 중 어느 하나가 3배를 만들지는 않아요. 하지만 각각 20~30퍼센트씩 깎이는 수정이 대여섯 개 겹치면 곱해져서 3배가 나오거든요. 오래된 서비스일수록 이런 저비용 고효과 수정이 손대지 않은 채 쌓여 있는 경우가 많고, 그래서 2주 만에 큰 숫자가 나올 수 있는 거예요.
업계 흐름에서 보면
ChatGPT, Gemini, Perplexity 같은 서비스들도 비슷한 고민을 계속하고 있어요. 스트리밍 마크다운을 처음부터 다시 파싱하지 않고 증분으로 처리하는 라이브러리들이 나오고 있고, 무거운 파싱을 웹 워커(메인 스레드와 별개로 돌아가는 백그라운드 스레드)로 빼는 시도도 있죠. React 쪽에서는 컴파일러가 메모이제이션을 자동으로 넣어주는 방향으로 가고 있어서, 앞으로는 이런 수작업 최적화 중 일부가 자동화될 거예요.
한국 개발자에게 주는 시사점
지금 사내에서 챗봇 UI나 AI 기능을 붙인 서비스를 만들고 있다면, 이 접근법은 거의 그대로 가져다 쓸 수 있어요. 특히 스트리밍 응답을 받아서 마크다운으로 보여주는 화면이 있다면 「토큰 하나당 몇 번 렌더링되는가」를 한 번 프로파일러로 찍어보세요. 생각보다 훨씬 많이 그리고 있을 확률이 높거든요. 그리고 성능 개선은 거창한 리팩터링보다 측정하고, 제일 큰 것부터 하나씩 고치는 반복이 훨씬 효과적이라는 것도 기억해 두면 좋아요.
정리하면
AI 채팅 앱의 체감 속도는 모델이 아니라 스트리밍 렌더링을 얼마나 영리하게 처리하느냐에 달려 있고, 그 최적화는 측정에서 시작한다. 여러분 프로젝트에서는 성능 문제를 발견했을 때 어디서부터 손대시나요? 프로파일러부터 켜시나요, 아니면 일단 감으로 의심 가는 곳부터 고치시나요?
🔗 출처: Hacker News