그냥 갑자기 생각나서 끄적여보는 다양한 모음집

의식의 흐름대로 작성하는 모든 링크 총 집합

생각나거나 내키는대로 바로바로 업데이트 예정이며, 당장 사용하기 위함

1. 노동요 🎶

유튜브를 풀로 틀어놓고 작업을 하기 때문에 마음에 드는 유튜버나 노래 모음 영상 링크 모음

1-1. 해외

특정한 가수, 아예 인기 음악 모음 등 다양하게 종류별로 모아놓은 걸 정리한 것

노래 모음

• 해외노래 Playlist

가수 모음

• 해외가수 Playlist

• Jagwar Twin

  • Jagwar Twin Playlist

OST 모음

• 해외 OST Playlist

1-2. 국내

사실 국내는 노래 모음보다는 가수 모음을 주로 노동요로 사용

가수 모음

• 국내가수 Playlist

• LEGIT GOONS (리짓군즈)

  • LEGIT GOONS (리짓군즈) Playlist

1-3. 기타

장르, 국적 불문 거의 다 모여있다고 생각되는 플레이리스트를 정리

주다사 플레이리스트

• 주다사 플레이리스트

2. 노동용 💻

유튜브 들어가서 직접 플레이리스트를 들어가는 것이 귀찮아서 만드는 프로젝트 모음집

2-1. 공부용 리스트

실제로 프로젝트 진행을 하면서 공부할 수 있는 것들을 모아둔 나의 코딩 공부 모음집

유튜브 플레이리스트

• 코딩 공부 (by.한형진)

• 머신러닝/딥러닝 강의

기타 무료 인강

• Flutter 로 웹툰 앱 만들기

• 바닐라 JS로 크롬 앱 만들기

• GraphQL로 영화 API 만들기

• NestJS로 API 만들기

2-2. 실제로 자주 사용

여기는 거의 항상 접속하는 그런 공간 (아마 나만 입장이 가능한 링크가 많을 듯)

개인 링크

• 타인 입장 ⭕

  • GitHub

  • 포트폴리오 사이트

• 타인 입장 ❌

  • Notion

  • Figma

  • Sanity

  • Vercel Dashboard

  • Firebase

  • Thirdweb 대시보드

유용한 링크

• Simple Icons

• unDraw - 무료 svg 사이트

• React Icons - react-icons 라이브러리용 아이콘 사이트

• Tailwind CSS 공식 사이트 - 생각보다 많이 헷갈리는 부분 때문

• Adobe Express (영상, 이미지 편집)

• 개인 Logo 제작 사이트

위의 사진과 같이 웹의 구조를 간단하게 설명하자면,

• HTML : 웹 페이지의 구조를 만들어준다. (마크업 언어)

• CSS : 웹 페이지에 디자인을 입혀준다. (스타일 규칙 언어)

• JavaScript : 웹 페이지가 동적으로 움직이도록 만들어준다 (스크립트 언어)

이렇게 설명할 수 있다.

여기서 JavaScript가 무엇인지 알아보는 시간을 갖도록 한다.

2. JavaScript는 무엇인가?

JavaScript는 웹을 위한 인터프리터 언어이자 객체 기반의 스크립트 프로그래밍 언어이며, HTML의 특정 요소(들)을 선택하여 다양한 이벤트(마우스 클릭, 키보드 입력 등)에 따라 어떤 동작을 하도록 기능을 넣을 수 있다.

발생하는 이벤트에 따라 HTML, CSS를 조작할 수도 있고 그 외에도 여러가지의 기능을 구현할 수 있다.

2-1. JavaScript의 역사

JavaScript는 1995년에 넷스케이프(Netscape)의 브렌던 아이크(Brendan Eich)에 의해 만들어졌다.

처음에는 모카(Mocha)라는 이름으로 개발되었으나, 그 후에 라이브스크립트(LiveScript), 최종적으로는 자바스크립트(JavaScript)라는 이름으로 변경된다.

3. JavaScript 실행 순서

일반적으로 JavaScript는 위에서 아래의 순서대로 실행이 된다.

이는 순서에 주의해서 코드를 작성해야 한다는 의미이다.

단, Hoisting으로 인한 예외의 경우가 발생할 수 있다.

3-1. JavaScript 엔진

브라우저에는 JavaScript 가상 시스템이라는 내장 엔진이 존재한다.

• Chrome, Opera -> V8

• Firefox -> SpiderMonky

• IE -> Trident 및 Chakar

• Microsoft Edge -> ChakraCore

• Safari -> Nitro 및 SquirrelFish

3-1-1. JavaScript 가상 시스템 엔진의 작동 방법

1. 엔진이 스크립트를 읽음

2. 스크립트를 기계어로 변환

3. 코드를 빠르게 실행

순서로 작동한다.

4. JavaScript의 특징

JavaScript는 객체 기반의 스크립트 언어이며, 객체 지향형 프로그래밍과 함수형 프로그래밍을 모두 표현할 수 있다.

또한 JavaScript는 동적이며, 타입을 명시할 필요가 없는 인터프리터 언어이다.

이로 인해 발생할 수 있는 문제를 보완하기 위해 나온 것이 TypeScript이다.

4-1. JavaScript의 장단점

4-1-1. JavaScript의 장점

• 컴파일 과정이 필요없으므로, 빠른 시간 안에 스크립트 코드를 작성할 수 있다.

• 다른 언어들에 비해 단순한 구조와 원칙을 갖고 있어 배우기 쉽다.

• 웹에 특화된 기술이기 때문에 운영체제나 플랫폼에 상관없이 잘 작동되고 확장성이 높다.

4-1-2. JavaScript의 단점

• OS에 직접 접근이 불가능하다.

• 하드디스크를 읽거나 쓸 수 없다.

• 다른 프로그램을 호출할 수 없다.

• JavaScript는 도메인이 동일한 두 탭/윈도우를 제외하고 탭/윈도우 간에 통신을 수횅할 수 있다.

• JavaScript는 웹 브라우저에서 실행되기 때문에 일부 보안상의 제약이 있으며, 브라우저에서 웹 페이지를 열 때 안전하고 위험에 처하지 않도록 보장해야 한다.

• 일반적으로 JavaScript는 자체 도메인에 대해서만 제한없이 네트워크 요청을 보낼 수 있다.

5. JavaScript의 역할

JavaScript의 일반적인 용도는 웹 페이지에 기능을 더하여 HTML 페이지를 동적으로 만들어주는 역할을 한다.

5-1. JavaScript가 할 수 있는 일

• HTML 페이지 변경 및 HTML 엘리먼트와 콘텐츠의 추가나 제거

• CSS 및 HTML 엘리먼트의 스타일 변경

• 사용자와의 상호작용, 폼의 유효성 검증

• 마우스와 키보드 이벤트에 대한 스크립트 실행

• 웹 브라우저 제어, 쿠키 등의 설정과 조회

• AJAX 기술을 이용한 웹 서버와의 통신

6. Java vs JavaScript

이름으로는 서로 관련이 있는 언어로 생각하기 쉽지만, 사실상 두 언어는 서로 직접적인 관련이 전혀 없다.

문법상의 비슷한 부분이 존재하지만, 그 이유는 두 언어의 문법이 모두 C언어를 기반으로 만들어졌기 때문이다.

7. JavaScript 표준

1996년에 넷스케이프(Netscape)는 JavaScript를 국제 표준안으로 만들기 위해 ECMA(European Computer Manufacturers Association)에 제출한다.

그 결과, ECMA는 ECMAScript라는 새로운 표준을 제정하였고, 그 첫 번째 버전인 ECMA-262를 1997년에 공표한다.

ECMAScript는 자바스크립트뿐만 아니라 마이크로소프트의 JScript나 어도비의 액션스크립트도 따르는 국제 표준이 된다.

현재 JavaScript 최신 표준은 2019년에 발표된 ECMAScript 2019(EX2019)이다.

참고 사이트

surim's develog - 웹을 움직이는 근육, JavaScript란 무엇인가? 위키백과 - ECMA스크립트 Dev and Dev - 자바스크립트란?

실행 컨텍스트는 실행할 코드에 제공할 환경 정보들을 모아놓은 객체이다.

JavaScript는 동일한 환경에 있는 환경 정보들을 모은 실행 컨텍스트를 콜스택에 쌓아올린 후 실행하여 코드의 환경과 순서를 보장할 수 있게 된다.

즉, 스택(Stack)의 경우, FILO(First In, Last Out)의 구조이기에 순서를 보장하며, 콜스택 내부에 쌓인 실행 컨텍스트의 정보를 통해 환경을 보장할 수 있는 것이다.

위에서 말한 환경이란 전역 공간이 될 수 있고, 함수 내부의 환경이 될 수도 있다.

var temp = "temp";

function b() {
  console.log("Hello, World");
}

function a() {
  b();
}

a(); // Hello, World

위의 예시와 그림을 참고하면,

1. 콜스택엔 전역 컨텍스트를 제외하고 다른 컨텍스트가 없기에 전역 컨텍스트와 관련된 코드를 진행한다.

2. 전역 컨텍스트와 관련된 코드를 진행 중, a 함수를 실행했기 때문에 a 함수의 환경 정보들을 수집하여 a 실행 컨텍스트를 생성하고 콜스택에 담으며, 콜스택 최상단에 a 실행 컨텍스트가 있기 때문에 기존의 전역 컨텍스트와 관련된 코드의 실행을 일시적으로 중단한 후, a 실행 컨텍스트의 코드를 실행한다.

3. a 함수 내부에서 b 함수를 실행하였기 때문에 b 함수의 환경 정보들을 수집하여 실행 컨텍스트를 생성하고, 콜스택에 담으며, 이전과 똑같이 콜스택 최상단에 b 실행 컨텍스트가 있기 때문에 기존 a 실행 컨텍스트와 관련된 코드의 실행을 일시적으로 중단한다.

4. b 함수가 종료된 후, b 실행 컨텍스트가 콜스택에서 제거되고, 그 후 콜스택 최상단에는 a 실행 컨텍스트가 있기 때문에 이전에 중단된 지점부터 코드 진행이 재개된다.

5. a 함수 또한 종료된 후 실행 컨텍스트가 콜스택에서 제거되며, 이후에는 전역 공간에 실행할 코드가 남아있지 않다면 콜스택에서 전역 컨텍스트 또한 제거되며 콜스택에 아무것도 남지 않은 상태로 종료된다.

위의 단계로 JavaScript 코드가 진행된다.

2. 실행 컨텍스트 내의 정보

실행 컨텍스트 내부에는 variable environment, lexical environment, this binding이 있다.

2-1. VariableEnvironment

VariableEnvironment란 현재 컨텍스트 내부의 식별자 정보 environmentRecord, 외부 환경 정보 outerEnvironmentReference가 포함되어 있다.

VariableEnvironment에 먼저 정보를 담고, 그대로 LexicalEnvironment에 복사해 사용한다고 한다.

2-2. LexicalEnvironment

LexicalEnvironment는 초기에는 VariableEnvironment와 같지만 변경 사항이 실시간으로 적용된다.

즉, VariableEnvironment 초기 상태를 기억하고 있으며, LexicalEnvironment 최신 상태를 저장하고 있다.

2-2-1. environmentRecord

environmentRecord란 현재 컨텍스트와 관련된 식별자와 식별자에 바인딩된 값이 기록되는 공간이다.

더불어 실행 컨텍스트 내부 전체를 처음부터 끝까지 확인하며 순서대로 수집한다.

var hhj = "HyungJin Han";

console.log(hhj); // HyungJin Han

console.log(hhj); // undefined

var hhj = "HyungJin Han";

위의 예시를 보면, 첫 코드 예시의 경우 문제없이 작동되나, 두 번째 예시의 경우 선언하기도 전에 값을 호출했지만, Reference error가 발생하지 않고, undefined가 출력된다.

위의 현상은 JavaScript의 호이스팅이라는 현상과 관련있다.

호이스팅에 관련된 포스팅은 이전에 올렸던 포스팅을 보며 재차 공부할 예정이다.

LexicalEnvironment의 environmentRecord의 경우 해당 컨텍스트 환경에 필요한 식별자와 식별자의 값이 기록되며, 함수 실행 시 실행 컨텍스트가 생성되므로(함수 실행보다 environmentRecord 수집이 먼저 되므로) 변수와 같은 식별자를 끌어올리는 것과 같다는 개념의 호이스팅이 생겨났다.

2-2-2. outerEnvironmentReference

const greeding = "Hello, World";

const info = () => {
  const hhj = {
    age: 28,
    name: "HyungJin Han",
  };
  const jhh = {
    age: 23,
    breed: "HyungHan Jin",
  };
  console.log(greeding);
  console.log(hhj);
  console.log(jhh);
};
info(); // Hello, World { age: 28, name: 'HyungJin Han' } { age: 23, breed: 'HyungHan Jin' }
console.log(hhj); // ReferenceError: hhj is not defined
console.log(jhh); // ReferenceError: jhh is not defined

위의 예시를 보면, 해당 코드의 함수 내부에서는 외부의 greeding이 접근 가능하며, 내부에서 선언한 hhj와 jhh 또한 접근이 가능하다.

하지만 외부에서는 내부에 선언된 hhj와 jhh에 접근할 수 없다.

그 이유는 outerEnvironmentReference 때문이다.

outerEnvironmentReference란 현재 호출된 함수가 선언될 당시의 LexicalEnvironment를 참조하게 된다.

여기서 선언될 당시를 집중해야 하는데, info 함수가 선언될 당시의 outerEnvironmentReference는 글로벌 실행 컨텍스트의 LexicalEnvironment를 참조하고 있으며, 해당 환경의 environmentRecord에 greeding과 같은 변수의 정보들이 기록되어 있게 된다.

그렇기에 함수 내부에서는 outerEnvironmentReference를 통해 상위 컨텍스트의 LexicalEnvironment에 접근하여 environmentRecord에서 변수인 greeding을 사용할 수 있게 되는 것이다.

또한 outerEnvironmentReference는 오직 자신이 선언될 당시의 LexicalEnvironment를 참조하기 때문에 순차적으로만 접근이 가능하며, 여러 스코프에서 동일한 식별자를 생성하였다고 하더라도 가장 먼저 발견된 식별자만 접근이 가능하다.

const a = "a";
const b = "b";

const sayHi = () => {
  const a = "aa";
  console.log(a); // aa
  console.log(b); // b
};

sayHi();

위의 코드 예제를 보면, a라는 변수는 현재 컨텍스트의 LexicalEnvironment => environmentRecord에 a라는 식별자가 있고, outerEnvironmentReference => LexicalEnvironment => environmentRecord에도 a 식별자가 있지만, 가장 먼저 발견된(가까운) 식별자에 바인딩 된 값인 aa를 출력한다.

결국 전역 컨텍스트에서 선언한 a의 경우 변수 은닉화가 된다.

b 변수는 현재 컨텍스트의 LexicalEnvironment => environmentRecord 에 b 라는 식별자가 있으므로, outerEnvironmentReference 참조하여 전역 컨텍스트의 LexicalEnvironment 참조, environmentRecord 의 b 식별자에 접근하여 b를 출력한다.

결론적으로 outerEnvironmentReference란 해당 함수가 선언된 위치의 LexicalEnvironment를 참조하며, 변수에 접근을 한다면 해당 LexicalEnvironment에서 발견된다면 사용, 찾지 못할 경우 다시 outerEnvironmentReference를 참조하여 탐색하는 과정을 반복한다.

이러한 과정을 스코프 체인 이라고 하며 outerEnvironmentReference 는 스코프 체인을 가능하게 하는 역할이다.

2-3. ThisBinding

우선 this 는 컨텍스트를 가르킨다.

method에서 사용시 해당 method가 담겨있는 instance or object를 가르키며, 함수표현식에서 사용시 this 를 바인딩하지 않는 이상 전역 객체를 가르킨다.

더불어 전역 공간에서 this는 함수 표현식과 같이 전역 객체를 가르킨다.

ES6의 화살표 함수를 사용하면 this 바인딩, 우회법으로 변수에 this를 담아 실행할 필요 없이 함수를 실행한 컨텍스트를 바라본다.

const obj = {
  outer: function () {
    console.log(this); // { outer: [Function: outer] }
    // 메소드에서 사용되었기에 obj 출력
    function inner() {
      console.log(this); // Object [global] {...}
      // 함수 표현식에서 사용되었기에 전역 객체 출력
    }
    inner();

    const self = this;
    function inner2() {
      console.log(self); // { outer: [Function: outer] }
      // 우회하기 위해 this를 self에 할당, 출력했기에 obj 출력
    }
    inner2();

    const inner3 = () => {
      console.log(this); // { outer: [Function: outer] }
      // 화살표함수 사용으로 this는 상위 스코프의 컨텍스트를 가르킴, obj 출력
    };
    inner3();
  },
};

obj.outer();

요약하자면, this는 실행 컨텍스트 생성 시, 즉, 함수를 실행할 때 할당해주는 것으로 상황에 따라 전역 객체 또는 instance를 카르킨다.

3. 결론

위에서 설명했듯이, 실행 컨텍스트는 VariableEnvironment, LexicalEnvironment, environmentRecord, outerEnvironmentReference, hisBinding 등의 여러 정보들이 합쳐져 실행 컨텍스트가 되고, 이것이 콜스택에 쌓여 JavaScript의 코드가 실행된다.

참고 사이트

감구마- JS Execution Context (실행 컨텍스트) 란? 천천히 꾸준하게 - [javascript 자바스크립트] 실행 컨텍스트(Execution Context) 란?

웹 표준(Web Standards)이란?

"웹에서 표준적으로 사용되는 기술이나 규칙"으로 표준화 단체인 W3C가 권고한 표준안에 따라 웹 사이트를 작성할 때 이용하는 HTML, CSS, JavaScript 등에 규정이 담겨있다.

즉, 어떤 운영체제나 브라우저를 사용하더라도 웹페이지가 동일하게 보이고 정상 작동해야함을 의미하며, 표준 스펙을 잘 지키는 것 뿐만 아니라 구조적 마크업(XHTML)과 표현 및 레이아웃(CSS) 및 사용자 행위 제어(DOMScripting)를 잘 분리하는 고급 홈페이지 구축하는 방식을 말한다.

CSS 와 HTML(XHTML)로 웹 문서를 작성하는 것의 명확한 용어는 권고(Recommend)라고 하며 버전과 상관없이 HTML, XHTML은 그 자체로 표준이라고 한다.

가이드 라인 참조

W3C - STANDARDS

1-1. 웹 표준이 중요한 이유

현재 인터넷의 사용량이 급증하고 있으며, 앞으로도 꾸준히 증가할 것으로, 이에 따라 표준화는 개발자로써 반드시 해결해야 할 과제이다.

웹 표준이 없던 1990년대 말부터 2000년대 초반에는 웹 사이트 개발자는 사실상 두 개의 사이트를 만들어야 했다. (익스플로러, 넷스케이프)

하지만 지금과 같은 표준이 있었다면, 해당하는 표준에 맞게끔 한 번만 작업을 진행해도 되며, 이에 따라 노동력과 시간을 아낄 수 있게 된다.

결국, 자연스럽게 정보 제공의 질도 올라가게 되므로, 현재 웹 개발자는 웹 표준에 따라 개발하는 것을 중요하게 생각하게 된다.

위의 이유로 인해 웹 표준을 지킬 시, 생길 수 있는 장점이 많다.

1-1-1. 웹 표준의 장점

• 소스의 통일화로 수정 및 운영관리가 용이하다.

• 다양한 브라우저, 휴대폰 PDA, 장애인 지원용 프로그램에서도 대응이 가능하므로, 접근성이 향상되고, 장애인, 고령자 등을 포함한 사용자 층도 확대가 가능하다.

• 논리적이고 효율적으로 작성된 웹 문서는 코드의 양이 줄어 파일의 크기가 줄고 서버 부담의 감소로 이어질 수 있다.

• CSS와 HTML이 분리되어 유지보수에 들어가는 시간이 단축되고, 불필요한 마크업이 최소화되어 페이지 로딩 속도가 향상된다.

• 오래된 브라우저에서도 컨텐츠가 적절하게 표시되고, 호환성과 운용성이 확보된다.

• 스크린 리더기 등 보조 공학 기기 사용자들이 조금 더 정확한 정보를 얻을 수 있도록 돕는다.

• 검색봇을 통한 효율적인 노출과 감튼 검색 엔진 최적화(SEO)가 가능하다.

1-2. 웹 표준의 기술

1. XHTML (eXtensible Hypertext Markup Language)

2. CSS (Cascading Style Sheets)

3. XML (eXtensible Markup Language)

4. DOM (Document Object Model)

5. ECMAScript

   • ECMA international 의 ECMA-262 기술 명세에 정의된 표준화 된 스크립트 프로그래밍 언어

2. 웹 접근성 (Web Accessibility)

웹 접근성이란?

모든 사용자가 신체적, 환경적 조건에 관계없이 웹에 접근하여 이용할 수 있도록 보장하는 것이다.

즉, 어떠한 사용자(일반인, 장애인, 고령자 등)가 어떠한 환경(브라우저, 운영체제, 디바이스의 환경이나 사양 등)에서도 어려움 없이 접근, 이용할 수 있는 것을 접근성이라고 한다.

W3C 정의에 따르면 웹 표준은 접근성, 사생활 보호, 보안, 국제화의 측면에서 고려해야 한다고 말한다.

위의 정의를 쉽게 정리하자면, 웹 접근성은 신체적 차이나 장애 여부와 상관없이 누구나 원활하게 웹페이지를 이용할 수 있어야 한다는 것을 의미 한다.

예를 들어, 시각 장애인의 경우 화면을 눈으로 볼 수 없기 때문에 "스크린 리더"라는 별도의 소프트웨어를 컴퓨터에 설치하여 음성으로 웹페이지에 담긴 정보를 이해 한다.

하지만 스크린 리더는 스스로 웹 페이지의 내용을 분석하지 못한다.

예를 들어 "로그인"이라는 텍스트 대신 메뉴라고 로그인 이미지를 사용할 경우 비시각 장애인의 눈에는 로그인 메뉴로 인식 가능하지만, 소프트웨어의 입장에서는 그저 이미지일 뿐이다.

따라서, 되도록이면 이미지 대신 소스코드에 내용을 그대로 담는 것이 권장되며, 부득이하게 이미지를 사용할 경우,

