배민에서 React Query와 Justand를 선택한 이유는?

React Query를 선택한 이유

• API 호출 코드로 비대해진 Store를 목적에 맞게 분리
• 리액트 훅과 비슷한 직관적인 사용성
• 여러 인터페이스 & 옵션을 제공해 적은 코드로 강력한 동작
• 자체 개발도구 제공
• 캐싱, 동기화 등 다양한 기능

Zustand 역시 마찬가지의 이유이며 React-query는 서버 상태, Zustand는 클라이언트 상태관리를 담당한다.

Zustand를 선택한 이유

• 컴포넌트 밖에서도 상태 변경이 가능
• 사용성이 단순해 러닝커브가 낮음
• 상태관리에 필요한 코드도 적음

1. 실전 적용 예

컴포넌트를 business, store layer로 나누어 역할에 맞게 분리. 그 결과 컴포넌트는 한눈에 역할을 알아볼수 있을 정도로 짧고 명료해 졌다.

2. Clinet State: Zustand 예

3. Server State: React Query 예

3. Businnes Layer /hooks

4. Store Layer

상태관리와 레이어의 도입 전후

이 글을 정리하기전까진 어떤식으로 컴포넌트들을 분리 할 수있을까?란 고민부터 디자인 패턴들을 보아도 막상 저걸 어떻게 적용할 수 있지? 란 생각이 있었었다. tanstack-query의 useQuery는 그 자체만으로도 하나의 훅인데 이걸 또 훅안에 담아서 관리 할 필요가 있을까? hook으로 구분해서 분류를 한다면 어떻게 해야할까라는 고민이 있었는데 예시를 통해 어떻게 정리해야하는지의 표본을 봐서 내 프로젝트는 어떻게 적용할지 벌써 설렌다.

💡 원티드 프리온보딩이란?

원티드에서 진행하는 코스로 신입, 이직 개발자를 대상으로 팀 협업 중심의 프로그램. 프론트엔드 , 백엔드 등 분야별로 나뉘어 있다. 그 중 내가 수료한 코스는 프론트엔드 6차!

기간은 : 22.08.29 ~ 22.09.30 5주가량

🔍 어떤식으로 진행되는지??

주 2회 3시간씩 있는 세션에서** 클린코드, 컴포넌트 세분화, 리덕스, 리액트 쿼리, 타입스크립트** 등의 기술들을 강의해주고 팀별로 기업과제를 통하여 적용도 해보고 리팩토링도 해보는 식으로 진행이 되었다.

✏️ 어떤 부분을 배울 수 있었는지?

이번 코스로 배울수 있던점은 정말 많았다. 우리팀은 프론트엔드 6명으로 구성되었던 팀으로 기업과제를 페이지가 많고 양이 많으면 분담하여 진행을 하였고 양이 적다고 생각되는 과제는 개인별 진행을 하고 서로 리뷰 후에 투표로 best practice를 선별하여 제출하는 식으로 진행을 하였다.

팀원들에게 많이 배우며 코드도 참고를 하였었는데 팀원 한분의 axios 라이브러리를 커스텀 한 것을 참고로 내 입맛에 맞게 바꾸어 그 뒤에 있는 프로젝트들에서 다 적용을 시켜버렸다! 이제 내꺼다!

뿐만 아니라 컴포넌트를 어느 단위까지 쪼개야 하는지, 폴더 구조는 어떻게 갈것인지 서로의 의견을 장단점을 더해 설명하며 토론하는 시간도 여럿 있었으며 각자 깃허브 Pull request시에 바로 머지하지 않고 서로 리뷰를 해주어 피드백을 주곤 하였다.

원티드에서는 팀내의 과제 등에는 아예 간섭을 하지 않았고 나포함 능동적인 팀원들 덕에 무사히 코스를 마칠수 있었던것 같다.

힘든 5주 일정동안 잘 이끌어준 팀원들에게 다시 한번 고마움을 표한다.

📌 아쉬웠던 부분?

아쉬웠던 부분이라고 하면 알고는 있었지만 직접 겪어보니 일정이 너무 빠듯했다.. 화, 금 오후 2시세션 이후에 과제를 내주고 제출은 각 월, 목 정오까지 제출하는 방식으로 실제 쉴수 있는시간은 제출후 반나절 정도 있었던것 같다.

우리팀도 처음부터 손발이 잘 맞았던건 아니고 첫 과제 초기세팅에선 꽤 많은 시간 회의가 이루어졌다. 자바스크립트를 쓸 것인지, 타입스크립트를 쓸 것인지, css 전처리기는 어떤 것을 사용할 것인지, 폴더 구조는 어떻게? 누가 어떤 부분을 담당할 것인지에 대해 많은 얘기가 필요하였고 초기세팅으로만 새벽까지 이어져 프로젝트 시작은 다음날 오후가 되서야 시작 할 수 있었다.

물론 그 이후엔 먼저 맞추었던 보일러플레이트가 있던 관계로 변경사항만 짚고 넘어갔으면 되었어서 무난히 진행이 되었다.

또 다른 부분은 세션 커리큘럼에 포함되어 있던 리액트 쿼리와, 리덕스를 아직 공부가 좀 많이 필요한데에 있다. 필요한 부분으로는 리액트 쿼리 - 기본적인 사용은 가능하나 특정 이벤트 시에 작동, 훅 제작하여 사용 등 심화적인 부분에 대해 학습이 필요. 리덕스 - 이해는 기본적인 툴킷까지만... flex 패턴부터 미들웨어까지 전체적인 깊은 학습이 필요하다!!

⛳️ 회고를 마치며

프리온보딩 일정은 코스를 마친후 참가한 기업들의 채용설명회가 진행이 되었는데 분명 프론트엔드 코스이나 프론트엔드만을 뽑으려는 기업은 거의 없어 아쉬운 부분이 있다.

너무 바쁜 5주 일정이였던 터라 다른 동기들은 이 시간에 사이드 프로젝트, 포트폴리오에 신경을 썼으면 취직을 하지 않았을까? 라고 생각하는 경우도 있지만 나는 단기간에 성장하기엔 너무 좋은 프로그램으로 기억에 남아 여러 사람에게 추천할 예정이다.

클로저는 함수와 함수가 선언된 어휘적 환경의 조합으로 클로저를 이해하려면 자바스크립트가 어떻게 변수의 유효 범위를 지정하는지(lexical scoping)을 먼저 이해해야 한다.

    function init() {
      var name = "Mozilla"; // name은 init에 의해 생성된 지역 변수이다.
      function displayName() { // displayName() 은 내부 함수이며, 클로저다.
        alert(name); // 부모 함수에서 선언된 변수를 사용한다.
      }
      displayName();
    }
    init();

init은 지역 변수 name과 함수 displayName을 생성. displayName 내부엔 지역 변수가 없다. 그런데 함수 내부에서 외부 함수의 변수에 접근할 수 있기 때문에 displayName이 부모 함수 init 안에서 선언된 변수 name에 접근을 할 수 있다. displayName이 자신만의 name 변수를 가지고 있었다면, **name 대신 this.name을 사용했을 것이다.**

이는 어휘적 범위 지정(lexial scoping)의 한 예이다. lexical은 어휘적 범위 지정(lexial scoping) 과정에서 변수가 어디에서 사용 가능한지 알기 위해 그 변수가 소스 코드 내 어디에서 선언되었는지 고려한다는 것을 의미한다. 중첩된 함수는 외부 범위에서 선언한 변수에도 접근할 수 있다

let과 const를 사용한 범위 지정

ES6 이전 var만 사용 했던 Javascript에선 함수 스코프와 전역스코프 두가지만 존재했다. var로 선언한 변수는 함수 내부에서 선언되었을때만 블록 스코프가 되며 if,for문 등 다른 중괄호로 표시된 블록 안에서는 스코프를 생성하지 않아 혼란을 일으킬 수 있는 여지가 있었다.

if (Math.random() > 0.5) {
      var x = 1;
    } else {
      var x = 2;
    }
    console.log(x); // 콘솔 잘 찍힘.

Javascript의 경우 var로 선언된 변수는 함수에서만 블록 스코프가 되어 조건문 안에 있는 x는 글로벌 스코프가 되기에 콘솔이 잘 찍힌다.

ES6에선 호이스팅 뿐만 아니라 이러한 문제도 해결하기 위해 let과 const를 도입하며 시간상 사각지대 등을 같이 도입하였다.

    if (Math.random() > 0.5) {
      const x = 1;
    } else {
      const x = 2;
    }
    console.log(x); // ReferenceError: x is not defined
                    // const와 let은 조건문,반복문 등에서도 지역스코프가 된다.

비슷한 다음 예제

    function makeFunc() {
      var name = "Mozilla";
      function displayName() {
        alert(name);
      }
      return displayName;
    }

    var myFunc = makeFunc();
    //myFunc변수에 displayName을 리턴함
    //유효범위의 어휘적 환경을 유지
    myFunc();
    //리턴된 displayName 함수를 실행(name 변수에 접근)

이 코드는 바로 전 코드와 같을까? 동일한 결과가 실행된다. 하지만 차이가 있다면 displayName 함수가 실행되기 전에 외부함수인 makeFunc로 부터 리턴되어 myFunc 변수에 저장된다는 것이다.

솔직히 처음 봤을때는 무슨차이가 있나 싶었다. makeFunc 함수의 실행이 끝나면 name 변수에 더이상 접근할 수 없을 걸로 생각했었다.

하지만 자바스크립트는 다르다고한다. 그 이유로는 자바스크립트는 함수를 리턴하고, 리턴하는 함수가 클로저를 형성하기 때문에. 클로저란 함수와 함수가 선언된 어휘적 환경의 조합이다 이 환경은 클로저가 생성된 시점의 유효 범위 내에 있는 모든 지역 변수로 구성된다. 첫번째 예시의 경우, myFunc은 makeFunc이 실행 될 때 생성된 displayName 함수의 인스턴스에 대한 참조다. 이런 이유로 displayName의 인스턴스는 변수 name이 있는 어휘적 환경에 대한 참조를 유지. 이런 이유로 myFunc가 호출될 때 변수 name은 사용할 수 있는 상태로 남게 되고 "Mozilla"가 alert에 전달된다.

