하루하루 발전하는 개발자와 블로그

[HTTP] 웹브라우저의 요청 흐름

더 멋진 세상을 꿈꾸는 개발자 — Sat, 25 Sep 2021 23:25:52 +0900

이전 글에서 프로토콜은 '규약', '규칙'을 의미한다고 이야기 했다.

그렇다면 인터넷 프로토콜 스택에는 4계층이 이루어져 있는데 이에 대해 알아보자.

먼저, 프롵토콜 스택이란 데이터 통신에 활용되는 프로토콜의 구조에 관한 개념으로 계층화된 구조로 모여있는 프로토콜의 집합이라 생각하면된다. 그래서 우리는 이를 (Protocol Family)라고 부르기도 한다.

이러한 프로토콜은 용도에 따라 4개의 계층으로 이루어져 있다.

인터넷 프로토콜 스택 4계층

어플리케이션 계층 : 프로세스간 통신을 위해 설계된 계층. 예시) HTTP, FTP, TLS/SSL
전송 계층(Transport Layer) : 송신자와 수신자를 연결하는 서비스에 대한 정보를 담는 계층. 예) TCP, UDP
인터넷 계층 : 패킷을 목적지로 전송하기 위한 정보를 계층 예) IP
네트워크 인터페이스 계층 : LAN 드라이버, LAN 장비 등 물리적 전송을 위한 계층

출처: 강의 '모든 개발자를 위한 HTTP 웹 기본지식' (김영한) 인프런

실제 인터넷을 이용해 서로 통신할 때 위와 같이 하나씩 덧씌어져 서버에 보내진다고 생각하면 된다.

자, 그러면 이제 출발지와 목적지를 담은 IP를 보완해주는 정보를 담는 TCP, UDP에 대해 알아보자.

1. TCP / IP 패킷 정보

여기서 패킷은 'package' + 'buket'의 합성어로 한 마디로 '수하물 덩어리'라고 생각하면 된다.

출처: 강의 '모든 개발자를 위한 HTTP 웹 기본지식' (김영한) 인프런

TCP는 Transmission Control Protocol의 약자로 전송 제어 프로토콜이라고 생각하면 된다. 즉, 전송을 어떻게 할지를 제어하는 규약이다. TCP를 이용하면 IP 만으로 해결이 되지 않았던 '순서', '전송' 제어 등이 가능하다.

TCP의 특징은 아래와 같다.

1. 연결 지향 - TCP 3 way handshake (가상연결)

IP는 그저 상대 컴퓨터가 켜져 있는지 없는지 상관없이 그냥 보내기만 한다면, TCP는 이러한 점을 보완하여 대상 컴퓨터와 내가 연결이 되는지를 확인하고 메시지를 보낸다. 즉, 가상연결이 먼저 이루어진 다음에 실제 '전송'을 하는 것이다. 이를 TCP 3 way handshake라 하는데 이는 실제로 그 연결 단계가 3번이나 이루어지기 때문이며 이에 대한 자세한 내용은 여기서 다루지는 않겠다.

2. 데이터 전달을 보증할 수 있다.

IP 같은 경우, 상대 컴퓨터가 꺼져 있어서 전송이 이루어지지 않아도 확인할 방법이 없었다면, TCP는 데이터를 보낸 후 상대 컴퓨터에서 확인 메시지를 받기 때문에 메시지가 누락될 경우, 이를 알 수 있다.

3. 패킷의 순서가 보장된다.

패킷의 순서가 잘못된 경우, 대상 컴퓨터는 TCP에 적힌 메시지와 비교하기 떄문에 순서가 잘못된 것을 인식하여 해당 번호부터 다시 보내라고 클라이언트에 요청하게 된다. 이것이 가능한 이유는 TCP에 전송제어 정보, 순서 정보들이 포함되어 있기 때문이다.

즉, TCP는 신뢰할 수 있는 프로토콜이며 IP를 보완하기에 현재, 대부분 TCP를 사용한다.

2. UDP의 특징

UDP란 User Datagram Protocol의 약자로 사용자 데이터그램 규약이라 생각하면 된다.

이는 사실 '하얀 도화지'와 같다. 기능이 거의 없기 때문이다.

데이터 전달 보증이나 순서 보장이 안된다는 점에서 IP와 거의 비슷하다.

그러나 PORT와 '체크섬' 정보와 기능이 추가된다는 점이 특징적이다.

그렇다면 IP에는 없지만 UDP와 TCP에 있는 port란 무엇인가?

자, 여러분이 평상시에 사용하는 노트북을 생각해보자. '인터넷 동작 방식'에 대한 발제를 하기 위해 노트북을 열었다.

그렇다면 당신은 과연 발제를 준비하기위한 keynote만 켤 것인가?

일단, 한국인의 필수 통신인 '카카오톡'부터 열고 시작하며, 음악도 들으면서 인터넷 검색도 하면서 동시에 가십거리 기사도 보고 있을 수 있다. 이렇듯 우리는 하나의 컴퓨터(하나의 IP)로 게임도 하고 음악도 듣고 있는 등 다양한 일을 한다. 그러면 내 컴퓨터 IP에 여러 패킷이 들어오게 되는데 각각 어떤 패킷인지 구분해 주는 정보가 바로 PORT이다.

