JAVASCRIPT01

해당 포스팅은 링크된 웹사이트를 보고 이해한 내용을 정리합니다.

프로그래밍

사람과 사람이 대화를 하기 위해서는 통하는 말, 그러니까 언어가 있어야 하잖아요? 컴퓨터와 사람 사이의 대화에도 언어가 당연히 필요해요.

0과 1 밖에 모르는 친구에게 내가 원하는 문제(요구사항)를 해결하도록 만들기 위해서 필요한 것을 "프로그래밍 언어"라고 하고 이를 하기 위한 과정을 프로그래밍이라 하기로 했어요.

 

그러면 프로그래밍은 도대체 어떻게 하는 걸까요?

그걸 알기 위해서는 컴퓨터는 어떻게 문제를 받아들이고, 사람은 또 어떻게 문제를 받아들이는지 알아야 해요.

 

쉬운 예시를 들어봅시다.

사람이 말하는 "소리 좀 키워줘~"에서 우리는 경험으로 소리를 얼만큼 올려야 할 지 알아요.

그런데 컴퓨터는 아직 잘 모릅니다. 소리를 키워? 어떻게? 그걸 명확하게 알려줘야 해요.

요리할 때처럼 대충 한 꼬집 넣어서 색 이쁘면 돼~ 같은 바이브는 안 통한다는 거죠.

 

그래서 컴퓨터에게 말할 때에는 "소리를 1단계만큼 올려줘/내려줘." 혹은 "볼륨을 60에 맞춰줘." 와 같이 명확하게 요구사항을 말해야 해요.

 

이런 흐름을 만드는 사고를 바로 Computational thinking이라고 해요.

컴퓨터의 입장에서 알아들을 수 있도록 설명하는 거죠.

 

복잡하고 애매할 수 있는 사람의 말로 문제를 해결해달라고 컴퓨터에게 말할 때에는 그래서 다음과 같은 단계가 필요해요.

1. 문제 이해

2. 복잡한 문제 단순화

3. 자료 정리/구분

4. 순서에 맞게 행위 배열

ex) 걷다.

걷기 위해서는 오른발/왼발이 필요하고

오른발과 왼발 중 어떤 것을 먼저 뻗을 지 선택해야 하고

어떤 경우에 발을 뻗고, 뻗지 않을지 등을 명확히 수치화 해서 정의해야 한다.

 

프로그래밍 언어

위와 같이 프로그래밍한 것을 이제 컴퓨터에게 컴퓨터의 언어로 말해주어야 컴퓨터도 명령을 수행할 수 있겠죠?

컴퓨터가 쓰는 언어를 Machine Code 즉, 기계어라고 해요.

하지만 기계어는 사람이 사용하기에는 너무 어려운 말이라 우리는 번역기를 사용해야 합니다.

 

우리 다른 나라 사람과 대화할 때에도 번역기를 사용하잖아요.

그때 번역하고 싶은 말이 명확하게 번역될 수 있도록 하려면, 해당 언어와 비슷한 문자 체계를 갖도록 입력합니다.

"밥 먹었는지 궁금해." 라는 말을 번역기를 돌리기 전에, "궁금해, 먹었는지 밥을." 이라고 입력하는 것처럼요.

 

컴퓨터와 소통하기 위해 번역기를 돌릴 때에도 마찬가지입니다.

약속된 Syntax 문법으로 구성된 프로그래밍 언어를 사용해 프로그램을 작성해서 번역기를 사용해 기계어로 바꿔주는 거죠.

이 작업을 해주는 번역기를 우리는 Compiler 혹은 Interpreter라고 불러요.

 

자연어와 인공어(프로그래밍 언어)가 소통하는 감동적인 순간이지요.

 

자, 그러면 이제 어떻게 소통하는지를 알았어요.

그런데 아직 프로그래밍 언어에 대해서 잘 모르고 있죠. 그러니 우리는 프로그래밍 언어에 대해 좀 더 공부해봅시다.

프로그래밍 언어는 Syntax(구문) + Semantics(의미) 로 표현돼요.

 

Syntax & Semantics

영어를 배울 때, 우리 문법도 배우지만, 문법을 어느 정도 숙지하게 되면 단어 외우는 것, 다양한 표현을 익히는 것에 집중하잖아요?

왜 그러나요? 문맥에 맞는 문장임을 알기 위해서죠.

