🚀 [프로그래머스 백엔드 데브코스] Space Club 최종 프로젝트 회고

리팩토링을 진행할때의 내 심정..

진행한지 꽤 되었지만, 늦은 프로젝트 회고를 진행해 보려고 한다.

늦게 진행하는 이유는 조금씩 리팩토링을 진행한게, 이제서야 거의 끝맺음을 지은 것 같기 때문이다.

1️⃣ 프로젝트는 어떤 프로젝트였는지?

https://github.com/Space-Club/Backend

GitHub - Space-Club/Backend: Backend Repository For Space Club

누구나 동아리를 쉽게 만들고, 관리하며, 행사를 주최할 수 있는 서비스를 만들었다.

https://spaceclub.vercel.app(지금도 사용가능할 것이다.. 아마?)

위 사이트에서 사용할 수 있는데, 기획의도는 괜찮다고 생각했다.

보통 대학생들이 동아리 주점을 개최하더라도, 홍보는 에브리타임을 통해서 진행하고, 폼 작성은 구글 폼을 사용하는데, 사람이 많이 몰리는 선착순 기능을 구글폼은 제공하지 않는것으로 알고 있기 때문에, 괜찮은 가치가 있는 프로젝트라고 생각했다.

 

2️⃣ 어떻게 진행했는가? 🤔

솔직히 이렇게 제대로된 프로젝트 경험을 하는게 처음이라, 되돌아보면 정말 힘들기도 했지만, 재밌기도 했다.

백엔드 팀규칙

위와 같이 매 스프린트때 마다 팀 규칙을 세워 진행해 나가기도 했고,

총 11차례의 스프린트를 거치며 회고를 진행하기도 했다.

스프린트 기간은 짧게 잡아 최대한 빠르고 타이트하게 개발 진행을 할 수 있도록 했다.

짧게 스프린트를 10차례 이상 가져가니, 프로젝트 기간동안 핫식스와 같은 에너지드링크를 달고 살았고, 나중에 프로젝트가 끝날 시점에는 진짜 내가 좀비가 된 것 같았다. 

그 결과 60개 가까운 api를 뽑아냈고, qa를 진행하면서 다른팀보다 완성도 있는 결과물을 낸 것 같기도 하다.

