이미지1

2018년 회고에 이어서, 올해는 상반기 회고를 먼저 작성하게 되었다.
올해 상반기는 나의 규칙적인 라이프사이클을 만드는데 집중했고 라이프사이클을 만들면서 점진적으로 다양한 활동을 추가했다.

1월

1월은 2018년을 되돌아보면서 회고를 진행했다. 회고를 하면서 2018년을 꽤 바쁘게 지냇음에도 불구하고, 2018년의 목표중 50%밖에 달성하지 못했다는 사실에 적잖이 충격이었다. 회고를 하면서 부족한 부분을 캐치했고 ‘이를 바꾸기 위해서 어떤 노력을 해야하는가’에 대한 생각을 많이했다. 당장 문제로 보이는 건 규칙적인 라이프사이클을 만들고, 그 라이프사이클안에 자연스럽게 공부와 목표를 배분하는게 중요해보였다.

라이프사이클 만들기

라이프사이클을 만드는 일은 생각외로 힘들었다. ‘그 누구도 나를 건들순 없으셈’하며 자유분방하게 살아왔던 지난 24년을 뒤로하고 새로운 삶의 방식을 만드는 의미이기 때문에 많은 인내심을 필요로 했고, 각오가 되어있어야 했다.

규칙적인 생활

라이프사이클을 만드는데 가장 중요한 포인트는 규칙적인 생활을 만드는 것이다. 규칙적인 생활을 위해 생활내에서 이룰 수 있는 목표 몇 가지를 만들었다.

  • 아침 6시 기상하기
  • 저녁 12시 취침하기
  • 과음하지 않기

아침 6시부터 저녁 12시까지 내가 깨어있는 시간은 총 18시간이다. 18시간을 배분한 이유는, 작년의 불규칙한 생활을 참고했을때 하루 평균 14시간 깨어있었다. 그래서 4시간을 늘려서 오전 시간에 공부를 한다면 작년보다 더 좋은 결과물을 낼 거라는 생각을 가지고 시간을 조정했다. 아침 기상시간을 늘리지 않고 저녁 12시로 땡긴 목적은 오전에 늦게 일어나면 하루가 개운하지 못하고, 지각에 쫓겨 오전에 제대로 된 시간을 보낼 수 없기 때문이다. 그래서 최대한 외부의 압박을 줄이고자 했다.

생활 환경 만들기

피플웨어에 ‘2부 사무실 환경’ 챕터를 읽어보면 회사내에서의 개발환경에 대한 중요도가 높다는 걸 알 수 있다. 업무 환경이 개발 퍼포먼스에 영향을 주는 것처럼 생활 환경도 규칙적인 생활을 만드는데 많은 도움이 될거라 생각해서 좋은 환경을 조성하려 노력했다.

  • 쉽게 일어날 수 있는 환경 조성
    일찍 일어나기 위해서 여러가지 강제할 수 있는 장치를 설치했다.

    1. 스마트폰 앱으로 알람을 걸어두기
    2. 알람은 누워있는 상태에서 종료할 수 있으므로 탁상시계를 구매해서 알람걸기.
    3. 탁상시계도 끄고 다시 들어갈 수 있으므로 화장실에 탁상시계 한개 더 두기
  • 쉽게 잠들 수 있는 환경 조성
    12시에 잠이 안올 수도 있다. 그래서 일찍 잘 수 있게 독서를 하는 선택지를 만들었다.

    1. 전자기기를 마주할 수 없도록 침대와 책상의 거리를 매우 멀리 떨어뜨림
    2. 침대 옆에 책장 배치
    3. 10시 ~ 12시 사이드 프로젝트 및 운동 스케쥴 잡기
  • 일어나서 피로가 풀리도록 환경 조성

    1. 6시 기상 후 커피를 먹을 수 있게 네스프레소 머신 구매
    2. 오전에 생각할 시간이 적으므로 미리 옷을 꺼내놓기

피플웨어는 1987년에 발행되어 현재 한국에 3판까지 개정되어 나왔다.
‘소프트웨어의 주요 쟁점은 기술이 아닌 사람에 있다’는 주제를 가지고 진행되는 책이다.
협업, 회사, 인재 등의 저자들의 많은 고민이 잘 들어가 있는 훌륭한 책이므로 시간이 되면 꼭 읽어보는 걸 추천한다.

