프론트엔드 자동화, 모니터링

들어가며

안녕하세요, 프론트엔드 개발자 Lennon입니다.

거의 1년만에 글을 작성하는 것 같네요, 이직도 하고, 개인 생활도 보내고 많이 바빴던 것 같습니다.

현업 개발자라면 DX 개선을 위해 사소하게 PR 템플릿부터 CI/CD 자동화 등 사내에서 많은 자동화를 시도하거나, 경험해보셨을 것 같습니다.

오늘은 자동화와 모니터링에 대해 이야기해보려합니다.

다들 알고 계실 내용이겠지만, 현재 우리 회사에서, 내 프로젝트에서 적용하거나 기여할 수 있는 건 무엇이 있을까? 를 한 번씩 상기시키면서 간단하게 읽어주시면 감사드리겠습니다.

테스트 자동화

매일 배포되는 바쁜 스타트업의 제품이 항상 온전한 상태인 걸 검증할 수 있을까요?

우리는 배포 이후 서비스를 사용하는 유저 행동에 의해 가끔 뜬금없는 Sentry 에러 Slack을 마주하곤 합니다.

그때서야 아차 여길 고려 못했네 하고 버그를 fix하죠

복잡하고 다양한 기능이 존재하고, 바쁘게 개발되어 코드 복잡도가 큰 B2B SaaS에서 위 경험이 많았습니다. 유저는 돈을 내고 사용하는데 버그를 마주하면 별로 기분이 좋을 것 같진 않았어요.

그래서 위를 근거로 시간을 조금 할애해 테스트 자동화를 진행했습니다.

UI가 자주 바뀌는 부분은 유닛 테스트가 적합하지만, 우린 프로덕션의 핵심 로직을 기준으로 E2E 자동화를 진행했습니다.

단순하겐 모든 페이지가 정상 로드 되는가부터, 특정 핵심 로직들이 정상적으로 처리가 되는지 검증을 진행했어요.

매일 평일 오전과 서비스 배포 전 CI가 동작되며 핵심 로직들이 정상동작 되는지, 사이드 이펙트가 없는지 충분하게 검증할 수 있었습니다.

다만, E2E 테스트이기에 자주 수정되거나 너무 많은 리소스가 필요한 부분은 팀원과 논의 후에 적용 유무를 결정하면 좋을 것 같아요. 대부분 로직은 유닛 테스트로도 충분할 수 있고, E2E가 늘어날수록 결국 유지보수 비용이 늘어날 수 있으니까요.

CI/CD

아마 대부분은 적용을 하셨을 것 같습니다.

Vercel 플랫폼에 배포하면 큰 문제가 없겠지만, AWS S3, CloudFront 환경이라면 배포 자동화 및 매뉴얼 Rollback까지 작성하는 걸 추천드립니다.

Vercel은 빌드 이미지가 존재해 바로 롤백이 가능하지만, 수동으로 세팅하는 AWS 같은 경우엔 CI/CD상 롤백이 구현되어있지 않으면 빌드하는 시간이 존재해 서비스가 망가져도 빌드 이후에 정상화되는 사례를 많이 봤습니다.

또한, CI/CD가 너무 느려 스트레스 받는 동료분들도 보셨을 것 같아요. 원인을 분석하고 해결해보는 경험도 actions에 대해 깊이있게 알 수 있는 좋은 기회가 될 수 있을 것 같습니다.

Slack을 활용하신다면 CI/CD에 연동해서 web hook으로 배포 및 PR 알림을 활용해 DX를 높이는 경험도 좋을 것 같아요.

협업 툴 자동화

저희는 현재 기업에서 Jira를 사용합니다. 릴리즈 노트 또한 Jira에서 관리를 진행합니다.

전임자가 Jira 릴리즈 노트 자동화를 구현했지만, 커밋 메시지에 티켓 이름(FNBCTECH-XXX)가 들어가있지 않으면 자동화 CI가 실패되는 구조였어요.

또한, release 브랜치에서 특정 버전 릴리즈 커밋을 하지 않으면 버젼 기록도 되지 않았습니다.

