염딩코

회사 프로젝트 중 랭킹 페이지를 개편하다 문제를 만났습니다. 순위표는 채널에 따라 수백 명, 많게는 약 1,000명가량의 행을 한 번에 그립니다. 화면에는 십수 개만 보이지만, 브라우저는 스크롤을 시작하기도 전에 보이지 않는 행까지 전부의 위치, 크기와 픽셀을 계산합니다. 첫 렌더에서 이미 비용을 다 치르는 셈입니다. 가장 먼저 떠오른 답은 무한 스크롤이었습니다. 약 1,000행을 한 번에 내려주지 말고 필요한 만큼만 잘라서 받는 방식이죠. 그런데 두 가지가 걸렸습니다. 하나는, 무한 스크롤은 데이터를 나눠 받는 기법이지 그리는 비용을 직접 줄이는 기법이 아니라는 점입니다. 스크롤해서 행이 쌓이면 결국 다시 전부 그리게 되니까요. 다른 하나는 현실적인 문제로, 이 방식은 백엔드에 페이지네이션 API가 필..

얼마전에 진행하던 사이드 프로젝트에서 React 19로 버전을 업그레이드를 하고, React 19로 업그레이드를 하는 김에 React Compiler를 도입해보았습니다. React Compiler를 도입하는 과정 자체는 어렵지 않았습니다.그러나, React Compiler를 왜 만들게 되었고 내부적으로 어떤 방식으로 동작하는지 아무런 이해없이 넘어갈 수는 없었습니다. React 팀은 왜 React Compiler를 도입하게 되었고, 이것이 어떤 방식으로 동작하는지 살펴보고 이해하기 위한 글을 작성해봅니다. 최적화를 자동으로 해준다고 하지만, 어떤 tradeoff가 있는지도 알아봅시다. React Compiler의 목적React compiler의 목적은 React 공식문서에서 찾을 수 있었습니다."R..

현대의 웹 개발 생태계는 단편적인 기술의 집합이 아니라, 제한된 네트워크 대역폭, 서버의 컴퓨팅 자원, 그리고 클라이언트(브라우저)의 처리 능력 사이에서 최적의 균형점을 찾기 위해 끊임없이 패러다임을 전환해 온 결과물이다. 1990년대의 정적인 문서 교환 시스템에서 출발한 웹은 오늘날 데스크톱 네이티브 애플리케이션을 능가하는 수준의 고도화된 상호작용과 성능을 요구하는 거대한 플랫폼으로 진화했다. 이러한 폭발적인 요구사항의 변화는 아키텍처의 근본적인 혁신을 강제했다. 서버 사이드 렌더링(SSR), 싱글 페이지 애플리케이션(SPA), 모던 하이브리드 렌더링(Next.js), 그리고 점진적 하이드레이션(Hydration)과 재개성(Resumability)이라는 기술적 도약은 특정 프레임워크의 유행이 아니라, ..

새 타입을 하나 추가했을 뿐인데, 컴파일러가 "여기도 고쳐야 하지 않냐"라고 먼저 알려줬다. 문제: 컴파일러는 빠뜨린 케이스를 알려주지 않는다.union type을 switch로 분기하는 코드는 흔하다.문제는 union에 멤버가 추가됐을 때, 타입스크립트가 처리 안 한 케이스에 대해 침묵한다는 것이다.type Shape = Circle | Square;function getArea(shape: Shape) { switch (shape.kind) { case 'circle': return Math.PI * shape.radius 2; case 'square': return shape.sideLength 2; } } 여기에 Triangle을 추가해도 ge..

토스에서 진행하는 frontend fundamental 모의고사 1회 차와 2회 차를 모두 참여하였다. 참여했던 이유는 단 하나다. 다른 프론트엔드 개발자들은 어떤 코드를 지향하는 것인지, 어떤 방향성을 갖고 코드를 작성하는지 궁금했다.무엇이든지 배울 점들이 있을 것 같아서 신청을 했고, 운이 좋게 2회 모두 참여할 수 있었다. 1회 차 모의고사1회 차 모의고사 때 주어진 과제는 실제로 이전에 풀어보았던 과제가 출제되었다. 과제의 난이도는 어렵지 않았지만, 토스에서 보고자 했던 것은 확장성 있는 코드와 유지보수가 쉬운 코드인지 보는 것이었다. 확장성 있는 코드와 유지보수가 쉬운 코드는 내 나름대로 정의를 가지고 풀어 나아갔다. 그럼에도 많은 궁금증과 고민이 있었고, 이것들을 품은 채, 라이브 해설강의를 ..

