제가 저번에는 저쪽 그 지금 트레이죠. 거기서 발표했었는데 여기는 처음 서 보네요.

되게 장소가 협소해서 계단에도 다 앉아계시고. 아, 굉장히 감사합니다.

힘든 환경에도 다들 FE Conf 재밌게 좀 즐기고 계신가요?

재밌게 즐기고 계시면 오늘이 자리 준비하시느라 고생 많이 박수 한번 주시죠.

네. 어, 그동안 좀 코로나 때문에 저희가 이렇게 만나서 좀 이야기할 수 있는 기회가 좀 없었는데 어 저도 이제 처음으로 이렇게 오프라인으로 모여서 이렇게 얼굴을 뵐 수 있어서 너무너무 뜻깊고 좋습니다.

사실 오늘 제가 좀 일찍 나와가지고 여러분들이랑 이야기도 나누고 어 좀 이렇게 하고 싶었는데 도저히 토요일 아침에 늦잠을 포기할 수가 없어서 지각을 해버렸습니다.

제가 좀 게으른 저녁형 인간이라서 아침잠을 포기할 수가 없는데 다들 엄청난 경쟁률의 티켓팅을 뚫고 이제 여기까지 아침 일찍 나오시고 열정이 너무 대단하신 거 같습니다.

그 열정으로 제 발표 집중력 있게 들어 주실 거라고 믿고요. 저도 최대한 좀 재밌게 전달해 드리도록 노력해 보겠습니다.

알고 계신 분들도 많겠지만 저희 당근에서 이제 스택 플로우라는 프레임워크를 주로 사용을 하고 있어요. 오늘 저는 지난 한 2년 동안 스택 플로우라는 프레임워크를 어떤 아이디어로 만들었는지, 그리고 운영하면서 좀 배웠던 교훈들을 이 자리에서 좀 공유해 보려고 합니다.

오늘 이야기에서는요, 다섯 가지 토픽을 이야기하게 될 텐데요.

라이브러리 개발의 끝부터 끝까지 살짝 맛보실 수 있는 좋은 시간이 될 거 같고요.

꼭 라이브러리 개발이 아니더라도 더 예쁘게 현실 세계 아이디어를 모델링하고 싶으시다던지, 아니면 인터페이스를 통해서 더 나은 협업을 목표로 하신다던지, 아니면 생태계를 통해서 뭔 전사 단위의 기술 임팩트 꿈꾸고 계신 분들한테 큰 영감이 될 수 있었으면 좋겠습니다.

어, 아시다시피 플로는 문서랑 이제 GitHub 링크로 미리 둘러 보실 수 있고요.

어, 코드를 둘러 보시거나 실제로 좀 yarn add 해서 사용해 보시면서 제 발표를 들으시면 좀 더 이야기가 입체적으로 들으실 수 있지 않을까 하는 생각이 듭니다.

어, 간단하게 제 소개를 드리면 저는 당근에서 개발자와 디자이너분들이 좀 더 행복하게 일할 수 있도록 돕는 역할을 하고 있고요.

어, 현재는 조금 얕지만 넓게 자바스크립트 기반의 풀스택 개발을 하고 있습니다.

어, 그러면은 첫 번째 이야기로 넘어가도록 하겠습니다.

첫 번째 얘기는 화면 전환을 활용해서 유저 경험 개선하기입니다.

어, 제가 회사에 합류하고 이제 당근에서 모바일 그 웹뷰를 좀 적극적으로 사용하게 됐는데요.

어, 아시다시피 그 웹에서는 좀 특별한 전환 효과가 없고 요렇게 이제 딱딱 끊어지는 경험을 줄 수밖에 없었어요.

요런 경험은 이제 유저한테 적절한 맥락을 만들기가 좀 어렵고 모바일 앱 내에서 다른 화면들과 다르게 좀 위화감을 줄 수 있다고 생각했어요.

어, 제가 바라던 전환 요건은 요런 모습이었는데요. 이게 조금 더 자연스럽죠.

어, 이렇게 클릭한 이후에 다음 화면으로 이동하거나 뒤로 가기를 했을 때 이전 화면이 슬쩍 보이는 애니메이션을 만들면 유저에게 좀 더 적절한 맥락을 전달하고 좀 더 자연스러운 웹뷰 화면이 될 수 있을 거라고 생각을 했습니다.

어, 이것을 구현하고자 마음먹었을 때 저는 처음에 이제 웹에 내장되어 있는 히스토리 API를 확장해야 된다고 생각했는데요.

