DDM(Datarize Dev Meetup)의 세 번째 세션은 프론트엔드(Front-end) 챕터였습니다. 이번 발표는 프론트엔드 챕터 리드를 맡고 있는 이종형님이 준비해주셨는데요. 주제는 바로 “글로벌 지원을 위한 프론트엔드 레거시 개편”이었습니다.

영상으로도 보실 수 있어요 🤓

데이터라이즈가 글로벌 서비스를 확장하면서, 다국어와 타임존 지원은 더 이상 선택이 아닌 필수가 되었습니다. 하지만 막상 들여다보니 생각보다 훨씬 복잡한 문제들이 숨어 있었습니다. 번역이 누락된 UI, 지역마다 다르게 보이는 시간, 도메인마다 제각각 쓰던 코드들까지… 사용자 경험도, 개발자 경험도 모두 불편을 겪고 있었죠.

왜 시작했는가?

이번 개편 프로젝트는 약 6개월간 진행되었습니다. 목표는 단순했습니다.

• 다국어 지원 품질 개선
• 글로벌 타임존 처리 통합
• 파편화된 레거시 코드 정리

무엇보다도 서비스 중단 없이 점진적으로 개선해야 했기에, 기술적인 고민뿐 아니라 협업 방식까지 새롭게 정비해야 했습니다.

다국어 지원, 단순 번역이 아니었다

기존 문제

처음 다국어를 도입했을 때는 그저 “언어팩을 넣으면 되겠지”라고 생각했습니다. 하지만 곧 문제가 드러났습니다.

• 같은 “확인” 버튼도 영어에서는 Confirm일 때가 있고, 맥락에 따라 Close여야 할 때가 있음
• 한국어는 두 글자로 충분하지만, 영어는 길어지고 일본어는 글자 높이까지 달라 UI가 깨지는 상황 발생
• 중복된 키, 누락된 키, 오타… 번역 품질은 떨어지고 개발자, 기획자는 매번 새 키를 추가하느라 피로감 증가

해결 방법

저희는 공통 요소와 맥락별 요소를 분리하고, 타입 세이프티(Type Safety)를 적용했습니다. 이제는 잘못된 키를 쓰거나 오타를 낼 일이 줄어들었고, 자동완성 덕분에 개발 효율도 높아졌습니다.

또한 구글 시트 연동 워크플로우를 도입해, 새로운 키가 추가되면 자동으로 시트에 반영되고, 기획자와 번역가가 실시간으로 맥락에 맞게 번역할 수 있게 만들었습니다. 마지막으로 UI 미리보기와 자동화 테스트를 통해 번역 품질과 화면 안정성을 동시에 잡았습니다.

레거시 시스템의 혼란

시간과 관련된 문제는 더 심각했습니다.

같은 데이터를 한국에서 보면 오전 8시, 미국에서는 오후 4시로 보이는 상황이 벌어졌습니다. 서버에서 내려주는 값이 KST 기준이면서 타임존 정보가 빠져 있었기 때문입니다.

상태 관리 역시 뒤섞여 있었습니다. 클래스형 컴포넌트, Redux, Zustand, useState… 제품 안에서 서로 다른 패턴이 공존했습니다. 날짜 처리도 마찬가지로 Moment.js, Date-fns, 자체 제작 모듈이 섞여 있어 일관성이 없었죠.

이 모든 요소가 맞물리면서 유지보수는 어렵고, 새 기능을 추가할 때마다 예기치 않은 오류가 발생했습니다.

타임존 처리, 전면 리팩터링

결국 FE 챕터는 2개월 동안 전원 투입해 전면 리팩터링을 진행했습니다.

주요 개선

가장 먼저 진행한 것은 상태 관리 일원화였습니다. 여러 방식이 뒤섞여 있던 코드를 통합 훅으로 정리하면서 중복이 줄고 유지보수가 쉬워졌습니다. 다음으로는 통합 날짜 모듈 설계입니다. Moment.js, Date-fns, 자체 모듈이 뒤섞여 있던 문제를 하나의 모듈로 통합했습니다. 단일 책임 원칙을 지키고 브라우저 독립성을 확보하면서, 더 이상 위치에 따라 데이터가 달라 보이지 않게 되었습니다. 또 하나 중요한 변화는 사이트 타임존 개념 도입입니다. 백엔드와 통신은 UTC로, 클라이언트는 사이트 타임존으로 처리하도록 표준화했죠. 덕분에 어느 나라에서 접속해도 동일한 데이터를 확인할 수 있습니다. UI 측면에서는 데이트 피커 재설계가 있었습니다. 기존에는 내부 상태를 고집해 동기화가 깨지곤 했는데, 이제는 순수 UI 컴포넌트로 바꾸어 외부 상태와 유연하게 연결되도록 했습니다. 이제 모든 날짜 데이터는 UTC 기준으로 통신하고, 화면에서는 사이트 타임존 기준으로 변환됩니다.

성과

이번 개편은 단순히 코드 몇 줄을 다듬는 수준이 아니라, 6개월 동안 단계적으로 진행된 대규모 프로젝트였습니다.

