웹 개발자: 웹 개발로 비지니스 가치를 창출하거나 문제를 해결하는 사람

입사 당시, 우리 부서에는 웹 개발자가 없었다. 이런 저런 문제를 겪고 나는 웹 개발자가 되기로 했다.

내가 기여한 것은 무엇이고 내가 기여해야 하는 것은 무엇인가?

• 회사가 나를 뽑은 이유

우리 제품은 Window Application이다. 그럼에도 불구하고 웹을 도입한 이유는 생산성과 디자인 일관성. 따라서 나는 낮은 생산성과 일관적이지 않은 디자인을 해결하기 위해 이자리에 앉아있는 셈이다. 두 가지 부문에서 2024년 내가 기여한 바를 정리해 보자.

생산성 개선

1. 개발 및 디버깅 환경 개선

• 문제

개발환경의 경우, 전임자들은 자기가 개발하는 WEB이 동작하는지 확인하기 위해 C++ 백엔드 서버를 빌드해야 했다. C++ 빌드 에러가 나면 Web 프론트 개발이 멈춘다. PostMan 등의 도구는 쓸 줄 모르기 때문에 C++개발자들이 API를 만들어주기 전까지 상상을 하며 개발을 했다.

• 해결법

개발 중에는 Vite 개발서버와 MSW, 단위 테스트의 경우 vitest로 모킹하고 E2E 테스트는 Cypress로 해결했다. 디버깅은 vscode와 jetbrains 제품의 설정파일로 통일.

작금에 이르러, 백엔드 서버 빌드 안된다고 프론트엔드 개발이 멈추는 사태는 더이상 일어나지 않는다.

2. 태스크 자동화 툴 사용

• 문제

전임자는 라이브러리 사용을 위해 폴더를 복사+붙여넣기 해야 했고 배포를 위해서, 모든 소스 코드를 index.html과 index.js에 수동으로 포함시키는 작업을 하고 있었다.

• 해결법

Lerna이용하여 모노레포 구조만들고 내가 개발한 디자인 시스템과 Web Component 라우터 라이브러리는 workspace를 통해 참조한다. 빌드 스크립트를 만들었다. 초창기에는 Parcel과 직접만든 플러그인들 이용하여 Grunt로 스크립트를 만들어 자동화했고 Typescript 마이그레이션을 진행한 이후 지금 app은 vite로, 라이브러리는 tsup을 사용한다.

3. 라이브러리 사용 개선

• 문제

일단 모듈 시스템이 없고(AMD, CJS, ESM) 전임자들이 오픈소스 라이브러리를 사용하기 위해 minify된 js를 직접 다운로드 받아 어딘가에 저장해서 런타임에 동적으로 삽입하게 만들고 퇴사를 하기 때문에 새로 들어온 전임자는 그게 Javascript의 기본 메서드라고 착각하고 사용한다. 당시 웹 서비스는 사용자가 1명만 붙어도 트래픽이 스파이크를 찍고 웹 서버가 응답조차 안줘버렸기 때문에 외부 라이브러리를 삽입하는 그 파일응답할 때 서버가 뻗으면 작동이 안된다.

• 해결법

당시 같은 파일을 여러번 요청하거나 웹 서버의 성능을 최적화해버리는 기상천외한 방법을 택했다. 내 해결법은 간단했다. 그냥 서버한테 필요없는 파일 수백개 요청 안하면 된다. tree shaking을 하자.

4. 코드 스타일 강제

• 문제

우스갯소리로 들은 말로는, 당시 전임자의 기분에 따라 2 space를 사용할지 4 space를 사용할지가 정해졌다. C++의 경우 google style을 사용하라고 문서까지 있었으나 js는 따로 없었다.

• 해결법

ESLint와 Husky를 사용해서 규칙 안지키면 커밋이 안되도록 막아버렸다.

내가 한창 백엔드 미디어 서버 개발할 때 당시 프론트 개발자가 ESLint안지키면 커밋안되는거 보고 날 이상하게 보던 기억이 난다.

