1차 프로젝트 회고

드디어 데브코스를 시작하면서 가장 기대?하면서도 걱정되었던 2주간의 팀 프로젝트가 끝났다! 시작하기에 앞서, 2주간 정말 고생하면서 프로젝트의 basic 기능을 만든 우리 팀원분들께 고생하셨다는 말씀을 전해드리고 싶다.

사실 더 자세히 적고 싶지만, 글을 잘 못쓰기 때문에 생각나는 토픽에 대하여 짤막하게 정리를 해 보았다. 나중에 기회가 되면 수정하는 것이 좋겠다.

How

프로젝트는 2주간의 짧은 기간동안 진행되었다. 기간이 짧기 때문에 기획 단계에서 확실히 베이스를 잡아야 나중에 의사 결정 비용이 감소하고, 전체적으로 봤을 때 시간을 벌 수 있다는 생각이 있었기 때문에 기획 단계를 확실히 가져가자고 팀원분들과 합의했다.

첫 날은 아이디어 기획 툴로는 Figjam이라는 팀 보드를 이용하여 아이디어를 다뤘다. 보드가 워낙 넓어 의식의 흐름대로 생각나는 아이디어를 적기 좋았다. 의식의 흐름대로 아이디어를 나열했더니 구체화할 수 있었다. 다음 날은 오프라인으로 만나 아이디어 구체화 시간을 가졌다. 아이디어 구체화는 다음과 같이 이루어졌다.

• 어떤 서비스를 가져야 하는지 도메인 별로 나누고, 해당 도메인에서 더 세부적인 사용자 이동 흐름 작성
• api를 보고 우리 서비스에서 사용할 api를 선정하고, api와 서비스 명을 매칭하여 명세서를 작성
• 팀 단계에서 사용할 여러가지 기술 스택 선정
• 태스크 분배

우리팀에서 사용한 대표적인 개발 관련 기술 스택은 다음과 같다.

Typescript

해당 부분은 필자가 강력 추천했다. 아무래도 팀 프로젝트를 할 때 api를 사용할 때 마다 타입을 찾아보는 것은 매우 매우 시간 낭비이기 때문에..

Emotion

css in js를 구현하기 위하여 사용. 또 scss에 비하여 클래스명을 신경쓰지 않아도 된다는 장점이 있었기 때문이고, 패러다임 자체가 리액트랑 잘 맞는 것 같아서 사용하였다.

ContextAPI

전역 상태관리 라이브러리로 사용되는 대표적인 redux 또는 api로 요청한 데이터를 유용하게 저장할 수 있는 react-query, recoil 등을 사용하지 않고 리액트 기본으로 내장된 ContextAPI를 사용하게 된 이유는 다음과 같다.

• redux를 사용하지 않은 이유
  • 생각보다 전역으로 관리해야 할 상태가 없음
  • 전역으로 관리해야 할 상태가 별로 없는데, 그에 비하여 사전에 작성해야 할 코드 양이 많음
    • 현재로서는 전역으로 관리해야 할 정보가 유저 정보 정도밖에 없기 때문에, 리덕스로 상태를 관리하는 것이 불필요하다고 생각했다. 물론 리덕스로 전역 상태 관리를 하게 된다면 렌더링 최적화가 되어 있다는 점이 장점이기는 하지만 (ContextAPI의 경우 상태가 변경시 구독하는 모든 컴포넌트의 재렌더링이 발생한다), 상태가 변경되는 일 역시 크게 없다고 판단되어 redux를 사용하지 않았다.
• react-query를 사용하지 않은 이유
  • 사실 나는 react-query를 사용하는 것을 추천하였다. loading, error 처리가 간단하고 다양한 옵션 부여를 통해 상태의 새로고침도 쉽게 가능하며, 데이터 캐싱도 가능하다는 특징이 있었기 때문이다.
  • 그런데 2주간의 짧은 시간 내에 필수적인 부분을 이해하는 것이 어렵고, 필요성을 느끼기 전까지는 순정으로 구현하여 사용하는 것이 좋을 것 같다고 판단되어 일단은 hooks와 Context API를 사용하자고 합의했다.

