미리보기

쏘카 차량에 대한 관리를 사용자에게 맡겨, 차량 관리에 대한 비용을 줄이는 '핸들러' 앱 내재화에 프로젝트에 참여하여 프론트엔드 파트를 전담했습니다. iOS, Android 각각 네이티브로 구현되어있던 레거시 앱을 웹뷰 환경의 하이브리드 앱 형태로 전환하는 작업을 진행했습니다. 위치, 갤러리, OCR 등 네이티브 기능이 필요한 부분은 webview bridge 를 이용해 모바일팀과 협업해 구현했고, 기타 대부분의 기능은 웹 환경을 이용해 구현했습니다. 이후 비슷한 형태의 기사전용 앱(공항편도)을 전담해 런칭하였고, 현재는 신규 웹 프로젝트를 전담하며 4명 규모의 FE 팀을 리딩하고 있습니다.

• 외주 네이티브 앱 -> 하이브리드 앱 마이그레이션 전담

• 잘 추상화된 기초 수준 라이브러리 조합 선호

• 4명 규모 FE 팀 리딩

폰트 리소스 최적화

유니코드 범위 기반 dynamic subset 폰트 리소스를 적용했습니다. 초기 구현시 font-weight별 subset을 적용했었는데, 각 파일의 크기가 약 250Kb이기 때문에 dynamic import를 적용해도 상황에 따라 약 1.5mb까지 받는 케이스가 존재했습니다. 이를 unicode-range 기준의 dynamic subset 방식으로 변경하여 필요한 문자열 범위에 따라 최소한의 폰트 파일만 받도록 최적화했습니다. 메인 화면 기준 초기 폰트 리소스를 약 1.2mb에서 약 200kb로 줄일 수 있었습니다.

ts-pattern 도입

다른 프로젝트들과 마찬가지로 해당 프로젝트 역시 규모가 커질수록 분기가 복잡해졌습니다. 분기의 케이스가 많아지고, 뎁스가 깊어졌기 때문에 이 부분을 단순화시킬 필요성이 있었습니다. typescript 기반으로 동작해 컴파일 시점에 분기를 감지할 수 있는 ts-pattern을 도입했고, 고려되지 않은 케이스를 컴파일 시점에 감지할 수 있게되어 위험도를 낮출수 있게 되었습니다.

react-swiper free mode를 활용한 time picker 개발

급하게 들어온 요구사항 중, 네이티브 친화적인 time-picker를 개발해달라는 요청이 있었습니다. 관련된 안정적인 오픈소스는 존재하지 않았고, 직접 구현하기에도 시간이 충분하지 못한 상황이었습니다. 메인 배너를 노출할 때 주로 사용하는 react-swiper의 free mode가 눈에 띄었고, 해당 모드를 사용한 후 컴포넌트만 수직으로 돌린 후 조금 수정하면 될 것이라 판단해 이런 방식으로 완성도 높은 time picker를 빠르게 구현할 수 있었습니다. 특정 모듈의 역할에 집중을 했을 때 해당 모듈과는 전혀 달라보이는 기능을 대체할 수 있다는 사실을 알게 되었습니다.

팝업형 UI 모바일 뒤로가기 버튼 대응

서비스 사용중 이탈방지를 팝업형 UI들의 안드로이드 뒤로가기 물리버튼 대응이 필요했습니다. NextJS 14의 parallel routes를 참고해 history를 조작해 구현하려 했으나, 팝업형 UI 들의 종류가 많고, 중첩된 케이스를 고려하면 history 관리가 복잡해질 것이라 판단했습니다. 뒤로가기를 차단해주는 web bridge 만들어 호출해 기본적으로 뒤로가기가 차단되도록 구현해주었고, 모든 팝업형 UI들을 stack 형태로 글로벌 상태로 관리한 후, 뒤로가기 이벤트 발생시 가장 위에 있는 팝업형 UI의 close callback을 호출, stack이 비어있다면 기본 뒤로가기 동작이 다시 수행되도록 구현해주었습니다. 결론적으로 모바일 디바이스의 뒤로가기 버튼에 대응할 수 있었고, 사용자의 잦은 이탈방지를 막을수 있게 되었습니다.

다양한 form 컴포넌트 관리

