기술 정리

HTML, CSS, JavaScript

• 한 세트로 생각하면 된다
• 갖다놓고 꾸미고 시킨다
• 웹사이트, 즉 브라우저에서 동작하는 소프트웨어에만 국한되지 않는다.
• React Native나 Native Script 처럼 모바일 앱을 만드는 기술들이 사용되고있다.
• HTML이 올려놓은 것을 CSS가 꾸민다.
• JavaScript는 프로그래밍 언어에 속한다. 원래는 브라우저에서 웹사이트를 돌리는 그닥 대우 못받는 언어였는데, NodeJS가 웹브라우저 밖으로 꺼내오면서 아주 위상이 높아졌다.
• 웹사이트에서 돌아가는 자바스크립트는 브라우저에서 다양한 일을 수행한다.
• html, css, javasctipt를 하나의 폴더 안에 만든다. head에 css와 javascript를 넣고 body에 html을 넣는다.
• html은 그저 화면에 얹을뿐.
• css는 색도 넣고 틀도 깎고 디자인이 가능하다.
• javascript는 html다 읽힌 후 작동하게 되어 있다.
• css, html 은 쉽지만 연습이 필요하다.
• javascript는 발전하는 중이어서 끊임없이 배워야 한다. 예전에는 jQuery라는 강력한 라이브러리로 순수 자바스크립트보다 훨씬 코딩을 쉽고 편하게 하곤했는데, 요즘은 자바스크립트도 파워풀해지고 jQuery의 성능문제도 있고 프론트엔드 프레임워크 같은 새로운 개발방식들이 나오면서 “jQuery를 배우지 않아도 된다.” 심지어 “이제는 jQuery를 쓰지 않도록 해야한다” 는 의견들이 있다. 실제로 필자도 쓰지 않은지 꽤 됐다.
• 입문자들은 우선 자바스크립트를 탄탄히 배워놓은 다음, 이런 라이브러리나 프레임워크를 필요에 따라 배워나가면 좋을 것이다.
• 웹사이트를 만들때 기억해야할 것이 HTML, CSS나 자바스크립트의 최신 기술들을 다 이용하려고 하면 곤란하다. 웹사이트는 어디까지나 위와 같은 브라우저(크롬, 사파리, firefox, edge 등)에서 작동하는 소프트웨어인데 이 브라우저들 중 일부에서 최신 기술들을 지원하지 않거나 혼자 이상하게 돌아가는 경우가 있기 때문에 사람들이 어떤 버전의 어떤 브러우저를 얼마나 사용하고 그것들이 지원하는 기능들은 어디까지인지 이 ‘호환성’을 확인하고 테스트해가면서 개발하는것이 중요하다.

---

동적웹 vs 정적웹

• 정적웹은 언제 접속해도 같은 리소스를 보여주는 웹사이트를 말한다.
• 정적웹사이트에 접속하면 이미 프로그래머가 작성해놓은 파일을 클라운터의 브라우저로 제공해준다.
• 시간 표시, 랜덤함수, 서버에서 받아오는 내용을 보여주는 것도 있다. 정적웹의 기준은 HTML, CSS, javascript 파일이 같은가이다. 접속시마다 내용이 변할 필요가 없는 사이트등에 사용될 수 있다.

 

• 동적웹은 서버가 그때그때 요리 하는거다.
• PHP가 예시이다.
• 데이터베이스로 정보를 읽어서 웹페이지를 만드는 것.

 

• 그럼 동적웹이 무조건 좋은것 아닐까?
• 아니다. 동적웹은 매번 서버가 일을 해야하기 때문에 HTML형식으로 잡지처럼 나열해놓는 형식을 사용하기도 한다. 정적 웹 생성 툴로 블로그를 많이 운영하기도 한다. jekyll(지킬) 이나 HUGO 가 그 예시이다.

---

MVC 웹 프레임워크란?