우리 프로젝트의 주제가 개발자를 위한 간단한 실력 점검 퀴즈 서비스를 제공하는 것인데, 해당 프로젝트에서 퀴즈를 보여주는 페이지와, 퀴즈를 다 풀고 난 뒤 결과를 보여주는 페이지를 맡았다.

처음 기획 단계에서 사용자의 흐름에 대하여 산출한 기능들에 대해 크게 벗어나지 않게끔 로직을 구성하고자 하였다.

• 개발 시 아직 데이터가 많지 않기 때문에, 우리가 정의한 스키마를 바탕으로 목 데이터를 만들어 해당 데이터가 화면에 잘 바인딩 되어 있는지 확인하는 작업부터 진행했다. 잘 바인딩 되어 있다면, 목 데이터를 이용하여 컴포넌트를 먼저 완성하였다.
• api를 묶어서 함수로 만든 뒤, 데이터를 요청했을 때 응답이 잘 오는지 확인하고, api를 연결했다.
• 댓글이나 좋아요 등 api 연결이 필요한 부분은 api 연결이 끝난 뒤 해당 기능들을 구현하였다.

개발 기간 동안 매일 매일 TID or 회고를 작성하고자 하였으나, 생각보다 일이 많고, 중간에 개인 사정도 있었던 탓에 매일 작성하지는 않았다. 이전에 TIL 작성하듯이 공 들여 작성하기에는 시간이 많이 부족하여,

• 오늘 한 일
• 오늘 일어난 이슈들
• 이슈를 어떻게 해결했는지
• 이슈를 해결하지 못했다면 왜 해결하지 못했는지, 생각해 놓은 다른 아이디어가 있는지
• 내일 할 일

에 대하여 나열식으로 간단히 정리하였다.

1주차가 지나고, 하루 동안 지금까지 진행한 프로젝트 현황에 대하여 회고를 진행하였다. 회고 단계에서 많은 좋은 점들도 있었지만, 그에 못지않게 많은 개선점들이 나왔다.

토론을 통해 문제점을 파악했고, 문제점을 해결하기 위한 방법들을 제시하였으며, 남은 일주일동안은 개선된 규칙으로 팀 프로젝트를 진행하려고 시도했다.

이슈 관리

이슈 관리는 Github 이슈를 사용하였다. 노션이나 지라를 사용할 수도 있다고 하지만, github 이슈를 사용하면 현재 열려있는 이슈, 진행중인 이슈가 연동이 되어 위치를 수정할 필요가 없고, PR이 머지되면 이슈가 자동으로 닫히게 할 수 있다는 점이 맘에 들었다.

회고

여기서부터는 프로젝트를 하면서 개인적으로 느낀 점들을 적은 것이다. :)

맘에 들었던 점

[ 소통 부분 ]

• 팀원간 서로 양보할 부분은 양보하고, 의견을 표출할 때 모두 해당 의견에 대하여 경청한 점
  • 끊임없는 소통
  • 반대 의견이 있다면 합리적인 이유를 제시하고 토론을 진행
  • 아이디어를 제시하기에 너무나도 자유로운 분위기였다. 코어타임 진행 중에 궁금한 사항이나 막히는 부분이 있다면 바로 마이크를 키고 말하거나, 그게 어려우면 디스코드 팀 채팅방에서 자유롭게 채팅을 날리는 문화를 확립했다. 다른 팀원분들도 어려움이 있을 때 다 같이 모여서 해당 이슈에 대하여 의견을 자유롭게 제시하고, 여러 방법들을 시도해 보면서 이슈들을 해결할 수 있었다.
  • 어떠한 의견도 의미 없는 의견이거나 무시할 만한 의견이라고 생각하지 않고 모두 경청해 주어서 너무 감사하다.
