토스, 프론트엔드 다이빙 클럽 회고

 

이미지 레퍼런스 - https://toss.tech/article/frontend-diving-club

계기

저는 링크드인에서 토스를 팔로우하고 있었는데, 우연히 토스에서 진행하는 프다클(프론트엔드 다이빙 클럽)이라는 모임이 프다클 다이버를 구한다는 소식을 보게 되었습니다. 저희 회사에는 저를 포함한 3-4명의 프론트엔드 개발자가 있기 때문에, 나름 교류를 많이 하는 편이라 굳이 회사 밖에서의 네트워킹을 생각하진 않았습니다. 혹은 다를 이유가 있어서일지는 모르지만, 지금 곰곰이 제가 네트워킹을 선호하지 않았던 이유를 생각해 보니, ‘할 일이 많아서?’, ‘혹은 우리 회사의 개발 문화를 다른 회사의 개발자 분들께 소개하기에는 만족하지 않아서?’, ‘내가 아직 부족하다고 생각해서 ?’ 등이 떠오르는 것 같습니다.

 

다양한 이유로 네트워킹을 선호하지 않았지만, 첫 번째 개발자 네트워킹으로 프다클이 신청하였고, 감사하게도 프다클에서 좋은 시간을 보내고 왔습니다. 제가 그 당시에 프다클을 신청한 이유는 ‘이제는 한번 다른 분들을 만나보고 싶다!’, 회사 안에서는 해결하지 못했던 나의 고민들을 ‘전혀 모르는 환경에서 일하고 계시는 같은 직군 개발자 분들과 나누고, 교류하고 싶다!’라는 생각이 컸던 것 같습니다.

 

최근 읽었던 책을 (오티움) 계기로 프다클에 신청하였고 정말 좋은 기회로 다른 분들과 뛰어난 개발자 분들과 이야기를 나눌 수 있었습니다.

 

오티움: 살아갈 힘을 주는 나만의 휴식

오티움 | 문요한 - 교보문고

 

이 책은 정신과 전문의가 작성한 책입니다. 여가 시간을 효율적으로 보내는 방법, 진짜 ‘나’에게 온전한 휴식을 부여하는 방법을 담은 책입니다. 너무 무겁지 않은 책이니, 휴식에 대한 내용이 고민이 될 때 읽어 보시기를 추천드립니다 ㅎㅎ

 

놀러 오세요! 프론트엔드 다이빙 클럽

놀러오세요! 프론트엔드 다이빙 클럽

product developer로 커리어 빌딩하기

현재 저는 웹 프론트엔드 개발자로서 리뉴얼 릴리즈를 정말 정말 코 앞에 앞두고 있습니다. 매일까진 아니지만, 야근과 더불어 주말에도 이 프로젝트 끝내고 싶다는 마음으로 달리고 있네요 🏃🏼🏃‍♀️🏃‍♂️.

 

저의 이번 리뉴얼 프로젝트에서의 담당 업무는 이전 기능 들 중 필요한 기능들을 마이그레이션 하고, 도메인 익스퍼트들과 시장의 니즈에 맞춘 신규 기능을 개발하는 역할을 했습니다. 신규 기능으로는 B2C로 확장하기 위한 기능들이 많이 포함되어 있었습니다. Socket.io 통신 (DM), 댓글 달기 연관 기능, 유저 프로필 및 상대방 프로필을 위한 파일 업로드 기능, 좋아요, 팔로우, 북마크를 포함한 기존 기능과의 고도화된 인터렉션을 포함해서 말이죠.

 

기존 서비스가 부족한 것은 아니지만, 제가 느꼈을 때는 기존 프로젝트에서 언어적, 기술적인 부채가 일부 느껴졌고, 팀원들과 합의하여 다양한 기술들을 도입할 수 있었습니다. 이번 리뉴얼 프로젝트에는 위의 기능적인 것 외에도, Next.js와 typescript, react-query 등을 바탕으로 새로운 전략을 도입하였고, SEO, GA4, Sentry를 적용하는 등, 모든 범위의 기능들에 대해 전반적으로 다루면서 웹 리뉴얼 프로젝트의 얇고 넓은 범위를 담당했던 것 같습니다.

 

정말 순탄치 많은 않았고, 모든 게 처음인 저에게는 프로젝트의 초기화부터 마무리까지 너무 큰 경험이었던 것 같습니다. (아직 끝나지 않았지만, 끝이 보이기 때문에 이렇게 쓸 수 있을 것 같아요 호호,,,) 이번 리뉴얼 프로젝트 기간 동안 맡았던 기술과 경험, 그리고 기술을 선택하면서 느꼈던 고민들을 나누고 싶었는데, 토스 측에서 감사하게도 이야기할 좋은 기회를 주셨습니다 ㅎㅎ,,

 