브라우저의 메인 스레드는 언제나 바쁘다현대 웹 애플리케이션, 특히 복잡한 UI와 수많은 서드파티 스크립트(GTM, Ads, Maps 등)를 품은 페이지에서 메인 스레드 블로킹은 필연적입니다. 메인 스레드가 막히면 TBT(Total Blocking Time)가 치솟고, 사용자의 첫 입력 지연(FID)이 악화됩니다. 초기 렌더링에 당장 필요 없는 작업들을 어떻게 영리하게 뒤로 미룰 것인가?그 해답으로 적용했던 requestIdleCallback에 대해서 정리하고자 합니다. requestIdleCallback은 어떻게 동작하는가?우리가 매일 사용하는 웹 브라우저는 겉보기에 단순해 보이지만, 사용자에게 끊김 없는 화면을 보여주기 위해 1초에 60번(60Hz 기준) 엄청난 속도로 화면을 다시 그립니다. 이 한 ..

지난번 포스트를 작성하고, 꽤 시간이 흘렀다. 이번 시즌에는 내가 잘못 알고 있던 점들과 새롭게 배운 사실들, 그리고 개선 포인트들을 기록해보려고 한다. https://yeomyeom.tistory.com/148 First Load JS 축소 및 번들 최적화 - 시즌 1회사 프로젝트의 개선 항목 중에서 입사를 하고 나서부터 오늘날까지 간곡히 해결하고 싶었던 문제가 있었다. 바로 홈 화면에서의 First Load JS를 줄이는 것이었다. 입사 당시, 회사 서비스의 속도yeomyeom.tistory.com(지난 시즌의 글은 위에서 확인할 수 있다.) 지난 글의 마지막을 보면, 더 이상 개선을 할 수 있을지 의문이 든다고 하면서 마무리를 했었다.하지만, 이번 개선 작업을 마무리하고 난 후에 지난 시즌의 결과..

회사 프로젝트의 개선 항목 중에서 입사를 하고 나서부터 오늘날까지 간곡히 해결하고 싶었던 문제가 있었다. 바로 홈 화면에서의 First Load JS를 줄이는 것이었다. 입사 당시, 회사 서비스의 속도는 매우 느렸다. 성능이 좋은 맥북 프로 m2로도 조금 답답한 느낌이 들 정도였다. 이렇게 생각해도 될지 모르겠지만, 회사 프로젝트가 "황금 고블린"같은 느낌이 들었다.경험치를 올린 사냥터가 아주 많은 프로젝트라고 생각했기 때문이었다. 느리다는 것도 렌더링이 느리거나, 로딩이 길거나, 반응속도가 느린 것과 같이 다양한 부분에서 측정이 가능했고, 회사의 서비스도 다양한 측면에서 느리다고 말할 수 있었다. 서비스에 가장 먼저 접근하게 되는 홈 화면의 First Load JS는 올해 1월 경만 해도 76..

잘 하는 개발자란 무엇일까. 내가 되고 싶은 미래의 나의 모습은 어떠한가. 커피챗이나 동료 개발자들과의 대화를 하면서 그들이 살아온 삶, 그들의 경험들을 들으면서 많은 도움을 받을 수 있었다.미래에 대한 방향성을 잡을 수 있었고, 그 방향대로 나는 묵묵히 앞으로 나가면 된다는 결론에 도달했다. 앞으로 나아가던 중, 운이 좋게 당근에 서류를 합격하게 되었다. 앞으로만 가던 나에게 뒤를 돌아보게 해주었던 당근의 인터뷰 덕분에 회고를 작성하게 되었다. 예전부터 당근에는 인턴부터해서 몇차례 서류를 넣었었는데, 한 번도 붙은 적이 없었다. 위의 메일을 받고, 부랴부랴 면접을 준비했었다. 많은 개념들을 다시 공부하고, 이력서와 포트폴리오 기반 질문들에 대비를 하고 있었다. 긴장이 되어서 밤에 잠은 잘 오지..

안녕하세요~~👋👋 여러분 잘 지내고 계신가요? 이제 슬슬 봄이 다가오고 있어요..!!! 🎉모두들 따뜻한 봄을 지내시길 바랄게요~ 문제상황저는 회사에서 경기 기록에 선수 정보를 추가/수정할 수 있는 기능을 맡게 되었어요!이미 구현된 부분이 있었고, 해당 부분에 추가적인 기능을 넣는 상황이었어요. 하지만, 왜인지 모르게 경기 기록 수정 모달이 굉장히 늦게 띄워졌어요..!!! --> 문제 상황 아래 영상을 확인해보시면 아시겠지만, 2초정도 늦게 모달이 띄워졌어요!  콘솔을 찍어보면서 원인을 찾아보기 시작했어요..! (6번이 모달, 7번이 경기로그입니다.) 문제는 모달이 열릴 때와 닫힐 때, 모든 기록들이 찍히는 것을 확인할 수 있었어요..!!!모든 기록들이 리렌더링이 되는 상황이었습니다! 결론부터 얘기하..