웹 성능은 개발자의 주요 관심사 중 하나입니다. 그리고 웹 성능에 영향을 미치는 주요 항목은 '지연시간'과 '싱글 스레드'입니다.

지연시간

네트워크를 통해 얼마나 빠르게 페이지 로드가 이루어지게 하는지는 매우 중요합니다. 이에 대한 해결책으로는 최대한 빠르게 요청하는 것과 최소한의 데이터를 응답받는 것 등이 포함될 수 있습니다.

싱글 스레드

웹 브라우저는 싱글 스레드로 동작합니다. 따라서 메인 스레드의 책임을 줄여주는 방식으로 웹 성능 향상을 이룰 수 있습니다.

탐색(Navigation)

탐색은 웹 페이지를 로딩하는 첫 단계로, 사용자가 URL을 주소창에 직접 입력하거나 링크를 클릭하고 폼을 제출하는 등의 동작을 통해 웹 페이지에 대한 요청을 서버에게 보낼 때 발생합니다.

DNS 조회

웹 페이지를 탐색하기 위해서는 해당 페이지의 자원이 어디에 위치하는지를 먼저 알아야 합니다. 이때 해당 사이트에 처음 방문하는 것이라면, DNS 조회가 필요합니다.

DNS(Domain Name System)란?

도메인 이름 시스템인 DNS는 사람이 읽기 편한 도메인 이름(e.g. www.amazon.com)을 컴퓨터가 읽을 수 있는 IP 주소(e.g. 192.0.2.44)로 변환해줍니다.

인터넷의 DNS 시스템은 도메인과 IP 주소를 마치 이름과 전화번호 같은 형식으로 각각 매핑하여 관리해주고 있습니다.

다시 돌아와서, 브라우저가 DNS 조회를 요청하면 이름 서버에 의해서 처리되고 IP 주소를 응답받게 됩니다. 이 IP 주소를 일정 기간 동안 캐시되어, 후속 요청 속도를 높여줍니다.

DNS 조회는 보통 호스트 이름 하나당 한 번만 수행되지만, 글꼴, 이미지, 스크립트, 광고 등의 자원들이 서로 다른 호스트 이름을 가지고 있다면 각각에 대해서 모두 수행되어야 합니다.

TCP 3-way Handshake

IP 주소를 알았다면, 브라우저는 서버와 TCP 3-way handshake를 통해 연결을 설정합니다.

이 방식은 데이터를 전송하기 전에 통신하는 두 주체, 즉 브라우저와 서버가 TCP 소켓 연결을 위한 매개변수를 주고 받을 수 있도록 만들어졌습니다.

TCP(Transmission Control Protocol, 전송 제어 프로토콜)란?

TCP는 두 개의 호스트를 연결하고 데이터 스트림을 교환하게 해주는 중요한 네트워크 프로토콜입니다. 이는 데이터와 패킷을 보내진 순서대로 전달하는 것과 에러 없이 신뢰할 수 있도록 전달하는 것을 보증해줍니다.

패킷은 네트워크를 통해 전송되는 형식화된 데이터 덩어리이며, 사용자 데이터와 제어 정보로 구성되어 있습니다. 사용자 데이터는 흔히 알려진 'payload'이며, 제어 정보는 페이로드를 전달하기 위한 정보로 '네트워크 주소, 순서 정보, 오류 감지 코드'로 구성되어 있습니다.

두 컴퓨터 간 TCP 세션을 협상하고 시작하기 위해서는 3개의 메세지를 주고받아야 합니다. 이는 각각 'SYN, SYN-ACK, ACK'에 해당됩니다.

1. SYN 클라이언트가 서버에게 SYN 메시지를 보냅니다. 이 메시지에 포함된 시퀀스 번호는 클라이언트가 임의로 설정한 값 A입니다.

2. SYN-ACK 서버가 클라이언트에게 SYN-ACK 메시지로 응답합니다. 이 메시지에 포함된 시퀀스 번호는 서버가 임의로 설정한 값 B이고, 응답 번호는 (A+1)입니다.

3. ACK 클라이언트가 서버에게 다시 ACK 메시지를 보냅니다. 이 메시지에 포함된 응답 번호는 (B+1)

TLS 협상

HTTPS를 이용한 보안성 있는 연결을 위해서는 또 다른 추가 handshake가 필요합니다. 여기서 통신 암호화에 사용할 암호를 결정하고, 서버를 확인하고, 실제 데이터 전송 전에 안전한 연결이 이뤄지도록 해줍니다.

TLS(Transport Layer Security, 전송 계층 보안)란?

SSL(Secure Sockets Layer)에서 발전된 TLS는 애플리케이션들 네트워크 상에서 안전하게 통신하기 위한 프로토콜입니다. 서버와 클라이언트가 TLS로 통신을 할 때, 제 3자가 메시지를 변형시키거나 감청할 수 없도록 해줍니다.

응답

웹 서버로 한 번 연결이 성립되고 나면, HTML 파일을 요청하는 초기 HTTP request를 보냅니다. 그리고 서버는 요청을 받아서, 관련 응답 헤더와 함께 HTML 파일을 응답해줍니다.

TTFB(Time to First Byte)는 사용자가 요청을 보내고, HTML의 첫 패킷을 받는데까지 걸린 시간입니다.

TCP Slow Start

첫번째 컨텐츠 청크는 일반적으로 14kb 크기의 데이터입니다. 이러한 사이즈는 네트워크 통신의 속도를 조절하는 알고리즘인 'TCP Slow Start'에 의해 정해졌습니다.

이는 네트워크의 최대 대역폭을 파악할 수 있을 때까지 점진적으로 데이터의 전송량을 증가시키기 위함입니다. 네트워크의 최대 용량을 찾아서 확산되는 정보의 양을 천천히 늘리고, 초기에 기능을 알 수 없는 네트워크 혼잡 현상을 방지해줍니다.

첫 패킷을 받고난 이후 서버는 다음 패킷을 사이즈를 2배인 28kb로 늘립니다. 미리 정의한 임계치에 다다르거나 혼잡의 징후가 나타나기 전까지 2배씩 커집니다.

혼잡 제어 알고리즘은 서버가 보낸 패킷의 흐름과 확인 응답(acknowledgements, ACKs)을 바탕으로 전송 속도를 결정합니다.

구문 분석(parsing)

브라우저가 첫 번째 데이터 청크를 받으면, 수신된 정보를 구문 분석합니다. 네트워크를 통해 받은 데이터를 DOM이나 CSSOM으로 바꾸는 단계입니다. 이를 렌더러가 화면에 페이지를 그리는데 사용합니다.

브라우저는 마크업을 내부적으로 DOM으로 표현하며, JS의 다양한 API를 통해 조작할 수 있습니다.

요청된 HTML 페이지의 크기가 초기 패킷의 크기인 14kb보다 크더라도, 브라우저는 구문 분석을 시작하고 가지고 있는 데이터 수준에서 렌더링을 시도합니다. 이는 첫 렌더링에 필요한 HTML과 CSS만이라도 첫 14kb에 포함해야 하는 이유입니다.

DOM 트리 구축

HTML을 처리하여 DOM 트리를 만들기 위해서는 토큰화를 먼저 진행해야 합니다. 각 태그의 시작 태그, 종료 태그, attribute, name, value 등이 토큰에 포함됩니다. 그리고 이렇게 토큰화된 입력을 분석하여 DOM 트리를 만듭니다.

DOM 트리에서 HTML 요소는 최상위 노드이며, 태그 간의 관계와 계층이 반영되어있습니다. DOM 노드의 갯수가 많아질수록, 트리 생성이 더 오랜 시간이 걸립니다.

Preload Scanner

브라우저에서 DOM 트리를 만드는 과정이 메인 스레드를 차지하고 있습니다. 따라서 프리로드 스캐너는 사용 가능한 컨텐츠를 분석하고 CSS, JS, Web Font와 같은 우선 순위가 높은 자원을 미리 요청합니다. 이 덕분에 구문 분석기가 요청된 자원에 다다를 때쯤에 이미 해당 자원들이 전송받는 중이거나 전송 받은 후입니다. 이렇게 프리로드 스캐너는 블록킹을 줄여줍니다.

CSS를 다운로드하는 것은 HTML 분석이나 다운로드를 막지 않습니다. 하지만 JS의 실행은 막습니다. 그 이유는 JS는 종종 요소에 영향을 주는 CSS 속성을 조작하기 때문입니다.

CSSOM 구축

JS Compilation

접근성 트리 구축

참조링크 웹페이지를 표시한다는 것: 브라우저는 어떻게 동작하는가

자바스크립트 엔진은 2개의 과정으로 나누어 소스코드를 처리합니다.

1. 소스코드의 평가
2. 소스코드의 실행

모든 소스코드는 실행에 앞서 평가 과정을 거치고 실행하기 위한 준비를 합니다. 평가 과정에서는 실행 컨텍스트를 생성하고 변수, 함수 등의 선언문을 먼저 실행합니다. 여기서 생성된 변수나 함수의 식별자를 키로 사용해서 실행 컨텍스트가 관리하는 스코프에 등록합니다.

이때 소코프는 렉시컬 환경의 환경 레코드를 의미합니다.

평가 과정이 끝나면, 앞서 실행했던 선언문을 제외한 나머지 소스코드가 순차적으로 실행됩니다. 이때가 '런타임'이 시작되는 것입니다. 이때 소스코드에 실행에 필요한 정보들(변수, 함수 등)을 실행 컨텍스트가 관리하는 스코프에서 검색해서 취득합니다. 그리고 변수 값의 변경 등의 실행 결과를 다시 실행 컨텍스트가 관리하는 스코프에 등록합니다.

그렇다면 만약 전역과 함수(로컬) 스코프가 있다면 어떤 순서로 자바스크립트 엔진은 동작할까요?

1. 전역 코드 평가

전역 코드 평가 과정을 거치면서 변수와 함수 선언문만 먼저 실행합니다. 이 결과로 생성된 전역 변수와 전역 함수는 실행 컨텍스트가 관리하는 전역 스코프에 등록됩니다. 이때 전역 변수와 전역 함수는 각각 전역 객체의 프로퍼티와 메소드가 되는 것입니다.

2. 전역 코드 실행

평가 과정이 끝나고 런타임이 시작되어 전역 코드가 순차적으로 실행됩니다. 이때 전역 변수에 값이 할당되고 함수가 호출되는 것입니다. 함수가 호출되면 순차적으로 실행되던 전역 코드의 실행을 일시 중단하고 코드 실행 순서를 변경하여 함수 내부로 진입합니다.

3. 함수 코드 평가

함수로 내부로 진입하면 함수 내부의 코드 평가 과정을 거칩니다. 이때 매개변수와 지역 변수 선언문만 먼저 실행되고, 여기서 생성된 매개변수와 지역 변수는 실행 컨텍스트가 관리하는 지역 스코프에 등록됩니다. 또한 함수 내부에서 지역 변수로 사용할 수 있는 arguments 객체가 생성되어 지역 스코프에 등록되고 this 바인딩도 결정됩니다.

4. 함수 코드 실행

함수 코드 평가 과정이 끝나면 런타임이 시작되어 함수 코드가 순차적으로 실행됩니다. 이때 매개변수와 지역 변수에 값이 할당되고 console.log 메소드가 호출됩니다. 이때 log 메소드에 인수로 전달된 a+x+y 표현식이 평가되며, 스코프 체인을 통해 a, x, y 식별자를 각각 검색합니다. log 메소드의 실행이 종료되면 함수 호출 이전으로 되돌아가 전역 코드 실행을 계속해서 진행합니다.

위와 같은 실행 과정이 가능하기 위해서는 '스코프, 식별자, 코드 실행 순서'에 대한 관리가 필요합니다.

1. 선언에 의해 생성된 '변수, 함수, 클래스' 등의 모든 식별자를 스코프를 구분하여 등록하고, 상태 변화를 지속적으로 관리해야 합니다.

2. 스코프 간의 중첩 관계에 의해 스코프 체인을 형성해야 합니다. 따라서 스코프 체인을 통해서 하위 스코프에서 상위 스코프로 이동하며 식별자를 검색할 수 있어야 합니다.

3. 함수 호출에 의해 함수 내부로 코드 실행 순서가 진입하거나, 종료 후 다시 이전 위치로 되돌아갈 수 있어야 합니다.

이러한 조건들을 유지할 수 있도록 모든 것을 관리하는 것이 '실행 컨텍스트'입니다.

식별자를 등록하고 식별자를 관리하는 스코프와 코드 실행 순서 관리를 구현한 내부 메커니즘으로, 모든 자바스크립트 코드는 실행 컨텍스트를 통해 실행되고 관리됩니다.

식별자와 스코프는 실행 컨텍스트의 '렉시컬 환경'으로 관리하고, 코드 실행 순서는 실행 컨텍스트 '스택'으로 관리합니다.

참조링크 모던 자바스크립트 Deep Dive

타입스크립트는 자바스크립트이 상위 집합(superset)입니다. 자바스크립트는 타입스크립트의 부분 집합(subset)입니다.

모든 자바스크립트 프로그램은 타입스크립트입니다. 하지만 모든 타입스크립트 프로그램은 자바스크립트가 아닙니다. 자바스크립트가 아닌 타입스크립트 프로그램이 존재합니다.

이는 타입스크립트가 타입을 명시하는 등의 추가적인 문법을 가지기 때문입니다. 타입 구문을 사용하게 되는 순간, 자바스크립트에서 타입스크립트의 영역으로 변환됩니다.

타입스크립트를 정적 타입 시스템이라고 하는 이유는 타입 시스템의 목표 중 하나가 런타임에 오류를 발생시킬 코드를 미리 찾아내는 것이기 때문입니다.

타입스크립트 컴파일러는 타입 구문을 추가하지 않아도 변수의 초깃값으로부터 타입을 자동으로 추론합니다. 또한 타입 구문과 관계 없이 개발자 의도와 다른 오류를 찾아내고 꽤 훌륭한 해결책을 제시합니다.

하지만 타입 구문을 추가한다면, 훨씬 더 정확하고 많은 오류를 찾아낼 수 있습니다. 왜냐하면 코드의 의도와 목적이 무엇인지 타입 구문을 통해 타입스크립트에게 명확하게 알려줄 수 있기 때문입니다.

위 다이어그램에서 '타입 체커 통과 TS'가 우리가 평소에 작성하는 타입스크립트 코드입니다. 로컬에서 타입 체크 에러를 해결해가면서 코드를 작성하기 때문입니다.

타입 시스템은 자바스크립트의 런타임 동작을 모델링합니다. 따라서 런타임 오류를 발생시키는 코드를 찾아내려고 합니다. 하지만 타입 체커는 런타임 오류를 정상으로 인식하거나, 정상 코드를 오류로 인식할 수도 있습니다.

이러한 오류가 발생하는 근본적인 원인은 타입스크립트가 이해하는 값의 타입과 실제 값에 차이가 있기 때문입니다. 결국 타입스크립트는 정적 타입의 정확성을 보장해주지 않고 애초에 그런 목적으로 만들어지지 않았습니다.

주요 TS 설정

noImplicitAny

inplicit 암시적인, 암묵적으로 합의된 explicit 명시적인, 명확하게 지정된

변수에 아무런 타입도 명시해주지 않으면 타입스크립트는 any로 추론합니다. 하지만 모든 변수가 any로 사용되면, 타입 체커는 무의미해집니다.

따라서 이 설정은 특정 타입을 명시해달라는 뜻입니다.

자바스크립트에서 타입스크립트로 마이그레이션하는 중이 아니라면, 설정하는 것이 좋습니다.

strictNullChecks

모든 타입에서 null과 undefined를 할당할 수 없게 해서, 꼭 필요한 경우에는 명시해서 사용하라는 뜻입니다.

따라서 다른 타입에 null과 undefined가 전달될 경우, 에러가 발생합니다.

'undefinded는 객체가 아닙니다.' 같은 런타임 오류를 예방하기 위해서는 설정하는 것이 좋습니다.

TS Compiler

TS Compiler는 크게 2가지 역할을 수행합니다.

최신 TS/JS 코드를 구형 브라우저에서 동작할 수 있도록 구버전 JS로 transpile합니다. 코드의 타입 오류를 체크합니다.

트랜스파일은 translate(번역)와 compile(컴파일)을 합친 말로, 소스 코드를 동일한 동작을 하는 다른 버전 또는 다른 언어의 소스 코드로 변환하는 것을 의미합니다. 트랜스파일링의 결과물은 여전히 컴파일이 필요한 소스코드(e.g. JavaScript)이기 때문에, 컴파일과 구분해서 부릅니다.

컴파일은 소스 코드를 동일한 동작을 하는 다른 언어로 변환해주는 것을 의미하지만, 컴파일링의 결과물은 컴퓨터가 바로 실행할 수 있는 이진 코드 또는 기계 코드입니다.

위 두 가지 역할은 서로 독립적으로 동작합니다.

따라서 타입 오류가 있는 코드도 컴파일이 됩니다. 이를 통해 애플리케이션 개발 중에 타입 에러 때문에 테스트를 중단할 필요가 없습니다.

그리고 런타임에는 타입 체크가 불가능합니다. 타입스크립트의 타입들은 제거 가능(erasable)하기 때문에, TS에서 JS로 컴파일되는 과정에서 모든 interface, type, 타입 구문은 제거됩니다.

런타임에는 타입 연산이 영향을 주지 않습니다. 이 또한 컴파일 과정에서 타입 구문이 제거되기 때문입니다. 연산이 필요하면, 자바스크립트 연산을 통해 타입 변환을 수행해야 합니다.

참조링크 이펙티브 타입스크립트 mdn Compile

bundle exec jekyll serve 명령어를 실행하면 로컬에서 Jekyll을 사용하여 정적 웹사이트를 생성하고, 내장된 개발 서버를 통해 웹사이트를 호스팅합니다. 이렇게 실행하면 실시간 변경을 확인할 수 있는 이유는 다음과 같습니다:

1. 자동 재생성 (Auto-regeneration): Jekyll은 파일이 변경될 때마다 자동으로 사이트를 다시 생성하도록 설정할 수 있습니다. bundle exec jekyll serve 명령을 실행하면 Jekyll은 소스 디렉토리의 내용을 모니터링하고, 파일이 변경될 때마다 사이트를 다시 빌드하여 새로운 변경 사항을 반영합니다. 이로써 실시간으로 변경된 내용을 확인할 수 있습니다.

2. 개발 서버 (Development Server): bundle exec jekyll serve 명령을 실행하면 내장된 개발 서버가 시작됩니다. 이 서버는 로컬에서 웹사이트를 호스팅하며, 변경 사항이 발생할 때마다 자동으로 사이트를 다시 빌드하여 브라우저에서 변경 내용을 확인할 수 있도록 합니다.

3. 브라우저 자동 새로고침: 개발 서버가 시작되면 브라우저에 자동으로 실시간 새로고침 기능이 적용됩니다. 파일이 변경되고 사이트가 다시 빌드될 때마다 브라우저는 자동으로 페이지를 새로 고침하여 변경 내용을 보여줍니다.

위의 요소들이 함께 작동하여, bundle exec jekyll serve 명령을 실행한 상태에서 소스 코드를 수정하면 Jekyll이 자동으로 사이트를 다시 생성하고, 개발 서버가 변경 사항을 브라우저로 전달하여 실시간으로 변경 내용을 확인할 수 있도록 만들어줍니다.

Jekyll과 Liquid

먼저 Jekyll과 Liquid은 웹 개발 분야에서 사용되는 두 가지 도구입니다. 각각은 정적 사이트 생성기와 템플릿 언어로 사용되며, 웹사이트의 구축 및 관리를 용이하게 해줍니다.

1. Jekyll: Jekyll은 정적 사이트 생성기로, 웹사이트를 만들고 관리하기 위한 도구입니다. Jekyll은 Markdown, HTML, CSS 등의 웹 기술을 사용하여 컨텐츠를 작성하고, 이를 바탕으로 정적인 HTML 페이지를 생성합니다. 이렇게 생성된 정적 사이트는 웹 서버에 배포하여 호스팅하거나, GitHub Pages와 같은 플랫폼에 배포할 수 있습니다.

   주요 기능:

   • 마크다운과 HTML로 작성된 컨텐츠를 변환하여 정적 웹페이지를 생성합니다.
   • 레이아웃, 템플릿, 포스트 등의 개념을 지원하여 웹사이트의 일관성을 유지하고 구성할 수 있습니다.
   • 내장된 개발 서버를 통해 로컬에서 사이트를 빠르게 확인할 수 있습니다.
   • 다양한 플러그인과 테마를 활용하여 웹사이트를 확장하고 개선할 수 있습니다.

2. Liquid: Liquid는 템플릿 언어로, 주로 Jekyll과 같은 정적 사이트 생성기에서 사용되며, 동적인 컨텐츠를 효율적으로 처리하고 템플릿을 관리하는 데 사용됩니다. Liquid는 주로 HTML과 함께 사용되며, 루비와 비슷한 문법을 가지고 있습니다.

   주요 기능:

   • 변수, 조건문, 반복문 등의 기능을 포함하여 템플릿 안에서 동적인 내용을 처리할 수 있습니다.
   • 웹사이트의 일관성을 유지하고 코드를 재사용하기 위해 템플릿 기능을 지원합니다.
   • Jekyll과 같은 정적 사이트 생성기에서는 Liquid 템플릿을 사용하여 사이트의 레이아웃, 포스트, 페이지 등을 구성합니다.
   • 웹 개발에서도 Liquid를 통해 동적인 데이터를 효과적으로 처리하고 템플릿화된 컨텐츠를 생성할 수 있습니다.

요약하면, Jekyll은 정적 사이트 생성기로 마크다운과 HTML 컨텐츠를 기반으로 정적 웹사이트를 생성하고 관리하는 도구입니다. Liquid는 Jekyll과 같은 도구에서 사용되는 템플릿 언어로, 템플릿화된 컨텐츠를 생성하고 동적인 데이터를 처리하는 역할을 합니다.

CS 지식

컴파일러와 인터프리터의 차이

컴파일러와 인터프리터는 사람이 이해할 수 있는 언어인 프로그래밍 언어를 사용된 코드를 컴퓨터가 이해할 수 있는 기계어로 변환해주는 번역기 역할을 합니다. 두 도구의 차이는 다음과 같습니다.

1. 실행 방식:

   • 컴파일러: 소스 코드를 한 번에 모두 읽고 분석한 뒤, 중간 코드 또는 기계 코드로 변환합니다. 이 변환된 코드는 컴파일 과정 중에 생성되며, 실행 시에는 이 코드를 직접 실행합니다. 이것은 프로그램 실행 속도를 향상시킬 수 있습니다.
   • 인터프리터: 소스 코드를 한 줄씩 읽고 해석하여 실행합니다. 따라서 소스 코드가 실행되기 전에 중간 코드 또는 기계 코드로 변환되지 않으며, 코드를 직접 실행하는 동안 소스 코드를 해석합니다.

2. 속도와 성능:

   • 컴파일러: 컴파일된 코드는 실행 시간에 더 빠르게 실행될 수 있으므로 실행 속도가 빠를 수 있습니다. 그러나 컴파일 시간이 필요하며, 변경된 소스 코드를 적용하려면 다시 컴파일해야 합니다.
   • 인터프리터: 실행 시간에 소스 코드를 해석하므로 컴파일러에 비해 실행 속도가 느릴 수 있습니다. 그러나 코드 수정 및 디버깅이 더 편리하며, 소스 코드 변경 후 바로 실행할 수 있습니다.

3. 디버깅:

   • 컴파일러: 컴파일된 코드를 디버그하기 어려울 수 있으며, 디버그 정보가 소스 코드와 일치하지 않을 수 있습니다.
   • 인터프리터: 소스 코드를 직접 해석하므로 디버깅이 더 쉽고 직관적입니다. 디버그 정보가 소스 코드와 일치합니다.

4. 예시 언어:

   • 컴파일러: C, C++, Java, Rust 등
   • 인터프리터: Python, JavaScript, Ruby, PHP 등

문법, syntax 의미, semantics 자바스크립트에서는 문법적으로는 맞으나, 의미가 옳지 않은 경우가 있다.

/** number라는 변수에서 문자열이 할당되어서, 의미가 이상해짐 */
const number = 'string';

Ajax의 등장

1999년 자바스크립트를 이용해 서버와 브라우저 사이의 데이터를 비동기적으로 전달할 수 있는 기능인 Ajax가 XMLHttpRequest라는 이름의 객체를 사용하여 가능해졌습니다. 그 전에는 웹 사이트가 전체 웹 페이지를 렌더링하는 방식이었기 때문에, 불필요한 데이터 사용과 새로기침이 화면이 깜빡이는 현상이 있었죠.

Ajax가 등장한 후에는 변경이 필요한 부분에 대한 데이터만 전송받아 한정적으로 렌더링하게 되어, 효율적인 데이터 사용과 부드러운 화면 전환이 가능해졌습니다.

XMLHttpRequest

XMLHttpRequest는 JavaScript에서 사용되는 객체입니다. 이 객체를 사용하여 웹 페이지에서 비동기적으로 서버와 통신할 수 있습니다. XMLHttpRequest 객체를 사용하면 웹 페이지가 다시 로드되지 않고도 서버로 데이터를 보낼 수 있으며, 서버로부터 데이터를 받아와 웹 페이지를 업데이트할 수 있습니다. XMLHttpRequest는 클라이언트 측 웹 개발에서 서버와의 통신을 처리하는 핵심 도구 중 하나입니다.

Ajax (Asynchronous JavaScript and XML)

Ajax는 "Asynchronous JavaScript and XML"의 약자로, 클라이언트 측 웹 애플리케이션을 개발하는 데 사용되는 개념 및 기술 모음입니다. Ajax는 XMLHttpRequest 객체를 주로 사용하여 웹 페이지와 서버 간 비동기 통신을 구현하는 기술 중 하나입니다. 그러나 Ajax는 이것뿐만 아니라 JavaScript, HTML, CSS 등 다양한 기술과 함께 사용되어 웹 애플리케이션의 사용자 경험을 향상시키는 데 기여합니다. Ajax는 사용자의 입력에 반응하면서 서버로 데이터를 보내고 받아와 동적으로 웹 페이지를 업데이트하는 데 사용됩니다.

XMLHttpRequest 통신 과정

1. XMLHttpRequest 객체 생성: 먼저 XMLHttpRequest 객체를 생성합니다. 이것은 웹 브라우저 환경에서 제공하는 내장 객체입니다. 다음과 같이 생성할 수 있습니다.

   var xhr = new XMLHttpRequest();

2. 콜백 함수 설정: XMLHttpRequest 객체의 onreadystatechange 속성을 설정하여 서버 응답을 처리할 콜백 함수를 지정합니다. 이 콜백 함수는 서버 응답의 상태에 따라 호출됩니다.

   xhr.onreadystatechange = function () {
       if (xhr.readyState === 4 && xhr.status === 200) {
           // 서버 응답을 성공적으로 처리하는 코드
       }
   };

   여기서 readyState는 XMLHttpRequest의 상태를 나타내며, status는 서버 응답의 HTTP 상태 코드를 나타냅니다.

