리액트 입문자의 고군분투기

항해 99 3주차의 회고

1. 어째서 리액트일까?

아이유의 '분홍신'의 첫 구절 가사는 "길을 잃었다~" 이다.
이 노래 가사에 한번 빠지고 나면 계속 되뇌일수 밖에 없는데, 이번주가 딱 그지경이었다.

코딩의 코자도 모르던 코린이는 웹개발 종합반을 두번듣고 항해 부트캠프에 참여하게 되었다. 첫주는 나와 차이가 많이 나는 능력자들을 따라가느라 코드 리딩하기 바빴고, 둘째주는 다시 수능치는 기분이었던 알고리즘 문제를 만나 머리를 쥐어 뜯으며 고민해야했다.

셋째주에 드디에 주특기로 꼽은 리액트가 시작되었는데, 사실 주특기를 고를때도 다른 이유는 없었다. 눈으로 보고 코드를 써야 훨씬 더 열심히 할 것 같아서였다. 지난번 회고에도 썼지만, 이제 겨우 HTML과 안면을 튼 사이였는데, 리액트는 조금 다른 모습으로 다가왔다. 자바스크립트 언어를 기반으로 하고 있는데, 알고리즘을 풀때 자바스크립트 언어를 사용했고, HTML작성하면서 접했던 언어라 낯설지는 않았으나, 리액트 라이브러리가 요구하는 형식이 조금 낯설었던 것이다.

다들 처음 리액트를 배울 때에는 TodoList라는 것을 만드나보다. 이게 초심자가 하기에 난이도가 쉽고 기본적인 기능을 배우기 때문이어서 그런가보다. HTML로 만들라고 해도 사실은 더듬더듬거릴테다. 이제는 그때 들었던 내용이 아득해질 만큼 정말 많은양의 정보들이 쏟아지고 있어서 vs code를 딱 켜면 막연함이 밀려온다. ajax를 써서 post get 방식으로 서버와 소통하던 방식도 익숙하진 않았는데, 그걸로 투두리스트를 만든다고 하면, 어떻게 해야할지 감이 안온다.

이제 터미널로 폴더 만들어서 리액트 화면 켜는건 알겠다.
그것만 젤 자신에 차서 하게 된다는게 함정 ㅋㅋㅋ

어쨌거나 이제는 리액트다. 간단한 기능정도 들어있는 웹페이지는 HTML로도 충분하겠지만, 점점 더 방대한 양의 정보를 다루고 여러 기능을 복합해서 사용하는 웹페이지를 꾸민다고 하면, 기존 방식으로는 해결되지 않으니 이런게 나오지 않았을까. 게다가 HTML로 구현한 웹페이지의 경우에는 필연적으로 데이터베이스를 사용해서 데이터를 주고 받고 통신해야 작동을 했고, 그걸 또 배포까지 하려면 AWS를 써야 했는데 그러기에는 과제로 만드는 페이지들이 너무도 단조로운 기능들이라... ㅎ
그마저도 잘 하지 못하는 입장에서는 이렇게 이야기 하면 안되는 것이지만, 비용 측면에서는 잘 못하니까 더더욱 유지비가 없는 쪽이 한결 마음이 편하다는 점...

그점에서 일단 배포는 간결하게 됐던것 같다. 배포가 문제가 아니었던게... 문제였지만.

왜 리액트를 배우는가에 대해서 의문점을 가져본 적은 없다. 프론트엔드에 종사하고 있는 분들이 많이 사용하고 있는 라이브러리라고 하면 취준생의 입장에서는 일단 배워야 되는 것으로 인지하게 되니까.
그렇지만, 컴포넌트를 이렇게 나누고 이런 컴포넌트를 연결하는 과정을 익히면서 이 라이브러리가 어디까지 편리함을 주고 있는가에 대해 궁금해 질 수 밖에 없었다. 왜냐면 컴포넌트를 나누고 쪼개고 연결하는 일련의 과정들이 효율적이라는 생각이 들지 않는 정도의 페이지를 만들고 있었기 때문이다.
복잡하면 이게 편리하게 쓰이고 있다는게 느껴질텐데 코드 자체가 복잡한건 아닌데 되려 컴포넌트가 나뉘어지는게 더 복잡하게 느껴지는 코린이의 상태... ㅋㅋㅋ

나중에 이 첫 구상을 몇 번 뒤엎어야 했다... ㅎㅎ
알고 짜면 쉽겠지만, 아무것도 모르는 상태에서 컴포넌트를 구성한다는게 쉬운일은 아니었던거 같다. 사람마다 스타일이 다르다고 하는데, 그 스타일이 달라지기 전에 베이스는 깔려 있어야 그 위에 스타일을 쌓을 수 있지 않을까...

