안녕하세요, 저는 레베뉴마켓 서비스를 만드는 Verticah 팀에서 Frontend Engineer로 일하고 있는 이승규입니다.
Verticah팀은 작년 9월 첫 엔지니어링 팀이 구성되었고, 저는 작년 12월에 첫 Frontend Engineer로 합류해 일을 하고 있는데요, 단지 프론트엔드 엔지니어가 아니라 프론트엔드 개발을 할수 있는 팀원으로써 어떻게하면 효율적으로 일을 하며 팀이 만들어 가는 프로덕트 및 방향성에 도움을 줄 수 있을지에 대해 많은 고민을 하며 일을 해왔던것 같습니다.
그 과정속에서 어떠한 상황들을 마주했고, 또 그 상황속에서 어떻게 일해왔는지 3가지 사례를 통해 경험을 공유해보려 합니다.
1. 프로덕트 안정성을 자동화된 시스템에서 뒷받침하기
서비스를 만들어 나갈때 고객분들에게 새로운 기능이나 더 나은 UX를 빠른 호흡으로 제공해드림과 동시에, 프로덕트의 안정성을 확보해나가야 했는데요. 더군다나 저희는 스타트업들의 성장을 위해 성장자금을 지원해 드리고 그러한 과정에서 문제가 생기면 안된다는 생각으로 항상 프로덕트를 만들었습니다.
큰 회사나 조직에서는 전문 QA인력이 regression test (smoke test)를 진행하지만 초기 스타트업 특성상 그러한 인력을 채용하기는 어려운 상황이므로, 자동화된 시스템으로 그런 안정성을 확보하는게 필요하다 판단했습니다. 또한 플랫폼팀 인력 또한 한정되어 있었기 때문에, 매번 새로운 배포가 있을때마다 일일이 그런 과정들을 QA할수 없었기 때문입니다.
이를 위해 E2E 테스트 (가상의 유저의 행동을 작성해 자동화된 시스템에서 애플리케이션의 흐름을 처음부터 끝까지 테스트)의 필요성을 인식하고 있었고, 그러한 인식이 팀내에서도 대두되고 있었습니다. 마침 위와같이 문제 상황을 마주한 이후, 이를 위한 E2E 테스트 파이프라인을 구축하기 시작했습니다.
이를 위한 Tool로는 playwright을 도입 했는데요. 그 이유는 아래와 같습니다.
- low code 를 위한 code generate 도 제공
- 동시에 수행가능한 테스트들의 병렬 테스트가 가능해서 속도면에서 우위 (다른 e2e test tool인 Cypress는 유료 플랜을 가입해야 CI/CD 환경에서 병렬로 테스트를 수행가능)
- POM(Page Object Model) 개념 활용해 test 동작들을 class에 정의해서 상속 및 재사용 가능
- Chromium, WebKit 및 Firefox , Edge 등등 여러 브라우저들의 테스트를 지원
위처럼 이미 알려진 많은 장점들이 있지만, 초기 스타트업 특성상 개개인의 효율이 중요한 만큼 test 작성과정에서의 시간 효율이 특히 중요했고, 그 관점에서 low code를 위한 code generate 기능이 매우 큰 장점으로 다가왔습니다. 이 기능에 대해서는 아래에서 상세히 설명해드리겠습니다.
E2E 테스트 작성과정에서 고려한것들
e2e 작성과정에서 고려했던 여러 과정들을 몇가지 소개하면 아래와 같습니다.
A. low code generate 기능 활용
위에서 말했듯이, playwright을 도입한 가장 큰 이유이기도한 low code test generate 기능입니다.
아래 화면처럼 브라우저 내에서 input을 입력하거나 버튼을 클릭한다던지, 특정 영역을 focus하는 등등 여러 유저의 행동을 자동으로 레코딩해 이를 test code로 자동으로 generate하게 됩니다.
물론 생성된 test code를 manual하게 조금 조정해주는 시간은 투자해야하지만, playwright에서 제공하는 low code generation 기능을 활용해 해당 요소를 선택하기 위해 어떠한 문법과 어떠한 코드를 작성해야 하는지 인지할 필요없이, simulate 화면에서 위 화면처럼 사용자의 행동 기반으로 자동으로 code를 작성할 수 있게되어 지속가능한 E2E 테스트 코드 유지 및 생성이 가능했었습니다.
B. 두 서비스(레베뉴마켓 , Admin)에서 E2E 테스트 상호작용
저희는 고객분들이 레베뉴마켓 서비스에서 자금조달을 위해 조건을 요청하시게되면, 저희 어드민상에서 분석한 결과를 바탕으로 결과를 제공해주는 과정이 있기 때문에 두가지 웹서비스를 넘나드는 flow가 E2E테스트에서 가능해야 했습니다. playwright 에서 multiple webserver를 띄우는 기능을 제공하고 있었고, 저희 서비스는 monorepo기반에 서비스와 어드민 프로젝트가 함께 있었기에 동시에 서비스를 띄운 후 위와 같이 config file에서 실행시킬 서비스들을 추가만 해주면 되었습니다.
C. Worker 여러개 할당하기
또한 serial하게 테스트들을 돌리면 테스트 시간의 비효율이 발생하므로, worker 2개에서 조건 제공과 조건 거절 case를 병렬로 돌려 e2e 테스트에서 속도면에서의 효율을 올리도록 해줬습니다.
D. POM 컨셉 활용
또 어드민과 사용자 서비스에서 반복되는 유저의 행동들은 playwright에서 제공하는 Page Object Model (POM) class에 행동들을 응집시켜, 조건 신청 및 조건 제공과정에서의 공통적인 flow들을 재사용해 테스트코드를 효율적으로 구성할 수 있었습니다.
Admin Page Object Model
- 기본적인 로그인
- 분석결과를 내보내기 전까지의 과정들
Service Page Object Model
- 로그인
- 매출업로드
- 회계업로드
위에 소개한 여러 과정들을 바탕으로, 현재는 아래와 같은 프로세스들이 E2E 테스트로 관리되고 있습니다. 아래 과정들은 고객의 자금조달 과정에서의 핵심적인 flow였고, 안정성이 확보되어야 했으므로 우선적으로 test code들을 추가해 나갔습니다.
- 판매조건 신청을 위한 고객 데이터 업로드 과정
- 판매조건 신청 과정
- 판매조건 제공 (거절) 과정
- 판매조건 제공 (수락) 과정
- 제공된 판매조건으로 판매신청하는 과정
추후에는 고객이 레베뉴마켓을 이용하는 전 과정에서의 안정성을 확보할 수 있도록 E2E 테스트 코드들을 추가/개선해 나갈 예정입니다.
E2E 테스트 파이프라인
위와 같이 작성한 E2E 테스트가 CI 환경에서 어떻게 돌아가는지 간략히 설명드리면 아래와 같습니다.
- main 브랜치를 바라보게 PR을 올리면 e2e test github action work flow가 trigger
- E2E테스트, unit 테스트, 빌드 성공하면 merge 가능
3. E2E테스트 결과를 PR에 댓글로 달아줌
4. E2E 테스트 실패시에는 디버깅을 위해 playwright report 아티팩트 업로드
CI 상에서 실패하는 경우에 왜 E2E 테스트가 실패했는지는 블랙박스인 경우들이 있는데, 이를 디버깅하기 위해 playwright에서 제공해주는 report 기능을 활용해 report artifact를 github action상에서 업로드 하도록 파이프라인을 구성했습니다.
이 artifact report file을 바탕으로 아래와 같이 e2e 테스트를 simulate를 하며 수정이 필요한 상황에 디버깅을 하면서 지속가능한 e2e 테스트 파이프라인을 만들어 나갔습니다.
E2E 테스트 파이프라인을 구축한 이후, 기능을 새롭게 릴리즈하거나 기존 기능에 변경이 있을때, 조금 더 안심하며 고객의 자금조달과정에서는 여전히 문제가 없도록 프로덕트의 안정성을 확보해 나갈수 있었습니다.
2. 나의 효율, DX 끌어 올리기
위처럼 프로덕트의 안정성을 끌어올리는 것 뿐만 아니라, 프로덕트를 만드는 과정 속에서 유일한 팀내 프론트엔지니어로써 저의 효율을 끌어올릴수 있는 방법이 무엇이 있을까 고민을 하게 되었는데요. 그 과정에서 시간을 줄일수 있는 포인트가 무엇이 있을지 일 하는 과정들을 복기해보았고, 또 그것을 시스템화/자동화 할수 있는 방법은 없을까? 라고 의문을 던져보았습니다. 그 결과 몇몇 매뉴얼하게 시간이 드는 프로세스를 찾을 수 있었습니다.
A. S3 이미지 업로드 피그마 플러그인 만들기
사용할 이미지 리소스들을 s3에 올리고, 그 주소를 따서 활용하는 과정이 첫번째 였습니다. 이러한 매뉴얼한 작업을 시스템화 하기위해, 피그마 플러그인을 개발해바로 s3에 업로드 후 이미지 주소를 클립보드에 복사하는 식으로 활용했습니다.
B. Swagger 에서 type 추출하기
두번째로는 swagger로 공유된 응답 스펙들을 타입스크립트 기반으로 서비스를 만들어 갈때, 일일히 타입을 명시할때 드는 시간을 줄일수 없을까 고민하게 되었는데요. 기본적인 크롬 익스텐션 개발에 필요한 컨셉을 숙지한 후, 프론트엔드 개발시 바로 활용할수 있도록 타입 인터페이스를 추출해내는 크롬 익스텐션을 제작해보게 되었습니다.
우선은 react-chrome-extension-boilerplate 라는 보일러플레이트를 활용해 제작하였고, 이를 통해 타입을 작성하는 시간들을 대폭 줄일수 있었습니다.
위에 말했듯 한명 한명의 효율을 극대화 하는것이 회사가 만들어가는 프로덕트를 만드는 속도와 퀄리티에도 큰 영향을 끼치므로 앞으로도 이렇게 저의 효율을 시스템으로, 혹은 프로세스적으로 개선할만한 것들이 있다면 적극적으로 개선할 예정입니다.
3. 프론트 엔지니어링을 활용한 toy 프로젝트 진행하기
앞서 저의 효율을 올리기 위한 여러가지 작업들을 소개 드렸는데요. 이 이외에 다른 팀원의 효율을 올리기 위해 했던 작업을 소개하려 합니다.
고객분들이 정확한 분석을 받기위해 필요한 데이터와 이를 제출하기 위한 여러가지 flow가 있었고, 이를 이용하는 과정에서 VOC가 지속적으로 들어왔었습니다. Demand팀에서는 이를 응대하기 위해 시간과 리소스를 들여야 했는데요, 이를 해결하기 위해 튜토리얼 page를 고객에게 제공해 전반적인 레베뉴마켓 사용흐름에 대해 이해하도록 도움으로써 고객분들의 자금조달 과정에서의 bottle neck을 줄이고, Demand쪽 업무 효율증대를 도우려 했습니다.
우선 이번 분기에 Engineer분들과 모여 진행한 해커톤에서 MVP를 제작해 팀원 분들의 의견을 들었고, Demand쪽 팀원분과 추가 기획이 필요한 내용들을 함께 정리하고 문구워싱들을 진행해 다른과제들을 하는 동시에 짬짬이 기능화를 진행했었습니다.
우선 첫 단계로 판매 조건 요청까지의 단계를 확인할 수 있는 튜토리얼 기능을 추가했고, 추후 계획으로는 고객분들이 레베뉴마켓을 이용하는 모든 flow를 아우르는 튜토리얼 시나리오들을 추가해 사용자분들이 서비스내에서 모든 과정을 자연스레 터득할 수 있도록 제공하는것이 목표입니다.
이렇게 Demand 조직에 도움을 준것처럼, 팀원분들이 어떤 문제를 겪고 있고 어떤 방식으로 도움을 줄수 있는지 지속적으로 다른 조직의 업무에 귀 기울이려 노력중에 있습니다.
글을 마치며,
팀에 합류한 이후 어떻게하면 효율적으로 일을 하며 또 팀이 만들어 가는 프로덕트 및 방향성에 도움을 줄 수 있을지에 대해 많은 고민을 하며 일을 해왔던것 같습니다.
이처럼 엔지니어링으로 제품을 만드는 것을 넘어 세상의 문제를 해결하고 고객과 팀의 비즈니스에 좋은 영향을 끼치고자 하는 분들이 있다면 함께 같이 이러한 과정을 함께했으면 좋겠습니다 :)
