FE 개발일지

저번 글에서는 CI / CD 구축을 위한 기본적인 개념과 큰 틀에 대해서 설명했다면 이번 글에서는 git action과 aws에서 설정해줘야 하는 작업들에 대해서 설명을 해볼까 한다. CI / CD를 구축하면서 느낀점은 내가 해오던 프론트 개발과 정말 다른 세계라는 생각을 많이 했던 것 같다. 심지어 딥하게 들어간 것도 아니고 간단하게 맛만 본 것 같은데도 이런 느낌이 들어 새삼 인프라 구성을 하시는 DevOps 포지션이나 백엔드 분들에게 존경심이 느껴졌다. 그러면 이제 CI / CD 구축을 위한 Step을 밟아보자! 1. S3 버킷 만들기 버킷 이름을 설정해주고 AWS 리전을 설정한다. 여기서 객체 소유권 설정을 해주지 않아 "File upload failed : AccessControlListNotS..

이번에 새로운 프로젝트에 투입되면서 초기 단계에서 개발을 진행중이다. 아직 CI CD 구축이 되어 있지 않았는데 항상 백엔드 팀에서 해주셨는데 이번에는 내가 맡게 되었다. 같이 일하시던 백엔드 팀원분이 이직을 하게되었는데, 인수인계 및 잔여 업무들이 많은 것 같아 CI / CD 작업을 가져왔다. 해보고 싶었던 작업이기도 했고 여러모로 좋은 경험이 될 것 같아서 흔쾌히 진행하게 되었다. 현재 프로젝트는 리액트로 진행하고 있고 Git Action과 AWS를 이용해서 CI / CD를 구축할 계획으로 서치를 했다. 위 과정을 간략하게 설명해보자면 코드를 Push 하면 Git Action이 실행되어 CI (빌드) 작업을 수행 빌드 작업을 통해 zip 파일과 사전에 작성한 배포 스크립트 파일을 압축해 AWS S3에..

# 내용추가 WebView vs In-App-Browser vs Embedded Browser의 차이점을 좀 찾아봤습니다! 내용을 요약해 정리하면, WebView 앱 내의 웹 페이지를 표시하는 데 사용하는 기능 (기본적으로 앱 내에 번들로 제공되는 웹 브라우저의 축소판) 일반적으로 앱에 내장되어 앱 외부에서 액세스할 수 없음 기능이 제한적일 수 있음 (동일한 기능을 지원하지 않거나 특정 유형의 웹 콘텐츠를 렌더링하는데 어려움을 겪을 수 있음) In-AppBrowser 사용자를 별도의 웹 브라우저 앱으로 리다이렉트 하지 않고 앱 자체 내에서 웹 페이지를 열 수 있도록 해주는 기능 앱 내에서 액세스 할 수 있는 기능이며, 일반적으로 장치의 기본 웹 브라우저를 기반으로 함 사용자의 기본 웹 브라우저와 동일한..

7월달에 어드민 개선하기 글을 쓰고나서 이제야 어드민 프로젝트 재구축을 완료하였습니다. 중간에 다른 업무와 병행하느라 예상했던 것보다 좀 더 걸렸네요. 많은 문제가 있던 어드민을 완료하고 이제 QA 진행에 들어갔습니다. 기존에 제기 되었던 문제(Recompiling 시간, 타입추론, 버그 양산 코드 제거, API 문제 등)들은 당연히 다 해결되었습니다. 항상 어드민 작업을 맡게 되면 그리 규모가 크지도 않은 프로젝트의 Recompiling 시간 때문에 한숨을 쉬었던 기억이 많았는데 되게 뿌듯하면서도 문제가 생기지 않을까 염려되기도 하네요. 오늘은 어드민 프로젝트를 다시 작업하면서 느꼈던 많은 부분들 중 제 스스로의 피드백과 함께 회고글을 작성해볼까 합니다. - 사용기술 React, React-router..

글을 쓰기에 앞서 어떤 문제가 있다고 해서 무조건적으로 프로젝트를 재구축하거나, 리팩터링을 거쳐서 개선하자는 위험할 수 있다고 생각합니다. 개발자 이외의 사람들이 보기에는 문제없이 잘 진행되어 있는 프로젝트일 수 있고 재구축을 진행하면서 어떤 변수가 일어날지 알 수 없기 때문에 정말 많이 고민하고 신중해야 할 것 같습니다. 1년 전 어드민의 대한 문제가 제기되어 다른 사람 주도하에 어드민이 재구축 되었고 현재 재구축된 프로젝트에 대해 다시 문제가 제기되고 있는 상황입니다. 주도 했던 분의 개발 방식이 저희(현재 프론트 동료분과 저)와 맞지 않았고, 더 이상 이 프로젝트에 관여를 하지 않기 때문에 앞으로 어드민을 개발해 나가야 하는 저희의 개선 의견을 대표님께서 받아들여주셨던 것 같습니다. 문제점 파악하기..

