이미지1

2017년 회고를 한 것이 엊그제 같은데, 작년에 이어 올해도 어김없이 회고를 작성하려 합니다.

1 :: 이직 준비를 하면서.

2018년 초의 상황은 이전 회사가 경영난으로 인해 역사의 뒤안길로 사라지고 백수의 상태에서 휴식을 조금 취하면서 이직 준비를 하는 상황이었습니다. 스타트업으로써는 하루하루 앞길을 알 수 없는 것이 당연하지만 (자본이 많다면 예외) 직접 스타트업이 망하는 것을 경험하니 정말 오묘한 기분이 들었습니다. 그러면서 회사가 한 치 앞을 예상하지 못하는 상황에서 너무나 여유롭게 개발을 했던 자신을 되돌아보면서 여러 가지 생각을 했던 것 같습니다.

1.1 :: 소박한 이직의 꿈

게임 쪽에서 서비스 개발 회사로 첫 이직을 하면서 망한 회사인 만큼 깨달은 점이 많았습니다.
그 깨달은 점을 정리하면서 다음 이직할 회사는 이러면 좋겠다. 하는 바람을 정리해보았습니다.

1.1.1 :: 지분보다 월급을 많이 주는 회사로 가자

언제 망할지 모르는 스타트업 생태계에서 지분을 주는 대신 월급을 어느 정도 삭감하고 들어가는 경우가 있습니다.
제가 다녔던 회사에 들어갈 때 지분을 받고 어느 정도 급여에 대해서 낮추는 계약 조건이 있었습니다.
하지만 결국 종이쪼가리에 불과했습니다.

또한, 적은 금액을 받으니 회사 다니면서 생활이 정상적으로 영위되지 않았습니다. 저는 모아둔 적금을 써야 했고 이는 부업을 하자라는 결과로 이어졌습니다.
그렇게 천천히, 회사 일에 대한 동기부여는 사라지면서 자연스럽게 회사 분위기는 좋아지지 않았습니다.

당연한 이야기지만 회사보다 중요한 것은 자기 자신입니다. 회사가 잘 되는 것도 결국엔 나 자신의 성장을 위한 수단일 뿐입니다.

1.1.2 :: 내부 스터디가 많은 회사였으면..

회사 내부 스터디가 활발할수록 많은 것들을 경험할 수 있다고 생각했습니다.
그래서 다음 회사는 스터디가 활발할 회사였으면 좋겠다고 생각했습니다.

전 회사에서는 스터디를 하려고 하는 사람이 없었고 배우려는 열망 혹은 열정이 없는 상태였습니다.
그래서 회사 분위기가 스터디를 기본적으로 열심히 한다면 개발을 할 때도 열정 있는 개발을 하는 사람들이 많을 것으로 생각했습니다.

1.1.3 :: 다양한 포지션의 경험을 했으면 좋겠다.

프론트엔드 뿐만이 아니라 백엔드 및 아이폰 어플리케이션 개발도 했으면 좋겠다고 생각했습니다.
왜냐하면, 스페셜리스트로 가는 길을 제너럴리스트를 거치지 않으면 갈 수 없다고 생각했기 때문입니다.
다방면의 경험을 하게 될수록 개발자는 프로덕트를 제작할 때 더 좋은 퀄리티를 낼 수 있다고 생각합니다.

1.1.4 :: 개발 시작 단계부터 서비스 운영 과정까지 경험을 해봤으면 좋겠다.

개발자들과 커뮤니케이션 해본 경험이 적은 저로서는 아이디어 회의를 통해 컨텐츠 기획을 하고 개발 회의를 통해 개발 방향을 잡는 것이 생소했습니다.
게임 업계에서 개발할 때는 아이디어 회의는 기획자들의 전통적인 영역이었고 해당 영역에 대해서 개발자가 터치할 수 없었기 때문입니다.
(드물게 하드웨어 스펙이 감당 되지 않을 때에는 캔슬) 그러므로 이러한 경험을 처음부터 할 수 있는 회사를 원했습니다.

1.2 :: 포트폴리오 준비

소박한 이직의 꿈을 안고 꿈을 실현 하기 위해 저 자신을 알릴 수 있는 포트폴리오를 작성했습니다.
간단하게 React.js를 사용해서 작성했습니다.

React로 만든 포트폴리오 페이지

웹 개발자로서는 처음으로 만든 웹 포트폴리오입니다.

해당 포트폴리오를 만드는데 약 일주일의 시간이 걸렸습니다.
어떻게 하면 예쁜 디자인을 할 수 있을까 고민하면서 디자인에 대해서만 일주일 중 90%를 고민했던 것 같습니다.

아쉬운 점은 모바일에 대해 지원은 하지 못한 프로젝트였습니다.
지금 생각해보면 모바일로 포트폴리오를 더 많이 볼 텐데 왜 모바일 지원을 하지 않았을까? 하는 생각이 들곤 합니다.

또한, 로켓펀치 프로필, 페이스북 프로필, 등등 프로필 작성에 열을 기울였습니다.

1.3 :: 회사 지원

회사 리서치를 하면서 내가 이 회사에 가면 많은 것들을 경험할 수 있겠다.라는 생각이 들었던 회사들을 정리했습니다.
정리하면서 동시에 지원하기도 했는데요. 보통의 회사들은 읽어보지도 않고 메일 답변을 해주지도 않았습니다.
(경력만 뽑으면 신입은 어디서 일하라는 말입니까!)

2개 회사에 지원했습니다.
그중에 1개는 연락이 오지 않았고 1개는 면접까지 보았습니다.

면접을 보기 전, 그 회사는 과제를 젓는데요. 과제가 이상형 월드컵을 만들어 오는 과제였습니다.

그래서 과제를 5일 동안 열심히 만들었습니다.

이상형 월드컵

이상형을 선택하여 마지막에 이상형을 선택한 트리를 볼 수 있게 제작하는 것이 과제였는데요.
되게 재밌는 과제여서 즐겁게 구현했던 것 같습니다.

해당 과제를 하면서 열심히 markdown 작성도 했습니다.
열심히 작성한 Markdown은 소스 레포지토리 에서 볼 수 있습니다.

그 후 과제를 전달하고 나서 얼마 후 면접 요청이 왔습니다. 하지만 많은 일이 겹쳐지고 있어서 시간에 쫓기는 탓에 제대로 면접 준비를 하지 못했습니다.
지금 생각해보면 면접 준비는 꼭 필수적으로 해야 하는 것 같습니다. 아무리 오랜 기간 개발한 개발자여도 면접 그날 기억이 나지 못할 수도 있기 때문입니다.

1.4 :: 면접에서 떨어지다.

면접을 보면서 안일했던 나머지 면접 질문에 대해서 준비를 많이 해가지 못했습니다.
그래서 불합격 통보가 떨어졌고, 불합격한 회사에서는 어떤 부분이 아쉬웠는지 정리해서 보내주었습니다.
훌륭한 회사였고 지금도 그 회사에 가면 훌륭한 개발자들과 같이 일할 수 있을 거라 긍정적으로 생각합니다.

다른 회사를 알아보고 있는 와중, 친하게 지내던 형에게 고민 상담을 했습니다.
이 형은 제가 서비스 업계로 발을 들이는 데 굉장히 많은 도움을 준 형이기에 당시 대다수의 고민을 털어놓았습니다.
그리고 얼마후, 자기 회사에 들어와서 아무것도 지금은 없지만, 처음부터 개발을 같이하면 어떻겠냐?라는 면접 제의를 했습니다.
흔쾌히 승낙 후 이번에는 꼭 성공해야지 하며 면접 준비에 박차를 가했습니다.

