안녕하세요. 토스증권 AI 드라이브 프론트엔드 개발자 이승현입니다.

마지막 3부 주제로 토스증권 AI 제품에 프론트 개발을 하면서 고민하고 배웠던 점들에 대해 이야기해 보려고 합니다. 본격적인 발표에 앞서 아마 발표를 듣고 계신 많은 분들이 발표 제목인 AI에 관심이 있으실 것으로 예상을 하는데요.

저희 팀은 AI 기술을 활용한 고객 서비스를 만드는 조직으로 최근 토스증권 여러 곳에서 만나보셨을 것으로 예상합니다.

그래서 오늘 제가 얘기해 볼 주제는 토스증권 AI 제품 중 토스증권 AI 시그널을 개발하면서 얻은 러닝과 쉽지는 않았던 개발 과정에 대해서 공유해 보려고 합니다.

참고로 토스증권 AI 시그널은 순수 웹 기반의 서비스입니다. 당시 처음 서비스를 계획하고 최초 아, 최소 런칭 스펙을 정리했을 때 여기 보이는 스펙들이 최종적으로 구현을 했어야 했던 스펙들인데요.

어 오늘은 여기 나열된 내용 중에서 가장 기억에 남는 내용들을 소개해 드리고자 합니다.

아마 애니메이션이나 인터랙션 구현을 좀 해 보신 분들이라면은 어 머릿속에 딱 떠오를 만한 구현 방법들인데요.

어 각자 특색이 있고 장단점이 있는 방법들입니다. 어, 물론 저희 토스 증권 내에서도 이 세 가지 방법들을 모두 사용을 하고 있고요.

하지만 그중에서도 이번 AI 시그널 제품에는 어 프레이머 모션 이제는 모션이란 이름으로 통합된 어 모션 라이브러리를 선택하게 되었는데요.

어 모션을 선택하게 된 가장 큰 이유는 성능에 있었습니다.

어 웹 환경에서도 저희가 네이티브 수준의 성능을 보장하고 싶었고 어 모션이 웹 애니메이션 API를 우선 지원한다는 장점이 있어서 선택하게 되었습니다.

어, 웹 애니메이션 API를 이용해서 애니메이션을 구현하게 되면 어, 일부 애니메이션, 특히 트랜스폼이나 오퍼시티 등은 자바스크립트 쓰레드 개입 없이 브라우저 컴포지터 쓰레드에서만 처리 가능하게 되고 이는 곧 자바스크립트 쓰레드의 여유를 만들어 주는 역할을 하게 됩니다.

그렇다면 자바스크립트 쓰레드 여유가 생기면은 그만큼 다른 로직들을 동시에 처리할 수 있게 되고 사용자들 입장에서는 유려한 인터랙션을 제공받게 되므로 이제는 웹 애니메이션 API를 안 쓸 이유가 없어졌죠.

네. 하지만 구버전 브라우저를 사용하고 계신 고객분들도 계시기 때문에 아직 리퀘스트 애니메이션 프레임 방식을 포기할 수는 없었습니다.

하지만 모션 내부적으로 RAF 방식을 풀백으로 제공을 하고 있었기 때문에 실제 개발을 함에 있어서 크게 신경 쓸 부분이 줄었던 것 같습니다.

그리고 추가로 이제 리액트를 위한 모션과 순수 JS를 위한 모션 라이브러리 이렇게 두 개로 나눠져 있는데요.

어, 실제 프로젝트에서 이 두 가지 라이브러리들을 동시에 사용할 수도 있었습니다.

그리고 어, 지금 생각해 보니까 생각나는 예시로는 어 특정 요소로 스크롤 할 때 뭐 스프링 이징 같은 거를 넣을 때 어 리액트 버전의 모션이 아닌 그 모션 자체의 유틸리티를 썼던 기억이 납니다.

어, 그리고 추가로 랜덤 수열 같은 걸 만들 때도 어, 이런 모션 라이브러리가 큰 도움이 됐던 거 같습니다.

그래서 실제로 저희 이 애니메이션 성능 최적화가 필요했던 예시를 하나 가져와 보았는데요.

어, 여기 아래 영상을 잘 보시면은 화살표 배경색이 왼쪽에서 오른쪽으로 뭔가 그라디언트가 흐르는 저희는 펄스 애니메이션이라고 부르는데요.

어, 이런 펄스 애니메이션들을 구현해야 했었고 어, 해당 모션이 적용된 컴포넌트가 어, 한 화면에 여러 개까지 존재할 수 있었던 스펙이었습니다.

그래서 이 애니메이션을 이제 실제로 구현하라고 하면은 많은 분들이 이렇게 마스크 포지션을 이용해서 구현을 하실 겁니다.

실제로도 이렇게 구현하면은 잘 작동하고요.

저도 처음에는 이렇게 구현을 했었거든요. 근데 이게 개발을 마무리하고 저희가 이제 QA를 하던 도중에 그 서비스에 접속만 하면은 이제 핸드폰이 뜨거워지고 화면에 렉이 발생한다는 거예요.

그래서 저희가 이게 이유를 찾아보았죠.