3. 요청 설정: XMLHttpRequest 객체의 open() 메서드를 사용하여 요청을 설정합니다. 이 메서드는 요청 메서드(GET, POST 등)와 요청할 URL을 지정합니다.

   xhr.open("GET", "https://api.example.com/data", true);

   세 번째 인자 true는 비동기 요청을 나타냅니다. true로 설정하면 요청이 비동기적으로 수행되며, 페이지의 다른 작업을 차단하지 않습니다.

4. 요청 전송: 요청을 서버로 보내려면 send() 메서드를 호출합니다.

   xhr.send();

   이로써 서버로 비동기 요청이 보내집니다.

5. 콜백 함수에서 응답 처리: onreadystatechange 콜백 함수 내부에서 서버 응답을 처리합니다. 이 함수는 readyState가 4(완료)이고 status가 200(성공)일 때 응답을 처리합니다. 예를 들어 xhr 객체의 responseText 속성을 이용해서 받아온 데이터를 활용할 수 있습니다.

   document.getElementById("text").innerHTML = xhr.responseText;

참조

모던 자바스크립트 Deep Dive

GitHub Pages는 정적 웹사이트 호스팅 서비스를 제공하는 플랫폼으로, GitHub 리포지토리에 있는 정적 파일들을 호스팅하여 웹사이트를 제공합니다. 이때 정적 파일은 HTML, CSS, JavaScript, 이미지 등과 같이 서버에서 추가적인 처리 없이 클라이언트 브라우저에서 직접 열람 가능한 파일들을 말합니다.

Jekyll은 정적 사이트 생성기로서, 마크다운 파일과 템플릿을 사용하여 웹사이트의 구조와 콘텐츠를 정의하고, 이를 빌드하여 정적 HTML 파일로 변환해줍니다. Jekyll은 개발자들이 웹사이트의 디자인, 레이아웃, 콘텐츠 등을 관리하고 갱신할 때 도움을 주는 역할을 합니다. GitHub Pages에서 Jekyll을 사용하면 빌드된 정적 HTML 파일들을 호스팅하여 웹사이트를 구동하게 됩니다.

즉, 지킬은 빌드 시 정적 파일을 생성해주고, 깃허브 페이지는 생성된 정적 파일을 실제로 웹 사이트로 들어가서 볼 수 있도록 호스팅해주는 역할을 합니다.

SSG(정적 사이트 생성기)를 사용해야 하는 이유

정적 사이트를 사용하지 않고도 웹 사이트를 구축할 수 있지만, SSG는 개발 및 유지보수의 편의성과 웹사이트의 성능 측면에서 여러 이점을 제공합니다.

정적 사이트 생성기를 사용하지 않을 경우

• 각각의 HTML 파일을 수동으로 작성해야 합니다.
• 콘텐츠와 디자인을 별도로 관리해야 하므로 유지보수가 어려울 수 있습니다.
• 동적인 요소를 구현하기 위해서는 서버 사이드 스크립팅 언어 (예: PHP, Node.js) 또는 클라이언트 사이드 JavaScript를 사용해야 합니다.
• 서버에서 콘텐츠를 렌더링하므로 서버 자원을 사용하게 됩니다.

정적 사이트 생성기를 사용할 경우

• 마크다운과 같은 간편한 마크업 언어를 사용하여 콘텐츠를 작성할 수 있습니다.
• 템플릿을 사용하여 일관된 디자인을 유지하고 쉽게 변경할 수 있습니다.
• 정적 사이트 생성기는 미리 빌드하여 정적 HTML 파일로 만들기 때문에 서버에 부담이 적습니다.
• 웹사이트를 배포할 때 웹 서버 구성이나 백엔드 코드 없이도 쉽게 배포할 수 있습니다.

시스템 전역과 개인 디렉토리 간의 차이는 주로 설치된 소프트웨어와 라이브러리가 어디에 위치하고 어떤 사용자가 접근할 수 있는지에 있습니다.

시스템 전역설치 vs 개인 디렉토리 설치

시스템 전역 (System Global) 설치: 시스템 전역 설치는 시스템 전체에서 사용 가능한 프로그램과 라이브러리를 설치하는 것을 말합니다. 즉, 모든 사용자가 접근할 수 있도록 시스템 레벨에 설치됩니다. 이는 시스템 전체의 소프트웨어를 관리하기 용이하고 모든 사용자가 일관된 환경을 사용할 수 있도록 도와줍니다.

개인 디렉토리 (User Directory) 설치: 개인 디렉토리 설치는 특정 사용자의 홈 디렉토리 내에 프로그램과 라이브러리를 설치하는 것을 말합니다. 각 사용자가 독립적으로 소프트웨어를 설치하고 관리할 수 있으며, 시스템 전체의 설정에 영향을 주지 않습니다.

시스템 전역 설치와 개인 디렉토리 설치의 차이:

• 권한: 시스템 전역 설치는 관리자 권한이 필요하며, 모든 사용자가 접근할 수 있습니다. 개인 디렉토리 설치는 해당 사용자만 접근 가능하고, 관리자 권한이 필요하지 않습니다.
• 환경 격리: 시스템 전역 설치는 모든 사용자가 같은 환경을 공유하므로 충돌이나 의존성 문제가 발생할 수 있습니다. 개인 디렉토리 설치는 각 사용자의 환경이 격리되어 충돌 가능성이 줄어듭니다.
• 보안: 시스템 전역 설치는 모든 사용자가 접근할 수 있기 때문에 보안에 취약할 수 있습니다. 개인 디렉토리 설치는 해당 사용자만 접근 가능하므로 상대적으로 보안성이 높습니다.

시스템 전역 설치를 권장하지 않는 이유:

1. 권한 문제: 시스템 전역 설치는 관리자 권한이 필요하며, 시스템 전체에 영향을 미칠 수 있어 실수로 중요한 시스템 파일을 수정할 수 있습니다.
2. 환경 격리와 충돌: 시스템 전역 설치는 다양한 소프트웨어 간의 충돌이나 의존성 문제가 발생할 수 있습니다.
3. 관리의 어려움: 다양한 소프트웨어의 버전 관리와 업그레이드가 복잡하며, 업데이트할 때 시스템 전체에 영향을 줄 수 있습니다.
4. 보안 취약점: 시스템 전역 설치된 소프트웨어의 보안 취약점은 시스템 전체에 영향을 미칠 수 있습니다.

개인 디렉토리 설치는 각 사용자의 필요에 맞게 소프트웨어를 관리하고, 시스템 전체에 영향을 덜 주며 보안성이 높기 때문에 일반적으로 권장됩니다.

분기된 브랜치

You have divergent branches and need to specify how to reconcile them.

브랜치들이 분기된 상태란, 로컬 브랜치와 원격 브랜치가 서로 다른 커밋을 가리키고 있는 상태를 의미합니다. 이렇게 되면 Git은 어떤 작업을 수행해야 할지 결정할 수 없으며, 어떤 방법으로 브랜치들을 조정할지 지정해야 합니다.

메시지에서 제안하는 대로, 이 문제를 해결하기 위해 git pull 명령을 실행하기 전에 어떤 방식으로 브랜치를 조정할지 설정할 수 있습니다. 아래와 같은 방법으로 설정할 수 있습니다:

1. Merge:

   git config pull.rebase false

   git pull을 실행하면 로컬 브랜치가 원격 브랜치를 병합하는 방식입니다. 새로운 병합 커밋이 생성되어 두 브랜치의 변경 내용을 합칩니다. 커밋 히스토리에 브랜치 병합 과정이 명확하게 기록됩니다.

2. Rebase:

   git config pull.rebase true

   git pull을 실행하면 로컬 브랜치의 변경 내용을 원격 브랜치 위로 옮깁니다. 로컬 브랜치의 커밋들을 재배치하며, 원격 브랜치의 최신 커밋 위에 쌓습니다. 커밋 히스토리가 선형적이고 깔끔해지는 경향이 있습니다. 원격 브랜치의 커밋과 로컬 브랜치의 변경 내용이 하나의 통합된 히스토리로 보입니다.

3. Fast-forward only:

   git config pull.ff only

   원격 브랜치가 로컬 브랜치보다 앞선 경우에만 허용됩니다. 로컬 브랜치가 원격 브랜치를 바로 앞으로 따라잡을 때만 사용됩니다. 로컬 브랜치의 변경 내용이 원격 브랜치를 업데이트하는 형태로 반영됩니다. 커밋 히스토리가 단순해집니다.

또한 이러한 설정을 전역적으로 모든 저장소에 적용하려면 --global 옵션을 사용하여 설정할 수 있습니다. 예를 들어:

git config --global pull.rebase true

커널(Kernel)

커널은 운영 체제의 핵심 부분으로, 하드웨어와 소프트웨어 간의 인터페이스 역할을 수행하는 중요한 컴퓨터 프로그램입니다. 주요 기능은 다음과 같습니다:

하드웨어 관리: 커널은 하드웨어 자원(프로세서, 메모리, 디스크, 네트워크 등)을 효율적으로 관리하고 할당합니다. 이를 통해 여러 응용 프로그램이 동시에 실행되는 멀티태스킹을 지원합니다.

시스템 콜: 커널은 응용 프로그램이 하드웨어를 조작할 수 있도록 인터페이스인 시스템 콜(System Call)을 제공합니다. 시스템 콜은 커널의 기능을 호출하는 방법을 제공하며, 응용 프로그램은 시스템 콜을 사용하여 하드웨어와 상호 작용합니다.

메모리 관리: 커널은 프로세스가 메모리를 효율적으로 할당하고 관리할 수 있도록 도와줍니다. 이를 통해 여러 프로세스가 안정적으로 메모리를 사용하고 충돌을 피할 수 있습니다.

파일 시스템 관리: 커널은 파일과 디렉토리를 관리하며, 응용 프로그램이 파일을 읽고 쓸 수 있도록 지원합니다.

쉘(Shell)

쉘은 사용자와 운영 체제 간의 인터페이스로서 명령어를 입력받아 실행하고 결과를 표시하는 환경을 제공합니다. 쉘은 텍스트 기반 인터페이스로 동작하며, 다양한 명령어와 기능을 제공합니다.

명령어 해석 및 실행: 사용자는 쉘에 명령어를 입력하면 쉘이 해당 명령어를 해석하고 실행합니다. 예를 들어, 파일을 생성하거나 삭제하는 명령어, 프로그램을 실행하는 명령어 등을 입력할 수 있습니다.

환경 제어: 쉘은 사용자의 작업 환경을 제어하는 기능을 제공합니다. 변수 설정, 환경 설정 파일 실행, 별칭 설정 등이 이에 해당합니다.

스크립트: 쉘은 스크립트 형태로 명령어를 저장하고 실행할 수 있습니다. 이를 통해 반복적인 작업을 자동화하거나 복잡한 작업을 처리할 수 있습니다.

zshrc

zshrc 파일은 Zsh 쉘(즉, Z Shell)의 환경 설정을 구성하는 파일입니다. Zsh는 Bourne 쉘과 호환되는 고급 쉘로, 다양한 기능과 확장성을 제공하는 대체 쉘 중 하나입니다. zshrc 파일은 Zsh가 시작될 때 실행되며 사용자 정의 설정, 환경 변수, 별칭 등을 지정할 수 있게 해줍니다.

zshrc 파일의 주요 역할은 다음과 같습니다:

1. 환경 변수 설정: zshrc 파일을 통해 환경 변수를 설정하거나 변경할 수 있습니다. 이를 통해 사용자의 작업 환경을 지정하거나 커스터마이즈할 수 있습니다.

2. 별칭 설정: 긴 명령어나 자주 사용하는 명령어를 간단한 단축어로 정의할 수 있는 별칭(alias)을 설정할 수 있습니다.

3. 경로 설정: 실행 파일이 위치한 경로를 설정하여, 특정 프로그램이나 스크립트를 어디서든 실행할 수 있도록 도와줍니다.

4. 테마 설정: Zsh 프롬프트의 외관과 색상을 변경하여 사용자 정의 프롬프트 테마를 생성할 수 있습니다.

5. 플러그인 및 확장 설정: Zsh는 다양한 플러그인과 확장을 지원합니다. zshrc 파일을 통해 이러한 확장 기능들을 설정하고 활성화할 수 있습니다.

6. 함수 정의: 사용자 정의 함수를 zshrc 파일에 정의하여, 특정 작업을 자동화하거나 사용자 편의성을 높일 수 있습니다.

일반적으로 사용자의 홈 디렉토리에 .zshrc라는 이름의 숨겨진 파일로 저장됩니다. 수정한 설정은 Zsh 쉘을 다시 시작하거나 source ~/.zshrc 명령을 통해 적용할 수 있습니다. zshrc 파일을 편집하여 Zsh 쉘을 사용자에게 맞게 설정하고 최적화할 수 있습니다.

rc(run command) : 프로그램이나 시스템에서 실행되는 초기화나 설정 명령들을 담고 있는 파일의 확장자 config(configuration) : 다양한 설정 항목과 값들을 정의하여 프로그램이나 시스템의 동작을 조정하는 데 사용

컴퓨터 구성요소

하드웨어 - 커널 - 쉘 - 사용자

하드웨어 (Hardware)

컴퓨터 시스템의 물리적인 부분으로, 프로세서(CPU), 메모리(RAM), 저장장치(하드 디스크, SSD 등), 입출력 장치(모니터, 키보드, 마우스 등) 등이 포함됩니다.

커널 (Kernel)

커널은 운영 체제의 핵심 부분으로, 하드웨어와 소프트웨어 간의 인터페이스 역할을 합니다. 하드웨어를 관리하고 프로세스 스케줄링, 메모리 관리, 파일 시스템 관리 등의 역할을 수행합니다. 커널은 하드웨어의 저수준 기능에 접근하여 시스템 동작을 조정합니다.

쉘 (Shell)

쉘은 사용자와 운영 체제 간의 인터페이스 역할을 합니다. 사용자가 명령어를 입력하면 쉘이 해당 명령어를 해석하고 실행합니다. 쉘은 사용자 정의 설정, 환경 변수, 별칭, 스크립트 등을 지원하여 사용자와 시스템 간의 상호 작용을 도와줍니다.

사용자 (User)

사용자는 컴퓨터 시스템을 사용하는 사람이나 응용 프로그램을 의미합니다. 사용자는 쉘을 통해 시스템 명령어를 입력하거나 응용 프로그램을 실행하여 컴퓨터를 활용합니다.

이렇게 구조화된 시스템은 사용자가 하드웨어를 직접 다루지 않고도 쉘을 통해 운영 체제를 조작하고 프로그램을 실행할 수 있게 해주는 구조입니다.

JSON Server는 개발 및 프로토타이핑을 위한 가상 REST API를 생성하는 도구입니다. 이를 사용하면 간단한 JSON 파일로 가짜 API를 만들어서 데이터를 관리하고 응답을 제공할 수 있습니다. 주로 프론트엔드 개발자들이 프론트엔드 애플리케이션을 개발하는 동안 백엔드와 협업하지 않고도 가상의 API를 생성하여 테스트하고 개발할 수 있도록 도와줍니다.

JSON Server를 사용하면 다음과 같은 작업을 할 수 있습니다:

1. 가상 API 서버 구축: JSON 파일을 데이터 소스로 사용하여 가상의 API 서버를 생성할 수 있습니다. 이를 통해 실제 백엔드 없이도 프론트엔드 개발을 진행할 수 있습니다.

2. 데이터 조작: JSON 파일을 수정하면서 데이터를 추가, 수정, 삭제할 수 있습니다. JSON Server는 변경된 내용을 가상의 REST API로 노출하여 프론트엔드 애플리케이션에서 사용할 수 있도록 합니다.

3. 라우팅 설정: JSON Server를 사용하여 다양한 엔드포인트를 생성하고 라우팅을 설정할 수 있습니다. 이를 통해 다양한 RESTful API 엔드포인트를 시뮬레이션할 수 있습니다.

4. 필터링 및 정렬: JSON Server는 쿼리 문자열을 사용하여 데이터를 필터링하거나 정렬하는 기능을 제공합니다. 이를 통해 데이터 검색과 정렬을 시뮬레이션할 수 있습니다.

5. 인증 및 인가 시뮬레이션: JSON Server는 미들웨어를 사용하여 사용자 인증과 인가를 시뮬레이션할 수 있는 기능을 제공합니다.

JSON Server는 주로 프로토타이핑이나 개발 초기 단계에서 사용되며, 실제 운영 환경에서는 보다 실제적인 백엔드 서버를 사용하는 것이 바람직합니다.

CS 지식

OSI(Open System Interconnection)

OSI (Open Systems Interconnection) 모델은 네트워크 프로토콜 아키텍처의 개념적인 구조를 정의한 것으로, 7개의 계층으로 나누어져 있습니다. 각 계층은 특정한 역할과 기능을 수행하며, 데이터의 흐름과 처리 방식을 추상화하여 표준화하고 상호 운용성을 확보하는 데 사용됩니다.

아래는 OSI 7 계층의 각 계층과 그 역할에 대한 간략한 설명입니다:

1. 물리 계층 (Physical Layer):

   • 물리적인 연결과 전송을 담당합니다.
   • 전기적, 기계적, 기능적인 특성에 관련된 규격을 정의하며, 비트 스트림을 전기 신호로 변환합니다.
   • 주요 기술: 전기적 특성, 케이블, 허브 등

2. 데이터 링크 계층 (Data Link Layer):

   • 프레임의 오류 검출 및 수정, 흐름 제어, 매체 액세스 제어 등을 수행합니다.
   • MAC 주소를 사용하여 로컬 네트워크에서 통신합니다.
   • 주요 기술: 이더넷, 스위치, 브리지 등

3. 네트워크 계층 (Network Layer):

   • 경로 선택과 라우팅, 패킷 전달을 담당합니다.
   • IP 주소와 같은 논리적 주소를 사용하여 여러 네트워크 간의 통신을 관리합니다.
   • 주요 기술: IP, 라우터 등

4. 전송 계층 (Transport Layer):

   • 데이터 전송의 신뢰성과 효율성을 보장하며, 오류 복구와 흐름 제어를 수행합니다.
   • 포트 번호를 사용하여 애플리케이션 간의 연결을 관리합니다.
   • 주요 기술: TCP, UDP 등

5. 세션 계층 (Session Layer):

   • 데이터 교환의 세션을 설정, 유지 및 해제합니다.
   • 데이터의 동기화와 대화 관리를 제공합니다.
   • 주요 기술: RPC, NetBIOS 등

6. 표현 계층 (Presentation Layer):

   • 데이터 형식 변환, 암호화, 압축 등을 수행하여 상호 운용성을 제공합니다.
   • 데이터를 표현하고 변환하여 애플리케이션 계층으로 전달합니다.
   • 주요 기술: JPEG, GIF, SSL 등

7. 응용 계층 (Application Layer):

   • 최종 사용자에게 서비스를 제공하며, 네트워크 프로토콜을 사용하여 데이터를 주고받습니다.
   • 사용자 인터페이스, 이메일, 파일 전송 등의 서비스를 포함합니다.
   • 주요 기술: HTTP, FTP, SMTP 등

이러한 7개의 계층은 각자 독립적인 기능을 수행하며, 네트워크 통신에서 데이터의 흐름과 처리 방식을 표준화하여 상호 연결성과 통합성을 확보하는 데 사용됩니다.

SSL -> TLS

SSL (Secure Sockets Layer)과 TLS (Transport Layer Security)는 모두 보안 프로토콜로, 데이터 통신의 기밀성과 무결성을 보장하기 위해 사용됩니다. 초기에는 SSL이 사용되었으나, 보안 결함 및 취약점이 발견되어 TLS가 SSL의 후속 버전으로 개발되었습니다. TLS는 현재 널리 사용되는 보안 프로토콜이며, SSL은 안전하지 않다고 간주되어 거의 사용되지 않습니다.

주요 차이점과 특징은 다음과 같습니다:

1. SSL (Secure Sockets Layer):

   • 초기 보안 프로토콜로서, 1990년대 중반에 개발되었습니다.
   • SSL 2.0, SSL 3.0 등 여러 버전이 나왔지만, 보안 결함과 취약점이 발견되어 사용이 중단되었습니다.
   • 현재 SSL은 보안 결함으로 인해 사용이 권장되지 않습니다.

2. TLS (Transport Layer Security):

   • SSL의 취약점을 개선하여 만든 후속 프로토콜입니다.
   • TLS 1.0, TLS 1.1, TLS 1.2, TLS 1.3 등 여러 버전이 개발되었습니다.
   • TLS 1.2와 TLS 1.3은 현재 가장 많이 사용되며, 보안 향상과 성능 개선을 제공합니다.
   • TLS 1.3은 더 나은 보안과 빠른 핸드셰이크 프로세스를 제공하여 더욱 안전한 통신을 지원합니다.

TLS는 데이터 통신을 보호하기 위해 공개키 암호화와 대칭키 암호화 등 다양한 보안 기법을 사용합니다. 주로 웹 브라우저와 웹 서버 간의 통신을 보호하는 데 사용되며, HTTPS (HTTP Secure) 프로토콜의 기반이 됩니다. HTTPS는 웹 사이트에서 제공되는 데이터의 기밀성과 무결성을 보장하여 사용자 정보와 민감한 데이터의 안전성을 확보하는 데 중요한 역할을 합니다.

TLS를 통해 데이터 통신을 암호화하고 보호함으로써 중간자 공격(MITM, Man-in-the-Middle)과 같은 보안 위협으로부터 사용자와 서버 간의 통신을 안전하게 유지할 수 있습니다.

IP(Internet Protocol)

인터넷 프로토콜 (Internet Protocol, IP)은 컴퓨터 네트워크에서 데이터를 전달하고 라우팅하는 데 사용되는 통신 프로토콜입니다. IP는 인터넷의 기본 프로토콜로서, 데이터를 작은 패킷으로 나누어 전송하고, 각 패킷에는 출발지와 목적지 IP 주소가 포함됩니다. IP는 OSI 7 계층 모델에서 네트워크 계층에 속하며, 주로 IP 주소를 사용하여 호스트 및 네트워크 간의 식별과 라우팅을 수행합니다.

IP의 주요 특징과 개념은 다음과 같습니다:

1. IP 주소: 각 컴퓨터와 네트워크는 고유한 IP 주소를 갖습니다. IP 주소는 네트워크 식별과 호스트 식별을 포함하며, IPv4에서는 32비트 숫자로 표현되고, IPv6에서는 128비트 길이의 16진수로 표현됩니다.

2. 패킷 기반 통신: 데이터는 작은 패킷으로 분할되어 전송됩니다. 각 패킷에는 출발지와 목적지 IP 주소, 데이터 조각 등의 정보가 포함됩니다. 이 패킷 기반 통신은 네트워크 상태에 따라 패킷이 다양한 경로로 전달되는 장점을 가집니다.

3. 라우팅: IP 패킷은 네트워크 간에 라우팅되어 목적지에 도달합니다. 라우터는 패킷의 목적지 IP 주소를 기반으로 최적의 경로를 선택하여 패킷을 전달합니다.

4. IPv4와 IPv6: 초기에는 IPv4가 주로 사용되었으나, IP 주소 고갈 문제와 인터넷 확장에 따라 IPv6가 도입되었습니다. IPv6는 더 많은 IP 주소를 제공하고 보안 기능을 강화한 버전입니다.

5. 서비스 타입 및 헤더: IP 헤더에는 패킷의 서비스 타입, 프로토콜 정보 등이 포함됩니다. 이 헤더는 라우팅 및 데이터 전달을 위한 필수 정보를 포함합니다.

IP는 인터넷의 핵심 프로토콜로서, 데이터의 전달과 라우팅을 가능하게 하여 전 세계의 컴퓨터와 네트워크가 연결되어 있는 기반을 제공합니다. 하지만 단순한 데이터 전달에만 사용되므로 보안과 신뢰성 측면에서 추가적인 기술과 프로토콜이 필요합니다.

github pages 정적 사이트 만들기

git repository name을 <깃허브 아이디>.github.io로 설정해야만 사이트의 도메인이 <깃허브 아이디>.github.io로 예쁘게 구성됩니다.

만약 레파지토리 이름을 다른 것으로 설정하게 되면, <깃허브 아이디>.github.io/<레파지토리 이름> 처럼 어색한 url로 생성되기 때문에 주의해야 합니다. 혹시 이렇게 생성했더라도, 이름을 다시 수정하면 정상적으로 변경되기 때문에 걱정하지 않아도 됩니다.

Jekyll

Jekyll은 정적 웹사이트 생성기(Static Site Generator)로, 웹사이트를 만들고 관리하기 위한 도구입니다. Jekyll을 사용하면 마크다운(Markdown)이나 HTML 등의 텍스트 파일과 템플릿을 사용하여 웹사이트를 구축할 수 있습니다. Jekyll은 웹사이트를 미리 빌드하고, 이를 정적인 HTML 파일로 변환하여 제공함으로써 동적인 서버 측 처리 없이 웹사이트를 구동할 수 있도록 도와줍니다.

Jekyll의 주요 특징과 동작 방식은 다음과 같습니다:

1. 마크다운을 활용한 내용 작성: Jekyll은 Markdown과 같은 마크업 언어로 콘텐츠를 작성할 수 있습니다. 이는 개발자와 작성자 모두에게 쉽고 편리한 방식으로 콘텐츠를 관리할 수 있도록 도와줍니다.

2. 템플릿과 레이아웃: Jekyll은 템플릿과 레이아웃을 사용하여 웹사이트의 일관된 디자인과 구조를 유지할 수 있습니다. 레이아웃은 공통적으로 사용되는 헤더, 푸터 등의 요소를 정의하고, 콘텐츠 페이지는 해당 레이아웃에 삽입됩니다.

3. 데이터 파일 사용: Jekyll은 데이터 파일을 사용하여 웹사이트의 동적인 요소를 처리할 수 있습니다. 예를 들어, JSON 또는 YAML 파일을 사용하여 변수를 정의하고 템플릿에서 이 변수들을 활용할 수 있습니다.

4. 플러그인 지원: Jekyll은 다양한 플러그인을 제공하며, 이를 통해 이미지 최적화, 자동화된 태그 생성, 검색 엔진 최적화 등의 작업을 수행할 수 있습니다.

5. GitHub Pages와의 통합: Jekyll은 GitHub Pages에서 공식적으로 지원되는 정적 웹사이트 생성기 중 하나입니다. GitHub Pages를 사용하면 GitHub 리포지토리에 Jekyll 웹사이트를 호스팅할 수 있습니다.

Jekyll을 사용하면 웹사이트를 보다 간결하고 빠르게 구축할 수 있으며, 블로그, 개인 웹사이트, 문서 사이트 등 다양한 종류의 웹사이트를 만들 수 있습니다. Jekyll은 Ruby 언어로 개발되었으며, 커맨드 라인 인터페이스를 통해 사용자가 웹사이트를 생성, 빌드, 테스트할 수 있습니다.