더불어 이 메시지에 대해 제대로 맞는지 검증해주는 것이 '체크섬'인 것이다.

그러면 UDP의 특징은 그저 PORT와 체크섬 정도인 것 같은데 PORT 정보는 TCP도 가지고 있는데 왜 굳이 UDP가 필요할까?

TCP는 3 way handshake 도 해야하기 때문에 은근히 시간이 좀 걸릴 수 있다.

데이터 양이 많다면 속도도 좀 더 느려질 수 밖에 없다.

이럴때, 최적화 하고 싶을 때 TCP는 그대로 두고 UDP에 손을 대어 최적화를 하면 된다.

그래서 이 UDP 프로토콜이 최근에 각광을 받고 있다.

3. 웹브라우저의 요청 흐름

자, 그럼 다시 정리를 해보자.

우리가 구글 웹사이트에 접속하려 한다고 생각해보자.

그럼 그 과정은 아래와 같다.

1. 사용자가 url을 작성한다. (https://www.google.com:443)

2. www.google.com 주소의 DNS를 조회하여 IP주소를 얻는다. https의 port 443은 생략된다.

3. 웹브라우저에서 http 요청 메시지를 생성한다.

4. soket 라이브러리를 이용해 TCP/IP(3 way handshake 포함) 연결 후 대상 IP에 데이터(http 메시지)를 전달한다.

5. 이렇게 패킷이 인터넷 망에 딱 던져지면 수 많은 노드를 통해 대상 IP로 전달이 된다.

6. 대상 서버인 구글서버에 요청패킷이 도착하면 구글 서버는 TCP/IP를 까서 버리고 안에 있는 HTTP 메시지를 해석한다.

7. get요청이 담긴 이 메시지에 해당하는 정보를 찾은 후 '응답 메시지'를 만들어 아래와 같이 'HTTP 응답 메시지'를 클라이언트에 보낸다.

출처: 강의 '모든 개발자를 위한 HTTP 웹 기본지식' (김영한) 인프런

8. 클라이언트는 받은 응답 메시지의 내용을 화면에 보여준다.

출처 :

'모든 개발자를 위한 HTTP 웹 기본 지식' -김영한 (인프런강의)

(https://www.inflearn.com/course/http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC/dashboard)

[HTTP] 인터넷 통신에 대하여

더 멋진 세상을 꿈꾸는 개발자 — Sat, 25 Sep 2021 22:36:36 +0900

중학생때, 한창 영어 배우는 것에 호기심을 가지던 시절

영국인 중학생과 이메일 펜팔을 했던 것이 생각난다.

물론 내용은 "난 오늘 학교 다녀왔어. 그리고 저녁은 ~을 먹었어. 너는 무엇을 했니?" 뭐 이런 내용이었지만 ㅎㅎ

이런 사사로운 이야기 마저 굉장히 설레였던게 생각난다.

내가 지구 반대편에 있는 사람과 이렇게 일상적인 이야기를 주고 받을 수 있다니!!

저 멀리 있는 영국인 중학생과 나는 어떻게 이메일을 주고 받을 수 있었을까?

인터넷에서 컴퓨터 둘은 어떻게 통신을 하며 텍스트를 주고 받을 수 있는가?

1. 인터넷이 통신하는 방법

자, 일단 간단하게 먼저, 두 개의 컴퓨터가 통신한다고 생각해보자.

여러분이 생각하실 때에는 두 대의 컴퓨터가 서로 어떠한 정보를 주고 받기 위해서 무엇이 필요하다고 생각하는가?

1. 물리적으로 연결한다. (이더넷 케이블)

2. 무선으로 연결한다. (wifi, bluetooth)

그런데, 우리는 딱 한대의 컴퓨터만 연결해서 사용하지 않는다.

중학생 시절의 나는 영국에 사는 친구, 남아공에 사는 친구, 호주에 사는 친구와도 이메일을 주고 받을 수 있을 것이다.

어떻게 그게 가능할까?

네트워크는 단지 두 대의 컴퓨터로 제한되지 않기 때문이다.

우리가 원하는 만큼의 컴퓨터를 연결할 수 있다. 그러나 그럴 경우, 엄청나게 많은 케이블이 필요할 것이다.

이러한 문제를 해결하기 위해 네트워크의 각 컴퓨터는 라우터라고 하는 특수한 소형 컴퓨터에 연결된다.

출처 : mdn 인터넷은 어떻게 동작하는가?

자, 이런 그림이 되는 것이다. 우리는 이 라우터를 이용해 총 10대의 컴퓨터와 각 각 통신을 할 수 있게 되었다.

그렇다면 만약 수백, 수천, 수십억 대의 컴퓨터를 연결하면 어떻게 될까?

내가 아프리카 세네갈의 한 프랑스 언어교육원 홈페이지(https://ifs.sn/#/)에 들어가고 싶을 수도 있고,

미국의 아마존 사이트(https://www.amazon.com/)에 들어가 해외물품을 구입하고 싶을 수도 있다.

바로 라우터에 라우터를 연결하고- 이런식으로 우리는 무한히 확장 할 수 있다.

출처 : mdn 인터넷은 어떻게 동작하는가?

이러한 네트워크를 우리는 우리의 친구, 이웃에 연결할 수는 있어도 아주 먼 다른 지역에 케이블을 연결할 수는 없다.

이 문제를 해결하기 위해 네트워크는 이미 잘 갖추어진 전화 시설에 연결된다.

우리는 이 네트워크를 인터넷 서비스 제공업체(Internet Service Provider, ISP)에 연결한다.

즉, 우리의 메시지는 ISP 네트워크의 네트워크를 통해 우리가 도달하고자 하는 대상 네트워크로 전달이 된다!

이러한 지역 네트워크에 연결된 컴퓨터와 그 안에 속한 장비들을 통틀어 하나의 '노드'라고 칭한다.

자, 그럼 다시 돌아와서 중학생 시절의 내가 보냈던 이메일은 어떻게 영국에 있는 친구의 메일 계정이 저장된 서버 컴퓨터에 도달해 내 텍스트를 전달할 수 있었을까?

저 수많은 노드들 중에서 어떻게 특정 서버 컴퓨터를 찾아낼 수 있었을까?

2. IP주소

바로 IP 주소를 이용해서이다.

저 맥북, 아이패드 모두 각각 고유한 IP 주소를 가지고 있다.

인터넷이 연결된 모든 기기에는 각각 고유의 IP 주소가 부여된다.

각 기기가 서로 통신을 주고 받을 때에도 이 IP주소를 이용하는 것이다.

출처: 강의 '모든 개발자를 위한 HTTP 웹 기본지식' (김영한) 인프런

이런식으로 각 IP주소를 이용해 대상자를 찾아 전달을 해주는데,

컴퓨터가 서로 통신하기 위해서는 어떤 '규약, 규정'이 있어야 하지 않겠는가?

그것이 바로 'Protocol'이며 HTTP는 문서간에 링크를 통해 연결할 수 있는 html을 전송하는 규약, 규칙을 뜻하는

HyperText Transfer Protocol 이다.

출처 :

'모든 개발자를 위한 HTTP 웹 기본 지식' -김영한 (인프런강의)

(https://www.inflearn.com/course/http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC/dashboard)

인터넷은 어떻게 동작하는가? - mdn (https://developer.mozilla.org/ko/docs/Learn/Common_questions/How_does_the_Internet_work)

가상돔

더 멋진 세상을 꿈꾸는 개발자 — Sat, 18 Sep 2021 18:25:00 +0900

리액트는 렌더링 성능을 위해 가상 돔을 활용한다.

브라우저에서 돔을 변경하는 것은 비교적 오래 걸리는 작업이다. 따라서 빠른 렌더링을 위해서는 돔 변경을 최소화 해야한다.

그래서 리액트는 메모리에 가상 돔을 올려 놓고 이전과 이후의 가상 돔을 비교해서 변경된 부분만 실제 돔에 반영하는 전략을 채택했다.

리액트 요소 이해하기

JSX문법으로 작성된 코드는 리액트의 createElement 함수로 변경된다.

리액트가 UI를 표현하기 위해 사용하는 리액트 요소의 구조를 살펴보자.

const elementJSX = <a href="https://shinyeong.com">click here</a>
const element = React.createElement(
  'a',
  { href: 'https://shinyeong.com' },
  'click here',
);

첫줄의 elementJSX코드는 아래의 element 코드로 변경된다.

리액트 요소가 돔 요소로 만들어지는 과정

하나의 화면을 표현하기 위해 여러 개의 리액트 요소가 트리(tree)구조로 구성된다.

프로그램 화면은 여러 가지 이벤트를 통해서 다양한 모습으로 변화한다.

하나의 리액트 요소 트리는 시간에 따라 변화하는 화면의 한 순간을 나타낸다.

리액트에서 데이터 변경에 의한 화면 업데이트는 '렌더 단계(render phase)와 커밋단계(commit phase)를 거친다.

렌더 단계

실제 돔에 반영할 변경 사항을 파악하는 단계. 변경사항을 파악하기 위해 가상 돔을 이용한다.

커밋 단계

파악된 변경사항을 실제 돔에 반영하는 단계

가상돔

가상돔은 리액트 요소로부터 만들어진다.

리액트는 렌더링을 할 때마다 가상돔을 만들고 이전의 가상 돔과 비교한다.

이는 실제 돔의 변경 사항을 최소화하기 위한 과정이다.

리액트의 가상돔 과정은 다음과 같다.

변경사항이 생기면 ReactDOM.render()가 호출된다.

해당 과정은 위에서 언급했듯이 변경점을 찾는 과정(렌더 단계)과 변경점을 실제 UI에 적용하는 과정(커밋단계)으로 나뉜다.

[변경점을 찾는 작업] React는 Virtual DOM을 통하여 브라우저 DOM에 전달하기 전에 Reconciliation라는 비교 과정을 선행하기 때문에 UI에 대한 제어를 최소화 시킨다.
Render가 진행 될 때마다, 각 Element들은 key를 부여 받고, 해당 key를 통해 같은 Element라고 인식 되고 비교 된다. (물론, 계층이 달라지게 될 경우는 제외된다. 또, React diff 알고리즘은 필터 관련 기능에 취약하다고 한다. 많은 list를 필터하는 경우, 이것을 기억하고 해결책을 찾아보기로 기약하자.)
이런 비교 과정을 최소화 시키기 위해 shouldComponentUpdate(), PureComponent 를 활용한다.

코드로 살펴보는 리액트의 가상돔 과정

다음 코드는 할일의 우선순위를 상탯값으로 관리하는 코드다.

할일의 제목과 내용은 부모 컴포넌트가 속성 값으로 내려준다.

class Todo extends React.Component {
  state = {
    priority: 'high',
  };
  
  onClick = () => {
    const { priority } = this.state;
    this.setState({ priority: priority === 'high' ? 'low' : 'high' });
  };
  
  render() {
  	const { title, desc } = this.props;
    const { priority } = this.state;
    return (
      <div>
      	<Title title={title} />
        <p>{desc}</p>
        <p>{priority === 'high' ? '우선순위 높음' : '우선순위 낮음'}</p>
        <button onClick={this.onClick}>우선순위 변경</button>
      </div>
    );
  }
};

class Title extends React.PureComponent {
  render() {
  	const { title } = this.props;
    return <p style={{ color: 'blue' }}>{title}</p>
  }
};

ReactDOM.render(
  <Todo title="리액트 공부하기" desc="실전 리액트를 열심히 읽는다" />
  document.getElementById('root'),
);

버튼을 클릭하면 priority의 상탯값이 변화되고 화면을 다시 그린다.

PureCoponent로 만들어진 Title 컴포넌트는 상탯값이나 속성값이 변경될 때만 render 메서드를 호출한다.

ReactDOM.render 함수로 전달된 리액트 요소 트리의 구조는 다음과 같다.

const initialElementTree = {
  type: Todo, 
  props: {
    title: '리액트 공부하기',
    desc: '실전 리액트를 열심히 읽는다',
  },
  // ...
};

리액트가 initialElementTree를 이용해서 실제 돔을 만드는 과정을 따라가 보자.

먼저 Todo 컴포넌트의 렌더링 결과를 얻기 위해 Todo 컴포넌트의 렌더 함수를 호출한다.

// Todo 컴포넌트의 렌더 함수 호출 결과

const elementTree = {
  type: 'div',
  props: {
    children: [
      {
        type: Title,
        props: { title: '리액트 공부하기' },
       //...
      },
      {
        type: 'p',
        props: { children: '리액트 스터디 모임을 갖는다' },
        // ...
      },
      {
        type: 'button',
        props: {
          onClick: function() {
            /* Todo 컴포넌트의 onClick 함수 */
          },
          children: '우선순위 변경',
        },
        //...
       },
     ],
   },
   // ...
 }

트리의 루트는 div 태그로 변경된다.

아직 Title 컴포넌트가 존재하기 때문에 이 트리를 실제 돔으로 만들 수는 없다.

리액트 요소 트리가 실제 돔으로 만들어지기 위해서는 모든 리액트 요소의 type 속성 값이 문자열이어야 한다.

이는 type 속성값이 문자열이어야 HTML 태그로 변환할 수 있기 때문이다.

그러기 위해서는 모든 컴포넌트의 렌더 함수가 호출되어야 한다.

// Title 컴포넌트의 렌더 함수 호출 결과

const elementTree = {
  type: 'div',
  props: {
    children: [
      {
        type: 'p',
        props: {
          children: [
            {
              type: 'p',
              props: {
                style: { color: 'blue' }, 
                children: '리액트 공부하기',
              },
              //...
            },
            {
              type: 'p',
              props: { children: '리액트 스터디 모임을 갖는다' },
              // ...
            },
            {
              type: 'button',
              props: {
                onClick: function() {
                  /* Todo 컴포넌트의 onClick 함수 */
                },
                children: '우선순위 변경',
             },
             //...
           },
         ],
       },
       // ...
      }
    ]
  }
}

Title 컴포넌트로 표현됬던 리액트 요소가 p태그로 변경되었다.

이제 모든 리액트 요소의 type 속성 값이 문자열이므로 실제 돔을 만들 수 있다.

이와 같이 실제 돔을 만들 수 있는 리액트 요소 트리를 '가상 돔'이라고 한다.

가상돔 : 최종 리액트 요소 트리를 만들기 위해 치환되는 컴포넌트의 리액트 요소도 메모리에 유지된다. 메모리에 저장된 컴포넌트의 리액트 요소는 렌더 단계의 효율을 높이는데 사용된다. 가상 돔은 UI에서 변경된 부분을 빨리 찾기 위한 개념이므로 컴포넌트의 리액트 요소도 가상 돔의 일부라고 생각할 수 있다.

최초의 리액트 요소 트리로부터 가상 돔을 만들고 이전 가상 돔과 비교해서 실제 돔에 반영할 내용을 결정하는 단계를 위에서 말했듯이 '렌더단계'라 한다.

리액트는 화면을 업데이트할 때, 이전의 가상 돔과 현재의 가상 돔을 비교해서 변경된 부분만 실제 돔에 반영한다.

브라우저에서 실제 돔을 변경하는 작업은 다른 작업에 비해 시간이 오래 걸리기 때문에 꼭 필요한 부분만 변경하는 것이 중요하다.

이 랜더단계는 ReactDOM.render 함수와 setState 메서드에 의해 시작된다.

지금까지의 관계를 정리하자면 아래와 같다.

위 코드의 Todolist가 렌더단계와 커밋단계를 거쳐 가상돔을 이용해 렌더링 하는 방법을 이미지화함.

지금까지 리액트 요소를 이용해 렌더 단계를 설명했지만, 엄밀히 말하면 리액트 요소는 파이버(fiber)라는 구조체로 변환된다. 파이버는 리액트 버전 16부터 도입된 구조체 이름이다. 파이버도 리액트 요소와 같이 속성값을 가지며 모든 type 속성값이 문자열이 될 때까지 연산하다는 사실에는 변함이 없다.

참조자료 :

- 실전 리액트 프로그래밍

- https://ryublock.tistory.com/41

브라우저 동작원리

더 멋진 세상을 꿈꾸는 개발자 — Sat, 18 Sep 2021 18:24:35 +0900

크롬 브라우저를 사용한지 아마 어연 10여년이 되는 것 같다.

대학생 때, 그저 흔히 사용해왔던 ie 보다 디자인이 더 깔끔하고 직관적인것 같아 맘에 들어 사용하기 시작했다.

어연 10여년을 사용했음에도 개발자가 되기 전까지는 이 브라우저가 어떠한 원리로 동작하는지 전혀 몰랐다.

직접 배포작업들을 거치면서 웹 브라우저는 어떠한 방식으로 동작할지 살펴보게 되었다.

브라우저의 주요 기능

브라우저의 주요 기능은 사용자가 선택한 자원을 서버에 요청하고 브라우저에 표시하는 것이다.

자원은 보통 HTML 문서이지만 PDF나 이미지 또는 다른 형태일 수 있다.

자원의 주소는 URI에 의해 정해진다.

브라우저 기본 구조

사용자 인터페이스

요청한 페이지를 보여주는 창을 제외한 나머지 모든 부분을 의미한다. 예를 들면, 주소 표시줄이나 즐겨찾기 등을 말한다.

브라우저 엔진

사용자 인터페이스와 렌더링 엔진 사이의 동작을 제어한다. HTML 문서와 기타 자원의 웹 페이지를 사용자의 장치에 상호작용적인 시각 표현으로 변환시키는 것이다.

렌더링 엔진

요청한 콘텐츠를 표시한다. 예를들어, HTML을 요청하면 HTML과 CSS를 파싱하여 화면에 표시한다.

파이어폭스, 크롬, 사파리는 두 종류의 렌더링 엔진으로 제작되어 있다.

- 파이어폭스 : 게코엔진

- 사파리 : 웹킷

- 크롬 : 블링크

통신

HTTP 요청과 같은 네트워크 호출에 사용되며 이것은 플랫폼의 독립적인 인터페이스이고 각 플랫폼 하부에서 실행된다.

UI 백엔드

콤보 박스와 창 같은 기본적인 장치를 그린다. 플랫폼에서 명시하지 않은 일반적인 인터페이스로서, OS 사용자 인터페이스 체계를 사용한다.

자바스크립트 해석기

자바스크립트 코드를 해석하고 실행한다.

자료 저장소

이 부분은 자료를 저장하는 계층이다. 쿠키를 저장하는 것과 같이 모든 종류의 자원을 하드 디스크에 저장할 필요가 있다.

HTML5 명세에는 브라우저가 지원하는 '웹 데이터 베이스'가 정의되어 있다.

렌더링 엔진의 동작과정

1. HTML 마크업을 처리하여 DOM 트리를 생성한다.

2. CSS 마크업을 처리하여 CSSOM 트리를 생성한다.

3. DOM 트리와 CSSOM 트리를 결합하여 렌더링 트리를 생성한다.

4. 랜더링 트리 배치 : 각 노드에 대해 화면에서의 정확한 위치와 크기를 계산한다.

5. 렌더 트리 그리기 : UI 백엔드에서 렌더링 트리의 각 노드를 가로지르며 렌더링 한다.

이 과정들은 점진적으로 진행된다. 렌더링 엔진은 모든 HTML을 파싱할 때까지 기다리지 않고 배치와 그리기 과정을 시작한다.

네트워크로부터 나머지 내용이 전송되기를 기다리는 동시에 받은 내용의 일부를 먼저 화면에 표시한다.
이는 좀 더 나은 사용자 경험을 위한 것이다

웹킷 동작 과정

DOM의 Re-render

Element를 추가, 수정, 생성하면서 DOM이 수정되면, Render Tree생성, Layout 생성, 표시가 다시 이루어진다.

이는 리소스가 변경될 떄마다 전체 페이지를 갱신 시킨다고 생각하면 된다.

이 문제는 SPA(Single Page Application) 형식이 탄생하고, HTML 파일 규모가 커지고 나서 더 큰 문제로 이어졌다.

DOM을 사용하는 JS Version 에서는 하나의 컴포넌트가 바뀌는데 변하지 않는 요소까지 모두 바뀌는 모습을 볼 수 있다.

그 외, DOM API가 확장 되면서 문제가 많이 발생했다고 한다.

출처 : https://ryublock.tistory.com/41

https://d2.naver.com/helloworld/59361

자바스크립트란?

더 멋진 세상을 꿈꾸는 개발자 — Sun, 22 Aug 2021 22:32:36 +0900

자바스크립트란?

2-1. 자바스크립트의 탄생

1995년, 브라우저에서 동작하는 경량 프로그래밍 언어를 도입하며 탄생한 것이 Brendan Eich가 개발한 자바스크립트이다.

자바스크립트의 아버지, 브랜든 아이크

2-2. 자바스크립트의 표준화

1996년, 넷스케이프 커뮤니케이션즈는 컴퓨터 시스템의 표준을 관리하는 비영리 표준화 기구인 ECMA 인터내셔널에 자바스크립트의 표준화를 요청한다.

1997년, 표준화된 자바스크립트 초판 사양이 완성되었고 자바스크립트는 ECMAScript로 명명된다.

2015년, ECMAScript 6 (ES6)는 let/const 키워드, 화살표 함수, 클래스, 모듈 등과 같은 범용 프로그래밍 언어로서 갖춰야 할 기능들을 대거 도입하는 큰 변화가 있었다.

2-3. 자바스크립트 성장의 역사

2-3-1. Ajax

1999년, 자바스크립트를 이용해 서버와 브라우저가 비동기(asynchronous) 방식으로 데이터를 교환할 수 있는 통신 기능은 Ajax (Asynchronous JavaScript and XML)가 XMLHttpRequest라는 이름으로 등장했다.

Ajax의 등장으로 웹페이지에서 변경할 필요가 없는 부분은 다시 렌더링 하지 않고, 서버로부터 필요한 데이터만 전송받아 변경해야하는 부분만 한정적으로 렌더링 하는 것이 가능해졌다. 이로써 웹 브라우저에서도 빠른 성능과 부드러운 화면 전환이 가능해졌다.

2-3-2. JQuery

2006년, JQuery의 등장으로 다소 번거롭던 DOM( Document Object Model) 을 더욱 쉽게 제어할 수 있게 되었고 크로스 브라우징 이슈도 어느정도 해결되었다.

2-3-3. V8 자바스크립트 엔진

v8 자바스크립트 엔진의 등장으로 자바스크립트는 데스크톱 앱과 유사한 사용자 경험 UX를 제공할 수 있는 웹 어플리케이션 프로그래밍 언어로 정착하게 되었다.

V8 자바스크립트 엔진으로 촉발된 JS의 발전으로 과거 웹 서버에서 수행되던 로직들이 대거 클라이언트(브라우저)로 이동했고, 이는 웹 앱 개발에서 프론트엔드 영역이 주목받는 계기로 작용했다.

2-3-4. Node.js

2009년, 라이언 달이 발표한 Node.js는 구글 V8 자바스크립트 엔진으로 빌드된 자바스크립트 런타임환경이다.

Node.js는 브라우저의 자바스크립트 엔진에서만 동작하던 자바스크립트를 브라우저 이외의 환경에서도 동작할 수 있도록 자바스크립트 엔진을 브라우저에서 독립시킨 자바스크립트 실행환경이다.

자바스크립트의 동형성은 별도의 언어를 학습하기 위한 시간을 덜 수 있다는 장점이 있다.

Node.js는 비동기 I/O를 지원하며 단일 스레드 single thread 이벤트 루프 기반으로 동작함으로써 요청처리 성능이 좋다.

적합	부적합
데이터를 실시간으로 처리하기 위해 I/O가 빈번하게 발생하는 SPA에 적합하다.	CPU 사용률이 높은 애플리케이션에는 권장하지 않는다.

2-3-5. SPA 프레임워크

모던 웹 어플리케이션은 데스크톱 앱과 비교해도 손색없는 성능과 사용자 경험을 제공하는 것이 필수가 되었고, 더불어 개발 규모와 복잡도도 상승했다.
복잡해진 개발 과정을 수행하기 위해 많은 패턴과 라이브러리가 출현했지만 변경에 유연하면서 확장하기 쉬운 애플리케이션 아키텍처의 구축을 어렵게 했고, 필연적으로 프레임워크가 등장하게 되었다.

이러한 요구에 발맞추어 Component Based Development 방법론을 기반으로 하는 SPA single page application이 대중화되면서 Angular, React, Vue.js, Svelte 등 다양한 SPA 프레임워크, 라이브러리 들이 등장하였따.

간단히 둘러본 자바스크립트의 배경과 성장 과정이다.

브라우저에서 동작하는 경량 프로그래밍 언어로 시작해, 어플리케이션의 복잡도와 규모가 커지면서 그에 발맞추어 성능과 기능이 빠르게 성장하고 있는 자바스크립트. 나 또한 브라우저 화면에서 유일하게 동작하는 자바스크립트가 매력적이었고 나아가 백엔드 영역에서도 사용할 수 있다는 동형성이 매력도의 정점을 찍게 해주었다. 나중에 리액트에 좀 더 익숙해 질 때 쯤, 노드.js도 공부해 프론트와 백을 다루어 온전히 내가 만든 작은 프로젝트를 만들어 보고 싶다.
앞으로의 성장이 또한 기대되는 언어인 거 같다.

Loading, Error 컴포넌트 생성하기 - 1. Skeleton Loading

더 멋진 세상을 꿈꾸는 개발자 — Sun, 11 Jul 2021 19:27:10 +0900

동영상 서비스가 종료되어 해당 콘텐츠를 재생할 수 없습니다.

정말 오랜만에 블로깅을 한다. :)

오늘은 회사에서 로딩, 에러 컴포넌트 티켓을 담당하면서 처음에 생각한 것보다 굉장히 다양한 방법과 내용들이 포함되어 있는 것 같아 좀 더 공부할 겸 글로 남겨본다.

위의 영상과 같이 웹 사이트내에서 로딩이 이루어지는 장면을 본 적 있을 것이다.

지난 주 나에게 맡겨진 task 중 하나가 바로 사용자에게 "로딩, 에러"를 안내함으로 사용자 경험이 지루하거나 답답하지 않도록 하는 것이 었다. 잠시 디자이너의 부재로 인해, 디자인과 기획까지 구상해야했다.

"그래? 그냥, 데이터 로딩이 이루어질 동안 로딩 컴포넌트 보여주면 되겠지!" 이게 처음 나의 단순한 생각이었다.

그러나 로딩 화면을 보여주는데에는 다양한 디자인과 더불어 다양한 방식도 있었다.

먼저, 로딩 화면을 구현하면서 구글링을 통해 처음 접한 개념이 바로 "Skeleton Loaing"방식이었다.

오늘은 먼저 이 skeleton loading에 대해 알아보자.

Skeleton loading screen for the usual blog post

Skeleton Loading

Skeleton Screen은 어플리케이션의 본질적인 wireframe 이다. 이 wireframe은 어플리케이션이 최종적으로 로드될때까지 대신 구조를 잡아주는 역할을 한다. (위의 이미지와 같이 말이다)

이 것은 사용자들이 화면에 어떤 일이 일어나고 있는지 알게 해준다. 그래서 사용자는 어플리케이션이 부팅되고 있고, 컨텐츠가 로딩되고 있다는 것을 이해하게 된다.

skeleton은 "뼈대, 골격" 라는 의미라는 것은 모두 알 것이다. 말 그대로, 어플리케이션의 뼈대와 골격을 미리 보여주는 로딩 방식이다.

스켈레톤 화면은 페이지 레이아웃을 모방한 사용자 인터페이스 버전이다.

왜 Skeleton Loading Screen을 이용하는가?

빈 페이지를 표시하는 대신에 컨텐츠 뼈대를 표시하면 사용자는 어플리케이션의 응답 속도가 더 빠르다는 느낌을 받을 수 있다.

그래서 뺑글뺑글 돌아가는 로딩 스피너를 보여주는 대신에, 우리는 사용자가 어플리케이션을 시작하고 탐색할 때 진행 중인 상황을 확인할 수 있는 스켈레톤 화면을 표시하곤 한다.

사용방법

나는 css로 해당 부분의 골격만 로딩 구간에서 보여주는 방식으로 구현했었다.

그런게 검색해보니 react-loading-skeleton이라는 라이브러리가 있다는 것을 지금 글을 적으며 발견하였다ㅎㅎ

import React from "react";
import Skeleton from "react-loading-skeleton";

export default function BlogPost({ title, body, subTitle }) {
  return (
    <div>
      <h1>{title || <Skeleton />}</h1>
      <h3>{subTitle || <Skeleton />}</h3>

      <p>{body || <Skeleton count={6} />}</p>

      <button>
        {body ? "Read more" : <Skeleton height={25} width={100} />}
      </button>
    </div>
  );
}

자세한 사용방법은 아래 참조 글을 이용해 볼 수 있다.

다음에는 이 라이브러리를 이용하거나, 좀더 애니메이션을 더 추가한 skeleton방식으로 구현해보고 싶다 ;)

참조 : https://betterprogramming.pub/the-what-why-and-how-of-using-a-skeleton-loading-screen-e68809d7f702 (번역함)

신입 개발자에게 필요한 자세 - 1. 사람 된 마음과 자세 그리고 말

더 멋진 세상을 꿈꾸는 개발자 — Sat, 24 Apr 2021 11:25:35 +0900

신입 개발자가 되어보니, 나는 정말 많은 실수를 저지르고 있고 처음 보는 듯한 모르는 것들은 계속 생겨나 언덕을 오르고 또 오르게 되는 기분이다.

실력이 좀 부족한 한 부하직원은 늘 잦은 실수를 하는 중에도 감사와 고마움의 표현을 열심히, 진심을 다해 전했다. 똑같은 실수에 지적을 거듭해도 수정 되기까지 한참이 걸렸고 다른 부서원에 비해 업무능력도 떨어져 상사인 내 입장에서는 고민이었는데, 늘 말 끝에 "더 열심히 해서 선배의 짐을 들어드리겠습니다" "제 부족함을 감싸주셔서 감사합니다" "가르침에 누가 되지 않겠습니다" 하며 마음을 담은 인사를 전하곤 했다. 예쁜 말을 골라서 하니 심하게 야단을 칠 수도 없고, 하나라도 더 가르쳐 주고 싶은 마음이 들었다. 그런데 그렇게 느낀 사람이 나만은 아니었던 듯 하다. 임원진과의 식사 자리에서 우연히 그 후배 이야기가 나왔는데 최고참이 한마디 했다. "그 친구는 어디 가든 잘 살아남을 거야. 누군들 그런 말 듣고 내칠 수 있겠어"

-예쁘게 말을 하니 좋은 사람들이 왔다- 심희정 지음

남에게 도움을 요청해야할 경우도, 나의 실수를 인정해야 하는 경우도 많아진다.

그럴 때 신입의 마음과 태도 그 자세가 너무 중요하다는 것을 깨닫는다.

물론 처음에는 좌절되어 스스로 낮아지는 마음이 들 수 있다. 하지만, 거기서 끝내면 안된다.

신입은 누구나 그렇다. (물론 아닌 사람도 있겠지만 ^^)

배우려는 자세, 의지, 태도 그것이 너무나 중요하다.

[Kelly deli] Kelly가 전하는 목표 성취 방법

더 멋진 세상을 꿈꾸는 개발자 — Sat, 27 Mar 2021 16:55:29 +0900

1. 구체적인 목표를 세워라

- 나는 5년 뒤 300억을 현금으로 가지고 있는다.

2. 구체적인 목표를 간단한 문장으로 만들어 시각화하고 매일 아침 저녁 명상한다.

- 구체적인 목표를 이룬 나의 모습을 상상한다.

3. 구체적 목표를 이루기 위한 방법들을 찾는다.

4. 목표를 이루기 위한 도움을 얻기 위해 멘토를 찾아간다.

5. 항상 운동을 하여 뇌의 근육도 키운다.

- 일주일의 3번은 유산소운동을 하라.

- 어떻게 하면 그 시간을 내려고 노력하는가. 그게 중요하다.

6. "내가 할 수 있을까?, 될까 안될까?" 와 같은 생각은 쓸데없는 시간낭비이다.

- 목표를 이룬 나의 모습을 생각하며 계속 행동한다.

7. 부자들에게는 항상 '끈기'가 있다.

- 하루의 10분만 100일간 해보아라. (운동, 독서 등)

- 10분에서 "복리"가 생겨 3시간도 할 수 있게 되는 것이다.

8. 롤모델의 "습관"을 내 것으로 만든다.

- 처음에는 롤모델의 습관을 100일간 모방하다보면 나의 것으로 만들 수 있다.

20.09.07:: TIL (react-native webview)

더 멋진 세상을 꿈꾸는 개발자 — Mon, 7 Sep 2020 18:17:03 +0900

github.com/react-native-community/react-native-webview/blob/master/docs/Getting-Started.md

오늘의 한 일

react-native webview 활용

새롭게 배운 것

WebView란?!

-> 어플리케이션 화면상에 내가 띄우고 싶은 웹페이지를 어플리케이션 안에서 보여주는 프레임을 말한다. 즉, link로 연결하지 않고 바로 내 어플 안에서 페이지를 보여줄 수 있다.

react -natived에서 사용할 수 있는 React-native webview 라이브러리가 있다.
react-native webview -reborn 라이브러리도 있는데, 이 버전 라이브러리를 깔아서 사용했더니 계속해서 모듈 에러가 났다. 구글링해도 이와 같은 에러가 별로 없었다. 라이브러리 레파지토리를 보니 업데이트된지 2-3년은 된 것 같았다. 라이브러리를 설치하기 전에는 항상 최신까지 관리가 되고 있는 라이브러리인지 확인하고 설치를 해야겠다. 결국 힘들게 힘들게 uninstall로 다운받았던 라이브러리를 삭제하고 react-native webview 라이브러리를 설치해서 사용했다. :) 설치했더니 아주 잘 되었음!!

기업협업

기업협업을 하면서 맨 땅에 헤딩하며 스스로 하는 방법들을 많이 배우고 있는 것 같다.

내가 현재 인턴쉽을 하고 있는 회사에는 '네이티브' 사수가 없다.

그래서 홀로 찾고 검색하고 에러핸들링 하는 시간을 많이 쏟았다.

예전에는 대표님께서 '이거 해봐~~' 주시면

"나 모르는데.. 할 수 있을까? 어떻게 하지?" 하는 생각이 앞섰는데,

한달 정도 구글링하고, 에러핸들링 하면서 해보니,

검색하면 왠만한건 다 나오더라...

물론, native 생태계가 좁아서 고생은 좀 해야하는 것 같다.... ㅎㅎ

내가 찾은 라이브러리를 활용해서 생각했던 기능을 눈으로 직접 보이게 구현하니 너무 재밌다:)

20.08.29:: TIL

더 멋진 세상을 꿈꾸는 개발자 — Sat, 29 Aug 2020 16:56:53 +0900

오늘의 한 일

React Native xcode 여는 방법 (이걸 몰라서... 5시간을 날림...)
RN app testfligt 에 upload
touchbleOpacity -> hitSlop이용

새롭게 배운 것

HitSlop - 어플을 만들다 보면 터치하는 영역이 좀 더 확장되어야 터치가 이루어진다는 걸 알게 될 것이다. 딱 아이콘 에만 onPress 함수를 걸었더니 진짜 아이콘만 터치해야 함수가 작동했다. 아이콘을 넘어가는 다른 부분에는 다른 click 실행이 이루어졌다. 그래서 touchble opacity 태그를 활용해서 hitslop을 걸어주니 그 만큼 touchable 영역이 확장되었다.
React native cli 버전은 xcode 열 때 ".xcworkspace"로 xcode를 열어야 한다. 그래야 xcode가 어떤걸 여는지 안다. 그냥 작성한 폴더 자체를 xcode로 열려고 하면 'could not open file'이 뜬다. (내가 이 오류로 4-5시간을 날림...ㅋㅋㅋ)