[프로젝트 회고] ALL WE NEED IS LUVOOK

들어가면서

데브코스의 절반 이상을 함께한 팀원들과의 프로젝트가 끝났다.

우여곡절이 많았지만, 처음에 완성하고자 하는 방향성으로 잘 나아간 프로젝트라고 생각한다.

LUVOOK 미리보기

배포 사이트

지금 당신에게 필요한 책, 러북

깃헙 README

GitHub - prgrms-fe-devcourse/FEDC2LUVOOKJieun: 📚 지금 당신에게 필요한 책, <러북>

HighLight

프로젝트를 하면서 가장 기억에 남는 부분과 핵심이라고 생각하는 부분이다.

컴포넌트 재사용성과 리모트 데이터 스키마의 숨은 의존성

• 초반에는 컴포넌트에 있어서, 컴포넌트가 당연히 가져야할 기능은 미리 가이드를 만들어두는 것이 좋다고 생각했었는데, base 컴포넌트에 기본적으로 그런 기능을 끼워넣는 다는 것이 오히려 재사용성을 해칠 수 있다.

• 컴포넌트의 재사용성에 대한 자료를 꽤 찾아봤던 것 같다. 그 중에서 제일 기억에 남는 것은 FeConf Korean에서 원지혁님이 발표하신 컴포넌트 다시 생각하기. 였는데, 내용 중에서 리모트 데이터 스키마의 숨은 의존성 이라는 내용이 특히나 와닿았다.

  특히, 프로젝트 전날에 API 스펙의 변경되는 이슈가 있었는데, API 스펙과 강하게 연결되어있던 몇 요소 들에서 문제가 생겨 버렸다.

• API 스펙을 이용하면서, API를 있는 그대로 사용하였던 점이 문제의 원인들이였던 것 같다. 대부분의 API의 설계가 객체를 받아오는 방식으로 되어있는데, 객체를 받아오는 방식 내에서 객체가 가지고 있는 프로퍼티들이 id로 오는 경우와 객체 그대로 오는 경우가 상당히 오락가락 하였기 때문에, 객체의 형식을 유지하고 있던 컴포넌트들에게 문제가 발생하였다.
• 따라서, 객체 대신에 모든 API 응답에서 공통적으로 오는 id 값들을 Promise.all 을 통하여 id를 통하여 다시 요청하는 함수를 통하여 id 값을 통하여 값을 불러오도록 하였다. 위의 컴포넌트 다시 생각하기의 발표에서 위에서는 ID만 받고 스키마는 전역 상태에서만 받자 는 내용이 생각났다.
• 그러나, ID 값을 이용하면 안정적으로 데이터를 가져올 수 있겠지만, 그 만큼 다시 요청해야하는 경우가 생기기 때문에 또 다른 낭비가 생길 수 있다고 생각한다. (물론 서비스가 커지면, 객체를 그대로 api가 불러와주지는 않을 것 같아서, 결국엔 주로 id값으로 주로 불러와주는 과정이 많이 사용될 것이라는 생각은 든다.)

React는 “충분히(not best)” 빠르다

• 프로젝트를 하던 도중에 1기 분이 와주셔서 React에 대한 말씀을 해주셨다. 가장 기억에 남는 이야기는 React는 아주 빠른게 아니라 충분히 빠르다는 것이엿다.
• React는 최적화를 도와주는 것이지, 우리가 React를 사용할 때 최적화 할 수 있는 환경을 만들어줘야한다. 프로젝트를 할 때 아쉬웠던 점 중 하나가, 최적화 로직을 제대로 작성하지 못했다는 것이다. React.Memo 와 useCallback 등을 사용하여 각 컴포넌트 별로 최적화를 해줘야 함을 느꼈다.
• React를 사용할 때, React의 Reconcilliation 에 이해하는 과정이 중요하다고 생각이 들었다. 왜냐면, 프로젝트에서 api를 통해서 계속해서 변화하는 상태를 받아오는 과정이 많았는데, 이 과정을 이해하지 못해서 생긴 여러가지 이슈가 존재하였다. (ex: state로직의 얕은 비교)

동료들에게 어떻게 배울 수 있었나?

• Notion - 지금 당신에게 필요한 책, <러북>