이 다음 예제를 한번 보자

function makeAdder(x) {
      var y = 1;
      return function(z) {
        y = 100;
        return x + y + z;
      };
    }

    var add5 = makeAdder(5);
    var add10 = makeAdder(10);
    //클로저에 x와 y의 환경이 저장됨

    console.log(add5(2));  // 107 (x:5 + y:100 + z:2)
    console.log(add10(2)); // 112 (x:10 + y:100 + z:2)
    //함수 실행 시 클로저에 저장된 x, y값에 접근하여 값을 계산

이 예제에서 단일 인자 x를 받아서 새 함수를 반환하는 함수 makeAdder(x)를 정의했다. 반환되는 함수는 단일인자 z를 받아서 x와 y와 z의 합을 변환하다.

본질적으로 makeAdder는 함수를 만들어내는 공장이다. 이는 makeAdder 함수가 특정한 값을 인자로 가질 수 있는 함수들을 리턴한다는 것을 의미. 위 코드에서 add5, add10 두 개의 새로운 함수들을 만들기 위해 makeAdder 함수를 사용. 하나는 매개변수 x에 5를 더하고 다른 하나는 매개변수 x에 10을 더한다.

add5와 add10은 둘 다 클로저이다. 이 둘은 같은 함수 본문 정의를 공유하지만 서로 어휘적 환경을 저장한다. 함수 실행시에 add5의 맥락적 환경에서 클로저 내부의 x는 5이지만 add10의 맥락적 환경에서 x는 10이다. 또한 리턴되는 함수에서 초기값이 1로 할당된 y에 접근하여 y 값을 100으로 변경한 것을 볼 수 있다. (물론 x값도 동일하게 변경 가능하다.) 이는 클로저가 리턴된 후에도 외부함수의 변수들에 접근 가능하다는 것을 보여주는 포인트이며 클로저에 단순히 값 형태로 전달되는것이 아니라는 것을 의미한다.

요약

• 클로저란 함수와 함수가 선언된 어휘적 환경의 조합이다
• 클로저가 생성된 시점의 유효 범위 내에 있는 모든 지역 변수로 구성된다.

솔직히 오늘 클로저 처음 본거 아니였다... 근데 첨에 봤을땐 이게 뭔지 싶었다. 여러 블로그를 돌아다녔지만 결국 이해시켜준건 mdn. 충성충성

일반적인 React에서 prop 전달의 흐름은 하향식이다. (부모에서 자식으로) 전달되는 prop이 많아지고 컴포넌트 깊이가 깊어지면 관리가 번거로워 질 수 있다. Context Tree는 컨텍스트 안에 포함된 모든 레벨에서 명시적으로 prop을 전달하지 않고, 어디서든 상태값에 접근 할 수 있는 방법을 제공한다.

Context는 아무것도 관리하지 않는다. 단순한 값을 전달하는 파이프와 같다. 사용하는 주요 목적은 prop-drilling을 피하는 것이다. prop-passing 로직을 작성할 필요가 없기 때문에 코드가 단순해진다.

💡 Redux란?

애플리케이션 전체에 대한 상태 중앙 저장소 역할을 하며 액션이라는 이벤트를 사용하여 에플리케이션의 상태를 예측 가능한 방식으로 업데이트 하기 위한 패턴 또는 라이브러리이다.

Redux에서 제공하는 패턴과 도구들을 사용하면 상태가 언제, 어디서, 어떻게, 왜 업데이트 되었는지 쉽게 이해 할 수 있다.

• 상태 관리
• Redux의 목적은 시간이 지남에 따라 상태 값들이 어떻게 변하는지 쉽게 이해할 수 있도록 돕는것이다.

React에서 Redux를 사용할 때 사용되는 React-Redux 라이브러리는 Redux에서 상태 값을 읽고 action을 React 컴포넌트에게 전달하여 Redux 저장소와 상호 작용 할 수 있도록 도와주는 UI바인딩 레이어이다.

React-Redux 를 사용하면 애플리케이션의 모든 React 요소들이 Redux 저장소에 접근이 가능한데 이는 React-Redux 내부에서 Context 를 사용하기 때문이다. 여기서 주의할 점은 React-Redux 는 현재의 상태값이 아닌 Context 를 통해 Redux 저장소 인스턴스만 전달한다는점이다.

Redux 목적

• UI 레이어와 분리된 상태 관리 로직 작성이 필요할 때
• 서로 다른 ui 계층간에 상태 공유가 필요할 때
• Redux 미들웨어 기능을 빌려 액션이 전달 될 때 추가적인 로직이 필요할때

⭐️ Context가 상태 관리가 아닌 이유

상태관리라 하면 시간이 지남에 따라 상태가 변경되는 방식을 의미한다.

• 초기 값을 저장한다.
• 현재 값을 읽을 수 있다.
• 값 업데이트가 가능하다.

React useState와 useReducer가 상태 관리의 좋은 예이다.

• hook을 호출하여 초기 값 저장
• hook을 호출하여 현재 값을 읽는다
• 제공된 setState, dispatch 함수를 호출하여 값을 업데이트한다.
• 구성요소가 re-render 되었기 때문에 값이 업데이트 됐음을 확인 할 수 있다.
• 마찬가지로 Redux, Recoil, Mob x 도 위의 조건들을 충족하기 때문에 상태관리라 할 수 있다.

Context의 경우 위의 조건을 충족하지 않는다. Context는 전달되는 값을 결정하는 역할을 하고 일반적으로 실제 상태 관리는 useState/useReducer hook과 함께 발생한다.

Context는 상태(이미 존재하는, 어딘가에 있는)가 Context Tree 내부에 포함된 다른 컴포넌트들과 공유되는 방식이다.

Context와 useReducer

useReducer는 Redux + React-Redux와 비슷한 구조를 가지고 있다.

• 값의 저장
• reducer 함수
• action 전달
• 값을 전달하고 컴포넌트에서 읽는 방법

기능과 동작에는 차이점이 많음

• Context + useReducer는 Context를 통해 현재 상태 값을 전달하는데 의존. React-Redux는 Context를 통해 현재 Redux 스토어 인스턴스를 전달한다.

• useReducer의 경우 새로운 상태 값을 생성 할 때 해당 Context 내부에 포함된 컴포넌트들이 상태 값의 일부에만 관심이 있더라도 강제로 re-render 되기 때문에 성능 문제가 발생할 수 있다. re-render 되기 때문에 성능 문제가 발생 할 수 있다. React-redux를 사용하면 저장소 상태의 특정 부분만 사용하고 해당 값이 변경 될 때만 re-render 할 수 있다.

• Context + useReducersms React의 기능이기 때문에 React 외부에서는 사용이 불가하다. Redux는 UI 독립적이기 때문에 React와 별도로 사용이 가능하다.

• useReducer는 미들웨어가 없다.

Context API + useReducer는 낮은 규모와 빈도의 업데이트와 같은 정적인 상태의 전달에는 괜찮지만, Flux와 유사한 상태 전파의 대체물로는 부족하다.

최종 정리

• 단순 prop-drilling을 피하는 것이 목적이라면 Context를 사용하자.

• 적당히 복잡한 컴포넌트가 있거나 외부 라이브러리를 사용하고 싶지 않다면 Context +useReducer를 사용해라

• 특정 구성 요소만 re-render 시키거나, 사이드이펙트를 줄이기 위해 더 강력한 기능이 필요하다면 Redux + React+Redux를 사용

⭐️ 얕은 복사 shallow copy

얕은 복사란 한 단계까지만 복사하는 것을 의미하며 객체 안에 객체가 담겨 있는 객체의 경우 참조 값을 복사한다.

얕은 복사의 방법으로는 우리가 잘 아는 스프레드 연산자를 사용한다.

const 100 = { name: { first: "gwanghyun", last: "Baek" } };
const shallowCopied100 = {...100};

console.log(shallowCopied100 === 100); //false
console.log(shallowCopied100.name.first === 100.name.first); //true
console.log("재할당 전 원본", 100.name.first); //gwanghyun
console.log("재할당 전 복사본", shallowCopied100.first); //gwanghyun

shallowCopied100.name.first = "pizza";

console.log(shallowCopied100 === 100); //false
console.log(shallowCopied100.name.first === 100.name.first); //true
console.log("재할당 후 원본", 100.name.first); //bumsoo
console.log("재할당 후 복사본", shallowCopied100.name.first); //pizza

왜 false가 출력이 될까?

스프레드 연산자를 사용해서 얕은 복사를 하게되면 서로 다른 메모리 주소값을 가지게 된다. console.log(shallowCopied100 === 100) //false 결과를 가져오는 이유는 복사를 했기 때문에 두개는 서로 다른 메모리 주소값을 가진다.

얕은 복사는 다른 메모리에 저장되어 원본 사본이 있는데 재할당을 shallowCopied100.name에만 했는데 왜 100.name도 수정된 값 pizza가 출력되나요?

100과 shallowCopied100의 메모리 주소는 다르지만 동일한 참조 값을 갖습니다. 다시 말해 원본과 복사본이 모두 동일한 객체를 가르킨다.

즉, 100에는 참조값인 객체 데이터가 저장된 메모리 주소가 할당되어 있고 같은 주소가 shallowCopied100에도 동일하게 할당되어 있다.

두개의 식별자가 하나의 객체를 공유하는 상황이다.

따라서 원본 또는 사본 중 어느 한쪽에서 객체를 변경하면 서로 영향을 주고 받는다!!.

그럼 중첩된 객체를 복사하고 따로 값을 할당하고 싶을 때는 어떻게 하면 될까요?

이럴땐 깊은복사!

💡 깊은 복사 deep copy

깊은 복사가 된 객체는 객체 안에 객체가 있을 경우에도 원본과의 참조가 완전히 끊어진 객체를 말한다.

