종합프로젝트-아이북좋아_후기

아이북조아

3줄 요약

• 처음 구현하는 기능이라도 페어가 있으면 할 수 있다.
• 개발자는 개발 실력보다 작성하고 설명할 수 있는 실력이 더 중요하다.
• 상을 타고 싶으면 상을 타기 위해 노력해야한다.

지금 교육중인 LG U+의 유레카 과정에서는 큰 프로젝트가 2개가 있다. 그 중 종합프로젝트 회고를 해보려고 한다.

 

기간 : 2024.10.15 ~ 2024.11.04 (3주)

팀원 : 전원 백엔드 6명

구현 기능(제시된 세부 과업)

• 자녀 성향 진단 시스템
• 콘텐츠 추천 시스템
• 선착순 응모 시스템

 

1주차 (10.15 ~ 10.18, 4일)

이번 프로젝트는 3주간 진행되었고, 처음 기획부터 테스트까지 모두 진행해야했다.

따라서 기획과 설계단계를 최소한으로 진행했다. 개인적으로 기획, 설계를 대충하고 프로젝트를 진행하고 ERD를 수정할 때 매우 힘들었던 기억이 있었어서 최대한 꼼꼼하게 진행하려고 했던 것 같다. (우리 조가 다른 조에 비해 몇시간~1일 정도 더 진행한 것 같다.)

 

기획서작성, ERD 생성, 개발 내용 분배를 진행했고, 이번 팀에서는 수업시간에 진행했던 페어 프로그래밍과 컨벤션(규칙)을 정하는 새로운 경험을 했다.

 

1. 페어 프로그래밍

페어 프로그래밍은 말 그대로 2인 1조, 3인 1조가 되어 같이 한 기능을 구현하는 방법이다. 지금까지는 각자 1개 기능을 담당해서 개발했고, 다같이 합치는 과정으로 진행되었다. 하지만 이번에는 개발기간이 짧기도 하고, 세부 과업내용이 백엔드적으로 6개가 동시진행이 어려워서 개발하고 싶은 기능이 겹치기도 했다. 그래서 원하는 기능이 겹치는 팀원과 페어를 맺어서 페어 프로그래밍을 진행하게 되었다.

 

결론적으로 페어 프로그래밍은 성공적이었고 매우 만족했다.

 

최우수상을 탔을 뿐더러 만약 내가 페어를 맺지 않고 혼자 인증인가, 이벤트 기능을 구현했더라면 시간안에 다 구현하지 못했을 것이라는 확신이 든다.

 

내 페어들은 본인이 맡은 일을 절대 미루지않았고, 어떻게든 끝내려는 사람들이었다. 모르는게 있으면 서로 스스럼없이 물어봤고, 물어본 내용에 대해서는 니꺼내꺼 없이 최선을 다해 같이 해결하려고 했다. 이런 사람들과 페어하는게 너무 감사했고 스스로도 도움이 되려고 노력했다.

 

2. 컨벤션 작성

우리 조에는 팀 규칙과 함께 컨벤션이 존재했다.

지금까지는 개발하면서 파일명을 맞추고, PR을 날릴때마다 title을 정하듯이 미리 규칙을 만들지 않았다. 조직적이지 않았다.

 

이번 조에서는 컨벤션을 자연스럽게 작성하고 지키는 팀원이 있었다. 생소하고 처음보는 규칙은 아니었지만, 확실히 문서화하고 설명을 들으니, 개발할때도 컨벤션을 지켰는지 한번 더 확인하게 되고, 다름 팀원의 코드와 병합했을 때도 확인하기 쉬웠다. 

 

컨벤션을 작성하는 중에 하나 기억나는게 있다면, DTO 클래스 명을 정할 때이다.

이 DTO 클래스 명을 정하는데 

• dto를 붙일건지 말건지
• 내부 클래스를 넣을건지 말건지
• request/response를 붙일건지 말건지, 붙인다면 response가 필요없는 dto는 어떻게 할건지

등등을 고려했다. 

 

지금까지 저 파일명 하나를 정하는데 3분도 안걸렸던 경험을 생각하면 꽤 충격적이었다. 이런 디테일 하나하나가 팀원의 실력을 높이 평가하게되는 요인이 되었다.

 

 

2,3주차 (10.19 ~ 11.03, 16일)

모든 기획과 설계가 끝나고 나선 개발, 개발, 개발이었다.

이번 요구사항은 크게 필수사항과 선택사항으로 나뉘었는데, 우리조는 먼저 필수사항을 페어로 진행하고, 그 후에 시간이 남으면 선택사항을 페어로 진행하기로 했다.

 

하지만, 대부분의 팀이 선택사항까지 진행한다는 소식을 듣고 평일9-6 교육시간이외에 새벽 3-4시, 주말을 풀로 개발하게 되었다.

나뿐만 아니라 대부분 팀원들이 힘들고 예민했을 것이다. 그럼에도 매일 강사님께서는 우리조 분위기가 매우 좋다는 피드백을 해주셨다.

1.  데일리 스크럼