tsconfig.json

타입스크립트 컴파일러의 동작을 설정하는 '설정 파일'로서, 컴파일 시 어떤 옵션을 사용하고 어떤 파일을 포함 또는 제외할지를 정의합니다. 파일 확장자 그대로 json 형태로 작성되어 있습니다.

{
/** typescript compiler 옵션 정의 */
  "compilerOptions": {
    /** 컴파일할 ECMAScript 버전 */
    "target": "es5",
    /** 컴파일 시 사용할 라이브러리 */
    "lib": ["dom", "dom.iterable", "esnext"],
    /** 컴파일 시 js 파일 포함 여부 */
    "allowJs": true,
    /** 선언 파일 유효성 검사 스킵 여부 */
    "skipLibCheck": true,
    /** 엄격한 타입 검사 여부 설정 */
    "strict": true,
    /** 파일 이름의 대소문자 형식 일관성 강제 여부 */
    "forceConsistentCasingInFileNames": true,
    /** 컴파일 후 JS 파일 생성하지 않음 여부 */
    "noEmit": true,
    /** CommonJS 모듈 및 ES6 모듈 간의 상호운용성 설정 */
    "esModuleInterop": true,
    /** 컴파일된 코드가 어떤 모듈 시스템을 사용할지 */
    "module": "esnext",
    /** 모듈 해결 전략 지정(node, classic, bundler) */
    "moduleResolution": "bundler",
    /** json 파일을 모듈처럼 불러와서 사용할지의 여부 */
    "resolveJsonModule": true,
    /** 파일 간의 의존성 강제 분리 여부 */
    "isolatedModules": true,
    /** JSX 구문 처리 방식 */
    "jsx": "preserve",
    /** 증분 컴파일 옵션 설정 */
    "incremental": true,
    /** TS 컴파일러 플러그인 설정 */
    "plugins": [
      {
        "name": "next"
      }
    ],
    /** 모듈을 해결하기 위한 경로 별칭 설정 */
    "paths": {
      "@/*": ["./src/*"]
    }
  },
  /** 컴파일에 포함될 파일 경로 설정 */
  "include": ["next-env.d.ts", "**/*.ts", "**/*.tsx", ".next/types/**/*.ts"],
  /** 컴파일에 제외할 파일 경로 설정 */
  "exclude": ["node_modules"]
}

선언 파일(Declaration File)

타입스크립트의 선언 파일은 .d.ts 확장자를 가진 파일을 의미합니다. JS는 동적 언어로 정적인 타입 정보가 부족한 경우가 많으므로, 타입스크립트 컴파일을 위해 코드 또는 외부 라이브러리의 타입 정보를 정의해주는 선언 파일을 사용합니다.

CommonJS vs. ES6(ECMAScript2015)

CommonJS와 ES6 (ECMAScript 2015)는 둘 다 모듈 시스템의 다른 접근 방식을 나타냅니다. 이 두 가지 모듈 형식은 JavaScript 코드를 구조화하고 모듈화하는 데 사용됩니다.

Node.js에서는 기본적으로 CommonJS 모듈 시스템을 사용합니다. CommonJS는 Node.js에서 모듈을 정의하고 가져오는 데 사용되며, require 함수와 module.exports 객체를 사용하여 모듈을 정의하고 공유합니다.

// 모듈 가져오기
const myModule = require('./myModule');

// 모듈 정의하기
module.exports = {
  // 모듈 내용
};

반면에 ES6에서는 ECMAScript 2015부터 도입된 모듈 시스템을 사용할 수 있습니다. ES6 모듈 시스템은 import와 export 키워드를 사용하여 모듈을 가져오고 내보냅니다. 웹 개발에서는 주로 ES6 방식을 사용합니다.

// 모듈 가져오기
import myModule from './myModule';

// 모듈 내보내기
export default {
  // 모듈 내용
};

AMD(Asynchronous Module Definition)

AMD(Asynchronous Module Definition)는 JavaScript 모듈을 비동기적으로 정의하고 로드하기 위한 모듈 형식 중 하나입니다. CommonJS와 함께 모듈 시스템의 중요한 대안 중 하나로 등장한 개념입니다.

AMD는 주로 웹 브라우저 환경에서 사용되며, 주요 목표 중 하나는 웹 페이지의 로딩과 성능을 향상시키는 것입니다. 특히 브라우저에서 여러 모듈을 비동기적으로 로드할 때 발생하는 의존성 문제를 해결하기 위해 개발되었습니다.

AMD의 특징은 다음과 같습니다:

1. 비동기 로딩: 모듈을 비동기적으로 로드하므로, 의존성을 해결하기 위해 브라우저가 기다리지 않습니다. 이로 인해 페이지 로딩 성능이 향상됩니다.
2. 정의 및 사용 분리: 모듈을 정의할 때 사용될 코드와 실제 모듈을 사용하는 코드가 분리됩니다.
3. 모듈 로더: AMD는 모듈 로더(Loader) 라이브러리를 사용하여 모듈을 로드하고 의존성을 해결합니다. RequireJS가 가장 널리 사용되는 AMD 모듈 로더입니다.
4. define 함수: define 함수를 사용하여 모듈을 정의하고 의존성을 명시합니다.

AMD의 기본적인 사용 예시는 아래와 같습니다:

// 모듈 정의
define(['dependency'], function(dependency) {
  // 모듈 코드
  return module;
});

// 모듈 사용
require(['myModule'], function(myModule) {
  // 모듈 사용 코드
});

AMD는 주로 브라우저 환경에서 모듈을 로드하고 비동기적으로 사용해야 할 때 유용합니다. 하지만 CommonJS와 비교했을 때 문법이 더 복잡하고, Node.js와 같은 서버 사이드 환경에서는 사용되지 않는 특징이 있습니다. 이런 이유로 Node.js에서는 주로 CommonJS가 사용됩니다.

Bundler

번들러의 주요 목적은 여러 개의 파일을 하나의 번들로 묶어서 웹 애플리케이션의 로딩 성능을 최적화하는 것입니다. 번들러는 여러 개의 모듈이나 파일 간의 의존성을 파악하고, 필요한 모든 코드를 하나의 번들 파일로 결합하여 최종 사용자가 로딩할 때 필요한 리소스 양을 줄입니다.

Webpack은 이러한 번들링 작업을 수행하는 대표적인 도구 중 하나입니다. Webpack은 다양한 모듈 시스템을 지원하며, 주로 ES6 모듈과 CommonJS를 다룹니다. Webpack은 의존성 그래프를 분석하여 필요한 모듈을 찾아 번들로 묶고, 코드 압축, 트랜스파일링, 이미지나 스타일 등의 리소스 관리도 함께 수행합니다.

웹 사이트 렌더링 시 로드해주는 기능뿐만 아니라, 번들링을 통해 브라우저에 전달되는 파일의 수를 줄여서 초기 로딩 속도를 향상시키는 것이 주요한 목적입니다. 번들러를 사용하면 여러 개의 파일을 하나의 파일로 결합하고, 필요한 코드만 불러오는 등 최적화된 방식으로 웹 애플리케이션의 성능을 향상시킬 수 있습니다.

Routing path 구성요소

ex) https://domain/path(segment/segment/...) url에서 domain 다음에 나오는 요소를 path라고 하며, path를 구성하고 있는 각 요소를 segment라고 합니다.

URL(Uniform Resource Locator)

URL은 웹에서 리소스의 주소를 나타내는 문자열입니다.

https://www.example.com:8080/path/to/resource?param1=value1&param2=value2#section3

프로토콜/도메인(또는 ip주소)/포트번호/path(세그먼트로 구성)/쿼리스트링/프래그먼트

• 프로토콜 - https://
• 도메인 - www.example.com
• 포트번호 - 8080
• 경로(세그먼트로 구성) - /path/to/resource
• 쿼리스트링(?로 시작하고, &로 구분함, 키=밸류 형식) - param1=value1&param2=value2
• 프래그먼트(특정 위치 표시) - #section3

URI

URI(Uniform Resource Identifier)은 URL(Uniform Resource Locator)과 URN(Uniform Resource Name)을 포함하는 상위 개념입니다. 리소스의 고유한 식별자를 나타내는 통합된 형식을 의미합니다.

URN은 리소스가 위치에 의존하지 않고, 리소스 이름 자체를 고유한 식별자로 사용하는 것입니다. 예를 들어, "urn:isbn:0451450523"는 책의 ISBN 번호를 URN으로 나타낸 예시입니다.

a 태그 vs. Link 태그

<a> 태그는 외부 URL 또는 다른 페이지로 이동시 사용하며, 클릭 시 전체 페이지 리로딩이 발생하여 서버 요청을 보내고 전체 페이지를 새로 리로드합니다. 따라서 server side rendering이 사용되고, 전체 페이지 컨텐츠를 로드하기 때문에 성능이 저하될 수 있습니다.

<Link> 컴포넌트는 Next.js에서 제공하는 라우팅 기능을 활용하여 페이지 간의 네비게이션을 처리하는 데 사용됩니다. 페이지 간 전환 시, 서버 요청이 발생하지 않기 때문에 빠른 속도와 깔끔한 사용자 경험이 가능합니다. 오직 애플리케이션 내부에서 페이지 전환 시 필요한 자원만 로드됩니다.

여기서 next.js는 브라우저의 주소만 변경하고, 변경된 주소에 따라 필요한 컴포넌트만 렌더링하여 클라이언트 사이드 라우팅을 구현합니다. 이를 통해 변경이 필요한 부분만 실제 DOM 조작을 통해 업데이트하며 전체 페이지 리로딩을 방지하여 성능을 향상시킵니다.

브라우저의 뒤로가기/앞으로가기 기능을 통해 이전 페이지와 현재 페이지 간의 차이를 비교하고, 변경이 필요한 컴포넌트만 다시 렌더링하여 이를 '앱 쉘(Application Shell)'이라고 하는 가벼운 프레임워크로 구성합니다. 이런 방식은 사용자 경험을 향상시키고 성능을 개선하는 데 도움이 됩니다.

타입스크립트 제네릭

타입스크립트 제네릭은 코드를 더 유연하고 재사용 가능하게 만들어주는 기능입니다. 제네릭은 함수, 클래스, 인터페이스 등에서 사용되며, 동적인 타입을 사용할 때 유용합니다. 제네릭을 사용하면 타입을 추상화하여 여러 종류의 타입에서 동작할 수 있는 함수나 컴포넌트를 작성할 수 있습니다.

제네릭을 사용하는 주요 이점은 다음과 같습니다:

1. 재사용성과 유연성: 제네릭을 사용하면 함수나 클래스를 여러 타입에서 재사용할 수 있습니다. 같은 로직을 다양한 타입에 대해 적용할 수 있습니다.

2. 타입 안정성: 제네릭을 사용하면 코드 내부에서 타입 안정성을 유지하면서도 여러 타입을 다룰 수 있습니다. 컴파일러가 타입 검사를 수행하므로 런타임 에러를 방지할 수 있습니다. 만약 매개변수로 들어올 데이터의 타입이 정해지지 않았다고 any를 사용하면, '모든 타입을 허용한다'는 뜻이기 때문에, 타입 오류를 검출할 수 없습니다.

3. 타입 추론: 제네릭을 사용하면 컴파일러가 입력된 값의 타입을 추론하여 유추할 수 있습니다.

제네릭은 <T>와 같이 꺾쇠 괄호 내에 타입 변수를 선언하는 방식으로 사용됩니다. 일반적으로 T는 타입 변수의 이름으로 많이 사용되지만, 어떤 이름도 사용할 수 있습니다.

예를 들어, 아래는 제네릭을 사용하여 배열의 요소를 역순으로 반환하는 함수를 작성한 예시입니다:

function reverseArray<T>(array: T[]): T[] {
  return array.reverse();
}

const numbers = [1, 2, 3, 4, 5];
const reversedNumbers = reverseArray(numbers); // [5, 4, 3, 2, 1]

const strings = ["apple", "banana", "cherry"];
const reversedStrings = reverseArray(strings); // ["cherry", "banana", "apple"]

위 코드에서 reverseArray 함수는 배열의 타입에 따라 동작합니다. 이 함수는 숫자 배열이든 문자열 배열이든 역순으로 반환할 수 있으며, 여러 타입에서 재사용할 수 있습니다.

참조링크

생활코딩 Next.js 13 - 5. 라우팅

align-items

align-items 속성은 Flex 컨테이너 내의 모든 아이템들의 수직 정렬 방식을 설정합니다. 이 속성은 아이템들을 단일 행(row) 또는 열(column) 내에서 수직 정렬하는 데 사용됩니다.

• flex-start: 아이템들을 컨테이너의 시작 부분에 정렬합니다.

• flex-end: 아이템들을 컨테이너의 끝 부분에 정렬합니다.

• center: 아이템들을 수직 중앙에 정렬합니다.

• baseline: 아이템들을 텍스트의 베이스라인에 정렬합니다.

• stretch: 아이템들을 컨테이너의 높이에 맞게 늘립니다.

  align-content

  align-content 속성은 여러 행 또는 여러 열로 구성된 Flex 컨테이너 내에서 행 또는 열의 간격과 수직 정렬 방식을 설정합니다. 이 속성은 컨테이너 내의 여러 줄의 아이템들을 조작하는 데 사용됩니다.

• flex-start: 행 또는 열을 컨테이너의 시작 부분에 정렬합니다.

• flex-end: 행 또는 열을 컨테이너의 끝 부분에 정렬합니다.

• center: 행 또는 열을 수직 중앙에 정렬합니다.

• space-between: 아이템들 사이의 간격을 동일하게 조절하여 정렬합니다.

• space-around: 아이템들 주위의 간격을 동일하게 조절하여 정렬합니다.

• space-evenly: 아이템들 주위의 간격을 균등하게 조절하여 정렬합니다.

• stretch: 행 또는 열을 컨테이너의 높이에 맞게 늘립니다.

위 두 속성의 가장 큰 차이는 align-items는 단일 행 또는 열에서 수직 정렬을 담당하고, align-content는 여러 행 또는 여러 열로 구성된 컨테이너의 행 또는 열 간의 수직 정렬을 담당한다는 것입니다. 따라서 align-content 속성은 flex-wrap을 이용해서 여러 행 또는 열이 생성된 후에 적용이 가능합니다.

align-self

각 항목 별로 하나씩 적용하고 싶을 때, 사용하는 속성입니다.

정렬 적용 기준 -content : 여러 열 또는 여러 행 -items : 하나의 열 또는 하나의 행 -self : 하나의 항목에 각각 적용

Reset CSS & Normalize CSS

Reset CSS는 브라우저의 기본 스타일을 완전히 제거하고 초기화하는 스타일시트입니다. 브라우저 간의 기본 스타일 차이로 인해 웹 페이지가 일관성 없이 보일 수 있는 문제를 해결하기 위해 사용됩니다. 예를 들어, 헤딩(Heading) 요소의 크기, 목록 스타일, 여백 등의 스타일을 초기화하여 일관된 디자인을 구현할 수 있습니다.

Reset CSS의 목적은 모든 HTML 요소에 대한 기본 스타일을 제거하고, 개발자가 원하는 스타일을 완전히 커스터마이즈할 수 있는 기반을 제공하는 것입니다. 대표적인 Reset CSS로는 Eric Meyer's Reset, Normalize.css의 Reset 스타일 등이 있습니다.

Normalize CSS는 브라우저 간의 일관성 있는 스타일을 유지하면서 HTML 요소의 기본 스타일을 초기화하는 스타일시트입니다. Normalize CSS는 브라우저 스타일의 차이를 최소화하면서 웹 페이지를 일관성 있게 보이도록 보완하는 데 초점을 둡니다.

Normalize CSS는 HTML5 요소의 스타일을 정의하고, 버튼 스타일, 입력 요소 스타일, 목록 스타일 등을 정규화하여 브라우저 간 차이를 보완합니다. 그리고 웹 페이지가 브라우저에 따라 동일한 모습으로 나타날 수 있도록 돕습니다.

Reset CSS는 브라우저 기본 스타일을 완전히 제거하여 완전한 커스터마이즈를 제공하며, Normalize CSS는 일관성 있는 스타일을 유지하면서 브라우저 간의 스타일 차이를 보완하는 역할을 합니다.

SDK(Software Development Kit)

소프트웨어 개발 도구 모음으로, 개발자들이 특정 플랫폼, 언어, 기술, 프레임워크 등을 활용하여 소프트웨어 애플리케이션을 개발하는 데 도움을 주는 도구 모음입니다. SDK는 필요한 라이브러리, API(응용 프로그램 인터페이스), 문서, 샘플 코드, 디버깅 도구 등을 포함할 수 있습니다.

웹뷰(webview) & Native

WebView

모바일 앱 내에서 웹 페이지를 표시하는 컴포넌트입니다. 쉽게 말해, 앱 안에서 웹 브라우저를 내장하는 것으로, 웹 기술을 사용하여 앱의 일부분을 개발하는 방식입니다. WebView를 사용하면 웹 페이지를 렌더링하고 HTML, CSS, JavaScript를 활용하여 앱의 화면을 구성할 수 있습니다.

웹 기술을 활용하여 웹 개발자들이 빠르게 앱을 개발할 수 있으며, 크로스 플랫폼 호환성이 뛰어나, 한번의 개발로 iOS, Android에 동일한 화면을 구성할 수 있습니다.

Native

최적화된 성능: 특정 플랫폼에 최적화된 코드를 사용하기 때문에 성능이 우수합니다. 네이티브 기능 활용: 각 플랫폼의 고유한 기능을 활용할 수 있습니다. 뛰어난 UI/UX: 각 플랫폼에 맞게 디자인된 UI를 구현할 수 있습니다.

플랫폼 별로 앱을 개발해야 하기 때문에, 개발 시간과 비용이 증가할 수 있습니다. 대신 뛰어난 성능과 고유 기능을 잘 활용할 수 있습니다.

가상 element after, before

CSS에서 ::before와 ::after는 가상 엘리먼트(pseudo-elements)로, HTML 요소의 내용(content) 앞이나 뒤에 콘텐츠를 생성하거나 스타일을 적용할 때 사용됩니다. 이러한 가상 엘리먼트를 사용하면 실제 HTML 구조를 변경하지 않고도 시각적인 효과를 만들 수 있습니다.

/* 예시 */
.element::before {
  content: "Before content";
  /* 추가적인 스타일링을 적용할 수 있습니다 */
}

.element::after {
  content: "After content";
  /* 추가적인 스타일링을 적용할 수 있습니다 */
}

이외의 가상 엘리먼트

1. ::first-line: 선택한 요소의 첫 번째 줄에 스타일을 적용합니다. 주로 글자 스타일링에 사용됩니다.

2. ::first-letter: 선택한 요소의 첫 번째 글자에 스타일을 적용합니다. 주로 드랍캡(첫 글자 큰 스타일) 효과를 만들 때 사용됩니다.

3. ::selection: 텍스트 선택 영역에 스타일을 적용합니다. 예를 들어, 사용자가 텍스트를 드래그해서 선택하는 부분에 배경색이나 글자색을 변경할 수 있습니다.

4. ::placeholder: 입력 필드의 placeholder 텍스트에 스타일을 적용합니다. 입력 필드에 사용자가 아무것도 입력하지 않았을 때 표시되는 텍스트입니다.

5. ::marker: 목록 요소의 마커(숫자나 불릿)에 스타일을 적용합니다.

6. ::backdrop: 모달 창과 같은 배경 뒷면의 스타일을 정의합니다.

css 속성

box-sizing은 CSS 속성 중 하나로, 요소의 크기를 계산하는 방식을 지정하는 데 사용됩니다. HTML 요소의 크기는 기본적으로 해당 요소의 내용(content), 패딩(padding), 테두리(border), 그리고 마진(margin)의 합으로 결정됩니다.

content-box (기본값)

이 값은 요소의 크기를 내용(content) 영역만을 기준으로 계산합니다. 즉, 패딩, 테두리, 마진을 크기 계산에서 제외하고 내용 영역만을 고려합니다. 따라서 패딩과 테두리, 마진은 요소의 크기를 증가시키지 않습니다.

border-box

이 값은 요소의 크기를 테두리(border)까지 포함한 영역을 기준으로 계산합니다. 즉, 내용(content) 영역과 패딩(padding), 테두리(border)를 함께 고려하여 요소의 전체 크기를 결정합니다. 이 경우 패딩과 테두리, 마진은 요소의 크기를 증가시킵니다.

따라서 기본 속성인 content-box으로 설정되어 있을 땐, 포함된 padding 값을 고려해서 width 등을 설정해줘야 합니다.

Flex and Grid

CSS Flexbox (유연한 박스 모델)

CSS Flexbox(Flexible Box Layout)은 1차원(한 방향) 레이아웃을 만들 때 사용됩니다. 주로 행(row) 또는 열(column) 방향으로 요소들을 배치하고 정렬할 때 유용합니다. Flexbox는 부모 요소(컨테이너)와 그 안의 자식 요소(아이템) 간의 관계를 기반으로 배치와 정렬을 조정합니다.

Flexbox의 주요 개념과 속성:

display: flex;: 부모 요소를 Flex 컨테이너로 설정합니다. flex-direction: 아이템의 배치 방향을 설정합니다 (row, column 등). justify-content: 메인 축(main axis)을 따라 아이템을 정렬합니다. align-items: 교차 축(cross axis)을 따라 아이템을 정렬합니다. flex: 아이템의 크기를 조정하고 유연한 레이아웃을 만듭니다. align-self: 개별 아이템의 교차 축 정렬을 설정합니다. flex-wrap: 아이템들이 부모 컨테이너를 벗어날 경우 줄 바꿈 여부를 설정합니다.

CSS Grid (그리드 레이아웃)

CSS Grid Layout은 2차원(행과 열) 레이아웃을 만들 때 사용됩니다. 그리드 시스템을 사용하면 부모 요소 내에서 그리드 형태로 요소들을 배치하고 위치시킬 수 있습니다. Grid는 Flexbox와는 달리 행과 열 둘 다를 동시에 제어하여 더 복잡한 레이아웃을 구성할 수 있습니다.

Grid의 주요 개념과 속성:

display: grid;: 부모 요소를 그리드 컨테이너로 설정합니다. grid-template-columns 및 grid-template-rows: 그리드의 열과 행을 설정합니다. grid-gap 또는 gap: 그리드 아이템 사이의 간격을 설정합니다. grid-column 및 grid-row: 아이템의 열과 행 위치를 지정합니다. grid-template-areas: 그리드 영역을 정의하여 복잡한 레이아웃을 생성할 수 있습니다. justify-items: 아이템의 수평 정렬을 설정합니다. align-items: 아이템의 수직 정렬을 설정합니다. place-items: align-items와 justify-items를 한 번에 설정합니다.

Flex vs. Grid

• flex는 1차원 레이아웃, grid는 2차원 레이아웃을 위해 주로 사용합니다.
• flex는 아이템을 main axis(주 축)에 따라 배치하고 정렬합니다. grid는 아이템을 행과 열을 기준으로 정렬하고 배치합니다.
• flex는 컨텐츠의 순서나 정렬을 조정할 때, 주로 사용합니다. grid는 복잡한 레이아웃을 구성해야 할 때 사용합니다.

emotion library

CSS-in-JS 스타일을 지원하는 라이브러리로, 컴포넌트 기반의 개발을 할 때, 동적으로 생성되는 스타일을 쉽게 관리하고 수정할 수 있도록 해줍니다.

Styled Components 와의 차이점

문법과 사용

• Styled Components: Styled Components는 템플릿 리터럴을 사용하여 CSS 스타일을 정의합니다. 컴포넌트 내부에서 스타일을 정의하고 사용할 수 있습니다. 예를 들어, styled.div와 같이 스타일을 정의하고 해당 스타일을 컴포넌트에 적용할 수 있습니다.

• Emotion: Emotion은 JavaScript의 객체 리터럴 또는 매크로 문법을 사용하여 스타일을 정의합니다. Emotion은 객체 리터럴 문법과 매크로 문법을 모두 지원하므로, 스타일을 작성하는 방식에 대한 선택권을 제공합니다.

클래스명 생성

• Styled Components: Styled Components는 랜덤한 클래스명을 생성하여 컴포넌트마다 유니크한 스타일을 가질 수 있도록 합니다. 이를 통해 스타일 간의 이름 충돌을 피할 수 있습니다.

• Emotion: Emotion은 스타일링 작업을 컴파일 시간에 해시화하여 클래스명을 생성합니다. 이는 런타임 성능을 향상시키고 스타일 간의 충돌을 피할 수 있게 해줍니다.

CSS 변수 지원

• Styled Components: Styled Components는 기본적으로 CSS 변수 지원을 제공하지 않습니다.

• Emotion: Emotion은 CSS 변수를 사용하여 스타일을 구성할 수 있는 기능을 제공합니다.

성능

• Styled Components: Styled Components는 성능 면에서 좋은 결과를 보여줍니다. 컴파일 시간에 스타일을 최적화하고 불필요한 리렌더링을 줄일 수 있습니다.

• Emotion: Emotion도 성능을 중요시하며, 스타일을 컴파일 시간에 최적화하여 성능을 개선하려고 노력합니다.

SSR and SSG

SSR(서버 사이드 렌더링)과 SSG(정적 사이트 생성)은 웹 애플리케이션의 렌더링 방식을 나타내는 용어입니다. 둘 다 사용자 경험을 향상시키고 검색 엔진 최적화(SEO)를 개선하기 위해 사용됩니다.

SSG (정적 사이트 생성, static site generation)

정적 사이트 생성(SSG)은 웹 애플리케이션의 모든 페이지를 미리 렌더링하여 정적인 HTML 파일로 생성하는 방식입니다. 사이트의 콘텐츠가 자주 변경되지 않는 경우에 유용합니다. 사이트를 빌드할 때 필요한 모든 페이지가 미리 생성되며, 사용자가 사이트에 접속할 때 서버가 아닌 CDN(Content Delivery Network)을 통해 정적인 HTML 파일을 제공합니다.

초기 로딩 속도가 매우 빠릅니다. 모든 페이지가 미리 렌더링되어 있어서 필요한 데이터만 불러오면 됩니다. 서버에 부담이 적습니다. CDN을 통해 정적 파일을 전달하므로 서버 측에서의 렌더링이 필요하지 않습니다.

단, 동적인 콘텐츠에 대한 업데이트가 자주 발생하는 경우 적합하지 않습니다. 동적 기능은 클라이언트 측에서 추가 작업이 필요할 수 있습니다.

따라서 프로젝트의 목적와 요구사항에 따서 적절히 선택되어야 합니다. SSR은 초기 로딩 속도와 SEO 개선을 필요할 떄, SSG는 정적 컨텐츠를 빠르게 전달할 때 유용하게 사용할 수 있습니다.

CDN(Content Delivery Network)