깊은 복사를 할 수 있는 방법으로는 JSON.parse && JSON.stringify와 재귀함수도 있지만 쉽지않다. Lodash 라이브러리 쓰자

const deepCopy = require("lodash.clonedeep") const object = {  a: "a",  number: {    one: 1,    two: 2,  },  arr: [1, 2, [3, 4]],}; const copy = deepCopy(object); copy.number.one = 3;copy.arr[2].push(5); console.log(object === copy); // falseconsole.log(object.number.one === copy.number.one); // falseconsole.log(object.arr === copy.arr); // false console.log(object); // { a: 'a', number: { one: 1, two: 2 }, arr: [ 1, 2, [ 3, 4 ] ] }console.log(copy); // { a: 'a', number: { one: 3, two: 2 }, arr: [ 1, 2, [ 3, 4, 5 ] ] }

출처: https://bbangson.tistory.com/78 [뺑슨 개발 블로그:티스토리]

자바스크립트에서 불변성이란 객체가 생성된 이후 그 상태를 변경할 수 없는 것을 의미한다. 여기서 상태를 변경할 수 있는 것과 값을 재할당하는 것은 다르다는 것이다.

let a = 10;
let b = a;
a = 20;
console.log(a,b); //20 10

위 코드에서 a에 10을 할당, b는 a가 가리키는 주소를 가르킨다. 이때 a의 값을 20으로 바꾸면?

값이 직접 변경되는 것이라면 a와 b 둘다 20을 출력해야 한다.

하지만 자바스크립트에서 number 값은 불변성을 유지하기 때문에 새롭게 20이라는 값을 가지는 주소를 a에 할당하게 되기 때문에 위와 같은 결과가 나오게 된다.

1. immutable vs mutable

자바스크립트에서 불변성을 유지하는 값들과 그렇지 않은 값들이 나누어져 있다.

Boolean, Number, String, null, undefined, Symbol과 같은 타입들은 불변성을 유지하는 타입들이고 Object 타입들은 변경가능한 값들이다.

이 말은 객체는 객체 내부의 값을 변경하면 객체를 참조하고 있는 다른 값들도 다 같이 변경된다는 의미이다.

var coke = {
    name: 'coca',
    price: 2980,
}
var new_coke = coke;
coke.name = 'pepsi';
console.log(coke.name,new_coke.name);//'pepsi' 'pepsi'

위와 같이 coke의 name 값을 변경했는데 new_coke의 name까지 한번에 변경된 것을 볼 수 있다.

2. 객체의 불변성 지키기

2.1 스프레드 문법 사용

var coke = {
    name: 'coca',
    price: 2980,
}
var new_coke = {...coke};
coke.name = 'pepsi';
console.log(coke.name,new_coke.name);//'pepsi' 'coca'

스프레드 문법을 사용하여 객체를 복사해야 객체가 불변성을 유지할 수 있습니다. 하지만 스프레드 문법은 1레벨 깊이에서만 유효하게 동착하는 얕은 복사이기 때문에 객체 내부의 불변성까지는 유지할 수 없다.

var coke = {
    name: 'coca',
    fake: {
        name: 'pepsi',
    }
}
var new_coke = {...coke};
coke.fake.name = 'coca zero';
console.log(coke.fake.name,new_coke.fake.name);
//'coca zero' 'coca zero'

레벨2 객체까지 불변성을 유지해주려면 아래와 같이 별도의 변수에 값을 재할당하고 넣어주는 번거로운 과정을 거쳐야 한다.

const coke = {
    name: 'coca',
    fake: {
        name: 'pepsi',
    }
}
const new_fake = {...coke.fake};
const new_coke = {...coke};
new_coke.fake = new_fake;
coke.fake.name = 'coca zero';
console.log(coke.fake.name,new_coke.fake.name);
//'coca zero' 'pepsi'

2.2 immer

불변성을 유지하기 위해 복잡한 과정없이 immer 라이브러리를 사용하면 간단하게 불변성을 유지할 수 있습니다.

• 설치 npm i immer
• import import produce from 'immer
• 사용방법

import produce from 'immer';
const coke = {
    name: 'coca',
    fake: {
        name: 'pepsi',
    }
}

const new_coke = produce(coke, (draft) => {
    draft.name = 'pepsi';
    draft.fake.name = 'coca';
});
console.log(coke.name,coke.fake.name);
console.log(new_coke.name,new_coke.fake.name);

//"coca" "pepsi"
//"pepsi" "coca"

불변성을 지키는 것이 왜 중요한가?

개발자는 유지보수가 가능하고 가독성이 좋은 코드를 작성해야한다.

불변서을 지키지 않는다면 위의 예시처럼 사용할 데이터가 어디서 어떻게 바뀌어가는지 흐름을 쫓아가기 어렵고, 이는 곧 예기치 못한 side effects나 버그로 이어지게 된다.

불변성을 지켜 명시적으로 작성된 코드는 다른 개발자가 코드를 보았을 때도 내가 모르는 어딘가에서 데이터가 변화했을거야! 라는 불필요한 의심 없이 코드를 읽는 그대로 흐름을 따라가면서 이해할 수 있도록 돕는다.

그러므로 불변성을 지키면서 데이터를 변화시킨다면, 예상가능하고 신뢰할 수 있는 코드가 될 수 있다.

ex)

<div onclick="alert('div에 할당한 핸들러!')">
  <em><code>EM</code>을 클릭했는데도 <code>DIV</code>에 할당한 핸들러가 동작합니다.</em>
</div>

위 예시코드에 이벤트는 div에 할당되어 있지만, em이나 code 태그를 클릭해도 동작한다.

왜 동작하는 걸까??

버블링

버블링(bubbling)의 원리는

한 요소에 이벤트가 발생하면, 이 요소에 할당된 핸들러가 동작하고, 이어서 부모 요소의 핸들러가 동작한다. 가장 최상단의 조상요소를 만날 때까지 이 과정이 반복되면서 요소 각각에 할당된 핸들러가 동작한다.

<form onclick="alert('form')">FORM
  <div onclick="alert('div')">DIV
    <p onclick="alert('p')">P</p>
  </div>
</form>

가장 안쪽 p태그를 클릭하면

1. p태그에 할당된 onclick 핸들러가 동작.
2. 바깥 div태그에 할당된 핸들러가 동작.
3. form 태그에 할당된 핸들러가 동작. 최상위인 document 객체를 만날 때까지, 각 요소에 할당된 onclick 핸들러가 동작한다.

이런 동작 방식 때문에 p 태그를 클릭하면 p -> div -> form 순서로 3개의 alert 창이 뜨게 된다.

이런 흐름을 '이벤트 버블링'이라고 한다. 가장 깊은 곳에 있는 요소에서 시작해 부모 요소를 거슬러 올라가는 모습이 물속 거품과 닮았기 때문이다.

event.target

우리가 흔히 사용하던 event.target은 정확히 이벤트가 어디서 발생했는지 등에 대한 자세한 정보를 얻을 수 있다.

이벤트가 발생한 가장 안쪽의 요소는 타겟(target)요소라고 하며, event target을 사용해 접근할 수 있다.

event.target과 this(event.currentTarget)은 다르다

this는 현재 요소로, 실행중인 핸들러가 할당된 요소를 참조한다.

버블링 중단하기

이벤트 버블리은 타겟에서 시작해서 document 객체를 만날 때까지 각 노드에서 모두 발생한다. 몇몇 이벤트는 window 객체까지 거슬러 올라가기도 한다. 이때 모든 핸들러가 호출되는데 핸들러에게 이벤트를 완전히 처리하고 난 후 버블링을 중단하도록 명령할 수도 있다. * event.stopPropagation()* 을 사용하면 된다.

<body onclick="alert(`버블링은 여기까지 도달하지 못합니다.`)">
  <button onclick="event.stopPropagation()">클릭해 주세요.</button>
</body>

event.stopPropagation()은 위쪽으로 일어나는 버블링은 막아주지만, 다른 핸들러들이 동작하는 건 막지 못한다.

버블링을 멈추고, 요소에 할당된 다른 핸들러의 동작도 막으려면 event.stopImmediatePropagation()을 사용해야 한다. 이 메서드를 사용하면 요소에 할당된 특정 이벤트를 처리하는 핸들러 모두가 동작하지 않는다.

캡쳐링

버블링과는 정반대의 단계로 자주 쓰이진 않지만, 종종 유용한 경우가 있다고 한다.

1. 캡쳐링 단계 - 이벤트가 하위 요소로 전파되는 단계
2. 타깃 단계 - 이벤트가 실제 타깃 요소에 전달되는 단계
3. 버블링 단계 - 이벤트가 상위 요소로 전파되는 단계

캡쳐링 단계에서 이벤트를 실행하려면 addEventListener의 capture 옵션을 true로 설정해야 한다.

  elem.addEventListener(..., {capture: true})
// 아니면, 아래 같이 {capture: true} 대신, true를 써줘도 됩니다.
elem.addEventListener(..., true)

capture 옵션은 두가지 값을 갖는다.

• false이면(default) 핸들러는 버블링 단계에서 동작.
• true이면 핸들러는 캡쳐링 단계에서 동작.

요약

이벤트가 발생하면 이벤트가 발생한 가장 안쪽 요소가 event.target이 된다.

• 이벤트는 document에서 시작해 DOM트리를 따라 event.target까지 내려간다. 이벤트는 트리를 따라 내려가면서 addEventListener(..., true)로 할당한 핸들러를 동작시킨다. addEventListener(..., true)의 true는 {capture: true}의 축약형이다.

• event.target에 설정된 핸들러가 호출된다.

• 이벤트가 event.target 부터 시작해서 최상위 노드까지 전달되면서 각 요소에 on로 할당한 핸들러와 addEventListener로 할당한 헨들러를 동작시킨다.

  버블링을 멈출 수 있는 방법으로는 event.stopPropagation()이 있지만 추천되는 방법은 아니다. 추후에 버블링이 필요한 경우가 생기기 때문.