우리조는 매일 아침에 6명 전원이 함께 데일리 스크럼을 진행했다. 아침이어서 힘들텐데 항상 웃으면서 팀원들 한명한명 안색?을 살피던 팀원을 중심으로 다들 노션에 오늘 할일, 간밤에 있었던 이슈등을 작성했고, 무조건 말로 설명했다.

(안그래도 아침이라 텐션올려야할 상황에서 나 피곤하다고 좀 수동적이었던 내 모습이 지금은 좀 후회스럽다.)

 

이 과정에서 다들 정신도 좀 깨고, 리셋하고 페어프로그래밍을 진행할 수 있었던것 같다.

 

2.  게더타운

9-6사이에는 줌에서 제공되는 소회의실에서 페어프로그래밍을 진행했다. 하지만 그 이후부터 새벽까지 페어프로그래밍을 하기 위해서는 다른 공간이 필요했다. 우리조는 디스코드보다는 유레카에서 제공해주는 게더타운에서 함께했다.

 

특히 로그인부분을 구현할 때 내 페어와 함께 거의 매일 게더타운에서 같이 있었다. 거의 동지였다.

 

3. PR 및 코드리뷰

지금까지 나한테 코드리뷰는 "확인했습니다." 끝이었다. 나 코드올릴거니까 너 코드 올릴거면 풀받아 이정도 의미였다.

다른사람에게 코드리뷰를 받아본적도 적었고 내가 코드리뷰를 적은적은 없었다. 왜? 코드보고 뭐가 잘못됐는지 모르니까.

 

이번 조에서는 코드리뷰를 기깔나게 잘해주시는 팀원들이 있었다.

 

잘못된 점을 찾기도 어려운데 거기에 더불어 쓸모없는 코드가 있으면 그것에 대한 피드백이 들어왔다.

피드백을 받으면서 코드를 작성할때, 코드를 올릴때 모두 한번 더 검토하게 되었다.

어떻게 이런 코드리뷰를 할 수 있냐는 질문에 그저 나보다 코드를 더 많이 봤을 뿐 대단한게 아니라는 답변을 해주신 대단하신 팀원들이었다.

 

마지막 마무리_발표, 시연영상

모든 팀플이 그렇듯, 발표는 총대매는 사람이 있어야한다. ppt 자료조사는 다같이 해도 결국 최종 ppt는 누군가 시간과 손가락을 갈아 넣어서 만들게 되어있다.

 

이번 ppt와 발표는 내가 아닌 다른 팀원이 맡았다. 발표자료와 발표를 보면서 느낀점은

1. 모든 팀원이 기능 하나하나를 어떻게 만들었는지 아는 입장으로서 ppt장수를 줄일 수는 없었던거같다. 대신 가독성을 높혔다.
2. 가독성이라고 하면, 글수, 줄바꿈 뿐만아니라 적당한 사진, 적당한 폰트, 적당한 색상이 있어야한다.(가장 어려운 단어. 적당히)
3. ppt를 모두 읽는게 아니다. 강조하고 싶은 부분은 ppt가 아니라 발표의 시간으로 구분한다. (강조할 내용에 시간투자)
4. 발표톤은 존재한다. 발표 말투도 존재한다. 설득력은 여기서 시작하는 것 같다.

나는 내가 맡은 부분 ppt자료조사와 시연영상 제작을 맡았다.

 

이또한 결과론적이긴 하지만, 상을 받으려면 상받을 짓을 해야한다.

 

저번 해커톤에서 느낀 점은 아무리 뛰어난 기술분석과 꼼꼼한 테스트를 진행했어도 결국 사람은 눈에 직접 보이는 것을 더 잘 기억한다는 것이다.

몇백만원짜리 해커톤도 그랬는데, 겨우 교육내 프로젝트1에서 기술과 테스트의 뛰어남으로 순위를 매기기 힘들것이라고 생각했다.

 

그래서 시연영상만큼은 우리조가 제일 튀게? 만들어야겠다고 생각했다. 그래서 우리조는 클로바 AI를 사용해서 tts로 만들었다.

계속 듣다보면 좀 이질적이고 ai라는 느낌이 강하지만, 처음이자 마지막으로 듣게 될 심사위원과 다른 팀들을 생각하면 이만큼 뇌에 박아줄만한게 없었고 잘 통한것같다.

 

추가로 다음에도 시연영상을 만든다면 

• 시연영상 + 발표로 설명 : 미리 준비를 잘해야할 것같다. 정리가 안되면 집중이 안된다.
• 시연영상 + 더빙 : 상당히 또박또박말해야하고, 영상배속은 괜찮지만 더빙 배속은 상당히 힘들었다.
• 발표자가 2명이라면 조금더 계획적이고 똑똑한 전략으로 진행해야한다.(다량의 연습 필수)

이 3가지를 참고해서 진행하고 싶다.

 

 

결론

이번 프로젝트도 인복이 미쳤다. 항상 팀 프로젝트를 할 때마다 내가 부족했던 점, 아쉬운 점을 계속 느끼고 있다.

 

다른사람들에게 설명하고 질문하는 능력을 꼭 길러야겠다고 생각했고, 다음 프로젝트에서는 몰라도 적극적으로 코드리뷰를 진행할 것이다.

또한, 최종융합프로젝트에서 상받기 위한 짓은 뭐가 됐던 해볼 생각이다.