리액트 공식문서를 보면, 상호작용이 많은 UI를 만들때 생기는 어려움을 줄여준다고 한다. 각 상태에 대한 간단한 뷰만 설계를 하면, 데이터가 변경됨에 따라 적절한 컴포넌트만 효율적으로 갱신하고 렌더링을 한단다. 나는 이 효율적이라는 말에 조금 더 힘을 내 보기로 했다. 처음 배울때가 어렵지 배워두면 이 효율성을 자유롭게 관리할 수 있지 않을까.

2. 이론의 적용과 적응

이론을 배우면, 쉽게 적용해서 쓰는 사람이 있고, 낯설어하다가 적응해서 그제야 적용이 쉬워지는 사람이 있다.
나는 120% 후자인 사람이다. 게임도 첫판은 무조건 필패다. 어떻게 하는지를 충분히보고 그제서야 제대로 접근할 수 있는 사람이기때문이다. 그래서 인터넷상에서 하는 게임보다는 혼자 조용히 몇번이고 재도전을 해서 스테이지를 갱신해나가는 류의 게임을 좋아하는 사람이다.
내가 이해하고 있는게 맞는지 의심이 들고, 맞다는 확신이 들 때까지는 섣불리 나서지 못하는 소심한 성격이라서 그런 것일지도 모르겠다.

홀로 공부를 해나가는 과정에서 어려움은 바로 그 점 때문에 발생한다. 내가 본게 맞나? 내가 보고 있는게 정확한건가? 이걸 보면 되는건가? 이게 아니면 어떡하지? 등등 끊임없는 의심과 싸우며 공부를 해나가고 있고, 마치 알맹이가 빠진채 위태롭게 서있는 젠가처럼 언제 쓰러질지 모르는 얕은 지식의 탑에 불안해 한다.

"그렇지만, 어쩌겠습니까. 해내야죠. "

노트북에 붙여놓은 말이다. 그냥 해야지 어쩌겠는가. 달리 방법이 없다. 익숙해질때까지 보고 납득할때가 또보는 방법 밖에는 없다. 체력이 많이 소진된다는 점을 제외하고는 아직은 해볼만 한 상태이다.

예를 들어 어떤 개념에 대해 공부를 했다고 치면, 이것을 말로 설명할 수 있을때까지 파고들어야 하는데, 물리적 시간의 한계에 쫓겨서 두루뭉술하게 알고 넘어가버린다. 처음에는 그냥 넘겨도 문제가 없지만, 계속 반복해서 등장하는데 내가 알지 못하고 있는 상황이라면? 찝찝함을 견디다 못해 다시 원래대로 돌아간다.

홀로 공부하는 것에 가장 큰 단점이 바로 그것이다. 게다가 그 상태가 되면 어떤 것을 질문해야겠다는 구체적인 생각도 떠오르지가 않는다. 이미 의심으로 출발한 상태는 의심으로 작동이 될 수 밖에 없으니까. 내가 아는게 맞나? 내가 본게 맞나? 정도의 피상적인 질문 이외에 더 파고들 수가 없다. 여전히 출발점에 서있으므로 갈길만 남아 있을 뿐.

이런 고민때문에 아마 많은 사람들이 명강사의 명강의를 들으려고 하지 않나 하는 생각이 들었다. 초심자에게는 앞으로 나아가야할 원동력이 필요한데 스스로에게서 확신을 찾기 힘드니깐, 명강의에 의존 할 수 밖에... 그래서 뭐라도 더 찾아보고 확신 할 수 있는 근거를 찾아나가게 되는 것 같다. 이 과정이 몹시 힘들고 고통스럽지만, 익숙해지면 고통에는 무뎌지지 않을까 싶다. 개발자라면 응당 어떤 정보를 찾고 습득하는 것에 익숙해져야 한다고 한다. 찾다보면 보다 더 정확한 정보를 찾는 방식도 터득하게 될거니까 일단은 이렇게 나아가 보자.

3. 그래서 이번주에 한 일은?

이상하게도 아직까지 너무 힘들어서 고만해야겠다는 생각은 하지 않고 있다. 그만둘 생각이면 시작을 하지 않았을 것이다.
메모장에다가 손으로 쓸때도 있고, 타자를 칠때도 있고 어떻게든 습득을 하려고 애쓰는 중이다.

다양한 리액트 관련 개념을 보았다. 정말 말그대로 "본"상태이다.

데이터 바인딩 - 중괄호를 활용하여 데이터를 밀어넣는다는 개념
jsx문법 - className, 변수를 html에 꽂아넣기, Style을 쓰고 싶으면
변수를 선언하고 style = {{변수값}}을 해준다.

#props란 ?

props란 부모컴포넌트로부터 받아온 데이터.
컴포넌트간의 교류 구조를 살펴보면 항상 props로 값을 전달하고 있었다.