무한 스크롤을 구현하는 방법엔 여러 방법이 있지만 스크롤 이벤트와 인피니티 스크롤 라이브러리는 해당 과제에 적합하지 않았다. Intersection Observer API는 기본적으로 브라우저 Viewport와 Target으로 설정한 요소의 교차점을 관찰하여 그 Target이 Viewport에 포함되는지 구별하는 기능을 제공한다.

Intersection Observer API를 사용하는 부분을 custom hook으로 분리하기전 옵션값인 Intersection Observerinit 인터페이스를 먼저 확인한다.

// [코드 10] IntersectionObserver 옵션 인터페이스
interface IntersectionObserverInit {
   root?: Element | Document | null;
   rootMargin?: string;
   threshold?: number | number[];
}

// [코드 11] IntersectionObserver custom hook
type IntersectHandler = (
 entry: IntersectionObserverEntry,
 observer: IntersectionObserver
) => void

const useIntersect = (
 onIntersect: IntersectHandler,
 options?: IntersectionObserverInit
) => {
 const ref = useRef<HTMLDivElement>(null)
 const callback = useCallback(
   (entries: IntersectionObserverEntry[], observer: IntersectionObserver) => {
     entries.forEach((entry) => {
       if (entry.isIntersecting) onIntersect(entry, observer)
     })
   },
   [onIntersect]
 )

 useEffect(() => {
   if (!ref.current) return
   const observer = new IntersectionObserver(callback, options)
   observer.observe(ref.current)
   return () => observer.disconnect()
 }, [ref, options, callback])

 return ref
}

먼저 target 위치를 잡을 ref를 선언. 그후 root와 target이 교차 상태인지 확인하는 isintersecting 값이 true이면 콜백을 실행하는 함수를 useCallback으로 선언한다. useEffect 콜백에서 Intersection Observer 객체를 생성하고 observe 호출을 통해 target 요소의 관찰을 시작한다. 컴포넌트가 언마운트될 때는 clean up을 통해 disconnect를 호출하여 모든 요소의 관찰을 중지하도록 한다.

여기까지가 intersection observer API에 관한 예시코드이고 내가 참고한 카카오 기술 블로그 에선 react-query와 같이 사용하여 구현을 하였다.

이번 과제는 UI관련 라이브러리 이외엔 사용이 불가 하였고 남은 프리온보딩 과제중 무한스크롤 관련 과제가 나온다면 react-query와 같이 사용해보려고 한다.

📍 변수

자바스크립트에서 변수는 무엇일까?

변수(variable)은 하나의 값을 저장하기 위해 확보한 메모리 공간 자체 또는 그 메모리 공간을 식별하기 위해 붙인 이름이다.

const myNumber = 23
// 변수명(식별자): myNumber
// 해당 값의 위치(메모리 주소): 0012CCGWH80
// 변수 값(저장된 값): 23

자바스크립트는 매니지드 언어(managed language)이기 때문에 개발자가 직접 메모리르 제어하지 못한다. 따라서 개발자가 직접 메모리 주소를 통해 값을 저장하고 참조할 필요가 없고 변수를 통해 안전하게 값에 접근이 가능하다.

변수명(식별자)인 myNumber는 변수의 값이 아닌 메모리 주소를 기억하고 있다. 변수명을 사용하면, 자바스크립트 엔진이 변수명과 매핑된 메모리 주소를 통해 거기에 저장된 값(23)을 반환한다.

이처럼 변수에 값을 저장하는 것을 할당(assignment, 대입) 이라 하며 변수에 저장된 값을 읽어 들이는 것을 참조(reference) 라 한다. 그리고 변수명을 자바스크립트 엔진에 알리는 것을 선언(Declaration)이라 한다.

✏️ 변수 선언

변수 선언 방법으로는 var, let, const가 있으며, ES6에서 const와 let이 추가되었다.

자바스크립트에서 변수 선언은 선언 -> 초기화 단계를 거쳐 실행이 된다.

• 선언: 변수명을 등록하여 자바스크립트 엔진에 변수의 존재를 알린다.
• 초기화: 값을 저장하기 위한 메모리 공간을 확보하고 임시로 undefined을 할당해 초기화한다.

var kmj
console.log(kmj)

var 키워드를 이용한 변수 선언은 선언 단계와 초기화 단계가 동시에 진행되어, kmj에 암묵적으로 undefined를 할당해 초기화한다.

하지만 반대로, console을 먼저 찍어도 반환 값이 undefined로 나온다.

console.log(kmj) // output: undefined
var kmj

이러한 이유는 변수 선언이 런타임에서 되는것이 아니라, 그 이전 단계에서 먼저 실행이 되기 때문. 자바스크립트 엔진은 소스코드를 한줄씩 순서대로 실행하기 전에 변수선언을 포함한 모든 선언문(변수 선언, 함수 선언문)을 찾아내 먼저 실행한다. 즉 변수 선언이 어디에 있든 상관없이 다른 코드보다 먼저 실행되는 특징을 호이스팅(hoisting)이라고 한다.

📍 변수 할당 방법

변수에 값을 할당 할 때는 할당 연산자(=)을 사용.

var kmj // 변수선언
kmj = 'howdy-mj' //값의 할당
var kmj = 'howdy-mj' //변수 선언과 할당을 동시에

변수 선언과 할당은 하나로 단축 표현할 수 있지만, 두개의 실행 시점이 다르다. 변수 선언이 호이스팅되어 런타임 이전에 실행되지만, 값의 할당은 소스코드가 순차적으로 실행되는 런타임에 실행된다. *선언이 먼저!!, 값의 할당은 소스코드가 실행될때!! *

변수의 할당과 console을 실행하는 위치에 따라 반환되는 값이 다르다.

console.log(kmj) // output: undefined
var kmj = 'howdy-mj'
console.log(kmj) // output: howdy-mj
kmj = 'mj'
console.log(kmj) // output: mj

kmj라는 변수에 새로운 값 재할당도 가능. 재할당은 변수에 저장된 값을 다른 값으로 변경하는 것으로, 만약 변경할 수 없는 값이라면 이는 변수가 아니라 상수(constant)라 부른다.

📍 호이스팅

함수선언문, 함수표현문도 호이스팅이 될까? 된다.

// 1. 함수 선언문
// 함수 이름 생략 불가능
function add(x, y) {
  return x + y
}

// 2. 함수 표현식
// 함수 이름 생략 가능
var add = function(x, y) {
  return x + y
}
// 함수 이름 작성 시,
// var add = function plus(x, y) {
//   return x + y
// }

// 3. Function 생성자 함수
var add = new Function('x', 'y', 'return x+ y')

// 4. 화살표 함수
var add = (x, y) => x + y

위 함수 선언문과 함수 표현식의 호이스팅 결과는?

// 함수 참조
console.dir(add) // output: f add(x, y)
console.dir(sub) // output: undefined

// 함수 호출
console.log(add(2, 5)) // output: 7
console.log(sub(2, 5)) // output: Uncaught TypeError: sub is not a function

// 함수 선언문
function add(x, y) {
  return x + y
}

// 함수 표현식
var sub = function(x, y) {
  return x + y
}

함수 선언문은 위 변수들과 마찬가지로 런타임 이전에 자바스크립트 엔진에서 먼저 실행. 함수 자체를 호이스팅 시킬 수 있다. 함수 표현식은 위에서 봤던 변수 호이스팅과 같이 런타임 이전에 해당 값을 undefined로 초기화만 시키고, 런타임에서 해당 함수 표현식이 할당된다.

📍 스코프

스코프(scope)는 식별자(ex- 변수명, 함수명, 클래스명 등)의 유효범위를 뜻하며, 선언된 위치에 따라 유효 범위가 달라진다. 전역에 선언된 변수는 전역 스코프, 지역에 선언된 변수는 지역 스코프를 갖는다. 한 가지 주의할 점은 자바스크립트에서 모든 코드 블록(if, for, while, try/catch 등)이 지역 스코프를 만들며, 이러한 특성을 블록 레벨 스코프라 한다. 하지만 var 키워드로 선언된 변수는 오로지 함수의 코드 블록만을 지역스코프로 적용됨. 이를 함수 레벨 스코프라 한다.

var a = 1

if (true) {
  var a = 5
}

console.log(a) // output: 5

위 코드는 함수가 아닌 곳에서 var를 사용해 a를 선언했기 때문에 전역 변수로 취급. 기존에 있던 a가 중복선언되면서 console.log(a)이 값이 바뀌었다.

해당 예제는 코드가 짧아서 어디에서 문제가 일어난지 바로 알 수 있었지만, 큰 프로젝트 일 수록 어려울 것이다. 전역 변수로 인해 재할당이 발생하거나, 전역 스코프를 공유하기 때문에 어딘가에 같은 이름의 변수가 있다면 무슨 일이 일어날지 알 수 없다. 이러한 이유로 함수 코드 블록만을 지역 스코프로 인정하는 var 대신, 블록 레벨 스코프를 지원하는 let, const를 사용하는 것이 좋다.

⛳️ var, let, const의 차이

세가지의 차이점에 앞서 var에는 하자가 있다.

• 변수 선언문 이전에 변수를 참조하면 언제나 undefined.
• 변수 중복 선언이 가능.
• 함수 레벨 스코프로 인해 함수 외부에서 선언한 변수는 모드 전역 변수가 됨.

이러한 이유들로 ES6에 let과 const가 나오게 되었다.

1. 변수 중복 선언 불가

let

let은 변수 중복 선언이 불가능하지만, 재할당은 가능.

let name = 'kmj'
console.log(name) // output: kmj

let name = 'howdy' // output: Uncaught SyntaxError: Identifier 'name' has already been declared

name = 'howdy'
console.log(name) // output: howdy

const

const는 상수로 가장 큰 차이점은 선언과 초기화가 동시에 진행되어야 함.

const name; // output: Uncaught SyntaxError: Missing initializer in const declaration
const name = 'kmj'

const도 let과 같이 재선언 불가, 그리고 재할당도 불가. 재할당은 원시값은 불가능, 객체는 가능. const는 재할당을 금지할 뿐, '불변'을 의미하지는 않는다.

