신입이가 원티드 프론트엔드 팀에 온보딩 하면서 알게 된 것들

원티드 프론트엔드 팀에서는 어떻게 일하고 있을까

목차

1. 소개
2. 용어
3. 진행업무
4. 업무 플로우
   - 팀에서 일하는 방법
   - 다른 팀과 협업하는 방법

글에 포함하려고 한 것들

• 내가 온보딩 하면서 새롭게 알게 된 것들
• 좋았던 점들(나의 생각!)
• 온보딩 때 알면 좋을 것들

안녕하세요

원티드랩 프론트엔드 팀에 합류한지 두 달이 되어가는 🐤 주니어 개발자입니다.

원티드의 온보딩 세션에도 참여하고, 프론트엔드 팀에서의 다양한 가이드와 자료들을 바탕으로 팀에 적응해 나가고 있습니다. 짧은 기간동안 제가 느낀 원티드의 프론트엔드 팀이 어떻게 일하고 있는지 또 저는 그 안에서 어떤 방식으로 팀원이 되려고 노력하고 있는지를 공유하려고 합니다.

용어

원티드에서 그리고 프론트엔드 팀에서 사용하고 있는 용어들 있습니다. 원티드 프론트엔드 팀에 합류 하면서 알게 된 용어인데, 이어지는 글에서도 계속 사용 되기 때문에 간단하게 설명을 달아 보았습니다.

• 스쿼드 : 특정 목표를 위해 운영되는 TF 팀 같은 조직입니다. 개발자부터 PO 마케팅 까지 한 팀을 이루는 팀이고, 프론트엔드 팀원 분들도 스쿼드에 소속되어 있습니다.
• 팀 프로젝트 : 전체적인 운영 이슈, 팀 내부 생산성을 높이는 툴 개발, 기존 서비스에 대한 개선작업 등을 진행하는 프론트엔드 팀 입니다.
  저는 팀 프로젝트를 진행하고 있습니다.
• 짝꿍 : 신규 입사자에게는 짝꿍이 정해지게 됩니다. 짝꿍은 온보딩을 도와주시고 제 궁금증과 입사 후 첫 업무 가이드도 도와주십니다.
  (thanks to 짝꿍님😉)

진행 업무

저는 두 달 동안 다음과 같은 업무들을 주로 진행했습니다.

• 운영 이슈 처리
• 기술 공유
• amplitude 작업 (보류)
• b2b 작업

주로 운영 업무를 진행하고 도메인에 대해 파악하는 시간이었습니다.

업무 플로우

이제 제가 두달동안 위의 업무들을 수행하면서 알게 된 원티드랩이 일하는 방법과 프론트엔드 팀이 일하는 방법에 대해서 소개하겠습니다.

크게 두 방향으로 소개하려고 합니다 1) 팀에서의 협업과 2) 다른 팀과의 협업 입니다. 팀 내에서 개발을 진행 할 때 또 다양한 어떤 활동들을 하고 있는지에 대해서 소개하고 다른 팀과 어떨 때 커뮤니케이션 했는지 말씀드리려고 합니다.

프론트엔드 팀에서 일하는 방법

프론트엔드 팀에서는 다양한 툴과 규칙을 바탕으로 협업하고 있습니다. 팀원 분들이 만들어주신 Welcome kit 과 confluence의 공유 문서들 그리고 짝꿍님의 도움으로 새로운 툴과 업무 방식을 알아가고 있습니다.

▪️ 프로젝트 관리

프론트엔드 팀에서는 git-flow를 사용해서 프로젝트를 관리하고 있습니다.

기존 git-flow 규칙과 함께 몇가지 규칙들을 더해서 통일성 있는 프로젝트 관리를 하고 있습니다. JIRA와 연동되기 위한 commit 과 PR 규칙을 정하고, 이런 부분의 편의를 개선하기 위해서 commit template과 템퍼몽키를 사용하고 있습니다.

commit log

• JIRA 와의 연동을 위해서 정해진 룰을 사용하고 있고 상세 commit에 JIRA issue 링크를 포함하고 있습니다.
• 기존의 gitflow와 다르게 관리하고 있는 부분도 있습니다. feature branch가 develop branch로 merge 되어도 따로 삭제 되지 않고 히스토리 확인을 위해서 feature branch를 유지하고 있습니다.
• develop branch 로 merge 되면 테스트 서버로 파이프라인을 타고 배포됩니다.

