취준의 해라고 하기도 부끄럽지만 .. 나름의 23년도 목표였던 취업하기를 이룰 수 있었다 !

짧게라도 지난 시간들을 돌아보려고 한다 😌

1월

졸프의 마무리와 42

지난해 9월부터, 처음으로 백엔드와 함께 기획, 디자인하고 티켓 작성하며 진행해본 프로젝트였다. 주제는 와인 입문자를 위한 와인 추천 서비스

프론트 구현뿐만 아니라 크롤링해서 데이터 수집하고, 간단한 추천 알고리즘도 구현해볼 수 있었다. 아무리 생각해도 너무 부끄러운 코드지만 .. 나도 가비도 이 졸업 프로젝트를 시작으로 정말 많이 성장했고 달라졌기 때문에 🥴 절대 부끄럽지 않다 ..

그리고 만 1년을 함께 했던 42서울 .. 블랙홀에 빨려들어가지 않기 위해 열심히 exam을 보고 과제를 했다 😮

2월

오픽과 인턴 지원

나의 마지막 방학 ! 오전 시간을 허투루 보내고 싶지 않아서 오픽 학원을 다녔다.

그리고 중간중간 .. 학점연계 인턴과 다른 기업 인턴들을 지원했다. 이때 웨이브 서류 합격 후에 코테탈 하면서 코테의 부족함을 많이 느꼈던 것 같다.

ICT 학점연계 인턴은 총 3곳을 지원할 수 있었다. 프론트엔드 기술 스택에서는 가장 인기 있을 것이라 생각했던 M사에서 유일하게 서류 탈락을 했고, 가장 네임밸류가 있다고 생각했던 J사에서는 대면 면접을 볼 수 있었다. 그리고 스타트업 B사에서는 비대면 면접을 진행했다.

결과적으로 대면 면접이었던 기업은 탈락, 비대면 면접을 진행했던 스타트업에서 최종합격하여 인턴십을 진행하게 되었다.

첫 다대다 면접에서 기술 질문에 거의 답변하지 못하고 왔지만 같이 면접을 진행했던 면접자분들 모두 나보다 훨씬 뛰어난 분들이었기 때문에 큰 자괴감 느끼지 않고 아 기술면접은 이렇게 진행되는구나, 기초가 많이 부족했구나를 깨달을 수 있어서 좋은 경험이었다고 생각한다 😊

3월 - 6월

스타트업 인턴

그렇게 3월부터 6월 말까지 총 4개월 간의 인턴십을 진행했다. 기존 서비스인 파트너스 사이트 개선부터 여러 새로운 서비스 개발까지 참여해볼 수 있었다. 실제 서비스를 직접 구현하고 배포하는 과정이 정말 의미있었고, 실력을 정말 많이 성장시킬 수 있었다! 현재 회사에 입사한 지금 돌이켜 생각해보면, 학부생 수준에 진행했던 토이 프로젝트들보다는 규모가 크지만, 기업 서비스로는 상대적으로 규모가 작은 프로젝트의 코드를 이해하고 개발했던 경험이 도움이 많이 되었던 것 같다. 무엇보다 함께 일했던 나의 사수 프론트엔드 개발자분, 백엔드 개발자분, 짧았지만 가장 의지했던 UI/UX 디자이너분, 그리고 PM분까지 너무 좋은 분들이라 더더욱 좋은 기억만 남는 것 같다.

그리고 인턴십이 끝나면 또 백수 생활에 빠져서는 안된다는 강박에 .. 인턴십을 진행하면서 간간히 올라오는 활동들에 지원을 했고, 운이 좋게 7월 첫날부터 현대자동차그룹에서 진행하는 소프티어 부트캠프 2기에 참여할 수 있었다.

7월 - 8월

현대자동차 소프티어 부트캠프

부트캠프는 두 달간 진행되었고, 7월은 바닐라 자바스크립트 8월은 팀 프로젝트를 진행했다. 개발을 진행하는 중간중간 피어 세션과 스쿼드 세션을 가졌는데, 이 시간동안 다른 분들의 코드를 보고 설명을 들으면서 많이 배울 수 있어 좋았던 것 같다 👍🏻 프로젝트를 진행했던 8월 한 달간은 정말 힘들었는데, 문제를 공유하면 같이 고민해주고 해결해주는 분들이 곁에 있어서 마냥 힘들지만은 않았다! 미숙했던 나 때문에 팀 프로젝트를 진행하면서 우여곡절이 많았지만, 다같이 마무리 할 수 있었다는 것만으로도 너무 뿌듯하고 자랑스러웠다. 결과물도 .. 내 마음속엔 우리가 1등 😎

