[Java 풀스택 개발자] 팀 프로젝트:프로젝트를 마무리하며

 

0. 들어가기 전에

먼저 3주간 블로그를 쓰지 못한 이유는 간단하다. 프로젝트가 마무리 작업에 들어갔기 때문이다. 그 3주간은 블로그는 물론이고 다른 무엇도 제대로 하지 못했다. 오로지 깃헙에 잔디 색이 짙어질 뿐이었다.

 

5월 말부터 짙어지는 잔디를 보자

 

개발을 마무리하고 프로젝트 발표 준비에도 시간이 걸렸었다. 내가 발표 담당이었기 때문에 더더욱. 그래서 결국 3주 간 블로그를 관리하지 못했다. 바빴다고 해도 이렇게까지 블로그를 관리 못할 줄은 몰랐다. 물론 블로그를 쓴다고 해도 딱히 쓸 말은 없었을지도 모른다. 프로젝트의 개발 관련된 부분은 거의 마무리되어서 더 쓸만한 기술적인 내용이 없었기 때문이다. 아쉽게도 그래서 이번 회고에서는 [기술] 자체 보다는 [개발자]가 프로젝트를 마무리하는 과정에 대해서 담아둘 예정이다. 이론적인 이야기보다는 실전의 회고에 가까운 내용이기 때문에 참고 바란다.

 

1. 멘토링

일단 6월 13일에 3차 멘토링을 받았고, 이게 멘토링의 마지막이었다. 이 과정에서 우리는 백엔드와 프론트엔드를 거의 완료할 필요가 있었다. 그래서 6월 13일까지 매우 많은 양의 PR을 하게 되었다. 프론트엔드 백엔드 합해서 총 74회의 PR을 거쳤고, 백엔드 마무리과정에서는 그날 자정까지 계속 코드를 건드렸던 기억이 난다.

 

6월 7일부터 6월 12일까지를 기록한 수행일지에서의 횟수.

 

 

백엔드 빌드 마지막 날 6월 6일 0시 6분에 PR을 올렸다.

 

이 상태에서 ppt를 준비하려고 하니 매우 급해질 수밖에 없었는데, 덕분에 좀 엉망이었다. 지난 멘토링에서 받았던 피드백 내용은 그대로 적용했지만, 좀 더 갈무리 할 수 있었을 텐데도 거의 불가능에 가까웠다. 그래도 멘토링 분위기는 나쁘지 않았는데, 몇 가지 피드백에 대해서는 다음과 같았다. 모든 피드백을 담지는 않았다.

 

• 메타태그 관련된 시간이 너무 길다
• 당분간 보지 않기 해버리고 해당 상품 충동 구매를 해버렸는데 해당 부분에 대해서 해당 상품을 추천 상품에 보여줄 것인가?
• 각자 어느 역할을 맡았는지 아키텍처 구성도 넣어주면 좋을 거 같다
• 콜라보 필터링을 생각해 보았는가
• 점수 기준이 좀 더 객관적인 자료가 있으면 좋겠다

 

특히 가장 많이 이야기를 들었던 건 "복지몰"이라는 부분이었는데, 이 부분에 관하여 많은 피드백이 있었다. 그래서 우리 팀이 정한 것은 바로, 복지몰이라는 키워드를 제외하자는 것. 이 복지몰이라는 키워드가 우리 프로젝트의 핵심과 떨어져 있음에도 멘토분들께서 그부분에 대해서 집중하시는 부분이 없잖아 있어 이 부분이 우리 기능을 어필하는 것에 방해된다고 판단했다. 이렇게 복지몰을 제외하고 30대 및 40대 직장인을 중점으로 한 쇼핑몰로 바꾸었다. 실제로 발표에서는 그 수정이 매우 좋았던 듯하다.

 

그 외에도 들었던 피드백들에 대해서 수정 처리를 했다. 1. 발표에서 과감히 메타태그에 관한 설명 비중을 줄이고, 2. 실제 예를 들어 우리 시스템에 대한 이해를 높이며 3. 당분간 보지 않기에 관한 피드백을 반영하여, 당분간 보지 않기 후 장바구니, 구매 등의 행위를 하면 당분간 보지 않기가 해제되는 형태가 되었다.

 

콜라보 필터링에 대한 부분 관련해서도 Q&A를 대비하여 발표에 넣었는데, 이 부분에 대해서는 아쉽게도 질문이 오지 않았다.

 

콜라보 필터링 관련한 우리 서비스와의 비교

 

2. 전반적인 마무리 작업

사실 내 파트에서 백엔드 관련한 부분은 앞서 포스트들에서 알 수 있듯 Redis 등을 사용하는 것이고, 백엔드가 대부분이라 프론트엔드에서는 내 비중이 적은 편이다. 그래서 백엔드에서는 설계 등 때문에 많은 고민을 했던 반면에 프론트엔드는 일이 크게 없어 다른 팀원의 일을 가져다가 작업을 했다.

 