그것처럼 프로그래밍 언어도 언어이기 때문에 이 과정이 필요해요.

 

문법에 맞는다고 모든 문장이 의미를 제대로 전달하는 문장이 되지 않는 것처럼 프로그래밍 언어에도 의미가 있기 때문에 문제를 해결하는 방안을 잘 설계했다고 하더라도 문법과 의미에 맞는 구현을 하지 못한다면 컴퓨터와 소통할 수 없어요.

 

기본 개념과 동작 원리 이해의 중요성

우스갯소리로 개발자는 복사+붙여넣기하는 직업이라고들 하잖아요.

사실 이것도 이 모두를 정확히 이해해야 가능한 일이랍니다.

우리 영어만 해도 그래요. 알아야 맞는 문장을 가져와서 글을 만들잖아요.

 

우리는 혼자 일하는 사람들이 아니기 때문에 내가 만들어낸 코드가 무엇을 위한 것이고 어떻게 돌아가는 것인지를 알아야 함께 일하는 사람들에게도 설명할 수 있고, 후에 유지/보수 할 때에도 적은 비용을 들일 수 있어요.

 

또 복사+붙여넣기 한 코드에도 나와 같은 환경이 아니기에 발생하는 많은 에러들의 원인을 이해하고 디버깅 할 수 있어요.

 

자바스크립트 탄생

정적인 HTML을 동적으로 표현하기 위해 Brendan Eich가 개발

Mocha -> LiveScript -> JavaScript

지금은 현재 모든 브라우저의 표준 프로그래밍 언어지만, 과거에는 파생 버전인 JScript의 출시로 위기 직면

자바스크립트의 파편화와 표준화

JScript와 JavaScript = 표준화 X, 적당히 호환 O

자사 브라우저의 시장 점유율을 점유하기 위해 자사 브라우저에만 동작하는 기능 추가

=> 브라우저에 따라 웹 페이지가 정상 동작하지 않는 크로스 브라우징 이슈 발생 = 모든 브라우저에서 동작하는 웹 페이지 개발이 어려워짐

=> JavaScript가 모든 웹 페이지에서 정상 동작하도록 표준화된 자바스크립트의 중요성 제기

 

1997년 7월, ECMAScript로 명명된 표준화된 자바스크립트 등장

 

ECMAScript 버전별 특징

ES1	1997	초판
ES2	1998	ISO/IEC 16262 국제 표준과 동일한 규격을 적용
ES3	1999	정규 표현식, try…catch 예외 처리
ES5	2009	HTML5와 함께 출현한 표준안. JSON, strict mode, 접근자 프로퍼티(getter, setter), 향상된 배열 조작 기능(forEach, map, filter, reduce, some, every)
ES6 (ECMAScript 2015)	2015	let, const, class, 화살표 함수, 템플릿 리터럴, 디스트럭처링 할당, spread 문법, rest 파라미터, Symbol, Promise, Map/Set, iterator/generator, module import/export
ES7 (ECMAScript 2016)	2016	지수(**) 연산자, Array.prototype.includes, String.prototype.includes
ES8 (ECMAScript 2017)	2017	async/await, Object 정적 메소드(Object.values, Object.entries, Object.getOwnPropertyDescriptors)
ES9 (ECMAScript 2018)	2018	Object Rest/Spread 프로퍼티

 

자바스크립트 성장의 역사

- 초창기 자바스크립트 : HTML과 CSS 단순 랜더링 수준의 웹 페이지의 보조적 기능 수행(= 한정적)

화면이 전환되면 서버로부터 새로운 HTML을 전송 받아 웹 페이지 전체를 처음부터 다시 렌더링

변경이 없는 부분까지 포함된 HTML을 서버로부터 다시 전송 받기 때문에 불필요한 데이터 통신이 발생하고, 변경이 없는 부분까지 처음부터 다시 렌더링해야 하기 때문에 퍼포먼스 측면에서도 불리

 

- 1999년 : 비동기적으로 서버와 브라우저가 데이터 교환할 수 있는 통신 기능인 Ajax(Asynchronous JavaScript and XML) 가 XMLHttpRequest이라는 이름으로 등장

웹 페이지의 변경이 필요 없는 부분은 다시 렌더링하지 않고, 서버로부터 필요한 데이터만을 전송 받아 변경이 필요한 부분만을 한정적으로 렌더링

