안녕하세요. 토스증권 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 개발로 배운 실전 인터랙션 팁

토스 챌린저스

웹 애니메이션 API를 활용하고 트랜스폼, 오퍼시티 등 컴포지터 스레드만으로 처리 가능한 애니메이션을 사용하면 JavaScript 스레드의 부담을 줄여 성능을 최적화하고 사용자 경험을 향상할 수 있습니다.

브라우저의 기본 스크롤 제어가 불가능하거나 특정 기능(핀치 줌, 스냅 등)이 필요할 경우, Three.js의 카메라 컨트롤을 커스텀하여 원하는 스크롤 모션이나 복잡한 인터랙션을 직접 구현하는 것이 효과적입니다.

인트로 애니메이션 구현 시, 투명 배경 영상을 사용하여 여러 개를 겹쳐 재생하고 캐시 API를 통해 리소스를 기기에 저장하면 네트워크 부하 없이 네이티브 앱과 유사한 유려한 사용자 경험을 제공할 수 있습니다.

토스증권 AI 시그널 프론트엔드 개발 경험 공유

안녕하세요, 저는 토스증권 AI 드라이브 프론트엔드 개발자 이승현입니다. 이 발표에서는 토스증권 AI 제품, 특히 AI 시그널을 개발하며 **고민하고 배웠던 점들을 공유**하고자 합니다. 토스증권 AI 시그널은 순수 웹 기반 서비스로, 초기 최소 런칭 스펙을 구현하면서 얻은 경험들을 위주로 말씀드리겠습니다.

애니메이션 구현과 성능 최적화: Motion 라이브러리 활용

애니메이션 구현 시 여러 방법론 중 'Motion' 라이브러리(이전 Framer Motion)를 선택했습니다. **Motion을 선택한 가장 큰 이유는 웹 환경에서도 네이티브 수준의 성능을 보장**하고 싶었기 때문이며, 웹 애니메이션 API를 우선 지원한다는 장점이 컸습니다. 웹 애니메이션 API는 자바스크립트 스레드 개입 없이 브라우저 컴포지터 스레드에서 트랜스폼이나 오퍼시티 등을 처리하여, 자바스크립트 스레드에 여유를 주어 다른 로직을 동시에 처리하고 유려한 인터랙션을 제공합니다.

구버전 브라우저 지원을 위해 `requestAnimationFrame` 방식도 필요했지만, Motion 라이브러리 내부적으로 이를 폴백으로 제공하여 개발 부담이 줄었습니다. 또한, React를 위한 Motion과 순수 JS를 위한 Motion 라이브러리를 **동시에 활용할 수 있어 스크롤 스프링 이징이나 랜덤 수열 생성 등 다양한 상황에 유용하게 적용**했습니다.

실제 성능 최적화가 필요했던 사례로 '펄스 애니메이션' 구현이 있었습니다. 이 애니메이션은 화살표 배경색이 왼쪽에서 오른쪽으로 그라데이션이 흐르는 형태로, 한 화면에 여러 컴포넌트가 존재할 수 있었습니다. 처음에는 마스크 포지션을 이용해 구현했으나, **QA 도중 서비스 접속 시 휴대폰 발열과 화면 렉이 발생하는 문제**가 발견되었습니다.

원인 분석 결과, **화살표 하나가 500번의 리페인트를 발생시켜, 화면 당 5,000번의 리페인트가 일어나는 심각한 성능 문제**였습니다. 이를 해결하기 위해 화살표 모양 틀을 만들고, 그 아래 레디얼 그라디언트를 단순히 X축으로 이동(translate X)시키는 방식으로 변경했습니다. 이 과정에서 AI 도구를 활용하여 SVG 패스를 빠르게 생성할 수 있었습니다.

이러한 개선을 통해 **화살표 한 개당 리페인트 횟수를 1회로 줄였고, 트랜스레이트 애니메이션이 컴포지터 스레드에서만 처리되면서 JS 스레드의 부담을 덜어 전반적인 사용자 경험이 크게 향상**되었습니다. 결론적으로, 애니메이션 성능을 고려할 때 웹 애니메이션 API를 활용하고, 컴포지터로만 처리될 수 있는 애니메이션을 이용하는 것이 중요합니다.

커스텀 스크롤 구현: Three.js 및 AI 활용

저희 서비스는 가로세로 스크롤을 지원해야 했는데, 스크롤이 한쪽 방향으로만 이루어져야 한다는 스펙이 있었습니다. 일반적인 `overflow: auto`를 사용하면 대각 스크롤이 발생하는 문제가 있었고, `overflow-x`나 `overflow-y`를 `hidden`으로 설정해도 대각 스크롤 제어가 불가능했습니다. 또한, **향후 핀치 줌 기능 추가 및 가로 스냅 기능 등 복잡한 요구사항**이 있었습니다.