서비스 특성상 사용자가 입력하는 form이 다양하고 많았습니다. 개발 이후, 코드가 잘 유지보수되기 위해서는 form 관련 로직이 잘 정리되는 것이 중요하다고 판단했고, react-hook-form + resolver를 적극적으로 사용했습니다. 실제 일반적인 형태의 form 뿐만 아니라, 지도, time picker, 기타 정보들을 필터링하는 종합 필터의 경우도 결국 유효성 검증, 값 전송이라는 기본 동작의 뼈대가 동일하다고 판단해 적극적으로 활용했고, 덕분에 불필요하게 복잡한 코드가 생성되는 것을 막을수 있었습니다. input 요소의 경우, 매 입력시 xxx-xxx-xxx 같은 특정 포맷을 유지해야하는 경우가 많았는데, 각 입력 이벤트 핸들러에서 정규식을 사용하거나 하는 등의 복잡한 방법을 사용하지 않고, input-format이라는 라이브러리를 활용해 선언적으로 관리될 수 있도록 하였습니다. 해서 브라우저 호환이나, 이벤트 타이밍을 신경써야하는 등의 불필요한 관리에서 벗어날 수 있었습니다.

type 스키마 자동 생성을 위한 openapi-generator 도입

현재 진행중인 프로젝트는 특정 응답은 200개 이상의 필드가 내려올 정도로 api 응답 스키마가 매우 큰 편입니다. swagger로 문서화가 되어있으나, 일일이 해당 스키마에 맞게 typescript의 type을 작성해주는 것은 개발에 크게 지장을 주었고, 실제로 개발이 진행되면서 api 수정도 잦은 상황이라 일일이 대응하는 것은 큰 낭비라고 생각했습니다. 리서칭 후 보편적으로 적용할 수 있는 openapi-generator를 적용했고 API swagger 문서를 바탕으로 type 이 자동 생성될 수 있도록 하여 개발자의 불필요한 코드 수정을 최소화했습니다.

숨고 웹 프론트엔드와 어드민 사이트 개발 및 유지보수에 참여하였습니다. 주 스택으로 JavaScript, TypeScript, Vue, Vue-SSR, React를 사용하였고, 그 외 Vuex, RTK, Material UI를 사용하였습니다.

• 숨고 클라이언트, 어드민 사이트 UI 개발

• viewport 기반 반응형 웹 개발

• 크로스 브라우징 (IE 11 이상, Safari, Chrome, Mobile Browser)

• 페이스북 전환 API 적용

• SEO 경험

• SSR 경험

• 숨고 기술블로그 마이그레이션 전담

Bitbucket -> Github 마이그레이션

프론트엔드 메인 저장소를 Bitbucket -> Github로 이전하는 작업을 전담하였습니다. 중요한 부분은 CI/CD였는데, Bitbucket Pipeline -> Github Action으로 마이그레이션하였고, 환경변수, 코드 등 배포 관련해 불필요한 레거시 부분을 제거하였습니다. 배포전 main branch를 merge 하는 등의 로직이 코드레벨에서 구현되어있기도 했었는데, 해당 부분들을 Github Action 오픈소스로 간단하게 수정하여 Github CI/CD 파이프라인 영역으로 옮겨두었습니다. 추가로 코드리뷰, 편의기능 등 협업을 위한 환경도 Github Action으로 구현해두었습니다.

E2E 테스팅 환경 구축

기존 QA 챕터의 젠킨스 기반 E2E 시스템을 CircleCI, Puppeteer로 새로 구축하는 것을 초기에 전담했습니다. 서비스에 주요한 영향을 주는 6가지 시나리오를 Puppeteer로 구현하고, CI/CD 과정중에서 이를 병렬적으로 실행하도록 구현하였습니다. 초기에 Github Action으로 이를 구현했으나, 파악하기 힘든 타임아웃 에러가 간헐적으로 발생하였고, 이로인해 테스트 결과를 신뢰하지 못하는 문제가 발생하였습니다. Github Action 러너 스펙 확인 후 우선 성능문제로 추정을 해보았고, 마침 챕터에서 소유하고 있던 CircleCI 유료 플랜이 있어 해당 E2E 스크립트를 CircleCI에서 실행하도록 바꾸고, Github Action과 이를 연동하여 문제를 해결하였습니다. 테스팅 환경을 구성할 때, 단순히 시나리오 뿐만 아니라 테스트가 실행되는 환경에 대해서도 고려해보아야 한다는 것을 알게 되었습니다.

