위코드 부트캠프를 다닌지 어느덧 두 달이 흘러, 삼 개월 차 과정인 기업 협업을 진행했다.
기업 협업은 한 달 과정으로 인턴십 프로그램처럼 기업에 나가 팀 프로젝트를 하는 기간이다.

한 달간 협업을 하며 배우게 될 기업은 희망 1순위 중 첫 번째로 작성한 '위티'로, 자사 서비스로 '집현전'이라는 Prop-tech 서비스를 운영하며 현재 스포츠 이커머스 포털 앱을 만드는 프로젝트를 진행하고 있다.

스포츠 이커머스 포털 앱은 특정 스포츠 분야와 관련된 뉴스, 영상, 쇼핑 등을 제공하는 애플리케이션이다. 나는 사용자가 직접 앱에 영상을 올려서 확인하는 페이지에 더불어 나중에 쇼핑 메인 페이지를 추가적으로 맡아 한 달 간 프로젝트에 참여하게 되었다.

---

스포츠 이커머스 포털 앱 프로젝트

프로젝트 기간

4주, 주 4일 (2020.11.16 ~ 2020.12.10)

4주 동안 프로젝트를 진행했다. 일주일에 하루는 위코드로 출근해 세션을 듣고 기술을 공유하고 재정비하는 날인 위코드데이가 있었기에, 기업으로 주 4일 씩 출근했다.

프로젝트 소개

스포츠 이커머스 계의 대표 포털 앱을 만드는 것이 목표인 프로젝트.
스포츠 이커머스와 관련된 뉴스, 영상, 쇼핑, 인테리어(매장 견적요청), 커뮤니티(포털 카페) 등의 정보를 제공하는 서비스이다.
안드로이드와 ios 모든 기기에서 사용가능한 앱을 만든다.

2020년 12월 내 애플리케이션 배포가 예정된 프로젝트이다.

실제 사업 중인 프로덕트 아이템이기 때문에 저작권 보호를 받고 있어, 해당 포스트에 프로젝트 이름, 실제 코드, 프로젝트 결과물 등을 소개하기 어려운 아쉬움이 있다.

기술 스택

• React
• React Native
• TypeScript
• React Hooks
• React
• Styled-component
• Redux
• Redux-saga
• Axios
• Yarn

React Hooks 일부(useRef 등), React Native, TypeScript, Axios를 이 프로젝트에서 처음 접했다.

모두 꼭 써보고 싶었던 기술이었기에 설레는 마음으로 사용하려고 했으나, 진입 장벽이 꽤 높았다.
그래도 일단 시작했다. React Native는 초기세팅을 하는 단계부터 난관이 마구 닥쳐왔지만, 모르는 것이 있을 때마다 구글과 스택오버플로우에 찾아보며 문제를 해결했다.

React Native가 익숙해질 때 쯤 Axios와 TypeScript, Hooks를 더 찾아보고 공부했다.

이 프로젝트에서는 API를 호출하는 대부분의 기능을 custom hooks로 만들어두었기에, 내가 직접 axios를 작성한 코드는 없다. 그러나 custom hooks를 사용하기 위해서는 그 hooks가 어떤 순서와 원리로 작동되는지 알아야 하기 때문에 그것을 알기 위해 axios를 공부했다.

아쉬운 것은 내가 맡은 페이지의 경우, 비즈니스 로직 혹은 컴포넌트 내에서 상태 관리를 하는 것이 효율적이었기 때문에 Redux와 Redux-saga를 사용하거나 관련된 custom hooks를 사용할 직접적인 기회가 없었다는 점이다.

협업 도구

• GitLab
• Slack
• teamgantt
• Swagger
• Google Docs-Presentation
• Adobe XD
• Naver Cloud

(Slack을 제외하고 모두 이 프로젝트에서 새롭게 사용한 협업 도구이다.)

GitLab을 통해 업데이트한 코드를 push & pull 하고, 팀 멤버들과 서로 코드리뷰를 주고 받았다.

Slack을 통해 서로 질문과 답을 하고, 프로젝트 진행 중 업데이트나 수정된 내용을 간략하게 공유했다.

