'전체 글'에 해당되는 글 82건

오늘의 5분 개발지식 라디오! 안녕하세요~ 오늘은 최근에 카카오 사태로 크게 이슈가 되었던 개념인 DR, Disaster Recovery에 대해서 알아보려고 합니다. 구체적인 방법이나 대책보다는 뉴스기사나 매체에서 나오는 단어들 위주로 간단하게 전달해드리겠습니다

먼저 IDC입니다. IDC는 internet data center의 줄임말인데요, 우리가 흔히 말하는 데이터센터입니다. 이름때문에 오해하기 쉬운데 단순하게 데이터만을 저장하는 시설이 아니라 서버를 구동하기 위한 여러 통신장비들부터 안정적인 전기 공급을 위한 전자장비들이 들어가있습니다. 

우리가 흔히 사용하는 AWS, GCP가 이러한 수많은 IDC들이 합쳐져 추상화되어 일반 개발자들이 클라우드 서비스를 사용한다고 생각하시면 됩니다. 

IDC는 엄청나게 많은 서버들을 구동하기 위해 전문적으로 지어지는 건물이기때문에 쿨링을 위한 공조시설도 설계시부터 꼼꼼하게 반영됩니다. 또 정전 등의 이유로 전기 공급이 끊어져도 다른 발전소에서 전기를 끌어오거나 어느정도는 자체적으로 발전하도록 되어있습니다. 특정 구역에 문제가 생기더라도 다른 구역에는 영향을 미치지 않도록 분리되는 등 안정적인 서비스를 위해 다양한 처리들을 해둡니다.

이렇게 IDC에는 다양한 안전장치들을 해놓지만 이번 카카오사태처럼 화재가 난다거나 하는 등의 이유로 문제가 생겼을 때 이를 사용하는 서비스기업들에서 피해를 최소화하기 위해 빠르게 복구하는 계획들을 수립해놓는데요, 이를 DR, Disaster Recovery라고합니다. 직역하자면 재해 복구 정도 될 것 같네요.

DR과 관련된 개념들이 있는데요 2가지정도 알아보겠습니다.

첫번째 RPO입니다. Recovery Point Objective의 줄임말인데요, 문제가 생겼을 때 어느 시점의 데이터까지 복구를 할 것인가를 정하는 기준입니다. RPO로 정해진 기준까지는 복구를 해야되기때문에 이 시점까지는 백업을 해둡니다.

다음은 RTO입니다. Recovery time Objective의 줄임말인데요, 기업에서 아무리 늦어도 이 시간까지는 복구가 되어야만 하는 시간입니다. 이 시간이 넘어가면 사업에 너무 크거나 복구 불가능한 피해를 입힌다는 의미입니다.

자 그럼 마지막으로 재해에 대비한 실행책들을 알아보겠습니다. 총 4가지 단계로 알려드리겠습니다.

첫번째는 Mirror Site입니다. 이름에서 알 수 있듯이 실제 서비스와 완전히 동일한 서비스를 하나 더 운용하는 것입니다. 최근의 예시로 들자면 판교 IDC이외에 다른 지역에 있는 IDC에 하나 더 서버를 운영하는 것입니다. 트래픽도 거의 동일하게 분산시켜 운용합니다. 두 지역 모두 완벽하게 동기화되어있으며 실제로 사용자들의 트래픽이 유입되고 있는 상태이기때문에 Active-Active 상태라고도 합니다. 두 지역에 동일한 수준의 인프라를 구축하여야되기때문에 가장 비용이 크지만 가장 안전하고 문제가 발생해도 문제가 발생하지 않은 지역으로 트래픽을 돌리면 되기때문에 바로 복구가 가능합니다. 

두번째는 Hot Site입니다. 미러사이트와 동일하게 바로 사용이 가능한 수준의 인프라를 다른 데이터센터에 구축하지만 실제로 트래픽을 보내지는 않는 것입니다. 한쪽은 실제로 사용자가 사용하고 한쪽은 만약을 대비하여 대기중인 상태이기때문에 Active-Standby 상태라고도 합니다. 

재해 발생시 standby상태인 데이터센터를 Active로 돌리기만 하면 되기때문에 미러사이트 보다는 느려도 빠르게 복구가 가능하고 한쪽을 Active가 아닌 Standby로 두기때문에 비교적 비용도 조금 더 저렴합니다.

세번째는 Warm Site입니다. 바로 운영이 가능한 상태는 아니지만 서비스에 중요한 데이터들을 가지고 있는 상태라고 생각하시면됩니다. 데이터는 최신상태가 아니며 데이터 손실이 발생할 수 있으나 비용이 더 저렴합니다.