웹 브라우저에서도 데스크톱 애플리케이션과 유사한 빠른 퍼포먼스와 부드러운 화면 전환 가능

 

- 2005년 : 자바스크립트와 Ajax를 기반으로 동작하는 Google Maps에서 데스크톱 애플리케이션과 비교해 손색이 없을 정도의 퍼포먼스와 부드러운 화면 전환 효과 구현

 

- 2006년 : jQuery의 등장

DOM(Document Object Model)을 보다 쉽게 제어, 크로스 브라우징 이슈 일부 해결

V8 자바스크립트 엔진의 등장

자바스크립트는 데스크톱 애플리케이션과 유사한 사용자 경험(user experience)을 제공할 수 있는 웹 애플리케이션 개발 프로그래밍 언어로 정착

 

- 2009년 : Node.js의 등장

브라우저 이외의 환경(서버 사이드 애플리케이션 개발)에서 동작 가능 = 프론트엔드 + 백엔드 영역 섭렵

 

=> 사용되는 범위가 넓어지며 개발 규모와 복잡도가 더불어 상승

필요에 따른 많은 패턴/라이브러리 출현

 

=> 개발에 많은 도움을 주었지만 유연하면서 확장이 쉬운 애플리케이션 아키텍처 구축을 어렵게 하였고 필연적으로 프레임워크 등장

 

=> SPA(Single Page Application) 대중화

Angular, React, Vue.js 등 다양한 SPA 프레임워크/라이브러리 또한 많은 사용층을 확보

 

💡 용어 정리

- 동기적 Vs 비동기적 : 실행 순서
동기적 방식: 요청을 보낸 후, 응답을 받아야 다음 동작을 실행
비동기적 방식: 요청을 보낸 후, 응답과는 관계없이 다음 동작을 실행

- SPA Vs MPA : 페이지 수
SPA: 하나의 페이지로 이루어진 웹
MPA: 여러 개의 페이지로 이루어진 웹
* 초기 화면이 뜰 때는 MPA가 빠르지만, 한 번 페이지를 띄우고 나면 SPA가 빠르다.

 

JavaScript와 ECMAScript

JavaScript	ECMAScript
일반적인 프로그래밍 언어	자바스크립트의 표준 명세인 ECMA-262
기본 뼈대를 이루는 ECMAScript와 브라우저가 별도 지원하는 클라이언트 사이드 Web API	프로그래밍 언어의 타입, 값, 객체와 프로퍼티, 함수, 빌트인 객체 등 핵심 문법(core syntax)을 규정
DOM, BOM, Canvas, XMLHttpRequest, Fetch, requestAnimationFrame, SVG, Web Storage, Web Component, Web worker 등	각 브라우저 제조사는 ECMAScript를 준수하여 브라우저에 내장되는 자바스크립트 엔진 구현

* 클라이언트 사이드 Web API는 ECMAScript와는 별도로 World Wide Web Consortium (W3C)에서 별도의 명세로 관리

 

자바스크립트의 특징

1. 웹 브라우저에서 동작하는 유일한 프로그래밍 언어

기존의 프로그래밍 언어에서 많은 영향을 받음

- 기본 문법은 C, Java

- 프로토타입 기반 상속은 Self

- 일급 함수의 개념은 Scheme

 

2. 인터프리터 언어: 개발자가 별도의 컴파일 작업 수행 X

인터프리터는 소스코드를 즉시 실행하고 컴파일러는 빠르게 동작하는 머신 코드를 생성하고 최적화

인터프리터와 컴파일러의 장점을 결합해 비교적 처리 속도가 느린 인터프리터의 단점 해결

 

3. 멀티 패러다임 프로그래밍 언어

 명령형(imperative), 함수형(functional), 프로토타입 기반(prototype-based) 객체지향 프로그래밍 지원

 

4. 프로토타입 기반의 객체지향 언어

클래스(ES6 새롭게 도입), 상속, 정보 은닉을 위한 키워드 private가 없어서 객체지향 언어가 아니란 오해 O

💡 용어 정리

- 명령형(Imperative Programming)
"어떻게(How)"에 초점을 두는 프로그래밍
명시적으로 배열을 반복하거나 원하는 기능을 수행하는 방법에 대한 단계 설명
순차적인 작동 방식으로 유지/보수 힘듦

