생성형 AI를 이용해 '스케줄'을 관리한다...

그래,, 스케줄 서비스에 빠질 수 없는 게 바로 무엇?

달력

이다.

우리 서비스의 프론트엔드는, next.js를 사용하고 있는데, 이 노드 기반의 프로젝트를 진행하면서 가장 중요한 기반이 될 캘린더를 어떻게 만들어야 할지는 내게 굉장히 큰 고민이었다.

사실, 직접 만들까도 생각해보았는데 생각보다 시간이 촉박하여, 라이브러리를 사용하기로 하였고, 어떤 라이브러리를 사용하면 좋을지에 대해 조사를 해보았다.

정말정말 많은 캘린더 UI 관련 서비스가 있었지만, 내가 최종적으로 선택한 서비스는 npm 라이브러리인 react-big-calendar이다.

선택한 이유는 다음과 같다.

1. npm 으로 관리가 가능한가? => 필수조건. O
2. 많이 사용되어 사용성이 검증되었는가? => O (date-picker을 앞질렀다)
3. 자유도가 높은가? => 상당히 많은 기능이 들어갈 것 같아, 이미 많이 만들어져 있는 것 보다는, 기본 틀만 잡혀있고, custom을 자유롭게 하길 바랐다. O

위에 적은 이유와 더불어, 일정을 캘린더 위에서 드래그 앤 드랍으로 움직여서 떨어트릴 수 있는 기능이 굉장히, 매력적으로 보였고, 그렇게 나는 react-big-calendar을 사용하게 되었다.(의 늪에 빠지고 말았다.. 허우적)

처음, npm install react-big-calendar를 터미널 창에 쳐서 다운을 받고, (타입스크립트는 npm i --save-dev @types/react-big-calendar)

이렇게 상단에 react-big-calendar라는 module로 부터 Calendar를 꺼내온다. (나는 BigCalendar라는 이름으로 명칭을 넣고 싶어서 as BigCalendar라고 한 거고, 그냥 import {Calendar} 라고 해도 된다.)

자, 그럼 일단 내가 만든 결과물을 살펴보자.

기본적으로 내가 만든 캘린더는

이런 형태를 가지고 있다. 여기서는 간단하게 header를 내가 따로 component로 만들어서 react-big-calendar 안에 넣어주었고,(이것이 바로 이 라이브러리의 큰 장점) 달력은 css를 커스텀하였다.

그리고

이렇게... 각 날짜 칸을 클릭하면 그 날짜에 해당하는 모달창이 뜨게끔 만들어줬다. (아주 고생했다.)

그래서 오늘은, 이 중에서도 가장 기본적인 css 커스터마이징에 대해 얘기해보고자 한다. 사실 이건, 앞으로 어떤 라이브러리를 다운을 받던 적용하는 방식이 비슷해서 한번 같이 알아보며 정리해보면 좋을 것 같아 준비했다.

그 전에, 우리가 보통 말하는 라이브러리란, 그리고 node_modules란 무엇일까? 맨날 node_modules node_modules.. 얘네는 git에 올리면 안되고, 파일 그 안에 엄청 많고 그런 건 많이 들어봤는데, 혹시 node_modules를 뜯어본 적이 있는가..!!

사실 나도 각 잡고 뜯어본 적은 없는데, 이번에 react-big-calendar를 적용시키면서, '하도 답답해서' node_modules를 뜯어보았다.

그 결과...

이 화면이 보이는가? 왼쪽에 보이는 게 바로 node_modules 안에 설치된 react-big-calendar인데, 우리가 보통 사용하는 바와 같이 css와 js가 고대로...! 들어있다.

그러니까 node_modules라고 특별한 게 있는 건 아니고, 그냥 css랑 js가 그대로 들어있고, (html은 그럼 어디있어요? => 우리가 결국 library를 설치해 가져오는 게, 화면(html, dom)이니까 그게 html이 되어주는 것 - 내 뇌피셜) 거기서 정의되어 있는 기능들을 가져오는 것이다! 그리고, 이 node_modules는 package.json 에 적혀있는 파일명들을 보고 자동적으로 설치가 되는 것이기 때문에, package.json만 있으면, 언제든 똑같이 설치가 가능. 그래서 git 같은 곳에는 괜히 무거워지게 올리지 않고, package.json만 업데이트 해주는 것이다.

그래서 만약, 이 react-big-calendar를 커스텀하고 싶다? 그럼 여기서 정의하고 있는 css나 기능들을 참고해서, 우리가 사용하는 쪽으로 끌어와서 위에 덮어쓰면 된다.

근데,, 사실 js 같은 경우는 아예 상호작용 적인 게 다 프로그래밍이 되어 있다 보니, 이미 짜여진 로직을 변경하는 게 아주아주 어렵더라. 아니, 거의 불가능에 가까워서 거의 Proxy 서버 띄우듯이 그 아이들의 로직을 속이려 노력해야 했다.

하지만, css는??? 바로바로 뒤늦게 선언된 아이가 승자이자, 최종적으로 적용되기 때문에, (그러니까, 만약 width: 100px; width: 200px; 이렇게 돼있으면 200px로 적용된다는 의미)

node_modules의 라이브러리에서 선언된 css 적인 부분은 모두모두! 우리가 커스터마이징 할 수 있다는 점!

그래서, 어떻게 하나요?

지금부터, 내가 아주 빠르게. node_modules의 css를 커스텀하는 방식을 알려주겠다.

일단, 기본적인 calendar를 창에 띄워보자. 내 calendar는 이미 커스텀되어 있지만, 기본 틀은 같으므로 그냥 여기서 진행을 해보겠다.

그리고, Fn+F12를 눌러서 크롬 개발자 도구를 켜보자.

그럼 대충 이런 창이 보일 거고, 오른쪽 Elements와 Network가 써져있는 왼쪽 맨 끝에, 창에 화살표가 있는 것을 클릭을 한다.

그리고 왼쪽의 화면 창에 갖다대면,

이런 모습을 볼 수 있다.

자, 지금 나는 날짜에 커서를 갖다댔고, 거기에는 button.rbc-button-link라는 이름이 붙여져 있다. 이게 무엇이냐? 바로 className이다. className이란 무엇이냐? 바로. css를 적용하기 위해 임의로 저 숫자들에 붙여놓은 이름이란 것이다.

무슨 소리냐고? 아까 찾아놓은 node_modules의 css 창으로 가보자.

