만약 다른 도메인에서 API를 요청해서 사용 할 수 있게 해주려면 CORS 설정이 필요하다는 것을 여러분 또한 이전 섹션에서 배워 기억하고 계실 것입니다.

CORS 교차 출처 리소스 공유(Cross-Origin Resource Sharing, CORS)는 추가 HTTP 헤더를 사용하여, 한 출처에서 실행 중인 웹 애플리케이션이 다른 출처의 선택한 자원에 접근할 수 있는 권한을 부여하도록 브라우저에 알려주는 체제입니다. 웹 콘텐츠의 출처(origin)는 접근할 때 사용하는 URL의 스킴(프로토콜), 호스트(도메인), 포트로 정의됩니다. 두 객체의 스킴, 호스트, 포트가 모두 일치하는 경우 같은 출처를 가졌다고 말합니다. 일부 작업은 동일 출처 콘텐츠로 제한되나, CORS를 통해 제한을 해제할 수 있습니다

CORS 정책이 생긴 이유

만일 모든 출처의 접근을 허용하게 된다면, 보안성의 문제와 해킹의 위험에 노출되기 때문에 모든 도메인의 접근을 허용하지 않고, 특정 도메인에서만 접근이 가능하도록 구현하는 것입니다.

우리가 프록시를 통해 우회하는 이유 1

프록시 서버를 통해 오히려 한 단계의[한채널의] 보안을 더 추가할 수 있다는 장점도 있고, 캐시를 사용하여 리소스로의 접근을 빠르게 하기 위해 사용되기도 합니다. 웹 프록시는 웹 서버로부터 웹페이지를 캐시로 저장하는데 흔히 쓰이며 캐싱을 통해 콘텐츠를 빠르게 가져올 수 있습니다.

우리가 프록시를 통해 우회하는 이유 2

또한 사용률을 기록하고 검사하기 위해 사용할 수 있습니다. 관리자의 입장에서 클라이언트에 대한 사용정보를 별도의 프록시 서버에서 관리함으로서 민감한 정보와 민감하지 않은 정보의 계층을 분리하여 관리할 수 있습니다. 덧붙여, 이용자가 파일을 업로드할 수 있는 경우 악성코드를 목적으로 전달된 콘텐츠를 메인서버에서 확인하기 이전에 해당 콘텐츠가 적합한지 검사하기 위해 이용될 수 있습니다. 따라서 한단계의 중계서버를 거치기 때문에 보안성은 더욱 높아지고 민감한 정보가 저장된 메인서버를 지키기 더 수월해집니다.

웹팩에서 프록시 사용하기

// webpack.config.js
module.exports = {
  devServer: {
    proxy: {
      '/api': 'http://localhost:3000'
    }
  }
};

CRA를 통해 만든 리액트에서의 프록시 적용

...
"browserslist": {
    "production": [
      ">0.2%",
      "not dead",
      "not op_mini all"
    ],
    "development": [
      "last 1 chrome version",
      "last 1 firefox version",
      "last 1 safari version"
    ]
  },
    "proxy" : "우회할 API 주소"
}
//proxy는 보통 맨 밑에 작성을 해 금방 찾을 수 있도록 합니다.

기존의 fetch, 또는 axios를 이용해 요청하던 부분에서 도메인 주소만을 삭제합니다.

export async function getAllfetch() {

    const response = await fetch('우회할 api주소/params');
    .then(() => {
            ...
        })
}

위의 코드에서 우회할 api주소 만을 삭제해 아래 코드처럼 바꾸면, proxy 미들웨어가 알아서 잡아줍니다. 원리가 궁금하다면, 미들웨어 참고 주소 [https://www.npmjs.com/package/proxy-middleware]

export async function getAllfetch() {

    const response = await fetch('/params');
    .then(() => {
            ...
        })
}

가장 많이 사용하는 번들러답게 공식문서도 한글로 번역이 되어있고, 자료도 쉽게 찾을 수 있어 처음 번들링에 대해서 학습할 때 참고하기 좋습니다.

Webpack이란

여러 개의 파일을 하나의 파일로 합쳐주는 모듈 번들러를 의미합니다. 모듈 번들러란 HTML, CSS, JavaScript 등의 자원을 전부 각각의 모듈로 보고 이를 조합해 하나의 묶음으로 번들링(빌드)하는 도구입니다.

1. 모듈 번들러(Module Bundler)의 등장

모던 웹으로 발전하면서 JavaScript 코드의 양이 절대적으로 많이 증가했고, 또 대규모의 의존성 트리를 가지고 있는 대형 웹 애플리케이션이 등장하므로써 세분화된 모듈 파일이 폭발적으로 증가했습니다. 이 모듈 단위의 파일들을 호출을 해 브라우저에 띄워야 하는데, JavaScript 언어의 특성에 따라 발생하기 쉬운 각 변수들의 스코프 문제를 해결해야 하고, 각 자원을 호출할 때에 생겨나는 네트워크 쪽의 코스트도 신경써줘야만 했습니다.

각 모듈에서 쓰이는 변수의 이름의 종속성과 순서 문제/ 네이밍 충돌 / 비효율적일정도로 많은 통신

그래서 이런 복잡성에 대응하기 위해 하나의 시작점(Ex. React App의 index.js 등)으로부터 의존성을 가지는 모듈을 모두 추적하여 하나의 결과물을 만들어내는 모듈 번들러가 등장하게 되었습니다.

네트워크 코스트 해결 위 사진에서 8번의 requests와 305ms의 시간이 소요된 반면3번의 requestsfh 184ms가 걸린 것을 확인할 수 있다.

2. Entry, Output, Loader, Plugin 설정

웹팩의 4가지 핵심 개념

1)Target

2)Entry

3)Output

4)Loader

5)Plugin

2-1. Target 설정

Webpack은 다양한 환경과 target을 컴파일합니다. target의 기본값은 web입니다. 적용하지 않으면 해당 기본 값으로 적용됩니다. 이 부분에는 web 외에도 다양한 환경을 컴파일 할 수 있는데, esX를 넣으면 지정된 ECMAScript 버전으로 컴파일할 수 있습니다.

module.exports = {
  target: ["web", "es5"],
};

해당 config 파일에서는 es5를 배열 안에 넣었습니다. 따라서 이 config 파일은 브라우저와 동일한 환경에서 사용하기 위하여 컴파일할 것이며, 작성된 코드를 es5 버전으로 컴파일 하겠다고 지정한 것임을 알 수 있습니다. Browser Compatibility와 연관된 속성으로 볼 수 있습니다.

2-2. Entry 설정