이러한 문제와 복잡한 스펙을 해결하기 위해 **완전하게 커스텀할 수 있는 브라우저 스크롤을 직접 구현하기로 결정**했습니다. 순수 CSS나 Motion으로도 가능하지만, 컴퓨터 그래픽스의 '카메라' 개념을 이용해 코드를 추상화하고 간결하게 만들어 협업 효율성을 높이고자 Three.js를 도입했습니다.

Three.js 데모에 기본으로 포함된 `OrbitControls`는 3차원 이동 및 회전 등 기능이 너무 많았기 때문에, **`OrbitControls` 내부의 `CameraControls`를 커스텀하여 위아래, 좌우 이동만 가능한 형태로 설계**했습니다. 코드를 덜어내는 과정이 쉽지 않았지만, AI 에이전트의 도움을 받아 브라우저 코드 기반의 답변을 통해 구현 로직을 교차 검증하며 과감한 결정을 내릴 수 있었습니다.

세로 스와이프는 카메라의 페데스트랄 동작으로, 가로 스크롤은 카메라의 트럭 이동 방식으로 구현했습니다. 결과적으로 **브라우저 스크롤 제어가 어렵다면 직접 구현하는 것도 가능**하며, Three.js는 화려한 3D 게임 요소뿐 아니라 단순 벡터나 행렬 등에도 활용될 수 있음을 확인했습니다. 또한, Three.js와 CameraControls 커스터마이징을 통해 원하는 스크롤 모션을 쉽게 구현할 수 있었습니다. AI 도구의 보조가 이러한 과감한 결정에 큰 도움이 되었습니다.

인트로 애니메이션 구현 팁: 영상 활용 및 캐시 API

인트로 애니메이션 구현에 많은 고민이 있었지만, 생각보다 간단하게 해결되었습니다. 토스 앱에서 자주 볼 수 있는 로띠, 애니메이티드 WebP, GIF 같은 인트로 구현 시 **네이티브 앱과 유사한 경험을 제공하기 위한 두 가지 노하우**를 공유하고자 합니다.

첫째, 애니메이티드 WebP보다 **배경이 투명한 영상을 만들어 두 개를 겹쳐 활용**하는 것입니다. 웹에서 영상을 제어하는 것이 이미지나 로띠 로딩 및 재생 제어보다 훨씬 편리하고 쉽기 때문입니다. 둘째, **캐시 API를 이용하여 리소스 자체를 기기에 저장**하여 활용하는 것입니다. 명시적으로 리소스를 로딩해두면 네트워크로 인한 사이드 이펙트를 줄여 사용자에게 더 유려한 경험을 제공할 수 있습니다.

추가로 **미디어 데브 툴즈를 활용하면 영상의 재생 상태, 할당 및 해제 여부 등을 시각적으로 확인**할 수 있어 인트로 개발에 많은 도움이 되었습니다. 요약하자면, 인트로 애니메이션 구현 시 배경 투명 영상을 활용하고, 캐시 API로 영상 리소스를 기기에 저장하여 네트워크 부하 없이 최적의 사용자 경험을 제공하며, 미디어 데브 툴즈로 실시간 디버깅하는 것이 효과적입니다.

토스증권 AI 시그널 개발 중 펄스 애니메이션 최적화를 위해 기존 방식 대신 새로운 방식을 도입하게 된 구체적인 문제점과 해결 과정이 궁금합니다.

브라우저 스크롤을 직접 구현하기 위해 Three.js와 카메라 컨트롤을 커스텀하게 된 배경과 이 과정에서 AI 에이전트의 도움을 어떻게 받았는지 설명해 주세요.

인트로 애니메이션 구현 시 애니메이티드 WebP 대신 투명한 배경 영상을 활용하고 캐시 API를 사용한 이유와 그 장점은 무엇인가요?

발표자가 프론트엔드 개발 과정에서 Framer Motion 라이브러리를 선택한 주된 이유와 웹 애니메이션 API 활용의 장점에 대해 자세히 설명해 주세요.

Three.js가 화려한 인터랙션이나 3D 게임 요소 외에 토스증권 AI 시그널 서비스처럼 단순한 스크롤 모션 구현에 어떻게 활용될 수 있는지 구체적인 사례를 들어 설명해 주세요.

토스증권 AI 제품 프론트엔드 개발 과정 및 러닝 공유

발표자는 토스증권 AI 드라이브 프론트엔드 개발자 이승현으로, AI 기술 활용 고객 서비스를 만드는 조직에 소속됨.

토스증권 AI 시그널 제품 개발 경험을 중심으로 러닝과 개발 과정을 공유할 예정.

