노마드 코더에서 진행하는 챌린지 기록들
노개북 챌린지 4일차
오늘의 범위
- episode 16: 인터넷 익스플로러가 사라진 이유와 브라우저 엔진
- episode 17: 아, 쿠키가 먹는 게 아니라고요?
- episode 18: 프런트엔드, 백엔드?
- episode 19: 서버가 뭔지 아직도 모른다고?
- episode 20: 슈퍼 개발자만 할 수 있다, 풀스택?
- episode 21: 서버리스는 서버가 없다는 뜻?
Ep 16 인터넷 익스플로러가 사라진 이유와 브라우저 엔진
인터넷 익스플로러(Internet Explorer)는 CSS, Ajax 등 사람들이 좋아하는 기술을 빨리 지원하면서 큰 사랑을 받아왔다. 현 20대 이상이라면 아마 한 번쯤은 무조건 써봤을 법한데, 이토록 유명했던 인터넷 익스플로러가 이제는 사용할 수 없게 된 이유가 뭘까.
브라우저 엔진(=렌더링 엔진)
몰락한 이유를 설명하기에 앞서 브라우저 엔진에 대해 알아보자. 웹 브라우저를 개발할 때는 HTML 표준안을 정해야 하는데, 예를 들어 ’<h1> 태그로 감싼 텍스트는 20pt 크기로 굵게 작성해야 한다’라는 표준안이 있다면 그에 맞게 웹 브라우저에 보이게 해주어야 한다.
h1 태그로 작성한 텍스트
이러한 표준안에 맞게 개발한 웹 브라우저의 핵심 프로그램을 브라우저 엔진 또는 렌더링 엔진이라 부른다.
브라우저별로 다른 엔진을 사용하는데, 파이어폭스는 게코(gecko) 엔진, 사파리는 웹킷(webkit), 크롬은 블링크(blink)라는 엔진을 사용한다. 이 엔진이 최신 표준안과 최신 기술을 지원하면 최신 웹 브라우저, 즉, 엔진의 성능이 곧 웹 브라우저의 성능이라는 것이다.
익스플로러의 하락세
인터넷 익스플로러는 시장을 독점할 정도로 인기를 끌었지만 게을러진 나머지 2003년 이후로 급격한 하락세를 보이게 되었다. 그동안 사파리, 크롬과 같은 다른 브라우저들이 더 좋은 엔진을 갖추면서 결국 마이크로소프트는 인터넷 익스플로러 지원을 중단하게 된다.
대신 마이크로소프트는 마이크로소프트 엣지(Microsoft Edge)라는 새로운 브라우저를 발표하고 오늘날 이를 비롯한 크롬, 사파리 등 여러 브라우저로 세대교체가 되었다.
Ep 17 아, 쿠키가 먹는 게 아니라고요?
쿠키(cookie)는 어떤 웹 사이트에 방문했을 때 브라우저를 통해 컴퓨터에 보관하는 기록을 말한다. 쿠키는 왜 필요한걸까?
웹 사이트 주소의 HTTP는 주소에 대한 데이터를 사용자에게 보여주고 난 후에 서버와 연결을 끊어버린다는 특징이 있다. 그래서 서버 측에서 사용자가 그 주소를 방문했는지 기억을 할 수 없다.
그러나 로그인했던 사용자가 다시 주소를 방문하면 재로그인할 필요 없이 정보를 보여주는 것처럼 서버가 사용자를 기억해야 할 필요도 있다. 이럴 때 필요한 것이 바로 쿠키이다. 웹 사이트에 접속해 사용자가 로그인하면 서버에서 발행하는 영수증 같은 것이 쿠키이고 재방문할 때마다 서버 측에 쿠키를 전송하여 서버의 기억을 되살리는 것이다.
쿠키의 규칙
쿠키는 보안과 편의 등의 이유로 몇 가지 규칙을 따라야 하는데, 다음과 같다.
- 쿠키는 도메인 1개에만 한정한다.
- 쿠키는 자동으로 보낸다.
- 쿠키는 컴퓨터에 자동으로 저장된다.
도메인과 상관없는 쿠키
쿠키는 도메인 하나에만 한정되어 있다고 했다. 페이스북의 쿠키를 넷플릭스에 보낼 수 없듯이. 근데 페이스북은 사용자가 방문했던 사이트들을 어떻게 알고 있는 걸까.
✕✕ 사이트에 페이스북 좋아요 버튼과 같은 페이스북에 관련한 이벤트가 있다고 가정하자. A라는 사람이 본인 계정으로 페이스북 좋아요 버튼을 누르면 페이스북에서는 그 사용자에 대한 정보가 있으므로 ‘쿠키 123을 소유한 A가 ✕✕ 사이트에서 좋아요를 눌렀다.‘라는 식의 방문 사이트에 대한 정보도 함께 얻을 수 있는 것이다.
Ep 18 프런트엔드, 백엔드?
프런트엔드(Front-end)는 말 그대로 앞부분, 웹 사이트나 앱의 화면을 담당하고 백엔드(Back-end)는 데이터베이스나 라우터 등 웹, 앱의 뒷부분을 담당하는 것이다.
프런트엔드(Front-end)
프런트엔드의 장점은 작업한 것을 바로 확인할 수 있다는 점이다. 결과물이 즉각적으로 보이기 때문에 공부하거나 일을 하는 입장에서 성취감을 느끼기 비교적 쉽다.
단점은 기술의 변화 속도가 매우 빠르기 때문에 끊임없이 공부하고 발전해야 한다는 것이다. 공부를 꾸준히 했다는 생각이 들어도 기술 변화 속도에 못 미치면 또 새롭게 배워야 하고 그만큼 손을 놓으면 도태되기 쉽다. 이제 막 공부를 끝내가는데 새 버전이 나왔을 때의 기분을 서술하시오.
백엔드(Back-end)
백엔드의 큰 장점은 개발 환경이 프론트엔드에 비해 안정적이라는 것이다. 예를 들어, 2년 전에 배웠던 장고를 오늘 다시 공부한다고 했을 때 일부 기능만 공부하여 프로젝트에 업데이트하면 금방 최신 버전에 맞추기 쉽지만, 프런트엔드 영역의 webpack, React, GraphQL과 같은 기술을 2년 뒤에 공부한다고 한다면? 그냥 새롭게 하나 배우는 거랑 같다고 보면 된다. but 그만큼 고인물도 많다는..
또 다른 장점으로는 기술 선택지가 다양하다는 것이다. 웹 프론트라면 HTML, CSS, JS가 필수라 자바스크립트가 싫다고 해서 안 배울 수 없는 환경이지만 백엔드는 Java, Ruby, Django, Python, Flask 등 선택지가 많다.
단점은 눈에 안 보이는 부분을 담당하기 때문에 사용자와 거리가 멀다는 것이라 할 수 있겠다.
Ep 19 서버가 뭔지 아직도 모른다고?
서버(server)의 외부적인 모습은 간단히 말해 365일 매시간 인터넷에 연결된 모니터 없는 컴퓨터라고 할 수 있겠다. 저장소와 메모리 크기는 어마어마하다.
소프트웨어로서의 서버는 어떨까. 사용자가 요청한 정보에 해당하는 웹 페이지와 데이터를 보여주는 것이라 정의할 수 있다. 24시간 내내 항상 켜져 있으며 주소 입력을 기다리고 있다. 사용자가 어떠한 주소를 입력하면 네트워크에 연결된 서버가 기다리고 있던 그 주소를 받아 데이터를 꺼내서 보여주는 것이다.
🎯서버 정리
- 모니터가 없거나 한 개
- 항상 네트워크에 연결되어 24시간 내내 주소 입력 기다림
- 저장소와 메모리 크기 상당함
- 주소 입력되면 해당하는 데이터 보여줌
Ep 20 슈퍼 개발자만 할 수 있다, 풀스택?
풀스택(Full stack)이란 프런트엔드, 백엔드, 데브옵스(DevOps) 세 가지를 모두 포함하는 것을 뜻한다. 서버를 골라 설정하고, 소프트웨어를 설치하고, DB 설정, 보안까지 이 모든 것을 데브옵스라 하고 이런 일을 하는 사람을 데브옵스 개발자라 지칭한다.
데브옵스(DevOps)
소프트웨어의 개발(Development)과 운영(Operations)의 합성어로 개발자와 정보 기술 전문가 사이에 소통, 협업, 통합을 강조하는 개발 환경이나 문화를 말한다.
그래서 풀스택 개발자란, 프런트엔드와 백엔드는 기본적으로 할 줄 알면서 데브옵스까지 혼자서 다 하는 개발자라는 거다. 기획까지 할 줄 안다면 그냥 1인 스타트업 하나 설립해도 된다.
풀스택 개발자 주의!
어떤 회사에서는 두세 명이 할 수 있는 일을 풀스택 개발자 한 명만 고용하여 일을 시키는 경우도 있는데, 이런 회사는 조심해야 한다. 채용 공고에서 풀스택 개발자’만’ 뽑는다거나 팀원을 한 명 뽑는데 그게 풀스택 개발자라거나..
할 수 있는 것과 하는 것은 다르므로 몸 갈려가며 일하기 싫다면 신중하게 결정하자.
Ep 21 서버리스는 서버가 없다는 뜻?
서버리스는 실제로 서버가 없는 게 아니라 직접 관리하지 않는 서버를 의미한다. 예전에는 회사마다 서버를 구매해 수동으로 관리했었다. 그러나 사무실에 정전이 발생하거나 성능이 좋지 않은데 트래픽이 증가하는 등 문제점이 발생한다면 대처하기가 곤란하다는 단점이 있어 아마존의 EC2 같은 서버 관리 시스템이 등장하게 된다.
EC2는 아마존이 최신 서버를 정전이나 각종 사고 없이 안전하게 제공하고 관리해주는 시스템이다. 아마존 이외에도 여러 회사에서 이러한 서비스를 제공하고 있지만 하드웨어를 제공, 관리해줄 뿐이고 서버의 소프트웨어 관리는 직접 해야 한다.
그래서 서버리스가 뭔데?
서버를 위한 소프트웨어를 함수 단위로 작게 쪼개어 서비스에 올리게 되면 함수가 24시간 내내 깨어있는 게 아닌, 요청할 때만 함수를 실행시킨다. 그러면 서버 운영자 입장에서는 비용적인 측면에서도 이득이고 효율성이 높아지며 서비스를 이용하는 사람은 함수가 실행된 만큼만 돈을 내면 된다.
장점만 있는 건 아니다. 서버리스는 2가지 단점을 가지고 있다.
첫 번째는 서버리스 함수가 잠에서 깰 때 시간이 필요하다. 이를 콜드 스타트(cold start)라고 하는데, 요청한 함수를 실행시키기 위해선 평소 잠자고 있던 함수를 깨울 때 아주 조금의 시간이라도 소요한다는 것이다. 만약 밀리초 단위로 서비스의 질이 크게 갈리는 일에는 서버리스가 좋은 선택이 아닐 수 있다.
두 번째는 서버 제공자에게 지나친 의존을 한다는 것이다. 서버리스는 편리한 만큼 함수의 형태가 서비스에 딱 맞아떨어져 현재 사용하고 있는 서비스에서 다른 회사의 서비스로 쉽게 갈아타기가 힘들다.
그럼, 서버리스는 누가 사용하는 게 적합한가.
서버를 준비할 때는 설정 작업도 중요한데, 서버리스는 그런 일로부터 좀 더 자유롭기 때문에 사이드 프로젝트를 하거나 프로토타입을 빠르게 출시하고 싶은 기업에 적합하다. 서버 설정에 들이는 시간을 절약하고 코드에만 집중할 수 있으니까.
느낀 점
풀스택 개발자는 단순히 프런트와 백을 모두 할 줄 아는 것이라고 생각했었는데, 데브옵스까지 겸비한 사람이라는 것을 알게 되었다. 생각 이외로 더 쉽지 않은 거구나. 하지만 그렇기에 더더욱 해보고 싶은 생각이 들었다. 지금은 아니어도 조금씩 지식을 쌓아가면서 프런트도 백도 데브옵스도 기획도 디자인도 다 혼자서 해보고 싶다!
나도 처음 프런트엔드랑 백엔드 분야를 고민했을 때 책에 나온 장단점을 고려했었는데, 확실히 성향상 직관적으로 확인할 수 있고 심미성을 따지는 나로서는 흥미를 계속 이어가기엔 프런트가 더 적합하지 않을까 했었고 뭐 지금도 그렇다. (내가 디자이너면 예쁜 게 다가 아니라고 생각해야겠지만 코딩하면서 디자인까지 하려 하다 보면 사용성이고 나발이고 일단 예쁘게 만드는 것도 힘든 것 같다..)
서버리스에 대해서도 함수 단위로 실행한 만큼만 돈 낸다는 그런 정보만 알고 있었지, 단점에 대해서는 몰랐고 서버 설정 작업이 까다롭다는 것도 이 기회에 잘 알게 되어 다음 프로젝트에 시도해볼지 고민이 된다.
References
book - IT 5분 잡학사전