webpack은 번들링 과정에서 '디펜던시 그래프(dependency graph)'를 그린다. 특정 지점에서 출발해서, 애플리케이션에 필요한 모든 모듈을 포함하는 그래프를 재귀적으로 완성해 나간다. 한 파일이 다른 파일을 필요로 하면 이를 '디펜던시(dependency)'가 있다고 해석하는데, 이 방식으로 웹팩은 이미지 또는 웹 글꼴과 같이 코드가 아닌 리소스도 디펜던시로 관리할 수 있게 된다. 그래프를 모두 그리고 나면 이 모든 모듈을 소수의 번들로 묶어서 (보통 하나의 번들로 묶는다) 브라우저에 로드될 준비를 마친다.

이때 우리는 webpack이 어디를 출발지점으로 해서 그려나가면 좋을지 알려주어야 한다. config파일에서 entry 속성을 설정해서 웹팩이 어떤 모듈로부터 시작해서 디펜던시 그래프를 그려나갈지 명시해줄 수 있다. 'entry' 속성의 기본값은 './src/index.js'이지만 다른 Entry Point를 지정할 수도 있다. (여러 개도 지정 가능)

//기본 값
module.exports = {
    ...
  entry: "./src/index.js",
};

//지정 값
module.exports = {
    ...
  entry: "./src/script.js",
};

기본 값은 ./src/index.js이지만 webpack 설정에서 이런 식으로 Entry 속성을 설정하여 다른 (또는 여러 entry point)를 지정할 수 있습니다.

2-3. Output 설정

Output 속성은 생성된 번들을 내보낼 위치와 이 파일의 이름을 지정하는 방법을 webpack에 알려주는 역할을 합니다.

const path = require('path');

module.exports = {
    ...
  output: {
    path: path.resolve(__dirname, "docs"), // 절대 경로로 설정을 해야 합니다. 
    filename: "app.bundle.js",
    clean: true
  },
};

기본 출력 파일의 경우에는 ./dist/main.js로 , 생성된 기타 파일의 경우에는 ./dist 폴더로 설정됩니다. 위의 예제에서는 output.filename과 output.path 속성을 사용하여 webpack에 번들의 이름과 내보낼 위치를 알려주고 있습니다. path 속성을 사용할 때는 path 모듈을 사용해야만 합니다.

2-4. Loader 설정

이제까지 자바스크립트 외의 리소스도 번들링할 수 있다고 했지만, 사실 웹팩은 기본적으로 JavaScript와 JSON 파일만 이해할 수 있다. 이 때 필요한 것이 Loader이다. 사용하려는 포맷에 대응하는 Loader를 설정해주면 다른 포맷의 리소스도 디펜던시 그래프에 추가할 수있게 된다.

Loader를 설정하려면 'test'와 'use' 두 가지 필수 속성을 적어주어야 한다. 'test'는 어떤 파일을 변환할지 지정하는 속성으로, 보통 /.txt$/과 같이 정규표현식으로 작성한다. 이 때, /.txt$/ 과 같이 따옴표 없이 작성해야한다. '/.txt$/' 또는 "/.txt$/"와 같이 따옴표를 넣으면 빌드가 제대로 안될 것이다,,, 'use'는 파일을 변환할 때 어떤 로더를 사용해야하는지 명시하는 속성이다. 이렇게 Loader를 설정해주면 포맷에 얽매이지 않은 자유로운 import가 가능하다. 예를 들어 js파일에서 import '../css/index.css';과 같이 해당 모듈에서 필요한 css파일을 import해올 수 있다. 웹팩을 사용하기 전에는 상상할 수 없었던 일이다! 이 기능은 다른 번들러에서는 지원되지 않을 수도 있다고 한다.

module.exports = {
    ...
  module: {
    rules: [
      {
        test: /\.css$/,
        use: [MiniCssExtractPlugin.loader, "css-loader"],
        exclude: /node_modules/,
      },
    ],
  },
};

상위 수준에서 loader는 webpack 설정에 몇 가지 속성을 가집니다.

test: 변환이 필요한 파일들을 식별하기 위한 속성 use: 변환을 수행하는데 사용되는 로더를 가리키는 속성 exclude: 바벨로 컴파일하지 않을 파일이나 폴더를 지정. (반대로 include 속성을 이용해 반드시 컴파일해야 할 파일이나 폴더 지정 가능)

2-5. Plugin 설정

Plugins를 사용하면 번들을 최적화하거나 에셋을 관리하고, 또는 환경변수 주입 등의 광범위한 작업을 수행할 수 있게 됩니다.

const webpack = require('webpack');
const HtmlWebpackPlugin = require("html-webpack-plugin");
const MiniCssExtractPlugin = require("mini-css-extract-plugin");

module.exports = {
  ...
  plugins: [
    new HtmlWebpackPlugin({
      template: path.resolve(__dirname, "src", "index.html"),
    }),
    new MiniCssExtractPlugin(),
  ],
};

로더가 파일단위로 처리하는 반면 플러그인은 번들된 결과물을 처리한다. 로더가 변환하는 동안 플러그인은 bundle optimization, asset management and injection of environment과 같은 일을 진행할 수 있다

Internet Service Provider

우리가 흔히아는 통신3사 그외 알뜰폰 사업자, 방송통신사업자, 인터넷 회선과 IP할당을 하는 기업, 회선에 대한 소유권을 가지고 통신사업자에게 임대하는 기업등이 여기에 속한다.

Router - 라우터

동일한 전송 프로토콜을 사용하는 분리된 네트웍을 연결하는 장치로 서로다른 계층의 네트워크를 연결하는 물리적 혹은 소프트웨어적 장치를 말한다. 라우터는 브리지가 가지는 기능에 추가하여 경로 배정표에 따라 다른 네트웍 또는 자신의 네트웍 내의 노드를 결정한다. 그리고 여러 경로 중 가장 효율적인 경로를 선택하여 패킷을 보낸다. 라우터는 흐름제어를 하며, 인터네트웍 내부에서 여러 서브네트웍을 구성하고, 다양한 네트웍 관리 기능을 수행한다. 브리지와 라우터의 차이점을 간단히 살펴보면, 라우터는 네트웍 계층까지의 기능을 담당하고 있으면서 경로 설정을 해주는 반면, 브리지는 데이터링크 계층까지의 기능만으로 목적지 주소에 따른 선별 및 간단한 경로 결정을 한다.

라우터의 장점

환경설정 가능 : 관리 방침에 따라 라우팅 방식이 결정, 전체 네트웍의 성능이 개선된다. 유지보수의 용이 : 알고리즘에 따라 자동으로 경로가 결정된다. 확장이 용이 : 네트웍 형상에 구애받지 않으므로 대규모 네트웍 구성이 용이하다.

라우터의 단점

초기 환경설정이 어렵다. 특정 프로토콜이나 하위 프로토콜 지원이 불가능하고 복잡하므로 가격이 비싸다.

Bridge - 브릿지

연결하는 다리라는 의미와 동일하게 브릿지는 랜을 이더넷이나 서로 같은 프로토콜을 쓰고 있는 다른 랜과 연결시켜주는 제품을 말하며, 각 랜에 연결되어 있는 스테이션들은 프로토콜을 바꾸지 않고서도 랜이 확장되는 혜택을 받을 수 있게 된다.

