#5. IT 5분 잡학사전 - 백엔드가 뭐죠

• Day.5
• 오늘 읽은 범위: 챕터 16 ~ 챕터 21
• 오늘의 TIL 3줄 요약

1.  프론트엔드/백엔드 이용자쪽 끝단과 서버쪽 끝단
2.  서버는 server. 기다리고 있다가 주문 들어오면 "여기 주문하신 xx입니다"
3.  풀스택 = 프런트엔드 + 백엔드 + 데브옵스

---

책에서 기억하고 싶은 내용을 써보자

• 풀스택 개발자는 무조건 모든 영역을 다 개발해야 한다고 생각하는데, 할 수 있는 것과 하는 것은 엄연히 다른 거야.(121p)
• 서버는 영어로 봉사자 서비스를 제공하는 사람...서버는 그냥 컴퓨터(115p)

---

ep16. 인터넷 익스플로러가 사라진 이유와 브라우저 엔진

인터넷 익스플로러로 유튜브에 접속해보면 안된다고 나올 것임. IE는 미국 갔음(죽었다는 뜻)

 

인터넷 익스플로러는 CSS를 최초 적용, 지원한 웹브라우저. 1999년에는 Ajax(Asynchronous JavaScript and XML)을 최초로 지원함. => IE는 사람들이 좋아하는 기술을 빨리 지원하는 HIP한 프로그램.. 이었따

*Ajax는? 웹사이트에 어떤 내용을 업데이트 하면 새로고침 해야되는데 안 해도 볼 수 있게 해주는 기술임.

 

프론트엔드(Front-end) 웹 개발 : 사용자와 가장 가까운 개발 영역을 담당하는 개발.

이 프론트엔드에 필요한 3대장이 HTML, CSS, JavaScript.

HTML은 웹에 들어갈 규칙인데 이 규칙(표준안)을 정하고 웹브라우저를 개발하게 됨

HTML의 경우 h1은 굵고 큰 제목 글씨->그렇게 정해진대로 표현되도록 웹브라우저 개발 -> 그런 웹브라우저의 핵심 프로그램을 "브라우저 엔진"or"렌더링 엔진"이라고 함

엔진 이름	브라우저 이름
게코	파이어폭스
웹킷(webkit)	사파리
블링크(blink)	크롬

자바스크립트도 마찬가지인데 ECMAScript라는 표준안, 웹브라우저에서 실행할 수 있게 해주는 v8엔진

핵심! 엔진의 성능 == 웹 브라우저의 성능

 

IE는 점유율이 95%인데 보안 취약점 등도 잘 안고치고, 업데이트도 오래 걸리고...

그동안 다른 웹브라우저는 발전해왔고, IE는 결국 가버림.

 

ep17. 아, 쿠키가 먹는 게 아니라고요?

여기서 말하는 쿠키는 HTTP 쿠키. 쿠키는 웹 기술 관련. 어떤 웹사이트에 방문했을 때 브라우저를 통해 우리의 컴퓨터에 보관하는 기록물이 쿠키.

예) 페북 쿠키: 우리가 어떤 웹사이트에 방문했는지, 관심사가 뭔지 등을 관찰

how? HTTP에 대한 이해가 필요함

HTTP는? HyperText Transfer Protocol. 인터넷에서 사용자<->서버 정보 주보갇기 위한 일종의 규칙

HTTP는 우리와 서버는 항상 연결되어 있지 않다stateless라는 특징

예를 들어 주소창에 입력한다->서버가 그에 맞는 데이터를 보내준다.->데이터전송완료되면 연결 끝...누구세요?

여기서 문제점... 가끔은 우리가 누구인지 기억할 필요가 있음. 그때 필요한 게 쿠키

 

우리가 웹사이트를 사용하다가 껐다가 켜도 정보가 기억되는 경우(로그인 아이디 기억 등)가 있을텐데, 로그인할 때 서버에서 일종의 영수증 같은 것을 발행해주기 때문에 이것을 우리의 컴퓨터에 저장하고 나중에 다시 접속하면 이 영수증을 서버에 보냄. '그때 걔?' 라면서 ㅇㅋ ㄱㄱ 해주는 것임. 

이 영수증이 바로 쿠키.

 

쿠키의 규칙(편의, 보안상)

