이번 포스팅에서는 학습 16일차에 Kaggle에 있는 타이타닉 생존자예측 dataset을 분석하고, 분석한 dataset을 시각화하는 연습한 내용을 정리하려고 한다.
이번 미니 프로젝트를 통해 얻었던 나 자신에 대한 피드백은 우선 첫 번째 dataset에 대한 사전 분석이 부족했다는 것이다. 그리고 두 번째, DataFrame과 시각화 작업에 대해 연습이 부족하여 작업함에 있어 미숙한 부분이 많았다.

이 피드백을 통해 알게된 개선해야 될 부분에 대해서는 앞으로 차근차근 채워가도록 해야겠다.

타이타닉 생존자 예측 dataset

주어진 dataset은 총 12개의 칼럼과 891개의 행으로 구성되어있다. 즉, 한 사람당 총 12 종류의 정보를 포함하고 있다.
특정 승객의 새존 여부를 알아보려면 survived 항목의 값을 살펴보면 된다. (1:생존)
주어진 test.csv 파일의 구조는 train.csv 파일과 거의 동일하지만, survived 항목이 없다.

1
2
3
4
5
6
7
8

import pandas as pd
import numpy as np # 데이터 분석을 위한 NumPy
import matplotlib.pyplot as plt # 데이터 시각화 라이브러리
import seaborn as sns # 데이터 시각화 라이브러리

train_df = pd.read_csv('train.csv')

print(train_df)

타이타닉 dataset 분석

데이터셋을 시각화하고 결론을 도출해내기 전에는 우선적으로 주어진 dataset에 대한 분석이 필요하다. 이번 미니 프로젝트에서 간과했던 부분이었는데, dataset이 주어졌다면, 우선적으로 주어진 dataset의 columns 구성(df.columns.values),데이터 자료 구성 정보(df.info())를 확인해야한다.

2022년 4월 2일, 퇴사한지는 어느덧 42일차가 되었고, 새롭게 학습을 시작한지는 16일차가 되었다. 그리고 추가적으로 건강관리의 일관으로 시작한 식단조절 및 운동을 한지는 27일차가 되었다.

이번 포스팅에서는 나의 내적으로 좀 의미있는 반성의 시간을 갖으며, 글을 작성해보려고 한다.
반성이 없는 계획과 발전은 의미가 없기 때문에 지난 나의 과거를 다시 되새기고 현재 내가 걱정하는 것을 구체화시켜서 현재의 나를 좀 더 발전시켜 나가고자 한다.

현실적으로 해결할 수 있는 문제와 그렇지 않은 문제

최근 오랜만에 공부를 시작하면서 “내가 의욕이 많이 없구나”라는 것을 느꼈다. 이전에는 새로운 것을 배우면 적용시켜보기 위해 따로 만들어보고 만들어보는 과정을 통해 또 추가적으로 공부를 했었다.
그런데 요즘은 처음 배우는 내용임에도 불구하고, 복습과 시뮬레이션해보는 과정을 따로 하지 않았다.
왜 그랬을까?
이 문제부터 생각에 접근해봐야겠다. 우선 의욕이 없는 이유는 내가 아직도 현실적으로 해결할 수 없는 문제에 대해 신경을 쓰고 있다는 것과 아직도 나 자신에 대한 확신이 부족하기 때문이다.

아무리 주변 경력있으신 분께 조언을 얻으면서 좋은 말씀을 들어도 결국은 현실적으로 해결할 수 있는 부분에 집중해서 현실에 최선을 다하는 것은 내 몫이며 어쩌면 그것이 전부이지 않을까 생각이 된다.

사람마다 각기 무언가를 배우거나 적용하는 방법이 다르듯이, 내가 앞으로 나아가고자 하는 방향에 대해 나 자신이 스스로 찾아보고 부딪히고 체득하면서 나만의 루트를 만들어가는 것이 맞는 것 같다.

내가 알고 있는 것과 모르는 것, 메타인지