// 원시값의 재할당
const name = 'kmj'
name = 'howdy' // output: Uncaught TypeError: Assignment to constant variable.

// 객체의 재할당
const name = {
  eng: 'kmj',
}
name.eng = 'howdy'

console.log(name) // output: { eng: "howdy" }

2. 블록 레벨 스코프

let, const로 선언한 변수는 모두 코드 블록(함수, if, for, while, try/catch 등)을 지역 스코프로 인정하는 블록 레벨 스코프를 따른다. 위 var로 예를 들었던 코드를 let으로 바꾸면 아래와 같다.

let a = 1

if (true) {
  let a = 5
}

console.log(a) // output: 1

var로 선언했을땐 5가 나왔다. 하지만 let 같은 경우 if문 안에 있는 것은 지역 스코프를 가져 전역에서 console을 찍을 경우 전역에 있는 a가 출력 된다. const도 동일하다.

3. 호이스팅

let

let으로 선언한 변수는 선언 단계와 초기화 단계가 분리되어 진행됨. 런타임 이전에 자바스크립트 엔진에 의해 선언 단계가 실행 -> 초기화 단계가 실행되지 않았을때 접근하려고 하면 참조 에러가 뜸

console.log(name) // output: Uncaught ReferenceError: name is not defined

let name = 'kmj'

따라서 let 키워드로 선언한 변수는 스코프의 시작 지점부터 초기화 단계 시작 지점까지 변수를 참조할 수 없는 일시적 사각지대(Temporal Dead Zone: TDZ) 구간에 존재한다.

const

const는 선언과 초기화 단계가 동시에 진행.

console.log(name) // output: Uncaught ReferenceError: Cannot access 'name' before initialization

const name = 'kmj'

let 같은 경우 런타임 이전에 선언이 되어 자바스크립트 엔진에 이미 존재하지만 초기화가 되지 않았기 때문에 name is not defined가 뜸. 하지만 const로 선언한 경우, 선언과 초기화가 동시에 이루어져야 하지만 런타임 이전에는 실행될 수 없다. 따라서 초기화가 진행되지 않은 상태이기 때문에 cannot access 'name' before initialization 에러 문구가 뜬다.

⛳️ 정리

변수의 스코프는 최대한 좁게 만드는 것이 좋다. 그러므로 var 보다는 let과 const를 사용하며, 변경되지 않는 값이면 let보다 const를 사용하자!!

📍 async와 await

async란?

async 키워드의 사용법

async function f() {
  return 1;
}

function 앞에 async를 붙이면 해당 함수는 항상 promise를 반환한다. promise가 아닌 값을 반환하더라도 resolved promise로 값을 감싸 이행된 promise가 반환되도록 한다.

const f = async() => {
  return 1;
}
f().then(alert); //1

async만 사용할 경우 성공한 상태의 promise가 반환된다. (resolved promise)

conse f = async() {
  return Promise.resolve(1);
}
f().then(alert); // 1

async가 붙은 함수는 반드시 promise를 반환하고, promise가 아닌 것은 promise로 감싸 반환한다. 이 뿐아니라 async는 await 라는 키워드와 주로 같이 사용한다.

📍 await란?

let a = await promise;
// await는 async 함수 안에서만 사용 가능하다.

자바스크립트는 await를 만나면 promise가 처리될 때까지 기다린다. 결과는 그 이후 반환된다.

const f = async() => {

  let promise = new Promise((resolve, reject) => {
    setTimeout(() => resolve("완료!"), 1000)
  });

  let result = await promise; // 프라미스가 이행될 때까지 기다림 (*)

  alert(result); // "완료!"
}

f();

함수를 호출하고, 함수 본문이 실행되는 도중에(*)로 표시한 줄에서 실행이 잠시 '중단'되었다가 promise가 처리되면 실행이 재개된다. 이때 promise 객체의 result 값이 변수 result에 할당되며, 위 예시를 실행하면 1초 뒤에 '완료!'가 출력됩니다.

await는 말 그대로 promise가 처리될 때까지 함수 실행을 기다리게 만든다. promise가 처리되면 그 결과와 함께 실행이 재개됨.

promise가 처리되길 기다리는 동안에 자바스크립트 엔진은 다른일(다른 스크립트를 실행, 이벤트 처리 등)을 할 수 있게 때문에, CPU 리소스가 낭비되지 않는다.

📍 callback을 사용한 예시

function async(callback) {
  setTimeout(() => {
    callback("1초 후 실행");
  }, 1000);
}

async(function (msg) {
  console.log(msg);
});

async 함수는 첫번째 인자로 callback을 받고, callback이 실행될 때 첫 번째 인자를 console에 출력한다. callback이 실행되는 시점은 async 함수 안에 있는 setTimeout으로 인해서 1초 후에 실행이 된다. callback이 실행이 되면서 첫번째 인자로 '1초후 실행'이 들어가고, 콘솔에 '1초 후 실행'이 나타나게 된다.

이렇게 callback을 통해서 어떠한 비동기 로직이 끝났을 때 callback 함수를 실행시키므로써 비동기 작업이 완료 되었을 때 callback에서 작성한 어떠한 행동을 실행할 수 있게 된다.

📍 promise를 사용한 비동기 처리

promise 객체는 new 키워드와 함수를 인자로 받는 생성자를 통해서 생성할 수 있다. 여기서 인자로 받는 함수는 resolve와 reject라는 2개의 파라미터를 가진다.

function async(key) {
  return new Promise((resolve, reject) => {
    setTimeout(() => {
      if (key === true) resolve("waited 1 sec.");
      else reject(new Error("Error!"))
    }, 1000);
  })
}

async(true)
  .then((result) => { console.log(result); })
  .catch((error) => { console.log(error); });

promise를 사용하면 resolve는 성공했을 때, reject는 에러가 발생했을 때 첫번째 인자로 어떠한 값을 넘길 수 있다. resolvesms .then의 첫번째 인자로, reject는 .catch의 첫번째 인자로 들어간다.

async 함수에 true를 넣어 실행하면 1초 후, resolve의 "waited 1 sec"이 .then의 첫번째 인자로 전달되어 "waited 1 sec"이 콘솔에 찍히고, false를 넣어 실행하면 1초 후 reject의 new Error("Error!")가 .catch의 첫번째 인자로 전달되어 "Error: Error! at" 가 콘솔에 찍힌다.

📍 callback과 promise의 차이점

callback을 사용하면 비동기 로직의 결과값을 처리하기 위해서는 callback 안에서만 처리를 해야되고, 콜백 밖에서는 비동기에서 온 값을 알 수가 없습니다. 하지만 promise를 사용하면 비동기에서 온 값이 promise 객체에 저장되기 때문에 코드 작성이 용이해집니다.

function async(callback) {
  var result;

  setTimeout(() => {
    result = callback("결과값");
  },1000);

  return result;
}

var b = async((res) => {
  return res;
})

만약 async 함수에서 비동기가 끝난 후의 값을 가지고 싶어서 위처럼 코드를 썼다면, b를 1초 후, 100초 후에 찍어도 undefined만 나오게 된다.

var p = new Promise((res, rej) => {
    setTimeout(() => {
      res("a")
    }, 1000)

})

var result = p.then(res => {
  return res;
})

console.log(result) // Promise {<fulfilled>: "a"}

result.then(res => {
    console.log(res); // "a"
})

promise를 사용하게 되면 promise 객체에 비동기가 처리된 결과값이 저장됩니다. 콜백의 경우 매번 비동기를 실행해야지 그 값을 사용할 수 있지만 프로미스는 .then 메소드를 통해서 저장되어 있는 값을 원하는 때에 사용할 수 있습니다.

function async(result, callback) {
  setTimeout(() => {
    callback(result, function (result) {
      console.log(result);
    });
  }, 1000);
}

async(0, function (res, callback) {
  callback(res)
  async(res + 1, function (res, callback) {
    callback(res)
    async(res + 1, function (res, callback) {
      callback(res)
    });
  });
});

// 0
// 1
// 2

위처럼 비동기 로직의 결과를 다음 비동기로 전달해서 실행해야 할 때 callback은 깊어질수 있음 -> callback hell이 발생하며 가독성이 매우 안좋아질 수 있다.

function async(result) {
  return new Promise((resolve, reject) => {
    setTimeout(() => {
      console.log(result);
      resolve(result);
    }, 1000)
  });
}

async(0).then(res => {
  return async(res + 1);
}).then(res => {
  return async(res + 1);
})

// 0
// 1
// 2

프로미스를 사용할 경우 .then을 통해 코드의 깊이가 깊어지지 않고, 이해하기도 쉬워진다.

HTTP 프로토콜의 한계를 보안하기 위해 쿠키 또는 세션을 사용.

기본적으로 HTTP 프로토콜 환경은 비연결지향(connectionless), 무상태(stateless)한 특성을 가지기 때문에 요청만으로 서버는 클라이언트를 구별할 수 없다.

• 비연결성지향(connectionless)

  • HTTP는 먼저 클라이언트가 요청을 서버에 보내면, 서버는 클라이언트에게 요청에 맞는 응답을 보내고 TCP/IP 연결을 끊는 특성이다.
  • HTTP 1.1에서는 헤더에 keep-alive라는 값을 줘서 커넥션을 재활용한다.

• 무상태(stateless)

    - 연결을 끊는 순간 클라이언트와 서버의 통신이 끝나며 상태 정보를 유지하지 않는 특성이다.

1.** 쿠키(Cookie) **

• 클라이언트(브라우저)에 저장되는 키와 같이 들어있는 작은 파일이다.
• 클라이언트의 상태 정보를 로컬에 저장했다가 참조한다.
• ** 클라이언트에 300개까지 쿠키저장 가능, 하나의 **도메인당 20개의 값만 가질 수 있으며, 하나의 쿠키값은 4KB까지 저장이 가능하다.
• Response Header에 Set-Cookie 속성을 사용하면 클라이언트에 쿠키를 만들 수 있다.
• 쿠키는 사용자가 따로 요청하지 않아도 브라우저가 Request 시에 Request Header를 넣어서 자동으로 서버에 전송한다.