또한, 현재 회사의 CTO님과 개발자 형은 편안한 분위기를 만들어줬고 그 분위기에 편하게 면접을 볼 수 있었습니다.

2 :: 새로운 시작

2018년 2월 19일, 새로운 회사로 첫 입사를 했습니다.
지금 회사의 장점이 많이 있지만 그중에서도 4가지를 뽑자면,

  • 기획 단계부터 서비스 출시, 운영까지 경험할 수 있는 회사
  • 내부 스터티가 많은 회사
  • 프론트엔드 뿐만 아니라 다른 직무에 대해서도 일을 할 수 있는 회사
  • 개발팀이 매우 탄력적인 회사

개발팀 및 다른 부서의 직원분들도 좋으신 분들이시고 배울 점이 많았습니다.

2.1 :: 서비스 개발의 시작

회사의 서비스는 와인을 예약해서 이마트24 매장에서 받아볼 수 있는 서비스입니다.
저희 서비스의 랜딩페이지에서 확인하실 수 있습니다. 바로 가기 : 와인포인트

개발팀은 안드로이드 애플리케이션을 개발 진행 중에 있었습니다.
현재 단계에서 필요한 프론트엔드 니즈는 앱에서 보이는 데이터를 기획자님께서 쉽게 추가하고 수정할 수 있는 관리자 페이지를 제작하는 것이었습니다.

2.2 :: 프론트엔드 기술 스택의 고민

관리자 페이지를 제작하는 것이 당장 일이지만 앞으로 개발할 웹들을 살펴보기로 했습니다.
앱 설정을 할 수 있는 관리자 페이지, 창고와 점포에서 사용할 수 있는 페이지 총 2개의 프로젝트 개발이 필요했습니다.

이 2개의 프로젝트 개발 및 유지보수가 쉽도록 프론트엔드 기술 스택에 대해서 고민을 했습니다.

임시로 관리자 페이지가 만들어져 있던 것은 Vue.js로 SPA가 아닌 MPA 형태로 간단하게 제작되어 있었습니다.
언제까지나 임시로 관리자 페이지를 사용할 수는 없었기에 개발 속도가 빠른 프레임워크를 사용하는 것이 일차적인 생각이었습니다.

2.2.1 :: Node.js 환경의 프레임워크

수많은 javascript 라이브러리가 Node.js 환경에서 동작하고 있으며 오랜 기간 웹 시장에서 변동 없이 스크립트 언어로서 기능합니다.
오랫동안 수많은 이슈를 개발자들이 해결하고자 Node.js라는 환경도 등장하고 사용자들의 향상된 웹 경험을 위해 SPA라는 개념도 나오게 되었습니다.
그러면서 SPA에 특화된 프레임워크들이 나오기 시작했는데요. 예를 몇 개 들어보자면 Backbone.js, Angular.js, Polymer.js.. 가 있습니다.

우리 회사도 백오피스 사용에서 더 좋은 사용자 경험을 위해 SPA를 생각하게 되었고 많은 프레임워크들을 개발에 고려했습니다.
많은 프레임워크들의 좋은 점이 있지만, 우리 회사에서 사용해야겠다 라는 생각이 든 프레임워크는 React.js와 Vue.js 입니다.

2.2.2 :: React.js와 Vue.js

React.js와 Vue.js는 앞으로도 계속 뭐가 더 좋은가에 관해서 토론의 여지가 많은 프레임워크라고 생각합니다.
그런데도 React.js와 Vue.js가 지향하는 방향은 전혀 다릅니다.

2.2.2.1 :: React.js

  • jsx 파일 사용
  • inline CSS 적극 활용 (CSS in javascript)
  • 모든 컨트롤을 Javascript로 하겠다!
  • 공식 커뮤니티에서 React만 지원한다.

2.2.2.2 :: Vue.js

  • .vue (Single File Component) 파일 사용
  • 한 파일에서 HTML, CSS, Javascript를 분리하여 사용할 수 있음
  • 공식 커뮤니티에서 Vue, Vuex, Vue-router 등 지원

React와 Vue가 가고자 하는 방향은 다릅니다.
그래서 뭐가 더 좋으냐고 물어본다고 했을 때 더 좋은 프레임워크보다는 개발자의 취향 차이로 갈리는 것 같습니다.
HTML, CSS 보다 Javascript를 훨씬 더 많이 사용하고 싶은 개발자는 React.js를 사용할 거로 생각합니다.
반면 HTML, CSS 등을 적당히 활용하는 개발이 편한 개발자들은 Vue.js를 사용할 거라 생각하고요.

물론 개발자들이 선호하는 방향으로 선택할 수도 있겠지만, 해당 프레임워크의 모듈이나 편의성에 따라 팀에서 선택하는 게 달라질 수도 있습니다.

저는 React.js와 Vue.js를 사용할 때 가장 큰 선택 점을 State Manage Framework 에 중점을 두었습니다.
이는 처음 접하는 개발자들에게는 상당한 러닝 커브가 있기 때문입니다.

특히나 저희 개발팀은 개발자들이 소수이며 모두가 각자의 파트만 맡아서 하는 게 아닌, 일정이 급할 때 해당 파트로 들어가서 소스코드를 이해하고 작업을 해야 합니다.
그래서 러닝 커브는 우리 회사에서 1순위 고려대상이었습니다.

먼저 React.js 진영에서는 Redux 혹은 Mobx를 사용합니다.
Redux, Mobx는 숙련된 개발자라고 하더라도 빠른 이해가 쉽지 않습니다.
왜냐하면, Redux에도 saga, thunk 등등 파편화되어 선택에 힘들기 때문입니다.

하지만 Vue.js는 공식 레퍼런스에서 지원하는 Vuex가 있으며 Vuex는 매우 쉽게 개발할 수 있도록 개발이 되어 있습니다.
또한, 한글 도큐먼트도 100%로 제작이 되어 있으며 사용 자체도 React.js 진영의 State Manage Framework보다 쉬웠습니다.
특히 Vuex는 내부적으로 비동기 처리를 지원하기 때문에 아주 강력했습니다.
물론 Redux에서도 비동기 처리를 할 수 있지만 하기 위해서는 다른 모듈을 추가로 사용해야 했습니다.

많은 모듈을 사용하면 추가적인 공부가 필요하므로 저희 팀은 Vue.js를 사용하게 되었습니다.

2.2.3 :: Angular.js는 왜 생각하지 않았는가?

Angular.js를 사용하지 않은 이유는 다음과 같습니다.

  • 큰 커뮤니티의 질문 답변율 저조
  • 프론트엔드 프레임워크 점유율이 떨어지고 있음
  • 규모가 큰 프레임워크, 러닝 커브 곡선이 가파름
  • 타입스크립트 사용

가장 큰 이유는 규모가 큰 프레임워크, 러닝 커브 곡선이 가파르다는 점이었습니다.

우리 회사는 시작하는 스타트업으로써 어떤 일이 닥쳐도 유연하게 대처해야 했습니다.
또한, 커다란 규모의 앱을 하나 만드는 것 보다 여러 서비스를 빠르게 만드는 일이 중요했기 때문에 Angular.js를 선택하지 않았습니다.

