내가 경험한 B마트 프론트엔드의 온보딩 프로세스

Dec.21.2021 권기석
clipboard facebook twitter

Culture Web Frontend

B마트 프론트엔드 신규 입사자의 온보딩 프로세스를 끝마치며

안녕하세요! 10월 26일 우아한형제들 B마트서비스팀의 웹 프론트엔드 개발자로 합류하게 된 권기석입니다.

오늘은 B마트 프론트엔드 챕터에서 진행하고 있는 신규 입사자를 위한 온보딩 프로세스에 대해서 이제 막 온보딩을 졸업한 신규 입사자 관점으로 함께 회고하는 시간을 가져보려 합니다! 🤩

프로젝트의 기술적인 이야기를 주로 말씀드리기보다는 신입 개발자가 온보딩 프로세스를 진행하면서 바라본 B마트 프론트엔드의 문화에 대해서 말씀드리고, 그 과정 속에서 어떤 점이 좋았는지와 같은 내용을 전달드리고자 합니다.

온보딩을 시작하면서

목적 이해하기

첫 단추를 잘 끼우는 것이 중요하듯이, 온보딩을 ‘성공적인 시간’으로 보내기 위해서 무엇에 집중하고 어떤 방향성을 가지고 진행해야 할지 구체적인 목표를 세울 필요가 있었습니다.

B마트 프론트엔드의 온보딩은 파일럿 프로젝트를 진행하면서 협업 문화와 개발 문화에 적응할 수 있도록 구성되어 있습니다.

먼저 팀에서 안내해 주신 파일럿 프로젝트를 통해 달성하고자 하는 목표는 아래와 같았습니다.

  • 위키 / 지라 / 제플린을 활용한 협업 방식 파악
  • 기술선택 / 설계 / 개발 단계에서 팀원에게 받는 피드백
  • 실제 서비스에서 활용되는 API를 활용 및 이를 바탕으로 한 페이지 개발로 도메인 파악

실제로 파일럿 프로젝트의 안내도 요구사항 분석 ⇒ 설계 ⇒ 문서화 ⇒ 임무 분담 ⇒ 개발 ⇒ 배포 ⇒ 회고 과정을 모두 포함하고 있었고, B마트 프론트엔드 개발의 미니멀하지만 전체적인 사이클을 직접 경험해볼 수 있는 구조처럼 보였습니다.

온보딩 프로세스의 의도가 명확하게 드러나 있는 덕분에 배포하기까지의 개발문화는 물론 협업문화까지 전체적으로 체험해보는 것에 집중하자는 목표를 설정할 수 있었습니다.

협업을 위한 스트레칭

문화 적응하기

B마트 프론트엔드 챕터에서는 개발 외적으로도 적극적인 소통과 정보를 공유할 수 있는 다양한 문화들이 정착되어 있습니다.

1. 데일리 스크럼과 회고

업무 시작 전에 함께 모이는 데일리 스크럼 시간을 가지고 있습니다.
이 시간을 통해서 실제 업무에 참여하고 있는 것처럼 파일럿 프로젝트의 진행 상황이나 이슈를 공유하였습니다.

이 외에도 한 주를 되돌아보는 주간 회고도 함께 진행하고 있는데요.
주간 회고의 경우 한 주를 마무리하는 금요일 아래와 같이 진행되고 있습니다.

  • 배포 일정을 함께 보면서 이슈를 체크
  • 일주일간 공유한 정보 소개 및 관련한 내용에 관해서 이야기
  • 논의가 필요한 내용에 대해서 회고 시간을 활용해서 논의를 진행
  • 한 주간 진행했던 업무에 대해서, 진행하면서 겪은 이슈를 공유하며 마무리


데일리 스크럼과 주간 회고와 같이 팀원들끼리 자주 소통할 수 있는 문화가 정착되어 있는 덕분에 파일럿 프로젝트의 진행 과정과 이슈 상황들을 공유하기 쉬웠고, 온라인으로 온보딩을 진행하면서도 팀원분들에게 별 스스럼없이 궁금한 게 있으면 쉽게 물어보고 도움을 요청할 수 있었습니다.

2. 문서화

B마트 프론트엔드 챕터에서는 문서 작성을 통해서 투명하고 상세한 공유문화가 정착되어 있습니다.