2.세션(Session)

• 사용자 정보를 파일 브라우저에 저장하는 쿠키와 달리 세션은 서버 측에서 관리한다.
• 서버에서 클라이언트를 구분하기 위해 세션 ID를 부여하며, 웹 브라우저가 서버에 접속해서 브라우저를 종료할 때까지 인증상태를 유지한다.
• 접속 시간에 제한을 두어 일정 시간 응답이 없다면 정보가 유지되지 않게 설정 가능하다.
• 데이터를 서버에 두기 때문에 쿠키보다 보안에 좋지만, 사용자가 많아질수록 서버 메모리를 많이 차지하게 된다.

2.1. 쿠키와 세션 간단 비교

• 데이터 저장위치; 쿠키는 클라이언트, 세션은 서버
• 보안; 저장위치 때문에 쿠키는 스니핑에 당할 우려가 있지만, 세션은 쿠키를 이용해 세션 아이디만 저장하고 서버에서 처리하기때문에 보안성은 쿠키<세션
• 라이프 사이클; 쿠키는 브라우저를 종료해도 만료기간이 남아있으면 존재, 세션은 브라우저 종료 시 만료기간에 상관없이 종료
• 속도; 쿠키>세션

3. 웹 스토리지(Web Storage)

• 클라이언트에 데이터를 저장할 수 있도록 HTML5부터 추가된 저장소
• 간단한 Key-Value 스토리지 형태
• 쿠키와 달리 자동 전송의 위험성이 없음
• 오리진(Origin)(도메인,프로토콜,포트) 단위로 접근이 제한되는 특성 덕분에 CSRF로 부터 안전
• 쿠키보다 큰 저쟝 용량 지원(모바일 2.5MB, 데스크탑 5~10MB)
• 서버가 HTTP 헤더를 통해 스토리지 객체를 조작할 수 없음(웹 스토리지 객체 조작은 JavaScript 내에서만 수행)
• 오직 문자형(string) 데이터 타입만 지원
• 로컬 스토리지(Local Storage)와 세션 스토리지(Session Storage)가 있으며, 같은 Storage 객체를 상속하기 때문에 메서드가 동일

3-1. 로컬스토리지(localStorage)

• 사용자가 데이터를 지우지 않는 이상, 브라우저나 OS를 종료해도 계속 브라우저에 남아있음(영구성)
• 단, 동일한 브라우저 일때만 해당(도메인이 같을 때만)
• 지속적으로 필요한 데이터를 저장(자동 로그인등)

3-2. 세션스토리지(sessionStorage)

• 데이터가 오리진 뿐만 아니라 브라우저 탭에도 종속되기 때문에, 윈도우나 브라우저 탭을 닫을 경우 제거
• 일시적으로 필요한 데이터 저장(일회성 로그인 정보, 입력폼 저장 등)

• 자신의 state가 변경 될 때
• 부모 컴포넌트가 리렌더링 될때
• 부모에서 전달받은 props가 변경될때

1. useMemo

useMemo는 바로 전 작성글에서 다룬 내용으로 Reack Hook의 한 종류이다. 컴포넌트내의 어떤 함수가 값을 리턴하는데 하나의 변화에도 값을 리턴하는데 많은 시간을 소요한다면 이 컴포넌트가 리렌더링 될 때마다 함수가 호출되면서 많은 시간을 소요하게 될 것이고, 그 함수가 return 되는 값이 자식 컴포넌트에도 props로 사용이 된다면, 그 자식 컴포넌트도 함수가 호출 될 때마다 새로운 값을 받아 리렌더링 된다.

 const average = useMemo(() => {
    console.log("calculate average. It takes long time !!");
    return users.reduce((acc, cur) => {
      return acc + cur.score / users.length;
    }, 0);
  }, [users]);

그럴때 사용 할 수 있는 것이 useMemo 사용법으로는

useMemo(() => {}, [deps])

useMemo는 종속 변수들이 변하지 않으면 함수를 굳이 다시 호출하지 않고 이전에 반환한 참조값을 재사용 한다. 즉, 함수 호출 시간도 세이브할 수 있고 같은 값을 props로 받는 하위 컴포넌트의 리렌더링도 방지할 수 있다.

2. useCallback

useCallback도 앞서 전 작성글에서 다뤘던 내용으로 useMemo와 비슷하면서 다른 차이점은 useMemo는 리턴되는 값을 memorize, useCallback은 함수를 memorize 하는데 사용된다.

3. 자식 컴포넌트의 prop로 객체를 넘길경우 변형하지 않고 넘겨주기

개발을 하다보면 props의 값으로 객체를 넘겨주는 경우가 많다. 이때 props로 전달하는 형태에 주의 하여야 한다.

// 생성자 함수
<Component prop={new Obj("x")} />
// 객체 리터럴
<Component prop={{property: "x"}} />

위와 같은 경우 생성된 객체가 props로 들어가므로 컴포넌트가 리렌더링 될 때마다 새로운 객체가 생성되어 자식 컴포넌트로 전달된다. props로 전달한 객체가 동일한 값이어도 새로 생성된 객체는 이전 객체와 다른 참조 주소를 가진 객체이기 때문에 자식 컴포넌트는 메모제이션이 되지 않는다.

안좋은예

