리액트 깨우치기-1. 시작하기 전에

태현·2021년 4월 1일

🙋🏻‍♂️ 이 페이지는 리액트를 공식사이트에서부터 차근차근 시작하여 전체적인 흐름과, 생태계 전반을 충분히 이해하기 위해 요약하지 않고 길게 풀어서 작성되었습니다.

시작하기 전에...✍️

🙌 안녕하세요, 태현입니다. 자바스크립트 언어가 태어나게 된 계기는 여러가지가 있다고 합니다. 제가 확인하지 못한 부분도 한 두 가지는 더 있겠죠? 이번 포스팅에서는 좀 더 원시적으로 접근해서 내가 지금 이걸 왜 하는지? 이걸 쓰면 비즈니스와 관련해서 어떤 것들을 할 수 있는지 등을 기록으로 남겨볼까 합니다. 결국, 공부하는 거에요😅😅.. 사실 저는 이미 리액트를 인강을 통해서 공부했습니다. 하지만 무언가 '정리가 필요하다' 라는 생각을 했어요. 그래서 노션에 정리를 하고, 벨로그에 공유할 생각입니다. 기존에 구글이나 벨로그, 리액트 공식사이트 등 정리 정돈이 너무 잘 된 웹 페이지가 오히려 머리속에 들어오지 않으신다면, 제 페이지는 또 괜찮을 수 있을 것 같습니다. 그럼, 천천히 시작해 보겠습니다.

리액트를 알아보기 전에 자바스크립트를 다시 생각해봅시다

🙌 우리가 쓰는 JS는 클라이언트에서 쓰려고 생겨났다고 합니다. 여기서 말하는 웹 개발이면서 클라이언트라는 것은 브라우저를 말해요. 그런데, 브라우저에서 돌아가는 언어는 하나, JS밖에 없습니다. 따라서 많은 개발자들이 브라우저 밖에서도 JS를 사용하기 위한 도구로 node.js 가 생겼다고 합니다.

node.js란 무엇이고, 어떤 회사에서 사용될까?

node.js 는 브라우저 밖에서 JS를 실행시키기 위한 환경을 말합니다. 결국, node.js 와 JS를 이용하여 웹 서버를 개발할 수 있게 되는 것입니다. 우리가 잘 알고 있었던 Linkedin 이나 Walmart, Paypal 등 여러 곳에서 사용되고 있었어요.

그러나 node.js 에도 한계점이 있습니다. 하드웨어 성능을 남김없이 다 처리해야 하는 초대량 트래픽 처리용으로는 안 맞다 라는 것입니다. 이게 이제 기술 특성 때문입니다. 하지만 node.js 가 적합한 곳도 있어요. 오히려 일반적인 CRUD 중심의 RESTful API를 만들기에는 최적이라고 합니다. 여기서 CRUD란 무엇일까요,

출처: IT 컴퓨터 공학 자료실

CRUD

IT관계자분들은 흔히 소프트웨어를 만들때 "CRUD를 써서 한다." 라는 말을 많이 한다고 합니다. 결국 노드로 만든다는 겁니다.🙂 그래서 찾아보았습니다.

CRUD라는 것은 대부분의 컴퓨터 소프트웨어가 가지는 기본적인 데이터 처리 기능인데 생성, 읽기, 갱신, 삭제 를 그냥 묶어서 부른다고 합니다. UI가 갖추어야 할 기능들 이라고 간단히 기억해 놓으면 될 것 같습니다.

돌아와서, 결국 node.js 는 CRUD가 중심이기 때문에 기업 프로젝트에서 모니터링과 관리자용 웹 서비스를 만들고 관리도 할 수 있는 도구라는 것을 알 수 있습니다. 비록, 기술적인 단점이 있지만 장점이 명확하기 때문에 node.js 는 여전히 필수 플랫폼으로 인식되고 있었습니다.

node.js가 좋다면, 그걸로 내가 무엇을 할 수 있을까?