CDN(Cotent Delivery Network)은 웹 콘텐츠를 더 빠르게 전달하기 위한 분산 네트워크 시스템입니다. CDN은 전세계에 분산된 서버 네트워크를 구축하여 사용자들이 웹 사이트의 콘텐츠를 빠르게 로드할 수 있도록 도와줍니다. 이는 대규모 트래픽이나 지리적으로 분산된 사용자에게 더 나은 성능을 제공하는 데 도움이 됩니다. 주로 이미지나 스크립트 같은 정적인 데이터 전송에 사용됩니다.

CDN의 작동 방식:

1. 캐싱: CDN은 웹 사이트의 정적인 콘텐츠(이미지, 스크립트, 스타일 시트 등)를 여러 지역의 서버에 캐싱하여 저장합니다. 사용자가 웹 사이트에 접속하면 가장 가까운 서버에서 콘텐츠를 빠르게 로드할 수 있습니다.

2. 지리적 분배: CDN은 여러 곳에 위치한 서버를 사용하여 콘텐츠를 제공합니다. 사용자가 웹 사이트에 접속할 때 가장 가까운 서버를 통해 콘텐츠를 받아올 수 있어 더 빠른 로딩 속도를 제공합니다.

3. 부하 분산: CDN은 웹 사이트의 트래픽을 여러 서버에 분산하여 서버의 부하를 분담하고 대량의 트래픽에 대응할 수 있도록 도와줍니다.

4. 보안: 일부 CDN은 보안 기능도 제공하여 DDoS 공격 및 다른 보안 위협으로부터 웹 사이트를 보호할 수 있습니다.

CDN의 장점:

• 로딩 속도 개선: 콘텐츠를 사용자에게 가장 가까운 서버에서 제공하여 로딩 속도를 향상시킵니다.
• 대규모 트래픽 관리: CDN은 서버 부하를 분산하여 대규모 트래픽에 대응할 수 있게 도와줍니다.
• 전세계적인 서비스: 전 세계 여러 지역에서 콘텐츠를 빠르게 제공할 수 있습니다.
• 보안 및 안정성: 일부 CDN은 웹 사이트를 보안 위협으로부터 보호할 수 있는 기능을 제공합니다.

대표적인 CDN 서비스로는 Cloudflare, Akamai, Amazon CloudFront 등이 있으며, 이러한 서비스는 웹 사이트의 성능과 안정성을 향상시키는 데 도움을 줍니다.

CDN과 프록시 서버의 연관성

CDN은 웹 콘텐츠를 여러 지역의 서버에 분산하여 사용자에게 가까운 서버에서 콘텐츠를 제공하여 로딩 속도를 개선하는 데 중점을 둡니다. 주로 정적인 콘텐츠(이미지, 스크립트 등)의 전송에 사용됩니다. 예를 들어, 사용자가 한국에 있다면 한국 서버에서 이미지를 빠르게 받아올 수 있도록 도와줍니다.

프록시 서버는 중계 서버로서 사용자와 원격 서버 사이에서 요청과 응답을 전달하는 역할을 합니다. 이를 통해 익명성을 보장하거나, 콘텐츠 필터링, 보안 검사 등을 수행할 수 있습니다. 프록시 서버는 동적인 콘텐츠를 처리하는 데 사용되며, 웹 페이지 내에서 리소스의 요청과 응답을 중계합니다. 사용자의 IP 주소를 숨기거나 웹 필터링을 위해 사용되기도 합니다.

두 기술 모두 컨텐츠 전달 과정에서 중간자 역할을 하며, 전송 효율성 및 사용자 경험을 개선하기 위해 요청과 응답을 중간에서 조작하거나 보완할 수 있습니다.

CDN은 주로 정적인 컨텐츠를 빠른 속도로 전송하기 위함이고, 전 세계 여러 지역에 서버를 두고 최적화된 컨텐츠를 제공합니다. 프록시 서버는 주로 동적인 컨텐츠를 처리하고 사용자의 익명성 보호 및 보안 검사의 목적을 수행합니다.

참조링크

CSS 레이아웃 - 처음부터 반응형 웹까지 핵심만 간단히 정리해 봅시다. CSS Flexbox와 CSS Grid, 한번에 정리!

리덕스는 애플리케이션의 상태가 하나의 중앙 스토어에서 관리되므로, 상태의 일관성을 유지하고 예측 가능함을 보장합니다. 이는 애플리케이션의 모듈화와 독립성을 강화하여 코드의 유지보수성을 높이고, 결합도를 낮추는 데 도움을 줍니다.

decoupling

Decoupling은 애플리케이션의 다양한 부분들 간의 결합도를 낮추는 개념입니다. 결합도란 하나의 모듈이 다른 모듈에 의존하는 정도를 나타냅니다. Redux에서는 상태 관리를 중앙에서 처리하기 때문에 컴포넌트 간에 상태를 공유하고 통신하기 위해 직접적인 의존성을 갖지 않아도 됩니다. 이로 인해 컴포넌트들은 더 독립적이며, 결합도가 낮아져 컴포넌트의 재사용성과 유지보수성이 높아집니다.

stand alone

Redux의 스토어와 리듀서는 모듈화되어 독립적으로 작성할 수 있습니다. 각각의 리듀서는 특정 상태 조각을 관리하며, 이들은 서로 영향을 미치지 않고 독립적으로 작동합니다. 이렇게 모듈화된 스토어와 리듀서는 애플리케이션 전체에서 공유되며, 각각의 부분이 독립적으로 업데이트될 수 있습니다. 이러한 독립성은 애플리케이션의 각 모듈을 개별적으로 테스트하고 유지보수하기 쉽게 만듭니다.

dispatch 메소드가 필요한 이유

리덕스의 핵심 개념은 복잡한 상태를 에측 가능하게 관리한다는 것입니다. 우선 dispatch 메소드는 store에 액션을 보내는 역할을 합니다. 액션은 '어떤 변화가 일어나야 한다'에 대한 정보가 담긴 객체입니다. dispatch가 보낸 액션을 store 내부에 있는 reducer가 받아서 state를 업데이트해줍니다.

어디에서든지 dispatch를 통해 중앙에 있는 store로 상태 변경 정보를 보낼 수 있기 때문에, 중앙 관리에 유리합니다. 또는 dispatch를 이용해서 비동기 작업을 처리하거나 미들웨어를 통해 액션을 가로채고 추가 작업을 해줄 수도 있습니다.

오늘의 CS지식

html script 태그 위치

1. head 태그 내부 페이지 컨텐츠 렌더링 전에 스크립트 파일 로드됩니다.

   단 defer 속성을 추가하면, 컨텐츠가 로드된 후에 스크립트 파일이 실행되게 하여 페이지 로딩과 스크립트 실행을 병렬로 처리할 수 있습니다.

2. body 태그 내부 끝 부분 페이지 컨텐츠가 먼저 로드된 후에 스크립트 파일이 로드됩니다.

canvas

<canvas>는 웹 게임, 데이터 시각화, 차트 생성 등 다양한 그래픽 관련 작업에 활용되며, 자바스크립트와 함께 사용하여 동적이고 상호작용적인 그래픽 화면을 구현하는 데 유용합니다.

캔버스 태그는 그래픽을 그리기 위한 빈 영역을 제공하며, 이 영역에 그림 또는 그래픽을 그리고 수정할 수 있습니다. 이러한 동작은 자바스크립트로 작성됩니다.

svg

SVG(Scalable Vector Graphics)는 확장 가능한 벡터 그래픽을 나타내기 위한 XML 기반의 파일 형식입니다. SVG 파일은 그래픽을 벡터 형식으로 표현하며, 다양한 크기에서 화질을 유지하며 확대 또는 축소할 수 있습니다. 이러한 특징으로 SVG는 웹, 애플리케이션, 데이터 시각화 등 다양한 분야에서 사용됩니다.

SVG 파일의 특징과 사용법:

벡터 그래픽: SVG 파일은 선, 원, 사각형, 다각형 등의 기하학적 도형과 텍스트, 경로 등을 사용하여 그래픽을 표현합니다. 이러한 그래픽 요소들은 확대 또는 축소해도 화질을 유지하며 깔끔하게 표현됩니다.

XML 기반: SVG 파일은 XML 문법을 사용하여 작성됩니다. 이는 텍스트 파일로서 읽기와 수정이 용이하며, 소스 코드와 분석에도 도움이 됩니다.

상호작용성: SVG는 자바스크립트와 결합하여 상호작용적인 그래픽을 구현할 수 있습니다. 클릭, 호버, 애니메이션 등을 추가하여 동적인 그래픽 화면을 만들 수 있습니다.

웹에서 사용: 웹 페이지에서 SVG를 사용하면 크기와 화질을 유지한 채로 다양한 디스플레이 크기에 맞게 표시할 수 있습니다. 또한, 검색 엔진 최적화(SEO) 측면에서도 유리한 요소입니다.

애플리케이션에서 사용: SVG는 웹 브라우저뿐만 아니라 애플리케이션 인터페이스(UI)나 데이터 시각화 등에서도 활용됩니다. 벡터 형식이므로 화면 크기나 DPI에 따른 문제가 없어 화면이나 인쇄물 등 다양한 출력에 사용될 수 있습니다.

편집 및 생성 도구: 다양한 그래픽 편집 도구와 프로그래밍 언어로 SVG 파일을 생성, 수정할 수 있습니다. Adobe Illustrator, Inkscape 등은 SVG 파일 편집에 유용한 도구 중 하나입니다.

SVG는 높은 품질의 그래픽을 제공하면서도 파일 크기가 작고 다양한 용도로 활용할 수 있는 형식으로, 웹 및 그래픽 관련 작업에 유용하게 사용되는 포맷입니다.

벡터 형식 vs. 비트맵 형식

벡터 형식과 비트맵 형식은 사용 목적에 따라 선택되어야 합니다. 화질 유지와 크기 조절이 중요한 경우에는 벡터 형식이 유용하며, 사진이나 자연스러운 그래픽을 다루는 경우에는 비트맵 형식이 적합합니다.

1. 벡터 형식 벡터 형식은 기하학적 도형과 선, 곡선, 텍스트 등을 수학적 수식으로 표현합니다. 확대 및 축소 시 해상도 손실이 없습니다. 즉, 그림이 얼마나 크든 작든 화질은 유지됩니다. 대표적으로 SVG(Scaleable Vector Graphics)가 벡터 형식의 예입니다. 그래픽 요소 간 상대적인 위치와 크기가 중요한 경우에 유용합니다. 로고, 아이콘, 도표 등에 적합합니다.

2. 비트맵 형식 비트맵 형식은 픽셀로 이루어진 이미지로, 각 픽셀의 색상 정보를 저장합니다. 확대 시 픽셀 정보가 보이거나 계단 현상이 발생할 수 있습니다. 확대하면 화질이 떨어집니다. JPEG, PNG, GIF, BMP 등이 비트맵 형식의 대표적인 예시입니다. 사진, 그림, 사진과 같이 세밀한 색상과 질감이 중요한 이미지에 적합합니다.

참조링크

애플 웹사이트 iPhone X 비주얼 똑같이 만들기 #1 생활코딩 Redux

Emotion

Emotion은 JavaScript를 사용하여 CSS 스타일을 관리하는 라이브러리로, React와 다른 프레임워크에서 사용할 수 있습니다. Emotion은 CSS-in-JS 스타일링 방식을 채택하여, 컴포넌트와 함께 스타일을 선언하고 적용할 수 있습니다. CSS-in-JS 방식 중 하나인 "Styled Components"와 유사한 기능을 제공합니다.

1. CSS-in-JS: Emotion은 JavaScript 코드 안에서 CSS 스타일을 작성할 수 있도록 해주는 방식으로, 스타일과 컴포넌트를 함께 관리할 수 있습니다.
2. 퍼포먼스: Emotion은 빠른 런타임 성능을 제공하며, 스타일을 최적화하여 불필요한 렌더링을 방지합니다.
3. 스타일 재사용: Emotion은 스타일을 JavaScript 객체로 추상화하여 재사용성을 높여줍니다.

Framer-motion

Framer Motion은 모션 그래픽 및 애니메이션을 구현하기 위한 모션 라이브러리입니다. React와 함께 사용되며, 간단하고 직관적인 API를 제공하여 다양한 모션 및 애니메이션 효과를 구현할 수 있습니다.

1. 직관적인 API: Framer Motion은 사용하기 쉬운 API를 제공하여 모션과 애니메이션을 구현하는 것이 간단하고 편리합니다.
2. 애니메이션 제어: 시간, 이징(Easing), 지연, 반복 등 애니메이션을 제어하는 기능을 제공하여 다양한 모션 효과를 세밀하게 조정할 수 있습니다.
3. 여러 요소 지원: Framer Motion은 DOM 요소뿐만 아니라 SVG, 캔버스 등 다양한 요소를 지원합니다.
4. 퍼포먼스: Framer Motion은 빠른 런타임 성능을 지향하며, 스크롤, 제스처 등 다양한 상황에서도 부드러운 애니메이션을 제공합니다.

패키지 매니저(package manager)

자바스크립트 패키지 매니저는 자바스크립트 애플리케이션에서 사용되는 외부 라이브러리, 모듈, 플러그인 등을 관리하는 도구입니다. 패키지 매니저를 사용하면 프로젝트에 필요한 의존성을 쉽게 관리하고 설치할 수 있으며, 프로젝트를 더 쉽고 효율적으로 개발할 수 있습니다.

npm (Node Package Manager)

npm은 Node.js를 위한 기본 패키지 매니저로 가장 널리 사용되는 패키지 매니저입니다. npm은 Node.js 생태계의 모듈을 설치, 관리, 배포할 수 있도록 해주며, 개발자들이 작성한 모듈을 공유하고 다른 사람들이 사용할 수 있도록 합니다. 프로젝트의 의존성을 package.json 파일에 기록하여 프로젝트를 쉽게 공유하고 재현 가능하게 만들 수 있습니다.

npm의 동작

npm은 node_modules 디렉토리 안에 프로젝트에 필요한 패키지들을 설치하여 의존성을 관리하고, JavaScript 코드에서 패키지를 불러올 때(ex. import문) 해당 디렉토리를 검색하여 필요한 패키지를 찾습니다. 만약 node_modules에 패키지가 없으면 상위 디렉토리로 올라가면서 패키지를 찾으며, 전역 설치된 패키지는 프로젝트의 모든 디렉토리에서 사용 가능합니다.

1. 프로젝트이 루트 디렉토리에 저장된 package.json 파일이 있습니다. 여기에는 프로젝트의 메타 정보와 의존성 정보가 들어있습니다. 예를 들어 패키지 이름, 저작권, 스크립트 등이 기록되어 있습니다.
2. npm install 명령어를 통해, npm은 package.js 파일에 명시된 의존성을 검사하고 이를 기반으로 필요한 패키지들을 인터넷에서 다운로드하여 프로젝트 폴더에 node_modules 디렉토리에 설치합니다.
3. JavaScript 프로젝트에서 코드를 작성할 때, 코드 내에서 require() 함수나 import 문을 사용하여 필요한 패키지를 불러올 수 있습니다. 이 때, npm은 먼저 현재 프로젝트의 node_modules 디렉토리에서 해당 패키지를 검색합니다. 만약 현재 프로젝트의 node_modules에 패키지가 없는 경우, npm은 상위 디렉토리로 올라가면서 해당 패키지를 찾습니다. 이 과정은 프로젝트 디렉토리의 루트까지 올라가거나 패키지를 찾을 때까지 계속됩니다.

npm의 비효율성

npm은 파일 시스템을 통해, node_modules 폴더를 이용해서 의존성을 관리 및 검색합니다. 하지만 이 방식에서 npm은 원하는 의존성을 찾기 위해, 상위 디렉토리의 node_modules 폴더를 계속 탐색하게 되고, 이 과정에서 여러 비효율이 발생합니다.

1. 해당 패키지의 상위 디렉토리 환경에 따라 의존성 탐색 여부와 의존성의 버전이 달라질 수 있습니다.
2. node_modules 디렉토리 구조는 일반적으로 수백 메가바이트 이상의 용량이 필요하며, 이를 탐색하기 위해 많은 I/O 작업이 필요합니다.

I/O 작업 (입출력 작업) : 데이터의 입력과 출력을 통해 프로그램이 외부 환경과 상호작업하는 작업을 의미합니다. 시스템 리소스에 접근해야 하기 때문에 상대적으로 느린 작업입니다.

3. npm 및 Yarn v1에서는 중복되서 설치되는 node_modules를 아끼기 위해서 Hoisting(끌어올리기) 기법을 사용합니다. 따라서 의존성의 중복을 피할 수 있었지만 직접 의존하지 않는 라이브러리 등을 직접 불러오게 되면서, '유령 의존성'이 생기게 되었습니다. 즉, package.json에 명시되어 있지 않으나 조용히 사용하고 있을 수 있는 것이죠. 따라서 다른 의존성에 변경이 발생할 때, 예측하지 못한 사이드 이펙트가 발생할 수 있었습니다.

Yarn

Yarn v1

Yarn은 페이스북에서 개발한 자바스크립트 패키지 매니저로, npm의 대안으로 사용됩니다. Yarn은 npm 저장소에서 패키지를 설치하는 데 사용되며, npm과 호환되기 때문에 기존 npm으로 설치된 패키지들을 그대로 사용할 수 있습니다. Yarn은 더 빠르고 안정적인 의존성 해결과 캐시 기능을 갖추고 있으며, lock 파일을 통해 패키지 버전을 고정하여 동일한 환경에서 일관성을 유지할 수 있도록 합니다.

Yarn v1은 package.json 기반으로 의존성 트리를 생성하고, node_modules 디렉토리 구조를 만듭니다. 이를 통해 의존성 충돌을 피하고 관리를 도와줍니다.

Yarn Berry

Yarn Berry는 Yarn의 최신 버전 중 하나로, Plug'n'Play 즉 pnp 개념을 적용합니다. node_modules 폴더를 생성하지 않고, cache 폴더에 의존성 정보를 저장하며 cjs 파일에 의존성을 찾을 수 있는 정보가 기록됩니다.

cache 폴더 안에 있는 파일들은 Zip FileSystem을 따르기 떄문에 다음과 같은 장점이 있었습니다.

1. node_modules 디렉토리 구조가 필요없기 때문에, 설치가 빠릅니다.
2. 각 패키지는 버전마다 하나의 zip 아카이브를 가지고 있기 때문에 중복 설치가 되지 않습니다. 또한 압축되어 있어 용량을 아낄 수 있습니다.
3. 의존성 파일을 효율적이고 엄격하게 관리할 수 있습니다.
4. cjs에 의존성 위치가 명시되어 있기 때문에, node_modules를 순회할 필요가 없습니다.
5. 설치 시간을 단축시키거나 zero-intall을 통해서 설치 없이 사용할 수 있습니다. 의존성의 용량이 매우 낮아졌기 때문에 git과 같은 버전 관리에 포함시켜 관리할 수 있는 것을 zero-install이라고 합니다.

PNPM

PNPM은 Yarn과 npm과 같은 자바스크립트 패키지 매니저의 대안으로 개발된 패키지 매니저입니다. PNPM은 중복되는 의존성을 공유하여 설치 디스크 공간을 절약하고, 더 빠른 설치 속도를 제공하는 특징을 갖고 있습니다. PNPM은 기존 npm 저장소와 호환되며, 패키지를 설치할 때에도 캐시 기능을 사용하여 중복 다운로드를 최소화합니다.

빌드 도구

빌드(Build) 도구들인 Webpack, ESBuild, SWC, Babel에 대해 간단히 설명드리겠습니다.

1. Webpack: Webpack은 웹 애플리케이션의 정적 자원(JavaScript, CSS, 이미지 등)을 번들링하기 위한 모듈 번들러입니다. 웹팩은 애플리케이션의 의존성 그래프를 분석하여 모든 자원을 하나 또는 여러 개의 번들 파일로 묶어주며, 최적화와 소스 맵 생성 등 다양한 기능을 제공합니다. 또한, 로더(loader)와 플러그인(plugin)을 사용하여 자바스크립트 파일 이외의 다른 자원을 처리하거나 추가 기능을 확장할 수 있습니다.

2. ESBuild: ESBuild는 빠른 빌드 속도를 강조하는 자바스크립트 번들러 및 컴파일러입니다. 기존 번들러에 비해 높은 속도를 자랑하며, Go 언어로 개발되었습니다. ESBuild는 주로 최신 자바스크립트 문법 (ES6+), JSX, TypeScript 등을 컴파일하여 빠르게 번들링하는 데에 사용됩니다.

3. SWC: SWC는 빠른 속도와 효율성을 강조하는 Rust로 작성된 자바스크립트/타입스크립트 컴파일러입니다. Babel과 비슷한 역할을 수행하지만, 빌드 속도와 효율성에서 우수한 성능을 보여줍니다. SWC는 최신 자바스크립트 문법과 타입스크립트를 ES5로 변환하여 브라우저 호환성을 강화하고 최적화된 코드를 생성합니다.

4. Babel: Babel은 주로 구형 브라우저에서도 동작하는 현대 자바스크립트 문법을 사용하여 개발하기 위해 사용되는 컴파일러입니다. Babel은 최신 자바스크립트 문법을 이전 버전으로 변환하는 트랜스파일러로, 주로 ES6+ 문법을 ES5 이하로 변환하여 구형 브라우저와의 호환성을 확보합니다.

요약하자면, Webpack은 웹 애플리케이션의 정적 자원을 번들링하고 최적화하는 모듈 번들러, ESBuild는 빠른 빌드 속도를 강조하는 번들러/컴파일러, SWC는 높은 효율성과 속도를 갖는 Rust 기반의 컴파일러, Babel은 구형 브라우저와의 호환성을 위해 최신 자바스크립트 문법을 이전 버전으로 변환하는 컴파일러입니다. 이들 빌드 도구는 각자의 강점과 특징을 가지고 있으며, 프로젝트의 요구사항과 성능을 고려하여 선택하여 사용할 수 있습니다.

CI/CD

CI/CD(Continuous Integration/Continuous Deployment)는 소프트웨어 개발에서 자동화된 빌드, 테스트, 배포 과정을 의미합니다. CI/CD를 적용하면 개발자들이 코드를 버전 관리 시스템에 푸시할 때마다 자동으로 빌드와 테스트가 실행되어 품질이 높은 소프트웨어를 지속적으로 배포할 수 있습니다.

GitHub Actions와 CircleCI는 둘 다 CI/CD를 구현하기 위한 서비스입니다. 각각에 대해 간단히 설명드리겠습니다:

1. GitHub Actions: GitHub Actions는 GitHub에서 제공하는 CI/CD 서비스로, GitHub 저장소와 완전히 통합되어 있습니다. GitHub Actions를 사용하면 소스 코드의 변경 사항을 기반으로 자동 빌드, 테스트, 배포 등의 작업을 수행할 수 있습니다. YAML 파일을 사용하여 작업 흐름(Workflows)을 정의하며, 이를 기반으로 CI/CD 파이프라인을 구축할 수 있습니다. GitHub Actions는 무료 플랜과 유료 플랜을 제공하며, 통합이 용이하고 간편한 사용법으로 인기가 있습니다.

2. CircleCI: CircleCI는 클라우드 기반의 CI/CD 플랫폼으로, GitHub, Bitbucket, GitLab 등 다양한 버전 관리 시스템과 연동하여 사용할 수 있습니다. CircleCI를 사용하여 소스 코드의 변경 사항을 자동으로 감지하고 테스트 및 빌드를 실행할 수 있습니다. CircleCI는 환경 설정이 유연하고 커스터마이징이 용이한 장점을 갖고 있으며, 복잡한 빌드 및 배포 프로세스를 구축하는 데에 유용합니다.

둘 다 CI/CD를 구현하는데 사용되는 서비스이며, 각각의 특징과 기능을 고려하여 프로젝트에 맞는 적절한 서비스를 선택하여 사용할 수 있습니다. CI/CD를 적용하면 소프트웨어 개발과 배포 과정이 자동화되어 개발 생산성과 품질을 향상시킬 수 있습니다.

3D 그래픽

Three.js

hree.js는 3D 그래픽을 웹 브라우저에서 쉽게 구현할 수 있도록 도와주는 자바스크립트 3D 라이브러리입니다. WebGL을 기반으로 동작하며, WebGL을 직접 다루는 복잡한 코드 없이도 3D 객체, 조명, 카메라, 애니메이션 등을 생성하고 조작할 수 있도록 인터페이스를 제공합니다.

Three.js는 3D 모델링과 시뮬레이션, 게임 개발, 시각화, 웹 상에서의 3D 그래픽 구현 등 다양한 분야에서 사용됩니다. 주요 특징과 기능은 다음과 같습니다:

1. 3D 객체 생성: Three.js를 사용하여 기하학적 도형 (상자, 구, 원통 등)뿐만 아니라 사용자 정의 3D 모델을 생성할 수 있습니다.

2. 카메라와 뷰포트: Three.js에서는 카메라를 통해 3D 공간을 관찰하며, 원하는 시점으로 이동할 수 있습니다.

3. 조명: Three.js에서는 광원을 생성하여 3D 객체에 조명을 줄 수 있으며, 조명에 따른 빛의 반사, 그림자 등을 설정할 수 있습니다.

4. 재질(Material)과 텍스처(Texture): Three.js에서는 재질을 설정하여 3D 객체의 외관을 결정하며, 이미지나 동영상 등의 텍스처를 적용할 수 있습니다.

5. 애니메이션: Three.js를 사용하여 객체의 위치, 회전, 크기 등을 애니메이션화할 수 있으며, 더 복잡한 애니메이션도 제작할 수 있습니다.

6. 물리 엔진 연동: Three.js는 물리 엔진 라이브러리인 Ammo.js 등과 연동하여 물리 기반 시뮬레이션을 구현할 수 있습니다.

오늘의 CS지식

GNB : Global Navigation Bar, 웹 사이트에서 전역으로 제공하는 공통 네이게이션 바 또는 레이어를 의미합니다. 다양한 메뉴 및 기능 페이지로 빠르게 전환할 수 있도록 링크를 포함해줍니다.

LNB : Local Navigation Bar, GNB의 하위 네이비게이션 바입니다. 특정 카테고리 내부에 있는 메뉴들의 링크를 포함하고 있습니다. 서브 메뉴라고도 할 수 있습니다.

FNB : Foot Navigation Bar, 웹 사이트 가장 하단에 위치한 네비게이션 바로 기업 및 웹 사이트의 정보들을 기재합니다.

Next.js의 _app 과 _document 파일 비교

Next.js 애플리케이션의 모든 페이지는 _app.js 파일을 통해 렌더링되며, _app.js의 MyApp 컴포넌트 내에서는 모든 페이지에 공통적으로 적용되어야 할 레이아웃이나 글로벌 스타일 등을 설정할 수 있습니다.

