클론코딩 최종 회고

클론 코딩 Project : CREAM (KREAM 클론 코딩)

프로젝트 진행 기간 : 2023.08.28 ~ 2023.09.22

GitHub - prgrms-be-devcourse/BE-04-CREAM: [앨런팀] KREAM 클론 코딩

 

들어가며

한달동안의 프로젝트를 진행하며 많은 것들을 배웠고, 많은 것들을 깨달았던 클론코딩 프로젝트였다. 

회고를 통해 배웠던 것, 깨달은 것을 정리하고 기록하고자 한다. 

 

Good Things

Git-flow 도입

사실 Git-flow라는 개념을 처음 접했다거나, 적용해본 적이 없는 것은 아니다. 마지막 팀 프로젝트로 Git-flow를 적용했던 것이 작년 말이었다. 하지만 그 당시에는 Github에 대한 이해도도 낮았고, 무엇보다 개발을 빨리 해야한다는 마인드 때문에 Git-flow를 제대로 이해하지 못하고 표면적으로만 Git-flow를 흉내 냈던 것에 가까웠다.

 

이번 클론코딩 프로젝트에서 팀원들과 주된 관점을 두었던 것은 협업 이었다. 

팀 프로젝트와 개인 프로젝트의 가장 큰 차이는 같이하는 팀원이 있는가 없는가 라고 생각한다. 

 

개인 프로젝트에서는 프로젝트를 가꿔나가는 주인이 혼자이기 때문에 프로젝트에만 몰두하면 된다.

팀프로젝트는 나 이외에 다른 개발자들과 함게 주인이 되어 프로젝트를 성공시키기 위해 노력한다. 개발자 개인마다 코드를 짜는 방식도 다르고, 커밋을 남기는 방식도 다를 것이다. 이러한 부분들을 서로 맞춰나가야 성공적인 프로젝트를 만들 수 있다고 생각했다.

 

아마 Git-flow를 한번이라도 검색을 해봤다면 나동호님의 기술블로그 글을 봤을 것이라 생각한다. 

해당 글을 자세하게 읽어 어떠한 방식으로 Git-flow를 적용해야하는지 우선적으로 공부를 진행했다. 

다만 우아한 형제들에서 사용하는 방식과는 살짝 다른 방식으로, 우리 팀에 맞는 Git-flow를 적용했다. 

블로그에서는 각자의 repository에 fork를 해 개인의 repository에서 커밋을 한 후 pull request를 올리는 방식을 사용했으나, CREAM 팀에서는 개인 repository를 쓰지 않고, 직접 repository에서 push를 올려 pull request를 올리는 방식을 사용했다. 

우아한 형제들 Git-flow

CREAM 팀 Git-flow

fork한 repository에서 작업 후 pull-request를 올리는 방식도 좋아보였으나, 팀원 모두 github에 대해 높은 이해도가 없어 fork를 하는 과정에서 잦은 장애 사항이 발생 해 시간을 많이 소요할 것 같다는 생각이 들었다. fork하는 과정을 생략하여 보다 실수가 발생하지 않는 프로세스를 만들기 위해 살짝 변경하여 프로젝트를 진행했다.

 

Code Review 문화 정착 시키기

개발자마다 다른 코드 스타일 및 개발 숙련도를 가지고 있다. 

개발자 1은 메서드명을 축약해 개발하는 것을 좋아하고, 개발자 2는 메서드명이 길더라도 명확하게 보여주는 것을 좋아할 수 있다.

개발자 1은 Effective Java 및 Clean Code정도의 실력을 가지고 있고, 개발자 2는 기본 Java를 막 뗀 실력을 가지고 있다.

(물론 예시일 뿐, 실제 팀원들이 그렇다는 것은 절대 아니다.)

 

개발자마다 숙련도가 다르고, 코드 스타일도 다르다. 

혼자 개발을 한다면 어떻게 개발을 해도 큰 상관이 없겠지만 다른 팀원들과 코드를 공유하는 프로젝트를 진행한다면, 서로에 대한 이해도가 높고 서로의 코드 스타일을 어느정도 일치시키는 방향으로 진행을 해야 생산성이 높아지는 개발 팀이 될 수 있을 것이라 생각했다. 

그렇기에 각자 개발한 코드들에 대해서 pull-request를 올릴 때, 모든 팀원이 review를 해야 merge를 할 수 있도록 branch rule을 적용해 두었다. 

 

처음에는 다른 팀원들의 코드를 보며 의견을 나누는데 30~50분의 시간이 들 정도로 많은 시간이 소요되었다.

하지만 시간이 갈 수록 소요시간이 점점 줄었고, 프로젝트가 거의 끝나갈 때 쯤에는 서로 비슷한 스타일로 개발을 하는 모습을 확인할 수 있었다. 

 

빠른 CI / CD 구성 

프로젝트를 본격적으로 시작하기 전부터 Github Actions를 사용해 AWS EC2 서버에 배포가 되게끔 구성을 해 두었다. 

그 덕에 프로젝트 중간에 CI / CD에 시간을 뺐기지 않고 개발을 할 수 있어 효율 좋게 개발을 할 수 있었다. 

 

그 외에도 팀원 모두에게 개인 EC2 서버 pem 키를 공유했고, 간단한 EC2 설정 및 사용 방법에 대해 간략하게 교육을 해 모두 공평하게 EC2를 경험해볼 수 있도록 하였다. 

 

Bad Things

잘못된 도메인 분배

프로젝트 초반에 이번 프로젝트의 MVP는 무엇인지 정한 후 MVP를 달성하기 위해서 어떠한 도메인을 구현할 것인지 분배를 하는 과정에 있어서 잘못된 분배를 했었다. 

[잘못된 분배의 주된 원인]