지나온 발자국을 남기듯이, 프로젝트를 진행하면서 겪은 이슈에 대한 히스토리를 문서로 기록하고 있는데요.
언제든지 이후에 작업할 사람이 쉽게 히스토리를 이해하고 도움이 될 수 있도록 하고 있습니다.

프로젝트의 히스토리를 체계적으로 남기기 위해 팀에서 활용 중인 3 Phase 문서화 방식에 대해 간단하게 소개해 드리겠습니다.

First Phase ⇒ N-th Phase ⇒ Last Phase 로 3단위로 분리되어서 문서를 작성합니다.

  • First Phase
    프로젝트 / 피처의 작업 시작 전에 대략적인 스케치를 진행하는 과정입니다.
    프로젝트의 배경 및 무엇을 어떻게 진행할지에 대한 내용으로 작성이 됩니다.

  • N-th Phase
    이슈 및 문제 해결 과정 등 프로젝트의 히스토리를 작성하는 과정입니다.

    파일럿 프로젝트를 진행하면서 설계 과정의 내용을 N-th Phase 히스토리로 작성하며 문서화 방식에 적응하는 시간을 가졌습니다.
  • Last Phase
    프로젝트/피처의 작업 후 회고를 진행합니다.
    First Phase에서 작성했던 내용을 바탕으로 성과 / 비교 중점으로 작성하게 됩니다.

고도화 / 개선이 필요한 피처 또한 분기별로 문서화로 기록하고 있습니다.

다음 분기에는 어떤 고도화 작업이 필요하고 개선해야 할지 계획을 세우고, 구체적인 Todo List를 작성해 관리하고 있습니다.

실제로 처음 입사했을 당시, 팀에서 어떤 작업을 개선하고 있는지 앞으로의 목표는 무엇인지 파악하는 데 도움이 많이 됐습니다.

그 밖에도 신규 입사자의 이해를 돕는 업무 가이드와 코드 컨벤션을 비롯한 개발 가이드부터 팀 내에서 겪은 트러블 슈팅과 해결 방법 등 B마트 프론트엔드 챕터에서 필요한 모든 히스토리에 대해서 문서화가 되어있을 정도로 기술적인 내용 외에도 면밀하게 협업할 수 있도록 문서화를 장려하고 있습니다.

업데이트되지 않은 문서를 발견하면 즉시 최신 내용으로 업데이트하는 등 문서화를 다음으로 미루지 않는 것처럼 높은 우선순위로 지정할 만큼 중요한 문화로 자리 잡고 있습니다.

실제로 온보딩을 진행하면서도 문서가 잘 작성된 덕분에 많은 궁금증의 해답을 언제든지 위키 속에서 쉽게 찾을 수 있었습니다.

3. 자유주제 워크샵

지식 공유를 자연스럽게 할 수 있는 문화가 정착되어있는데요. 바로 "자유 주제 워크샵" 입니다.
발표 순서를 정해놓고 돌아가며 발표하고 싶은 주제를 가져와서 금요일마다 공유하는 시간을 가지고 있습니다!

주제가 정해져 있지 않아서 개발을 효율적으로 할 수 있는 테크닉 방법부터 다양한 아키텍처의 소개와 같이 다양한 이야기들이 자유롭게 주제로 선정되고 있습니다.

무엇보다도 정보를 말로써 잘 풀어 설명할 수 있는 역량이 중요하다고 생각하는데, 한 번씩 강사가 되어봄으로써 자연스럽게 이런 역량도 길러낼 수 있는 좋은 문화라고 느꼈습니다!

워크샵으로 진행한 내용도 공유될 수 있게 모두 기록하고 있습니다!

이 외에도 슬랙 채널을 통해 이슈를 자유롭게 공유할 수 있는 환경이 마련되어 있어서 언제든지 빠른 피드백을 주고받을 수 있었습니다!

협업 툴 활용해보기

파일럿 프로젝트도 실전처럼

다른 언어를 사용하는 외국인과 커뮤니케이션을 원활하게 하기 위해서 번역기의 도움이 때로는 필요한 것처럼,
다양한 분야의 사람들과 앞으로 있을 협업을 대비하기 위해 팀에서 사용하는 협업 툴(위키, 지라, 제플린)에 익숙해지는 것이 온보딩 첫 과제였습니다.

백문이 불여일견이란 말이 있듯이 직접 경험해 보는 것만큼 좋은 방법은 없기에, 파일럿 프로젝트의 진행도 실제로 협업을 하는 것처럼 협업툴을 사용해 보도록 안내받았습니다.