23년 한 해를 통틀어 가장 많이 성장할 수 있었던 두 달이었다 🤧

프로젝트 관련 내용은 첨부할 수 없을거 같아서 .. 마지막 회고 사진으로 대체 ~

9월

휴식과 취준

4개월 인턴과 2달의 부트캠프를 끝내고 맞은 오랜만의 백수생활 알리기 부끄러운 숫자의 서류도 지원을 했고, 동시에 오토에버 면접을 준비했다. 채용 일정이 늦어져서 걱정했는데 .. 다행히 면접은 9월 말에 치뤄졌고, 바로 이틀 후에 마음 편히 미국 여행도 다녀올 수 있었다. 면접은 나쁘지 않게 진행됐던 것 같다 ㅎㅎ 기술 질문이 대다수였는데, 면접을 준비하는 동안 글로만 공부하는 것은 지루해서 테코톡을 많이 봤더니 더 수월하게 말로 설명할 수 있었던 것 같다. 면접 일정이 빡빡하지 않다면 테코톡 추천합니다 🌟

10월

취준과 입사

10월에도 나름의 취준을 했다! 서류도 작성하고, 코테도 보고 .. 그러던 중 오토에버 합격 발표를 받고 입사를 하게 되었다 😮

메일이 오기 전에 홈페이지에 들어갔다가 알게 됐는데, 믿기지 않아서 몇 번을 다시 확인했던 것 같다 .. 😊

11월 - 12월

현재는 온보딩 및 간단한 프로젝트를 진행하면서 회사 생활에 적응중이다 !

팀원분들 모두 정말 좋은 분들이라 빠르게 적응할 수 있었고, 무엇보다 내가 원하는 기술 스택을 활용하는 팀에 들어와서 만족하면서 공부하고 있다

아쉬웠던 점

23년을 보내면서 아쉬웠던 점을 꼽아본다면, 꾸준히 기록하지 않았던 점이 아쉽다 지원 후기, 활동 후기, 기술 정리 등 꾸준히 기술 블로그를 작성했으면 가장 좋았을 것 같다. 24년도 목표는 꾸준히 기술 블로그 작성해보기로 정해야겠다 .. 🤓

좋았던 점

좋았던 점 ? 칭찬하고 싶은 점 ? 모든 순간을 칭찬해주고 싶지만 .. 그래도 꾸준히 도전하고 노력했던 점 같다 ㅎㅎ

마무리

취준을 했다고 하기엔 조금 부끄러울 정도로 짧았지만 .. 어떻게 보면 매순간 노력하고 준비하고 있었기 때문에 또 좋은 기회를 잡을 수 있던게 아닐까 싶다

단순 취업이 절대 최종 목표는 아니기 때문에 더욱더 기대가 되는 2024년을 살아야겠다 ~

2023년 ! 올 한해도 너무 수고했다 에옹 🤗

저와 2023년을 함께 했던 모든 분들, 너무 고생 많았어요! 🍀 읽어주셔서 감사합니다 ( 꾸벅 )

React Query란?

React Query는 React Application에서 서버 상태 가져오기, 캐싱, 동기화 및 업데이트 작업을 쉽게 수행할 수 있도록 도와주는 라이브러리이다.

React Query를 사용하는 이유?

이미 한 줄 요약에서 설명했듯이, react-query는 fetching, caching, 서버 데이터와의 동기화 등을 지원해주고, 무엇보다 클라이언트와 서버 데이터를 온전하게 분리 할 수 있도록 도와준다. 데이터를 가져오거나 업데이트하는 로직을 store 내부에 구현하는 경우가 많은데, 이러한 경우에 클라이언트 상태와 서버 상태가 공존하기 때문에 로직이 복잡해질 수 밖에 없다 ( 과거의 나.. 😵 ) 이러한 문제점과 더불어 비동기 데이터를 다루면서 마주했던 여러 문제점들을 react-query의 여러 기능들을 통해 편리하게 해결할 수가 있다!