당시 내 프론트엔드 PR. 담당하기로 한 메인 외에도 상품 정렬, 리뷰 처리, 일부 버그 등에 대해서도 작업했다.

 

이렇게 마무리된 뒤에는 UI 및 UX를 본격적으로 손보았다. 퇴소한 팀원의 작업물을 전체적으로 수정하는 과정이었는데, 안타깝게도 팀원의 작업물은 우리 규격에 맞지 않았고 API 연결에 친화적이지 않았다. 수고한 팀원의 작업물을 건드리는 것에 대해 고민이 많았지만, 우리의 방향성에 맞춰 수정하는 것에 더 초점을 두기로 했다.

 

 

이럴 때마다 프론트경험이 이 부트캠프에 들어오기 전에 있어서 다행이라고 생각한다. 전반적으로 우리 프로젝트의 방향성에 맞춰 바꾸었고, API와의 연결을 마무리했다. 말은 이렇게 간단하게 했지만 이 과정은 약 3일이 걸렸고, 그만큼 깔끔하게 작업물이 나타나 다행이라고 생각한다.

 

그 외에는 자잘한 버그를 수정하거나 하기도 했고, 조장이 CI/CD 자동화를 통해 서버와 동기화하여 마지막 테스트를 거쳐 확인을 했다.

 

배포했다고 해서 개발이 끝나는 건 아니다. 오히려 디버깅의 과정이 생긴다

 

슬프게도 시간으로서는 최선이었지만, 완전한 최선의 빌드라고 할 수는 없었다. 좀 더 고칠 수 있었다면 고칠 수 있었겠지만… 나는 발표 준비를 해야했고, 이 때문에 아쉽게도 빌드는 여기서 마무리 되었다.

 

3. 결전의 날

이후부터는 프로젝트에 대한 발표 원고와 발표 자료로서 PPT, 그리고 시연 영상을 작업했다. 약 6일 동안 이 작업을 진행했던 걸로 기억하는데(더 길 수도 있다), 그동안에는 주말에도 제대로 쉬지 못하고 작업을 했던 기억이 난다. 쉴 수 있는 날에는 반드시 휴식을 취하고 무리하지 않는 게 더 효율적인 작업이라고 생각하는 것과는 별개로, 최선의 작업물이 나올 수 있다면 휴식을 다소 반납하더라도 작업을 해야하는 게 나의 나쁜 습관이라면 나쁜 습관일 것이다. 발표에서의 업무량은 그야말로 어마어마했는데, 팀원들이 물리적으로 도와주기는 어려운 대신 많이 신경 써준 기억이 난다.

 

실제로 시연 영상의 경우 대회날 아침까지 편집 작업을 했던 기억이 난다. 참고로, 내 모토는 밤샘은 절대 하지 않는 것이다. 나는 가장 중요한 날에는 적절히 휴식을 취해야 한다고 생각하기에(그래야만 최적의 결과물을 낼 수 있다고 본다) 그날도 밤을 새지는 않았고 발표 직전까지 편집을 이어나갔다. 그렇게 완성된 시연 영상은 7분 20초 정도 되는 결과물이었는데, 시나리오는 약 3개를 사용했다. 이에 맞춰 페르소나도 3개였다. 시나리오 3개를 7분 안에 담는다는 건 사실 그렇게 간단한 건 아니라고 생각했는데, 다행히 편집 덕분에 최대 분량인 10분을 초과하지도 않았다.

 

우리의 발표 시간에는 기한이 있다. 시연영상을 포함하여 20분에서 25분이 우리 발표 시간의 기한이다. 이에 따라 발표 대본과 시연 영상이 적당히 이루어져야 하는데, 발표 당시에 22분 30초 정도를 기록하여 굉장히 중도적인 결과가 나왔다. 이 시간에 대해서는 매우 만족한다.

 

우리의 발표 차례는 두 번째였고, 따라서 앞 조에서의 발표가 있었다. 앞 조에서의 피드백이나 질문을 들으면서 우리의 발표는 어떻게 흘러갈지 생각하고 준비를 했었다. 그러나…

 

Q&A에서 준비했던 내용과 다른 것들이 질문으로 나왔다.

 

이걸 멘붕이라고 말하던가, 딱 그런 느낌이었다. 사실 우리의 발표 자료들은 한번 크게 수정했기 때문에, 이에 대한 궁금증이나 설명이 부족한 부분이 자연스레 다시 등장할 수밖에 없었다. 그런데 그런 부분에 대해서까지는 미처 생각하지 못했던 것이다.

 

발표가 끝나고 이 상태였다

 

