안녕하세요, Simplicity 4 프로젝트에서 프론트엔드 개발을 맡은 Frontend UX Engineer 박은식, 이예서입니다. 이번 프로젝트를 진행할 때 기술적으로 고민했던 내용들을 공유하고자 해요.

재사용 가능한 컨퍼런스 만들기
이번 Simplicity 프로젝트는 다음 시즌에도 재사용 가능하도록 구조화하는데 초점을 맞췄어요. 
그로 인해 세션 화면을 컴포넌트 단위로 템플릿화하고, 세션 정보를 시트에 입력받아 누구나 쉽게 세션 내용을 수정할 수 있도록 만들어야 하는 요구사항이 있었죠.
그 중에서도 각 세션 화면이 인터렉션을 통해 자연스럽게 연결되게 하는 것이 무척 어려웠는데요. 화면 템플릿마다, 또 플랫폼마다 인터렉션 스펙이 전부 달랐기에 고민해야 할 지점이 많았어요. 그래서 저희는 세션 템플릿의 구성 요소를 4분할하고, 공통된 인터렉션 흐름을 정의했어요.


위 사진과 같이 Simplicity 세션은 총 12개 템플릿의 조합으로 진행돼요. 모바일과 데스크탑까지 고려해야하는 만큼 중복을 줄이고 패턴화시켜 구현해야할 필요가 있었어요. 저희는 템플릿들의 각 요소들을 분리해서 크게 네 가지로 분류했는데요.


연사자의 대본이 위치하는 Script
Script의 상단에 위치하는 Top
Script 외의 영역을 차지하는 Canvas
스크립트 뒤에 깔려 화면 전체를 차지하는 Background
12개의 템플릿의 구성요소들을 위 네 가지로 분류한 후 분류된 것 내에서 애니메이션으로 전환하도록 구현하였어요. 특히 Script의 경우 계속해서 하단과 중단을 왔다갔다 해야했고, 화면마다 라인수가 달라져 정확하게 위치를 잡는것이 까다로웠는데요. 어떤 템플릿을 사용하고 있는지, 기기의 높이는 얼마나 되는지에 따라 휴리스틱하게 위치를 잡도록 구현하였어요. 이러한 방식을 통해 템플릿의 모든 요소를 자신의 위치에 정확하게 렌더링시키는 것 뿐만 아니라 추후 유지보수도 효율적으로 할 수 있었어요.



다양한 브라우저 대응하기
모바일에서도 시청 가능해야 하는 만큼, 삼성, Safari 등 각각 다른 브라우저에서의 대응 작업도 필요했어요. 개발로 해소할 수 있는 문제는 대부분 해결했지만, 브라우저 정책 상 해결이 불가능한 문제들은 스펙 변경을 설득해야 했어요.
대표적으로 모바일 Safari 브라우저에는 비디오가 포함된 화면에서 유저 인터렉션이 발생해야 비디오를 재생할 수 있는 스펙이 있었고, 이 문제를 해결하기 위해 Audio로 우회하는 등 여러 시도를 해보았지만 잘 동작하지 않았어요. 결국 해당 브라우저에서는 버튼을 터치해야 세션이 재생될 수 있게 하는 동작을 추가했어요.
아래 영상과 같이 Blur를 사용할 경우 Safari에서는 눈에 띄게 성능이 저하되는 경우도 있었는데요. 가장 뒤에 깔리는 BackgroundImage를 Safari에서는 좀 더 낮은 opacity를 주어 비슷한 느낌을 구현하기도 했어요.


로드 최적화하기
이번 Simplicity는 처음으로 모바일 공식 지원을 하게 되어서, 로드 최적화가 그 어느 때보다 중요했어요.
개발된 화면을 모바일 기기에서 테스트 해보니, 개발 환경에서와 다르게 애셋이 느리게 뜨거나 연사자 음성이 느리게 재생되는 등의 로드 이슈가 발생했어요. 인스타그램 스토리처럼 자연스럽게 넘어가야 하는데, 로드 시간 때문에 버그처럼 느껴졌죠.
하나씩 로드를 느려지게 한 범인을 색출해 나갔어요. 용량이 큰 에셋들이 대부분 gif인 것을 발견하고, 비교적 용량 문제로부터 자유로운 webp로 교체했고, 세션 진입 시점에 필요한 에셋들을 순차적으로 미리 로드해 세션 재생 도중에 에셋이 비어있는 상황을 대폭 개선했습니다. 연사자 영상의 경우엔 하나의 video element를 필요한 위치에 텔레포트시켜 중복 로드를 막기도 했어요.
애셋 문제 뿐만 아니라 디바이스 판별 후 라우팅하는 로직의 성능 문제 등 코드적인 성능 문제도 발견하고 해소하는 과정을 거쳤어요.
프로파일러를 며칠 내내 돌려보며 외로운 싸움을 한 결과 모바일 기기에서도 문제 없이 시청 가능하게끔 만들 수 있었어요.