그리고 Angular.js의 문제 중 하나라고 생각하는 점이 있었습니다.
버전업될 때마다 Angular.js의 문법이나 함수가 많이 바뀌는 작업이 몇 번 이루어졌기 때문에 선택하지 않은 것도 있습니다.

2.3 :: 개발 진행

저희 개발팀은 React.js보다 Vue.js를 선택했을 때의 이점이 많을 것 같아 Vue.js로 개발을 진행했습니다.
개발을 진행할 때 여러 가지 이슈가 있었습니다.

2.3.1 :: 개발 이슈

- 2.3.1.1 :: Nuxt.js 사용?

Nuxt.js는 Vue.js 애플리케이션을 만드는 프레임워크입니다.
동적 라우팅, 서버사이드 렌더링, 폴더 스트럭쳐 등의 세팅이 되어 있어서 첫 개발 시 길라잡이로 좋은 프레임워크 같았습니다.

하지만 저희 프로젝트가 요구하는 사항 중에 서버사이드 렌더링이 존재하지 않았습니다.
또한, 더 나은 사용자 경험을 필요로 하지 않았기 때문에 저희는 Nuxt.js의 폴더 스트럭쳐만 계승하여 가져오고 프로그램을 작성하였습니다.
(백오피스 개발, 사용자 관점에서 첫 로드가 바로 나와야 불편함을 호소하지 않기 때문에 서버사이드 렌더링을 사용하는 이유도 있음)

개인적인 생각이지만 프로그래머에게 정형화된 규제는 매우 중요하다고 생각합니다.
코딩으로 A라는 답에 접근하는 방법은 수만 가지가 있습니다.
그 수만 가지의 방법이 팀원들에게서 다르게 나타난다면 결국 엉망으로 코드가 작성될 것입니다.

그러므로 Nuxt.js 같은 프레임워크를 사용함으로써 강력한 규칙으로 개발을 시작하는 게 좋을 것으로 생각합니다.
또한, Nuxt.js의 구조는 정말 괜찮습니다. 수많은 Vue.js 프로덕트들이 Nuxt.js를 사용하고 있다는 것이 반증이라고 생각합니다.

- 2.3.1.2 :: 클라이언트와 API 서버

클라이언트와 API 서버를 분할을 어떻게 할 것인가에 대해 고민을 많이 했습니다.
저희 팀의 백 앤드는 Node.js 환경에서 돌아가는 Express.js 서버 프레임워크를 사용했기 때문에 javascript 언어를 사용했습니다.

이는 프론트앤드 개발자들을 위해서라고 개인적으로 생각했는데요.
프론트엔드 개발자들이 javascript에 익숙하니 express.js로 사용하는 게 좋겠다는 판단이 아니었을까 생각해봅니다.

그래서 관리자 API 서버는 Express.js 로 제작을 시작했습니다.
여기서, 관리자 클라이언트 프로젝트와 API 프로젝트를 레포지토리로 관리할 때 같은 프로젝트로 넣어야 할지 따로 해야할지 고민이 생겼습니다.

그때 당시의 생각은 어차피 웹을 호스팅 하는 서버가 필요했으므로 서버마다 API 프로젝트를 통합해서 제작해 놓았습니다.
하지만 지금의 생각은 다릅니다.

그 이유는 프로젝트 두 가지를 제작하면서 공통으로 겹치는 API 로직들이 많았습니다.
그래서 두 프로젝트를 왔다 갔다 하면서 소스코드를 복사 붙여넣기를 했습니다.
하지만 결과물이 비슷해서 차라리 이 소스들을 프로젝트 한 개에서 관리하는 게 좋을 것 같다는 생각이 들었습니다.

그래서 다음 작업으로는 API 프로젝트를 병합하는 작업을 진행할 예정입니다.

- 2.3.1.3 :: Vuex 적용

초기에 관리자 페이지는 Vuex는 정말 필요한 상황이 아니면 적용하지 않겠다는 생각 때문에 적용하지 않았습니다.
그 이유는 Vuex 의존도가 올라가는 소스코드를 작성하면 다음 작업할 주문 관리자 페이지에서 재사용하기가 쉽지 않을 것 같다는 판단이었습니다.

하지만 API 로직을 받을 때 서비스 로직에 대해 미들웨어로 기능하는 역할이 필요한 상황에 왔습니다.
백오피스에서 오가는 수많은 API 로직을 바로 컴포넌트 레이어에 작성을 하니 컴포넌트의 로직들이 깔끔하게 코딩이 되지 않았습니다.
그래서 자체적으로 미들웨어를 만들어서 넣어줫는데 모양새가 예쁘지 않았습니다. 또한, 미들웨어 작성에 시간을 들이기도 쉽지 않았습니다.

그래서 Vuex 도입을 생각했으며 미들웨어로서의 기능으로 도입을 시작했습니다.
아니나 다를까. Vuex를 적용하고 얼마 안 돼서 Vuex에 레거시 코드들이 쌓여가기 시작했습니다.
그래서 Vuex 의존도를 높이는 소스들을 자제하고 전역 컨트롤이 필요한 기능은 이벤트 버스로 매니저를 제작해서 만들었습니다.

지금도 고민하는 것은 과연 매니저에 싱글 톤을 붙여서 많이 사용하는 게 정답인가 하는 의문을 가지고 있습니다.
Vuex 적용 이슈의 결론은 Vuex를 사용할 때 정말 Vuex가 필요한지 여러 번 생각을 해봐야 하며 이 프로젝트에는 Vuex가 없으면 망한다 싶은 프로젝트에만 적용하는 것을 권장하는 것이 저의 생각입니다.

- 2.3.1.4 :: 세션 체크

로그인 세션 체크 처리에 대한 고민을 지금도 진행 중입니다.
세션 타임아웃이 지나면 로그인을 풀어야 하는데 이를 30분에 한 번씩 setTimeout 구문으로 작성하는 것이 좋은 작업인가? 하는 생각이 들었습니다.

좀 더 효율적인 처리가 없을까 해서 고민을 거듭한 결과, Vue.js의 Life cycle hook에서 어떤 작업이 생기면 로그아웃되도록 처리를 했습니다.

이렇게 작업을 했더니 긍정적인 점은 세션 컨트롤을 이벤트 시에 처리를 할 수 있었습니다.
그래서 세션 로그아웃이 되는 것을 쉽게 컴포넌트에서 조절할 수 있었고 현재 작업 중인 데이터를 저장할 수 있었습니다.

이 처리가 맞는 처리인지는 잘 모르겠으나, 더 좋은 처리는 어떻게 해야 할 지 더 좋은 코딩 방법을 모색 중입니다.

- 2.3.1.5 :: Typescript 적용 이슈

Typescript가 협업하거나 큰 규모의 작업을 할 때 선택이 아닌 필수라는 것을 알게 되었습니다.
개발 초기에는 javascript로 별문제 없이 코딩하였습니다.
하지만 점차 개발을 진행하면서 변수 이름에 의존적인 코딩 방법 및 데이터가 다른 타입으로 들어갔을 때의 에러 탐지가 매우 어렵다는 것을 알게 되었습니다.

첫 번째 :: 생산성 문제

자바스크립트에서는 데이터를 넘길 때 데이터 타입이 보장이 안됨으로써 데이터가 지나가는 부분에 모델의 정보를 일일이 타자 해주어야 했습니다.
대다수 프로젝트는 client - vuex - server flow를 거쳐 서버에 데이터를 전달합니다.
100줄이나 되는 모델이 client, vuex, server에 각각 로직이 있다고 생각해보면 끔찍하지 않을 수 없습니다.

