[테코톡 요약] 우아한테크코스 3기 레벨2 테코톡 모아보기

 

 

1. 웹 접근성 & 웹 표준

🎤 미키

웹 초창기에는 웹 표준이 없어 개발자는 넷스케이프와 IE 모두 개발해야 했었다. 이후 대세가 된 IE는 호환성을 고려하지 않고 자사에 유리한 ActiveX 오직 윈도우에서만 동작하는 플러그인을 대거 채용하기도 했다. 현대에 와서는 특정 브라우저에서만 동작하는 애플리케이션은 설 자리를 잃게 되었다.

'웹 표준'은 하나의 소스로 어느 운영체제나 브라우저를 사용해도 동일한 콘텐츠를 볼 수 있도록 하는 웹 개발자들 간의 약속이다. 여기서 '동일한 컨텐츠'란 완전히 동일한 것이 아니라 동등한 수준의 컨텐츠를 뜻한다. 웹 표준은 W3C에서 확정한다. 웹 표준을 지키면 기업 입장에서는 운영의 효율성을 가져다 준다. 뿐만 아니라 웹표준은 검색 엔진 최적화, 코드 상에서 구조와 표현의 분리를 가능하게 해 주었다.

미키의 '웹표준' 설명 슬라이드

'웹 접근성'은 장애인이나 고령자분들이 웹 사이트에서 제공하는 정보를 동등하게 접근하고 이용할 수 있도록 보장한다는 개념이다. 웹 접근성을 높이기 위한 쉽고 기본적인 방법은 웹 표준을 준수하는 것이다. 예를 들어, 시각 장애인은 웹 접근성이 보장된 웹 애플리케이션에서 스크린 리더라는 프로그램을 통해 웹페이지를 읽을 수 있다. 웹 요소 간을 Tab키로 이동하면서 메뉴를 선택하거나, 폼을 제출하는 등의 상호작용을 할 수 있는데, 이렇게 사용자와 상호작용할 수 있는 요소들을 대화형 요소(Interactive Element)라고 한다.

 

2. Virtual DOM

🎤 지그

브라우저는 다음과 같은 순서로 렌더링된다.
1. DOM Tree 생성 - 렌더 엔진이 HTML을 파싱하여 DOM 노드로 이루어진 트리 생성
2. Render Tree 생성 - DOM + CSSOM 으로 렌더 트리를 생성
3. Layout (reflow) - 각 노드들의 스크린에서의 좌표에 따라 위치 결정
4. Paint (repaint) - 실제 화면에 그리기

이러한 브라우저 렌더링 과정에서 한 가지 문제가 있다. 사용자와의 인터랙션에 따라 변경사항이 생기면 '렌더 트리가 재생성'된다는 것이다. 예를 들어, 유저가 어떤 포스트에 좋아요를 누르거나 담아둔 장바구니에서 상품을 하나 삭제하거나 댓글을 하나 달기라도 하면, 전체 노드가 다시 생성된다. SPA에서는 특히 더더욱 DOM 조작을 더 효율적으로 하는 최적화가 필요했다.

지그의 '가상돔' 설명 슬라이드

이러한 DOM 조작의 비효율성을 줄이기 위해 등장한 것이 바로 Virtual DOM이다. Virtual DOM 은 Real DOM의 추상화 버전이라고 할 수 있다. Real DOM의 전체를 업데이트하지 않고도 필요한 변화만 반영할 수 있다. Virtual DOM이 하는 일은 DOM Fragment의 변화를 묶어서 적용한 다음 기존의 DOM에 적용시켜주는 것이다. Virtual DOM은 사실 자바스크립트 객체이다. 실제 DOM이 아닌 메모리상에서 동작하기 때문에 빠르게 동작한다. 실제 렌더링이 되지 않기 때문에 연산 비용이 적다. 

리액트는 Virtual DOM을 이용하는 대표적인 자바스크립트 라이브러리이다. 리액트에서는 Virtual DOM을 "UI의 가상적인 표현을 메모리에 저장하고 ReactDOM과 같은 라이브러리에 의해 실제 DOM과 동기화한다"고 표현하고 있다. 이 과정을 '재조정'이라고 부른다.

리액트의 Diffing 알고리즘에서는, Virtual DOM이 업데이트되면 이전의 Virtual DOM 스냅샷과 비교하여 정확히 어떤 부분이 바뀌었는지 검사한다. 만약 element의 태그 또는 컴포넌트가 변경된다면, 속성 값만 업데이트한다. 만약 element의 태그 또는 컴포넌트가 변경된 경우, 해당 노드를 포함한 하위 모드 노드를 이런 변경이나 업데이트가 마무리 된 후 딱 한번 실제 돔을 업데이트 한다.

항상 Virtual DOM이 더 빠른 것은 아니라는 점을 유념해야 한다. SPA로 제작된 큰 규모의 앱에서는 Virtual DOM을 사용해서 브라우저의 연산 양을 줄여 성능을 개선할 수 있다. 반대로, 정보제공만 하는 웹페이지라면 사용자와의 인터렉션이 적기 때문에 일반 DOM의 성능이 더 좋을 수도 있다. 만드는 프로젝트의 성격에 맞게 사용해야 한다. 

 

3. 브라우저 렌더링

🎤 체프

 

4. 비동기

🎤 카일

 

5. 컴포넌트

🎤 브랜

 

6. 테스트 종류

🎤 도비

 

 

 

 

 

+ 백엔드 주제 일부

프레임워크 vs 라이브러리 vs API

🎤 욘

'프레임워크(Framework)'란 개발할 때 빈번하게 사용되는 기능을 한꺼번에 제공해서, 개발 효율을 올릴 수 있는 소프트웨어를 말한다. 프레임워크는 공통적인 개발환경을 제공해서, 통일된 형태로 개발할 수 있게 해주고, 필요로 하는 부분을 구현하는 데만 신경 쓸 수 있도록 해준다. 개발할 수 있는 범위에 한계가 있고, 제어의 역전이 발생한다는 점이 큰 특징이다. 프레임워크의 예시로는 Spring, Django 등이 있다.

'라이브러리(Library)'란 개발하는데 필요한 것들을 모아둔 일종의 저장소라고 할 수 있는데, 그 실체는 개발자가 사용할 수 있는 API들을 종류나 목적에 따라서 나누어 정의한 API 묶음이다. 필요할 때 목적에 맞게 필요할 때 호출해서 사용할 수 있고. 흐름을 제어한다는 점에서 프레임워크와 차이가 있다. 시스템에 기본적으로 설치되어 있는 '기본 라이브러리'와 제조사나 외부 메이커에 의해서 만들어지는 '확장 라이브러리'로 나눌 수 있다. 

'API(Application Programming Interface)'란 다른 프로그램이 제공하는 기능을 제어할 수 있게 만든 인터페이스이다. API는 다른 프로그램과 연결해주는 일종의 연결 다리로서, 구현이 아닌 제어를 담당한다. API를 조합하면 원하는 프로그램을 만들 수 있다. 지하철 알림과 같은 애플리케이션도 공공 API를 이용해서 만들어졌다. 

집 짓기에 빗대어 비유를 하자면, '프레임워크'는 평면도에, '라이브러리'는 에어컨에, 'API'는 리모컨에 비유할 수 있다.