저도 컨플루언스에 가이드 된 규칙들을 지키면서 commit 과 PR을 작성 할 때 작업한 이유와 확인한 범위에 대한 설명을 포함하여 맥락을 파악하기 쉽게 작성하려고 노력하고 있습니다.

▪️ Code Review

모든 PR은 Code Review의 과정을 거쳐야 합니다. PR에 리뷰어를 세명 이상 추가하고, 1개 이상이 approve 가 있을 때 merge 가능합니다.

저는 작업한 부분과 연관된 작업을 하신 분과 짝꿍님을 리뷰어로 추가하고 있습니다.

Code Review는 스타일 가이드와 히스토리에 대한 Code Review를 바탕으로 이루어지고 있습니다. 또한 더 나은 방법들을 제시하기도 합니다.

짧은 기간 이었지만 처리한 이슈에 대해 놓칠 수 있었던 히스토리에 대한 부분 또는 연결되어 있는 다른 작업에 대한 부분을 체크 해 주셔서 더 안정적인 코드로 배포가 나갈 수 있게 되었습니다.

history code review : 확인하지 못했던 히스토리 부분을 리뷰 주셔서 변경 할 수 있었습니다.

다른 pr 에 달린 review

더 나은 방법에 대한 제안을 Code Review로 남겨 주시기도 하는데, 제가 받은 Code Review가 아니더라도 같이 공유되기 때문에 팀 차원의 성장에 도움이 되고 히스토리를 파악할 때도 도움이 되고 있습니다!

▪️ 스프린트와 배포 일정

프론트엔드 팀에서는 2주 단위 스프린트로 업무가 진행되고 있었습니다. 정기 배포는 격주 목요일마다 진행됩니다.

하지만 달력을 보면 배포가 매주 있는 것을 볼 수 있습니다. 처음에 가장 헷갈렸던 부분인데요, 프론트엔드 팀에서 진행하는 배포의 종류는 두가지가 있습니다.

운영 이슈의 경우 주로 정기 배포 일정에 포함되어서 배포가 진행됩니다. 하지만 배포 일정은 꼭 한번 더! 배포 달력을 확인하는 게 좋습니다. (revert 의 경험으로 알게 되었습니다.!😢)

• 정기 배포 : 정기 배포는 격주 목요일에 배포가 진행됩니다.
• 스쿼드 배포 : 상시 배포의 경우 정기 배포 사이의 주에 진행됩니다.

배포달력

제가 경험한 정기 배포를 기준으로 말씀드리면

• 첫번째 주에는 개발을 진행합니다. 발생한 버그, 기능 개선, 신규 개발 등의 작업을 진행하게 됩니다.
• 두번째 주에는 개발 서버에 배포해서 QA 테스트를 진행하게 됩니다.

(개발 배포의 시점이 어려웠는데 최근 배포 달력이 완성되면서! 팀 별, 스쿼드 별 배포 일정과 범위를 쉽게 확인 할 수 있게 되었습니다. 🎉 🎉 🎉)

▪️ 기술 공유

팀 내에서는 작업하고 있는 상황, 유의미한 작업들에 대해서 또 새로운 기술에 대한 공유 활동들을 진행하고 있습니다.

저도 팀 주간 회의 때 운영 이슈를 처리 하면서 경험한 CORS에 대한 내용을 정리하고 공유했습니다.

넵 제가 썼습니다 Z는 여러분의 몫 ;)

꼭 블로그에 올라가는 글이 아니더라도 confluence에 패키지 개발 현황과 한 주의 기술적인 이슈, 개발 이슈에 대해서 공유하기 때문에 히스토리와 진행 상황들을 파악할 수 있었습니다.

이외에도 #suggestion-channel 등을 통해서 새로운 기술 트렌드나 아이디어들 대해서도 자유롭게 이야기하고 있습니다. 이런 채널을 통한 커뮤니케이션을 통해서 새로운 팀 내의 자동화 도구들이 만들어 지고 있습니다.

▪️ 자동화

또 프론트엔드 팀에서는 다양한 방법으로 자동화를 진행하고 있습니다. 이런 부분은 팀 내에서 실수를 줄여주고 더 나은 제품을 만드는 데 도움이 되고 있다고 생각합니다.

PR과 지라 티켓에 대한 slack 연결, 번역 키나 캐시 관리를 위한 프론트엔드 툴, 릴리즈 노트 생성기 등 다양한 방법들을 사용해서 생산성을 높이고 있습니다.