// UserList.jsx  
function UserList() {
{...}

 const getResult = useCallback((score) => {
    if (score <= 70) {
      return { grade: "D" };
    } else if (score <= 80) {
      return { grade: "C" };
    } else if (score <= 90) {
      return { grade: "B" };
    } else {
      return { grade: "A" };
    }
  }, []);

return(
 <div>
 {users.map((user) => {
    return (
      <Item key={user.id} user={user} result={getResult(user.score)} />
        );
      })}
 </div> 

)
export default memo(UserList);


// Item.jsx  
function Item({ user, result }) {
  console.log("Item component render");

  return (
    <div className="item">
      <div>이름: {user.name}</div>
      <div>나이: {user.age}</div>
      <div>점수: {user.score}</div>
      <div>등급: {result.grade}</div>
    </div>
  );
}

export default Item;

좋은예

// UserList.jsx  
function UserList() {
{...}

return(
 <div>
 {users.map((user) => {
    return (
      <Item key={user.id} user={user} />
        );
      })}
 </div> 

)
export default memo(UserList);



// Item.jsx  

function Item({ user }) {
  console.log("Item component render");

  const getResult = useCallback((score) => {
    if (score <= 70) {
      return { grade: "D" };
    }
    if (score <= 80) {
      return { grade: "C" };
    }
    if (score <= 90) {
      return { grade: "B" };
    } else {
      return { grade: "A" };
    }
  }, []);

  const { grade } = getResult(user.score);

  return (
    <div className="item">
      <div>이름: {user.name}</div>
      <div>나이: {user.age}</div>
      <div>점수: {user.score}</div>
      <div>등급: {grade}</div>
    </div>
  );
}

export default memo(Item);

아직 완벽히 이해가 되지 않는 부분으로 참조한 블로그의 예시코드를 가져왔다.

이 부분은 다시 다뤄볼 예정이다.

4. 컴포넌트를 매핑할 때에는 Key값에 index 넣지 않기!

사람들이 많이 하는 실수 중에 하나가 바로 컴포넌트를 매핑할 때 key값에 index 값을 넣어준다. 리액트에서 매핍을 할떄 반드시 고유 key를 부여하도록 강제하고 있는데, 이렇게 index값으로 key값을 부여하면 좋지 않다. 왜냐하면, 어떤 배열에 중간에 어떤 요소가 삽입될때 그 중간 이후에 위치한 요소들은 전부 index가 변경된다.

ex)

{items.map((el,index) => {
<Component key={index}
   }  

이런 상황에선 items라는 배열에 값이 추가되거나 수정이될때마다 index가 변경이되어 이로 인해 key값이 변경되어 React는 key가 동일 할 경우, 동일한 DOM Element를 보여주기 때문에 예상치 못한 문제가 발생합니다. 또한, 데이터가 key와 매치가 안되어 서로 꼬이는 부작용도 발생한다.

그럼 index 는 key로 아예 사용하면 안될까?

배열의 요소 가 필터링, 삭제, 추가 등이 들어간다면 문제가 생길 수 있으나 다음과 같은 경우에서는 index로 사용해도 무방하다.(그래도 사용안하는걸 권장)

• 배열과 각 요소가 수정, 삭제, 추가 등의 기능이 없는 단순 렌더링만 담당하는 경우
• id로 쓸만한 unique 값이 정말 없을경우
• 정렬 혹은 필터 요소가 없어야 함

5. useState의 함수형 업데이트

기존 useState를 사용하며, 대부분 setState시에 새로운 상태를 파라미터로 넣어주었다. setState를 사용할 때 새로운 상태를 파라미터로 넣는대신에 상대 업데이트를 어떻게 할지 정의해주는 함수를 넣을수도 있다.

이렇게 하면 useCallback을 사용할 때 두번째 파라미터로 넣는 배열에 값을 넣어주지 않아도 된다.

// 예시) 함수형 업데이트 
const onRemove = useCallback(id => {
  setTodos(todos => todos.filter(todo => todo.id !== id));
}, []);

다른 최적화 방법도 여러가지가 더 있겠지만 일단은 내가 이해할 수 있는 내용을 정리하여봤다.

https://velog.io/@shin6403/React-%EB%A0%8C%EB%8D%94%EB%A7%81-%EC%84%B1%EB%8A%A5-%EC%B5%9C%EC%A0%81%ED%99%94%ED%95%98%EB%8A%94-7%EA%B0%80%EC%A7%80-%EB%B0%A9%EB%B2%95-Hooks-%EA%B8%B0%EC%A4%80

useMemo 함수에 대해서 알아보기 전에 알고리즘 시간에 자주 나오는 메모이제이션(memoization) 개념에 대해서 짚어보면 memoization이란 기존에 수행한** 연산의 결과값을 어딘가에 저장!** 동일한 입력이 들어오면 재활용하는 프로그래밍 기법을 뜻함.

memoization을 적절히 적용하면 중복 연산을 피할 수 있기 때문에 메모리를 좀 더 쓰더라도 앱의 성능을 최적화 시킬 수 있다.

1. useMemo

ex) 사용법

useMemo(()=> fn, deps)

const [ex, setEx] = useState(0);
  const [why, setWhy] = useState(0);

  // useMemo 사용하기
  useMemo(() => {console.log(ex)}, [ex]);

  return (
    <>
      <button onClick={() => setEx((prev) => (prev + 1))}>X</button>
    </>
  );

이 예시의 useMemo는

useMemo(() => {console.log(ex)}, [ex]);

에서 deps는 [ex] 이다. ex가 변할 때에만 ()=> {console.log(ex)}이 실행된다. 다른 변경 사항이 있더라도 ex 값이 변하지 않으면 useMemo에는 아무런 변화가 없다.

2. useCallback

useMemo와의 차이점은 useMemo는 예전시점의 값을 반환, useCallback은 함수를 반환!

ex) 사용법

useCallback(fn, deps)

useCallback은 deps가 변한다면, fn 이라는 새로운 함수를 반환한다.

// useCallback 이 () => {console.log(why)} 라는 함수를 반환한다.
  const useCallbackReturn = useCallback(() => {console.log(why)}, [ex]);

  // useCallback 이 담겨있는 함수를 실행
  useCallbackReturn()

  return (
    <>
      <button onClick={() => setEx((curr) => (curr + 1))}>X</button>
      <button onClick={() => setWhy((curr2) => (curr2 + 1))}>Y</button>
    </>
  );

위 useMemo와 비슷한 예시코드로 useCallback은 ()=> {console.lo(why)} 라는 함수를 반환해준다.

실행의 순서는

1. 처음 컴포넌트가 시작될때 실행 ()=> console.log(0)
2. ex가 변할때까지 함수는 ()=> console.log(0)
3. ex가 변한다면 그제서야 why의 값을 가져와서 ()=> console.log(new)

중요한 점은 why값이 바뀌어도 실행x, deps인 ex 라는 변수가 변해야 그때서야 함수 컴포넌트와 상태값(why)를 공유

3. useCallback의 새로고침

useCallback 은 deps 가 변하면서 함수를 반환할 때, 형태가 같더라도 아예 새로운 함수를 반환한다

const add1 = () => {};
const add2 = () => {};

두 함수는 다르다.

각 변수는 같은 함수를 바라볼뿐 전혀 다른 변수! 바라보는 값만 같을뿐, 전혀 다른 메모리를 가진 변수이다.

useCallback은 새로운 함수를 반환한다.

const useCallbackReturn = useCallback(() => {}, [ex])

ex가 변할때, useCallback은 새로운 함수를 반환 ex == 0일때와 ex == 1 일 때의 ()=>{} 함수는 다른 함수 새로운 무기명 함수를 반환했기 때문이고, 값이 같을 뿐 다른 메모리이다.

https://basemenks.tistory.com/238

인간은 망각의 동물이니까!!

⭐️ 리엑트에서 JSX 문법이 어떻게 사용되나?

⛳️ JSX란?

• 자바스크립트의 확장 문법
• 브라우저에서 실행하기 전에 코드가 번들링되는 과정에서 바벨을 사용하여 자바스크립트 형태의 코드로 변환됨.
• JSX는 자바스크립트의 공식적인 문법이 아님.
• 자바스크립트에서 HTML을 작성하듯이 비슷하게 작성할 수 있도록 해주는 것이 JSX의 가장 큰 장점이자 이유.

JSX 문법의 특징

• 컴포넌트에 두개 이상의 요소가 있다면 부모 요소 하나가 감싸야함

  function App(){
  return(
        <div>
            <h1>테스트1</h1>
            <h2>테스트2</h2>
        </div>
    )
  }

감싸는 이유는 ?

리액트가 사용하는 Virtual DOM(가상돔) 방식에서는 컴포넌트 변화를 감지할 때 효율적으로 비교하고자 컴포넌트 내부는 하나의 DOM 트리 구조로 이루어져야 한다는 규칙!

JSX안에서 자바스크립트 값을 사용할때

name의 값을 {name}과 같이 넣어서 렌더링 할 수 있다.

import Reactfrom 'react';

function App() {
const name= '리액트';
return (
    <>
        <h1>{name}</h1>
        <h2>test</h2>
    </>
  );
}

exportdefault App;

• JSX 내부에서 if문은 사용 불가능, 필요시엔 삼항 연산자를 사용.

⭐️ props와 state의 차이

⛳️ state

state는 컴포넌트 상태를 나타내며, props와 반대로 변할수 있다. 컴포넌트의 내부에서 선언되기 때문에 이러한 state는 외부에 공개하지 않고 컴포넌트가 스스로 관리한다.! state로 사용하는 것은 컴포넌트의 상태값을 나타내기 위한 것들이 될 것이다. ex) (리스트에서 선택된값 또는 체크박스에서 체크된값 등)

• 상태에 따라 변화하는것
• 직접 변경가능
• 내부에서 생성하고 활동, 데이터를 변경할 수 있다.

⛳️ props

먼저 props('properties'의 줄임말)로 state 와의 간단한 차이는 변할수 없다는 것. 컴포넌트는 상속하는 부모 컴포넌트로 부터 props를 받고 이 props는 상속받는 컴포넌트 내에서 수정이 불가능하다. 리엑트에서 부모> 자식 일방향성 상속이라는 특징때문이다.

• 읽기전용
• 설정은 부모요소에서
• 외부(부모 컴포넌트)에서 상속받는 데이터이며 데이터 변경이 불가능하다.

💡 클래스형 컴포넌트란?

react에서 컴포넌트를 선언하는 방법은 두가지가 있다. (클래스형, 함수형) 현재 점점 더 사용안하는 추세이나 과거 프로젝트 유지보수시 사용 가능성 있음.

• 클래스형 컴포넌트의 핵심

1. class라는 키워드가 들어가며 Component로 상속을 받아야함.
2. render() 메소드가 반드시 있어야함.

ex)

import React,{Component} from 'react';

class App extends Component {
   render() {
     const name = "react";
     return <div className="react">{name}</div>
   }
}

export default App;

⛳️ 함수형 컴포넌트와 클래스형 컴포넌트의 차이점

클래스형:

• state, lifeCycle 관련 기능사용이 가능하다.
• 메모리 자원을 함수형 컴포넌트보다 조금 더 사용한다.
• 임의 메서드를 정의할 수 있다.

함수형:

• state, lifeCycle 관련 기능 사용이 불가능. [Hook]
• 메모리 자원을 클래스형보다 덜 사용.
• 컴포넌트 선언이 좀 더 편함.

state 사용시에도 차이점이 있다.

클래스형 컴포넌트

• constructor 안에서 this.state 초기값 설정 가능

  constructor(props) {
   super(props);
  
   this.state  = {
     monsters: [],
     userInput: "",
   };
  }

• constructor 없이 바로 state 초기값을 설정할 수 있다.

class Monsters extendes Component {
   state = {
     monsters: [],
     userInput: "",
   }
}

• 클래스형 컴포넌트에서 state는 객체 형식!

this.state = { monsters: [], userInput: "", };

state값을 변경하려면 setState 함수 사용!

onClick = {() => {
   this.setState({number: number * 1});
}}

함수형:

• 함수형 컴포넌트에서 useState 함수로 state 사용.
• useState 함수를 호출하면 배열이 반환되는데 첫 번째 원소는 현재 상태를 나타낸다.
• 두번째 원소는 상태를 바꿔주는 함수!

const [message, setMessage] = useState('');

출처:

https://koras02.tistory.com/177

[Koras02코딩웹:티스토리]

Virtual DOM 이란?

실제 DOM에 접근하여 조작하는게 아닌, 추상화한 자바스크립트 객체를 구성하여 사용

실제 DOM의 가벼운 사본!

가상 DOM은 DOM의 상태를 메모리 위에 올려두고, DOM에 변경이 있을 경우 해당 변경된 내용만

반영함.

변경 전과 변경 후의 상태를 비교한 뒤 최소한의 내용만 반영하니 성능 향상

리액트가 Virtual Dom을 반영하는 절차

ex) 특정 부분에서 데이터가 변했다고 가정.

• 리액트를 이용해 돔을 업데이트 시키는 절차

1. 데이터가 업데이트 되면, 전체 UI를 Virtual DOM에 리렌더링함.
2. 이전 Virtual DOM에 있던 내용과 현재의 내용을 비교함(가상 돔끼리 비교)
3. 바뀐 부분만 실제 DOM에 적용됨.

출처: https://dev-cini.tistory.com/11

📌 Why React?

정적인 페이지는 웹 서버에 이미 저장되어 있는 HTML 문서를 클라이언트에게 전달하여 받은 페이지로. 단순한 소개 페이지 같은 경우는 유저의 인터렉션은 중요하지 않기에 HTML과 CSS만으로도 구현이 가능했다.

하지만 동적 페이지는 유저의 행동과 흐름에 따라 페이지 구성을 달리해야함.

정적페이지는 이미 저장 되어 있는 HTML 문서만 받으면 되지만 동적 페이지는 유저의 요청 정보를 처리한 후 제작된 HTML 문서를 전달받게 됨.

동적 페이지들의 규모가 커지면서 유저의 인터렉션이 전달되면 그만큼 DOM요소들이 변화를 가져야 하고 이러한 과정이 반복되면 브라우저는 많은 연산이 필요하게 된다.

React의 장점

• 가상 돔(Virtual DOM)의 존재
• React Native의 앱 개발 기능
• 수 많은 커뮤니티
• Component를 사용하여 재사용이 가능하고 유지보수의 용이함

1. Virtual DOM의 존재

   리액트의 가장 큰 특징 중 하나로 React에서 컴포넌트 단위의 개발이 가능하게 됨.

2. 수많은 커뮤니티

   Vue에 비해 사용자가 많고, facebook에서 만들어 계속되는 업데이트와 자료가 굉장히 방대함.

3. component 단위 작성

