[WIL] DOM과 서버리스 | 이노베이션 캠프 동북권 - 3주차 회고

🚢 이번 항해는?

리액트 입문 주차 동안 이노베이션 캠프에서 지급받은 리액트 기초반 강의를 완강했다.

 

클래스 컴포넌트 생명주기와 함수 컴포넌트 hooks 등 리액트의 기초 및 로딩 스피너, 프로그레스 바 같은 팁들과 AWS S3, 파이어베이스 호스팅을 통한 배포 방법을 알게 되었다. 특히 리덕스와 파이어스토어에 중점을 두어 공부했는데, 어렵게만 생각했던 리덕스를 강의를 통해 배운 후 할만하다고 느껴져서 바로 활용해보고 싶었다.

 

https://ko.redux.js.org/

Redux - 자바스크립트 앱을 위한 예측 가능한 상태 컨테이너. | Redux

https://firebase.google.com/products/firestore?hl=ko

Cloud Firestore | 글로벌 규모의 앱 데이터 저장 및 동기화  |  Firebase

 

그러다 마침 좋은 기회로 아는 분과 MBTI 테스트에 따른 웹툰 추천 미니 프로젝트를 시작하게 되어서 리덕스를 적용해볼 수 있었다. 필요한 기능에 따른 모듈을 만들고 스토어를 생성해 컴포넌트에 적용하다보니 덕스 구조에 익숙해지는 것을 느꼈다. 모듈에서 만든 액션 크리에이터를 컴포넌트에 불러오고, 액션 객체를 디스패치해서 리듀서를 통해 원하는 대로 상태를 업데이트하는 과정을 몇 번 반복하니 리덕스의 기본적인 흐름에 금방 적응할 수 있게 되었다.

 

이번 주를 회고하며 DOM과 서버리스에 대해 더 공부하고 정리해보고자 한다.

 

🌲 DOM이란?

DOM(Document Object Model)은 문서 객체 모델이다.

 

브라우저의 렌더링 엔진이 HTML 문서를 파싱하면 HTML 요소들(eliments)은 바이트(2진수) 형태와 지정된 인코딩 방식(예: UTF-8)에 따른 문자열, 그리고 문법적 의미의 최소 단위인 토큰 형태를 거친 뒤 최종적으로 노드(node) 객체로 변환되어 브라우저가 이해할 수 있는 DOM이 생성된다. 노드는 DOM을 구성하는 기본 요소이며, 토큰의 내용에 따라 문서 노드, 요소 노드, 어트리뷰트 노드, 텍스트 노드로 나뉘게 된다.

 

HTML 요소의 시작 태그(start tag)와 종료 태그(end tag) 사이인 콘텐츠 영역에는 텍스트 뿐만 아니라 다른 HTML 요소도 포함될 수 있기 때문에 요소 간 중첩 관계에 의해 계층적인 부모-자식 관계가 형성된다. DOM은 HTML 문서의 이러한 계층적 구조와 정보를 반영해 모든 노드 객체들이 비선형(nonlinear) 트리 자료 구조로 구성되어 있다. 그래서 DOM 트리라고도 한다.

 

DOM을 구성하는 노드 객체는 ECMAScript 사양에 정의된 표준 빌트인 객체가 아니라 브라우저 환경에서 추가적으로 제공하는 (W3C 표준) 호스트 객체다. 하지만 노드 객체도 자바스크립트 객체이므로 프로토타입에 의한 상속 구조를 갖는다.

 

DOM API의 프로퍼티와 메서드를 통해 메모리 상에 존재하는 DOM에 접근하고 변경할 수 있는데, 노드 객체의 부모, 형제, 자식을 탐색하거나 원하는 노드의 어트리뷰트와 텍스트를 조작할 수 있다. 이렇게 동적으로 변경한 DOM은 렌더링에 반영된다.

 

👨‍💻 서버리스란?

서버리스란 서버가 없는 백엔드가 아니라, 서버를 직접 관리할 필요가 없는 아키텍처를 의미한다.

> 분류

클라우드 컴퓨팅 모델을 보통 서비스 형태(# as-a-Service)에 따라 SaaS(서비스로 제공되는 소프트웨어), PaaS(서비스로 제공되는 플랫폼), IaaS(서비스로 제공되는 인프라)로 나누는데, 서버리스 컴퓨팅도 마찬가지로 BaaS(서비스로 제공되는 백엔드)와 FaaS(서비스로 제공되는 함수)로 분류할 수 있다. 보통 서버리스라고 부르면 FaaS를 일컫는다.

> FaaS와 BaaS의 차이

FaaS는 개발자가 서버에서 수행될 함수들을 직접 만들어서 올리면 서비스 업체에서 관리하는 서버 컨테이너(stateless) 안에서 특정 이벤트(트리거)가 발생할 때 함수가 호출되도록 하는 것이고, BaaS는 개발자가 직접 백엔드 기능을 구현하지 않고 서비스 업체에서 제공하는 기능들(데이터베이스, 파일 시스템, 사용자 인증, 소셜 서비스, 메시징 등)을 백엔드 API를 통해 사용한다는 차이점이 있다. 대표적으로 Firebase가 BaaS에 해당된다.

> 서버리스의 장단점

서버리스의 탄생 배경은 클라우드 컴퓨팅이 실사용량과는 관계없이 선택한 용량에 대한 요금을 미리 결제(PaaS, IaaS)해야 한다는 점과, 텅 빈 서버만 빌려오기 때문에 소프트웨어적인 부분은 직접 관리해줘야 하는 불편함에서 시작되었다.

 

서버리스는 서비스 업체(AWS, Microsoft Azure Functions, Google Cloud Functions 등)가 컴퓨팅 리소스와 스토리지를 동적으로 구성한 다음, 함수를 실행한 횟수 및 시간에 따라 사용된 리소스에 대한 비용만을 청구하는 클라우드 실행 모델이기 때문에 비용 절감의 효과가 있다. 예를 들어 서버리스의 대표적 서비스인 AWS Lambda의 경우, 100만 개의 함수를 실행하는 데 20센트의 비용이 청구된다.

 

또한 서버리스를 활용하면 백엔드를 작은 함수 단으로 쪼개서 올리는데, 이때 서버는 서비스 업체가 전적으로 관리한다. 따라서 개발자는 서버의 스케일링, 업데이트, 보안 등의 런타임 관리와 운영에 대해 신경 쓸 필요 없이 핵심 제품에 집중할 수 있으며, 빠른 개발 및 배포가 가능하다는 장점이 있다.

 

하지만 함수가 계속 가동되지 않고 사용자가 요청하는 순간 휴면에서 벗어나 실행되기 때문에 PaaS나 IaaS 모델과 비교했을 때 응답 지연이 발생한다 (cold start). 그러므로 서비스의 규모가 커지거나 빠른 응답을 요구하는 실시간 서비스일 경우 서버리스는 적합하지 않을 수 있다. 또한 유연성과 커스터마이징 수준에 제한을 받고, 벤더 종속성 문제도 발생할 수 있다.

 

Reference >

• 모던 자바스크립트 Deep Dive p.665-667, 677-679
• https://medium.com/개발자의품격/브라우저의-렌더링-과정-5c01c4158ce
• https://sst.dev/chapters/ko/what-is-serverless.html
• https://inpa.tistory.com/entry/WEB-🌐-서버리스ServerLess-개념-💯-총정리-BaaS-FaaS
• https://www.redhat.com/ko/topics/cloud-native-apps/what-is-serverless