브릿지로 연결된 네트웍들에서 컴퓨터나 노드 주소들은 실제 위치와 특별한 상관관계가 없다. 이러한 이유로, 모든 메시지들은 네트웍 상의 모든 주소로 보내지지만, 그 메시지들은 오직 목적지 노드에 의해서만 받아들여진다. 브릿지는 어떤 주소들이 어떤 네트웍에 있는지를 미리 파악하고, 메시지들을 정확히 다른 네트웍으로 전달할 수 있도록 미리 표를 작성해 놓는다. 브릿지로 연결된 네트웍들은 일반적으로 항상 서로 연결되어 있고, 모든 메시지들을 브로드캐스팅하기 때문에 대형 네트웍인 경우 불필요한 네트웍 트래픽들이 쇄도할 수도 있다. 이러한 이유로, 인터넷과 같은 라우팅 네트웍은 각 노드에 주소를 할당함으로써, 메시지나 패킷들이 모든 방향으로 전달되는 대신에 한 방향으로만 전달될 수 있도록 하고 있다. 브릿지는 네트웍의 데이터링크 계층에서, 통신 선로를 따라 한 네트웍에서 그 다음 네트웍으로 데이터 프레임을 복사하는 일을 한다.

게이트웨이 - Gate + Way

게이트와 길or방향. 즉, 다른 네트워크로 들어가는 입구 역할을 하는 네트워크 지점을 말한다.

라우팅의 관점에서 보면, 인터넷은 많은 게이트웨이 노드들과 호스트 노드들로 구성된 네트워크라고 할 수 있는데, 네트워크 사용자들의 컴퓨터들과 웹페이지와 같은 콘텐츠를 제공하는 컴퓨터들이 바로 호스트 노드들이며, 일반 회사의 네트워크 내에서 트래픽을 통제하는 컴퓨터들이나, [ISP]인터넷 서비스제공자들의 컴퓨터가 바로 게이트웨이 노드들이다.

백본

BackBone 척추, 뼈대를 뜻하지만 SW산업에서는 자신에게 연결되어 있는 소형 회선들로부터 데이터를 모아 빠르게 전송할 수 있는 대규모 전송회선을 말한다. 네트워크의 물리적 . 다양한 네트워크를 상호연결하는 척추 속 척수라고 보아도 좋다.

OSI 7계층과 TCP/IP 4계층

TCP/IP [Transmission Control Protocol) / [Internet Protocol]

데이터 통신을 위한 약속[프로토콜]의 한 종류. 과거 동기적 통신을 비동기적이면서 경로가 중간에 단절되더라도 우회해서 들어올 수 있도록 개발됨 경로가 정해져있기 않기에, 중간 회선하나가 단절되어도 연결 경로만 있다면 통신 가능 패킷교환의 방식으로 비동기적

패킷교환 방식의 예시

패킷 전송의 장점과 특징

네트워크 자원을 패킷 단위로 나누어 동시간대에 여러 자료를 전송할 수 있기에 전송 효율이 높다 한번에 많은 데이터를 전송할 수 없기에 데이터의 순서가 적힌 "패킷"을 비동기적으로 여러번 전송한다. 수신하는 곳에서는 패킷 나열을 다시 원본 파일로 재구성하여 파일을 받게된다.

TCP의 주요한 특징

신뢰된 연결설정

a. 통신 요청콜 -> b.요청 콜에 대한 응답[가능/불가] -> c.응답 확인 및 연결 회선교환 방식은 a,b,c가 똑같이 이루어지지만 경로[Route]에 대해 훨씬 자유롭다.

신뢰성 보장

확인응답 + 복원과정 오류 검출을 통해 토신의 신뢰성 보장

혼잡제어

-라우터의 데이터 저장에는 한계점이 있기에 모든 경로의 라우터가 혼잡할시 데이터 손실 발생 -데이터 수신측에서 수신 검증 + 수신 패킷량을 응답하고, 전송측은 수신속도에 맞추어 패킷 전송량을 조절

이메일 혹은 파일전송에 있어서 데이터의 손실은 용납할 수 없지만, 전송속도의 측면이 더 중요한 경우 UDP라는 데이터 통신 프로토콜을 사용한다.

UDP[User Datagram Protocol]

UDP는 TCP와 다르게 데이터 전송의 신뢰성이 보장되지 않는다 전송과정에서 손실되는 데이터가 발생할 확률이 높지만 그대신 전송속도가 빠르고 서버 자원을 절약할 수 있다. 이러한 특징을 이용해 주로 동영상/음악 스트리밍 분야와 VolP,mVolP에서 사용되고 있다. 대표적으로 온라인 게임 [클라이언트 => 서버] 에서의 활용.[종종 핑 누락이 생기는이유] 2022년 6월6일 IETF[국제인터넷표준화기구]에서 HTTP/3의 표준으로 RFC 9114를 발표하였다.

하지만 UDP도 TCP만큼은 아니지만 신뢰성을 어느정도 보완할 수 있다. 이러한 점을 이용해 속도와 데이터 신뢰성과 보안을 함께 갖춘 통신 프로토콜 표준이 완성되었고 그것이 바로 HTTP/3이다. HTTP와 HTTP/2가 TCP로 통신하는 것과 달리 HTTP3는 UDP기반의 QUIC프로토콜을 사용하여 통신한다. 당연히 유튜브도 HTTP/3를 사용중이고. 구글과 페이스북, 인스타그램, 디스코드 또한 HTTP/3를 사용중이다. QUIC는 구글의 자체 프로토콜이였고, IETF에서는 구글의 QUIC의 보안소켓을 표준 프로토콜인 DTLS로 대체하는 표준을 만들고 있다.

미들웨어의 정확한 정의는 OS[운영체제]와 응용 프로그램 사이에서 동작하는 프로그램을 의미합니다.

함수 또한 작은 프로그램이라고 볼 수 있으니 Express에서 말하는 미들웨어 또한 미들웨어의 정의에 부합합니다.

우리는 Express에서 app.use(express.json()); 라는 코드를 추가해,

• 요청 http 프로토콜의 [바디]에 들어있는 JSON [데이터]를 => [req 객체]의 [body 프로퍼티]에 설정하도록 했습니다.
• express의 json 메소드는 미들웨어를 리턴하는 메소드이고, 미들웨어란 리퀘스트를 처리하는 기능을 하는 함수라고 했었는데요.

express의 json이라는 메소드는 어떤 미들웨어(함수)를 리턴하는 걸까요? 한번 코드를 파헤쳐봅시다.

그럼 한번 express의 맨처음 코드인 아래코드가 실행될때 참조되는 파일인 index.js 파일을 찾아가봅시다.

const express = require(‘express’);

