여기 용어를 오용하거나 개념이 잘못 잡힌 사람들이 많아서 짤막하게 남기고 감. 개발 뉴비들은 다들 이거가 맞니 저거가 맞니 해서 많이들 헤깔렸을 거라 보니 도움되길 바람. jQuery 퇴물, 리액트 최고! 에 관심있는 사람들은 스크롤 내려서 그 부분부터 시작하셈. 매우 얕게 다루고 있음으로 오류 가능성 있음.

*웹이란

용어 정리

프로토콜: 그냥 전기 신호를 어떻게 보낼까 약속한거임. ㄷ ㄸㄸ 이라고 보낼지 ㄷ ㄷㄷㄷ 라고 보낼지 같은 차이임. 한국어로 통신 규약이라고 함. 자세히 들어가면 복잡함.

HTTP: 프로토콜의 한 종류, 웹을 위해 만들어짐.

모두가 알겠지만 우리가 보는 웹은 그냥 하나의 텍스트 파일, 문서임. 다만 브라우저는 일종의 '규칙'을 가지고 있어서 특정 텍스트를 비주얼 적으로 다르게 보여줌. 갸령 x->ㄴ y->ㅁ 해서 xy 라고 쓰고 전송하면 우리 브라우저 화면에서는 ㄴㅁ라고 보이는 것임. 또 책과 달리 이 HTML 텍스트는 다른 HTML 텍스트 파일로 제한없이 이동할 수 있음. 실제 책은 페이지를 순서대로 넘겨야 하잖아? 이를 하이퍼텍스트 라고 함.

브라우저라는 프로그램은 HTML로 작성된 문서를 수신함. 브라우저는 '누군가'에게 HTTP의 형태로 HTML을 받아 위에 말한 규칙에 따라 한번 번역을 한뒤 우리에게 비주얼적으로 보여줌.

*웹 서버란...nodejs와 기존 웹 서버의 차이?

웹 서버란 서버에 저장된 파일을 클라이언트의 요청에 따라 보내줌. HTTP를 당연히 지원하기 때문에 유저가 domain.com/order/detail 라는 url을 입력하면 서버 컴퓨터의 order 폴더 내 detail 파일을 건내주는 어찌보면 단순한 구조임. 공급자는 서버 컴퓨터에 미리 HTML문서를 작성해 놓고 서버를 띄어 놓아 유저가 브라우저로 HTTP요청을 날리면 그에 해당하는 HTML을 건내줌. 이를 정적 파일 호스팅 이라고 함.

하지만 단순 HTML, CSS, Javascript 가지고는 비즈니스 로직을 처리하기 어려움, 데이터베이스 질의를 필요로 한다던가. 이에 따라 Python PHP Java 등 프로그래밍 언어로 스크립트를 작성하고 적절한 결과 값을 HTTP요청에 따라 되돌려 줘 동적으로 HTML을 작성하는 방법이 필요함. 웹 서버와 이 서버 사이드 스크립트를 연결시켜 주는 것을 CGI 라고 함.

HTTP 신호가 들어오면 웹 서버가 신호를 CGI에게 패스해줌, 이렇게 신호를 건내 다른 놈이 처리하고 결과를 리턴 받는걸 프록시 라고 함. CGI는 스크립트를 실행시켜 받은 결과값을 기본으로 HTML을 작성함. 웹 서버는 로컬 파일처럼 저장된 HTML마냥 똑같은 방식으로 작성된 HTML을 유저에게 되돌려줌.

리액트 노드 리액트 노드 거리면서 리액트를 아파치, nginx 등과 써야 하나? 노드가 짱 아닌가? 웹 서버는 퇴물 방식인가? 라는 의문이 있었을 것임. 노드는 그 자체가 응용 프로그램으로 들어오는 입력(이벤트)에 따라 반복적으로 자바스크립트를 실행시켜 줌. 우리가 익스프레스를 붙여서 웹 서버로 사용할 수 있는건 HTTP를 입력으로 받아들이게 하고 자바스크립트를 실행시켜 그 결과 값을 HTML로 내보낼 수 있기 때문임(혹은 JSON등 다른 마크업 언어).

그럼 앞으로 노드를 쓰고 웹 서버는 필요가 없냐? 아님. 노드는 싱글 스레드기 때문에 웹 서버로 쓰기에는 적합하지 않음. 이건 자세한 내용을 쓰면 길어지니깐 패스함.