자식컴포넌트는 부모컴포넌트로 props를 전달할 수 없다.
변칙적인 방법은 존재하지만 기초단계에서는 이렇게 알아뒀다.

부모컴포넌트로 정보를 전달하는 children은 그 개념을 이해하려고 하기 보다는, 쓰는 양식과 잘 쓰이는 용도를 기억하기로 했다.
Layout에 각종 컴포넌트들을 넣어서 상위 컴포넌트에 전달하는데, 이때 Layout 컴포넌트 안에서는 {props. children}으로 처리만 해주면 되었다. 구조분해 할당을 사용하면 props.데이터명을 쓰지 않고 그냥 중괄호안에 데이터명만 써주면 된다.
defaultprops란 부모 컴포넌트에서 props를 보내주지 않아도 설정될 초기 값을 말한다.

#State란?

컴포넌트 내부에서 바뀔수 있는 값을 의미한다.
State를 만들기 위해서 useState()를 사용한다.

형식이 있는데, 그 형식을 잘 숙지해서 응용해보려고 했다.
리액트에만 존재하는 개념이자 기능이고, 기능 대신 훅(Hook)이라는 말을 사용한다.

useState 훅을 사용하는 방식은 아래와 같다.

const [value, setValue] = useState(초기값)

setValue는 바꾸고 싶은 값을 의미하는데,
state는 컴포넌트 안에서 변해갈수 있는 값이기 때문에 바꾸고 싶은 값이 있으면 양식에 알맞게 써서..

응용하느라 혼났다. 난 왜 안되지의 늪...

할아버지 컴포넌트에서 차일드 컴포넌트에 값을 보내고 싶다면,
마더컴포넌트를 경유하는 방식도 불편했다.

할아버지가 손자에게 용돈을 주기위해 반드시 엄마의 통장을 거쳐야 하는 불편한 상황이었달까...

나중에 이 방식을 개선한 리덕스를 배운다고 하니...
일단은 배운만큼만이라도 제대로 소화를 하고 싶었다.

몇번의 컴포넌트 구조의 수정 이후,
여전한 난 왜 안되지의 늪.

형제 컴포넌트 간의 데이터 전송은 원활하지 않기 때문에 어떤 것이 상위이고 어떤것이 하위인지의 구분을 명확하게 하는게 중요했다.

#virtual DOM????

DOM의 개념이 아직 확 와닿진 않는다. 설명을 듣기로는 HTML, XML document와 상호작용하고 표현하는 API라고 하는데, API를 나는 여태껏 은행창구의 역할을 하는 것으로 알고 있었다. 이 두가지를 연결해서 생각해보면, 웹페이지에 대한 인터페이스 즉 어떤 경계같은 느낌인데, HTML과 상호작용을 하기 위한 창구역할을 하는게 DOM이라고 이해를 하면 되려나?

지금껏 써왔던 HTML의 트리형식의 구조를 떠올려 보면, 화면에 보여지는 것, 보여지지 않는 것들을 구분짓고, 페이지 콘텐츠의 구조를 짜고, 스타일을 지정해 주면서 HTML의 문서를 웹상에서 구현할 수 있는 이런 방식을 DOM이라고 하는 건가..
DOM은 browser에서 로드되며, 노드트리로 표현하는 document코드다. 이렇게 정리가 되면 될것 같다.

모호한 상태에서 virtual DOM이라는 개념을 듣게 되었다. 리액트에서는 필연적인 개념이다.
virtualDOM은 HTML 문서를 객체화 시켜서 트리형태로 만든것이다.
한 덩어리의 문서가 객체화 되어 여러 개의 객체들이 트리형태를 이루며 작동되는 방식을 이야기 하는것 같은데, 이벤트 리스너 같은 것들이 DOM API라고 하면 어렴풋이 알겠다는 느낌이다.
virtualDOM은 DOM을 직접 조작하지 않고 변경사항을 하나의 가상 돔에 모았다가 DOM에 한번에 보내는 기술을 말한다.
DOM 조작의 연산비용을 줄일수 있는 방법으로 나온 대안이 virtualDOM이라고 한다. 이 virtualDOM의 개념을 적용한게 바로 리액트 이다.

이것 외에도 개념적으로 적어야 할 것들이 꽤있는데, 미션으로 받은 서버리스는 일주일동안 공부했던 내용에서는 없어서 추가로 더 찾아보았다. 진도를 더 나갔어야 했나보다.

#서버리스
서버를 하나부터 열까지 만들 필요 없이, 서버기능을 제공하는 곳에서 우리가 필요한 기능들을 클릭 한번으로 구현할 수 있는 서비스를 말한다고 한다.

리액트의 경우 서버와 통신하는 시점이 나뉘는데 일정부분 서버관리를 해주어야 백엔드에 일일이 요청하지 않고 작업을 수행할수 있기 때문에 어느정도는 익혀둬야 하는 개념인듯 하다.