[프로덕트♟️] 개발 스택 및 데이터 수집에 관하여
Data Acquisition, Dev Ops, Staging
[매쉬업벤처스]의 이승국 파트너님 조언을 간략하게 Q&A 형태로 정리해보았습니다.
초기 창업팀에게 도움이 되고자 작성하여 공유합니다.
Q. 현재 저희 서비스의 스택은 웹은 Nest.js와 React, 앱은 React Native(RN)로 구성되어 있습니다. 어떤 특징이 있나요?
▶ RN은 서비스의 사용성 및 구조적 복잡성이 증가할 때 그 중요도가 높아진다. 특히 피드 로딩과 같은 구조적 복잡성이 있는 화면을 웹뷰로 구현할 경우 퍼포먼스가 떨어지기 때문에 RN으로 전환하는 것이 좋다. 또한 네트워크 환경이 좋지 않거나 데이터 속도 제한이 있는 외국인 유저들을 대상으로 초기에 로딩 속도를 줄일 수 있는 장점이 있으니 참고.
개인 인사이트 ✍
기능과 스크린이 많아지면 RN의 필요성이 더욱 커지는 것 같다. 아티투의 경우 홈 피드 개수가 많고 구조의 복잡성이 강해질 것을 염두에 뒀기에 RN의 중요성을 인지하는 계기가 됐다.
Q: 배포 효율성을 높이기 위한 DevOps와 Staging 환경은 어떻게 구성해야 하나요?
▶ 이상적인 Staging 환경은 세 단계로 나누어진다.
1. Dev(내복) 2.Staging(외출복) 3.Production(정장).▶ 이 구조는 배포 효율성을 높이고, 버그를 쉽게 식별할 수 있게 한다. 이렇게 단계별로 환경을 나누면 안정성을 높이면서 개발 속도 또한 유지할 수 있다.
개인 인사이트 ✍
현재 내부 프로세스에서는 Staging 없이 Dev와 Production 2단계로 운영 중. 실제로 서비스 운영 중 프로세스 부재로 인해 중대한 버그가 잦게 발생하는 것으로 파악되어 Staging 단계 도입을 검토했다. 결과적으로 3단계로 설계하지 않고 2단계로 유지했고, 현 상황에서의 안정성 강화를 진행했다.
Q: 데이터 수집을 어떤 방식으로 하면 좋을까요?
▶ 모든 이벤트를 수집하지 마라. 특히 리소스가 적은 상황이라면 더더욱. 데이터를 전부 모아두면 ‘언젠가 쓸 일이 있겠지’라는 착각에 빠지기 쉽다. 하지만 대부분 활용되지 않는다. 필요한 이벤트만을 우선순위에 따라 측정하는 게 좋다.
▶ 또 이벤트를 웹뷰에 심으면 앱과 웹의 구분이 모호해진다. 앱 애널리틱스 SDK를 사용하는 것을 권장한다.
해당 세션 이후에 무엇을 배웠고, 어떻게 바뀌었나요?
✍ 작업 프로세스를 보다 정교화해야 할 필요성을 느꼈다. 따라서, 노션, 피그마, 깃허브까지 내부적으로 진행하는 서비스 제작 프로세스를 팀과 함께 점검했다. 이에 따라 [서비스의 안정성, 기록의 엄밀함 vs 빠른 속도의 메이킹]의 선택지가 생겼다. 우리 팀은 후자를 택했다.
✍ 다만, 현재 시스템의 만족도가 높았다고 하더라도, 더 나은 목표 달성을 위해 추가적인 도구나 프로세스를 도입할 여지가 있었다. 이에 따라 스프린트 프로젝트 관리를 위해 'Clickup'이라는 별도 툴을 사용했다. Clickup은 노션보다 가볍고, 아사나보다 복잡도가 낮은 툴이었다. 그리고 무료라는 큰 장점이 있다.
내용이 조금이라도 유익하셨다면 좋아요 부탁드립니다.
읽어주셔서 감사합니다.