node_modules에서 react-big-calendar를 찾아 들어가 lib/css 창을 들어가보면, react-big-calendar.css가 보인다. 그리고, 거기서 rbc-button-link를 찾아보면, 이렇게 여기에 적용되는 css 값들이 있다!!

즉, npm 라이브러리를 통해 설치된 node_modules에서는 이렇게 각 부분에className을 붙여 놓고, css에서 값을 설정하는 방식으로 화면을 구성시켜놓았고, 그래서 우리는 단 몇 번의 클릭만으로 사용되는 css 값들과, className을 찾을 수 있는 것이다.

그러면 우리는, 그냥 우리가 직접 만드는 창으로 내려와서, 이 className을 덮어주기만 하면 된다.

나는 이렇게 본래의 프로젝트에서 따로 style/calendar/style.css 라는 파일을 만들어서,

이렇게 가장 기본 _app.tsx 파일에 선언을 해놓고,

여기서 중요한 점은 내가 react-big-calendar의 css를 덮어쓴다는 것을 확실히 하기 위해

import "react-big-calendar/lib/css/react-big-calendar.css";

이 부분도 꼭 추가해줘야 한다는 점이다.

그 이후에 아까 찾은 className 값을 그대로 가져와서, 배경색, 글씨 크기 등을 커스텀함으로써 나만의 캘린더를 만들었다!

1. 라우터별 제어 플레인

- 제어 플레인 : 네트워크에서 데이터를 어디로 보낼지, 트래픽이 어떻게 전달될지 결정하는 두뇌
- 각 라우터는 자신만의 제어 플레인을 가짐 => 라우터별로 독립적인 경로 계산 및 결정이 가능
- 결론적으로, 네트워크의 각 부분이 서로 다른 운영 체제와 설정을 가질 수 있고, 중앙집중식 관리가 없는 분산된 환경에서 작동.
- ex) IP, RIP, IS-IS, OSPF, BGP
- 라우터의 독립성이 네트워크 전체의 통합된 관리와 최적화를 어렵게 함.

2. 트래픽 엔지니어링

- 트래픽을 특정 경로로 유도하는 것.
- 전통적인 라우팅에서는 트래픽 엔지니어링이 어렵다.
- 매번 특정 경로를 위해 링크 가중치를 재정의하거나 새로운 라우팅 알고리즘을 개발해야 할 수 있다.

=> 전통적인 라우팅 방식은 네트워크의 다양한 요구와 유연성을 충족시키기 어렵다. => 네트워크가 계속 발전하고 복잡해지면서, 이러한 제한 사항들이 더욱 두드러지게 되었고 => SDN이 등장하였다.

SDN(Software Defined Networking)

네트워크 제어 플레인과 포워딩 플레인을 분리하고, 제어 플레인을 중앙집중화하여 유연성과 효율성을 높인다.

1. 네트워크 제어 플레인과 포워딩 플레인의 분리

- 네트워크의 제어 기능을 구현하고, SDN 컨트롤러가 제공하는 북바운드 API를 사용하여 작동

2. 메인프레임에서 PC로의 진화 비유

- SDN의 개념은 메인프레임 컴퓨터에서 개인용 컴퓨터(PC)로의 진화와 비교될 수 있다.

3. SDN 제어 플레인의 역할

- SDN에서 제어 플레인은 원격 위치의 컨트롤러에 의해 수행.
- 컨트롤러는 네트워크의 전체 상황을 파악하고, 라우터나 스위치 등의 네트워크 장치에 포워딩 테이블을 계산하여 설치

4. SDN의 구조

- SDN 컨트롤러, 네트워크 제어 애플리케이션, 남북방 API, 그리고 SDN 제어 스위치로 구성
- 컨트롤러는 네트워크 제어 애플리케이션과 통신하며, 남북방 API를 통해 제어 명령을 전달하고 정보를 수집. SDN 제어 스위치는 이러한 명령에 따라 데이터 플레인을 조정.

5. 데이터 플레인 스위치

- 데이터 플레인 스위치는 네트워크에서 데이터 패킷을 전달하는 역할을 하는 장치
- "물리적 통로"와 같은 역할을 하며, 네트워크에서 데이터가 이동하는 경로를 결정.
- SDN에서 데이터 플레인 스위치는 단순하고 빠른 상품 스위치로 구성

6. SDN 컨트롤러의 역할

- SDN 컨트롤러는 네트워크 운영 체제
- 전체 네트워크 상태 정보를 유지하고 네트워크 제어 애플리케이션과 상호 작용
- 네트워크의 성능과 확장성을 고려하여 분산 시스템으로 구현

OpenFlow

- SDN 환경에서 컨트롤러와 스위치 간의 통신에 사용되는 프로토콜
-  TCP를 사용하여 메시지를 교환하며, 필요에 따라 선택적인 암호화를 제공
=>  컨트롤러가 네트워크 스위치를 효율적으로 제어 및 관리 가능

OpenFlow 메시지

[메세지 유형]
1. 스위치 기능에 대한 컨트롤러의 쿼리 : 컨트롤러는 스위치의 기능 및 능력을 파악하기 위해 쿼리를 보냄
2. 스위치 설정 매개변수의 쿼리 및 설정 : 컨트롤러는 스위치의 구성을 확인하고 필요에 따라 설정을 변경
3. 플로우 엔트리의 추가, 삭제, 수정 : 컨트롤러는 네트워크 트래픽을 제어하기 위해 플로우 테이블에 엔트리를 추가, 삭제 또는 수정 (특정 트래픽 패턴을 인식하고 그에 따라 적절한 액션을 취하는 규칙)

제어 플레인과 데이터 플레인 간의 상호작용

1. 링크 실패 시 :

- 네트워크 내의 링크에 실패가 발생하면, 데이터 플레인(스위치)는 OpenFlow 프로토콜을 사용하여 컨트롤러에게 이 상황을 알림

2. 컨트롤러 :

- 컨트롤러는 이 정보를 받고, Dijkstra 알고리즘과 같은 라우팅 알고리즘을 사용하여 새로운 라우팅 경로를 계산

=> 네트워크의 효율성을 유지하고, 장애에 신속하게 대응

Network ManageMent

네트워크 관리 프로토콜 : 네트워크 장비 및 서비스를 모니터링, 관리, 유지하는 데 사용되는 일련의 규약이나 표준

=> 이를 통해 트워크 장치의 상태를 파악하고, 문제를 진단하며, 네트워크 구성을 변경하고, 성능을 최적화하는 데 필요한 데이터와 명령을 전송함