• 동적웹을 좀 더 깊이 파고 들어보자.
• PHP 파일 안에서 변수들을 다루고 db에 접속하고 html을 작성했었다.
• 그러나 네이버는 저런 방식으로는 어렵다. 뭔가 거대해고 복잡할때는 특정 기준으로, 분리하고 모듈화한다.
• 웹사이트를 비롯한 소프트웨어들에는 Model , View , Controller.    즉, MVC라는 접근법이 많이 사용된다.
• View : 눈에 보이는 것들, HTML, CSS로 나타내는 요소들
• Controller : 뭔가 제어하는 것. 프로그래밍이 여기서 이루어짐
• Model : 데이터에 관련된것이라고 생각하면 됨. 게시판을 생각해보자. 게시판에 쓰이고 읽히고 수정되는 글들은 db에 저장된다. 그 db의 형식을 저장하고 저장하고 불러오는 것이 model 파트에서 이루어진다.
• 이걸 사용자들이 목록과 글, 입력화면 등으로 시각적으로 볼수있게 해주는 html, css가 view 파트에 작성된다.
• Model 의 데이터를 View 에 연결해서 사용자가 GUI 화면의 데이터를 읽고 쓰고 지우고 할수 있도록 전반적 제어를 하는 파트가 Controller 인것이다.
• 동적웹을 식당에 비교했었는데 Model은 식료품창고를 관리하고 음식을 요리하는 주방장
• View는 주방장이 내온 음식을 플레이팅하는 직원
• Controller는 주문도 받고 서빙도 하는 매니저에 비유할 수 있다.
• 이렇게 Model, View, Controller 를 갖춘 웹사이트를 코드로 기본 골격을 한 번 짜고 나면 그 코드를 기반으로 내 사이트를 개발하는 일이 수월해지겠지만 이런 구조 자체를 개발하는데는 꽤나 시간이 걸린다.
• 각종 만들기, 조립 세트처럼 전문가들에 의해 필수요소가 이미 만들어져 있는게 있다면 참 편리할 것이다.
• 다행히도 여러 회사나 다른 집단들이 이 MVC 구조이 기본 설계가 갖춰진 상태인 MVC 웹 프레임워크라는 것을 제공한다.
• 건물의 기초 골격과 수도, 전기, 난방이 설치된 채로 사용자가 원하는대로 집을 개조하고 꾸밀수 있게 제공되는 것이다.
• ‘프레임워크’는 남이 이미 짜놓은 코드라는 점에서 ‘라이브러리’와도 비슷한데
• ‘라이브러리’가 각각 개별적인 기능들. 즉, 문짝이나 욕조 등의 부속품이라고 한다면
• ‘프레임워크’는 이것들이 연결되어서 기초적인 제품 골격을 갖춘 상태를 말한다.
• 쉽게 말해서, 가져다 쓰는게 ‘라이브러리’이고
• 기본 틀로 삼아서 그 위에 뭘 덧붙여 만드는게 ‘프레임워크’이다.
• 웹 프로그래밍에는 다양한 언어들이 사용되고 이 언어들마다 여러 MVC프레임워크가 있다.
• 한국에서 가장 많이 사용되는것은 Java언어로 동작하는 Spring 프레임워크
• PHP 개발자들에게 워라벨은 없지만 라라벨 등이 있다
• 특이하게도 MVC라고 안하고 MTV(Model Template View)라고 하는 Python의 Django
• 일본에서 많이 쓰는 Ruby의 Ruby on Rails
• 함수형 언어 Scala의 Play 등등 굉장히 많다.
• c#의 닷넷코어
• Angular 같은 프론트엔드는 나중에 다뤄보자.
• 어느 회사에서 일하는가 혹은 어떤 웹사이트를 만드는가에 따라서 무슨 언어와 프레임워크를 사용할지 결정하면 된다.대략적인 구조나 사용법이 다 비슷비슷해서 한 두 가지 써보면 새로운 걸 접해도 쉽게 알 수 있다.

---

Angular, React, Vue 란?