1. 쿠키는 도메인 1개에만 한정 (여기서 만든걸 다른데서 쓰면 안된다)

2. 쿠키는 자동으로 보낸다 (물어보는 곳도 있지만, 대부분 자동)

3. 쿠키는 컴퓨터에 자동으로 저장됨

 

근데 1번 규칙대로라면 페북은 내가 어디 갔는지 몰라야 되는데?

도메인과 상관 없는 쿠키가 있음. 상관 없는 사이트라도 페이스북의'좋아요'가 있다면? 이를 통해서 상관 없는 사이트의 쿠키를 얻을 수 있다.

웹 개발자라면 꼭 알아야 하는 브라우저 익스텐션( 작업 능률을 높이는 익스텐션들)
1. ColorZilla : 색상 스포이드 기능
2. Momentum : 할 일 목록 정리
3. CSSViewer : 특정 페이지의 CSS Element를 확인할 수 있게 해줌
4. JSON Viewer : 마구 나열된 JSON을 예쁘게 정리해서 보여줌

 

ep18. 프런트엔드, 백엔드?

프런트엔드와 백엔드의 의미는 뭘까?

front end 앞 끝 : 앞쪽 끝 : 제일 앞쪽 => 사용자와 마주하는 화면

back end 뒤 끝: 뒤쪽 끝 : 제일 뒤쪽 => 모든 프로그램의 제일 뒤. DB, 라우터

* 웹개발만 있는 거 아님 다른 개발 영역도 있음 여기서는 웹개발 영역으로 얘기하는 거임.

 

프런트엔드

단점: 기술의 변화가 엄청 빠르다. 공부해야할 내용이 많음. 계속 발전하고 업데이트해야 하는 환경. 대신 그만큼 활발한 곳이기에 기회도 많음

장점: 내가 입력한 것의 결과를 바로 볼 수 있다. 사용자와 거리가 가깝다. 피드백 받기도 쉽다. "녀석이 만든 웹사이트를 봐 아지 멋진 걸"

 

백엔드

장점: 개발 환경이 안정적. 장고, 루비온레일즈 등. Node.JS는 빠르다고 해도 프런트엔드만큼은 아님. 2년 전에 배운 장고를 다시 공부하면 일부 기능만 업데이트하면 되는 느낌. 즉, 백엔드는 변화가 크지 않다.

기술 선택지도 다양하다. 프런트엔드는 HTML,CSS,JavaScript를 무조건 해야한다면, 백엔드는? 자바, 루비, 장고, 파이썬, 플라스크 등등 많음.

단점: 초보자는 노잼. "너의 데이터베이스 구조가 아주 멋진걸?" << 이런 사람 없음. 

 

ep19. 서버가 뭔지 아직도 모른다고?

서버 터졌네 이런 얘기 자주 들음. 근데 서버가 도대체 뭐냐?

서버는? 그냥 컴퓨터임. 항상 연결되어 있는 모습일 뿐.

 

서버는 기다리고 있다가 naver.com이라고 누가 말하면 '주문하신 naver.com 나왔습니다.'하고 주는 역할임.

항상 인터넷에 연결되어 있으면서 기다리고 있다가 입력이 오면 그에 맞는 출력을 주는 녀석.

=>서버는 항상 켜져 있는 컴퓨터이면서 인터넷에 연결되어 있고 접속 요청에 응답하는 컴퓨터

 

ep20. 슈퍼 개발자만 할 수 있다, 풀스택?

full stack이 뭐냐? 풀스택은 프런트엔드, 백엔드, 데브옵스(DevOps)를 포함하는 개념

*데브옵스는 개발과 운영의 합성어를 말함.

 

잠깐 복습

프런트엔드: HCJ, 사용자에게 보이는 것, 상호작용하는 기술 영역

백엔드: 사용자한테 안 보이는 것. 데이터베이스에 저장하고 처리하는 등의 영역

 

프런트엔드+백엔드 = 풀스택인 것이냐? 그걸 서버에 올리고 고르고 설정하고, 서버에 소프트에어도 설치하고, 등등. 할일이 많은데 이것들을 데브옵스라고 하고 이런 일을 하는 사람을 데브옵스 개발자라고 함.

 

풀스택 개발자가 된다는 것은... 웹페이지 화면 만들기 + DB에 데이터 저장하기 + 완성된 프로그램 서버에 올리기