마지막은 Cold Site입니다. Warm Site보다도 더 적은 데이터만을 가지고 있거나 빈 서버가 있는 정도입니다. 거의 모든 세팅을 처음해야되는 상태로 복구까지 오랜시간이 걸리는 방법입니다.

자 이렇게 오늘은 카카오로 크게 이슈가되었던 재해 대비책인 DR에 대해서 알아보았습니다. 당연히 모든 기업들이 미러 사이트 방식으로 수십개를 유지하면 좋겠지만 자원은 유한하기때문에 그렇게 운영하기가 현실적으로 어렵습니다. 만약 이번 사건처럼 화재가 나지 않는다면 운영하지 않고 있는 쪽이 훨씬 더 저렴했겠지만 이렇게 문제가 생겼을때는 발생하는 피해대비 추가 데이터센터를 운용하고 있는 쪽이 더 저렴하다고도 볼 수 있는 것이죠. 제가 생각하기에는 비용과 예방효과의 시소게임인 것 같습니다.

끝!

오늘의 5분 개발지식 라디오! 안녕하세요~ 오늘은 브라우저에서 유저의 눈에 보이도록 렌더링을 하기까지의 과정을 간략하게 정리해보려고 합니다.

렌더링 파이프라인의 처음 시작은 HTML과 CSS를 파싱하는 작업부터 시작합니다.

개발자가 작성한 HTML과 CSS를 분석하여 각각의 태그들의 구조도인 Document Object Model, DOM을 만듭니다. 트리형태로 생성이 되기때문에 DOM트리라고도 합니다. 

CSS도 비슷한 방식으로 각각의 태그들이 가져야될 스타일을 트리형태로 생성하는데 이것을 CSS Object Model, CSSOM 트리라고 합니다.

이 과정에서 유의할점은 DOM트리 생성을 위해 HTML을 파싱할때, script 태그를 만나게되면 병렬로 진행하는 것이 아니라 잠시 파싱을 멈추고 script태그를 먼저 처리합니다. 

그 이유는 스크립트에 노드 구조를 변경할 수 있는 코드가 있을수도 있기때문인데요, 따라서 스크립트가 어느 위치에 삽입되느냐에 따라서 초기 로딩 속도가 차이날수도 있습니다.

이렇게 HTML과 CSS를 사용하여 DOM 트리와 CSSOM 트리를 생성하면 Recalculate style이라는 단계를 통해 DOM트리와 CSSOM트리를 합쳐 Render tree를 생성합니다. 여기서 특이한점은 실제로 화면에 보여지는 노드만을 가지고 있게되는데 css의 display none이 적용되면 눈에 보이지 않기때문에 render tree에서는 삭제됩니다.

자 다음은 Layout 단계인데요, 이전의 recalculate style의 결과물인 render tree에는 화면에 그려져야 될 모든 노드의 계층구조와 스타일을 포함하고 있습니다. Layout 단계에서는 해당 정보들을 사용하여 모든 노드들의 크기와 위치를 계산합니다. 

예를 들어 개발자가 display: flex를 적용하였다면 안에 포함된 노드들이 어떤 사이즈로 어떤 간격으로 배치될지 정확한 수치가 계산되는 단계로 보시면됩니다. 실제 노드들의 크기와 위치를 결정하는 단계로 브라우저 사이즈인 view port와 폰트 사이즈에 매우 종속적인 단계입니다. viewport와 폰트사이즈가 변경되면 위치와 사이즈가 모두 재계산되야되므로 layout 단계부터 재실행됩니다.

마지막은 Paint단계인데요, Layout 단계에서 계산된 정보를 가지고 그래픽카드에서 실제로 픽셀단위로 그려주는 역할을 합니다. 마치 초등학교에서 그리던 점묘화를 그리는 것 처럼 화면의 각 픽셀에 어떤 색이 들어갈지를 다 세팅하여 화면에 송출하기 전 단계입니다.

이렇게 모든 과정이 끝나면 화면에 어떻게 하나의 페이지가 그려져야될지 그래픽카드의 메모리에 저장되게 되고 사용자가 볼 수 있게됩니다. 각각의 단계가 이전 단계의 결과물을 사용하여 점진적으로 진행되기 때문에 파이프라인이라고 부릅니다. 전체의 과정이 화면에 렌더링하기 위한 과정이기때문에 렌더링 파이프라인이라고 부르는 것입니다.

지금까지의 설명은 브라우저의 가장 핵심적이고 기본적인 과정만을 담고 있기때문에 최신 브라우저들은 지금까지 설명드린 내용 이상으로 여러가지 추가적인 기법들과 단계들을 통하여 최적화를 하고 있습니다.

끝!

