드디어 3주간의 주특기 공부 기간이 되었다!!
새롭게 만난 우리 팀분들도 정말 좋다. 진득하게 못앉아있는 나와 달리 하루종일 그 자리에서 움직이지 않으시고 캠도 성실히 키고 계시는 분들이다. 서로 말도 이쁘게 하고 굳이 쓸데없는 잡담을 하지도 않으셨다! 몬가 공부하기에 셋이 합이 좋다.
일단 내가 선택한 리액트가, 내가 공부할 리액트가 뭔지 진짜 궁금했는데 드디어 궁금증이 풀렸다. 환경설정도 다 하고 기초부터 천천히 공부하니 드디어 개발 공부를 시작한 느낌이다. 여태까지 내가 개인적으로 했던 공부들은 정말 쓸모없었다는 것이 몸소 느껴졌고, 심지어 그 기간이 너무나 아까웠다. 다른 언어들 대충 깔짝대고 구글링으로 복붙할 시간에 리액트나 배워둘걸... 하는 생각
진짜 기초부터 시작하는 것이기 때문에 개념정리부터 하는 데 시간이 오래걸렸다. 개념을 정확히 짚고 넘어가야하는 성격이기도 하고, 정리에 강박을 느끼는 사람이라 프로젝트 구현에 시간을 쏟기보다 개념을 천천히 보는 것을 선택했다.
그래서 다른 팀원들은 빠르게 훑고 프로젝트에 들어가셨는데, 나는 조금 더 개념정리에 몰두하고 늦게 시작한 축에 속했다. 늦게 시작한 만큼 예시 사이트를 많이 참고하고 급하게 코드를 이해해서 과연 이게 내 실력이 된건지, 이해한 개념을 써먹은게 맞는지 혼란스럽고 확신이 들진 않았지만 시험은 그럭저럭 통과를 해서 대충 이해한건 맞구나... 했다.
근데 기술매니저님이 개념확인차, 코드 점검을 위해 내가 직접 코드를 쳐보는 시간이 있었는데... 거기서 멘붕이 왔다. 뭘 보지 않고는 내 힘으로 코드를 칠 수 없었다 ㅠㅠ 매니저님이 던지는 질문에도 대답이 잘 나오지 않고 이해가 느렸다. 기본 코드들을 겨우.. 쳐냈다. 프로젝트에서 복붙해서 구현한 긴 시험코드도 엄청나게 짧게 줄여주셨는데, 내가 완전히 이해를 못했다고 느낀 계기가 되어 엄청 찜찜해졌다..
하지만 진도 다빠지고 당장 다음주 진도가 나와서 이번주 진도를 완벽하게 짚고 넘어가기에는 시간이 부족했다. 팀원분들은 나를 진짜 잘하는 사람으로 알고 계신 것 같은데 전혀 아니라서 걱정이 크다 ㅋㅋㅋㅋㅋ 차차 연습하며 익숙해져갈 미래의 나야, 화이팅^^ 지금은 모르겠어.. 그냥 가보자😭
DOM에 대한 특강을 들었는데 솔직히 강의를 듣고 하나도 이해하지 못했다. 어떤 개념, 형체라고 느낌만 오는 정도..? 내가 이해한 것만 정리하자면 html이 아니라 html 문서가 브라우저에 의해 해석돼서 실제 문서를 나타내는 트리 형태?가 돔이다.
리액트에서는 실시간 업데이트, 상호작용이 정말 중요하기 때문에 프로그래밍 언어와 페이지가 상태가 바뀔때마다 동기화되기 위해 돔 개념은 필수다.
구조가 복잡해지거나 사용자의 인터렉션이 많아지면 그 횟수가 너무 많아지기 때문에 노드의 수정, 레이아웃 재계산, 리렌더링 등 과부하가 일어난다고 한다...
그래서 '가상 돔'이라는 것은 돔을 직접 조작하지 않고 변경사항을 하나의 가상 돔에 모았다가 그냥 돔에 한꺼번에 보내는 중요한 개념이다. 연산 비용을 줄이고 변경사항을 빠르게 파악하고 반영하기 위해 내부적으로 가상돔을 만들어서 관리하는 것이 거의 필수적이다. 가상 돔은 돔의 연산의 양을 줄여주는것이 존재의 핵심이다.
가장 기억해야할 것은 리액트가 컴포넌트의 변화를 감지해야 렌더링을 시킬 수 있다는 것이고, 리액트에서 권장하는 방법에 맞춰 사용하지 않으면 렌더링이 일어나지 않기 때문에 당장 화면과 코드가 일치하지 않는 큰 문제가 발생할 수 있다는 것이다. 이를 위해 이번 주차의 setState와 props는 꼭 계속 이해하고 익숙해져가야한다.
우리는 서버를 직접 구축/연결하지 않는다. 화면에 렌더링되는 것이 가장 중요하기 때문에, 데이터의 CRUD를 서버에서 하나부터 열까지 만들 필요가 없다. 서버 기능을 제공하는 곳에서 우리가 필요한 기능을 클릭 한번으로 구현할 수 있도록 하는 서비스를 '서버리스'라고 한다.
서버리스에서 데이터를 요청하거나 보내려면 그 서버가 정한 규칙에 따라야 한다. 서버쪽에서 정한 규칙을 'API'라고 한다.
서버에 요청 - Reqeust
서버가 응답 - Response
API 형태는 도메인일수도 있고, 서버가 만들어놓은 함수를 이용해서 사용하는 규칙일 수도 있다.
보통 서버가 앱에 데이터를 줄 때는 스터디시간에 배운 JSON 형태로 전달해준다고 한다.
리액트 네이티브로 구현할때, 서버와 통신하는 방법은
1) 앱 화면이 그려진 다음 가장 처음 실행되는 useEffect 함수 차원에서 요청하는 방법
2) 앱에서 사용자가 저장버튼을 눌러 서버에 데이터를 보내면서 데이터 저장을 요청하는 방법
이렇게 두가지라고 한다.
따라서 '서버리스'는 실제로 서버가 없는 것은 아니고, 특정 작업을 수행하기위해 컴퓨터나 가상머신에 서버를 설정하진 않지만 BaaS(Backend as a Service) 또는 FaaS(Function as a Service)에 의존하여 작업을 처리한다.
보통 우리가 모바일이나 웹 어플리케이션을 만들게 될 때, 백엔드 서버 개발을 진행하게 된다. 서버 개발을 하다보면 고려할 사항이 꽤 많다. 대표적으로 유저가 늘어나게 되면 서버의 확장도 고려해야 하고, 보안성도 고려해야 한다. 그래서 탄생한 서비스가 Firebase 같은 BaaS 이다.
이 서비스에서는 앱 개발에 있어서 필요한 다양한 기능들 (데이터베이스, 소셜서비스 연동, 파일 시스템 등)을 API로 제공해 줌으로서, 개발자들이 서버 개발을 하지 않고서도 필요한 기능을 쉽고 빠르게 구현 할 수 있게 해주고, 비용은 사용 한 만큼 나가게 된다. 서버의 이용자가 순식간에 늘어나게 되어도 따로 대비를 안해줘도 알아서 확장이 된다.
BaaS 의 가장 큰 장점은 개발 시간의 단축, 서버 확장 작업의 불필요함이다. 따라서 백엔드에 대한 지식이 별로 없더라도, 아주 빠른 속도로 개발이 가능하다.
그렇다면 BaaS 의 단점은 무엇인가.
클라이언트 위주의 코드
-> BaaS 를 사용하면 백엔드 로직들이 클라이언트쪽에 구현이 된다. 데이터단의 로직이 변경되면 클라이언트 코드의 수정이 이루어진다. 그렇게 되면 재배포를 해야되고 웹어플리케이션이라면 JS를 새로 받아야한다. 그렇다면 모바일 앱이라면, 앱 업데이트를 해야되고 상황에 따라 구버전 사용자를 강제 업데이트해야 하는 일이 발생 할 수도 있다.
가격
-> Firebase 의 경우 초반에는 무료라 소규모 프로젝트에는 매력적인 장점이다. 하지만 앱의 규모가 커지면 가격이 꽤 비싸진다. 실시간 데이터베이스에 10G 가 쌓이고, 한 달 전송되는 데이터의 양이 20G 정도면 데이터베이스 비용으로만 $70 가 발생한다. 참고로 클라우드 컴퓨팅 호스팅을 해주는 서비스 Vultr 의 가격대를 보면, $10 이면 40GB SSD, 2000GB 월 대역폭을 사용 할 수 있다.
복잡한 쿼리가 불가능함
FaaS 는 프로젝트를 여러개의 함수로 쪼개서 매우 거대하고 분산된 컴퓨팅 자원에 준비해둔 함수를 등록하고, 이 함수들이 실행되는 횟수, 시간만큼 비용을 내는 방식이다.
우리가 등록한 함수는 특정 이벤트가 발생했을때 실행된다.
주기적으로 실행되게끔 설정 할 수 있다. 5분마다, 1시간마다, 하루마다 이런식으로 가능하고 크롤링 작업, 주기적 처리를 할 때 좋다.
웹 요청을 처리 할 수도 있다. 예를 들어 특정 URL 로 들어오면 어떠한 작업을 하게끔 할 수 있다. 이를 통해 백엔드 API 를 구성 할 수도 있다.
콘솔을 통하여 직접 호출 할 수도 있다.
장점
비용
: 특정 작업을 하기 위해 서버를 준비하고 하루종일 켜놓는것이 아니라, 필요할때만 함수가 호출되어 처리되며 함수가 호출된 만큼만 비용이 드므로, 비용이 많이 절약된다.
인프라 관리
: 네트워크, 장비 이런것들에 대한 구성 작업을 신경 쓸 필요가 없다. 확장성면에서 매우 뛰어나다.
단점
모든 코드를 함수로 쪼개서 작업하다보니, 함수에서 사용할 수 있는 자원에 제한이 있다.
FaaS 제공사에 매우 의존하므로 AWS, Azure, Google 등의 FaaS 제공사에 강한 의존을 하게 된다. 갑자기 이 회사들이 망해버리면 매우 골치 아프게 된다.
비교적 신기술이라 해외에서는 관련 자료들을 볼 수 있는 반면, 국내에서는 관련 자료를 찾아보기 힘들다.
팀원 중 한분이 API 연결이 가장 두렵하고 하셨는데, 벌써 무섭다ㅠㅠ
Q