- 함수형(Functional Programming)
"무엇을(What)"에 초점을 두는 프로그래밍
거의 모든 것을 순수 함수로 나누어 문제를 해결
가독성을 높이고 유지/보수 용이

- 프로토타입 기반(Prototype-based Programming)
속성과 매서드를 다른 클래스의 인스턴스에 추가하거나 빈 객체에 추가해 참조하는 프로그래밍
어떤 객체를 생성할 때, 객체의 클래스를 정의하지 않는 것을 허용

ES6 브라우저 지원 현황

Internet Explorer를 제외한 모던 브라우저의 ES6 지원 비율은 96~ 99%로 거의 100%에 육박하지만 Internet Explorer나 구형 브라우저는 ES6를 대부분 지원 X

= Internet Explorer나 구형 브라우저를 고려해야 하는 상황이라면 babel과 같은 트랜스파일러를 사용하여 ES6로 구현한 소스코드를 ES5 이하의 버전으로 다운그레이드할 필요 O

ES6에서 도입된 모듈 import/export는 아직 대부분의 브라우저가 지원 X = 프로젝트에서 모듈을 도입하려면 Webpack과 같은 모듈 번들러 사용

 

자바스크립트 개발 환경과 실행 방법

브라우저 : HTML, CSS, 자바스크립트를 실행하여 웹 페이지를 화면에 렌더링하는 것이 주된 목적

Node.js : 서버 개발 환경을 제공하는 것이 주된 목적

= 브라우저와 Node.js 모두 자바스크립트의 코어인 ECMAScript를 실행 O

그러나, 브라우저와 Node.js에서 ECMAScript 이외에 추가적으로 제공하는 기능은 호환 X

ex) 브라우저는 HTML 요소를 선택하거나 조작하는 기능들의 집합인 DOM API를 기본적으로 제공

하지만, 서버 개발 환경을 제공하는 것이 주 목적인 Node.js는 클라이언트 사이드 Web API인 DOM API를 제공 X = 서버에서 HTML 사용할 일이 X기 때문

 

반대로 Node.js에서는 파일을 생성하고 수정할 수 있는 File 시스템을 기본 제공하지만 브라우저는 이를 지원 X

= 브라우저는 사용자 컴퓨터에서 동작, 브라우저를 통해 사용자 컴퓨터에 파일을 생성하거나 기존 로컬 파일을 수정할 수 있다면 사용자 컴퓨터는 악성 코드에 노출되기 쉽기 때문에 보안 상 이유로 금지

 

웹 브라우저

웹 브라우저 : 크롬

개발자 도구 : 브라우저에 기본 내장되어 있음

Windows	F12 또는 Ctrl + Shift + I
macOS	command ⌘ + option ⌥ + I

 

개발자 도구 내 콘솔 패널

Elements	로딩된 웹 페이지의 DOM과 CSS를 편집하여 렌더링된 뷰를 확인 가능 단, 편집한 내용이 저장 X 웹 페이지가 의도된 대로 렌더링되지 않았다면 이 패널을 확인
Console	로딩된 웹 페이지의 에러 확인이나 자바스크립트 소스코드에 포함시킨 console.log 메소드의 결과 확인
Sources	로딩된 웹 페이지의 자바스크립트 코드를 디버깅
Network	로딩된 웹 페이지에 관련한 네트워크 요청(request) 정보와 퍼포먼스를 확인
Application	웹 스토리지, 세션, 쿠키를 확인/관리

 

콘솔

Console(콘솔) 패널은 자바스크립트 코드에서 에러가 발생하여 애플리케이션이 정상적으로 동작하지 않을 때 가장 우선적으로 살펴보아야 할 곳

콘솔을 열어두지 않으면 에러가 발생했는지 조차 알 수 없는 경우가 있다.

 

자바스크립트 코드를 직접 입력해 결과를 확인할 수 있는 REPL(Read Eval Print Loop: 입력 수행 출력 반복) 환경으로 사용 가능

개발자 도구의 Console 패널을 클릭하면 프롬프트(>)가 깜박임

프롬프트에 자바스크립트 코드를 입력하면 다음 줄에 실행 결과 표시

Enter	다음 프롬프트로 이동
Shift + Enter	여러 줄로 이루어진 코드 실행

에러 발생 시, 에러 내용이 콘솔에 출력

 