• 칭찬을 아끼지 않음
  • 우리 팀원 분들 모두가 성격이 좋으시다. 그래서 잘했다고 하는 부분 에대하여 항상 감사함을 표출하고, 박수를 쳤다. ㅋㅋㅋ 칭찬은 고래도 춤추게 한다는 말이 있는 만큼, 칭찬을 받으면 더 열심히 하게 되는 부분이 있어 개인적으로 동기 부여가 많이 되었다.
• 팀 화이트보드 도입
  • 2주간의 짧은 개발 기간 때문에 시작과 마무리 스크럼을 모두 진행하는데, 여러가지 이슈들을 생각하다 보면 의미없이 보내는 시간이 정말 많았다. 그런데 팀 화이트보드를 도입하고 나서, 끝나거나 생각나는 이슈들, 다루고 싶은 주제들을 자유롭게 팀 화이트보드에 적어두면, 마무리 스크럼 또는 다음날 오픈 스크럼에서 팀 화이트보드에 써있는 주제들을 가지고 이슈들을 다루니, 스크럼 시간도 줄어들면서 중요한 부분만 빠르게 논의가 가능했다.

ex) 개인이 논의하고 싶은 주제를 자유롭게 적은 칸반보드

[ 개발 부분 ]

• PR의 단위를 짧게 가져갔음
  • 처음에 페이지 단위로 개발을 하다 보니 PR의 길이가 너무 길어졌다. 그래서 읽는 사람도 부담이 되고, PR 리뷰 기간이 길어지면서 반영이 늦어지는 악순환이 발생했다.
  • 해당 부분을 해결하고자 이슈 자체를 작은 단위로 가져가고, PR 코드 양도 200자 정도로 매우 적게 가져가기로 정했다. 그리고 basic 기능들을 개발하기 때문에 코드의 반영이 빠르게 이루어져야 하므로, PR을 올리면 30분 이내로 리뷰가 끝나게끔 룰을 정했다. 사실 해당 부분은 나의 경우는 코드를 작성하다가 흐름이 끊기는 것을 별로 좋아하지 않아서 반대 했던 부분이다(마무리 스크럼 1시간 전에 PR을 리뷰하는 시간을 갖는 것이 어떠냐고 제안했었다) 그러나 돌아보니 해당 부분은 나의 잘못된 생각임을 깨달았다. PR리뷰를 빠르게 하고 빠르게 반영함으로써 개발 시간을 크게 줄여 지금의 위치에 올 수 있었다고 생각한다.

[ 개인 부분 ]

• 조금이나마 단일 책임 원칙을 준수하고, 컴포넌트의 의존도를 낮추고 응집도를 높이기 위하여 이를 의식적으로 생각한 것
  • 이전부터 코드를 작성하면서 가장 고민했던 부분 중 하나이다. 특히 오브젝트라는 책을 읽으면서(아직 시간이 없어서 챕터 1밖에 읽어보지 않았지만) 가장 첫 챕터에 나오는 부분이 바로 이 단일 책임 원칙 준수와 의존성을 줄이고 응집도가 높은 클래스를 만드는 것이 중요하다는 내용이었다.
  • 해당 부분은 Java로 쓰여졌기 때문에 컴포넌트인 리액트와 Java와는 다른 패러다임을 갖기 때문에 완벽히 이론을 적용할 수는 없었지만, 원칙 자체는 동일하므로, 최대한 하나의 컴포넌트가 하나의 역할을 하는가? 를 우선적으로 생각하여, 해당 컴포넌트 내부에 다른 역할을 하는 함수, 분리 가능한 함수가 있다면 이를 우선적으로 분리하려는 시도를 하였다. 완벽하진 않았지만, 그래도 어느정도 가독성 향상과 유지보수하기 쉬운 코드를 만드는데 기여할 수 있던 것 같다.
  • 다만 시간이 부족하여 팀 내부에서 일단 구현에 집중하고 재사용성은 추후에 고려하자고 했으므로, 응집도나 의존성을 낮추는데 크게 힘쓰지 못한 것이 다소 아쉽지만, 이 프로젝트는 접지 않고 계속 리팩토링 및 서비스를 개발하자고 팀원들과 확정했으므로 앞으로 해결될 것이라 기대한다 🙂