index.js 파일을 로컬 스토리지의 express 디렉토리[폴더]에서도 찾을 수 있지만, Express 는 오픈소스 프로젝트이기에 github에서 직접 들어가서 확인할 수 있습니다.

Express 깃 허브 페이지

https://github.com/expressjs/express

원본 코드를 보려고 들어갔드니 새로운 경로를 알려주시네...

위 사진에서 볼 수 있듯이. index.js 파일은 lib디렉토리 안에 있는 express라는 파일에서 모듈을 가져오는군요. 그럼 해당 파일로 올라가봅시다. lib/express.js 파일을 열어서 그 상단 부분을 보면

express.js 파일에서는 createApplication라는 함수가 선언되어있고 createApplication 함수는 실행될 때 => app이라는 함수를 리턴한다는 것을 알 수 있습니다. 그러니까 결국 아래 코드에서 저희가 보았던 app 객체는 함수였던 것이죠.

const express = require('express');
const app = express();세요

그리고 express.js 파일에서 조금만 더 아래로 내려가보면 [70~80번째줄]

(바로 이전에 확인한 것처럼 exports는 createApplication의 함수를 가리킵니다)

이런 식으로 createApplication 함수에 json이라는 프로퍼티를 생성하고(만들고) 있습니다.

그렇기때문에 저희가 아래 코드를 처음에 입력한 순간부터 바로 json()을 쓸 수 있엇던 것 입니다.

const express = require(‘express’);

app.use(express.json());

그렇다면 지금 json 프로퍼티에 설정된 bodyParser.json이라는 건 무엇이고 어디에서 온 것 일까요?

bodyParser는 사실 express 패키지 내부에 없습니다.

express 패키지가 의존하고 있는 => 다른 패키지에 있는 객체인데요. 약간 어지럽죠..?

이따가 다시 한번 정리하겠습니다. 잠깐 express 패키지의 package.json 파일을 살펴보면,

express의 package.json파일을 보면 의존성관리 항목에 body-parser가 있다.

Express의 packge.json에 있는 의존성[dependencies] 패키지들 중에 body-parser라는 패키지가 있다는 걸 알 수 있습니다. 이 패키지를 봐야 json 함수의 정체를 온전히 파악할 수 있습니다. 타고들어가고 또 타고들어가서 또 타고들어가는...

그러고나서 npm 사이트에 들어가서 body-parser를 찾아보면 아래와 같은 화면이 나오는데.

위 내용을 정리하자면. 서버로 들어오는 요청을 라우트 핸들러에 도달하기 전에 리퀘스트의 바디를 파싱(parsing)해주는 기능을 가진 패키지라는 설명입니다.

라우트 핸들러란?

라우트 핸들러[Route Handler]란 특정 path에 지정된 메소드를 리퀘스트 처리해주는 함수를 의미합니다. 어떤 기능을 하냐면 => 지정된 경로에 맞춰서 리퀘스트를 처리해주거나 보통은 컨트롤러로 옮겨주는 역할을 수행하죠.

app.get('/api/members', async (req, res) => {
  const { team } = req.query;
  if (team) {
    const teamMembers = await Member.findAll({ where: { team } });
    res.send(teamMembers);
  } else {
    const members = await Member.findAll();
    res.send(members);
  }
});
 "여기서는 async로 시작되는 함수가 라우트 핸들러인 거죠."

그러니까 body-parser 패키지는 요청이 라우트 핸들러에 의해 처리되기 전에 먼저=> HTTP 응답의 바디에 관한 처리하는 기능을 갖고 있는 패키지입니다. 또한 body-parser에는 JSON 형식의 데이터를 파싱하는 기능도 있음을 알 수 있습니다.

자그럼 GitHub 링크를 클릭해서 body-parser 패키지에서 필요한걸 찾아옵시다. 마찬가지로 body-parser 패키지도 오픈소스입니다 이번에도 index.js 파일을 열고. 코드 중간을 보면 아래와 같은

일단 exports가 가리키는 객체가 설정되어있고

그 아래에 Object.defineProperty로 시작되는 코드는 exports 객체에 json이라는 프로퍼티를 설정하는 코드입니다.

지금 defineProperty 메소드의 세 번째 매개변수로 들어온 객체는 json이라는 프로퍼티 자체가 가질 속성들인데요.

여기서 get이라는 부분은 나중에 이 프로퍼티에 접근할 때 실행될 getter 함수를 의미합니다.

Recap!                    

express.json은
bodyParser.json을 의미하고
createParserGetter('json')의 리턴값을 가리킵니다! 

자 근데 createParserGetter의 리턴값은 무엇을 가르킬까요? ㅎㅎ...

createParserGetter 함수도 같은 파일 안에 들어있는데요. createParserGetter 함수는 => get 함수를 리턴하네요.

이 get이라는 함수는 다시 loadParser 함수의 리턴 결과를 리턴합니다. 아래 코드를 보면서 loadParser함수도 한번 확인해봅시다.

loadParser 함수에는 switch case 문이 있습니다!

Swith case 조건문에서는 문자열 'json'을 발견하면 => 또다른 파일에서 가져온 parser를 parsers 객체에 설정! 그후 => parser 배열을 리턴합니다.

그러므로 parser 에는 =>lib/types/json.js 파일에서 가져온 =>parser들이 들어간 배열이 됩니다.

parser만으로 이루어진 parser 타입같은 배열이랄까요?

슬슬한계가 오고 있겠지만 정말 곧 끝입니다! 거의 다 왔어요!

아래 코드에 보이는 ./lib/types/json 파일로 가보겠습니다.

자, 이 파일은 json이라는 함수를 리턴하고 있습니다. 그리고 json 함수는 결국 jsonParser라는 함수를 리턴합니다.

body-parser의 json파일 내부 json함수에 대한 코드를 보시면

json 함수가 => jsonParser 함수를 리턴하는걸 볼 수 있습니다!

Velog에서는 접은글 기능을 사용할 수 없네요.. 코드가 너무 길기 때문에 건너뛰시려면 스크롤을 많이 내리셔야합니다.