<img src="img/login.jpg" alt="로그인하기" />

위의 코드와 같이 반드시 이미지의 내용에 대한 설명을 추가해야 한다.

가이드 라인 참조

W3C Accessibility Standards Overview

2-1. 웹 콘텐츠 접근성 지침(WCAG)

2-1-1. 인지성 (Perceivable)

정보와 사용자 인터페이스 요소는 그들이 인지할 수 있도록 사용자에게 표시될 수 있어야 한다.

• 모든 텍스트가 아닌 콘텐츠에 대체 텍스트를 사람들이 원하는 인쇄, 점자, 음성, 기호 또는 간단한 언어 등과 같은 형태로 제공해야 한다.

• 시간을 바탕으로 한 미디어에 대한 대안을 제공해야 한다.

• 정보와 구조의 손실 없이 콘텐츠를 다른 방식(예를 들면 더욱 간단한 형태로)들로 표현할 수 있어야 한다.

• 사용자들이 보다 쉽게 보고 들을 수 있는 전경에서 배경을 분리한 콘텐츠를 만들어야 한다.

2-1-2. 운용성 (Operable)

사용자 인터페이스 요소와 탐색은 운용이 가능해야 한다.

• 키보드로 모든 기능을 사용할 수 있도록 해야 한다.

• 읽기 및 콘텐츠를 사용하는 사용자에게 충분한 시간을 제공해야 한다.

• 알려진 방법으로 발작을 일으킬 수 있는 콘텐츠를 디자인하지 않아야 한다.

• 사용자가 탐색하고, 콘텐츠를 찾고 그들이 어디에 위치하고 있는지를 알 수 있도록 도와주는 방법을 제공해야 한다.

2-1-3. 이해성 (Understandable)

정보와 사용자 인터페이스 운용은 이해할 수 있어야 한다.

• 텍스트 콘텐츠를 판독하고 이해할 수 있도록 만들어야 한다.

• 웹 페이지의 탑재와 운용을 예측 가능한 방법으로 제작해야 한다.

• 사용자의 실수를 방지하고 수정할 수 있도록 도와야 한다.

2-1-4. 내구성 (Robust)

콘텐츠는 보조 기술을 포함한 넓고 다양한 사용자 에이전트에 의존하여 해석될 수 있도록 충분히 내구성을 가져야 한다.

• 보조 기술을 포함한 현채 및 미래의 사용자 에이전트의 호환성을 극대화해야 한다.

2-2. 웹 접근성을 위해 사용되는 보조기기

• 자막

• 스크린 리더

• 자동완성 기능

• 마우스 스틱

• 색상 대비 디자인 등

3. 관련 용어 정리

• DTD(Document Type Definition)

  • 브라우저에 어떤 문서형 정의을 적용할 것인가를 선언하는 것

• Validator

  • 웹 문석가 표준안에 따라 만들어졌는지, 접근성에 대한 고려가 이루어졌는지에 대한 유효성을 검사해주는 도구

• Meta Data

  • 데이터를 위한 데이터로, 구조화된 정보를 분석/분류하고 부가적인 정보를 추가하기 위해 그 데이터와 함께 따라가는 정보

• Encoding

  • 문자들의 집합을 컴퓨터에서 저장하거나 통신에 사용할 목적으로 부호화하는 방법

• Semantic Web

  • 컴퓨터가 정보(웹 문서, 파일, 서비스 등) 사이에 연결되어 있는 의미를 컴퓨터가 이해하고 논리적인 추론까지 할 수 있는 지능형 웹

• Name Space

  • 서로 다른 XML 문서와 서로 인식할 수 있도록 태그로 나타내는 개념상의 공간

• MIME-TYPE (Multipurpose Internet Mail Extention Type)

  • 전송받은 멀티미디어 문서에 대해 클라이언트가 해당 Data를 어떻게 처리하는지 사전에 약속된 명칭

• Streaming

  • 인터넷에서 음성이나 영상, 애니메이션 등을 실시간으로 재생하는 기법

• Pointing Device

  • 컴퓨터 조작을 위해 표시 화면에 보이는 커서의 이동을 제어하는데 쓰이는 입력 장치

• 서버측 이미지 맵

  • img 요소에 ismap 속성을 사용하고 링크 영역의 좌표 정보가 서버에 있으며, 마우스와 같은 포인팅 기기로만 사용할 수 있으며, 키보드로 접근은 불가능

• 클라이언트측 이미지 맵

  • img 요소에 usemap 속성을 사용하고, 링크 영역의 좌표 정보가 HTML(클라이언트)에 존재하는 일반적으로 가장 많이 사용되는 이미지 맵

    클라이언트 측 이미지 맵의 경우 영역별로 대체 텍스트를 적절하게 제공해야 한다.

참고 사이트

갓대희의 작은공간 - 웹표준의 이해(웹 표준이란?) weebee design - 웹표준/웹접근성에 대한 요약

1-1. 웹의 동작 단계

위의 이미지를 참고하여 www.google.com을 입력했을 시, 어떻게 동작하는지 알아보면,

1-1-1. 사용자가 웹 브라우저 검색창에 www.google.com 입력

1-1-2. 웹 브라우저는 캐싱된 DNS 기록들을 통해 해당 도메인 주소와 대응하는 IP 주소를 확인

DNS란?

DNS (Domain Name System Servers)는 URL들의 이름과 IP 주소를 저장하고 있는 데이터베이스로, 웹사이트를 위한 주소록이라고 볼 수 있다.

숫자로 된 IP 주소(ex. 63.245.217.105) 대신 사용자가 사용하기 편리하도록 주소를 매핑해주는 역할을 한다.

• 이 단계에서 캐싱된 기록이 없을 경우, 다음 단계로 넘어간다.

1-1-3. 웹 브라우저가 HTTP를 사용하여 DNS에게 입력된 도메인 주소를 요청

1-1-4. DNS가 웹 브라우저에게 찾는 사이트의 IP 주소를 응답

• ISP(Internet Service Provider)의 DNS 서버가 호스팅하고 있는 서버의 IP 주소를 찾기 위해 DNS query를 날린다.

  DNS query의 목적

  DNS 서버들을 검색해서 해당 사이트의 IP 주소를 찾는데에 있다.

  IP 주소를 찾을 때까지 DNS 서버에서 다른 DNS 서버를 오가며 에러가 날때까지 반복적으로 검색한다. -> recursive search

• DNS recursor(ISP의 DNS 서버)는 name server들에게 물어 물어 올바른 IP 주소를 찾는데에 책임이 있으며, name server는 도메인 이름 구조에 기반해서 주소를 검색하게 된다. (아래의 그림 참고)

  정리하자면,

  www.google.com 주소에 대해 검색할 때

  1. DNS recursor가 root name server에 연락
  2. .com 도메인 name server로 리다이렉트
  3. google.com name server로 리다이렉트
  4. 최종적으로 DNS 기록에서 www.google.com 에 매칭되는 IP 주소 찾기
  5. 찾은 주소를 DNS recursor로 보내기

  위의 모든 요청들과 DNS recursor, IP 주소는 작은 데이터 패킷을 통해 보내지며, 원하는 DNS 기록을 가진 DNS 서버에 도달할 때까지 클라이언트와 서버를 여러번 오가는 과정을 거친다.

1-1-5. 웹 브라우저가 웹 서버에게 IP 주소를 이용하여 html 문서를 요청

• TCP로 연결이 되면, 브라우저는 GET 요청을 통해 서버에게 www.google.com의 웹 페이지를 요구한다.

  TCP/IP(Transmission Control Protocol / Internet Protocol)란?

  '전송제어규약'과 '인터넷규약'은 데이터가 어떻게 웹을 건너 여행하는지 정의하는 통신 규약이다.

  이를 사용하겠다는 것은, IP 주소 체계를 따르며 TCP의 특성을 활용해 송신자와 수신자의 논리적 연결을 생성하고 신뢰성을 유지할 수 있도록 하겠다는 의미이다.

  즉 송신자가 수신자에게 IP 주소를 사용해서 데이터를 전달하고 그 데이터가 제대로 갔는지에 대해 이야기하는 것이다.

1-1-6. 웹 애플리케이션 서버(WAS)와 데이터 베이스에서 우선 웹 페이지 작업을 처리

• 웹 서버 혼자서 모든 로직을 수행하고 데이터를 관리할 수 있다면 간단하겠지만, 그렇게 될 경우엔 서버에 과부하가 일어날 수 있다.

  그렇기 때문에 서버의 일을 돕는 조력자 역할을 하는 것이 웹 애플리케이션 서버(Web Application Server, WAS)이다.

  WAS(Web Application Server)란?

  WAS 는 사용자의 컴퓨터나 장치에 웹 애플리케이션을 수행해주는 미들웨어를 말한다.

  브라우저로부터 요청을 받으면, 웹 서버는 페이지의 로직이나 데이터 베이스(DB)의 연동을 위해 WAS에게 이들의 처리를 요청한다.

  그러면 WAS는 이 요청을 받아 동적인 페이지 처리를 담당하고, DB에서 필요한 데이터 정보를 받아서 파일을 생성한다.

  웹 서버와 웹 애플리케이션 서버(WAS)의 차이점

  • 웹 서버

  정적인 콘텐츠(HTML, CSS, Image 등)를 요청받아 처리

  • 웹 애플리케이션 서버(WAS)

  동적인 컨텐츠(JSP, ASP, PHP 등)를 요청받아 처리

  DB 서버에 대한 접속 정보가 있기 때문에 외부에 노출 될 경우 보안상의 문제를 이유로 웹 서버와의 연결을 통해 요청을 전달받음

  

1-1-7. 위의 작업처리 결과를 웹 서버로 전송

1-1-8. 웹 서버는 웹 브라우저에게 HTML 문서 결과를 응답

• response는 status code로 서버 요청에 따른 상태를 보내며, 총 5가지의 종류가 있다.

  

  1xx ▶️ 정보만 담긴 메세지 2xx ▶️ response 성공 (기분좋은 200 OK 해당) 3xx ▶️ 클라이언트를 다른 URL로 리다이렉트 4xx ▶️ 클라이언트 측에서 에러 발생 (자주보는 404 Error 해당) 5xx ▶️ 서버 측에서 에러 발생 (자주보는 505 Error 해당)

1-1-9. 웹 브라우저는 화면에 웹 페이지 내용물 출력

2. 웹의 동작 정리

1. 사용자가 웹 브라우저 검색창에 www.google.com 입력

2. 웹 브라우저는 캐싱된 DNS 기록들을 통해 해당 도메인 주소와 대응하는 IP 주소를 확인

3. 웹 브라우저가 HTTP를 사용하여 DNS에게 입력된 도메인 주소를 요청

4. DNS가 웹 브라우저에게 찾는 사이트의 IP 주소를 응답

5. 웹 브라우저가 웹 서버에게 IP 주소를 이용하여 html 문서를 요청

6. 웹 애플리케이션 서버(WAS)와 데이터 베이스에서 우선 웹 페이지 작업을 처리

7. 위의 작업처리 결과를 웹 서버로 전송

8. 웹 서버는 웹 브라우저에게 HTML 문서 결과를 응답

9. 웹 브라우저는 화면에 웹 페이지 내용물 출력

3. 브라우저 렌더링 과정

▲ 이미지 클릭으로 해당 포스트로 가기 ▲

이후로는 브라우저 렌더링 과정을 통해 사용자에게 www.google.com 주고에 맞는 화면을 출력하게 된다.

브라우저 렌더링 과정은 따로 포스팅한 내용을 추가적으로 읽어보며 공부할 예정이다.

참고 사이트

eassy.log - 'www.google.com'을 주소창에서 입력하면 일어나는 일 billy - 주소창에 www.google.com을 입력했을 때 일어나는 과정

유효범위(Scope)는 JavaScript 뿐만 아니라 모든 프로그래밍 언어에서 가장 기본적인 개념 중 하나로 반드시 알고 넘어가야 한다.

하지만 JavaScript의 유효범위는 다른 언어의 유효범위와 다르다.

프로그래밍 언어에서 유효범위는 어느 범위까지 참조하는 지를 뜻한다.

• 전역 스코프 (Global Scope)

  • 스크립트 전체에서 참조되는 것을 의미하며, 어느 곳에서든 참조된다.

• 지역 스코프 (Local Scope)

  • 정의된 함수 내에서만 참조되는 것을 의미하며, 밖에서는 참조되지 않는다.

1-1. Scope(유효범위)의 특징

• 함수 단위의 유효범위 (function-level-scope)

• 변수명 중복 허용

• 암묵적 선언 (Implied Globals)

• Lexical Scoping (Static Scoping)

1-1-1. function-level-scope

function-level-scope란?

함수 코드 블럭 내에서 선언된 변수는 함수 코드 블럭 내에서만 유효하고, 함수 외부에서는 유효하지 않다는 것이다.

var x = 0;

{
  var x = 1;
  console.log(x); // 1
}

console.log(x); // 1 - 결론적으로 var로 선언한 x가 값이 1로 변경

let y = 0;

{
  let y = 1;
  console.log(y); // 1
}

console.log(y); // 0 - 결론적으로 let로 선언한 y는 함수 내부에서만 1

1-1-2. 변수명 중복 허용

클로벌 영역에 변수를 선언하면, 이 변수는 어느 곳에서든지 참조할 수 있는 Global Scope 를 갖는 전역 변수가 된다.

var global = 'global';

function foo() {
  var local = 'local';

  console.log(global); // global
  // Global 영역의 변수로 어디서든 사용 가능
  console.log(local); // local
}

foo();

console.log(global); // global
console.log(local); // Uncaught ReferenceError: local is not defined
// Local 영역의 변수로 함수 내에서만 사용 가능

1-1-3. 암묵적 전역 (Implied Globals)

명시적으로 변수 앞에 var를 붙여주지 않으면 암묵적 전역 변수가 된다.

하지만 암묵적 전역은 오류를 발생시키는 원인이 될 가능성이 크기 때문에, 반드시 var, let, const 키워드를 사용하여 변수를 선언한 다음 사용해야 한다.

하지만 오타나 문법지식의 미비로 인한 실수는 언제나 발생할 수 있기 때문에, 이를 위해 ES5 부터 Strict Mode(엄격 모드)가 추가되었으며, ES6에서 도입된 클래스와 모듈은 기본적으로 Strict Mode가 적용된다.

Strice Mode(엄격 모드)란?

Strice Mode(엄격 모드)는 JavaScript 언어의 문법을 좀 더 엄격히 적용하여 오류를 발생시킬 가능성이 높거나 자바스크립트 엔진의 최적화 작업에 문제가 될 수 있는 코드에 대해 명시적 에러를 발생시킨다.

ESLint와 같은 도구를 사용해도 Strice Mode와 유사한 효과를 얻을 수 있다.

ESLint 도구는 정적 분석(Static Analysis)기능을 통해 소스코드를 실행하기 전에 소스코드를 스캔하여 문법적 오류만 아니라 잠재적 오류까지 찾아내고 오류의 원인을 리포팅해주는 유용한 도구다.

ESLint 도구는 Strice Mode가 제한하는 오류는 물론 코딩 컨벤션을 설정 파일 형태로 정의하고 강제할 수 있기 때문에 더욱 강력한 효과를 얻을 수 있다.

function foo() {
  x = 'x'; // ES6의 Strinc Mode 및 ESLint로 인해 오류 출력
  var y = 'y';
}

foo();

console.log(x); // x
console.log(y); // Uncaught ReferenceError: y is not defined
// Local 영역의 변수로 함수 내에서만 사용 가능

1-1-4. Lexical Scoping (Static Scoping)

자바스크립트는 함수가 선언된 시점에서의 유효범위를 갖는다.

• 예제 1

  var number = 1234;
  
  function printNumber() {
    console.log(number);
  }
  
  function wrapper() {
    number = 4321;
    // printNumber 함수를 실행시키기 전에 number를 변경했기 때문에 값이 변경됨
    printNumber();
  }
  
  wrapper(); // 4321

  printNumber 함수를 실행하기 직전에 number 의 값을 변경해주었으므로 wrapper 함수를 실행시켰을 때에 값이 변경되어, 1234에서 4321가 출력된다.

• 예제 2

  var number = 1234;
  
  function printNumber() {
    console.log(number);
  }
  
  function wrapper() {
    var number = 4321;
    console.log(number); // 4321
    printNumber();
  }
  wrapper(); // 1234

  wrapper 함수 안에서 var 키워드를 사용하게 되면 결과가 달라진다.

  함수를 처음 선언하는 순간, 함수 내부의 변수는 자기 스코프로부터 가장 가까운 곳(상위 범위에서)있는 변수를 계속 참조하게 된다.

  위에 예시에서는 printNumber 함수 안의 number 변수는 선언 시 가장 가까운 전역변수 number를 참조하게 된다.

2. 스코프체인 (Scope Chain)

새롭게 정의된 스코프는 상위의 스코프에 접근할 수 있다.

스코프 체인은 Scope의 가장 내부에서 Scope Chain을 따라 바깥쪽으로 검색을 하게 된다.

3. 클로저 (Closure)

클로저는 함수가 선언된 환경의 (Lexical) 스코프를 기억하여, 함수가 스코프 밖에서 실행될 때에도 이 스코프에 접근할 수 있게 하는 기술이다.

const counter = () => {
  let count = 0;

  // changeCounter는 inner 함수
  // 객체를 리턴하고 있고, 객체 안에는 increase, decrease, show라는 inner 함수들을 저장
  function changeCount(number) {
    count += number;
  }

  return {
    increase: function () {
      changeCount(100);
    },
    decrease: function () {
      changeCount(-10);
    },
    show: function () {
      console.log(count);
    }
  }
};

const counterClosure = counter();
// counter를 실행하면, outer 함수 스코프를 기억하고 있는 클로저들이 담긴 객체를 반환
// counterClosure는 counter 함수 내부에 정의된 count나 changeCount에 접근 가능

counterClosure.increase();
counterClosure.show(); // 100

counterClosure.decrease();
counterClosure.show(); // 90

내부 함수는 외부 함수의 지역 변수에 접근 할 수 있는데, 외부 함수의 실행이 끝나서 외부 함수가 소멸된 이후에도 내부 함수가 외부 함수의 변수에 접근할 수 있다.

이러한 매커니즘을 클로저(Closure)라고 한다.

3-1. React Hook에서의 클로저(Closure)

3-1-1. useState의 작동 방식

React에서 함수형 컴포넌트의 상태 관리를 위해서는 컴포넌트 외부에 저장된 값을 사용하며 클로저(Closure)를 통해 해당 값에 접근해서 상태를 비교하고 변경한다.

useState는 컴포넌트 내부에서 값을 변경시키는 것이 아니라, 외부에 있는 값을 변경시키기 때문에 상태가 변경된 직후 컴포넌트가 가진 값은 이전의 값을 그대로 참조한다.

각 컴포넌트의 상태 정보는 배열 형태로 저장되기 때문에 상태를 변화시키는 hook을 조건문이나 반복문 안에서 사용하면 잘못된 순서의 값을 참조하게 될 수 있다.

참고 사이트

aeong98.log - 스코프(Scope) 와 클로저(Closure)의 이해 암묵적 전역(Implicit Global), Strict Mode

HTTP는 요청과 응답으로 이뤄지는 하나의 사이클이 끝나면, 연결이 끊어지는 무상태성을 띄어서 클라이언트의 상태를 보존하지 않는다.

클라이언트의 상태를 서버가 아닌 클라이언트에 저장해두고 필요시마다 데이터를 꺼내서 서버에 전달하는 방식으로 HTTP의 단점을 보완하고자 쿠키와 웹 스토리지를 사용한다.

2. Cookie란?

만료 기간이 있는 클라이언트 단에서 저장하는 작은 텍스트 파일이다.

요청과 응답만이 존재했던 HTTP 웹에서 이전에 서버와 클라이언트가 주고 받은 내역을 기억하고 불러올 수 있는 역할을 수행하고 있다.

• 일시적으로 필요한 가벼운 데이터 저장이 필요한 경우 사용한다.

  • 다시 보지 않음 팝업창, 로그인 자동 완성 등에 사용

2-1. Cookie 종류

• Session Cookie

  • 메모리에만 저장되며, 만료 시간이 있지만 브라우저 종료 시 삭제되는 쿠키이다.

• Persistent Cookie

  • 파일로 저장되며, Max-Age 설정을 통해 자기간 유지가 가능하고, 브라우저 종료와 관계없이 사용이 가능한 쿠키이다.

• Secure Cookie

  • HTTPS에서 사용되는 암호화된 쿠키로, 비교적 안전하지만 실질적 보안이 제공되지 않기 때문에 민감한 데이터 저장에는 위험한 쿠키이다.

• Third Party Cookie

  • 다른 도메인에 요청이 필요할 때 생성하는 쿠키로, 주로 광고 목적으로 사용되며, 유저 개인정보 악용의 문제가 발생할 수 있는 쿠키이다.

2-2. Cookie 동작 원리

1. 클라이언트가 서버에 HTTP를 요청한다.

2. 서버가 HTTP 응답시, set-cookie를 통해 쿠키를 생성하여 전달한다.

3. 클라이언트는 이때부터 매 HTTP Request시에 HTTP Header에 쿠키를 담아서 전송한다.

4. 만료 기간 전이라면, 쿠키는 브라우저에 저장되어 있으며, 항상 요청 시에 사용이 가능하다.

5. 만료되었다면, 클라이언트가 새로 서버에 요청하여 쿠키를 새로 발급받아야 한다.

2-3. Cookie의 특징

2-3-1. 장점

• 대부분의 브라우저에서 지원한다.

• 데이터 유효기간을 지정할 수 있다. (1시간, 1일 등)

• XSS(사이트 간에 악성 JavaScript 코드를 심는 행위)로부터 안전하며, 서버에서 쿠키의 httpOnly 옵션을 설정하여 JavaScript에서 쿠키에 접근 자체를 막을 수 있다.

2-3-2. 단점

• 저장 용량이 매우 작다. (4kb)

• 매번 서버에 HTTP 요청시에 같이 전달되어 서버에 부담을 줄 수 있다.

• 암호화가 안되어 있어서 유저 정보의 도난 위험이 있다.

• CSRF(사이트 간 요청 위조)의 위협에 취약하다.

  CSRF(사이트 간 요청 위조)란?

  공격자가 사용자의 요청을 가로챈 뒤 사용자의 의지와 상관없이 보안적으로 위험한 행동을 하게끔 변조하여 부당하게 이익을 취하는 행위