어, 다들 아시겠지만 히스토리 API 푸시 스테이트가 호출될 때마다 이런 식으로 페이지가 쌓여 가게 되고요.

근데 저희가 원하는 동작, 특히 이제 뒤로 가기를 할 때 이전 페이지가 보이는 효과를 만들기 위해서는 현재 시점에 대한 상태값뿐 아니라 이전 화면에 대한 상태값이 꼭 필요했습니다.

하지만 히스토리 API는 이전 화면에 대한 스테이트를 가져올 수 없는 문제가 있습니다.

이 문제를 해결하기 위해서 처음에 굉장히 무식하게 접근했는데 바로 히스토리 API를 한번 감싸는 방식으로 이렇게 푸시 스테이트가 호출될 때 리액트 내부 상태를 함께 유지하는 겁니다.

그리고 다음과 같이 화면에 대한 정보가 히스토리 API에 표시될 때마다 내부 상태값에 어레이를 하나 만들어서 함께 저장하게 했는데요.

이런 방식으로 이전 화면에 대한 상태값에 접근할 수 있게 만들어서 일단은 화면 전환 애니메이션은 어떻게든 구현할 수 있었습니다.

이렇게 프레임이라는 첫 번째 라이브러리를 좀 출시하게 됐고요.

앞서 설명드렸다시피 히스토리 API, 특히 이제 리액트 라우터 돔이라는 라이브러리에 의존하게 개발이 되어서 지금 여기 문서에 보이실지는 모르겠는데 맨 하단에 리액트 라우터에 의존한다고 귀엽게 적혀 있습니다.

어 좀 이렇게 빠르게 구현된 캐러 프레임은 굉장히 많은 문제들을 가지고 있었어요.

어 첫 번째로는 좀 테스트하기가 어려웠습니다.

이게 제가 좀 부족해서도 있지만 의존성이 깊게 침투되어 있어서 테스트 짜기도 어렵고 그래서 테스트가 없었고요.

라이브러리 특성상 이게 웹뷰 뿌리를 담당하고 있는데 버그나 기능 제한이 들어왔을 때 테스트가 없어서 빨리 대응하기가 매우 힘들었습니다.

어 두 번째로 뭐 마찬가지지만 히스토리 API, 리액트 내부 상태를 동기화하는 게 매우 어렵고 버그가 나기 쉬운 코드가 되어 버렸습니다.

어 개발 환경에서 보통 우리가 고치고 나서 새로 고침을 굉장히 자주 하시잖아요.

근데 개발자분들 저희가 신뢰 가능한 환경을 제공하기 위해서 이제 새로 고침하고 앞으로 가기, 뒤로 가기 이런 걸 했을 때에 대한 대응이 필요했는데 이 부분에서 버그가 계속 발생해서 이제 프로덕션 환경에 대한 신뢰도의 이슈가 있을 수밖에 없었습니다.

세 번째로 리액트 환경 자체에 종속되다 보니까 새로운 프레임워크에 대응하기가 힘들었습니다.

제가 회사 내에서 예를 들면 누가 스벨트 한번 써 볼까, 솔리드를 한번 써 볼까 이런 얘기가 나오면 저는 땀을 흘리면서 '아, 그걸 지원하지 못하는데' 이러면서 불안해했죠.

네 번째로는 이제 새로운 요구 사항에 대해서 확장하기가 좀 어려웠습니다.

이제 동작 자체가 리액트 라우터 돔에 의존을 하다 보니까 동작에 대한 정의가 좀 굉장히 모호할 수밖에 없었는데요.

예를 들면 페이지가 추가되었을 때 무언가를 실행하고 싶어요.

그러면은 리액트 라우터 돔에 호출하고 나서 이 콜백 함수를 호출해야 되는지 아니면 실제 렌더링 될 때 유즈 이펙트에서 호출해야 되는지 이런 게 명확한 룰이 좀 없었습니다.

그래서 저도 마찬가지고 저희 팀원들도 이제 슬랙 맨션이 막 울리는데 가슴이 먹먹해지면서 이 문제를 지금 빨리 해결해야겠다 이런 생각을 갖게 되었습니다.

어 그래서 좀 리팩토링을 하겠다고 마음을 먹었어요.

그러면 지난 날에 제가 이제 작성했던 코드들은 다 잊고 아주 깔끔한 상태로 처음부터 다시 시작하려고 했어요.

