[webpack v4] 1. 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 해보자

이 포스트에 관련된 코드는

https://github.com/brightparagon/webpack-conquer/tree/getting-started

에서 확인해볼 수 있습니다. 작은 예제부터 모두 실행해보며 학습해보고 싶으신 분은 위 링크에서 레파지토리를 fork 하거나 zip 파일을 다운로드해서 활용해보세요.

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

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

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

carbon
앞으로 계속 고생해줄 우리의 index.html
carbon (2)
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을 설치해보자.

carbon (4)

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

carbon (5)
package.json

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

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

carbon (6)
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가 된다. 이제 번들을 해볼 차례다. 아래 명령어를 실행해보자.

carbon (7).png

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

스크린샷 2018-02-22 오후 11.21.54
디렉토리 구조

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

스크린샷 2018-02-22 오후 11.25.37.png

정상적으로 동작하는 것을 확인할 수 있다!

웹에서의 module과 webpack의 역할

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

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

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

carbon (8)
app.js와 bar.js

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

스크린샷 2018-02-23 오전 12.02.56.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를 지원하는 플러그인을 사용할 수도 있다. 걸작이다. 근데 이 모든 것을 사용하려면 많이, 아주 많이 복잡하다. 그래서 요새 많이 parcel로 넘어가는 듯 하지만.. 필자는 webpack이 더 프로덕트 친화적이라 생각해 webpack에 잔류할 생각이다.. 앞으로 연재할 webpack 포스트들에서 이런 멋진 기능들을 예제로 직접 만들어보면서 사용해보도록 하자.

이 포스트에 관련된 코드는

https://github.com/brightparagon/webpack-conquer/tree/getting-started

에서 확인해볼 수 있습니다. 작은 예제부터 모두 실행해보며 학습해보고 싶으신 분은 위 링크에서 레파지토리를 fork 하거나 zip 파일을 다운로드해서 활용해보세요.

Advertisements

SK에서 난 무엇을 배웠나

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

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

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

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개월이 지나 적절한 때(?)에 퇴사할 수 있었다.

스타트업으로 오기까지

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

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

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

IMG_3044UNADJUSTEDNONRAW_thumb_1553UNADJUSTEDNONRAW_thumb_1536

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

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

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