• 문자열 데이터만 저장이 가능하다.

3. Web Storage란?

클라이언트에 데이터를 저장할 수 있도록 HTML5부터 나온 새로운 방식의 데이터 저장소이다.

Local Storage와 Session Storage 두 가지의 방식이 존재하며, key와 value 1쌍의 형태로 데이터를 저장한다.

또한 window 객체의 프로퍼티로써 존재한다.

3-1. Local Storage VS Session Storage

3-1-1. Local Storage

Local Storage는 사용자의 로컬 환경에 데이터를 저장하는 방식으로, 영구적인 저장이 가능하다.

• 지속적으로 필요한 데이터 저장이 필요한 경우에 사용한다.

  • 자동 로그인 등에 사용

3-1-2. Session Storage

Session Storage는 브라우저 탭/윈도우 자체에 데이터를 저장하는 방식으로, 브라우저 탭/윈도우가 닫힐 경우, 스토리지가 초기화된다.

• 일시적으로 필요한 데이터 저장이 필요한 경우 사용한다.

  • 일회성 로그인, 입력 폼 저장, 비로그인 장바구니 등에 사용

3-2. Web Storage의 특징

3-2-1. 장점

• 서버에 불필요하게 데이터 저장하지 않는다.

• 데이터의 저장 용량이 Cookie비해 크다

  모바일 : 2.5MB 데스크탑 : 5~10MB

• 문자열 외에도 JavaScript의 모든 원시형 데이터와 객체형 데이터를 저장할 수 있다.

• 도메인 단위로 접근이 제한되는 CORS 특성 덕분에 CSRF로부터 안전하다.

3-2-2. 단점

• HTML5를 지원하는 브라우저만 사용이 가능하다.

• Local Storage에 접근하는 JavaScript 코드로 쉽게 접근 가능하며, XSS로부터 취약하다.

참고 사이트

hs.log - 쿠키, 로컬 스토리지, 세션 스토리지 Login Radius Blog - Local Storage vs. Session Storage vs. Cookies

1. 불변성이란?

불변성이 프로그래밍에서 주목받는 이유는 변경 가능한 상태를 여러 곳에서 공유하게 됨으로써 발생하는 여러 가지 문제를 해결하기 위함이었다.

이런 문제는 멀티 스레딩과 같은 동시성 프로그래밍(동시에 값을 읽고 다른 동작을 할 때)을 사용할 때 많이 발생했는데 기존에는 락을 걸어놓고 락이 풀린 상태에만 스레드가 상태에 접근할 수 있도록 허가하는 방식을 주로 사용했었다.

즉, 불변성(Immutability)은 상태나 값을 변경하지 않는 것이다.

JavaScript의 경우 원시 타입의 값들은 불변성을 갖고 있다.

let a = 0
a = 1
console.log(a);
// 결과 : 1

위의 코드처럼 변수에 값을 재할당하면 a가 참조하고 있는 메모리의 값이 변경되는 것이 아니라 새로운 값인 2가 메모리에 새로 저장되고 그 주소 값이 a에 할당되는 방식으로 작동한다.

하지만, 원시 타입 값이 아닌 다른 참조형 값들(객체, 배열, 함수 등)은 다른 방식으로 작동한다.

const object = { a: 0 };
object.a = 1;
console.log(object);
// 결과 : { a: 1 }

위의 코드에서 object의 내부 프로퍼티의 값을 변경했을 때 object에서 참조하고 있는 a값은 변경되지 않고 값이 변경된다.

단, a가 참조하고 있는 1의 주소 값은 변경된다.

이처럼 JavaScript 객체는 가변한며, React에서는 JavaScript 객체가 가변하기 때문에 문제가 된다.

2. React의 상태값 불변성의 필요

React에서 상태값의 불변성을 유지해야 하는 이유는

1. 값이 변경됐는지 알기 위함

2. 값을 수정하면, 이전 상태와 바뀐 상태값이 동일해져서 비교할 수 없음

등이 있다.

React에서는 상태가 변하면 컴포넌트가 리렌더링이 된다.

React에서 리렌더링할 때 값 자체가 아니라 참조 값을 비교하므로 참조 값이 동일하면, 변경을 감지할 수 없게 된다.

또한, 값을 수정하면 이전 상태와 바뀐 상태값이 동일해지기 때문에, 이전 상태와 현재 상태를 비교하여 렌더링할 수 없게 된다.

불변 객체를 사용하지 않고 객체의 변화를 감지할 수 있지만, 효과적으로 객체의 변화를 감지할 수 있는 가장 좋은 방법은 불변 객체를 사용하는 것이다.

3. 불변성을 유지하는 방법

JavaScript에서 객체를 불변하게 만드는 방법은 크게 3가지 정도가 있다.

1. assign 메서드 사용

2. spread 연산자 사용

3. immer 라이브러리 사용

4. MobX 라이브러리를 통한 전역 상태 관리

등이 있다.

3-1. Object.assign()

Object.assign 메서드를 통해 불변성을 유지할 수 있다.

const object = { a: 0 };
object.a = 1;
console.log(object);
// 결과 : { a: 1 }

const cloneAssign = Object.assign({}, object, { b: 2 });
console.log(cloneAssign);
// 결과 : { a: 1, b: 2 }

Object.assign()은 매개 변수로 전달된 객체의 모든 속성을 첫 번째 매개 변수에 지정된 객체에 복사한다.

주의 사항으로는 Object.assign()은 속성의 값을 복사(얕은 복사)하기 때문에, 깊은 복사를 수행하려면 다른 방법을 사용해야 한다.

3-2. Spread 연산자

Spread 연산자를 이용하면, 객체 혹은 배열을 펼칠 수 있으며, 객체나 배열을 통채로 끌고와서 사용이 가능하다.

또한 기존의 것은 건들이지 않고 새로운 객체를 만들 때 사용한다. (기존 값의 불변성 유지)

const object = { a: 0 };
object.a = 1;
console.log(object);
// 결과 : { a: 1 }

const cloneAssign = Object.assign({}, object, { b: 2 });
console.log(cloneAssign);
// 결과 : { a: 1, b: 2 }

const cloneSpread = { ...object, ...cloneAssign, c: 3 };
console.log(cloneSpread);
// 결과 : { a: 1, b: 2, c: 3 }

const numberObject = { one: '하나', two: '둘', three: '셋' }
const { three, ...rest } = numberObject;
console.log(three);
// 결과 : 셋
console.log(rest);
// 결과 : { one: '하나', two: '둘' } - rest 안에는 three 값을 제외한 값이 들어있음
console.log(numberObject);
// 결과 : { one: '하나', two: '둘', three: '셋' }

3-3. immer 라이브러리 사용

위의 두 가지 방식을 사용하면 얕은 복사가 된다.

그러므로 객체 안의 객체가 있으면 그 안의 객체도 복사해 주어야 한다.

하지만 무분별하게 깊은 복사를 사용하는 것은 다음과 같은 이유로 문제가 될 수 있다.

• 깊은 복사는 성능이 저하될 수 있다.

• 리액트에서 변경되지 않은 객체도 변경되었다고 감지하여 모든 것을 리렌더링할 수 있다.

그러므로, 변경된 객체만 변경해주는 것이 좋다.

immer와 같은 라이브러리를 사용하여 쉽게 불변성을 관리할 수 있다.

Immer performance 문서를 보면, 변경된 객체만 복사하여 성능을 향상시킬 수 있다고 나와 있다.

위의 3가지의 불변성을 유지한 프로그래밍의 경우 객체 지향 프로그래밍에 적합하지 않으며, 불변성 유지를 위해 계속해서 노력하고 신경을 써야한다.

3-4. MobX 라이브러리를 통한 전역 상태 관리

MobX는 전역 상태 라이브러리로, 모든 상태 변화롤 일어나는 부분으로 자동으로 추적해주는 역할을 한다.

MobX는 다음과 같은 특징을 가지고 있다.

1. React에 종속적인 라이브러리가 아님

2. 아키텍처나 상태 컨테이너가 아닌 라이브러리

3. Redux와 다르게 store에 제한이 없음

4. 또한 Redux에서 해줘야했던 action 선언, connect, mapStateToProps, mapDispatchToProps 등 번거로운 작업들은 데코레이터로 간단하게 대체

5. observable을 기본적으로 사용하고 있음

6. Mobx는 절대적으로 필요한 경우에만 state 변경

7. Typescript를 기반으로 만들어짐

8. 객체 지향 프로그래밍에 적합

9. 불변성을 신경쓰지 않아도 내부적으로 처리

후에 추가적으로 MobX 라이브러리에 대해 사용 및 정보 등을 포스팅할 예정이다.

참고 사이트

구보현 블로그 - 리액트의 상태가 불변해야 하는 이유 badahertz52.log - React의 불변성 MDN - Object.assign() Spread / React 문법 (feat. 구조 분해 할당) Immer - Introduction to Immer 기억보다 기록을 - mobx 알아보기

Hyper Text Transfer Protocol의 약자로 서버/클라이언트 모델을 따라 데이터를 주고 받기 위한 프로토콜이다.

즉, HTTP는 인터넷에서 하이퍼텍스트를 교환하기 위한 통신 규약으로, 80번 포트를 사용하고 있으며, 따라서 HTTP 서버가 80번 포트에서 요청을 기다리고 있으며, 클라이언트는 80번 포트로 요청을 보내게 된다.

HTTP의 역사

HTTP는 1989년 팀 버너스 리(Tim Berners Lee)에 의해 처음 설계되었으며, WWW(World-Wide-Web) 기반에서 세계적인 정보를 공유하는데 큰 역할을 하였다.

1-1. HTTP의 구조

HTTP는 애플리케이션 레벨의 프로토콜로 TCP/IP 위에서 작동한다.

HTTP는 상태를 가지고 있지 않는 Stateless 프로토콜이며 Method, Path, Version, Headers, Body 등으로 구성된다.

하지만 HTTP는 암호화가 되지 않은 평문 데이터를 전송하는 프로토콜이였기 때문에, HTTP로 비밀번호나 주민등록번호 등을 주고 받으면 제3자가 정보를 조회할 수 있었다.

그리고 이러한 문제를 해결하기 위해 HTTPS가 등장하게 되었다.

2. HTTPS