*웹의 역사

*용어 정리

웹 프레임워크: HTTP를 수신하고 결과값을 내보내는 스크립트를 더 쉽게 작성할 수 있도록 미리 짜여진 소스코드와 구조

서버 사이드 스크립팅: DB등 적절한 자원을 땡겨오고, 필요한 절차를 규정한 뒤 적절한 결과 값을 되돌려 보내기 까지를 코딩하는 것.

위처럼 브라우저는 누군가에게 HTML을 받아 그려줌. 즉 웹을 통해 고객 혹은 원하는 대상에게 원하는 화면을 보여주려면 요청을 보낸 유저의 브라우저에 규칙에 따른 알맞은 하이퍼텍스트를 작성해 HTTP로 보내줘야함.

익스프레스 등을 깔짝여본 사람들이 제일 먼저 배웠던게 "Listening port XXXX" 일 것임. 우리는 HTTP 신호를 수신할 수 있는 응용프로그램(혹은 CGI가 통신할 스크립트)을 만들어서 유저에게 필요한 문서를 되돌려줌. 유저에게 전달해 마크업을 스크립트를 작성해 그려내는 과정, 이게 요즘 부르는 서버사이드 스크립팅임(동적일 경우 SSR, 전처리일 경우 pre-rendered 이라 하는데 자세히는 스킵함). 예로 PHTML이라든지, 아니면 프레임워크에 템플릿 엔진이 내장되어 있기도 함.

웹 프레임워크로 짜여진 웹 응용 프로그램이 하는 일은 따라서, 데이터베이스 등과 같은 자원과 소통하고 프로그래밍을 통해 유저에 의한 HTTP요청이 발생했을때 적절히 작성된 HTML을 되돌려 주는 것 이라 할 수 있음 (물론 실제로는 훨씬 많음). 이 응용 프로그램(어플리케이션)을 서버라고 부름 (단, 인프라쪽에 말하는 서버와는 다른 말)

*jQuery... 그 전에 브라우저란

용어 정리

DOM: 브라우저가 HTML문서를 렌더링 하면 그게 DOM이 됨.

먼저 브라우저가 무엇인지 정의해야할 필요성이 있음. "웹 브라우저 또는 브라우저는 웹 서버에서 이동하며 쌍방향으로 통신하고 HTML 문서나 파일을 출력하는 그래픽 사용자 인터페이스 기반의 응용 소프트웨어이다."

브라우저가 하는 일은 두가지임. HTML문서 (파일 등도 가능)을 비주얼 적으로 보여주는 것과 HTML에 내장된 스크립트 태그 속 내용을 실행하는 것임. 즉 스크립트 태그를 통해 우리는 HTML문서가 유저의 브라우저에 도달한 뒤에야 실행될 스크립트를 심는게 가능함. 거의 모든 브라우저들이 이에 쓰일 언어를 자바스크립트로 통일화함.

웹이 사용되는 방식은 그래서 상당히 기형적임. 보통 데스크탑 어플리케이션의 경우 대부분의 유저 액션과 비주얼화는 앱 내에서 처리함. 어느 화면을 보여줄지 혹은 넘어갈지 등 말이야. 다른 유저와 연계가 있는 전역적인 데이터를 필요로 할 때만 회사가 띄어놓은 서버와 통신해서 자료를 받아감 (HTTP든 어느 프로토콜을 사용하든지).

그러나 웹은 서버가 대부분의 일을 처리하고 (유저의 액션1에 의해 어떤 화면을 재구성해서 보여줘야 하는 지 등) 브라우저는 그걸 받아서 보여주기만 함. 근데 또 브라우저 내에서 실행되는 스크립트를 만들 수 있어서 브라우저가 알아서 바꿔서 보여주게 할 수 있음. 듣기에도 지저분하지 않음? 이건 모두 HTML이 단순한 '문서', 다른 파일과 같이(이미지 등) 그냥 좀 기능적인 텍스트파일로 취급되던 시절이었기 때문임.

*jQuery

용어 정리

라이브러리: 이미 누가 만들어놓은 소스 코드. 보통 네이티브 기능을 더 쉽게 사용하기 위해 사용함.

