[Bunddeuk]팀 프로젝트 개발을 마치며.. 회고

Bunddeuk: https://bit.ly/3KMdACS
Github: https://github.com/KhaeMiin/Final_Team_Project

간단한 KPT

Keep

• 회의,약속시간 칼같이 지킴(너무 기본적인 거라 적을까 말까 고민했지만 기본적인 것 마저 안 지키는 사람들이 있었기에)
• 코딩 규칙 세우기(네이밍규치, 기타규칙) (조장님 아이디어)
• 노션을 활용하여 팀 규칙과 일정관리, 진행상황과 회의 내용 등 기록
• 먹고 자고 싸고 코딩하고 무한 반복
• 포기하지 않고 폭풍 구글링을 하여 결국 서버 배포함 (3일을 밤새 붙잡고 했었다..)
• 메인 페이지를 맡은 팀원의 일탈에도 멘탈을 부여잡고 밤을 지새워 완성함(나는 프론트 바보다..그럼에도 포기하지 않고 2~3일 밤을 포기하고 완성하였고 모두에게 박수를 받았다....)
• 철저한 일정관리 덕분에 조금은 일찍 완성하여 여러 번의 테스트를 통해 계속해서 에러를 잡고 수정함.
• DB에 넣을 콘텐츠의 저작권 동의받기(조장님이 직접 한 분 한 분 메시지를 보내서 허락을 구했다고 한다.) *사용을 허락해주신 창작자님들 감사합니다!
• 내 구글링 실력이 많이 늘었다!!! 에러가 나면 일단 구글 검색과 파파고 번역기부터 켜는 것이 이제는 숨 쉬듯 되어버렸다.(어느정도 눈에 익숙해진 에러 메세지들이 늘어났다.)
• 최종 완성일자보다 열흘정도 앞당겨 각자 기능구현 완성을 한 후 테스트를 여러번 진행함(각자가 했을 땐 몰랐던 문제점들이 테스트기간을 통해서 많이 나왔다.) - 그 덕에 최종 발표 시 시연 도중 문제점이 많이 발생한 다른 팀들과 달리 문제없이 깔끔하게 기능을 시연함

Problem

• @Service에서 핵심 비즈니스 로직을 담지 못하고 모든 정보 가공처리를 Controller에서 수행하였다.(스프링에 대한 이해도가 부족하기 때문이다.)
• 허술한 DB 테이블 설계: 모두가 연관성이 있음에도 모두 각자가 아무런 상의 없이 테이블을 만들었다...제약조건도 생각하지 못했고 컬럼명도 공유가 제대로 안 돼서 결국 모든 테이블을 삭제하고 다시 생성하였다.
• 무료 CSS 탬플릿을 가져와서 적용하였지만 결국 사용하지 않았고, 쓸모없는 CSS 파일들만 주야장천 남음(scss??알지도 못하는 파일들이 남았다. 처음에는 무서워서 삭제를 못 했지만 프로젝트가 완성되고 과감하게 쓸모없는 파일들은 다 삭제해버렸다. 그러면서 모든 css가 뒤틀어졌었고 하나하나 복구하는 데에 시간이 꽤 걸렸다.)
• 로그인 시 카카오로 그인 API를 구현하지 못함.
• 밤에는 조금 일찍 자고 아침에 일찍 일어나는 부지런한 패턴을 가졌더라면...
• 서버를 재배포할 때마다 image 폴더들이 초기화됨.(결국,리눅스 환경에 이미지를 올릴 폴더가 필요) → 지식이 너무 없다 보니 좀 더 공부해야겠다.
• git을 제대로 활용하지 못함.
• 이클립스에서 Lombok이 적용이 안 되는 팀원 2명이 있었다. 결국, 방법을 찾지 못함.

Try

• API를 잘 사용하지 못했다. 다음 toy project를 진행할 땐 카카오 로그인API를 꼭 사용해보자.
• 소켓 공부해서 채팅기능 꼭 만들 수 있도록 하자.
• 역할분담 명확하게 하기
• git bash 명령어 공부하기
• AWS S3를 좀 더 공부해서 S3 Bucket 생성 후 이미지 또는 파일을 업로드 하기
• DB테이블 설계 시 컬럼명과 구조는 팀원 모두가 함께 철저하게 세우기(개인 프로젝트를 하더라도 마찬가지)