물론 이러한 문제를 조금이나마 해결하기 위해 ES6 destructuring assignment를 사용할 수 있습니다.
하지만 destructuring을 사용해도 소스가 길어지는 것은 똑같습니다.

문제를 해결하기 위해 확실하게 모델의 타입을 구분하여 전달한다면 이러한 생산성의 문제에서 조금 자유 로울 수 있습니다.
그러므로 자바스크립트의 동적 타입에서 타입스크립트의 정적 타입으로 사용 해야 한다는 생각이 들었습니다.

두 번째 :: 에러 탐지의 어려움

마크업 단계에서 데이터 전달을 할 때 잘못된 데이터를 전달했을 경우 (타입이 다른) 런타임 로그에 의존해서 에러 상황을 체크 하게 됩니다.

이는 Vue.js에서 더욱 주목받는 문제 입니다.
Vue.js에서는 에러가 나오더라도 마크업 단계에서 데이터 전달 시 타입 체크가 어렵기 때문 입니다.
마크업 코드가 커질수록 제대로 데이터가 전달되는지 혹은 값에 여러 가지 타입이 들어갈 때 런타임 로그에 의존하여 어떤 문제가 있는지 판단하는 것은 매우 어렵습니다.

저희 프론트엔드 팀은 Typescript를 적용해야 한다는 것에 대해서 별다른 이견이 없었지만 UI 레이어에는 Typescript를 적용하지 않기 로 하였습니다.
그 이유는 Typescript가 방해되는 경우가 있으며 Vue의 경우 아직 Typescript 지원을 100% 하지 못하기 때문 입니다.
특히, HTML Element 요소를 변경하거나 가져와야 하는 상황에서는 Typescript가 좋지 못할 수 도 있습니다.

하지만 Vuex같은 Storage 영역은 Typescript를 적용해야 합니다.
수많은 상태를 관리해야 하는 Storage 입장에서는 State의 명세를 가지고 있는 model의 역할도 하는 것이 분명합니다.
그러므로 다른 레이어로 데이터를 전달하거나 받을 때 Type가 명확해야 에러율도 줄고 탐지도 빨라질 것입니다.

3 :: 활동

2018년에는 회사 외부의 개인 활동도 진행 하였습니다.

회사에 취업한 상반기에는 공부 및 회사 생활에 익숙해지기 위해서 많은 활동을 하진 못했습니다.
그래서, 하반기에는 상반기에 못했던 외부 활동을 진행했습니다.

3.1 :: 과외

2018년은 제게 과외의 해라고도 볼 수 있습니다.
대학생들을 기준으로 과외를 진행하였으며 과외의 범위는 기초적인 언어부터 알고리즘까지 다양했습니다.

3.1.1 :: 동갑내기 대학생 과외

어느 날 친구가 제게 프로그래밍 과외를 하지 않겠느냐고 물어보았습니다.
그래서 마침 소일거리가 필요했던 저는 흔쾌히 동의하고 친구는 과외를 받을 친구에게 연락해본다고 하였습니다.

그리고 며칠 후 친구는 자신의 대학교 친구인데 열심히 하려고 하는 친구가 있다며 소개를 해주었습니다.
그래서 만나서 이야기를 나눠보니, 그 친구는 열심히 공부하고 싶지만 혼자 공부하는 방법이 익숙하지 않았고 대학에서의 공부로는 충족이 안 된다 라는 이야기를 했습니다.

이러한 이야기를 듣고 커리큘럼을 혼자 공부할 수 있는 시간을 강제적으로도 많이 가질 수 있게 커리큘럼을 제작했습니다.
학습 진도는 C/C++, 자료구조, 디자인패턴 등 기본적으로 개발자로서 알아야 할 것들을 잡았습니다.

제가 생각하기에 가장 효과적인 교육 방법은 게임을 제작하는 것으로 생각합니다.
C/C++, 자료구조와 디자인패턴 등을 효과적으로 알기 쉽게 하도록 과제와 목표를 게임으로 설정했습니다.
게임으로 설정하니 쉽게 이해가 가능했고 재미를 느껴서 열정이 빠르게 식지 않았습니다.

약 2개월간의 첫 번째 과외가 끝나며 식사를 같이하면서 조언을 했습니다.
기본기를 공부하면서 곧 취업할 시기인데 어떤 직무를 하고 싶은지 천천히 생각해보는 게 좋을 것 같다.
멀티미디어 학부에서 컴퓨터 공학과로 전과 하는 게 좋을 것 같다.

등등 여러 가지 이야기를 해주었습니다.

그렇게 이 친구에게 이야기한 지 며칠 후 답변이 돌아왔습니다.
컴퓨터 공학과로 전과한다는 소식과 자신은 웹 개발을 하고 싶다는 생각을 정리해서 말해주었습니다.
그래서 웹 개발 과외가 필요하냐고 물어봤고 친구는 필요하다고 했고 과외를 진행했습니다.

그래서 프론트앤드 웹 개발 두 번째 과외를 시작했습니다.
이번에는 웹 개발을 하면서 AWS도 붙여보고, Express.js를 사용해서 서버를 만들어보는 과외였습니다.

진행하면서 실제 프로젝트를 꾸준히 만들어보면서 블로그에 포스팅을 많이 하라고 이야기를 했습니다.
그 후, 트위터를 모작하는 프로젝트를 완성했고 이는 이 친구의 포트폴리오로 잘 쓰이고 있습니다.

두 번의 과외를 통해, 이 친구는 혼자 공부하는 방법과 회사 입사를 할 수 있었고
꾸준히 블로그를 하라는 이야기와 함께 블로그 및 장난감 프로젝트를 꾸준히 하는 개발자로 변모하는 모습이 보기 좋았습니다.

이 친구의 블로그

교육 리스트

  • C/C++
  • 자료구조
  • 알고리즘
  • 코딩 컨벤션
  • HTML, CSS, Javascript
  • Node.js
  • Express.js
  • Vue.js
  • AWS

3.1.2 :: 고등학교 후배 과외 1

과외를 구하고 있을 때, 고등학교 후배가 과외 요청을 해왔습니다.
이 친구는 웹을 공부하고 싶어 했고 Node.js 기반의 웹 개발을 궁금해했습니다.

다만 이 친구는 배우다가 도중에 나오지 않아서… ㅠㅠ..

교육 리스트

  • HTML, CSS, Javascript
  • Node.js
  • Express.js

3.1.3 :: 고등학교 후배 과외 2

현재 진행하고 있는 과외입니다.
엄청나게 친한 고등학교 후배가 기본기 과외를 원해서 과외를 진행했습니다.

교육 리스트

  • C/C++
  • 컴퓨터의 역사
  • HTML, CSS, Javascript
  • 알고리즘
  • 자료구조

3.2 :: 스터디

사람의 성향마다 공부하는 방법이 다른 것 같습니다.
어떤 사람은 혼자 하는 것이 더 도움될 수 있고 어떤 사람은 여러 명이 모여서 하는 게 더 도움이 될 수 있습니다.

제 경우에는 사람들과 모여서 이야기를 하며 정리도 하고 의사소통을 하면서 일거양득을 취하는 방법을 많이 사용합니다.
그래서 스터디에 많이 가입하는 편이고 그만큼 실패하는 스터디도 있습니다.

작년 회고에서 2018년에는 많은 스터디에 참가하고 싶다고 했습니다.
2018년 한 해는 스터디로 풍족한 생활을 보낸 년도 인 것 같습니다.