제대로 된 협업을 경험한 적이 거의 없었어서, 이번 프로젝트에서 특히나, 협업과 동료들을 통해서 많은 내용을 배울 수 있었다. 특히나 개발자들이 자주 사용하는 소통 툴을 이용하여 개발자 다운 소통을 할 수 있었다.

Issue 들을 모아놓는 비동기 소통

기본적으로 팀원들이 다 함께 있을 수 있는 환경이기도 했지만(마지막 날을 제외하면 거의 하루종일 같은 팀 내에서 의사소통이 가능한 환경이였다), 그럼에도 불구하고 발생할 수 있는, 불가피한 소통의 간극을 매우기 위해, 그리고 논의에 시간이 필요한 내용들을 나누기 위하여 노션에 각자 안건을 모아둘 수 있는 공간을 만들고 매일 시작스크럼마다 해당 내용을 공유하였다.

이런 방식으로 안건을 모아두어서 느낀 이점 중 하나는 실시간으로 말하는 것과 비교하여 어느정도 내 생각을 글로 정리할 수 있는 기회가 생겼다는 것이다. 단순히 “~가 편해서”, “~를 강의에서 사용하니까”와 같은 이유가 아니라 도입을 제안하고, 다른 팀원분들을 설득하기 위해서 나름의 이유를 생각하면서 조금 더 영혼을 탑재한 개발을 할 수 있었던 것 같다.

개발자다운 소통이란

위에서 언급했다싶이, 개발자 다운 소통을 체험하기 위하여 다양한 소통 툴을 이용하였다. 여기서 개발자 다운 소통이 뭐냐?라고 물어보실 수 있어서 한 번 내 생각을 정리해보자면, 내가 생각하는 이상적인 개발자다운 소통이란 협업에 있어서  인간으로서의 소통 과 개발(코드)로서의 소통이 합쳐진 모양이라고 생각한다. 왜냐하면 나는 (여기서는 간략하게만 이야기하겠다. 이 이야기를 더 듣고 싶다면 개인적으로 연락을…) 개발에 있어서의 “소통”이라는 면은 사람과 사람, 사람과 컴퓨터, 컴퓨터와 컴퓨터의 여러 주체를 아우르는 소통이고, 이 소통은 얽혀있는 형태로 나타난다. (또한 이런 여러 주체들의 소통에서도 소통 방식에 따라서 말과 말의 소통, 말과 코드의 소통, 코드와 코드의 소통으로 다시 얽힌다고 생각하지만, 이걸로 글을 쓰게 된다면 앞으로 4시간 동안은 글을 써야하므로 이만 줄이도록 하겠다)

이런 소통 방식들은 이 애플리케이션들이 가지고 있는 실시간성의 강도에 따라서 각기 다른 형태로 사용하였는데, 팀 작업에서 어떻게 사용하였는지에 대한 이야기는 다음과 같다.

• Github Issue - PR과 바로 연결할 수 있다는 점이 편리하였다. 조금 아쉬웠던 점은 Issue에도 comment를 이용한 소통이 있었으면 좋았을 것 같지만(그래서 처음에는 Issue에서 어떻게 개발할지에 대해서 꽤나 시간을 들여서 자세하게 적었으나, 이는 PR로 대신하게 되었다)… 너무 짧은 시간에 많은 것들을 개발해야 했었고, 코드리뷰 조차 시간이 부족해서 빠르게 해야했기 때문에, Issue를 120% 활용하지는 못한 것 같지만, Issue를 통하여 내가 어떤 작업을 할지 에 대해서 모두가 알 수 있었다는 큰 장점이 있었다.