• 큰 → 중 → 작 방향으로 개발을 진행한 것
  • 나의 평소 개발 진행 방향은 보통 핵심이라고 생각되는 부분의 로직을 생각해 둔 뒤, 각이 나온다 싶으면 세부 사항을 개발하는 방식으로 진행해왔다. 이런 방식은 먼저 큰 것부터 정리해두고 나머지 부분을 정리할 수 있어 심적 여유가 생긴다는 점에서는 좋지만, 전체적으로 봤을 때 처음에 잘 풀리지 않으면 개발 진행 속도가 점점 늦어진다는 단점이 있고, 이를 인지하고 있었다. 이번에는 큰 틀로 먼저 로직들을 짜고(이를 함수명으로 반영하는 것이 정말 가독성이 좋았다), 그 큰 틀 안에서 가져야 할 책임들을 나누고 다시 해당 책임 내에서 다음 책임을 나누는 방식으로 진행했다. 이렇게 트리구조로 접근하는 것이 생각의 흐름과 일치하기 때문에 개발 속도도 증가되었고, 가독성도 향상되었다고 생각한다.

아쉬웠던 점

[ 소통 부분 ]

• 개인적으로 소통 부분에 대해 크게 아쉬웠던 점은 없었다. 가끔 의견 차이가 있긴 했지만, 그것이 감정적으로 발전하진 않았다. 우리 팀 자체가 일단 타인의 말을 경청해주는 문화가 있었고, 이유가 합당하면 수용하는 오픈 마인드를 가지고 있기 때문이었다.

[ 개발 부분 ]

• 통일된 디자인 시스템의 부재
  • 공통적인 부분이 많았음에도 불구하고, css 는 일단 동작만 하면 돼!라는 생각에 emotion 기반의 컴포넌트를 사용하였음에도 불구하고 잘 사용은 못했던 것 같다. 이번 프로젝트에서 QuizSolvePage와 QuizResultPage를 담당했는데, QuizResultPage 는 지금 컴포넌트를 봐도 그냥 닫고 싶을 정도로 너무 막 짰다.(사실 가장 처음에 만들어진 부분이라 더 그런것도 있다)
  • 오히려 리팩토링할 수 있는 여지가 많아서 좋다(?). 우리팀은 이번 2주가 지나간 뒤 조금 여유를 두고 리팩토링을 우선 진행한 뒤, 우리가 생각한 advanced를 구성하기로 했다.
  • 아마도 우선 공통적으로 사용하는 부분 button, input 등등의 스타일을 디자인 시스템으로 만든 뒤에 사용하지 않을까 싶다!!
• rule 적인 부분이 완벽하지 않았던 것
  • 시간적인 이슈 때문에 완벽하게 팀 룰을 정하지 않아 파일명의 prefix가 다 제각각이었고, 폴더 구조도 애매한 부분이 많았다. 좀 더 짚고 넘어가야 할 부분이 꽤 있었음에도 불구하고 일단은 구현이 목표이다보니 잘 짚고 넘어가지 않았던 점이 조금 아쉽다. 해당 부분 다음주에 있을 팀 회의 때 정해나가려고 한다.
• 이슈와 커밋 단위의 불일치
  • 이슈단위로 개발하는 것이 아직 익숙하지 않다 보니 해당 이슈 범위를 벗어나게 되는 경우가 종종 발생했다. 처음에는 페이지 기반을 닦다보니 PR 단위가 커져버려 더욱 이런 문제가 심각했다. 중반 부분에는 그래도 신경 써서 개발을 해서 해당 문제가 좀 덜 했지만, 후반에 시간에 쫒기면서 다시 해당 문제가 드러나게 되었다.
  • 해당 문제를 해결하기 위한 방법…으로는 더 실수(?)를 많이 하여 익숙해지는 방법 말고는 없지 않을까 싶다. PR도 단일 책임으로!