안녕하세요 기존의 영상들과 더불어 이제 면접에서 나오는 질문들이나 주제들을 모아서 면접지식 시리즈를 시작해보려고 합니다. 오늘은 프론트엔드 쪽으로 취준을 하시면 자주 나오는 질문인 쓰로틀링과 디바운스에 대해서 알아보려고 합니다.

쓰로틀링과 디바운스 모두 프론트엔드에서 성능 최적화를 위해서 사용됩니다. 특정 이벤트에 로직을 붙일 때 로직이 실행되는 횟수를 제한하는 것이 목적이지만 동작방식이 조금씩 차이가 있는데요,

—-

먼저 쓰로틀링입니다.

쓰로틀링은 한번 로직이 실행되고 나면이후 정해진 시간동안은 해당 로직의 실행을 막는 방식입니다. 

화면에서 보이다시피 처음 0초에 이벤트가 발생되었기때문에 로직이 실행됩니다. 현재 화면의 예시는 쓰로틀링을 3초로 걸었기때문에 1초와 2초에 발생한 이벤트에 대해서는 로직이 실행되지 않습니다. 그 후 3초가 지났기때문에 3초에 발생한 이벤트에 대해서는 다시 로직이 실행됩니다.

이런 방식으로 한번 로직이 실행되고 나면 일정 시간동안 로직의 재실행을 막는 것을 쓰로틀링이라고 합니다. 이벤트 발생 시에 수행되는 이벤트 핸들러는 로직 실행가능여부를 판단하여 로직을 실행하는데요.

첫번째 방식으로는 로직을 실행한 후 로직 실행가능여부를 false로 바꾸고 타이머를 세팅하여 정해진 시간이 지난후 true로 변경해주는 방식으로 작성이 가능하고 두번째로는 로직이 마지막으로 수행된 시간을 저장해두고 이벤트 핸들러에서 이벤트가 발생했을때의 시간을 저장된 마지막 로직 수행시간과 비교하여 실행여부를 판단할 수 있습니다.

—

다음은 디바운스입니다.

디바운스는 이벤트발생이 종료되고 정해진 시간이 지날동안 이벤트가 다시 발생하지 않으면 로직을 실행하는 방식입니다. 정해진 시간이 지나기 전에 다시 이벤트가 발생한다면 다시 처음부터 그 시간을 기다립니다. 

화면을 보시면 0초에 최초로 이벤트가 발생하여 3초까지 대기하다가 로직을 실행하려고 합니다. 하지만 1초에 다시 이벤트가 발생했기때문에 4초까지 기다리도록 타이머가 초기화되었고, 2초에도 동일하게 초기화되어 5초까지 기다리게됩니다. 그 후 3초와 4초에는 이벤트가 발생하지않았기때문에 5초에 예약되었던 로직이 실행됩니다.

디바운스는 이벤트 핸들러에서 로직 수행을 위한 타이머가 세팅되어 있는 지를 확인합니다. 세팅되어있지 않다면 정해진 시간 후에 로직이 수행하도록 타이머를 세팅합니다. 만약 이미 타이머가 세팅되어있다면 세팅된 타이머를 초기화하거나 제거한 후 새로 세팅합니다.

—

그럼 언제 어떤 방식을 사용해야할까요?

이건 전적으로 어떠한 문제를 어떠한 방식으로 해결할지에 달렸습니다. 본인의 서비스의 사용자들의 사용방법에 따라 다르기도하구요. 둘다 적용될 수 있는 문제를 예시를 들어 장단점을 설명드리겠습니다.

가장 대중적인 예시로 스마트폰에서 사용하는 지도 어플리케이션을 생각해보겠습니다. 이름이 프레임워크나 언어별로 다를 수 있지만 일반적으로 저희가 지도를 살펴보기 위해 터치로 쭉 끌어서 이동하는 경우 발생하는 이벤트를 drag라고 생각해보겠습니다.

이런 drag이벤트는 사용자가 드래그를 하는 동안 수십수백번 실행되는데요, 현재 화면의 지도에 보이는 영역에 있는 카페를 검색하기 위한 API가 호출된다고 생각하면 1초에 수십번 호출되는 것입니다. 

1분동안 사용된다고 하면 수천번 호출되는 것이고 천명의 사용자가 동시에 사용한다면 몇백만번 이상의 API호출이 일어나 서버에 과부하가 일어나게됩니다. 이렇게 서버 호출 뿐만이 아니라 복잡한 계산이 들어가는 경우에도 불필요하게 많이 반복됨으로 인해 부하가 일어나고 사용자의 화면에서 버벅임이 일어나기도 합니다.