어 근데 기존 프레임워크의 문제는 이제 다 알겠는데 이게 백지에서 시작하려니까 무엇을 좀 어떻게 그려 나가야 될지 막막하더라고요.

그렇게 좀 처음에 이 문제 인식이 드러났을 때부터 실제 구현까지 몇 달간 좀 허송세월 하기도 했습니다.

어 그러다가 여기 보시면 2022년 4월 18일이 이제 킥오프 차원에서 팀원들이랑 2.0 구조 논의를 하게 됐어요.

이때 저희 동료였던 어시가 본질에 대한 이야기를 꺼냈고 팀원들이랑 이야기를 나누면서 저희가 표현하고자 하는 것들이 굉장히 구체화되었습니다.

어 간단하게 요약하면 전환 효과나 내비게이션 URL 이런 것들은 저희가 처음에 핵심이라고 생각했었는데 실제로는 저희가 표현하고자 하는 본질이 아니었고요.

실제로 저희가 표현하고자 하는 것은 애니메이션이 존재하는 스택이라는 걸 깨닫게 되었습니다.

어 본질을 찾고 나니까 기존과 다르게 아무것도 의존하지 않을 수 있게 되었고 이제 어떤 것을 만들어야 되는지 명확하게 알 수 있었습니다.

어 그러면 이제 스택을 만들어야 되는데요. 이때 여러 가지 방법이 있겠지만 저는 이벤트 기반으로 설계를 하기로 했습니다.

뭐 액션, 메시지, 트랜지션 뭐 여러 이름으로 불리기도 하고 아마 여러분들한테 유즈 리나 리덕스 같은 걸로 익숙하실 거라고 생각하는데요.

이때 제가 이제 백엔드 개발에 이벤트 소싱 패턴을 연습하던 때여서 이에 영감을 받아서 저희 코어 모델은 이벤트 기반으로 설계하게 되었습니다.

어 조금 구체적으로 아이디어를 소개해드리려고 하는데요.

이벤트 기반 설계는 간단히 말해서 어 유저가 행동 데이터를 발행하면 해당 데이터가 로직에 들어가서 현재 상태를 계산하는 방식이라고 이해하시면 좋습니다.

만약에 유저가 행동을 더 수행하면 행동 여러 개가 로직을 통하게 되고 계산된 상태가 요런 식으로 바뀌게 됩니다.

이 모습을 살짝 틀어 보면요. 결국에 상태는 로직의 행동 여러 개를 넣은 결과값이다는 것을 알 수 있고요.

상태는 스테이트, 로직은 행동 여러 개를 모은다는 의미에서 게이트라는 이름으로 바꿨고요.

행동은 이벤트라는 이름으로 바꿀 수 있습니다.

그럼 이제 요거를 코드로 바꿔서 써 보면 이런 코드가 나오게 됩니다.

참고로 뒤에 이제 시간값을 넘기는 부분이 있는데 이거는 애니메이션 상태가 현재 시간의 영향을 받다 보니까 추가 인자로 넘겨 주게 됩니다.

그러면은 결국 우리는 이제 이 함수 딱 하나만 구현하면 되거든요.

보시다시피 이벤트 목록을 인자로 받아서 이벤트를 포문을 막 돌아서 적절하게 만들고 결과 상태를 반환하는 함수입니다.

그럼 문제로 다시 돌아와서 우리가 표현하고자 하는 스택을 구현하기 위해서 어떤 이벤트가 필요할까요?

처음에 스택이 초기화될 때 필요한 init 이벤트가 하나 있으면 좋을 것 같고, 화면이 덮어지는 건 push 이벤트, 화면이 사라지는 건 pop 이벤트로 표현하면 좋을 것 같습니다.

아까와 같이 한번 표현해 볼게요. 유저가 다음과 같이 이벤트를 발행하면 해당 이벤트가 `aggregate`라는 함수로 들어가게 되고 결과로 우리가 표현하고자 하는 스택을 반환하게 됩니다.

push 이벤트가 하나 추가되면 `aggregate` 함수의 결과값으로 화면이 두 개 들어 있는 상태가 반환될 거고요.

하나 더 추가되면 화면이 세 개, 여기서 pop 이벤트가 추가되면 맨 위 화면이 없어지도록 `aggregate` 함수를 구현하면 됩니다.

그러면은 저희가 짠 코어 모델을 어떻게 테스트하면 좋을까요?

굉장히 심플한데요. 다음과 같은 코드를 짜면 됩니다. 보시다시피 이벤트 목록을 이렇게 선언을 하고요.