---

 

 

회고하다(뜻): 지나간 일을 돌이켜 생각하다.

 

학원에서 진행하는 두 번째이자 마지막 프로젝트를 마치게 되었다.

무엇보다 중요한 것이 커뮤니케이션이과 시간 분배라는 것을 알게 되었다.
커뮤니케이션 미스로 인한 시간을 최소화해야 시간을 효율적으로 사용하고 작업 분배도 효율적으로 할 수 있다.

1. 프로젝트 기획과 계획 그리고 목표

우리 팀원 모두가 기획은 빠르고 간결하게, 기능 구현에 더 많은 시간을 투자하자는 공통된 생각 덕분에 쉽게 진행되었다.

각자 개인 시간 동안 모두 꽤 구체적으로 하고 싶은 기능과 벤치마킹사이트,생각들을 정리해왔으며 그저 선생님과 배웠던 단순한 쇼핑몰사이트보다는 모든 면에서 조금은 더 복잡한 기능의 사이트로 기획하였다.

 

초반 팀워크는 꽤 좋은 편이었고 짧은 시간에 세운 기획임에도 꽤 상세하게 계획이 세워졌다.

 

우리의 목표는 완벽한 완성이었다.

 

대부분의 스케줄과 회의내용 등 문서화는 Notion에 기록하였다.
철저하게 완성까지의 일정을 나눠서 짰고, 당연히 경험도 없던 우리들의 계획은 며칠 안가 틀어지기 일쑤였지만 회의 날을 정해 회의를 통해 유동성 있게 스케줄을 다시 조율하기도 하였다.

좋은 조장과 팀원을 만난 덕분에 가능한 일이었다.
우리 팀의 조장은 조장으로서의 역할을 수행하기위해 최선을 다하였고, 미흡한 부분은 나머지 팀원과 함께 다 같이 이끌어갔다.

2. 완벽한 줄 알았던 소통과 문서화

소통은 Notion과 단톡을 이용하여 활발하게 하였고, 우리들의 설계는 완벽하다고 생각하였다.
그러나 프로젝트 시작 후 한 달이 지난 시점에서 처음으로 각자의 기능구현에 대한 시련이 아닌 팀 자체에 일이 터져버렸다.
최종 발표까지 열흘도 남지 않은 상황이었다.

허술한 DB 테이블 설계
문서화의 중요성은 초반부터 모두가 신경을 썼던 부분이다.
그럼에도 특정 중요사항에 대해서 누락이 되었다든지, 규칙이 다르다던 지의 문제가 생겼다.
설계에 관한 내용은 모두가 같이 충분히 협의한 후 한 사람이 최종적으로 문서를 작성해야 전체적인 톤을 맞춰나갈 수 있다. 그런데 이러한 부분을 각 멤버에서 일정 부분 나눠서 할당하니 전체적으로 매끄럽지 않았고, 규칙이 흐트러지는 현상이 발견되었다.

그 부분이 가장 크게 드러난 부분이 DB 테이블 설계였다.
각자가 만든 테이블은 서로가 모두 연관 지어져 있다.
즉, 자신이 생성한 테이블이 전체 DB 테이블에 영향이 미친다는 것이다.
A라는 팀원은 닉네임을 'Nick'이라 쓰고, 또 다른 B라는 팀원은 'id'라 쓰는 현상이 있었다.
이 외에도 제약조건을 고려하지 않은 테이블생성으로 게시글을 삭제 시 게시글에 연관지어 있는 댓글과 옵션들이 삭제되지 않는 등 문제가 연달아 발생하였다.

별거 아닐 수도 있다고 생각했던 부분이 개발할 때 이러한 사소한 단어 차이 때문에 문제가 무수히 발생한 것이었다.
결국 모든 테이블을 삭제하고 DB 테이블 설계를 한 후 다시 테이블을 생성하였다.
(지금 생각해도 머리가 아찔해진다......)

3. 도중 탈주한 팀원 한 명

직설적으로 말하자면 우리 팀은 모두가 실력을 떠나서 Back_end의 성향이 뚜렷한 사람들뿐이었다.