내가 알고 있는 것과 모르고 있는 것, 메타인지를 높이기 위한 가장 좋은 방법은 시뮬레이션이라고 한다.
무언가 새로 배웠다면, 내가 진짜 이해를 하고, 스스로 응용을 할 수 있는지 확인하는 과정(시뮬레이션)을 거쳐서 메타인지를 높이는 것이 중요하다.
당장 듣고 바로 적용해보면, 마치 내가 다 이해한 것 마냥 착각을 하고 그 다음 그다음 세션으로 넘어가고, 결국 나중에는 이게 누적이 되서 다시 이전으로 돌아가서 다시 학습을 해야되는 최악의 상황이 온다.
이제부터는 무언가를 학습했다면, 그것을 새롭게 적용시켜보는 과정을 거쳐서 완전한 내것으로 만들어야 한다.

단기 성취를 느낄 수 있는 목표 설정

이번에 퇴사를 하고, 새로운 도메인에 대한 학습을 시작하였다. 혼자서 스스로 학습해야되는 부분이 많고, 그 기간도 상대적으로 길기 때문에 단기적으로 성취감을 느끼면서 계속 동기부여를 얻으면서 앞으로 나아갈 수 있는 목표설정이 필요하다.
그래서 자격증 취득이나 짧게는 하루, 일주일, 한달 단위로 해서 계속 자기 피드백을 받을 수 있도록 목표설정을 하고 나 스스로에 대해 피드백을 해야한다.
지금 이 시점에서 16일이라는 시간이 흘렀지만, 지금부터 다시 제대로 교정하고 다잡아야겠다.
지금 이 습관이 나중에 새로운 회사에 입사해서도 새로운 기술을 습득하고 업무를 함에 있어 좋은 원동력이 될 수 있도록 차근차근 준비해야겠다.

Infinite scrolling 구현

Infinite scrolling을 구현하기 위해 스크롤이 가장 최 하단으로 이동했을때 이벤트를 발생시켜야 한다.
실제 실무에서는 이벤트 발생시점이 최하단이 아닌 하단에서 일정 px 떨어진 이전 시점에 미리 로드할 데이터를 로딩시켜 사용자가 스크롤링을 했을때 끊기는 느낌이 들지 않도록 한다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

useEffect(() => {
  // 현재 스크롤 위치
  function onScroll() {
    // 스크롤된 높이를 구하는데 아래 세가지 함수가 많이 쓰인다.
    console.log(
      // (1) 얼마나 내렸는지
      // 가장 최하단으로 스크롤을 내리면, 최 하단으로 내려간 페이지의 최 상단이 마지막 내려간 지점이 된다.
      window.scrollY,

      // (2) 화면에 보이는 길이(최상단에서 하단 스크롤 위까지 길이)
      document.documentElement.clientHeight,

      // (3) 총 길이 (스크롤의 제일 위부터 아래까지 총 길이)
      // (=) window.scrollY + document.documentElement.clientHeight
      document.documentElement.scrollHeight

      // (1)과 (2)의 합이 (3)과 같을때 스크롤이 가장 최 하단으로 내려갔다는 것을 의미한다.
      // 이 시점에 새로 로딩
    );
    // 끝에서 300px 위보다 더 많이 내렸을때
    if (
      window.scrollY + document.documentElement.clientHeight >
      document.documentElement.scrollHeight - 300
    ) {
      // loadPostLoading이 false인 경우에만 새로운 요청을 한다.
      if (hasMorePosts && !loadPostLoading) {
        dispatch({
          type: LOAD_POST_REQUEST,
          data: mainPosts[mainPosts.length - 1].id
        });
      }
    }
  }

  window.addEventListener('scroll', onScroll);

  // 반드시 스크롤했떤 이벤트를 해제시켜줘야 한다.
  // 안그러면 메모리상에 계속 남아있다.
  return () => {
    window.removeEventListener('scroll', onScroll);
  };
}, [hasMorePosts, mainPosts, loadPostLoading]);

throttle과 takelatest

infinite scrolling을 구현하면서 scroll이벤트가 발생할때마다 매번 비동기 요청이 발생을 하였는데, 이 문제를 해결하기 위해 throttle과 takelatest를 사용해서 해결해보려고 했다.
하지만 throttle과 takelatest 모두 요청(Async request)은 차단되지 않고, 응답(Response)만을 차단하기 때문에 만약에 5s 간격으로 throttle 처리를 하게 되면, 받은 요청에 대해서는 취소되지 않고, 5s 간격으로 지연되서 처리가 되는 것을 확인할 수 있었다.

