6.20 ~ 21 팀 워크샵이 있어 놀고 왔다. 군필 5명이라 숙소 도착하자마자 탁구 토너먼트, 족구 토너먼트, 노래방, 와인 5병 테이스팅을 몇 시간만에 끝내고 각자 쉬었다. ㅋㅋ
1. toss slash 달리는 토스 앱에 React Native 엔진 더하기
영상: https://toss.im/slash-23/session-detail/A1-4
회사 동료분이 공유해주신 내용을 보고 깨달은 바가 많았다. 회사 팀원들과 우리도 결국은 next로 가야하지 않을까? ssr을 해야하지 않을까? 항상 생각했던 것 같다. 이유는 UX 적인 이유로 첫 페이지로드를 최대한 빠르게 하고 싶은데 가장 큰 효과를 볼 수 있는게 ssr이라고 생각했기 때문이다.
하지만 영상을 보고 방향을 다시 재고해볼 필요가 있다는걸 알게 되었던 것 같다. next는 정말 리소스도 많이 들고 큰 변화이다. 이러한 변화를 충분히 검증하지 않고 진행했을 때 시간만 낭비될 수 있기 때문이다. toss에서는 이미 next를 사용하고 있다고 알고 있었는데 next를 운영했을 때 단점들이 많아서 rn으로 갈아탄 것 같았다.
next는 배포도 느리고 k8s와 docker를 사용해서 배포하고 fe 개발자가 k8s, s3, cloudfront, ecr, cks등의 cloud service와 argoCD, grafana등의 모니터링 툴도 관리해야한다. 그리고 이벤트 등이 있을 때는 미리 pod를 늘려두는 작업도 필요하다. 과연 이렇게 노력, 돈, 리소스를 투자할 정도로 가치있는 일일까? 더군다나 비용 감축을 하고 있어서 cloud service를 마음대로 사용할 수 없는 상황에서 말이다.
윗 영상을 통해 next가 아닌 다른 방향도 많이 고려해야함을 알게 되었던 것 같다. rn도 그 방법이고 next보다 좋은 방법일 수 있다는 것도.
우리도 차근차근 문제를 해결해나가야 한다. 그 방향은
- 사용자 경험
- 개발자 경험
두 가지 모두를 개선시킬 수 있는 방향으로 말이다. 필터링없이 내가 고민한 것들을 적어보자면 다음과 같다.
- 프로젝트 통합을 했을때 account, money, payment도 번들된 js를 분리해서 따로 배포하는 프로세스를 만들면 좋을 것 같아요. 하나의 프로젝트이지만 따로 번들링되고 따로 배포가 이루어지도록. 하나의 배포가 다른 곳에 영향을 주지 않도록
- esbuild를 조작하여 js를 shared js, 각 service별 js로 만들고 배포할 수 있도록 해보면 좋지 않을까?
- 1차적으로 저희 웹 성능을 측정해볼 필요가 있을 것 같네요. core-webvital 만 우선 측정해봐도..
- 이야기가 나왔듯이 두가지 모두 챙기면 좋을 것 같아요. 저희는 둘 모두 소홀히 하지 않았나 생각이드네요ㅠ
- 사용자 경험
- 개발자 경험
- ci, cd 속도도 더 줄일 수 있을지 고민해봐도 좋을 것 같아요. 지금 보면 compressed-size ci는 특수한 상황일 때 체크하도록 하면될 것 같아요. 지금은 제거하고 (payment, payment-card에 적용되어 있음)
- core-webvital 중 FCP, FID 시간을 측정하고 50% 이상 개선을 올해 목표로 삼아봐도 재미있을 것 같아요
- asset load 시간을 줄일것인가? 실행된 이후 첫 contents 가 보이기 까지의 시간을 줄일것인가?
- 어떻게 불필요한 api 요청을 줄이고 account-webclient 를 띄우고 토큰을 받아오는 과정을 간략하게 할 수 있을까?
- 각 서비스들의 공통 로직들을 따로 js로 만들어 서비스간 이동할 때는 공통 js를 로드하지 않도록하여 js asset download 시간을 줄일수도 있지 않을까.
- 어떻게 불필요한 api 요청을 줄이고 account-webclient 를 띄우고 토큰을 받아오는 과정을 간략하게 할 수 있을까? pc에서는 기존과 같이 account-webclient로 redirect하여 토큰을 받아오도록 하되 웹뷰에서는 각 서비스가 직접 토큰을 받아올 수 있도록 하면 좋지 않을까? (현 native처럼)
- ci 시간이 4분~5분 걸리는데 github-action 사용하지 않고 m1 머신사용하여 1분 이내로 줄이면 좋지 않을까? (e2e의 경우 action이 수행될 때 browser driver를 다운받기에 시간이 너무 많이 걸림. binary 파일이라 github-action caching도 안됨.. )
- 하지만 자체 ci 머신을 사용하면 node install, browser driver download등을 하지않음, 컴퓨팅 성능도 훨씬 좋음.
- next가 운영상에 어려움이 많고 토큰관련해서도 해결해야할 문제들이 많으니 JAM Stack을 이용하여 서버관리를 최소화 하자. 토큰없이 그릴 수 있는 것들을 최대한 그려서 index.html이 비어있지 않도록 해보자.
그냥 생각나는대로 아이디어를 적은거라서 토론과 정리가 필요하다. 하지만 이걸 시작으로 우리의 프로젝트&서비스가 조금은 더 유저에게 좋은 경험을 줄 수 있지 않을까 희망을 가져본다. 한 번에 큰 변화는 힘드니 조금씩 개선해 나가보자. 1년만 지나도 매우 큰 변화가 있을 것이다.
2. 소프트웨어 공학 공부뿐 아니라 툴, 방법들의 공부도 필요하다.
소프트웨어 공학을 공부하는 주된 이유는 뭘까? 유지보수를 쉽게하기 위함이다. 이때의 유지보수는 오늘의 기능을 구현하며 내일의 요구사항을 쉽게 적용할 수 있는 것을 이야기한다. + 기능을 개발했을 때 사이드 이팩트가 없도록
사실 윗 방법이 지금까지 젤 중요하다고 생각했던 것 같다. 주변 software 책들을 보면 다 그런 책들이다. 클린코드, 클린코더, 테스트주도개발, 단위테스트, 오브젝트 등등... 그런데 이번에 성능을 좋게 만드는 툴이나 방법들을 공부하는것도 매우 중요하다는 것을 알게 되었던 것 같다. 소프트웨어 개발 공부는 큰 프로젝트에서 가장 큰 힘을 발휘한다. 하지만 성능을 좋게하는 툴이나 방법들은 언제나 큰 힘을 발휘하며 그 영향은 개발자 뿐 아니라 사용자들에게도 큰 영향을 끼치게 된다. 첫 페이지 로드가 5초에서 1초가 걸리고 ci, cd 시간이 50% 단축된다. 어느것이 더 좋기에 여기에 시간을 더 투자해라. 라고 말하기에는 둘 다 너무 중요하다. 이번에 소프트웨어 개발 공부뿐 아니라 성능을 위한 툴, 방법들을 공부하는것도 매우 중요하다는걸 깨달아서 관련 공부도 게을리 하지 않아야겠다고 다짐해썯ㄴ