[ 개인 부분 ]

• 로직과 컴포넌트의 분리를 시도하고자 하였으나, 잘 되지 않았음
  • 페이지에 많은 기능들이 들어가게 되고 api 요청 함수들과 util로 뺄 수 있는 순수함수들을 제외하고 나머지들에 대하여 로직 분리를 해보고 싶었으나, 리액트 상태에 묶여있는 부분들이 많아 리팩토링이 쉽지 않았다. 상태를 custom hook으로 묶기에는 재사용성도 떨어지는 부분이라고 생각해서 custom hook 방식으로는 리팩토링 하지 않았다. 실력의 문제이기도 하고, 시간의 문제이기도 한 것 같다. 리팩토링 기간에 좀 더 로직을 분리하여 순수함수로 내보낼 수 있는 부분이 있는지 확인하고, 코드 다이어트를 시도해 보고자 한다. (잘 안될 수도 있지만, 일단 해보는 거지 뭐…) → 해당 과정에 대해 기록으로 남기기
• 초반에 엄청난 git 실수
  • git 사용법이 아직 익숙하지 않아서 초반에 중대한 git 실수를 저질렀다. develop 브랜치를 기본 브랜치로 사용하고 있는데, merge 하면서 conflict를 처리하다가 rebase를 잘못하여 develop 브랜치가 현재 작업하고 있는 브랜치에 머지되었다… 덕분에 그래프가 많이 꼬여버렸다 ㅜㅜ. 덕분에 git 작업하면서 명령어도 조금 더 잘 숙지하게 되었고, 실수를 다시 하지 않으려고 두 번 세 번 확인한 결과, 그 이후로 중대한 실수는 발생하지 않았다.

내가 배운 것

• 팀 단위 소통 방식(문서화 및 리뷰)
  • 팀 단위의 소통은 개인 프로젝트를 진행할 때보다 훨씬 어렵고 중요함을 깨달았다. 우리 팀원과 함께 하면서 문서화의 중요성을 배웠다. 기록을 중시하는 팀원분들 덕분에 늘 스크럼 하기 전에 회의록부터 만드는 습관을 가지게 되었다. 의사 소통 비용을 줄이는데 가장 큰 기여를 했다고 생각했다. 그때 그때 기억나는 좋은 아이디어들도 기록하지 않으면 소멸되거나, 스크럼하면서 이런 저런 좋은 아이디어나 의사 결정을 하더라도 뒤돌아서면 까먹기 일상이었다. 근데 회의록을 기록하면서 이러한 부분이 많이 개선되었다고 생각한다.
  • PR은 내 코드를 남에게 보여주는 것이다. 나 역시 리뷰를 통해 더 좋은 코드를 작성하고자 리뷰를 받는 것인데, 상대방에게 이 코드가 무엇인지 설명을 제대로 하지 않으면 무엇을 하고자 하는지 잘 모를 것이다. 나 역시 이러한 피드백을 받았으므로 더 성심 성의껏 PR을 작성하는 연습을 했다. (물론 코드 가독성이 일순위이다)
  • 그리고 팀에 기록되지 않는, 프로젝트를 진행하면서 무엇을 했는지 간단히 기록하는 TID를 개인 노션에 작성했다. 작성에 공들일 시간이 별로 없어 간단히 무엇을 했는지, 어떤 이슈가 있었는지, 해당 이슈를 해결했다면 어떤 방식으로 해결했는지, 해결하지 못했다면 앞으로 어떤 방식으로 접근해볼 수 있을지 간단하게 적어놓았다. 그러면 다음번에 같은 실수나 오류가 발생했을 때 훨씬 찾아보기 쉬울것이다.
