안녕하세요. 2019년부터는 1달 간격으로 이번 달 어떤 개발을 했는지 간단히 정리하는 개발일지를 남겨보려고 합니다. 블로그 포스팅은 유튜브 활동과 책 집필 활동으로 할 시간이 많이 부족해졌습니다. 그래도 한 달에 한 번씩, 시간이 난다면 2주에 한 번씩은 회사에서 또는 개인 프로젝트에서 어떤 신기술을 사용해보았고, 소감이나 장단점은 무엇인지 정리해보도록 하겠습니다.
혹시나 서비스 개발에 관련해서 궁금한 사항이 있으신 분들은 댓글이나 메시지로 문의 주시면 대외비가 아닌 것들은 알려드리도록 하겠습니다.
서비스 출시
위케어라는 서비스를 출시했습니다. 요즘 일하고 공부하느라 운동을 자주 못하는데요. 그나마 영양제로 부족한 건강을 보충하고 있습니다. 그런데 영양제도 종류가 너무 많고 영양 성분도 어려운 용어가 많아서 뭘 골라야할지 어렵습니다. 그래서 저희 서비스는 간단한 설문을 통해 필요한 영양소를 알려드리고, 영양제는 랭킹 순으로 보여드립니다. 영양제에 관심이 많으시거나 몸이 안 좋으신 분들, 피로하신 분들은 한 번 이용해보세요~!
서비스는 React(Next) + Node + GCP(구글 클라우드 플랫폼) 스택입니다. GCP를 사용한 이유는 크레딧 2만 달러를 받았기 때문입니다. 구글의 스타트업 지원 일환으로요. 다음은 이 서비스를 출시하는 데 사용한 기술과, 기술에 대한 소감을 말씀드리겠습니다.
기술 스택
Redux + Redux-saga
요즘 GraphQL이 핫하지만 저는 Apollo를 클라이언트로 삼는 대신 리덕스와 리덕스 사가를 사용했습니다. 함수형 프로그래밍을 좋아하거니와 개발자가 저 혼자인 상황에서는 굳이 GraphQL을 사용해서 얻는 이득이 별로 없었습니다. 제가 프론트와 서버를 다 통제할 수 있기 때문에요. Redux-saga는 대체품으로 thunk나 Observable이 있지만 저는 saga가 테스트하기 쉬워서 씁니다. thunk는 기능이 부족하고요. Observable은 기능이 뛰어나지만 테스트가 어렵다는 평가가 있네요. saga가 제너레이터 기반이기 때문에 next만 호출하면 단계별로 테스트하기 쉽습니다.
Next
처음에는 Next.js를 쓸 생각이 없었습니다. 리액트로 서버사이드렌더링(상품별로 검색엔진 노출이 필요하기 때문에 SSR이 필요했습니다)을 한지 3년이 넘었기 때문에 자신이 있었거든요. 그런데 SSR에 필요한 componentWillMount가 deprecated되면서 상황이 좀 달라졌습니다. suspense라는 대체 기능이 나왔지만 서버사이드에서 사용할 수가 없었기 때문에(일해라 페북!) 서버사이드렌더링에 애로사항이 좀 생겼습니다. 거기에 redux-saga 액션을 렌더링 전에 미리 수행하는 것이 상당히 어렵습니다. 거기에 styled components와 redux state까지 모두 head와 body에 렌더링해야 해서 훨씬 복잡해집니다. 이런 것들을 Next와 next-redux-saga 패키지가 자동으로 해줍니다. 코드 스플리팅도 페이지가 많은 사이트에서는 필수인데 이 기능은 기본으로 딸려옵니다.
혹시나 개발 중에 내 사이트가 SSR이 되고 있는건지 판단하시고 싶으시면 절대 눈으로 하시면 안 됩니다. postman같은 프로그램으로 요청을 보내서 받아오는 HTML 태그에서 head, title, meta 태그와 body 부분이 제대로 들어있는지 확인하셔야 합니다. 구글같이 똑똑한 봇은 SSR이 아니더라도 어느 정도 긁어갈 수 있지만 다른 검색 엔진의 봇들은 그렇지 않은 경우가 많습니다.
아래는 SSR 적용이 완료되어 페이지별로 구글이 크롤링해간 모습입니다.
앞으로도 리액트로 프로젝트를 개발하면 Next를 사용할 것 같습니다. Vue라면 Nuxt를요.
Sentry
이번 프로젝트에서는 개발 인력이 매우 부족하기 때문에 에러 대응이 어려웠습니다. 그래서 Sentry 라는 서비스를 도입하였습니다. React같은 프론트엔드나 Node같은 벡엔드에 모두 붙일 수 있는 서비스입니다. 무슨 기능을 하냐고요? 바로 콘솔에 에러가 찍히면(console.error) 메일을 보내줍니다. 슬랙과 연동하면 슬랙 메시지로도 오고 다양한 방식으로 알림을 받을 수 있습니다. 개발자 개인이 테스트할 수 있는 양은 한계가 있기 때문에 고객에게 QA를 시킬 수 있는 조금은 꼼수같은 방법인데요. 고객들이 방문한 페이지, 방문한 경로, 기기와 브라우저 버전 등을 모두 알 수 있어 좋습니다. 노드에서도 마찬가지이고요. 개발 시에는 꺼두어야 console.log 위치를 제대로 파악할 수 있다는 점 기억하세요.
다음 이미지는 에러가 어떻게 표시되는지에 대한 예시입니다. 아랫 부분이 짤렸지만 stack trace까지 다 보여주어 매우 좋습니다.
다음 서비스 개발에도 무조건 쓸 예정입니다.
Puppeteer
저는 상당히 크롤링에 자신이 있습니다. 현재 노드로 크롤링 강좌도 제작 중이고요(유튜브에서 보실 수 있습니다!). 그래서 회사에서도 크롤링 기술을 적극 활용하여 다른 사이트의 가격이나 영양소 정보, 영양제 정보를 긁어오고 있습니다(이 때 쿠팡을 보면서 감탄한게 쿠팡은 rate-limit을 적용해서 크롤링을 빠르게 하면 차단하더라고요). 이 때 정말 도움이 되는게 퍼페티어 입니다. 헤들리스 크롬 브라우저인데요. 목이 없는(!?) 브라우저, 즉 화면이 없는 브라우저입니다.
아니, 화면이 없으면 어디에 쓸 수 있냐 궁금하실텐데요. 바로 프로그래밍으로 브라우저를 컨트롤할 수 있습니다. 즉, 서버에서 웹사이트를 방문하여 스크린샷을 찍어 저장한다거나, HTML 태그를 읽어 필요한 정보를 빼올 수 있습니다. 바로 크롤링을 할 수 있는 것입니다. 비슷한 툴로 셀레늄 이 있습니다만, 셀레늄은 보통 다양한 브라우저에서 자동 테스트를 할 때 쓰고, 크롤링은 간편한 퍼페티어로 하는 것이 좋습니다(퍼페티어는 크롬이기 때문에, IE에서만 방문할 수 있는 페이지라면 좀 슬프네요 ㅠㅠ).
직접 짠 코드로 브라우저가 알아서 페이지를 방문하고 크롤링을 해오는 모습을 보면 기분이 정말 좋습니다. 마치 말 잘 듣는 로봇을 하나 만든 것 같은 느낌이에요.
데이터를 주기적으로 긁어오게 되는데 주기적으로 긁어오는 것은 구글 클라우드의 cron 작업 기능 을 사용하고 있습니다. 크롤링 라우터를 하나 만들어두면 cron이 주기적으로 라우터에 요청을 보내줍니다. 아마도 AWS나 Azure도 비슷한 기능이 있을거에요.
Google Analytics
요즘 서비스를 출시하시면 기본적으로 구글 애널리틱스나 페이스북 픽셀 같은 것을 붙이시죠? 개발에 관련된 것은 아니지만 서비스를 운영할 때 지표가 되고 인사이트를 얻을 수 있습니다. 리액트에서는 react-ga 로 웬만한 기능을 다 사용하실 수 있습니다. 싱글 페이지 서비스이기 때문에(기본적으로는 페이지 전환이 기록되지 않습니다) 따로 해주어야 하는 것이 있긴 한데요. next.js example에 같이 사용하는 방법이 잘 나와 있습니다.
앞으로 해야할 것들
테스트
지금 개발자가 저 혼자인데다가 일정도 빠듯해 테스트를 제대로 하지 못하고 있습니다. 순수 함수들만 테스트를 하고 있고, 복잡한 리액트 컴포넌트나 익스프레스 라우터는 테스트를 못 하고 있습니다. 이러다보니 하나의 기능을 수정하면 다른 기능이 고장나는 현상을 빈번하게 겪고 있습니다. 그렇다고 테스트 코드를 쓰자니 서비스가 너무 확 바뀌는 경우가 많고, 일정도 맞추기 어려울 것 같아 난감한 상황이네요. 서비스가 안정이 되고 인력이 확충되는대로 테스트 코드를 작성할 예정입니다. 테스트 작성에 관한 것도 하게 되면 개발일지에 남기도록 하겠습니다.
캐싱 및 성능 최적화
일단 서버가 일본에 있음에도 속도가 빠르다는 평가를 받고 있어서 한 숨 돌렸지만 내부적으로는 매 번 DB 요청을 하는 등 스케일링에 문제가 될 소지가 많습니다. 불필요한 DB 요청을 최소화하고, 레디스나 localStorage 등에 데이터를 나눠서 저장하여 DB 요청을 줄이려고 합니다. DB 요청이 가장 병목이 많은 구간이기 때문입니다. 테이블이 30개가 넘어 JOIN이 많기 때문에 쿼리 튜닝도 해야할 것 같습니다.
이상으로 1월 개발일지를 마칩니다. 서비스가 더 성장해서 더 고급 기술들을 적용해 볼 수 있었으면 좋겠네요.
익명