렌더링 최적화하기
특히 홈의 경우 데스크탑에서는 모바일보다 복잡한 인터랙션과 좀 더 많은 요소들을 필요로 했는데요. React의 Memoization 함수들을 사용하여 카드들의 필요한 부분만 렌더링되도록 하였고, 위치나 투명도 등 스타일 변경이 필요하다면 상태를 변경하기보다 element의 스타일을 직접 변경하는 방식을 사용했어요. 크롬 개발자도구에서 CPU 감속을 걸며 렌더링을 깎은 결과, 처음에 비해 상당한 성능 개선을 이뤄낼 수 있었어요.









함께 만든 개발자들의 후기
예서
입사 전에 Simplicity 컨퍼런스 페이지를 보면서 “이걸 꼭 내 손으로 만들어보고 싶다”고 느꼈고, 그 마음이 토스에 오게 된 계기 중 하나였어요. 그래서 이 프로젝트에 참여하게 된 건 제게는 꿈을 이룬 일이기도 했어요.
은식
저는 Simplicity23의 랜딩페이지를 구현했었는데요. 당시에 예서님과 비슷하게 “언젠가 한 번은 Simplicity같은 프로젝트를 만들고 싶다”라고 생각했었는데, 많은 분들의 도움으로 해낼 수 있었던 것 같아 뿌듯해요.

때로는 스펙을 포기하고 싶었지만, 포기하지 않은 덕분에 특별하고 새로운 형태의 컨퍼런스를 만들 수 있었어요. 동료 개발자들이 “오늘도 개발자가 안 된다고 말했다”는 농담을 “오늘도 개발자가 된다고 말했다”로 바꿔 유쾌하게 인정해줬을 때는 정말 뿌듯했어요. 힘든 과정을 버텨낸 저희 스스로에게도 작은 박수를 쳐주고 싶습니다.




안녕하세요, Simplicity 4 프로젝트에서 프론트엔드 개발을 맡은 Frontend UX Engineer 박은식, 이예서입니다. 이번 프로젝트를 진행할 때 기술적으로 고민했던 내용들을 공유하고자 해요.

재사용 가능한 컨퍼런스 만들기
이번 Simplicity 프로젝트는 다음 시즌에도 재사용 가능하도록 구조화하는데 초점

토스 디자인 컨퍼런스 Simplicity 사이트를 개발하며 고민한 내용을 공유합니다.

뒤에 개발자 있어요 | Simplicity 4 제작기 #2


빠르게 쌓이는 PR, 느리게 달리는 리뷰. 결국 남는 건 LGTM(Looks Good To Me)뿐이라면?
이번 모닥불에서는 토스 프론트엔드 챕터가 어떻게 코드 리뷰 문화를 활성화했는지 알려드릴게요.
‘고맥락자 코드 리뷰’ 부터 ‘코드스멜 워킹그룹’, ‘가독성 위원회’ 그리고 ‘코드 리뷰 배틀’ 까지
실전에 적용해 볼 수 있는 다양한 코드 리뷰 꿀팁들, 지금 바로 공개합니다!

타임스탬프
00:00 인트로
01:40 코드 리뷰, 왜 필요한가요?
02:22 저맥락자 vs 고맥락자 리뷰
08:56 코드 스멜 워킹그룹 그리고 가독성 위원회
11:20 좋은 코드의 4가지 기준!
14:29 코드 리뷰 배틀 Ssul

출연진
박서진, 토스 Head of Frontend
진유림, 토스 Frontend Developer
전환오, 토스 Frontend Developer

Frontend Fundamentals
; 변경하기 쉬운 프론트엔드 코드를 위한 지침서
👉바로가기: https://frontend-fundamentals.com

다른 모닥불 회차 보러가기
EP.10 캠프파이어 특집 상편 | 무엇이든 물어보세요 (feat. 프론트엔드 코드, 디렉토리 관리)
EP.10 캠프파이어 특집 하편 | 무엇이든 물어보세요 (feat. 테스트 코드, ESLint Rule)
EP.11 토스의 디자인 편집기 ‘데우스’, 이렇게 만들었어요!




빠르게 쌓이는 PR, 느리게 달리는 리뷰. 결국 남는 건 LGTM(Looks Good To Me)뿐이라면?
이번 모닥불에서는 토스 프론트엔드 챕터가 어떻게 코드 리뷰 문화를 활성화했는지 알려드릴게요.
‘고맥락자 코드 리뷰’ 부터 ‘코드스멜 워킹그룹’, ‘가독성 위원회’ 그리고 ‘코드 리뷰 배틀’ 까지
실전에 적용해 볼 

이번 모닥불에서는 토스 프론트엔드 챕터가 어떻게 코드 리뷰 문화를 활성화했는지 알려드릴게요.

‘고맥락자 코드 리뷰’ 부터 ‘코드스멜 워킹그룹’, ‘가독성 위원회’ 그리고 ‘코드 리뷰 배틀’ 까지실전에 적용해 볼 수 있는 다양한 코드 리뷰 꿀팁들, 지금 바로 공개합니다!

아티클 시리즈