본질적으로 해결하고자 하는 것은 scroll이벤트에서 발생되는 요청 자체를 차단하는 것이기 때문에 이 문제 해결을 위해 redux의 상태 데이터에서 해당 비동기 처리 요청에 대한 loading과 관련된 상태값을 활용하여 해결하였다.

faker

개발을 하다보면 임의로 데이터를 넣어 실제 페이지가 어떻게 출력이 되는지 확인해야될 때가 있다.
소수의 데이터는 괜찮지만 10개 이상의 데이터를 넣어서 확인을 해야 될 때에는 여간 번거로운 일이 아니다.
이런 경우에 facker라는 패키지를 사용해서 임의의 dummy 데이터를 넣어 줄 수 있다.
(무한 스크롤링 테스트)

[참고]: https://www.npmjs.com/package/faker

1

$ npm i faker

Placeholder.com

dummy 이미지 대체하여 사용할 수 있다.

[참고] : https://placeholder.com/

Redux toolkit

createReducer, createAction을 사용해서 Redux를 사용할때 코드가 길어지는 것을 보완할 수 있다.

이전에 공부할때 정리한 내용을 참고하자.

http://localhost:4000/2021/04/30/202104/210430-Redux_TIL/

immer

state의 데이터 구조가 복잡해지면 불변성을 지키기 위해 변하지 않는 값에 대해 spread 문법을 사용해서 얕은 복사를 하는 것이 지저분해질 수 있는데 immer를 사용하면 이 문제를 해결할 수 있다.

1

$ npm i immer

Redux에서만 아니라 React의 useState, setState에서도 immer를 사용할 수 있으며,hooks를 위한 useImmer도 있다.(useState 대체 가능)

우선 Redux의 reducer 함수에서의 immer의 사용에 대해서 알아보자.

reducer함수는 이전 상태를 action을 통해 다음 상태로 만들어내는 역할을 한다.
이때 새로운 상태는 반드시 불변성을 지켜서 구현을 해줘야 하는데, 구조가 복잡한 객체의 불변성을 지켜서 상태값을 업데이트하는 것이 복잡한 경우에는 immer를 사용한다.

immer의 기본 사용 형태
기존 reducer함수의 switch-case 문을 produce의 내부에 작성해준다.

1
2
3

const reducer = (state = initialState, action) => {
  return produce(state, (draft) => {});
};

immer를 사용하게 되면, 기존에 state로 작성했던 부분이 draft로 대체가 된다. draft는 별도의 불변성과 상관없이 작성을 해줘도 immer가 알아서 새로운 state를 불변성 지켜서 만들어준다. (state 인자는 건들이지 말고 draft만 조작하도록 한다 - return produce()부분이 불변성을 지킨 새로운 state 값을 반환해준다)

2021/05/17 - redux-thunk 내용추가

Next Redux Wrapper

일반적으로 React에 Redux를 붙일 때에는 하나의 Redux store만 존재하기 때문에 어렵지 않다.
하지만 Next.js에서 Redux를 사용하게 되면 여러 개의 Redux store가 생성된다.
그 이유는 Next.js에서는 User가 Request를 보낼때마다 Redux store를 새로 생성하기 때문이다. 그리고 Next.js에서 제공하는 getInitialProps와 getServerSideProps에서도 Redux store에 접근이 가능하도록 해야되기 때문에 NextJS에서 Redux를 붙일때 꽤나 복잡하다. 하지만 이를 간편하게 해주는 라이브러리가 있는데 바로 Next Redux Wrapper이다.

next redux wrapper 설치

/store/configureStore.js

1
2
3
4
5
6
7
8
9
10
11
12
13
14

import { createWrapper } from 'next-redux-wrapper';
import { createStore } from 'redux';
import reducer from '../reducers';

const configureStore = () => {
  const store = createStore(reducer);
  return store;
};

const wrapper = createWrapper(configureStore, {
  debug: process.env.NODE_ENV === 'development'
});

export default wrapper;

참고 : https://github.com/vercel/next.js/tree/master/examples/with-styled-components

Next.js에서 styled-components 사용하기

Next.js에서 styled-components를 사용하려면 몇 가지 설정이 필요하다.

(1) babel-plugin-styled-components 설치하기