Main Goal : 네트워크의 효율성과 안정성을 유지하고, 잠재적 문제를 신속하게 해결하여 네트워크의 지속적인 운영을 보장하는 것

1. SNMP (Simple Network Management Protocol)

- 네트워크 장비를 모니터링하고 관리하는 데 사용되는 인터넷 표준 프로토콜
- 세 가지 주요 구성 요소: 관리 대상 장치(네트워크 장비), 에이전트(장치에 설치된 소프트웨어), 네트워크 관리 시스템(NMS)
- 에이전트는 장치의 상태 정보를 수집하고, NMS에게 SNMP 메시지를 통해 이를 보고. NMS는 네트워크의 전반적인 상태를 모니터링하고 필요한 경우 설정을 조정
- 현재 보안과 데이터 형식의 개선이 이루어진 SNMP v2가 나온 상태.

2. NETCONF (Network Configuration Protocol)

- 네트워크 장비의 구성을 관리하기 위한 프로토콜
- XML(언어)을 기반으로 하며, 네트워크 장비의 구성을 검색하고, 수정하고, 업데이트하는 기능을 제공
- SSH(Secure Shell)을 통해 안전한 연결을 지원하며, 더 나은 보안과 무결성을 제공

3. YANG (A Data Modeling Language for NETCONF)

- NETCONF를 위한 데이터 모델링 언어로, 네트워크 장비의 구성과 상태를 모델링하는 데 사용
- 네트워크 장비의 구성을 표준화하고, 구성 데이터의 구조와 제약 조건을 명확하게 정의
- 복잡한 네트워크 장비의 구성을 단순하고 이해하기 쉬운 방식으로 표현할 수 있어, 네트워크 관리자가 보다 효과적으로 장비를 관리할 수 있음

SNMP는 주로 모니터링과 관리에 초점을 맞춘 반면, NETCONF와 YANG은 네트워크 장비의 구성을 보다 정밀하게 관리하고, 네트워크의 상태와 구성을 보다 효율적으로 모델링할 수 있는 기능을 제공

• Autonomous System
  • 네트워크 모음, 동일한 라우팅 정책, 단일 소유권
  • 고유 32비트 정수 AS 번호(ASN)로 식별
  • ASN, Internet Assigned Numbers Authority(IANA) 관리
  • 동일 AS 내 라우터, 동일한 intra-AS 라우팅 프로토콜 실행 (OSPF, RIP 등)
• Gateway Router
  • AS의 "edge"에 위치, 다른 AS의 라우터와 링크
  • inter-AS 라우팅 프로토콜 실행 (BGP 등)
• ASBR(Autonomous System Border Router)
  • IGP와 EGP 수행
• Transit AS
  • 여러 AS를 거쳐가는 트래픽 통과
• Stub AS
  • 단일 ISP와만 연결, 해당 AS로 도착 및 출발하는 트래픽만 존재

인터넷의 확장 가능한 라우팅 접근 방식

• Intra-AS Routing (IGP)
  • Interior Gateway Protocol (IGP)
  • 동일 AS 내 호스트, 라우터 간 라우팅
  • 모든 라우터, 동일한 intra-domain 프로토콜 실행
  • RIP, OSPF, IS-IS, IGRP 등
• Inter-AS Routing (EGP)
  • Exterior Gateway Protocol (EGP)
  • AS간 라우팅
  • 연결된 ASes

라우터, Intra-AS(IGP) 및 Inter-AS(EGP) 라우팅 알고리즘에 의해 설정된 포워딩 테이블

• 각 라우터, intra-AS(IGP)와 inter-AS(EGP) 둘 다 필요

Intra-AS Routing: RIP(Routing Information Protocol)

• L5 프로토콜: "routed"라 불리는 응용 수준 프로세스에 의해 관리되는 RIP 라우팅 테이블
• UDP 패킷에서 주기적으로 반복되는 광고
• Distance-Vector (DV) 알고리즘 (B-F 알고리즘)
• Metric = 홉 카운터(최대 15 홉), 각 링크 비용
• 15 홉 이상의 경로는 도달 불가능
• DV(광고)는 이웃과 30초마다 교환
• 광고에 최대 25개 목적지 서브넷 포함
• 느린 수렴 문제: Count-to-Infinity -> 해결: Split horizons, Split horizons with poison reverse

OSPF(Open Shortest Path First)

• Link State (LS) 알고리즘
• Metric = 서비스 유형에 기반 (BW, 최소 지연, 처리량, 신뢰성 등)
• 모든 라우터, 동일한 AS에 대한 글로벌 토폴로지 맵 보유
• 계산은 Dijkstra 알고리즘 사용
• 두 레벨 계층
• AS는 지역, 하나의 백본 영역으로 나뉨
• LSA는 지역 내에만 홍수
• ABR(Area Border Router): 다른 ABR에게 요약, 광고
• 백본 라우터: 백본에 한정된 OSPF 라우팅 실행 (DV 사용)
• ASBR(AS Boundary Router): 다른 AS에 연결 (OSPF + BGP)
• 백본 영역: DV 사용, count-to-infinity 발생 가능

BGP(Border Gateway Protocol)

• Inter-AS 라우팅 프로토콜

• 여러 ISP를 거쳐 가는 경로 계산

• EGP와 BGP

  존재, 현재 모든 인터넷 라우터 BGP 사용

• 정책 기반 라우팅

• 목적지 서브넷에 도달하기 위한 경로의 전체 AS 경로 목록 광고

• 라우팅 루프 방지

• Classless Inter Domain Routing (CIDR)

• 증분 업데이트: TCP 연결 수립 및 모든 후보 BGP 경로 교환 후, 이전 업데이트의 변경 사항만 광고

BGP: Peering

• Peering: 무료로 라우팅 정보 및 트래픽 교환
• BGP Peers (이웃): BGP 메시지 교환하는 두 라우터
• External BGP Peering (eBGP): 다른 AS 간
  • eBGP 피어는 다른 ASN 보유
  • eBGP는 라우팅 정책 구현
  • 물리적으로 직접 연결되어야 함
• Internal BGP Peering (iBGP): 동일 AS 내
  • iBGP 피어는 동일 ASN 보유
  • 완전 메쉬 연결 필요 (반드시 직접 연결되지 않아도 됨) - iBGP 피어, IGP 사용하여 도달 가능해야 함
• 게이트웨이 라우터, eBGP 및 iBGP 프로토콜 실행

