4년만의 회고 - Goodbye, My Twenties

Google 광고에 대해 알아보자 - Google Ad Manager

# 커뮤니티의 역할에 대한 단상

최근에 [백엔드가 이정도는 해줘야 함](https://velog.io/@city7310/%EB%B0%B1%EC%97%94%EB%93%9C%EA%B0%80-%EC%9D%B4%EC%A0%95%EB%8F%84%EB%8A%94-%ED%95%B4%EC%A4%98%EC%95%BC-%ED%95%A8-1.-%EC%BB%A8%ED%85%90%EC%B8%A0%EC%9D%98-%EB%8F%99%EA%B8%B0%EC%99%80-%EA%B0%9C%EC%9A%94)이라는 글 시리즈를 재밌게 보고있다. 이 시리즈를 쓰는 동기에 대해서 설명하는 아래 문장이 인상깊어서 계속 읽고 있다.

> "백엔드를 조금 경험해본 사람이라면 사용자를 어떻게 인증할지, 암호화는 어떻게 할지, API 문서는 어떻게 작성해야할 지 같은 걸 비교적 쉽게 의사결정할 수 있지만, 그렇지 않은 사람은 이런 게 필요하다는 것조차 깨달을 수 있는 경로가 별로 없다."

여기서 깨달을 수 있는 경로가 별로 없다는 점이 내게 중요하게 다가왔다. 나는 백엔드 엔지니어가 아니라서 그것이 여러 관점에서 어떤 의미가 될 수 있을지 오롯이 느낄 수는 없지만 프런트엔드 영역도 비슷한 구석이 있다고 느꼈다.

최근의 웹앱은 뷰와 데이터를 나누고, 상태와 비동기코드를 나눠 관리하고, 그 상태마저 mutable 또는 immutable로 관리할지 선택하고, 앱을 구성하는 코드 전체 또는 일부를 번들링하고, 또 라우팅 경로를 기반으로 스플리팅하고, CSS마저 CSS-in-JS로 다룰 것인지 선택한다. 이 이상 나열하자면 너무 길다. 이중 어떤 것은 강력한 필요에 의해 쓰이는 것도 있지만 단순한 편의성이나 취향에 의해 쓰이는 것도 있다. 그런데 이 모든 것은 선택적이다. 이중 어떤 것도 사용하지 않고 기본 요소만으로 그럭저럭 돌아가는 웹을 만들 수 있다. 그러나 날것으로만 웹을 만드는 것보다는 점점 많은 회사들이 위에서 말한 것들의 일부 혹은 대부분을 채택하는 경향이 있다보니 이것들을 이해하고 사용할 줄 아는 엔지니어를 선호하는 것 같다. 그런데 프런트엔드에 진입한 초심자와 주니어 입장에서는 이것들을 공부하고 간단한 앱을 만들어볼 수는 있지만 그 이상으로 필요성을 느끼고 딥다이브를 하기는 상당히 힘들다. 필요성이 피부로 느껴질 만큼 공부 목적으로 만드는 앱과 그 코드의 규모가 커지지 않기 때문이다. 즉, 위의 인용문장처럼 프런트엔드에서도 이런 기술들이 어떤 배경에서 탄생했고 왜 필요한지, 어떻게 쓰면 좋을지에 대해 깨달을 수 있는 경로가 그리 많지 않다. 물론 백엔드와는 온도가 다르긴 하나 엔지니어로서 필요한 어떤 기술이나 습관을 필요성을 느껴 깨닫고 배양해나갈 수 있는 경로가 부족하다는 점에서는 공통점을 갖는다.

이것과 관련하여 근 몇개월간 계속 머릿속에 맴도는 생각이 있는데 단순히 도식화하면 다음과 같다.

> 회사는 기본을 잘 갖춘 엔지니어를 원한다. 원리를 궁금해하는 태도와 문서화의 중요성을 이해하고 있고 소프트 스킬을 갖추고 있으면 보너스다(이걸 보너스로 볼지 말지에 대해서는 회사마다 다른듯 하나 회사와 팀에 적응하는데 드는 코스트가 때론 급격히 적어진다는 점에서 대부분 선호하는듯 하다).</br></br>-> 이걸 이해하고 있는 교육에 관심있는 누군가가 이것을 잘 이해 & 습득시킬 수 있는 <교육 기관, 교육 회사, 교육 서비스, 교육 컨텐츠> 등을 만든다(교육 관련 기관, 회사, 서비스 각각의 예가 바로 떠오를 정도로 요새 굉장히 핫이슈인듯 하다).</br></br>-> 그러나 이런 기본이나 소프트스킬에 대해 역설하는 <회사, 서비스, 컨텐츠>의 마케팅 효과는 초심자에게 이것이 캐치워드가 아닌지 미비한 수준인듯 하다.</br></br>-> 이런 교육 서비스를 만드는 기관이나 회사 입장에서는 매출이 잘 일어나지 않으니 캐치워드를 찾아나서게 되고, 프런트엔드에서는 많은 경우의 그 대상은 프런트엔드 포지션의 Job Description에서 가장 많이 발견되는 SPA 삼대장이 된다. 이외에도 대상은 더 있고 "x주 완성", "x주 만에 만드는 ~" 과 같은 마케팅으로 이어진다.

절대 일반화할 수 없지만 이런 싸이클이 실제로 있지 않은가라는 생각이 들었고, 이 교육 과정을 끝냈을때 이해를 잘 하고 기본기도 잘 닦은 경우도 있지만 아닌 경우가 좀 더 많은듯 하다(훨씬일 수도 있다). 결과에 관계없이 양극단에 있는 두 경우와 그 사이에 있는 모든 경우에서 어쨌거나 윗단락에서 말한 경로를 접할 기회는 여전히 많지 않다. 왜냐하면 이미 catchy한 워딩으로 프레이징 되어있는 만큼 그 커리큘럼도 이에 영향을 받을 수 밖에 없고, 위의 예에서는 SPA를 필두로 이외의 기본 기술을 습득했다고 하더라도 SPA는 프런트엔드 기술 영역을 이루는 일부에 불과하기 때문에 무엇이 가장 기본적이고 중요한지에 대한 깨달음을 얻을 수 있는 경로는 여전히 흐릿할 수 밖에 없기 때문이다.

이런 이유에서 인지 커뮤니티를 운영하고 이벤트를 만들면서 이런 부분을 많이 신경쓰게 된다. 기술과 지식에 대해 이야기를 나누는 이벤트를 만들 수 있고, 서비스를 만드는 여러 직군의 사람들을 모아 네트워킹을 하는 이벤트를 만들 수 있고, 간단한 기술 세션이나 해커톤 이벤트를 만들 수도 있다. 이 모든 이벤트가 의미있고 재미있고 또 중요하다. 그런데 위에서 말한 부족한 경로에 대해 알려주고 도움을 줄 수 있는 이벤트는 턱없이 부족하다고 느낀다. 물론 저런 필요성을 느끼고 기술을 익히고 엔지니어로서 성장하는 것은 어디까지나 개인의 몫이다. 이것은 변함없는 사실이지만 개인적으로 프런트엔드를 처음 접하고 2년 정도가 흐른 지금까지 오는 과정([지난 3년의 기록: 대기업에서 스타트업으로](/posts/move-to-startup)와 [되돌아보는 2017년](/posts/2017-retrospective)에 정리했었다)이 많이 고통스러웠고 많은 운이 작용했다. 이것이 비단 나만의 일은 아닐 것이라 생각한다. 정말 필요성을 깨닫고 성장하는 것은 개인의 몫이라는 점은 몇번을 말해도 과언이 아니라고 생각은 하지만, 그리고 여전히 그렇게 믿지만, 내가 프런트엔드 엔지니어로서 일과 공부를 하면서 정말 힘들었을때 가끔 '아 누가 조금이라도 가이드해주면 좋으련만.. ' 이라고 읊조렸던 것을 상기해보면, 그리고 누군가는 아주 작은 배움의 기회마저 상실한채 모든 의욕을 잃고 이 길을 포기했고, 포기하려 고민한다는 것을 마음속에서 되뇌어 본다면 이 사회에는 여전히 길라잡이가 필요하고 누군가는 그 역할을 어떤 방식으로든 계속 해나가야 하지 않을까 한다. 지금까지는 아주 효과적인 길라잡이가 없었고 부족했을 뿐이다.

그래서 요새는 기술 커뮤니티나 이벤트가 이 점을 어떻게 해소할 수 있을지 많이 생각하고 있다. 단순히 엔지니어를 위해서라기 보다는 본질적으로 사람을 위한 것이라는 점에서 다분히 인본주의적인 생각을 하고있다.


커뮤니티의 역할에 대한 단상

지난 3년의 기록: 대기업에서 스타트업으로

오픈소스에 한걸음 더: 2018 오픈소스 개발자 이야기를 다녀와서

# [webpack v4] Development 환경 구성하기

[지난 Output Management 편](/posts/webpack-v4-output-management)에서는 다수의 js 파일을 entry point를 사용해 하나의 bundle 파일로 만들어보았다. 이번 포스팅에서는 프로젝트를 개발할때 쓰는 개발 환경을 구성해보도록 하자.

> 이 포스트에 관련된 코드는</br></br>https://github.com/brightparagon/webpack-conquer/tree/development</br></br>에서 확인해볼 수 있습니다.

이 글은 다음과 같은 내용을 다룰 것이다.

1. webpack-dev-server
2. Dev server options: proxy, historyApiFallback, stats...
3. Source map

왜 이런 옵션들을 이용해서 개발 환경을 구성할까? 우선 webpack을 사용하는 환경이라면 대부분 [ 코드를 작성하고, babel 등을 이용해 트랜스파일하고, 결과물을 브라우저로 확인하는 ] 일련의 반복적이고 구조적인 과정이 잡혀있을 것이다. 간단한 웹을 만드는 경우에도 코드 수정 - 저장 - 브라우저 확인이라는 세가지 단계를 거치게 마련이다. 그런데 코드를 수정하고 결과물을 확인하는 일은 한두번으로 끝나지 않는다는 문제가 있다. 매번 이 작업을 수동으로 한다면 아주 귀찮은 일일 것이다.

webpack으로 이 과정을 자동화해주면 ctrl + s를 누르는 순간 변경 사항이 반영된 결과물을 브라우저에서 확인할 수 있다. 꽤나 큰 수고를 덜어줄 수 있어서 아주 편리한 기능이다.

## webpack-dev-server

위에서 언급한 작업을 해주는 webpack의 도구에는 아래와 같이 크게 세가지가 있다.

1. 기본적인 webpack cli + watch mode
2. webpack-dev-server
3. webpack-dev-middleware

이런 옵션들이 나뉘어있는 것은 다양한 환경에서 webpack으로 개발 환경을 구성할 수 있게 하기 위함이다. 1번은 단순히 모든 파일들을 감시하고 있다가 변경사항이 있을 경우 webpack config에 따라 리컴파일 한다. 다만, 변경 사항을 확인하기 위해서는 매번 브라우저를 새로고침 해줘야 한다. 2번은 express로 만들어진 간단한 web server이다. 이 옵션도 1번과 같이 변경 사항을 감지해 리컴파일을 한다. 그런데 1번과는 달리 브라우저를 리로드하고 더 다양한 configurable option들을 사용할 수 있다. proxy나 historyApiFallback 같은 것들이 이 옵션에 속한다. 3번은 2번에서 내부적으로 사용되는 subset인데 코드 변경시 webpack config 파일에 따라 컴파일한 코드를 내뱉는 역할만을 middleware로 패키징한 모듈이라고 이해하면 된다. 그래서 자체적으로 express server를 사용한다면 이 3번을 사용해 입맛에 맞게 서버와 함께 커스터마이즈 할 수 있다.

세 도구 모두 많이 쓰이지만 사이드 프로젝트를 셋업하는 등의 용도로서는 2번이 가장 많이 쓰인다는 경험하에 이 글에서는 webpack-dev-server를 다뤄보도록 하겠다.

먼저 npm install --dev webpack-dev-server 혹은 yarn add webpack-dev-server --dev를 터미널에 입력해 설치해보자. 그리고 저번 글에서 작성했던 webpack.config.js 파일을 아래와 같이 수정해 webpack-dev-server를 위한 설정을 추가해보자. 27 라인에 devServer라는 옵션이 추가되었다.

```javascript
const path = require('path');
const HtmlWebpackPlugin = require('html-webpack-plugin');
const CleanWebpackPlugin = require('clean-webpack-plugin');

module.exports = {
  mode: 'development',

  entry: {
    app: path.resolve(__dirname, 'src', 'app.js'),
    bar: path.resolve(__dirname, 'src', 'bar.js'),
  },
  
  output: {
    path: path.resolve(__dirname, 'build'),
    filename: '[name].bundle.js',
  },

  plugins: [
    new CleanWebpackPlugin(['build']),
    new HtmlWebpackPlugin({
      title: 'CONQUER WEBPACK V4!',
      inject: true,
      template: path.resolve(__dirname, 'index.html'),
    }),
  ],

  devServer: {
    port: 8000,
    inline: true,
  },
};
```
webpack.config.js

devServer 옵션에서 포트를 8000으로 주었고 inline 모드로 설정했다. 포트가 8000이기 때문에 브라우저에서 localhost:8000으로 접근할 수 있다. devServer를 사용할때 컴파일된 코드를 일반적인 template html에 삽입하는 inline 모드와 iframe에 넣어 업데이트하는 iframe 모드가 있는데 HMR이 inline 모드에서 지원이 되므로 여기서는 inline 모드를 사용하도록 하겠다.

이제 이 설정을 이용해 서버를 실행하기 위한 스크립트를 package.json 파일에 작성해서 개발을 할때마다 이 스크립트로 프로젝트를 실행할 수 있도록 해보자. 8 라인에 "start" key가 추가되었다.

```json
{
  "name": "webpack-conquer",
  "version": "1.0.0",
  "main": "index.js",
  "author": "brightparagon",
  "license": "MIT",
  "scripts": {
    "build": "webpack",
    "start": "webpack-dev-server --config webpack.config.js"
  },
  "dependencies": {
    "clean-webpack-plugin": "^0.1.19",
    "html-webpack-plugin": "^3.2.0",
    "webpack": "^4.7.0"
  },
  "devDependencies": {
    "webpack-cli": "^2.1.2",
    "webpack-dev-server": "^3.1.4"
  }
}
```
package.json

webpack과 webpack-dev-server 두가지 도구 모두 --config 옵션을 주지 않으면 기본적으로 webpack.config.js 파일을 찾아서 사용하기 때문에 위 파일에서 "--config webpack.config.js"는 생략가능하다. 만약 config 파일명을 달리한다면 해당 부분을 변경해서 사용하면 되며 이후에 Production(운영 환경)을 위한 설정을 할때도 --config 옵션을 요긴하게 사용할 것이다.

이제 터미널에 **npm start** 또는 **yarn start**를 입력해 프로젝트를 실행해보자.

![webpack development](/images/webpack-dev.png)

위와 같이 나올 것이고 버튼도 잘 작동할 것이다. 그리고 app.js 파일을 열어 Hello 문구를 Hello Development로 수정한 뒤 저장하고 브라우저를 확인해보자.

![webpack development](/images/webpack-dev2.png)

위와 같이 자동으로 변경 사항이 반영되어 있고 full refresh까지 된 것을 확인할 수 있다. port와 inline 이외에도 devServer에 줄 수 있는 다양한 옵션이 있는데 대표적으로 아래와 같은 것들이 있다.

- proxy: 프로젝트 내에서 호출하는 외부 API나 다른 포트를 사용하는 로컬 서버 API가 있을 경우 이 API url들은 해당 서버로 호출하도록 우회할 수 있도록 만드는 옵션
- compress: gzip compression을 사용하는 옵션
- overlay: 에러가 발생했을때 브라우저에 풀스크린으로 에러 내용을 오버레이로 표시해주는 옵션
- hot: HotModuleReplacementPlugin을 사용해 HMR 기능을 이용하는 옵션
- historyApiFallback: HTML5의 History API를 사용하는 경우에 설정해놓은 url 이외의 url 경로로 접근했을때 404 responses를 받게 되는데 이때도 index.html을 서빙할지 결정하는 옵션이다. - React와 react-router-dom을 사용해 프로젝트를 만들때도 react-router-dom이 내부적으로 HTML5 History API를 사용하므로 미지정 경로로 이동했을때, 있는 경로지만 그 상태에서 refresh를 했을때와 같은 경우에도 애플리케이션이 적절히 서빙될 수 있어서 유용한 옵션이다.
- host: 기본적으로 애플리케이션은 localhost에서 서빙되지만 이 옵션을 이용해 다른 host를 지정해줄 수 있다. 또한 이 옵션에 '0.0.0.0'을 주면 개발중인 localhost를 외부에서 접근할 수 있다.

devServer에 사용할 수 있는 다양한 옵션에 대해 자세한 내용은 [이 링크](https://webpack.js.org/configuration/dev-server/)에서 확인하면 된다.

Source map으로 넘어가기 전에 위의 옵션들 중 몇가지를 사용해보자.

### overlay

```javascript
devServer: {
  port: 8000,
  inline: true,
  overlay: true,
},
```
webpack.config.js

위와 같이 devServer에 overlay 옵션을 true로 주고 app.js 파일에 일부러 잘못된 코드를 작성하자.

```javascript
function app() {
  const div = document.createElement('div');
  const btn = document.createElement('button');

  div.innerHTML = 'Hello';
  btn.innerHTML = 'Click me and check the console!';
  btn.onclick = bar;
  div.appendChild(bt

  return div;
}

document.body.appendChild(app());
```
app.js

8번 라인이 바뀌었다. appendChild 함수 실행부가 온전히 닫혀있지 않고 btn 변수명도 치다 말았다. 이렇게 변경하고 저장하면 브라우저에서 아래와 같은 화면이 나타날 것이다.

![webpack development](/images/webpack-dev3.png)

./src/app.js 에서 에러가 났고 문제가 되는 코드의 부분을 친절하게 알려준다. 이 옵션을 사용하지 않아도 개발자 도구 콘솔에서 알려주므로 꼭 사용하지 않아도 된다. 다만 에러가 났을때 확실하게 알려주는 것 같아서 필자는 꼭 쓰는 옵션이다.

### historyApiFallback

다시 app.js 파일을 원래대로 돌리고 브라우저 url 주소를 보자. localhost:8000 일 것이다. 아직 우리의 애플리케이션은 루트 경로 이외의 url에 해당하는 페이지를 만들지 않았다. localhost:8000/mypage 를 직접 입력해 접속해보자. 아래와 같은 화면이 나타날 것이다.

![webpack development](/images/webpack-dev4.png)

이 url로 접속하는 순간 webpack-dev-server(express server)는 mypage라는 라우팅 경로가 있는지 확인할 것이다. 그런데 아무런 라우팅 설정을 하지 않았기 때문에 Cannot GET 에러를 낸다. 애플리케이션은 에러가 난 상태로 가만히 있게 되는데 개발 중간에 이렇게 멈춰있으면 url을 다시 입력해 이동해야 하는 번거로움이 생긴다. 이때 아래와 같이 historyApiFallback 옵션을 사용하면 이런 번거로움을 피할 수 있다.

```javascript
devServer: {
  host: '0.0.0.0',
  port: 8000,
  overlay: true,
  historyApiFallback: true,
  // or
  historyApiFallback: {
    rewrites: [
      { from: /^\/$/, to: '/views/landing.html' },
      { from: /^\/subpage/, to: '/views/subpage.html' },
      { from: /./, to: '/views/404.html' },
    ],
  },
},
```
webpack.config.js

true를 주게되면 모든 404 responses에 대해 index.html로 리다이렉트를 하고 rewrites 옵션을 담은 객체를 주면 정규식을 이용해 더 복잡한 경우를 다룰 수 있다.

이제 아까와 같이 localhost:8000/mypage 경로에 다시 접속해보자. 곧장 접속해도, 이 경로에서 새로고침을 해도 애플리케이션이 서빙되는 것을 확인할 수 있다.

### host

웹 애플리케이션을 개발하다 보면 다양한 태블릿이나 모바일 기기로 화면 및 기능 동작을 확인하거나, 결제 모듈을 테스트하거나, 근처에 있는 팀원이 봐야하는 경우가 종종 생긴다. 이럴때 host 옵션을 사용하면 유용하다. 아래와 같이 설정해보자.

```javascript
devServer: {
  host: '0.0.0.0',
  port: 8000,
  overlay: true,
  historyApiFallback: true,
  host: '0.0.0.0'
},
```
webpack.config.js

이렇게 config 파일을 수정하면 앱을 재실행해주자. 그리고 맥이라면 터미널을 열어 **ifconfig | grep inet**을 입력해 현재 IP주소를 확인하자. 이제 태블릿이나 모바일 기기로 개발 중인 컴퓨터와 같은 와이파이에 접속한 다음 브라우저에서 방금 확인한 IP주소의 8000번 포트로 접속해보자. 예를 들어, 10.23.2.2:8000 과 같은 주소로 접속하면 된다. 필자는 모바일에서 접속했는데 아래와 같이 나온다.

![webpack development](/images/webpack-dev5.jpg)

이제 app.js 파일을 열어 div의 text를 이리저리 바꿔보면서 저장해보고 모바일 화면을 지켜보자. 아래와 같이 저장할 때마다 자동으로 업데이트 되는 것을 확인할 수 있다.

![webpack development](/images/webpack-dev6.gif)

정말 편하다! 이제 Source map을 알아볼 차례다.

## Source map

개발을 진행하다보면 점점 js 파일이 늘어나게 되는데 webpack은 여러 파일들을 하나 또는 특정 갯수의 bundled 파일로 묶다보니 error와 warning 메시지를 통해 어느 파일의 어느 코드에서 문제가 되는지 정확히 추적하기가 어려워진다. 이럴때 Source map을 사용하면 원본 파일을 통해 코드를 보여주고 error 및 warning 메세지도 정확한 파일명과 코드 위치를 짚어주기 때문에 유용하다.

bar.js 파일에서 아래와 같이 일부러 버그를 심어놓자.

```javascript
function bar() {
  cosnole.log("I'm a bar!");
}

export default bar;
```
bar.js

console을 cosnole라고 바꿨다. webpack v4 공식 다큐먼트에서 에러를 이렇게 심었다 ㅎㅎ. 그리고 앱을 재시작하고 버튼을 클릭해보자. 그리고 개발자 도구의 콘솔을 열어보자.

![webpack development](/images/webpack-dev7.png)

버튼을 누르면 이렇게 cosnole이 선언되어 있지 않다는 레퍼런스 에러를 뿜을 것이다. 그리고 이 에러 옆에 에러가 난 파일명과 몇번 라인인지 표시가 되어있다. 파일명을 클릭해보자.

![webpack development](/images/webpack-dev8.png)

webpack이 실컷 빌드한 코드로 연결하고 있음을 알 수 있다. webpack_require... 같은 코드가 보인다. 아직은 코드가 간단해서 볼만(?) 하지만 거대해지면 더욱 보기가 어려울 것이다. 이 에러를 보다 더 눈이 덜 아프고 깨끗하게 추적할 수 있도록 webpack config 파일을 아래와 같이 수정해보자.

```javascript
const path = require('path');
const HtmlWebpackPlugin = require('html-webpack-plugin');
const CleanWebpackPlugin = require('clean-webpack-plugin');

module.exports = {
  mode: 'development',

  devtool: 'inline-source-map',

  entry: {
    app: path.resolve(__dirname, 'src', 'app.js'),
    bar: path.resolve(__dirname, 'src', 'bar.js')
  },

  ...
};
```
webpack.config.js

4번 라인에 devtool 옵션이 추가되었고 'inline-source-map' 이라는 값을 주었다. 저장하고 앱 재실행 뒤 다시 버튼을 클릭해보자. 이번엔 아래처럼 조금 다르게 표시될 것이다.

![webpack development](/images/webpack-dev9.png)

벌써 여기부터 조금 깔끔해졌다. 파일명에 군더더기도 없고 정확한 코드 라인을 표기하고 있다. 파일명을 클릭해보자.

![webpack development](/images/webpack-dev10.png)

전과는 달리 정확히 원본 파일을 보여주면서 에러가 난 라인도 잘 나타내고 있다. 이렇게 유용한 옵션이긴 하지만 webpack은 이를 위해 내부적으로 빌드된 파일과 원본 파일간의 관계를 나타내는 매핑 파일을 따로 만든다. 이걸 매 빌드마다 새로 만들어내므로 프로젝트가 거대해지면 한번 저장하고 변경 사항이 반영되기까지 상당한 시간이 걸린다. 필자가 만드는 리액트 프로젝트의 경우 총 11,000 라인 정도의 코드로 이루어져있는데 반영까지 체감상 3~4초 정도 걸리는 것 같다. 어찌보면 양날의 검일 수도 있어서 개발자들에 따라 이 옵션을 사용하지 않고 본능(?)으로 어느 부분이 잘못되었는지 추측하려 노력하는 경우도 있고(이 방법이 생각을 많이 하게 해서 좀 더 논리적인 사고를 하게 만드는 것 같다. 처음엔 무지 힘들긴 하지만..) 빠른 빌드를 위해 아예 사용하지 않거나 'inline-source-map' 이외의 다른 옵션을 사용하기도 한다. 개발과 운영 모드에서 사용할 수 있는 옵션이 서로 다르고 개발과 운영 각각에서도 옵션이 다양하게 존재하는데 이에 대해서는 [이 링크](https://webpack.js.org/configuration/devtool/)에서 확인하면 된다. webpack 공식 문서에서는 개발 모드에서는 'eval-source-map' 또는 'cheap-eval-source-map'를, 운영 모드에서는 none(아예 사용하지 않음) 또는 'hidden-source-map' 정도를 권장하고 있다. 필자의 프로젝트에서는 아직 크기가 아주 크지는 않기 때문에 개발 모드에서는 'source-map'을, 운영 모드에서는 'hidden-source-map'을 사용하고 있다.

> 이 포스트에 관련된 코드는</br></br>https://github.com/brightparagon/webpack-conquer/tree/development</br></br>에서 확인해볼 수 있습니다.

Reference
- https://webpack.js.org/guides/development/
- https://webpack.js.org/configuration/dev-server
- https://github.com/webpack/docs/wiki/webpack-dev-server


[webpack v4] Development 환경 구성하기

# [webpack v4] Output Management

[저번 Asset Management 편](/posts/webpack-v4-asset-management)에서 index.html에 번들된 app.js와 bar.js를 불러와 사용했었다. 이번에도 비슷하게 시작해보자. 단, 이번에는 두개의 entry point로 만들어보자.

```javascript
const path = require('path');

module.exports = {
  mode: 'development',

  entry: {
    app: path.resolve(__dirname, 'src', 'app.js'),
    bar: path.resolve(__dirname, 'src', 'bar.js'),
  },
  
  output: {
    path: path.resolve(__dirname, 'build'),
    filename: '[name].bundle.js',
  },
};
```
webpack.config.js

이렇게 복수의 entry point를 명시하면 webpack은 각 entry point마다 완전히 독립적인 dependency graph를 만든다. 흠.. 이걸 왜 하는걸까? 이후에 다른 글(CommonsChunkPlugin 관련)에서 더 설명하겠지만 이렇게 여러 entry point를 만들면 CommonsChunkPlugin를 이용해 앱을 원하는 청크들로 분리할 수 있다. 이렇게 분리하면 처음 웹앱을 접근할때 모든 js 파일들을 한꺼번에 불러오지 않고 dependency graph에 따라 그때그때(예를 들어 route 경로 변경) 필요한 js 파일을 불러오게 된다. 결론적으로 첫 랜딩 시간을 줄일 수 있다. real-world use case에서는 웹앱의 entry인 app과 앱에서 사용하는 third-party library들을 vendor라는 entry point로 묶는 방법을 많이 사용한다. 당연히 vendor가 각종 library들의 집합이므로 무거우니 이를 필요한 시기에 불러오면 효율적일 것이다.

webpack.config.js 파일을 위와 같이 만들고 yarn build 혹은 npm run build로 빌드를 해보면 두개의 번들 파일이 생긴다. 이외에도 entry point는 배열을 받을 수도 있는데 배열을 쓰게 되면 js 파일들이 여러개로 나뉘어 있을때 간단하게 하나의 entry point로 묶을 수 있다. entry point 전략에 대해 공식적인 설명이 궁금하면 이 글을 참고하자.

자, 이것이 우리의 실제 프로젝트라고 생각해보면 아래와 같은 일들이 생길 수 있다.

- app.js의 파일명이 바뀐다
- apple.js라는 새로운 js 파일이 생긴다
- bar.js 파일이 삭제된다

이런 일들이 일어났을때 index.html의 script tag는 변경 사항을 반영해야만 의도된 결과를 얻는다. 거기다 output filename 설정에 hash라도 해놓으면 파일이 변경되면 매 build 마다 이름이 변경되어 index.html에 매번 반영해주기가 귀찮게 된다. webpack이 알아서 똑똑하게 현재 쓰이는/안쓰이는 파일을 구분해줬으면 좋겠지만 그러지 못하는게 아쉽다.

## html-webpack-plugin comes to the rescue!

다행히 webpack 초창기부터 html-webpack-plugin이라는 플러그인이 생겼는데 이 문제를 해결해준다. yarn add html-webpack-plugin 혹은 npm install html-webpack-plugin --dev로 설치하고 webpack.config.js를 아래와 같이 수정해보자.

```javascript
const path = require('path');
const HtmlWebpackPlugin = require('html-webpack-plugin');

module.exports = {
  mode: 'development',

  entry: {
    app: path.resolve(__dirname, 'src', 'app.js'),
    bar: path.resolve(__dirname, 'src', 'bar.js'),
  },
  
  output: {
    path: path.resolve(__dirname, 'build'),
    filename: '[name].bundle.js',
  },

  plugins: [
    new HtmlWebpackPlugin({
      title: 'CONQUER WEBPACK V4!',
      inject: true,
      template: path.resolve(__dirname, 'index.html'),
    }),
  ],
};
```
webpack.config.js

설치한 html-webpack-plugin를 불러오고 plugins 옵션에서 위와 같이 사용하고 있다. 이 플러그인은 Default로 아주 간단한 index.html을 사용해 자동으로 번들 결과를 script tag에 반영해주므로 더이상 index.html 파일을 따로 갖고 있지 않아도 된다.

html-webpack-plugin 옵션으로 title, inject, template 옵션을 사용하고 있는데 만약 우리가 우리만의 index.html을 사용하고 싶다면 template 옵션에 우리가 관리할 index.html 파일의 경로를 명시해주면 된다. 예를 들어, head tag에 cdn으로 style이나 폰트를 불러와 사용하고 번들 파일만 webpack이 자동으로 넣어주는 방식으로 사용할 수 있다. 그리고 inject 옵션을 true로 주었는데 Default로 true가 잡힌다. 이 옵션이 true 혹은 'body'일 경우엔 플러그인이 body tag에 script tag를 삽입해주고 'head'일 경우엔 head tag에 삽입한다. 자세한 것은 [공식 문서](https://github.com/jantimon/html-webpack-plugin)에서 확인해보자.

## clean-webpack-plugin

뭔가 편해진 것 같은데 아직 한가지 문제가 더 있다. 우리는 앞으로 build를 계속할텐데 번들 파일들이 build 폴더에 계속 쌓이고 있다. 이름이 같으면 덮어씌워지지만 다르면 계속 파일이 늘어난다. 이미 번들된 파일의 기존 파일이 지워졌을 수도 있고 파일명이 변경되어 새 번들 파일이 생겼을 수도 있다. 이 문제는 clean-webpack-plugin으로 간단하게 해결할 수 있다.

yarn add clean-webpack-plugin 혹은 npm install clean-webpack-plugin --dev로 설치하고 webpack.config.js 파일을 아래와 같이 수정하자.

```javascript
const path = require('path');
const HtmlWebpackPlugin = require('html-webpack-plugin');
const CleanWebpackPlugin = require('clean-webpack-plugin');

module.exports = {
  mode: 'development',

  entry: {
    app: path.resolve(__dirname, 'src', 'app.js'),
    bar: path.resolve(__dirname, 'src', 'bar.js'),
  },
  
  output: {
    path: path.resolve(__dirname, 'build'),
    filename: '[name].bundle.js',
  },

  plugins: [
    new CleanWebpackPlugin(['build']),
    new HtmlWebpackPlugin({
      title: 'CONQUER WEBPACK V4!',
      inject: true,
      template: path.resolve(__dirname, 'index.html'),
    }),
  ],
};
```
webpack.config.js

지금껏 번들된 파일들은 build 폴더에 넣고 있었다. clean-webpack-plugin을 불러와 plugins 옵션에서 위와 같이 설정해주면 build 폴더를 매 build 마다 clean-webpack-plugin이 build 폴더를 먼저 비우고 html-webpack-plugin이 그 다음 index.html template에 번들 결과를 삽입하고 build 폴더에 결과물을 저장한다. 이제 build 사이클을 어느 정도 완성했다. 더이상 build 폴더를 직접 관리해주어야 하는 일이 사라지게 되었다.

> 이 포스트에 관련된 코드는</br></br>https://github.com/brightparagon/webpack-conquer/tree/output-management</br></br>에서 확인해볼 수 있습니다.


[webpack v4] Output Management

# [webpack v4] Asset Management

## 들어가며

[저번 글](/posts/webpack-v4-start)에서는 간단한 js 파일 하나를 번들링해서 index.html 파일에서 사용하도록 만들었다. 그런데 우리가 웹 애플리케이션을 만들때 JavaScript 파일만 쓰지는 않지 않은가? 스타일링을 위해 CSS 파일을 만들고, 사진을 보여주기 위해 jpg, png 등의 이미지 파일을 추가하고, 때로는 글씨체를 위해 font 파일이나 json 파일을 사용하기도 한다. 이때 사용되는 모든 종류의 파일들은 CDN과 같은 외부링크로 불러들이지 않는 이상 우리 프로젝트 디렉토리 내에 존재한다. 물론 webpack은 js 이외의 파일들도 번들링 해준다. 이 파일들을 각각 하나의 JavaScript 모듈로 만들어 js 파일과 마찬가지로 dependency graph로 관리한다. 이번 글에서는 이런 asset을 webpack으로 어떻게 관리하는지 알아보자.

## CSS를 사용하는 웹을 만들어보자

> 이 포스트에 관련된 코드는</br></br>https://github.com/brightparagon/webpack-conquer/tree/asset-management</br></br>에서 확인해볼 수 있습니다.

```html
<!doctype html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <title>CONQUER WEBPACK V4</title>
  </head>
  <body>
    <script src="bundle.js"></script>
  </body>
</html>
```
index.html

```javascript
import './style.css';

function app() {
  const division = document.createElement('div');

  const h1 = document.createElement('h1');
  h1.innerHTML = 'Hello Webpack!';
  h1.className = 'Hello';

  division.appendChild(h1);

  return division;
}

document.body.appendChild(app());
```
app.js

```css
.hello {
  background-color: coral;
  font-family: 'Roboto Mono';
}
```
style.css

이전 예시와 크게 다르지 않다. app.js는 h1이 들어있는 div를 만들고 body에 붙인다. 몇가지 차이점은 파일 상단에서 style.css 파일을 불러오고 h1에 className을 'hello'로 정하고 있다. 그런데 app.js를 보면 css 파일을 import 하고 있다. index.html에는 css 파일을 불러오는 링크는 없는데 어떻게 h1에 css를 적용하는 걸까. 아래의 webpack config를 보자.

```javascript
const path = require('path');

module.exports = {
  entry: path.resolve(__dirname, 'src', 'app.js'),

  output: {
    path: path.resolve(__dirname, 'build'),
    filename: 'bundle.js',
  },

  module: {
    rules: [
      {
        test: /\.css$/,
        use: [
          'style-loader',
          'css-loader',
        ],
      },
    ],
  },
};
```
webpack.config.js

entry와 output은 전 예제와 변함없다. module 프로퍼티가 새로 생겼는데 이곳에서 우리가 원하는 파일들을 webpack이 불러올 수 있도록 각 파일에 맞는 loader를 지정한다. 지금 우리는 css 파일을 불러들일 것이므로 .css 확장자를 가진 파일들을 style-loader와 css-loader로 불러들이도록 설정하고 있다. 이때 webpack은 아래에서 위로 loader를 적용한다. css-loader가 먼저 css 파일을 읽어들이고 그 결과물을 style-loader가 index.html의 head 태그에 삽입한다. 그래서 만약 scss를 사용한다면 먼저 scss 파일을 css 파일로 변환해야 하기 때문에 sass-loader를 맨 아래에서 필요한 옵션과 함께 지정해주면 된다. 이제 설정 파일 준비가 끝났으니 npm run  build나 yarn build 명령어를 통해 빌드하고 브라우저에서 index.html을 열어보자.

![hello webpack](/images/hello-webpack.png)
![hello webpack](/images/hello-webpack2.png)

css가 적용이 된 h1이 보인다. 개발자 도구를 열어 Elements 탭을 보니 head 태그에 style 태그가 삽입되어 있는 것을 볼 수 있다. 만약 app.js에서 다른 js 파일을 불러와 사용하고 그 파일에서도 css를 사용하면 어떻게 될까? 그리고 이미지 파일은 어떻게 불러올까? json 파일이나 font는?

위에서 만든 js, css 파일들을 수정해보자.

```javascript
import bar from './bar';
import './style.css';
import the1975 from './the1975.jpg'
import exampleJsonData from './data.json';

function app() {
  const division = document.createElement('div');

  const h1 = document.createElement('h1');
  h1.innerHTML = 'Hello Webpack!';
  h1.className = 'another';

  const img = new Image();
  img.className = 'center';
  img.src = the1975;

  division.appendChild(h1);
  division.appendChild(img);

  console.log(exampleJsonData);

  return division;
}

document.body.appendChild(app());
document.body.appendChild(bar());
```
app.js

```css
@font-face {
  font-family: 'Roboto Mono';
  src: url('./RobotoMono-Regular.ttf') format('ttf');
  font-weight: 600;
  font-style: normal;
}

.hello {
  background-color: coral;
  font-family: 'Roboto Mono';
}

.center {
  margin: 0 auto;
}
```
style.css

```javascript
import './another.css';

function bar() {
  const contents = document.createElement('h3');
  contents.innerHTML = 'Another Element!'
  contents.className = 'another';

  return contents;
}

export default bar;
```
bar.js

```css
.another {
  background-color: mediumseagreen;
}
```
another.css

```javascript
const path = require('path');

module.exports = {
  entry: path.resolve(__dirname, 'src', 'app.js'),

  output: {
    path: path.resolve(__dirname, 'build'),
    filename: 'bundle.js',
  },

  module: {
    rules: [
      {
        test: /\.css$/,
        use: [
          'style-loader',
          'css-loader',
        ],
      },
      {
        test: /\.(png|svg|jpg|gif)$/,
        use: [
          'file-loader',
        ],
      },
      {
        test: /\.(woff|woff2|eot|ttf|otf)$/,
        use: [
          'file-loader',
        ],
      },
    ],
  },
};
```
webpack.config.js

app.js에서 새로 만든 bar.js 파일과 the1975 이미지, data.json 파일을 불러오고 있다. style.css 에서는 이미지에 적용할 center class를 추가했고 새로운 폰트 파일을 불러오고 있다. 이미지, json, font 파일은 컴퓨터에 저장되어 있는 것을 활용했다. bar.js는 app.js와 비슷하게 another라는 css 파일을 사용하고 h3 태그를 만들어 반환한다.

webpack.config.js 파일의 module에 두 부분이 추가됐다. file-loader를 사용해 이미지 파일과 각종 폰트 파일을 불러올 수 있도록 만들었다. 이외에도 csv, tsv 파일 등을 csv-loader로 불러올 수 있다. 다시 빌드해서 브라우저로 열어보자.

![hello webpack](/images/hello-webpack3.png)
![hello webpack](/images/hello-webpack4.png)

the1975(아주 좋아하는 밴드..) 이미지와 bar.js의 결과가 잘 나오고 있다. 그런데 Elements 탭을 보니 head tag에 style tag가 두개가 있다. style-loader는 css 파일을 부르는 js 파일을 만날때마다 style tag를 삽입하는 것을 알 수 있다. 만약 프로젝트가 점점 커지고 css 파일도 많아지면 html 파일도 불필요하게 커지게 될 것이다. 그래서 style-loader는 production으로는 그렇게 좋은 선택은 아니다. 이때 css 파일을 개별적으로 추출하고 caching까지 할 수 있는 extract-text-webpack-plugin 이라는 좋은 플러그인이 있다. 이 웹팩 시리즈에서 이후에 production에서 이 플러그인을 사용하는 것을 다룰 것이다.

## CSS Module

지금까지 style.css, another.css 이라는 두 파일을 만들었다. 그런데 만약 style.css에 있던 hello 라는 클래스의 이름이 another로 바뀌게 되면 어떻게 될까? another.css에도 another라는 클래스가 있는데 중복되지 않을까?

```javascript
import bar from './bar';
import './style.css';
import the1975 from './the1975.jpg'
import exampleJsonData from './data.json';

function app() {
  const division = document.createElement('div');

  const h1 = document.createElement('h1');
  h1.innerHTML = 'Hello Webpack!';
  // h1.className = 'hello';
  h1.className = 'another';

  const img = new Image();
  img.className = 'center';
  img.src = the1975;

  division.appendChild(h1);
  division.appendChild(img);

  console.log(exampleJsonData);

  return division;
}

document.body.appendChild(app());
document.body.appendChild(bar());
```
app.js

```css
/* .hello { */
.another {
  background-color: coral;
  font-family: 'Roboto Mono';
}
```
style.css

위와 같이 app.js와 style.css 파일을 변경해보고 다시 빌드해서 결과를 확인해보자.

![hello webpack](/images/hello-webpack5.png)
![hello webpack](/images/hello-webpack6.png)

두개의 another 클래스는 다른 내용을 담고 있지만 style-loader에 의해 두개의 style 태그가 삽입되고 아래에 있는 style 태그의 another 클래스가 위의 클래스를 덮어씌우게 되어(중복된 클래스의 경우 나중에 오는 클래스가 우선순위를 갖는다) h1와 h3 둘 모두 배경색이 coral이 되었다. 프로젝트가 점점 커지면 스타일링도 여러 개발자가 하게 될 수 있고 점점 클래스 네이밍이 중요해진다. 일정한 규칙에 따라 이름을 짓기도 하고 개발자 나름의 묘책을 세워 만들 수도 있다. 그럼에도 파일이 더 복잡해질 수록 트래킹이 어려워지고 결국 중복되는 지점이 찾아오는데 이때 CSS Module을 사용하면 이 문제를 해결할 수 있다. CSS Module은 css 파일 하나하나를 개별적인 모듈로 간주하고 css-loader가 option에 주어지는 규칙에 따라 css 파일의 이름과 DOM에 들어갈 css 클래스명을 결정함을 의미한다. webpack config 파일과 app.js, bar.js 파일을 아래와 같이 수정해보자.

```javascript
const path = require('path');

module.exports = {
  entry: path.resolve(__dirname, 'src', 'app.js'),

  output: {
    path: path.resolve(__dirname, 'build'),
    filename: 'bundle.js',
  },

  module: {
    rules: [
      {
        test: /\.css$/,
        use: [
          'style-loader',
          // 'css-loader'
          {
            loader: require.resolve('css-loader'),
            options: {
              importLoaders: 1,
              modules: true,
              localIdentName: '[path][name]__[local]--[hash:base64:5]',
            },
          },
        ],
      },
      {
        test: /\.(png|svg|jpg|gif)$/,
        use: [
          'file-loader',
        ],
      },
      {
        test: /\.(woff|woff2|eot|ttf|otf)$/,
        use: [
          'file-loader',
        ],
      },
    ],
  },
};
```
webpack.config.js

```javascript
import bar from './bar';
// import './style.css';
import styles from './style.css';
import the1975 from './the1975.jpg'
import exampleJsonData from './data.json';

function app() {
  const division = document.createElement('div');

  const h1 = document.createElement('h1');
  h1.innerHTML = 'Hello Webpack!';
  // h1.className = 'another';
  h1.className = styles.another;

  const img = new Image();
  // img.className = 'center';
  img.className = styles.center;
  img.src = the1975;

  division.appendChild(h1);
  division.appendChild(img);

  console.log(exampleJsonData);

  return division;
}

document.body.appendChild(app());
document.body.appendChild(bar());
```
app.js

```javascript
// import './another.css';
import styles from './another.css';

function bar() {
  const contents = document.createElement('h3');
  contents.innerHTML = 'Another Element!'
  // contents.className = 'another';
  contents.className = styles.another;

  return contents;
}

export default bar;
```
bar.js

webpack.config.js 파일에서 css-loader 설정 부분을 변경했다. modules option을 true로 하고 localIdentName option에 일정한 규칙을 주었다. 이 부분은 css-loader document를 참고하면 된다. localIdentName를 살펴보자. path는 css 파일의 디렉토리 경로, name은 css 파일의 이름, local은 css selector 이름이고 마지막 hash는 매 build 마다 파일에 변경 사항이 있을때 자동으로 변경되는 부분이다. 이 옵션으로 우리는 개발 중일때 파일별로 중복되는 css 클래스명이 있어도 우리 의도대로 스타일링을 할 수 있다. 그리고 app.js와 bar.js에서 css를 불러오고 클래스명을 적용하는 부분이 바뀐 점을 주목하자.

예를 들어, book 화면에 적용할 list class를 만들고, user 화면에 적용할 list class를 만들면 list 라는 이름이 중복되어도 개발 중일때 list-book, list-user 와 같이 불편한 작업을 하지 않아도 되어 직관적으로 스타일링을 할 수 있다. 이외에도 sass-loader(sass-loader에도 동일한 modules option을 사용할 수 있다)를 사용하거나 styled-component를 사용할 수도 있다.

이제 빌드해보고 브라우저에서 결과를 확인해보자.

![hello webpack](/images/hello-webpack7.png)

localIdentName의 규칙대로 css class 이름이 만들어진 것을 확인할 수 있다.

> 이 포스트에 관련된 코드는</br></br>https://github.com/brightparagon/webpack-conquer/tree/asset-management</br></br>에서 확인해볼 수 있습니다.


[webpack v4] Asset Management

나만의 길을 걷는 것

# [webpack v4] webpack v4 시작하기

## 들어가며

2016년 초반 즈음 react에 입문해 개발을 시작하게 되었다. 웬걸, react를 하려고 봤더니 이것만으로는 웹을 만들기가 번거로워 여러(꽤 많은...) 도구들이 거의 필수적으로 사용해야 함을 알게되었다. redux도 redux지만 그중에서도 오랜 시간에 걸쳐 머리를 지속적으로 아프게 했던 것은 단연 webpack이다. 처음 사용했을때 버전이 1이었는데 해가 바뀌기가 무섭게 메이저 버전이 2로 뛰더니 여러 부분에서 사용 방식이나 문법 등이 바뀌어서 잊을만하면 재학습을 요구했다.

그래서 쓴다. 나를 위한 webpack v4 정리 시리즈. 이제와 생각해보니 redux도, redux-saga도 참 어려웠지만 유독 webpack이 골치아팠던 이유는 특히 UI Library인 react를 사용함으로써 개발 과정에서 필요한 UI 이외의 많은 부분들을 webpack이 커버하기 때문이었다. 프레임워크를 생각해보면 이해가 쉽다. 프레임워크가 제공하던 인터페이스가 없으므로 예를 들어 MVC에서 V만 지원되는 상태에서 다른 라이브러리들로 MC를 구성하고 이것을 V와 함께 일관된 패러다임 하에 서로 꿰매고 컨트롤해야 한다. 다시 말해, webpack은 개발 사이클의 전반적인 부분에 관여하기 때문에 웹 개발의 큰 구조를 어느정도 이해하고 있지 않은 경우엔 쉽고 직관적으로 활용하기가 어렵다. 갈 수록 더 많은 option과 보조하는 plugin들이 많아지는 것은 react의 활약을 포함한 Modern Web Development의 흐름 변화와 무관하지 않다.

이런 배경에서 webpack 활용에 대해 아주 기초적인 것부터 복잡한 것까지 천천히 그리고 아주 자세히 정리해보고자 한다. 버전이 또 바뀌어 사용법이나 문법이 바뀌더라도 정리한 것을 바탕으로 내 머리를 업데이트하면 되므로 이 시리즈를 webpack 활용에 대한 형상관리라고 해두면 되겠다.

## 아주 간단한 웹을 bundle 해보자

> 이 포스트에 관련된 코드는 </br></br>https://github.com/brightparagon/webpack-conquer/tree/getting-started</br></br>에서 확인해볼 수 있습니다. 작은 예제부터 모두 실행해보며 학습해보고 싶으신 분은 위 링크에서 레파지토리를 fork 하거나 zip 파일을 다운로드해서 활용해보세요.

시작하기 전에 준비물이 몇가지 있다.

- 코드를 작성할 적절한 에디터 like Sublime Text, Atom, VS Code
- 외부 모듈을 설치하고 관리해줄 npm 또는 yarn

이제 간단한 웹을 구성해보자.

```html
<!doctype html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <title>CONQUER WEBPACK V4</title>
  </head>
  <body>
    <script src="bundle.js"></script>
  </body>
</html>
```
앞으로 계속 고생해줄 index.html

```javascript
function app() {
  // h1 tag를 만든다.
  const contents = document.createElement('h1');
  contents.innerHTML = 'Hello Webpack v4!'

  return contents;
}

// app 함수가 반환한 h1 tag를 body tag에 렌더링한다.
document.body.appendChild(app());
```
indext.html에서 불러와 사용할 app.js

app.js를 번들해 index.html에서 사용할 것이다. 이때 app.js 말고도 다른 파일들도 함께 번들될 수 있고 이렇게 번들된 결과를 지금은 bundle.js라고 부르자. 그래서 index.html에서 app.js 대신 bundle.js를 불러오고 있다.

app.js에서는 h1 tag를 만들어 body에 붙이고 있다. 이 간단한 웹을 앞으로 점점 커져갈 우리의 프로젝트라고 생각하자.

이제 이것을 번들 해볼건데 이때 번들되는 대상은 우리의 web application을 동작하게 해줄 요소들이다. 이 요소들에는 js, css, image 등이 있다. 여기서 js 파일이 확장되면 react나 vue로 만들어진 앱도 webpack으로 번들될 수 있다.

이제 번들하기 위해 webpack을 설치해보자.

```bash
npm install webpack --save-dev
or
yarn add webpack
```

webpack을 설치할때 -g 옵션 등을 주어 글로벌로 설치하는 것보다 프로젝트 내부에 설치하는 것을 권장한다. webpack의 버전, 나아가 프로젝트 dependencies의 버전들이 서로 의존적일 수 있기 때문이다. 더불어 이렇게 하는 것이 다른 개발자나 다른 팀이 프로젝트 셋업을 빠르게 하는데 수월하다.

```json
"scripts: {
  "build": "webpack"
}
```
package.json

webpack을 글로벌로 설치하지 않았다면 터미널에서 webpack 명령어를 사용할 수 없다. 따라서 package.json의 scripts에 위와 같이 입력해 npm run build 혹은 yarn build로 webpack 명령어를 사용할 수 있도록 하자. 이때 webpack 명령어를 실행할 수 있는 것은 node_modules에 있는 webpack을 npm이 찾아주기 때문이다.

그 다음 webpack이 무엇을 어떻게 번들할 것인지에 대해 정해줄 수 있는 설정 파일을 작성해보자.

```javascript
const path = require('path');

module.exports = {
  entry: path.resolve(__dirname, 'src', 'app.js'),
  output: {
    path: path.resolve(__dirname, 'build'),
    filename: 'bundle.js',
  },
};
```
webpack.config.js

당장 지금은 9줄로 아주 간단하다. webpack으로 할 수 있는 것이 아주 다양한 만큼 이 파일은 앞으로 더 복잡해질 것이니 지금부터 기초를 단단히 잡아두자.

이 파일에서는 객체 하나를 내보내고 있다. 이를 webpack이 읽어 사용할 것이다. 객체 안의 속성을 하나씩 살펴보자. 먼저 4번째 줄의 entry는 webpack이 번들을 진행할 첫 진입 파일을 명시한다. webpack은 진입 파일을 시작점으로 이 파일과과 import 혹은 require로 연결된 모든 파일들 간의 관계를 dependency graph로 만들어 이것을 기준으로 번들링을 진행한다. 따라서 만약 app.js 에서 const bar = require('./bar.js')와 같이 다른 파일을 불러들이면 이를 의존 관계로 보고 bar.js까지 번들 결과에 포함시킨다. 그럼 당연히 여러 파일을 작성하더라도 index.html에서 여러 script tag로 그 파일들을 일일이 불러주지 않아도 된다. 그 다음, 5번째 줄의 output은 번들링 결과를 저장할 경로(path)와 파일 이름(filename)을 결정하고 있다. 즉, entry에서 명시된 진입 파일을 기준으로 모든 파일을 하나로 묶고 이름을 bundle.js로 지어 path에 명시된 경로로 저장하게 된다.

이때 entry와 output path에서 Node.js의 path 내장 모듈(webpack은 Node.js 환경 위에서 움직인다)을 사용해 path.resolve(__dirname, ...)와 같이 경로를 지정하고 있는데 여기에 대해서는 다른 글에서 다뤄보도록 하겠다. __dirname은 현재 프로젝트의 경로를 의미한다. 현재 경로가 /Users/brightparagon/Documents/workspace/webpack-conquer라면 entry의 결과는 /Users/brightparagon/Documents/workspace/webpack-conquer/src/app.js가 되고 output path의 결과는 /Users/brightparagon/Documents/workspace/webpack-conquer/build가 된다. 이제 번들을 해볼 차례다. 아래 명령어를 실행해보자.

```bash
npm run build
or
yarn build
```

build 폴더 내부를 보면 bundle.js이 생성되어 있을 것이다. 아래는 현재 프로젝트의 디렉토리 구조다.

![webpack direcotry](/images/webpack-dir.png)
디렉토리 구조

index.html이 build 폴더 내에 있고 webpack에 의해 생긴 bundle.js가 함께 있다. 이렇게 우리의 첫번째 번들링 과정이 완성되었다. 이제 브라우저를 열고 index.html을 열어보자.

![webpack direcotry](/images/webpack-work.png)
정상적으로 동작하는 것을 확인할 수 있다!

## 웹에서의 module과 webpack의 역할

위의 예제를 이어서 생각해보자. 지금은 app.js 파일 하나만 있고 이 파일 마저도 코드의 양이 많지 않다. 그런데 이제 로그인 기능을 붙이고, 홈페이지에서 사진을 보여주고, 네비게이션을 붙여 여러 페이지로 이동시키는 등 필요한 기능이 늘어감에 따라 한 js 파일에서 다루는 코드의 양이 점점 늘어날 것이다.

여러 기능을 한 파일에서 다루면 기능 추가나 수정이 필요할때 쉽게 접근하기 어렵다. 그래서 기능별로 파일을 나눌 필요가 생기고 어느 파일이 어느 파일을 불러 사용하는 등의 의존 관계가 생기게 된다. C++이나 Java에 익숙하다면 JavaScript에 모듈 시스템이 따로 없는 것을 받아들이기 힘들 것이다. 필자는 처음 JavaScript를 접하고 공부할때 require()가 언어가 자체적으로 지원하는 함수인줄 알았는데 브라우저에서는 지원되지 않는 것을 알고 문화컬쳐에 빠졌다.. 이에 JavaScript를 범용적 언어로서 활용하기 위한 움직임이 일었고 표준화 작업에 있어 CommonJS와 AMD가 이끌어가고 있다. Node.js도 이런 움직임에 영향을 받았다. 더 자세한 것은 14만번 정도 조회된 [스택오버플로우 링크](https://stackoverflow.com/questions/16521471/relation-between-commonjs-amd-and-requirejs)에서 찾아보자.

이것이 어떤 의미인지 알아보기 위해 위 예제에서 src 폴더에 아래와 같이 bar.js를 만들고 app.js에서 불러오는 코드를 만들어보자.

```javascript
const bar = require('./bar.js');
// or
import bar from './bar';

function app() {
  const contents = document.createElement('h1');
  contents.innerHTML = 'Hello' + bar();

  return contents;
}

document.body.appendChild(app());

// bar.js
function bar() {
  const string = ' Webpack!';
  return string;
}

module.exports = bar;
// or
export default bar;
```
app.js와 bar.js

이번엔 webpack을 활용하지 않고 index.html에서 script 태그의 src 속성 값을 "../src/app.js"로 수정하고 브라우저로 다시 열어보자.

![console](/images/console.png)

개발자 도구를 열어 Console 탭을 확인해보면 이와 비슷한 에러를 볼 수 있다. 저 Unexpected identifier는 import from 구문을 의미한다. 만약 require를 사용했다면 require is not defined와 같은 에러를 뱉는다. 그렇다. 브라우저엔 정말 당연히 있을 것 같은 모듈 시스템이 없다.

Modern Web Development의 많은 비중을 JavaScript가 잠식해가고 있는 만큼 webpack이 건네는 도움의 손길은 더욱 크게 느껴진다. 부족한 모듈 시스템을 브라우저가 알아듣게끔 대신 설명해주고, 동시에 개발자인 우리에게는 모듈 시스템을 이용해 손쉽게 파일들을 모듈화할 수 있도록 도와준다. 벌써 v4의 베타 버전이 올라왔고 더 많은 개선 사항이 포함되어 있다. webpack은 모듈화 말고도 훨씬 더 멋진 기능들을 갖고 있다. 가령,  bundle.js가 너무 비대해지면 이것을 쪼개 parallel로 불러오게끔 만들어 초기 로딩 속도를 개선시킬 수도 있고, 심지어 SPA의 경우엔 라우팅 경로를 구분해 처음엔 필요한 번들만 불러오고 경로에 따라 알맞은 파일만 그때그때 불러와 앱을 가볍게 느껴주게 할 수도 있다. 또, 개발 과정을 단순화하고 코드 변경에 따른 앱 리로딩을 자동으로 해주며 [Progressive Web Apps](https://developers.google.com/web/progressive-web-apps/)를 지원하는 플러그인을 사용할 수도 있다. 걸작이다. 근데 이 모든 것을 사용하려면 많이, 아주 많이 복잡하다. ~~그래서 요새 많이 parcel로 넘어가는 듯 하지만.. 필자는 webpack이 더 프로덕트 친화적이라 생각해 webpack에 잔류할 생각이다..~~ 앞으로 연재할 webpack 포스트들에서 이런 멋진 기능들을 예제로 직접 만들어보면서 사용해보도록 하자.

> 이 포스트에 관련된 코드는 </br></br>https://github.com/brightparagon/webpack-conquer/tree/getting-started</br></br>에서 확인해볼 수 있습니다. 작은 예제부터 모두 실행해보며 학습해보고 싶으신 분은 위 링크에서 레파지토리를 fork 하거나 zip 파일을 다운로드해서 활용해보세요.


[webpack v4] webpack v4 시작하기

되돌아보는 2017년

# 옷, 개인 그리고 패션테크 스타트업

얼마전 김정운 작가의 Editology를 읽었을때 책에 이런 구절이 있었다.

> 공간의 형태에 따라 생각하는 방식도 달라진다.

그래서 위 사진과 같이 Facebook도 자신들의 미션에 따라 새로운 공간에서 일하기 시작했는데 사방이 탁 트이고 천장도 매우 높은 공간이다. 그럼 그들의 미션이 뭐길래 탁 트인 공간에서 일하기를 원했을까? 이미 Zuckerberg가 Y Combinator에서 언급해 많이 유명해진 그들의 미션은 사람들을 더 연결시키는 것이다. 이런 미션에 따라 일하는 것이 업무 공간과 어떤 연관성을 갖는지 생각하기 전에 먼저 이 미션에 따라 일한다면 사람들이 어떤 방식으로 생각하게 될지에 대해 알아보는 것이 좋겠다. 그래서 아래와 같은 질문들을 떠올려봤다.

- 전세계의 사람들을 연결시키고자 하는 이들은 일을 할때 생각이 어떻게 흐를까?
- 한 국가에 한정된 서비스를 만드는 사람들의 사고 흐름과 비슷할까?
- Facebook의 엔지니어들은 엔지니어링 부서 이외에 어떤 팀들과 소통을 얼마나 자주하고 어떤 과정으로 기능에 대한 아이디어를 얻어 설계하고 만들까?
- 그럼 마케팅팀 직원들은?
- 디자인팀 직원들은?
- CEO와 경영진은?
- 이 몇만명의 직원들이 어떻게 미션과 가치를 서로 공유하고 그에 따라 태스크를 구상할까?

질문을 하면서 답변이 동시에 저절로 나오는 걸 느꼈다. 국가, 종교, 문화, 기후, 언어, 인종 그리고 가치관이 서로 다른 사람들을 연결 시키려면 그에 걸맞는 서비스가 필요할 것이고 그 서비스를 이루기 위한 기능과 디자인이 필요할 것이다. 누구를 대상으로 어떤 서비스를 하느냐는 그 회사의 정체성을 나타낼 것이고 그에 따라 팀들 간의 유기적 협업 방식도 달라질 것이다. 즉, 일의 목적에 따라 그에 적합한 업무 방식이 필요하게 될텐데 그 방식이 회사 곳곳에 잘 정착되기 위한 문화나 공간이 필요하지 않을까? 이런 서비스를 하는 회사의 업무 공간이 팀별로 지나치게 구분되어 있거나 넓은 회의실이 몇 군데 없고 건물 곳곳에 배치되어 있지 않으면 팀들이 서로 협업하기 어렵지 않을까?

위에서 든 예는 업무 형태에 따라 적합한 공간 형태를 생각하는 순서였지만 반대로도 설명이 가능하다. 자연을 벗삼아 사는 사람과 건물이 빽빽하게 들어선 도시에 사는 사람의 사고 방식과 흐름이 전혀 다른 것처럼 업무 공간의 형태에 따라 같은 일을 하더라도 사고의 방식과 흐름에서 차이가 생길 것이다. 물론 업무에 적합한 공간에서 일하지 못한다고 해서 생산성이 급격하게 낮아지거나 하는 것은 아닐 것이다. 어디까지나 공간까지 생각하는 것은 생산성을 최대한 끌어올리고 자신들의 미션과 문화에 맞는, 직원들을 한껏 고무시킬 수 있는 환경을 만드는데 목적이 있기 때문이다. 98%에서 99%로 나가기 위함일 것이기 때문이다.

---

서론이 참 길었는데 패션테크 스타트업에서 일하면서 옷도 이와 비슷하다고 생각하게 됐다. 내가 좋아하는 옷을 입은 날은 집을 나설때부터 다르다. 아침에 하는 생각의 내용도 조금 달라진다. 오늘 있을 일을 생각하고 누굴 만나 어떤 이야기를 나눌지까지 생각이 이어진다. 뭘 입을지 생각이 안나 대충 입은 날은 종일 찝찝하다. 옷에도 생각이 반영되지만 어떤 옷을 입느냐도 생각에 영향을 미친다.

> 옷은 생각과 행동에 영향을 미친다.

심지어 옷을 구경하면서 이건 어떨까, 저건 어떨까 생각해보고 입다보면 내가 몰랐던 나의 모습을 알게 될 때가 있다. 전에는 한번도 생각해보지 못했던 디자인이나 스타일의 옷을 입어보면 되게 어색하지만 '어 뭐지 이런 모습도 있었나?' 하고 생각하게 된다. 직장인이 되고나서 이런 경험을 서너번 했다. 이쯤 되니 사실 패션은 자기이해를 필요로 하는 자기표현인 거구나! 하고 깨닫게 되었다.

> 패션은 자신을 찾아가는 길이다.

그래서 패션테크 스타트업에서 일하는 사람으로서 패션을 자기이해의 수단으로 보는 관점이 사회에 얼마나 만연한가가 패션 사업성에 어떻게 영향을 미칠지 그 관계성에 대해서 다뤄보고 싶어졌다.

## Fashion - 너에 대해 얼마나 알고 있니?

나는 나에 대해서 얼마나 이해하고 있을까? 정확히 말할 수 있다. 나는 아직도 나를 잘 모른다. 아직 찾지 못한 부분이 많다. 물론, 아는 범위 안에서는 누구보다 나를 더 잘 안다. 하지만 모르는 부분이 있는 것은 사실이고 인생은 어쩌면 자기를 찾고 이해하는 자아성찰의 여행일지 모른다. 마틴 하이데거도 죽기 전까지 자신에 대해서 완전히 이해하지 못했을 것이다.

![sartorialist](/images/sartorialist.jpg)

The Sartorialist – 사진으로 가득 채워진 이 책은 패션에 대해 그리고 패션이라는 창으로 새로운 나를 보게 해주었다.

아마존 베스트셀러 중에 [The Sartorialist](https://www.amazon.com/Sartorialist-Scott-Schuman/dp/0143116371/ref=sr_1_1?ie=UTF8&qid=1502588963&sr=8-1&keywords=sartorialist)라는 책이 있다. www.thesartorialist.com 이라는 사이트의 도서 버전이다. 이 책은 텍스트가 반도 안된다. 전체가 인물사진이고 모두들 완전히 다른 옷을 입고 있다. 한명 한명 사진을 보면서 '내가 저 옷을 입고 있다면 어떤 기분일까' 라며 계속 나를 대입시켜 보았다. 찌릿찌릿 했다. 어떨때는 부끄럽기도 했고 어떨때는 기분이 좋아지기도 했다. 단순히 멋진 옷을 자기만의 스타일로 입은 사람의 사진을 보았을 뿐인데 나는 거기서 오히려 나에 대해서 알게 되었고, 심지어는 가까운 미래에 어떤 커리어를 쌓으면서 어떤 옷을 입고 일을 하고 싶은지, 어떤 옷을 입고 회의에 참석하고, 연단에 올라 발표하고 싶은지를 생각해보게 되었다. ~~물론 지금은 너덜하게 막 입고 다닌다..~~

<div>
  <img alt="sartorialist" src="/images/sartorialist2.jpg" style="width: 49.6%; height: auto;" />
  <img alt="sartorialist" src="/images/sartorialist3.jpg" style="width: 49.6%; height: auto;" />
  <img alt="sartorialist" src="/images/sartorialist4.jpg" style="width: 49.6%; height: auto;" />
  <img alt="sartorialist" src="/images/sartorialist5.jpg" style="width: 49.6%; height: auto;" />
</div>

사토리얼리스트에 있는 사진들이다. 요새 너무 formal하지 않은 정장에 관심이 많아서 이런 사진들을 가져왔다. 아.. 저 일본 아저씨들 너무 멋있다. 이 사진들을 보고 어떤 생각이 드는가? 그냥 저런 옷을 입은 외국인에 불과한가? 아니면 '내가 저 옷을 입고 출근을 하면 어떤 기분일까' 라며 자신을 대입시켜 보고 상상해보았는가?

나는 단순히 옷을 입은 사람을 본 것이 아니었다. 패션 도서를 읽은 것이 아니었다. 나는 패션이라는 도구를 접함으로써 자기이해의 과정을 걷고 있었던 것이다. 몇년전의 내가 이 문장을, 이런 생각을 보고 엿듣게 된다면 코웃음을 쳤을 것 같다. 그런데 한번 관심을 갖게 되니 안보이던 것들이 보이기 시작하고 이 분야의 사람들이 이해되기 시작했다. 그리고 나도 모르던 나의 모습과 내가 어떤 모습이길 바라는가에 대해서도 서서히 알아가기 시작했다. 책을 읽고 여행을 떠나 모르던 곳을 탐방하고 새로운 모임에 나가 새로운 사람들을 만나 이야기하는 것만이 자기성찰의 방법이 아니었던 것이다. 나를 알아가는 새로운 루트를 찾은 것이었다. 옷을 통해서 나와 주변 그리고 우리를 감싼 문화 전반에 대해서 새로운 관점으로 이해하기 시작한 것이다. 문화에 따라, 오늘의 느낌에 따라, 충동에 따라, 만날 사람에 따라, 나갈 모임에 따라, 생각에 따라 옷을 골라 갖춰 입는 것은 그저 옷을 집어 걸치는 행위가 아닌, 충분한 자기이해를 바탕으로 한 자기표현의 행위인 것이다.

혹자는 이렇게 생각할 수도 있겠다. '나는 옷을 잘 입는데 그렇게까지 나에 대해 이해하면서 옷을 입지는 않는데?' 어디까지나 자기이해는 메타인지의 영역이다. 옷을 잘 입는다고 꼭 자기이해가 수반 되었다고는 할 수 없다. 그러나 옷을 잘 입고 싶은 그 이유를 내 안에서 찾기 시작하면 그때부터 자기이해가 시작된다. 나 자신이 어떻게 생각하고, 어떻게 느끼고 반응하는지에 대해 알아가기 때문이다. 그렇다고 옷을 잘 입지 못한다고해서  자기이해가 덜 된 것도 아니다. 앞서 이야기했듯 패션은 자기이해와 자기표현에 이르는 하나의 길이기 때문이다. 내가 과도가 없다고 사과를 못깎아 먹는 것은 아닌 것처럼 말이다. 과도 없어서 못깎아 먹으면 인생에 대해서 한번 되돌아 볼 필요가 있다...

## 그리고 사업성

생각이 여기까지 이르고 나니, 패션테크 스타트업에서 일하는 사람으로서 사업성을 생각하지 않을 수 없었다. 지금까지 살펴본 바로는 패션은 개인의 취향과 생각, 가치관에만 그 영향이 국한되어 있지 않다. 사회와 문화에도 관련이 있고 둘은 서로 끊임없이 영향을 주고 받는다. 개인이 사회에서 갖는 역할을 중요시하는 문화에서는(성숙한 문화에서는) 많은 사람들이 다양한 활동을 하며 계속 자신을 이해하는 과정을 반복한다. 선진국에 작가와 블로그 문화(like Wordpress and Medium)가 잘 발달되어 있는 것도 같은 맥락으로 볼 수 있다. 자신이 경험한 것과 알게된 것에 대해서 서로 공유한다. 도대체 이게 패션의 사업성과 무슨 연관성이 있단 말인가?

이 부분이 아주 중요하다. 옷은, 패션은 그냥 옷 걸치는 것이 아니다. 개인 문화가 성숙한 사회에서는 개개인이 스스로의 인생에 대한 관심과 애정이 높고 자신의 취향 또한 분명(확고)해질 수 밖에 없다. 자신이 뭘 원하고 앞으로 어떻게 살고 싶은지 이해하고 있는 개인들이 매우 다양하게 그리고 많이 존재한다는 의미다. 이것이 옷으로 옮겨가면 앞서 이야기했던 다양한 상황 속에서 자신이 어떻게 보여지고 싶은지 즉, 어떤 옷을 입어 자신을 나타내고 싶은지로 연결된다. 당연히 이런 곳에서, 이런 개인이 많은 곳에서 다양한 옷이 더 자주, 더 많이 팔리지 않을까? 옷에 정말 개미 코딱지 만큼도 관심없는 사람을 붙잡고 옷이 이래요, 추천이 어째요, 감성이 오져요라며 백날 설명하고 광고해도 통하지 않을 것이다. 특히 그런 개인이 많은 지역 혹은 국가일 수록 더 그럴 것이다. 물론, 아직은 옷에 관심이 없지만 이제 천천히 알아가고자 하는 사람이 있을 수 있듯 경우의 수는 매우 다양할 것이다. 하지만 분명한 것은 그 여러 카테고리에 속한 사람의 수는 많지 않을 것이다. 중요한 것은 어떤 카테고리들이 주류를 이루는가에 대해 알아내는 것이지 않을까?

<img alt="airbnb" src="/images/airbnb.png" style="margin: 30px auto; width: 200px; height: auto;" />

Airbnb는 사업이 궤도에 오른 후 시인했다. 자신들이 성공할 수 있었던 가장 큰 이유 중 하나는 밀레니얼 세대였다고. 밀레니얼 세대는 디지털에 익숙하고 자금이 그리 넉넉치 않지만 여행을 떠나기 좋아하며 새로운 인연을 만들어 나가는데에 거리낌이 없는 세대다. 앞서 설명한 내용에 비추어보면 이 세대는 자기이해의 여정을 달가워하고 즐기는 세대인 것이다. 초창기의 Airbnb는, 현재도 그러하지만, 이 세대가 견인했다고 해도 과언이 아니다. 남의 집에 모르는 사람을 들여 숙박하게 한다? 새로움과 창의성이 샘솟는 실리콘 밸리에서도 Airbnb의 이런 아이디어는 철저히 무시당했다. 그러나 그들의 사업과 아이디어는 돈이 궁핍하지만 전세계로 여행하길 원하는 밀레니얼 세대에 의해 처음으로 환영받았고 지지 받았다. 그렇게 사업이 성장하기 시작했고 안정화 되어갔다. Airbnb가 이후 어떤 고난과 역경을 딛고 지금에 이르렀는지는 The Airbnb Story라는 책이 아주 잘 설명해 놓았다.

다시 패션으로 돌아와, 이 Airbnb의 이야기를 패션에 적용해보면, 현재 우리가 시장으로 삼고 있는 사회에 속한 사람들이 어떤 사람들인지를 알아보는 것이 필요해진다. 물론 Airbnb는 사업을 시작할때 밀레니얼 세대는 생각조차 안했지만 말이다. 적어도 서비스를 제공할 대상에 대해 알아본다면 사업을 진행하고 전략을 수립하는데 큰 도움이 되지 않을까? 우리가 만들 서비스를 쓸 사람들에 대해 알아보기 위한 질문들을 아래와 같이 생각해보았다.

- 이들은 어떤 사람일까?
- 자신에 대해 알기를 꺼려하지는 않을까? 그럴 준비는 되었을까?
- 아직 그 정도로 문화가 성숙하지는 못하지 않았을까?
- 2, 3, 4, 50대 각각은 어떤 생활 양식으로 대변될 수 있을까?
- 지금 그들의 상황은 어떠한가?
- 앞으로 더 잘 벌 수 있으리라는 분위기가 사회에 만연한가?
- 이들은 미래를 낙관하는가? 아니면 반대인가? 그에 대한 이유는?
- 이들은 여행하기를 좋아하는가?
- 이들이 명품에 대해 또는 어떤 브랜드에 대해 어떤 인상을 갖고 있을까?
- 또 그 인상의 강도는 강한가? 혹은 약한가?
- 강하다면 어느 방향으로 강하고, 그 방향이 우리가 알리려는 방향과 다르다면 어떻게 이해시킬 수 있을까?
- 이해시키는데에는 얼마만큼의 시간이 걸릴까? 그 시간을 우리가 견뎌낼 수 있을까?
- 거부감이 들지 않도록 바꾸고 이해시키려면 어떤 마케팅과 홍보 전략을 어떤 스텝으로 수립하고 실행해야 할까?
- …

타겟을 이해하고 좁혀 사업을 진행하는 것은 중요할 것이다. 그런데 그 타겟이 속한 사회와 이를 대변하는 개인을 이해하지 못한다면, 위와 같은 질문들에 대한 대답이 선행되지 않는다면 뭘 어떻게 좁힐지 정하는 것이 어렵지 않을까? 적어도, 위와 같은 질문 및 이해가 뒷받침 된다면 좀 더 수월하게 사업을 진행하고 여러 전략들도 시장에 대한 이해를 바탕으로 수립할 수 있지 않을까라는 생각이 든다. 이 이해를 바탕으로 또 다시 아래와 같은 질문을 해볼 수 있다.

- 우리가 제공하려는 패션 서비스의 가치가 무엇인가?
- 그 가치가 소비자 주류에게 얼마나 다가갈까?
- 다가가지 못하고 있다면 그 이유가 성숙한 개인 문화의 부재 때문은 아닐까?
- 다른 이유가 있다면 개별적인 영향은 얼마나 될까?
- 현재 소비자 카테고리는 어떻게 나눌 수 있을까?
- 각각에 대한 상황은?
- ...

지금까지 패션이 개인의 자기이해와 어떤 관련이 있는지 그리고 그 관련성이 패션 서비스를 만드는 관점에서 어떻게 사업성에 영향을 미칠 수 있는지 살펴보았다.

자기이해의 관점에서만 보면 우리는 음악을 들으면서, 옷을 사고 입으면서, 여행을 하며 새로운 곳에 가보면서, 새로운 분야를 공부하면서, 새로운 사람을 만나면서, 새로운 언어로 소통하면서 끝없이 자기이해의 과정을 걷는다. 나는 이 각각이 서로 분리되어 있다고 믿지 않는다. 아직은 보수적인 사회 분위기에 의해 이 연결고리들이 군데군데 끊어져있다. 남자가 화장을 하네, 여자가 저런 옷을 입네, 저 사람은 저런데를 가네.. 등 온갖 편견들이 도사리고 있다. 이 편견들이 자취를 감출때, 모든 개인이 각자의 성향과 하고자 하는 일에 대해 존중을 받을때 개인들의 활동은 더욱 다양해지고 풍성해질 것이라 믿는다. 그리고 그렇게 되었을때 옷에 대한 사람들의 관심 또한 훨씬 더 다양하고 많이 생길 것이라 생각한다. 그때 우리 서비스는 사람들이 자신을 찾아가는 여정을 돕는 건강한 서비스로서 더 큰 성장을 할 수 있을거라 믿는다.


옷, 개인 그리고 패션테크 스타트업

# SK에서 나는 무엇을 배웠나

이 회사에서 나는 무엇을 배웠는가? 그리고 스타트업으로 오기까지 무엇을 했나!

지난 2년을 정리하고 되돌아볼 때가 왔다. 그 2년을 크게 세부분으로 나눠볼 수 있겠다.

- 회사에 입사했고
- 퇴사를 했고
- 회사에 입사했다

2015년 2월 졸업을 하고 회사가 뭔지, 일이란게 무엇인지 아무것도 모르는 상태에서 같은 해 7월 1일, SK C&C에 입사했다. 그리고 정확히 15개월 뒤인 2016년 9월 30일에 퇴사를 했다. 지금 생각해도 아찔한 나날들이다.😨 너무 많은 변화가 짧은 기간에 일어나 무슨 일이 일어날 때마다 적절한 대처가 무엇인지 알기 위해 부딪치고 헤맨, 고된 학습의 시간이었다. 컴퓨터공학엔 관심을 가진지 2년도 안되는, 그저 철학 서적을 탐독하던 스물다섯 새파란 rookie였으니 옆구리만 찔러도 놀라고 뭘 갖다줘도 모든게 새로운 때였다. 물론 지금도 공부할 게 산더미다(..).

## 그래서 무얼 배웠나?

이것도 아래와 같이 크게 세가지로 나눠볼 수 있겠다.

- 조직이 어떻게 구성되고 업무가 어떻게 부여되는가
- 조직 문화가 갖는 회사에서의 역할
- How to communicate efficiently!

### 조직, the organism constantly moving forward

팀에 부서 배치를 받고 사무실에 처음 들어간 날을 잊을 수 없다. 오우 이게 회사구나. 그렇게 첫 여섯달을 배우고 일하면서 가장 먼저 눈에 들어온 것이 이 정도 규모의 큰 조직이 어떻게 구성되어 있고 그 구조에 따라 개인에게 업무가 어떤 형태와 과정으로 부여되는가였다. 물론 신입사원의 눈으로 보는 것이었기에 많은 것을 다 파악하기엔 한계가 있었다. 그럼에도 그 구조를 알아보려 부단히 노력했다.

가장 중요해 보였던 것은 사업부다. 사업부란 말 그대로 어떤 회사가 생존하고 성장하기 위해 중점적으로 일으키고 있는 모든 경제적 행위들을 실행하는 세부 조직의 집합이다. 그리고 이것을 중심으로 사업과 직접적으로 관련된 세부 조직이 구성되고, 이 조직이 원활히 운영되기 위해 필요한 인적, 물적, 문화적 자원을 관리 및 배분하고 경영에 관련한 변경 사항이나 공지할 사항을 전 조직에 알리는 역할을 하는 지원 조직이 구성된다. 단순히 구분하자면 Running / Support로 나눌 수 있겠다. 이 Support 조직을 회사마다 다르게 부르고 구성한다. 이중에 인적 자원에 집중하는 조직을 대표적으로 부르는 이름이 HR 일테다. 그리고 돈을 벌어다주는 영업 조직. 사업의 형태와 성격에 따라 팀으로 있을 수도 있고 Running 조직의 부분으로 존재할 수도 있다. 그 다음으로 회사의 규모, 재정 상태 혹은 종류에 따라 부가적으로 생기는 조직들 중 하나가 R&D다. 이 연구개발 조직 또한 사업의 특성에 따라 완전히 독립적인 형태로 존재할 수도 있고 각 사업부마다 귀속된 형태로 있을 수도 있다.

이쯤 파악하고 나서 든 생각은 회사는 완전한 유기체라는 것이다. 가장 기본이 되는 단위 조직이 마치 움직이는 레고 같았다. 위 단락에서 본 바와 같이 어느 것 하나 글로벌하게 정해진 틀이 없다. 어떤 사업을 하느냐에 따라 Support 조직의 규모가 클 수도, 작을 수도 있고 R&D 조직이 독립적일 수도 있고 특정 사업부에만 존재할 수도 있다. 회사의 가치, 사업의 형태에 따라 이 레고들은 유기적으로 배치되고 조립된다. 더 높은 차원에서 이야기하면, 당연히 회사 또한 국가와 국제사회라는 더 큰 조직의 세부 조직이므로 회사의 레고들은 사회-회사에 걸쳐 이중으로 영향을 받는 셈이다. 이렇게 이중적 영향을 받아 생기고 있는 대표적인 레고 중 하나가 AI branch다. 애초에 회사의 사업을 구성할 때 AI 및 Machine Learning은 고려조차 하지 않았지만 시대적 흐름을 무시할 수 없어 만들어졌기 때문이다. 즉, 처음부터 ML로 돈을 벌기 위해 설립된 회사가 아닌데 회사 내에 ML related 팀이 있다면 그 레고는 이중적 영향을 받은 것이다.

나이 서른, 늦더라도 마흔에 북미권에서 스타트업을 꼭 만들고 싶은 나로서는 조직을 어떻게 구성해야 하는가에 대해 알아볼 수 있었던 소중한 배움들이었다. 조직에 대해 한 문장으로 정리해보면, 조직은 실행하려는 사업의 특성과 형태에 따라 적절히 구성하고 회사의 핵심 가치에 따라 끊임없이 개선 및 발전시켜야 한다는 것이다. 사업의 특성에 맞지 않게 Support 조직이 비정상적으로 비대하거나, Running 조직들 간의 조립 이음새가 시원찮거나, 외부의 흐름에 따라 유기적으로 조직 구성의 변화를 꾀하지 못한다거나, 조직의 구성이 사업의 특성에 맞지 않는다거나 하여 레고들이 잘 조립되어 굴러가지 않는다면 회사는 언젠가 삐걱거릴 것이라고 생각한다.

### 조직 문화의 역할과 중요성

다음에 배운 것이 조직 문화이다. 이것의 결핍을 회사에서 많이 느꼈기 때문에 그 필요성과 중요함이 매우 크게 다가왔다. 조직 문화는 실체가 없다. 그래서 만질 수도 없고 누군가에게 '여기 있어요~' 라며 건네줄 수도 없다. 다만, peer colleague들이 서로를 어떻게 대하고 소통하는지, 서로 다른 직급에서는 어떻게 소통이 이루어지는지, 구성원들이 서로를 어떻게 부르는지, 구성원들이 회사를 어떻게 생각하는지, 경영진과 모든 구성원이 회사의 Service로 고객에게 어떤 가치를 주고싶은지, 경영에 관한 중대한 결정을 할때 구성원들이 어떻게 참여하고 의견을 내는지, 한 가지 사안에 대해 다같이 참여해야할 상황에 회의를 어떤 가치에 따라 진행하는지, 그 방식은 어떤지 등 회사 내에서 이루어지는 모든 행위에 추상적으로 깃들어있다.

만질 수 없고 보이지 않아서 쉽게 간과되고 무시될 수 있다. 그래서 더욱 중요하다. 보이지 않지만 회사 구석구석 모든 곳에 존재하고 그 영향을 끊임없이 끼치기 때문이다. 따라서 '우리가 하려는 일은 이러한 거에요. 이 일을 통해 이런 가치를 만들고 있어요. 우리는 이런 일을 하기 때문에 서로를 이렇게 생각했으면 좋겠어요. 그래서 일대일, 다대다 소통을 할때는 이런 방향으로 하길 원해요. 그 방식이 우리가 추구하는 가치를 더욱 풍성하게 하고 서비스를 더 좋게 만들 것이라 믿어요.' 라는 식의 정언적 문장들이 지속적으로 갈고 닦아져야 하며 구성원들 또한 그것을 좋아하고 그것에 깊이 공명하고 그것에 따라 행동할 수 있어야 한다. 회사를 구성하는 아주 작은 개인들에게도 큰 영향을 끼치고 이는 곧 사업의 질과도 연결되어 있기 때문이다. 물론 뚜렷한 조직 문화가 없다고 해서 제품 혹은 서비스가 꼭 안좋지는 않을 것이다. 하지만 분명한 것은 그저 좋은 제품이 아닌, 사랑받는 제품과 서비스를 만드는 회사를 보면 하나같이 좋은 조직 문화를 갖고 있고 그것을 끊임없이 개선시키고 있다. 여기에 대해 생각할 때마다 문화가 좋으면 사내에 선순환적인 고리가 생길 것 같은 직감을 꾸준히 받는다.

### 소통이 뭐에요? 😲

그 다음은 소통. 가끔 인스타를 하다보면 누군가가 내 사진에 좋아요를 누르고 '잘 봤어요. 소통해요~' 라며 댓글을 다는 것을 심심찮게 본다. 대체 난 저들과 무슨 소통을 해야한단 말인가.. 들어가보면 죄다 네일샵이다.. 이런 실체가 잘 와닿지 않는 소통을 회사에서도 적절히 잘 해야함을 느꼈다. 너무 당연한 말인가? 하지만 '잘' 하는 것은 그리 쉽지 않다. 그것도 회사에서는 더욱. 결론적으로 '커뮤니케이션에 능하다' 를 먼저 정의하자면, '상대가 어떤 심정, 상태, 맥락에서 어떤 메세지를 전달하려는지 의도를 파악하고 경청한 뒤, 나의 메세지 또한 상대가 잘 이해할 수 있도록 상대의 언어로 표현하는 것'이다. 너무 조건이 많아 보이는가? 하지만 아주 필요한 것들로만 구성한 문장이다. 그만큼 잘 소통하는 것은 무척 어려운 일이다. 살아보니 실제로 그렇고 이것의 결핍때문에 크고 작은 불상사를 겪는 사람들을 주변에서 아주 많이 왕왕 봐왔다. 그래서 적어본다. 내가 겪은 소통이 참 어려웠던 불통 케이스들.

1. 듣는 것 같긴 한데 말이 너무 없는 사람
2. 듣지도 않고 말도 없는 사람(...)
3. 잘 듣지도 않는데 자기 말이 너무 많은 사람
4. 상대의 말을 아무렇지 않게 끊는 사람
5. 듣기는 하는데 상대의 심정, 상태, 맥락 파악이 안되는 사람
6. 말할 때 상대의 언어로 말하지 못하는 사람

모두 회사에서 만나면 골치아픈 건 매한가지인 사람들이다. 1, 2번은 매우 답답하고, 3번은 annoying하고, 4번은 매우 불쾌하며, 5, 6번은 안타깝다. 1~4번은 눈에 너무 띄기 때문에 웬만해선 주변에서 다 인식하고 있다. 그래서 협동(?)하여 잘 대처할 수 있다. 5, 6번은 안타깝다고 했는데 이유는 다음과 같다. 먼저 5번은 정상적인 소통은 가능하나 상대에 대한 이해를 바탕으로 이야기하지 못하기 때문에 메세지 전달력이 낮을 뿐더러 상대의 마음을 움직이는 데에는 십중팔구 실패한다. 상대의 심정을 알고 그의 말하는 전후 맥락을 파악하는 것이 어떻게 메세지 전달력과 설득력에 도움이 되냐고 묻는 사람이 더러 있다. 상대가 어떤 심정인지 알면 그에 맞춰 나의 말하는 stance를 정할 수 있다. 당연히 나의 stance에 따라 말하는 양태 또한 달라지고 이를 듣는 이도 느끼고 반응한다. 같은 내용의 메세지이더라도 어떤 방식과 형태를 취하느냐에 따라 분위기가 달라지고 듣는 이의 수용력에 영향을 미칠 수 있다. 그래서 5번은 그 이해의 폭만 넓히면 괜찮은 소통을 할 수 있기 때문에 안타까운 것이다. 6번도 안타깝지만 조금은 답답한 케이스다. 가끔 자기 분야의 용어로 뒤범벅된 언어를 구사하는 사람이 있다. 대화 중에 말이다. 모두가 같은 분야 사람이고 회의를 하는 경우에는 문제가 되지 않는다. 하지만 다양한 분야의 사람들이 모인 자리나 그런 개인과 소통할 때엔 문제가 된다. 듣는 이가 화자의 말에 공감할 수 없기 때문이다. 이런 경우, 듣는 이도 화자가 적어도 무슨 말을 하는지는 이해하지만 결론적으로 와닿지 않기 때문에 서로 좋은 소통을 하는 데엔 실패한다.

어디든 좋은 소통이 이루어지기 어려운 곳은 별로 있고 싶은 곳은 아니다. 좋은 소통이 되는 곳에 있으면 일과 대화에 완전히 몰입하고 시간 가는 줄 모르고 집중하게 되는 일이 빈번하게 일어난다. 그런 일이 잦으면 잦을 수록 직장 생활 뿐만 아니라 삶에 대한 만족도 또한 상승할 것이라 생각한다. 아니, 거의 그렇게 믿는다. 김정운 작가의 책을 읽다가 이런 구절을 본 적이 있다. 소통을 정말 잘하는 사람은 공감(sympathy), 감정이입(empathy)을 하고 나아가 공명(resonance)한다는 것이다. 정말 공감하는 바이다. 이 말은 앞서 설명한 '상대의 심정, 상태, 맥락을 이해'하지 않고서는 성립되지 않기 때문이다. 입사하기 전엔 이런 여러 종류의 불통러들을 회사 내에서 만났을 때 어떤 일이 일어날지 전혀 예상하지 못했고 생각할 겨를도 없었다. 1년 넘게 다니면서 이런 불통러들이 회사와 일에 어떤 영향을 미치는지 골고루 보아왔다. 그래서 참 고맙고(?) 좋은 소통을 하기란 쉬운 것이 아니고 그것엔 자기 개선이 필수적으로 수반된다는 사실을 알게 된 시간들이었다.

## 무엇이 나를 퇴사로 이끌었는가?

대학교 2학년때 처음으로 꿈이 생겼다. 당시엔 '세계적인 엔지니어가 되어 세상에 무언가 도움이 되는 걸 만들고 싶다' 라는 다소 추상적인 형태의 꿈이었다. 다행히 전에 쓴 글 나, 주체적으로 살고 있는 걸까? 에서 설명한 것처럼 이 추상적인 꿈은 현재 나의 가장 근원이 되는 꿈이 되어 지금도 길라잡이 역할을 하고 있다. 입사를 할때에도 이런 삶의 방향성에 입각해서 계획을 세워야 했다. 그래서 생각한 것이, 개발 부서에 배치되면 최대 3년, 이외의 부서는 2년을 다니는 것으로 정했다. SI 회사였기 때문에 기간 산정이 저렇게 나왔고 대기업에서 배울 수 있는 것을 최대한 습득하고 service를 만드는 개발을 하기 위함이었다. 그래야만 최대 3년을 다녀도 스물여덟에 나와 다른 도전을 할 수 있다는 계산이 나왔기 때문이었다.

그렇게 입사하고 인프라 팀에서 일한지 13개월이 되었을 때 머릿속에 스멀스멀 피어오르기 시작했다. 이 이상 더 머무를 이유가 없다는 생각. 때마침 고객사였던 SK Hynix의 책임님께서도 새로운 도전에 대해 이야기해주셨다. 그래서 퇴사한 것은 아니다.. 3년이 되었든, 2년이 되었든 퇴사를 해야할 시점에 적절히 퇴사할 수 있도록 입사를 한 시점부터 퇴근 후 개인 포트폴리오를 위한 공부와 개발을 하기 시작했다. 그 공부와 개발의 행적을 남기기 위해 Github에 프로젝트를 만들고 꾸준히 commit 했다. 별거 아니지만 그땐 그 별거아닌 것이 필요했고 중요했고 간절했다. 그렇게 하루 두시간씩 매일을 공부하고 15개월이 지나 적절한 때(?)에 퇴사할 수 있었다.

## 스타트업으로 오기까지

그럼 퇴사를 하고 스타트업으로 오기 전까지 난 무엇을 했는가? 퇴사하기 전 다음 행보를 밟기 위해 필요한 것이 무엇인지 정리할 필요가 있었다. 그래서 아래와 같은 목록이 나왔다.

- 국제적 커리어를 위해 세계를 좀 더 직접적으로 경험해볼 필요가 있다.
- 당연히 이를 위해 영어가 더 세련될 필요가 있다.
- 관심을 쏟기 시작한 Web Development를 위해 React.js와 같은 기술을 공부하고 이것으로 개발해 볼 필요가 있다.
- 이력서를 국문/영문으로 각기 다른 버전으로 잘 다듬을 필요가 있다.

1번을 위해 호주에 가기로 결정했다. 캐나다는 교환학생때 경험했고 때마침 친한 친구가 Gold Coast 부근에서 대학교 졸업을 앞두고 있었다. 그래서 오랜 친구를 만날 겸, 친구에게 호주 전반과 이민에 대한 이야기도 들을 겸, 직접 호주 IT 회사들을 살펴보고 문화를 경험해볼 겸, 다시 한번 방향 설정을 견고히 할 겸, 그간 못본 책을 마음 껏 볼 겸 그렇게 호주로 떠나 8주 넘게 지냈다.

![2016 kogarah airbnb australia](/images/kogarah.jpg)
![2016 opera house australia](/images/opera.jpg)
![2016 opera house cafe australia](/images/opera-cafe.jpg)

완벽한 시간이었다. 호주에서도 개발을 했고 책을 읽고 글을 썼다. 호주에도 IT 회사가 꽤 많고 Software Engineer가 꽤 괜찮은 것 같았다. 호주에서 캐나다 친구를 사귀게 되었는데 그 또한 Software Engineer였고 캐나다와 호주의 IT에 대해 많은 이야기를 나누었다. 그렇게 해외의 IT 업계에 대해서 조금씩 감을 잡기 시작했다.

늦은 겨울, 귀국을 하고나서 본격적으로 React.js, Webpack, Redux, Node.js로 Web app을 만드는 프로젝트 두개를 만들어 멤버를 모집하고 시작했다. 영어는 TIME이나 논문을 읽고 쓰는데는 편했지만 네이티브와 자연스럽게 듣고 말하는 데는 한계가 있어 회화 스터디를 시작했다. 그 무렵이 12월 말이었고 그렇게 넉달을 보냈다. 춥고 꽤나 고단스러운 시간이었으나 무엇보다 재밌었기 때문에 꾸준히 할 수 있었다. 이후 2주에 걸쳐 이력서를 다듬었고 여러 스타트업에 Wanted를 통해 지원하기 시작했다. 몇몇 한국 스타트업과 미국계 스타트업의 면접을 거치면서 어떤 회사에 가고 싶은지가 점점 명확해졌다. 미국계 스타트업은 면접을 영어로 5시간을 해서 실신할 뻔 했다.. 그렇게 d.code라는 앱을 서비스하고 있는 지금의 회사로 오게 되었고 좋은 배움의 나날들을 보내고 있다.

여기까지가 지난 2년간 SK에서 배운 것들과 스타트업으로 오기까지의 여정이다. 지금 또한 추상적 목표에 따라 끊임없이 방향 설정을 하고 재밌게 개발 공부를 하고 있다. 이제 스물일곱, 앞으로 어떻게 삶이 펼쳐질지는 어느것도 예측할 수 없지만 적어도 새로움을 추구하고 끊임없이 도전하고 공부하는 이 방향 아래에서만 나아간다면 행복하고 성장하는 삶을 살 수 있지 않을까 싶다.


SK에서 나는 무엇을 배웠나

# 무례란 무엇인가

최근에 페이스북을 보다가 예의없는 사람에 대해 쓴 글을 보게 되었는데 간결하고, 관점이 재밌고 무엇보다 무릎을 치게 되는 시원함이 있어 그 글을 공유하고 내 생각을 얹어 글을 조금 확장해보고자 한다. 근래에 정의란 무엇인가(Michael Sandel), 죽음이란 무엇인가(Shelly Kagan), 국가란 무엇인가(유시민) 등 '~란 무엇인가' 류의 책을 많이 읽어 제목을 따라해봤다(..).

아래는 신상철님의 글이다.

> https://www.facebook.com/shinestory/posts/1279056888889466

결론은 딱 11자다. 예의 없는 사람은 멍청하다.

27년 밖에 살지 않은 내 인생에서도 별의별 이상한(..) 사람, 예의 없는 사람, 눈에 뻔히 보이게 남을 이용하려는 사람, 상대를 없는 사람 취급하는 사람 등 갖가지 종류의 사람들을 봐왔다. 내가 직접 겪은 것도 있고 목격한 것도 있다. 글 쓰면서 주마등처럼 그때의 기억들이 스쳐지나가고 있다. 지금 회사 입사 전에 했던 면접도 떠오르고 전 직장 사람들도 떠오른다. 후후.. 열이 오르네. 다 사람구실 하면서 살고는 있으려나 그게 제일 궁금하다.

거두절미 하고, 내심 어떻게 저런 인간들(?)이 세상에 존재하는가에 대해서 누군가 설명해주길 바랐다. '저런 사람들은 이러한 환경적, 문화적, 개인적, 사회적 요인에 의해 그런 사고방식과 행동양식을 갖게 되었으리라~' 식의 해석이 필요했다. 그래야만 편안하고 안정된 마음으로(...) 앞으로도 있을 이런 상황에 잘 대처할 수 있을 것 같았다. 그런데 11자라니! 단지 멍청한 거였어?.. 단순히 정신승리적인 통쾌함 뿐만 아니라 간결하고 똑 부러지는 논리가 뒷받침하고 있기에 난 드디어 해석이라 할만한 걸 얻게 되었다. 그래서 이왕 이렇게 예의 없는 사람에 대해 논리적 해석을 득하게 된거 한번 더 깊게 생각해 보기로 했다. 지능과 정서 개념에서부터 시작해보자. 단순히 예의 없음은 지적 능력의 결함이 아닌 나쁜 정서에서 나올 수 있다고 생각할 수 있기 때문!

분류하기 좋아하는 인류는 자연을 분해하고 분석하다가 언제부터인가 스스로를 이해하고자 자신을 분해하기 시작했다. 그래서 초기 심리학의 고군분투로 탄생한 것 중 하나가 인지능력과 정서의 분리이다. 상황에 따라 시시각각 변하는 정서를 학문의 범주로 끼워맞출 수 없었기 때문이다. 인간 마음에 대한 과학적 분석의 시도이므로 폄하할 생각도, 폄하할 위치도 아니지만 분리할 수 없는 걸 분리하려고 시도했다고 생각한다. 그 시도의 여파로 정말 우리 마음 어딘가에는 지능과 정서가 따로 움직인다고 생각하게 되는 부분이 많다. 이걸 정말 분리할 수 있을까? 세상과 사람에 대해 좋은 마음 혹은 나쁜 마음을 갖게 되는 것이 인지능력과 정말 서로 독립적일까?

단순한 예를 들어보자. 주어진 정보를 잘 분석하고, 편재되어 있는 정보들 사이에서 흐름과 패턴을 객관성있게 잘 읽어내는 사람이 있다고 하자. 이런 사람은 주변에 일어나는 일들, 사람들, 나아가 사회가 어떻게 작동하고 흘러가는지를 마냥 지켜보고 흘려보내지 않을 것이다. 인간은 언제나 자신에게 주어진 상황에 대해 합리적인 해석을 해야하는 존재이기 때문이다. 이 사람은 상황을 잘 주시하고 있고 또 어느정도 이해도 하고 있다. 반대로 정보들 사이의 관계성과 흐름을 판단하지 못한다면, 다른 말로 인지능력이 부족하다면 전체를 보지 못해 객관성이 떨어지게 된다. 즉, 편견이 여러 부분에서 점점 심해지게 되고 이를 두고 '편협'하다고 한다. 이게 대체 무슨 말인가? 이걸 현실의 예로 치환해보자. 근처의 사람만 봐도 객관성이 두드러지는 사람과 편협한 사람이 각각 어떻게 행동하는지 보이지 않는가? 편견이 심한 사람일 수록 어떤 사람을 대할 때에도 그 차이가 심해진다. 이런 사람은 어떤 사람이든 비슷하게 대할 수 없기 때문이다. 사람을 대하는데에도 정보 분석이 동반된다. 가령, 이 사람은 어떤 사람인가, 무엇을 하는 사람인가, 어디 출신인가, 말하는 습관이 어떠한가, 어떤 옷을 입는가, 최근 무슨 일을 겪었는가 등등 사람에 따라 누군가를 대하기에 앞서 자신의 가치관을 바탕으로 수 많은 정보 분석과 가치 판단이 선행된다. 그래서 위의 편협한 사람은 객관적 분석 능력이 부족한 것이고 - 한쪽으로 치우쳐 생각하게 되는 경향이 심하고 - 누군가를 대할 때에도 합리적으로 대할 줄을 모르고 - 인지능력이 뒤떨어지는 것이다. 지금 대쉬(-)로 표현한 구절은 논리적으로 거의 동등한 것들이다. 그래서 이를 한마디로 바꿔 말하면, 편협은 인지능력의 결함으로 설명해낼 수 있다.

나 또한 이렇게 설명해놓고 보니 이 이론이 꽤나 설명할 수 있는 부분이 많은 것 같다. 신기한걸..? 여기까지 써놓고 보니 인지능력의 부조화가 심한 환자들이 편협성이 커지고 사회성이 급격히 후퇴한다는 내용의 책도 떠오른다. 그렇다. 편견이 심한 것은 인지능력이 뒤떨어지거나 의식적으로 정보를 선택적으로 받아들인다는 것이다! 벌써 많은 정치인들이 떠오르는 것은 기분 탓만은 아닐 것이다(..).

다시 지능과 정서의 분리로 돌아와, 따라서 이 둘은 분리할 수도 없고 분리되어 있지도 않다. 다만 분리해서 생각은 해볼 수 있다. 분리하여 심리학적으로 논지를 전개해 나갈 수는 있다. 그런데 딱 거기까지다. 인간 정신에 대한 설명과 해석의 한가지 관점을 추가시킨 것 뿐 그 이상도, 그 이하도 아니다. 이를 상철님의 글처럼 실생활에 적용해보면, 예의가 실종된 사람, 자신보다 경제적, 육체적, 정신적, 지적으로 약해보이는 사람을 얕잡아보는 사람, 나아가 무시하는 사람, 함부로 대하고 하대하는 사람, 이용하려는 사람, 속이려는 사람 등 이 모든 카테고리의 사람들(인간들이라 하고 싶다)은 결론적으로 멍청하거나 알고는 있지만 연유야 어찌 되었든 의식적으로 그렇게 행동하는 것이다. 어쨌거나 두가지 경우 모두 씁쓸하다..

그런데 여기서 혹자는 정말 철저하게 남을 속이고 이용하는 사람이 어쨌든 이득을 많이 보고 잘 살게 될 가능성이 크니까 더 똑똑한거 아니냐고 의구심을 품을 수 있다. 남을 쉽게 무시하고 할 말 못할 말 다 내뱉고 사는 사람이 마음 후련하게 사는 것이니 정신적으로도 더 편한 삶을 사는 것 아니냐고 반문할 수 있다. 아니다. 그런 사람들은 시야가 좁은 것이고 편협한 것이다. 단기적으로 보면 맞을 수 있지만 결국 멀리 보면 그 방식은 실패한다. 행복한 삶도 아니다. 이제까지의 역사가 보여주듯 그런 사람들의 거의 전부는 말로가 좋지 못하다. 멍청하다는 거다. 멀리 보는 것도 지적 능력이다. 멍청하든 의도적으로 그렇게 살든 이래나 저래나 피곤한 삶이고 사랑받는 삶도 아니다. 별로 추천(?)하고 싶지 않은 방식이다..

위의 경우들을 수도 없이 본 선대의 사람들이 이것을 대상화시킨 개념이 바로 도덕과 윤리이다. 이 개념들이 괜히 나온게 아니다. 도덕이란 개념이 역사적으로 어떻게 구성되었는지를 찾아보면 상당 부분 이런 내용이다. '그냥 사람 좋게 사는게 좋은거지 암~' 이러고 나온 개념이 아니란 거다. 그래서 타고난다고 생각했던 이 인성 혹은 도덕성을 '교육'하는 것이다. 마음의 태도와 인성 모두 지적 능력이라는 말이다. 좋은 마음과 예의 바름이 인생의 마지막까지 미칠 영향을 수도 없이 보고 집대성한 이 윤리를 그렇게 주변에서 보고 듣고 학교에서, 가정에서 교육받았음에도 그 이치를 깨닫지 못해 예의없이 행동하고 쉽게 남을 얕잡아보는 것은 멍청하다고 밖에 설명할 수 없다. Edward Wilson의 On Human Nature와 Richard Dawkins의 The Selfish Gene이라는 책을 보면 동물 세계에서도 '처음엔 남에게 좋게 대하기, 나에게 잘해주면 그 상대에게 잘 대하기, 나에게 해를 끼치면 무시하거나 되갚아주기'라는 소위 호혜주의 혹은 Tit for tat 전략이 가장 장래있는 생존 전략이다. 이 전략을 따르지 않은 개체 혹은 종은 종족 번식에 어려움을 겪는다. 심지어 이 호혜주의가 유전적 형질로 생기게 되었다는 이론도 있다. 동물도 안다는 거다 예의가 가져올 좋은 영향을. 이쯤되면 예의 없는 사람은 편협하고 지적능력이 떨어질 뿐더러 동물만도 못한 사람이 된다(...). 그렇다고 미안해 할 필요는 없을 것 같다(!).

그래서 예의 없는 사람을 보면 어떡하란 말인가? 상철님의 말씀대로 무시하면 된다. 설득할 수도 없고, 싸울 수도 없고, 그렇다고 교화시킬 수도 없다. 그리고 그렇게 할 수 있다고 해도 거기에 들일 시간과 노력, 에너지가 너무 아깝다. 그래서 정중히(?) 무시하고 할 일을 묵묵히 하면 된다.

이제 마무리지을 때가 왔다. 주변에 쉽게 고함지르고, 무시하고, 남을 얕잡아보는 사람이 있는가? 멍청한 거니까 무시하면 된다. 물론 '예의있고 나이스'하게 무시해야 한다. 그래야 지적이니까. 이제 예의없는 사람을 깨끗이 무시할 이론적 토대가 구색을 갖추었으니 실컷 무시하고 다니자. 아 정리가 잘 된 느낌이다!


무례란 무엇인가

# 나는 주체적으로 살고 있는 걸까?

요새 김정운 작가의 '가끔은 격하게 외로워야 한다'를 읽고 있는데 한 단락이 중요하게 다가와서 읽다말고 전부터 생각하던 걸 정리하는 시간을 가졌다.

항상 고민이 된다. 지금 내가 진짜 원해서 이러고 살고 있는 것인지, 아니면 타율성이 한톨이라도 섞여 남의 기준에 조금이라도 맞추기 위해 이러고 있는 것인지 분간이 가지 않을 때가 있다. 적어도 우린 사회에 살고 있으니 타인의 영향 아래 있는 것은 그렇다 치지만 내가 원한다고 생각해왔던 것이, 사실은 부모님과 주변 사람들이 원했던 것이라는 것을 깨달은 순간엔 그렇게 무서울 수 없었다. 그래서 병적으로 스스로를 돌아보는 시간을 자주 갖고 메타인지를 발휘해보려 발버둥친다. 그러다 읽던 책에서 이 문제의 핵심을 찌르는 문장이 나와 관심이 가지 않을 수 없었다.

아래가 그 단락이다.

> 월급쟁이 생활을 때려치우기만 하면 바로 내 삶의 주인이 될 거라고 생각한다면 정말 큰 착각이다. 평생 추구해야 할 공부의 목표가 없음을 돈의 문제로 환원시키며 자신의 쫓기는 삶을 정당화하는 것 또한 참으로 비겁하다. 삶의 마지막 순간까지 놓치지 않을 관심의 대상과 목표가 있어야 주체적 삶이다. 우리가 젊어서 했던 '남의 돈 따먹기 위한 공부'는 진짜 공부가 아니다. </br></br>- 김정운의 '가끔은 격하게 외로워야 한다' 중에서 -

약 7년전, 처음 철학 공부를 시작했을 때 다행히 내가 처음 그렸던 평생동안 할 공부의 밑그림은 나의 죽음을 기준으로 작성되었다. 보통 앞으로 무얼 하며 살아야할지 고민한다거나 1년 혹은 길어야 3년짜리 계획을 세울때의 기준은 '지금'이다. 그래서 하고자 했던 일이 끝나고 세운 계획의 막바지에 이르면 항상 다음의 목표는 상실된다. 그때가서 또 다음에 무얼할지 생각하게 된다. 세운 계획은 딱 그 기간만큼을 상정해놓고 만들었기 때문이다. 10년짜리 혹은 더 긴 계획을 세워도 그 기간이 끝나면 다음에 무얼할지 모르는 것은 매한가지다.

고맙고 재밌는 것은, 철학적 사유는 내가 계획을 만들거나 계획을 만드는 행위를 하기 전에 그것에 대해서 추상적 사고를 하게 만들어준다. 다른 말로는 메타인지를 갖게 해준다. 그래서 그 계획이 왜 내게 필요하고, 그게 내 인생과 정체성에 어떤 의미를 부여하고, 그것이 끝났을 때 내가 어떤 감정을 느끼고, 다음엔 무엇을 해야할지에 대해서 파악하게끔 만든다. 이렇게 '지금'의 기준말고 보다 '전체'의 기준으로 사고하고 행동하다보면 한가지 사실에 다가가게 된다. 그것은 인생에 관한 모든 계획은(아무리 사소한 것일지라도) 죽음을 기준으로 세워져야 자연스럽다는 것이다.

어떻게 그럴까? 앞서 말했듯이 지금을 기준으로 계획을 세우면 그것이 달성되었을 때 필연적으로 다음의 것에 대해 생각해야만 한다. 그거 안세우면 '방황' 혹은 '휴식'이다. 그런데 죽음의 순간에 내가 어떤 존재로 기억되고 싶은지, 세상에 어떤 기여를 한 사람으로 남고 싶은지, 가족과 친구, 주변 사람들에게 어떤 사람이고 싶은지, 궁극적으로 어떤 종류의 즐거움을 추구하고 싶은지 등, 마지막 상(image)에 대해 정의를 해놓으면 폭포수처럼 거꾸로 거슬러 생각할 수 있다. 이렇게 해놓으면 하나의 계획 혹은 목표를 달성했을 때 다음 목표를 걱정하거나 세우기 위해 방황하지 않아도 된다.

위에서 언급한 것을 예로 들면, 가족과 친구, 주변 사람들에게 '어떤' 사람으로 기억되고 싶은지를 정의하는 것은 나의 인간적인 면에 대해 정의하는 것이다. 그 '어떤'이 되기 위해 오늘 가족과 주변 사람들에게 어떻게 대해야할지 벌써 대충의 밑그림이 그려지고 이것을 바탕으로 짧고 긴 '인간적 면모에 관한' 계획을 세울 수 있다. 이 계획들의 중간중간에 카네기의 '인간관계론'을 읽는 것이 포함될 수도 있고 오늘 당장 친구에게 어떻게 대하고 어떤 감정과 마음을 전달할지에 대해서도 미리 생각해볼 수 있다.

또 다른 예로, 세상에 작더라도 어떤 기여를 한 사람으로 남고싶은지에 대해 정의한다면 그것은 아마 나의 커리어에 관해 정의하는 일일 것이다. 나의 경우엔 이 질문에 대한 대답(정의)은 '대단하진 않더라도 사람들이 재미를 느끼거나 기존에 불편했던 것들을 편리하게 만들고자 노력했던 사람으로 남는 것'이다. 그래서 이 인생 전체에 걸친 목표에 다다르기 위한 수단으로서 프로그래밍이라는 것을 택했다. 이걸 세운 것이 2013년이고 3년 반이 지난 지금도 이걸 재밌고 제대로 해보기 위해서 혼자 공부하거나 프로젝트 팀을 만들거나 퇴사하고 새 회사로 옮기는 등 여러 방면으로 진행하고 있다. 그리고 중요한 것은 지금껏 열몇개의 계획들이 있었지만 한번도 방황하게 된 경우는 없었다. 물론 인생 굴곡의 높낮이, 즉 원하는 것을 얻고 못얻고의 차이는 존재했지만 그 방향성 자체에는 틀어짐이 없었다.

이처럼 인생을 살고, 이에 대해 계획하는 것의 본질에는 마지막에 대해 정의하는 것이 포함되어 있다. 한가지 중요한 것은 이 죽음을 기준으로 한 마지막 상은 추상적이어야 하고 추상적일 수 밖에 없다는 점이다. 예를 들어, 200억 정도의 재산을 가진 부자로 살다가고 싶다라고 마지막을 정의하면 필연적으로 그걸 계획한 현재에는 그 수치에 따라 움직이게 되고 부서지기도 쉽다. 가령, 지금 스무살인데 70년뒤쯤 죽을 것 같으니 200억을 그 나이에 맞춰 나눠 계산하면 현재 얼마를 벌어야하는지에 대해 나오게 되는데 그것이 타산에 맞지 않으면 불가피하게 계획을 수정해야만 한다. 그리고 삶은 불확실성의 연속이므로 자신이 70년뒤에 죽을지, 내일 죽을지 알 길이 없어 계획은 무너지기 쉽다. 그러나 추상적으로 세운다면 그 계획은 그걸 이루기 위한 수 많은 구체적인 하위 계획으로 구성될 수 있고, 중간중간 어떤 일이 일어나는 등의 이변이 생기더라도 쉽게 유기적으로 하위 계획들을 조정해 마지막 추상적인 계획을 유지할 수 있다.

다시 맨 위의 김정운 작가의 글로 돌아와, 이 부분을 읽으며 위의 생각들이 떠올랐다. 마지막에 대해 생각하지 못한 사람들은 현재에 함몰되어 살기 때문에 현재 자신의 삶이 이렇게 된데에 대한 원인 파악을 하기 어렵고 더 나은 상태로 도약하기 위한 next move를 꾀하기도 어렵다. 비유하자면 근시안적이라고 할 수 있고 그런 시야를 갖고 있기에 현실에서 도피해도 주체적 삶을 살기가 어렵다. 삶의 마지막 순간까지 놓치지 않을 관심의 대상과 목표가 있어야 주체적 삶이라는 대목은 그래서 매우 공감하는 바이다. 내가 지금 하고 있는 공부가 근시안적인 목표를 위해 하는 것이 아닌, 마지막 상에 정의된 공부와 일치할 때, 내가 지금 다른 이들을 생각하고 대하는 방식이 매 순간의 감정과 생각을 바탕으로 하는 것이 아닌, 마지막 상에 정의된 내가 원하는 나의 인간적인 면모와 궤를 같이 할 때 비로소 그것이 진짜 주체적 삶일 것이고 evanescent한 우리네 삶이 끝날 때 마지막 날숨을 내뱉으며 '좋은 삶이었다'라고 말하며 삶을 마무리할 수 있을 것이라고 생각하며 글을 마친다.


나는 주체적으로 살고 있는 걸까?

# Jeff Bezos, founder of Amazon 그리고 삶

이 글은 조성문님의 [아마존(Amazon) 성공의 비결은 소비자 경험 개선을 위한 끊임없는 노력](https://sungmooncho.com/2011/05/16/amazon-2/) 포스팅에 영향을 받아 작성 했으며 발췌한 내용으로 시작합니다.

<iframe
  src="https://www.youtube.com/embed/vBmavNoChZc?version=3&amp;rel=1&amp;showsearch=0&amp;showinfo=1&amp;iv_load_policy=1&amp;fs=1&amp;hl=ko&amp;autohide=2&amp;wmode=transparent"
  allowfullscreen={true}
  sandbox="allow-scripts allow-same-origin allow-popups allow-presentation"
></iframe>

올해 47세의 아마존 CEO 제프 베조스, 2010년에 모교인 프린스턴 대학에서 졸업생을 대상으로 연설을 했다. 6분 25초 지점부터 그의 연설이 시작된다. 10살 때 할아버지에게 어떻게 해서 “It’s harder to be kind than clever (똑똑한 것보다 친절한 것이 더 어렵다)“는 원칙을 배우게 되었는지, 그리고 어떤 계기로 뉴욕의 잘 다니던 회사를 그만두고 아마존을 창업하게 되었는지, 어떤 기분으로 어려운 선택을 내렸는지 등을 설명한다. 연설 중 마지막 대목을 인용하며 이 글을 마친다.

> 와이프에게 아이디어를 이야기했습니다. 그녀는 하라고 했어요. 그래서 당시 내가 존경하던 상사에게 가서 이야기했습니다. 인터넷으로 책을 팔고 싶다구요. 센트럴 파크를 한참 걸으면서 주의 깊게 이야기를 듣던 그가 말했습니다. “That sounds like a really good idea, but would be even BETTER idea for someone who already didn’t have a good job. (그거 참 멋진 아이디어군, 근데 이미 좋은 직업이 없는 사람에게 더 좋은 아이디어일텐데..)” 그리고 48시간동안 생각해보라고 했습니다. 어려운 선택이었습니다. 그리고 결국 시도해보기로 했습니다. 시도조차 해보지 않는 것은 싫었습니다. 돌이켜보면, 열정을 따르기 위해 가장 안전하지 않은 선택을 한 셈이지만, 저는 그 선택이 자랑스럽습니다. (중략) 시간이 지나 당신이 80세가 되었다고 생각해보세요. 조용한 방에 혼자 있습니다. 자신의 인생 이야기를 혼자 이야기해본다고 생각해보세요. 가장 간결하고 의미있는 이야기는, 결국 당신이 했던 선택들을 나열하는 것일겁니다. **결국, 우리는 우리가 한 선택 그 자체입니다 (In the end, we are our choices).** </br></br>**자기 자신에게 멋진 이야기를 만들어주세요.** 감사합니다. 그리고 행운을 빕니다. (**Build yourself a great story.** Thank you, and good luck.)

가장 인상적인, 가장 뇌에 충격을 준 부분을 파란색으로 표시했다.

살면서 겪어온 경험들과 공부해온 지식은 내게 '인간이란 그리 단순하지 않은 존재' 라고 알려주었다. 이 글을 읽기 전까지만 해도 그랬다. 그런데 정작 생의 말미에 가면 우린 우리가 한 선택들의 단순한 나열 혹은 그 집합 자체라니. 단순한 배열 조차 거대한 의미를 가질 수 있다는 사실을 깨닫게 된 순간이었다.

생각해보면 나 자신을 포함한 모든 사람들의 경험과 행동, 생각, 선택들은 단순한 데이터의 집합으로 표현될 수 있다. 그런데 개개인의 사연을, 인생을 들여다보면 모든 것엔 크고 작은 의미가 깃들어 있다. 그곳에 모든 희로애락이 있다. 그만큼 인간은 고유한 존재다.

Bezos에게 Amazon은 그의 선택들의 나열이 만든 가장 큰 결과물 중의 하나일 것이다. 그리고 Amazon이 있기 전, 그는 선택들의 나열이 중대한 방향 전환을 맞게 할 중요한 선택 하나를 했다. 자신의 마음을, 열정을 따르기로 결정한 것이다. 그렇게 그는 자신에게 의미있는 선택을 했다. 남들이, 사회가 말하는 'risk'에 귀기울이지 않고 자신의 정체성을 살아있게 할 선택을 했다.

이런 멋진 이야기들을 여럿 접하면서 내게 요상한 이분법적인 질문이 하나 떠올랐다.

> "무미건조한 인생 그리고 흥미로운 인생, 둘 중 어떤 인생을 택할 것인가?"

어떤 인생을 살지는 전적으로 나의 선택에 달려있다고 생각한다. 그렇게 믿고 있다. 훗날, 선택에 방해가 되는 여러 문제들이나 상황에 핑계를 대가며 이렇게 살 수 밖에 없었다고 한숨섞인 말을 하기엔 단 한번의 인생은 너무나 소중하다. 그리고 시간은 자비없이 흐른다. 마음을 따르지 않은 선택을 하고 시간이 흐르면 그 뒤엔 후회만 남을 뿐이다. 즉, 냉철한 시간 앞에 나의 선택과 그 과정에서 나오는 결과만이 있을 뿐이다. 그 결과가 자신에게 의미가 있을지 없을지는 그 선택의 동기가 내부의 것인지(마음을 따랐는지) 혹은 외부의 것인지(타인, 사회의 훈수를 따랐는지)에 따라 결정될 터. 결국 인생을 바꾸고자 한다면 그 유일한 수단은 자신의 마음과 선택이다. 매일매일 어떤 선택을 얼마나 신중을 기해야 하는지 혹은 대충 하는지 뒤돌아 본다면 어느 정도 자신의 미래를 점칠 수 있지 않을까.

아직 위 질문에 답을 하지 않았다. 다시 물어본다. "난 어떤 인생을 살고 싶은가?" 힘들겠지만 후자를 택할 것이다. 단순히 wording만 보자면 혹자는 "아니 무슨 누군들 흥미로운 삶을 살고 싶지 않겠나?" 라고 물을 수 있지만 이면엔 사실 무서우리만치 냉정한 현실과 시간이 존재하고 있다. 진짜 흥미로운 인생을 택하지 않는다면, 대충 결정지은 선택들로 점철된 삶을 살고 있다면 삶의 끝으로 가면 갈 수록.. 단조로움만이 자리할 것이다. 물론 그런 삶이 꼭 나쁘다는 건 아니다!

그럼 흥미로운 삶을 살기 위해선 어떻게 해야 하는가? 여기엔 딱히 방법이랄 만한 것이 없다고 본다. 질문이 단순한 만큼 답변도 단순하다. 그저 나 자신이 긍정적이고 흥미로운 사람이어야 한다. 딱히 그렇지 않으면 그렇게 되길 추구해야 한다. 그것이 방법이라면 방법이다. 멋진 이야기들의 주인공들이 그랬던 것처럼 이런 삶을 살기 위해선 새로운 것을 생각하고, 새로운 상상을 하고, 새로운 일을 하고, 새로운 도전을 해야한다. 이렇게 새로운 나의 모습을 발견하고 이 모든 과정을 즐겨야 한다. 이때 변해가는 나 자신도 사랑해야 한다(나는 요새 어떤 새로운 생각을, 상상을, 도전을 하고 있는지 그리고 하려는지에 대해선 다른 글을 통해 다루려고 한다!).

Bezos의 일화와 연설을 본 뒤 Jobs의 말이 뒤섞이며 머릿속에 한 문장이 떠올랐다.

*새로운 경험과 일에 대한 선택들(dots)이 모여 Story를 만들고 논리적으로는 설명할 수 없는, 그런 관련없어 보이는 선택의 배열이 우리의 인생을 점점 더 흥미로운 인생으로 바꾸어 놓을 것이다.*