• 작년 11~12월: 현황 분석 및 설계

  레거시 코드를 면밀히 분석하고, 문제점을 정리했습니다. 이를 토대로 개선 방향을 설계하고 리팩터링 계획을 수립했습니다.

• 1~2월: 레거시 리팩터링

  집중 작업 기간이었습니다. 두 달 동안 챕터 전체가 투입되어 978개의 파일을 변경했고, 19,702줄을 추가하며 26,819줄을 삭제했습니다. 코드베이스의 약 15%가 줄어든 셈입니다.

• 3~4월: 타임존 관리 모듈 개발

  사이트 타임존 개념을 도입하고, 날짜 관리 모듈을 통합했습니다. 이 과정에서 브라우저 로컬 시간에 의존하지 않고, 서버와 클라이언트가 일관되게 시간을 처리할 수 있도록 API 규약을 정비했습니다.

• 5~6월: 데이트 피커 재설계

  내부 상태를 고집하던 기존 컴포넌트를 순수 UI 컴포넌트로 바꾸고, 외부 로직을 주입하는 방식으로 재설계했습니다. 백엔드 API와의 연동을 마친 뒤 최종 테스트를 거쳐 배포까지 완료했습니다.

개발 측면 성과

이 과정을 거치면서 개발 생산성과 품질 모두가 눈에 띄게 개선되었습니다.

• 모든 페이지에서 동일한 날짜 처리 로직을 사용 → 유지보수 용이
• 타임존 관련 버그 90% 감소 → 안정성과 신뢰 확보
• 코드 가독성·일관성 향상 → 신규 입사자의 적응 시간 단축
• 테스트 코드 확충 → 대규모 리팩터링 후에도 안정성 확보

사용자 측면 성과

사용자 경험도 크게 달라졌습니다.

• 해외 어디서 접속해도 동일한 데이터 확인 가능
• 브라우저 시간 조작에도 안정적으로 동작 → 데이터 신뢰성 강화
• 직관적인 날짜 선택 UI 제공 → 오류 감소
• 다국어 번역 품질 향상 → 문의 건수 70% 감소, 긍정적 피드백 증가

우리가 배운 것

이번 프로젝트를 통해 얻은 가장 큰 교훈은 “기술 문제도 결국 사람 문제”라는 점이었습니다.

다국어 번역이나 UI 깨짐은 코드만으로는 해결되지 않았습니다. 디자이너와 협업해 언어별 폰트 크기를 조정하고, 기획자와 협력해 텍스트 길이 가이드라인을 세우는 등, 챕터 간 긴밀한 협업이 필수였습니다. 번역가와의 티키타카도 마찬가지였습니다. 단순히 번역본을 전달받는 것이 아니라, 맥락을 설명하고 빠르게 피드백을 주고받는 체계가 갖춰졌을 때 품질이 비약적으로 올라갔습니다.

또 하나는 표준화의 가치입니다. 예전에는 같은 기능도 페이지마다 구현 방식이 달라 유지보수 난이도가 높았습니다. 하지만 이번 개편을 통해 코드 패턴이 정리되자, 서로의 코드를 낯설지 않게 이해할 수 있었고, 신규 입사자도 빠르게 적응할 수 있었습니다. “내 코드”와 “네 코드”가 아니라 “우리 코드”라는 감각이 자리 잡게 된 것이죠.

기술 부채에 대해서도 크게 깨달았습니다. 0 to 1, 1 to 10 단계에서 빠르게 기능을 붙이느라 미뤄왔던 부분이 시간이 갈수록 더 큰 짐이 되었습니다. 두 달간 전원 투입이라는 대수술이 불가피했던 것도 그 때문입니다. 결과적으로 “기술 부채는 조기 정리해야 한다”는 단순한 원칙이 얼마나 중요한지 체감했습니다.

마지막으로, 레거시 개편은 비용이 아니라 투자라는 점을 확인했습니다. 코드 리팩터링은 눈앞의 성과로 바로 드러나지 않기 때문에 “꼭 해야 하냐”는 질문을 받기도 합니다. 하지만 사용자 경험이 개선되고, 개발 속도가 향상되며, 장기적인 신뢰가 쌓이는 과정을 직접 겪으면서, 이는 단순한 비용이 아니라 미래를 위한 투자라는 사실을 증명할 수 있었습니다.

마치며

이번 개편은 단순히 오래된 코드를 정리하는 작업을 넘어, 사용자와 개발자 모두에게 새로운 가치를 남겼습니다.

사용자에게는 위치와 환경에 상관없이 일관된 경험과 신뢰를 제공했고, 개발자에게는 효율적이고 안정적인 환경을 마련했습니다.

무엇보다도 프로젝트를 통해 팀워크와 협업 방식이 크게 성장했습니다. 각자의 도메인에만 몰두하던 구성원들이 서로의 코드를 뜯어보고, 함께 해결책을 찾으며 “데이터라이즈 FE 챕터”라는 하나의 챕터로 더 단단해졌습니다.

앞으로도 데이터라이즈 FE챕터는 글로벌 사용자에게 더 나은 경험을 제공하기 위해 끊임없이 개선을 이어갈 예정입니다.