가장 먼저 진행한 건 커밋 메시지 자동화였어요.

*/FNBCTECH-XXX 브랜치명이 FE의 기존 룰이었으며, FNBCTECH는 변하지 않는 고유 ID였습니다.

*/FNBCTECH-XXX 형태를 가진 브랜치에서 커밋하면 자동으로 husky의 prepare-commit-msg를 활용해

feat[FNBCTECH-554]: 로 메시지가 시작되도록 hook을 작성했어요.

또한, 누군가가 저 티켓 Number를 지우고 커밋하면 자동화가 실패하는 건 동일하니 husky를 통해 */FNBCTECH-554 형태의 브랜치일 때 브랜치명 내 티켓 이름이 포함되어 있지 않으면 커밋이 실패하도록 자동화했습니다.

release 브랜치 또한 자동화해 Jira 릴리즈 자동화 실패 확률을 0퍼로 수렴시킬 수 있었습니다.

Github도 Base 브랜치별로 다르게 PR Template을 만들거나, 실제 릴리즈 버전이 main을 바라보게 PR이 올라왔을 때 특정 컨벤션을 지켰는지, 특정 커밋이 존재하는 지 등 Actions를 통해 검증할수도 있을 것 같아요.

모니터링

그동안 만났던 FE분들이나, 면접 때 면접자분과 이야기해보면 현업에서 비용 문제로 모니터링 툴을 활용한 경험이 없으신 분이 많이 계셨던 것 같아요.

지표 기반 개선, 근거 기반 설득은 개발자에게 중요한 요소이니 한 번 이야기해보려합니다.

돈이 많은 기업이라면 Datadog RUM과 같이 비용이 큰 서비스를 이용해 백엔드까지 통합된 플로우로 개선 및 디버깅을 이어가겠지만, 대부분 스타트업은 모니터링에 큰 비용을 지출할 수 없을 것 같아요.

저희 팀은 Datadog RUM을 덜어내고 Sentry, GA, GTM, Clarity를 활용하고 있습니다.

이유는 기존 RUM sampleRate가 0.3으로 모든 세션을 받을 수 없었고, 에러만 인덱싱하는 기능 가격이 높았기에 목적에 맞는 Sentry로 이관을 결정했습니다.

현재는 MAU 40-50만 여러 개의 프로젝트들을 운영하지만, iOS, AOS, FE 모두 Sentry Team Plan으로 한 달에 $29에 해결되도록 최적화를 진행하고 있습니다.

아마 당분간은 에러를 많이 없애고,, 무시할 에러들 리스트도 잘 정리 후 적용해야할 것 같아요.

GA4, GTM, Clarity 무료이니, 모니터링 툴이 없다면, 비용 부담없이 서비스에서 한 번 활용해보시는 걸 꼭 추천드립니다.

코드 품질 측정 도구 (sonarqube)를 활용해 품질 근거를 만드는 경험, 코드 리뷰 자동화 (copilot, coderabbit) 등을 활용해보는 경험도 좋을 것 같아요.

번외

요즘은 터미널 명령어를 쓸 때 오타가 많이 나 zsh 터미널 alias를 활용해 저만의 명령어를 만들고 있어요.
물론 Ai가 탑재된 터미널들이 많지만,,, 터미널로 대단한 걸 하지 않는 저는 아직 IDE 내 터미널이 익숙한 것 같아요

gpush = git push origin '현재 브랜치'
gpull = git pull origin '현재 브랜치'
gp = git pull origin
gc = git checkout 
gcb = git checkout -b
gb = git branch
등등....

저에게 맞게 alias하니 오타도 별로 발생되지 않아서 좋았던 것 같습니다.

마무리

이번 글에선 자동화, 모니터링 주제에 대한 경험을 공유해 보았습니다.

긴 글 읽어주셔서 감사합니다.
주제와 관련해 좋은 생각이 있으면 댓글 부탁드립니다.

추가로, 현재 저희 회사에서 저와 함께 일할 FE 2분을 모시려합니다. 많은 관심 부탁드립니다.

https://www.wanted.co.kr/wd/289981