node.js 는 정확한 컨셉과 장점이 있습니다. 그래서 주로 사용하기 좋은 곳도 정해져 있다고 합니다.

적합한 경우

-프론트엔드 개발자가 백엔드 개발을 하려 할 때: 게시판, 모니터링, 안내 페이지 및 회원가입을 빠르게 개발하고 싶을 때

-스타트업 개발자 : 자기 혼자서 회사 서비스를 개발해야 할 때, RESTful API를 빠르게 개발하고 싶을 때

-오너 프로그래머가 되려는 사람 : 앱 개발을 시작하는 사람인데, 서버도 필요한 사람, 아주 작은 규모의 서비스지만 그냥 혼자 한 번 만들어보고 싶은 사람

그 밖에 특징

대기업(대규모) 서비스에는 적합하지 않다
백엔드 개발이 오랜만인 사람은 적합하다
초보지만 웹 개발을 해 본 사람도 적합하다

node.js와 npm, npx

지금까지 JS를 브라우저 밖에서 실행하기 위해서는 node.js가 필요했습니다. 그런데 node.js 를 설치하면 npm과 npx 가 자동적으로 설치된다고 해요. 우리가 터미널에서 CRA를 설치할 때는 왜 npx라는 명령어를 입력하는 것일까요?`그래서 한 번 찾아보았습니다.

출처: npx란 무엇이고, npm은 무엇일까? yarn은 무엇일까?

npx

결론적으로, npx 는 새로 나온 패키지 관리 모듈이 아니였습니다. 이걸 이해하려면 npm 를 알아야 하고, npm 의 역사를 알아야 합니다.

노드 패키지 관리 모듈인 npm 에서 추가적으로 나온 것이라고 해요. 정확히 말하면 5.2.0 버전에서 부터 나왔다고 하는데 아마 여러가지 어려움이 있었겠죠?

npx의 과거, 역사

과거에 npm으로 패키지를 설치할 때는 두 가지 방법이 있었는데요, 하나는 전역으로 패키지를 설치해서 관리하는 방법. 또 하나는 그 프로젝트에만 의존하는 의존성 라이브러리를 설치하는 방법이 있었어요.

이렇게 의존성 라이브러리들이 전역이나 로컬에 설치가 되서 관리가 되면 문제가 생긴다고 합니다. 패키지가 업데이트 된다면 어떻게 할 것인지? 그러면 패키지도 따로 업데이트해야하고... 로컬도 따로 업데이트하고... 굉장히 번거로웠다고 해요. 그래서 이런 어려움 때문에 npx 가 나왔다고 합니다.

CLI도구, npx

npx 는 npm 레지스트리 위에 올라가있는 패키지를 쉽게 설치하고 관리해주는 *CLI 도구 라고 합니다. 여기서 CLI 라는 것은 command line tool 이라고 해서 명령어 기반의 툴이라고 보면 됩니다. 그래서 npx 에서 제공하는 명령어를 가지고 npm 을 통해 설치하는 모든 종류의 node.js 기반의 파일들을 굉장히 간단하게 설치할 수 있게 도와주는 것입니다.

맥락정리

정리를 하면, npx는 npm 패키지를 굉장히 편하게 실행시키는 도구입니다.

npm과 npx에서 p는 패키지라고 해서 라이브러리인데 남이 만들어 놓은 소스코드라고 생각하면 됩니다. 우리가 프로그래밍을 하다보면 수학도 해야하고, 수학에서 통계도 해야하고 할 일이 굉장히 많습니다. 랜덤함수나, 최소값•최대값 구하기 등 굉장히 많습니다. 그런 걸 몰라도 그럴 거라고 어느정도는 예상을 할 수 있어요. 그래서 우리가 일을 할 때마다 일일히 다 정의할 수 없기 때문에 누군가가 미리 만들어 놓은 소스코드를 가져다가 쓰는 것입니다.

앞으로도 node, npm, npx 는 정말 많이 사용될 것 같습니다.

참고 : npx 공식 사이트

CRA하기전에 라이브러리를 알아봅시다

지금까지 node.js와 npm•npx 를 알아보았어요. 사실 바로 CRA로 넘어 갈 수 있지만 그 전에 라이브러리의 개념에서부터 알아보았고 이것을 공유하려고 합니다.

개발 말고도 다른 업종에서 일을 하게 되면, 그 세계에서 공통적으로 쓰이는 단어들의 차이점을 잘 이해해야 한다고 생각합니다. 특히 개발에서 너무나도 많이 쓰이는 용어이지만 혼동되기 쉬운 프레임워크와 라이브러리의 차이점이 다음 주제입니다

프레임워크와 라이브러리란 무엇이고 왜 쓸까?

먼저, 라이브러리라는 것은 프로그램을 만들 때 필요한 기능을 말합니다. 연장이나 망치, 삽, 자동차 바퀴, 에어백등을 말해요.

라이브러리라는 것이 JS에서 항상 반복되던 코드의 양을 줄이기 위해서 조금이라도 다시 쓰일 일이 있으면 컴포넌트 단위로 나눠버리는 것입니다.

결국, 일을 조금 더 생산적으로 하고 싶었기 때문이라고 생각해요. JS에서 유명한 라이브러리는 jQuery 인데, 이 jQuery 가 write less, do more 이라는 문구를 지니고 있습니다. 참고로 jQuery 공식 사이트에서 라이브러리라고 명시가 되어 있지요. UI에서 재사용 가능하고 버튼에 카드 같은 것들을 분리했다면 그게 라이브러리 입니다.

다음으로 프레임워크라는 것은 프로그램을 만들 때 뼈대를 구성합니다. 프레임워크도 라이브러리가 포함되어 있긴 하지만, 결국 프레임워크는 어떤 틀 안에서 작업을 수행하는 것입니다. 배를 타고 산을 올라갈 수 없듯이 어떤 정해진 규격 안에서 개발자가 일을 하는 것입니다. 그런데 그렇다고 해서 단점이 아닙니다. 저는 그냥 특징이라고 이해를 하고 있습니다.

그러면 두 가지의 차이점은 무엇일까요?

아키텍쳐?

프레임워크와 라이브러리는 겉으로 보기에는 비슷하지만 상호간에 아키텍쳐 가 다르다고 해요. 그래서 어떤 특정한 규칙을 따라야하는 차이가 있다고 합니다.

여기서, 아키텍쳐 라는 것은 기획한 것을 프로그램화하고 지술적으로 설계하고 나타낸 것을 말합니다. 그런데 결과물에 대한 설명을 하기는 하지만, 깊이 있게는 하지 않는다고 해요. 예를 들어서 자동차의 부품이 어떤 형태로 만들어졌는지 등은 명시를 하지만 그 안에 있는 볼트가 몇 개 들었는지, 접착제는 어떤 회사 제품을 사와서 썼는지 등은 명시되어 있지 않아요.

참고, 프레임워크의 예)

자바개발자 → 스프링,

파이썬개발자 → 장고,

자바스크립트개발자 → 앵귤러,

PHP개발자 → 라라벨

그렇다면 둘의 차이는 정말 무엇일까요?

만약, 프레임워크가 담당하는 부분이 내가 하고자 하는 목적과 다를 경우?

: 그냥 그 걸를 잘못 쓴 거라고 합니다. 적합한 프레임워크를 찾아서 쓰는 것이 중요하다고 해요.
프레임워크 없이 그냥 라이브러리로만 만들면 안될까?

: 시간이 많으면 그렇게 해도 된다고 합니다. 스스로 만든 라이브러리는 버그도 스스로 잡아야하지만 남들이 만들어 놓은 것은 그만큼 수정이나 업데이트가 빠르다고 해요.
만약에 기능이 마음에 안든다면?

: 프레임워크를 고치면 된다고 합니다. 우리가 처음부터 다 만드는 것보다 기회 비용이 발생하는 것을 염두해야 함.