TIL

[TIL] 2022/12/18 한달 회고록, 모노레포, Nextjs, SEO, 아키텍쳐 1

youngble 2022. 12. 18. 20:04

한달 넘도록 블로그관리를 하지 못했어서 한달 회고록파트12로 나누어서 쓰려고한다.

SEO

먼저 내가 담당했던 서비스의 마케팅부분에서 구글 SEO가 제대로 잡히지 않아 급하게 프로젝트를 다시 내부적으로 교체해야하는 상황이 왔었다.
어느정도 서비스가 잘이루어져서 구글 Ads페이스북을 통해 마케팅 광고를 시작했는데 예전에 최적화하지 못했던 SEO부분때문에 빠르게 최적화를 하지못한다면 많은 고객을 받지 못하는 상황이 되기 때문에 가능하면 빠르게 대안을 찾아야한다고 전달 받았었다.

모노레포

선택지를 몇가지 주었다. 모노레포 라는 개념으로 프로젝트를 만들어서 SEO에 필요한 페이지에 대해서 따로 라우팅을 잡아서 배포하는 부분이 첫번째 제안이었고 두번째는 Next.js로 필요한 페이지를 부분이관이 가능한지 아니면 모든 페이지를 Nextjs 프로젝트로 이관해야하는 선택지, 마지막은 결국 SEO는 메타태그와 크롤러가 미리 읽을수 있는 태그들이 필요한것이기 때문에 react-static을 사용해서 정적페이지를 미리 구축하는 것이였다.

결론부터 말하자면 Nextjs로 전체 이관을 하기로했다. 이유는 빠른시간안에 바꿔야한다고 해도 모노레포라는 개념을 이해하고 그것을 기존 프로젝트를 모노레포 프로젝트로 셋팅을 바꾸고 용으로 사용할 라이브러리를 셋팅하는 것에 대한 이해도 필요하고 그런 시간을 드릴바에는 SEO 최적화에 잘이루어진 Nextjs에 시간을 투자하는게 맞다고 생각했다. 선택전에는 먼저 모노레포라는 개념을 잡고 어떻게 셋팅을 해야하는지 알아보았다. 모노레포의 개념은 이해했지만 모노레포를 적용할때 사용하는 yarn workspace, npm workspace, turbo, nx, Lerna 등 많이 있었고 처음에는 yarn workspace를 선택하여 진행하려고 했다. 이유는 많은 레퍼런스 제공과 가장 많이 사용하고 있기 때문이었다.

하지만 팀원중 한명이 nx의 장점을 이야기하고 하고싶어하는거 같아서 중간에 바꾸기는 했다. 솔직히 nx로 바꾸고싶지 않았다 리스크도 클거같았다 레퍼런스도 많이없었고 세팅은 좀더 쉽지만 디테일하게 들어가면 오히려 그게 발목을 잡는다고 한다면 결국 나중에 다시 바꿔야했기 때문이다. 하지만 이게 좋네 저게 나쁘네 할만큼 시간이 충분하지 않았고 그렇기 때문에 이런곳에서 시간을 뺏고 싶지도 않아서 그렇게 하기로 했다.

nx로 셋팅을 하려고 했는데 솔직히 업무중에 해당 서비스 내부를 동시에 바꾸는 과정에서 집중할 수 있는 상황이 아니라서 힘들었고 계속해서 다른 업무로 미뤄지고 미뤄지다가 시도를 해볼때는 이미 일주일이 지난 상태였다. 조급한 상태로 겉할기식으로 구축을 할려고하니 안되는것도 많았고 프로젝트를 만들어도 제대로 돌아가지않고 알수 없는 에러들이 발생하였다. 이부분 때문에 솔직히 많은 스트레스를 받았는데 업무는 업무대로 계속 생기면서 내부를 바꿔야하는 상황과 최대한 빨리해달라고하였고 재택은 줄고 출근은 길어져서 공부할 수 있는 시간, 업무에 투자할수 있는 시간, 컨디션은 점점 최악을 달리고 있었다. 일은 병렬로 하되 주어진 시간은 촉박하고 투자할 시간도없는 상황.