teamgantt를 통해 내가 현재 해야할 업무를 명확히 함과 동시에 진행속도를 체크하고, 서로의 업무 진행 내용을 공유했다.

Swagger를 통해 모든 API와 HTTP 메소드 형식을 확인하고, 호출 시 필요한 정보 및 데이터 구조를 파악했다. 따라서 백엔드 개발자 분과 효율적이고 긴밀하게 협업할 수 있었다.

(Swagger와 같은 서비스가 있다는 것을 처음 알았다. 1,2차 프로젝트 때에는 API endpoint나 데이터 구조 등을 백엔드 분들께 별도로 여쭤보고, POST 등의 메소드로 데이터베이스에 저장된 데이터를 확인하고 싶을 때도 백엔드 분들께 따로 부탁드렸어야 해서 조금 비효율적으로 프로젝트를 진행한 감이 있었다. 그런데 Swagger를 사용하니 그렇게 하지 않고도 정확하게 정보를 얻을 수 있어서 정말 편리했다.)

GoogleDocs-Presentation을 통해 기획안을 공유받고, 확인이 필요한 부분은 기획자 및 디자이너 분과 직접 소통했다.

Adobe XD를 통해 화면 디자인의 세부 정보를 공유받고, 이를 기반으로 코드작성을 진행했다.

Naver Cloud를 통해 프로젝트에 사용되는 이미지 파일을 공유했다.

'어떤 종류의 협업 툴을 어떻게 사용하느냐'가 팀 멤버 간의 효율적인 소통과 프로젝트 진행 속도에 영향을 많이 주는 것 같다.

---

업무 방식

스크럼 회의

매일 아침 스크럼 회의를 진행했다. 서로 '어제 한 일'과 '오늘 할 일'을 공유했다.

나는 아래 캡쳐사진처럼 노트북 메모장에 머릿말을 적어둔 채, 모두에게 공유가 필요한 일이나 회의 때 수정된 사항은 특이사항에 적어 공유하고, 확인이 필요한 일은 질문드릴 것에 미리 작성해 여쭤봤다. 스크럼 회의 결과 빠른 진행이 필요한 일은 스크럼 후 바로 할 일에 적어 우선적으로 처리했다.

업무상 소통

스크럼 회의 이후 질문이 있을 경우, 협업 도구를 이용해 적재적소에 맞는 방식으로 소통했다.

개발팀 분들과 코드 관련 질문이 있을 경우 슬랙을 이용했고, 기획자 및 디자이너 분들과 기획안 및 디자인 관련 질문이 있을 경우 구글 독스 프레젠테이션을 이용했다.

이렇게 하니 팀원 모두 질문과 답을 확인할 수 있고 시간이 흐른 뒤 내용을 재확인할 수 있어 공유와 기록 면에서 참 편리했다.

업무 진행

첫 시작

• 첫 이틀간 GitLab과 React Native를 세팅하는 방법, 프로젝트 디렉토리 구조, Merge Request와 commit message 관련 컨벤션, TypeScript, Redux 등 업무를 진행하는 데 필요한 정보를 사수 분들께서 압축적으로 알려주셨다.

• 위코드 팀원들의 할당 업무는 미리 팀간트에 업데이트 되어 있어 각자의 업무 내용을 확인했다. 내가 맡은 부분은 모달 버튼, 영상 업로드 페이지, 영상 수정 페이지, 내 영상 관리 페이지로 크게 네 부분이었다.

• 첫 이틀간 세팅을 완료한 후 사흘 째부터 본격적으로 작업을 시작하려고 했으나 마음처럼 쉽지가 않았다. 함께 한 7 명의 위코드 팀원 중 맥북이 아닌 윈도우를 사용하고 계신 두 분은 끝내 윈도우에서 나타나는 에러를 해결할 수 없어 사흘 째 아침, 바로 맥북을 구매하기까지 했다.

• 이렇게 사흘 째 저녁, 프로젝트 세팅을 마쳤다.

첫 주

• 기존에 이미 프로젝트가 진행되고 있어서 약속된 컨벤션이나 코드 내용, 디렉토리 구조가 상세히 나눠진 상태였다. 실제 기업 프로젝트 차원의 디렉토리 구조는 처음 마주했고, 내가 코드를 잘 짜기 위해서는 이를 잘 파악하고 있어야 했기 때문에 첫 주에는 디렉토리 구조를 이해하는 것에 노력을 많이 기울였다.