프론트엔드 툴은 프론트엔드 팀에서 사용하는 관리 도구입니다. 번역 키, 캐시, 배포 달력, 데일리 스크럼 등을 통해서 생산성을 높이고 있습니다.

▪️ 팀 스크럼과 주간회의

git과 기술공유, 팀 내부 운영 툴 등을 통해서 다양하게 소통하고 있지만, 팀 구성원들이 어떤 일을 하고 있는지를 지속적으로 알고 있는 것 또한 중요한 부분이라고 생각합니다. 원티드에서는 하루를 마무리 하면서 데일리 리포트를 작성하고, 프론트엔드 팀에서는 매일 아침마다 데일리 리포트를 바탕으로 빠르게 스크럼을 진행합니다.

데일리 리포트는

• 오늘 한 일
• 내일 한 일
• 공유가 필요한 일

이렇게 세 가지로 구성되어 있는데요.

매일 퇴근 30분 전에 이렇게 독촉을 해줍니다 😌

아침에 15분 내외로 빠르게 공유 하면서 서로 어떤 부분을 작업하고 있는지 또 어떤 문제를 겪고 있는지를 빠르게 이야기 하고 있습니다. 팀에 새롭게 합류한 사람으로서 어떤 작업들에 어떤 이슈가 있는지를 들으면서 더 알아보면 좋을 것들을 알 수도 있었고, 궁금했던 것들을 해결할 수도 있었습니다. 새로 합류한 사람은 내가 무엇을모르는지 모르는 점이 답답할 수 있는데 이런 부분을 보완해 줄 수 있는 역할을 한다고 느꼈습니다.

또한 다른 역할로는 도움을 구해야 할 팀원을 빠르게 알게 되고 또 문제를 빠르게 해결하는데 도움이 된다는 점 입니다. 찾아서 하는 것도 좋지만 때로는 아는 사람에게 물어서 해결 하는게 가장 빠른 해결 방법이 되기도 합니다. 이럴 때 서로 알고 있는 점들에 대해서 먼저 확인해보면 좋을 부분에 대한 이야기를 하면서 빠른 문제 해결을 도와주는 역할도 하고 있습니다.

또한 코로나로 재택근무를 진행하면서 각자 떨어진 곳에서 업무를 진행하게 되는데, 서로 이런 현황 공유를 통해서 커뮤니케이션을 하는데도 도움이 된다고 생각됩니다.

2. 다른 팀과 함께 일 하는 방법

프론트엔드 팀 내에서 다양한 방법으로 코드를 관리하고 운영하면서 다른 팀들과 협업해야 하는 부분들이 있었습니다. 원티드에서는 confluence와 JIRA를 사용해서 전사적인 문서 공유와 티켓 처리를 진행하고 있습니다.

제가 경험한 QA팀과 Server팀과의 협업에 대해 공유하려고 합니다.

▪️ QA 팀

프론트엔드 팀과 가장 많이 커뮤니케이션 하게 되는 팀이라고 생각합니다. 테스트와 가장 가까운 위치에서 개발을 하기도 하고 또 작업 프로세스에서도 가깝기 때문입니다. 운영 이슈를 처리하면서 QA팀과 어떤 커뮤니케이션 하게 되는지를 알게 되었습니다.

운영 이슈를 처리하는 과정은 다음과 같습니다

① 운영 이슈 발생 → ② JIRA에 티겟 등록 → ③ 티켓 할당 → ④ 해당 티켓 처리 후 PR → ⑤ 개발 서버에 배포 → ⑥ QA → ⑦ 스테이징 배포 → ⑧ 프로덕션 배포

③ 티켓이 할당 되면서 부터 QA팀과의 협업이 시작됩니다.

티켓을 할당 받을 때 QA 팀과의 협업이 필요할 수 있는 두가지 입니다.

• 배포 날짜
• QA type

우선 배포 날짜입니다.

정기 배포 일주일 전까지 개발을 완료 할 수 있는 배포 날짜 === fixdate

해당 티켓이 언제 배포 될 것 인지를 정해야 합니다. 실제 프로덕션 배포 1주일 전에는 QA가 진행되기 때문에 그 전까지 작업을 완료할 수 있는지 확인해서 fixdate 정하게 됩니다.
만약 더 빠르게 배포가 되어야 하거나 기간이 오래 걸릴 것 같을 때에는 JIRA를 통해서 QA 팀과 커뮤니케이션을 통해 일정을 조정하게 됩니다.