(API docs: https://space-club.site/docs/index.html)

기술공유 문서의 일부

기획서부터, 개인일정 관리까지 비동기적으로 소통할 수 있는것을 최대한 지향했기 때문에, 기획서부터 개인 일정까지 모든 내용들을 투명하게 공유했다.

백엔드 기술 공유를 통해 새로운 기술을 학습하고 프로젝트에 적용하려고 한다면, 팀원들이 이해할 수 있게 공유하기도 했다.

문서화가 생명이라고 생각했고, 일주일에서 두번정도 만나는 요일을 제외한 모든 날들은 각자의 주둔지(?)에서 개발을 진행했기 때문에 슬렉과 지라를 통한 비동기적인 소통의 중요성을 알고, 적응하려고 노력했던 것 같다.

이 시간은 와글와글이라 했다.

아침 늦잠 방지를 위해서, 그리고 다른 프로젝트를 진행하는 팀원들의 기술을 엿보기 위해서 멘토님이 아침에 다른 팀과 진행사항 공유하는 시간을 가지라고 했는데, 다른 팀의 문제를 함께 해결하고, 내가 진행하는 개발에 대한 고민들을 공유하면서 기술적으로 많은 고민을 하는 시간이기도 했다. (제대로 진행안해서 멘토님한테 많은 혼이 났기도 했는데, 지금 생각해보면 그것조차 그립고 추억인것 같다)

 

3️⃣ 협업을 통해 배운 것

프론트와 협업하는 부분에서도 많은 것을 배웠는데, 떠오르는 것을 써 보자면 다음과 같다.

1. API는 도메인 담당자들 끼리 지라로 소통하자. 그리고 최대한 진행사항을 투명하게 공유해 협업에 차질이 나지 않게 하자.

2. 소프트스킬의 중요성. 

3. 하나의 컨트롤러당 필요한 메서드는 4~5개 정도밖에 안된다. (create, get, getAll, update, delete). 기능 구현 시 백엔드 api 여러개를 조합하는 방식으로 프론트에서 기능구현할 수 있도록 타협점을 찾고 설득하자. 프론트에 모든 것을 맞춰준 개발은 컨트롤러를 괴물로 만든다.

 

개인적인 인격적인 부족함에 대해서도 스스로 많이 느끼고, 자책하기도 했던 것 같다.

먼저, 내가 모든 것을 알고 팀을 리드할 수 없다는 것에대한 괴로움이 컸다. 내가 이런 경험이 많았다면 좀 더 착착 진행할 수 있었을 텐데.. 하는 아쉬움 말이다.

나도 이런 제대로된 협업 경험을 하는 프로젝트가 처음이였고, 다른 팀원들도 마찬가지였을 것이다. 그래서 좀 아쉬움이 남는다.

기술적인 것에 대해서 아쉬움도 있지만, 내가 좀더 팀원들과 소통을 잘 할걸, 더 좋게 대할걸 하는 아쉬움 말이다.

 

중간에 예비군이 있어 4일정도를 개발하지 못한 기간이 있었는데, 그때 스스로 예비군 다녀오니 힘들기도 해서 코드리뷰도 제대로 안하고, 개발도 거의 못했었는데, 그 기간동안 좀 더 힘을 내서 책임감있게 할 걸이라는 생각이 든다.

 

그때 내가 너무 지쳐서 이걸 사람들이 사용하지 않을 것 같은데 무슨 의미가 있는지 잘 모르겠다고 솔직하게 팀원들에게 이야기한 적이있는데, 결과적으로 봤을 때 팀원들의 사기또한 떨어뜨리는 행동이였던 것 같고, 되돌아 보면 좀 책임감 없는 언행이였던 것 같아 후회가 되기도 한다. 하지만 팀원들에 이끌려 어떻게든 프로젝트를 끝냈으니 돌아보면 팀원들에게 고마울 따름이다.

 

4️⃣ 프로젝트의 결과..

그래서 우리 팀 프로젝트는 어떻게 되었냐고?

프로젝트 발표 전 일단 기능을 하는게 중요했기 때문에, 최대한 버그없이 돌아가게 만드는 것이 중요하다고 생각했다.

5차례의 QA를 대면으로 진행했고, 버그없는 서비스를 만드는데 집중했다.

 

따라서 코드 퀄리티 보다 각자 맡은 도메인에서 맡은 기능 구현에 집중했던 것 같다.

그 결과, 발표 시 다른 데브코스 팀원들에게 우리 프로젝트를 소개하고 사용하게했다. 40명이 넘는 유저가 가입해서 사용했고, 피드백을 받았다.

 

프로젝트 발표가 끝나고, 팀원들도 지쳤고 나도 지쳤었다.

12월 데브코스가 끝나고, 한 2주동안은 진짜 쉬어도 쉬는 것 같지 않고, 불안했다. 기억도 잘 안난다.

무너진 수면패턴으로 불면증도 와서 아침 해가 뜰때까지 잠이오지 않았던 것 같다.

README도 작성하지 않고, 그냥 내팽겨치고 그렇게 우리 프로젝트는 끝이 났다.

 

5️⃣ 추후 ...

정신을 차려보니 1월, 나는 이 프로젝트를 이렇게 마무리 짓고 싶지 않았다.

기능 고도화도 충분히 못했고, 하고싶은 것들을 아직 못했다 생각했기 때문이다.

인프라를 내가 맡지 않아 인프라에 대한 이해도 부족했고, 전체 프로세스를 이해하는 것이 아닌, 내가 맡지 않은 부분에 대해서는 이해가 부족했다.

그래서 프론트 팀원 한 분과 덧붙히고 싶은 게시판 기능을 추가적으로 만들고, 나는 개인적으로 고도화 작업과 리팩토링 작업을 진행했다.

모니터링 환경을 구축하고, 프로젝트 전체 도메인에 대한 이해를 하고자 노력했고, 어느정도 하고싶은 것들은 괴로움을 꾹꾹 눌러담으며 진행했고, 완료했다.

 

6️⃣ 리팩토링을 하면서 느낀 점 / 아쉬운 점

1. DB - CS의 기본기의 중요성

DB에 대해서 팀원들이 익숙하지 못했던 것 같아 테이블 설계 과정에서 아쉬움이 많이 남는다.

프로젝트 시작 전 or 적어도 첫 번째 스프린트 끝날 때에는 DB 테이블 정규화를 통해 테이블 분리가 이루어졌어야 했다.

그리고 그것들을 팀원들이 전제 공유를 하고 중복되는 컬럼이 없는지, null 값이 안들어가게끔 테이블 설계를 할 수 없는지, 정규화 대신 비정규화를 하는 방식이 왜 더 나은지 등 충분한 논의가 이루어졌어야 했다.

 

 

2. 책임감

프로젝트는 기간안에 끝내는 것이 가장 중요하다.

멘토님들이 항상 말 했던 것이고, 스프린트를 성공적으로 끝내는것에 포커스를 맞추어 마감을 맞추는 것이 가장 중요하다.

 

프로젝트가 끝나고, 나는 개발자는 자기 프로덕트에 대해서 끝까지 완성도를 책임지는 사람이 되고 싶었다. 이대로 내팽겨치기에는 너무 아쉬운 부분이 많았다.

 

프로젝트가 끝났다 해서 미완의 상태로 프로젝트를 남긴다거나, 제대로 동작하지 않는 부분이나 문제가 있음에도 마감이 끝났고 기한을 못맞췄다고 그냥 내팽겨치는 것은 내 성격상 받아들이기 힘들엇다.

 

그래서 내 코드에 자아를 너무 투영시켜서도 안되겠지만, 특정 퀄리티까지 반드시 완수는 시키는 사람이 되고 싶었다.

 

3. 비전공자라고 기죽지말기!

진짜 컴공을 졸업한 사람들과 협업하는, 제대로된 첫 프로젝트였다.

나는 팀원(프론트 + 백) 중 유일한 비전공자였고, 컴공 졸업생들과 함께 하는 프로젝트에서 주변들로 부터 배울 것이 많을것이라고 생각했다.

그래서 사실 내 의견을 필사적으로 피력하기 보다는, 다른 사람들의 개발 스타일이나 방식을 존중하면서 크게 터치를 하지 않고 개발 했던 것 같다. 사실 누군가 나를 좀 이끌어 주길 바랬던 것 같다.

 

하지만 냉정하게 프로젝트가 끝난 시점에서 돌아본다면, 내가 수동적이면 안되었다.

아닌건 아니라고 말할 수 있어야 했고, 더 나은 방식이 있다면 설득하기를 피해서는 안되었다.

물론 주변의 사람들이 뛰어나 내가 배울점이 많고 따라가기만 한다면 더없이 좋겠지만, 디폴트는 의존할 사람이 전혀 없는것이여야 한다.

 

물론 전공자 중에서도 뛰어나고 진짜 레벨이 다르고 배울 점이 많은 사람들이 있다.

하지만, 나도 생명과학을 전공했지만 생명과학에 대해서 잘 모르듯 너무 큰 전공자에 대한 환상은 접어두는게 필요한 것 같다. 대부분의 사람들에게는.

 

 

4. 모든것은 하고 나면 별거 아니다

CI CD, 인프라 부분은 클론프로젝트 때도, 최종프로젝트때도 모두 내가 맡지 않았다.

DevOps 쪽에 관심있는 팀원과 이미 프로젝트를 통해 CI/CD 경험있는 팀원이 있어 최종프로젝트까지 모든 인프라 부분을 책임졌다.

 

리팩토링을 진행하면서 기존 인프라 구조를 이해하고, 개편하는 작업을 진행했다.

솔직히 인프라 쪽이라 하면 엄청 복잡해 보이고, 나는 범접하기 힘들어 보이지만, 막상 하고나면 별것 아니라는 것을 느꼈다.

개발이라는게 엄청난 머리를 가지고 있어야 하는 것은 아닌것 같다.

 

그것 보다 개발하는데 중요한 덕목이라고 한다면, 끝까지 문제를 포기하지 않고 물고 늘어져 해결하는 그 끈기.

문제가 어디서 발생했는지 찾고 끝내 해결해 내고야 마는 인내심과 참을성.

뛰어난 두뇌보다 그러한 가치들이 더 중요한 것이라고 생각한다.

 

그러니 참을성과 끈질김으로 계속 밀어 붙이자. 그리고 좀 자신감을 가지자

 

5. 심리적 안정감의 중요성

심리적인 안정감의 중요성을 요즘 느끼고 있다.

원래 나는 불안감과 부정적인 생각에 대해서 별 생각이 없었다. 너무 긍정적인 것을 오히려 부정적으로 봤었다.

하지만 최근 느낀 것이 불안감과 부정적인 생각은 삶에 독소 같은 것이라는 생각이 든다.

심리적인 안정감을 깨고 마음이 불안한 상태에서는 좋은 성과가 나올 수 없다는 것이 내 결론이다.

 

프로젝트를 진행할 때, 나는 말 그대로 혼돈의 상태였다.

두 달 동안 진행되었지만, 팀원들과 협업하면서 몰아닥치는 지라 티켓을 쳐내기에 바빴던 것 같다.

그때는 몰랐는데, 리팩토링을 하면서 느낀 점이 아... 이런 더 좋은 방법이 있는데 하는 것들이 너무 많았다.

다음 프로젝트를 하게 된다면, 좀 마음의 안정을 취하고 넓은 시각에서 바라보면서 기능 구현에만 너무 매몰되지 않아야 겠다는 생각이 들었다.

그냥 정리하자면, 프로젝트가 첫 프로젝트라 미숙했다.

 

또한 스스로 돌아보자면, 말을 곱게 해야 겠다는 생각이 들고, 실수를 하더라도 비난하고 공격하는게 아니라 같이 협업하고 편안한 환경을 만드는 능력을 키워야 겠다는 생각이 든다.

그러기 위해서는 개발 실력, 팀을 리딩할 수 있을 만큼의 개발 실력이 우선되어야 할 것이고, 팀원간 마찰이 생길 경우 팀원을 비난하고 공격할 것이 아니라 나랑 안맞는 팀원이라도 같이 조율 해 나가는 것이 필요할 것이다.

 

내가 팀에 안정적인 분위기를 형성하진 못해도, 적어도 나 때문에 팀 내의 안정적인 분위기가 깨져서는 안되는 것을 목표로 해야겠다. 

그러기 위해서는 내가 더 정신적, 신체적으로나 단단해지고, 개발 실력도 뛰어아야 할 것.

 

그리고 나는 성격상 내가 리드하는것이 마음편하기에, 다음 프로젝트를 진행하면서 협업해야 하는 상황이 생긴다면, 최대한 편안한 분위기를 팀내에 만들고 싶다. 그리고 그럴만한 역량을 가지기 위해서 더 노력하고 싶다.

다들 고생했다! 내 스스로에게도, 다른 팀원들에게도.