CI/CD 파이프라인 client 빌드 에러 감지

숨고 웹 프론트엔드는 client, render server 두가지로 구별되어있는 구조입니다. client -> render server 순으로 빌드가 진행되는데 client 빌드시 에러가 발생하여도, 그 결과와 무관하게 render server 빌드가 진행되고, 최종적으로 배포가 완료되어 망가진 앱이 서빙되는 문제가 있었습니다. 기존 빌드 과정이 동일한 프로세스에서 직렬로 실행된다는 것을 파악한 후, client 전용 webpack 커스텀 훅을 만들어 컴파일 에러가 감지되면 프로세스를 종료하도록 처리해 배포에 안정성을 더해주었습니다.

AI 기반 의료 솔루션 UI 개발을 담당하였습니다. 주 기술 스택은 React, Typescript, Redux, Redux-Saga입니다. 보편적인 서비스에 비해 클라이언트에서 많은 데이터를 다루는 경험을 해볼 수 있었습니다.

• AI 의료 솔루션 UI 개발

• lodash chain API 기반 지연평가 적용

windowing 기법 적용

의료용 솔루션에서는 한 화면에서 보여줘야할 데이터가 많습니다. 추가적으로 무한스크롤까지 지원해야하는 경우가 있었는데, 스크롤되는 양이 많아질수록 앱이 심하게 느려지는 현상이 있었습니다. 컴포넌트나 변수를 메모제이션 하는 것도 고려해보았으나, 이 방법도 결국 데이터의 양에 의존하는 한계가 있다고 판단했고, 이론적으로만 알고있던 windowing 기법을 적용해보기로 하였습니다. 느리게 동작하던 기존 리스트 컴포넌트에 react-virtualized를 적용했고 데이터의 양과 상관없이 부드러운 UI를 구현할 수 있었습니다.

다양한 프로젝트의 프론트엔드 개발 및 유지보수에 참여하였습니다. 여러가지 프론트엔드 기술을 접하며 기술간의 차이를 느낄 수 있었고, 기술스택에 크게 집착하지 않는 계기가 되었습니다. 기본적으로 백엔드 API 작업을 겸하며 프로젝트들을 진행했습니다.

• Vanilla JS 기반 UI 개발

• React, Vue, Angular 기반 UI 개발

• 웹뷰 기반 모바일 앱 UI 개발

• 크로스 브라우징(IE 10 이상)

• 프론트엔드 기술환경 세팅

requestAnimationFrame 적용

커머스 앱에서 게임 형태의 이벤트 UI 개발을 맡았습니다. 대부분의 코드에서 DOM 요소를 조작하는 부분을 setInterval API를 사용해 조작하고 있었는데, 불특정한 상황에서 애니메이션이 부자연스럽게 끊기는 현상이 발생했습니다. 코드의 구현과 관계없이 프레임에 맞게 동작하는 것이 더 좋다고 판단해 requestAnimationFrame API를 적용했고, 결과적으로 애니메이션이 부드럽게 동작하였습니다. 별도의 polyfill을 적용해 IE에 대해 크로스 브라우징 처리를 해두었습니다.

patch-package를 활용한 오픈소스 버그 대응

npm 기반의 오픈소스를 사용할때, 라이브러리 내부적으로 버그가 발생하는 경우가 있었습니다. 부모요소를 찾지 못해 참조 에러가 발생하는 것이 원인이었고, 커뮤니티를 뒤져본 결과, 해결채은 명확하고 간단했지만 오픈소스 개발자의 대응을 기다릴 수는 없었습니다. patch-package로 해당 모듈을 직접 수정해주었고, 빌드 스크립트에 patch 과정을 추가하여 패키지 의존성을 건드리지 않고 이슈를 해결하였습니다. 이후에도 이 경험을 응용해 당장 마이그레이션 할 수 없는 구버전 라이브러리의 문제를 해결할때도 동일한 방법으로 해결할 수 있었습니다.