function json (options) {
  var opts = options || {}

  var limit = typeof opts.limit !== 'number'
    ? bytes.parse(opts.limit || '100kb')
    : opts.limit
  var inflate = opts.inflate !== false
  var reviver = opts.reviver
  var strict = opts.strict !== false
  var type = opts.type || 'application/json'
  var verify = opts.verify || false

  if (verify !== false && typeof verify !== 'function') {
    throw new TypeError('option verify must be function')
  }

  // create the appropriate type checking function
  var shouldParse = typeof type !== 'function'
    ? typeChecker(type)
    : type

  function parse (body) {
    if (body.length === 0) {
      // special-case empty json body, as it's a common client-side mistake
      // TODO: maybe make this configurable or part of "strict" option
      return {}
    }

    if (strict) {
      var first = firstchar(body)

      if (first !== '{' && first !== '[') {
        debug('strict violation')
        throw createStrictSyntaxError(body, first)
      }
    }

    try {
      debug('parse json')
      return JSON.parse(body, reviver)
    } catch (e) {
      throw normalizeJsonSyntaxError(e, {
        message: e.message,
        stack: e.stack
      })
    }
  }

  return function jsonParser (req, res, next) {
    if (req._body) {
      debug('body already parsed')
      next()
      return
    }

    req.body = req.body || {}

    // skip requests without bodies
    if (!typeis.hasBody(req)) {
      debug('skip empty body')
      next()
      return
    }

    debug('content-type %j', req.headers['content-type'])

    // determine if request should be parsed
    if (!shouldParse(req)) {
      debug('skip parsing')
      next()
      return
    }

    // assert charset per RFC 7159 sec 8.1
    var charset = getCharset(req) || 'utf-8'
    if (charset.slice(0, 4) !== 'utf-') {
      debug('invalid charset')
      next(createError(415, 'unsupported charset "' + charset.toUpperCase() + '"', {
        charset: charset,
        type: 'charset.unsupported'
      }))
      return
    }

    // read
    read(req, res, next, parse, debug, {
      encoding: charset,
      inflate: inflate,
      limit: limit,
      verify: verify
    })
  }
}

그럼 한번 더 정리하자면.

Express 프레임워크에서 우리가 쓰는 express.json() 이것은 지금 보이는 jsonParser라고 하는 함수를 리턴하는 부분이었던 겁니다.

app.use(express.json());

좀 더 구체적으로 설명하자면.

맨 처음 우리가 추상적으로 썻던 위의 코드는 app.use(jsonParser); 사실 jsonParser를 json()으로 표현한 것이고. jsonParser 함수의 파라미터는 req, res, next 라는 3개의 파라미터가 있고. 마지막 next 파라미터로 넘어오는 함수를 마지막에 호출함으로서.

function jsonParser (req, res, next) {
...
...
  next();
}

HTTP 요청 / 응답 을 다음 미들웨어나 라우트 핸들러로 넘기는 것. 이라고 이해하면 되겠습니다.

jsonParse에 대한 더 구체적인 흐름은 위에 첨부한 json function 코드를 참고하시고.

parse와 통신 과정에서의 정확한 원리는  IETF 국제 인터넷 통신 표준 협회의 HTTP 통신에 관한 문서에서 parse와 패킷에 대한 부분을 확인해주세요. [저 협회에서 HTTP, HTTPS, HTTP/3 , WEB3.0 등의 iso 프로토콜 표준을 만든답니다.] https://www.rfc-editor.org/rfc/rfc9110.html

긴글 읽으시느라 정말... 수고하셨습니다!

Part1에서는 디자인 시스템이 무엇인지, 어떤 특징을 가지고 있는지 알아봤습니다. Part2에서는 디자인 시스템의 구성요소에 대해 자세히 알아봅시다.

잠시 생물시간으로 돌아가봅시다.

사람은 수많은 세포들로 이루어져있습니다. 그리고 세포는 지방세포/근육세포/신경세포/적혈구/백혈구/상피세포 등 정말 다양한 종류가 있습니다.

이러한 세포들이 모여 "조직"을 이루고, 조직들이 모여 기관을 구성하고 기관들이 모여 하나의 기관계를 구성합니다. 그리고 이 기관계가 모인 것이 하나의 유기체이죠.

이 세포들이 어떻게 조직을 구성하고 어떻게 위치되는지에 따라 사람이 될 수도 있고 원숭이,개,고양이,고래 등이 될 수도 있습니다. 조금 더 극단적으로 바나나가 될 수도 있습니다. 왜냐하면 바나나와 사람의 DNA는 60% 가까이 일치하기 때문입니다. 실제로도 사람 채내 화학반응의 50% 이상이 바나나에서도 똑같이 이루어집니다.

DNA라는 방대한 설계도안에 명시된 배열과 조직간의 관계 위치에 따라 비슷한 세포조직을 가지고도 이렇게 다양한 결과가[고래부터쥐바나나] 나올 수 있는 것이죠.

디자인 시스템 또한 DNA라는 설계도와 유사합니다. 공통되고 반복되는 작은 요소들이 > 큰 요소를 만들고 > 큰 요소가 모여 개체가 되었듯이 최소한의 디자인 단위들과 그것들로 이루어진 작은 컴포넌트 > 작은 컴포넌트로 이루어진 구성요소 > 커다란 구성요소[상단/사이드바/푸터 등]들이 모여 하나의 서비스를 만듭니다.

구체적인 사례를 한번 볼까요?

구글의 머티리얼 디자인 - Navigation drawer

네비게이션 드로어의 디자인 구성요소와 기능에 대해 자세히 작성되어 있네요.

하지만 다른 IT회사들이 구글의 디자인 시스템을 따라할 필요는 없겠죠? 예상하다시피 디자인 시스템은 각 회사들마다 기능과 정의가 조금씩 다릅니다. 전체적인 구성요소는 비슷할지언정 세부 목적이 서로 다르기 때문이죠.

그렇지만 디자인 시스템들을 보면 거의 항상 아래 3가지가 포함됩니다.

디자인 시스템

• 스타일 가이드 - 가이드라인

• 패턴 라이브러리 - 컴퍼넌트와 패턴의 집합

• 시스템 가이드

*그럼 순서대로 스타일 가이드/ 패턴 라이브러리 / 시스템 가이드에 대해 알아보겠습니다. *

1. 스타일 가이드

디자인의 기준과 요소 원칙에 따라 만들어진 가이드를 스타일 가이드라고 합니다. 스타일 가이드는 회사마다 다르기는 하지만, 디자인원칙과 컬러,아이콘, 쉐이프, 타이포그래피 그리고 컴포넌트로 이루어져 있습니다. 아래 그림을 참고하면 좀더 이해하기 좋습니다.

1-1. 디자인 원칙

디자인 원칙은 제품이나 서비스의 디자인에 대한 대전제와 나침반 같은 역할을 합니다 보통은 3개에서 6개 정도 되는 키워드로 디자인 원칙을 만들고 필요하다면 더 자세한 디자인 가이드를 추가합니다.

디자인 원칙은 프로젝트를 진행하는 데 있어서 구성원간의 기능 등에 대한 논쟁 시 서비스 방향성의 기준이 되기에 의사결정을 할 때 큰 도움이 됩니다. 디자이너들과 개발자들 그리고 기획자들이 함께 협업을 하다 보면 원래의 목표나 방향성을 잃기 쉬운데 디자인 원칙을 떠올리며 원칙을 기준삼아 자신의 디자인이 서비스의 방향과 부합하는지 판단을 도와주는 역할도 합니다.

구글 머티리얼 디자인의 원칙

Material is the metaphor

Material Design is inspired by the physical world and its textures, including how they reflect light and cast shadows. Material surfaces reimagine the mediums of paper and ink.