처음부터 많은 조건을 만들어 지치면 안됐기 때문에 간단한 규칙부터 만들어서 시작했다. 1월 한 달간 생활 환경을 조성하고 규칙적인 생활을 진행했다. 처음에 진행하면서 정말 힘들었는데 3주정도 가까이 진행해보니 어느정도 할만했고 몸에 점점 익어가는 것이 느껴졌다. 제일 난이도가 높은 일은 오전 6시 기상 이다. 본인은 아침에 매우 약한데, 그걸 극복하는 일도 함께 했다.

2월

1월동안 라이프사이클에 어느정도 익숙해져 라이프사이클에 몇 가지 feature를 넣을 여유가 생겼다. 그래서 지난 2018년 회고를 회고하면서 필요한 부분을 라이프사이클에 추가할 수 있는게 있을까 고민했다.

회고의 회고

지난 2018년을 회고하면서 어려웠던 점은 내가 1월에는 뭘했지..?와 같은 기억을 되짚는 일이었다. 그래서 내년에도 똑같은 실수를 반복하지 않기위해 어딘가에 글을 남기는게 필요했다. 마침 Notion이라는 툴이 한국에서 Evernote를 추월하여 삽시간에 개발자와 IT 직업들에게 퍼져나갔다. 안그래도 기록을 작성할 앱이 필요하던 차에 Notion을 사용하기로 했다.

Notion 활용하기

일기를 작성하면서 점점 늘어가는 일기장을 관리할 수 있었으면 했고, 동일한 포맷을 매일 노가다하여 배치하는 작업이 매우 불필요한 과정이라 개선했으면 했다. 그래서 이를 개선하기 위해서 노션을 삽질하기 시작했고, 삽질의 결과로 월, 주, 일 단위의 회고와 일기, 집중을 얼마나 했는지를 작성하는 포맷을 작성했다.

제작한 노션 포맷

이미지1

작성한 노션 포맷을 사람들과 공유했고, 꽤나 괜찮은 반응을 얻었다. 지금도 이 포멧을 사용하여 할 일을 배분하고, 일기를 작성하고 있다.

함께자라기 독서

김창준님의 함께자라기를 2월 한달동안 읽었다. 이 책은 제목처럼 ‘함께’, ‘자라기’ 두 가지에 대해 초점이 맞추어져 있다. 책을 읽으면서 생각도 못했던 자라는 방향에 대해서 고민하는 시간이 되었다. 익숙한 일과, 어려운 일의 사이를 잘 걸치면서 작업하면 성장이 매우 훌륭하게 될 수 있다는 파트가 가장 와닿았다. 내가 지난 6년간 개발을 하면서 익숙한 코딩만 하진 않는지, 발전을 위해 코딩 방법을 새롭게 도입을 해보진 않았는지 다시금 생각하게 되었다. 그래서 몇 가지 지금 할 수 있는 새롭게 도전해보기로 한 게 몇 가지 있다.

  • WebStorm에서 Visual Studio Code로 환경 변경
  • 함수형으로 적극 코딩하기
  • 웹 서핑보다 먼저 코딩하고 찾기

이 세 가지 규칙을 갖고 의도적 수련 을 3월부터 진행해보기로 했다. 이 뿐만 아니라 여러 방면에서 생각을 하게된 게 많다. 그래서 나중에 따로 독후감을 작성할 예정이다.

하드웨어 스터디 진행

화요일 목요일마다 오전 9시부터 10시까지 한 시간씩 하드웨어 스터디를 진행했다. 하드웨어 스터디를 하면서 어셈블리와 하드웨어 구조에 대해서 알게 되었다. 우리가 흔히 쓰는 C++같은 언어들이 어셈블리로 컴파일되어 어떻게 동작하는지, 내부적으로는 어떤 패러다임으로 돌아가고 있으며 상태관리는 어떻게하는지, 컴퓨터 하드웨어가 어떻게 동작하는지와 같은 기본 지식을 공부하게 되었다.

특히, 어셈블리어 공부의 경우 코드를 짜면서 컴퓨터가 어떻게 동작을 시킬까를 생각하면서 작성하게 되었다. 예전에 비해 버그와 코드 가독성이 향상되었음을 느낀다.

하드웨어 스터디는 ARM Cortex m4와 어셈블리를 이용해서 진행했다.

3월