• 또한, 새로 접한 React Native을 어떻게 사용하는지 익히고 팀간트 업무 내용을 확인하며 조금씩 코드를 작성해나갔다.

2주 차

• 본격적으로 코드를 작성했다. 어떤 custom hooks가 있으며 그것을 어떻게 사용하는지 사수분께 배우고, 완벽히 이해하진 못했더라도 필요한 custom hooks를 이용해 API를 연결했다.

• 기획서 상 명확하게 지정되지 않은 부분이 있으면 내 나름대로 방안을 구상해 사수분들께 확인하고 진행했다.

• 위코드 팀원들과 서로 코드리뷰를 주고 받으며 다른 팀원들의 코드를 보고 배우고, 내 코드를 더 짜임새있게 만들어야겠다는 반성을 했다.

• 이 때까지는 컴포넌트에서 비즈니스 로직을 분리하거나, 재활용이 가능한 컴포넌트로 만드는 일을 하지 못했다.

3주 차

• 해결이 잘 되지 않는 UI 부분이 있어, 계속해서 그 부분을 수정했다.

  (버튼 클릭 시 모달이 나타나더라도 버튼의 색이 유지되어야 하는데, 모달의 기능 상 모달 바깥의 요소는 모두 모달 백그라운드컬러의 영향을 받는다. 이를 해결하고자 모달 밖과 안의 같은 위치에 같은 크기의 아이콘을 배치했으나, 모달 밖의 bottom 기준과 모달 안의 bottom 기준이 달라 유저의 화면 크기에 따라 아이콘 위치가 달라질 수 있는 위험이 있었다.)

• 유튜브 링크의 유효성을 검사하는 유틸 함수를 만들었다. 다른 페이지에서도 사용해야하는 함수로 담당 개발자 분과 공유했다.

• 2주 차 때 하지 못했던 비즈니스 로직 분리를 이뤄냈다. 이후 UI 컴포넌트 중에서 큰 묶음인 코드를 따로 떼어 컴포넌트를 분리했고, 그 중 다른 분들도 사용할 가능성이 있는 컴포넌트는 재활용 가능한 컴포넌트로 분리했다.

• 3주 차가 끝나갈 쯤, 내가 맡은 4 개의 업무에서 레이아웃과 기능을 모두 구현했으나 테스트를 해보니 이런 저런 에러가 튀어나왔다. 계속해서 테스트와 에러 해결을 반복하다보니 더 효율적인 방법을 찾게 되었고, 테스트 코드와 TDD 프로세스에 관심이 생겼다.

• 에러 뿐만 아니라, 기획안 상에는 없지만 유저 입장에서 조금 아쉬운 부분들이 눈에 들어왔다. 예를 들어, 제목이 입력되지 않았을 경우, 링크가 입력되지 않았을 경우, 제목과 링크가 모두 입력되지 않았을 경우에 따라 각기 다른 Alert를 추가했다.

• 기업의 예상 날짜보다 내 업무가 일찍 진행되어, 새로운 태스크를 추가적으로 부여받았다.

4주 차

• 새로 받은 태스크를 진행했다. 홈탭에 나타나는 쇼핑 메인 페이지였으며, 네비게이션 탭과 추천상품 및 6개 카테고리의 제품을 소개하는 페이지였다. 반복되는 6개 카테고리는 처음부터 재활용 가능한 컴포넌트를 만들어 구성했다.

• 이미지 그라데이션 기능을 제외하고는 UI 구현을 완료했다. 네비게이션 탭을 클릭하면 useRef 기능을 이용해 특정 카테고리로 스크롤링되는 기능을 시도했는데, 결국 구현하지 못한 채 프로젝트가 끝났다.

• 새로 진행한 쇼핑 메인 페이지에서 어떤 부분까지 하고, 어떤 부분을 못 했는지, 못한 이유는 어떤 것이고, 어디까지 검색해봤는지 정리해서 사수 분께 공유해드렸다.