• SPA 프론트엔드 프레임워크에 대해 알아보자.
• 이것들이 왜 나왔는지 이유부터 알아보자.
• 강력한 MVC 웹 프레임워크들이 등장하고 발전하면서 우리는 편리하고 빠르게 웹사이트를 개발할수 있게 되었다.
• 하지만 기술이 발달해서 어떤 필요를 충족하고 나면 또 다른 수요와 해결 과제가 생기기 마련.
• 기존 MVC 웹이 가졌던 아쉬움들 중에 두 가지를 살펴보자.
• 첫번째, 오래된 웹사이트일수록 이러한 사용자경험이 많을 것이다. 이것저것 있는 웹사이트에서 한 게시글 좋아요 눌렀는데 고작 그거 하나 업데이트 한다고 페이지가 깜빡하고 업데이트 되는 것이다. 결국 전체를 서버에서 다시 불러오는 것이다. 비효율적이다. 사이트에 로드할 정보나 이미지들이 많으면 데이터 낭비도 심할 것이다. 옛날에는 이렇게 통쨰로 다시 로드해야했다.
• 다행히 ajax 라는 기술이 나온 이후로는 http 통신으로 데이터를 전송하고 결과를 받아와서 사이트의 이 부분을 이렇게 변경해라 하고 자바스크립트로 명령을 줄 수 있게 되었다.
• 대신 이걸 일일이 프로그래밍 해야되는 불편함이 있다.
• 두번째, 예전에는 PC용 웹사이트 하나만 만들면 되었지만 모바일 시대가 열리고, 앱이나 스마트폰 브라우저로 서비스들이 이용되기 시작하면서 이제는 어느정도 갖춰진 사업을 하는 회사에서는 개발자들이 PC용 웹사이트, 모바일용 사이트, 그리고 아이폰과 안드로이드용 앱과 서버까지 개발해야하게 되었다.
• 먼저 PC용 사이트는 접속이 들어오면 데이터베이스에서 정보들을 찾아서 그걸로 HTML, CSS, JavaScript로 렌더링하고 이걸 PC의 브라우저에 보내준다. 반응형으로 만들지 않는 다는 가정 하에 모바일용 사이트도 이 과정을 다 프로그래밍 해야 한다. 안드로이드나 iOS의 네이티브 앱은 앱 개발자들이 만든 앱에서 서버에 정보를 요청하면 데이터베이스에서 정보들을 찾아서 앱으로 전송하고 앱에서는 이 정보들을 받아서 안드로이드나 iOS의 방식으로 폰 화면에 띄워주게 된다.
• 사이트 하나만 만들면 되던 예전보다 개발 인력이 배로 들겠죠?
• 여기서 겹치는 부분들을 최소화하고 업무를 더 깔끔하게 분할할 수는 없을까요?
• 안드로이드와 iOS 에는 자체적인 SW와 시스템이 있어서 서버로부터 데이터만 전송받으면 화면이 보여질 수 있다.
• 웹에서도 그게 가능하다면, 즉 서버에서 데이터만 보내줘도 이걸 부라우저에서 HTML, CSS, JS로 렌더링해낼 수 있다면 이제 서버는 어디서 요청이 들어오든 동일한 작업을 수행해서 데이터를 전송하면 될 것이다. 서버 개발자가 이 일에만 집중할 수 있게 되는 것이다.
• 웹사이트 개발을 이렇게 사용자 컴퓨터의 브라우저에서 돌아가는 프론트엔드와 서버에서 돌아가는 백엔드로 분리하는 것이다.
• 브라우저에서도 동작하는 이 자바스크립트란 언어로 강력한 라이브러리나 프레임워크를 만들면 가능하지 않을까??
• 바로 그게 Angular, React, Vue 같은 SPA 프레임워크이다.
• 정적웹은 편의점, 동적웹은 그떄그떄 요리해주는 식당에 비유 할 수 있다.
• SPA, Single Page Application 은 종업원들이 고기와 쌈재료를 가져다주면 손님이 직접 불판에 구워먹는 고기집이라고 생각하면 된다.
• 서버는 정적 웹처럼, HTML, CSS, JS 로 된 코드들을 브라우저에 전송해준다.  여기 포함된 자바스크립트 코드는 기똥찬 기능을 수행하는데 그것은 주어진 데이터에 따라 HTML 웹페이지를 렌더링 해내는 것이다.
• 기존에 동적 웹에서 서버가 하던 일을 이제는 사용자의 컴퓨터에서 브라우저가 해내는 것이다. SPA는 서버에서 데이터를 받아와야 할 때마다 요청을 보내서 반환된 데이터로 사이트 내용을 갱신한다. 
• 이렇게 되면 사이트에서 뭘 할 때마다 새로 접속하지 않고 한번 로드된 화면에서 많은 기능을 사용할 수 있다.
• 그래서 Single Page Application 이라고 불리는 것이다. 
• Angular, reanct, vue는 방식은 달라도 기본 아이디어는 비슷하다.
• vue 가 가장 쉽다. 
• 중요한건 코드가 서버가 아니라 브라우저 즉, 사용자의 컴퓨터에서 돌아간다는 것이다.

 