지난 두 달간 라이프사이클을 만들면서 어느정도 익숙해졌다. 라이프사이클에 일기 작성을 추가한지 약 한달동안 서른개 남짓한 일기를 작성했고 그러면서 설명하는 능력이 향상되고 있는걸 느낀다. 또한 스몰토크를 할 수 있는 컨텐츠도 많아졌는데, 이는 매일 매일 일기를 쓰므로 장기기억으로 남기 때문이라 생각한다. 3월에는 이런 라이프사이클을 바탕으로 실제로 공부를 진행해보려한다.

타입스크립트 공부

웹 시장에서 압도적으로 많이 쓰이는 언어는 JavaScript이다. JavaScript의 여러가지 문제점은 자유롭기 때문에 불변성을 보장할 수 없는 점이 문제로 꼽혀왔다. 대표적인 예시를 몇 가지 들어보자면, 바쁜 일정 사이에서 협업을 진행하면 코드 리딩을 할 수 있는 시간이 줄어든다. 그러면서 개발자는 바삐 개발을 해야하기 때문에 코드를 정신없이 작성하게 된다. A 개발자가 foo라는 객체의 데이터를 string으로 바꿨는데, 이게 string인지, number인지 보장할 수가 없다는 말이다. 협업할 때 문제가 된다. 그래서 타입스크립트는 빠르게 웹 시장의 표준으로 자리를 잡아가고 있는 중이고, 많은 회사들이 타입스크립트를 도입하고 있다.

이러한 이유로 타입스크립트를 공부해야겠다는 판단이 들어서 타입스크립트 공부를 시작했다. 오전 시간을 주로 활용해서 공부를 했고, 3월 한달간 회사 내에서 타입스크립트 스터디를 만들어서 운영했다. 스터디를 운영하면서 타입스크립트에 빠르게 익숙해지기 위해 Realworld를 포크떠서 Vue + TypeScript를 진행했다. Realworld에 공식으로 올려달라고 했으나, README.md 수정 및 travis ci 붙여야 올려줄 수 있다고 하여 일단 보류해놓았다. (..)

퇴근길 와인 수업

이미지2

지금 재직하고 있는 와인포인트는 앱 내에서 큐레이팅을 통해 고객이 와인을 추천받고 와인을 주문한 고객이 요청한 이마트24 점포로 배달해주는 서비스이다. 하지만 우리 회사는 와인을 전문적으로 알고있는 기획자가 없기 때문에 우리가 공부해서 데이터베이스 스키마를 제작하고, 앱과 웹을 기획해야했다. 그렇기 때문에 도메인 지식은 매우 중요하다. 회사 초반에는 소믈리에님이 회사내에 있어서 교육을 받았다. 하지만 와인의 세계는 방대했고 초기 교육으로는 부족하다고 느껴 퇴근길 와인 수업을 참가하게 되었다. 회사에 계시던 소믈리에님이 회사를 퇴직하고 사업을 하시면서 사이드로 진행하는 프로젝트인데, 와인을 테이스팅 하면서 평가하고, 품종, 국가등을 공부하는 수업이다. 퇴근길 와인 수업은 6개월간 진행되는데, 6개월 후에 내가 얼마나 성장해 있을지 기대된다.

관리자 페이지 리펙토링

회사 관리자 페이지를 리팩토링했다. 일관되지 않은 구조를 Container, Presentational 형태로 일차로 나누었고, Module들에 의존된 형태를 제거했다. 이 작업을 하는데 한달 꼬박 걸렸고, 야근을 자주 했다.

  • 모바일 지원
  • Container, Presentational 형태로 변경 (Props Drilling 형태의 코드로 변경)
  • API 중복로직 개선
  • JWT 적용

총 코드 줄 수를 2/3으로 줄였다. 가독성이 좋아졌고 만족스러운 구조로 잡혀서 맘에든다. 특히나 Container, Presentational로 변경하고나서 디자인 변경 속도가 1.5배는 빨라짐을 느낀다. 이는 Presentational에서만 디자인을 변경해도 되니, 폴더 선택의 영역이 줄어들었기 때문으로 보인다.

피플웨어 독서