그럼 쓰로틀링을 적용하면 어떻게 될까요? 이 경우 쓰로틀링을 적용하면 사용자가 드래그를 시작하고 3초마다 한번씩만 카페 검색 API를 호출합니다. 장점은 사용자가 드래그를 하는 동안 계속해서 현재 위치의 카페들을 볼 수 있습니다.

반대로 디바운스를 적용하면 사용자가 드래그를 멈출때까지 API가 호출되지 않고 드래그를 멈추면 최종 화면의 위치에 있는 카페들을 검색합니다. 쓰로틀링에 비해서 API호출 횟수가 적은점은 장점이지만 드래그를 하는 도중에는 화면에 카페가 보여지지 않습니다.

위의 예시에서 만약 본인의 팀이 사용자의 사용성을 더 우선시한다면 쓰로틀링을 적용할 것이고, 서버의 비용을 줄이고 싶다하면 디바운스를 적용할 수 있을 것 같은데요, 앞서 말씀드렸다시피 정답이 있다기보다는 현재의 상황에 따라 다를 것 같네요.

끝!

안녕하세요~ 오늘은 Facade pattern에 대해서 이야기해보려고 합니다.

> 어원

Facade pattern은 소프트웨어 디자인 패턴 중 하나인데요, 주로 객체지향 프로그래밍에서 많이 쓰입니다. ‘파사드’라는 단어를 사전에 검색해보면 “건물의 정면”이라는 뜻으로 나옵니다. 여기서 추측할 수 있듯이 어떠한 코드의 정면, 껍데기 역할을 하는 오브젝트를 두는 패턴을 뜻합니다.

> 설명

어떻게 생각하면 추가적인 레이어를 하나 더 두는 것인데요, 이렇게 하는 이유는 주로 복잡한 코드를 감추기 위해서입니다. 일종의 추상화와 비슷하다고 생각하시면 됩니다. 복잡한 내부로직을 그대로 노출시켜서 사용하게하면 복잡하니, 좀 더 쉽게 셀계된 인터페이스인 파사드 객체를 노출시키는 것입니다. 이 파사드 객체가 내부로직을 호출하게 되구요.

> 사용처

파사드 패턴은 주로 다음과 같은 경우에 사용됩니다.

• 첫번째, 간단한 인터페이스를 통해 복잡한 시스템을 접근하도록 하고 싶을때
• 두번째, 시스템이 너무 복잡할때

어떻게 보면 첫번째와 연결된 이유이죠?

• 세번째, 시스템을 사용하고 있는 외부와 결합도가 너무 높을때 의존성을 낮추기 위해서

> 장점

파사드 패턴을 적용하면 가장 큰 장점이 2가지가 있습니다.

• 첫번째, 외부에서 사용하기가 쉽습니다.

파사드 패턴을 적용하는 가장 근본적인 이유이지만, 추가적인 레이어를 파사드 객체를 통해 제공하여 외부에서 사용하기 쉽도록 인터페이스를 간소화하여 노출시키기 때분에 복잡한 기존의 내부로직을 사용하지 않습니다.

• 둘째, 의존성이 감소합니다

이전에는 외부에서 내부 로직을 직접 사용하기 때문에 내부 로직의 구조를 변경한다거나, 파라미터나 리턴값을 변경할 경우 직접적으로 영향을 받아 수정이 힘들거나 불가능한 경우가 종종 있습니다. 하지만 중간에 매개체 역할을 해주는 파사드 객체가 있기때문에 실제 내부 로직은 어떻게 변경이 되더라도 상관이 없어지므로 의존성이 감소합니다.

> 사용예시

마지막으로 위키피디아에 올라와있는 예시까지만 살펴보겠습니다.

c++로 작성된 코드인데요, 상단의 CPU, HardDrive, Memory쪽을 지금까지 이야기하던 복잡한 내부로직이라고 생각하시면됩니다. 만약 다음과 같은 코드를 라이브러리로 제공하여 외부에서 사용할 수 있도록 한다고 생각해보면, CPU, HardDrive, Memory 3개의 클래스를 제공해주고 사용처에서 알아서 적절히 섞어서 사용하도록 해도됩니다.

하지만 이 경우, 사용처에서 각각의 부품들이 제공하는 메소드들이 어떤 역할을 하는지 파악해야하고, 실행되는 순서또한 매우 중요합니다. 그렇기때문에 파사드객체인 ComputerFacade를 통해서 사용하도록 하는 것입니다. 사용처에서는 복잡하게 컴퓨터 내부 부품들의 메소드들을 알 필요없이 ComputerFacade객체의 start 메소드만 호출하면되는 것입니다.

