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

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

힘든 환경에도 다들 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 Korea

웹뷰의 화면 전환을 이벤트 기반으로 모델링하여 히스토리 상태를 관리하고 복잡한 의존성 없이 핵심 로직을 독립적으로 설계할 수 있습니다.

복잡한 라이프사이클을 일관된 이벤트 후크로 정의하고 플러그인 인터페이스를 제공함으로써 외부 의존성을 최소화하고 확장성을 극대화할 수 있습니다.

사용자가 직접 플러그인을 개발하고 공유하는 생태계를 구축하면 플랫폼의 리소스 한계를 극복하고 앱의 성능을 지속적으로 향상시키는 향상성을 확보할 수 있습니다.

화면 전환 유저 경험 개선과 초기 설계의 한계

웹뷰 환경은 기본적으로 페이지가 끊어지는 전환 방식을 가지지만, 모바일 앱 환경에 맞게 이전 화면이 슬쩍 보이는 **애니메이션 전환 효과를 구현**하여 유저에게 적절한 맥락을 전달하고자 했습니다.

초기에는 히스토리 API의 상태를 관리하기 위해 리액트 상태와 동기화하는 방식을 택했으나, 이는 **의존성이 강하게 침투된 구조**를 만들어 테스트가 어렵고 버그 대응이 힘든 결과를 낳았습니다.

특히 히스토리 API와 리액트 내부 상태를 동기화하는 과정에서 새로고침, 뒤로 가기 등 브라우저 환경의 복잡한 시나리오를 대응하지 못해 **프로덕션 환경의 신뢰도 저하**와 새로운 프레임워크 도입에 대한 제약이 발생하는 문제가 있었습니다.

본질에 집중한 이벤트 기반 재설계

리팩토링 과정에서 팀원들과 고민한 결과, 프레임워크의 본질은 URL이나 전환 효과 그 자체가 아닌 **애니메이션이 존재하는 스택(Stack)**이라는 점을 깨달았습니다. 이를 통해 외부 프레임워크 의존성을 제거한 핵심 코어 모델을 설계할 수 있었습니다.

핵심 로직은 **이벤트 소싱 패턴에서 영감을 얻은 이벤트 기반 설계**를 채택했습니다. 유저의 행동(이벤트)을 수집하고, 이를 로직(Aggregate)에 통과시켜 최종 상태(State)를 계산하는 방식을 통해 복잡한 상태 관리를 단순화했습니다.

핵심 로직이 외부 의존성 없이 이벤트 목록을 통해 상태를 계산하는 함수로 분리됨에 따라, **유닛 테스트가 매우 용이해졌으며** 특정 버그 발생 시 이벤트 스냅샷을 통한 재현과 수정이 훨씬 간편해졌습니다.

확장 가능한 플러그인 생태계 구축

프레임워크의 확장성을 높이기 위해 **이펙트(Effect) 개념을 도입**했습니다. 상태 변화 전후에 특정 콜백을 호출하는 라이프사이클 훅을 설계함으로써, 라이브러리의 핵심 기능을 보존하면서도 유저가 원하는 기능을 안전하게 추가할 수 있는 구조를 마련했습니다.

개별적인 훅 노출로 인한 학습 비용 증가 문제를 해결하기 위해 **플러그인 인터페이스를 도입**했습니다. 유저들은 구체적인 옵션을 알지 못해도 플러그인 조합을 통해 필요한 확장 기능을 구현할 수 있게 되었습니다.

생태계 확장은 플랫폼의 성공을 위한 **향상성(내 코드 수정 없이 플랫폼 기능이 향상되는 경험)**을 확보하는 데 필수적입니다. 유저들이 직접 플러그인을 개발하고 기여함에 따라 커뮤니티가 형성되었고, 이는 리소스가 부족한 팀에게 강력한 운영 전략이 되었습니다.

애플리케이션 개발과 기술 라이브러리 개발은 본질적으로 같습니다. 고객이 겪는 문제를 공감하고, 그 고통 속에서 **더 나은 인터페이스와 API를 끊임없이 고민**하는 과정이 개발자들의 삶과 우리가 사는 세상을 더 나아지게 만듭니다.

당근의 스택 플로우 프레임워크 소개 및 강연 목표

당근에서 2년 동안 스택 플로우 프레임워크를 개발한 아이디어와 운영 교훈 공유

라이브러리 개발 전반, 현실 아이디어 모델링, 더 나은 협업, 전사적 기술 임팩트에 대한 영감 제공

스택 플로우 문서는 GitHub에서 미리 확인 가능하며, 코드 실습과 함께 들으면 더욱 이해도를 높일 수 있음

발표자 소개: 당근에서 개발자와 디자이너의 업무 효율 증진을 돕고 있으며, 자바스크립트 기반의 풀스택 개발 진행