• Github PR - 우리 팀의 경우 2명이상의 Approve를 받아야 merge 할 수 있는 룰이 있었는데, 덕분에 하기싫어도 코드 리뷰에 상당한 비중을 쏟을 수 밖에 없었고, 이 때 쏟은 비중은 이 후에 다른 팀원들이 만든 컴포넌트나 기능들을 활용할 때 시간을 크게 줄여줬다. 특히나 다른 분들도 열심히 코드리뷰를 해 주셔서, 다른 방식으로 작성된 코드들을 모두가 활용할 수 있었다.

  개인적으로, 우리 팀의 작업 중 가장 마음에 들었던 부분 중 하나가, 코드를 작성할 때 남의 코드에 대해서 이해하지 못한 부분이 나도 없었고, 팀원들도 크게 없었다는 것이다. 이렇게 코드를 짜는 것과 코드를 읽는 것 역시 소통이라는 관점에서 생각해보면 위에서 말했던 대로 협업을 구성하는 ‘인간으로서의 소통’ 적인 면과, ‘개발로서의 소통’적인 면을 모두 잘 충족한 형태였던 것 같다.

• Slack - slack이라는 툴은 다른 툴보다 실시간성이 있다는 점을 이용해서 주로 그날그날의 일정을 공지하는 곳으로 주로, 사용하였다.

• Discord - 사용한 소통 방식 중 가장 실시간성이 큰 방식이였다. 팀원분의 열정이 매우 강했기때문에 대부분의 시간동안 디스코드에 팀원들이 모두 존재하였고, 디스코드 덕분에 급한 안건도 급한 안건이지만, 무엇보다 팀원끼리의 전우애를 향상시키는데 도움이 되었다.

• Notion - 가장 실시간성이 떨어지는 방식이였다. 처음에는 Notion의 업데이트 소식을 슬랙 채널 알림으로 구독하려고 했으나, 생각보다 Notion의 세세한 방식까지 알림을 보내주는 바람에 채널에 Notion을 구독하지는 못하였다.

  따라서 Notion은 비동기소통을 위한 장으로 주로 사용하였다. 또한 그런 특성덕분에 다른 소통 방식에 비하여 조금 더 정제된 내용을 작성할 수가 있었고, 이것은 문서화에 크게 도움이 되었다.

더 배우고 싶은 것

단단한 프로그램 만들기 with TypeScript

• 기본적으로 프로그램에서 React + Javascrtipt를 사용하였으나 JS의 문제점이라고 꼽히는 타입이 “느슨한 타입”이 생각보다 많은 오류를 만들어내었다. 특히나 api에서 특정 객체 데이터를 받아오는 과정에서, 이 객체 데이터는 JSON.parse 와 JSON.stringify를 통하여 우리 팀원들이 정한 약속대로 사용하였는데 JS에서는 타입에 대한 interface를 만들 수 없었기 때문에, 이 데이터를 팀원끼리 회의하고 각 컴포넌트에서 사용하는 방식을 택했었는데, interface의 부재 때문에 서로 생각하는 객체 데이터의 타입이 통일되지 않아서, 컴포넌트 별로 다른 프로퍼티를 사용하게 된다던가, (아무리 미리 정해둔다고해도, interface를 정의해두는 것보다 강력한 효과를 미치지 못한다) 프로퍼티 별로 다른 방어코드를 작성한다던가 등의 문제점이 있었고, 이 interface가 명시적으로 코드에 보이지 않았기 때문에 코드 자체의 가독성 역시 떨어지는 문제가 있었다.
• 그리고 컴파일 과정에서 타입 체크가 일어나지 않기 때문에 Proptypes 와 같은 것으로 방어코드를 작성해보려고 해도 에러 콘솔만 뜨고, 제대로 에러를 잡을 수 없었다. 아마도 만들어진 프로젝트 내에서도 숨어있는 버그가 상당히 많을 것이라고 예상하는데, 이 버그를 줄이기 위하여 컴파일 단계에서의 버그 체크가 필요하다고 느껴졌다.

번외: 프로젝트 동안 무슨 일이 있었고, 무엇을 공부했나? 프로젝트 일지

220609 프로젝트 일지 + TIL

220610-220612 프로젝트 일지 + TIL

220616~220622? 프로젝트 일지 + TIL

개발하면서 맞닦드린 일들과 공부한 내용을 조금씩 정리하였다.

사실은 3일에 한번 씩 쓰는게 목표였는데 시간이 지날 수록 개발 내용이 많아지고

버그 픽스가 많아지면서 점점 텀이 늘어나고 퀄리티도 조금씩 떨어지지만ㅋㅋㅋ

큼직큼직한 사건들은 다 기록할 수 있었어서 의미있는 기록이라고 생각한다.