3년치 회고록_0

이 회사에 들어온지도 어언 3년이 넘었다. 개발자가 되기 이전에 나는 여러 직업을 전전했었다. 불안정한 고용 환경에서 벗어나고 싶었고, 뭔가를 쓴다는 점이 매력적이라고 느껴서 국비지원과정을 통해 소프트웨어 개발을 배우기 시작한 게 2018년이었다. 그러니 소프트웨어 개발을 배우기 시작한지 5년 만에 개발자가 된 거다.

내가 입사하고 반년 쯤 되었나, 그때 나는 팀에서 혼자가 되었다. 그로부터 1년간 나는 이 회사에서 유일한 프론트엔드 개발자로 일했다. 입사 초기부터 1년까지는 떠나간 프론트엔드 팀원 분들이 남기고 간 내부 어드민 대시보드(CRA + Javascript), 판매자 포털(CRA + Typescript), 그리고 자회사 공식 웹사이트(Webpack 커스텀 + Typescript) 등 3개의 React SPA를 단독으로 유지보수 & 신규 기능 개발했다.

처음엔 팀원들이 다 나가버리고 나에게 주어지는 일만 해도 격무였기에 DX니 프론트엔드 생태계니 신경 쓸 시간이 없었다. 그렇게 1년이 지나 신입 프론트엔드 개발자 한 분이 입사하고, 그때 잠깐 생긴 여유에 나는 곧바로 마이그레이션을 시도했다. 목표는 두 가지였다. Create React App으로 만들어진 React SPA를 모두 Vite 기반으로 전환하는 것. 바닐라 자바스크립트로 쓰여진 코드 베이스를 가진 프로젝트의 코드를 타입스크립트 코드로 다시 쓰는 것.

각 프로젝트당 일주일 정도 걸려서 마이그레이션을 완료했다. 방법은 무식했는데, 기존의 코드베이스를 Vite로 초기화된 React SPA 프로젝트에 그대로 붙여 넣은 뒤(대부분의 SPA의 폴더 구조가 그렇듯 src 폴더 내부 파일들은 그 내용과 동작이 달라질 것이 없다) 로컬에서 실행해서 컴파일 에러가 나는 곳을 일일이 찾아 손으로 수정하는 식이었다. 타입스크립트 전환도 마찬가지였다. js / jsx 파일을 하나씩 ts / tsx로 옮겼다. ESLint 설정에 따라 당연히 타입 명시가 있어야 할 곳에 타입 명시가 없거나, 권장하지 않는 방식으로 쓰여진 코드에 빨간 줄이 그어졌다. 하나씩, 수정해나갔다.

컴파일 에러가 없더라도 실제 브라우저에서 동작이 제대로 되지 않는 경우도 있기 때문에, 개발 서버에 마이그레이션 버전을 배포해서 페이지를 하나씩 점검했다. 정말 핵심적인 기능이 동작한다고 판단이 됐을 때, 운영 환경에 병합한 후 유저들의 실제 에러 리포트나 피드백을 받아 마이그레이션을 이어갔다.

그때 신입이었던 팀원 분은 너무 오래 걸릴 테니 하지 말자고 했었다. 그래도, 시간이 아무리 걸려도 해야 한다는 게 내 입장이었다. 어차피 지금 들이는 시간이나 레거시를 보존해 쌓인 기술 부채로 낭비되는 시간이나 같은 시간일 것이란 생각에서. 다행히 내가 생각한 일정보다 빠르게 마이그레이션을 완료할 수 있었고, 걸림돌이었던 Jenkins CI / CD 파이프라인을 다시 연결하는 일도 우여곡절 끝에 해냈다.

이 마이그레이션을 하기 전에 내가 제일 많이 들었던 말은 '잘 동작하는 걸 왜 고치려 하느냐'였다. 프론트엔드 생태계에 관심을 가진 개발자가 나 외엔 전무하다보니, 잘 동작하는 클라이언트 코드는… 고칠 이유가 없다는 거였다. 사실은 지금도 이렇게 말하는 사람들을 어떻게 설득해야할까, 생각해보면 답이 잘 나오지 않는다. 그들에겐 Webpack이나 CRA나 Vite나 전부 같은 것이고, Node.js 14와 현재의 LTS 버전이 같은 것이었다.

많은 프론트엔드 툴이 DX를 정량화 해서 그것을 기준으로 서로를 비교하곤 한다. 빌드 타임이라던지, HMR 속도라던지... 그러나 프론트엔드 프로젝트의 빌드를 직접 하지 않는 사람이나 로컬 환경에서 브라우저를 띄워두고 변경 사항을 육안으로 확인하며 개발하지 않는, 다시 말해 프론트엔드 개발에 본격적으로 뛰어들지 않은 사람들에게는 정량화된 DX라고 해도 감흥 있는 지표가 될 수 없다는 걸 알았다.

프론트엔드 개발자의 개발 경험을 어떻게 전달해야 하는가? 이것이 나에겐 여전히 어려운 숙제이다. 내가 해낸 전환이 정확히 어떤 성과인지도 사실은 잘 모르겠다. 다만 한 가지는 확실하다. 그때 마이그레이션을 하지 않았다면, 지금 우리 팀은 훨씬 더 많은 시간을 기술 부채를 갚는 데 쓰고 있을 것이다. 그렇게 낭비된 시간들은 회복할 수도 없다. 마이그레이션은 언제든 가능하지만, 누구도 이 회사의 시계를 뒤로 돌릴 순 없으니까 말이다.