이부분에 대해서 회사와 스케쥴 조율을 하고싶었지만 쉽지 않은 부분이었고 약 2~3일동안 nx셋팅도 해보고 react-static도 구현을 해보았지만 결론적으론 많은 제약과 정해진 시간동안 습득할수 없는 한계에 부딪혔고 그런 와중에 CTO분께서 결론적으로 어떻게 진행이 되고있고 결론이 났는지 말하기를 원했다. 그래서 Nextjs로 하는게 맞다고 이야기 드리고 그렇게 진행하기로했다.

AWS S3 Bucket 배포

Next로 이관이 결정하기전에 모노레포를 이해할때 실험을 몇가지 하고싶었다. 모노레포 개념으로 프로젝트를 자동으로 생성할수도 있지만 결국 모노레포라는 개념이 다른 라우팅 페이지에서 같은 레퍼지토리에 다른 프러젝트의 환경을 구축하여 해당 라우팅으로 배포한다는 개념이었다. (이부분에 대해서는 추후에 자세히 다뤄보도록할려고한다. 왜냐하면 모노레포의 정의와 생긴 배경은 방금 설명한것과는 조금 다른 이야기이기 때문이다.) 그래서 그전에 배포했단 S3에 다른 라우팅 폴더를 만들고 배포를해서 어떤식으로 되는지 확인해보았다. 예를들어 /customerService 라는 경로의 페이지를 별도의 다른 프로젝트로 배포하는것이다.

S3 배포를할때 build된 폴더안의 파일들을 업로드하게되면 자동으로 / 이라는 경로와 그 프로젝트 안에서 작동하는 라우팅에 의해서 /adc 와 같은 경로도 갈수 있게 되는것인데, 별도의 폴더를 만들고 그안에 프로젝트를 넣게 되면 그것만의 별도의 라우팅을 잡히게 되었다. 모노레포 라는 개념과 취지와 SEO 최적화와는 조금 다른 컨셉이긴 한데 어떤 시각으로 보고 구축하는지에 따라 여러 특색이 있는거 같다. 모노레포에 관해서는 추후에 제대로 정리할려고 한다.


그렇게 배포를 해보니 어떤게 모노레포인지 개념이 확실하게 이해는 되었지만 이런방식으로 배포가 어려웠던점이 S3로 폴더를 만들어 별도의 라우팅페이지 폴더를 만들어도 폴더이름에 자동으로 '/' 가 붙게되어 문제가 되었다 예를들어 나는 www.Domain.com/test 라는 별도의 경로 페이지의 폴더를 만든다고할때 이름을 /test 라고 지으면 자동으로 /test/ 라고 생성된다. 이것이 문제가 되는것은 웹 뿐만아니라 어플로써 서비스를 하고 있고 하이브리드 방식으로 웹뷰를 사용하는데 이때 웹뷰에서 어플로 들어올때 해당 도메인 경로 파라미터뒤에 쿼리스트링 값을 넣어서 마케팅용 쿼리를 사용하고 있었기 때문인데 만약 / 가 붙게되면 test?device=apple 이런식으로 되는게 아니라 /test/?device=apple 라는 방식이 되어 쿼리스트링을 가져올때도 기존과 달라진다.

어쨌든 이런 짜잘짜잘한 문제와 여러 리액트 프로젝트를 폴더구조로 라우팅을 만든다 하더라도 프리랜더링 되지 않고 결국 빈 index.html만 크롤러가 잡기 때문에 모노레포로 리액트를 나눈다고 해도 SEO를 최적화할 수 없었다. 그래서 react-static 을 이용하려고 했는데 이것도 결국 프레임워크처럼 고정적 템플릿을 프로젝트로 셋팅해서 사용해야하기 때문에 이렇게 할바에는 nextjs 로 하는게 맞다고 생각이 들었다.

프론트엔드, 백엔드 서비스 아키텍쳐 이해