Bold, graphic, intentional	Motion provides meaning
Material Design is guided by print design methods — typography, grids, space, scale, color, and imagery — to create hierarchy, meaning, and focus that immerse viewers in the experience	Motion focuses attention and maintains continuity through subtle feedback andtransitions. As elements appear on screen, they transform and reorganize environment with interactions

1-2. 컬러

컬러는 디자인 시스템에서 컴포넌트의 위계 순서를 체계적으로 만드는데 중요한 역할을 합니다. 예를들어 명암이나 채도를 통해 제목은 진하게 내용은 연하게, 중요한 정보는 더 가독성있게 만들면 한눈에 이해하기 쉽겠죠. 그리고 상태 값에 대한 컬러는 State의 변화 측면에서 중요도를[EX: 이미 읽어본 메일인지 아닌지] 유저에게 간편하게 알려줄 수 있습니다. 그렇기 때문에 컬러는 디자인 시스템에서 제대로 정의하고, 구체적인 명도와 채도에 대한 사용 범위, 위계에 따른 규칙이나 컬러코드 값을 정리해두는게 좋습니다.

1-3. 타이포 그래피

웹이나 앱에서는 타이틀과 바디 등 컴포넌트에서 해상도나 상황에서 따라 한글,영문 폰트를 어떻게 설정한 것인지 정리해둡니다. 헤드라인에서 서브 타이틀/바디/캡션/오버 라인 등 여러 상황에서 어떤 폰트를 어떻게 사용할지 디자인 시스템에서 정의합니다.

1-4. 아이콘

아이콘은 사람들 머릿속의 심볼을 시각적으로 표현한 것으로. 유저에게 어떤 상태나 기능이 동작할 수 있음을 매우 직관적으로 알려주는 수단으로 사용되고있습니다. 디자인 시스템에서는 이런 아이콘들을 각 상태별 사용 방법에 대해 정의하고. 예시나 실제 디자인 소스를 필요할 때 가져가 쓸 수 있도록 벡터이미지로 만들어야 합니다. 구글 디자인 시스템 - (Icon) 문서보기

1-5. 쉐이프

디자인 시스템에서 쉐이프 파트란, 네모의 귀퉁이를 얼마나 알값을 줄 것인지 어떤 상황[State]에서 쉐이프의 투명도를 어떻게 조절할 것인지 네모 버튼을 쓸 것인가 동그라미 버튼을 쓸 것인가와 같이 컴포넌트나 디자인 요소의 형태 모양에 대한 그러한 것들을 정의하는 것이 쉐이프 파트입니다.

구글의 Shape 문서

Displaying shape

Shape is made visible when surface edges have sufficient contrast against their background. By default, Material Design makes shapes noticeable by using shadows to display surfaces edges. Other methods to show surface edges and shapes can be used in combination with shadows, or on their own, such as color fills and opacity, .

1-6. 컴포넌트

컴포넌트는 이미 다들 알고계시겠지만, 다시 한번 이야기해보자면 Bar라든가 메뉴, 네비게이션, 아티클 박스 등 화면을 이루는 구성 요소들을 컴포넌트라고 부르는데요. 스타일 가이드에서는 이러한 각각의 컴포넌트를 디자인하는 방법을 명시해야합니다.

해당 컴포넌트에 대한 정의와 크기가 얼마나 되고 구체적이고 수치가 적힌 스펙, 활용 방법이나 예시,용례를 문서화하여 명시해둡니다. 그리고 해당 컴포넌트가 가지는 여러 상태 값과 그에 따른 변경 방식, 여러 개가 동시에 존재할 때의 배치 등도 고려해 문서를 작성합니다.

이렇게 스타일 가이드에 대해 알아봤습니다.

스타일 가이드는 디자인 원칙 + 컴포넌트 + 파운데이션의 모임,집합이라고 볼 수 있습니다.

디자인 시스템의 세가지 구성요소 중 2번째 패턴 라이브러리에 대해 살펴봅시다.

2. 패턴 라이브러리

스타일 가이드가 일종의 디자인 사용 설명서라면 패턴 라이브러리는 마치 도서관처럼 가지고 있는 디자인 패턴이라면 언제든지 꺼내 사용할 수 있는 디자이너의 패턴 도서관을 의미합니다. 패턴 라이브러리 안에는 반복되는 디자인 요소들을 패턴으로 만들어둔 완성된 다양한 컴포넌트들이 존재하면서 디자이너나 개발자들이 언제든지 가져다 쓸 수 있게 새로운 서비스를 만들어야 한다거나 새로운 화면을 만들어야 되면 이러한 패턴 라이브리에서 필요한 컴포넌트를 쏙쏙 빼서 쓸 수 있게 되어 있는 마치 데이터베이스 같은 역할을 합니다.

대표적으로, 나의 정보 페이지 혹은 시즌별 광고 팝업을 예시로 들 수 있겠는데요. 이런 팝업창 안에는 이미지도 있고 텍스트도 있고 아이콘도 있는 경우가 있고, 대게 그 구성 순서나 배치가 유사하거나 동일합니다. 이런 것들을 패턴으로 패턴라이브러리에 저장해두고 다시 사용하게 되었을 때 이미 준비된 템플릿으로 디자인 업무 효율을 높여주는 방법입니다.

우리는 지금까지 시각적인 가이드들을 담아두는 그릇에 대해 알아봤습니다. 앞의 스타일가이드와 패턴 라이브러리와는 다르게 비시각적인 가이드인 디자인 시스템의 3번째 구성요소 시스템 가이드에 대해 알아 봅시다.

3.시스템 가이드 - 지침

시스템 가이드는 1.팀의 목표 2.구성원에 대한 소개 3.커뮤니케이션 가이드 4.자료 공유 방법 이 명시되어 있는 일종의 지침서입니다.

3-1.시스템 가이드 - 목표

목표는 말 그대로 디자인 시스템을 운영하거나 이루고자 하는 목적에 대한 명시이고 해결하고자 하는 문제는 서비스나 프로덕트에서 정확히 어떤 문제인지 원인은 무엇인지 목적을 통해 어떻게 개선할 수 있는지 이러한 목적을 같이 명시함으로서 내부의 디자인 시스템을 처음 본 새로온 디자이너나 개발자들이 긴 인수인계의 과정없이 빠르게 적응 할 수 있게 해줍니다.

3-2. 구성원에 대한 소개

소개는 말 그대로 디자인 시스템을 운영하는 데 있어서 담당 부서-담당자가 누구인지 그리고 수정 권한을 가진 사람과 이런 수정된 것들을 검토할 수 있는 사람 팀원들에게 배포하거나 교육을 담당한 사람은 누구인지 구성원들의 롤과 능력 등을 명시해 놓은 문서입니다.

3-3. 커뮤니케이션 가이드