이 패키지를 설치하는 이유는 Next에서 최초로 SSR이 된 이후에 내부 라우팅을 통해 페이지가 이동하면서 CSR을 하게 되는데, className의 해시값이 서버에서 생성되는 값과 브라우저에서 생성되는 값이 불일치하게 되면서 에러가 발생하기 때문에 설치해줘야 한다.

1

npm i -D babel-plugin-styled-components

(2) .babelrc 파일 생성하기

1
2
3
4

{
  "presets": ["next/babel"],
  "plugins": [["styled-components", { "ssr": true }]]
}

(3) pages 폴더 아래에 _document.js 파일 생성하기

참고: https://nextjs.org/docs/advanced-features/custom-document

keyof와 typeof의 혼합 사용

특정 변수의 타입을 정의할때 만약에 해당 타입이 다른 타입과 종속적인 관계에 있다면, 종속관계에 있는 해당 타입의 정의를 참조해서 타입을 정의해야 한다.

아래는 스프라이트 기법으로 이미지를 잘라내서 사용하기 위한 이미지 좌표의 타입 정의이다.

1
2
3
4
5
6
7
8

const coords = {
  img1: '0',
  img2: '-142px',
  img3: '-284px'
} as const;

type a = keyof typeof coords; // coords 타입(typeof)의 key 값(img1 | img2 | img3)
type imgCoords = typeof coords[keyof typeof coords] // '0' | '-142px' | '-284px'

2021/05/13 Update - createSelector shopping cart 연습예제

React는 프레임워크가 아닌 라이브러리?

상태관리 라이브러리에 대해서 포스팅을 하는 글에서 갑자기 뜬금없이 React가 프레임워크인지 아닌지에 대한 이야기를 하는 이유는 React에서는 상태관리와 라우팅을 기본적으로 제공하지 않기 때문에 라이브러리로 분류한다는 이야기를 하기 위해서이다. Vue와 Angular에서는 자체적으로 상태관리를 지원하기 때문에 프레임워크라고 하지만 React는 다르다.
하지만 생태계 자체로써 봤을때에는 React도 프레임워크이다.

React의 상태관리 라이브러리의 선택지 Redux와 MobX

React는 Vue와 Angular와 다르게 자체적으로 상태관리를 지원하지 않기 때문에 Redux나 MobX를 선택적으로 사용해서 상태를 관리한다.

ContextAPI + useReducer가 Redux와 MobX를 대체할 수 있다?

JavaScript를 ContextAPI+useReducer라고 하고, jQuery를 Redux나 MobX라고 비유한다면, ContextAPI+useReducer의 조합으로 Redux나 MobX를 구현할 수 있다는 결론이 나온다. 하지만 손쉽게 사용할 수 있도록 이미 만들어져 있는 Redux나 MobX를 사용하는 것이 좋다.

지난 과거의 나와 현재의 나 그리고 두려움을 극복하기 위한 자기반성

이번 포스팅에서는 나의 내적으로 좀 의미있는 반성의 시간을 갖으며, 글을 작성해보려고 한다.
반성이 없는 계획과 발전은 의미가 없기 때문에 시간이 많이 흘렀지만, 지난 나의 과거를 다시 되새기고 현재 내가 걱정하는 것과 두려워하는 것을 구체화시켜서 현재의 나를 좀 더 발전시켜 나가고자 한다.

우선 현재의 나는 프론트엔드 개발자로서 취업을 준비하고 있고, 내가 지원하고자 하는 포지션에서 필요로하는 기본적이고 중요한 기술적인 부분을 스스로 공부하며 자기개발을 해나가고 있는 중이다.

현재의 나에게 있어, 가장 큰 두려움은 제대로 된 개발자가 될 수 있을까?이다. 나에게 있어 제대로 된 개발자란, 자기개발을 꾸준히 하고, 견고한 어플리케이션 개발에 대해 끊임없이 고민을 하며, 내가 하는 일과 어플레케이션에 대해 자부심을 가지는 개발자가 되는 것이다.

나는 2018년 10월부터 2020년 4월 17일까지 짧다면 짧은 1년 반이라는 시간동안 일본에서 개발자로 일을 했었다. 그때 당시 내가 개발자로서 일을 하면서 느꼈고, 현재 내가 가지고 있는 두려움에 영향을 준 경험에 대해서 적어보며 직접 이 두려움에 직면해서 극복해보려고 한다.