정리하자면, 다음 예시와 같이 파사드 객체를 제공하면 사용처에서 복잡하게 내부 로직들을 알필요없이 사용하기 쉽도록 추상화된 파사드 객체를 사용하면 되기때문에 훨씬 사용하기 용이해집니다. 또, 이것을 제공하는 측에서는 사용자가 직접 내부로직을 사용하지 않기때문에 CPU, HardDrive, Memory와 같은 내부로직을 수정, 추가, 삭제하는 것이 훨씬 자유로워지는 의존성 감소 효과 또한 받을 수 있게됩니다. 

하지만 반대로 어찌되었건 추가적인 코드가 늘어나는 것이기 때문에 유지보수 측면에서 공수가 더 많이드는 것은 사실이므로 추상화하고자하는 시스템이 얼마나 복잡한지, 파사드 패턴을 통해서 얻게되는 이점이 추가적인 유지보수 비용보다 클지를 잘 따져보고 적용해야될 것 같습니다.

끝!

오늘의 5분 개발지식 라디오! 안녕하세요~ 오늘은 dependency injection, 의존성 주입에 대해서 이야기해보려고 합니다.

단어 자체가 직관적이지 않아서 저도 처음에 이해할때 많이 헷갈렸는데요, 의존성 주입이라는 용어에서부터 시작해보겠습니다.

일단 의존성이라는 단어부터 보면 좋을 것 같은데요, 의존성이란 말 그대로 하나의 코드가 다른 코드에 의존하는 상태를 뜻하는데요, 쉽게 말하자면 A라는 코드가 B라는 코드를 사용한다면, A는 B에 의존하고 있다, 혹은 의존성이 있다라고 말할 수 있습니다.

주입이라는 말은 말그대로 “넣어주다”라는 말인데요, 합쳐서 보면 의존성 주입이라는 용어는 의존성이 있는 코드, 객체를 넣어준다~라는 말입니다. 조금 더 실사용 예시로 풀어서 생각을 해보면, A라는 클래스가 B라는 클래스를 사용하고 있을때, 즉 의존하고 있을때, A 클래스에서 B클래스를 직접 생성해서 사용하는 것이 아니라 외부에서 B클래스의 인스턴스를 생성해서 주입해준다는 것입니다.

자 이렇게 의존성 주입이라는 용어를 이해했는데요, 의존성 주입이라는 단어를 사용할때에는 방금 설명한 가장 기초적인 개념외에도 추가적인 몇가지 개념들이 같이 포함되어있습니다.

첫번째로 Inversion of Control, 줄여서 IoC, 제어의 역전이라는 용어인데요, 의존성 주입이라는 오늘의 주제에 맞게 해석을 해보자면, 기존에는 의존성을 직접 모두 제어했다면, Inversion of Control이 발생하면 제어권이 역전되어있기때문에 반대로 직접 제어하지 않는다라고 생각하시면 됩니다. 그림으로 보시면 조금 더 이해가 빠르실텐데요,

조금 쉽게 이해가 되도록 대략적으로 그림으로 그려보았습니다.. 이전의 예시를 그대로 들고오자면 클래스A가 클래스B를 직접 참조하고 생성했던 것을 중간에 매개체를 하나 두고 그 매개체를 통해서 사용한다고 생각을 해보시면 기존의 화살표가 위에서 아래로 쭉 흐르던 것이 서로 마주보게 되어 제어를 나타내는 화살표의 방향이 역전된 것을 보실 수 있습니다.

이렇게 그림으로 보면 이해가 빠르긴 하지만 직접적으로 화살표 방향으로 생각하시지 마시고 개발자가 직접 의존성을 제어하던 것을 어떠한 매개체에게 제어권을 일임, 또는 뺏기게되어 더이상 제어의 주체가 개발자가 아니게되기 때문에 제어의 역전이 발생되었다고 보시면됩니다.

여기서 조금 전에 매개체라고 했던 것이 있는데요, 이 매개체를 IoC Container라고 합니다. 이 IoC Container는 개발자에게서 일임 받은 제어권을 사용하여 의존성을 관리하고, 인스턴스를 생성하여 주입해주고, 나중에는 메모리 해제하는 역할을 해줍니다. 이 IoC Container는 주로 프레임워크가 이 역할을 담당합니다. NestJS, Spring등과 같은 프레임워크들을 IoC Container를 포함하고 있습니다.

자 이제 정리를 해봅시다. 의존성 주입이라는 것은 IoC 컨테이너라는 매개체를 두고, 여기에 필요한 모든 모듈들을 등록해둡니다. 그리고 사용처에서 직접 생성하는 것이 아니라 필요할때에 IoC 컨테이더가 의존성이 있는 모듈을 주입해주는 방식입니다. 이 과정에서 의존하는 모듈의 생성과 해제, 주입 등 일련의 제어과정을 IoC 컨테이너 기능을 포함하는 프레임워크들에게 줌으로써 제어의 역전이 일어나게 됩니다.