실제 업무 프로세스와 동일하게 진행할 프로젝트의 제플린 디자인 시안을 먼저 받아보고, 프로젝트의 요구사항 분석을 거쳐 기술 스택을 선정하는 것부터 어떻게 개발을 진행할 건지까지 직접 설계할 수 있는 기회가 주어졌습니다.

이 과정을 위키에 문서로 정리해 봄으로써 팀의 문서 작성 방식에 적응하는 시간으로 활용할 수 있었고, 왜 이런 선택을 했고 앞으로 어떻게 프로젝트를 진행할 계획인지와 같이 제 생각을 팀원분들에게 투명하게 전달하고 적절한 피드백을 받을 수 있었습니다.

마지막으로는 이렇게 완성된 설계 내용을 바탕으로 직접 일정을 산출해서 작업 단위를 나눠보기도 하고 지라를 이용해서 티켓(이슈)을 생성해보기까지, 업무에서 사용되는 협업 툴을 미리 활용해 볼 수 있었습니다.

실제 서비스 중인 페이지 개발로 도메인 파악

파일럿 프로젝트는 실제 서비스 하고있는 B마트 이벤트/쿠폰 모음 페이지를 구현하는 과제로 진행됐습니다.


팀에서 실제로 서비스하고 있는 페이지를 파일럿 프로젝트로 진행하면서 얻을 수 있던 장점은 많았습니다.

1. 이벤트 목록 조회, 쿠폰 조회 등 서버로부터 데이터를 받는 실제 서비스 API 요청을 활용해 보기

  • 서비스하고 있는 API 문서를 직접 탐방해 봄으로써 B마트의 API 도메인과 응답 형태를 이해
  • 프로젝트에 직접 적용해 봄으로써 프론트엔드, 백엔드 사이에서의 협업 과정을 경험

2. 팀이 서비스하고 있는 프로젝트에 대한 이해

  • "나"는 이런 식으로 개발했는데, "팀"에서는 어떻게 개발을 했을까? 궁금할 때면, 직접 코드를 찾아다니면서 팀의 코드 스타일이나 서비스가 흘러가는 흐름, 프로젝트의 구조를 자연스럽게 파악하기 용이

그 밖에도 사용자가 가진 쿠폰을 조회, 장바구니에 담긴 물품의 수를 조회하기 위해서는 API 요청에 넣어줄 테스트 사용자의 정보가 필요했었는데요.
사내 테스트 앱을 활용해서 테스트용으로 사용할 유저를 생성하고 생성한 유저의 값을 뽑아내기까지, 테스트에 필요한 실제 업무 프로세스도 미리 경험해 볼 수 있었습니다.

아낌없이 주는 코드리뷰

파일럿 프로젝트의 코드리뷰도 실제 업무와 동일하게 팀 규칙에 맞추어 리뷰를 진행하였습니다.


B마트에서는 더 효과적인 코드 리뷰 문화로 거듭날 수 있게 도와주는 코드리뷰 봇이 있는데요.

잠시 파일럿 프로젝트를 하면서 리뷰 시작부터 마무리까지 귀찮은 일을 도맡아준 B마트 리뷰 매니저를 소개해 드리겠습니다.

1. PR을 요청했을 때 저 대신에 랜덤으로 선정된 리뷰어 인원들에게 새로운 PR이 요청되었음을 알리는 메시지를 슬랙으로 호출과 함께 보내줘요.

2. PR에 새로운 코멘트와 리뷰가 달렸을 때, 그리고 Approve가 되었을 때마다 바로바로 슬랙으로 알림을 줘요.

이전까지 프로젝트를 진행하면서, 매번 팀원들에게 PR 주소와 함께 리뷰를 요청하는 메시지를 전달했었는데요.
반복적인 일을 수동으로 해야 하는 번거로움과 다른 일을 하고 있는 팀원들에게 직접적으로 부탁하다 보니 부담감으로 작용할 수 있는 여지가 있었습니다.

코드 리뷰 매니저가 리뷰어를 랜덤으로 선정해 적절히 분산시켜줌으로써 개인의 업무시간을 존중해 주고, 매번 PR을 요청할 때나 리뷰를 남길 때마다 메시지를 직접 보내야 하는 번거로움과 부담을 많이 덜어주어 상당히 편리했습니다.

리뷰 봇보다 더 코드 리뷰에 진심이신 B마트 프론트엔드 팀원분들