그래서 여러 가지 이유를 찾던 중에 진짜 원인을 찾게 되었습니다.

이 펄스 화살표 하나가 리페인트를 500번씩 발생시키고 있었던 거죠.

그러니까 아까 화면에 열 개, 최소 열 개가 나올 수 있다고 했으니까 화면 접속, 한 서비스 접속 한 번에 5,000번의 리페인트가 발생했던 것이죠.

그래서 고민을 했습니다. 그래서 이 문제를 어떻게 해결할까 고민을 했었고 고민 끝에 내린 답은 이것이었습니다.

여기 영상에서 보시는 것처럼 화살표 모양의 틀을 만들고 그 틀 아래 레디얼 그레디언트가 단순히 왼쪽에서 오른쪽으로 트랜스레이트 X만 작동시키는 방식이었죠.

그렇게 되면 여기 영상에서 보시는 것처럼 작동하게 되겠죠.

아, 그리고 참고로 이 화살표 모양 틀을 만들 때 기존 화살표 모양에 맞게 똑같은 그 SVG 패스를 만드는 게 되게 중요했었는데요.

이러한 작업들을 AI 도구를 이용해서 빠르게 개발할 수 있었습니다.

그래서 이렇게 화살표 한 개당 리페인트 횟수를 한 번으로 줄이게 되니 아까 말씀드렸던 발열이나 아니면 렉 같은 현상이 많이 그 문제가 해결이 되게 되었고요.

그리고 리페인트 횟수를 1회로 줄였을 뿐만 아니라 아까 말씀드렸듯이 트랜스레이트 애니메이션은 컴포지터 스레드로만 처리되는 애니메이션이기 때문에 JS 스레드에서 더 많은 일들을 처리할 수 있게 되었습니다.

그래서 전반적인 서비스의 사용자 경험이 좋아졌던 그런 사례였던 거로 기억이 납니다.

그래서 정리를 해 보자면 이렇게 말씀드릴 수 있을 것 같아요.

애니메이션 성능을 고려를 한다면은 이제 웹 애니메이션 API를 안 쓸 이유가 없다.

그리고 컴포지터로만 처리될 수 있는 애니메이션을 이용하면은 서비스 애니메이션 구현에 애니메이션 성능 구현에 큰 도움이 됩니다.

그리고 두 번째로 저희가 고민했었던 주제인데요.

저희 제품에 보시면, 아 저희 서비스에 보시면은 가로 세로 스크롤을 하실 수 있어요.

근데 이게 그 스펙 논의를 했을 때 스크롤을 한쪽 방향으로만 이렇게 할 수 있게 만들어 주라는 스펙이었죠.

이것도 아마 처음 들으시면은 이렇게 생각하실 수 있습니다.

그거 그냥 오버플로 오토 쓰면 되는 거 아닙니까?

할 수 있는데 네. 저도 처음에는 그렇게 생각을 했습니다.

근데 한 가지 간과한 점이 있었습니다. 이 오버플로 오토를 쓰게 되면은 대각 스크롤이 발생하게 됩니다.

그래서 아시다시피 오버플로 X나 Y 한쪽을 히든을 시키면은 한쪽 방향으로만 스크롤이 되죠.

이게 대각 스크롤을 어떻게 제어할 수가 없었어요. 그래서 이것도 어떻게 해결할까 되게 고민을 많이 했습니다.

그리고 서비스에서 추가로 요구했던 스펙이 스크롤만 되는 게 아니라 나중에는 이제 핀치 줌도 추가될 가능성이 존재했었고요.

그 가로 방향에 대해서는 스냅 기능이 필요했고 네, 세로 방향에 대해서도 여러 가지 스펙을 추가로 구현했었어야 됩니다.

그래서 많은 고민 했었고 저는 이럴 바엔 그냥 제가 완전하게 커스텀 할 수 있는 브라우저 스크롤을 직접 구현하기로 했습니다.

그래서 도입하게 된 게 이게 사실 순수 CSS나 모션을 이용해서 스크롤을 구현할 수도 있습니다.

근데 개념적으로 이 컴퓨터 그래픽스의 카메라라는 개념을 좀 이용해서 코드 자체를 추상화 좀 해보고 싶었고 코드도 간결해지고 이제 같이 협업하시는 팀원분들에도 협력 협업하는 데도 도움이 될 것이라 생각해서 3JS를 이용해 서비스 전면에 적용해 보기로 결정을 했습니다.

아마 3JS 써 보신 분들 아시겠지만 데모를 실행하면은 요렇게 보시는 그림처럼 Orbit Controls 제스처가 기본으로 세팅되어 있을 거예요.

근데 이 저희 시그널 서비스에 있어서 이 Orbit Controls 기능이 너무 많았어요.

이게 Orbit Controls 해보시면은 3차원 이동이나 회전들도 할 수 있는데 저희 서비스에서는 단순히 위로 아래로 그리고 좌우로 움직일 수만 있으면 됐었어요.

그래서 Orbit Controls이 내부적으로 이제 카메라 컨트롤이라는 걸 쓰고 있는데, 이 친구들을 커스텀해서 저희가 원하는 동작들만 남기는 방향으로 설계를 시작을 했습니다.