BGP: session

• 두 BGP 라우터(피어)가 TCP 연결을 통해 BGP 메시지 교환
• eBGP: 이웃 AS로부터 서브넷 도달 가능성 정보 학습
• iBGP: AS 외부에서 학습된 접두어를 AS 내 모든 라우터에 전파
• iBGP는 다른 iBGP로부터 학습된 접두어 전달 안 함
• 도달 가능성 정보 및 정책 기반 좋은 경로 결정

BGP 메시지 유형

• OPEN: 원격 BGP 피어와 TCP 연결 개설, BGP 피어 인증
• UPDATE: 새 경로 광고 (또는 기존 철회)
• KEEPALIVE: UPDATE 부재시 연결 유지, OPEN 요청 ACK
• NOTIFICATION: 이전 메시지의 오류 보고, 연결 종료
• Marker: BGP 메시지 시작 구별, TCP byte-stream 전송 방식 때문에 필요

BGP 경로

• 광고 접두사에 BGP 경로 속성 포함
• BGP 경로 = (목적지 접두사 + 해당 목적지로 가는 경로 속성)
• BGP 경로 속성
  • AS-PATH: 목적지 서브넷에 도달하기 위한 ASN 목록
  • NEXT-HOP: 다음 홉 AS의 eBGP 피어 IP 주소

BGP: 정책 기반 라우팅

• import 정책: 게이트웨이 수신 경로 광고, import 정책 사용하여 경로 수락/거부
  • 외부 AS에서 얻은 라우터 정보 내부 AS 전달 결정
• export 정책: 인접 AS에 경로 광고 여부 결정
  • 내부 AS 라우터 정보 이웃 AS에 알릴지 결정
• ASBR은 다른 ASBR이 알려준 모든 inter-AS 경로 정보를 iBGP 세션으로 전달한다? (X) → 정책에 기반한 선택된 경로 정보만 전달

BGP 라우트 선택: Hot Potato Routing

• 외부 AS에 연결된 목적지로 가는 경로 중 AS 내부 비용이 가장 적은 라우트

주요 목적은 데이터를 통해 숨겨진 새로운 지식을 발견하고, 문제 해결에 활용하는 것. 이를 위해 데이터 과학은 컴퓨터 과학, 통계학, 특정 적용 분야에 대한 이해를 필요로 하는 복합적 기술을 사용.

DIKW(DIWK) 계층 구조는 데이터 과학의 중요한 개념 중 하나. 이 구조는 데이터, 정보, 지식, 지혜의 네 단계로 구성:

1. 데이터(Data): 관찰이나 측정을 통해 수집된 사실이나 값. 예를 들어, 온도 측정값이나 판매 데이터 등이 해당.

2. 정보(Information): 데이터를 상황에 맞게 가공하여 얻은 의미 있는 형태. 예를 들어, 특정 기간의 평균 온도나 월별 판매량 증감 등의 데이터가 정보에 해당.

3. 지식(Knowledge): 정보 분석을 통해 발견된 규칙이나 패턴. 의미 있고 유용한 정보로, 시장 추세나 소비자 행동 패턴 이해에 포함.

4. 지혜(Wisdom): 지식에 통찰력을 더한 새롭고 창의적인 아이디어. 문제 해결이나 새로운 전략 개발에 활용될 수 있음.

이 계층 구조는 데이터로부터 시작해 지혜에 이르는 정보의 가치 증대 과정을 나타냄. 데이터 과학자들은 이 구조를 이해하고 활용해 데이터에서 가치 있는 통찰을 도출하고 실제 세계의 문제를 해결하는 데 중요한 역할을 함.

빅데이터(Big Data)는 기존 데이터베이스의 저장 및 관리 능력을 초과하는 대규모의 다양한 데이터를 뜻함. 이는 대규모 데이터의 저장, 관리 기술과 가치 있는 정보를 만들기 위한 분석 기술을 포함. 빅데이터의 특징은 '3V'로 요약:

1. 데이터양(Volume): 테라바이트(TB) 단위 이상의 대량 데이터를 포함하며, 여러 경로를 통해 지속적으로 생성되는 많은 양의 데이터.

2. 속도(Velocity): 데이터의 수집과 분석을 정해진 시간 내에 처리하는 것으로, 많은 양의 데이터가 빠르게 생성되고 전달됨으로써 수집 및 분석 작업이 실시간으로 진행됨.

3. 다양성(Variety): 정형, 반정형, 비정형 등 다양한 형태의 데이터를 포함. 이는 빅데이터를 단순한 양적 대규모 데이터를 넘어서 질적 측면의 다양한 형태를 포함하는 대규모 데이터로 이해하는 것을 의미.

빅데이터 기술은 저장 기술, 분석 기술, 표현 기술을 포함:

빅데이터 저장 기술:

• 하둡(Hadoop): 대용량 데이터를 분산 처리할 수 있는 자바 기반의 오픈 소스 프레임워크. 분산 파일 시스템인 HDFS에 데이터를 저장하고, 맵리듀스를 이용해 데이터 처리. 오픈 소스이며, 여러 대의 서버에 데이터를 분산해서 저장해 처리 속도가 빠름.
• NoSQL: 관계 데이터 모델과 SQL을 사용하지 않는 데이터베이스 시스템. 가용성과 확장성에 중점을 둠. 비정형 데이터 저장을 위해 유연한 데이터 모델을 지원하며, 분산 처리와 병렬 처리가 가능함. 예: H베이스, 카산드라, 몽고DB, 카우치DB 등.

빅데이터 분석 기술:

• 텍스트 마이닝: 반정형 또는 비정형 텍스트에서 자연어 처리 기술로 정보를 추출하고 가공.
• 오피니언 마이닝: SNS, 블로그, 게시판 등에 기록된 사용자들의 의견을 수집하고 분석하여 제품이나 서비스에 대한 선호도를 추출.
• 소셜 네트워크 분석: 소셜 네트워크의 연결 구조나 강도 등을 바탕으로 영향력, 관심사, 성향, 행동 패턴 등을 추출.
• 군집 분석: 데이터 간 유사도를 측정한 후 특성이 비슷한 데이터를 합쳐 최종적으로 유사 특성의 데이터 집합을 추출.

빅데이터 표현 기술:

• R 언어: 데이터 분석을 통해 추출한 의미와 가치를 시각적으로 표현하기 위해 사용됨. 다양한 프로그래밍 언어와 연동 가능하고 다양한 운영체제를 지원하며, 하둡 환경에서 분산 처리를 지원하는 라이브러리를 제공.