시대가 지날수록 웹에서 좀더 풍부한 비주얼, 좀더 강력한 기능을 요구하게 되었음. 즉슨 브라우저에서 실행될 스크립트의 고도화가 요구되던 시점임. 브라우저가 제공하는 자바스크립트로 된 DOM조작 API 통해 (자바스크립트의 document객체) 이래저래 마개조 할 수 있었음.

문제는 내장 document객체와 API는 매우 비직관적이었음 (심지어 아직도 그럼). 그래서 jQuery, Knockout 등이 등장함. 라이브러리를 통해 DOM을 조금 더 쉽게 조작하는 것임. 이를 통해 훨씬 풍부한 표헌이 브라우저 위에서 가능해졌음. 그래서 이 들을 DOM Accessor라고도 부름.

돔을 직접적으로 제어하는데는 이런 라이브러리가 필수였고 심지어 아직도 대체재는 없음! jQuery의 점유율이 유지되는 이유임.

(Ember, Backbone 등 이후에 등장한 것도 있는데 안해봐서 모름)

* AJAX, XML Request,.. 비동기 JS?

브라우저에서 서버에 덜 의존적이고 더 효율적으로 DOM을 그리기 위해 나옴. 자세한 내용은 생략함.

* jQuery는 퇴물? SPA의 등장

용어정리

ES6: 브라우저는 하나의 응용 프로그램이고 각 브라우저 개발 회사별로 스크립팅을 어떻게 할지, API를 어떻게 제공할지가 벤더 마음대로였음. 그래서 같은 자바스크립트 내에서도 파편화가 많이 됬었는데 이걸 통합시킨게 ES6임. 비동기 액션도 일관적인 문법으로 정립시켰기에, 더 역동적인 반응형 DOM을 더 쉽게 설계할 수 있게 되었음.

가상돔: 돔을 조작하는 이벤트가 발생해도, 우선 프레임워크가 스캔 한번 때려서 읽어들인 뒤 최적화, 구조적인 방법으로 지가 주때로 실제 돔에 반영하는 것.

그럼 왜 jQuery가 퇴물 소리를 듣고 모두 리액트,뷰,앵귤러를 사용할까? 프론트 신붕이 들은 과연 jQuery를 공부할 필요가 없을까?

2010년대 이후로 웹 시장이 엄청나게 커져버린 배경에는 3가지 개념의 등장이 있음. 바인딩, 컴포넌트, ES6.

jQuery를 쓰더라도 웹은 웹, 문서 쪼가리는 스케일이 커질수록 유지보수가 감당하기 힘들었음. CSS등이 더해지면 이를 읽는 것도 고통 그 자체임. 이 직접적으로 DOM을 조작하는 방식은 불편했고 그때 까지도 서버에 의존적인 기형적 구조는 계속됬음.

React,Angular,Vue 등이 나오고 상황이 급변했음. (이건 개괄적인 거고 실제로 타임라인이 정확하게 어떻게 되는지는 아는 사람이 달아주셈) 우리가 MVVM할때 그 바인딩 개념을 차용해서, 돔을 조작하는건 프레임워크가 알아서 해주고 개발자는 기능을 위한 스크립팅에 집중할 수 있게 됨. 즉 돔을 SDK 형태로, 간접적으로 접근하게 강요함으로써 기능 개발에 집중할 수 있게 해준 것임.

이는 당연히 직접적인 돔 조작보다는 퍼포먼스가 낮음 (리액트,뷰의 가상돔이든 앵귤러의 방식이든). 그러나 과거 브라우저의 악명과는 달리 이제는 어느정도 속도가 올라오고 기술적 혁신이 있었기에 무시할 정도가 되었음.

즉, OS위에서 실행되는 독립적인 응용 프로그램과 같이, 드디어 웹의 스크립트 딱지도 서버와 의존적이지 않은 하나의 어플리케이션이라 부를 정도의 볼륨으로 만들 수 있게 된것임. 이걸 웹 앱이라 칭함. 이렇게 타 분야 개발 같이 클라이언트랑 서버의 역활이 명확히 나뉘게 만들 수 있게 되고, 이제 기존의 서버를 백엔드, 클라이언트를 프론트 라고 부름 (즉 게임 클라랑 서버 개념이랑 동일함).

*프론트엔드 개발자 = 웹 퍼블리셔?

DOM에서 벌어지는 일을 보는 관점의 차이에 있음. 퍼블리셔는 DOM이 그저 서버에서 비즈니스 로직이 처리 된 후 이후의 결과 값을 비주얼 적으로 표현한다고 보고 만들어진 직종임. 그에 반해 프론트엔드 개발자는 DOM을 하나의 어플리케이션이 운용될 수 있는 환경이라고 봄.

