프론트엔드 다이빙 클럽(23.11.09)

📌 참조 : https://toss.tech/article/frontend-diving-club-agora

장소 : 아크스페이스 https://naver.me/xWNifzt7

---

💡 본인이 신청한 주제와 관련해서 토스 개발자 두 분과 다양한 곳에서 프론트엔드 개발자로 일하고 있는 사람들이 모여 두 시간 정도 토론하는 시간을 가졌습니다. LG 유플러스, 바로팜 외 여러 스타트업의 상황과 개개인의 고충, 사고 방식 등을 듣고 배워갈 수 있는 좋은 시간이었습니다. 다만 다른 주제에 대해서는 참여하기가 어려웠던 점이 아쉬웠습니다.

 

토론 주제

 

1. 팀 결단력 및 소통을 위해 노력한 경험

해당 주제를 제시한 분은, 회사가 빠르게 성장함에 따라 각 팀 별 간 소통이 점점 단절되고 서로 다른 목표를 향해 달려가는 느낌을 받았다고 합니다. 개발팀 내적으로는 좀 더 견고하게 성장하는 계기가 되었지만 디자인팀이나 기획팀과의 마찰이 자주 일어나게 되었는데, 이는 개발자의 시선에서는 어렵거나 필요하지 않은 부분이 디자인팀이나 기획팀에서는 필수적이라고 여겨지는 의견 차이로부터 발생한 것 같다고 했습니다.

이러한 주제에 대해 토스 플레이스 백광민 개발자님은 본인의 의견을 제안하기 위해 일단 a. 해당 부분이 왜 필요하지 않은지, b. 더 나은 방향이 있지는 않은지, c. 개발을 진행했을 때 소요될 시간 및 리소스 등 의견을 뒷받침 할 수 있는 대안과 레퍼런스를 최대한 찾아서 같이 제시한다고 했습니다. 다른 개발자분은 이 의견에 더해서 서로 간의 신뢰가 중요한 것 같다고 말했습니다. 근거를 통한 의견을 제시한 뒤, 자신의 의견을 증명하면 서로 간의 날카로운 의견도 신뢰가 기반이 되어 감정이 상하지 않게 되는 경우를 많이 보았기 때문입니다.

 

BI 활용툴

1. GA
   UA 는 더 이상 서비스하지 않고 보통 대부분 GA 를 활용하고 있다고 합니다.
2. Amplitude
   GA 만큼 자주 언급되는 플랫폼이지만 토스에서는 사용을 권장하지 않고 있다고 했습니다. 이는 토스의 최고 결정자 분들이 amplitude 가 sass 형태이며 해당 서비스에 금융 정보를 제공하고 싶지 않다는 의견이 있어서였고, 토스 내부에서 자체 BI 활용툴을 개발하여 사용하고 있다고 합니다.
3. 데이터독
   한 회사는 해당 서비스를 활용하고 있다고 했는데 개발자 입장에서 모든 버튼에 이벤트를 걸어둬야하는 번거로움 없이 간편하게 쌓인 데이터를 통해 지표와 로그를 확인할 수 있다고 했습니다. 다만 편리한 만큼 비용이 많이 들어간다는 단점이 있다고 합니다.

✅ BI 를 활용하면 좋은 점

가장 먼저, 개발자에게 동기부여가 될 수 있다. 자신이 만드는 product 의 사용자 지표와 쌓여가는 데이터를 시각적으로 확인이 가능하며 위에서 언급된 자신의 의견을 뒷받침하는 근거로도 활용이 가능하다. 또한, 마케팅 팀에서 효과적으로 product 의 홍보 및 소개에 사용할 수 있다.

 

도메인 지식을 코드에 반영하는 과정

프론트엔드 개발자에게는 product 와 연관된 대부분의 도메인 지식을 습득하고 이해하는 과정이 중요하다고 합니다. 초기 단계 제품의 도메인을 이해하고 이를 코드에 번역하고 반영하는 과정이 필수적이며, 이는 기획자와의 원활한 소통에도 기여하게 됩니다. 예를 들어, 요금 및 카드 결제 부분을 담당하게 된다면 PG 사 연결 이전에 요금 정책이나 결제 관련 기획에 대해 충분한 이해가 필요하며 관련하여 전반적인 flow 를 알고 있어야 합니다. 또한, 적절한 기능 구현을 위해 이를 잘 조합하여 코드에 반영하는 것 또한 중요합니다.

 

제품 개선을 위한 VOC를 어디까지 반영해야 이상적인가

해당 주제에 대해서는 스타트업 특성상 중요한 부분이기 때문에 많은 얘기가 오고 갔습니다. B2B의 경우 정확한 요구사항을 너무 많이 제안한다는 문제점이 있었고, 경쟁사와 비교하여 더 많은 욕심을 내거나 서비스의 커스텀화를 과하게 요구하는 경우가 발생하기 때문에 적절한 기준을 세워 이외의 기능은 사용자에게 맡기는 방식으로 가야한다는 의견이 있었습니다.

 