(나포함 프론트바보들..)
웹 자체의 프론트를 맡을 사람이 한 명뿐이었고, 모두 각자의 맡은 부분에 대한 디자인 레이아웃만으로도 충분히 힘들어했다.
결국 팀원 한 명이 메인 디자인 레이아웃(카테고리, 배너, 메인, 푸터) 등 프론트적인 부분을 모두 맡게 되었다.

그리고 최종발표를 열흘 앞두고 이 친구는 자신의 새로운 진로를 위해 떠나가버렸고 (잠적을 하였다...심지어 무료 템플릿을 가져오기만 하고 아무것도 정리가 안된 상태) 우리는 메인화면 레이아웃조차 없는 이 프로젝트를 두고 멘탈이 터질 수 밖에 없는 상황에 부닥쳤다.
사실 조금 불안했던 팀원이라 조금은 예상하고 있었던 일이었다.
처음에는 정말 어떻게 해야 할 지 몰라서 괜히 그 친구에게 원망이 갔었다.
지금 생각해보면 애초에 역할 분배할 때 메인 프론트단 파트를 모두가 조금씩은 나눴어야 했다.

하지만 우리의 완벽한 완성이라는 목표를 위해 다시 비상회의를 열었었다.
나는 그 당시 내 파트의 기능 구현이 거의 끝마친 상황(하지만 테스트를 거치며 생각보다 많은 에러가 나왔다..)이라 메인화면의 전체 레이아웃과 배너,푸터 기타 등등 모든 것을 다시 만들어나갔다.
우리가 벤치마킹한 '텀블벅'사이트를 그대로 구현하고 싶었던 나는 정말 처음부터 시작하였다.
그리고 마찬가지로 기능구현이 거의 끝난 조장님이 메인의 리스트출력 부분을 맡아주었고, 또 다른 기능구현이 끝난 팀원이 검색기능 등 기능적인 부분을 맡아주었다.

결과는 만족스러웠지만, 초반에 역할을 좀 더 철저하게 분해하였다면 이렇게까지 치명타를 입진 않았을 것 같다.

4. 기타 아쉬운 부분

1. 스프링 @어노테이션에 대한 이해도 부족
   대표적으로 @Service에서 핵심 비즈니스 로직을 담지 못하였다.
   모든 정보 가공처리를 Controller에서 수행하였다.
   물론 Service에서 꼭 로직을 담을 이유는 없지만, 나의 경우엔 Service의 기능에 대한 이해도가 없었기 때문에 필요성을 알지 못하고 Controller에서 모든 것을 수행했기 때문이다.
   결국 스프링에 대한 이해도가 부족해서 생긴 문제이다.
2. Git을 제대로 사용해보지 못함
   Git을 제대로 사용해보지 못해서 프로젝트를 진행하는 동안 어려움을 많이 겪었다.
   깃에 대해 조금이라도 공부를 한 사람이라면 금방 해결하는 에러마저 나는 헤매기 일쑤였다.
   (내 브랜치를 생성하는것 부터 나에겐 큰 고난이었다......)
3. 카카오 로그인 API를 구현하지 못함
   로그인 기능 구현은 내 파트는 아니었지만, 조금은 시간적 여유가 있었기에 팀원이 구현하지 못한 부분을 열심히 구글검색 등 찾아보았다.
   하지만 결국 기능을 구현해내지 못하였다.
   먼저 다른 팀원의 코드를 제대로 파악하기엔 내 지식과 팀원의 시간이 너무 부족했다.
   다음 개인 프로젝트를 진행하게 된다면 꼭 구현해보고 싶은 부분이다.

 

이것으로 글을 마치며...

나는 아직 기초가 많이 부족한 개발자라는 것을 프로젝트를 하는 동안 느꼈다.

좋은 개발자가 되기 위해 내 시간을 쪼개고 공부에 투자하여 기초를 더 탄탄하게 쌓아야 할 것이다.

힘들지만 힘들지 않다.

언젠가 좋은 개발자가 되어 지금 이 글을 읽으며 이런 하찮은 시절도 있었구나 하고 웃어보고 싶다.

그때는 정말 좋은 개발자가 되어있길 내 미래에 바래본다.

그동안 현재의 나는 미래의 나를 위해 열심히 공부하자!

 

 

발표영상

https://youtu.be/w9w6OACFT28?list=LL

 

https://github.com/KhaeMiin

KhaeMiin - Overview