즉 프론트엔드 개발자가 말하는 개발이란 무엇인가? 브라우저 라는 응용 소프트웨어가 읽어들인 HTML의 스크립트 태그를... 그러니깐 내 브라우저 안의 작은 응용 프로그램이라는 관점으로 보는 것임. 브라우저의 DOM이 추상화 될 수 있어(마치 OS같이) 간접적인 조작을 통해 보다 독립적인 응용 프로그램을 만들 수 있다는 것임.

그럼 프론트엔드 개발자는 jQuery를 공부해야 할까?

하고 싶으면 하고, 하고 싶지 않으면 안해도 됨. jQuery는 돔의 직접적인 조작을 위해 있는 것임. 리액트 등은 돔 조작을 간접화 시켜 실 개발을 구분시키기 위해 만들어 진거지 jQuery의 상위호환으로 설명할 수는 없음. 프론트엔드 개발자가 오히려 돔 조작에 서투른건 어찌보면 당연하다 할 수 있음. 마치 게임 개발자가 스킬 이팩트까지 건드리지 않는 거마냥.

프론트엔드 개발자는 비전공 양산 직종이다?

관점의 차이임. 브라우저를 환경삼아(OS같이) 어플리케이션을 돌리겠다는 발상 자체가 좀 발칙함. 태생부터 불안정 하기 때문에 여러가지 기술, 표준이 바뀌고 공부해야 할 것이 많음. 여러 기존 웹의 한계를 이리저리 기워 붙여서 해결하는 형상임.

또 하나의 지식에 깊게 파고들기 힘들고 넓은 지식 범위를 계속 공부해야함. 프론트엔드 시니어가 그렇게 구하기가 힘듬. 학문적인 성취의 관점으로 보면 그리 높지 않으나 실 코딩 실력으로 보면 다른 분야에 비해 떨어진다고 절대 할 수 없음. 비전공자들이 노력으로 도전할 수 있는 이유임(물론 쉽다는 뜻이 아님).

=========================== 아래는 기회가 되면 다룸 ==================================

*BFF, HTTP API, REST API, RESTful API, GraphQL, grpc란 무엇인가? 차이점?

백엔드 개발이란? API란 무엇인가? 현대적인 웹이 어떻게 서버와 서로다른 서비스, 어플리케이션 끼리 소통하는가?

*컴포넌트, SSR, JAMStack, SEO?

SPA는 모두 알다시피 검색 엔진 최적화 문제가 있음. 이 검색 엔진 최적화가 어떤 방식으로 이루어지고 과연 순수 SPA에서 해결하는 방법이 없는지. 그리고 대체재라고 나온 NextJS등의 동적 렌더링 방식이 야기하는 비용, 마지막으로 요즘 주목받는 JAMStack 방식에 대해 다룸.

*Express vs. Spring or Full Stack Frameworks, 어느 쪽이 우월한가? 적합한 용도는?

익스프레스, 혹은 풀스택, 백엔드 프레임워크를 써본 사람들은 과연 어느쪽이 더 나은 선택지인가? 전망은? 한 쪽이 상위호환인가? 등의 의문점을 가졌을 것임.

스프링과 익스프레스는 어느 한쪽이 다른 쪽을 대체하는 상위호환 개념이 아님. 같은 웹 카테고리에도 여러 분야가 나뉨, 채팅, 스트리밍이라 던지. 즉 회사가 어떤 서비스를 제공하냐에 따라 각 언어별로 강점이 있고 이를 활용하는 것임.

*웹 아키텍쳐는 어떻게 설계해야 할까? 클라우드? 간단한 시스템 디자인을 알아 보자

취직을 했으면 자사 서비스가 전반적으로 어떻게 돌아가는지, 하지 못했으면 웹 서비스가 전체적으로 어떻게 설계되어 제공되는지 궁금했을 것임. 단순히 서버 하나 띄워서 CRUD한다고 Production-level 서비스를 제공한다는 건 얼토당토 없는 소리임. API Gateway, Proxy, Load Balancing 등 기초적인 시스템 디자인과 AWS 같은 클라우드 플랫폼이 auto-scaling 같이 어떻게 활용되는지 다루겠음.