한편으로, B2C의 경우는 고객이 서비스와 기능에 대해 아무것도 모른다는 전제를 가져야 VOC 대응에 편할 것이라는 토스 플레이스 개발자님의 의견도 있었습니다. 토스의 예를 들어, 상세 페이지를 구성한 뒤 해당 상세 페이지 진입 시 쿠폰을 적용하면 가격이 할인되는 정책이 있었고, 해당 정책을 반영한 기능은 버튼을 클릭하여 쿠폰을 받은 뒤 다시 상세 페이지에 진입하면 쿠폰이 적용된 할인 가격이 보이는 것이었습니다. 이와 관련된 VOC 는 버튼을 통한 쿠폰 발급을 진행하지 않은 고객이 쿠폰이 자동으로 반영되지 않는다는 것이었고, 쿠폰 적용 자동화를 해야하는가에 대해 남용과 오용에 대한 부분까지 생각해야하는 리소스가 발생하여 해당 VOC 는 처리하지 않는 방향으로 진행되었다고 합니다.

 

즉, VOC 를 모두 반영해주는 것은 모두가 원하는 바이지만 현실적으로 불가능하기 때문에 어느 정도 타협을 해야하고 이 때 타협의 기준은 회사의 방향성과 목표가 우선되어야 합니다. 스타트업의 경우 VOC 를 전부 다 사용자의 니즈로 파악하기 쉬운데, 그러다보면 product 의 모습이나 방향성이 오히려 흐트러질 수 있기 때문에 분명한 기준을 토대로 해당 피드백이 합리적인지 아닌지에 대한 판단을 내리고, 우선순위를 정해서 처리할 필요가 있습니다.

 

✅ 웹 접근성

VOC 중에서는 종종 웹 접근성과 관련된 부분도 있습니다. 이와 관련하여 div 의 남용보다는 시맨틱 태그를 제대로 활용하는 방법, 이미지의 alt 를 적절하게 작성하여 브라우저 스크리닝 시에 해당 이미지의 url 을 읽지 않도록 하는 방법 등 코드 작성 시 기본에 충실해야 한다는 의견이 있었습니다. 토스의 경우, 웹 접근성을 위해 정기적으로 시각 장애인을 통해 검증하는 기관에 맡겨 이 점을 보완하고 있다고 했습니다.

웹 접근성과 관련하여 쇼핑몰 상세페이지의 경우, 사방넷 등의 호스팅 쪽에서는 소호몰 업체가 이미지를 단순히 업로드 하기만 하면 상세 페이지에 이미지가 뜨기 때문에, 이미지 태그의 alt 값이 부여되지 않아서 여러번 VOC 가 들어왔으며, 인권위원회 소송까지 걸린 이슈가 있었다는 이야기도 나왔습니다. 웹 접근성은 간과하기 쉽고 코드를 작성하다 보면 놓치거나 지나치기 쉬운 부분이지만, 생각보다 무거운 책임이 걸려있으며 기본적인 자세이기 때문에 대부분의 상황을 커버할 수 없더라도 의식하고 있어야 한다는 게 대부분의 결론이었습니다.

 

테스트 코드 그리고 에러 추적

테스트 코드 작성과 관련해서 토스 개발자님은 프론트엔드 개발자에게 테스트 코드를 전부 다 작성하는 건 비효율적이라는 의견이었습니다. 프론트엔드 개발의 특성상 다양한 외부적 환경에 영향을 지속적으로 받기 때문에 테스트 코드를 작성하는 게 의미가 없는 부분들도 분명히 존재하기 때문입니다. 예를 들어, 테스트 코드를 작성하는 와중에 디자인이 변경될 수 있으며 기획이 바뀌게 되어 기능 수정이 필요할 수도 있는 경우가 종종 발생하곤 합니다. 따라서 토스의 경우, Utils 이나 특정 핵심 기능들 (ex. 고정된 버튼) 에만 테스트 코드를 작성해두었고 이외에는 그 때 그 때 에러를 추적한다고 했습니다.

 

에러 추적의 경우 sentry 에 대한 얘기가 많았습니다. 다른 서비스를 사용하는 회사도 있었지만 대체로 sentry 가 지배적이었고 추가적으로 비용이 더 드는 다양한 로그 시스템을 사용하는 곳도 있었습니다. 해당 주제를 말씀하신 분이 sentry 를 도입하게 된 이유는 팀원이 알기 전에 먼저 에러를 캐치하자, 라는 생각으로 에러 모니터링을 하기 위해서라고 했습니다. 토스 개발자님은 이와 관련해서 매번 에러를 재현하기 어려우며 재현에도 리소스가 들기 때문에 sentry 의 메타 정보(유저 정보)를 통해 해당 유저의 에러가 어디서 어떻게 발생한 것인지 빠르게 체크하는 용도로 의의가 있다고 합니다. 즉, CS 를 효과적이고 효율적으로 추적하는 용도로 sentry 는 굉장히 유용한 방법이라는 결론이었습니다.