AI 시그널은 순수 웹 기반 서비스이며, 초기 런칭 스펙에서 구현해야 했던 내용 중 가장 기억에 남는 점들을 소개할 것임.

프레이머 모션(Framer Motion) 라이브러리 선택 및 애니메이션 성능 최적화

애니메이션/인터랙션 구현 방식 중 프레이머 모션(현 모션) 라이브러리를 선택함.

모션 선택의 가장 큰 이유는 성능으로, 웹에서도 네이티브 수준의 성능을 목표로 웹 애니메이션 API를 우선 지원하는 점을 활용.

웹 애니메이션 API를 사용하면 트랜스폼, 오퍼시티 등은 자바스크립트 스레드 개입 없이 브라우저 컴포지터 스레드에서 처리되어 JS 스레드 여유가 생김.

구버전 브라우저 지원을 위해 requestAnimationFrame(RAF) 방식도 필요했지만, 모션이 RAF를 폴백으로 제공하여 개발 부담을 줄임.

리액트용 모션과 순수 JS용 모션 라이브러리를 함께 사용하여 스크롤 시 스프링 이징이나 랜덤 수열 생성 등 다양한 기능 구현에 활용.

애니메이션 성능 최적화 사례: '펄스 애니메이션' 구현 시 초기 구현(mask-position 이용)에서 500번의 리페인트(요소당) 발생, 화면에 10개 있을 경우 5000번의 리페인트로 발열 및 렉 문제 발생.

문제 해결을 위해 화살표 모양 틀 아래 레디얼 그레디언트가 translate X만 작동하도록 변경하여 리페인트 횟수를 1회로 줄임.

화살표 모양 틀 제작 시 SVG 패스 사용 및 AI 도구 활용으로 개발 속도 향상.

최적화 결과, 발열 및 렉 문제 해결 및 트랜스레이트 애니메이션이 컴포지터 스레드에서 처리되어 JS 스레드 부담 감소, 전반적인 사용자 경험 개선.

애니메이션 성능 고려 시 웹 애니메이션 API 활용, 컴포지터로만 처리 가능한 애니메이션 활용이 중요.

가로/세로 스크롤 및 핀치 줌 커스텀 구현 (Three.js 활용)

서비스 스펙상 한쪽 방향(가로 또는 세로)으로만 스크롤이 가능해야 했으나, `overflow: auto` 사용 시 대각 스크롤 문제 발생.

추가적으로 핀치 줌, 가로 스냅 등 복잡한 스펙 요구로 인해 브라우저 스크롤을 직접 커스텀 구현하기로 결정.

컴퓨터 그래픽스의 '카메라' 개념을 활용하여 코드 추상화 및 간결화를 위해 Three.js를 도입.

Three.js의 기본 Orbit Controls 기능이 너무 많아(3차원 이동, 회전 등), 서비스에 필요한 상하좌우 이동만 남기도록 카메라 컨트롤 커스텀.

커스텀 구현은 쉽지 않았으나, AI 에이전트의 도움을 받아 브라우저 코드 기반 답변으로 구현 로직을 교차 검증하며 과감한 결정 가능.

세로 스와이프는 카메라의 패데스트랄 동작, 가로 스크롤은 카메라의 트럭 이동 방식으로 구현.

브라우저 스크롤 제어가 어렵다면 직접 구현 가능하며, Three.js는 3D 게임 요소 외에 단순 벡터/행렬 활용 및 커스텀 카메라 컨트롤로 원하는 스크롤 모션 구현에 용이.

AI 도구의 보조가 과감한 기술적 결정에 도움을 줌.

인트로 애니메이션 구현 노하우

토스 앱에서 볼 수 있는 인트로 애니메이션(로띠, 애니메이티드 WebP, GIF 등)을 웹에서 네이티브 앱과 유사한 경험으로 구현하기 위한 두 가지 노하우.

첫째, 애니메이티드 WebP보다 배경이 투명한 영상 두 개를 겹쳐서 만드는 방법.

둘째, 캐시 API를 이용해 리소스를 기기에 저장하여 활용.

이유: 웹에서 영상 제어가 이미지나 로띠보다 편리하고 쉬움; 캐시 API로 명시적 로딩 시 네트워크 사이드 이펙트 감소 및 유려한 사용자 경험 제공.

미디어 데브 툴즈(Media Dev Tools) 활용으로 영상 재생, 할당, 해제 상태를 시각적으로 확인하며 인트로 개발에 도움받음.

인트로 애니메이션은 배경이 투명한 영상을 활용하는 것이 사용자 경험에 가장 좋았으며, 캐시 API로 리소스를 기기에 저장하여 네트워크 부하 없이 사용자 경험 향상 가능. 미디어 데브 툴즈로 영상 상태 실시간 시각적 디버깅 가능.