두번째는 QA 종류 입니다.

• qa : QA 팀에서 확인
• dev-qa : 개발자가 배포 후 직접 확인

대부분 이슈는 report해주신 QA 담당자 분이 진행해 주십니다. 하지만 간단한 텍스트 변경과 같은 경우는 개발자가 배포 후 직접 확인하는 dev-qa 를 진행하기도 합니다. 이런 경우 JIRA에서 이야기해서 간단한 변경 사항이기 때문에 dev-qa를 진행한다고 말씀드리고 배포가 진행 될 때 잘 챙겨서 확인을 진행하고 있습니다.

▪️ Server 팀

api 변경 건으로 서버 팀과 협업해야 하는 경우도 있었습니다. 이럴 때에는 서브 테스크로 작업을 요청드리고 작업 상황이 반영되게 되면 in review 개발용 서버에 api 를 반영시켜 주실 수 있는지 요청드리게 됩니다.

① 작업 요청 또는 작업 상황 확인
② in review 가 되면
③ 개발 서버에 api 반영 요청
④ 서버 팀에서 반영 해 주신 개발 server로 api 확인

▪️ JIRA 티켓과 배포과정

원티드에서는 JIRA를 사용해서 이슈 관리를 하고 있는데요. 그렇기 때문에 작업이 완료된 티켓에 대해서는 JIRA 티켓의 상태가 변경되고 있습니다. 이 티켓의 상태를 잘 변경하고 설명을 적절하게 추가하는 부분이 협업에서 중요합니다.

운영 이슈가 처리되는 단계에 따라서 JIRA 티켓 상태가 변경되는 과정입니다.

① 운영 이슈 발생 → ② JIRA에 티켓 등록 열림 → ③ 티켓 할당 진행중→ ④ 해당 티켓 처리 후 PR 리뷰 중 → ⑤ 개발 서버에 배포 작업 완료 → ⑥ 개발 서버 QA 닫힘→ ⑦ 스테이징 배포 → ⑧ 프로덕션 배포

• 이슈를 처리하고 PR을 올리게 되면 리뷰 중 상태가 되고
• 작업이 완료된 후 배포가 된 다음에는 작업 완료 로 변경해 주어야 합니다.
• QA가 종료되면 해당 이슈를 리포트 해주신 분이 확인 후 닫힘 으로 상태가 변경됩니다.

그래야 QA 팀에서 Release에 포함된 이슈들이 다 처리 되었는지를 확인 할 수 있기 때문입니다.

🎉 두 달!

프론트엔드 팀의 🐥뉴비🐥로 업무경험 공유를 작성하는 것은알게 된 것들을 또 정리된 언어로 이야기 할 수 있는 경험이었습니다. 이 경험을 통해서 작성하면서 알고 있는 내용도 다시 정리 할 수 있었고, 또 새롭게 궁금한 것들도 생겼습니다. 새롭게 생긴 궁금증들은 또 다시 알아가면서 점점 프론트엔드 팀 구성원이 되어가고 있습니다.

글에서는 주로 업무 방식과 도구에 대해 이야기를 했지만, 이외에도 팀에서 새로운 구성원을 환영해 주기 위한 많은 준비를 해 주십니다. Welcome Kit 이나 온보딩 교육 일정을 만들어 주시는 점도 그렇지만, 물어 볼 수 있는 분위기를 많이 만들어 주시고 있다고 느꼈습니다.

또 실제 면접 때 소개해 주셨던 것들과 일치한다는 점 이었습니다. 기술 공유에 대한 세션, 문서화에 대한 노력, 스프린트 단위의 업무 등을 면접에서 알게 되었는데, 실제로 이런 부분들이 적용되고 있고 또 만들어가고 있는 점이 인상적이었습니다.

약 두 달 동안의 경험 공유인 만큼 아직 잘 모르는 부분도 또 새롭게 느껴지는 부분들도 있습니다. 하지만 팀원 분들의 도움으로 팀에 잘 적응해 나가고 있습니다. 이제는 이런 팀 문화와 프로젝트를 같이 만들어가는 팀원이 되겠습니다. 🙂 그동안 저의 온보딩과 질문을 많이 도와주신 팀 분들 감사합니다!
(앞으로도 잘 부탁드립니다 😉)