( Quick Start는 공식 문서를 참고해주세요 😉 )

React Query의 기능

1. 캐싱

React-Query는 캐싱을 통해 불필요한 API 호출을 방지하여 서버에 대한 부하를 줄일 수 있다.

react-query에서 캐싱은 어떤 방식으로 진행될까? 🤔

캐싱 사이클에 대해 알아보기 전에, 먼저 react-query는 다음과 같은 기본 옵션들을 제공한다.

refetchOnMount,
refetchOnWindowFocus,
refetchOnReconnect,
refetchInterval,
staleTime,
cacheTime,

react-query는 기본적으로 캐싱된 데이터를 stale한 상태로 여긴다. stale이란 신선하지 않은, 오래된 낡은 데이터를 의미한다. 데이터가 stale하면 신선하지 않은 상태이기 때문에, 업데이트가 필요한 것이다. 따라서 react-query는 아래 옵션들을 기본적으로 제공하고, 설정에 따라 다음과 같은 시점에 해당 쿼리를 refech한다.

• 새로운 인스턴스가 마운트 될 때 (refetchOnMount)
• 브라우저에 refocus 될 때 (refetchOnWindowFocus)
• 네트워크가 reconnect 될 때 (refetchOnReconnect)
• 별도로 설정한 refetch interval이 있을 때 (refetchInterval)

refetch 옵션들과 함께 staleTime과 cacheTime 또한 설정할 수 있다. staleTime의 기본값은 0초, cacheTime의 기본값은 5분이다.

staleTime : 데이터가 fresh에서 stale한 상태로 변경되는 데 걸리는 시간

cacheTime ( react-query v5에서는 gcTime ) : 데이터가 inactive 상태일때 캐싱된 상태로 남아있는 시간

캐싱 라이프 사이클

이제 react-query의 기본 옵션들에 대해 이해했으니 캐싱 사이클에 대해 알아볼 수 있다! 😎 react-query의 캐싱 라이프 사이클은 다음과 같다.

1. 쿼리 인스턴스가 mount되고,
2. 네트워크에서 데이터를 fetch하고 해당 queryKey로 caching한다.
3. 이 데이터는 fresh 상태에서 staleTime 이후에 stale 상태로 변경된다.
4. 해당 쿼리 인스턴스는 unmount되고,
5. 캐시는 cacheTime(gcTime)만큼 유지되다가 가비지 콜렉터 (gc)로 수집된다.

이러한 과정들로 쿼리 응답 데이터가 캐시되고, cacheTime(gcTime)이 지나기 전에, 쿼리 인스턴스가 fresh한 상태라면 새로 mount되었을 때 캐시 데이터를 보여주게 되는 것이다!

2. useQuery

react-query는 가장 기본적으로 useQuery와 useMutation Hook을 제공한다.

useQuery는 서버로부터 데이터를 조회해올 때 사용되는 Hook이다 (GET)

const { data } = useQuery(
  queryKey, // 응답 데이터를 캐시할 때 사용할 Unique Key (required)
  fetchFn, // Promise를 Return 하는 함수 (required)
  options, // Option 객체 (optional)
);

• 첫 번째 파라미터로 unique Key를 포함한 배열이 들어가고,
• 두 번째 파라미터에는 비동기 함수 queryFn가 들어간다. queryFn은 Promise를 반환하는 형태여야 한다.
• 세 번째 파라미터에는 staleTime, cacheTime, refetch 옵션 등 다양한 옵션들을 설정할 수 있다.
  • enabled 옵션을 사용할 경우에는 비동기 함수인 useQuery를 동기적으로 사용할 수 있다.
  • select 옵션을 사용할 경우, 반환값에서 필요한 필드만을 선택하여 효율적으로 활용할 수 있다.

    const { data } = useQuery(
    ['queryKey', id],
    () => fetchById(id),
    { 
    enabled: !!id, // id가 존재할 때만 쿼리 요청
    select: data => data.title // 필요한 필드만을 선택
    }
    );

