팀의 메인 목표는 오가닉 트래픽을 늘리는 것이였고, 마케팅과 같은 회사의 자원을 지원받기는 힘든 상황이였다..
즉, 팀의 자력으로 문제를 해결해야 했는데, 프론트엔드의 코드베이스는 CRA 기반의 프로젝트로 구성되어있어 SEO 최적화 또한 힘든 상황이였다.
오가닉 트래픽을 늘리기 위해서는 SEO 최적화를 통해 검섹 엔진에 노출이 많아야하는 상황이였다.
기업 정보를 크롤링해 사용자에게 제공하는 사이트다보니 사람들이 알음알음 자주 들어왔다.
게다가 많은 커뮤니티에서 사이트의 링크를 공유하다보니 백링크도 꽤 많이 발생하고 있었다.
하지만 우리 목표는 트래픽을 늘리는 것이고, 우리 타겟은 우리 사이트를 알지 못하는 잠재적 고객들이다.
이미 기본 트래픽이 있고 백링크도 꾸준히 생기고 있으니 SEO 최적화만 잘 진행한다면 기업 페이지가 검색엔진에서 노출이 잘 될것이고, 트래픽도 올라갈거라 판단했다.
SEO 최적화는 트래픽을 올리는 이미 검증된 전략이였고, 현재 상황에서 Next.js가 적절한 솔루션이라고 판단했다.
(참고로 Indeed는 구직자를 유치하기 위한 주요 전략으로 SEO를 선택했다. (링크추가))
그러나 운영중인 서비스를 중단 없이 Next.js로 교체하는것은 너무나 큰 리스트였다.
먼저 팀에 현재 가지고 있는 문제와, 이에 대한 해결책을 함께 제시했다. 너무나 당연하게도 팀에서는 우려를 표했다.
현재도 잘 동작하고 있는 서비스 전체를 완전히 교제하는 것은 프로젝트 담당자, 개발자 모두에게 큰 부담이다.
무엇보다 중요한건 서비스의 안전성이다.
예상치 못한 문제가 발생했을때 즉시 이전 서비스로 복구할 수 있도록 준비가 필요했다.
검색을 해보니 Canary deployment가 우리에게 딱 맞는 해결책으로 보였고, DevOps팀에 상황을 설명하고 현재 인프라 환경에서 기술적으로 가능한지 검토를 요청드렸다.
다행히 문제없이 적용 가능하다는 피드백을 받았다.
배포는 Canary로 간다..!
롤백 시나리오에 대한 기술 검토를 마쳤고, 이제 배포를 방식에 대해 동료 개발자와 고민했다.
우선 Next.js로 프로젝트를 기존 프로젝트가 아닌 새로운 레포지토리에서 진행하기로 했다.
산규 프로젝트는 QA를 위해 완전 배포까지는 별도의 도메인으로 운영하고, Canary deployment를 통해 트래픽 가중치를 조절하며 기존 서비스와 병행 운영한다.
신규 프로젝트의 안전성을 최종적으로 검토한 후, 문제가 없다 판단되면 변경 계획을 수립했다.
팀원들을 다시 한번 설득하는 자리를 가졌다.
변경을 통해 우리가 얻을 이점과 문제가 발생했을때 어떻게 대처할지에 대한 구제척인 계획을 공유했다.
여전히 우려하는 지점이 있었지만 너무 감사하게도 모두 한번 해보자는 의견을 주었고, 그루밍 스프린트 2주와 별도의 기간 2주, 총 한달의 작업시간을 확보할 수 있었다.
(설득이 되지 않으면 다른 방향으로 고민을 해볼 계획이였다.)
기존 코드가 레거시화되어 유지보수가 어려운 또 다른 문제가 있었다.
동료와 역할을 나눴다. 동료는 Next.js 개발 환경을 구축했고, 나는 기존 코드를 Next.js에 맞춰 리팩토링하기로 했다.
리팩토링을 시작하기 전, 기존 디렉토리 구조가 중구난방으로 관리되고 있어 이를 먼저 정리할 필요가 있었다. 논의 끝에, 도메인 기반으로 디렉토리를 구성하는 feature based 구조 구조를 적용하기로 결정했다.
구조가 정리된 후, 기존 코드를 Next.js 방식에 맞게 리팩토링을 진행했다.
리팩토링이 마무리되어서 Next.js 프로젝트로 코드 마이그레이션도 완료했다. 남은건 배포 프로세스.
기존 프로젝트는 S3에서 정적 파일을 호스팅하는 방식이었기 때문에 그대로 재사용할 수 없었고, 다른 팀에서 사용 중인 배포 방식을 참고해 Next.js의 AWS 워크로드를 구성하고, Docker 설정 및 GitHub Actions 기반의 CI/CD 파이프라인을 추가했다.
우여곡절이 많았지만 배포에 성공했다!
QA 진행을 위해 테스트 시나리오를 작성했다.
QA는 크게 디자인, 기능 테스트, 데이터 테스트 3개로 진행했다.
먼저 동료 개발자분과 1차 테스트를 진행하며 발견된 이슈를 수정했고, 이후 팀원들과 함께 테스트를 수정했다. 디바이스, 데스크탑 브라우저별로 각 테스트 시나리오 시트를 만들고 동료들에게 전달했다.
기능이나 디자인은 어렵지 않았지만 데이터를 테스트 할 때가 조금 까다로웠는데, 동시에 QA를 진행하면 본인의 액션으로 인해 이벤트가 전송된건지 구분하기가 어려웠다.
그래서 앰플리튜드의 user property를 이용해 QA 진행 전 임시로 만든 폼에서 사용자 이름을 입력하고, 그 값을 user look up 페이지에서 이벤트가 잘 전송되는지 독립적으로 진행할 수 있었다.
덕분에 각 테스트가 독립적으로 진행될 수 있었고, 이벤트가 정상적으로 전송되는 것을 확인할 수 있었다.
QA를 마치고 드디어 배포일이 다가왔다.
팀원들은 최종 테스트를 준비했고, 나는 동료 개발자와 함께 Sentry로 에러 모니터링을 담당했다.
DevOps 엔지니어는 Canary deployment의 트래픽 가중치를 조정할 준비를 마쳤다.
DevOps에서 트래픽 가중치를 2로 설정했고, 전체 트래픽의 1/5이 새로운 프로젝트로 유입되기 시작했다.
QA를 철저히 진행했음에도 예상치 못한 에러가 발생했고, 트래픽 가중치를 다시 0으로 줄이면서 문제를 수정한 후 배포 및 모니터링을 반복했다.
크고 작은 이슈들이 발생했지만, 3일간의 모니터링을 거쳐 안정성을 확인했고, 이후 새로운 프로젝트의 트래픽 가중치를 10으로 설정하며, 마침내 프로젝트를 성공적으로 마무리했다!
실제로 확보받은 기간은 한달이였지만, 개발자 동료분과는 거의 3개월정도 준비했다. (주말, 야근, 심지어 추석에도..)
이번 프로젝트 이후 게재순위와 트래픽이 꾸준히 증가했고, 이후 회사에서 SEO의 중요성을 인식하는 계기를 준 프로젝트가 되었다.
이번 프로젝트에서 얻은 갚진 소중한 경험이 너무나 많지만 몇가지로 추리자면
이 프로젝트는 내 커리어에서 큰 전환점이 되었다.
개발은 단순한 코드 작업이 아니라, 문제를 해결하는 강력한 도구임을 다시 한번 체감했다.
무엇보다도, 풀고자 하는 문제가 명확하다면 어떤 어려움도 해결할 수 있다는 자신감이 생겼다.
긴 시간 동안 도전하고, 설득하고, 팀과 함께 문제를 해결하며 얻은 경험들은 앞으로 어떤 프로젝트를 맡든 소중한 자산이 될 것이다.