커뮤니케이션 가이드란 디자인 시스템 관련해서 이슈라든가 파일을 공유할 채널의 플랫폼과 Url/ 신규 팀원의 경우 아이디 생성과 초대 요청 방법, 슬랙이라든가 노션이라든가 피그잼 등과 같은 url의 접속 방법과 커뮤니케이션 시의 규칙이 적힌 가이드입니다.

3-4. 이슈/자료 공유방법

디자인 시스템이 바뀐 경우 이에 대한 수정 요청을 다른 사람들한테 알리는 것은 정말 어렵습니다. 그렇기 때문에 이러한 변경된 사안들을 어떤 식으로 잘 공유할 것인가 그 공유에 대한 프로세스를 잘 잡는 것 또한 디자인 시스템의 한 요소라고 할 수 있겠습니다.

이렇게 Part-2에서는 디자인 시스템을 구성하는 요소

1. 스타일 가이드
2. 패턴 라이브러리
3. 시스템 가이드

회사가 가지고 있는 모든 UI 리소스들과 일관된 디자인을 위한 원칙(Principle)과 해당 원칙을 기반으로 만들어진 디자인 패턴과 적용가능한 예제 그리고 스타일가이드가 모인

"방대한 디자인 데이터 라이브러리" 입니다.

(출처/참고 : Anatomy of a Design System, Adobe 디자인 시스템 디자이너 Nate Baldwin)

패턴라이브러리란 패턴라이브러리는 반복적으로 혹은 자주 사용되는 디자인 요소들의 모임이자 Library -저장소 입니다. 그렇다면 패턴라이브러리가 디자인시스템이 아닌가 하는 의문이 생길 수 있습니다. 하지만 디자인시스템은 시각적/비시각적인 요소들을 모두 포괄하는 디자인 원칙과 소스,가이드 들의 거대한 집합으로서 디자인시스템에 패턴라이브러리가 종속된 시스템의 일부라고 할 수 있겠습니다.

하지만 이런 학문적인 설명은 직관적이지 않을 뿐더러 "그래서 왜 쓰는건데?" 라는 의문을 해결해주지 않습니다. 우리는 왜 디자인 시스템을 알아야할까요?

그럼 잠시 조별과제를 하던 추억을 떠올려볼까요?

아무리 친하게 지냈던 동기,선후배여도 한번도 손발을 맞춰본적이 없던 사람들이라면 프로젝트를 진행하는 것부터 의사결정과 일의 분배와 모임일정의 조율 그리고 마지막으로 자료를 취합하는 것을 비롯해 전체적인 과정이 너무나 힘듭니다. 모두 다른 생각과 관점을 가진 사람들이 만나 누구하나 손해보는 일 없이 공정하고도 공평하게 일을 나누고 다들 동의할만한 시간과 일정을 잡는건...

실무에서도 마찬가지로. -내부 구성원들의 공감과 동의 -변경된 디자인 현황을 모르는 구성원 -공유,전달의 업무 로직이 미흡한 조직 -구체적이지 않고 모호한 디자인 원칙 -상충하는 개념이 동시에 포함된 디자인 원칙 등 구성원들 사이에 디자인 Protocol[약속-규칙]이 없다면.

간단한 디자인 수정에도 기존 디자인과 차이가 날 수 있습니다. 예를 들자면 RGB값/font-size/bold/opacity 등에서 말이죠. 간단한 수정과 새로운 컴포넌트 생성, 서비스 개설에 따라 미세한 오차가 누적되면. 나중에는 일반유저의 시각에서도 일관성을 찾아보기 어려워질 수 있습니다.

더군다나 유저의 니즈도 빠르게 변화하는 시대적 상황에서 서비스의 기능과 형태가 시장 요구에 맞추어 재빠르게 움직이지 못한다면. 시장 파이를 어느정도 차지하고 있는 기업이라도 도전자에게 자리를 내주게 될 것입니다. 한번 네카라쿠배 같은 큰 IT기업을 생각해봅시다. 이런 큰기업들은 보통 하나의 서비스만 보유하고 있지않고. 엄청나게 다양한 프로덕트를 가지고 있는 경우가 많습니다. 그리고 그 하나의 서비스는 웹과 안드로이드 그리고 IOS 등 구동 플랫폼 기반으로 또 나누어지고.

각각의 플랫폼에서 스마트폰화면과 태블릿화면 데스크탑 화면까지 고려해야하는 경우가 거의 항상 있을겁니다. 그리고 스마트폰과 테블릿, 모니터는 정말 다양한 규격을 가지고있죠. 이렇게 되면 정말 많은 디자이너와 디자인팀이 하나의 프로덕트를 만들기 위해 유기적으로 협업을 해야하는데. 이렇게 점점 IT 산업이 고도화됨에 따라. 디자인 조직도 점점 커져가게 되었고. 따라서, 더 효율적으로 디자인하는 방법인 디자인 시스템이 중요해진 것입니다.

자, 그럼 디자인 시스템이 왜 중요해졌는지 알았으니. 기업들이 사용하는 구체적인 이유에 대해서도 알아봅시다!

디자인시스템을 도입하게되면, 회사의 모든 구성원은 디자인 레퍼런스와 원칙 그리고 패턴 및 메인 색상 코드와 사용 예시, 디자인 소스들이 모여있는 하나의 온전한 "시스템"을 갖게 됩니다. 이를 통해 작업을 일관적이고[Consistency] 시간을 절약하고[Time Efficiency] 협업[Collaboration]생산성을 높이고 리스크를 최소화[RickLess]하고 업무속도[Progress]를 높일 수 있습니다.

1. 일관성의 장점

여러 서비스에서 혹은 다양한 페이지에서 사용자 경험을 통합하는 큰 도움이 됩니다. 디자인적은 일관성은 유저에게 브랜드인식을 높이고 기능적으로도 유저가 화면의 정보의 구조를 빠르게 파악하고 동작 방식에 대해서도 쉽게 학습하고 사용할 수 있게 합니다.

But

사용 편의성이 일관성보다 우선시 되야합니다. 서비스에서는 사용 편의성을 향상하기 위해 새로운 컨트롤 위치 또는 동작이 추가되야하는 경우가 있습니다. 휴대폰을 한 손으로 사용했다고해서 계속해서 휴대폰을 한손으로만 조작하는 일관성을 유지하게 된다면. 기능이 많고 복잡해질 경우 서비스를 사용하는데 큰 어려움과 불편이 생길 것 입니다. 일관성을 유지하는 것도 좋지만 기능이 많아질 경우 조작 간편성/ 사용 편의성을 더 높이는 것이 좋습니다. 요약하자면 - 유저의 조작법이 더 간편해지도록 유저인터페이스를[UI를] 일관성보다는 편의성 측면에서 직관적으로 추상화 합시다.

2. 시간절약의 장점