• 기존 MVC에서는 서버가 최종 결과물까지 요리해서 보내줘야 했지만 이제는 브라우저한테 ‘자 여기 이렇게 레시피를 줄테니까 필요한 재료들만 따로 요청해서 네기 페이지를 요리해내’하고 역할을 맡기는 것이다. 
• 전보다 사이트가 훨씬 효율적으로 동작하는 모습을 볼 수 있다.
• Vue는 코드가 깔끔하고 배우기 쉽다는 특성떄문에 다른 둘에 비해 후발주자임에도 불구하고 빠른 속도로 성장하고 있다.
• React는 Facebook에서 만든 것인데 막강한 커뮤니티와 자료들을 갖추고 있다. 다른 설계들에 잘 녹아들기 때문에 유연성을 요구하는 서비스에  권장된다.
• Angular는 Google에서 만든 것인데 TypeScript라는, JavaScript를 보완한 언어로 매우 안정적이고 탄탄한 프론트엔드 앱을 만들 수 있다. 대신 상대적으로 무겁고 배우기 어렵다는 단점이 있다. Angular는 Framework의 구조가 뚜렷하다면 나머지 둘, 특히 React는 라이브러리의 특성을 갖는다는 차이가 있다.
• 뭐든 필요와 취향에 따라 선택해서 배워보면 다른 것도 쉽게 배울 수 있을 것이다. 

---

비동기 프로그래밍이란?

• 동기적이란 코드가 반드시 작성된 순서 그대로 실행된다
• 비동기적이란 꼭 한줄한줄 순서대로 실행되는 건 아닌 코드
• 왜 굳이 헷갈리는 비동기를 쓰는것이지? 
• 프로그래밍이 비동기로 한다는것은 쓰레드나 프로세스가 여러개 구현되고 있는 것이다.
• 자바스크립트는 싱글 쓰레드라고 배웠는데 어떻게 여러개가 돌아가죠? 
• 자바스크립트는 웹 브라우저나 Node.js의 자바스크립트 엔진에서 실행된다.
• 이 엔진에는 자바스크립트를 돌리는 하나의 쓰레도가 있다.
• Web API 가 함께 있다. 여기서는 시간을 처리하는 작업들을 수행한다. 브라우저나 Node.js에서 돌린다. 콜백 칸들은 태스크 큐를 따라 자바스크립트로 돌아오게 된다. 물레방아같은 것이 콜백함수들을 자바스크립트로 올려준다. 이 물레방아를 이벤트 루프라고 한다.
• 순서가 섞일 것같은데??  콜백 지옥… 가독성도 떨어진다. 그래서 Promise라는 것이 만들어졌다.
• Promise 란 비동기 작업을 마치면 then 이라는 콜백을 수행하라는 약속인가보군..
• Async 함수안에 비동기작업을 한다. await 코드는 잠시 멈추게 함.

---

RESP API 란?