제가 프다클이 신청하면서 선정한 주제는 ‘product developer로 커리어 빌딩하기’ 였습니다. 단순히 MVP 단위로 한 기능만을 빠르게 개발하는 것이 아닌, 기존 제품에 대한 이해를 바탕으로 새롭게 추가된 기능까지 더해지는 프로덕트 자체를 개발하는 업무라고 느껴서 이 주제에 관심이 갔던 것 같습니다.

 

저희 아고라에는 토스 플레이스의 유건님, 백광민 님이 참여해 주셨습니다. (👏🏻) 토스 측에서 3가지 주제를 제시해 주셨는데, 그 주제를 바탕으로 파생되는 공감되는 경험에 대해 이야기해보려고 합니다.

기억에 남는 주제들

• product developer로서 팀의 단결력을 높이거나 새로운 문제 해결방법을 찾기 위해 노력했던 경험이 있다면?
• 제품 개선을 위한 고객의 목소리는 어디까지 반영해 줘야 이상적일까요?
• BI 툴을 쓰시나요? 쓴다면 어떤 효용가치가 있나요?
• PR이 승인될 때까지, 얼마나 걸리시나요? (얼마나 많은 대화를 나누시나요?)

1. product developer로서 팀의 단결력을 높이거나 새로운 문제 해결 방법을 찾기 위해 노력했던 경험이 있다면?

• 우려 사항을 미리미리 얘기하기
• 객관적인 지표로 얘기하기
• 기존 유저를 지키거나, 신규 유저를 스케일업 할 것인지 고민하기 - 타깃을 명확히 정하기
• 문제를 제기할 때, 대안을 반드시 같이 제시해 줄 것
  • 레퍼런스
  • 예시 코드 등
• 대상이 피드백이 받을 수 있는 여력이 되는지 고민해 보기

2. 제품 개선을 위한 고객의 목소리는 어디까지 반영해 줘야 이상적일까요?

• b2c에서 고객은 아무것도 모른다는 가정하에 제품을 만들었던 것 같아요
• b2b는 요구사항이 명확하나, 너무 많다. ‘경쟁사의 기능을 구현해 달라’
• 반영에 대해서는 우선순위가 중요할 것 같아요
  • 회사가, 팀 전체가 한 곳을 바라볼 수 있도록 노력하기
• 웹 접근성.. 스크린 리더
  • 컨설팅 업체에게 시각 장애인 분들의 지속적인 피드백을 받는다
  • 시멘틱 하게 짜도록 노력하기
  • img에 alt를 반드시 달아주기..!
  • 인권 위원회까지 올라간 경험이 있음

3. BI 툴은 얼마나 사용하고 계신가요? 어떤 효용가치가 있나요?

• 메타데이터를 넣어서 CS가 들어왔을 때, 무슨 에러를 통해 유추할 수 있도록
• CS를 추적하는 용도로 사용하는 것 같다
• 데이터 드리븐을 하려고 하면 어느 정도 데이터가 쌓이는 것도 중요한 것 같아요
• 가능하면 부족하더라도 많이 쌓아두는 편이 좋을 것 같아요

저는 저희 웹 서비스의 추가적인 BI(Business intelligence)로 GA4, Sentry를 택했습니다. 접근하기 쉽고 웹 상에 해당 툴을 적용하기 위한, 활용할만한 예시 정보가 많았기 때문입니다. 저희는 B2B단계에서 MAU가 매우 높지는 않은 상황이었기 때문에, B2C로 갈 때 BI툴의 고도화가 필요한 상황이었습니다. 이 부분도 맞는 얘기지만, 다른 개발자 분은 BI 툴을 기술적 CS(customer service)에 활용하고 계신다고 말씀해 주셨습니다.

 

Sentry를 예로 들어보겠습니다. 기술적인 태깅을 할 때, 우리는 유저의 메타데이터를 삽입할 수 있습니다. 단순히 DB에 저장된 id 값일 수도 있고, 유저에 대한 상세 정보일 수도 있습니다. 이런 정보를 활용하여 어떤 유저가 문제를 겪었을 때, 유저에게 직접 문제 상황 설명을 요청하는 것보다, 유저의 고유 데이터를 바탕으로 추적할 수 있습니다.

 