Document 컴포넌트는 HTML, Head, Body 요소를 커스터마이징할 수 있는 파일로, 페이지에 대한 커스텀 메타데이터, 스타일 시트 등을 설정하는 데에 사용됩니다. _document.js파일 내부의 MyDocument 클래스는 Document 클래스를 상속받아야 합니다. render 메서드를 통해 HTML, Head, Body 요소를 커스터마이징할 수 있으며, Head 컴포넌트 내에서 페이지에 대한 커스텀 메타데이터(예: title, meta 태그 등)를 설정할 수 있습니다.

참조링크

node_modules로부터 우리를 구원해 줄 Yarn Berry 인텐트 마케팅GNB, LNB? 웹사이트 용어 알아보기

React의 Context는 컴포넌트 간에 데이터를 전달하는 메커니즘을 제공하는 React API입니다. 일반적으로 React 컴포넌트는 상위 컴포넌트로부터 데이터를 props로 전달받습니다. 그러나 컴포넌트 트리의 여러 단계를 거치는 경우, 중간 컴포넌트들이 해당 데이터를 모두 전달해야 하는 번거로움이 생길 수 있습니다. 이런 경우 Context를 사용하면 데이터를 중간 컴포넌트 없이도 효율적으로 전달할 수 있습니다.

Context를 사용하면, 상위 컴포넌트에서 생성한 데이터(또는 상태)를 모든 하위 컴포넌트에서 직접 접근할 수 있습니다. 이를 통해 컴포넌트 간의 데이터 흐름을 간소화하고, 데이터가 필요한 곳에서 쉽게 사용할 수 있도록 합니다.

Context Provider

Context 데이터를 제공하는 컴포넌트입니다. Context Provider는 일반적으로 상위 컴포넌트에서 생성하며, createContext 함수를 사용하여 생성할 수 있습니다. 이 컴포넌트는 자식 컴포넌트에게 데이터를 제공하기 위해 value prop을 사용하여 데이터를 전달합니다.

Context Consumer

Context 데이터를 필요로 하는 하위 컴포넌트에서 사용됩니다. useContext 훅을 사용하거나 Consumer 컴포넌트를 이용하여 Context 데이터를 소비(consume)합니다. 이를 통해 해당 컴포넌트에서 Context 데이터를 직접 사용할 수 있습니다.

Context

Context 객체 자체입니다. 이 객체를 통해 Provider와 Consumer를 만들고, Context 데이터를 생성하고 공유합니다.

createContext() 메소드를 통해 먼저 context 객체를 만들고, 부모 컴포넌트에서 해당 객체의 Provider 컴포넌트를 이용해서 value props를 통해 데이터를 전달합니다. 그리고 자식 컴포넌트에서 Consumer 컴포넌트 또는 useContext 훅을 이용해서 데이터를 전달 받아 사용합니다.

// Context 생성
const MyContext = React.createContext();

// Context Provider
const ParentComponent = () => {
  const data = "Hello from Context!";

  return (
    <MyContext.Provider value={data}>
      <ChildComponent />
    </MyContext.Provider>
  );
};

// Context Consumer
const ChildComponent = () => {
  const data = React.useContext(MyContext);

  return <div>{data}</div>; // 출력: Hello from Context!
};

SPA(Single Page Application)

SPA(단일 페이지 애플리케이션)는 웹 애플리케이션의 일종으로, 하나의 HTML 페이지를 기반으로 동적으로 콘텐츠를 변경하며 사용자와 상호작용하는 웹 애플리케이션입니다. 기존의 전통적인 멀티 페이지 웹 애플리케이션과는 다른 접근 방식을 가지고 있습니다.

전통적인 멀티 페이지 웹 애플리케이션은 매 페이지 요청마다 새로운 HTML을 받아와 전체 페이지를 다시 렌더링하는 방식이었습니다. 이로 인해 페이지 간 전환 시 매번 서버로부터 새로운 페이지를 받아와야 하므로, 사용자 경험이 떨어질 수 있습니다. 또한, 서버와의 통신이 필요하기 때문에 새로운 페이지 로딩 시간도 증가하게 됩니다.

이와 달리, SPA는 초기에 한 번 페이지를 로딩한 후, 페이지 이동 시에 서버로부터 새로운 페이지를 받아오는 것이 아니라, 클라이언트 측에서 필요한 데이터만 받아와 페이지를 동적으로 갱신합니다. 이로 인해 페이지 간의 전환 속도가 빠르며, 사용자 경험을 향상시킬 수 있습니다.

1. 단일 페이지: SPA는 하나의 HTML 페이지로 구성되어 있습니다. 페이지 간 전환 시 새로운 페이지를 서버로부터 받아오는 것이 아니라, 동적으로 콘텐츠를 변경하여 사용자에게 보여줍니다.

2. 동적 업데이트: virtual dom을 이용해서 실제 dom의 조작 비용을 최소화하고 렌더링 성능을 향상시켜 줍니다. 페이지의 일부분만 동적으로 업데이트되므로, 사용자의 상호작용에 따라 필요한 부분만 새로 로딩합니다. 이는 서버로의 요청을 줄이고 애플리케이션의 반응성을 향상시킵니다.

3. 클라이언트 사이드 렌더링(CSR): 콘텐츠를 클라이언트 측에서 동적으로 렌더링하므로, 서버 측에서는 데이터만 제공하면 됩니다. 이로 인해 서버의 부담이 줄어들고, 서버와 클라이언트 간의 통신을 최소화할 수 있습니다.

4. 라우팅: SPA는 클라이언트 측에서 라우팅을 처리합니다. URL의 변경에 따라 필요한 컴포넌트를 동적으로 로딩하여 적절한 페이지를 보여줍니다.

5. 프론트엔드 프레임워크/라이브러리: 주로 React, Angular, Vue.js 등의 프론트엔드 프레임워크나 라이브러리와 함께 사용됩니다. 이러한 도구들은 SPA의 개발과 관리를 용이하게 해줍니다.

SPA의 장점은 좋은 사용자 경험과 빠른 페이지 간 이동 속도 등이 있지만, 초기 로딩 시 모든 자원을 받아와야 하므로 초기 로딩 속도가 느릴 수 있습니다. 또한, 브라우저의 뒤로 가기와 같은 기본적인 기능을 구현하기 위해서도 추가적인 처리가 필요할 수 있습니다. 이러한 단점들을 극복하기 위해 코드 스플리팅과 라우팅 처리에 주의하여 개발하는 것이 중요합니다.

Next.js

React 언어를 사용하여 만든 SPA(Single Page Application)와 SSR(Server-Side Rendering)이 가능한 Next.js 라이브러리를 사용한 프로젝트는 SPA이면서 SSR이 가능합니다.

React는 기본적으로 클라이언트 측에서 동작하는 라이브러리로, SPA를 구현하는데 사용됩니다. SPA는 페이지 간의 전환 시에 서버로부터 새로운 페이지를 받아오지 않고, 클라이언트 측에서 페이지를 동적으로 갱신하는 방식을 사용합니다. 이로 인해 사용자 경험이 향상되고, 페이지 간의 전환 속도가 빠릅니다.

Next.js는 React 기반의 프레임워크로서, 서버 측 렌더링(SSR)을 지원합니다. SSR은 SPA의 초기 로딩 속도를 개선하기 위해 서버 측에서 최초로 페이지를 렌더링하는 기술입니다. 따라서 Next.js를 사용하면 SPA처럼 클라이언트 측에서 동작하는 이점을 유지하면서도 SSR을 통해 초기 로딩 속도를 개선할 수 있습니다.

Next.js는 라우팅과 데이터 미리 불러오기 등 SSR을 간편하게 구현할 수 있는 기능을 제공합니다. 또한, 필요에 따라서는 클라이언트 측에서 SPA처럼 동작하도록 할 수도 있습니다. 따라서 Next.js로 만든 프로젝트는 SPA이면서 SSR이 가능한 장점을 동시에 가지고 있습니다.

예를 들어, Next.js를 사용하여 만든 프로젝트는 초기 로딩 시에 서버 측에서 페이지를 렌더링하여 사용자에게 보여줍니다(SSR). 그 후, 페이지 간 전환은 클라이언트 측에서 SPA처럼 동적으로 처리되며(CSR), 필요한 데이터는 미리 불러오거나 필요 시에 비동기로 불러올 수 있습니다. 이를 통해 최적화된 사용자 경험과 검색 엔진 최적화(SEO)를 동시에 얻을 수 있습니다.

react.js에 next.js가 있다면, vue.js에는 동일한 기능을 할 수 있도록 해주는 라이브러리 nuxt.js가 있습니다.

Hydration(하이드레이션)

Hydration은 서버 사이드 렌더링(SSR)을 통해 서버에서 최초로 렌더링된 HTML에 대해 클라이언트에서 이루어지는 과정입니다. 서버 사이드 렌더링은 웹 페이지의 초기 렌더링을 빠르게 하고, 검색 엔진 최적화(SEO)에 도움을 주는 장점이 있습니다. 하지만 초기 렌더링 이후에는 웹 애플리케이션이 클라이언트 사이드 라우팅을 통해 동적으로 페이지를 변경하고 업데이트해야 할 때가 있습니다. 서버 사이드 렌더링으로 생성된 HTML은 브라우저에 로드되면서 클라이언트 사이드 라이브러리(예: React)가 해당 HTML에 이벤트 핸들러 등을 붙이고 상호작용을 설정합니다. 이렇게 웹 애플리케이션은 초기 렌더링 이후에도 사용자와의 상호작용에 응답하면서, 변경된 부분만 업데이트하여 동적 렌더링을 가능하게 합니다. 이 과정을 Hydration이라고 합니다. 하이드레이션 덕분에 Next.js는 CSR의 동적 렌더링과 SSR의 최초 HTML 파일 렌더링의 강점을 둘 다 살릴 수 있습니다.

Svelte(스벨트)

Svelte는 컴파일러를 사용하여 빌드 시점에 코드를 변환하며, 이를 통해 런타임에 Virtual DOM을 사용하지 않고도 효율적인 돔 조작을 가능하게 합니다.

일반적인 SPA 라이브러리들은 Virtual DOM을 사용하여 상태가 변경될 때마다 가상 돔과 실제 돔을 비교하고 업데이트합니다. 이러한 과정은 메모리와 CPU 자원을 소비하며, 복잡한 UI나 상태가 많은 경우에는 성능 저하를 가져올 수 있습니다.

반면, Svelte는 컴파일러를 사용하여 컴포넌트 코드를 컴파일 시점에 JavaScript 코드로 변환합니다. 이렇게 변환된 코드는 실제 돔 조작 코드가 됩니다. Svelte 컴파일러는 컴포넌트 코드에서 상태 변경을 추적하고, 변경된 부분만 실제 돔에 반영하는 최적화된 코드를 생성합니다.

결과적으로 Svelte는 런타임에 Virtual DOM을 사용하지 않고, 컴파일 시점에 최적화된 실제 돔 조작 코드를 생성함으로써 메모리 사용량과 런타임 성능을 최적화합니다. 이는 Svelte를 더 가볍고 빠르게 만들어주는 주요한 특징 중 하나입니다.

Svelte의 접근 방식은 개발자가 코드를 작성할 때 더 직관적이고 간단하게 작성할 수 있게 해줍니다. 개발자는 가상 돔과 관련된 추가적인 세부 사항을 신경 쓰지 않고, 단순히 상태를 변경하고 컴포넌트를 정의하는 것에 집중할 수 있습니다. Svelte가 빌드 시점에서 최적화를 수행하기 때문에 높은 성능을 유지하면서도 코드 작성의 편의성을 제공합니다.

Svelte의 접근 방식은 개발자가 코드를 작성할 때 더 직관적이고 간단하게 작성할 수 있게 해줍니다. 개발자는 가상 돔과 관련된 추가적인 세부 사항을 신경 쓰지 않고, 단순히 상태를 변경하고 컴포넌트를 정의하는 것에 집중할 수 있습니다. Svelte가 빌드 시점에서 최적화를 수행하기 때문에 높은 성능을 유지하면서도 코드 작성의 편의성을 제공합니다.

스벨트와 기존 SPA 라이브러리의 차이

기존의 SPA 라이브러리들이 Virtual DOM을 도입한 이유는 성능 최적화와 상태 변경 추적의 용이성 때문입니다. Virtual DOM을 사용하면 상태가 변경될 때마다 이전 Virtual DOM과 새로운 Virtual DOM을 비교하여 변경된 부분만 돔에 반영하여 불필요한 돔 조작을 줄이고 성능을 향상시킬 수 있습니다. 또한, Virtual DOM은 라이브러리에서 상태 변경을 추적하고 UI를 업데이트하는 데에도 도움을 주므로 개발자가 더 쉽게 상태 관리를 할 수 있게 됩니다.

그러나 Svelte는 컴파일 시점에 코드를 변환하고, 상태 변경을 추적하여 빌드 시점에서 최적화된 돔 조작 코드를 생성합니다. 이렇게 생성된 코드는 런타임에 돔을 조작하며 동적 렌더링을 가능하게 합니다. Svelte는 컴파일러가 상태 변경을 감지하고 해당 상태에 의존하는 코드를 생성하므로, 런타임에 추가적인 비용 없이 최적화된 돔 조작을 할 수 있습니다.

따라서 Svelte는 Virtual DOM을 사용하지 않고도 성능을 최적화하고, 직접 돔을 조작하면서 동적 렌더링을 가능하게 하는 리액티브 시스템을 통해 이러한 기능을 구현합니다. 이는 개발자가 코드를 간결하게 작성하면서도 높은 성능을 유지할 수 있도록 도와줍니다.

Virtual DOM은 메모리 상에 가상의 돔 트리를 유지하고, 상태 변경이 발생할 때마다 이를 비교하여 업데이트하는 방식으로 동작합니다. 이는 돔 조작을 추상화하기 위해 사용되는 효과적인 방법이지만, 가상 돔을 유지하는 데에는 일정한 메모리와 계산 비용이 발생합니다. 따라서 복잡한 UI를 다룰 때나 큰 규모의 애플리케이션에서는 Virtual DOM을 사용하는 것이 동작 속도에 영향을 미칠 수 있습니다.

스벨트는 컴파일 시점에 최적화된 코드를 생성하고, 상태 변경을 추적하여 변경된 부분만을 업데이트하는 방식을 사용합니다. 이로 인해 불필요한 돔 조작을 최소화하고, Virtual DOM을 유지하는 데 필요한 리소스를 줄일 수 있습니다. 또한, 리액티브 시스템을 활용하여 상태 변경을 추적하는 과정도 Virtual DOM의 비교 과정보다 더 효율적으로 동작할 수 있습니다.

결국 스벨트는 컴파일 시점에 최적화되고 리액티브 시스템을 통해 상태 변경을 추적하여 필요한 부분만을 돔에 업데이트하여 성능을 향상시킵니다. 이러한 설계로 인해 스벨트는 리소스를 효율적으로 사용하면서도 빠른 렌더링과 업데이트를 제공합니다. 그렇기 때문에 스벨트는 일반적으로 Virtual DOM을 사용하는 라이브러리보다 더 가볍고 빠르게 동작할 수 있습니다.

JavaScript 정적 타입 검사 도구

1. 마이크로소프트 개발에서 개발한 TypeScript
2. 페이스북에서 개발한 Flow

위 라이브러리들을 이용하여 코드의 타입을 사전에 명시하고, 코드가 실행되기 전에 타입 에러를 찾아내는 것이 가능합니다. 따라서 런타임에 발생할 수 있는 많은 버그를 사전에 방지할 수 있습니다. 이를 통해 코드 가독성 및 유지보수성을 높일 수 있습니다.

react 상태 관리 도구

1. React-Query

React-Query는 서버 상태와 데이터를 관리하기 위한 라이브러리입니다. 주로 원격 API 호출과 데이터 캐싱을 쉽게 처리하며, 비동기 데이터를 쉽게 가져오고 조작할 수 있도록 설계되었습니다.

주요 특징:

• 데이터 Fetching: 서버에서 데이터를 가져오는 비동기 작업을 지원합니다. HTTP 요청과 GraphQL 쿼리를 손쉽게 처리할 수 있습니다.
• 캐싱: 가져온 데이터를 자동으로 캐싱하여, 같은 요청을 반복적으로 보낼 때 불필요한 네트워크 호출을 방지합니다.
• 리패칭과 리프레싱: 주기적으로 데이터를 새로 고치거나, 재요청하여 최신 데이터를 유지할 수 있습니다.
• 에러 핸들링: 비동기 작업 중 발생하는 오류를 처리하고, 오류 상태를 관리할 수 있습니다.

2. Recoil

Recoil은 페이스북에서 개발한 React 상태 관리 라이브러리입니다. React 컴포넌트 트리 내에서 상태를 전역적으로 관리하고 공유하는데 사용됩니다. 기본적으로 React의 컴포넌트 상태와 유사한 방식으로 상태를 정의하고 사용합니다.

주요 특징:

• 아톰(Atoms): 컴포넌트 간에 공유할 수 있는 상태 단위를 "아톰"이라고 합니다. Recoil은 이러한 아톰을 생성하고 정의하는 방식으로 상태를 관리합니다.
• 선택기(Selectors): 아톰을 기반으로 데이터를 변환하거나 연산하는 함수를 "선택기"라고 합니다. 선택기는 다른 선택기나 아톰과 의존성을 가질 수 있습니다.

3. Jotai

Jotai는 Recoil의 영향을 받아 개발된 간단하고 미니멀한 상태 관리 라이브러리입니다. Recoil과 유사한 아이디어와 패턴을 제공하지만, 더 경량화되어 있습니다.

주요 특징:

• 아톰과 컨텍스트: Jotai는 아톰과 컨텍스트 개념을 사용하여 전역 상태를 관리합니다. 컴포넌트 트리 내에서 이러한 상태를 손쉽게 공유할 수 있습니다.
• 리액트 훅 지원: Jotai는 React 훅을 통해 상태를 생성하고 조작할 수 있습니다.

4. Zustand

Zustand는 React를 위한 간단한 리액트 상태 관리 라이브러리입니다. 상태를 관리하기 위해 React의 useReducer 훅과 Context API를 기반으로 합니다.

주요 특징:

• useReducer 기반: 상태를 관리하는 데에 useReducer 훅과 함께 제공되는 dispatch 함수를 사용합니다.
• 컨텍스트 지원: 상태를 컨텍스트 API를 이용하여 컴포넌트 트리 내에서 공유할 수 있습니다.

각 라이브러리나 패턴은 프로젝트의 크기, 복잡도, 팀의 선호도에 따라 선택될 수 있습니다. React-Query는 주로 데이터 통신과 관련하여 사용되며, Recoil과 Jotai는 복잡한 상태 관리를 위해 사용되고, Zustand는 상대적으로 간단한 프로젝트나 상태 관리에 적합합니다.

Redux 또한 Recoil, Zustand와 마찬가지로 전역 상태 관리를 위한 라이브러리입니다. 공통적인 특징은 다음과 같습니다.

1. 상태 불변성 : 상태를 불변성을 유지하면서 업데이트하는 방식입니다. 이를 통해 상태 변경을 추적하고 안정적으로 상태를 공유 및 관리할 수 있습니다.
2. 컴포넌트 분리 : 컴포넌트 UI와 상태 관리 로직을 분리하여 유지보수성과 가독성을 높이고, 재사용성도 높아졌습니다.
3. Context API 기반 : Context 트리 내부에서 변수 및 상태를 자유롭게 공유하고 관리할 수 있습니다.

상태 불변성(Immutability)

프로그래밍에서 변경 불가능한(immutable) 데이터를 의미합니다. 즉, 데이터가 한 번 생성되면 그 값을 변경할 수 없는 것을 말합니다. 상태 불변성은 많은 언어와 라이브러리에서 중요하게 다루어지며, 특히 React, Redux 등과 같은 라이브러리에서 상태 관리를 위해 사용됩니다.

상태 불변성을 유지하는 것은 데이터의 변화를 추적하고 관리하는 데 매우 중요합니다. 여기에는 몇 가지 이점이 있습니다:

1. 예측 가능한 데이터 변경 상태 불변성을 유지하면 데이터의 변화를 추적하기 쉽습니다. 객체나 배열과 같은 복잡한 데이터 구조를 변경할 때, 이전 상태를 복제하고 변경한 새로운 상태를 반환하여 예측 가능한 방식으로 데이터를 업데이트할 수 있습니다.

2. 시간 여행 (Time Travel) 상태가 불변성을 유지하면 이전 상태를 기록해두어 시간 여행 디버깅과 같은 기능을 구현하는 데 도움이 됩니다. 시간 여행은 개발자가 과거의 애플리케이션 상태를 디버깅하고 검사할 수 있는 기능을 말합니다.

3. 성능 최적화 불변성을 유지하면 객체의 변경 여부를 감지하는 데에도 도움이 됩니다. 이는 React와 같은 UI 라이브러리에서 불필요한 렌더링을 방지하는 데 도움이 됩니다.

오늘의 CS 지식

접두어(prefix), 접미어(suffix)

Headless 개념은 소프트웨어 개발에서 주로 사용되는 용어로, 사용자 인터페이스(UI)를 가지지 않은 컴포넌트 또는 서비스를 의미합니다. 일반적으로 웹 애플리케이션 또는 CMS(Content Management System)과 같은 시스템에서 사용됩니다.

Headless 개념은 UI를 분리하여 개발하는 아키텍처 패턴을 지칭합니다. 기존의 전통적인 웹 애플리케이션 개발에서는 백엔드와 프론트엔드가 긴밀하게 결합되어 있었습니다. 하지만 Headless 개념을 도입하면 백엔드와 프론트엔드를 독립적으로 개발하고, 통신하는 API를 통해 데이터를 주고받을 수 있습니다.

Headless 개념에서는 백엔드가 데이터와 비즈니스 로직을 처리하고, 프론트엔드는 이러한 데이터를 가져와 UI를 구성하는 역할을 합니다. 이렇게 분리된 아키텍처를 통해 다양한 프론트엔드 플랫폼(웹, 모바일 앱, IoT 등)에서 동일한 백엔드 서비스를 사용할 수 있으며, 컴포넌트 기반의 재사용성과 유연성을 높일 수 있습니다.

Headless 아키텍처의 주요 이점은 다음과 같습니다:

유연성: 데이터와 비즈니스 로직은 백엔드에서 처리되므로 프론트엔드는 필요에 따라 다양한 방식으로 데이터를 표현하고 사용자 경험을 개선할 수 있습니다.

재사용성: 백엔드 API는 다양한 프론트엔드 플랫폼에서 재사용할 수 있으며, UI 컴포넌트도 다른 애플리케이션에서 재사용할 수 있습니다.

확장성: 백엔드와 프론트엔드가 독립적으로 확장 가능하므로, 시스템이 성장하거나 변화하는 요구사항에 대응하기 쉬워집니다.

개발 팀 간 협업: 백엔드와 프론트엔드 개발 팀이 독립적으로 작업할 수 있으므로 개발 프로세스가 병렬로 진행될 수 있고, 팀 간 협업이 용이해집니다.

1. Compound(화합물) 컴포넌트

Compound Component는 리액트(React)에서 사용되는 패턴 중 하나입니다. 이 패턴은 부모 컴포넌트와 그 자식 컴포넌트들로 구성된 복합적인 컴포넌트를 생성하는 방법을 제공합니다.

일반적으로 리액트에서 컴포넌트 간에 데이터를 전달하기 위해서는 props를 사용합니다. 그러나 Compound Component 패턴을 사용하면, 부모 컴포넌트가 자식 컴포넌트들에게 직접적으로 데이터를 전달할 수 있습니다. 이는 부모 컴포넌트와 자식 컴포넌트들 사이의 관계를 더욱 직관적으로 만들어줍니다.

Compound Component 패턴은 주로 UI 컴포넌트 라이브러리에서 사용됩니다. 예를 들어, 탭(Tab) 컴포넌트를 생각해보겠습니다. 탭 컴포넌트는 여러 개의 탭을 가지고 있고, 각 탭을 클릭하면 해당 탭의 내용이 보여집니다. 이때, Compound Component 패턴을 사용하면 부모 컴포넌트는 탭 컴포넌트 자체를 생성하고, 자식 컴포넌트로 각 탭을 구성하는 탭 아이템(TabItem) 컴포넌트를 전달할 수 있습니다.

부모 컴포넌트는 탭 컴포넌트의 속성을 통해 선택된 탭을 추적하고, 자식 컴포넌트에게 필요한 데이터를 전달할 수 있습니다. 자식 컴포넌트들은 부모 컴포넌트에서 전달받은 데이터를 사용하여 각 탭 아이템을 렌더링하고, 이벤트 핸들러를 등록할 수 있습니다.

이렇게 Compound Component 패턴을 사용하면, 부모 컴포넌트와 자식 컴포넌트들 사이의 관계가 더욱 명확해지고, 컴포넌트의 사용자가 더 쉽게 컴포넌트를 조작하고 커스터마이징할 수 있습니다.

compoundInput.tsx

import React, { useContext } from "react";

/** context api를 이용해서 컴포넌트 내부에서 공유할 데이터를 정의함 */
const InputContext = React.createContext({
  id: "",
  value: "",
  type: "text",
  onchange: () => {},
});

/** 부모 컴포넌트, context api를 통해 데이터를 공유할 수 있도록 설정 */
export const InputWrapper = ({ id, value, type, onChange, children }) => {
  const contextValue = { id, value, type, onChange };
  return (
    <InputContext.Provider value={contextValue}>
      {children}
    </InputContext.Provider>
  );
};

/** 자식 컴포넌트, context api를 통해 데이터 사용함
    부모 컴포넌트가 props로 받아서 context에 저장시킨 기본 데이터도 가져오고, 추가로 자신만의 props를 받아서 사용할 수도 있음
*/
const Input = ({ ...props }) => {
  const { id, value, type, onChange } = useContext(InputContext);
  return (
    <input id={id} value={value} type={type} onChange={onChange} {...props} />
  );
};

const Label = ({ children, ...props }) => {
  const id = useContext(InputContext);
  return (
    <label id={id} {...props}>
      {children}
    </label>
  );
};

/** 자식 컴포넌트를 부모 컴포넌트의 props로 등록함 */
InputWrapper.Input = Input;
InputWrapper.Label = Label;

App.js

/** 데이터 관리 */
  const [name, setName] = useState("");

  const handleChange = (event) => {
    setName(event.target.value);
  };

<InputWrapper id="name" value={name} type="text" onChange={handleChange}>
        <InputWrapper.Label>Name</InputWrapper.Label>
        <InputWrapper.Input />
</InputWrapper>

2. Function as Child 컴포넌트

자식 요소에 어떤 것이 들어올지 모르는 상황에서, 부모 요소는 오직 데이터 로직만 갖고, 자식 요소를 컴포넌트 통째로 받도록 구성하는 컴포넌트입니다.

실제 컴포넌트 사용처인 App.js에서는 ui와 관련된 마크업을 원하는대로 마음대로 바꾸어서 쓰고, 데이터 로직은 컴포넌트 내부에서 설정 및 관리하는 것입니다.