평소와 같이 하나의 PR에는 2명의 리뷰어가 할당됨에도 불구하고 프론트엔드 팀원 5분 모두가 하나의 PR에 피드백을 달아주실 정도로, 온보딩 파일럿 프로젝트에 아낌없이 많은 관심을 표현해 주셨습니다.
팀에서 적극적인 코드 리뷰 문화를 통해 코드의 품질을 중요시하고 있음을 많이 느낄 수 있는 순간이었습니다.

화려한 신고식의 현장

코드 리뷰의 내용은 대체로 아래와 같이 꼼꼼한 피드백을 남겨주셨습니다.

  • 일관된 코드 스타일, 아키텍처를 유지하고 있는지
  • 더 나은 코드 방법을 제시해 주시기도 하고, 기술적인 지식, 노하우 공유
  • 기존의 팀 프로젝트에서 활용되고 있는 방식을 알려주셔서 팀의 개발 히스토리를 파악할 수 있었습니다.
협업을 위한 코드에 대해서도 피드백을 자주 받았는데요. 그중 저와 같은 신입 개발자분들과 함께 보면 좋겠다는 생각이 들었던 피드백을 공유해 드리고자 합니다!

1. 확장하기 좋은 코드

피드백 받기 전
//theme.ts
const colors = {
  gray1: '#222222',
  gray2: '#444444',
  gray3: '#888888',
  gray4: '#e6e6e6',
  gray5: '#f6f6f6',
};

프로젝트에서 사용될 색상들을 한곳에 모아 저장하고 있는 간단한 코드입니다.

gray1과 gray2 사이에 추후 #333333 이 들어와야 하는 상황이 발생한다면 어떻게 할지에 대한 말씀과 함께, 이 값을 새롭게 gray6 와 같이 의미가 명확하지 않은 변숫값으로 확장하는 것에도 문제가 있다는 피드백을 받았습니다. 이러한 설계는 추후 변경에 취약하고 협업할 때 어려움을 야기할 수 있다는 문제점을 지적해 주시고 아래 코드와 같이 확장 가능한 코드의 예시를 제시해 주셨습니다.

이전까지는 정해놓은 색상 외에 새로운 색상이 추가되는 것 같이 "언제든 변경 사항이 생길 수 있다는 걸 고려하지 못해왔구나"라는 생각과 함께 머리를 세게 맞은 느낌이었습니다.

피드백을 통해서 앞으로 협업하기 좋은 코드를 작성하기 위해서는 어떤 변경 사항에 대해서도 유연하게 처리 가능한 확장하기 좋은 코드를 작성하는 것에 유의해야 할 필요성을 격하게 공감할 수 있었습니다.

피드백 받은 후
const colors = {
  gray_100: '#222222',
// 추후 사이 값이 추가가 된다면, gray_150으로 사용할 수 있고, 그 외에도 99가지의 사잇값이 들어갈 수 있다.
  gray_200: '#444444',
  gray_300: '#888888',
  gray_400: '#e6e6e6',
  gray_500: '#f6f6f6',
};

2. E2E 테스트의 의미

피드백 받기 전
describe('이벤트 모음 쿠폰 페이지 E2E 테스트', () => {

  it('초기 로드 시 장바구니 담은 수 조회 API 호출하면 숫자 3이 장바구니 아이콘에 표시가 된다.');

  it('쿠폰 탭 클릭 시 쿠폰 데이터 3개가 그려진다.');

  it('이벤트 탭 클릭 시 이벤트 배너 데이터 3개가 그려진다.');

  it('쿠폰 탭 클릭 시 응답 쿠폰이 0개일 때 텅 이미지가 보여진다. ');

  it('이벤트 탭 클릭 시 응답 이벤트 배너가 0개일 때 텅 이미지가 보여진다. ');

  it('쿠폰에서 더보기 아이콘을 클릭 시, 카드 뒷면이 펼쳐지고 카드 뒷면의 주의 메시지가 화면에 그려진다.');

  it('이벤트 목록 조회 실패 시 에러 메시지가 콘솔에 출력된다. ');

  it('쿠폰 목록 조회 실패 시 에러 메시지가 콘솔에 출력된다.');
});

위의 코드는 E2E 테스트 코드 작성을 처음 작성할 당시, 테스트하고자 하는 상황들입니다.
E2E 테스트 코드의 의미를 정확하게 녹여내지 못하고, 페이지 안에서의 거시적인 기능이 올바르게 동작하는지에 대해서만 작성한 모습입니다.

