2차 데모데이 피드백과 반영

2차 데모데이를 진행했다.

본격적인 개발에 들어간 기간이기 때문에

백엔드/프론트엔드 나누어 현재 진행 상황에 대해 발표했다.

 

Webpack을 사용한 프로젝트 환경 세팅

CRA를 사용하지 않고 Webpack을 사용해 프로젝트 환경 세팅을 했다.

CRA를 사용하면 우리가 사용하지 않는 기능까지 딸려오기 때문에 우리의 입맛에 맞게 설치하고 구성했다.

 

미리 Webpack을 사용해하는 방법을 연습해 보고 각자의 방법을 조합해 만들었다.

자세한 내용은 CRA 없이 리액트 세팅하기 참조,,, 

 

디자인 시스템 구축

공통 컴포넌트를 따로 배포하여 디자인 시스템을 구축하였다.

chakra를 참고하여 만들었고, 당장 필요한 컴포넌트부터 만들고 본 프로젝트에 붙이는 식으로 작업하였다.

 

이 디자인 시스템에 대해서는 할 말이 많은데 아래 피드백 부분에서 후술 하도록 하겠다.

 

메인 페이지 컴포넌트 및 화면 구현

메인 페이지에 있는 컴포넌트와 화면을 구현하였다.

시간이 없어 백엔드와 API 통신은 하지 못했고 mock 데이터를 활용했다.

 

테스트 전략

react-testing-libaray를 사용하기로 했다.

 

아래의 이유로 결정하였다.

• 리액트 컴포넌트를 테스트하기 위한 함수 제공
• 테스트를 실제 DOM 노드에서 수행
  • -> 사용자가 실제로 서비스를 사용하는 것처럼 테스트를 할 수 있게 도와줌
• 우리가 하고자 하는 테스트인 E2E와 hook 테스트 모두 지원

 

CI/CD

위 과정을 사용해 CI/CD 환경을 구축하였다.

GitHub의 develop branch에 merge가 되면 webhook을 통해 트리거가 된다.

이때 Jenkins가 본 저장소를 clone 하고 build를 하고 이 과정을 slack을 통해 알려준다.

과정이 완료되면 HTML 등 정적 리소스 파일과 JAR 파일로 나누어 배포된다.

 

피드백

다음과 같은 피드백을 받았다.

 

1.  프론트엔드와 백엔드의 싱크가 맞지 않는다.

백엔드는 속도가 빨라 앞서나가고 있는데 프론트의 경우 API 연결을 하지 못했다.

각각의 개발 테스트보다는 통합해서 실제로 사용할 수 있도록 해야 한다.

데모라는 것은 기능을 데모하는 것인데 이는 실제로 동작 가능한 수준을 말한다.

한 사이클이 돌 때마다 제대로 작동하는지 확인해야 한다.

 

2. 팀원 전체의 작업을 이해해야 한다.

CI/CD에 대해 나머지 팀원들은 이해하고 있는가? 유지 보수 할 수 있는가?

협업이란 다른 사람들이 하는 작업을 모르면 안 된다.

다른 사람이 했던 작업을 이어받더라도 큰 문제가 없어야 한다.

서로 이해 수준을 맞춰야 한다.

 

3. 디자인 시스템에 대한 회의가 든다.

디자인 시스템을 왜 만들었는지 모르겠다.

이걸 만든다고 api 연동을 하지 못한 것은 아닌가.

프로덕트를 완성하는 것이 더 중요하다.

일단 완성하고 나중에 개선점을 찾아서 고도화하자.

 

 

 

위 피드백에 대한 해결 방법은 아래와 같다.

 

 

1.  프론트엔드와 백엔드의 싱크가 맞지 않는다.

초반에 프론트엔드는 적용해야 할 요구사항이 많아 개발 진행이 많이 느렸다.

그래서 결국 데모데이 전까지 api 연동을 하지 못했다.

 

우리는 이 피드백을 받고 일정 추정표를 다시 작성하였다.

전체 추가될 기능을 세부적으로 쪼개어 정의하고 프론트엔드와 백엔드 담당자 이름을 작성하였다.

그리고 그 기능이 완성되면 해당 칸에 색칠을 하여 진행도를 표시하였다.

 

프론트와 백 모두 진행이 완료되면, 담당자 둘이 모여 api 연동을 함께 한다.

올바른 값이 오고 있는지 확인하고 그다음 merge 하는 방식으로 싱크를 맞추었다.

 

이 이후로 진행한 데모데이 모두 계획한 기능을 api 연동까지 끝냈다.

(코치님이 예상 계획을 듣고 너무 많은 것이 아니냐고 놀라기도 했지만 일정 추정을 잘해 모두 기간 안에 끝낼 수 있었다)

 

 

2. 팀원 전체의 작업을 이해해야 한다.

이건 전적으로 내가 할 말이 없다 🥲

솔직히 이때 근로한다고 너무 바빠서 CI/CD 쪽은 놓았다...

그래서 코치님이 날 콕 집어 설명해 보라고 했을 때 대답하지 못했다.

많이 반성을 했다. 현업이라고 하면 내가 그 작업을 물려받았을 때 아무것도 하지 못했을 거 같다.

 

그다음부터는 새로운 기능이 생기면 간의 세미나를 열어 설명을 듣고

오류가 생기면 그 오류 상황을 공유하고, 해결 방법을 같이 찾는 등 여러 노력을 해 작업을 이해하려고 했다.

 

 

3. 디자인 시스템에 대한 회의가 든다.

이 부분에 대한 피드백은 처음에 약간의 반발(?)이 있었다.

왜냐하면 디자인 시스템을 구축할 때 생각보다 시간이 많이 걸리지 않았기 때문이다.

 

물론 적용하지 않은 것에 비해서는 어느 정도 걸렸겠지만

이것 때문에 api 연동을 하지 못할 정도는 아니었기 때문이다.

(오히려 webpack 관련 이슈나 컨벤션을 짜는 게 시간을 많이 잡아먹었다...)

 

그래도 지금 와서 그만두기에는 이미 컴포넌트도 어느 정도 있고 잘 사용하고 있어서 그대로 진행하기로 했다.

그리고 우리는 나중에 왜 말렸는지 이해할 수 있었다.

 

첫째, 우리가 디자인을 다 한 게 아니라는 것이다.

예를 들어 버튼의 경우 디자인 된 부분 기준으로 규격을 잡아두었는데

나중에 다른 디자인의 버튼이 계속 추가되면서 의미가 없게 되었다.

 

따라서 버튼의 경우 나중에 디자인이 완료될 때 

다시 규격을 정의하기로 하고 일반적인 속성을 다 받게 했다.

 

둘째, 디자인 시스템을 수도 없이 수정해야 하는 경우가 생겼다.

웹 접근성을 위해 디자인 시스템에 있는 한 컴포넌트에 ref를 붙여야 하는 사례가 있었는데,

이 경우 거기서 다시 수정하고 배포하는 등의 번거로운 과정을 거쳐야 했다.

이게 한두 번이면 괜찮은데 적용되지 않으면 하나를 고치기 위해 여러 번의 배포 과정을 겪어야 했다.

 

왜 초반부터 무턱대고 시작하지 말라고 하는지 이해가 됐다.

우리 모두 매번 디자인 시스템에 대해 말을 하면 그때를 떠올리며 '이렇게 큰 뜻이 있었구나' 한다.

그래도 이 과정에서 공통 컴포넌트에 대해 조금 더 이해하고, 버저닝 관리도 할 수 있어서 배운 게 많았다.