• 3주 차 때 해결이 잘 되지 않았던 UI 부분은 모달 밖의 bottom tab 높이를 구해 모달 안의 버튼에 더하는 방법으로 해결했으나, 테스트 중 각 기기에 따라 이미지 일부와 bottom tab이 겹치는 현상이 새롭게 나타났다. 4주 차로 얼마 시간이 남지 않았기 때문에, 개발팀이 모두 확인할 수 있도록 GitLab의 Issue에 상세히 기록해두고 해당 부분은 마무리 지었다. 해결하지 못해 찜찜하고 아쉬웠다.

• 모든 분들의 브랜치를 머지하여 통합리뷰를 진행했다. 이 때 나타난 수정사항은 당일 바로 해결했다. 각자 맡아 구현한 화면을 모두 연결해서 보니 신기한 마음이 들었다.

---

구현 사항

카테고리 메인 모달 버튼

• 클릭 시 모달창 오픈
  Modal 컴포넌트와 boolean 값을 가진 state를 이용하여 구현했다.

  Modal은 visible={modalVisible} 이라는 속성을 갖고 있어서, boolean 값에 따라 나타나거나 사라진다. modalVisible이라는 이름의 state 기본값은 false이나, 모달 버튼을 클릭하면 true로 변경된다.

• dim 처리된 회색 영역 및 모달 버튼 클릭 시 원 화면으로 복귀
  모달 전체 화면과 모달창 내 버튼을 Pressable 컴포넌트로 감싸고, 모달 전체 화면에만 modalVisible을 false로 변경하는 onPress 이벤트를 지정해 구현했다.

• 버튼 2개 나타남
  유저의 Access Token 유무를 확인한 후, Token이 없으면 로그인 확인 Alert를 팝업하는 custom hooks를 이용하여,
  Token이 있으면 navigation 기능을 이용해 해당 페이지로 이동시키고 Token이 없으면 해당 custom hooks에 따라 로그인 확인 팝업이 나타나도록 구현했다.

  • 영상 업로드 클릭 시
    (로그인 상태) 영상 업로드 페이지로 이동
    (로그아웃 상태) 로그인 확인 팝업 - Alert 이용하여 직접 구현했으나, 추후 custom hooks 이용하여 재구현
  • 내 영상 관리 클릭 시
    (로그인 상태) 내 영상 관리 페이지로 이동
    (로그아웃 상태) 로그인 확인 팝업 - Alert 이용하여 직접 구현했으나, 추후 custom hooks 이용하여 재구현

영상 업로드 페이지

• 업로드 기능
  (제목과 링크를 입력한 후 완료를 클릭하면, 영상이 업로드되고 메인화면으로 이동한다.)
  state에 저장된 제목과 링크, getItem 메소드를 통해 가져온 유저정보를 API를 통해 서버로 전송한다.

• Validation
  올바른 입력 입력이 아닐 때 유저에게 Alert가 뜨도록 설정했다.
  (제목이 입력되지 않았을 경우, 링크가 입력되지 않았을 경우, 제목과 링크 모두 입력되지 않았을 경우, 링크 형식이 유튜브와 다를 경우)

내 영상 관리 페이지

• 유저가 올린 영상 출력
  getItem 메소드를 통해 유저의 ID 정보를 가져오고, API를 통해 서버로부터 데이터를 받는다.
  FlatList 컴포넌트를 이용하여 구현했다.

• 무한 스크롤
  스크롤바가 화면 중간에 닿으면, 5개씩 추가적으로 영상 데이터를 받아온다. 이를 스프레드 연산자를 통해 앞선 영상리스트와 이어지도록 했다.
  FlatList 속성 중 onEndReached, onEndReachedThreshold 를 사용하여 구현했다.

• 상세페이지 이동
  useNavigation hooks를 이용해 각 영상의 이미지, 제목, 업로드일 등을 클릭하면 해당 영상의 상세페이지로 이동하는 기능을 구현했다.

• 수정페이지 이동 시 영상 ID, 제목, 링크 전송
  영상 정보에 thumnail 정보가 있을 뿐 링크는 없다. 그 thumnail 중 영상 고유의 ID를 추출하고, 이를 유튜브링크 형식으로 만들어서 수정페이지에 전송하는 로직을 구성했다.