화면 전환을 활용한 유저 경험 개선 초기 시도

모바일 웹뷰에서 웹의 딱딱 끊어지는 전환 효과가 유저에게 부자연스럽고 맥락 전달이 어렵다고 판단

클릭 후 다음 화면 이동, 뒤로 가기 시 이전 화면이 슬쩍 보이는 애니메이션을 통해 자연스러운 웹뷰 화면 목표

초기 구현 시 웹 내장 히스토리 API 확장을 고려했으나, 이전 화면 상태를 가져올 수 없는 문제점 발견

히스토리 API를 감싸 리액트 내부 상태와 동기화하여 이전 화면 상태에 접근, 화면 전환 애니메이션 구현

초기 라이브러리(프레임)의 문제점 분석

프레임 라이브러리가 히스토리 API 및 React Router DOM에 의존하여 개발됨

의존성이 깊어 테스트하기 어렵고, 버그 발생 시 대응이 힘들었음

히스토리 API와 React 내부 상태 동기화가 어려워 버그 발생률이 높았고, 개발 환경에서의 새로고침 문제 발생

React 환경에 종속되어 Svelte, Solid 등 다른 프레임워크 대응이 불가능

React Router DOM에 의존하여 동작 정의가 모호, 새로운 요구사항에 대한 확장성 부족

프레임워크 리팩토링 결정 및 본질 탐색

기존 문제점을 파악했으나 백지 상태에서 시작하려니 막막함과 몇 달간의 허송세월 경험

2022년 4월 18일, 팀원들과 2.0 구조 논의 중 본질에 대한 이야기를 통해 표현하고자 하는 것들이 구체화됨

전환 효과나 내비게이션 URL이 아닌, '애니메이션이 존재하는 스택'이 본질임을 깨달음

본질을 찾은 후 어떤 것에도 의존하지 않고 무엇을 만들어야 하는지 명확하게 인지

스택 구현을 위해 이벤트 기반 설계 선택 (액션, 메시지, 트랜지션 등으로 불리며 Redux 등과 유사)

백엔드 개발의 이벤트 소싱 패턴에서 영감을 받아 코어 모델을 이벤트 기반으로 설계

이벤트 기반 설계: 유저 행동 데이터(이벤트)를 발행하면 로직이 현재 상태를 계산하는 방식

상태는 로직에 여러 행동(이벤트)을 넣은 결과값이며, 이를 `state`, `aggregate`, `event`로 명명

코드로 구현 시 `aggregate` 함수 하나로 이벤트 목록을 받아 상태를 반환하는 간결한 구조

스택 구현을 위한 이벤트 정의 및 작동 방식

스택 초기화를 위한 `init`, 화면 추가를 위한 `push`, 화면 제거를 위한 `pop` 이벤트 정의

유저가 이벤트를 발행하면 `aggregate` 함수가 스택 상태를 계산하여 반환 (push 시 화면 증가, pop 시 화면 감소)

코어 로직 테스트 용이성 및 React 통합

이벤트 목록과 기대하는 결과 상태를 선언하여 간단하고 쉽게 유닛 테스트 가능 (외부 의존성 없음)

TDD 페어 프로그래밍 경험을 통해 테스트의 중요성을 깨닫고, 코드 기반의 소통이 신선했음을 언급

완성된 코어 로직을 `CoreStore` 객체로 감싸 `dispatch`, `getState`, `subscribe` 인터페이스 노출

React 18의 `useSyncExternalStore` API를 통해 React 내부 상태와 동기화

React 위에서 스택 상태가 JSON으로 적절하게 계산되는 모습을 보고 뿌듯함을 느낌

이벤트 기반 설계 후 버그 수정 워크플로우 개선

이전에는 버그 시나리오 재현에 시간이 소요되고 정보 부족으로 소통 비용 및 수정 시간이 증가

이벤트 기반 리팩토링 후, 유저가 전체 이벤트 목록과 현재 상태를 JSON으로 전달하여 버그 재현 및 수정 용이

제보받은 JSON 값을 테스트 코드에 추가하여 실패하는 테스트를 만들고 수정하는 과정

실제 유저 버그 제보를 통해 테스트 케이스에 추가된 하드코딩된 값들의 존재 설명

확장성 있는 인터페이스 설계: 이펙트 개념 도입

확장성의 정의: 어떤 일이 일어났을 때 유저가 스스로 원하는 작업을 수행할 수 있게 만드는 것 (콜백 함수와 유사)

확장성의 핵심은 유저가 라이브러리를 자유롭게 활용할 수 있도록 '미리 재료를 준비'하는 것

불필요한 콜백 노출은 '성급한 추상화'로 이어져 일관성 없는 인터페이스와 레거시 발생 위험

이벤트 기반 설계에서는 '이펙트' 개념을 추가하여 아름답고 일관된 해결 가능