3.2.1 :: Vue.js Study

Github Link

Vue.js를 좀 더 자세하게 공부하기 위해 가입한 스터디입니다.
다만 Vue.js 입문자들이 많아서 깊게 공부해보지는 못했고 사용법 중심으로 봤던 것 같습니다.

사용법만 익히면 도움이 되지 못할 것이라는 판단으로 안에 사용된 모듈들을 전부 훑어보기도 하고
내부 라이프 사이클의 구동 배경도 알아보았습니다.

이를 Vue.js 스터디에서 정리해서 발표했지만, 반응이 시큰둥했고 피드백이 없었어 별로 괜찮은 스터디는 아니었습니다.
그리고 기본적으로 HTML, CSS, Javascript에 대해 숙지가 되지 않은 개발자분도 계셔서 스터디 보다는 교육의 느낌이었습니다.

Vue.js Study를 하고 느낀 몇 가지 생각을 적어보자면.

  • Vue.js와 같은 프론트앤드 Framework 자체를 다루는 스터디는 별로 도움이 되지 않는다.
  • 스터디를 하려 할 때 아무나와 하면 안 되고, 적어도 기본 배경지식이 있어야 한다.
  • 실무자들과 스터디를 진행하자.
  • 기본기를 다루는 스터디를 하자.

3.2.2 :: Machine Leaning Study

회사에 들어오고 나서, 팀원들이 Machine Leaning에 대한 공부를 하고 있어서 저도 스터디에 끼게 되었습니다.

스터디 진행

스터디 진행 방식은 Andrew Ng의 Machine Leaning - Stanford Univ. 를 듣고 와서 진행합니다.
강좌를 듣고 와서 서로 정리 한 내용을 공유하는 것을 일주일의 화, 목마다 진행했습니다.

경험

기본적으로 머신러닝에 대한 이해가 없어서 따라가는 것도 힘들었지만
그런데 막상 들어오고 나니 수학 쪽이 제가 많이 약하다는 것을 깨달으며 강좌가 영어기 때문에 영어로 어느 정도 듣고 읽는 것이 되어야 했습니다.
하지만 제 영어는 미국의 초등학교 영어에 머물러있기 때문에 모르는 단어가 매우 많았습니다.

또한, 제 자신도 해당 스터디에 제대로 열정을 못 태운 것 같습니다.
이게 제 문제 중 하나인데요. 제가 흥미로 가지는 부분이 아니라면 손을 조금 놓아버리는 버릇이 있습니다.

2019년에는 머신러닝 스터디를 조금 더 열심히 할 수 있게 환경을 만들어 놓고, 영어 수학 학원에 다닐 것입니다.

진짜 영어 수학은 필수…
그래서 2월부터 영어 학원 수강 신청을 해놓았습니다.
또한, 리드해주시는 회사 CTO 님과 형에게 감사를 ㅠㅠ

3.2.3 :: Hardware(Assembly) Study

예전부터 하드웨어를 공부하려는 생각이 있었습니다.
하드웨어 공부를 해야겠다고 생각이 들던 때는 게임회사에서 일할 때였습니다.
게임은 하드웨어 성능에 많이 의존적이기 때문에 하드웨어 공부는 자연스럽게 성능 최적화와 맞닿아 있는 부분입니다.
또한, 주변에서도 하드웨어에 관련된 공부는 많이 할수록 그 위에 돌아가는 소프트웨어를 작성하는데 효과적이다 라는 이야기를 많이 들었습니다.

필요성을 인식하고 있었지만 서비스 쪽으로 이직하고 그러한 생각을 조금 덜 하고 있었습니다.
왜냐하면, 서비스쪽은 비교적 성능 관련돼서 이슈가 없었기 때문입니다.

그러던 어느 날, 회사의 CTO님께서 하드웨어는 공부하는 게 좋다고 이야기하시며 하드웨어 스터디가 시작이 되었습니다.

스터디 진행

TIVA C Series TM4C123G 런치패드에 어셈블리 언어를 이용해서 스터디를 진행합니다.
Shape the world 강좌를 이용해서 공부를 진행합니다.

경험

하지만 어느새 CTO님께서 매일 교육자료를 만드시고 그걸 다른 사람들이 청강하는 교육의 장으로 바뀌었습니다. (… 왠지 Vue Study를 하시는 기분일 것 같습니다)

이러한 기회가 흔치 않고 제게 너무나 도움이 되는 스터디이기 때문에 주말에 2시간 정도 따로 공부하고 있습니다.
다만 여태까지 어셈블리를 해본 적이 없어서 공부하는데 시간이 다소 걸리고 있습니다.

해당 스터디를 진행 및 공부하면서 알게 된 것들이 잔뜩 있습니다!

  • 레지스터의 역할과 내부 처리 과정
  • 스레드와 프로세스
  • 어셈블리 문법
  • 32비트 체계의 메모리
  • C언어에서 if, for문등이 어떻게 처리되는가?
  • MOSFET
  • System Bus (MMIO, DMA ..), FlashROM 등등.. 기본적인 버스의 구성
  • 등등..

어셈블리 공부를 하면서 새로운 세상이 있다는 것을 알게 되었습니다.
소프트웨어 제작뿐만 아니라 하드웨어도 바로바로 반응이 일어나고 실체를 만질 수 있어 개발이 재밌다는 것을 알았습니다.

여기서도 영어가 중요하다 를 깨달았습니다.. (영어 영어 영어)

3.2.4 :: Wine Study

제가 지금 회사에 왔을 때 회사에 소믈리에님이 계셨습니다.
소믈리에님은 제가 회사에 오기 전 CTO님과 개발자분에게 와인 앱을 만들기 위해 기본적인 와인 지식을 알려주기 위한 스터디를 진행하셨습니다.
그 이후에 제가 회사에 들어오자 제게도 와인 기초 지식을 알려주기 위해 스터디를 한 번 더 진행하셨습니다.

스터디 진행

스터디는 기본적으로 소믈리에님이 자료를 보여주시고 공부한 자료를 다음 스터디 처음에 제가 정리하는 방법으로 진행되었습니다.

경험

와인에 대해서 하나도 모르던 제가 그래도 어떤 와인을 이야기하시면 아! 그 지역이군요?! 를 조금이나마 할 수 있게 된 스터디입니다.
스터디에서 공부한 것은 프랑스, 이탈리아, 등 전 세계 곳곳의 와인 산지의 지역적 특색과 어떤 품종의 와인들이 생산되는지, 유명한 생산자는 무엇인지에 대해서 프로그래밍이 아닌 와인에 대해 공부를 했습니다.

공부하면서 지리와 역사를 부가적으로 공부하게 되었습니다.
와인에는 필수적으로 지리와 역사 가 붙어있다는 것을 알게 되었습니다.

스터디를 하면서 오전에 스터디 하면서 와인을 먹거나 회사 점심에도 와인을 먹으면서 맛을 이야기하면 소믈리에님은 자연스럽게 어떤 지역인지, 어떤 맛이 나는지 질문을 하셨습니다.
회사에서 자연스럽게 와인을 접하니, 와인의 세계가 엄청나게 다양하고 재밌구나 라는 생각을 했습니다.

