제대로 쉬지도 그렇다고 열심히 집중하지도 못했던 한 주.
주특기 입문 주차에 들어와 리액트를 처음 시작하였는데 생각보다 너무 어려워서 강의만 보다 몇일이 지나갔다. 그리고 과제 제출 하루 전에 발등에 불 떨어져서 구글링 해서 코드를 복붙해가며 겨우 냈다. 과제에서 요구하는 사항들을 제대로 이해하지 못했다고 생각하고 강의나 자료에 의존하는 공부 방식에 대해 다시 생각해보게 됐다. 일주일 간 하기에 크게 힘든 과제는 아니라고 생각했는데 막상 생각대로 되지 않고 시간은 없지... 제대로 기초를 쌓지 않은 상태에서 끼워맞추기 식으로 코드를 써오던 게 문제였던 것 같다.
주특기 주차에 들어와 가장 힘들었던 점은 수준 차이. 원래 긍정적이고 다른 사람 의식하지 않고 내 페이스대로 잘 해나가는 성격인데 미리 배우고 온 사람들과 같은 조를 하기도 하고 이야기도 많이 나누면서 부족하다는 생각이 들었던 것 같다. 몇 달, 길게는 몇 년간 해 온 공부를 내가 바로 따라잡기 힘들다는걸 인정하고, 내 자리에서 할 수 있는걸 해나가려고 하지만 한 두명도 아니고 같은 기수분들 수준이 전반적으로 높은 것 같아 비교가 될 수 밖에 없었다...
남은 75일, 체력 관리 + 멘탈 관리 잘해서 지치지 않고 원하는만큼 성장할 수 있었으면.
처음 항해를 하겠다고 마음 먹었을 때 다짐을 잊지 말자!
+++
그래도 컴퓨터라곤 유튜브, 검색이 다였던 컴맹이 포기하지 않고 달려가는게 대견하다! (진심 멋져 나 ❤️)
역시 꿈꾸고 도전할 때 내가 가장 반짝거리는 것 같다. 지금은 부족하더라도 언젠가 내가 개발을 시작했던 이유를 이뤄내며 살아갈 것을 알기에 나를 믿고 나아갈 수 있다. 다음주는 더 몰입하고 더 적극적인 내가 되자! :)
자책과 자기애가 범벅된 한 주 정리 시작.
DOM과 Virtual DOM
"직접 DOM에 접근하는 것은 지양해야 한다."
프론트 특히 SPA를 다루다 보면, DOM(Document Object Model)이란 단어를 많이 마주친다. 하지만 영문으로 봐도 정확히 무슨 뜻인지 와 닿지 않는다.
DOM이란?
MDN에서는 "DOM은 HTML, XML document와 상호작용하고 표현하는 API이다. DOM은 browser에서 로드되며, Node(이하 노드) 트리(각 노드는 document의 부분을 나타낸다)로 표현하는 document 모델이다. (ex. element, 문자열, 혹은 코멘트)"라고 나와 있다.
위의 설명으로, Document는 HTML, XML을, Object는 노드 트리라 유추해볼 수 있다. 그렇다면 노드 트리는 무엇일까? 아래의 그림을 보면 조금 더 쉽게 이해가 갈 것이다.
위의 그림에서 볼 수 있듯이 노드란 웹을 만들어본 사람이라면 다 알고 있는 HTML 태그들이다.
노드(Node)
가장 일반적인 노드 유형(nodeType)은 아래와 같다.
- DOCUMENT_NODE (ex. window.document)
- ELEMENT_NODE (ex. <html>, <body>, <a>, <p>, <script>, <style>, <h1>)
- ATTRIBUTE_NODE (ex. class="hi")
- TEXT_NODE (ex. 줄바꿈과 공백을 포함한 HTML 문서 내의 텍스트)
- DOCUMENT_FRAGMENT_NODE (ex. document.createDocumentFragment())
- DOCUMENT_TYPE_NODE (ex. <!DOCTYPE html>)
지금 사용하고 있는 브라우저에서 console에 Node를 치면 바로 위의 노드 유형들이 나온다.
console에서 Node 입력
그럼 내가 만든 HTML이 곧 DOM인가 보네? 라는 생각이 들 법하지만, 아쉽게도 그렇지 않다.
맨 처음에 MDN에서 설명했듯이, DOM은 브라우저에서 로드되는 것이다. 각자의 IDE에서 작성한 HTML은 DOM이 아니고, 작성 된 HTML 문서가 브라우저에 의해 해석되어 실제 문서를 나타내는 노드 트리가 DOM이다. 그리고 이러한 DOM은 자바스크립트로 해당 문서에 노드 추가, 삭제, 변경, 이벤트 처리, 수정 등을 가능케 하는 API를 제공한다.
내가 아무리 나의 IDE에 HTML을 작성한다 한들, 최종적으로 이 결과물을 보기 위해 브라우저가 필요하다. IDE에 작성된 HTML은 단순한 문자열(string)일 뿐이며, 브라우저가 이해하기 위해서는 노드(객체)로 변환해야 한다.
즉 DOM은 HTML과 자바스크립트를 이어주는 공간으로, 내가 작성한 HTML을 자바스크립트가 이해할 수 있도록 객체(object)로 변환하는 것이다.
DOM은 내가 작성한 HTML로 부터 생성되지만, 브라우저가 알아서 필요한 노드들을 붙여준다. 예를 들어, <head>나 <body>없이 <html>안에 어떠한 내용을 작성을 하더라도, 브라우저로 열어보면 자동으로 생성되어 있다. 그리고 자바스크립트로 인해 새로운 노드를 추가할 수도 있다.
const newTextDiv = document.createElement('div')
const helloWorld = document.createTextNode('Hello world!')
newTextDiv.appendChild(helloWorld)
document.body.appendChild(newTextDiv)따라서, 자바스크립트를 DOM API라고 부르기도 한다.
브라우저 동작 원리
그렇다면 DOM이 어떻게 브라우저로 동작 되는 걸까? 해당 글에서는 간단하게만 다뤄보며 Webkit을 기준으로 작성되었다.
브라우저가 HTML을 전달 받으면, 곧 이를 변환(파싱)하고 노드들로 이루어진 DOM 트리를 만든다. 그 후, 외부의 CSS 파일과 각 노드들의 inline 스타일을 파싱하여 스타일을 입힌 Render 트리를 만든다.
Render 트리가 만들이지면, 각 노드들이 화면에서 정확히 어디에 나타나야 하는지에 대한 위치가 주어진다. 그 후, paint() 메서드를 호출하면 내가 구현하고 싶었던 화면이 출력된다.
DOM은 해당 과정을 계속 반복한다. 즉, 오타 수정, 문구 제거 혹은 이미지를 첨부하는 사소한 일을 하더라도, DOM은 처음부터 다시 HTML을 파싱하여 DOM 트리를 만들고 CSS를 파싱하여 Render 트리를 만들고, 레이아웃을 입혀 출력한다.
2000년도 초만 하더라도 하나의 웹 사이트에 몇 페이지 없었을 테지만, 현재 대부분의 웹 사이트는 수 십개 심지어 수 백, 수 천개의 페이지로 이루어졌다. 겨우 오타 하나를 잡고 싶을 뿐인데, 전체 사이트를 다시 처음부터 렌더링(위의 결과물 출력 과정)을 해야 하며, 해당 오타를 찾기 까지 너무나 많은 시간이 들어가 상당히 비효율적이다.
그래서 Virtual Dom이 나왔다.
Virtual Dom
Virtual Dom(이하 가상 DOM)은 수정사항이 여러 가지 있더라도, 가상 DOM은 한 번만 렌더링을 일으킨다.
위의 그림처럼, 가상 DOM은 DOM이 생성되기 전, 이전 상태 값과 수정사항을 비교하여 달라진 부분만 DOM에게 한 번에 전달하여 딱 한 번만 렌더링을 진행한다.
빨간 부분에 수정사항이 생겼다면, 가상 DOM이 알아서 달라진 값을 탐지하여 변경하고 최종적인 결과물을 실제 DOM에 전달한다. 만약 가상 DOM이 없었다면, DOM은 렌더링을 처음부터 해야했기 때문에 모든 동그라미가 다 빨간색으로 바뀌었을 것이다.
"직접 DOM에 접근하는 것은 지양해야 한다."
이는 DOM에 직접 접근해도 문제가 되진 않지만, DOM이 직접 변경된다면 사소한 변경사항에도 전체가 재렌더링 되기 때문에 브라우저에 과부하가 올 수 있다. 따라서 최대한 DOM에 직접 접근하지 말아야 한다, 라고 이해하면 될 것 같다.
서버리스(Serverless)
서버리스란 ?
서버리스(Serverless)는 직역하면 "서버가 없다"라는 뜻.
하지만, 서버가 없는 것은 아니고, 서버를 직접 관리할 필요가 없는 아키텍처를 뜻해서 서버리스 아키텍처(Serverless Architecture)라고 부르는 듯하다.
- 서버가 필요 없다는 뜻은 아니다!
- 서버를 관리하거나 신경 쓸 필요가 없다는 뜻
- 나노 수준의 함수로 구성된다.
서버리스 아키텍처의 구현 방식
서버리스 아키텍처의 대표적인 두 가지 구현 방식은 아래와 같다.
- BaaS (Backend as a Service) : Firebase, Kinvey, Parse ... 등
- FaaS (Function as a Service) : AWS Lambda, Azure Functions, Google Cloud Functions ... 등
BaaS를 사용하는 애플리케이션은 일반적으로 SPA, 안드로이드와 같은 클라이언트 중심으로 개발된 애플리케이션. 클라이언트단에서 Baas가 제공하는 인증, DB, 사용자 관리 등과 같은 외부 서비스를 사용해서 대부분의 비즈니스 로직을 처리.
FaaS는 무상태(Stateless) 함수가 서버 측 비즈니스 로직을 포함. 백엔드를 작은 함수단으로 쪼개서 사용자가 직접 관리하지 않는 서버로 올린다. 함수들은 특정한 조건 또는 주기, 요청 등으로 트리거 되어서 서버가 알아서 실행되고 종료됨. 주로 서버리스라 하면 FaaS에 더 가깝다.
서버리스의 장단점
- 장점
- 이벤트 기반의 비용. (일정 주기, 조건 등에 함수를 호출하므로 리소스를 낭비하지 않게 되어서 비용이 저렴.)
- 인프라 구성, 운영, 보안 등에 신경쓰지 않고 비즈니스 로직에 집중할 수 있다.
- 자동 스케일 업 및 스케일 다운
- 간단한 패키징 및 배포
- 릴리즈 주기 감소
- 높은 생산성
- 단점
- 실시간 서비스에는 적합하지 않음 (항시 실행 중인 서버랑 달리, 트리거에 의해 서버를 실행하고 종료하기를 반복하기 때문에 실행 대기 시간이 오래 걸림)
- 클라우드 서비스 업체에 종속적
- 마이그레이션의 어려움
- 실행 시간 한계 (AWS Lambda의 경우 15분)
- 로컬 데이터를 사용할 수 없다. (Stateless)
- 디버깅이나 테스팅에 불편하다.
서버리스는 특히, 사이드 프로젝트나 빠르게 프로토타입을 출시할 때 빠르고 쉽게 제품을 출시할 수 있고, 돈도 매우 절약되며, 서버리스 시장은 무섭게 성장하고 있다.
다음 주 계획 👀
- 그저 리액트, 리덕스......
- 개인 과제, 팀 과제 잘 마무리하기
- 리액트에 꼭 필요한 자바스크립트 문법 정리!
References.
'TIL | WIL' 카테고리의 다른 글
| [WIL] 221031~221106 (항해99 week7.) (0) | 2022.11.06 |
|---|---|
| [WIL] 221017-221026 (항해99 week5.) (0) | 2022.10.24 |
| [WIL] 221010-221016 (항해99 week4.) (3) | 2022.10.24 |
| [WIL] 220926-221002 (항해99 week2.) (1) | 2022.10.02 |
| [WIL] 220919-220925 (항해99 week1.) (0) | 2022.09.25 |