빅데이터 저장 기술: NoSQL(Not Only SQL)

대량의 비정형 데이터를 빠른 속도로 저장, 처리 ACID(원자성, 일관성, 격리성, 지속성) 위한 트랜잭션 기능 미제공 저렴한 비용으로 여러 대의 컴퓨터에 데이터 분산, 저장, 처리 가능 융통성 있는 데이터 모델 사용 스키마 없이 동작, 데이터 구조 변경 용이 비정형 데이터 저장 적합

관계 데이터베이스 vs. NoSQL

• 관계 데이터베이스
  • 장점: 트랜잭션 일관성 유지, 테이블 간 관계 표현, 복잡한 질의 처리
  • 단점: 대량 비정형 데이터 저장 확장성 비효율
• NoSQL
  • 장점: 트랜잭션 기능 미제공, 스키마 변경 자유, 대량 비정형 데이터 빠른 저장, 처리
  • 단점: SQL 대신 별도 분석 기술 필요

NoSQL 종류

• 키-값(key-value) 데이터베이스
  • 키와 값 쌍 저장, 다양한 형태 값 저장 가능
  • 질의 처리 속도 빠름
  • 키 이용 전체 검색 가능, 값 일부 검색 및 내용 기반 질의 별도 처리 필요
  • 예: 아마존 다이나모DB(DynamoDB), 레디스(Redis)
• 문서 기반(document-based) 데이터베이스
  • 키와 문서 쌍 저장, JSON, XML 등 반정형 형태 문서 저장
  • 문서 객체지향 개념 유사
  • 문서 전체 검색 및 특별한 문서 대상 질의 언어 이용 부분 검색 가능
  • 예: 몽고DB(MongoDB), CouchDB
• 컬럼 기반(column-based) 데이터베이스
  • 컬럼 패밀리와 키 쌍 저장, 관련 컬럼 값들 모음
  • 관계 데이터 모델 테이블 유사성 및 차별성
  • 다양한 형태 데이터 저장, 컬럼 패밀리별 구성 다양화
  • 예: 구글 빅테이블(BigTable), H베이스(HBase), 카산드라(Cassandra)
• 그래프 기반(graph-based) 데이터베이스
  • 노드 데이터 저장, 간선 데이터 관계 표현
  • 질의 그래프 순회 처리
  • 연관 데이터 추천, 소셜 네트워크 친구 찾기 적합
  • ACID 지원, 클러스터 환경 부적합
  • 예: Neo4J, OrientDB

빅데이터 분석 기술: 데이터 마이닝

기존 데이터 분석 기술 + 빅데이터 특징: 다양한 형태 비정형 데이터 기반 대량 데이터 처리 대표 기술: 데이터 마이닝, 기계 학습

• 데이터 마이닝: 숨겨진 규칙, 패턴 발견
• 기계 학습: 수집된 데이터 학습, 새로운 데이터 결과 예측

데이터 마이닝 분석 기법

• 분류 분석: 새로운 데이터 그룹, 등급 예측, 기존 데이터 그룹 기준 정의
  • 기법: 로지스틱 회귀모형, 의사결정나

무, K-최근접 이웃모형, 베이즈분류모형, 인공신경망, 지지벡터기계, 유전 알고리즘

• 군집 분석: 유사한 특성 데이터 독립적 군집 나눔, 군집 특성 및 관계 분석
  • 계층적: 유사 데이터 묶기, 최단/최장/평균/중심/와드 연결법
  • 비계층적: 최적화된 군집 형성, K-중심 군집
• 연관 분석: 데이터 발생 빈도 분석, 숨겨진 연관 규칙 파악
  • 예: 상품 동시 구매 분석, Apriori 알고리즘 사용

Link State Routing Algorithm: 전체 네트워크의 링크 상태를 파악하여 경로를 결정. 대표적인 예는 Dijkstra's algorithm (다익스트라 알고리즘). Distance Vector Algorithm: 각 라우터가 주변 라우터와의 거리 정보를 기반으로 경로를 계산. 예로는 Bellman-Ford algorithm (벨만-포드 알고리즘)이 있음. Hierarchical Routing: 대규모 네트워크를 여러 영역으로 나누어 관리하는 방식. Routing Protocols (라우팅 프로토콜)

RIP, OSPF (IGP; Interior Gateway Protocol): 내부 네트워크 라우팅을 위해 사용. BGP (EGP; Exterior Gateway Protocol): 서로 다른 네트워크 사이의 라우팅에 사용. Data Plane (데이터 평면)과 Control Plane (제어 평면)

FIB (Forwarding Information Base): 데이터 평면에서 패킷을 적절한 출력 포트로 전송. RIB (Routing Information Base): 제어 평면에서 소스에서 목적지까지의 경로를 결정. Per-router Control Plane (라우터별 제어 평면)

각 라우터에는 독립적으로 라우팅 알고리즘 구성 요소가 있으며, 이들은 제어 평면에서 서로 상호 작용하여 포워딩 테이블을 계산. 2) Logically Centralized Control: SDN Controllers (논리적 중앙 집중식 제어: SDN 컨트롤러) OpenFlow Controllers SDN (Software-Defined Networking) 환경에서 네트워크를 중앙에서 효율적으로 제어할 수 있는 컨트롤러. Traditional Routing Algorithm (전통적인 라우팅 알고리즘) Routing Algorithms (라우팅 알고리즘)

라우터 간에 교환되는 메시지의 형식과 순서를 정의하고, 경로 선택 알고리즘을 포함. 목표: 송신 호스트에서 수신 호스트까지 좋은 경로(최소 비용, 가장 빠른, 최소 혼잡 등)를 결정. Routing Algorithm Classification (라우팅 알고리즘 분류)

Global vs. Decentralized: 전체 네트워크 구조를 알고 있는지 여부에 따라 분류. Static vs. Dynamic: 경로가 시간에 따라 얼마나 자주 변경되는지에 따라 분류. Load-sensitive vs. Load-insensitive: 링크 비용이 현재의 혼잡도를 반영하는지 여부에 따라 분류. Problem of Dijkstra's Algorithm

네트워크 상황에 따라 경로가 반복적으로 변할 수 있으며, 이로 인해 네트워크 성능 저하가 발생할 수 있음. Distance Vector (DV) Algorithm Bellman-Ford Equation