• REST API 는 정보들이 주고받아지는데 있어서 개발자들 사이에 널리쓰이는 일종의 형식이다.
• 어떤 기술이나 제품이 아니라 형식이기때문에 이 폼에 맞춰서 기능을 만들어내면 된다.
• 예를 들어 tv의 리모콘, 자판기의 버튼, 컴퓨터의 마우스나 키보드가 있는데 이것을 interface라고 한다. 사용자가 명령을 넣는 것 뿐아니라 그 결과와 정보를 받아오는 tv의 스크린, 컴퓨터의 모니터 또한 interface이다. 사람과 기계의 소통 창구이다.
• 기계와 기계, 소프트웨어 소프트웨어 사이에도 소통할 수 있는 창구가 필요하다. 기상정보 관련 서버가 있다. 포털이나 날씨를 제공하는 웹사이트들은 기상청에서 정보들을 받아온다. 
• 여기서 정보를 요청하는 정해진 형식이 있어야겠죠!? 그것이 API 이다. 
• REST API 는 무엇인가?? 프론트엔드 웹에서 서버에 정보를 요청할 때 REST 형식의 API 를 사용한다. REST의 가장 중요한 특성은 각 요청이 어떤 동작이나 정보를 위한것인지 그 요청의 모습을 보고서 추론 가능하다는 것이다.
• 요청을 보낸 주소만으로도 무슨 의도인지 파악 가능하다. 
• 수정 삭제 CRUD 한다. HTTP 라는 규약으로 신호를 전달한다. HTTP로 요청을보낼 때 여러 메소드가 있다. GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS, TRACE, PATCH 등등
• REST API에서는 GET, POST, PUT, DELETE ,(PATCH) 이 4가지 혹은 5가지를 사용한다.
• POST 하나로도 데이터를 CRUD 다 할 수 있다. 하지만 RESTful 하게 API 를 짜야한다.
• GET : READ, 조회하는데 사용 
• POST : CREATE
• PUT or PATCH : UPDATE
• DELETE : DELETE
• 결국 REST API 란 어떤 URI 에 어떤 메소드를 사용할지 개발자들 사이에 널리 지켜지는 약속이다. 
• 이미 말했든, 형식이기 떄문에 기술에 구애받지 않는다.
• 소프트웨어간 HTTP 로 정보를 주고받는것이 있다면 REST API 개발 연습을 해볼 수 있다.
• REST API 의 대안인 GraphQL에 대해서 알아보자.

---

GraphQL 이란?

• REST API 와 대조를 해보자면
• REST API 의 장점은 메소드와 URI 를 조합해서, 예측 가능하고 일정한 정보와 작업을 요청하는 것이다. 버튼마다 나오는 것이 확실한 자판기처럼 말이다.
• 유용한 방식이긴 하지만 불편한 점이 있다. 영어 성적을 알고 싶으면 수학, 국어 성적 정보들까지 다 읽어버린다. 그래서 데이터 소모가 많다.
• 1반의 정보를 얻고 싶다. 한번의 요청으로는 REST API 로는 다 불러올수없다. URI 마다 하는것이 따박따박 정해져 있지만 
• GraphQL 은 body에 들어간 주문서로다가 유도리 있게 요청이 가능하다.
• 같은 API 서버를 쓰더라도 사용자마다 사용하는 매체들이 다를 텐데 GraphQL 은 매우 유용.
• 정보요청은 POST 로 하고
• 그 요청의 body 내에 서버가 할일이 저장되어 있다.
• GraphQL보다 REST API 가 유리한 케이스도 있을 것이다. 받아야 하는 항목들이 많고 딱 정해져 있는 경우에는 그것들을 하나하나 GraphQL 요청에 적어 보내기보다 Rest API의 URI 한줄로 요청하는게 나을 것이다.
• 요청은 단순하고 데이터는 복잡한 Rest API, 요청은 복잡하고 데이터는 효율적인 GraphQL
• 만드는 서비스가 누구에게 어떤 정보를 제공하느냐에 따라 신중하게 고르면 되려나??
• 그럴 필요 없다. 백엔드 서버 하나에 Rest API 랑 GraphQL 을 둘 다 구현해 놓으면 되니까.
• 어디까지나 개발자가 구현하기 나름 
• node.js 의 express 로 만드는 것이 하나의 예임.