이 이벤트 목록을 어그리게이트라는 함수에 넣고 기대하는 결과 상태를 선언하면 됩니다.

이게 외부 의존성이 하나도 없어서 굉장히 간단하고 쉽게 유닛 테스트로 저희의 핵심 로직을 테스트할 수 있습니다.

이 갑자기 뜬금없는데요. 사진은 저희 팀이 작년 5월에 이제 제주도로 워케이션 가서 카페에서 찍은 사진인데요.

이 카페에서 저희 동료인 어랑 처음으로 TDD 페어 프로그래밍을 했었는데 저한테는 개인적으로 굉장히 놀랍고 즐거운 시간이었습니다.

이 당시만 해도 저는 테스트랑 좀 거리가 먼 사람이었는데 서로 생각하는 구체적인 로직에 대해서 코드로 이야기하고 소통할 수 있어서 굉장히 신선했습니다.

어 그다음 이어서요. 이렇게 완성한 코어 로직을 이제 리액트 통합을 해야 될 텐데 요때 또 짜릿한데 코어 스토어라는 객체로 저희 로직을 한번 감싸고 어 디스패치는 이름으로 이벤트를 추가하는 함수를 하나 만들고 내부에서 어그리게이트 함수가 작동에 상태를 계산하도록 했고요.

현재 상태를 반환하는 `getState` 함수랑 상태가 변경될 때마다 콜백을 호출해주는 `subscribe` 인터페이스를 노출했고, React 18에 있는 `useSyncExternalStore`라는 API를 통해서 React 내부 상태와 동기화할 수 있었습니다.

요거는 그 당시에 처음에 이제 React 통합하고 테스트할 때 썼던 코드인데요.

실제로 React 위에서 스택 상태가 이렇게 JSON으로 적절하게 계산되는 모습을 보니까 너무 뿌듯했습니다.

아마 지금 코드 보고 계신 분 계시면 히스토리 위쪽으로 가시면요.

데모를 직접 돌려 보실 수도 있습니다.

하지만 세상이 그렇게 녹록하지 않겠죠. 당연히 설계를 잘해도 현실 세계에서 버그는 발생할 수밖에 없습니다.

근데 이제 이벤트 기반 설계로 전환한 이후에는 이제 버그를 수정하는 워크플로우 자체가 굉장히 심플해졌습니다.

버그가 들어왔을 때 이제 해당 버그 시나리오를 대화를 통해서 전달받고 이를 제 로컬에서 재현하는 데 시간을 좀 썼었어요.

이 단서가 유저가 이해하고 있는 구조에 의존할 수밖에 없는데요. 그러다 보니 정보가 충분하지 않아 제어하기가 쉽지 않았고 결론적으로 의사 소통 비용이 증가하고 실제 버그 수정까지 시간이 더 소요되고 했습니다.

하지만 이벤트 기반으로 리팩토링한 이후에는 상황이 그나마 좀 좋아졌는데요.

이제 유저는 전체 이벤트 목록과 현재 상태를 저희에게 JSON으로 전달할 수 있게 됐고, 저희는 해당 이벤트를 머릿속으로 막 굴려보고, 그다음에 주신 이제 JSON 값을 기대하는 결과가 맞는지 체크를 했고요.

해당 기대값을 저희 테스트 코드에 추가해 실패하는 테스트를 만든 뒤에 가볍게 수정할 수 있게 되었습니다.

지금 코드 보고 계신 분 있으면 코어 코드 안에 .

spt 파일이 있는데요. 거기 다른 테스트랑 다르게 막 실제 값들이 하드코딩된 것들이 있는데, 그게 저희가 유저로부터 버그 제보를 받아서 테스트 케이스에 추가한 내용입니다.

이제 코어 기능 구현이 어느 정도 끝나서 유저가 스스로 확장할 수 있는 인터페이스를 만들어 보려고 합니다.

FEConf 2023 [A4] 이벤트 기반 웹뷰 프레임워크 설계와 플러그인 생태계 만들기

프론트엔드 개발의 소중한 경험을 공유합니다! 
프론트엔드 개발자에 의한! 프론트엔드 개발자를 위한!

프론트엔드를 개발하며 마주했던
치열한 고민과 깊은 인사이트를 공유하며
여러분과 함께 성장하고 싶습니다!


FEConf 2023 [A4] 이벤트 기반 웹뷰 프레임워크 설계와 플러그인 생태계 만들기

Scripts