다들 프론트엔드에서의 OOP(객체지향 프로그래밍) 어떻게 생각하시나요? https://www.youtube.com/watch?v=1V6mQom0paI&ab_channel=%EA%B0%9C%EB%B0%9C%EB%B0%94%EB%8B%A5 관련해서 개발바닥 유튜브 영상도 정말 재밌게 봤던 것 같습니다. 클래스에 대한 고민은 제가 타입스크립트를 도입하면서 같은 Url Prefix를 사용하는 Api들을 어떻게 묶어볼 수 없을까?부터 시작되었는데요. 레퍼런스가 많이 없기도 하고 실제로 FE에서는 FP가 더 중심적이고 OOP에 대해서 많은 고민과 고찰이 없었던 것도 사실인 것 같습니다. 굳이 필요한가?란 생각도 있구요. 그래서 더더욱 클래스를 도출하기까지 시간이 좀 걸린 것 같기도 합니다. 당연히 클래스만 쓴다고 ..

저번 포스트에서 웹뷰 및 인앱 브라우저 환경을 고려한 프로세스로 작업을 다시 하기로 했었는데요. 결론은 해결하려고 하는 방식으로 잘 해결하였고, 배포까지 마무리 되었습니다. 그러나 많은 곳은 아니지만 몇군데 참조를 해보니 인앱환경에서 안되는 곳도 많았습니다. 꼭 SNS 뿐만 아니라 팝업 형식이면 본인인증 프로세스도 되지 않더라고요. 순간적으로 인앱 환경까지 고려해야 할까?란 생각도 들었지만 SNS는 대중적으로 많이 사용되고 있고, 사용자의 편의성을 조금이나마 개선하기 위해서라면 하는게 맞다란 결론을 내렸습니다. (서비스 중점적 개발 개선) 물론 인앱 환경을 위한 프로세스로 작업을 하면서 겪었던 문제들을 보면 방향성에 대한 의구심이 들긴 합니다. 이래서 고려를 안했나?란 생각도 들었고요.. (각 회사의 정..

1. 확장자명 js, ts, tsx 파일 파일 확장자명 js에서는 뭐가 js고 jsx인지 모릅니다. 그러나 ts 파일 내에서는 ts와 리액트 컴포넌트들을 구분해서 처리를 하기 때문에 react에 관련 import 즉 tsx를 알 수 없습니다. 정리해보면 .ts - 순수 Typescript 파일에 사용 .tsx - JSX를 포함하는 파일에 사용 (리액트 구성요소) 간혹 모든 파일 확장자명이 tsx로 되어있는 것을 보면 아 이래서 그랬구나라고 깨달았던 것 같습니다. 저희는 로직만 담은건 ts로 처리하고 React 구성요소가 포함되어 있으면 tsx로 처리하기로 했습니다. 2. Typescript의 타입 자동추론은 정말 강력하다. 타입스크립트와 vscode 둘 다 마이크로소프트에서 만들었기 때문에 에디터간의 자..

TS 마이그레이션 이전에.. 이전에 디자인 패턴의 대한 고민과 redux-saga에서 react-query로 리팩터링의 대한 글을 올렸었는데요. 이 모든 리팩터링 과정은 타입스크립트 마이그레이션 전에 적용되어야 할 우선순위였습니다. 최종적으로 목표는 타입스크립트 마이그레이션이였고, 원할한 TS 마이그레이션을 위해 디자인 패턴을 바꾸어 필요없는 파일은 줄이 redux-saga로 관리되던 비동기 코드들은 react-query로 전환하여 원하는 기능들을 더 편리하게 사용하게끔 만들었습니다. 이렇게 타입스크립트를 위한 빌드업은 끝났고, 타입스크립트 마이그레이션을 하게 되었는데 결코 쉽지 않았습니다. 백엔드분들이 IDC에서 NCP로 이전을 해야되는 상황이였기 때문에 api작업은 원할하게 진행될 수 없던 상황이였고..

지난 포스트에 이어 react-query를 사용하며 얻은 유용한? 점 들에 대해 정리해보려고 합니다. react-query는 정말 다양한 기능들을 제공해주고 제어할 수 있게 해줍니다. 저는 제가 직접 사용했던 범위내에서 헷갈리거나 유용했던 것들을 정리해보겠습니다. 잠깐 npm trends를 보면 react-query의 인기가 실감나지 않나요? 많은 개발자분들이 react-query를 사용중인 것 같습니다. #1 useQuery isLoading VS isFetching useQuery의 isLoading과 isFetching 이 둘이 순간 헷갈렸던 적이 있는데요. isLoading과 isFetching을 가장 간단하게 설명하면 isLoading은 처음 로드할 때, 아직 데이터가 없을 때 isFetchin..