위에서 언급했던 피플웨어를 4월 한달동안 완독했다. 피플웨어를 주요로 관통하는 주제는 소프트웨어는 ‘기술’보다 ‘사람’이 중요하다는 것이다. 이는 나도 동의한다. 기술은 언제나 변할 수 있으나, 사람은 그 기술에 언제든 익숙해질 수 있다. 가장 기억에 남는 이야기가 있다. ‘어떤 팀은 개발자들이 집중할 시간을 갖기위해, 집중하는 중이면 자신의 책상에 빨간색 천을 걸어두었다’ 이 문장을 보고 협업을 아름답게 풀어나갈 수 있구나 하는 생각이 들었다.

4월

본격적으로 이직을 하기위해서 움직이기 시작했다.

이력서 작성

나의 이력서

이력서 작성을 할 때 필수적인 규칙을 몇 가지 정했다.

  • 웹으로 개발해서 퍼블리싱한다.
  • 한 눈에 내 기술 스택을 확인할 수 있어야 한다.
  • 디자인은 심플하게, 최대한 타이포그래피를 활용

규칙을 정했으니, 이력서 흐름을 생각하여 목차를 작성했다.

  1. 첫 인사
  2. 관심사
  3. 기술 스택
  4. 경력
  5. 대외활동
  6. 강연
  7. 수상

내가 면접관이 되었다고 가정하고 구상했다. 구상해보니 경력을 보고, 기술 스택을 유추하는 행위는 매우 비효율적이라고 생각했다. 그래서 관심사와 기술 스택을 먼저 서술하여 인지한 상태에서 경력을 읽는게 효과적이라 판단하여 배치를 관심사 - 기술 스택 - 경력으로 진행했다.

그 외에 대외 활동, 강연, 수상은 관심사와 경력을 뒷받침 해줄 수 있다고 생각했기 때문에 뒷 부분에 추가했다.

기술을 서술할 때의 순서는 웹 프론트엔드 개발자 기준으로 작성했다.

  1. HTML/CSS
  2. JavaScript
  3. SPA Framework (vue, react)
  4. Server
  5. DevOps (Web을 Deploy 하기 위함)
  6. 그 외 (git 등..)

‘프론트엔드 개발자가 원하는 기술이 무엇일까’를 곰곰이 고민해봤다. 개발자를 뽑을 때 React, Vue와 같은 Web Framework를 다루는 능력도 중요하지만, 다양한 상황에 대해 대응하기 위해서 기본 지식이 중요하다고 생각했다. 또한 여러 기업들이 React와 Vue 같은 Web Framework를 많이 사용하고 있지만 그럼에도 불구하고 jQuery나 Vanilla JavaScript 같은 코드는 많이 존재하고 지금도 코딩이 되고 있다. 그래서 HTML/CSS, JavaScript와 같은 기본기를 앞에 배치했다.

기본기 다음으로 SPA Framework를 배치했다. 읽으면서 ‘튼튼한 기본기로 SPA Framework들을 다룰 줄 안다!’으로 자연스럽게 읽혀지길 바라는 생각이었다. 하지만 생각보다 강조가 많이 되지 않은 것 같다. 모노한 전개여서 그런지, 다음 이력서를 제작할 때 핵심 기술을 강조하는 부분을 추가해야 하겠다는 생각이 들었다.

최근, Front-end 개발자는 Server 지식도 충분히 갖고 있어야 된다고 생각한다. 하나의 웹 서비스를 구성하는 요소 가운데 서버는 당연히 빠질 수 없는 요소이며, 이는 SEO, SSR와 같은 유저가 웹을 마주하게 되는 시작점에 대한 중요한 개발을 포함하는 영역이다. 또, 완벽한 서버 구현은 힘들겠지만 프로토타입용으로 웹을 만들 때 잠시 사용되는 역할의 조그마한 서버는 만들 수 있어야한다. 이러한 필요성에 따라, ‘앞에서 웹 개발을 잘할 수 있다’에서 ‘웹 개발 후 웹 배포 및 서버 개발도 할 수 있다’로 좀 더 다듬어 주는 흐름을 구성했다.

DevOps를 구축하면 귀찮은 일을 자동화하여 개발 속도를 향상 시키는데 큰 도움을 준다. 특히나 웹 배포 시나리오는 반복적인 작업을 하는 일종의 노동이다. 자동화를 하지 않으면, AWS console 접속 → ip 확인 → ip에 해당하는 서버 접속 → 서버에서 git fetch → git checkout upstream → pm2 restart 와 같은 반복적인 작업을 하게 된다. 이러한 작업을 크게 덜어주면 작업 효율이 많이 상승하므로 이러한 작업을 할 줄 아는 웹 개발자인 것을 마지막으로 어필했다.