• 가독성의 중요성 (코드 길이 및 변수명, 상식적인 흐름, 단일 책임) [ 엄청난 난제, 사실 지금도 잘 모르긴 함 ]
  • 팀 프로젝트다보니, 내 코드만 담당하는 것이 아닌, 타인의 코드를 편집해야 하는 경우가 필연적으로 생길 수 있다. 그런데 코드가 제대로 책임이 분리되어 있지 않고, 가독성이 너무 떨어져 어디서부터 고쳐야할 지 몰라 방치된다면?? 정말 최악의 경우 해당 코드를 전부 드러내거나 같은 작업을 여러 번 반복하게 될 수 있다.
  • 나 역시 팀원분의 코드를 보면서, 내 코드를 볼 때도 사람들이 쉽게 편집할 수 있는가? 에 대하여 의문을 갖게 되었고, 해당 부분에 좀 더 신경쓰면서 코드를 작성했다.
    • ex) 사용자가 의도한 동작을 통해 해당 페이지로 접근했는지 → isAppropriateAccess
    • 함수의 길이는 50줄 이내로 작성하기
    • 잘 이해가 안될 때에는 코멘트 작성하기
  • 상식적인 흐름 같은 경우는 다음과 같은 경우이다
    • 일반적으로 물건을 사기위하여 손님이 점원에게 돈을 지불하지, 점원이 손님의 가방으로부터 돈을 빼가지 않는다.
    • 상식적인 흐름을 위해서는 구현 부분과 api 영역의 분리가 필요하다.
• 공식 문서를 잘 보자
  • 캐러셀 구현을 위하여 React-Slick을 사용하였는데, 화면이 움직일 때 페이지 번호를 갱신해야 했다. 처음에는 클릭 후에 React-Slick의 애니메이션 시간과 동일하게 시간을 주어 SetTimeout을 이용하여 버튼을 비활성화 시키는 방법을 사용하였다.
  • 이 방법은 꽤나 효과적이였지만, 간헐적으로 버튼을 연타시 실제 이동한 인덱스와 표시되는 인덱스가 달라지는 문제가 있었다.
  • documentation을 잘 보니 해당 api를 제공하더라… 조금은 허무했다 ㅠㅠ

소감

• 개발자로 나아가는 첫 번째 프로젝트였다. 그래서 데브코스에 처음 지원했을 때에도 나는 팀 활동을 하고싶다고 강력하게 어필했던 기억이 있다. 막상 팀 프로젝트를 시작하려니 기대도 되긴 했는데 그보다 불안감이 더 컸다. 팀장이라는 역할을 달고 있었기 때문에 약간의 부담감도 있었다.
• 그러나 기획부터 마감까지 같이하면서, 불안감은 사라지고 데브코스에 참여하길 정말 잘했다는 생각밖에 안든다. 내가 혼자 프로젝트를 진행했다면, 데드라인이 명확하고, 기획이 명확한 서비스를 만들 수 있을까? 아마 못했지 싶다. 역시 사람은 데드라인이 정해져있어야 일을 한다(?)
• 내가 기여한 부분보다는 팀원분들로부터 배운 점이 훨씬 많았다고 생각한다. 이 역시 첫 팀프로젝트였기 때문에 많은 기대는 하지 않았다. 그래도 앞으로 리팩토링을 진행하면서 내가 팀에 기여할 수 있는 기여도가 좀 더 높아졌으면 한다.
• 우리팀 밸런스는 정말 좋았다. 각각 다른 부분에 강점을 가진 분들이 모이니, 이것이 모여 -가 아닌 +가 되는 효과를 보았다. 우리 팀은 정말 오랫동안 기억에 남을 팀이다.
• 누구를 위해서가 아닌, 나를 위해서 꾸준히 기록하고자 노력하였는데, 정말 감사하게도 이번달 데브코스 배움 기록왕에 선정되었다😀. 앞으로 습관을 꾸준히 이어나가겠다.