이에 대해서 아래와 같은 피드백을 받았습니다.

e2e는 코드만으로 실제 앱에서 코드가 어떻게 동작할지를 그려볼 수 있어야 하고, 사용자가 앱을 이용할 수 있는 구체적인 flow를 이해하는 것에 유의
'사용자는 쿠폰 탭에서 스크롤을 내려 10번째 쿠폰을 선택한다.' 와 같이 사용 케이스에 대해서 여러 describe 단위로 쪼개어 작성해 볼 것.

API 응답에 대한 테스트가 들어가 있는 부분에서 UI 단의 end to end 테스트에 집중하고, API 응답에 대한 테스트를 e2e테스트에서 하기보다는 API 코드 단으로 분리하기.

unit, integration, e2e 등 각 테스트 코드를 작성할 때는 해당 테스트가 가지는 의미를 명확하게 부각할 수 있게 작성하는 것이 중요함을 경험할 수 있었습니다.

피드백 받은 후
describe('사용자는 헤더의 장바구니 아이콘에서 장바구니에 담은 물품 개수를 확인한다.', () => {

  it('사용자는 장바구니에 아무 물건도 담지 않았을 때 장바구니 아이콘만 화면에서 본다.');

  it('사용자는 장바구니에 3개의 물건이 담겨있을 때 장바구니 아이콘에 숫자 3이 그려진 것을 본다');
});

describe('사용자는 이벤트 탭, 쿠폰 탭을 번갈아 클릭하여 이벤트, 쿠폰 목록을 본다.', () => {
  it('쿠폰 탭 클릭 후 목록에서 3번째 쿠폰 카드의 이름을 본다.');

  it('이벤트 탭 클릭 후 스크롤을 가장 아래로 내려 마지막 이벤트 배너 이미지를 본다.');

  it('쿠폰 탭 클릭 시 가진 쿠폰이 없을 때 사용자 화면에 텅 이미지가 보인다. ');

  it('이벤트 탭 클릭 시 진행 중인 이벤트가 없을 때 사용자 화면에 텅 이미지가 보인다. ');
});

describe('사용자는 쿠폰 탭을 클릭하고 스크롤을 내려 6번째 쿠폰의 더 보기 아이콘을 클릭한다.', () => {
  it('6번째 쿠폰의 더 보기 아이콘을 클릭하여 쿠폰 뒷면의 주의 메시지를 본다.');

  it('6번째 쿠폰의 앞면으로 돌리는 아이콘을 클릭하여 쿠폰의 앞면을 본다.');
});

이전 코드와 비교해 보면 사용자 관점에서 앱이 사용하는 흐름에 맞추어 테스트 케이스가 추가된 것으로 보입니다.

온보딩을 끝마치며

입사 후 6주간의 시간이 흘러 온보딩 프로세스가 마무리되었습니다.
처음 입사할 당시, 내가 뭘 모르는지조차 모르기 때문에 "무엇을 ‘질문’ 해야 하는 걸까?"와 같은 막막함이 있었던 것 같습니다.

이런 걱정을 완전히 덜어준 것이 바로 팀에서 마련해 준 온보딩 프로세스였습니다.
제가 경험한 온보딩을 한 문장으로 표현하자면 "질문을 던질 수 있게끔 질문 리스트를 한가득 모아놓은 보따리" 입니다.
보따리에서 새로운 과제를 하나씩 꺼낼 때마다 모르는 것이 생겨났고, 그럴 때마다 자연스럽게 팀원분들에게 질문을 하며 차근차근 팀 문화에 적응할 수 있었습니다.

무엇보다도 온보딩 프로세스를 진행하면서 매번 어려움은 없는지 물어봐 주시고 어려움이 있다면 함께 문제해결을 해주시는 건 물론, 항상 아낌없는 피드백을 제공해 주신 팀원분들의 열렬한 서포트가 있었기에 6주간의 시간을 재밌고 알차게 보낼 수 있었습니다
(감사합니다!! 😊)

신규 입사자가 경험한 B마트 프론트엔드 온보딩의 후기가 여러분에게 도움이 되었길 바라며 글을 마치겠습니다.

마지막으로 긴 글 읽어주신 여러분들에게 감사하다는 말씀드립니다. 🙇‍♂️