m2ndy 개발 블로그

모던 리액트 Deep Dive를 학습하고 정리한 글입니다. 5.1 상태 관리가 필요한 이유상태 : 어떠한 의미를 지닌 값. 어플리케이션의 시나리오에 따라 지속적으로 변경될 수 있는 값.상태로 분류될 수 있는 것들UI : 다크/라이트 모드, 라디오, input 등URL : 브라우저에서 관리되고 있는 상태 값form : 로딩 중인지, 제출되었는지, 접근이 불가능한지, 값이 유효한지 모두 상태로 관리됨서버에서 가져온 값 : 대표적으로 API 요청상태 관리의 역사Flux 패턴의 등장MVC 패턴은 모델과 뷰가 많아지면 복잡도 증가이렇게 MVC 패턴을 적용한 어플리케이션이 비대해지고 상태도 많아짐에 따라 상태를 추적하기 어려워 짐페이스북은 이 문제를 양방향 데이터 바인딩을 원인으로 봄컨트롤러에서 모델로는 단방향이지..

번들 사이즈가 웹 사이트에 미치는 영향웹 사이트가 복잡해지면서 번들 사이즈도 함께 증가하는 경향이 있습니다. 특히 사용자 경험을 강화하기 위해 다양한 기능과 복잡한 인터페이스를 추가하면서 자바스크립트, CSS, 이미지 등의 리소스 크기가 커지는 문제가 발생합니다. 이로 인해 초기 로딩 시간이 길어지고, 이는 사용자 경험과 웹 사이트 성능에 부정적인 영향을 미칩니다.KissMetrics 연구 결과에 따르면 페이지 로드 시간이 1초씩 길어질 때마다 웹 페이지 이탈률이 7%씩 증가한다고 합니다. 전자상거래 사이트의 경우, 이는 매출 감소로 이어질 수 있습니다. 사용자는 로딩 시간이 길어지면 페이지를 떠날 가능성이 높아지고, 특히 구매 과정에서 지연이 발생하면 구매를 포기할 확률이 증가합니다. 실제로 대형 전자..

QA, UT 피드백 반영  3차례의 QA와 5회의 유저 테스트(UT)를 진행하며, 자잘한 버그를 해결하고 테스트 유저로부터 피드백을 수집했습니다.  테스트 과정 중 "글 수정 기능이 있으면 좋겠다"는 피드백을 받아 수정 기능을 구현하기로 결정했습니다. 하지만 새로운 풀이 작성 페이지와 풀이 수정 페이지를 같은 MissionSubmitPage로 재사용하고자 했기에, 이를 어떻게 설계할지에 대해 고민이 들었습니다. 그래서 일단 흐름도를 그려보기로 했습니다. 글 작성 페이지를 (1) 새로운 글을 작성하기 위해 방문하는 경우와, (2) 수정하기 위해 방문하는 경우를 나누기 위해 url에 solutionId 파라미터를 추가했습니다. 페이지 로드 시 파라미터를 확인하여, 데이터가 존재하면 서버에서 기존 데이터를 가..

끝이 나지 않을 것만 같았던 레벨 3, 4가 끝이 났다..! 어느새 우테코도 마지막을 바라보고 있다..😭    드디어 대망의 데모데이 .. !우리 팀은 오전 부스로 배치되었다. 깔끔하고 단정한 컨셉에 맞춰 부스를 꾸미고 부스 방문 손님(?)들을 맞이했다. 예전에 서비스직 알바했던 톤이 저절로 나왔던 게 신기했다 ㅋㅋㅋㅋㅋㅋ저희 서비스 사용해 보신 적 있으신가요~? 아 없으시다구요~? 그럼 앉아서 사용해 보고 가세요~!    크루들에게 서비스를 소개하면서 우리 서비스를 직접 사용할 수 있게 홍보했다. 웹으로도, 모바일로도 사용이 가능한 점을 어필했고, 프리코스를 웹으로 즐길 수 있음을 강조했다. 우테코 크루가 아닌 외부인들도 많이 오셔서 서비스를 사용하고 가셨다. 4개월 동안 열심히 만든 서비스를 잘 사..

본 글은 2024.11.13에 마지막으로 수정되었습니다.  Devel Up 서비스에는 '위로 가기 버튼'이 있습니다. 아래 사진과 같은 버튼인데요, 글이 길어지는 경우 사용자 경험을 향상시키기 위해 스크롤을 최상단으로 끌어올릴 수 있게 해주는 버튼입니다.      이 버튼은 페이지 스크롤에 상관 없이 항상 position: fixed로 화면에 고정되어 있었습니다. 하지만 스크롤이 최상단에 있는 경우에도 버튼이 존재하는 것이 어색하다는 사용자 피드백이 있었습니다. 따라서 이 버튼을 스크롤이 특정 지점 아래에 있을 때만 보이도록 구현하기로 했습니다.  여기서 든 의문점이 있었습니다. 1. 사용자의 스크롤 위치를 항상 구하고 있어야 되는가?2. 스크롤 위치를 항상 구하고 있어야 한다면, 이벤트의 콜백 함수를 ..