경력은 최근 경력부터 정렬을 했다. 글만 있으니 읽는 사람이 집중하기 힘들다는 생각이 들어 프로젝트마다 Preview를 배치했다. 프로젝트마다 기간, 짧은 설명, 기술 스택, 핵심 작업을 명세했다. 특히 작업에 해당하는 영역은 어떤 효과를 얻었는지 기술을 적용한 이유와 그 기술을 통해 회사의 프로젝트가 어떤 긍정적 영향을 얻었는지 상세하게 적었다. 개발자가 기술을 선택하는 궁극적인 목표는 ‘협업을 위해’, ‘편한 개발을 위해’ 와 같은 팀 시너지를 올려서 회사의 사업이 훌륭하게 돌아가도록 하는 것이니까.

면접 준비

기술 면접을 준비하기 위해서 노션에 질문을 정리했다.

기술 면접 준비는 회사에 서류와 코드 테스트에 합격하고 나서 준비하지 않았다. 그 이유는 코드 테스트를 합격하고 기술 면접을 보는 시간이 매우 짧을 걸 예상하고 있었고, 웹 개발자로 전향하고 어느정도 시간이 흐르지 않아서 기본적인 웹 개발 질문을 할거라 생각했다. 그렇기에 많은 시간이 필요하다 느껴, 두 달 전부터 시작했다.

노션 면접 준비 링크

완벽한 공부법 독서

완벽한 공부법을 독서하기 시작했다. 온라인 상에서 유명하기도 했고, 목차를 읽어봤는데 좋은 글들이 많았기 때문이다. 이 책은 목표를 정하는 방법, 외국어 공부하는 방법, 독서를 왜 하는가? 독서를 하는 방법과 같은 실생활에서 공부에 도움을 주는 책이다. 읽으면서 많은 동기부여가 되었는데, 그 이유는 허위정보가 아닌 논문을 정리하여 팩폭을 갈궛기 때문이라 추측한다. (…)

회사 프론트 웹 기술 스택 확정

회사의 프론트 웹페이지 기술 스택을 올해 초부터 정하고 있었다. 그래서 길게 보면서 스택을 정리하고 있었는데 4월에 스택을 확정했다. 와인포인트 프론트앤드를 클릭해서 우리가 어떤 기술을 적용했고, 기술을 적용한 이유를 볼 수 있다.

회사 지원 및 서류 작성, 그리고 면접

세 곳의 회사를 지원하여 서류를 작성했고 코딩테스트 그리고 면접을 봤다. 대다수의 회사가 코딩테스트 48시간 과제를 줘서 동시에 세 군대에 지원한 나는 그 스케쥴을 다 견뎌야 했고 힘든 시간이었다. 하지만 코딩테스트에 새로운 기술도 적용해보고 약간 실험형식으로 써서 재미도 있었다.

이직을 준비하면서 이 링크에서 더 자세히 읽을 수 있다.

5월

5월은 다시 이직을 하기위해 준비하는 시간이었다. 도중에 헤커톤과 같은 다양한 행사에 나갔다. 라이프사이클을 꾸준히 지키고 있어서 나의 끈기가 대단하다는 생각이 들었다.

알고리즘 잡스

면접을 볼 때 라이브코딩을 항상 망쳐서 내가 알고리즘이 문제인가? 하고 5월 한달동안 알고리즘 잡스를 수강했다. 하지만 알고리즘 잡스를 수강하면서 내가 알고리즘이 필요하다는 생각이 들지 않았고 (상당히 높은 레벨의 문제를 쉽게 풀었음) 그래서 5월 말에 수강을 종료했다. 만약 알고리즘이 부족하다 하시는 분이 계신다면, 알고리즘 잡스를 추천한다. 빡세게 알고리즘만 하루에 4시간씩 코딩할 수 있다. 그리고 원하는 회사의 알고리즘 난이도까지 파악하고 있어서 스케쥴링까지 잡아주니 괜찮은 서비스인 것 같다. 그 것과 별개로 웹 프로그램으로 알고리즘을 푸는데, 본인은 불편해서 XCode에서 코딩해서 붙여넣기를 했다. 웹 프로그램이 조금 아쉬웠다.

스포카 해커톤 ‘무쓸모톤’ 참가

이미지3

