리액트를 쓰기로 결정하고 보니, 이쪽이라고 배울게 마냥 적은것은 아니었다. 어차피 컴포넌트 개념에 대한 이해는 필요했고, 앵귤러에 타입스크립트가 있다면 리액트에는 JSX가 있었다. 심지어 JSX는 보기도 안좋았다. 앵귤러에 끌렸던 이유가 그 칼같은 분리 때문이었는데, 리액트는 무슨 자바스크립트 안에 HTML을 적고 있었다. 그래도 뭐 이걸 하기로 결정헀으니 시작했다.
좀 읽다보니, 차이가 눈에 보이기 시작했다. 앵귤러는 프레임워크기 때문에 그 안에서 모든 일을 다 할 수 있었다면, 리액트는 단순히 화면 렌더링 라이브러리에 가까워보였다. 이건 간편하면서도 또다른 문제를 낳았다. 회사의 목표는 쉽게 템플릿 하나로 여러 HTML을 찍어내는거였는데, 리액트는 분명 컴포넌트 구조를 통해 그런 일을 쉽게 하지만 그 자체를 하는 것은 아니었다.
오히려 우리에게 필요한건 템플릿 엔진.. 내지는 번들러와 같은 것들이었다. 그래서 번들러를 보기로 했다. 잠시 인턴으로 있던 개발자가 Parcel이라는 번들러를 사용했는데, 안에 바벨 플러그인을 끼우는데서 무슨 문제가 발생한건지 자꾸 트랜스컴파일이 안되는 현상이 있었다. 그래서 파셀은 쓰고 싶지 않았고, 그를 제하고 보니 있는 것들은 Grunt, Gulp, 혹은 Webpack 같은 조금 그 자체만으로도 러닝 커브가 있는 것들이었다.
대표는 대표대로 닥달을 하고 우리는 우리 나름대로 개발 일관성/편의성이 중요했기 때문에, 좀 더 나은 integration을 찾아다녔다. 그러다가 닿은 것이 개츠비다. 사실 예전에 들어본 적이 있었다. 지킬과 함께 개발자 블로그 만들기에 그렇게 좋다고 이야기를 들었었는데, 그때 당시만 해도 블로그에 대해 전혀 관심이 없었기 때문에 지나갔다.
단순히 블로그에 관심없던것 뿐만 아니라, 처음에는 매우 다양한 기능의 웹앱을 개발하고 싶었고 그렇기 때문에 서버도 모두 갖춘 구조를 지향했었다. 물론 막상 개발을 진행하면서 어떻게든 보여주기만 하면 된다로 변해 정적 웹사이트가 되버렸지만 말이다.
그런데 지금은 또 얘기가 달랐다. 어차피 정적 웹사이트가 되었는데, 개츠비를 안쓸 이유가 거의 없던 것이다. 심지어 리액트 문서에 따르면 개츠비는 정적 웹 사이트 생성기로, 우리가 원하는 모든 기능이 있을 가능성이 매우매우 높았다. 실제로 찾아볼수록 더 확신이 생겼다.
그래서 기술 기반을 개츠비로 변경하기로 결정을 한 뒤, 나와 다른 개발자가 각각 튜토리얼 및 공식문서 독파를 시작했다.
개츠비 진행과는 별개로, 리액트 자체에 대한 이해도를 좀 올려야겠다는 생각을 하고 있다. 그런데 마침 QA 일을 대표가 건네주는 것이다. 기회라고 느꼈다. 핑계 삼아서 TDD(Test-Driven-Development) 리액트를 읽기 시작했다. 제법 재밌는 것 같다.