2025. 1. 2.
회사업무 효율성 높이기
Vience
"자유는 효율의 원천"
상황
일을하면서 느낀 것인데, 크게 3가지 문제가 있었다.
- 서비스 개발을 할 때, 백엔드 그리고 프론트엔드의 속도 차이
- 코드적 및 구조적 컨벤션이 없음
- 소규모 인원으로 큰 서비스의 qa가 진행되고 있음
이런 문제가 있었는데, 오늘은 각각 어떻게 이 3가지 문제를 해결했는지 적은 글이다.
서비스 개발을 할 때, 백엔드 그리고 프론트엔드의 속도 차이
회사에는 학부 인턴이 백엔드를 담당하고 있었다. 추가적인 채용은 이후에 계획되어져 있지만 스프린트가 빡빡한 편이라서, 통신부분에서 한쪽이 완성되어져 있지 않으면, 연계작업을 진행하는데 다른 일처리가 필요했다. 즉,
이런 상황이 많이 발생했기 때문에, 프론트엔드 개발을 할 때, 계속 기다려야하는 비효율적인 상황이 많이 발생했던 것이다. 목데이터만으로 처리를 처음에는 진행했지만, 사용자 인터렉션이 많은 서비스라서, 연계 작업에는 한계가 있었고, 이 문제로인해 MSW를 도입시켰다.
MSW는 datahub(vience canvas의 드라이브 서비스)작업에 전처리기 부분을 담당했을때 많이 도움이 되었는데, 그 당시 회사에 입사한지 한 달 조금 넘은 상황에서, 다른 페이지의 코드를 파악하기에는 시간이 많이 부족했다. 하지만, 미리 설계된 api에 따라 MSW를 적용시키고 메인 기능은 workspace의 코드를 미리 분석/파악 할 수 있게 되어 초기 스프린트보다 더많은 기능을 구현하는데 많이 도움이 되었던것 같다. 지금 시점에서는 새로운 백엔드 개발자가 들어와서, MSW를 쓸 일이 없지만 회사 초기에는 많은 도움을 받았던 기술이었다.
코드적 및 구조적 컨벤션이 없음
내가 들어오기 전까지는 여러명의 프론트엔드 개발자가 들어오고 나가고를 반복했다. 이때도 구조적 및 코드적 컨벤션이 없이, 초기 회사에서 product를 뽑는데 더 집중을 해야했기때문에 체계없는 코드가 대부분이었다. 하나의 서비스에서도, 여러 css 라이브러리가 사용되어있었고, 네이밍 규칙 또한, 매번 달랐기 때문에 코드파악에 있어서 시간을 더 투자해야하는 상황이었던것같다. 그래서, 코드적인 컨벤션을 팀 동료와 작성해서 문서화로 만들며 초반에는 esLint, prettier등을 도입해 엄격하게 규칙을 만들고, 상황에 따라서 점점 유연하게 풀어나갔다.
또한 디렉토리 구조의 경우에도, 규칙이 없었기 때문에 도메인별로(서비스 별)로 분리를 시키고, 각각의 특성에 맞게 fsd 아키텍쳐를 도입하거나, 일반적인(utils, asset, component, styles)등의 분리등을 통해 레거시를 정리해 회사의 코드의 체계를 잡았다.
추가적으로, 기본적으로 쓰는 상태관리나, css 라이브러리등도 용도에 맞게 확정을 지었으며, 만약 서비스를 따로 분리를 시켜야할 상황에서는 바로 적용이 가능할 수 있도록 의존성을 최소화 시킬 수 있었다. 이 과정에서는 마이그레이션 및 최적화, 아키텍쳐적용 새 기술도입에 관해 많은 시간과 회의가 있었지만 다른 블로그 글로 작성할 계획이다.
소규모 인원으로 큰 서비스의 qa가 진행되고 있음
알파로 서비스를 소규모의 인원이 실제로 쓰고있는 상황에서 개발이 진행이 되었다. 이때 개발 투입인원이 총 3명인 상황에서는 QA를 진행하기에는 너무 시간이 많이 소비되었고, 일관성이 없었기 때문에 수정한 버그가 다른 버그에 영향을 주는 일이 많았다. 특히, Vience Canvas의 datahub 서비스는 코드의 복잡성과 구조적 체계 부재로 인해 유지보수와 개선 작업이 더욱 어려웠기 때문에 이 문제는 더 심했던 것 같다. 그래서, 필수 동작(로그인부터, 디렉토리 삭제, 수정, 조회, 생성, 드래그 앤 드랍 로직, 계층 전달)등의 UI TESTTING 툴을 개발해서, 개발할 때 side effect를 이 시스템을 통해, 일관된 결과를 볼 수 있도록 만들었다.
Python Selenium을 활용해 로깅 대시보드를 구축·연동함으로써, 다른 코드의 의존성에 영향을 미치는 부분을 파악할 수 있었다. 이 UI 테스팅 툴은 회사의 주요 업무 흐름에 시간적인 부담을 주지 않으면서도, 틈틈이 적용하여 테스트를 진행할 수 있도록 설계했다. 최종 목표는 각 서비스가 하나의 원사이클로 연결되어, QA를 모든 서비스에서 일관성 있게 수행할 수 있는 체계를 구축하는 것이다.
메인 서비스 개발뿐 아니라, 자발적으로 이렇게 개발할 수 있는 스타트업 환경이 매력적인거 같다.