컴포넌트는 UI를 구성하는 개별적인 뷰 단위로 서로서, UI 개발을 레고라고 한다면, 컴포넌트는 블록 역할을 하게 됨. 이러한 블록을 조립해 하나의 완성품을 만듬.

컴포넌트를 나눌수 있기에 다른 부분, 다른 웹에서 재사용이 가능, 이는 생산성과 유지 보수를 용이하게 해준다.

📍 위코드에 들어가기 전 마음가짐과 개발자로서 시작의 단계에서 느낀 점들

개발을 시작하계 된 계기로는 지금까지 내가 해왔던 직무들을 통하여 사람들과의 커뮤니케이션에 자신이 있었고, 틀에 맞춘 업무가 아닌 개발자 한명, 한명의 아이디어와 생각이 담겨 같은 것을 만들더라도 전혀 다른 결과물들이 나올수 있다는것에 많은 매력을 느꼈었다.

위코드에 들어오기전에는 간단하게 HTML, CSS, JavaScript를 혼자 공부하였었고, 혼자 공부하는것에 어려움을 느낄때 학원, 부트캠프 등을 알아보았고 그 중 위코드를 선택하게 되었다. 위코드의 커리큘럼과 동기들을 통해 에너지를 얻고 싶은 마음이 제일 컸었고 위코드를 시작하며 다짐했던 나 자신과의 약속들이 있었다.

• 주도적으로 공부하기
• 칼퇴근 X!

결국 개발은 암기로는 해결될 것이 없다고 생각한다. 매번 수많은 에러와, 블락커에 마주치게 되는데 매번 암기한 내용으로는 해결 할 수 없다고 생각한다. 최대한 이해하며 익숙해져야 내 상황에 맞게 활용이 가능하다고 생각한다. 그래서 암기가 아닌 주도적으로 공부하는 습관들이려고 하였다.

두번째로는 절대적인 시간투자를 하려고 하였다. 당장 해야하는 공부량 뿐만 아니라 개발자에게 가장 중요한건 꾸준함이라고 생각하였다. 빠르게 바뀌는 기술들과 더욱더 많은 기술뿐만 아니라 UI,UX 등에도 관심이 많아 빠르게는 못하더라도 꾸준한 시간투자를 통하여 주도적이면서도 단단한 개발자가 되고 싶었다.

📍동기들과 함께하며 기를 수 있었던 협업과 소통 역량

위코드에서 진행되었던 두번의 프로젝트를 통해 개발자에게 중요한 커뮤니케이션에 대해 좀 더 깊게 생각 할 수 있는 시간이 되었다. 첫번째 프로젝트에선 백엔드와의 소통 부재로 데이터를 못 맞춰본 경험이 있었다. 이를 바탕으로 두번째 프로젝트에선 기획단계부터 데이터 키 값등을 미리 설정을 해두었으며 백엔드와 프론트간에 daily standing meeting을 통하여 진행상황 및 특이사항을 공유하며 진행을 하였었다. 키값 및 엔드포인트 등을 꾸준하게 맞춰놓은 결과 통신테스트도 한번에 성공하며 큰 문제 없이 프로젝트가 진행되었었다. 항상 팀단위로 일하는 개발자에게 디테일한 소통은 필수요소라고 생각하게 된 계기였다.

📍 12주 기간동안 위코드에서 훈련 받고 배울 수 있었던 것들

위코드에서 배울 수 있던 점중에 가장 큰 두가지는 소통과 에러, 블락커 등을 해결할 수 있는 능력이라고 생각한다.

• 커뮤니케이션

백엔드와 프론테엔드가 팀을 이뤄 진행한 두번의 프로젝트를 진행하며, sprint meeting과 daily standing meeting을 진행하며 소통의 중요성 뿐만 아니라 소통이 필요한 이유까지 확실하게 느낄 수 있었다.

• 에러, 블락커를 해결할 수 있는 능력

개발을 하며 하루에도 몇번씩 에러, 블락커를 만나지만 몇달전의 나한테는 에러한번이 매우 큰 스트레스이자 위기였다. 하지만 암기가 아닌 이해를 통하여 에러가 생겼을 때도 최대한 이해한 내용을 바탕으로 극복을 했다고 생각한다. 그리고 검색 능력이라는 말을 개발 공부를 하기전에는 알지 못했었다. 검색이면 검색이지 능력이 어딨어? 라고 생각을 했었으나, 매일 에러를 맞이하며 같은 문제더라도 현재 상황을 정확하게 파악하고 구글링을 하는것과 그렇지 않을때의 차이점을 명확하게 알게 되었다. 개발자에겐 소통과 함께 중요한 항목이라고 생각이 되며 앞으로도 주도적인 개발을 통하여 나에게 일어난 상황을 정확하게 파악하는것에 중점을 둘 계획이다.

📍 앞으로 개발자로서의 계획

프론트엔드 개발자로써의 앞으로의 계획은 UI / UX에도 많은 관심이 있는것 만큼 주말을 이용하여 1~2시간씩 진행할 계획이다. 또한 CS 기초지식과 알고리즘도 병행하여 어떤 분야에서도 바로 적응할 수 있는 단단한 개발자가 되고 싶다.

시니어 개발자와 주니어 개발자의 가장 큰 차이점은 내가 뭘 몰라도 되고 알아야 하는지 이해하는 것"이라는 글을 보았다. 현재의 나는 욕심만 앞서 깊이 있는 공부를 하지 못한 것을 돌이켜 보게 되었고 많은 분야의 공부도 중요하지만 하나를 하더라도 확실히 알고 넘어가는 깊이 있는 개발자가 될 것이다.

기술 진보가 사회적 불평등, 소득 격차에 미치는 영향이 크다.

기술진보가 소득 격차에 미치는 영향이 세계화나 제도 등 다른 요인에 비해 크다는 IMF 분석을 보더라도 기술 진보와 격차 문제에 관심을 기울이지 않을 수 없게 된다. 사실 기술 진보는 인류의 삶을 좀 더 안락하고 풍요롭게 하는 장점이 있다. 생산성 향상을 통해 경제 성장에 도움을 주기 때문이다. 하지만 이 말은 기술 진보에 따라 피해를 보는 사람이 생겨날 수 있는 것도 엄연한 사실이다. 고속도로를 이용할 때 하이패스 사용이 늘며 도로공사 직원이 줄어들게 되거나 은행에 자동현금인출기가 도입돼 일자리를 잃는 은행원이 생기는 경우가 단적인 예다.

디지털 기술은 격차의 엔진

미국 MIT대 에릭 브린욜프슨 교수ㄴ와 엔드루 맥아피 교수는 '디지털 기술은 풍요의 엔진이면서 격차의 엔진이다'라는 주장을 폈다. 디지털 기술 시대에는 기술과 자본 면에서 우월한 위치에 있는 소수에게 부가 몰리게 되어 소득 격차가 더욱 벌어진다는 것이다. 소득 불평등 문제의 권위자이자 2015년 노벨경제학상을 받은 미국 프린스턴대 앵거스 디턴 교수는 지난 30년 동안 이룩해 온 기술 진보는 숙련도가 높은 사람에게 유리하게 작용한 까닭에 소득 격차가 커졋따고 지적했다. IMF 보고서에서도 같은 진단을 내놓고 있다. 기술 진보는 오히려 불평등을 키우는 측면이 있는 만큼, 이제 인류는 새로운 결단이 필요하다는 얘기이다.

정부는 시장 실패 보완해야

기술 진보는 명실공히 사람의 삶의 질 개선과 포용적 성장의 실천 수단이 되도록 해야 할 시 점에 왔다. 기술 진보의 혜택이 보다 많은 사람에게 돌아갈 수 있도록 진지하게 고민하고 전체적으로 대응할 필요가 있다. 무엇보다 기술의 사각지대, 사회적 약자와 함께하는 이른바 "포용적 기술 진보"를 추구하는 일이 급선무다. 기술 진보로 인해 실업에 처하는 등 불가피하게 취약해지는 경우에 대하여는 구가가 재교육 프로그램을 포함한 각종 사회안전망을 치밀하게 준비하여 시행해 나가야 할 것이다.

2016년 8월 백악관 국가안전보장회의와 국립표준기술연구소를 통해 양자내성 암호체계를 만들기 위한 공고문을 전 세계 수학계와 암호학계에 내보내는 작업을 시작했다. 그리고 올해 5월 조 바이든 미국 대통령은 직접 '양자컴퓨터를 막을수 있는 국방 암호체계를 만들라'는 지시를 내렸고, 두달 뒤인 7월 6일 NIST는 양자컴퓨터 공격을 막아낼 수 있는 암호체계로 4가지 기준을 선정했다. 그리고 그중 2가지가 프랑스 출신 컴퓨터 과학자 다미앵 스텔레 교수가 이끄는 팀에서 제안됐다고 한다.

양자내성을 지닌 암호가 나오게된 이유는??

현재 사용되고 있는 인터넷, 애플리케이션, 모바일뱅킹, 디지털 서명 등을 지키고 있는 암호체계(RSA,ECC 등)는 모두 1970~1980년대에 고안된 것들이다. 기존 컴퓨터가 도저히 풀기 어려운 문제를 제시해서 오로지 그에 대한 해답을 가진 사람만 핵심 데이터에 접근할 수 있도록 만든 것이 바로 이들 암호체계이나, 문제는 과거에 만들어졌기 때문에 현대 '양자컴퓨터' 앞에서는 속수무책으로 뚫린다는 큰 문제점이 있다.

아직까지 국방, 항공, 우주, 에너지를 비롯한 국가적으로 민감한 산업들을 보호하고 있는 암호체계들은 양자컴퓨터가 도입될 경우 쉽게 뚫릴 수 있다. 유럽의 항공기 제작사 '에어버스'가 양자 내성 전자서명에 큰 관심을 보이고 있고 그뿐만 아니라 이들 모두 당장 눈앞에 열리는 양자내성 암호체계에 대한 사업 기회만을 노린게 아닌 판을 바꿔버릴 근본적인 수학적 방식에 대한 연구를 지원하고 있다고 한다.