개발일기

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

1차 런칭 이후 피드백 반영   1차 런칭 후 받은 주요 피드백은 모바일 환경을 고려해야 한다는 점이었습니다.서비스의 주요 진입점이 카카오톡이었기 때문에 대부분의 사용자가 모바일로 접속하는 상황이었습니다. 특히, 메신저를 통해 주변 사람들에게 서비스를 홍보하는 경우가 많아 사용자들이 처음 마주하는 랜딩 페이지가 모바일 환경에 최적화될 필요가 있다는 의견이 있었습니다. 이러한 피드백을 반영해 반응형 디자인 적용을 결정했습니다.   저는 랜딩 페이지의 소개 이미지를 코드로 변환하고 반응형 작업을 맡았습니다. 또한, 헤더를 반응형으로 수정해 모바일과 데스크탑 환경 모두에서 최적의 사용자 경험을 제공하고자 했습니다. 반응형 랜딩 페이지 구현기존에는 UT 피드백에 따라 랜딩 페이지를 소개 이미지로 대체했지만 화질..

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

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

본 글은 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를 적용! 새롭게 변할 데이터가 없을 것이라 판단하여 최..

개선 전후 성능 측정 결과   요청 크기 줄이기 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로 배포하..

본 글은 2024.11.15에 마지막으로 수정되었습니다.  4차 스프린트에서의 페어 프로그래밍으로 해시태그 및 필터링 구현을 담당했습니다. Devel Up에서 제공하는 미션의 종류와 풀이의 개수가 많아지면서, 원하는 컨텐츠를 분류하여 볼 수 있으면 좋겠다는 사용자 피드백을 받았습니다. 팀원들과 필터링 기능의 도입 여부에 대해 논의한 끝에, 1. 빠르게 구현 가능하고 2. 도입 시 큰 효과를 볼 수 있다는 판단이 들어 해당 기능을 구현하기로 결정했습니다.  가장 먼저 페어였던 아톰과 함께 할 일과 일정을 산정했습니다. 페어와 함께 해야 할 일로는 다음과 같았습니다.1. 전체 해시 태그 조회2. 미션에 해시 태그 추가3. 솔루션에 해시 태그 추가4. 미션 필터링 검색5. 솔루션 필터링 검색 이렇게 다섯 가지..

프론트엔드 에러 추적 프론트엔드에서 에러를 추적하는 것은 사용자 경험을 보장하고, 프로덕트의 안정성을 높일 수 있다. QA 단계에서 다양한 시나리오로 테스트를 한다고 해도, 모든 예외 상황을 100% 커버할 수 없다. 사용자가 서비스를 이용하며 에러를 겪게 되면 서비스 동작에 불편함을 느끼고 신뢰도가 떨어져 결국 사용자 이탈로 이어질 수 있다. 따라서 실시간으로 에러를 모니터링하고 빠르게 대응할 수 있는 시스템을 갖추는 것이 중요하다. 에러 추적 도구 중 하나인 Sentry는 에러가 발생한 경로와 에러 발생 시점의 디바이스, 브라우저, 유저가 사용하는 OS 등의 정보까지 함께 제공한다. 심지어 사용자의 화면까지 녹화하여 상황을 그대로 재현할 수 있도록 도와준다. 이를 통해 문제의 원인을 파악하는 데까지 ..