이제 의존성 주입을 이해했으니 이 개념이 어떠한 장점들이 있는지를 이해해보겠습니다.

첫번째로 의존성이 줄어듭니다. 사용하는 클래스에서 직접 생성하는 것이 아니라 IoC container를 통해서 사용하기 때문에 그렇습니다. 의존성이 줄어든다는 것은 변화에 강하다는 말도 됩니다. 의존하고 있는 모듈의 라이프사이클을 전혀 신경쓰지 않기때문에 의존하고있는 모듈이 변경된다고 해서 이를 사용처에서 신경쓸필요가 없어집니다. 따라서 유지보수도 더 용이해집니다.

모듈의 생성과 삭제 등을 직접할 필요가 없기때문에 코드의 양도 감소합니다. 다이나믹하게 크게 차이나지는 않겠지만 작업속도도 빨라질 수 있겠죠.

또, 외부에서 의존성을 직접 주입받기때문에 테스트를 하기에도 용이합니다. 자신이 원하는 객체의 상태를 직접 세팅하여 주입할 수 있기때문에 내가 원하는 테스트 코드를 작성하기도 훨씬 더 수월합니다.

끝!

오늘의 5분 개발지식 라디오! 안녕하세요~ 오늘은 타입스크립트에 대해서 이야기해보려고 합니다.

> 생긴 이유 (장점)

일단 타입스크립트가 왜 생겼는지를 먼저 알아보려고 하는데요, 타입스크립트랑 이름이 비슷한 친구가 있죠? 네 맞습니다. 자바스크립트가 있는데요, 타입스크립트는 이 자바스크립트에서 파생된 언어입니다. 자바스크립트는 동적 타입 언어로 개발자들이 코딩을 할 때 각 변수들이 어떤 타입인지를 명시하지 않습니다. 때문에 개발을 하다보면 로직상의 오류로 개발자가 의도한 타입이 아닌 경우가 있는데요, 

예를 들어 a와 b를 더하는 함수를 작성했다고 했을 때, 위의 코드는 에러없이 동작하는 매우 정상적인 코드입니다만, 개발자의 의도는 이게 아니죠. 

이렇게 오류없이 돌아가지만 의도한 동작이 아닌 경우도 있고, 아예 코드가 동작하지 않아서 빈화면이 뜨거나 멈춰버리는 경우도 많이있습니다.

따라서 타입스크립트는 변수에 타입을 명시하도록해서  정적분석을 통해 런타임에서 발생할 수 있는 에러를 미리 해결할 수 있도록 합니다. 화면에서 보이는 것처럼 IDE에서 빨간줄로 힌트를 주는 경우도 있고, 빌드타임에 에러가 발생해서 미리 검출하고 미리 해결할 수 있습니다. 

만약 타입스크립트처럼 미리 잡아주지않으면 실제 프로덕션 환경에 배포되어 사용자들이 피해를 본 다음에 고칠 수 밖에 없겠죠. 물론 타입스크립트는 타입관련 에러만 잡아주기때문에 그 외의 로직상의 오류는 당연히 스스로 찾아야 합니다만, 제 경험상으로 타입 관련 오류만 잡아주더라도 전체 발생하는 오류의 반 정도는 사전에 예방이 되는 것 같습니다.

이 외에도 미리 타입을 정의하고 작업을 하기때문에 경우에 따라선 조금 더 계획적으로 접근할 수 있기도 합니다.

타입스크립트에서 타입 명시는 필수가 아니며 여러가지 옵션들을 통해 조절을 할 수 있고, 바닐라 자바스크립트로 작성하더라도 정상적으로 동작합니다. 즉, 타입스크립트는 자바스크립트의 superset, 확대집합으로서 타입 정의와 체킹만 추가한 것으로 보셔도 됩니다.

> 트랜스파일러

하지만 문제가 하나 있습니다. 우리가 사용하는 크롬, 웨일, 사파리 등의 브라우저는 “타입스크립트"라는 언어를 이해하지 못합니다. 타입스크립트엔진이 아닌 자바스크립트 엔진만을 내장하고 있기 때문이죠. 오직 자바스크립트밖에 이해하지 못하는데요, 그럼 우리는 어떻게 타입스크립트를 사용할 수 있을까요?

여기서 트랜스파일이라는 개념이 등장하는데요, 

어 트랜스파일? 컴파일은 들어봤는데?라고 생각하실 수 있습니다.

컴파일은 더 높은 수준으로 추상화된 언어(high level language)를 그보다 낮은 수준으로 추상화된 언어(low level language)로 변환하는 작업을 뜻합니다. c언어를 머신코드로 바꿔주는 작업이 바로 컴파일인것이죠.