스포카 해커톤 ‘무쓸모톤’을 지원했다. 무쓸모톤은 세상에서 제일 쓸모없는 앱을 만드는 헤커톤이라는 의미인데, 너무 신박해서 지원을 할 수 밖에 없었다. 운이 좋았던 게 우연히 Festa를 살펴보다가 (여태까지 안보다가) 봤는데 딱 있어서 지원했다. 지원자가 많으면 짤릴수도 있다고 했는데, 다행히도 참가자 안에 들어서 개발을 할 수 있게 되었다. 본인은 8팀으로 배정을 받아 4명의 팀원들과 함께 개발을 시작하게 되었다. 초기에 아이디어를 5번정도 바꿨다. 왜 그러냐면 세상에서 정말 쓸모없어야 했기 때문이다. 더군다나 흔할 수도 있기 때문에 신중히 선택을 했다. 계속 선택을 못하고 있다가, 마지막에 의견이 나온 ‘세상에서 가장 쓸모없는 TO-DO List’를 팀원 모두 만족해했기 때문에 이걸로 정하게 되었다.

팀원중에 웹, 앱과 같은 프론트를 나 혼자밖에 하지 못해서 해커톤 내내 코딩에 매진했고, 화장실 가는 시간 외에는 코딩에만 몰입했다. 결과적으로는 7페이지 되는 분량의 기능을 전부 완성했다. 솔직히 하루만에 이렇게 만드는 사람은 많지 않다고 생각한다. (정말 힘들었다)

코드는 여기서 확인할 수 있다.
스포카 해커톤 팀 08

기술 스택으로는 Vue.js를 사용했다. 왜냐하면 Vue.js는 모듈을 선택하는데 있어서 생각할 필요가 많이 없고 (모두 공식 커뮤니티에서 관리하기 때문에) 개발이 매우 빠르다는 장점이 있다. 그리고 몇몇 페이지는 부분적으로 svelte를 사용했는데, Vue.js를 쓰는데 굳이 이 친구를 쓸 일은 많이 없어보였다. html 안에서 순서와 상관없이 자유롭게 웹 코딩을 진행할 수 있고, No Virtual DOM이라는 특징이 있는데 성능 테스트를 나중에 해보고 싶다.

하룻밤동안 빡세게 작업을 하고, 최종 뽑는 과정에서 1등의 영예를 짊어질 수 있었다. 우리 프로젝트가 완성도가 제일 좋아서 뽑혔다고 다른 팀원 분들이 말씀하셨다. 보람찬 하루였다.

그들은 알고리즘을 알았을까? 독서

컴퓨터의 내부 연산과 알고리즘, 자료구조를 쉽게 정리한 책이 있다고하여 구매해서 읽었다. 하지만 기대와 다르게 책의 퀄리티가 별로였다. 이 책은 기본적으로 서양 이솝우화와 셜록홈즈와 같은 저명한 소설을 읽어본 경험이 있어야 수월하게 읽힐 수 있고, 비유를 드는데 살짝 억지비유의 느낌이 있다. 또한, 결정적으로 번역을 너무 어렵게 해놓아서 이해하기가 쉽지않다. 알 수 없는 단어 선택으로 첫 장부터 모호해질 수 있다.

AWS + Docker In Docker + Jenkins + ELB를 이용해서 블루 그린 배포 자동화

배포를 할 때 노가다를 하는게 싫어서 자동화를 하고자 DinD + Jenkins로 배포 자동화를 공부했다.

Docker In Docker
Jenkins

한달 내내 이 자동화로 사이드 시간을 잡아먹혔는데 시간을 많이 소모한 걸 몇 가지 꼽아보자면

  • Docker In Docker 삽질
  • AWS의 많은 기능에 익숙하지 않음 (IAM)
  • Jenkins 설정 삽질

이 중에서도 Jenkins 설정 삽질이 제일 많이 걸렸는데 Jenkins stable 버전에 대해 Docker Cloud에서 지원하지 않아서 업데이트하는 과정에서 삽질한 게 크다. (부들부들..)

6월

지난 5개월간 회고를 하면서 문득 작년 하고자 했던 목표가 기억이 났다. 그 중에 지금 이뤄지지 못한게 있나 확인을 해봤는데 사이드 프로젝트를 전혀 진행하고 있지 않았고 그나마 진행하는 것들은 사이드로 공부정도의 규모밖에 되지 않았다. 그래서 이번 6월은 사이드 프로젝트를 준비하는 달로 지정하고 작업에 착수했다.