GA4를 통해 특정 유저 또는 유입 경로를 분석하여, 우리가 원하는 흐름 (예를 들면 서비스 구독)을 유도하기 위한 전략을 수립할 수 있고, A/B 테스트의 기반이 될 수도 있습니다. 그렇기 때문에 여건이 된다면 다룰 수 있는 선에서의 BI 툴을 사용하는 것도 웹 서비스 고도화에 도움이 된다고 느꼈습니다.

4. PR을 얼마나 오래 가져가시나요?

• 데드라인을 정해놓은 뒤, 절충안을 둔 채로 PR을 받아준다.

 

저희 서비스는 리뉴얼을 앞두고 있지만, 대부분의 피쳐 개발 또는 리팩터링은 PR을 통해 팀원들의 확인과 피드백을 받는 편입니다.

 

기능 개발은 새롭게 도입한 라이브러리가 있는지, 비즈니스 로직에는 문제가 없는지, 다양한 상황에 대응이 가능한지 등을 확인하는 편입니다.

 

리팩터링의 경우, 변수 명 또는 폴더 구조에 대한 변화가 있는지, 개선을 통해 얻을 수 있는 점은 무엇인지, 리팩터링 이후에도 기존 기능과의 예상되는 동작에 문제가 없는지를 확인합니다.

 

이렇게 PR을 하다 보니, 뭔가 한 기능의 효용 가치에 대해 논쟁, 논의하기보다는, 상대방의 의견을 대부분 수용하고 approve 받는 흐름이 생겼다는 것을 인지했습니다. 대부분 혼자서 생각하는 것보다 나은 생각이거나, 도움이 되는 내용이기 때문에 저 또한 수용하는 편입니다.

 

가끔은 조금 더 논의를 해보거나 효율을 측정해보고 싶기도 하지만, 시기가 시기인지(리뉴얼을 바로 앞둔 시기)라 따로 회의까지 가져가기에는 시간이 부족하다는 핑계로 대부분 적용하고 넘어갔었습니다. 그래서 타 회사 개발자 분들은 이런 PR기간에 대해 얼마나 가져가는지 궁금했던 것 같습니다.

 

이야기를 해봤을 때, 정말 느낀 점이 많았습니다. 같은 스타트업 업계에 계신 분들이 많아서 그런지, 시기와 상황에 따라 달라지지만 대부분 수용한다고 하셨습니다. 단, 위에서 얘기한 것처럼 뭔가 ‘논의하고 싶은 부분이 있거나 바꾸고 싶은 부분이 있다면, 본인이 대체 코드 또는 더 나은 코드를 제안하면서 논의를 하면 좋을 것 같다’라고 말씀을 주셨습니다. 정말 맞는 말씀이었습니다.

 

저는 PR을 올릴 때, 제가 만들 수 있는 최선의 코드를 PR에 올리려고 노력합니다. 저뿐만 아니라, 다른 팀원 분들도 그러시겠죠. 이렇게 만든 코드가 마음에 안 든다고 해서 무작정 ‘이해하기 어려워요’, ‘이렇게 해보면 어떨까요?’와 같이 단순히 의견만 전달하는 것이 아닌, ‘해당 메서드의 이 쪽 부분이 이해가 안 되는데 설명해 주실 수 있나요?‘, ‘이 부분은 이렇게 바꾸면 조금 더 효율적일 것 같습니다!’ 등 코드를 예시로 들어가며 질문을 한다면 상대방의 입장에서도 조금 더 수용적인 자세로 PR을 바라볼 수 있을 것 같습니다.

 

마치며

이런 네트워킹에 처음 참여해서 익숙하지 않았지만, 자리를 마련해 준 토스와 함께 아고라를 이끌어주신 토스 플레이스의 유건님, 백광민 님 감사합니다 ^0^,,, 덕분에 너무 재밌게 의견을 교류할 수 있었습니다. 내가 겪은 일처럼 공감해 주시고, 적극적으로 참여해 주신 다른 동료 개발자 분들께 감사합니다. 저는 스스로 '열심히 하고 있어', '잘하고 있어'라고 생각하지만, 이런 계기를 통해 더 뛰어나고 다양한 일을 하시는 개발자 분들과 얘기하며 더 열심히 해야겠다. 더 노력해야겠다는 것을 많이 느꼈습니다. 개발뿐만 아니라, 팀으로써의 가치를 높게 두시고, 함께 개발해 나가는 문화를 위해 힘써주시는 다른 개발자분을 통해 또 다른 열정을 불러일으킬 수 있었습니다. 너무 자주는 아니더라도, 참여할 기회가 있다면 적극적으로 참여해야겠다고 느꼈던, 토스의 프론트엔드 다이빙 클럽이었습니다.