• 삭제 모달창
  Modal 컴포넌트를 통해 삭제 버튼을 클릭하면 재확인하는 모달창이 오픈되도록 했다. beforeDelete라는 state를 설정하고 기본값으로 true를 지정한다. 모달창의 삭제를 클릭하면, beforeDelete 값이 false로 변하면서 모달창의 문구와 버튼 양식이 달라진다. 삼항연산자와 beforeDelete state 값을 이용하여 각각 다른 문구와 다른 하위 컴포넌트가 나타나도록 했다.

• 삭제 후 새로고침 (처럼 보이는 기능)
  나는 영상이 삭제되면, 해당 페이지만 새로고침이 되길 원했다. 그러나 React Native에서 새로고침 기능은 앱 자체를 reload할 뿐이었다. 그래서 서버에 delete 정보를 전송한 후 업데이트된 데이터를 API를 통해 서버로부터 바로 전송받았다.

영상 수정 페이지

• 미리 입력되어있는 제목과 링크
  내 영상 관리 페이지에서 넘어올 때 함께 전송 받은 영상 ID 제목, 링크를 setState하여 제목과 링크 Input 창의 DefaultValue로 설정한다.

• 수정 기능
  (수정한 제목과 링크를 입력한 후 완료를 클릭하면, 영상정보가 수정되고 메인화면으로 이동한다.)
  영상 ID 및 state에 저장된 제목과 링크를 API를 통해 서버로 전송한다.

쇼핑 메인 페이지

• 카테고리 내비게이션
  FlatList의 numColumns 속성을 통해 위아래 3개씩 반복되도록 구현했다. useRef의 focus 메소드를 통해 해당 카테고리로 스크롤링 되는 기능 구현을 시도했으나, 완료하지 못했다.

• 카테고리별 제품 목록 출력
  6개 카테고리가 같은 양식으로 되어 있어, 하나의 컴포넌트를 만들어 재활용했다. 각 제품마다 사진, 제품명, 가격, 브랜드이름, 구매와 리뷰 수 등이 나타나도록 했고, 하나의 제품 영역을 감싸는 부모 컴포넌트를TouchableOpacity로 만들어 이 중 어떤 부분을 클릭해도 제품 상세 페이지로 이동하도록 했다.

---

협업하며 느낀 점

CTO님과 사수분들을 보며 멋있다는 생각을 여러 번 했다.
후배들을 동료 개발자로 이끌어 주시려는 마음이 느껴졌고, 좋은 개발자에 대해 고민하며 감명깊은 글이 있을 때 우리에게도 공유하여 함께 고민할 수 있게 해주셨다.
무엇보다도 개발에 대해 아직 잘 모르는 우리를 마주할 때 가끔 답답한 마음이 드셨을 법도 한데 그런 내색 없이 우리가 잘 이해할 수 있도록 설명해주시는 모습을 보며, '나도 이 분같은 개발자로 성장하고 싶다'는 마음이 여러 번 들었다.

위티에서 일한 한 달 간, '깨어있는 기업이란 어떻게 일하는가'에 대해 느낀 점이 많다.
우선 서로의 시간을 소중히 여기기 때문에 꼭 필요한 회의만을 간결하게하는 하는 점이 그렇고, 직급과 관계 없이 상호를 존중하며 의견을 주고 받는 점이 그러하다. 이에 더해 문제점을 발견했을 때 문제 원인자를 찾기 이전에 해결 방안부터 함께 고민하는 모습도 그렇다.
내가 개발자로 전향한 이유 중 하나는 '사람으로서 일하고 싶다'였는데, 위와 같은 모습에 내가 개발자 문화와 정말 잘 맞는다는 것을 느꼈다.

코드를 작성하면서 console.log를 여러번 쓰고 지웠다. 원하는 기능이 동작하지 않을 때, 에러가 발생할 때, 테스트를 할 때 등 console.log를 사용해야할 경우가 많은데, 이 부분에 비효율적으로 시간을 많이 사용한 것 같다.
그래서 테스트 코드를 만들어 오류를 확인하거나, TDD 프로세스를 따르고 싶다는 마음이 생겼다.