샬롱(Salon) 공유 블로그 프로젝트

사건의 발단은 올해 초, 무언가 의미있는 일을 찾고있다가 문득 아이디어가 떠올랐다.

이미지4

모교의 후배들이랑 함께있는 톡방이 있는데, 톡방에 있는 각양각색의 친구들이 돌아가면서 한명씩만 글을써도 재미있는 글이 나올 것 같았다. 머신러닝, 딥러닝 연구실에 있는 친구, 대학교에서 복수전공 하고 있는 친구, 스타트업에서 유심칩 개발하고 있는 친구, 의료장비 업체에서 일하고 있는 친구등 다양한 친구들이 존재했기 때문에 이런 서비스를 개발하려는 의욕이 샘솟았고, 그 톡방의 개발하는 친구들 몇명을 모아서 프로젝트를 시작했다.

엘레강스 사교클럽이라는 이름으로 깃헙에 그룹을 만들었다. ‘사람들이 생각해내지 못한 이상한 것을 만드는 그룹’이라는 의미로 이름을 지었고, 첫 프로젝트는 위에서 말한 공유 블로그 프로젝트로 시작하기로 했다. 여담이지만, 다음 프로젝트는 웹에서 동작하는 미연시 프로젝트를 만들기로 했다.

프로젝트 이름은 엘레강스 사교클럽이니, 귀족들의 모임을 착안하여 샬롱 이라고 지었다.

기술스택

샬롱 프로젝트는 기본적으로 웹 기반으로 돌아가기 때문에, 웹 시장에 조금 더 오래있었던 내가 프로젝트를 리드하는 그림으로 진행되었다.

  • React.js
  • Redux
  • Redux Saga
  • Express.js
  • knex.js
  • PostgreSQL
  • AWS EC2, S3, CodeDeploy, RDS, Route53, AWS Certificate Manager
  • Travis CI
  • Gabia
  • Docker
  • Git
  • Github
  • Git Flow

프론트앤드와 백앤드 모두 github master branch에 push하면 자동으로 블루 그린 배포가 진행되어 새로운 빌드가 실행되는 설계를 작성했다.

배포 프로세스

  1. github master branch push
  2. Webhook으로 travis CI 감지
  3. test, build
  4. 빌드 파일 압축
  5. 빌드파일 s3에 업로드
  6. s3에 업로드 된 파일을 Code Deploy에서 실행
  7. EC2내의 프로젝트 경로 찾아서 프로젝트 파일 갱신
  8. Docker Compose로 현재 instance가 3000포트로 띄워져있는지 체크하여 있으면 4000 포트 Docker Container 생성, 없으면 3000 포트 컨테이너 생성, 몇초 후 이전 띄워져있던 컨테이너 삭제

이 순서대로 작업을 하니, 서버 들어가서 일일히 재배포 하는 과정을 하지 않게되어 작업 능률이 상승했다. 빌드 되는 시간동안 다른 작업을 더 할수 있다는 장점이 존재했다.

글또 3기

글또모임은 올해 초부터 관심있게 봐왔다. 글쓰는 걸 좋아하는 나로써는 굉장히 천국같은 모임이었고, 최근 옅어진 열정을 다시금 타오르게 시킬 수 있는 계기가 될 수 있을거라 생각했다. 그래서 이번 3기에 지원을 하게 되었고, 운이 좋게도 많은 분들이 지원했지만 그 중에서 선정이 되어 3기에 참여하게 되었다.

각오

글또 3기를 하면서 열정을 다시금 불타오르게 하는 계기가 될 수 있으면 한다. 과거 병특을 할 때 블로그 글을 일주일에 한 개씩은 썻었던 것 같다. 그때는 지금봐도 글의 퀄리티가 별로 좋지 못한데, 이번에 글또를 진행하면서 매일 조금씩 작성해서 2주마다 나오는 글의 퀄리티를 누가봐도 좋은 글이라고 생각할 수 있게 작성하고싶다.

올해 초부터 지금까지 라이프사이클을 만들어왔다. 그러면서 글또 3기에서 참가하게 되었는데 이 기회에 라이프사이클에 글을 작성하는 루틴을 추가하는게 목표이고, 내 각오이다. 이건 내 라이플사이클을 바꾸는 일이니까. 거대한 일이다. 꼭 이뤄보이고 싶다.