=> 1인 스타트업 (물론 기획도 포함)

 

※이런 회사는 조심하쟈!~

풀스택 하나만 뽑는 회사라면? 팀원이 몇이나 있는지 확인해야 됨. 풀스택 only one이면 한마디로 혼자 일 다하라는 뜻임.

점검사항

- 백엔드로 Node.JS를 사용하나요? 파이썬을 사용하나요?

- 데브옵스는 할 수 있지만 개발에 더 집중하고 싶은데, 개발 프로세스가 궁금합니다.

- 팀원은 몇 명이죠?

 

ep21. 서버리스는 서버가 없다는 뜻?

서버리스에 대해서 들어보았는가?

있는데 없어요. 서버가 뭔지 알았을 것임. 근데 서버리스가 뭐냐? 서버는 있지만, 우리가 직접 관리하지 않는 서버라는 것.

 

예전에 하던 서버 관리부터 알아보자.

예전에는 직접 서버를 구매해서 관리했음. 근데 전기 나가면? 실수로 망가뜨리면? => 서버 나가는 것

즉, 예전에는 서버를 수동으로 직접 관리하는 것

 

아마존의 등장.

EC2 Amazon Elastic Compute Cloud. 서버를 아마존이 대신 운영해준다는 뜻.

아마존, 구글, 마소 등등이 이런 서비스르 제공하고 있음. 여기는 그냥 그 서버라는 하드웨어를 제공해주는 거고, 서버의 소프트웨어 관리는 여전히 우리의 몫임. 운영체제 업데이트, 보안 점검, 장애 회복, 데이터 백업 등

 

=> 서.버.리.스

우선 서버를 위한 소프트웨어를 작은 함수 단위로 쪼개고 아마존 같은 서비스 서버에 올리는 것. 이 함수들은 서버에서 항상 깨어 있지 않음. == 그 함수가 필요할 때 깨워서 작업 수행

이제 우리는 등록된 함수가 실행된 만큼만 돈을 내면 됨.

 

서버리스의 단점

1. 콜드 스타트: 서버리스는 잠에서 깰 때 시간이 필요하다.

평소엔 잠을 자고 있으니 요청->깨우기->응답에 시간이 필요함. 그래서 중요한 서비스들은 서버리스지만 일부 함수를 깨어있게 하기도 한다고 함.

2. 서버 제공자에게 지나치게 의존적임

아마존이 마음에 안 들어도 마음대로 이사가기 힘듦. 왜? 이미 아마존 없인 살 수 없는 서버가 되어버렷..기 때문임.

 

서버리스 누구에게 좋은가?

사이드 프로젝트를 하는 사람, 프로토타입을 빨리 출시하고 싶은 사람

왜? 코드에 집중해서 작업할 수 있기 때문

서버리스 참고 프레임워크 사이트 살펴보기==>
serverless.com, AWS 람다, 구글 클라우드 펑션, 아펙스Apex, 테라폼Terraform

---

오늘 읽은 소감은? 떠오르는 생각을 가볍게 적기

[ 백엔드, 그리고 서버 생각보다 엄청나게 복잡한 개념은 아닐지도 ]

 

백엔드와 서버의 개념은 막연히 나와는 거리가 먼 개념이라고 생각하고 있었다. 전공자가 해야하는 것, 전공자가 할 수 있는 일이라는 생각이었다면, 이번 독서에서 느낀 점은 서버라는 개념이 무엇이고 백엔드와 프런트엔드의 구분이 정확히 어떤 의미인지 이해할 수 있었다는 점이다. 막연한 선입견 탓에 찾아볼 생각도 하지 않고 있었다..

서버의 개념을 봉사자로 이해시켜주자 이해가 아주 쉬웠다 주소창을 통한 데이터 주고받기의 개념 역시 이해가 되었다. 인터넷이라는 가상의 마법이 아니라 HTML 문서 데이터를 가지고 있다가 우리에게 보내주는 것!!

백엔드와 서버의 개념에 대한 이해가 높아지니 오히려 목표로 생각하고 있었던 프런트엔드에 대한 자신감도 조금 더 올라갈 수 있었다.

---

궁금한 내용, 잘 이해되지 않는 내용

• 따로 없음