이벤트를 계산하는 단계에 이펙트를 추가하여 이벤트 발생 전후 콜백 호출, 이벤트와 1:1 구조로 일관성 유지

콜백 함수 등록 인터페이스를 통해 유저가 모듈의 라이프사이클을 자연스럽게 학습 유도

Init, Push, Pop 이벤트가 콜백으로 노출되어 설계와 외부 인터페이스의 일관성을 확보

플러그인 인터페이스를 통한 확장성 및 사용성 개선

많은 옵션은 유저의 학습 비용을 높이고 모듈을 복잡하게 느끼게 할 수 있음

GraphQL의 플러그인 방식을 참고하여 확장성은 유지하면서 유저가 더 쉽게 느끼도록 개선 아이디어 얻음

유저가 구체적인 옵션을 모르더라도 플러그인을 통해 쉽게 확장 기능들을 묶어서 사용 가능

기존 옵션을 없애고 어레이 옵션을 넘기는 방식으로 변경, 여러 옵션이 묶인 객체들이 플러그인 인터페이스 됨

플러그인 인터페이스를 통해 메인 모듈 업데이트 없이 다양한 기능 제공 가능

예시: 히스토리 API 동기화 기능을 라이프사이클 훅과 히스토리 API 팝 스테이트 훅을 엮어 플러그인으로 구현

예시: 이벤트와 상태 변화를 크롬 익스텐션을 통해 실시간으로 볼 수 있는 기능도 플러그인으로 쉽게 구현

리팩토링 및 플러그인 인터페이스 제공의 성과

의존성 없는 코어 로직 분리로 쉬운 테스트 가능

이벤트 스냅샷을 통한 이슈 제보 및 디버깅 용이

코어 로직 분리로 React 외 다른 생태계 통합 용이

라이프사이클 훅과 플러그인 인터페이스로 쉬운 확장 가능

플러그인 생태계 구축을 통한 기술 임팩트

기존 요청 방식에서 벗어나 유저들이 직접 플러그인 인터페이스를 통해 기능을 개발하는 모습 관찰

기여 진입 장벽이 낮아지면서 핵심 유저들이 생기고, 이들이 플러그인 및 지식 공유를 통해 생태계 확장

커뮤니티 빌딩 모델인 '오르빗 모델'을 예시로 설명 (핵심 유저, 주변 유저, 커뮤니티 확장)

당근 내부에서 플러그인 창조, 참고 및 재창조가 활발히 일어나 각 팀마다 플러그인 축적

생태계의 중요성: 플랫폼 성공에 필요한 '향상성' 확보

향상성: 코드 수정 없이 앱이 자동으로 향상되는 경험 (OS 업데이트 시 앱 성능 개선 등)

향상성은 플랫폼의 미래에 대한 신뢰도를 높여 더 많은 기여를 유도

플러그인 생태계가 성장하면 플랫폼 전반적으로 앱이 향상되는 향상성 증폭 기반 마련

리소스가 부족한 라이브러리 팀에게 플러그인 생태계는 향상성 확보의 유효한 전략

스택 플로우 개발 핵심 문제, 모델링, 로직 테스트, 인터페이스 설계, 확장성, 생태계까지 총체적 설명

1. 이벤트 기반 설계, 2. 의존성 없는 깨끗한 코어 지식 및 장점, 3. 라이프사이클 일관된 정의 및 노출, 4. 플러그인 인터페이스 제작 방법

5. 핵심 유저 기여 환경 조성 (생태계), 6. 플랫폼 개발 및 평가에서의 향상성 중요성

기술 개발과 서비스 개발의 공통점

애플리케이션 개발자와 기술 개발자가 고객 문제 공감, 프로덕트 다듬기 등 동일한 노력을 함

서비스팀과 기술팀 모두 일해본 결과, 둘은 전혀 다르지 않음을 깨달음

개발자도 매일 치열하게 회의하며 고객(다른 개발자)의 문제에 공감하고 API를 다듬는 고민을 함

우리 모두 문제에 깊이 고민하고 더 나은 인터페이스를 위해 도전하며 세상을 나아지게 함

당근 프론트엔드 코어팀 채용 안내

당근의 프론트엔드 플랫폼 개발 및 운영, 프론트엔드 개발자들이 행복하게 일할 방법 고민

매일 배우고 성장하는 팀 분위기, 오픈소스 친화적 (Terarrecio's Fetch, Icon Nara 등 공개)

현재 프론트엔드 전용 SPA 배포 플랫폼 기획 및 개발 중, 도전적인 과제 수행

발표 내용 공감 시 당근닷컴 채용 공고 확인 및 지원 요청

프론트엔드 코어팀 외 중고거래, 광고 서비스, 로케이션 코어팀 공고도 열려있음

발표 마감 및 핵심 고객인 당근 프론트엔드 개발자들에게 감사 인사