최소 비용 경로 계산을 위한 주요 방정식. DV 알고리즘은 라우터가 직접 연결된 링크만 정확하게 알고 있음. Count to Infinity Problem

나쁜 뉴스(예: 링크 비용 증가)가 천천히 퍼져서 라우팅 루프 발생 가능. 이를 방지하기 위해 'Split Horizon'과 'Poisoned Reverse' 기법이 사용됨.

LS (Link-State) 라우팅 대비 DV (Distance-Vector) 라우팅 메시지 교환 방식: LS는 전체 네트워크에 걸쳐 작은 메시지를 브로드캐스트하는 반면, DV는 이웃 라우터들 사이에서만 큰 메시지를 교환함. 네트워크 인식 능력: LS는 전체 네트워크의 상태를 인식하는 반면, DV는 오직 국소적인 정보만을 인식함. 경로 계산 방식: LS는 일반적으로 보다 정확하고 효율적인 경로를 계산하지만, 더 많은 연산 자원을 요구함. DV는 계산이 간단하고 자원 사용이 적지만, 때때로 비효율적인 경로를 계산할 수 있음. 동적 반응성: LS는 네트워크 변화에 빠르게 반응하지만, DV는 정보 전파의 지연으로 인해 느린 반응을 보일 수 있음.

(추가 조사)

Link-State (LS) 라우팅 메시지 전송: LS 라우팅에서는 각 라우터가 자신의 직접 연결된 링크의 상태(비용, 속도 등) 정보를 전체 네트워크에 브로드캐스트합니다. 이 정보는 작은 메시지들로 구성되어 전송됩니다. 전체 네트워크 인식: 각 라우터는 전체 네트워크의 링크 상태 정보를 수집하여 로컬 데이터베이스에 저장합니다. 이를 통해 네트워크의 전체 구조를 파악할 수 있습니다. 경로 계산: Dijkstra 알고리즘을 사용하여 소스 라우터로부터 네트워크 내의 모든 다른 라우터까지의 최소 비용 경로를 계산합니다. 동적 반응성: 네트워크 상태 변화에 신속하게 반응하여 라우팅 정보를 업데이트합니다. 복잡도와 부하: 라우터가 많은 정보를 처리해야 하므로 연산 복잡도가 높고, 네트워크에 부하를 줄 수 있습니다. Distance-Vector (DV) 라우팅 메시지 전송: DV 라우팅에서는 각 라우터가 자신의 이웃 라우터에게만 자신의 최소 비용 추정치를 전송합니다. 이 정보는 일반적으로 더 크고, 전체 네트워크에 걸쳐 전송되지 않습니다. 국소적 인식: 라우터는 오직 직접 연결된 이웃 라우터에 대한 정보만을 알고 있으며, 이웃으로부터 수신한 정보를 통해 전체 네트워크에 대한 추정을 합니다. 경로 계산: Bellman-Ford 알고리즘을 사용하여 최소 비용 경로를 계산합니다. 이 과정은 이웃 라우터 간의 정보 교환을 기반으로 합니다. 반복적인 업데이트: 네트워크 상태의 변화에 따라 라우터들은 지속적으로 정보를 교환하며 라우팅 테이블을 업데이트합니다. 문제점: "Count to Infinity" 문제와 같은 문제가 발생할 수 있습니다. 이는 라우팅 정보의 느린 전파로 인해 발생하며, 네트워크의 불안정성을 초래할 수 있습니다. LS vs DV 메시지 교환: LS는 전체 네트워크에 걸쳐 작은 메시지를 브로드캐스트합니다. 반면, DV는 이웃 라우터 간에만 큰 메시지를 교환합니다. 네트워크 인식: LS는 네트워크의 전체적인 상태를 인식하지만, DV는 오직 국소적인 정보만을 인식합니다. 경로 계산: LS는 일반적으로 보다 정확하고 효율적인 경로를 계산하지만, 더 많은 연산 자원을 요구합니다. DV는 간단하고 자원 사용이 적지만, 때때로 비효율적인 경로를 계산할 수 있습니다. 동적 반응성: LS는 네트워크 변화에 빠르게 반응하지만, DV는 정보 전파의 지연으로 인해 느린 반응을 보일 수 있습니다.

IPv6 주소 지정 (IPv6 Addressing)

1. 다중 주소 설정: IPv4와 달리, IPv6에서는 하나의 네트워크 인터페이스 카드(NIC)에 여러 종류의 IPv6 주소가 설정될 수 있다.

2. 브로드캐스트 주소 미정의: IPv6에서는 브로드캐스트 주소가 정의되지 않고, 대신 멀티캐스트 주소(0xff로 시작)가 사용된다.

3. 루프백 주소: IPv4의 127.0.0.1과 같은 루프백 주소는 IPv6에서 0x::1/128로 정의되며, 네트워크 프로그램 테스트용으로 사용된다.

4. 링크-로컬 주소: 0xfe80로 시작하는 링크-로컬 주소는 한 서브넷 내의 패킷 전달에 사용된다.

5. 글로벌 유니캐스트 주소: 0x2001로 시작하는 글로벌 유니캐스트 주소는 IPv4의 공개 주소와 유사하다.

6. 6to4 주소: 0x2002로 시작하는 6to4 주소는 IPv4 주소를 포함하며 6to4 터널링에 사용된다.

IPv4 헤더와 IPv6 헤더의 차이점:

공통 기능: TTL(홉 제한)은 IPv6에서 홉 제한으로, 전체 길이는 페이로드 길이로, 상위 계층 프로토콜은 다음 헤더로, ToS는 우선순위로 표현된다.

IPv6의 설계 목표:

빠른 처리(전달): 헤더 체크섬이 없고 라우터에서의 조각화가 없다. 서비스 품질: 기대에 미치지 못함.

IPv4에서 IPv6로의 전환 기술:

듀얼 스택: 모든 노드(라우터 및 호스트)는 IPv4와 IPv6을 모두 가지고 있다. NAT64(DNS64): IPv4와 IPv6 사이의 주소와 프로토콜 헤더를 변환한다. 6to4 터널링: IPv6 패킷이 IPv4 페이로드에 캡슐화되어, IPv4가 IPv6 전송을 위한 링크 계층으로 작동한다.

SDN

1. 프레임워크 : "중앙집중식 네트워크 제어" => SDN은 네트워크 제어 기능을 네트워크 장비로부터 분리하여 중앙화된 서버(컨트롤러)에서 관리.