functionAsChildInput.js

import React, { useState } from "react";

const FunctionAsChildInput = ({ children }) => {
  const [value, setValue] = useState("");

  const handleChange = (event) => {
    setValue(event.target.value);
  };

  return children({
    value,
    onchange: { handleChange },
  });
};

export default FunctionAsChildInput;

App.js

<FunctionAsChildInput>
        {({ value, onChange }) => {
          return (
            <div className="input-container">
              <label id="1">Name</label>
              <input type={"text"} id="1" value={value} onChange={onChange} />
            </div>
          );
        }}
</FunctionAsChildInput>

3. Custom Hook 패턴

useInput이라는 훅을 만들어서, 데이터 로직을 다 구현해놓고 실제 사용처에서는 비구조화 할당을 통해 훅을 통해 반환된 객체의 속성을 추출해서 각각의 변수에 할당해서 사용하려는 코드입니다.

아래 코드의 경우, value 속성은 name 변수에 할당되고 onChange 속성은 onChangeName 변수에 할당되었습니다.

useInput.js

function useInput() {
  const [value, setValue] = useState('');

  const onChange = (event) => {
    setValue(event.target.value);
  };

  return { value, onChange };
}

App.js

const {value : name, onChange : onChangeName} = useInput()

<label htmlFor='1'>Name</label>
<input type="text" id='1' value={name} onChange={onChangeName} />

참조링크

[10분 테코톡] 호프의 프론트엔드에서 컴포넌트

1. 파싱(Parse)

웹 브라우저는 HTML, CSS 및 JavaScript와 같은 웹 페이지의 리소스를 서버로부터 가져옵니다. 그리고 가져온 리소스들은 파싱되어 문서 객체 모델(DOM) 및 CSS 객체 모델(CSSOM)로 변환됩니다. 이 단계에서 HTML 마크업을 DOM 트리로 구문 분석하고, CSS 규칙을 파싱하여 CSSOM 트리를 구성합니다.

그리고 DOM 트리와 CSSOM 트리를 이용해서 Render Tree를 생성하고, 문서의 구조와 각 노드의 스타일 속성이 입력되게 됩니다.

파싱이란?

파싱은 주어진 문장이나 코드를 구성 요소로 분해하고 그 구조를 이해하는 과정을 말합니다. 또한 파싱 과정에서 코드 분석을 하며, 특정 액션을 취하거나 데이터 추출, 포괄적인 개념으로의 변환 등의 다양한 목적을 달성할 수도 있습니다. 따라서 파싱을 위해서는 해당 도메인에서의 특정 지식이나 약속된 규칙을 잘 이해합니다.

2. 레이아웃(Layout, Reflow)

레이아웃 단계에서는 DOM 트리와 CSSOM 트리를 기반으로 상대적인 단위(rem, vh, vw)를 실제 픽셀 단위로 변환하고, 각 요소의 크기와 위치를 계산하여 레이아웃 트리(렌더 트리, render tree)를 생성합니다. 레이아웃 트리는 화면에 표시되는 각 요소의 정확한 위치와 크기를 정의합니다. 이 단계에서는 브라우저 창의 크기나 사용자의 스크롤 위치 등과 같은 뷰포트의 속성을 고려하여 요소를 배치합니다.

CSS의 상대적인 단위

1. em

   요소의 상대적인 크기를 나타내는 단위로, 부모 요소의 폰트 크기가 기준이 됩니다.

2. rem

   root em의 약자로, em과 마찬가지로 요소의 상대적인 크기를 나타냅니다. 기준은 root 요소의 폰트 크기가 기준이 됩니다. 따라서 전체 페이지에 걸쳐 일관된 크기를 유지할 수 있습니다.

3. %

   부모의 요소의 크기를 기준으로 상대적인 크기를 나타내는 단위입니다. 예를 들어 부모 요소의 width가 200px인데, 자식 요소의 폭이 50%이면 자식 요소의 실제 width값은 100px이 됩니다.

4. vw, vh

   viewport width와 viewport height의 비율을 의미하는 단위입니다. vw는 뷰포트 너비의 1/100을, vh는 뷰포트 높이의 1/100을 나타냅니다. 예를 들어, 50vw는 현재 뷰포트의 너비의 50%를 나타내고, 75vh는 뷰포트의 높이의 75%를 나타냅니다.

상대적인 단위들은 반응형 웹 디자인과 레이아웃 조정에 유용하게 사용되며, 화면 크기에 따라 자동으로 조정되어 다양한 장치와 화면 크기에서 일관된 디자인을 제공할 수 있습니다.

뷰포트(viewport)

뷰포트(viewport)는 웹 페이지를 표시하는 디바이스의 실제 가시 영역을 의미합니다. 즉, 사용자가 웹 브라우저 안에서 웹 페이지를 볼 수 있는 실제 화면 영역을 말합니다. 웹 브라우저는 웹 페이지를 뷰포트에 표시하고 사용자가 상호 작용할 수 있도록 합니다.

뷰포트의 크기는 디바이스의 화면 크기에 따라 다르며, 일반적으로 픽셀 단위로 표현됩니다. 뷰포트의 너비와 높이는 웹 페이지에서 사용할 수 있는 가용한 공간을 나타냅니다.

모바일 디바이스의 경우, 뷰포트의 너비는 일반적으로 디바이스의 화면의 실제 픽셀 너비와 동일합니다. 하지만 초기에는 데스크톱 웹 페이지를 모바일 디바이스에서 확대해서 보여주는 경우도 있었습니다. 이때 뷰포트의 너비는 초기 화면에 맞추어 설정되어 전체 컨텐츠가 화면에 나타날 수 있도록 했습니다.

그러나 모바일 웹 디자인에서는 반응형 레이아웃과 뷰포트 메타 태그를 사용하여 뷰포트를 제어하고 조정하는 것이 중요해졌습니다. 뷰포트 메타 태그를 사용하면 웹 개발자가 뷰포트의 초기 크기, 축소/확대 제한, 페이지 배율 조정 등을 설정할 수 있습니다. 이를 통해 모바일 장치에서 웹 페이지가 올바르게 표시되고 사용자 경험이 향상될 수 있습니다.

뷰포트는 반응형 웹 디자인과 모바일 최적화에 핵심적인 역할을 합니다. 적절한 뷰포트 설정과 레이아웃 조정을 통해 다양한 화면 크기와 디바이스에서 웹 페이지가 최적으로 표시되며, 사용자 경험이 향상될 수 있습니다.

3. 페인트(Paint, Repaint)

페인트 단계에서는 레이아웃 트리의 각 요소를 실제로 그려줍니다. 이 단계에서는 요소의 배경색, 텍스트, 이미지 등을 브라우저의 렌더링 엔진을 통해 화면에 페인팅합니다. 브라우저의 렌더링 엔진은 DOM Tree의 각 요소를 순서대로 탐색하며 해당 요소의 스타일과 속성을 적용하여, 화면에 요소를 배치하고 화면에 그래픽을 그립니다. Paint 단계에서는 화면을 업데이트하는 작업에 집중되며, 이 단계에서의 작업은 GPU가 아닌 'CPU'에 의해 처리됩니다.

4. 합성(Composite)

Composite 단계는 렌더링 엔진이 그려진 그래픽을 최종 화면에 조합하는 단계입니다. 이 단계에서는 레이아웃 트리에서 각 요소가 어떻게 겹치고 상호작용하는지 계산하고, 화면에 그려진(paint된) 그래픽 요소들을 합성하여 최종적으로 화면에 표시될 이미지를 생성합니다. 각 그래픽 요소들은 별도의 레이어로 생성되며, 여러 개의 레이어가 합성되어 최종 이미지를 생성하게 됩니다.

Composite 단계는 GPU를 사용하여 그래픽을 처리하며, 보통 하드웨어 가속 기능을 활용하여 빠른 화면 갱신을 지원합니다. 여러 개의 레이어(layer)로 구성된 화면의 각 부분이 합성되어 최종 이미지가 생성되는 과정입니다.

브라우저는 Paint 단계에서 화면에 그래픽을 그리고, Composite 단계에서 그려진 그래픽을 조합하여 최종 화면을 구성합니다. 이렇게 구성된 화면은 사용자에게 표시됩니다. Paint 단계와 Composite 단계는 렌더링 과정에서 서로 다른 역할을 수행하며, GPU와 CPU를 효율적으로 활용하여 빠르고 부드러운 화면 갱신을 제공합니다.

브라우저의 렌더링 vs 리액트의 렌더링

브라우저의 렌더링은 웹 페이지의 HTML, CSS, JavaScript 등의 리소스를 가져와서 화면에 표시하는 과정을 의미합니다.

리액트의 렌더링은 리액트 컴포넌트의 가상 DOM(Virtual DOM)을 생성하고 이를 기반으로 실제 DOM을 업데이트하는 과정을 의미합니다.

결국 '렌더링'을 한다는 것은 리소스의 변화를 감지하고 해당 페이지의 구조와 속성을 분석해서 dom을 만들고, 구조와 계층을 시각화하기 위해서 dom tree를 만들고, 다시 그것들을 바탕으로 화면을 업데이트 시켜주는 개념이라고 할 수 있습니다.

리액트의 렌더링 과정

초기 렌더링

• 리액트 컴포넌트의 가상 DOM(가상 DOM 트리)을 생성합니다.
• 가상 DOM을 기반으로 실제 DOM에 업데이트를 수행합니다. 이를 마운팅(Mounting)이라고도 합니다.

업데이트

• 컴포넌트의 상태(State)나 속성(Properties)이 변경되면, 리액트는 업데이트를 트리거합니다.
• 변경된 상태를 기반으로 새로운 가상 DOM(가상 DOM 트리)을 생성합니다.
• 이전 가상 DOM과 새로운 가상 DOM을 비교하여 변경된 부분을 찾습니다. 이 과정은 가상 DOM의 Diff 알고리즘을 활용하여 효율적으로 수행됩니다.
• 변경된 부분만을 선택적으로 실제 DOM에 반영하여 업데이트합니다. 이를 리렌더링(Rendering)이라고도 합니다.

리액트의 가상 DOM을 활용하는 이유는, 모든 컴포넌트를 다시 렌더링하는 대신 변경된 부분만을 효율적으로 업데이트하기 위해서입니다. 가상 DOM은 실제 DOM 조작을 최소화하고, 변경 사항을 효율적으로 반영하여 성능을 개선합니다. 이에 따라 효율적인 컴포넌트 업데이트와 빠른 UI 렌더링이 가능해졌습니다.

unmount

Unmount 과정은 컴포넌트의 생명주기(Lifecycle) 중 "componentWillUnmount" 메서드가 호출되는 시점에 발생하는 것으로, 이 메서드는 컴포넌트가 화면에서 제거되기 전에 실행됩니다. 주로 리소스 정리, 타이머 해제, 이벤트 핸들러 해제 등의 작업을 수행하는 데 사용됩니다.

Unmount 단계에서는 컴포넌트의 가상 DOM은 더 이상 필요하지 않으며, 컴포넌트가 화면에서 사라지므로 실제 DOM에서도 해당 컴포넌트와 관련된 요소들이 제거됩니다.

컴포넌트가 화면에서 제거되는 주요 상황은 다음과 같습니다.

1. 라우팅 변경: 사용자가 다른 페이지로 이동하거나 라우팅 경로가 변경될 때, 해당 페이지의 컴포넌트는 화면에서 제거됩니다. 이는 리액트 라우터 또는 다른 라우팅 라이브러리를 사용하여 처리됩니다.

2. 조건부 렌더링: 화면에서 특정 조건에 따라 컴포넌트를 동적으로 추가하거나 제거하는 경우가 있습니다. 조건이 변경되어 해당 컴포넌트가 화면에 더 이상 필요하지 않을 때, 컴포넌트는 제거됩니다.

3. 데이터 변경: 컴포넌트의 데이터가 변경되어 해당 컴포넌트가 화면에 더 이상 필요하지 않은 경우에도 컴포넌트는 제거될 수 있습니다. 예를 들어, 리스트 컴포넌트에서 항목이 삭제되거나 필터링 조건에 따라 특정 항목이 숨겨질 때 해당 컴포넌트는 제거됩니다.

리액트에서 컴포넌트가 unmount되면 다음과 같은 과정을 진행합니다.

• 컴포넌트의 "componentWillUnmount" 메서드가 호출됩니다. 이 메서드 내에서는 컴포넌트의 정리 작업이 수행됩니다.
• 해당 컴포넌트와 관련된 실제 DOM 요소들이 제거됩니다. 이로써 화면에서 해당 컴포넌트가 완전히 제거되고, 관련된 자원들이 해제됩니다.

Unmount 단계는 컴포넌트의 라이프사이클에서 중요한 단계입니다. 컴포넌트가 더 이상 필요하지 않을 때 메모리 누수를 방지하고 자원을 정리하기 위해 Unmount 단계에서 필요한 작업을 수행합니다. 이를 통해 애플리케이션의 성능과 자원 관리를 향상시킬 수 있습니다.

참고로 함수형 컴포넌트에서는 useEffect 훅을 이용하면 mount, unmount 시 실행할 동작을 정해줄 수도 있습니다.

렌더링 컨텍스트

렌더링 컨텍스트(Rendering Context)는 리액트에서 컴포넌트 트리 전체에 대한 데이터를 공유하기 위한 메커니즘입니다. 렌더링 컨텍스트를 사용하면 컴포넌트 간에 데이터를 전달하고 공유할 수 있으며, 중첩된 컴포넌트에서도 쉽게 접근할 수 있습니다.

렌더링 컨텍스트는 주로 상위 컴포넌트에서 하위 컴포넌트로 데이터를 전달할 때 사용됩니다. 이를 통해 프로퍼티 체인을 통해 데이터를 하위 컴포넌트로 전달하는 것보다 간편하고 효율적인 방식으로 데이터를 공유할 수 있습니다.

렌더링 컨텍스트는 다음과 같은 주요 특징을 가지고 있습니다:

1. Provider와 Consumer: 렌더링 컨텍스트는 Provider와 Consumer라는 두 가지 주요 구성 요소로 구성됩니다. Provider는 데이터를 제공하는 컴포넌트이고, Consumer는 데이터를 소비하는 컴포넌트입니다.

2. 데이터 공유: Provider 컴포넌트는 하위 컴포넌트에 데이터를 전달합니다. 이 데이터는 컴포넌트 트리의 하위 컴포넌트에서 Consumer 컴포넌트를 통해 접근할 수 있습니다.

3. 중첩된 컴포넌트에서의 접근: 렌더링 컨텍스트는 중첩된 컴포넌트에서도 쉽게 접근할 수 있습니다. 컴포넌트 트리의 어느 위치에서든 Provider 컴포넌트를 사용하여 데이터를 제공하고, 필요한 곳에서 Consumer 컴포넌트를 사용하여 데이터를 소비할 수 있습니다.

렌더링 컨텍스트는 주로 전역적인 상태 관리, 테마, 로컬라이제이션, 인증 정보 등과 같이 여러 컴포넌트에서 공유되어야 하는 데이터를 전달하는데 사용됩니다. 이를 통해 컴포넌트 간의 데이터 전달을 간소화하고, 중복 코드를 줄일 수 있습니다.

렌더링 컨텍스트는 React.createContext() 함수를 사용하여 생성하며, Provider와 Consumer 컴포넌트를 통해 데이터를 제공하고 소비합니다.

웹 브라우저의 구조

User Interface

• 사용자가 웹 브라우저와 상호작용할 수 있도록 하는 부분입니다.
• 주소 표시줄, 이전/다음 버튼, 즐겨찾기, 확대/축소 등의 기능이 포함됩니다.

Browser Engine

브라우저 엔진은 User Interface와 Browser Engine을 연결하는 역할을 합니다.

Rendering Engine

• 웹 페이지의 HTML, CSS 등을 해석하여 화면에 그래픽을 그리는 엔진입니다.
• DOM Tree와 CSSOM Tree를 생성하고, 이를 기반으로 레이아웃을 처리하고 화면에 그래픽 요소를 배치합니다.
• 대표적인 렌더링 엔진으로는 Blink(Chrome, Opera), Gecko(Firefox), WebKit(Safari) 등이 있습니다.
• 크롬의 경우 원래는 Webkit을 쓰다가, 2013년부터 Webkit에서 갈라져 나온 Blink 엔진을 사용하고 있습니다.

Networking

• Networking은 웹 브라우저에서 서버로의 통신을 처리하는 역할을 의미합니다.
• HTTP 요청과 응답을 주고받아 웹 페이지의 리소스를 로드하고 전송합니다.
• 네트워킹은 웹 페이지의 리소스를 다운로드하고, 외부 서버와의 통신을 처리하는 등의 네트워크 관련 작업을 담당합니다.

JavaScript Interpreter

• 웹 페이지에 포함된 JavaScript 코드를 해석하고 실행합니다.
• 자바스크립트 엔진은 브라우저 엔진의 일부로 포함되어 있습니다.
• 예를 들어, V8 엔진은 Chrome에서 사용되고, SpiderMonkey 엔진은 Firefox에서 사용됩니다.

UI Backend

• 사용자 인터페이스를 그리는 데 사용되는 백엔드 시스템입니다.
• 플랫폼에 따라 다양한 시스템 API를 사용하여 윈도우, 버튼, 메뉴 등을 그립니다.

UI Backend는 각 플랫폼의 기능과 시스템 API를 활용하여 UI 요소를 그리고 이벤트를 처리합니다. 이를 통해 사용자 인터페이스를 그리고 사용자 입력에 응답하는 등의 작업을 수행합니다. 각 플랫폼은 해당 플랫폼에 특화된 UI Backend를 가지고 있으며, 플랫폼에 따라 API 및 도구가 다를 수 있습니다.

예를 들어, Windows에서는 UI 요소를 그리기 위해 Windows API 함수를 사용하고, macOS에서는 Core Graphics 및 AppKit을 활용하여 UI를 그리고 이벤트를 처리합니다. 이와 같은 방식으로 UI Backend는 각 플랫폼에서 원활한 UI 표시와 상호작용을 제공합니다.

Data Persistance

• 웹 브라우저 내에서 데이터를 저장하고 관리하는 기능입니다.
• 쿠키, 로컬 스토리지, 세션 스토리지, 웹 데이터베이스 등의 저장소를 사용하여 데이터를 유지합니다.

Back-End Integration

• Back-End Integration은 웹 브라우저와 웹 서버 간의 데이터 통신을 관리하는 역할을 의미합니다.
• 웹 브라우저에서 서버로 데이터를 전송하거나, 서버로부터 동적인 콘텐츠를 받아오는 등의 작업을 수행합니다.
• 백엔드 통합은 웹 애플리케이션에서 서버 측과의 상호작용을 담당합니다.

Networking은 주로 웹 브라우저의 네트워크 관련 기능을 포함하고, HTTP 요청 및 응답을 처리합니다. 이는 웹 페이지의 리소스를 로드하거나, API와의 통신을 위한 네트워크 작업을 담당합니다.

반면에 Back-End Integration은 주로 웹 애플리케이션과 백엔드 서버 간의 데이터 통신을 관리합니다. 웹 브라우저에서 서버로 데이터를 전송하고, 서버로부터 동적인 콘텐츠를 받아오는 등의 작업을 수행합니다. 이는 웹 애플리케이션의 비즈니스 로직과 데이터 처리를 위한 서버와의 상호작용을 담당합니다.

따라서, Networking은 네트워크 관련 작업을 처리하고, Back-End Integration은 웹 애플리케이션과 서버 간의 데이터 통신을 관리하는 역할을 수행합니다. 두 개념은 서로 관련이 있으며 웹 브라우저의 기능을 지원하기 위해 함께 동작합니다.

참조링크

[10분 테코톡] 콤피의 CSS를 통한 브라우저 렌더링 최적화 [10분 테코톡] ☕️ 체프의 브라우저 렌더링

React에서 "nest"라는 개념은 컴포넌트 계층 구조를 구성하는 것을 의미합니다. Nesting은 컴포넌트를 다른 컴포넌트 내에 중첩시키는 것을 말합니다.

React에서는 UI를 작은 단위의 재사용 가능한 컴포넌트로 구성합니다. 이러한 컴포넌트들은 계층 구조로 이루어져 부모 컴포넌트와 자식 컴포넌트 관계를 형성합니다. 이때, 부모 컴포넌트 내에 자식 컴포넌트를 중첩시켜 사용하는 것을 Nesting이라고 합니다.

Nesting을 통해 복잡한 UI를 단순화하고 구성 요소를 재사용할 수 있습니다. 각 컴포넌트는 독립적이고 재사용 가능한 기능을 가지며, 이러한 컴포넌트들을 중첩시켜 원하는 복잡도의 UI를 구성할 수 있습니다. 부모 컴포넌트는 자식 컴포넌트에게 데이터나 속성을 전달할 수 있고, 자식 컴포넌트는 이를 받아 사용할 수 있습니다.

React의 Nesting은 컴포넌트의 재사용성과 유지보수성을 향상시키는 데에 도움을 주는 중요한 개념입니다. 컴포넌트를 작은 단위로 나누고 이를 중첩시켜 사용함으로써 코드의 가독성과 구조를 개선할 수 있습니다.

Webpack

Webpack은 JavaScript 애플리케이션을 위한 정적 모듈 번들러입니다. 웹팩은 의존성 그래프를 만들어 애플리케이션의 모든 모듈을 포함하는 번들 파일을 생성합니다. 이를 통해 여러 개의 파일을 하나로 결합하고 애플리케이션을 효율적으로 로드할 수 있습니다.

웹팩이 의존성 그래프를 그리는 이유는 모듈 간의 의존 관계를 파악하여 번들 파일을 생성하기 위함입니다. 의존성 그래프를 통해 웹팩은 어떤 모듈이 어떤 모듈에 의존하고 있는지를 알 수 있고, 이를 기반으로 모듈을 적절한 순서로 결합하여 번들 파일을 생성합니다.

웹팩은 주로 웹 애플리케이션의 자바스크립트, CSS, 이미지 및 기타 리소스를 처리합니다. 웹팩은 애플리케이션의 모든 모듈을 분석하고 각 모듈을 적절한 순서로 결합하여 번들 파일을 생성합니다. 이 과정에서 플러그인과 로더를 사용하여 추가적인 작업을 수행할 수 있습니다.

웹팩의 동작 순서

웹팩은 의존성 그래프를 통해 어떤 모듈이 어떤 모듈에 의존하고 있는지를 알 수 있고, 이를 기반으로 모듈을 적절한 순서로 결합하여 번들 파일을 생성합니다. 이렇게 생성된 번들 파일은 클라이언트에서 로드되어 웹 애플리케이션을 실행합니다.

1. 엔트리(Entry) 설정:

웹팩 설정 파일에서 엔트리 포인트를 지정합니다. 엔트리 포인트는 의존성 그래프의 시작점이 되는 파일입니다. 웹팩은 해당 파일을 기준으로 의존성 그래프를 생성합니다.

2. 모듈 로딩과 의존성 그래프 생성:

웹팩은 엔트리 파일을 로드하고 해당 파일이 의존하는 다른 모듈들을 식별합니다. 모듈은 파일 단위로 구성되며, 웹팩은 각 모듈의 의존성을 파악하여 의존성 그래프를 구성합니다.

3. 로더 적용:

웹팩은 로더(Loader)를 사용하여 각 모듈을 처리합니다. 로더는 웹팩이 이해할 수 있는 형식으로 모듈을 변환하거나 추가 작업을 수행하는 역할을 합니다. 예를 들어, Babel 로더를 사용하여 최신 JavaScript 문법을 구 버전의 JavaScript로 변환하거나, CSS 로더를 사용하여 CSS 파일을 로드하고 번들에 포함할 수 있습니다.

4. 의존성 해결:

웹팩은 의존성 그래프를 분석하여 각 모듈이 의존하는 다른 모듈을 찾습니다. 이 과정에서 웹팩은 모듈 해석(Module Resolution) 규칙을 따라 모듈의 경로를 해석하고 필요한 모듈을 로드합니다.

5. 번들 파일 생성:

웹팩은 모든 모듈과 의존성을 분석하고, 이를 하나의 번들 파일로 결합합니다. 번들 파일은 모든 애플리케이션 코드와 의존성을 포함하며, 클라이언트에서 로드될 준비가 된 최종 애플리케이션 번들입니다.

Loader(로더)

로더는 웹팩이 모듈을 처리하는 동안 사용하는 변환기입니다. 로더는 다양한 유형의 파일(JavaScript, CSS, 이미지 등)을 웹팩이 이해할 수 있는 형식으로 변환하거나 추가적인 작업을 수행합니다. 로더는 웹팩의 구성 파일에서 지정되며, 각각의 로더는 특정 유형의 파일 또는 리소스를 처리하기 위한 설정을 갖고 있습니다. 일반적으로 로더는 소스 코드를 변환하거나 필요한 리소스를 로드하여 번들에 포함시키는 역할을 수행합니다. 로더는 webpack의 구성 파일에서 설정되며, 여기서 필요한 로더를 추가하거나 옵션을 지정해서 사용할 수 있습니다.

대표적인 로더에는 Babel, CSS 로더, 이미지 로더 등이 있습니다.

• JavaScript 파일을 변환: Babel 로더는 최신 JavaScript 문법을 구 버전의 JavaScript로 변환합니다.
• CSS 파일 처리: CSS 로더는 CSS 파일을 로드하고 웹팩 번들에 포함시킵니다.
• 이미지 파일 처리: 이미지 로더는 이미지 파일을 로드하고 번들에 포함하거나, 이미지 파일 경로를 수정하여 해당 경로로 로드되도록 합니다.

Babel(바벨)

바벨(Babel)은 주로 웹팩(Webpack)과 함께 사용되며, 웹팩 내에서 동작하여 최신 자바스크립트 문법을 구 버전의 자바스크립트로 변환해줍니다.

바벨은 트랜스파일러(transpiler)로, 최신 자바스크립트 문법을 이전 버전의 자바스크립트로 변환하는 역할을 합니다. 이를 통해 최신 문법을 지원하지 않는 환경에서도 코드를 실행할 수 있게 됩니다.

웹팩과 바벨을 함께 사용하면, 웹팩의 로더 기능을 통해 바벨을 적용할 수 있습니다. 웹팩은 바벨 로더를 사용하여 웹 애플리케이션의 자바스크립트 파일을 로드하고, 바벨을 통해 해당 파일을 구 버전의 자바스크립트로 변환합니다.

웹팩의 바벨 로더를 설정하면, 웹팩은 지정된 바벨 구성을 사용하여 소스 코드에서 찾은 최신 문법을 구 버전의 자바스크립트로 변환합니다. 이를 통해 웹 애플리케이션은 구 버전의 브라우저에서도 실행할 수 있는 호환성을 갖게 됩니다.

