🌱 2년 전, 왕초보 개발자가 서비스를 출시하기까지의 기록 (#3)
당시 프론트엔드는 html 과 css를 다루는 것이라고만 알고 있어서 흥미가 없었다. 내심 ‘백엔드 개발자로 취직할건데 프론트엔드 알아서 뭐해’ 라는 마음도 있었다. 그래도 이미 프로젝트를 하기로 수락했으니 어떻게든 해내야 했다. 나는 보통 라이브러리나 프레임워크를 공부할 때 하나의 애플리케이션을 만들어보며 학습을 하는 편이다. 학습을 위한 토이 프로젝트 주제를 뭐로 할지 생각하다가, 어차피 서비스를 만드는 게 목적이니 이 서비스의 프로토타입을 만들기로 했다.
🖼️ 프론트엔드는 재밌다
프론트엔드 라이브러리로는 React.js를 선택했다. 특별히 다른 라이브러리보다 이점이 있어서라는 이유는 아니었고, 단순히 프로젝트와 비슷하게 생긴 애플리케이션을 만드는 강좌에서 React.js를 사용해서였다. 그때 본 내 첫 프론트엔드 강좌가 Nomadcoders 의 ReactJS로 영화 웹 서비스 만들기 였다.
프로젝트를 완성하려면 프론트엔드를 해야 하니까 시작했지만, 예상 외로 프론트엔드는 재밌었다! 그냥 html 과 css가 다라고 생각했는데 전혀 아니었다. 사용자랑 상호작용하는 화면을 만들고, 그 화면이라는 결과물이 코드를 작성하면 바로바로 나오니까 성취감이 엄청났다. css로 꾸미면 그럴듯한 사이트가 완성돼서 더욱 그랬다. 순간 백엔드 말고 프론트엔드로 취업할까? 하는 생각이 들 정도였다.
성취감 덕분에 관심 없었던 프론트엔드 분야를 공부하는 시간이 즐거워졌다. React.js를 깊게 파고들지는 못했지만, state 에 따라 화면이 어떤 과정을 거쳐 렌더링되는지, 복잡한 컴포넌트를 만들 때 html 의 구조를 어떻게 잡아야 할지, 길고 긴 css 를 정갈하게 작성하기 위해 class-name 을 어떻게 짓는 것이 좋은지를 알게 되었다.
백엔드 개발자 입장에선 조금 아이러니한 말이지만, 그 전에는 완성하는 데에만 급급했다면 이때가 처음으로 ‘내가 사용하는 프레임워크나 라이브러리가 어떻게 동작하는지, 어떻게 최적화할 수 있는지’ 라는 질문이 생기고 '코드를 어떻게 깔끔하게, 알아보기 쉽게 작성할 수 있을지' 를 고찰해본 때였다. 이런 질문들은 백엔드를 길로 택한 지금까지도 내가 서비스를 완성하는 것 다음으로 가장 중점으로 두는 것들이다. (그렇게 몇달 뒤 내 책장에는 클린아키텍처, 클린코드 등등의 책이 꽂히게 된다…)
강좌에서는 OpenAPI를 사용했지만 나는 직접 개발한 API를 사용했기 때문에 프론트엔드가 백엔드랑 어떻게 통신하는지, 웹 통신의 전반적인 흐름도 알게 되었다.
이 경험 덕분에 단순히 프론트엔드를 경험한 것을 넘어서 이후 회사에서 간단한 페이지를 요구하면 뚝딱 만들어낼 수 있었고, 다른 프로젝트에서는 프론트엔드 개발자와 소통을 수월하게 할 수 있었다. 백엔드라고 해서 백엔드만 공부하면 안된다는 말을 십분 이해하는 순간이었다.
🍪 나름대로 적용해본 캐싱
한창 무료 호스팅을 찾아 헤매며 비용 걱정과 트래픽 제한에 대한 걱정에 휩싸인 나는 어떻게 하면 api를 호출하는 빈도를 줄일 수 있을까 하는 고민을 계속 했다. 그렇게 찾은 방법은 로컬스토리지를 이용하는 것이다.
데이터팀은 수집한 데이터를 2주에 한번 혹은 1달에 한번 주기로 업데이트를 했다. 그래서 DB 내용이 그 기간동안에는 바뀌지 않았다. 그럼 그 데이터를 로컬스토리지에 업로드해두고 데이터 업데이트 주기에만 새로 갱신해 API 호출을 줄일 수 있도록 구현했다. 대신 데이터를 필터링하는 기능을 오로지 프론트엔드에서 전부 구현해야 하는데, 당시 총 데이터 수가 800여개 정도 뿐이어서 속도 이슈는 생기지 않았다.
데이터 업데이트 여부는 데이터가 업데이트될 때마다 로컬 스토리지의 신규 key와 기존 key값을 수동으로 바꿔주는 식으로 구현했는데, 이걸 자동화해야겠다는 계획은 여러 사정으로 프로젝트가 동결나 결국 적용하지는 못했다.
사실 이걸 캐싱이라고 하기에는 애매하다. 그렇지만 api 호출을 어떻게 줄일 수 있을지 나름대로 고찰해보고 그 방법을 적용해봤다는 점이 의미있다고 생각한다. 2년이 지난 지금도 클라이언트 측, 서버 측 캐싱을 다뤄본 적이 없어서 이번에는 이 부분을 더 알아보고 적용해보고 싶다.
🖥️ 웹 서비스 배포
정적 페이지는 Github Pages 로 배포했다. 프론트엔드 호스팅은 무료 호스팅 정보가 워낙 많았고 서버 호스팅보다 비교적 간단해서 순식간에 끝났다. 물론 github pages 도 트래픽 제한이 100GB 지만 소규모 프로젝트를 배포하기엔 충분하다고 생각됐다.
만약 BrowserRouter 를 썼다면 Github Pages가 SPA 를 지원하지 않아 생기는 여러 이슈가 있었겠지만, HashRouter 를 써서 배포 도중 별 다른 이슈가 있지 않았다. 다만 그때는 CD 라는 개념을 몰라서 프로젝트를 직접 build 한 뒤 빌드 파일을 gh-page 브랜치에 pull 했다…🙄
💫 도메인을 달다
백엔드와 프론트엔드 호스팅이 무사히 마무리된 후, GitHub Pages의 기본 URL을 namecheap 에서 구매한 나름 .com으로 끝나는 우리 서비스의 자체 도메인으로 변경했다. 개발하면서 실컷 본 화면이었지만 우리 서비스 도메인으로 접속해서 볼 때는 새삼 감회가 새로웠다.
드디어 완성!… 이면 좋았을텐데, 아직 끝이 아니다. 테스트와 운영 등등의 개발 외적인 이야기가 남아있다. 글이 길어져서 마찬가지로 다음에 계속…