아마 내 후임이 될 개발자도 마찬가지의 이유로 나를 싫어하겠지만 본인이 규칙을 정말로 지켰는지 생각해보길 바란다.

5. 문서 작성

• 문제

문서가 없다. 파라미터가 뭐가 들어가는지 알 수 없었고 전임자들도 고대에 만들어진 전역 함수에 어떤 파라미터가 들어가는지, 런타임에 뭘로 덮어써지는지를 몰라서 자기 전임자 코드를 복사+붙여넣기 하다보니, 나중에 내가 분석해본 결과 2세대 전임자가 잘못작성한 코드로 인해 악순환의 굴레가 벌어졌던 경우가 있었다.

• 해결법

적어도 내가 만든 함수와 클래스에는 JSDoc을 작성했다. 지금은 TypeScript로 마이그레이션했기 때문에 런타임에 오류나는게 아니라 빌드 시점에 오류가 난다.

작금에 이르러 내가 개발한 모든 라이브러리와 디자인 시스템은 IDE의 Syntax기능을 키더라도 모든 라인에 빨간줄을 긋지 않기 때문에 내 후임이 될 개발자는 이제 안심하고 IDE의 모든 기능을 활용할 것이고 개발 도중 빨간줄이 그이면 자기가 코드 잘못적었다고 깨달을 수 있다.

일관된 디자인 확립

1. 디자인 시스템 개발

• 문제

전임자들은 비슷한 UI가 있어도 Composition이 아니라 Inherit을 택했다. React나 Vue, Angular처럼 컴포넌트 단위로 재사용을 하지 않았고 같은 기능을 다른 방식으로 쓰고 또 썼다.

• 해결법

기존 레거시를 버릴 수는 없었기도 하고 다른 개발자는 어떤 프레임워크를 택할지 알 수 없었기 때문에 Web Component를 이용하여 컴포넌트 단위로 재사용을 했다. 현재는 디자인 시스템은 Web Component로, 그걸 사용하는 각 App은 React로 개발하고 있다.

2. CSS 관리 개선

• 문제

전임자의 경우 jQuery를 이용하여 자신이 원하는 파일에 CSS를 런타임에 주입하는 방식을 사용했다. 특정 UI를 고치기 위해서 어떤 파일을 수정해야 하는지 찾는 것이 사실상 불가능하기 때문에 주로 !important를 이용하여 강제로 덮어쓰는 방식을 택했다.

• 해결법

기존의 CSS도 살려야 했기때문에 ShadowDOM을 택했다. 후술하겠지만 지금은 생산성을 위해 ShadowDOM을 버리는 중이다. Class기반 Variants와 ShadowDOM은 아쉽게도 양립불가능하거나 번들 사이즈를 희생해야 한다.

3. Storybook 사용

• 문제

주로 html은 마크업, js는 로직, css는 스타일을 담당하는 형태여야 하나 아쉽게도 당시 전임자가 웹 개발자가 아니다 보니 index.js에 jQuery 또는 DOM API사용하여 마크업+로직+스타일을 다 결합시켰고 UI만 보여주는 것이 불가능했다.

• 해결법

퇴사자 PC를 받아다가 Storybook 서버를 만들고 내가 개발한 디자인시스템의 Story를 띄웠다. 디자인 시스템의 각 컴포넌트는 로직이 없고 오직 UI만을 담당한다.

4. 시각적 회귀 테스트 도입

이전 포스팅 참고.

요약

1. 모노레포 및 빌드 프로세스 구축
2. 디자인 시스템 개발
3. 자사 백엔드 서버에서 쓸 수 있는 라우터 라이브러리 개발
4. 자사 웹 클라이언트에서 사용가능한 http-client 라이브러리 개발
5. RTSP -> WebRTC, HLS 미디어 서버 개발
6. 위 디자인 시스템, 라우터 등등을 사용하는 Web APP 개발