로토의 블로그

2017년을 회고하며

2018년 새해를 맞이하여 2017년에 했던 일과 공부에 대해 생각해보며 회고하는 시간을 가져보았다.

Front-end

require.js 기반의 페이지를 webpack으로 전환

쿠팡을 퇴사하기 직전에 했던 작업이다.

기존엔 require.js 기반으로 JavaScript를 로딩해오도록 되어있었는데, r.js 등으로 최적화가 되어있지 않아서 로딩해야 하는 스크립트 모듈 갯수만큼 http call이 일어나는 상황이었다. 설상가상으로 모듈 중 하나라도 로딩에 실패하면 화면이 깨졌다.

이런 상황에서 기존 레거시 코드들을 이전에 프로젝트를 진행하며 만들었던 react + webpack 기반의 프로젝트로 이관 후, 이관을 마친 후에 require.js를 걷어내는 작업을 진행했다.

먼저 시범적으로 여행 상품 상세 페이지쪽에 작업을 진행했다.

대략 아래와 같은 require.js 기반의 모듈 코드를

// require.js style 모듈 정의
// text는 js 외에 파일들을 text 형태로 로딩해주는 require.js 플러그인이다.
// 주로 hbs 파일을 불러와서 컴파일해서 사용할 때 사용되었다.
define(['jquery', 'handlebars', 'modules/ModuleB', 'text!templates/ModuleATemplate.hbs`], function($, Handlebars, ModuleB, template) {
  // template 컴파일
  var compiledTemplate = Handlebars.compile(template);

// 무언가를 한다
…
…
var $target = $(‘#target’);
var someData = {};


return {

render: function () {
$target.html(compiledTemplate(someData));
}
};
}

아래와 같은 스타일로 변경하는 작업이다.

import $ from 'jquery';
import ModuleB from 'modules/ModuleB';
import template from 'templates/ModuleATemplate.hbs';

// handlebars-loader가 자동으로 컴파일 해주기 때문에 hbs 컴파일 필요가 없어짐


// var 키워드 let이나 const로 변경
const $target = $(‘#target’);
const someData = {};


export default {
render: function () {
$target.html(compiledTemplate(someData));
}
};

우선 기존에 세팅해둔 react.js + webpack 기반의 프로젝트에 webpack 설정에 handlebars-loader를 추가해주고, 모듈 로딩 부분, 변수 선언 부분, 그리고 모듈 export 부분을 고치는 작업이 주였다.

실제 작업은 4시간 정도 밖에 걸리지 않았는데, 아무래도 테스트를 꼼꼼하게 해야하다보니 테스트에만 1주일이 넘게 걸렸다.

테스트 및 적용은 사내 ABTest 도구를 통해 점진적으로 적용하는 식으로 했다. 가령 ABTest를 걸어놓고 A안인 경우는 기존 방식대로 모듈을 로드하고, B안인 경우는 webpack으로 만든 bundle을 로딩하는 식으로 설정한 뒤, A안과 B안을 90:10 정도로 건 다음 로그나 트래픽에 문제가 없다면 B안의 비율을 점점 높여가는 방식으로 전환했다.

결과적으로 아래와 같은 효과들을 얻었다.

  1. 극적인 latency 개선효과. 기존에는 모듈 수만큼 http call이 일어났는데 개선 후엔 bundle 하나만 로딩하면 끝났기 때문.
  2. 미사용 코드 추적 가능해짐
  3. 기존 레거시 스크립트들을 ecma2015 기반 문법으로 리팩토링 할 수 있는 여지가 마련됨.

아쉬운 것은 이 전환 이후 기존 jquery 기반 + 패턴이 중구난방인 js 코드들을 react.js 기반으로 싹 리팩토링 하고 싶었는데, 퇴사를 하는 바람에 거기까지는 못 했다는 점이다.

redux-saga

기존에는 redux에서 비동기 처리 작업이 필요한 경우 주로 redux-thunk를 주로 사용했었다. 그러다 스마트스터디에 입사 후 비슷한 시기에 입사한 손병대(닉네임 불꽃남자)에게 redux-saga에 대해 전수 받게 되었고 덕분에 redux-saga 쓰는 법을 익히게 되었다.

현재 개인 프로젝트(SpotShare)에 적용 중.

react-native

react.js 관련 학습을 계속 하면서 자연스럽게 react-navtive로 뭔가 프로젝트를 하고 싶은 욕구는 항상 있었다.

앱 개발은 2010년에 Android를 조금 공부한 정도가 다 였는데 react-native를 이용하면 앱 개발에 숟가락을 얹을 수 있지 않을까? 라는 불순한 생각에서 비롯되었다.

우선 프로토타이핑용으로 CatStory를 만들었다. 주로 앱의 카메라, firebase 연동을 통한 인증 등을 시도해봤고 이 경험을 정리하여 회사 동료들에게 공유하는 자리를 가졌다.

http://slides.com/rotoshine/try-react-native-to-web-developer#/ 는 그때 사용한 슬라이드이다.

토이프로젝트 말고, 이걸 실제 회사 프로젝트에 적용할만한 것이 뭐가 있을까 하다 회사 카페 앱이 없어서 회사 카페 앱을 만들면 좋겠다는 생각이 들었다. 그래서 CafeApp를 만들었다.

아쉽게도 api 연동 등을 하기 전에 퇴사를 해버려서 저 앱도 프로토타이핑만 한 셈이 되어버렸다.

어느정도 react-native를 사용하는 법과 네이티브 모듈과 연동하는 법은 익힌 상태.

이제 실전이 필요한데...2018년에는 회사에서 이걸로 뭔가 재밌는 거 만들 수 있었음 좋겠다.

next.js

next.js는 zeit에서 만든 react.js 기반 Server Side Rendering에 특화된 프레임워크이다. react.js에서의 Server Side Rendering은 이전에 SpotShare를 하면서 경험해봤는데, next.js가 상당히 좋다는 이야기만 여기저기서 주워듣고 본격적으로 토이 프로젝트에 적용하기 시작했다.

몇년 전에 angular.js 기반으로 만든 rotowiki 를 next.js 기반으로 싹 갈아엎는 작업을 하면서 다음과 같은 점들을 느꼈다.

  • 코드가 Client Side, Server Side 양쪽에서 실행되다보니 데이터를 로딩해오는 방식이 조금 특이하다.
       - 기존엔 Server Side에서 데이터를 미리 로딩해올 경우 mongoose model의 쿼리를 통해 데이터를 불러왔는데, next.js에선 코드가 양쪽 사이드에서 모두 실행되어야하다보니 Server Side에서 실행되더라도 fetch 등을 통해서 조회해오도록 만들어야 한다.
  • 코드가 Client Side, Server Side 양쪽에서 실행되다보니 isClient와 같은 플래그를 만들어서 써야할 때가 있다.
    • 대표적으로 fetch를 사용할 때인데, Client Side에서는 url이 상대경로여도 되지만(/api/documents) Server Side 일 때는 host를 포함한 full url이여만 한다.
    • 이 경우 Client Side에서도 full url을 만들어서 쓰면 되지만, 문제는 full url을 만들기 위해서 참조해야하는 객체가 Client Side 일 때, Server Side 일 때 각각 다르다는 점이다.
         - Server Side 일 때는 req 객체에 접근이 가능하고, 이 객체를 통해서 host 정보를 얻어올 수 있는데 Client Side에선 req 객체가 없다.

여튼 생각보다 신경쓸 부분이 많다. 그럼에도 불구하고 Server Side Rendering을 자연스럽게 가져갈 수 있는 부분은 큰 장점으로 보인다.

정리

  • require.js 기반의 프로젝트를 webpack 기반으로 바꾸는 작업 경험
  • redux-saga를 익혀서 SpotShare에 적용 중
  • react-native 학습
  • next.js 학습

Back-end

GraphQL

이전 회사에서 진행했던 프로젝트들은 처음엔 REST API 기반으로 되어있었는데 진행 중간에 GraphQL 도입이 시도되었었다.

비록 프로젝트는 중간에 드랍됐지만, Back-end 개발자와 협업하면서 커뮤니케이션 비용이 꽤 낮아졌던 기억이 남는다. 중요한 스키마와 모델만 잘 정의하면 필요한 데이터는 내가 알아서 query해서 꺼내다 쓰면 되니까.

좀 더 깊이 써보지 못한 게 아쉽다.

Python & django

잠깐 발 담궜던 프로젝트의 Back-end가 Python과 django 기반으로 되어있어서 겸사겸사 django를 공부했다. 깊게는 아니고 (django girls)[https://tutorial.djangogirls.org/ko/] 정도만 해본 수준.

근데 아무래도 Flask 와 같은 마이크로 웹 프레임워크를 선호하다보니, django 코드는 눈에도 잘 안 들어오고 그러다보니 깊게 경험하진 못했던 것 같다.

PostgreSQL

그동안 RDBMS는 주로 mysql을 많이 썼었는데 2017년에 처음으로 PostgreSQL을 써봤다.

근데 이것도 그냥 쓴 건 아니고, ORM 통해서 쓴거라 큰 차이점은 못 느껴봤다.

정리

  • GraphQL 맛만 봐서 아쉬움.
  • Python, django 역시 맛만 봄.
  • PostgreSQL는 혀만 갖다 댄 수준...

총 정리

좋았던 점

  • 레거시 코드를 개선해나가면서 성능과 가독성 모두를 향상시키는 귀중한 경험을 했다.
  • 다양한 토이 프로젝트를 했다. 특히 작년에는 react-native를 좀 해보면서 native app에 대한 경험도 약간이나마 쌓인 것 같다.
  • 회사를 옮기게 되면서, 같이 일하면서 시너지를 받을 수 있는 좋은 동료들을 만났다.
    • 결국 회사를 옮길 때마다 얻는 가장 좋은 점은 멋진 동료들을 알게 되는 것 같다.

아쉬웠던 점

  • 뭔가 만들었다라고 내세울 게 없다. 2016년에는 http://travel.coupang.com 의 Front-end 개발을 주도하면서 굉장히 많이 성장한 느낌도 들었고, 그 이전에도 매년 굵직굵직한 프로젝트들을 통해서 레벨업하는 느낌에서 오는 뽕이 충만했는데 2017년엔 그런 게 별로 없어서 무기력한 느낌을 받았다.
    • 실제로 회사 프로젝트를 하면서 배운 것보다, 개인 프로젝트를 하면서 배우고 익힌 게 훨씬 많다.
  • 2017년에 접했던 Back-end 관련에서도 많은 걸 배울 수 있었을텐데 그 기회를 제대로 못 살린 것 같다.

올해의 목표

  • 2017년에 느끼지 못했던 성장하는 느낌을 올해는 좀 더 받고 싶다. 작년에 못 받은 몫까지 더.
  • 끝내주는 웹앱 만들고 싶다.
    • UI/UX, 성능, 유용함 등
  • React-Native로 프로젝트 해보고 싶다.
  • Back-end에 대한 학습도 틈틈히 하자.

멋진 한 해가 되길 기대하며!

글 목록으로 돌아가기