바벨은 플러그인 시스템을 제공하여 추가적인 기능을 적용할 수도 있습니다. 예를 들어, 바벨 플러그인을 사용하여 화살표 함수, 클래스 문법, 모듈 문법 등의 최신 자바스크립트 기능을 변환할 수 있습니다.

따라서, 웹팩과 바벨을 함께 사용하면 웹 애플리케이션의 자바스크립트 코드를 호환성을 갖는 구 버전으로 변환할 수 있으며, 최신 자바스크립트 문법을 사용할 수 있는 개발 경험을 제공할 수 있습니다.

Module(모듈)

모듈은 프로그램을 구성하는 자바스크립트 코드의 작은 독립적인 단위이며, 재사용 가능한 코드 조각을 캡슐화한 것입니다. 이러한 모듈은 파일 단위로 구성되어 있지만, 한 파일에 하나 이상의 모듈이 포함될 수 있습니다. 모듈은 일반적으로 특정 기능을 수행하거나 변수, 함수, 클래스 등을 내보내는(exports) 역할을 합니다.

모듈 간의 의존성

모듈 간의 의존성은 모듈이 다른 모듈을 사용하거나 참조하는 관계를 의미합니다. 즉, 하나의 모듈이 다른 모듈의 기능, 변수, 함수, 클래스 등을 필요로 할 때 의존성이 발생합니다. 모듈 간의 의존성은 코드의 구조를 구성하고, 모듈화된 개발을 가능하게 합니다. 이는 코드의 재사용성, 유지 보수성, 확장성 등을 향상시키는데 도움을 줍니다.

모듈에는 내부 의존성과 외부 의존성이 있습니다. 모듈 내부에서 다른 모듈을 직접 참조하는 경우에는 주로 함수나 클래스를 사용합니다. A 모듈에서 B 모듈의 함수를 호출하는 경우 A는 B에 의존성이 있다고 할 수 있습니다. 외부 의존성은 모듈이 외부 모듈이나 라이브러리를 가져와서 사용하는 경우 발생하는 것입니다.

웹팩은 이러한 의존성 관리를 도와주는 매커니즘을 제공하며, 자바스크립트에서 모듈 간의 의존성을 해결하고 번들링하는 도구 중 하나라고 할 수 있습니다. 웹팩을 통해 모듈 간의 의존성 그래프를 분석하고 적절하게 모듈을 결합하여 번들 파일을 생성할 수 있습니다.

Bundle(번들)

번들은 웹팩(Webpack)이나 기타 모듈 번들러에서 생성되는 결과물입니다. 번들은 여러 개의 모듈과 종속성을 결합하여 하나의 단일 파일로 생성됩니다. 번들은 애플리케이션의 모든 코드, 스타일시트, 이미지 및 기타 리소스를 포함할 수 있습니다. 이렇게 번들로 묶여진 파일은 웹 서버에서 제공되고 클라이언트에서 로드됩니다.

번들 파일은 웹팩을 사용하여 여러 모듈을 결합하여 생성됩니다. 웹팩은 모듈 간의 의존성 그래프를 분석하고, 각 모듈을 적절한 순서로 결합하여 번들 파일을 생성합니다. 번들링을 통해 모듈 간의 의존성 문제를 해결하고, 웹 애플리케이션의 전체 코드를 단일 파일로 로드할 수 있습니다.

따라서, 번들 파일은 여러 개의 모듈이 결합된 결과물이라고 할 수 있으며, 웹 애플리케이션에서 사용되는 자바스크립트 코드를 포함합니다. 번들링을 통해 애플리케이션의 성능이 향상되고 네트워크에서의 파일 요청 수가 줄어듭니다.

웹 애플리케이션에서는 각각의 파일마다 네트워크 요청이 필요합니다. 파일 요청은 클라이언트와 서버 간의 왕복 시간(delay)이 소요되므로, 파일 요청 횟수가 많을수록 페이지 로딩 속도가 느려질 수 있습니다.

번들링을 통해 여러 개의 모듈을 하나의 번들 파일로 결합하면, 번들 파일 하나만을 로드하기 위한 단일 파일 요청만 필요합니다. 이는 페이지 로딩 속도를 향상시키고, 애플리케이션의 초기 로딩 시간을 단축시킵니다. 또한, 파일 요청 횟수가 감소함으로써 네트워크 대역폭을 효율적으로 사용할 수 있습니다.

번들링은 또한 코드 압축과 최적화 기능을 포함할 수 있습니다. 압축된 번들 파일은 파일 크기를 줄이고, 네트워크 전송 시간을 최소화하여 성능을 개선할 수 있습니다.

네트워크 대역폭(Bandwidth)

네트워크 대역폭(Bandwidth)은 네트워크를 통해 전송할 수 있는 데이터 양의 측정 단위입니다. 대역폭은 네트워크 연결의 속도를 나타내는 중요한 요소입니다.

일반적으로 대역폭은 초당 전송할 수 있는 데이터 비트 수로 표현됩니다. 예를 들어, "1 Mbps"라는 대역폭은 초당 1 백만 비트(1,000,000 비트)를 전송할 수 있다는 것을 의미합니다. 대역폭은 일반적으로 초당 비트(bps), 킬로비트(kbps), 메가비트(mbps), 기가비트(gbps) 단위로 표시됩니다.

대역폭은 네트워크 연결의 속도와 관련이 있습니다. 더 높은 대역폭을 가진 네트워크 연결은 더 많은 데이터를 빠르게 전송할 수 있습니다. 따라서, 대역폭이 큰 네트워크 연결은 대용량 파일의 다운로드나 미디어 스트리밍과 같은 데이터 집약적인 작업에 적합합니다.

네트워크 대역폭은 웹 애플리케이션의 성능에 영향을 미칠 수 있습니다. 높은 대역폭을 가진 사용자의 경우, 대용량 파일이나 이미지와 같은 리소스를 빠르게 로드할 수 있습니다. 그러나 대역폭이 낮은 사용자의 경우, 파일 다운로드나 페이지 로딩이 상대적으로 느릴 수 있습니다.

따라서, 웹 애플리케이션을 개발할 때에는 네트워크 대역폭을 고려하여 리소스의 크기와 최적화 방법을 결정하는 것이 중요합니다. 적절한 리소스 압축, 캐싱, 코드 스플리팅과 같은 기술을 사용하여 대역폭을 효율적으로 활용하고, 사용자들에게 빠른 성능을 제공할 수 있도록 해야 합니다.

'대역폭'은 물리적으로는 신호가 통과할 수 있는 주파수 스펙트럼의 폭을 나타냅니다. 예를 들어, 오디오 신호의 대역폭은 해당 신호가 얼마나 넓은 주파수 범위에서 전송되는지를 나타냅니다.

dependency(종속성)

프로그래밍에서 종속성은 외부 라이브러리, 프레임워크, 모듈, 패키지 등을 포함할 수 있습니다. 종속성을 사용하면 기능을 다시 구현하지 않고도 외부에서 제공하는 기능을 활용할 수 있습니다. 종속성을 사용하면 다음과 같은 장점을 얻을 수 있습니다.

• 코드 재사용: 이미 구현된 기능을 재사용하여 개발 시간과 노력을 절약할 수 있습니다.
• 기능 확장: 외부 종속성을 통해 애플리케이션에 새로운 기능을 추가할 수 있습니다.
• 효율성: 외부 종속성은 주로 커뮤니티나 개발자들에 의해 유지되고 업데이트되므로, 코드 품질과 보안을 향상시킬 수 있습니다.

종속성을 사용하기 위해선 해당 종속성을 애플리케이션에 포함시키거나, 외부로부터 가져와야 합니다. 이를 위해 패키지 매니저(NPM, Yarn 등)를 사용하거나, CDN(Content Delivery Network)에서 외부 스크립트를 가져오는 등의 방법을 사용합니다. 이렇게 가져온 종속성은 애플리케이션에서 해당 기능을 사용할 수 있게 됩니다.

기타 CS 개념

Progressive Web App(PWA 프로그레시브 웹 앱)

웹 기술을 사용하여 구축된 웹 애플리케이션의 한 형태입니다. PWA는 사용자에게 앱과 유사한 경험을 제공하며, 오프라인에서도 작동할 수 있고, 홈 화면에 설치되거나 백그라운드에서 푸시 알림을 받을 수 있는 등의 특징을 갖고 있습니다.

manifest.json

PWA를 개발하기 위해 사용되는 주요 개념 중 하나가 manifest.json입니다. manifest.json은 PWA의 기능과 외관에 대한 정보를 담고 있는 메타데이터 파일입니다.

manifest.json 파일은 웹 애플리케이션이 설치 가능한 PWA로 간주될 수 있도록 웹 브라우저에 알려줍니다. 이 파일은 웹 애플리케이션의 아이콘, 이름, 색상 테마, 시작 URL 등과 같은 정보를 포함합니다. manifest.json 파일은 웹 애플리케이션의 루트 디렉토리에 위치해야 합니다.

Manifest 파일은 PWA의 설치 가능성을 향상시키고 사용자 경험을 개선하는 데 도움이 됩니다. 예를 들어, 앱 아이콘을 추가하여 사용자의 홈 화면에 웹 앱을 바로 가기로 추가할 수 있습니다. 또한, 오프라인에서 작동할 수 있도록 캐시 전략을 설정하거나, 전체 화면 모드를 활성화하는 등의 기능을 구성할 수 있습니다. 이 파일을 사용하여 사용자 경험을 향상시키고, 앱과 유사한 기능을 제공하는 PWA를 구축할 수 있습니다.

백그라운드 동작

백그라운드 동작(Background Operation)은 애플리케이션이 활성화되지 않은 상태에서도 작업을 실행할 수 있는 기능을 의미합니다. 즉, 애플리케이션이 백그라운드에서 실행되거나 화면이 꺼진 상태에서도 작업이 계속되는 것을 말합니다. 이는 애플리케이션의 기능을 확장하고, 푸시 알림, 데이터 동기화, 위치 추적 등의 백그라운드 작업을 수행할 수 있도록 합니다.

백그라운드 동작은 일반적으로 다음과 같은 원리로 동작합니다:

1. 서비스 워커(Service Worker): 백그라운드 동작을 구현하기 위해 주로 서비스 워커라는 기술을 사용합니다. 서비스 워커는 브라우저와 웹 페이지 사이에서 동작하는 스크립트로, 웹 애플리케이션의 백그라운드 작업을 관리합니다. 서비스 워커는 브라우저가 백그라운드에서 실행되는 동안에도 네트워크 요청을 가로채고, 캐시를 사용하여 오프라인에서 작동하거나 다양한 기능을 수행할 수 있도록 합니다.

2. 이벤트 기반 접근: 백그라운드 동작은 주로 이벤트 기반 접근을 통해 작동합니다. 예를 들어, 푸시 알림을 받는 경우 서비스 워커는 서버로부터 푸시 알림을 받으면 이를 처리하기 위한 이벤트를 받습니다. 이벤트 핸들러는 해당 이벤트를 처리하고 사용자에게 알림을 표시하거나 기타 작업을 수행할 수 있습니다.

3. 백그라운드 스케줄링: 일부 플랫폼은 백그라운드 동작을 제어하기 위한 스케줄링 기능을 제공합니다. 이를 사용하면 특정 시간 간격이나 조건에 따라 애플리케이션의 백그라운드 작업을 실행할 수 있습니다. 예를 들어, 특정 시간에 알림을 표시하거나, 일정한 주기로 데이터를 동기화하는 작업을 수행할 수 있습니다.

백그라운드 동작의 예시로는 다음과 같은 기능이 포함될 수 있습니다:

1. 푸시 알림: 애플리케이션에서 중요한 정보나 업데이트를 받을 수 있는 푸시 알림 기능을 구현할 수 있습니다. 이를 통해 애플리케이션의 백그라운드에서 푸시 알림을 수신하고, 사용자에게 알림을 표시할 수 있습니다.

2. 데이터 동기화: 오프라인 상태에서도 애플리케이션의 데이터를 동기화할 수 있습니다. 백그라운드에서 데이터를 가져와 로컬 데이터베이스에 저장하거나 서버와 동기화할 수 있습니다.

3. 위치 추적: 애플리케이션에서 사용자의 위치를 추적하고, 특정 위치에 도달했을 때 작업을 실행할 수 있습니다. 이를 통해 위치 기반 서비스나 근접 알림 등을 구현할 수 있습니다.

4. 백그라운드 작업 처리: 큰 파일 업로드, 데이터 처리, 압축, 이미지 변환 등과 같은 오래 걸리는 작업을 백그라운드에서 처리할 수 있습니다. 이는 사용자 경험을 향상시키고, 애플리케이션의 반응성을 유지하는 데 도움을 줍니다.

이러한 예시들을 통해 백그라운드 동작은 애플리케이션이 활성화되지 않은 상태에서도 작업을 실행하고, 다양한 기능을 수행할 수 있는 기능을 제공합니다. 이를 통해 애플리케이션은 사용자에게 더 나은 경험을 제공하고, 보다 효율적으로 작동할 수 있습니다.

woff2

.woff2 확장자는 웹에서 사용되는 폰트 파일 형식 중 하나입니다. 이 파일 형식은 "Web Open Font Format 2"를 의미하며, 대부분의 웹 브라우저에서 지원됩니다. woff2은 폰트의 글리프 데이터를 압축하여 저장하는 포맷입니다. 이러한 압축은 파일 크기를 줄이고 네트워크 대역폭을 효율적으로 사용할 수 있도록 도와줍니다. 따라서 웹 개발자들은 .woff2 파일을 사용하여 웹 사이트에서 사용할 폰트를 최적화할 수 있습니다.

.woff2 파일은 .woff 파일과 비교하여 압축률이 높아 더 작은 파일 크기를 가지며, 폰트 파일의 다운로드 속도를 개선할 수 있습니다. 또한, 브라우저에서 효율적으로 디코딩되어 사용될 수 있도록 최적화되어 있습니다. 개발자는 .woff2 파일을 웹 사이트에 포함시키고, CSS 스타일시트에서 해당 폰트를 지정하여 사용할 수 있습니다. 이를 통해 웹 페이지의 텍스트를 원하는 폰트로 표시할 수 있습니다.

보일러플레이트(Boilerplate)

보일러플레이트(Boilerplate)는 개발자가 반복적으로 수행하는 일정한 작업을 미리 설정해놓은 초기 코드나 프로젝트 템플릿입니다. 즉, 보일러플레이트는 새로운 프로젝트를 시작할 때 필요한 구조, 설정, 기능 등을 미리 정의하여 개발자가 프로젝트를 빠르게 구축할 수 있도록 도와줍니다.

보일러플레이트는 다음과 같은 장점을 제공합니다:

• 효율적인 시작: 보일러플레이트는 프로젝트를 초기 설정하는 시간과 노력을 절약합니다. 개발자는 이미 정의된 구조와 설정을 기반으로 프로젝트를 시작할 수 있으며, 필요한 기능이나 패키지를 추가하기 위한 초기 작업을 줄일 수 있습니다.

• 일관성 있는 구조: 보일러플레이트는 일관성 있는 프로젝트 구조와 파일 패턴을 제공합니다. 이는 다수의 개발자가 협업하는 경우 통일된 작업 방식과 코드 구조를 유지할 수 있도록 도와줍니다.

• 모범 사례와 최적화: 보일러플레이트는 보다 효율적이고 최적화된 개발 방법을 포함할 수 있습니다. 최신 기술과 모범 사례를 적용하여 개발자가 좀 더 효율적이고 품질 높은 코드를 작성할 수 있도록 도와줍니다.

• 개발 생산성 향상: 보일러플레이트는 일상적인 개발 작업을 자동화하고, 공통 작업을 최소화하여 개발 생산성을 향상시킵니다. 이를 통해 개발자는 주요 로직에 집중할 수 있고, 프로젝트 초기 설정에 소비되는 시간을 줄일 수 있습니다.

메타데이터

메타데이터(Metadata)는 데이터에 대한 데이터로, 다른 데이터를 설명하고 분류하는 데 사용되는 정보입니다. 즉, 데이터의 특성, 속성, 구조, 관계 등을 나타내는 데이터라고 할 수 있습니다.

메타데이터는 데이터의 의미와 해석을 돕는 역할을 합니다. 데이터의 문맥을 이해하고 조직화하기 위해 필요한 정보를 제공하며, 데이터의 검색, 분류, 정렬, 필터링 등을 용이하게 합니다. 또한, 데이터의 보안, 권한, 소유자 등과 같은 관리 정보를 포함할 수도 있습니다.

메타데이터는 다양한 형태로 존재할 수 있습니다. 몇 가지 예시는 다음과 같습니다:

1. 파일 메타데이터: 파일의 이름, 크기, 생성 일자, 수정 일자, 파일 형식 등과 같은 정보를 포함합니다. 파일 메타데이터는 파일 시스템에서 사용되며, 파일을 식별하고 관리하는 데 도움을 줍니다.

2. 이미지 메타데이터: 디지털 이미지 파일의 경우, 이미지의 크기, 해상도, 촬영 일자, 카메라 제조사, 촬영 조건 등과 같은 정보를 포함할 수 있습니다. 이러한 메타데이터는 사진 앱이나 이미지 편집 소프트웨어에서 활용되며, 이미지를 분류하고 검색하는 데 사용됩니다.

3. 음악 메타데이터: 음악 파일의 경우, 노래 제목, 아티스트, 앨범, 장르, 릴리스 일자 등과 같은 정보를 포함할 수 있습니다. 이러한 메타데이터는 음악 플레이어나 음악 관련 애플리케이션에서 사용되어 음악을 구분하고 분류하는 데 활용됩니다.

4. 웹 페이지 메타데이터: 웹 페이지의 제목, 설명, 키워드, 작성자, 페이지의 언어 등과 같은 정보를 포함합니다. 이러한 메타데이터는 검색 엔진이 웹 페이지를 색인하고 검색 결과에서 표시하는 데 사용됩니다.

메타데이터는 데이터 자체와 함께 저장되거나 별도의 메타데이터 파일 또는 데이터베이스에 저장될 수 있습니다. 메타데이터는 데이터의 활용성을 높이고 데이터를 더 효과적으로 관리하고 활용할 수 있도록 도와줍니다.

JavaScript는 싱글 스레드 기반의 언어로, 한 번에 하나의 작업만 처리할 수 있습니다. 왜냐하면 코드를 읽고 실행하는 'stack'이 하나만 존재하기 때문이죠.

동기(Synchronous) vs 비동기(Asynchronous)

동기 작업은 순차적으로 실행되며, 이전 작업이 완료되어야 다음 작업이 실행됩니다. 한 작업이 실행 중인 동안 다른 작업들은 대기 상태에 있습니다. 작업의 결과를 기다리는 동안 프로그램이 블로킹되는 특징이 있습니다. 예를 들어, 함수 호출이 동기적으로 처리되면 해당 함수의 반환 값을 받을 때까지 다음 코드 실행이 차단됩니다.

비동기 작업은 작업이 백그라운드에서 실행되며, 작업이 완료되기를 기다리지 않고 다음 코드가 즉시 실행됩니다. 비동기 작업은 별도의 스레드나 백그라운드에서 처리되므로, 작업의 결과를 기다리는 동안 프로그램이 블로킹되지 않습니다. 비동기 작업은 일반적으로 콜백 함수, Promise, async/await와 같은 메커니즘을 사용하여 작업이 완료되면 결과를 처리하거나 다음 작업을 정의합니다.

비동기 작업은 주로 시간이 오래 걸리는 작업(예: 네트워크 요청, 파일 I/O, 데이터베이스 쿼리 등)이나 이벤트 기반 작업(예: 사용자 입력, 타이머, 애니메이션 등)에 사용됩니다. 비동기 작업을 사용하면 작업이 완료될 때까지 기다리지 않고 다른 작업을 수행할 수 있으므로, 애플리케이션의 반응성과 성능을 향상시킬 수 있습니다.

따라서 JavaScript는 기본적으로는 동기적으로 동작하는 언어이지만, 다양한 method(setTimeout, event listener, ajax 함수 등)를 사용해서 비동기적인 작업이 가능하도록 해줘 작업 속도와 효율성을 높이고 있습니다. 이러한 비동기 작업을 쉽고 간결하게 관리할 있도록 도와주는 기술에는 Promise와 Async/Await가 있습니다.

Promise

Promise는 비동기 작업을 처리하는 패턴 중 하나로 콜백 지옥(callback hell)을 피할 수 있도록 해주고, 작업들을 연결하고 조합하는 방법을 제공합니다. 비동기 작업이 성공적으로 완료되었는지 또는 실패했는지를 나타내는 상태와 결과값을 제공해주죠. Promise는 비동기 작업을 체인으로 연결하여 순차적으로 처리할 수 있고, 에러 처리도 간편하게 할 수 있습니다.

이 덕분에 코드 흐름을 파악하기 쉽고, 비동기 작업의 성능 향상이라는 장점은 그대로 유지한 채, 개발자가 동기적으로 비동기 작업의 움직임을 예측하고 처리할 수 있도록 도와줍니다.

Async/Await

async/await는 Promise를 더 쉽게 사용할 수 있도록 만든 JavaScript의 문법적인 개선입니다. async 함수는 비동기 작업을 수행하고 Promise를 반환하는 함수입니다. await 키워드는 async 함수 내에서 사용되며, 비동기 작업의 결과를 기다리는 역할을 합니다. await 키워드를 사용하면 코드를 동기적으로 작성할 수 있으며, 작업이 완료될 때까지 다음 코드의 실행을 일시 중지합니다. 이를 통해 비동기 작업을 동기적으로 표현하고, 비동기 코드의 가독성을 향상시킵니다. 에러 처리도 try-catch 문으로 간편하게 처리할 수 있습니다.

Promise와 async/await를 사용하면 비동기 작업의 흐름을 명확하게 표현할 수 있고, 작업들 간의 의존성과 순서를 조작하기 쉽습니다. 또한, 에러 처리도 보다 간단하고 효율적으로 할 수 있습니다. 이러한 기술들은 코드의 가독성과 유지보수성을 높이며, 비동기 작업을 보다 직관적이고 효율적으로 처리할 수 있도록 도와줍니다.

이벤트 루프(event loop)

그런데 자바스크립트는 단일 스레드 기반 언어로, 한번에 하나의 작업만 처리할 수 있다고 했습니다. 그런데 어떻게 여러 작업들이 동시에 진행될 수 있는걸까요? 이는 '이벤트 루프' 덕분에 가능합니다.

'setTimeout, XMLHttpRequset, 이벤트 처리'와 같은 비동기 작업이 발생하면, 이벤트 루프는 해당 작업을 백그라운드로 보내고 콜백 함수를 등록합니다. 이때 응답된 콜백 함수는 이벤트 큐로 이동됩니다. 호출 스택이 비어 있는 상태에서 이벤트 큐에 콜백 함수가 있는 경우, 이벤트 루프는 콜백 함수를 호출 스택으로 이동시켜 실행합니다.

즉, 비동기 작업은 queue에서 대기하다가 stack에 더 이상 진행하는 작업이 없을 때 스택으로 이동되어 실행되는 방식입니다. 이 덕분에 비동기적으로 작업을 처리할 수 있게 되었습니다.

이렇게 이벤트 루프를 이용하여 비동기 작업을 관리하고, Promise와 async/await를 활용하여 비동기 코드를 더욱 효과적으로 작성할 수 있습니다.

오늘의 cs

XMLHttpRequest 객체

XMLHttpRequest 객체는 클라이언트와 서버 간의 데이터를 주고받기 위한 JavaScript의 내장 객체입니다. XMLHttpRequest 객체를 사용하여 비동기적으로 서버에 HTTP 요청을 보내고 응답을 처리할 수 있습니다. XMLHttpRequest 객체는 브라우저의 웹 페이지 내에서 동적으로 데이터를 업데이트하고, AJAX(Asynchronous JavaScript and XML) 패턴을 구현하는 데 주로 사용됩니다. XMLHttpRequest 객체는 이벤트 핸들러를 사용하여 응답의 상태 변화를 모니터링하고 데이터를 처리할 수 있습니다.

AJAX(Asynchronous JavaScript and XML)

AJAX는 비동기적인 웹 애플리케이션 개발을 위한 패턴이며, XMLHttpRequest 객체를 사용하여 네트워크 통신을 수행하는 기술적인 접근 방식입니다. AJAX 패턴은 클라이언트와 서버 간에 데이터를 비동기적으로 주고받을 수 있도록 해주는 기술적인 개념을 의미합니다.

XMLHttpRequest 객체를 사용하여 데이터를 비동기적으로 요청하고 응답을 처리하는 것이 AJAX의 핵심 아이디어입니다. 이를 통해 웹 페이지의 일부분을 동적으로 업데이트하거나 서버와의 데이터 교환을 할 수 있습니다. AJAX 패턴은 사용자 경험을 향상시키고 웹 애플리케이션을 보다 반응형으로 만들기 위해 사용됩니다.

AJAX 자체는 개발자가 JavaScript와 XMLHttpRequest 객체를 사용하여 비동기 작업을 수행하는 패턴이며, AJAX를 더 편리하게 사용할 수 있는 기술에는 jQuery, Axios 라이브러리, JS 내장 API인 Fetch 메소드 등이 있습니다.

Fetch API

Fetch API는 네트워크 요청을 보내고 응답을 처리하기 위한 JavaScript의 인터페이스입니다. Fetch API는 HTTP 요청을 보내고 응답을 비동기적으로 처리할 수 있습니다. 주로 JSON, XML, HTML 등의 데이터를 가져오거나 전송하는 데 사용됩니다. Fetch API는 Promise 기반의 인터페이스를 제공하여 비동기 작업을 처리하고, Response 객체를 통해 응답 데이터를 다룰 수 있습니다.

클린 코드 조건

1. 응집도

하나의 목적을 가진 코드들은 서로 뭉쳐있어야, 코드 흐름과 목적을 파악하기 쉽습니다.

2. 단일책임

하나의 함수는 하나의 작업만을 수행해야 합니다. 그래야 차후에 새로운 기능이 추가되거나, 네이밍 단계에서 효율적으로 작업할 수 있습니다.

3. 추상화

함수의 세부구현 단계의 코드가 공통화되고, 재사용할 수 있어야 합니다. 따라서 핵심 기능과 비핵심 기능을 나눠서, 필요한 만큼만 로직을 노출시켜야 하죠.

핵심 데이터는 밖에서 받아오는 형식으로 모듈을 구현합니다. 그 외의 세부구현은 모듈 안에 담아서 숨깁니다. 개발자가 받아오는 핵심 데이터만 보고도 이 모듈이 어떤 목적을 가진 것은 파악할 수 있어야 합니다.

상황에 맞게 추상화 단계를 조절해서 만드는 것이 중요합니다.

선언형 프로그래밍 : 어떤 동작을 할지 선언을 해놓고 핵심 정보만 받을 수 있게 한 것 -> 응집도와 재사용성을 고려해야 하는 곳에서 사용 명령형 프로그래밍 : 어떤 동작을 할지 일일히 명령을 적어주는 것 -> 세부 구현 단계에서 사용