초기에 디자인 시스템을 구축하는데 시간과 인력자원이 많이 사용되는 것은 사실입니다. 하지만 새로운 프로젝트와 피드백마다 필요한 디자인 요소들을 매번 새로 그리며 반복적인 작업을 계속하게 되는 것은. 내부 인력을 낭비하는 것입니다. 디자인 시스템으로 미리 만들어 놓은 컴퍼넌트를 통해 빠르게 시안을 만들고, 시안과 시스템을 토대로 프로토타입을 만들게 되면 프로젝트 목표를 빨리 달성할 수 있을 것 입니다. 에셋화와 심볼화를 잘 사용한다면, 버튼 클릭 한번으로 수백수천장에 뿌려져있는 버튼의 디자인을 한번에 바꿀 수 있죠. 이렇듯 디자인 시스템을 잘 구축해둘 경우 많은 부분에서 시간을 절약할 수 있습니다.

3. 협업에서의 장점

디자인 시스템은 조직이 원할한 협업을 할 수 있게 도와주는데요. 디자인 시스템은 기존 구성원들의 의견과 공감을 토대로 세워진 명확한 원칙과 그에 대한 기술이 서술되어 있습니다. 그렇기 때문에 디자이너가 아닌 이해관계자를 설득시키는데 도움이되고. 새로운 구성원이 들어왔을 때 디자인 시스템을 보고 기존 팀원들의 디자인 방식이나 의사결정 방식, 공유방식등을 학습하여 팀에 빠르게 적응하고 회사가 디자인 역량을 보존하는데 큰 도움을 줄 수 있습니다.

4. 리스크 최소화의 장점

디자인시스템은 개발에 필요한 디자인적 요소를 명확하게 기재하고, 개발자에게 공유함으로서, 개발자가 새로운 컴포넌트를 추가할때 전체 디자인과 서비스 맥락을 이해하는데 도움을 줍니다. 그리고 만일 서비스의 업데이트와 유지보수를 위해 디자인시스템을 코드기반으로 구축한다면! 버튼의 디자인을 한번에 바꾸는 것 뿐만 아니라, 기기별, 디스플레이별 디자인 수정이 한번에 이루어지도록 로직을 짤 수도 있을 것 입니다. 그리고 이는 반복적인 디자인 작업을 최소화하죠.

5. Progress[진척,성장]의 장점인데요.

디자인에 대한 원칙과 가이드가 불필요한 의사결정 과정을 줄이고 효율적인 업무를 진행할 수 있게 도와줌으로서 프로젝트에서 더 중요하고 혁신적인 것들에 집중할 수 있게 도와줍니다. 반복적인 작업들을 줄임으로서, 서비스의 핵심적인 기능과 UX에 중요한 화면을 개선하거나 새로운 서비스에 대한 구상에 더 시간과 에너지를 집중할 수 있을겁니다. 그렇기에 프로세스가 빨라지고 서비스의 Progress[진척]가 있으며, 팀 내부의 역량에도 Progress[성장]가 있을 것 입니다.

디자인 시스템의 장점 5가지에 대해 살펴봣는데요. 디자인 시스템에는 장점만 있는 것이 아닙니다. 어느 순간 디자인 시스템이 너무 방대해지고 커져서 외우고 숙지해야할 것들이 너무 많아지는 경우. 뜻의 전달이 다르게 이루어 질 수 있고. 또 서로 상충하는 원칙들이 동시에 적혀져있을 수 있습니다. 서비스에서 가장 중요시 여겨야하는 유저의 경험과 기능들을 개선하기 보다는 디자인 시스템을 수정하고 디테일을 만드는데 시간을 더 쓰게 될 수도 있다는 말이죠. 그렇기 떄문에 디자인 시스템을 처음부터 너무 완벽하게 만들려고 하기보다는. 현재 회사 혹은 프로젝트 팀의 환경과 자원 구성원의 배경 등에 맞추어 필요한 최소한의 디자인 원칙과 시스템을 구축하고 서비스 성장방향에 맞추어 계속하여 업데이트 하는것이. 중요하다고 할 수 있겠습니다.

RE:CAP

Design System = "방대한 디자인 데이터 라이브러리"

디자인 시스템의 5가지 장점으로는

1. 일관성
2. 시간절약
3. 협업
4. 리스크 최소화
5. Progress

다음번 글 Part2에서는 디자인 시스템의 3가지 핵심 요소와 구체적인 내용에 대해 알아 보겠습니다.

waitlist에서 1주일간 기다린 끝에 드디어! 먼저 시작하기 전에 디스코드 서버에 들어가면 인증 절차를 돕는 공지가 나온다. 처음에 waitlist에 올려두었던 메일로 로그인하고. 그다음 원하는 그림에 대한 텍스트를 입력할 때 뒤에 디스코드에서 받은 3자리의 인증번호를 다음과 같이 입력해준다.

그후 DALL-E 2가 생성해준 이미지들 중 하나를 퍼블리쉬하고

copy URL키를 눌러 URL을 복사한 후 디스코드에 돌아와 Complete verification을 마치면된다.

그럼 이제 한번 재밌는 그림을 생성해보자.

투명한 헬멧과 우주복을 입고서 달에 도착한 아인슈타인을 만들어달라고 부탁한 결과 오오오! 생각보다 너무 잘 만들어진다. 그렇다면 최후의만찬의 패러디는? 아쉽게도 예상했던 스타일은 아니였다. 그다음 온갖 난잡해보이는 문장들을 입력해보아도 어떻게해서든지 그림을 찍어내는 DALL-E

오, 그렇다면 일론머스크가 화성에서 로버를 운전하는 사진도 그려줄 수 있겠지? 라는 생각을 했는데. 아래 그림에서 배경만 화성처럼 바꿔줬으면 하는 마음도 있었다.

그렇지만 자꾸만 term of use에 맞지않는 입력이라는 경고창이 뜨더니. 들어가서 노닥거린지 15분만에 계정을 정지먹었다.

아니 이게 뭐야.. 내 계정 돌려줘요 이용약관도 제대로 보지 않고 이용한 나의 잘못이 크긴했다. 실존인물에 관련한 이미지는 생성할 수 없고 입력해서도 안된다는 것. 물론 당연히 폭력적이거나 선정적이거나 인종차별적인 기타 부도덕한 이미지를 생성하는 것도 안된다.

아... 그래도 아인슈타인 이미지는 문제없이 나오길래 이용약관에 위배되는 내용이라는 생각을 못했다. 일론머스크는 안되고 아인슈타인과 닐슨 보어는 가능한.

어찌되었든 나의 잘못이긴하지만 그래도 계정 비활성화를 풀고싶어 메일로 싹싹빌었는데 효과가 있을지는 모르겠다. -과학적 유명인사에 대한 키워드 사용이 금지되어 있지 않아 일론머스크도 허용이 되는줄 착각했기에 정책을 위반했습니다.한번만 살려주십쇼..! - 이렇게 메일을 보낸 상황이다.