근데 이제 코드를 덜어내는 과정에서 이게 구현이 쉬웠냐라고 물어보신다면은 쉽지 않았다고 답변드리겠습니다.

하지만 이게 구현을 할 때 이 부분도 이제 AI 에이전트 도움을 좀 많이 받았고요.

실제 이 AI 에이전트가 브라우저 코드를 기반으로 이제 뭔가 답변을 주기 때문에 실제로 그 브라우저 내부의 스크롤 로직과 제가 구현한 로직이 교차 검증이 되는 그런 효과가 있어서 조금 과감한 결정을 할 수 있었던 것 같습니다.

그래서 여기 세로 스와이프 같은 경우는 카메라의 패데스트랄 동작을 이제 구현한 거고, 가로 스크롤 같은 경우는 이제 카메라의 트럭이라는 이동 구현 방식을 택하게 되었습니다.

그래서 이제 좀 리캡을 해 보자면은 이렇게 정리해 볼 수 있을 것 같은데요.

이 브라우저 스크롤을 제어할 수 없다면 직접 만들어 제어하는 것도 가능하고 Three.

js가 보통 이제 화려한 인터랙션 구현이나 뭐 이런 3D 게임 요소들 이런 것들을 구현하는 데 사용한다고 생각을 하실 텐데 어 여기 저희 서비스처럼 단순 벡터나 아니면 행렬 등에 활용될 수 있습니다.

그리고 Three.js와 카메라 컨트롤을 조금 커스텀하시면은 원하는 스크롤 모션을 조금 쉽게 구현할 수도 있었습니다.

어 그래서 뭐 조금 더 말씀드리자면은 이런 과감한 결정에 자신이 좀 있었던 이유는 그 AI 도구가 기본적인 로직을 같이 보조하고 있었던 이유도 있었던 것 같습니다.

그리고 세 번째로 소개해 드리고 싶었던 부분은 인트로 애니메이션인데요.

이게 실제로 구현할 때는 고민이 좀 많았습니다.

근데 생각보다 간단하게 끝났어요.

아마 토스 앱을 사용하시다 보면은 이런 류의 인트로를 좀 종종 보실 수 있는데요.

보통 로띠나 애니메이티드 WebP 혹은 뭐 애니메이티드 GIF 이런 것들을 사용하곤 하죠.

근데 어 이러한 인트로 웹에서 구현을 한다고 했을 때는 어 네이티브 앱과 비슷한 이제 경험을 주고 싶으실 텐데 어 이때 적용해 볼 법한 두 가지 노하우를 좀 공유드려 볼게요.

첫 번째로는 어 애니메이티드 WebP보다는 어 배경이 투명한 영상을 만들 수 있다면은 그 동영상 두 개를 겹쳐서 어 만들 수 있다는 거.

그리고 두 번째로는 어 캐시 API를 이용해서 어 기기 그 리소스 자체를 기기에다가 어 저장해서 활용할 수 있다는 것, 요 두 가지를 말씀드리고 싶었습니다.

어 네, 그 이유는 이제 웹에서 영상을 제어하는 것이 이미지나 로띠 로딩, 뭐 재생 제어하는 거보다 훨씬 더 편리하고 쉽기 때문이고요.

어 또한 캐시 API를 이용해서 명시적으로 어 리소스를 로딩을 해 두면은 그 네트워크로 인한 사이드 이펙트를 줄일 수가 있습니다.

어 네트워크 네트워크로 인한 사이드 이펙트가 줄어들면은 어 그만큼 사용자들에게 더 유료한 사용자 경험을 제공할 수 있을 것이고요.

어, 그를 추가로 조금 어, 개발하 데 도움이 됐던 거는 어, 미디어 데블 툴즈를 이번에 처음 써 봤는데 어, 이 미디어 데블 툴즈를 사용하게 되면은 어, 현재 영상들이 잘 재생 중인지 아니 멈췄는지 아니면 영상들이 뭐 할당이 되는지 해제가 되는지 이런 것들을 어, 시각적으로 확인해 보실 수 있어서 어, 이런 인터 인트로 개발에 많은 도움이 됐었던 거 같습니다.

네. 조금 빠르게 어 정리를 해 보자면은 어 인트로 애니메이션 구현 같은 경우는 뭐 애니메이티드 PNG, 뭐 GP 이런 거 쓸 수 있는데 어 가장 경험이 좋았던 거는 어 배경이 투명한 영상을 만들어서 이제 겹치거나 아니면은 그걸 서빙하는 그런 방법이 어 가장 어 사용자 경험이 좋았던 거 같고요.

어, 캐시 API도 있으니 영상 리소스를 기계에 명시적으로 저장을 해 두고 네트워크를 태우지 않고 기기에서 가져와서 사용자 경험에 도움을 줄 수도 있다.

그리고 세 번째로 미디어 트윈즈를 이용하면은 영상의 상태를 실시간으로 시각적으로 디버깅할 수 있다.

요런 팁들을 얻을 수 있었습니다.

테크톡톡 2026 | Frontend Developer - 토스증권 AI 개발로 배운 실전 인터랙션 팁

Scripts