팀원 모두 크림에서 제일 중요한 기능은 입찰 이라고 생각했다.

입찰 기능을 한명이 구현한다면, 다른 두명은 의미있는 경험을 하지못할 것이라 생각했다.

그러한 이유로 도메인으로 나누지 않고 역할로 기능 분배를 진행했다. (판매자, 구매자, 관리자)

역할로 기능 분배를 진행하니 크게 두가지 정도의 문제가 발생했다. 

 

1. 상대적으로 느린 개발 속도

관리자는 판매자와 구매자에게 영향을 받는 부분이 적어 개발 속도가 괜찮았지만, 구매자 판매자 역할을 맡은 개발자들은 서로 의존적인 부분들이 있어 다른 한명이 개발을 진행하고 commit을 올리는 것을 기다려야 하는 경우가 많이 발생했다. 심지어 branch rule에 모든 팀원들이 approve를 해줘야 merge를 할 수 있도록 해 두어, 코드 리뷰가 다 끝나야 다른 개발자가 개발을 시작할 수 있는 일들이 빈번하게 발생했다. 

 

2. 단일 도메인의 두가지 역할 분배

역할별로 기능을 분배하다보니 입찰 도메인에 판매자 구매자라는 역할이 분배가 되어버렸다. 

이 당시 정말 잘못된 설계를 저질러 버렸다. 

설계 초기 단계 ERD

최종 단계 ERD

두가지 사진 중 첫번째 사진이 처음 설계한 ERD이다. 

최종 단계에서는 많은 기능들이 추가되어 ERD가 복잡해졌지만, 입찰 테이블의 차이를 보면 명확하게 알 수 있다. 

설계 초기 단계에서는 입찰 Table이 구매입찰, 판매입찰로 나뉘어져 있다. 역할의 분리에 따라 보다 편리하게 개발을 하고자 테이블을 분리한 것이었다. 

잘못된 방식의 설계는 다음과 같았다.

개발을 편리하기 위해 Table을 분리하자.

이 당시에는 큰 문제가 되지 않을 거라 생각하고 개발을 했지만 점점 개발을 할 수록, 똑같은 테이블이 하나 더 있는 것이 좀 이상하다고 느껴졌다. 추후에 멘토님이 피드백을 주셨을 때 다음과 같이 말하셨다. 

명확하게 설계를 해놓는 것이 먼저입니다. 개발의 편리함이 우선이 되어서 안됩니다. 

결국에는 프로젝트를 갈아 엎는 현상이 도래했지만, 오히려 기존에 개발하던 것 보다 생산성이 4~5배는 올라갔던 것 같았다.

 

팀원간의 충분한 유대감 조성 실패 

살짝 부끄러운 이야기 이지만, 프로젝트 2주차 정도까지 프로젝트 외적으로 준비하는 일이 있기도 했고, 스크럼을 이끌어 가다 보니 프로젝트에 너무 많은 리소스가 들어가 주체적으로 이끌지 못했던 것 같다. 또한 개발 외적인 유대감은 개발에 있어 중요한가? 라는 생각이 존재해 크게 신경을 쓰지 않고 넘어갔던 부분이다. 

 

스크럼 마스터 혹은 프로젝트 리더의 공동 책임화 + 개발 외적인 유대감의 부재 

 

이 두가지 요인이 계속 겹치게 되니 팀원끼리 오해가 쌓여가고 프로젝트 생산성도 점차 저하됨을 느꼈다. 

 

프로젝트를 갈아 엎고 다시 시작을 할 때 팀원들과 개발 외적으로 서로 원하는 프로젝트 방향, 감정적으로 응어리졌던 부분들에 대해서 충분하게 얘기를 나눴고, 프로젝트를 성공적으로 이끌기 위해 스크럼 마스터의 역할을 다시 자처했다. 

 

팀원 분들이 감사하게도 부족한 리더의 소양을 가진 나를 잘 따라주었다. 그 덕에 프로젝트를 성공적으로 마무리 할 수 있었다. 

 

부족한 유저스토리 작성

 

소프트웨어 개발 및 제품 관리에서 사용자 스토리는 소프트웨어 시스템 기능에 대한 비공식적인 자연 언어 설명입니다
-wiki-

유저스토리는 우리가 개발하고자 하는 프로젝트에 대해서 사용자들이 ~ 할 것이다. 라고 짜는 방식을 의미한다.

 

처음 유저스토리를 짤 때는 과연 이게 중요한 부분인가? 라고 생각했을 때 그다지 라는 생각을 가지고 있었다. 그렇기에 유저스토리를 제대로 적지 않고 바로 개발에 몰두하려고 했었다. 멘토님들에게 유저스토리에 대해 부실하다는 피드백을 받은 후 다시 상세하게 작성을 해 나갔 다. 유저스토리를 자세하게 적을수록 내가 어떠한 기능을 개발해야 겠다 라는 부분이 명확해짐을 깨달았다. 자세한 유저스토리 덕에 앞으로 어떠한 걸 개발해야하는가를 생각하지 않고, 쭉 개발에만 몰두를 할 수 있었다. 

 

마무리

프로젝트 중반에 뒤집어 엎었던 프로젝트는 처음이었다. 

그만큼 우여곡절도 많았고, 배울 점도 많았던 프로젝트였다.

이번 프로젝트를 통해 앞으로 어떠한 방식으로 협업을 해야하는지 명확하게 알 수 있었고, 어떠한 부분에 우선순위를 두어야 하는지, 팀 프로젝트 시 어떠한 방식으로 역할을 분배해야 하는지 깨달을 수 있었다. 

이번 프로젝트를 통해 배운 것을 토대로 조금 더 나은 개발을 할 수 있는 개발자가 되기 위해 노력하겠다.