• 반환값의 status, isLoading, isFetching, isSuccess, isError 등 세분화된 결과값을 통해 추가적인 상태를 선언하지 않고, 간결하게 조건을 적용하여 사용할 수 있다.

3. useMutation

useMutation은 서버의 상태를 변경시킬 때 사용되는 Hook이다 (PUT, UPDATE, DELETE)

const { mutate } = useMutation(
  mutationFn, // Promise를 Return 하는 함수 (required)
  options, // Option 객체 (optional)
);

• 첫 번째 파라미터에는 Promise를 반환하는 비동기 함수가 들어가고,
• 두 번째 파라미터에는 상황 별 분기 설정이 들어간다.
• 반환값은 useQuery와 동일하다.

마무리

이번 온보딩 프로젝트에서 react-query를 처음 사용해보았는데, 기존 boiler-plate를 기반으로 api.ts에 비동기 함수를 구현하고, query.ts에 react-query를 사용한 훅을 구현한 후, 여러 옵션들을 활용해서 아주 간결하게 데이터 fetch 로직을 구현할 수 있었다. 아직까지는 기초적인 기능들 위주로 활용해본 것 같은데, 앞으로 더 다양한 프로젝트에서 react-query를 사용하면서 더 다양한 hook들과 option들을 활용해보기 위해 노력해야겠다~ 😉

참고

https://tanstack.com/query/v4/docs/react/overview https://github.com/ssi02014/react-query-tutorial https://velog.io/@kandy1002/React-Query-%ED%91%B9-%EC%B0%8D%EC%96%B4%EB%A8%B9%EA%B8%B0 https://tech.kakaopay.com/post/react-query-1/

이럴 때 편리하게 사용할 수 있는 명령어가 바로 git stash이다

Git stash

Stash는 Modified이면서 Tracked 상태인 파일과 Staging Area에 있는 파일들을 보관해두는 장소이다. 아직 끝내지 않은 수정사항을 스택에 잠시 저장했다가 나중에 다시 적용할 수 있다.

"파일 수정 중에 다른 브랜치로 이동해야하는 경우"에나, or 나와 같이 "다른 브랜치에서 작업해야하는데, 실수로 기존 브랜치에서 작업한 경우"에 stash로 저장해두고, 브랜치 이동 후에 해당 내용을 적용하면 편리하게 작업을 이어갈 수 있다 !

적용 방법

파일 내용을 수정한 상태에서 branch를 변경하려고 하면, 다음과 같은 에러 메세지를 마주하게 된다😶

error: Your local changes to the following files would be overwritten by checkout:

Please commit your changes or stash them before you switch branches.
Aborting

먼저, stash를 통해 변경사항을 저장한다. 다음과 같이 save 명령어를 사용하면 description을 포함하여 저장할 수도 있다.

$ git stash

$ git stash save "description"

나의 경우에는 gitlab에서 이슈를 생성한 이후에 브랜치를 만든 상황이었기 때문에, 브랜치를 업데이트하고 변경한 후 apply로 적용하였다!

# 원격 브랜치 업데이트
$ git remote update

# 브랜치 이동
$ git checkout [해당 브랜치]

# 가장 최근의 stash 적용
$ git stash apply

pop 명령어 같은 경우에는 apply와 drop을 동시에 실행하는 역할을 한다.

# 가장 최근의 stash 제거
$ git stash drop

# stash 전체 삭제
$ git stash clear

# stash를 적용한 이후에 바로 삭제하기
$ git stash pop

이렇게 하면 작업내용을 커밋하지 않고 브랜치 이동하기 완료~

처음에는 브랜치를 변경하지 않은걸 알면 당황스러웠는데, 이제는 초간단 해결 방법을 알기 때문에 당황하지 않는다~ 😎

🖇 참고

https://git-scm.com/book/ko/v2/Git-%EB%8F%84%EA%B5%AC-Stashing%EA%B3%BC-Cleaning https://inpa.tistory.com/entry/GIT-%E2%9A%A1%EF%B8%8F-%EC%BB%A4%EB%B0%8B%ED%95%98%EC%A7%80%EC%95%8A%EA%B3%A0-%EB%B8%8C%EB%9E%9C%EC%B9%98-%EA%B0%84-%EC%9D%B4%EB%8F%99-git-stash