사진은 참고한 블로그 내에서 임의로 실행해본 코드의 에러이니 사용법 정도로만 알고 가는 것이 좋겠다.

디버깅

"에러 발생 위치" 링크를 클릭하면 Sources 패널로 이동

에러 발생 위치에 보기 좋게 빨간 줄이 표시되고

그 위에 마우스를 올리면 에러 정보가 표현됨

에러가 발생한 코드 왼쪽의 라인 클릭해 break point(중단점)을 설정하고 다시 버튼 클릭하면 디버깅 모드로 전환

원인을 알아내고 소스코드로 돌아가 코드를 수정하면 에러 제거 완료!

 

콘솔과 디버깅에 대한 보다 자세한 내용은 구글의 Tools for Web Developers: 콘솔 사용과 Tools for Web Developers: Chrome DevTools에서 자바스크립트 디버깅 시작하기를 참고

 

Node.js

웹 브라우저에서 동작하는 간단한 웹 애플리케이션은 브라우저만으로도 개발 가능

하지만 규모가 커지면 React, jQuery와 같은 외부 라이브러리나 Babel, Webpack, ESlint 등 여러 가지 도구 사용 필요

이때 Node.js와 npm 필요

 

Node.js와 npm 소개

Node.js는 Chrome V8 자바스크립트 엔진으로 빌드된 자바스크립트 런타임 환경(Runtime Environment)
= 브라우저 이외의 환경에서 동작시킬 수 있는 자바스크립트 실행 환경

- 서버 사이드 애플리케이션 개발에 사용
- 프론트엔드 + 백엔드 영역 모두에서 사용
- 모듈, 파일 시스템, HTTP 등 빌트인 API 제공

- 데이터 실시간 처리하기 때문에 I/O가 자주 발생하는 SPA(Single Page Application)에 적합
- CPU 사용률이 높은 애플리케이션에는 권장 X

---

npm(node package manager)은 자바스크립트 패키지 매니저
Node.js에서 사용할 수 있는 모듈들을 패키지화하여 모아둔 저장소 역할과 패키지 설치 및 관리를 위한 CLI(Command line interface)를 제공

- 작성한 패키지를 공개
- 필요한 패키지를 검색해 재사용

 

브라우저 동작 원리

웹 애플리케이션의 자바스크립트는 브라우저에서 HTML, CSS와 함께 실행

따라서 브라우저 환경을 고려할 때 효율적인 프로그래밍이 가능

 

브라우저의 핵심 기능

: 사용자가 보고자하는 웹 페이지를 서버에 요청(Request)하고 서버의 응답(Response)을 받아 브라우저에 표시하는 것

1. 브라우저는 서버로부터 HTML, CSS, Javascript, 이미지 파일 등을 받음
2. HTML, CSS 파일은 렌더링 엔진의 HTML 파서와 CSS 파서에 의해 파싱(Parsing)되어 DOM, CSSOM 트리로 변환되고 렌더 트리로 결합
3. 렌더 트리를 기반으로 브라우저는 웹페이지를 표시

 

렌더링 엔진이 아닌 자바스크립트 엔진이 처리

HTML 파서는 script 태그를 만나면 자바스크립트 코드를 실행하기 위해 DOM 생성 프로세스를 중지하고 자바스크립트 엔진으로 제어 권한 넘김

제어 권한을 넘겨 받은 자바스크립트 엔진은 script 태그 내의 자바스크립트 코드 또는 script 태그의 src 어트리뷰트에 정의된 자바스크립트 파일을 로드하고 파싱하여 실행

자바스크립트의 실행이 완료되면 다시 HTML 파서로 제어 권한을 넘겨서 브라우저가 중지했던 시점부터 DOM 생성을 재개

 

브라우저는 동기(Synchronous)적으로 HTML, CSS, Javascript을 처리

= script 태그의 위치에 따라 블로킹이 발생하여 DOM의 생성이 지연될 수 있다는 것

=> script 태그의 위치 중요

 

body 요소의 가장 아래에 자바스크립트를 위치시키는 이유

- HTML 요소들이 스크립트 로딩 지연으로 인해 렌더링에 지장 받는 일이 발생하지 않아 페이지 로딩 시간이 단축된다.
- DOM이 완성되지 않은 상태에서 자바스크립트가 DOM을 조작한다면 에러가 발생한다.