넥스트 13 with TS 마이그레이션 점진적 적용기

넥스트 13 with TS 마이그레이션 점진적 적용기

0. 적용 계기 

넥스트와 타입스크립트 를 쓰게 된 경위는 비교적 명확하다.

 

0-1) 타입스크립트 

 

기존의 레거시 코드는 뭐가 뭔지 알아볼 수 가 전혀 없었다. 타입을 달아두면 변수명이 다소 개판이더라도 바로바로 파악이 가능했기때문에 타입스크립트의 적용은  안전한 코딩 , 협업을 위해서라도 필수적이였다.

 

0-2) 넥스트 제이에스

 

추후 seo 활용때문에 옮기게되었다. 물론 seo 적용은 나중일이겠지만 그렇다고 그때가서 옮기기에는 너무나도 큰 비용이였다. 분명 리액트 라이브러리 만으로도 seo를 해결 할 수 있는 방법이 있겠지만,  서버사이드 적인 이점과 넥스트 자체에서 제공하는 프레임워크로써의 기능들을 활용해서 좀 더 편하게 빠르게 개발 할 수 있을것같다는 판단하에 바꾼것도 있다. 

 

다만 어디까지나 개인적인 소감으론 계속 버젼업이 되어서 그런지 몰라도 개발하면서 프레임워크 자체에서 발생하는 애로사항에 부딪힐때마다 개인적으로는 미완성된 느낌을 종종 받는다. 

 

그 밖에도 당시의 다른 백엔드 팀원이 강하게 하자고 어필해서 하게된 등의 부가적인 이유도있다. 

 

 

적용기를 나름 순차적으로 적어보자면 다음과 같은 절차를 따랐다.

 

 

1. 기술조사

현재 쓰고 있는 기술이 넥스트js를 적용한 후에도 적합할 것인가에 대한 주 조사를 하고 더 좋은 라이브러리나 호환성이 뛰어나다고 판단되는 (주로 다운로드 횟수로 판단) 라이브러리로 갈아끼우는 작업을 한 것같다. 

 

2. 컴포넌트 별 스펙 파악 및 전환 

기존의 코드는 확장성이나 재사용성이 크게 고려가 되지 않은 컴포넌트 들의 연속이였음으로 타입스크립트를 쓰면서 자동적으로 파악하고 한 번 알아가는 과정 또한 거치게 되어 현재 코드에 대한 이해 역시 높일 수 있었다.  아무래도 코드를 작성한 사람이 전부 퇴사하고 없다보니 이 작업이 제일 고됬다. 아주 최소한의 리팩토링만을 진행하면서 타입만 달아주며 컴포넌트 스펙을 전환하게 되었다.

 

작업 하면서 어려웠던 점은 레거시는 자바스크립트를 정말로 동적으로 사용하고있었다. 같은 변수가 변수명만 봤을때는 boolean이겠구나 했는데 쓰이는 초기값은 string 이였으며 중간에 함수를 거쳐서 타입이 두번 세번씩 바뀌기도했다. 정적 발상으로는 도저히 레거시를 파악하고 변환할 수 없었다

 

그래서 기존에는 타입스크립트로만 작업한지 꽤되어서 이런 타입스크립트적인 관점을 버리는데 다소 애를 먹었다. 

 

3. 배포방식

어떻게 보면 가장 큰 벽이였다. 그 동안에는 S3 와 클라우드 프론트로 배포가 되어있는 상태였으나 Next js로 바꾸게 되면서 그렇게 할 수 가없었다.

 

아니 사실 이것저것 시도는 많이해봤다. 정적 배포 옵션을 사용했지만 패치 버젼 하나 차이로 옵션을 지원하지않아서 다운그레이드를 하기도하고 버셀 깃헙 이슈를 정말 많이본 것 같다. 

 

막상 다운그레이드를 해서 정적옵션으로 배포를 하니 404의 렌더링방식의 차이가 해결되지않는다거나 로직이 정상적으로 동작하지않는다거나 하는 문제가있어서 어쩔 수없이 배포 방식을 바꿔야됬는데

 

EC2 로 배포해보니 뭐가 CPU 사용량이 튀기는것을 확인할 수 있었다. 물론 이건 사전 지식없이 그냥 시도한것이라서 더욱 그렇겠지만 포팅같은것 이외에도 vpc 같은 문제들 역시나 공존하고있어서 어짜피 당장엔 할 수 있는 상태는 아니였다 

 

그런 이유로 별수없이 마음에는 안 들지만 당장에는 Ampilfy를 사용하기로했다.  초기 스타트업이라 시간도 너무없거니와 내가 AWS를 알긴알지만 깊게 아는 건 아닌지라 이 역시 배우면서 점진적으로 적용해낭가며 배포 하기로. 그렇게 방향을 틀었다. 

 

4. QA

어찌 보면 3번 전일 수 도 있는데 다르게 보면 3번 후일수도있을 것 같아. 아무래도 상관없겠거니 싶어 그냥 4번에 적었다.

QA는 기존에 조금이였지만 남아있던 QA시트를 보고 참조하여 매우 간략하게 만들었다. 그러나 이는 쓰일일이없었으니...

기껏힘들게 마이그레이션 했건만 기획에서 거의 기존의 기획을 전부 다 엎어버리는 새로운 기획을 가져오는 사태가 마이그레이션 다 끝나고난뒤 생겼기 때문이였다

 

아무튼 개발자들이야 본인이 만든것에 대한 QA를 요청하기전에 수도없이 테스트를 해보니 사실 QA 작업이 여기에 꼭 적혀야되는 과정은 아니라고도 생각이들지만 일단 적어봤다.  

 

5. 결론

사실 마이그레이션 하면서 적용한 부가적인 일들이  많긴하다.

원래 거의 없다시피 하던 배포전략도 마이그레이션 하면서 동시에 적용시켰고 버져닝 개념도 들어갔다 

3차 기능이 끝나고 나는 주말에 나와서 내가 만든기능들을 빠르게 붙여나아가기도했고 

 

전체적으로 기존에 없다시피 한게 워낙 많다보니 사실 내 짬밥에 고민할 필요도없는것들을 굉장히 많이 고민하면서 적용해나아갔던 것같다. 

 

 

그래서 그런지 마이그레이션 중이나 후나 모든 과정이 의미깊게 느껴졌다.

 

사실 이번글은 의도한건 이런 느낌은 아니였으나 굉장히 추상적인 내용 밖에 없긴하다. 

 

추상적으로 적히게 된 것은 실제 근무한지 몇달 안되었다보니 일들이 굉장히 정신없이진행된 것이 가장 큰 이유이긴 하다. 

이미 쌩스타트업 고군분투 일기에서 언급은 몇번 됬다만 이런식으로 분리해서 적지않으면 결코 이야기할 일이 없을것같아 나름의 분리된 글을 시도해봤다.