- Published on
상용 CCS: 글로벌 서비스 개발 경험에서 배운 점
- Authors
- Name
- Justart
목차
- 개발 이야기
- 타입스크립트로의 전환
- 타임존의 세계
- Webpack에서 Vite로의 전환
- 보안 점검
- 마치며
1. 개발 이야기
두 개의 프로젝트를 동시에 개발을 하면서 프로젝트에서도 각각 두 개의 권역(유럽/북미)를 서비스 할 수 있게 개발이 진행되었다.
타입스크립트로의 전환
프로젝트를 시작하기 전에 리액트 버전을 올리고 시작하게 되었는데 기존 레거시들과 라이브러리들이 버전을 올리면서 충돌하는 이슈가 있었다. 그래서 하나씩 잡아나가서 에러는 제거했으나 원하는 기능이 제대로 작동 하지 않을 때가 종종 발생했다. 자바스크립트로 되어있어서 디버깅이 힘들었기에 시간은 걸리더라도 타입스크립트로의 전환을 하기로 했다.
한 번에 모든 파일을 마이그레이션 하기에는 일정이 있어 점진적으로 적용하기로 했다. 그래서 자바스크립트와 타입스크립트 두 파일을 컴파일이 잘 될 수 있도록 구성하였고, 점진적으로 진행하였다.
이후 페이지들은 모두 타입스크립트로 작성되었다. 처음에는 타입스크립트를 사용하는 것에 조금의 반감은 있었다. 작업 속도가 잘 안나기 때문이였다.
하지만 점차 익숙해지니 오히려 예측 가능한 상황에 놓이게 되니 디버깅 하는 시간이 많이 줄었다. 자바스크립트로 개발했었을 당시에 잘구현했는데 안되는경우 시간을 많이 소비했는데 결국 오타문제였던 과거를 돌이켜보면 타입스크립트의 찬성파가 되었다.
타임존의 세계
글로벌 서비스를 개발하다보니 배치 데이터를 보여줘야할 때 건수가 안맞는 등 예상한 데이터가 안나오는 경우가 있었다. 처음에는 단순히 데이터 집계 로직 문제라고 생각했는데, 파고 들어가보니 결국 시간 기준이 서로 달랐던 경우가 많았다.
내수를 개발할 때는 크게 신경쓰지 않았던 부분이지만, 글로벌에서는 타임존 자체가 중요한 조건이 된다. 같은 시각에 들어온 데이터처럼 보여도 어느 지역 기준으로 하루를 끊느냐에 따라 오늘 데이터가 되기도 하고 어제 데이터가 되기도 한다. 여기에 서머타임까지 겹치면 생각보다 훨씬 복잡해진다.
이 과정에서 위치 정보와 시간 개념이 생각보다 연결되어 있다는 점도 다시 보게 되었다. 차량에서 들어오는 값에는 위도와 경도가 있는데, 여기서 경도는 동경과 서경으로 나뉜다. 결국 동쪽에 있느냐 서쪽에 있느냐에 따라 기준 시간이 달라지고, 이것이 타임존과 자연스럽게 이어진다.
물론 실제 서비스는 경도선만 안다고 해결되지는 않았다. 타임존은 단순히 지리 개념으로 끝나는 것이 아니라 국가별 정책과 서머타임 적용 여부까지 같이 봐야했기 때문이다. 즉 좌표를 알고 있다고 해서 바로 시간 기준을 확정할 수 있는 것이 아니라, 그 좌표가 어떤 시간대 규칙을 따르는지까지 함께 봐야 했다.
이런 부분은 개발 초기에는 잘 체감이 안되는데, 운영 데이터가 한 번만 어긋나기 시작하면 굉장히 크게 느껴진다. 이때부터는 날짜나 시간을 볼 때도 무조건 "이 값은 어느 타임존 기준인가"를 먼저 확인하는 습관이 생겼다. 지금 돌아보면 글로벌 서비스를 만든다는 것은 단순히 여러 나라에서 동작하게 만드는 것이 아니라, 시간의 기준이 여러 개라는 사실을 받아들이는 일에 더 가까웠다.
Webpack에서 Vite로의 전환
Webpack에서 Vite로 전환한 가장 큰 이유는 단순히 속도 때문은 아니었다. 물론 개발 서버를 띄우는 속도나 반영 속도도 무시할 수는 없었지만, 실제로 더 크게 느꼈던 것은 오래된 레거시 환경을 계속 끌고 가는 것 자체가 점점 부담이 된다는 점이었다. 프로젝트가 길어질수록 의존성도 쌓이고, 빌드 환경도 예전 방식에 많이 묶여 있었는데, 이 상태로 계속 가다 보면 언젠가 보안 점검이나 라이브러리 취약점 대응에서 더 크게 발목을 잡힐 수 있겠다는 생각이 들었다. 그래서 이번 기회에 번들링 환경도 같이 정리해야겠다고 판단했다.
처음에는 단순히 "잘 돌아가고 있는데 굳이 지금 바꿔야 하나?"라는 생각도 있었다. 하지만 실제로는 잘 돌아간다는 것과 앞으로도 안전하게 유지할 수 있다는 것은 다른 문제였다. 특히 레거시 의존성이 많아질수록 버전을 올리거나 환경을 건드릴 때마다 예상하지 못한 문제가 튀어나왔고, 그럴수록 점점 더 쉽게 손대기 어려운 구조가 되어갔다. 그렇게 되면 나중에는 작은 수정 하나도 부담이 커지고, 보안 이슈가 생겼을 때도 빠르게 대응하기가 어려워진다. 그래서 미리 조금 힘들더라도 환경을 정리하는 쪽이 더 낫다고 봤다.
Vite로 옮기면서 체감된 변화는 분명히 있었다. 개발 서버가 더 가볍게 올라오고 수정 후 반영도 빨라지니 작업 흐름이 부드러워졌다. 다만 이번 전환에서 더 중요했던 것은 속도가 아니라, 오래된 설정과 의존성을 한 번 걷어내고 현재 기준에서 다시 볼 수 있게 되었다는 점이었다. 예전에는 그냥 당연하게 남아 있던 설정들도 "왜 이게 필요한가"를 다시 묻게 되었고, 불필요하게 남아 있던 부분들도 함께 정리할 수 있었다.
물론 전환 과정은 생각보다 단순하지 않았다. 기존 프로젝트는 Webpack 기준으로 alias, 환경변수, 정적 파일 처리, 플러그인 등 여러 부분이 맞물려 있었기 때문에, Vite 방식으로 옮기려면 그 전제를 하나씩 다시 확인해야 했다. 특히 오래된 설정일수록 현재 기준에서는 왜 존재하는지도 애매한 경우가 있었고, 그런 부분들은 옮기면서 더 신중하게 판단해야 했다.
기존에는 문제없이 돌아가던 코드가 새로운 환경에서는 깨지는 경우도 있었고, 그 과정에서 프로젝트가 생각보다 많은 전제 위에 서 있었다는 점을 체감했다. 특히 오래된 라이브러리나 설정이 남아 있을수록 이런 차이가 더 크게 느껴졌다.
결국 이번 전환을 하면서 가장 크게 배운 것은, 빌드 도구를 바꾸는 일은 단순히 더 빠른 개발 환경을 만드는 작업이 아니라는 점이었다. 오히려 프로젝트가 오래되면서 쌓인 구조적 부담과 레거시 의존성을 다시 점검하고, 앞으로의 유지보수와 보안 대응을 생각해 현재 기준에 맞게 정리하는 과정에 더 가까웠다.
결과적으로 개발 경험도 좋아졌지만, 그보다 더 크게 남은 것은 "지금 이 프로젝트를 앞으로도 계속 가져갈 수 있는 상태로 만들고 있는가"를 한 번 더 고민하게 되었다는 점이다.
보안 점검
프로젝트의 종료가 눈 앞에 다가오자 프로젝트를 전반적으로 품질 검사를 위한 점검이 필요했다.
코드 품질을 살펴보는 SonarQube 그리고 라이브러리의 보안, 라이선스를 검토해보는 Black Duck 그리고 컨테이너·쿠버네티스·클라우드 워크로드 보안 도구인 Twistlock 그 외 내부 점검 등 많은 도구들을 활용하였다.
취약한 라이브러리의 버전을 올린다고 해서 능사가 아니라는 것이다. 버전을 올리더라도 의존관계에 있는 어떤 라이브러리는 해당 라이브러리에 맞는 버전으로 그대로 고정이 되기 때문에 여전히 보안에 걸린다는 것이다. 이러한 경우에 어떤 라이브러리의 버전도 같이 올려줘야한다.
npm list "패키지명"
이 부분도 올렸을 때 빌드를 해보면 빌드 실패하는 경우가 있기에 다시 한 번 점검을 해야한다. 다음 버전이 구조가 많이 변경되는 경우에는 함부로 막 올릴 수도 없다. 이런 경우에는 package.json에서 overrides에 버전을 명시해서 해결할 수 있었다.
마치며
이번 프로젝트를 진행하면서 기존에 코딩만 하는 단계에서 보다 다양한 경험을 할 수 있었다. 훌륭한 팀원들과 프로젝트를 진행하면서 고생도 했지만 즐겁게 일을 할 수 있었다. 좋은 사수분을 만나서 도움도 많이 받고, 개발을 할 때 가져야할 생각 등 값진 경험들도 얻게 되었다.
좋은 프로젝트였다. 끝!