참조링크

토스ㅣSLASH 21 - 실무에서 바로 쓰는 Frontend Clean Code

rest 아키텍쳐 스타일에 부합하는 api를 의미합니다.

1. 자원에 대한 식별 변하지 않는 고유한 식별자 -> URI를 통해 자원을 식별

representational state transfer : 표현된 자원의 상태

JSON

JSON(JavaScript Object Notation)은 데이터를 저장하고 전송하기 위한 경량의 데이터 교환 형식입니다. JSON은 인간이 읽고 쓰기 쉽고 기계가 파싱하고 생성하기도 쉬운 형식으로 구성되어 있습니다. 이러한 특성으로 인해 JSON은 웹 및 네트워크 애플리케이션에서 데이터 교환의 표준 형식으로 널리 사용됩니다.

JSON 객체는 JavaScript의 내장 객체로 제공되며, 다음 장점들을 가지고 있습니다.

1. 편리한 데이터 변환: JSON 객체를 사용하면 JavaScript 객체와 JSON 문자열 간의 변환을 간편하게 수행할 수 있습니다. stringify 메소드를 사용하여 JavaScript 객체를 JSON 문자열로 변환하고, parse 메소드를 사용하여 JSON 문자열을 JavaScript 객체로 변환할 수 있습니다.

2. 네트워크 통신과 데이터 교환: 웹 애플리케이션에서는 서버와 클라이언트 간에 데이터를 교환해야 합니다. JSON은 데이터를 구조화하고 전송하기 위한 간단하고 일반적으로 사용되는 형식으로, JSON을 사용하면 서버와 클라이언트 간에 데이터를 효율적으로 교환할 수 있습니다.

3. 크로스 플랫폼 호환성: JSON은 플랫폼에 독립적인 형식이며, 다양한 프로그래밍 언어에서 지원됩니다. 따라서 서로 다른 플랫폼과 언어 간에 데이터를 교환할 때 JSON을 사용하면 호환성과 상호 운용성을 유지할 수 있습니다.

4. 보안: JSON은 자바스크립트 코드를 실행하지 않으며, 데이터만을 포함하고 있습니다. 이로 인해 JSON 데이터는 일반적으로 안전하게 처리될 수 있습니다.

stringify

JSON.stringify(value[, replacer[, space]])

• value: JSON 문자열로 변환할 JavaScript 객체입니다.
• replacer (선택사항): JSON 문자열에서 제외하거나 변환할 속성을 지정하는 함수 또는 배열입니다.
• space (선택사항): JSON 문자열을 읽기 쉽게 들여쓰기하기 위해 사용되는 공백 문자열입니다.

stringify 메소드는 JavaScript 객체를 JSON 문자열로 변환하는 데 사용됩니다. 컴퓨터가 인식하는 객체 형태로 존재하는 데이터를 실제 사용자가 시각적으로 볼 수 있게 JSON 문자열 형태로 변경해주는 역할을 합니다.

반대로 parse 메소드는 JSON 문자열을 JavaScript 객체로 변환해주는 역할을 합니다.

parse

JSON.parse(text[, reviver])

• text: JSON 문자열입니다.
• reviver (선택사항): 변환된 객체의 속성을 수정하는 함수입니다.

코드 예시에서 [,text] 처럼 대괄호로 묶인 매개변수는 선택 사항이라는 의미입니다.

참조링크

[10분 테코톡] 정의 REST API

1. 사용자 요청

• 사용자가 주소 창에 URL을 입력하거나, 링크를 클릭하거나, 폼을 제출하는 등의 동작을 통해 웹 페이지를 요청합니다.

2. DNS 조회

• 브라우저는 입력된 도메인 이름(URL)을 기반으로 DNS(Domain Name System) 서버에 해당 도메인 이름을 해석하여 IP 주소를 가져옵니다.

3. TCP 연결

• 브라우저는 서버의 IP 주소를 기반으로 TCP/IP 연결을 수립합니다. 이 단계에서는 TCP/IP의 핸드셰이크 프로토콜을 사용하여 클라이언트와 서버 간의 안정적인 연결을 설정합니다.

4. HTTP 요청

• TCP 연결이 수립되면, 브라우저는 HTTP(Hypertext Transfer Protocol) 요청 메시지를 서버로 보냅니다. 이 요청은 사용자가 요청한 페이지의 종류(HTML, CSS, JavaScript, 이미지 등)와 함께 서버에 전달됩니다.

5. 서버 응답

• 서버는 받은 HTTP 요청을 처리하고, 요청에 따른 응답을 생성합니다. 이 응답은 일반적으로 HTML, CSS, JavaScript 파일, 이미지 등의 리소스로 구성됩니다.

6. 응답 처리

• 브라우저는 받은 서버 응답을 처리합니다.
• HTML 파일을 파싱하여 DOM(Document Object Model) 트리를 구성합니다.
• CSS 파일을 파싱하여 스타일 규칙을 적용하고, 렌더 트리를 구성합니다.
• JavaScript 파일을 실행하여 동적인 기능을 구현합니다.

7. 페이지 렌더링

브라우저는 DOM 트리와 렌더 트리를 사용하여 페이지를 렌더링합니다. 이 과정에서 요소의 위치, 크기, 스타일 등을 계산하여 실제 화면에 표시합니다.

8. 이벤트 처리

사용자의 동작(클릭, 스크롤, 키 입력 등)을 감지하고, 이에 대한 이벤트를 처리합니다. 이벤트 핸들러가 등록된 요소에 따라 적절한 동작을 수행합니다.

9. 반응성 유지

브라우저는 사용자의 동작 및 상태 변화에 따라 페이지를 업데이트하고, 필요한 리소스를 다시 요청하여 반응성을 유지합니다. 이 과정에서 AJAX 요청, 페이지 이동, 다른 리소스 로드 등이 발생할 수 있습니다.

Elements

Decoupling(디커플링, 탈동조화) : 경제용어로는 한 나라의 경제가 보편적이고 세계적인 경기 흐름과 독립적으로 움직이는 현상을 의미합니다. 예를 들어 글로벌 경기침체 시기에 특정 국가는 계속 성장하고 있을 때, 디커플링 현상이라고 할 수 있습니다.

리액트에서는 기존의 UI/UX 구현에서 코드가 복잡하고, 디커플링에 비효율적인 현상을 개선하기 위해 엘리먼츠를 도입했습니다.

DOM Tree를 그리기 위한 정보들을 가지고 묘사해주는 역할입니다. 엘리먼츠는 정보만 가지고 있을 뿐, 실제 DOM을 그리고 삭제하는 동작에 대한 것은 리액트가 알아서 해주고 있습니다.

Components

사용자가 선언한 컴포넌트가 마치 html 태그인 것처럼 엘리먼트의 동일한 Hierarchy에서 사용되고 있습니다.

Hierarchy(하이어라키) : 조직이나 집단 내에서 계층적인 구조

이 말은 리액트에서 엘러먼트라는 개념을 도입했기 때문에, 컴포넌트 간의 완전한 디커플링이 가능하게 되었다는 의미가 됩니다. 서로의 존재만 알 뿐, 서로 전혀 영향을 주지 않는 것이죠.

오늘의 CS 지식

타입스크립트 제네릭

타입스크립트에서 제네릭은 코드의 재사용성과 타입 안정성을 높이기 위한 기능입니다. 제네릭을 사용하면 함수나 클래스를 일반화하여 다양한 타입에 대해 동작할 수 있도록 만들 수 있습니다. 이를테면, 동일한 코드를 사용하여 여러 종류의 데이터를 다룰 수 있습니다.

함수 및 클래스의 파라미터나 반환 데이터 타입 그리고 속성에서 자주 사용되는 타입이 있다면, 일반 타입 대신에 사용할 타입 변수를 지정합니다. 타입 변수는 주로 알파벳 대문자로 표현하며, 실제 사용될 때는 원래의 구체적인 타입으로 대체되는 것이죠.

제네릭의 장점은 다음과 같습니다.

1. 코드 재사용성

제네릭을 이용하면, 서로 다른 여러 타입에 대해 하나의 동일한 로직을 적용해서 사용가능합니다. 타입에 대한 규칙을 일반화시킨 것이기 때문에, 예를 들어 배열에서 반복문을 사용할 때, 배열 안에 어떤 타입의 데이터가 들어오든 하나의 로직으로 처리가 가능합니다.

2. 타입 안정성 및 추상화

타입스크립트를 유연하고 안정적으로 사용할 수 있게 도와주기 때문에, 한층 강력하고 효율적으로 타입스크립트의 능력을 이용하게 됩니다.

타입스크립트의 데이터 타입

number string boolean null undefined any

any 타입은 일반 자바스크립트를 사용하는 것과 다른 바가 없기 때문에, 거의 사용하면 안됩니다. 어떤 변수가 어떤 타입인지 정의되지 않았거나, 타입이 자주 바뀌는 경우에만 any 를 간혹 사용할 수 있습니다.

or 연산자를 써서 다양한 타입을 받게 할 수도 있습니다.

const a : number | string = "abc"

함수의 인자에 각각 데이터 타입을 전달할 수 있고, () 오른쪽에 함수의 리턴값의 데이터 타입을 정해줄 수도 있습니다.

const addNumber = (a:number, b:number):number => {
  return a+b
}

웹 브라우저는 자바스크립트만 이해할 수 있습니다. 타입스크립트는 사람이 이해하기 쉽도록 작성된 언어이기 때문에, 실제 웹 브라우저가 읽을 때는 타입스크립트 코드를 자바스크립트로 변환되어야 합니다. tsconfig.json 파일에 타입스크립트 -> 자바스크립트 변환에 대한 설정을 입력하게 됩니다.

객체에 대한 타입은 type와 interface로 정의할 수 있습니다. 또한 타입 내부의 또 다른 타입을 생성해서 재정의해줄 수 있습니다. 한번 만들어놓은 타입은 export import 해서 다른 파일에서도 재사용할 수 있습니다.

<> 은 제네릭입니다. 어떤 타입을 사용할지 정해져 있지 않고, 리액트 hooks와 같은 다른 사람이 만들어 놓은 함수를 호출하는 순간 타입을 정해주고 싶을 때 <>안에 타입을 전달해서 쓰는 제네릭을 사용하면 됩니다.

interface ApiResponse<T> {
  data: T;
  status: number;
  message: string;
}

async function fetchData<T>(url: string): Promise<T> {
  try {
    const response: AxiosResponse<ApiResponse<T>> = await axios.get(url);
    return response.data.data;
  } catch (error) {
    // 에러 처리 로직
    console.error('API 요청 실패:', error);
    throw error;
  }
}

async function getUserData(userId: number): Promise<User> {
  const url = `https://api.example.com/users/${userId}`;
  const userData: User = await fetchData<User>(url);
  return userData;
}

getUserData(123)
  .then(user => {
    console.log('사용자 정보:', user);
  })
  .catch(error => {
    console.error('사용자 정보 요청 실패:', error);
  });

interface OwnProps {
    info:Restaurant,
    changeAddress(address:Address):void
}

함수는 타입스크립트 데이터 타입으로 표시할 때, 함수명(매개변수: 데이터 타입): 리턴값 데이터 타입 과 같은 형식으로 데이터 타입을 작성하면 됩니다. 만약 해당 함수가 리턴를 해주지 않으면 void 라는 타입으로 지정해주면 됩니다.

기존에 미리 작성된 타입을 extends로 상속받아서 필요한 내용만 추가해서 사용할 수 있습니다. 또한 zipCode?:number 처럼 optional mark를 추가해서 있어도 되고 없어도 되는 상태로 관리할 수도 있습니다.

참조링크

React component, element, instance 끝내기 코딩에 진심인 사람을 위해 준비한 리액트 타입스크립트 | 실제 회사에서 쓰는 레벨 ver

영어 뜻 자체로 '분할, 단편, 구분' 등의 의미가 있습니다. 기하학에서는 서로 다른 두 점을 연결하는 가장 짧은 선인 선분입니다. CS에서는 구성 또는 분할의 개념에서 사용하는 기본 단위를 의미합니다. transport layer에서는 교환되는 데이터의 단위를 지칭합니다.

TCP 세그먼트

양 끝단 간 연결된 TCP 세션 내 서로 교환, 전달되는 데이터 단위입니다.

OSI 7 Layer

다른 시간과 다른 장소 간에 언제든지 자유롭게 데이터를 주고받고 통신할 수 있는 것은 네트워크로 연결된 수많은 장비들이 끊임없이 데이터를 전달해주고 있기 때문입니다. 하지만 이 과정은 우리 눈에 보이지 않죠. 이런 데이터 통신 과정을 체계적으로 정리하여 표준화시킨 것을 OSI 7 Layer 라고 합니다.

국제표준화기구(International Standard Organization, ISO)에서 1984년에 발표한 네트워크 표준 모델입니다. 네트워크 통신의 각 과정을 계층별로 구분해서 개념화한 모델이기 때문에, 구간별로 데이터의 움직임을 알기 쉽고 장치 간의 데이터 통신을 설명하는데 유용하게 사용됩니다. 덕분에 통신 과정에서 발생하는 문제의 원인을 추적할 수 있게 되었습니다.

14계층은 하위계층, 57계층은 상위계층으로 분류되고 상위 계층은 하위계층의 기능을 이어받아 사용합니다.

1. Physical Layer

시스템의 물리적 전기적 표현을 나타내는 계층이며, 케이블, 무선 주파수 링크, 핀, 전압 등의 물리적인 요건을 의미합니다.

2. Data Link Layer

데이터 링크 계층에서는 연결된 두 노드 사이에 데이터 전송을 가능하게 하고, 물리 계층에서 발생한 오류를 수정하기도 합니다.

3. Network Layer

네트워크의 핵심인 라우팅의 대부분이 네트워크 계층에서 작동하며, 여러 대의 라우터들을 바탕으로 데이터를 패킷 단위로 쪼개어 전송합니다. 대표적으로 IP(Internet Protocol)이 있습니다.

4. Transport Layer

보내고자 하는 데이터의 용량, 속도, 목적지를 처리해줍니다. 대표적으로 TCP(전송 제어 프로토콜)이 있습니다. TCP가 IP 위에 구축되기 때문에 TCP/IP로 가장 잘 알려져 있습니다.

5. Session Layer

실제 네트워크 연결이 일어나고, 하나의 세션을 열어서 프로세스 간의 통신을 제어하고 통신과정이 진행될 때 동기화를 유지하는 역할을 합니다.

6. Presentation Layer

응용 프로그램 형식을 네트워크 형식으로 변환하거나 반대로도 변환합니다. 응용 프로그램 또는 네트워크를 위해 데이터를 표현해주죠. 대표적으로 데이터를 안전하게 주고받기 위한, '암호화, 복호화' 과정이 여기서 이루어집니다.

7. Application Layer

사용자가 네트워크에 접근할 수 있는 인터페이스를 제공합니다. 크롬 같은 브라우저나 다양한 응용프로그램이 동작합니다. 대표적으로 HTTP, FTP 등이 있습니다.

통신계층별 데이터 단위

Layer 5~7 (Session, Presentation, Application Layer)

메시지, 데이터

Layer 4 (Transport Layer)

세그먼트

Layer 3 (Network Layer)

패킷, 데이터그램

Layer 2 (Data Link)

프레임

Layer 1 (Physical Layer)

비트

JavaScript

Immutable Type

'불변성'이란 뜻으로 말 그대로 변하지 않는 성질을 의미합니다. JavaScript에서 한번 생성된 후에는 변경될 수 없는 타입들은 다음과 같습니다. 원시 타입의 데이터들은 변수가 정의되어 처음 할당된 때, 완전히 새로운 값이 만들어져 재할당됩니다.

• Boolean
• String
• Number
• Null, undefined
• Symbol

Mutable Type

Immutable Type을 제외한 모든 변수들은 변할 수 있는 객체입니다. 새로운 값을 만들지 않고도 기존의 변수를 대응시키는 것만으로도 변경이 가능합니다.

const

let은 재선언 & 재할당이 가능하지만, const는 불가능합니다. 단, const가 참조값이 한번 할당되고 나면 변할 수 없다는 것을 의미할 뿐이지 참조값 내부에 있는 데이터들은 변경될 수 있습니다. 객체 내부의 재할당까지 const가 제어할 수 없습니다.

변수를 추적

코드 작성 시 불변성을 지켜야만, 사용하는데 데이터가 어디서 어떻게 변경되는지 추적하고 관리할 수 있습니다.

export default

export는 파일 내에서 만든 모듈을 외부로 내보내고자 할 때 사용합니다. 단, 하나의 모듈만 존재할 때는 export default를 사용해서 객체가 하나만 있다는 것을 명확히 보여줄 수 있습니다.

export된 모듈을 다른 파일에서 import해서 사용할 때, 중괄호 없이 모듈 이름 자체를 import하면 전체 모듈 자체를 가져올 수 있고, 중괄호를 써서 특정 모듈 내부의 특정한 객체만 import해서 사용할 수도 있습니다.

순수함수 & 함수형 프로그래밍

순수함수는 side effect를 만들지 않고, 동일한 인자를 주었을 때 항상 같은 값을 리턴하는 함수를 의미합니다. 예를 들어 함수에 전달한 인자 외에 전역 변수를 사용해서, 전역 변수가 변경됨에 따라 리턴값에 영향을 받게 되면 순수함수가 아닙니다. 반대로 함수 내에 전역 변수의 상태 또는 인자의 상태를 변경시키는 로직이 있어도 순수함수가 아닙니다.

그러면 순수함수를 유지하며 외부에서 들어오거나 외부에 있는 변수의 값을 변경하고 싶을 때는 직접 그 상태를 변경하지 말고, 새로운 변수를 선언하고 변수값을 할당하여 사용하면 됩니다.

side effect는 함수로 들어온 인자 상태를 함수가 직접 변경하거나, 함수의 외부의 상태를 변경하는 것을 의미합니다. 사이드 이펙트가 발생한다면, 코드의 동작을 예측하기 어렵고 예상치 못한 버그를 만날 수 있습니다. 따라서 항상 순수함수로 컴포넌트를 만드는 것이 중요합니다.

함수형 프로그래밍은 이런 사이드 이펙트를 없애고 순수 함수를 만들어 모듈화 수준을 높이기 위한 프로그래밍 패러다임입니다.

babel

transpiling

상위 버전의 코드로 작성된 javascript 코드를 하위 버전으로 변환해주는 기능입니다.

preset(기본값, 초기설정) superset(상위 집합) prefix(접두사)

yarn, npm, npx

3가지 모두 node 프로젝트에서 설치되어 사용하는 패키지들을 관리하는 툴입니다. npm은 node package manager로 입니다. npx는 execute npm package binaries로 npm에 속해 있는 npm 패키지 실행 도구입니다. npx는 패키지 실행 도구라는 것이 npm과 가장 큰 차이점으로, 해당 패키지를 실행만 되게 해주는 기능이기 때문에 가벼운 것이 특징입니다.

yarn은 npm, npx과는 결이 다른 패키지 관리자로서, 속도와 안정성 면에서는 npm과 비슷하지만 버전을 어디에서나 같게 만들어서 버그를 줄이고 보안성을 높였다는 것이 특징입니다.

nvm

nvm은 node version manager로 여러 버전의 node.js를 설치하고, 버전끼리 쉽게 전환할 수 있도록 도와주는 shell script입니다.

shell script

쉘 스크립트는 unix 커맨드 등을 나열하여 실행하는 것입니다. 언제 어떤 조건으로 어떤 명령을 실행시킬 것인지 등에 대해 .sh 파일에 작성할 수 있습니다.

bash, zsh

shell(쉘)은 리눅스에서 명령어와 프로그램을 실행할 때 사용하는 인터페이스입니다. 이는 커널(kernel)과 사용자 간의 다리 역할을 해주며, 사용자의 명령을 받아 해석하고 프로그램을 실행하는 역할을 합니다.

bash(Bourne Again Shell)는 현재 리눅스의 표준 쉘로, 우분투와 페도라에서도 bash를 사용합니다. sh 쉘(Bourne 쉘)을 기반으로 만들어졌습니다.

zsh도 sh 쉘에서 확장된 버전으로, bash 보다 더 많은 기능이 확장된 쉘입니다. zsh은 현재 MacOS의 기본 쉘이며, bash와 호환되지만, 맞춤법 교정 등의 더 많은 기능을 가지고 있기 때문에 가장 인기를 끄는 최신 쉘이라고 할 수 있습니다.

참조링크

네트워크 통신 계층: OSI 7 계층 바로 알기 자바스크립트에서 불변성(Immutability)이란 순수 함수란? (함수형 프로그래밍의 뿌리, 함수의 부수효과를 없앤다) Bash, Zsh 및 다른 Linux 쉘의 차이점은 무엇입니까?

브라우저 별로 최신 ECMAScript(JavaScript) 문법을 지원하지 않는 경우에 대응하기 위해, JavaScript 코드를 이전 버전에서 호환되는 버전으로 변환해주는 컴파일러입니다. 이 덕분에 브라우저 지원 또는 호환을 기다리지 않고 바로 새로운 표준 문법을 사용할 수 있습니다.

HTTP(Hypertext Transfer Protocol)

HTTP는 HTML 문서 같은 리소스를 가져올 수 있도록 해주는 프로토콜입니다.

프로토콜 : 컴퓨터 내부 또는 컴퓨터 간의 데이터 교환 방식을 정의하는 규칙 체계입니다. 특히 기기 간의 통신은 교환되는 데이터의 형식에 대한 상호 합의가 있어야 하기 때문에, 이런 형식을 정의하는 규칙의 집합을 프로토콜이라고 합니다.

HTTP는 웹에서 이루어지는 모든 데이터 교환의 기초이며, '클라이언트-서버' 형식을 가지고 있습니다. 서로 개별적인 메시지 교환에 의해 통신을 하며, 보통 웹 브라우저인 클라이언트가 서버에게 데이터를 요청하는 것을 request라고 하고 서버가 클라이언트에 응답하는 것을 response라고 합니다.

Hypertext : 하이퍼링크를 통해 사용자가 한 문서에서 다른 문서로 이동할 수 있도록 해주는 '초월적인' 글이라는 뜻입니다.

HTTP는 1990년대 초에 설계되어 진화를 거듭해온 확장 가능한 프로토콜입니다. OSI 7계층 중에서 Application 계층에서 사용되며, 직역하면 하이퍼텍스트를 전송하는 통신 규약입니다. 여기에 TCP와 UDP가 더해져서 클라이언트와 서버 간의 데이터를 주고 받을 수 있게 됩니다.

OSI 7계층

1. Physical Layer, 물리계층

컴퓨터는 0과 1로 된 데이터만을 사용할 수 있습니다. 그런데 한 기기에서 다른 기기로 데이터를 전송하려면, 그 데이터가 전선을 타고 이동하여 다른 기기로 이동해야 합니다. 그런데 이 전선에서는 아날로그 전자기파 형태로만 이동이 가능합니다. 따라서 물리계층은 다음과 같은 과정을 통해서, 데이터를 주고받을 수 있도록 해줍니다.

1. encoding : 보내고자 하는 0과 1의 나열을 아날로그 신호로 바꾸어서 전선을 흘려 보내고,
2. decoding : 전선을 통해 받은 아날로그 신호를 다시 0과 1의 나열로 해석합니다.

이렇게 물리적으로 연결된 2대의 컴퓨터가 0과 1의 나열을 주고받을 수 있도록 해주는 모듈(프로그래밍에서 쓰는 함수)을 물리계층이라고 합니다. 물리계층은 하드웨어적인 회로의 형태로 구현이 되어 있습니다.

오늘의 코딩지식

CLI

Command-Line Interface(Character User Interface) 명령줄 인터페이스로, 글자를 입력하여 컴퓨터에 명령을 내리는 방식입니다. 대표적인 예시로는 도스, 명령 프롬프트, bash 로 대표되는 유닉스 쉘 환경이 있습니다. macOS에서는 Terminal, windows에서는 Windows Terminal이 있습니다.

GUI 보다 자원을 적게 잡아 먹고 안정적이며 빠르다는 장점이 있습니다.

인트라넷

인트라넷 intranet은 인터넷 기술과 통신 규약을 이용하여 조직 내부의 업무를 통합하는 정보 시스템입니다. 즉, 조직 내부에서만 접속하고 사용 가능한 사내망입니다.

미국 국방부에서 군사 목적으로 처음 등장했으며, 4개층 구조의 초기형 TCP/IP 방식을 사용한 것이 최초입니다. 이후 프로토콜의 표준화로 비용이 비약적으로 낮아지기 시작하며, 내부에서 외부로 확장시켰고 이것이 현재의 인터넷이 되었습니다. 따라서 폐쇄형 인터넷을 인트라넷이라고 할 수 있습니다.

인트라넷 구축 방법

1. VPN(가상 사설망, Virtual Private Netword) 이용

VPN은 특정 단말을 가진 사람만이 데이터를 복호화 할 수 있는 단말을 통해 터널링하여 연결되도록 하는 기술입니다. 악의적인 데이터 유출을 막을 수 있고 다른 방법에 비해 저렴하다는 장점이 있습니다. 이미 구축되어 있는 인터넷 망을 사용하기 때문에, 전용선을 설치할 필요가 없고 외부 접근성이 좋습니다.

2. 특정 백본(backbone)을 이용

백본은 속칭 기간망으로 불리는 것으로, 소형 네트워크들을 묶어 대규모 파이프라인을 통해 극도로 높은 대역폭으로 다른 네트워크들의 집합과 연결되는 네트워크이자 대규모 패킷 통신망을 백본이라고 합니다.

보통의 백본은 Internet Backbone Network를 의미합니다. 이는 우리가 쓰는 보통 인터넷으로, '광 케이블 + WDM + 케리어 라우팅 시스템 + 백본 스위치 + 상호 접속기 + 워크그룹 스위치'로 구성됩니다.

특정 백본을 이용하여 인트라넷을 구축하는 방법은 대개 국가 기반 시설이나 주요 기점병원 등 사회 전반적으로 중요한 시설들에 대해 연결되는 특정한 백본을 사용합니다. 이 백본은 물리적으로 다른 ISP(Internet Service Provider, 인터넷 공급자)의 백본들과 분리되어 있어 ISP와 무관하게 네트워크의 이용이 가능합니다.

3. 전용선을 설치

전용 케이블로 사설망을 설치하는 방식은 가장 안정적이고 보안성이 높지만, 케이블 및 네트워크 장비 설치를 위한 토지나 전신주 사용료까지 내려면 비용이 매우 높습니다. 이 방식은 주로 IP 카메라나 인터폰 같은 보안 시스템 및 건물 자동 제어 같은 관내 통신 구축에 이용됩니다.

참조링크

Babel JavaScript 컴파일러 Babel 직접 적용하며 이해하기 HTTP 개요 [Network] HyperText는 무엇일까? (feat. HTTP,HTML) [10분 테코톡] 🔮 히히의 OSI 7 Layer CLI 인트라넷