2. 프로그래밍 가능성 : 고급 API를 통해 네트워크 관리자는 네트워크 장치의 동작을 프로그래밍할 수 있다. 이를 통해 더 유연하고 효율적인 네트워크 관리가 가능함.

3. 전통적 라우터와의 비교:

• 메인프레임 컴퓨터: 전통적인 라우터는 메인프레임 컴퓨터에 비유될 수 있음. 여기서 제어 평면(control plane)과 데이터 평면(data plane)은 하나의 장치에서 통합되어 처리됨.
• 언번들 시스템: 반면, SDN은 '언번들 시스템'과 같음. 제어 평면과 데이터 평면이 분리되어 있어, 각각이 서로 다른 역할을 수행함.

4. 네트워크 제어 애플리케이션 레이어:

• 알고리즘과 기능: 네트워크 제어 애플리케이션 레이어에서는 다양한 네트워크 관리 알고리즘과 기능이 구현됨. ex) Dijkstra 알고리즘은 최적의 경로를 찾는 데 사용되고, NAT 알고리즘은 네트워크 주소 변환에 사용.

5. SDN 컨트롤러 (네트워크 운영 체제):

• 중앙 관리점: SDN 컨트롤러는 네트워크의 중앙 관리점으로, 네트워크 전반의 상태를 모니터링하고 제어함.
• 패킷 스위치 제어: 컨트롤러는 네트워크 제어 애플리케이션의 출력을 사용하여 패킷 스위치(예: 라우터, 스위치)를 관리함.

6. 패킷 스위치:

• 단순하고 빠른 처리: 데이터 평면에 위치하는 패킷 스위치는 네트워크 트래픽을 처리하는 데 중점을 둡니다. 이들은 단순하고 빠르게 설계되어, 최종 호스트의 메시지를 효율적으로 전달합니다.

• 디렉토리 내에 파일이 있는지 찾기 위해 linear search 필요

Hash Table -Linear list + hashing

• file name을 파일의 linear list의 위치로 바꾸어줌.
• search time 없앰.
• collision 발생 가능(hashing 단점)

**메타데이터 보관 방법

1. 디렉토리 내에 직접 보관
2. 디렉토리에는 포인터 두고 다른 곳에 보관

=> Long file name의 지원

• <file name, file metadata> list에서 각 entry 크기는 일반적으로 고정
• file name이 고정 크기 entry 길이보다 길어지는 경우 entry의 마지막 부분에 이름의 뒷부분이 위치한 곳의 포인터를 두는 방법 사용
• 이름의 나머지 부분은 동일한 directory file의 일부에 존재

가상 파일 시스템 (VFS)

목적: 다양한 파일 시스템에 대해 동일한 시스템 콜 인터페이스(API)를 통해 접근할 수 있도록 하는 운영체제

기능: 어떤 파일 시스템을 사용하든 간에 VFS 인터페이스를 통해 이를 사용할 수 있게 함. 이는 파일 시스템의 종류에 관계없이 일관된 방식으로 파일 시스템에 접근 가능.

네트워크 파일 시스템 (NFS)

목적: 분산 시스템에서 네트워크를 통해 파일을 공유할 수 있게 해주는 방법 작동 방식: NFS는 분산 환경에서 파일을 공유하는 대표적인 방법으로, NFS 클라이언트와 NFS 서버를 사용하여 작동

페이지 캐시 (Page Cache)

정의: 가상 메모리의 페이징 시스템에서 사용하는 페이지 프레임을 캐싱의 관점에서 설명하는 용어

활용: 메모리 매핑된 I/O에서 파일의 I/O를 위해 페이지 캐시를 사용

메모리 매핑된 I/O (Memory-Mapped I/O)

작동 방식: 파일의 일부를 가상 메모리에 매핑 => 이 매핑된 영역에 대한 메모리 접근 연산으로 파일의 입출력을 수행

특징: 메모리 매핑된 I/O를 사용할 경우 요청된 데이터가 메모리에 없으면 스왑 영역이 아닌 파일 시스템을 접근

버퍼 캐시 (Buffer Cache):

용도: 파일 시스템을 통한 I/O 연산 시 메모리의 특정 영역인 버퍼 캐시를 사용

특징: 파일 사용의 지역성 활용 => 한 번 읽어온 블록에 대한 후속 요청 시 버퍼 캐시에서 즉시 데이터를 전달 => 모든 프로세스가 이를 공동으로 사용

버퍼 캐시에서는 LRU (최근에 가장 적게 사용된 페이지 교체), LFU (가장 자주 사용되지 않는 페이지 교체) 등의 대체 알고리즘이 필요함.

통합 버퍼 캐시 (Unified Buffer Cache):

최근의 운영체제에서는 기존의 버퍼 캐시가 페이지 캐시에 통합되었다. 이를 통해 두 캐시 시스템의 중복을 제거하고 효율성을 높일 수 있다.

1. 논리적 주소

• 프로세스가 독립적으로 가지는 주소 공간
• 0번지부터 시작하는 자신만의 주소 공간을 가짐
• cpu는 이 논리적 주소를 참조함.

2. 물리적 주소

• 메모리에 실제로 존재하는 위치, 즉 dram 상의 변하지 않는 실제 주소.

3. 기호적 주소

• 프로그래머가 사용하는 변수나 레이블 등 기호적 이름으로 표현된 주소.

주소 바인딩

기호적 주소에서 논리적 주소, 그리고 물리적 주소로의 변환 과정.

1. 컴파일 시간 바인딩

• 컴파일 시 정적으로 물리적 주소가 결정
• 컴파일러는 절대 코드를 생성하여, 프로그램이 메모리에 로드되면 주소가 변경되지 않음.

2. 로드 시간 바인딩

• 로더가 프로그램이 메모리에 로드될 때 물리적 주소를 부여.
• 재배치 가능한 코드를 생성한 경우, 프로그램의 시작 위치를 변경하더라도 로더가 물리적 주소를 조정할 수 있다.

3. 실행 시간 바인딩

• 프로그램이 실행된 이후에도 프로세스의 메모리 상 위치를 옮길 수 있음.
• CPU가 주소를 참조할 때마다 주소 매핑 테이블을 검사하여 실제 메모리 주소를 변환함.
• 하드웨어적인 지원이 필요하고, 주로 MMU(메모리 관리 장치)에 의해 수행된다.

MMU(Memory-Management Unit)