Hyper Text Transfer Protocol Secure의 약자이며, HTTPS(https://)는 SSL(Secure Socket Layer) 인증서를 사용하는 HTTP(http://)이다.

HyperText Transfer Protocol over Secure Socket Layer, HTTP over TLS, HTTP over SSL, HTTP Secure 등으로 불리며, HTTPS는 HTTP에 데이터 암호화가 추가된 프로토콜이다.

HTTPS는 HTTP와 다르게 443번 포트를 사용하며, 네트워크 상에서 중간에 제3자가 정보를 볼 수 없도록 암호화를 지원하고 있다.

2-1. HTTPS의 동작 과정

HTTPS는 대칭키 암호화와 비대칭키 암호화를 모두 사용하여 빠른 연산 속도와 안정성을 모두 얻고 있다.

HTTPS 연결 과정(Hand-Shaking)에서는 먼저 서버와 클라이언트 간에 세션키를 교환한다.

여기서 세션키는 주고 받는 데이터를 암호화하기 위해 사용되는 대칭키이며, 데이터 간의 교환에는 빠른 연산 속도가 필요하므로 세션키는 대칭키로 만들어진다.

문제는 이 세션키를 클라이언트와 서버가 어떻게 교환할 것이냐 인데, 이 과정에서 비대칭키가 사용된다.

즉, 처음 연결을 성립하여 안전하게 세션키를 공유하는 과정에서 비대칭키가 사용되는 것이고, 이후에 데이터를 교환하는 과정에서 빠른 연산 속도를 위해 대칭키가 사용되는 것이다.

위의 그림을 통해 실제 HTTPS 연결 과정이 성립되는 흐름을 살펴보면 다음과 같다.

1. 클라이언트(브라우저)가 서버로 최초 연결 시도를 함

2. 서버는 공개키(엄밀히는 인증서)를 브라우저에게 넘겨줌

3. 브라우저는 인증서의 유효성을 검사하고 세션키를 발급함

4. 브라우저는 세션키를 보관하며 추가로 서버의 공개키로 세션키를 암호화하여 서버로 전송함

5. 서버는 개인키로 암호화된 세션키를 복호화하여 세션키를 얻음

6. 클라이언트와 서버는 동일한 세션키를 공유하므로 데이터를 전달할 때 세션키로 암호화/복호화를 진행함

2-1-1. 대칭키 암호화와 비대칭키 암호화

HTTPS는 대칭키 암호화 방식과 비대칭키 암호화 방식을 모두 사용하고 있다.

각각의 암호화 방식은 다음과 같다.

• 대칭키 암호화

  • 클라이언트와 서버가 동일한 키를 사용해 암호화/복호화를 진행함

  • 키가 노출되면 매우 위험하지만 연산 속도가 빠름

• 비대칭키 암호화

  • 1개의 쌍으로 구성된 공개키와 개인키를 암호화/복호화를 하는데 사용함

  • 키가 노출되어도 비교적 안전하지만, 연산 속도가 느림

    공개키

    모두에게 공개가능한 키이다.

    공개키 암호화를 하면 개인키로만 복호화할 수 있다. 개인키는 나만 가지고 있으므로, 자신만 볼 수 있다.

    개인키

    자신만 가지고 알고 있어야 하는 키.

    개인키로 암호화하면 공개키로만 복호화할 수 있다. 공개키는 모두에게 공개되어 있으므로, 자신이 인증한 정보임을 알려 신뢰성을 보장할 수 있다.

    

2-2. HTTPS의 발급 과정

위의 과정에서 추가로 살펴봐야 할 부분은 서버가 비대칭키를 발급받는 과정이다.

서버는 클라이언트와 세션키를 공유하기 위한 공개키를 생성해야 하는데, 일반적으로는 인증된 기관(Certificate Authority)에 공개키를 전송하여 인증서를 발급받는다.

자세한 과정은 다음과 같다.

A : Authority CA : Certification Authority

1. A 기업은 HTTP 기반의 앱에 HTTPS를 적용하기 위해 공개키/개인키를 발급

2. A 기업은 CA 기업에게 돈을 지불하고, 공개키를 저장하는 인증서 발급 요청

3. CA 기업은 CA 기업의 이름, 서버의 공개키, 서버의 정보 등을 기반으로 인증서를 생성

4. CA 기업의 개인키로 암호화 후, A 기업에게 이를 제공

5. A 기업은 클라이언트에게 암호화된 인증서 제공

6. 브라우저는 CA 기업의 공개키를 미리 다운받아 갖고 있어, 암호화된 인증서를 복호화

7. 암호화된 인증서를 복호화하여 얻은 A 기업의 공개키로 세션키를 공유

   

인증서는 CA 기업의 개인키로 암호화되었기 때문에 신뢰성을 확보할 수 있고, 클라이언트는 A 기업의 공개키로 데이터를 암호화하였기 때문에 A 기업만 복호화하여 원본의 데이터를 얻을 수 있다.

여기서 인증서에는 A 기업의 공개키가 포함되어 있으므로, A 기업의 공개키라고 봐도 무방하다.

또한 브라우저에는 인증된 CA 기관의 정보들이 사전에 등록되어 있어 인증된 CA 기관의 인증서가 아닐 경우에는 다음과 같은 형태로 브라우저에서 보여지게 된다.

3. HTTP와 HTTPS

HTTP는 암호화가 추가되지 않았기 때문에 보안에 취약한 반면, HTTPS는 안전하게 데이터를 주고받을 수 있다.

하지만 HTTPS를 이용하면 암호화/복호화의 과정이 필요하기 때문에 HTTP보다 속도가 느리다.

물론 오늘날에는 거의 차이를 못느낄 정도이다.

또한 HTTPS는 인증서를 발급하고 유지하기 위한 추가 비용이 발생한다.

3-1. 언제, 어떤걸 써야하나?

3-1-1. HTTP 사용

노출이 되어도 괜찮은 단순한 정보 조회 등만을 처리하고 있다면 HTTP를 이용하면 된다.

또한 HTTPS의 추가 비용 발생으로 인해, 간단한 프로젝트 진행의 경우, http://localhost:3000/과 같은 주소로 프로젝트 개발을 진행한다.

3-1-2. HTTPS 사용

개인 정보와 같은 민감한 데이터를 주고 받아야 한다면 HTTPS를 이용해야 한다.

사실상, 어플리케이션을 개발하여 사용자를 유치하고 서비스를 진행하기 위해서는 HTTPS 방식을 채택해야 한다.

참고 사이트

망나니개발자 - HTTP와 HTTPS의 개념 및 차이점

교차 출처 리소스 공유(Cross-Origin Resource Sharing, CORS)는 브라우저가 추가 HTTP 헤더를 사용하여, 한 출처에서 실행 중인 웹 애플리케이션이 다른 출처의 선택한 자원에 접근할 수 있는 권한을 부여하도록 브라우저에 알려주는 체제이다.

쉽게 정리하자면, 사용자가 지금 접속한 사이트와 다른 출처의 릴소스를 사용하려 할 때, 브라우저가 참고하는 화이트 리스트라고 할 수 있다.

만약, 이 리스트에 없다면 콘솔 창에 빨갛게 CORS 에러를 마주하게 된다.

2. SOP란?

동일 출처 정책(Same-Origin Policy)은 어떤 출처에서 불러온 문서나 스크립트가 다른 출처에서 가져온 리소스와 상호작용하는 것을 제한하는 중요한 보안 방식으로, 동일 출처 정책은 잠재적으로 해로울 수 있는 문서를 분리함으로써 공격받을 수 있는 경로를 줄여준다.

2-1. 동일 출처란?

프로토콜 / 호스트 / 포트 3가지가 모두 동일하면 동일 출처라고 할 수 있다.

동일 출처가 아닌데 ajax 요청을 보내면 CORS error를 만나게 되며, 즉, 동일 출처가 아닐 때 요청을 막는 것은 SOP이고, 요청이 가능하도록 하는 것이 CORS이다.

2-2. 왜 동일 출처 정책이 필요한가?

위의 그림을 통해 예시를 들자면,

1. 유저가 어떤사이트에 접속하고 로그인을 하면, 브라우저의 토큰 등의 로그인 정보가 쿠키에 저장된다.

2. 이때 로그인 했던 사이트에 접속할때 쿠키를 요청에 같에 보내어 로그인되었다고 판단한다.

3. 즉, 인증 정보가 브라우저의 쿠키, 세션등의 스토리지에 저장되어 있고 이를 특정 요청에 같이 실어 보내어 인증을 진행하는 것이다.

4. 만일 악의적인 사이트가 있다면 해당 사이트 접속시 JavaScript 코드가 유저의 브라우저에 다운로드되게 된다.

5. 악의적인 사이트의 JavaScript 코드가 유저의 브라우저에 저장된 쿠키나 세션등에 접근할 수 있다.

6. 이를 이용해 유저의 인증정보를 이용해 정보를 탈취할 수 있게된다.

원래 보안을 위해 다른 출처의 리소스를 접근하는 것이 불가능했지만, 웹 생태계가 다양해지면서 여러 서비스들끼리 자유롭게 데이터가 주고 받아질 필요가 생겼다.

그런데, 다른 사이트 간의 요청들을 브라우저가 막고 있기 때문에 이를 허용해주기 위해 어떠한 기준을 충족시키면 리소스를 공유할 수 있도록 만들어진 체제가 바로 CORS다.

3. CORS의 동작원리

CORS 동작의 시나리오는 다음 2가지로 나뉜다.

3-1. Simple Request

예비 요청을 보내지 않고, 서버에게 바로 본 요청을 전송한다.

이 후 서버가 응답 헤더에 Access-Control-Allow-Origin과 같은 값을 보내주면 그때 브라우저가 CORS 정책 위반 여부를 검사하는 방식이다.

GET이나 POST 등 일정 조건에 요청들에 대해 사용된다.

1. 기본적으로 웹은 다른 출처의 리소스를 요청할 때는 HTTP 프로토콜을 사용하여 요청을 하는데, 이때 브라우저는 요청 헤더에 Origin 필드에 요청을 보내는 출처를 담아 전송한다.

2. 서버는 요청에 대한 응답을 하는데, 응답 헤더에 Access-Control-Allow-Origin이라는 항목에 이 리소스를 접근하는 것이 허용된 출처를 명시해준다.

   Access-Control-Allow-Origin: * 처럼 와일드카드(*)를 사용하면 모든 origin 요청을 허용하는게 된다.

3. 이후, 응답을 받은 브라우저는 자신이 보냈던 요청의 Origin과 서버가 보내준 응답의 Access-Control-Allow-Origin을 비교한 후 이 응답 가능 여부를 결정한다.

요청 시 header의 origin 항목에 URL(프로토콜/호스트/포트) 정보가 담겨있고, 응답 header에 Access-Control-Allow-Origin 항목에 요청시 origin 항목의 URL 정보가 있다면 브라우저는 응답을 받아오게 되고 없다면, 거부하게되며 CORS error가 나타나게 된다.

이러한 에러를 해결할 수 있도록, Spring이나 Django, Express 등의 문서에 CORS 옵션 설정하는 방법이 잘 나와있다.

3-2. Preflight Request

요청을 한번에 보내는 것이 아닌 예비 요청과 본 요청으로 나누어서 서버로 전송한다.

본 요청을 보내기 전 미리 예비로 보내는 요청을 Preflight라고 하며, HTTP 메서드 중 OPTIONS 메서드를 사용한다.

서버는 예비 요청에 대한 응답으로, 어떤 요청을 허용하고 또 금지하는지에 대한 정보를 응답 헤더에 담아 보낸다.

예비 요청으로 본 요청이 안전한지 확인한 다음에야 본격적으로 요청을 보낼 수 있다.

PUT이나 DELETE 등 서버 데이터에 영향을 줄 수 있는 요청들이기 때문에 먼저 요청의 허용 여부를 검증하는 것이다.

만약, 토큰 등 사용자 식별 정보가 담긴 요청에 대해서는 보다 엄격하다.

요청 옵션에 crendentials 항목을 true로 세팅해야 하고, 서버에서도 모든 출처를 허용하는 와일드카드 (*)가 아닌 요청 웹페이지의 주소를 정확히 명시한 다음 Access-Control-Allow-Credentials 항목을 true로 설정해주어야 한다.

참고 사이트

gwanuuoo.log - CORS란 무엇인가? hinyc.log - CORS ? 쉽게 알아보자

소프트웨어 개발 방법론은 소프트웨어를 어떻게 만들지에 대한 관심을 가지게 된다.

따라서 개발 방법론에는 단계별 산출물뿐만 아니라 산출물을 누가 어떤 순서로 어떻게 만들어야 하는지, 그리고 어떤 도구를 사용해야 하는지를 구체적으로 정의하고 있다.

2. 소프트웨어 개발 방법론의 종류

소프트웨어의 개발 방법론은 크게 5가지로 나뉘며,

1. 구조적 개발 방법론

2. 정보공학 개발 방법론

3. 객체지향 개발 방법론

4. 컴포넌트 기반(CBD) 개발 방법론

5. 애자일, 폭포수 모델, 프로토타입 개발 방법론

등이 있다.

3. 구조적 개발 방법론

구조적 방법론은 구조, 흐름, 간결, 간단 이 구조적 개발 방법의 특징이다.

요구사항 분석 -> 구조적 분석 -> 구조적 설계 -> 구조적 프로그래밍 순서로 이루어져 있다.

3-1. 구조적 개발 방법론의 특징

3-1-1. 구조적 개발 방법론의 단계

위의 그림을 참고하면,

1. 요구사항 분석 단계

   • 데이터, 시스템 환경, 사용자 요구기능 등을 분석하는 단계이다.

   • 고객이 원하는 요구사항을 끌어내 명세화한다.

2. 구조적 분석 단계

   • DFD , DD, Minispec 등을 작성하고 DB를 분석하는 단계이다.

   • 고객이 원하는 기능/시스템 환경/데이터를 종합하여 데이터 흐름도(DFD)를 작성한다.

     데이터 흐름도(DFD, Data Flow Diagram)란? 데이터 흐름도는 유구사항 분석에서 데이터의 흐름 및 변환 과정과 기능을 도형 중심으로 기술하는 방법으로 데이터 흐름 그래프, 버블 차트라고도 하며, 데이터 흐름과 기능을 자세히 표현하기 위해 단계적으로 세분화된다.

     데이터 사전(DD, Data Dictionary)이란? 데이터 사전은 데이터 흐름도에 있는 자료를 더 자세히 정의하고 기록한 것으로, 이처럼 데이터를 설명하는 데이터를 데이터의 데이터 또는 메타 데이터(Meta Data)라고 한다.

     소단위 명세서(Minispec)란? 소단위 명세서는 세분화된 데이터 흐름도에서 최하위 단계 버블(프로세스)의 처리 절차를 기술한 것으로 프로세스 명세서라고도 하며, 분석가의 문서이며 데이터 프름도(DFD)를 지원하기 위해 작성한다.

3. 구조적 설계 단계

   • 구조적 분석 단계에서의 DB 분석을 통해 DB 설계 및 어플리케이션을 설계하는 단계이다.

   • 모듈 중심으로 설계를 진행하며, 재활용 가능하도록, 결합도를 낮춰서 독립성을 높이기 위한 목적으로 진행한다.

4. 구조적 프로그래밍 단계

   • 위의 3단계의 논리적인 구조를 통해 실질적인 프로그래밍을 진행하는 단계이다.

   • 순차, 선택, 반복의 논리 구조 구성으로 프로그램 복잡성을 최소화한다.

3-2. 구조적 개발 방법론의 장/단점

3-2-1. 구조적 개발 방법론의 장점

• 명확한 요구사항을 추출하여 설계에 반영이 가능하며, 정형화/체계화가 가능하다.

• 효율적인 재사용 및 유지보수가 용이한 모듈화가 가능하다.

3-2-2. 구조적 개발 방법론의 단점

• 거시적 관점의 인식이 부족하며, 방법론에 대한 다양한 시도를 하고 있지 않다는 뜻으로 프로젝트에서만 사용하는 추세이다.

• 실제 사례를 기반으로 하는 자료 부족으로 데이터 모델링 방법과 명확한 방법론적 지침이 미흡하다.

• 유지보수성 및 재사용성이 낮기 때문에 기능이 불완전하고 자주 변한다.

4. 정보공학 개발 방법론

정보공학 개발 방법론은 비지니스 시스템 규모 성장과 소프트웨어 공학 발전에 따라 1980년대 중반에 등장한 방법론이다.

기업 전체 또는 기업의 주요 부분을 계획, 분석, 설계 및 구축에 정형화된 기법들을 상호 연관성있게 통합, 적용하는 데이터 중심 방법론이다.

4-1. 정보공학 개발 방법론의 특징

4-1-1. 정보공학 개발 방법론의 단계

위의 그림을 참고하면,

1. 정보 전략 계획 수립 단계 (ISP, Information Strategy Planning)

   • 기업의 경영 전략을 뒷받침할 수 있는 정보화 전략을 수립하기 위해 현행 업무 프로세스와 시스템을 분석하고 미래 아키텍처와 전략 계획을 수립하는 단계이다.

   • 경영 전략, 관련 조직, 업무 자료를 거시적으로 분석하며, 현행 시스템을 평가한다.

2. 업무영역 분석단계(BAA, Business Area Analysis)

   • 기업의 업무 현황을 분석해서 개념 수준의 데이터와 프로세스를 설계하는 업무 분석 단계이다.

   • ERD를 통해 데이터 모델링을 진행하며, 프로세스 계층도(PHD), 프로세스 의존도(PDD), 데이터 흐름도(DFD) 등의 프로세스 모델링을 진행한다.

3. 업무 시스템 설계단계(BSD, Business System Design)

   • 실질적으로 시스템을 설계하는 단계로 우리가 많이 사용하고 있는 논리적 ER 다이어그램으로 데이터를 설계하고 분할 다이어그램, 액션 다이어그램, 의존 다이어그램을 사용해 프로세스를 설계한다.

4. 시스템 구축단계(SC ,System Construction)

   • 확정된 설계 명세서로부터 데이터 베이스 생성기와 프로그램 코드 생성기를 이용해 데이터 베이스와 실행 가능한 프로그램 코드를 생성한다.

4-1-2. 정보공학 개발 방법론의 개념

설계할 때는 스토리 보드, 데이터 설계서, UI 설계서 정도를 작성하고 개발 과정에서는 이를 바탕으로 물리적 테이블과 프로그램 코드가 만들어 진다.

이런 관점에서 정보공학 방법론을 바라 본다면 BAA에 해당하는 요구분석 단계에서는 요구사항 명세서가 만들어지고 BSD에 해당하는 시스템 설계 단계에서는 논리 ERD와 업무 프로세서를 설명하는 프로세스 구조도/흐름도가 만들어 진다.

그리고 SC에 해당하는 개발 단계에서는 물리 ERD, UI, 프로그램 코드가 개발된다.

4-2. 정보공학 개발 방법론의 장/단점

4-2-1. 정보공학 개발 방법론의 장점

• 경쟁 우위 전략적 기회를 식별할 수 있으며, 방안 또한 제공이 가능하다.

• 일관/통일된 정보 시스템을 구축할 수 있다.

• 데이터 중심으로 업무의 절차가 진행되며 환경 변화에 유연하다.

4-2-2. 정보공학 개발 방법론의 단점

• 정보 공학의 효과를 위해 장기간이 소요된다.

• 특정 사업 영역으로부터 독립된 시스템의 개발에 부적합하다.

• 소규모 자동화 요구 사업에는 부적합하다.

5. 객체지향 개발 방법론

객체지향 개발 방법론은 현실 세계의 개체(Entity)를 속성(Attribute)과 메소드(Method)가 결합된 형태의 객체(Object)로 표현한다.

이를 통해 현실 세계에 존재하는 실체 및 개념들을 객체(Object)라는 독립된 단위로 구성하고 이 객체들이 메시지 교환을 통해 상호작용함으로써 전체 시스템이 운영되는 개념이다.

5-1. 객체지향 개발 방법론의 특징

객체지향 개발 방법론에서는 분석, 설계, 구현의 전 과정을 객체 중심으로 진행한다.

심지어 데이터를 저장하는 테이블도 따로 설계하지 않고 데이터 객체로 설계하며, 데이터는 결국 데이터 베이스에 저장되는데 만일 데이터 베이스가 객체형 DB라면 별다른 변환 과정 없이 데이터 객체를 그대로 저장하면 되지만, 관계형 DB를 사용한다면 객체를 관계형 테이블로 변환하는 과정이 필요하다.

이 과정을 객체-관계 매핑(Object Relation Mapping)이라 하며 현재 대부분의 회사에서 관계형 데이터 베이스를 사용하고 있기 때문에 객체-관계 매핑은 필수적인 과정이라 할 수 있다.

5-1-1. 객체지향 개발 방법론의 특성

• 추상화 (Abstraction) 객체지향 이전에도 많이 다뤘던 설계 개념으로, 불필요한 세부 사항은 배제하고 핵심이 되는 공통 사항을 묶어 개략화하는 작업을 말한다.

• 캡슐화 (Encapsulation) 객체지향 그 자체를 설명하는 개념으로 볼 수 있으며, 속성과 메소드와 같은 각 알맹이들을 하나의 캡슐 안에 넣어서, 안에 무엇이 들어있는지 모르게 할수도, 한 입 크기로 먹어 삼키게 할 수도 있는 작업이다.

• 정보은닉 (Information Hiding) 캡슐화된 객체 내부에 자료 구조나 함수의 기능을 외부의 영향을 받거나 주지 않도록 설계하는 방법이다.

• 상속성 (Inheritance) 객체지향만의 특정으로 볼 수 있으며, 이 객체를 만드는 클래스들을 PC의 폴더(트리) 구조와 같이 부모/자식 계층으로 구성하여, 자식(하위) 계층에서는 부모(상위) 계층의 성질을 물려받을 수 있도록 하는 특성으로, 객체 간 메시지 전달을 통해 프로그래밍하는 방법이다.

• 다형성 (Polymorphism) 같은 메시지에 대해 클래스에 따라 다른 행위를 하게 하는 특성으로, 부모로부터 상속받은 메소드를 자식이 재정의할 수 있다. (오버라이딩)

5-1-2. 객체지향 개발 방법론의 구성요소

5-1-3. 객체지향 개발 방법론의 단계

위의 그림을 참고하면,

1. 개념화 단계(Inception Phase)

   • 시스템에 대한 비즈니스 사례(Business Case)를 만들고 프로젝트 범위(Scope)를 정의한다.

   • 시스템과 상호작용을 하는 모든 외부 엔티티(Actor)를 명시하고, 상위 레벨(High Level)에서 상호작용의 특징을 정의한다.

   • 모든 유즈케이스(Use Case)를 명시하고 중요한 몇 가지를 설명하는 것도 포함된다.

   • 비즈니스 사례는 성공기준(Success Criteria), 위험관리(RiskManagement), 필요한 자원의 평가, 주요한 이정표 날짜를 보여주는 단계별 계획을 포함한다.

   • 개념화 단계의 마지막에는 프로젝트 목적을 검사하고 개발 진행 여부를 결정한다.

2. 상세화 단계(Elaboration Phase)

   • 문제영역(Problem Domain)을 분석하고 견고한 아키텍처 토대를 마련하고 프로젝트 계획을 개발하며 프로젝트에서 가장 위험한 요소를 제거하는 것이다.

   • 아키텍처에 대한 결정은 전체 시스템의 충분한 이해를 통하여 이루어져야 하며, 이것은 유즈케이스를 기술하고 추가적인 요구사항과 같은 제약사항을 고려하는 것을 의미한다.

   • 아키텍처를 검증하기 위해서는 선정된 아키텍처를 실현하고(demonstrates) 중요한 유즈케이스를 실행하는 시스템을 구현하는 것이다.

   • 상세화 단계의 마지막에는 상세한 시스템의 목적과 범위 및 아키텍처 선정과 주요 위험을 검사한다.

3. 구축 단계(Construction Phase)

   • 구축 단계에서는 사용자들(User Community)에게 전이할 수 있도록 반복 및 점증적으로 제품을 완전히 개발하는 것으로, 이것은 나머지 유즈케이스를 기술하고 설계 부문을 더욱 충실하게 하며, 구현을 완전히 끝내고 소프트웨어를 테스트하는 것을 의미한다.

   • 구축 단계의 마지막에는 소프트웨어와 환경과 사용자들이 운영될 준비가 되었는지를 결정한다.

4. 전이 단계(Transition Phase)

   • 소프트웨어를 사용자들(User Community)에게 전달하는 것이다.

   • 제품이 사용자의 손에 전해졌을 때에는, 시스템에 적합하도록 추가적인 개발 및 발견되지 않은 문제점을 수정하고 미루어 놓은 사항들(Features)을 마무리 짓는다.

   • 일반적으로 이 단계는 시스템의 "베타 릴리즈(Beta Release)"로 시작된다.

   • 전이 단계의 마지막에는 생명주기 목적의 충족여부 및 또 다른 개발 주기의 시작여부를 결정해야 하며, 또한 프로세스를 개선하기 위해 프로젝트에서 경험한 것을 여기서 정리한다.

5-2. 객체지향 개발 방법론의 장/단점

5-2-1. 객체지향 개발 방법론의 장점

• 규모가 큰 대형 프로젝트에 적합하다.

• 소프트웨어의 재사용률/확장성/유지보수성이 향상된다.

• 신속하게 개발이 가능하다.

• 사용자 타입을 중심으로 개발된다.

• 대화식 프로그램 개발에 용이하다.

5-2-2. 객체지향 개발 방법론의 단점

• 설계 단계가 어렵다.

• 규모가 크기 때문에 실행 속도가 저하된다.

6. CBD 개발 방법론

CBD 개발 방법론(Component Base Development) 은 개발된 S/W 컴포넌트를 조립, 시스템을 개발하여 객체지향의 단점인 S/W 재사용성을 극대화한 개발 방법론이다.

컴포넌트는 인터페이스로 접근 가능하고 독립적인 기능을 수행하는 모듈로써 교체가 가능한 소프트웨어 부품이다.

6-1. CBD 개발 방법론의 특징

CBD 개발 방법론은 크게 컴포넌트를 개발하는 CD(Component Development) 단계와 개발된 컴포넌트를 사용해서 개발을 진행하는 CBD(Component Base Development) 단계로 나눌 수 있다.

CD 단계에서는 도메인을 분석해 컴포넌트 대상 업무를 선별하고 컴포넌트를 개발해 저장소에 입력한다.

CBD 단계에서는 요구 분석을 통해 컴포넌트 기반으로 설계하고 필요한 컴포넌트를 저장소에서 찾아서 조립하는 방식으로 프로그램 개발을 진행한다.

만일 필요한 컴포넌트가 저장소에 없다면 CD 단계로 돌아가서 컴포넌트를 개발하고 이를 사용해 개발을 계속 진행한다.

6-1-1. CBD 개발 방법론의 단계

위의 그림을 참고하면,

1. 요구 파악

   • 사용자 요구사항을 수집, 도메인을 분석하며, 요구사항 기술서, 용어 사전, 개념 모델등을 이해한다.

   • 요구사항 이해를 기반으로 유즈케이스를 작성하며 요구사항을 정의한다.

2. 분석 및 설계

   • 객체 모델의 프로토타이핑 및 UI를 시획하여 객체 모델과 UI 설계서를 제작하며 요구사항을 분석한다.

   • 아키텍쳐 기술서를 작성하며 소프트웨어 컴포넌트 아키택처를 정의한다.

   • 아키택처를 기반으로 I/D 명세화와 모델링을 진행하며, 인터페이스 명세서와 컴포넌트 명세서를 작성하며 컴포넌트 설계를 한다.

   • 객체 모델의 텐티티 클래스를 대상으로 DB를 모델링하며, ERD, DB 설계서를 작성하며 데이터 베이스를 설계한다.

3. 구현

   • 플랫폼 특성을 검토하며, 표준을 수립하고 명명 규칙, 코딩 규칙, 프로그래밍 가이드 등의 개발 표준 정의를 한다.
   • 플랫폼에 따른 전용 Compiler를 이용하며 코드를 구현한다.

4. 테스트

   • 테스트의 목표와 대상, 방법, 절차 등을 수립하며 테스트 계획을 진행하고 계획서를 작성한다.

   • 테스트의 수행, 절차 기록 및 승인을 진행하며, 컴포넌트 테스트, 통합 테스트, 인수 테스트 등의 보고서를 작성하며 테스트에 대한 수행/보고를 진행한다.

6-2. CBD 개발 방법론의 장/단점

6-2-1. CBD 개발 방법론의 장점

• 반복적인 활용에 의한 수익성 제고 및 개발 기간과 개발 비용이 감소한다.

• 검증된 Component 사용으로 S/W의 품질 수준을 향상시킨다.

• 지적 자산의 재활용 범위가 확대된다.

• 소프트웨어 개발, 유지보수 부문의 생산성을 극대화시킬 수 있다.

6-2-2. CBD 개발 방법론의 단점

• 파라다임 변화에 따른 시행 착오가 따른다.

• 고객과의 문제제로 인해 프로젝트의 잦은 범위 변경 요청에 취약하다.

• 초기 선행에 투자가 필요하다.

• 조립식 정보 시스템 구축에 따른 각각의 책임이 따른다.

7. 애자일 개발 방법론

애자일 개발 방법론은 기존 방법론들이 너무 절차를 중시한 나머지 변화에 대응하기 어려웠던 단점을 개선하기 위해 나왔다.

애자일 방법론은 절차보다는 사람을, 문서보다는 작동하는 소프트웨어를, 미리 철저하게 계획하기 보다는 변화에 대한 민첩한 대응을, 계약과 협상에 얽매이기 보다는 고객과의 협력을 중요하게 생각한다.

7-1. 애자일 개발 방법론의 특징

애자일 방법론에서는 먼저 개발 범위 안에 있는 요구사항을 분석해 우선 순위가 높은 요구사항을 먼저 개발한다.

개발된 부분에 대해 실행하는 모습을 보여줘서 고객의 평가를 받고 고객의 요구사항과 개선사항을 반영해 다음 요구사항 개발에 참고한다.

이런 방식을 계속 반복하면서 소프트웨어 개발 범위를 점진적으로 늘려가게 되는데, 여기에서 가장 핵심이 되는 사항은 단계별로 고객에게 동작하는 소프트웨어를 계속 보여주고 요구사항에 대한 변경을 적극적으로 수용한다는 것이다.

7-1-1. 애자일 소프트웨어 개발 12대 원칙

• 고객 만족

• 변화 수용

• 자주 납품

• 팀으로 작업

• 동기부여

• 대면 소통

• 가독성 측정

• 속도 일정 유지

• 품질 최우선

• 복잡하지 않도록

• 설계 진화

• 규칙적 반영

7-1-2. 애자일 개발 방법론의 단계

위의 그림을 참고하면,

1. 계획 및 분석

   • 고객과 사용자가 원하는 바를 파악하여 타당성을 조사하고 S/W 기능과 제약 조건을 정의하는 명세서 작성, 대상이 되는 문제 영역과 사용자가 원하는 Task를 이해하는 단계이다.

2. 설계 (디자인)

   • 기획 의도에 맞는 설계 및 디자인 추가 및 수정하는 단계이다.

3. 개발 (발전)

   • 설계 단계에서 만들어진 설계서를 바탕으로 프로그램을 작성, 코딩, 디버깅, 단위/통합 테스트를 수행한다.

4. 테스트

   • 발생할 수 있는 실행 프로그램 오류를 발견, 수정하는 단계이다.

5. 검토 (피드백)

   • 기획 의도를 파악하고 시험 결과와 기획에 따라 수정할 부분을 제시하는 단계이다.

7-2. 애자일 개발 방법론의 장/단점

7-2-1. 애자일 개발 방법론의 장점

• 프로젝트 계획에 걸리는 시간을 최소화할 수 있다.

• 점진적으로 테스트할 수 있어서 버그를 쉽고 빠르게 발견할 수 있다.

• 계획 혹은 기능에 대한 수정과 변경에 유연하다.

• 고객 요구사항에 대한 즉각적인 피드백에 유연하며 프로토타입 모델을 빠르게 출시할 수 있다.

• 빠듯한 기한의 프로젝트를 빠르게 출시할 수 있다.

7-2-2. 애자일 개발 방법론의 단점

• 확정되지 않은 계획 및 요구사항으로 인한 반복적인 유지보수 작업이 많다.

• 고객의 요구사항 및 계획이 크게 변경되면 모델이 무너질 수 있다.

• 개인이 아닌 팀이 중심이 되다 보니 공통으로 해야 할 작업이 많을 수 있다. (회의, 로그 등)

• 반복적인 업무로 속도는 빠를 수 있으나 미흡한 기능들에 대한 대처가 필요하다.

• 확정되지 않은 계획으로 개발 진행 시 이해하지 못하고 진행하는 부분이 많을 수 있다.

8. 결론

• 구조적 개발 방법론

  정형화 된 분석 절차에 따라 사용자 요구사항을 파악하여 문서화 하는 처리 중심의 방법론

• 정보공학 개발 방법론

  정보 시스템의 개발을 위해 계획, 분석, 설계, 구축에 정형화된 기법들을 상호 연관성 있게 통합 및 적용하는 자료 중심의 방법론

• 객체지향 개발 방법론

  객체들을 조립해서 필요한 소프트웨어를 구현하는 방법론

• CBD 개발 방법론

  정보 시스템의 개발을 위해 계획, 분석, 설계, 구축에 정형화된 기법들을 상호 연관성 있게 통합 및 적용하는 자료 중심의 방법론

• 애자일 개발 방법론

  고객의 요구사항 변화에 유연하게 대응할 수 있도록 일정한 주기를 반복하면서 개발 과정을 진행하는 방법론

참고 사이트

해시넷 - 소프트웨어 개발방법론 공대생의 차고 - 기술사 준비/SW공학 - 개발 방법론 My LifeChronicle - [소프트웨어공학] 객체지향 개발 방법론 인코덤 - 소프트웨어 개발 방법론 log.log.log.log.log.log - 개발 방법론 AI IMPACTS - [개발방법론] 객체지향방법론이란? 느리게 생각하기 - 구조적 분석 도구

CSR(Client Side Rendering)과 SSR(Server Side Rendering)은 대척 관계에 있는 방식인만큼 장단점이 서로 엇갈려 있기 때문에 서로의 장단을 정확하게 알고, 적재적소에 필요한 방식으로 구현하는 것이 중요하다.

1. SSR이란?

Server Side Rendering의 약자로 말 그대로 서버 쪽에서 렌터링 준비를 끝마친 상태로 클라이언트에게 전달하는 방식이다.

위의 그림을 통해 SSR 단계를 설명하자면,

1. 유저가 웹 사이트에 요청을 보낸다.

2. Server는 "Ready to Render". 즉, 즉시 렌더링 가능한 HTML 파일을 만든다.

   리소스 체크, 컴파일 후 완성된 HTML 컨텐츠로 만든다.

3. 클라이언트에 전달되는 순간, 이미 렌더링 준비가 되어있기 때문에 HTML은 즉시 렌더링이 되지만, 사이트 자체는 조작이 불가능하다.

   JavaScript가 읽히기 전이기 때문이다.

4. 클라이언트가 JavaScript를 다운받는다.

5. 다운받아지고 있는 사이에 유저는 컨텐츠를 볼 수 있지만, 사이트 조작을 할 수는 없다.

   이때의 사용자 조작 자체를 기억하고는 있다.

6. 브라우저가 JavaScript 프레임워크를 실행한다.

7. JavaScript까지 성공적으로 컴파일 되었기 때문에 기억하고 있던 사용자 조작이 실행되고 이제 웹 페이지는 상호작용이 가능해진다.

• SSR을 설명하는 간단한 이미지

즉, 서버에서 이미 "렌더 가능한" 상태로 클라이언트에 전달되기 때문에, JavaScript가 다운로드 되는 동안 사용자는 무언가를 보고 있을 수 있다.

2. CSR이란?

Client Side Rendering의 약자로 말 그대로 SSR과 달리 렌더링이 클라이언트 쪽에서 일어나며, 서버는 요청을 받으면 클라이언트에 HTML과 JavaSript를 보내주고, 클라이언트는 그것을 받아 렌더링을 시작한다.

위의 그림을 통해 CSR 단계를 설명하자면,

1. 유저가 웹 사이트에 요청을 보낸다.

2. CDN이 HTML 파일과 JavaScript로 접근할 수 있는 링크를 클라이언트로 보낸다.

   CDN이란? AWS의 Cloudflare를 생각하면 되며, 엔트 유저의 요청에 "물리적"으로 가까운 서버에서 요청에 응답하는 방식이다.

3. 클라이언트는 HTML과 JavaScript를 다운로드 받는다.

   이때 SSR과는 달리 유저는 아무것도 볼 수 없다.

4. 다운로드된 JavaScript가 실행되며, 데이터를 위한 API가 호출된다.

   이때 유저들은 placeholder를 보게 된다.

5. 서버가 API로부터의 요청에 응답한다.

6. API로부터 받아온 Data를 placeholder 자리에 넣어주며, 이제 페이지는 상호작용이 가능해진다.

• CSR을 설명하는 간단한 이미지

즉, 서버에서 처리 없이 클라이언트로 보내주기 때문에 JavaScript가 모두 다운로드 되고 실행이 끝나기 전까지 사용자는 볼 수 있는 것이 없다.

3. SSR과 CSR의 차이

3-1. 웹 페이지의 로딩 시간

웹 페이지 로딩의 종류는 두 가지로 나눌 수 있으며, 하나는 웹 사이트의 가장 첫 페이지 로딩, 다른 하나는 나머지 컨텐츠를 로딩하는 것으로 나누어진다.

3-1-1. 첫 페이지 로딩 시간

• CSR HTML, CSS와 모든 스크립트들을 한 번에 불러오는 방식이다.
• SSR 필요한 부분의 HTML과 스크립트만 불러오는 방식이다.

따라서 평균적으로 첫 페이지 로딩 시간은 SSR 방식이 더 빠르다고 볼 수 있다.

3-1-2. 나머지 컨텐츠 로딩 시간

첫 페이지를 로딩한 후, 사이트의 다른 곳으로 이동하는 식의 동작으로 가정한다.

• CSR HTML, CSS와 모든 스크립트들을 첫 페이지 로딩에서 한번에 불러오는 방식이므로 나머지 컨텐츠 부분을 구성하는 코드를 받아왔기 때문에 비교적 빠르게 작동한다.
• SSR 필요한 부분의 HTML과 스크립트만 불러오는 방식이므로 나머지 컨텐츠 부분을 첫 페이지를 로딩한 과정처럼 정확하게 다시 실행하기 때문에 비교적 느리게 작동한다.

따라서 평균적으로 첫 페이지 로딩의 작동 방식의 차이로 인해 나머지 컨텐츠 로딩 시간은 CSR 방식이 더 빠르다고 볼 수 있다.

3-2. SEO 대응

SEO란? SEO(검색 엔진 최적화)는 웹 사이트가 유기적인(무료) 검색 방식을 통해 검색 엔진에서 상위에 노출될 수 있도록 최적화하는 과정을 말하며, 비즈니스 유형이 어떤 것이든 SEO는 가장 중요한 마케팅 유형 중 하나이다.

• CSR CSR은 JavaScript를 실행시켜 동적으로 컨텐츠가 생성되기 때문에, JavaScript가 실행 되어야 meatadata가 바뀌는 방식이다.

  이전 크롤러들은 JavaScript를 실행시키지 않았기에 SEO 최적화가 필수적이었으며, 구글이 그 트렌드를 바꾸고 있다고 한다.

• SSR 애초에 Server Side에서 컴파일되어 클라이언트로 넘어오기 때문에 크롤러에 대응하기 용이하다.

따라서 JavaScript를 실행시켜 동적으로 컨텐츠를 생성하는 CSR에 비해 클라이언트로 넘어오기 전에 JavaScript를 서버 쪽에서 컴파일되기 때문에, SEO에 대응하기에 용이한 방식은 SSR 방식이라고 볼 수 있다.

3-3. 서버 자원 사용

• CSR 클라이언트에서 JavaScript를 실행시켜 컨텐츠를 생성한 후, 서버로 보내기 때문에 서버 자원 사용이 적다.

• SSR 애초에 매번 서버를 통해 JavaScript 컴파일을 오청하기 때문에 서버 자원의 사용이 많을 수 밖에 없다.

  React의 renderToString 메소드를 사용하여 SSR 방식을 구현할 수 있지만, 다음과 같은 문제가 발생한다.

  renderToString 메소드는 스택을 막고 동기적으로 처리하는 방식으로, 메소드가 실행되는 동안 서버가 멈추게 된다.

당연한 말이지만, SSR 방식이 서버 자원 사용량이 많다.

참고로 React가 18버전으로 버전업되면서 NextJS를 사용하여 SSR을 구현하는 것과 달리, React 자체적으로 React-router와 @loadable-component의 조합으로 SSR을 구현할 수 있다.

하지만, CSS는 @loadable-component에서 지원하지 않아, Hot Reload가 아직 불가능하다.

4. SSR과 CSR 사용

4-1. SSR의 사용

• SSR 방식은 각 페이지마다 나누어서 불러오기 때문에 네트워크가 느린 경우

• SEO(검색 엔진 최적화)가 필요한 경우

• 최초 페이지의 로딩이 빨라야 하는 사이트를 개발하는 경우

• 메인 스크립트가 크고, 로딩이 매우 느린 경우

  CSR 방식은 메인 스크립트가 로딩이 모두 끝나고 나서 API로 테이터 요청을 보내지만, SSR 방식은 한 번의 요청에 아예 렌더가 가능한 페이지로 돌아온다.

• 웹 사이트가 상호작용이 많지 않은 경우

4-2. CSR의 사용

• CSR 방식은 한 번에 모든 스크립트를 불러오는 방식으로, 네트워크가 빠른 경우

• 서버 성능이 좋지 않은 경우

• 사용자에게 보여줘야 하는 데이터의 양이 많은 경우

  로딩창을 띄울 수 있는 장점이 있다.

• 메인 스크립트가 가벼운 경우

• SEO(검색 엔진 최적화)에 대해 상관이 없는 경우

• 웹 어플리케이션이 사용자와 상호작용할 것들이 많은 경우

  아예 렌더링 되지 않아서 의도하지 않은 사용자의 행동을 막는 것이 UX 부분에서 오히려 유리함.

참고 사이트

Blog 프로그래밍 - SSR과 CSR의 차이 스타트업코드 - SSR과 CSR의 차이 DylanJu - React로 Next.js처럼 Server-side-rendering 구현하기

클래스는 객체 지향 프로그래밍에서 특정 객체를 생성하기 위해 변수와 메소드를 정의하는 일종의 틀로, 객체를 정의하기 위한 상태(멤버 변수)와 메서드(함수)로 구성된다.

1. JavaScript의 Class

JavaScript에서 class 사용은 ES6에서부터 지원을 하기 시작했으며, 익스플로러에서는 해당 코드 사용이 불가능하나, 최신 브라우저를 이용할 경우 class를 지원한다.

class를 사용하는 가장 큰 이유는 재사용성으로, 작은 사이트의 경우 잘 만든 Function 하나로도 충분히 개발이 용이했다면 좀 더 복잡한 사이트를 만들게 될 경우 class의 장점을 더 잘 알 수 있다고 한다.

1-1. Class의 기본 문법

1-1-1. Class 생성

JavaScript 내에서 class를 생성하려면 간단하며, class를 선언만 해준다면 class 객체를 바로 만들 수 있다.

class Person {

}

let hhj = new Person();

console.log(hhj, 'class 객체 생성');
// Person {} 'class 객체 생성'

class로 만들어준 예시 Perwon이라는 이름의 객체가 생성된다.

1-1-2. Class 초기값 설정

Constructor(생성자)를 이용하면 class 객체의 초기 값을 설정해 줄 수 있다.

class 내부에서 Constructor는 한 개만 존재할 수 있으며, 2번 이상 사용 시 Syntax Error가 발생할 수 있다.

class Person {
  constructor(name, age, city) {
    console.log('construtor'); // construtor
    this.name = name;
    this.age = age;
    this.city = city;
  }
}

let hhj = new Person('hhj', '28', 'Gwangju');

console.log(hhj);
// Person {name: 'hhj', age: '28', city: 'Gwangju'}

위의 코드처럼 Constructor는 새로운 클래스를 생성할 때 가장 처음으로 실행되며 초기값을 설정해준다.

1-1-3. Class 메서드 사용

class에서 설정한 초기값을 접근해 특정 기능을 하는 메서드를 만드는 것도 가능하며, class안에 function 형식으로 만들어준 뒤 해당 메서드를 호출하기만 하면 된다.

class Person {
  constructor(name, age, city) {
    this.name = name;
    this.age = age;
    this.city = city;
  }
  nextYear() {
    return Number(this.age) + 1;
  }
}

let hhj = new Person('hhj', '28', 'Gwangju');

console.log(hhj.nextYear());
// 29

class는 JavaScript 상 객체의 형태이므로 생성된 class 객체에 class 밖에서 새로운 메서드를 넣는 것도 가능하다.

class Person {
  constructor(name, age, city) {
    this.name = name;
    this.age = age;
    this.city = city;
  }
  nextYear() {
    return Number(this.age) + 1;
  }
}

let hhj = new Person('hhj', '28', 'Gwangju');

hhj.eat = function () {
  return 'meat';
}

console.log(hhj.nextYear());
// 29

console.log(hhj.eat());
// meat

class 밖에서 추가한 eat이라는 메서드도 함수로써 작동하지만, 이와 같이 밖에서 추가한 class는 추후 새로운 new Person class로 새로운 객체를 만들 경우에 호출하여 사용할 수 없다.

class Person {
  constructor(name, age, city) {
    this.name = name;
    this.age = age;
    this.city = city;
  }
  nextYear() {
    return Number(this.age) + 1;
  }
}

let hhj = new Person('hhj', '28', 'Gwangju');

hhj.eat = function () {
  return 'meat';
}

console.log('hhj의 내년의 나이 ->', hhj.nextYear());
// hhj의 내년의 나이 -> 29

console.log('hhj의 먹은 음식 ->', hhj.eat());
// hhj의 먹은 음식 -> meat

let hhj2 = new Person('hhj2', '24', 'Chumdan');

console.log('hhj2의 내년의 나이 ->', hhj2.nextYear());
// hhj2의 내년의 나이 -> 25

console.log('hhj2의 먹은 음식 ->', hhj2.eat());
// console.log('hhj2의 먹은 음식 ->', hhj2.eat());
// TypeError: hhj2.eat is not a function

1-2. Class의 상속 (extends)

class에서 상속 개념을 이용할 수 있으며, CSS를 이용한 분들이라면 하나의 속성이 하위 속성에도 같이 적용되는 것처럼 class에서도 상속을 이용하면 기존의 class의 값을 모두 접근하여 사용할 수 있다.

상속은 extends를 써서 이용할 수 있다.

class Person {
  constructor(name, age, city) {
    this.name = name;
    this.age = age;
    this.city = city;
  }
  nextYear() {
    return Number(this.age) + 1;
  }
}

class introducePerson extends Person {
  introduce() {
    return `저는 ${this.name}이며, ${this.city}에서 살고 있고, 나이는 ${this.age}세입니다.`
  }
}

let hhj = new introducePerson('hhj', '28', 'Gwangju');

console.log(hhj.introduce());
// 저는 hhj이며, Gwangju에서 살고 있고, 나이는 28세입니다.

위의 코드와 같이 introducePerson 클래스에서 Person을 상속받았기 때문에 this.city와 this.name을 모두 사용할 수 있는 것을 확인할 수 있다.

1-3. Class의 super 사용

introducePerson 하위 클래스에서 기존 class의 값을 가져다 쓰는 건 좋지만, 추가적으로 introducePerson이라는 하위 클래스에서만 사용하고 싶은 값이 있을 수도 있다.

이때 이용하는 것은 super라는 키워드로, 이는 객체의 부모가 가지고 있는 메서드를 호출할 수 있다.

자식 쪽의 추가적으로 사용할 초기값이 필요할 경우 constructor에 super로 부모 초기값을 세팅한 뒤 자식 class에서만 사용할 초기값을 따로 지정하는 것도 가능하며 super 기능을 이용해서 자식 class에서 부모 메서드를 호출할 수도 있다.

class Person {
  constructor(name, age, city) {
    this.name = name;
    this.age = age;
    this.city = city;
  }
  nextYear() {
    return Number(this.age) + 1;
  }
}

class introducePerson extends Person {
  constructor(name, age, city, job) {
    super(name, age, city);
    this.job = job;
  }

  introduce() {
    return `
    저는 ${this.name}이며, ${this.city}에서 살고 있고, 나이는 ${this.age}세입니다.
    내년에는 ${super.nextYear()}세이며, 하는 일은 ${this.job}입니다.
    `
  }
}

let hhj = new introducePerson('hhj', '28', 'Gwangju', '프론트엔드 개발자');

console.log(hhj.introduce());
// 저는 hhj이며, Gwangju에서 살고 있고, 나이는 28세입니다.
// 내년에는 29세이며, 하는 일은 프론트엔드 개발자입니다.

class를 이용할 경우 규칙성을 갖는 객체를 일관성 있게 만드는 게 가능하며, 상속을 통해서 기능 확장이 용이하다는 것 알 수 있었다.

참고 사이트

김평범's OrdinaryCode - 자바스크립트에서 Class 사용하기 잉룡's Devlog - 생성자(Constructor) 만들기

파싱(Parsing)이란? 프로그래밍 언어로 작성된 파일을 실행시키기 위해 구문 분석(Syntax Analysis)을 하는 단계이다. 파일의 문자열들을 문법적 의미를 갖는 최소 단위인 '토큰'으로 분해하고, 이 토큰들을 문법적인 의미와 구조에 따라 노드라는 요소로 만든다. 이러한 단계에서 노드들은 상하관계를 반영해 트리를 형성하는데, 이 트리를 Parse Tree라고 한다.

렌더링(Rendering)이란? HTML, CSS, JavaScript 파일을 파싱해, 브라우저에 시각적으로 출력하는 과정이다.

1. 브라우저 렌더링 전체 과정

1. 브라우저는 HTML, CSS, JS, 이미지, 폰트 등 리소소를 서버에 요청하고, 응답으로 받아온다.

2. 브라우저 렌더링 엔진은 받아온 HTML, CSS를 파싱해 Dom, CSSOM을 생성하고, 이들을 결합해 Render Tree를 생성한다.

3. 브라우저 JS 엔진은 받아온 JS를 파싱해 AST를 생성하고, 바이트 코드로 변환해 실행한다.

4. 렌더트리를 기반으로 HTML 요소의 레이아웃(위치, 크기)을 계산한다.

5. 화면에 HTML요소를 페인팅한다.

1-1. 요청, 응답

브라우저는 HTML, CSS, JS, 이미지, 폰트 등 리소스를 서버에 요청하고, 응답으로 받아온다.

서버가 가지고 있는 HTML, CSS, JavaScript 파일을 브라우저애서 서버에게 요청하고, 응답으로 받아와야 한다.

브라우저에 있는 주소창에 위와 같은 URL을 입력하고 엔터키를 누르면, URL의 호스트 이름이 DNS(도메인 네임 서비스)를 통해 진짜 주소인 IP 주소로 변환되고, 이 IP 주소를 갖는 서버에게 요청을 보낸다.

서버는 기본적으로 보통 index.html을 응답으로 주도록 설정되어 있다.

예를 들어, https://www.google.com 을 검색하면 사실은 https://www.google.com/index.html을 요청하는 것과 다름 없다.

이 요청에 대해 구글 서버는 클라이언트에 index.html 파일을 전달 해주며, 다른 파일을 요청하고 싶다면 뒤에 다른 파일 경로를 적거나, JavaScript를 통해서 동적으로 요청할 수도 있다.

1-2. 파싱, 생성

1-2-1. HTML 파싱, DOM 생성

브라우저 렌더링 엔진은 받아온 HTML, CSS를 파싱해 DOM, CSSOM을 생성하고, 이들을 결합해 렌더 트리를 생성한다.

응답으로 받아온 HTML 문서는 오직 텍스트로만 이루어져 있다.

이 텍스트들 우리가 알아볼 수 있도록 이 문서를 브라우저가 이해할 수 있는 형태로 바꾸는 작업이 필요한데, 여기서 말하는 형태가 바로 DOM 구조이다.

위의 그림은 서버에서 받아온 파일을 브라우저가 이해하기까지의 과정이다.

1. 바이트 (Bytes) : 서버는 브라우저에게 2진수 형태의 HTML 문서를 응답으로 준다.

2. 문자열 (Characters) : 문서는 <meta>의 charset 속성에 지정된 방식으로 문자열로 인코딩 된다.(ex : UTF-8) 서버는 이 인코딩 방식은 응답 헤더에 담아준다.

3. 토큰 (Tokens) : 문자열 형태의 HTML문서를 '토큰'단위로 분해한다. (문법적 의미를 갖는 코드의 최소 단위)

4. 노드 (Nodes) : 각 토큰을 객체로 변환해, 노드를 생성한다. (DOM을 구성하는 기본 요소)

5. DOM : HTML 문서의 요소들의 중첩관계를 기반으로 노드들을 트리 구조로 구성한다. 이 트리를 DOM이라고 한다.

위와 같은 과정을 거쳐서 HTML 문서가 파싱되고, DOM 이라는 결과물을 생성하게 된다.

위와 같은 복잡한 과정을 거치는 이유는 DOM은 Document Object Model의 줄임말로, 우리말로는 문서 객체 모델이라 할 수 있다.

말 그래도 문서를 객체로 바꾼 모델로, 브라우저는 JavaScript 언어만 알아듣는데, JavaScript는 HTML의 태그나 속성들을 바로 다룰 수 없기 때문에, 다룰 수 있는 형태인 '객체'로 바꿔주어야 한다.

그래야 브라우저도 HTML 문서를 이해할 수 있게 되기 때문에 이러한 과정을 거친다.

1-2-2. CSS 파싱, CSSOM 생성

앞서 html 파일을 파싱하다가 <link>, <style> 태그를 만나면 파싱을 잠시 멈추고 리소스 파일을 서버로 요청한다.

이 태그들은 CSS 파일을 가져올 때 보통 쓰는데, 이렇게 가져온 CSS 파일도 HTML과 마찬가지로 파싱을 한다. 서버에서 받아온 2진수 파일을 문자열로 인코딩하고, 토큰 단위로 나누고, 노드를 생성하고, 트리를 만들고.. 이렇게 파싱해 만든 트리는 CSSOM 이라고 한다.

위의 그림처럼 CSSOM은 CSS의 속성이 상속되기 때문에, 이를 반영한다는 점이다.

예를 들어 ul 이 부모 요소이고, li를 자식 요소로 가진다고 생각하면, 아래 코드처럼 ul는 파란색 속성을 가지고 있는데, 이 속성은 자식 요소인 li도 상속받게 된다.

따라서 li는 상속받은 color: blue와 자신이 가지고 있던 font-size 속성 두 가지를 갖게 된다.

1-2-3. 렌더 트리 생성

DOM과 CSSOM은 굉장히 비슷하게 생겼지만, 서로 다른 속성들을 가진 독립적인 트리들이다.

HTML은 구조를, CSS는 디자인을 담당하기 때문에 둘을 합치는 작업이 필요하다.

렌더 트리는 이름처럼 렌더링을 목적으로 만드는 트리이며, 렌더링은 브라우저가 이제 진짜로 사용자에게 보여주기 위한 화면을 그리는 과정이기 때문에, 보이지 않을 요소들은 이 트리에 포함하지 않는다.

예를 들어, DOM에서는 meta태그같은 정보 전달 목적의 태그나, CSSOM에서는 display: none으로 보이지 않게 해둔 요소(정확히는 노드)들은 렌더 트리에서는 제외된다.

단, visibility: hidden은 레이아웃 트리에 포함되니 주의해야 한다.

위의 그림처럼 DOM, CSSOM에 있던 속성들이 합쳐져 렌더트리를 구성하는 것을 확인할 수 있지만, 렌더 트리는 아직까지도 텍스트로 구성된 객체로 밖에 보이지 않는다.

실제로 우리가 보는 페이지를 만들기 위해서는 '페인팅'이라는 작업을 거쳐야 한다.

페인팅 작업은 렌더트리의 노드들이 가지고 있는 속성들을 바탕으로 이루어지는데, 이 작업은 잠시 후에 다시 자세히 알아보도록 하고 우선은 JavaScript 파일은 어떻게 해석이 되는지부터 잠시 살펴본다.

1-3. JavaScript 파싱

브라우저 JS 엔진은 받아온 JS를 파싱해 AST를 생성하고, 바이트 코드로 변환해 실행한다.

렌더링 엔진은 HTML 파일을 한줄씩 파싱하며 DOM을 생성하다가 JavaScript 코드들 불러오는 <script> 태그를 만날 때도 파싱을 잠시 멈춘다.

그리고 나서 src 속성에 적혀있는 파일을 서버에 요청해 받아오고, 이렇게 받아온 js 파일도 마찬가지로 파싱을 해야하는데, 이 파싱은 브라우저 렌더링 엔진이 직접하지 않고, JavaScript 엔진이 담당하게 된다.

이 때 렌더링 엔진은 JS 엔진에게 제어권을 아예 넘겨주기 때문에, HTML 파싱을 멈췄다가 JS 파싱이 전부 되면 다시 제어권을 돌려받아 파싱을 다시 시작하는 것이다.

JS 엔진은 js 파일의 코드를 파싱해서 컴퓨터가 이해할 수 있는 기계어로 변환하고 실행한다.

좀 더 구체적으로 살펴보면, 먼저 단순한 텍스트 문자열인 코드를 토큰 단위로 분해하며, 이렇게 분해된 토큰에 문법적인 의미와 구조가 더해져, AST(추상 구문 트리) 라는 트리가 완성된다.

구체적인 속성은 다르지만, 이전에 봤던 과정들과 비슷해 보이며, 아래 그림에서 맨 왼쪽의 코드가 바로 다음의 트리 구조로 바뀌는 부분이 여기까지의 내용에 해당한다.

이제 이렇게 코드를 해석해서 만든 AST라는 트리를 실제로 실행할 수 있도록 만들어야 한다.

코드의 실제 실행은 인터프리터가 담당하는데, 인터프리터가 알아들을 수 있도록 하기 위해서는 AST트리를 바이트 코드라는 중간 수준의 코드로 변환해야 한다.

이 변환은 바이트 코드 생성기가 담당해주며, 이제 위의 그림에서 가장 오른쪽에 있는 형태로 바뀌어 받아온 js파일 내용이 실제로 실행된다.

1-4. 레이아웃(리플로우)

렌더 트리를 기반으로 HTML 요소의 레이아웃(위치, 크기)을 계산한다.

레이아웃은 요소의 기하학적인 속성들을 찾는 과정이며, 아까 만들었던 렌더트리가 여기서 사용되니 다시 떠올려야 한다.

렌더 트리에는 요소들의 위치나 크기와 관련된 정보들이 들어있었다.

하지만 이 정보들은 각 요소들에 대한 정보일 뿐, 전체 화면에서 정확히 어디에 위치할 것인지에 대해서는 아직 알지 못하며, 이런 계산을 하는 단계가 레이아웃 단계이다.

브라우저는 각 요소들이 전체 화면에서 어디에, 어떤 크기로 배치되어야 할 지 파악하기 위해 렌더트리의 맨 윗부분부터 아래로 내려가며 계산을 진행하며, 모든 값들은 절대적인 단위인 px값으로 변환된다.

예를들어 우리가 <div>요소 하나만 띄우도록 코드를 작성했고, width를 50%로 지정해두었다면, 이 값은 전체 화면 크기(viewport)의 절반 크기로 계산되고, 절대적인 값인 px 단위로 변환되는 식이다.

1-5. 페인팅

화면에 HTML 요소를 페인팅한다.

이제 위치에 대한 계산도 마쳤으니, 정말로 화면에 보여줄 차례이다.

브라우저 화면은 픽셀이라고 하는 정말 작은 점들로 이루어져 있으며, 각각 정보를 가진 픽셀들이 모여 하나의 이미지, 화면을 구성하는 것이다.

따라서 화면에 색상을 입히고, 어떤 요소를 보여주기 위해서는 이 픽셀에 대한 정보가 있어야 하고, 페인팅은 이러한 픽셀들을 채워나가는 과정이다.

따라서 이 과정을 마지막으로 우리는 단순한 텍스트에 불과했던 파일 내용들을 이미지화된 모습으로 브라우저 화면을 통해 볼 수 있게되는 것이다.

2. Reflow(리플로우), Repaint(리페인트)

리플로우(Reflow) = 레이아웃 계산을 다시하는 것 리페인트(Repaint) = 새로운 렌더트리를 바탕으로 다시 페인트를 하는 것

만약 사용자가 브라우저 화면을 늘리거나 줄이는 등 크기를 조절하거나, 어떤 버튼을 눌러 화면에 요소가 추가되거나 삭제되는 경우가 생기면, 당연히 화면에 있던 요소들의 위치나 크기 등이 바뀌는 일이 생기게 될 것이다.

굉장히 당연하게 여겨지지만, 이렇게 화면에 나타나는 모습을 바꾸기 위해서는 모든 요소들의 위치와 크기를 다시 계산하고, 다시 그려서 보여주어야 한다.

이렇게 어떤 인터랙션으로 인해 앞서 보았던 레이아웃, 페인팅 과정을 반복하는 것을 리플로우, 리페인트라고 한다.

const makeDiv = document.createElement('div');

위의 코드는 JavaScript를 통해 DOM을 조작하는 코드이다.

DOM은 단순히 HTML 파일의 정보만 담고있게 아니라, 이렇게 JavaScript를 통해 요소들을 동적으로 조작할 수 있도록 DOM API라는 것을 제공한다. CSS도 마찬가지로 이런식으로 조작이 가능하다. 이렇게 JavaScript 조작으로 변경이 일어나면, DOM 트리를 다시 구성하는 것으로 시작해 CSSOM와 합쳐져 새 렌더 트리를 생성한다.

그리고 레이아웃과 페인트 과정을 또다시 거쳐서 화면에 보여진다.

DOM 조작은 리플로우, 리페인팅이 일어나는 대표적인 예시라고 할 수 있다.

물론 레이아웃과 페인트는 별개의 작업이기 때문에, 하나 씩만 발생할 수도 있고, 둘 다 발생할 수도 있으며, 위치나 크기에 대한 변경만 있다면 레이아웃 작업만 다시하면 되고, 요소의 색상이나 보이는지 여부 같은 스타일에 대한 사항에 대한 변경만 있다면 페인팅 작업만 다시하면 되기 때문이다.

2-1. Reflow

Reflow는 렌더링 엔진에서 요소를 배치하는 과정을 의미한다.

렌더 트리 구축 단계에서 DOM 트리와 스타일 규칙을 합쳐서 렌더 트리를 만들고, 여기에서 Reflow를 통해 각각의 요소들의 레이아웃을 위치시킨다.

여기서 렌더 트리는 DOM 요소를 기반으로 만들어지지만, 완전히 대응되지는 않는다.

DOM 트리가 문서의 구조를 나타낸다면 렌더 트리는 문서의 시각적 구조를 나타낸다.

예를 들어 스타일에 display: none 속성이 있다면 DOM에는 존재하지만 시각적으로는 없기에 렌더 트리에는 할당되지 않는다.

Reflow가 발생하는 경우는 다음과 같다.

• DOM 노드의 추가, 제거

• DOM 노드의 위치 변경

• DOM 노드의 크기 변경

  margin, padding, border, width, height 등

• CSS3 애니메이션과 트랜지션

• 폰트 변경, 텍스트 내용 변경

• 이미지 크기 변경

• offset, scrollTop, scrollLeft와 같은 계산된 스타일 정보 요청

• 페이지 초기 렌더링

• 윈도우 리사이징

2-2. Repaint

Repaint는 렌더 트리가 탐색되고 paint 메서드가 호출되어서 UI 기반의 구성 요소를 사용해서 그리는 과정이다.

Repaint가 이루어지기 위해서는 렌더 트리가 있어야 하고 따라서 Reflow 작업이 이루어진 후에 Repaint 작업이 이루어지는 것을 알 수 있다.

화면의 구조가 변경이 될 때는 Reflow와 Repaint가 모두 발생한다.

다만 Repaint가 발생하기 위해서 항상 Reflow가 발생해야 하는 것은 아니다.

Reflow가 발생하지 않고 Repaint만 발생하는 경우도 있는데, 예를 들면 레이아웃에 영향을 주지 않는 엘리먼트 개별의 변화에 대해서는 Repaint만 발생한다.

color, background-color, visibility 같은 속성의 경우, 곧바로 Repaint 과정만 발생한다.

2-3. Reflow 최적화

Reflow는 비용을 발생시키는 절차이므로 가능한 안 하는 것이 성능 측면에서 유리하며, 아래의 사항을 통해 Reflow 작업을 줄일 수 있다.

2-3-1. 가장 하위 노드의 클래스를 변경을 통한 스타일 변경

DOM 노드의 크기 또는 위치가 변경되면 하위 노드와 상위 노드에도 영향을 미칠 수 있다.

이 때 가장 하위 노드의 스타일을 변경할 경우, 전체 노드가 아닌 일부 노드로 Reflow를 영향을 최소화 할 수 있다.

전체적으로 큰 노드를 뒤흔드는 것보다 그 하위의 변경할 부분만을 변경하여 Reflow의 규모를 줄이는 방식으로 정리할 수 있다.

2-3-2. 인라인 스타일(inline) 사용 줄이기

인라인 스타일은 HTML이 파싱될 때, 레이아웃에 영향을 미쳐 추가 Reflow를 발생시킨다.

또한 관심사 분리가 제대로 이루어지지 않으면 유지 보수가 힘들어 진다.

2-3-3. 애니메이션이 있는 노드는 position을 fixed 또는 absolute로 지정

애니메이션 효과는 많은 Reflow 비용을 발생시킨다.

position 속성을 fixed 또는 absolute의 값으로 지정해서 지정된 노드를 전체 노드에서 분리시켜 해당 노드에서만 Reflow가 발생하도록 제한시킬 수 있다.

애니메이션 효과를 줘야 하는 노드에 position 속성이 적용이 되지 않았다면 애니메이션 시작 시 position 속성 값을 fixed 또는 absolute로 변경하였다가 애니메이션 종료 후 다시 원복시켜서 렌더링을 최적화 할 수 있다.

2-3-4. table 레이아웃 사용 줄이기

<table>은 점진적으로 렌더링 되지 않고, 모두 로드되고 테이블 너비가 계산된 후에 화면에 그려진다.

테이블 안의 컨텐츠의 값에 따라 테이블 너비가 계산된다는 의미로, 테이블 컨텐츠의 작은 변경만 있어도 테이블 너비가 다시 계산되고 테이블의 모든 노드들이 Reflow가 발생한다.

이러한 이유로 <table>을 레이아웃 용도로 사용하는 일은 피해야 한다.

2-3-5. CSS 하위 선택자 최소화

CSS 하위 선택자를 최소화 하는 것은 Reflow 횟수를 줄이는 방법이 아니라 렌더 트리 계산을 최소화 하는 방법에 대한 내용이다.

• 예시 코드

  <div class="reflow_box">
    <ul class="reflow_list">
      <li>
        <button type="button" class="btn">버튼</button>
      <li>
      <li>
        <button type="button" class="btn">버튼</button>
      <li>
    </ul>
  </div>

• CSS 코드

  /* 잘못된 예 */
  .reflow_box .reflow_list li .btn{
    display:block;
  }
  /* 올바른 예 */
  .reflow_list .btn {
    display:block;
  }

위의 코드처럼 CSS 하위 선택자를 최소화하는 것 또한 렌더링 성능 향상에 도움이 된다.

렌더 트리는 DOM과 CSSOM이 합쳐져서 만들어지는데, DOM은 HTML이 파싱되어 만들어진 트리이고, CSSOM은 CSS가 파싱되어 만들어진 트리이다.

두 트리를 결합하여 렌더 트리를 만드는데, CSS 하위 선택자가 많아지면 CSSOM 트리의 깊이(Depth)가 깊어지게 되고 결국 렌더 트리를 만드는 시간이 더 오래 걸리게 된다.

2-3-6. 숨겨진 노드의 스타일 변경

Reflow 비용을 줄이기 위해서 DOM 노드 사용을 최소화 해야 한다.

한 가지 방법은 DOM Fragment를 사용하여 DOM을 추가할 때 마다 DOM 접근을 최소화 하는 방법이다.

const frag = document.createDocumentFragment();
const ul = frag.appendChild(document.createElement('ul'));

for (let i = 1; i <= 3; i++) {
  li = ul.appendChild(document.createElement('li'));
  li.textContent = `item ${ i }`;
}

document.body.appendChild(frag);

위의 코드처럼 createDocumentFragment를 사용하여 한 번에 DOM을 추가하여 DOM 자체에 직접적인 접근을 최소화할 수 있다.

2-3-7. 캐시 활용

브라우저는 레이아웃 변경을 큐에 저장했다가 한 번에 실행하여 Reflow를 최소화 한다.

하지만 offset, scrollTop과 같은 계산된 스타일 정보를 요청할 때마다 정확한 정보를 제공하기 위해 큐를 비우고 모든 변경 사항을 적용한다.

// 안좋은 예시
for (let i = 0; i < len; i++) {
  el.style.top = `${ el.offsetTop + 10 }px`;
  el.style.left = `${ el.offsetLeft + 10 }px`;
}

// 좋은 예시
let top = el.offsetTop, left = el.offsetLeft, elStyle = el.style;

for (let i = 0; i < len; i++) {
  top += 10;
  left += 10;
  elStyle.top = `${ top }px`;
  elStyle.left = `${ left }px`;
}

이런 낭비를 해결하기 위해 위의 코드와 같이 스타일 정보를 변수에 저장하여 offset, scrollTop 등의 값 요청을 최소화해야 한다.

참고 사이트

joooing - 웹페이지가 사용자에게 보여지기까지 (브라우저 렌더링 과정) CHANYEONG - 브라우저 렌더링과 최적화 Web Frontend Developer - Reflow와 Repaint에 대하여

호이스팅(Hoisting)은 코드를 실행하기 전 변수선언/함수선언을 해당 스코프의 최상단으로 끌어올리는 것이 아닌, 해당 스코프를 최상단으로 끌어 올려진 것 같은 현상을 말한다.

JavaScript 엔진은 코드를 실행하기 전 실행 가능한 코드를 형상화하고 구분하는 과정(실행 컨텍스트를 위한 과정)을 거친다.

실행 컨텍스트란? 실행 가능한 코드가 실행되기 위해 필요한 환경을 의미하고 실행되기 전, 이러한 실행 컨텍스트 과정(코드를 구분하는 과정)을 거친다.

JavaScript 엔진은 코드를 실행하기 전 실행 컨텍스트를 위한 과정에서 모든 선언(var, let, const, function, class)을 스코프에 등록한다.

코드 실행 전, 이미 변수선언/함수선언이 저장되어 있기 때문에 선언문보다 참조/호출이 먼저 나와도 오류 없이 동작한다.

정확히는 var 키워드로 선언한 변수와 함수 선언문일 경우 오류 없이 동작하며, 이는 선언이 파일의 맨 위로 끌어 올려진 것처럼 보이게 한다.

위에서 말한 호이스팅(Hoisting)이라는 현상이란 선언이 코드 실행 보다 먼저 메모리에 저장되는 과정으로 인한 현상을 말한다.

그래서 JavaScript 실행 컨텍스트에 대한 이해하는 것이 호이스팅을 이해하는데 도움이 된다.

scope, hoisting, this, function, closure 등의 동작 원리를 담고 있는 JavaScript 핵심원리이다. 코드를 보고 실행 컨텍스트를 이해할 수 있어야 코드 독해, 디버깅을 할수 있다.

2. 변수 호이스팅 (var, let, const)

JavaScript의 모든 선언에는 호이스팅(Hoisting)이 일어난다.

하지만 let, const, class를 이용한 선언문은 호이스팅이 발생하지 않는 것처럼 동작한다.

var 키워드로 선언된 변수와는 달리 let 키워드로 선언된 변수를 선언문 이전에 참조하면 참조 에러(ReferenceError)가 발생한다.

이러한 현상은 let 키워드로 선언된 변수가 스코프의 시작에서 변수의 선언까지 일시적 사각지대(Temporal Dead Zone, TDZ)에 빠지기 때문이다.

TDZ란? 스코프의 시작 지점부터 초기화 시작 지점까지의 구간을 말하며, let 키워드로 선언된 변수 또한 선언 전, 실행 컨텍스트 변수 객체에 등록이 되어 호이스팅이 되지만, 이 TDZ 구간에 의해 메모리가 할당이 되질 않아 참조 에러(ReferenceError) 발생하는 현상을 말한다.

중요한 점은 이 호이스팅이라는 용어가 선언이 먼저 메모리에 저장되었다는 것을 의미하기 때문에 즉, 선언이 끌어올려진다는 의미이기 때문에 모든 선언은 호이스팅이 일어난다는 말은 참이 된다.

즉, 호이스팅이 파일의 맨 위로 끌어올려진 것 같은 현상을 의미할 때 선언문 이전에 참조해서 에러를 발생시킨다고 호이스팅이 일어나지 않은 것은 아니라는 의미이다.

정확히는 선언이 끌어올려진 현상이지만, 선언이 코드 실행 전에 메모리에 저장되었다는 의미이다.

하지만 이러한 오류가 나는 이유는 var 키워드는 선언과 함께 undefined로 초기화 되어 메모리에 저장되지만, let과 const는 초기화 되지 않은 상태로 선언만 메모리에 저장되기 때문이다.

초기화 되지 않으면 변수를 참조할 수 없으며, 그렇기 때문에 참조 에러(ReferenceError)를 발생시키며, let과 const에도 호이스팅이 일어나기 때문에 에러를 일으키는 것이다.

예시로

let foo = 1;
{
  console.log(foo);
  // Uncaught ReferenceError: Cannot access 'foo' before initialization
  let foo = 2;
}

위의 코드에서 만약에 호이스팅이 일어나지 않는다면 에러가 발생하지 않을 것이다.

하지만 선언과 동시에 호이스팅이 되었기 때문에 블록 스코프에서 foo를 찾을 수 없다.

var foo = 1;
{
  console.log(foo); // 1
  var foo = 2;
  console.log(foo); // 2
}

위의 코드처럼 var 키워드의 경우, 초기 선언과 동시에 undefined로 초기화 되어 메모리에 저장되기 때문에 에러가 나지 않는다.

3. 변수의 생성의 단계와 호이스팅의 원리

3-1. 변수의 생성 단계

변수는 3단계에 걸쳐서 생성된다.

1단계: 선언 단계 (Declaration phase)

• 변수를 실행 컨텍스트의 변수 객체에 등록한다.

• 이 변수 객체는 스코프가 참조하는 대상이 된다.

2단계: 초기화 단계(Initialization phase)

• 변수 객체에 등록된 변수를 위한 공간을 메모리에 확보한다.

• 이 단계에서 변수는 undefined로 초기화 된다.

3단계: 할당 단계(Assignment phase)

• undefined로 초기화된 변수에 실제 값을 할당한다.

3-2. 호이스팅의 원리

3-2-1. var 키워드의 변수 선언

var 키워드로 선언한 변수는 선언 단계와 초기화 단계가 한번에 이뤄지며, 스코프에 변수를 등록(선언 단계)하고 메모리에 변수를 위한 공간을 확보한 후, undefined로 초기화한다.

따라서 변수 선언문 이전에 변수에 접근하여도 스코프에 변수가 존재하기 때문에 에러가 발생하지 않지만, undefined를 반환한다.

이후 변수 할당문에 도달하면 비로소 값이 할당된다.

3-2-2. let, const, class 키워드의 변수 선언

let, const, class 키워드로 선언된 변수는 선언 단계와 초기화 단계가 분리되어 진행되며, 스코프에 변수를 등록(선언 단계)하지만, 초기화 단계는 변수 선언문에 도달했을 때(코드 실행 후) 이뤄진다.

초기화 이전에 변수에 접근하려고 하면 참조 에러(ReferenceError)가 발생하며, 이는 아직 변수가 초기화됮 않았기 때문이다.

즉, 변수를 위한 메모리 공간이 아직 확보되지 않았기 때문에 스코프의 시작 지점부터 초기화 시작 지점까지는 변수를 참조할 수 없다.

4. 호이스팅 예제

4-1. 변수 선언에서의 호이스팅 예시

4-1-1. var 키워드의 호이스팅 예제

// 선언이 끌어올려 지는 것이지 할당이 끌어 올려지는 것이 아니다.

name = 'HHJ';
// 선언 없으면 var로 선언한 것과 동일

console.log(name); // "HHJ"
// 별도의 var 선언 없이도 작동

var name;

4-1-2. let 키워드의 호이스팅 예제

name = 'HHJ';
// 선언 없으면 var로 선언한 것과 동일하게 작동하지만, let의 호이스팅으로 인해 오류

let name;

console.log(name);
// Uncaught ReferenceError: Cannot access 'text' before initialization

4-1-3. 함수 선언의 호이스팅 예제

foo1(); // 함수 선언문에서는 호이스팅 일어남
foo2(); // 함수 표현식이라서 호이스팅이 일어나지 않음

function foo1() {
  console.log('Hello'); // "Hello"
}

var foo2 = function() {
  console.log('world');
  // Uncaught TypeError: foo2 is not a function
}

참고 사이트

HANAMON - [JavaScript] 호이스팅(Hoisting)이란? 우주개발자 블로그 - TDZ(Temporal Dead Zone)이란? 호이스팅에 대한 오해와 진실

REST는 Representational State Transfer의 약자로 자원의 이름으로 구분하여 해당 자원의 상태를 주고 받는 모든 것을 의미한다.

즉 REST란

1. HTTP URI(Uniform Resource Identifier)를 통해 자원(Resource)을 명시하고,

2. HTTP Method(POST, GET, PUT, DELETE, PATCH 등)를 통해

3. 해당 자원(URI)에 대한 CRUD Operation을 적용하는 것을 의미한다.

CRUD Operation이란 CRUD는 대부분의 컴퓨터 소프트웨어가 가지는 기본적인 데이터 처리 기능인 Create(생성), Read(읽기), Update(갱신), Delete(삭제)를 묶어서 일컫는 말로 REST에서의 CRUD Operation 동작 예시는 다음과 같다.

• Create : 데이터 생성(POST)

• Read : 데이터 조회(GET)

• Update : 데이터 수정(PUT, PATCH)

• Delete : 데이터 삭제(DELETE)

1-1. REST 구성 요소

REST는 다음과 같은 3가지로 구성이 되어있다.

• 자원 (Resource) : HTTP URI

• 자원에 대한 행위 (Verb) : HTTP Method

• 자원에 대한 행위의 내용 (Representations) : HTTP Message Pay Load

1-2. REST 특징

• Server-Client (서버-클라이언트 구조)

• Stateless (무상태)

• Cacheable (캐시 처리 가능)

• Layered System (계층화)

• Uniform Interface (인터페이스 일관성)

1-3. REST의 장단점

1-3-1. 장점

• HTTP 프로토콜의 인프라를 그대로 사용하므로 REST API 사용을 위한 별도의 인프라를 구출할 필요가 없다.

• HTTP 프로토콜의 표준을 최대한 활용하여 여러 추가적인 장점을 함께 가져갈 수 있게 해 준다.

• HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능하다.

• Hypermedia API의 기본을 충실히 지키면서 범용성을 보장한다.

• REST API 메시지가 의도하는 바를 명확하게 나타내므로 의도하는 바를 쉽게 파악할 수 있다.

• 여러 가지 서비스 디자인에서 생길 수 있는 문제를 최소화한다.

• 서버와 클라이언트의 역할을 명확하게 분리한다.

1-3-2. 단점

• 표준이 자체가 존재하지 않아 정의가 필요하다.

• HTTP Method 형태가 제한적이다.

• 브라우저를 통해 테스트할 일이 많은 서비스라면 쉽게 고칠 수 있는 URL보다 Header 정보의 값을 처리해야 하므로 전문성이 요구된다.

• 구형 브라우저에서 호환이 되지 않아 지원해주지 못하는 동작이 많다.(ex : 익스플로어)

2. REST API란?

RESPT API란 REST의 원리를 따르는 API를 의미한다.

하지만 REST API를 올바르게 설계하기 위해서는 지켜야 하는 몇가지 규칙이 있으며

• URI는 동사보다는 명사를, 대문자보다는 소문자를 사용하여야 한다.

  ⭕ http://localhost:3000/test ❌ http://localhost:3000/testing ❌ http://localhost:3000/Test

• 마지막에 슬래시(/)를 포함하지 않는다.

  ⭕ http://localhost:3000/test ❌ http://localhost:3000/test/

• 언더바(_) 대신 하이폰(-)을 사용한다.

  ⭕ http://localhost:3000/test-write ❌ http://localhost:3000/test_write

• 파일 확장자는 URI에 포함하지 않는다.

  ⭕ http://localhost:3000/picture ❌ http://localhost:3000/picture.jpg

• 행위를 포함하지 않는다.

  ⭕ http://localhost:3000/article/1 ❌ http://localhost:3000/update-article/1

등의 규칙이 있다.

3. RESTful이란?

RESTful이란 REST의 원리를 따르는 시스템을 의미한다.

하지만 REST를 사용했다 하여 모두가 RESTful 한 것은 아니며, REST API의 설계 규칙을 올바르게 지킨 시스템을 RESTful하다 말할 수 있으며 모든 CRUD 기능을 POST로 처리 하는 API 혹은 URI 규칙을 올바르게 지키지 않은 API는 REST API의 설계 규칙을 올바르게 지키지 못한 시스템은 REST API를 사용하였지만 RESTful 하지 못한 시스템이라고 할 수 있다.

참고 사이트

히진쓰의 서버사이드 기술 블로그 - REST API란? REST, RESTful이란? 컴퓨터는 나의 친구 - REST API에 대해 설명해보자 Heee's Development Blog - REST란? REST API란? RESTful이란?

MVC(모델-뷰-컨트롤러)는 사용자 인터페이스, 데이터 및 논리 제어를 구현하는데 널리 사용되는 소프트웨어 디자인 패턴이다. 소프트웨어의 비즈니스 로직과 화면을 구분하는데 중점을 두고 있으며, 이러한 "관심사 분리" 는 더나은 업무의 분리와 향상된 관리를 제공한다. MVC 에 기반을 둔 몇 가지 다른 디자인 패턴으로 MVVM(모델-뷰-뷰모델), MVP(모델-뷰-프리젠터), MVW(모델-뷰-왓에버) 가 있습니다.

MVC 소프트웨어 디자인 패턴의 세 가지 부분은 다음과 같이 설명할 수 있다.

• Model : 데이터와 비즈니스 로직을 관리
• View : 레이아웃과 화면을 처리
• Controller : 명령을 모델과 뷰 부분으로 라우팅

2. 모델-뷰-컨트롤러 예시

간단한 쇼핑몰을 예시로 하는 자료

2-1. 모델 (Model)

모델은 앱이 포함해야할 데이터가 무엇인지를 정희하며, 데이터의 상태가 변경되면 모델을 일반적으로 뷰에게 알리며(필요에 따라 화면을 변경할 수도 있음) 가끔 컨트롤러에게 알리기도 한다. (업데이트 된 뷰를 제거하기 위해 다른 로직이 필요한 경우)

2-2. 뷰 (View)

뷰는 앱의 데이터를 보여주는 방식을 정의한다.

쇼핑 리스트 앱에서, 뷰는 항목이 사용자에게 보여지는 방식을 정의하며, 표시할 데이터를 모델로부터 받는다.

2-3. 컨트롤러 (Controller)

컨트롤러는 앱의 사용자로부터의 입력에 대한 응답으로 모델 및 뷰를 업데이트하는 로직을 포함한다.

예를 들어, 쇼핑 리스트는 항목을 추가하거나 제거할 수 있게 해주는 입력 폼과 버튼을 갖으며, 이러한 액션들은 모델이 업데이트 되는 것이므로, 입력이 컨트롤러에게 전송되고, 모델을 적당하게 처리한 다음, 업데이트 된 데이터를 뷰로 전송한다.

단순히 데이터를 다른 형태로 나타내기 위해 뷰를 업데이트를 해야 하는 경우(예를 들면, 항목을 알파벳순서로 정렬한다거나, 가격이 낮은 순서 또는 높은 순서로 정렬), 컨트롤러는 모델을 업데이트 할 필요 없이 바로 처리가 가능하다.

3. Web에서의 MVC

웹의 초창기에, MVC 구조는 클라이언트가 폼이나 링크를 통해 업데이트를 요청하거나 업데이트된 뷰를 받아 다시 브라우저에 표시하기 위해 대부분 서버 사이드에서 구현되었다.

반면, 요즘에는 클라이언트 사이드 데이터 저장소의 출현과 필요에 따라 페이지의 일부만 업데이트를 허용하는 XMLHttpRequest 를 포함해 더 많은 로직이 클라이언트 사이드에 추가되었다.

AngularJS 및 Ember.js 와 같은 웹 프레임워크들은 약간씩은 방식이 다르지만, 모두 MVC 구조를 구현한다.

3-1. 대표적인 MVC 프레임워크

참고 사이트

MDN Web Docs - MVC 얄코 - MVC 프레임워크가 뭔가요?

1-1. Stack의 개념

1-1-1. 스택(Stack)이란?

쌓아 올린다는 것을 의미하며, 스택 자료구조라는 것은 책을 쌓는 것처럼 차곡차곡 쌓아 올린 형태의 자료구조를 말한다.

1-2. Stack의 특징

스택은 위의 사진과 같이 구조와 크기의 자료를 정해진 방향으로만 쌓을 수 있고, Top으로 정한 곳을 통해서만 접근할 수 있다. Top에는 가장 위에 있는 자료는 가장 최근에 들어온 자료를 가리키고 있으며, 삽입되는 새 자료는 top이 가리키는 자료의 위에 쌓인다. 스택에서 자료를 삭제할 때도 Top을 통해서만 가능하다. 스택에서 Top을 통해 삽입하는 연산을 push, Top을 통한 삭제하는 연산을 pop이라고 한다.

따라서 스택은 시간 순서에 따라 자료가 쌓여서 가장 마지막에 삽입된 자료가 가장 먼저 삭제되는 후입선출(LIFO, Last-In-First-Out)의 구조를 갖고 있다.

비어있는 스택에서 원소를 추출하려고 할 때, stack underflow라고 하며, 스택이 넘치는 경우, stack overflow라고 한다.

여기서 유래된 사이트가 바로 Stack Overflow 사이트이다. 프로그래밍을 하며 궁금한 것, 막히는 것은 거의 모두 들어있다고 생각해도 과장이 아닌 코딩계의 지식인 느낌.

1-3. Stack의 활용

스택의 특징인 후입선출을 활용하여 여러 분야에서 활용이 가능한데,

• 웹 스라우저 방문기록 (뒤로가기) : 가장 나중에 열린 페이지부터 다시 보여줌
• 역순 문자열 만들기 : 가장 나중에 입력된 문자부터 출력
• 실행 취소 (undo) : 가장 나중에 실행된 것부터 실행을 취소
• 후위 표기법 계산
• 수식의 괄호 검사 : 연산자 우선순위 표현을 위한 괄호 검사

등의 활용이 있다.

1-4. Stack의 장단점

• Top 을 통해 접근하기 때문에 데이터 접근, 삽입, 삭제가 빠르다
• Top 위치 이외의 데이터에 접근할 수 없기 때문에 탐색이 불가능하다. 탐색하려면 모든 데이터를 꺼내면서 진행해야 한다.

2. Queue (FIFO)

2-1. Queue의 개념

큐(Queue)란?

사전적인 의미로는 (무엇을 기다리는 사람, 자동차 등의) 줄, 혹은 줄을 서서 기다리는 것을 의미하며, 일상 생활에서 줄을 서서 기다리거나, 먼저 온 사람의 업무를 처리해주는 것과 같이 선입선출(FIFO, First-In-First-Out) 방식의 자료구조를 말한다.

2-2. Queue의 특징

정해진 한 곳(Top)을 통해서 삽입, 삭제가 이루어지는 스택과는 달리, 큐는 한쪽 끝에서 삽입 작업이, 다른 쪽 끝에서는 살제 작업이 양쪽으로 이루어진다. 이때 삭제 연산만 수행되는 곳을 프론트(front), 삽입 연산만 이루어지는 곳을 리어(rear)로 정하여 각각의 연산 작업만 수행된다. 이때, 큐의 리어에서 이루어지는 삽입 연산을 인큐(enQueue), 프론트에서 이루어지는 삭제 연산을 디큐(dnQueue)라고 한다.

• 큐의 가장 첫 원소를 front / 가장 끝 원소를 rear
• 큐는 들어올 때 rear로 들어오지만 나올때는 front부터 빠지는 특성
• 접근방법은 가장 첫 원소와 끝 원소로만 가능
• 가장 먼저 들어온 프론트 원소가 가장 먼저 삭제

즉, 큐에서 프론트 원소는 가장 먼저 큐에 들어왔던 첫 번째 원소가 되는 것이며, 리어 원소는 가장 늦게 큐에 들어온 마지막 원소가 된다.

2-3. Queue의 활용

큐는 주로 데이터가 입력된 시간 순서대로 처리해야 할 필요가 있는 상황에 이용한다.

• 우선순위가 같은 작업 예약 (프린터의 인쇄 대기열)
• 은행 업무
• 콜센터 고객 대기시간
• 프로세스 관리
• 너비 우선 탐색(BFS, Breadth-First Search) 구현
• 캐시(Cache) 구현

2-4. Queue의 장단점

• 데이터 접근, 삽입, 삭제가 빠르다.
• 큐 역시 스택과 마찬가지로 중간에 위치한 데이터에 대한 접근이 불가능하다.

두 자료구조를 비교하여 하나만 사용하기보다는 활용 방안에 따라서 적절한 자료구조를 선택하여 사용하는 것이 최고로 좋은 프로그래밍인 것 같다.

실전 수익형 웹, 앱 서비스 동물상 테스트 만들기의 3번쨰 영상을 통해 제작된 코드입니다. 해당 내용에 도움이 되는 부분은 링크를 걸어두었습니다!

그럼 시작하도록 하겠습니다!

저번 시간의 경우, Crawling에 대한 이해와 원하는 키워드에 맞춰
이미지 다운로드 자동화 등을 제작해보고 이해하는 포스팅을 했다.
이제 본격적으로 동물상 테스트를 위한 머신러닝을 시도해 볼 차례다.

결국에는 정말 훌륭하게 만들어진 머신러닝 사이트를 사용하여 큰 틀을 짜고 작은 부분들을 내 입맛에 맞게 고치는 작업이다... 머신러닝을 처음부터 끝까지 필자가 만든다?? 1년 밤새도 할 수 있을까 싶다...

1. Teachable Machine을 이용한 머신러닝

우선 머신러닝을 위한 사이트를 이용해야 한다.
위에서도 언급했듯이, 훌륭하게 만들어진 코드를 가져와
수정하는 작업을 거칠 것이기 때문이다.
구글에서 지원받아 운영하고 있는 Teachable Machine이라는 사이트가 있다.
이곳이 필자가 머신러닝을 위해 사용할 사이트이다.
사이트에 들어가보자. 사이트의 메인 화면에 보이는 시작하기를 클릭하면, 프로젝트를 생성할 수 있다.
필자의 작업은 저번 1편에서 다운받았던 동물상 별 연예인의
사진을 데이터로 사용해서 자신의 얼굴을 테스트하는 프로젝트이기 때문에
이미지 프로젝트로 생성했다. 프로젝트 생성 후의 모습이다.
우선 클래스의 이름을 정해야 한다.
클래스의 이름은 쉽게 말하자면 컴퓨터로 따지면 폴더이다.
필자는 클래스 추가를 통해 5개의 클래스를 만들고,
각 클래스에 강아지 상, 고양이 상, 곰 상, 공룡 상, 토끼 상
이렇게 지정을 했다.
그리고 조코딩님이 미리 정리해놓은 정보를 토대로
강아지 상 : 워너원 강다니엘, 엑소 백현, 박보검, 송중기
고양이 : 워너원 황민현, 엑소 시우민, 강동원, 이종석, 이준기
곰 : 마동석, 조진웅, 조세호, 안재홍
공룡 : 김우빈, 윤두준, 이민기, 육성재, 공유
토끼 : 방탄소년단 정국, 아이콘 바비, 워너원 박지훈, 엑소 수호
이렇게 정해주고 각 클래스에 사진을 넣어주었다. 이렇게 정리된 폴더를 통째로 넣으면 끝난다.
굉장히 편리한 사이트였다.
이렇게 각 클래스에 사진을 업로드를 했다면 자료를 다듬어야 한다.
즉, 데이터 클렌징이라는 작업을 시작할 것이다.
데이터 클렌징이란, 사진이나 기타 데이터가 될 자료들 중에
필요없거나, 있으면 오히려 정확도가 저하될만한 자료들을
삭제해 줌으로써 정확도의 향상을 위해 일종의 자료 필터링을 하는 것이다.
특히, 필자의 경우에는 BeautifulSoup를 통해 키워드에 맞춰 일괄적으로
이미지를 다운받았기 때문에 더더욱 필요한 작업이다. 위의 이미지에서 빨간 네모 부분에 있는 🗑️ 이런 모양의 휴지통을 클릭하고
이미지 확인 후, 삭제를 시작하면 된다.
필자는 삭제할 이미지의 기준을 잡을 때,
물건에 얼굴이 가려진 사진, 키워드와 맞지 않은 사진, 얼굴이 한 개 이상인 사진, 얼굴이 나오지 않은 사진
이렇게만 걸러도 나쁘지 않은 결과를 얻을 수 있을 것이다. 이렇게 데이터 클렌징 작업을 마치고 각 클래스에 담겨있는 사진들을
참고할 모델로써 학습을 시키도록 해보자.
모델 학습시키기를 클릭하면, 이렇게 학습 중...이라는 문구와 함께 열심히 학습을 한다. 학습을 끝낸 후의 모습이다.
우측을 qhaus Webcam 부분을 파일로 바꿔주어야 테스트를 진행할 때
이미지 업로드를 통해 테스트를 할 수 있다. 대표적인 고양이 상인 가수 GD의 테스트 결과이다.
비교적 사진이 잘 나와서 그런지 고양이 상이 83%로 높게 나왔다. 다음으로는 곰 상으로 알려진 배우 곽도원의 테스트 결과이다.
그냥 곰 상으로 나와버렸다.
어? 그럼 무난하게 성공한거네? 라고 생각하고 정말 대표적인 공룡 상,
가수 TOP를 넣어봤다. ??????
아...아닌가?
그럼 더 공룡 상으로 알려진 배우 류준열로 해보았다. 이게 무슨 일이지....
사실 오류가 아니고 동물 상이라는 것은 지극히 주관적이기도 하고,
헤어스타일, 옷차림, 조명, 표정 등을 학습하게 되면서
수많은 변수에 따라 결과가 정확하지 않을 수 밖에 없다.
어찌보면 당연하다.
해당 편의 영상에서 조코딩님의 설명을 덧붙이자면,
사진의 색을 전부 흑백으로 처리하고, 얼굴 부분만을 학습시킨다면
보다 정확한 결과가 나올 것이라고 한다.
하지만 그렇게까지는 하지 않을 예정이다.
추후에 다른 주제로 해볼법 한 작업임은 틀림없다.
이제 이렇게 머신러닝은 끝났고, 이제 해당 링크와 코드를 불러와야 한다. 위의 이미지처럼 모델 업로드를 클릭하고, 모델 업로드가 끝나면 링크와 함께 JavaScript 코드가 나온다.
위의 링크의 경우 타인이 언제든지 이 링크를 들어와서
필자가 만든 동물상 테스트를 할 수 있는 링크이다.
동물상 테스트 사이트 👈 여기로 들어가면 된다.
하지만 필자는 그 밑의 JavaScript 코드를 수정해서 웹을 만들 예정이다. 위의 이미지에서 빨간 네모 부분의 복사📃를 클릭해 코드를 복사하고,
미리 만들어둔 HTML 파일에 에디터를 통해 <body> 태그 안에 붙여넣어 준다.
필자의 경우, HTML이 너무 복잡해질 것 같아서 js 파일을 따로 만들고
<script> 부분을 js 파일에 따로 넣어주었다.
그 후에 저장을 하고 실행을 시키면? 초라하지만 일단 성공은 한 셈이다.
Start를 클릭하면 학습한 모델을 불러오면서 웹캠이 켜지고,
웹캠에 비춰지는 얼굴에 따라 동물상을 수치로 나타내는 웹이다.
하지만 필자는 웹캠이 없어서 그런지 반응을 하지 않았다.
뭐 문제될 것은 없는 것이 웹캠은 쓰지 않을 예정이고,
이미지 업로드를 하고 그에 맞춰서 테스트를 하는 것에만 신경쓰자!

2. 웹캠에서 이미지 업로드 형식으로

앞서 설명했듯이 웹캠을 사용하지 않고 이미지 업로드를 통해
동물상 테스트를 할 예정이다.
이미지 업로드를 위한 코드를 작성해야 하지만...
구글링을 통해 템플릿을 찾아보도록 했다.

2-1. 이미지 업로드 템플릿 사용

우선 키워드는 image upload template로 검색했다.
그렇게 뜨는 사이트인 colorlib의 File Upload Input를 들어가봤다. 이런 식으로 간단한 프리뷰가 가능한 사이트가 나왔으며,
이미지의 빨간 네모로 체크된 곳을 클릭해서 각 HTML 코드와
CSS 코드, JS 코드 등을 복사해서 사용하면 된다.
만약에 이 코드를 사용하여 수익을 창출한다고 하면,
쭉 스크롤을 내려서 License를 유심히 주의 깊게 봐야 한다.
해당 코드의 License를 보자면,

Copyright (c) 2022 by Aaron Vanston (https://codepen.io/aaronvanston/pen/yNYOXR)

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

영어라 보기 힘들다면 번역기를 통해 좀 더 쉽게 알아보자!

Copyright (c) 2022 by Aaron Vanston (https://codepen.io/aaronvanston/pen/yNYOXR)

이에 따라 이 소프트웨어 및 관련 문서 파일("소프트웨어")의 사본을 입수한 사람에게 사용, 복사, 수정, 병합 권한을 포함하되 이에 국한되지 않는 제한 없이 소프트웨어를 취급할 수 있는 권한이 무료로 부여됩니다. 다음 조건에 따라 소프트웨어 사본을 게시, 배포, 재라이센스 부여 및/또는 판매하고 소프트웨어가 제공된 사람에게 그렇게 하도록 허용합니다.

위의 저작권 표시 및 이 허가 표시는 소프트웨어의 모든 사본 또는 상당 부분에 포함되어야 합니다.

소프트웨어는 상품성, 특정 목적에의 적합성 및 비침해에 대한 보증을 포함하되 이에 국한되지 않는 어떠한 종류의 명시적 또는 묵시적 보증 없이 "있는 그대로" 제공됩니다. 어떤 경우에도 저자 또는 저작권자는 계약, 불법 행위 또는 기타의 행위로 인해 소프트웨어 또는 다른 거래와 관련하여 발생하는 청구, 손해 또는 기타 책임에 대해 책임을 지지 않습니다. 소프트웨어.

제한 없이 소프트웨어를 취급할 수 있는 권한이 무료로 부여됩니다.
제한없이 사용은 가능하다는 뜻인데,

소프트웨어 사본을 게시, 배포, 재라이센스 부여 및/또는 판매하고 소프트웨어가 제공된 사람에게 그렇게 하도록 허용합니다.

위의 저작권 표시 및 이 허가 표시는 소프트웨어의 모든 사본 또는 상당 부분에 포함되어야 합니다.

위의 문구를 보면 위의 저작권 표시 및 이 허가 표시는 소프트웨어의 모든 사본 또는 상당 부분에 포함
이 부분이 눈에 띈다.
결국 이 코드를 사용하기 위해서는 저 License 전체를
코드에 삽입해야 한다는 의미이다.
그렇다면 위의 이미지에 있는 빨간 네모 부분의 Copy를 눌러 복사 후,
사용할 코드의 HTML 부분에 <!-- --> 이렇게 주석처리를 통해
어딘가에 붙여넣어주면 된다.
꼭 보이는 화면에 출력될 필요는 없기에 주석을 사용한 것이다.
이제 웹을 열어보면? 아주 수월하게 진행되고 있는 느낌이 든다.

당연하게 수월한 것이, 다른 사람들이 만들어 놓은 코드를 어떻게 보면 짜집기를 통해서 만들고 있기 때문에 수월할 수 밖에 없다는 걸 지금 블로그에 포스팅을 하면서 뼈저리게 깨닫게 된다. 하지만 이러한 과정도 성장의 일부라고 생각하고 열심히 해보자!

자! 그럼 여기서 코드의 중간점검을 할 시간이다.

<!-- HTML 코드 -->

<html lang="kor">
<head>
    <meta charset="UTF-8">
    <link rel="stylesheet" href="style.css">
    <title>Animal Test</title>
</head>
<body>
      <!-- Teachable Machine Start 버튼 -->
    <div>Teachable Machine Image Model</div>
    <button type="button" onclick="init()">Start</button>

      <!-- 이미지 업로드 코드 -->
    <script class="jsbin" src="https://ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js"></script>
    <div class="file-upload">
        <button class="file-upload-btn" type="button" onclick="$('.file-upload-input').trigger( 'click' )">AddImage</button>
        <div class="image-upload-wrap">
            <input class="file-upload-input" type='file' onchange="readURL(this);" accept="image/*" />
            <div class="drag-text">
                <h3>Drag and drop a file or select add Image</h3>
            </div>
        </div>
        <div class="file-upload-content">
            <!-- <img class="file-upload-image" src="#" alt="your image" /> -->
            <img class="file-upload-image" id="upload-image" src="#" alt="your image" />
            <div class="image-title-wrap">
                <button type="button" onclick="removeUpload()" class="remove-image">Remove <span class="image-title">Uploaded Image</span></button>
            </div>
        </div>
    </div>

    <!-- 웹캠, 테스트 결과 창 -->
    <div id="webcam-container"></div>
    <div id="label-container"></div>

      <!-- jsdelivr의 src -->
    <script src="https://cdn.jsdelivr.net/npm/@tensorflow/tfjs@1.3.1/dist/tf.min.js"></script>
    <script src="https://cdn.jsdelivr.net/npm/@teachablemachine/image@0.8/dist/teachablemachine-image.min.js"></script>

      <!-- 따로 생성한 js 파일의 src -->
    <script src="scripts.js"></script>
</body>

<!-- Copyright (c) 2022 by Aaron Vanston (https://codepen.io/aaronvanston/pen/yNYOXR)

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated
documentation files (the "Software"), to deal in the Software without restriction, including without limitation the
rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit
persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the
Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE
WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR
COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. -->

</html>

/* CSS 파일 */

body {
    font-family: sans-serif;
    background-color: #eeeeee;
}

.file-upload {
    background-color: #ffffff;
    width: 600px;
    margin: 0 auto;
    padding: 20px;
}

.file-upload-btn {
    width: 100%;
    margin: 0;
    color: #fff;
    background: #1FB264;
    border: none;
    padding: 10px;
    border-radius: 4px;
    border-bottom: 4px solid #15824B;
    transition: all .2s ease;
    outline: none;
    text-transform: uppercase;
    font-weight: 700;
}

.file-upload-btn:hover {
    background: #1AA059;
    color: #ffffff;
    transition: all .2s ease;
    cursor: pointer;
}

.file-upload-btn:active {
    border: 0;
    transition: all .2s ease;
}

.file-upload-content {
    display: none;
    text-align: center;
}

.file-upload-input {
    position: absolute;
    margin: 0;
    padding: 0;
    width: 100%;
    height: 100%;
    outline: none;
    opacity: 0;
    cursor: pointer;
}

.image-upload-wrap {
    margin-top: 20px;
    border: 4px dashed #1FB264;
    position: relative;
}

.image-dropping,
.image-upload-wrap:hover {
    background-color: #1FB264;
    border: 4px dashed #ffffff;
}

.image-title-wrap {
    padding: 0 15px 15px 15px;
    color: #222;
}

.drag-text {
    text-align: center;
}

.drag-text h3 {
    font-weight: 100;
    text-transform: uppercase;
    color: #15824B;
    padding: 60px 0;
}

.file-upload-image {
    max-height: 200px;
    max-width: 200px;
    margin: auto;
    padding: 20px;
}

.remove-image {
    width: 200px;
    margin: 0;
    color: #fff;
    background: #cd4535;
    border: none;
    padding: 10px;
    border-radius: 4px;
    border-bottom: 4px solid #b02818;
    transition: all .2s ease;
    outline: none;
    text-transform: uppercase;
    font-weight: 700;
}

.remove-image:hover {
    background: #c13b2a;
    color: #ffffff;
    transition: all .2s ease;
    cursor: pointer;
}

.remove-image:active {
    border: 0;
    transition: all .2s ease;
}

// JavaScript 파일

// Teachable Machine 코드
// More API functions here:
// https://github.com/googlecreativelab/teachablemachine-community/tree/master/libraries/image
// the link to your model provided by Teachable Machine export panel
const URL = "https://teachablemachine.withgoogle.com/models/WXmTZBNlH/";

let model, webcam, labelContainer, maxPredictions;

// Load the image model and setup the webcam
async function init() {
        const modelURL = URL + "model.json";
const metadataURL = URL + "metadata.json";

// load the model and metadata
// Refer to tmImage.loadFromFiles() in the API to support files from a file picker
// or files from your local hard drive
// Note: the pose library adds "tmImage" object to your window (window.tmImage)
model = await tmImage.load(modelURL, metadataURL);
maxPredictions = model.getTotalClasses();

// Convenience function to setup a webcam
const flip = true; // whether to flip the webcam
webcam = new tmImage.Webcam(200, 200, flip); // width, height, flip
await webcam.setup(); // request access to the webcam
await webcam.play();
window.requestAnimationFrame(loop);

// append elements to the DOM
document.getElementById("webcam-container").appendChild(webcam.canvas);
labelContainer = document.getElementById("label-container");
for (let i = 0; i < maxPredictions; i++) { // and class labels
    labelContainer.appendChild(document.createElement("div"));
        }
    }

async function loop() {
    webcam.update(); // update the webcam frame
await predict();
window.requestAnimationFrame(loop);
    }

// run the webcam image through the image model
async function predict() {
        // predict can take in an image, video or canvas html element
        const prediction = await model.predict(webcam.canvas);
for (let i = 0; i < maxPredictions; i++) {
            const classPrediction =
prediction[i].className + ": " + prediction[i].probability.toFixed(2);
labelContainer.childNodes[i].innerHTML = classPrediction;
        }
    }

// 이미지 업로드 JavaScript 코드
function readFile(input) {
    if (input.files && input.files[0]) {
        var reader = new FileReader();

        reader.onload = function (e) {
            var htmlPreview =
                '<img width="200" src="' + e.target.result + '" />' +
                '<p>' + input.files[0].name + '</p>';
            var wrapperZone = $(input).parent();
            var previewZone = $(input).parent().parent().find('.preview-zone');
            var boxZone = $(input).parent().parent().find('.preview-zone').find('.box').find('.box-body');

            wrapperZone.removeClass('dragover');
            previewZone.removeClass('hidden');
            boxZone.empty();
            boxZone.append(htmlPreview);
        };

        reader.readAsDataURL(input.files[0]);
    }
}

function reset(e) {
    e.wrap('<form>').closest('form').get(0).reset();
    e.unwrap();
}

$(".dropzone").change(function () {
    readFile(this);
});

$('.dropzone-wrapper').on('dragover', function (e) {
    e.preventDefault();
    e.stopPropagation();
    $(this).addClass('dragover');
});

$('.dropzone-wrapper').on('dragleave', function (e) {
    e.preventDefault();
    e.stopPropagation();
    $(this).removeClass('dragover');
});

$('.remove-preview').on('click', function () {
    var boxZone = $(this).parents('.preview-zone').find('.box-body');
    var previewZone = $(this).parents('.preview-zone');
    var dropzone = $(this).parents('.form-group').find('.dropzone');
    boxZone.empty();
    previewZone.addClass('hidden');
    reset(dropzone);
});

function readURL(input) {
    if (input.files && input.files[0]) {
        var reader = new FileReader();
        reader.onload = function (e) {
            $('.image-upload-wrap').hide();
            $('.file-upload-image').attr('src', e.target.result);
            $('.file-upload-content').show();
            $('.image-title').html(input.files[0].name);
        };
        reader.readAsDataURL(input.files[0]);
    } else {
        removeUpload();
    }
}

function readURL(input) {
    if (input.files && input.files[0]) {

        var reader = new FileReader();

        reader.onload = function (e) {
            $('.image-upload-wrap').hide();

            $('.file-upload-image').attr('src', e.target.result);
            $('.file-upload-content').show();

            $('.image-title').html(input.files[0].name);
        };

        reader.readAsDataURL(input.files[0]);

    } else {
        removeUpload();
    }
}

function removeUpload() {
    $('.file-upload-input').replaceWith($('.file-upload-input').clone());
    $('.file-upload-content').hide();
    $('.image-upload-wrap').show();
}
$('.image-upload-wrap').bind('dragover', function () {
    $('.image-upload-wrap').addClass('image-dropping');
});
$('.image-upload-wrap').bind('dragleave', function () {
    $('.image-upload-wrap').removeClass('image-dropping');
});

2-2. 전체적인 코드 리뷰

앞서 템플릿을 통해 이미지 업로드까지 구현했다.
이제는 업로드 된 이미지를 동물상 테스트에 적용해야 한다.
우선 코드에 사용된 웹캠의 잔재를 전부 없애야 한다.
그럼 간단히 코드 리뷰를 해야 하는데,

<button type="button" onclick="init()">Start</button>

위의 코드는 index 파일의 HTML 코드의 일부분이다.
작동되는 순서에 따라 리뷰를 하자면, 우선 만들어진 웹의 Start 버튼을
클릭하게 되면, 임의의 함수인 init 함수가 실행된다.
init 함수는 JavaScript 코드의 함수이기에
JavaScript 파일로 넘어가도록 한다.

async function init() {
        const modelURL = URL + "model.json";
const metadataURL = URL + "metadata.json";

우선 위의 코드는 Start 버튼을 클릭하면서 init 함수가 실행되고,
Teachable Machine에서 학습시켰던 model.json와 metadata.json을
초기값으로 불러오게 된다.

init 자체가 초기화라는 의미로 곧 잘 사용되는 것을 보면, 임의의 함수를 만드는 작업에 쓰이는 init은 초기값을 의미하는 함수로 보인다. 예를 들면, 에디터 툴과 Git의 연동 작업에서 git init 명령어를 통해 GitHub의 로컬 저장소를 초기화할 때 사용하는 단어가 바로 init의 경우다.

여담은 이제 그만하도록 하고, 다음 코드를 보겠다.

model = await tmImage.load(modelURL, metadataURL);
maxPredictions = model.getTotalClasses();

한 줄씩 리뷰를 하자면,
init 함수를 실행시키면서 model.json와 metadata.json을 load하는 작업을
model이라는 변수에 담아두고, model에 해당하는 앞서 지정한 모든 Class들을
예측할 수 있도록 불러오는 작업을 하고,

const flip = true;
webcam = new tmImage.Webcam(200, 200, flip);
await webcam.setup();
await webcam.play();
window.requestAnimationFrame(loop);

웹캠을 좌우 반전시키고 넓이 등을 설정, 웹캠에 접근해서 실행시키도록 하고,
웹캠이 실행되면서 loop 반복문을 실행시키는 코드로 이해했다.

document.getElementById("webcam-container").appendChild(webcam.canvas);
labelContainer = document.getElementById("label-container");
for (let i = 0; i < maxPredictions; i++) {
    labelContainer.appendChild(document.createElement("div"));
        }
    }

다음 위의 코드를 간단하게 보자면,
웹캠을 출력할 container를 만들어주고, 자식요소로 웹캠을 띄울 canvas를
생성해준다!!..라고 이해했다...
그럼 웹캠의 실행으로 작동하는 loop 반복문 부분을 보자면,

async function loop() {
    webcam.update();
await predict();
window.requestAnimationFrame(loop);
    }

웹캠이 업데이트가 되면 반복해서 동물상 예측을 하고,
웹캠의 움직임에 따라 계속해서 loop 함수를 실행하는 코드이다.
그럼 여기서 나오는 예측이라는 predict는 무엇인가?
다음 코드에서 등장한다.

async function predict() {
        const prediction = await model.predict(webcam.canvas);
for (let i = 0; i < maxPredictions; i++) {
            const classPrediction =
prediction[i].className + ": " + prediction[i].probability.toFixed(2);
labelContainer.childNodes[i].innerHTML = classPrediction;
        }
    }

위의 코드는 predict라는 동물상 예측 함수이다.
이해한 바로 간단하게 리뷰해 보자면,
하나의 영상이라는 차원의 webcam.canvas를 이미지로써 예측하도록 지정하고,
앞서 model.json와 metadata.json을 모든 클래스에서 예측하도록 지정해 둔
maxPredictions를 for문을 사용하여 예측을 반복해서 결과를
도출할 수 있도록 코드가 짜여져 있다.
그렇게 나온 동물상 예측 결과를
<예측 결과의 className> : <예측 결과의 확률> 형식으로
HTML에 출력하면서 결과가 나온다.
예시로 들자면, 곰 상 : 0.845 이런 식이다.

2-3. 업로드된 이미지 적용하기

본격적으로 앞서 리뷰했던 코드에서 웹캠 부분을 이미지로 변경하거나,
아예 사용되지 않는 웹캠은 삭제하는 작업을 하도록 하겠다.
일단 간단하게 생각할 수 있는 부분은 바로 반복문의 필요성이다.
웹캠의 경우 계속해서 움직이는 모습을 반복적으로 예측을 해야 하기 때문에
반복문을 사용해서 끊임없이 값이 변동한다.
하지만 이미지는?
그런거 없다. 깔끔하게 멈춰있다.
그럼 당연히! 반복문은 OUT!
당연히 웹캠이라는 단어도 전부 지워보도록 하겠다.

const URL = "https://teachablemachine.withgoogle.com/models/WXmTZBNlH/";

let model, webcam, labelContainer, maxPredictions;

async function init() {
        const modelURL = URL + "model.json";
const metadataURL = URL + "metadata.json";

model = await tmImage.load(modelURL, metadataURL);
maxPredictions = model.getTotalClasses();

// 웹캠, loop 부분 삭제
/*const flip = true;
webcam = new tmImage.Webcam(200, 200, flip);
await webcam.setup();
await webcam.play();
window.requestAnimationFrame(loop);*/

// 웹캠 부분 삭제
// document.getElementById("webcam-container").appendChild(webcam.canvas);
labelContainer = document.getElementById("label-container");
for (let i = 0; i < maxPredictions; i++) {
    labelContainer.appendChild(document.createElement("div"));
        }
    }

// 반복문 삭제
/*async function loop() {
    webcam.update();
await predict();
window.requestAnimationFrame(loop);
    }*/

// 웹캠 부분 삭제
async function predict() {
        // const prediction = await model.predict(webcam.canvas);
          // 이 부분에 이미지를 예측하도록 수정한다.
for (let i = 0; i < maxPredictions; i++) {
            const classPrediction =
prediction[i].className + ": " + prediction[i].probability.toFixed(2);
labelContainer.childNodes[i].innerHTML = classPrediction;
        }
    }

위의 코드에서 이제 해야 할 것은 이미지 업로드!
우선 웹캠의 id값을 getElementById로 불러와서 예측했다는 것을
위의 코드에서 삭제한 웹캠 부분을 통해서 볼 수 있다.

document.getElementById("webcam-container").appendChild(webcam.canvas);

바로 이 부분이다!
웹캠은 자식요소로 canvas를 HTML에 띄워주는 작업을 했지만,
이미지는 그런거 필요 없다.
자식요소 생성의 appendChild부분은 과감하게 없애주도록 하고,
이미지를 사용할 수 있는 코드를 구글링으로 찾아보도록 하자!
전체적으로 코드를 쭉 보다가 주석에 GitHub 주소를 찾았다.
teachable machine GitHub 이 링크이며,
Teachable Machine 공식 GitHub이다.
사용 설명서와 같은 느낌으로 작성되어 있어서 쭉 내리며 찾던 중,

model.predict(
  image: HTMLImageElement | HTMLCanvasElement | HTMLVideoElement | ImageBitmap,
  flipped = false
)

이러한 코드를 찾았다.
내용은 model.predict()의 인자로 이미지나, 캔ㄴ버스, 비디오 등이 들어갈 수 있고,
좌, 우 반전을 할지의 여부를 인자로 입력하면 된다고 한다.

model.predict(image, false);

이렇게 말이다.
웹캠 대신, 이미지를 넣기는 했지만, 이미지의 해당 id를 불러도록 id값을 찾는
작업을 시작하도록 한다.
간단하다. 아주. 개발자 메뉴를 통해 이미지의 id값은 upload-image라는 것을 알아냈다.
정리해서 코드를 보자면,

async function predict() {
          var image = document.getElementById("upload-image");
          // 해당 이미지의 id 가져오기
        const prediction = await model.predict(image, false);
          // 이미지로써의 예측을 실행하도록 수정
for (let i = 0; i < maxPredictions; i++) {
            const classPrediction =
prediction[i].className + ": " + prediction[i].probability.toFixed(2);
labelContainer.childNodes[i].innerHTML = classPrediction;
        }
    }

일단 필자가 이해한 바로만 주절주절 설명했다.
기타 CSS, 이미지 템플릿 관련된 사항은 생략하도록 하겠다...
마지막으로 웹캠을 이용할 시에 자동으로 예측되는 것을
사진을 올리고, 버튼을 클릭하는 방식으로 바꿔야 한다.
다시 HTML 코드로 돌아와서 Start 버튼 옆에

<button type="button" onclick="predict()">Predict</button>

이렇게 predict() 함수를 실행시키는 버튼을 만들어
Start 버튼 클릭 → 얼굴 사진 올리기 → Predict 버튼으로 결과 출력
이러한 순서로 동물상 테스트를 할 수 있는 웹을 만들었다. 필자는 공룡 상 98%가 나왔다.
난생 처음 들어봤다... 공룡 상... 뭐... 결과는 나왔다! 아마 데이터로써의 자료가 부족했던 것 같다.
안일하게 너무 적은 데이터를 사용하긴 했다.
여러가지로 어려운 시간이었다.

물론 프로그래밍 코드를 짠 것에 대한 것보다도, 이해하고 해석하는 부분이 굉장히 어려운 부분이 많았다. 하나씩 차근차근 영어 뜻 생각하며 해석을 해보고 이해하려고 노력은 했다...노력은... 사실 위의 내용이 맞는 지도 작성하면서도 긴가민가한 부분이 많았다. 추후에 다른 수업을 통해 늘도록 열심히 하는 수 밖에...

마치며...

우선 위의 과정을 거치며 만들어진 웹을 보고 느낀점은...
프로젝트 구상을 처음부터 다시 해서 다른 데이터를 통해 다른 결과를
도출하는, 코드는 같을 수 있지만, 학습된 데이터를 다르게 하고
다른 결과물이 나오는 음...예를 들면 동안 테스트? 이런 것을 다시 만들어 보고 싶다.
아니 만들어야겠다.
이렇게 쭉 이어간다면 충분히 가능할 것 같다.
일단 인터페이스를 좀 꾸미고 편의성을 갖춘 완성된 웹을 만들고
추후에 도전해봐야겠다.
다음 시간에는 인터페이스, 편의성을 고려해서 웹을 좀 꾸밀 예정이다.

물론 지금도 잘 관리하고 있다고는 전혀 말할 수 없는 입장이다... 그래도 무지성 삭제를 해서 탈모에 걸린 잔디를 보고 싶지는 않았다. 적어도 Repository를 합치면 기존에 Commit 했던 것들이 사라지지는 않기 때문에 PC 디렉토리 정리하는 것처럼 쉽게 생각해서 도전했지만 어렵다보니까 글로 남겼다...

1. 새로운 Repository 생성

우선 GitHub에 접속해서 Repository를 먼저 생성한다. 생성은 위의 이미지에서 📔New 부분을 클릭해서 생성하면 된다. 📔New를 클릭한 후,
위의 이미지처럼 Repository Name을 작성한다.
물론 Repository Name은 개인의 취향대로 입력하면 된다. 위의 이미지처럼 Public으로 설정해주면 된다. 위에 보이는 Add a README file을 체크해주면서 Repository 내에 파일을 하나 생성해준다.

2. 생성한 Repository 로컬 저장소로 Clone

이제 위에 보이는 Code ▼를 클릭하면 보이는 https 주소를 복사한다.
그 후로 로컬 저장소에 Clone(복사의 개념)할 차례이다.
cmd를 통해서

git clone https://복사한/git/주소.git

만약에 로컬 저장소가 없다면 git init을 입력해준다. 성공한 모습이다.

cd Clone한\디렉토리\경로\생성한Repository이름

#Example
cd C:\Users\ADMIN\merge_test

그 후, 위의 코드를 통해 Clone한 폴더로 이동한다.

3. 기존의 Repository 옮기기

새로 생성한 Repository로 들어갈 기존의 Repository의 주소를 복사한다.

git subtree add --prefix=기존Repository이름 기존Repository주소 기존RepositoryBranch

# Example
git subtree add --prefix=test_son https://github.com/HyungJinHan/test_son.git main

성공한 모습이다.
현재의 진행 상황은 생성한 Repository를 로컬 저장소에 Clone했고,
로컬 저장소의 Clone 디렉토리에 옮겨질 기존의 Repository가 들어가 있는 상황이다.
또한 cmd 상으로는 생성한 Repository의 로컬 저장소의
디렉토리에 머물러있는 상태이다.
물론 로컬 저장소에서만의 진행 상황이다.
GitHub에는 아직 동기화를 하지 않은 상태이다.

4. GitHub와 로컬 저장소 동기화

마지막으로 GitHub와 로컬 저장소를 동기화 할 차례이다.
다른 말로 표현하자면 push라고 한다.

git push

위의 코드를 입력해서 GitHub에 push를 해주면 동기화가 된다. 성공한 모습이다.
모든 작업이 끝났다면, GitHub에 접속해서 결과를 확인한다.
새롭게 생성한 Repository를 확인해보면, Good! 👍
결과물을 확인했다면, 기존의 지저분한 Repository를 삭제하면 된다.
로컬 저장소의 Clone한 디렉토리를 더이상 사용하지 않는다면,
삭제해도 무방하지만, 계속해서 원격으로 GitHub를 관리하고 싶다면
삭제하지 않고 사용하면 된다.