다음 조 발표까지 듣고 나서 이런 저런 생각을 했다. 저쪽은 이렇게 발표를 잘하네. 이쪽은 이렇게 잘하네. 프로젝트는 시상이 존재한다. 최우수를 가리는, 이른바 경진대회이다. 최우수를 받는다고 해서 무언가 취업에 도움이 직접적으로 되지는 않고, 상품과 최우수를 받는다는 성취정도였지만 그럼에도 불구하고 최우수를 받고 싶었다. 모든 조가 다 그렇겠지만, 나와 내 팀원이 고생한 만큼의 성취를 갖고 싶었다.

 

그런데 생각보다 질문이나 피드백에서 방어가 준비가 잘 안 되어있었기 때문에, 못 받을 수도 있겠다고 생각했다. 물론 프로젝트는 스스로들 만족하면 된다. 나는 우리 프로젝트가 잘 만들어진 프로젝트라고 생각했기 때문에 크게 멘붕하지는 않았지만, 내 준비가 부족했기 때문에 우리 프로젝트의 매력을 잘 못살리면 어떡할지에 대한 고민이 많았던 듯하다. 실제로 발표 전까지도 내가 아닌 다른 사람이 하는 게 더 최상의 결과를 낼 수 있지 않을까 고민했다. 자기 비하가 아니라, 당시 내 목컨디션이 좋지도 않았던데다 발표 준비를 내가 하고 다른 사람이 발표를 한다면 좀 더 많은 작업을 해낼 수 있을 거라고 생각했기 때문이다.

 

그래서 반쯤 포기하면서 팀원들이랑 열심히 이야기를 했다. 어쨌든 간에 잘 되길 바라며.

 

 

4. 결과

 

우리 조가 최우수상을 받았다. 그러나 다른 조들도 훌륭했기 때문에 치열한 싸움이었다고 한다. 내 고뇌와 걱정이 맞았던 것이다. 그럼에도 불구하고 우리 조가 최우수상을 받아서 정말 기뻤다. 특히 강사님께서 우리 프로젝트를 매우 칭찬해주셨고, 프로젝트 과정동안 응원과 피드백을 많이 주셨는데, 그간 노력을 인정받은 듯해서 좋았다. 사람이 보이는 인정만 좇을 게 아니라 스스로의 마음에서 우러나는 성취와 기쁨을 알아야한다고는 하지만, 솔직히 인정을 받으면 기분이 좋은 것도 맞으니까. 우리 조의 조원들 모두 정말로 기뻐했다.

 

다른 조의 멋진 프로젝트에 대해서는 혹시 몰라 적지는 않겠지만, 다들 부트캠프에서 만들 수 있는 최선의 결과물을 내놓았다 싶을 정도로 퀄리티가 정말 좋았다. 6주라는 적은 시간임에도 이렇게까지 잘 만들 수 있을까? 싶었기도 하다. 그런 조들 사이에서 우리가 최우수상을 얻을 수 있었다는 게 정말로 기뻤다.

 

그리고 마지막으로 수료를 하면서 우수 수료생이 되었다. 만약 우수 수료생 조건이 궁금한 사람이 있을지도 모르니 말한다면, 과제는 매번 내고, 시험은 열심히 공부하고, 출결도 열심히 관리하라는 상투적인 말밖에 할 수 없다. 그러나 6개월 동안 사람이 매번 성실하기도 어렵고, 그 성실함을 무기로 삼을 수 있는 사람은 얼마 되지도 않는다. 우리 부트캠프는 18명으로 시작했다가 9명이 수료했다. 9명 중 몇 명은 취직을 하여 중도퇴소했지만, 몇명은 포기하기도 했다. 개발이라는 직이 안 맞아서도 있겠지만, 이러한 6개월의 과정이 너무 힘들어서 나간 사람도 있을 것이다.

 

그럼에도 하나만 더 조언이 필요하다면 매니저님과 강사님을 괴롭히면 된다. 진짜 괴롭히라는 게 아니라, 궁금한 게 있으면 물어보고, 자신의 성장과 인성에 대해서 어필을 하면 그 누가 평가를 짜게 줄 수 있을까. 나는 실제로 부트캠프생 중에서 가장 많이 매니저님과 강사님을 괴롭혔다고 자부할 수 있다🤣 질문을 자주하고, 밝게 인사하고, 수업에 열심히 참여를 해서 두 분이 더 좋게 봐주신 게 맞을 것이다.

 

사실 나는 주니어 개발자로 시작하기에는 나이가 좀 있다. 개발자는 나이가 크게 중요하지 않단 이야기도 있지만, 큰 기업은 그렇지만도 않다. 비전공자인 나는 길고 긴 길을 돌아 결국 이곳에 와 수료까지 진행했다. 멀티캠퍼스 Java 풀스택 개발자 아카데미에서 긴 6개월을 겪으며, 나는 힘든 일도 많았지만 한번도 개발을 그만두고 싶다고 생각한 적은 없다. 드디어 퍼즐이 맞춰진 느낌이다. 충만한 6개월이었다.

 

덧붙여 TIL도 이걸로 마무리된다. 이 기록을 여기까지 이끌어주신 TIL 담당자님께 감사드린다.