개발일기

EC2와 Nginx를 사용한 첫 번째 버전의 배포 과정은 여기서 확인하실 수 있습니다. Devel Up 프로젝트의 브랜치 전략Devel Up 프로젝트에서는 dev 브랜치와 main 브랜치를 활용해 각각 개발 서버와 운영 서버의 파이프라인을 독립적으로 구축하고 배포하는 것을 목표로 했습니다.   처음에는 GitHub Actions를 사용하려 했지만, 제공받은 AWS 계정의 S3 정책 설정 상 access key 발급이 불가능했습니다. 이에 따라 AWS CodePipeline과 CodeBuild를 사용해 파이프라인을 구축하기로 결정했습니다.   AWS를 선택한 이유와 장단점 AWS는 GUI를 통해 파이프라인을 간편하게 설정하고 실행할 수 있는 장점이 있습니다. 디버깅 과정에서도 CloudWatch를 활용하면..

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

Devel-Up 프로젝트에서 프론트 팀원들과 힘을 합쳐 프론트엔드 S3 배포를 하기로 했다.개인적으로 공부한 뒤, 이번주 내로 배포하여 이미 구축된 CI/CD까지 연결하는 것이 목표! 잠시 프로젝트 소개를 하자면.. 개발자 취준생 상호 성장을 위한 플랫폼을 개발하고 있다.취준생들이 느끼는 불안감을 문제 상황으로 인식했고, 이 불안감을 해소할 수 있는 방법이 무엇이 있을까 고민하다 첫 번째 방법으로 코드 리뷰 서비스를 제공하기로 했다.2주 스프린트 단위로 나누어 아주 작은 기능부터 만들면서 8주 간 규모를 키워가려고 한다!  왜 S3를 사용하여 배포하지?프론트에서 Amazon S3를 통해 배포한 이유는, React 같이 SPA 프로젝트의 경우 서버가 필요 없고, 정적 웹 사이트 호스팅이 가능하여 간단하게 ..

✅ Webpack 이란?Javascript로 만든 어플리케이션을 위한 정적 모듈 번들러. 즉, 웹 어플리케이션을 구성하는 css, javascript, image 등의 웹 자원을 각각의 모듈로 간주한 뒤, 이들의 의존성 관계를 결합하여 하나의 결과물을 만들어주는 도구이다. Webpack은 프로젝트에서 필요한 모든 모듈을 매핑하고, 하나 또는 여러 개의 번들 파일로 결합하여 의존성 그래프를 생성한다. 이를 통해 웹 어플리케이션의 성능을 최적화하고, 모듈화를 통해 코드의 유지보수성을 높일 수 있다. 또한, 어플리케이션의 로드 시간을 줄이며, 사용하지 않는 코드를 제거하는 tree shaking을 통해 최종 번들 크기를 줄일 수 있다. webpack.config.js 파일을 통해 설정을 할 수 있으며, 진입점..

먼저, Javascript와 Typescript의 가장 큰 차이점은 Typescript에는 Type을 지정한다는 것입니다. Javascript에서는 a + b 코드를 작성할 때, const a = 1; const b = 1; const c = a + b; // 2 위와 같이 작성하지만 Typescript의 경우 타입을 지정하게 됩니다. const a :number = 1; const b :number = 1; const c :number = a + b; // 2 Type의 경우 number string boolean 등이 있으며, const와 let 등으로 선언하는 변수 이외에도 props로 전달받는 인자까지 타입을 지정하게 됩니다. const a :number = 1; const name :string..