위의 일련의 과정을 겪는동안 회사에서는 임시로 SEO를 최적화 하기위해서 예전방식의 JSP형식으로 정적페이지를 만들어서 meta태그와 해당 내용들이 구글에 검색될수 있도록 하였다. 이과정을 지켜보면서 그전에는 리액트만 사용하여 프로젝트를 배포해보았던 경험과 시야만 있었는데 정적페이지를 구축하기위해 만든 서버에서 jsp로 배포, 순수 html, js,css파일로 구축, 정적페이지에서 동적페이지(기능과 화면이 바뀌는 페이지)에서는 기존 서비스 리액트로 연결해주기 위한 리다이렉트를 하는걸 보고 리액트, vue, angluar, next 등 딱 이거만 사용한 아키텍쳐를 구축하고 서비스를 배포하고 사용한다라는 개념을 벗어나 여러가지 다른 스택과 언어를 섞은 아키텍쳐로 한프로젝트에 담아낼수 있구나 하는 이해와 시야가 생겼다.

CTO분께선 예전에도 이야기 한적이 있다. '결국 리액트든 vue든 jquery든 비즈니스를 만들기위한 수단과 도구일뿐이다' 라고 말이다. 어쨌든 nextjs로 구축하기 전까지는 SEO를 최적화를 하기위해선 현재 프론트엔드나 스타트업에서는 사용하지않은 예전방식(?)과 스택인 jsp 또는 기본 html파일을 만들어서 비즈니스적으로는 더 효율적인것을 보고 '아 정말 어떤방식을 선택하든 비즈니스를 구축할 수있는 안목과 여러 방안을 이렇게 선택하여 구축할수 있구나' 깨달게 되었다. 솔직히 수단과 도구일뿐이라고 해도 내 커리어이고 그 디테일에 대해서 쉽게 도구일뿐이다 수단일뿐이다 라고 받아들이고 싶진 않았다. 그만큼 진지하게 생각했기 때문이었고 가볍게 보는건 아닌가 하는 생각도 들었다. 경영진의 눈으로 보는지 개발자의 눈으로 보는지에 따라 다르기도 하기때문에.. 하지만 이런 상황을 보니 수단과 도구를 어떻게 선택하여 해결하는지 보게되었어서 여러모로 다른 시각과 시야가 생긴 기분이었다.

그래서 이렇게 돌아가고 있는 아키텍쳐의 큰틀을 이해하고 싶어서 CTO분께 JSP형식으로 배포된 서버는 AWS에서 어떻게 배포하고 구동하고 있는지 여쭤보았고 이에 대해서 docker, 로드벨런싱, 클러스터(?) 등 백엔드 서버와 가상컴퓨터관련 여러가지 큰 흐름에 대해서 설명해주셨는데 큰틀은 이해하게 되었지만 해당 용어와 디테일한 내용들은 알수 없었기 때문에 따로 키워드들만 적어두었다. 지금 이걸 쓸땐 개인컴퓨터로 작성중이라 위의 docker, 로드벨런싱 등이 회사컴퓨터에 있어서 키워드는 지금 적진 못하지만 추후에 따로 공부하기위해서 메모해두었었다.

따라서 서비스의 아키텍처에 대해서 좀더 폭넓게 이해하게되면서 컴퓨터 CS의 중요성도 알게 되고 시야가 넓어짐과 동시에 기초를 탄탄히 공부해야겠다는 생각이 절로 들었다. 백엔드 뿐만아니라 프론트엔드의 SEO관련 이슈, SSR, SSG, SPA, CSR 등 이번기회에 어떤 흐름이고 어떻게 돌아가는지 피부로 느꼈던 계기였다.

Next이관관련 해서는 한달회고록2 로 나누어서 작성하고 이 글은 여기에서 마무리 해야겠다.








'TIL' 카테고리의 다른 글

[TIL] 리랜더링 방지 최적화  (0) 2023.03.15
[TIL] HTML의 파싱 feat. ChatGPT  (0) 2023.02.26
[TIL] 2022/11/06 회고록  (2) 2022.11.06
[TIL] 디자인 시스템, 그리고 성장  (1) 2022.10.15
[TIL] 앞으로의 계획, 지난 회고  (3) 2022.10.11