빠르게 성장하고 있는 나인투원의 웹 프론트엔드팀은 현재 두 명으로 구성되어, 나인투원 회사 웹사이트와 일레클 앱 내외의 서비스 웹뷰, 서비스 운영을 위한 Operation/Admin 웹 페이지, 고객응대를 위한 CS 페이지, 지리적 정보를 활용한 데이터 시각화 등을 개발하고 있습니다. 이러한 과정에서 필연적으로 프로덕트팀이나 백엔드 엔지니어, IOS/안드로이드 엔지니어와 함께 협업이 이루어지지만, 이번 글에서는 프론트엔드 팀의 회의 내용을 통해 두 명의 프론트엔드 엔지니어가 어떤 문제를 어떻게 고민하고 해결해나가는 지 살짝 훔쳐보도록 하겠습니다!
1. 회의 진행 방식과 배경
지난 2월 재영님이 웹프론트엔드 개발팀에 합류하신 후 2명이 된 프론트엔드 개발팀은 업무를 진행하며 긴밀하게 논의가 필요한 경우, 논의를 요청하는 멤버가 직접 회의를 요청하여 진행하기로 하였습니다.
주기적인 미팅보다 요청에 의한 미팅을 진행하게 된 배경은
- 매일 아침 스프린트 회의와 주간 회고를 통해 전체적인 프로덕트와 프로세스에 관한 맥락이 지속적으로 공유되고 있고(나인투원에서 진행되고 있는 스프린트는 다영님이 쓰신 ‘나인투원이 제품을 만드는 과정 — 스크럼’을 통해 파악할 수 있습니다!)
- 현재 2명으로 구성된 팀이기 때문에 필요할 경우 바로 옆 자리에서, 재택근무 시에는 화상 콜을 요청하여 실시간으로 매일의 업무 진행 상황과 문제점을 적극적으로 공유할 수 있기 때문이었습니다.
주기적인 미팅 날짜를 잡기 보다 큰 단위의 업무를 시작하거나 종료하면서 개발적인 부분에 관해 혹은 애로사항에 관해 필요에 의해 유동적으로 논의를 진행하는 것이 더욱 효율적이라고 판단했고, 지난 두 달간 세 번의 회의를 통해 어느정도 만족스러운 프로세스가 되었다고 생각합니다.
회의를 요청하는 사람은 회의 문서를 생성하여 논의가 필요한 내용을 미리 정리합니다. 문서 제목은 약간의 재미와 인간적인 요소를 넣어 진행 시점의 본인의 감정이나 생각을 간단하게 표현하기로 했습니다.(보통 문제 상황에서 회의를 요청하기에 작성된 제목의 느낌이 좋지만은 않군요..)
2. 안건1 — 일레클 미디엄에 프론트엔드팀 회의를 주제로 글을 올리고 싶어요.
함께 참여하는 회의의 내용을 공개하는 것이기에 같이 회의를 진행하는 동료의 의견을 확인했습니다.
명곤: 저번에 미디엄에 글을 올려보았는데, 이번에는 오늘 회의 내용을 미디엄에 올려보려고 해요. 내용을 공개하는 것에 부담이 있을 수 있지만, 솔직하게 우리 프론트엔드 개발팀의 업무 진행방식을 공유하는 것도 의미가 있을 것 같습니다. 재영님은 개인 블로그에도 개발 관련된 내용을 정리하고 계셨는데 우리 회의의 진행 방식과 내용을 소개하는 것에 대해 어떻게 생각하시나요?
재영: 좋습니다. 채용 공고에서 보았던 내용도 마음에 들었어요. 또 블로그 글을 올리는 것을 저도 좋아해서.. 다만 저도 글 업로드 전에 내용을 확인하면 좋겠습니다.
명곤: 재영님이 일레클 미디엄에 직접 글을 써보시는 것 어떠신가요?
재영: 신경써서 작성하지만 회사 이름으로 글이 나간다면 글 내용이나 개발적인 내용에서 부족한 부분이 보이면 다소 부담스러울 수도 있을 것 같아요.
명곤: 그렇군요… 저도 그래서 이번에 회의를 주제로 글을 쓰고 반드시 피드백을 요청 드릴게요! 적극적으로 피드백 해주시면 감사하겠습니다.
(채용 공고: 웹 프론트엔드 개발자 채용 공고를 작성하면서, 딱딱하거나 지나치게 가벼운 느낌이 들지 않으면서도 솔직하게 소개하고자 노력을 했었는데요. 개발을 진행하는 현재 시점에서의 솔직한 고민과 상황을 전달하는 것이 지원자에게 적합한 정보를 주고 함께 업무를 진행하는 팀원을 뽑는데 필요한 것이라고 생각하여 작성하였습니다. 다음은 채용 공고 내용의 일부분입니다.)
(이를 통해, 리액트 마스터 재영님과 함께 할 수 있었고 즐겁게 프론트엔드 개발을 진행하고 있습니다!)
3. 안건2 — 랜딩페이지 마이그레이션
본격적인 다음 안건은 랜딩페이지 마이그레이션 작업을 진행하면서 필요한 논의들입니다. 현재 일레클을 서비스하고 있는 나인투원의 공식 웹사이트 https://elecle.bike 는 koa.js + pug와 jQuery의 페이지 렌더링 방식으로 구현되어 있는데요. 지난 번 새롭게 디자인된 웹사이트를 구현하며 간단한 작업이 될 것으로 예상하여 이미지뷰나 간단한 javascript를 활용하며 가볍게 사용하던 pug 형태를 그대로 사용하긴 했지만, 실제로 구현을 한 후 반복적인 컴포넌트, 페이지 구성 등 react 프레임워크로 구현한다면 더 효율적이고 지속적인 관리가 가능할 것으로 판단하여 진행하고 있는 태스크입니다. 위 채용공고에서 예고했던 react/Next.js를 이용하여 서비스 웹뷰와 함께 서비스하고자 합니다. 간략한 회의록을 통해 회의 내용을 살펴보시죠!
1) API request 분리
- 논의 배경: 나인투원 웹사이트에서 일레클 미디엄의 글의 목록과 제목, 내용, 썸네일을 볼 수 있도록 하기 위해 https://medium.com/feed/elecle-bike 의 rss데이터를 https://api.rss2json.com/ API를 활용, 데이터를 가져옴. 이번 프로젝트에서 API call을 다루는 것이 처음이라 API 호출을 프로젝트상 어떤 구조에서 진행할 지
- redux/recoil 상태관리 라이브러리 사용하더라도 API call은 별도로 분리하는 게 대세(?)일까 ⇒ Yes
- 본 프로젝트에서 필요한 분류: 웹사이트/앱 내 웹뷰/공통 > API call, asset, recoil 등 필요한 경우 이 세 가지 기준으로 분류
- 추가적으로, API 요청을 처리할 경우 어디까지 처리할 것인가? 1) request 자체만 리턴, 응답 값에 대한 처리는 API를 요청한 곳(파일)에서 한다. 2) 응답에 대한 에러 핸들링이나 response data 검증/변환을 처리하고 에러/데이터만 리턴하도록 처리한다.
2) IntersectionObserver 후기
- 논의 배경: https://elecle.bike/service 페이지 앱 내 이용 방법을 react로 재현(스크롤링에 따라 고정된 이미지 프레임 내부의 이미지가 정적으로 변화)을 하면서 스크롤 이벤트가 실행되는 y지점을 알아내기 위해 element(해당요소)의 y 값을 가져와야 하는데, scrollTop()이나 getBoundingClientRect()를 사용하면 리플로우가 발생하여 퍼포먼스를 고려하여 개발하고자 IntersectionObserver를 도입
- 재영: 구현 성공, 프레임 위치를 계산 해야함 ⇒ element scroll top을 활용해서 boundingClientRect 사용한다던지 타겟 엘리먼트의 position 구할 때 reflow현상 ⇒ 퍼포먼스에 좋지 않다. 1) IntersectionObserver에서 boundingClientRect로 포지션 가져온다.(해당 엘리먼트의 포지션을 reflow발생시키지 않고 가져오기 위해서) 2) scroll 이벤트리스너 ⇒ 스크롤 에 의해 컨텐츠를 변화시켜야 하니까 (스크롤에 따라 currentElement를 설정하여 변경시킴) — intersectionObserver를 통해 획득한 y값을 사용
- 명곤: https://elecle.bike/people 나인투원 스피릿 1~9 fade in + bottom to top 떠오르는 효과를 구현해보고자 하였음. ⇒ 9개 아이템을 가지고 있는 컨테이너를 기준으로 9가지 children를 각각 intersectionObserver로 isIntersecting일 때 css변화를 통해 애니메이션 효과를 부여하려고 하였음.
- 기존 aos로 구현된 레퍼런스(목표)가 있는 상황에서 디자인적으로(디자이너가 보기에) 같거나 더 나은 ui 경험을 주면서 개발적으로 효율적인(reflow발생하지 않는다, 새로운 기술-intersectionObserver을 효과적으로 도입한다 등) 방식을 달성하고자 시도, 컨테이너에 intersectionObserver 설정 ⇒ 불필요, 개별 SpiritComponent에 observer를 달아서 시도를 했는데… 시간이 지나치게 많이 소요되어 기존의 aos 라이브러리를 사용했다.
- 구현이 어려웠던 이유: 디자인 스펙을 맞추기 위해 구현해야 하는 목표를 명확하게 정의하지 않고 기술을 사용하고자 하였음. 여기서 구현해야 했던 것: 1) 특정 스크롤이 왔을 때 이벤트 트리거2) css효과를 부여한다 3) 이 때, requirements → 1, 2, 3번은 같은 스크롤 y에 위치한다. 같은 스크롤 y에서도 1, 2, 3번은 Fade in의 딜레이가 있다. 스크롤을 다시 올렸을 때는 애니메이션 없이 잘 보이는 상태여야 하고 다시 내리면 애니메이션이 재생되어야 한다.
- 즉, 스크롤 포지션과 함께 index에 따라 딜레이를 부여하도록 해야한다. 그러나 IntersectionObserver사용 시 시간을 많이 투입하여야 할 것이고 구현 했을 때 기존 css/js로 구현된 aos라이브러리에 의한 구현 보다 더 나은 방식일지 의문이 든다. aos 로 구현을 마무리 하도록 한다.
- 궁금증: aos라이브러리 ⇒ scroll을 자바스크립트로 제어를 할텐데 reflow현상이 발생하지 않을까? ⇒ TODO: aos라이브러리가 비효율적이지는 않은지 퍼포먼스 측정을 진행해봅시다.
3) Desktop/Tablet/Mobile size 반응형 대응
- media query이용해서 잘 옮겨봅시다.
4) 디자인을 코드로 반영하는 방식
- 논의 배경: figma상 auto layout을 활용하면 사실상 css구현에 개발 소요가 크게 들지 않은 형태의 컴포넌트로 가져올 수 있는데, 이를 자동화 하고자 라이브러리를 작성하던 중… 이러한 서비스가 이미 존재하여 괜찮아 보이는 React코드를 산출해주는 overlay 서비스를 이용해보았는데..
- Figma ⇒ Overlay ⇒ react/styled-components
- 도움은 된다.(배치/ flex 설정) 부담은 덜어준다.
- 시간을 분명히 아껴준다.
- 디자인-개발 연동 테스팅
- 실제로는.. 디자이너가 오버레이로 export해도 문제 없는 상태(auto-layout을 적용을 잘 하면된다)까지 작업을 하고 개발자는 오버레이로 익스포트 해서 붙이면 된다. - 개발적으로 세부적인 조정은 불가피하다.
- 더더욱 자동화는 쉽지 않을 것 같다.
- 특히 고정된 width/height ⇒ 뷰포트를 채우는 100% 설정 (디자인 fixed_width/wrap_content ⇒ 명확하게 디자인 된 상태로 보이기 위해서 추가적으로 설정해줘야하고. 디자인 자체가 고정된 화면 사이즈에 대응하지만 실제로는 브라우저 사이즈 변동에 대응시키는 부분에서 디테일을 명확하게 지정하는 것이 피그마/오버레이 상에서 어쨌든 쉽지 않다.)
- 인터랙션/컴포넌트화, 반응형 설정 등 100% 자동화는 아직이다! 프론트엔드 개발자는 필요하다..
- TODO: 오늘까지 개발 단 작업 하고 오버레이로 넘겼던 컴포넌트들 디자이너 확인 요청/수정
4. 안건3 — 추후(다음주) 업무
- 오늘로 일단 웹사이트 마이그레이션 작업은 마무리 하고, 디자인 수정 완성 대기.
- 다음주에는 스프린트 일정에 맞추어 다른 admin페이지 관련 업무를 진행하자.
5. 안건4 — 추가 논의
- 재영: user review carousel을 구현하는 데, 기존 jQuery로 구현된 것을 react-slick라이브러리를 사용해서 구현해보겠습니다! star도 많아요..
- 명곤: 좋아요
맺음말
지금 우리가 어떻게 일하고 있는지, 어떤 논의를 하는지 알리고자 회의를 진행했던 내용을 소개해보았습니다. 아직 2명이지만, 팀으로 일한다는 것은 분명 혼자와는 다른 방식의 업무 프로세스를 필요로 했습니다. 2명이 된다고 당장 2배의 퍼포먼스를 내기는 쉽지 않지만 발전을 위한 추가적인 리소스를 들이는 만큼 장기적으로 그 이상의 결과를 가져올 것이라 믿고 있습니다. 회의 내용에 담기지는 않았지만, 일상적으로 코드 리뷰도 진행하고, 다루지 않은 다양한 주제들에서도 적극적으로 논의하고 진행하고 있고요!
물론, 이러한 형태가 2명이어서 가능한 진행 방식이라는 생각도 들고, 아직도 개발적으로도 모두 커버하지 못하는 부분도 있지만 팀원간의 적극적인 의사소통과 성장을 통해 발전할 수 있을 것이라 생각합니다! 각자의 방식으로 팀 내, 다른 팀과의 협업을 통해 지속적으로 발전하고 있는 나인투원 구성원 모두와 이 글을 읽어주신 개발자 분들, 스타트업 관계자 분들을 응원합니다 😊