본 글은 2024.11.05에 마지막으로 수정되었습니다.    CSR와 SSR CSR와 SSR은 웹 어플리케이션을 렌더링 하는 대표적인 방법들이다. 본 글에서는 CSR와 SSR의 동작 원리와 이를 비교하며 장단점을 작성하려 한다.   CSR ( Client Side Rendering) CSR은 브라우저에서 거의 모든 작업이 이루어지는 렌더링 방식이다. React의 경우 기본 HTML에 컴포넌트를 갈아 끼우는 SPA로 동작하기 때문에, 서버로부터 처음 받아오는 html 파일은 아주 간단한 HTML 상태다.             이 기본 HTML 파일에는 태그만 있을 뿐, 서버에서 받아오는 데이터는 없는 상태다.브라우저는 HTML 파싱을 통해 파일을 위에서부터 순차적으로 읽어나가다     React    ..

본 글은 2024.11.06에 마지막으로 수정되었습니다.  1편과 이어집니다.  웹 사이트의 성능을 높여보자 (1) (요청 크기 줄이기, 필요한 것만 요청하기)개선 전후 성능 측정 결과   요청 크기 줄이기 1. 소스 코드 줄이기  Home 페이지에서 불러오는 스크립트 번들 크기가 951KB였다. 웹 페이지의 권장 번들 사이즈는 250KB 미만으로, 번들 사이즈의cho-sim-developer.tistory.com    같은 건 매번 새로 요청하지 않기 1. CDN 설정 1-1. CDN 캐시 설정 npm run build를 통해 생성된 정적 파일을 S3에 업로드 한 뒤 CDN을 통해 접근 가능하도록 했다.CDN의 캐시는 CachingOptimized를 적용! 새롭게 변할 데이터가 없을 것이라 판단하여 최..

성능 개선 중 S3와 CDN에 배포를 진행하며 캐시를 설정했다. CDN과 S3의 데이터에 새롭게 변할 데이터가 거의 없을 것이라 판단하여 모두 캐싱 기간을 1년으로 설정해 두었다. 여기서 궁금한 점이 생겼는데, S3에도 캐시 기간 설정을 할 수 있고 CDN에서도 캐시 설정을 할 수 있다. 그렇다면 각 캐싱이 어디에 적용되는지 헷갈렸다😵‍💫 정리하자면, 1. S3의 max-age : 브라우저가 캐시를 저장하는 시간이때, CDN의 최소 TTL < max-age < 최대 TTL인 경우 : CDN의 캐싱 시간은 max-agemax-age < 최소 TTL인 경우 : CDN의 캐싱 시간은 최소 TTL최대 TTL < max-age인 경우 : CDN의 캐싱 시간은 최대 TTL2. S3의 s-maxage : CDN이 캐..

개선 전후 성능 측정 결과   요청 크기 줄이기 1. 소스 코드 줄이기  Home 페이지에서 불러오는 스크립트 번들 크기가 951KB였다. 웹 페이지의 권장 번들 사이즈는 250KB 미만으로, 번들 사이즈의 용량 개선이 필요했다.  1-1. minify & uglify // webpack.config.js optimization: { minimize: true, }  Webpack v5부터는 production mode로 배포 시 기본적으로 압축과 난독화가 진행된다. TerserWebpackPlugin이 내장되어 있기 때문에, 자동으로 최적화가 이루어진다. minify & uglify 이전minify & uglify 이후압축률951KB216KB약 77%   그렇다면 development로 배포하..

4차 스프린트에서는 프로젝트의 목표였던 "개발 환경 개선"에 집중할 수 있었습니다. 저희 팀의 프론트엔드 인원이 다른 팀에 비해 한 명이 적다 보니 개발 환경의 효율화와 생산성 향상이 꼭 필요했습니다. 그래서 프로젝트를 하면서 제가 어떤 부분에 기여할 수 있을지 고민하다, 개발 환경을 개선시켜 생산성을 높여보자는 목표를 정했습니다.  1. 자동 배포 (CD) 개발 환경을 개선하기 위한 방법 중 첫 번째로는 자동 배포(CD)에 도전했습니다. 프론트엔드의 CI는 이미 구축되어 있었지만, CD는 구축되지 않은 상태였습니다. 그래서 배포 환경에서 테스트를 하려면 pem 키를 가진 크루에게 부탁해서, 우분투에 접속한 후 수동으로 배포를 해야 했습니다. 환경 변수가 추가되거나 변경 사항이 생길 때에도 우분투 CLI..