트랜스파일은 비슷한 개념이지만 더 낮은 추상화레벨로 바꿔주는 것이 아닌 비슷한, 또는 동일한 레벨의 언어로 바꿔주는 작업입니다. 자바스크립트는 머신코드와 같은 더 낮은 레벨은 언어라고 볼 수는 없기 때문에 컴파일이 아닌 트랜스파일이라고 합니다.

정리해보자면, 브라우저는 타입스크립트를 이해할 수 없기때문에 자바스크립트로 변환을 해서 실제 브라우저에서 돌리게 됩니다.

> 단점

• 하나의 절차가 더 추가되니까 비효율적인 것 아닌가?

자 여기까지 잘 따라오셨으면 문득

아니, 그냥 자바스크립트로 작성하면바로 브라우저에서 실행할 수 있는데 괜히 타입스크립트로 작성하면 코드도 트랜스파일해야되고 괜히 빌드 타임만 늘어나고 비효율적인거 아니야?

라고 생각이 드실 수 있습니다.

합리적인 추론이긴 한데요, 현실은 생각보다 녹록치 않습니다. 프론트엔드용 코드는 개발사가 세팅해둔 서버에서 돌아가는 것이 아니라 각각의 사용자의 디바이스에서 돌아갑니다. 이 디바이스는 최신 안드로이드일 수도 있고, iOS일 수도 있으며, 윈도우 PC일 수도 있습니다. 또, 극단적으로 이제 더이상 업데이트가 지원되지 않는 갤럭시 S2일 수도 있습니다. 이 경우 최신 자바스크립트 문법이 동작하지 않을 수 있는데요, 이러한 기기들을 지원하기 위해 polyfill을 사용하여 구형 자바스크립트 엔진에서도 돌아갈 수 있도록 코드를 변환합니다.

즉, 프론트엔드의 코드는 거의 항상 개발작업을 마치면 배포 전에 pollyfill 작업을 통해 코드를 변환하는 작업을 거치게 됩니다. 이 과정에서 최적화를 위해서 코드양을 줄이는 minification 등도 거치게되죠. 따라서 이 과정들과 함께 타입스크립트를 자바스크립트로 변환하면 되니까 크게 작업성에 문제가 되지 않는 것이죠.

정리하자면, 이왕 코드 작업 마치고 브라우저 호환성과 최적화를 위해서 변환작업을 거칠꺼면, 개발할 때 안정성과 편리함을 위해서 타입스크립트를 사용하고 같이 변환해버리자~ 가 된 것입니다.

• 코드양이 늘어나는 것 아닌가?

정적 타입을 사용하는 언어를 처음 접하게 되면 가장 먼저 들 수 있는 생각이 비즈니스 로직만 작성하면 되는데 쓸데없이 변수 타입까지 선언해줘야되서 코딩하는 것이 늘어나는 거 아니야?라고 생각하시는 분들이 많습니다.

이건 사람마다 조금씩 생각이 다를 수는 있는데요, 제 개인적인 생각으로는 개발자는 사람이기 때문에 필연적으로 실수를 하게 되어있는데요, 바닐라 자바스크립트를 사용할 때는 이 버그를 실제 페이지를 접근해서 오류가 발생해 빈화면이 떠야지만 그제서야 검출할 수 있었습니다. 타입스크립트를 사용하면 visual studio code와 같은 IDE에서 개발 중에 바로 에러를 표시해주기 때문에 오히려 제 기준에서는 생산성이 더 높아졌습니다.

또, 타입스크립트에서는 객체가 어떤 속성을 가지고 있는지 미리 선언해야되기때문에 IDE가 어떤 속성이 있는 지를 미리 알 수 있고, 따라서 속성을 타이핑할때 자동완성이되어 끝까지 치지않아도 되기때문에 작업속도가 더 빨라지는 것 같기도 합니다.

(^ 31)

> 최신 이슈

하지만 최근에는 타입스크립트를 자바스크립트로 변환하는 과정이 작업성을 저해한다는 의견도 조금씩 나오고 있습니다. 이는 최신 브라우저들의 발전때문인데요, 예전과 달리 브라우저들이 스스로 업데이트를 하면서 항상 최신 상태를 유지하는 기능을 많이 가지고 있는데요, 이런 브라우저들을 evergreen 브라우저라고 합니다.

이런 브라우저들이 많아지게되면 더이상 개발자가 브라우저 호환성을 신경쓸필요가 없어지게되고, 그럼 pollyfill을 사용하여 자바스크립트 변환이 필요없어지는 때가 온다는 것이죠. 그럼 트랜스파일하는 과정은 온전히 타입스크립트를 자바스크립트로 변환하기 위한 것이 되고, 이는 불필요한 작업성 저하라는 의견이 나오고 있습니다.