와인 스터디를 하면서 느낀 가장 중요한 깨달음은 개발이 아닌 다른 섹션에 대해 스터디를 하면서 개발자가 개발 한 가지에만 능통해선 안 된다 라는 것이었습니다.
서비스를 제작할 때, 개발에 대해서도 잘 알아야 하지만 개발할 소프트웨어의 카테고리에 대해서 많은 이해의 필요성 을 깨달았습니다.
사용자들이 앱을 사용할 때 어떠한 관점에서 볼지 와 볼 때 어떤 관점에서 봐야 더 이해가 쉽고 좋은 사용자 경험을 줄 수 있는지 다양한 생각을 하게 된 스터디입니다.

3.3 :: 발표

2017년 회고를 할 때 2018년에는 발표 한 번 하는 것이 목표였습니다.
2018년은 4번 발표를 했습니다. 횟수로는 많이 했지만 사실 성과로는 그렇게 크지 않아서 반쯤의 성공인 것 같습니다.

3.3.1 :: STACCATO 한세 사이버 보안 고등학교 발표

한세 사이버 보안 고등학교에서 게임 개발자에서 서비스 개발자로 주제로 발표했습니다.

발표하면서, 제가 하고 싶었던 말은 다시 한 번 진로에 대해서 고민해보자` 입니다.

이러한 말을 하고 싶었던 이유는 제가 몇 년간 게임업계에 있으면서 과연 게임 개발을 좋아하는가에 대해서 생각을 했습니다.
생각 끝에, 개발이라면 게임뿐만 아니라 다른 분야도 괜찮다는 결론 이 나와서 서비스업계로 이직을 생각하게 되었습니다.
하지만 서비스 업계로 이직하는 것은 쉬운 일이 아니었습니다.
그 이유에는 여러 가지가 있지만 그중에서 가장 컸던 것은 고등학교 졸업이 최종 학력 이기 때문에 이직이 쉽지 않았습니다.

그래서 저와 같은 고민을 하지 않도록 특성화고등학교 특성상 고등학교 졸업 후 취업하는 일이 빈번하므로 다시 한 번 진로에 대해서 생각해보는 게 좋을 것이다 라고 전달하고 싶었습니다.

결과는 좋은 반응이 있었습니다. 학교의 선생님께서도 굉장히 좋은 생각이라고 칭찬해주셨고 학생들도 많은 생각을 하는 얼굴이었습니다.
도움이 되었다고 메일을 보내온 친구도 있었고 강연이 이러한 긍정적 영향을 주는구나 라는 생각이 들었습니다.

3.3.2 :: STACCATO 한국 게임 과학 고등학교 발표

한국 게임 과학 고등학교에서 게임 개발자에서 서비스 개발자로 주제로 발표했습니다.

제 모교에서 발표했습니다.

감회는 한세 사이버 보안 고등학교와 비슷합니다.
하지만 저희 모교는 게임 개발 전문 특성화 고등학교인 만큼 주제에 대한 고민을 많이 했습니다.
그런데도 발표 주제를 같이 가져갔는데요. 이는 게임뿐만 아니라 다른 영역도 생각해보는 기회 가 되었으면 좋을 것 같아서 진행했습니다.

3.3.3 :: Vue.tiful Korea 여섯 번째 밋업 발표

Vue.tiful Korea에서 Vue.js를 이용한 백오피스 구현 주제로 발표했습니다.

항상 컨퍼런스를 갈 때마다 발표자로 강연하시는 분들이 대단하다고 생각합니다.
왜냐하면, 자신이 이해하고 공부한 내용을 다른 사람들 앞에서 설명하는 것은 엄청나게 어려운 일입니다.
그 내용에 대해서 완전한 이해는 물론 나올 질문에 답변까지 훌륭하게 해야 하기 때문입니다.
그래서 발표를 한다는 것은 훌륭한 이해를 기반으로 설명까지 잘한다는 것의 방증이기에 개발자들에게 발표란 경험은 중요하다고 생각합니다.

발표 지원 및 준비

그러던 어느 날 Vue.js korea Slack 채널에서 질문에 대해서 답변을 있던 중
general 채널에 Vue.js 6th meetup 발표자를 찾는 글이 올라와서 덜컥 지원했습니다.

발표자 지원을 하자, 이번 Vue.js 6th meetup은 이전 밋업까지 퀄리티가 낮다는 의견을 많이 주셔서 중, 상급자의 기준으로 발표자료를 구하고 있다고 진행자께서 말씀하셨습니다.

그래서, 발표를 하기 위해 발표 자료를 만들고자 주제를 선정했습니다.
처음 생각한 주제는 Vue.js, express.js, knex.js, postgreSQL를 사용한 웹 서비스 구축이었습니다.
이 주제로 발표하려 생각했으나 너무 사용법만 알려주는 얕은 강의가 될 것 같아서 좀 더 광범위하게 이야기할 수 있도록 Vue.js를 이용한 백오피스 구현 으로 바꾸었습니다.

발표

그렇게 발표 자료를 준비하면서 회사 일을 하고 있으니, 발표날이 밝아버렸습니다.
막상 당일이 되니 개발자 100명 앞에서 개발 이야기를 한다는 게 엄청나게 떨렸습니다.
오시는 분들에게 티켓을 구매한 가격, 그리고 시간을 할애를 해주신 것 자체가 너무나 감사했고 그만큼 좋은 시간이 되었으면 했습니다.

발표 시간이 되어, 첫 발표자인 제가 발표를 하러 앞으로 나갔습니다.
그런데 피피티에 써놓았던 발표 스크립트가 제대로 나오지 않았습니다.
저는 무한 당황을 했으나 이내 기다리신 시간도 있고 당황한 것도 있어서 바로 진행했습니다.

진행하면서 처음에는 긴장한 나머지 엄청나게 떨었고 발표 자체를 망쳤습니다. ㅠㅠ..
다행인 것은 시간이 조금 지나자 깨진 멘탈을 다시 부여잡고 천천히 발표를 진행했다는 점입니다.

발표가 끝나고 질문 시간이 있었는데, 질문 시간대는 제 대처가 아쉬운 점이 많았습니다.
너무 긴장한 나머지 질문에 대한 제대로 된 피드백을 하지 못했고, 질문 시간이 끝나고 질문하신 분을 찾아가서 다시 답변을 드렸습니다.

정리

되돌아보면 저의 첫 발표는 엉망이었습니다. 준비한 발표에 비해 제대로 퀄리티가 있는 발표를 하지도 못했고 답변에 대해 질문을 잘하지 못했습니다. 이러한 발표는 대다수의 사람들에게 좋은 전달이 되지 못했을 것이라 생각합니다.

발표하면서 있었던 여러 가지 문제를 상기해보면
첫 번째로 아쉬웠던 점은 스크립트 의존적인 발표 입니다.

스크립트가 없는 상황을 가정하고 발표를 준비했어야 했는데 스크립트가 없으면 발표를 못 해버리는 상황을 마주하니 준비를 안 한 꼴이 되었습니다.
스스로도 억울하고 발표를 청강하시는 분들에게도 좋지 않은 경험이니 스크립트 의존적으로 발표하면 안되겠다는 생각을 했습니다.

두 번째는 질문에 대한 준비입니다.

발표 자료가 100% 청강하시는 분들을 만족하게 할 수는 없습니다. 그러므로 발표 후 질문을 받는 것이라고 생각합니다. 특히나 질문에 대해서 준비를 많이 할수록 더욱 퀄리티 높은 발표가 된다고 생각합니다.
발표는 발표를 끝낸다고 끝나는 것이 아니라, 질문까지 잘 대답을 해야 완성된다 생각합니다.

앞으로의 발표에서는 이 두 가지에 대해서 더 준비를 잘해야겠다 하는 생각이 들었습니다.

발표 후기에 많은 분이 비판을 해주셨습니다. 해당 비판의 내용이 위의 아쉬웠던 점 2개와 일맥상통하는 점이 있었는데요. 다음부터는 더 좋은 발표를 하고자 노력하겠습니다.

3.3.4 :: Naver FE devtalk 발표

Naver에서 Vue.js를 이용한 백오피스 제작 경험 공유 라는 주제로 발표하였습니다.

해당 발표는 네이버 비디오, 유튜브 등에 영상으로 업로드됩니다.

올 한해 제게 가장 큰 이벤트가 아닌가 할 정도로 준비를 많이 했던 발표였습니다.

발표 지원 및 준비

Vue.js 6th meetup 준비를 하는 중에 친구에게 친구의 지인분이 네이버에서 FE devtalk라는 행사를 진행하는데 vue.js 세션으로 발표해줄 수 없느냐고 연락이 왔습니다.

처음 제안이 왔을 때 할까 말까 고민을 했습니다. 그 이유는 Vue.js 6th meetup과 일주일 밖에 차이가 나지 않아서 발표 자료를 100% 준비할 수 있을까 하는 고민이 있었기 때문입니다.

하지만 생각해보니 이런 기회를 차버릴 수 없겠다는 생각이 들었습니다. 일주일만 죽으라고 발표 준비를 하자 라고 생각하고 준비했습니다.

그래서 Vue.js 6th meetup과 함께 진행되었는데요. Vue.js 6th meetup에서 떨고 버벅이고 난리가 났었습니다. 네이버는 무조건 더 매끄럽게 발표해야겠다 라고 의지를 갈고 닦았습니다.

발표

발표 당일 발표 순서는 중간 세션이 저였습니다.
먼저 신정규 님이 첫 번째 세션 Polymer에 대해서 발표를 시작하셨습니다.
발표하시는 것을 보면서 발표를 이렇게 여유롭게 할 수 있다고 혼자 말하면서 발표하는 모습을 유심히 쳐다보며 배울 점을 관찰했습니다.

배울 점을 관찰하며, 여유를 가지자 라는 생각이 들었습니다.

Polymer 라는 프레임워크에 대해서 나오게 된 배경과 왜 안 쓰이는 지를 막힘없이 진행을 해주셨습니다.
진행하면서 버벅이는 점이 전혀 없었고 오히려 필요한 부분만 딱 짚고 넘어가는 게 훌륭했습니다.
오랜 기간 발표를 하셨던 것 같은 느낌이 전해졌고 저런 여유를 배워야겠다를 생각했습니다.

그러면서 제가 왜 저런 여유가 없을까 하는 생각이 들었습니다.
곰곰이 생각해보니 저는 저 자신이 아는 정보에 대해서 확신이 없고 틀리는 것에 불안함 을 가지고 있는 것 같다는 생각이 들었습니다.

그래서 조금 더 확실하게 알고, 틀리는 경험을 많이 해야겠다는 생각 을 했습니다.

여기서 틀리는 경험이라는 것은 틀려도 겸허히 받아들이고 더 나은 해결책을 제시하는 것을 뜻합니다.

첫 번째 세션의 발표가 끝나고 두 번째 세션, 제 발표가 시작되었습니다.
서당개도 삼 년이면 풍월을 읊는다고 삼 년은 아니지만 한 번 발표를 했던 경험 덕분에 확실히 긴장도 덜하고 시간에 맞게 전하고자 하는 바를 전달했습니다.

발표 후의 반응은 나쁘지 않았습니다. 폭팔적인 반응은 아니었지만 Vue.js 6th meetup 보다 좋은 반응이 나와서 다행이었습니다.

그렇게 쉬는 시간을 조금 가지고 다음 함수형 프로그래밍으로 프로젝트를 제작하신 유인동님의 발표가 시작되었습니다.

유인동님의 발표는 100% 라이브 코딩으로 이루어졌으며 마지막에 조금 버벅인 부분이 있지만, 전반적으로 호평의 발표였습니다.
왜 함수형으로 작성해야 하는지 점점 코드를 발전하는 시키면서 사용자의 경험을 효과적으로 조정할 수 있다는 것을 알게 되었습니다.

함수형 프로그래밍을 발표하시면서 함수형의 강력한 점과 틀렸을 때도 당황하지 않으시는 모습이 매우 프로페셔널 했습니다.
라이브 코딩을 하는 것이 상당히 어려운 일임에도 불구하고 발표를 마치신 것이 대단했습니다.

그 후 질문 답변 시간이 있었고 발표를 마쳤습니다.

정리

올해 마지막 가장 큰 이벤트를 마쳤습니다.
다양한 개발자분들과 발표를 하면서 어떻게 더 훌륭한 개발자가 될지에 대해서 생각을 많이 한 계기가 되었습니다.

다음 발표부터는 발표 내용도 조금 더 명확하게, 발표에 여유를 가져야겠다는 생각이 들었습니다.

발표 후 상패를 주시는데 상패 보고 깜짝 놀랐습니다.

3.4 :: 컨퍼런스

최근에는 컨퍼런스를 들으러 갈 때 세션 선택에 실패를 많이 하는 것 같습니다.
다양한 세션이 생기고 흥미가 있는 세션도 많은데 선택한 세션은 다 망해버리는 ㅠㅠ.

어떻게 하면 더 좋은 세션을 고를 수 있을까 하는 의문을 가지고 올해도 컨퍼런스를 갔다 왔습니다.

근데 올해는 작년보다 컨퍼런스를 많이 가지 못했습니다.
컨퍼런스에 대한 개발자들의 관심도도 높아지고 티켓팅도 어려워져서 그런 것 같다는 생각입니다.

3.4.1 :: Vue.tiful Korea 4th Meetup

Vue.js Korea Group에서 주관한 Vue.js의 4번째 밋업입니다.

  • 참여형태 : 참여자
  • Vue.js 4th meetup를 참여하여 청강하였습니다.
  • 사용 방법만 알려주고 정확한 사용 후기라던 가는 없어서 조금 아쉬웠습니다.

3.4.2 :: Vue.tiful Korea 5th Meetup

Vue.js Korea Group에서 주관한 Vue.js의 5번째 밋업입니다.

  • 참여형태 : 스태프
  • Vue.js 5th meetup에서 스태프로 참여했습니다. 스태프로 참여하면서 행사 진행을 어떻게 하는지, 기자재 빌리는 것과 장소 대여를 어떻게 하는지 등등을 직접 해보면서 알게 되었습니다.
  • 알게 모르게 우리가 보지 못한 부분들을 스탭들이 많이 주관하고 있습니다.

3.4.3 :: if kakao dev 2018

CTO님이 양도해주셔서 가게 된 if Kakao dev 2018입니다.

  • 참여형태 : 참여자
  • 카카오에서 처음으로 주관하는 컨퍼런스인 만큼 많은 후원사가 왔고 발표 퀄리티도 좋았습니다.

3.4.4 :: Google I/O Extended Seoul

세종대학교에서 진행된 Google I/O Extended Seoul 컨퍼런스 입니다.

  • 참여형태 : 참여자
  • 다양한 세션이 진행됐으나 개인적으로 Google의 product 자랑이 주였다는 것이 흠.. 별로 얻은 소득은 없었습니다.

3.4.5 :: Pycon Korea 2018

Pycon Korea에서 주관한 컨퍼런스 입니다.
예로부터 파이콘은 훌륭한 컨퍼런스라고 소문났습니다.
아니나 다를까 나온 내용은 다 훌륭했으나 제가 부족하여 다 이해를 하지 못했습니다. ㅠㅠ

  • 참여형태 : 참여자
  • 다양한 세션이 있었고 훌륭한 세션도 많았지만 제가 부족하여 이해를 많이 하지 못했습니다.
  • 인공지능 관련된 강의가 많았고 제가 어서 머신러닝 공부에 박차를 가해서 내년에는 꼭 이해하게 되었으면 좋겠습니다.

4 :: 고민

새로운 회사에서 본격적으로 서비스 개발로 가면서 개발자로서의 넓은 범위로 고민을 하게 되었습니다.

4.1 :: 커뮤니케이션의 문제

제가 회사에서 오고 나서 가장 크게 느낀 저의 문제입니다.
결론부터 말하기 의 중요성을 느끼고 있습니다.

저는 이야기를 할 때 이야기에 정확히 하고 싶은 바와 어떻게 할 것인가에 대해서 회의를 할 때 제대로 말을 하지 못하는 경우가 잦습니다. 그래서 커뮤니케이션에 어려움이 팀 내에서 있었습니다. 그래서 커뮤니케이션 할 때 어떻게 말을 해야 할 지 고민을 1년 내내 했습니다.

그래서 최근에는 최대한 결론을 앞에 말하고 뒤에 차분하게 설명을 덧붙이고 있습니다. 하지만 설명을 하면서 이야기가 되게 길어지는데 이것을 어떻게 해야 할까 고민 중입니다.

회사에 CTO님과 개발자 형이 다년간 쌓아온 커뮤니케이션 능력을 옆에서 볼 수 있어서 그들의 장점을 보며 점점 좋아지려 노력하고 있습니다.

장황하게 늘어놓기보다 결론만 말하자

4.2 :: 효과적으로 배우기

제가 직군으로 있는 프론트엔드 뿐만 아니라 개발 시장 전체가 수많은 기술이 무수히 쏟아져 나오고 있습니다. 그러면서 개발자들이 알아야 할 것이 점차 늘어가고 있습니다.

이런 흐름의 시장에서 제가 더 훌륭한 개발자가 되기 위해서는 어떤 개발을 하더라도 러닝 커브 곡선이 완만한 개발자가 되어야 함을 느낍니다.
제가 생각하기에 본인은 러닝 커브가 가파른 편은 아니라고 생각합니다. 하지만 이보다 러닝 커브가 없어져야 한다고 생각합니다.

특히 제가 아에 해보지 않은 영역에 대해서는 시간이 오래 걸립니다. 이는 기본기가 없다고 생각할 수 있습니다. 이런 이야기가 회사에서 나왔을 때 CTO님께서는 언어적인 개념을 알고 있을수록 그런 상황이 닥쳤을 때 아 이 기능은 있겠다 라고 생각해서 빠르게 적응할 수 있다고 하셨습니다.

그래서 러닝 커브를 더 완만하게 하려고 다양한 분야로 공부를 진행하고자 합니다. 특히 다양한 언어와 마주함으로써 언어들의 특징을 자세히 공부해볼까 합니다.

4.3 :: 집 사고 싶다.

집 사고 싶다..

5 :: 2019년 목표

2018년에 있었던 여러 가지 일들을 돌이켜봤습니다.
회고를 했으니 2019년 목표를 설정하고자 합니다.
그러기 전에, 먼저 2017년에 내년에 하고자 하는 목표들은 달성했는지 보도록 하겠습니다.

5.1 :: 2018년 목표 달성 현황

  • 일일 커밋 하기

달성하지 못했습니다.

  • 다양한 스터디 참가

달성했습니다. 다양한 스터디라는 것이 굉장히 범위가 넓지만, 프로그래밍에 국한되지 않고 와인 스터디도 했으며 다양한 깨달음을 얻었기 때문에 성공이라고 생각합니다.

  • 발표 한번 하기

달성했습니다. Naver, Vue등 개발자분들 앞에서 발표도 했고, 고등학교 대상으로 발표도 진행했습니다.

  • 영어 공부

7월까지 학원에 다니다가 그만 다녔습니다. 반쯤인 실패입니다.

  • 세미 프로젝트 3개 이상 완성

달성하지 못했습니다. 세미프로젝트를 제작하기가 생각외로 힘들다는 것을 깨달았습니다.

  • 개발자 컨퍼런스 참가

다양한 컨퍼런스를 다녀왔습니다. 비록 몇 번 가진 못했지만 내년에는 Deview나 커다란 컨퍼런스 들을 다녀오고 싶습니다.


생각외로 달성을 많이 못 했습니다.

다양한 스터디 참가, 발표 한번 하기, 개발자 컨퍼런스 등 굵직한 것은 해냈지만 평상시에 꾸준히 해야 하는 것에 대해서는 약하다는 것을 볼 수 있었습니다.

5.2 :: 2019년 목표

2019년에는 2018년에 하고자 한 목표들처럼 꾸준히 이루어져야 하는 것들을 제 라이프 사이클로 만들어서 넣고 싶습니다.

그래서 올해의 주제는 라이프 사이클 만들기 입니다.

저도 20대 중반이 되고 회사 생활한 지 6년인데 이제는 제 하루 라이프 사이클을 만들어야 할 것 같다는 생각이 들었습니다.

  • 영어 학원 꾸준히 다니기

작년까지 다니던 영어학원에서는 기간은 길게 다녔지만 사실상 배운 것은 딱히 없는 것 같습니다. 그러므로 올해는 조금 거세게 일주일에 3번을 다녀볼까 합니다. 회사 시간과 잘 조절해서 최소 2회 이상 다니며 성과를 낼 수 있는 연도가 되었으면 합니다.

  • 오전 6시 기상

작년까지 기상 시간이 불규칙해서 회사에 지각도 하고 정상적인 생활을 하지 못했습니다.
그래서 올해에는 오전 6시에 기상해서 개인 공부도 하고 운동도 할 수 있는 라이프 사이클을 만들고 싶습니다.

  • 세미 프로젝트 3개 완성

간단한 장난감 프로젝트나 세미 프로젝트로 3개의 프로젝트를 완성하고 싶습니다.
또한, 신기술을 왕창 적용한 재미있는 프로젝트도 만들고 싶습니다.
역시 이것은 제 꾸준함을 테스트하기 위해서 넣었습니다.

  • 일일 커밋

하루하루 무엇을 공부하고 어떤 것을 했는지, 회사에서의 커밋 뿐만 아니라 공부한 흔적에 대해서 남기고 싶습니다.

하루하루 공부한 내용이 일 년이면 365개의 데이터가 쌓여서 어마어마해집니다.
그래서 내년에는 회고함에 있어 일일 커밋한 내용을 대상으로 회고를 해보고 싶습니다.

  • 발표 두 번 하기

올해에는 발표를 두 번 이상 하고 싶습니다.
작년에 발표한 번 이상 했으니 올해에는 더 많은 기회가 있을 거라 생각하고 두 번을 잡았습니다.

6 :: 마무리

많은 사람의 도움이 있어서 여기까지 올라올 수 있었던 것 같습니다.
내년에는 그 도움에 보답하여 더 훌륭한 사람이 돼서 제가 도와드릴 차례가 되었으면 합니다.

감사합니다!