• 논리적 주소를 물리적 주소로 매핑하는 하드웨어 장치.
• 사용자 프로세스가 cpu에서 수행되며 생성하는 모든 주소값에 대해 기준 레지스터의 값을 더한다.
• 컨텍스트 스위치가 발생하면 mmu의 기준 레지스터 값도 변경된다
• 사용자 프로그램은 논리적 주소만을 다무려, 물리적 주소를 알 필요가 없다.

=> 프로그램이 메모리에 어떻게 매핑되는지, 어떻게 cpu에 의해 참조되는지를 결정하는 중요한 역할을 한다. 각 단계는 메모리 관리의 유연성과 효율성을 높이기 위해 설계되었으며, 프로그램의 실행과 메모리 관리를 최적화하기 위한 중요한 기술.

설계 과정

• 요구사항 분석 : 사용자의 요구사항을 수집하고 분석하여 데이터베이스의 용도를 파악한다. => 요구사항 명세서

1. 데이터베이스 주요 사용자 범위 결정
2. 사용자가 조직에서 수행하는 업무 분석
3. 요구사항 수집 수 분석 결과를 바탕으로 요구 사항 명세서 작성

• 개념적 설계 : 분석 결과를 바탕으로 개념적 모델링을 통해 독립적인 개념적 스키마 설계. => ER 다이어그램
• 개체* : 저장할 만한 가치가 있는 중요 데이터를 가진 사람이나 사물. 요구 사항에서 의미 있는 명사를 찾고, 찾은 명사를 개체와 속성으로 분류하여 개체를 추출한다.
• 관계* : 개체 간의 의미 있는 연관성. 요구 사항에서 연관성을 표현한 동사를 찾고, 매핑 카디널리티와 참여특성을 결정해 관계를 추출한다.
• 논리적 설계 : 개념적 스키마를 관계 데이터 모델에 맞게 논리적 스키마로 변환. 이 과정에서 속성의 데이터 타입, 길이, 널 값 허용 여부 등을 결정하고 릴레이션 스키마를 문서화함.
• 논리적 설계 규칙*

1. 모든 개체는 릴레이션으로 변환한다.

2. 다대다 관계는 릴레이션으로 변환한다.

3. 일대다 관계는 외래키로 표현한다.

4. 일대일 관계는 외래키로 표현한다.

5. 다중 값 속성은 릴레이션으로 변환한다.

• 물리적 설계 : 하드웨어나 운영체제의 특성을 고려하여 데이터베이스의 물리적 구조를 설계함. 인덱스 구조나 내부 저장 구조를 결정.

• 구현 : SQL 문을 작성하여 DBMS에서 실행함으로써 데이터베이스를 실제로 생성함. 오류 발생 시 이전 단계로 되돌아가 설계 내용을 수정.

변수는 생명주기가 있다. 만약 없다면? 한 번 선언된 변수가 프로그램을 종료하지 않는 한 영원히 메모리 공간을 점유한다.

• 전역 변수의 생명 주기 = 애플리케이션의 생명 주기
• 지역 변수(함수 내부)는 함수가 호출되면 생성되고, 함수가 종료하면 소멸.

foo 함수를 호출해야만 함수 안 변수 선언문 실행 => 이전까지는 x가 생성되지 않는다.

변수 선언은 가장 먼저 선언된다? => 전역 변수 한정.

함수 내부에서 선언한 변수는 함수 호출 직후, 함수 안의 코드 줄들을 읽기 전 먼저 실행.

foo 호 출 => x 변수 선언 및 undefined 초기화 => 변수 x에 할당. 함수 종료 => x 변수 소멸.

지역 변수의 생명주기 = 생명주기.

변수의 생명주기 : 메모리 공간 확보 ~ 메모리 공간 해제 및 가용 메모리 풀에 반환. 지역 변수는 함수가 생성한 스코프(물리적인 실체)에 등록. => 스코프가 소멸될 때까지 변수는 유효. => 누군가 스코프를 참조하고 있으면 소멸하지 않고 생존.

=> 누군가 스코프를 참조하고 있다면, 함수가 종료하더라도 스코프는 해제되지 않고 생존.

호이스팅

변수 선언이 스코프의 선두로 끌어 올려진 것처럼 동작하는 자바스크립트 고유의 특징.

전역변수

**var 키워드로 선언한 전역 변수의 생명 주기는 전역 객체(window)의 생명 주기와 일치한다.

문제점

• 암묵적 결합 : 전역 변수를 선언 => 코드 어디서든 참조하고 할당할 수 있는 변수를 사용하겠다 => 변수의 유효 범위가 커질 수록 코드의 가독성은 나빠지고 의도치 않은 상태 변경이 일어날 수 있음.
• 긴 생명 주기 : 메모리 리소스를 오랜 시간 소비함. 변수의 중복 선언을 허용하기 때문에 의도치 않은 재할당이 이뤄질 수 있음.
• 스코프 체인 상에서 종점에 존재 : 전역 변수의 검색 속도가 가장 느리다
• 네임 스페이스 오염 : 자바스크립트에서는 파일이 분리되어 있어도 하나의 전역 스코프를 공유한다 => 다른 파일 내에서 동일한 이름으로 명명된 전역 변수나 함수가 같은 스코프 내에 존재할 경우 잘못된 결과 도출.

전역 변수의 사용을 억제하는 방법

• 변수의 스코프는 좁을수록 좋다.
• 즉시 실행 함수 : 즉시 실행 함수는 단 한 번만 호출된다. => 모든 코드를 즉시 실행 함수로 감싸면 모든 변수는 즉시 실행 함수의 지역 변수가 된다. (라이브러리 등에 자주 사용됨)
• 네임 스페이스 객체 : 전역에 네임스페이스 역할을 담당할 객체를 생성하고 전역 변수처럼 사용하고 싶은 변수를 프로퍼티로 추가한다. => 계층적 구성 가능.
• 모듈 패턴 : 클래스를 모방해 관련이 잇는 변수와 함수를 하나의 실행 함수로 감싸 모듈을 만든다.
• 캡슐화* 객체의 상태를 나타내는 프로퍼티와 메서드를 하나로 묶는것. 외부에 노출하고 싶은 변수나 함수만 담아 반환한다.(퍼블릭) 외부로 노출하고 싶지 않은 반환되는 객체에 추가하지 않은 변수나 함수는 외부에서 접근할 수 없다. (프라이빗)
• ES6 : 이걸 사용하면 더는 전역 변수를 사용할 수 없음. 파일 자체의 독자적인 모듈 스코프를 제공하기 때문