하지만 타겟 사용자가 구형 디바이스를 사용할 가능성이 높거나 이런 사용자도 다수 포함되어있는 오래된 서비스나 대기업에서 제공하는 서비스들은 어쩔수없이 꽤 오랜 시간 동안 브라우저 호환성을 신경쓸 수 밖에없기도 하고 everygreen 브라우저가 대세가 되기 위해서는 아직은 시간이 더 걸릴 것으로 보여 제 개인적으로는 타입스크립트가 한동안은 기본으로 쓰이는 언어가 되지 않을까 싶습니다

네트워크:

mangkyu.tistory.com/91

프론트엔드:

- sunnykim91.tistory.com/121

- velog.io/@honeysuckle/%EC%8B%A0%EC%9E%85-%ED%94%84%EB%A1%A0%ED%8A%B8%EC%97%94%EB%93%9C-%EB%A9%B4%EC%A0%91-%EC%A7%88%EB%AC%B8-%EB%AA%A8%EC%9D%8C

- 

백엔드:

데이터베이스:

4줄요약:

1. WebRTC는 peer-to-peer communication을 하기 위해 signaling이라는 process를 거쳐야한다.
2. Peer-to-Peer 연결을 하기 위해 ICE Framework를 사용하며 UDP > TCP > STUN > TURN(relay)순으로 시도한다.
3. 연결이 되었으면 offer-and-answer mechanism으로 서로의 media capability를 교환한다. 자신의 RTCPeerConnection 인스턴스에 상대방의 자신과 상대방의 정보를 저장한다.
4. RTCPeerConnection의 등록된 정보로 서로 연결하고 communication이 이루어진다.

Signaling: process of coordination communication. In order for a WebRTC app to set up a call, its client need to exchange the following information:

• Metadata (codec, bandwidth, etc)
• Network data (IP addr, port, etc)
• etc

To avoid redundancy and to maximize compatibility with established technologies, signaling methods and protocols are not specified by WebRTC standards. You can use socket to build signaling services.

RTCPeerConnection: API used by WebRTC apps to create connection between peers and communicate audio and video. RTCPeerConnection has two tasks:

• Obtain local media conditions (resolutions, codec capabilities) using offer-and-answer mechanism.
• Obtain potential network address for the app's host, known as candidates.

Offer-and-answer mechanism (A is calling B):

1. A creates RTCPeerConnection object
2. A creates an offer with createOffer()
3. A calls setLocalDescription() to send A's setup to B
4. A stringifies offer and sends it to B using signaling mechanism
5. B calls setRemoteDescription() so that B's RTCPeerConnections knows about A's setup
6. B calls createAnswer()
7. B calls setLocalDescription() to send B's setup to A
8. B stringifies offer and sends it to A using signaling mechanism
9. A calls setRemoteDescription() so that A's RTCPeerConnection knows about B's setup

Very similar to handshake procedure

ICE framework: framework used to find network interfaces and ports (candidates)

In reality most devices live behind one or more layers of NAT, some have antivirus SW that blocks certain ports and protocols. You can use ICE framework to overcome complexities. To enable this to happen, your app must pass ICE server URLs to RTCPeerConnection. ICE tries to find the best path to connect peers.

ICE tries to find the best path to connect peers. It tries all possibilities in parallel and chooses the most efficient option that works.

1. ICE first tries to make a connection using the host address obtained from a device's OS and network card.(UDP > TCP)
2. If that fails(which it will for devices behind NATs), ICE obtains an external address using a STUN server.
3. If that fails, traffic is routed through a TURN relay server.
   Every TURN server supports STUN. A TURN server is a STUN server with additional built-in relaying functionality.

STUN: NATs provides an IP address for use within a private local network to a device but this can't be used externally. You need a public address. WebRTC uses STUN get around this problem. STUN server live on the public internet and check the IP:port address of an incoming request (from an app running behind a NAT) and send that address back as a response. In other words, the app uses a STUN server to discover its IP:port from a public perspective.

TURN: RTCPeerConnection tries to set up direct communication using UDP. if that fails, it tries TCP. if that fails, TURN servers are used to relay data. TURN is used to relay audio, video, and data streaming between peers, not signlaing data. TURN servers have public addresses, so they can be contacted by peers even if the peers are behind firewalls or proxies.

Reference:
www.html5rocks.com/en/tutorials/webrtc/basics/
www.html5rocks.com/en/tutorials/webrtc/infrastructure/
www.html5rocks.com/en/tutorials/webrtc/datachannels/