본문 바로가기
개발자 일기/일일회고 (TIL)

Main_Project 회고

by MS_developer 2023. 5. 23.

 

코드스테이츠 부트캠프의 꽃이자 정수, 메인 프로젝트는 가장 길었던 개발 기간만큼 많은 고난과 역경들이 있었다. 

 

하지만 힘들었던 만큼 어려움을 극복하고 나아가는 단계에서는 가히 치사량에 가까운 직업만족도(?)를 얻을 수 있었다. 특히 팀원들과의 끈끈한 유대와 함께 모각코(모두 각자 모여 코딩)를 하면서 나누었던 뜬금없던 이야기들은 생각하는 것만으로도 피식 웃음이 나올 정도로 즐거운 추억으로 남았다.

 

유의미한 결과도 얻었는데, 우리팀은 커뮤니케이션 우수상을 수상했다.

 

코드스테이츠 측은 "기본적인 프로젝트 완성도를 만족하면서, 팀 내 의사소통이 매우 활발하고 생산적이었다. 특히 Github을 사용한 커뮤니케이션이 인상적"이었다고 수상 이유를 밝혔다. 

 

개인적으로도 의미가 큰 프로젝트였다.

 

프로젝트를 진행하면서 "좋은 팀원"이란 무엇인지, "좋은 프로젝트"란 무엇인지 고민하고 나름의 정리를 할 수 있었다.

 

회고를 통해 당시의 내 생각을 정리하고, 기록하고자 이 포스팅을 적는다.


목표

메인 프로젝트의 목표는 부트캠프 수강생들이 관심 있는 분야를 선택하고, 같은 관심분야를 선택한 사람들을 만나 직접 팀을 결성하고 관심분야와 연관된 웹 페이지를 주제에 맞게 만드는 것이었다.

 

 

코드스테이츠에서는 다양한 주제를 선정할 수 있게 관심분야가 세분화된 선택지를 주었고, 이에 따라 각자의 관심에 맞는 다채로운 색깔의 팀들이 결성되었다.

 

우리 팀은 웹 서비스에서 많은 부분을 차지하고 있는 유통/물류 분야를 선택한 사람들 중에서 모여 팀을 구성하게 되었다. 이후 다소 긴 시간의 논의 끝에 "남성 화장품 쇼핑몰"을 프로젝트 주제로 결정하고 진행했다.


1. 제 생각은 다른데요

현재는 프로젝트의 결과물이 마음에 들고 그 방향성이 명확히 설정되어 있기 때문에 만족하고 있지만, 처음 팀을 결성했을 당시 나는 프로젝트의 "주제"에 대해 가장 많은 의문을 표했던 사람이었다. 때문에 "어떤 웹 사이트를 만들까"에 대한 주제로 긴 시간이 소요되었다.

 

코드스테이츠 측에서 제공된 세분화된 분류로 인해 비슷한 생각의 사람들이 모인 것은 맞지만, 내가 생각했던 유통/물류에 관련된 웹 페이지와 다른 사람들이 생각했던 유통/물류에 관련된 웹 페이지는 상이했다.

 

보는 이에 따라 다르게 보이는 그림

사람마다 생각하는 것이 다르니 어찌 보면 당연한 일이 아닐까 싶기도 했다.

 

프로젝트 아이디어는 쇼핑몰과 책 공유/기부/구매 플랫폼 두 개의 의견으로 갈리게 되었는데, 결정하는 과정이 순탄치 않았다.

 

 

책 유통 플랫폼은 mobile-first 개발에 더해 최근 비슷한 성향의 애플리케이션이 애용되는 트렌드가 반영되었지만 4주 프로젝트로 진행하기에 일정이 빠듯하고 완성도가 떨어지면 조잡해 보일 수 있다는 의견이 도출되었다.

 

 

쇼핑몰 웹 사이트의 경우 기존에 존재했던 많은 예시를 참고할 수 있고 사용자에게 익숙한 기능을 구현할 수 있지만 프로젝트의 독창성이나 새로운 시도를 보여주기엔 한계가 있다는 의견이었다.

 

둘 모두 각각의 장단점이 있었기에 갑론을박이 이어졌다.

 

나는 책 유통 플랫폼에 많이 마음이 기울어져 있었다. 때문에 팀의 분위기를 해치지 않는 선에서 조심스러운 말투로 팀원들을 설득하기 위해 노력했다. 해당 아이디어가 가진 장점을 강조했고, 현재 부트캠프 특성상 새로운 것을 시도해 볼 수 있는 기회라고 말했다. 어떤 팀원은 내 의견에 동조했고, 어떤 팀원은 반대했다. 또 어떤 팀원은 양쪽 모두 좋다는 기권표를 내기도 했다.

 

의견 취합이 명확히 이루어지지 않고, 과반수가 결정하지 못하는 상황이 지속되어 회의가 길어졌다. 

 

내 의견이 팀에 도움이 되고 있는걸까?

 

내심 마음에 들었던 프로젝트 아이디어였기 때문에 다른 팀원들은 유도하고 있는 건 아닐까? 나는 조심스러운 말투로 말하고 있어도 다른 팀원들은 그렇게 생각하지 않는 건 아닐까? 그렇다면 다른 팀원은? 그 사람도 아이디어를 유도하는 건가? 내가 지금 생각하는게 틀린 생각은 아닐까? 더 나은 결과물을 가져오기 위해서는 어쨌든 내가 생각하기에 맞는 걸 말하는 게 옳은걸까?

 

복잡한 생각들이 꼬리에 꼬리를 물었고 길어진 회의에 팀 분위기도 조금씩 지쳐가는 것이 느껴졌다.

 

프로젝트 사전 문서 작업 등 앞으로 진행해야 할 부분들이 너무나도 많았기에 이제는 팀의 의견을 일치시키고 나아가야 할 때였다.

 

문득 이전 프로젝트에서 내가 팀장으로 겪었던 어려움들이 상기되었다. 의견 취합과 팀원간의 중재는 당시 내게 큰 부담거리였다. 그만큼 프로젝트에서 신경써야할 부분이 많기 때문이다. 이 점을 고려해 내가 팀을 위해 양보하기로 했다.

 

 

결국 쇼핑몰을 프로젝트 주제로 선정했다. 

 

쇼핑몰 프로젝트 자체도 꽤 매력적인 프로젝트였기도 했고, 책 유통 플랫폼은 새롭게 시도하고 도전해야할 기술들이 많은데 다른 팀원들이 자발적이지 못하다면 완성도가 크게 떨어질 수 있다고 생각했기 때문이다. 무엇보다 서로가 양보할 생각이 없다면 결국 프로젝트가 더 늦춰질 수 있기 때문에 누군가는 포기하는 것이 맞다고 생각했다.

 

나는 "기획자"가 아닌 "개발자"니까.

 


2. 쿠션어의 중요성

JTBC 드라마 "밀회" 中

프로젝트 주제가 정해지고 본격적인 시동을 거는 시점에서 나에게는 한 가지 추가적인 직책을 부여받았다.

 

프로젝트 문서에 대한 전체적인 작성 및 정리를 맡은 "서기" 직책이었다.

 

문서 정리 잘 하시죠? 저 대신 해주세요.

 

사실 좀 당황스러웠다. 

 

코드스테이츠에서 진행중인 프로젝트에서 서기라는 직책은 따로 없었고, 팀의 프로젝트 문서화는 팀장이 맡아 진행했던 역할이기 때문이다.

 

"제가 왜요? 그건 팀장님 역할이죠." 라는 말은 하고 싶지 않았다. 

 

다만 아쉬운 점은 좀 더 부드러운 쿠션어를 사용했다면 좋았을 것 같다는 생각은 들었다.

 

 OO님이 노션 문서 정리를 잘 하시던데, 저희 프로젝트 문서에 대한 작성을 맡아주실 수 있나요?

 

라는 말을 들었다면 좀 더 기분이 좋았을텐데...팀원인 나를 조금 더 존중받는 느낌으로 말해주었으면 좋았을 것 같다.



프로젝트 주제 선정으로 장시간 서로 의견이 오고 간 상황이었기 때문에 모두가 지쳐있었던 점이 어느정도 작용하지 않았나 싶기도하다. 나는 긍정적으로 생각했다.

 

어찌됐든 내가 문서 작성을 잘 할 수 있다는 팀장님의 판단이 있었던 것이고, 이는 나의 능력을 믿고 맡기는 것이라는 의미이기도 했다.

 

팀원의 강점이 무엇인지 알아보고 맡기는 것도 팀장으로서의 역량 중 하나가 아닐까?

 

이전 프로젝트에서 나는 문서화 작업과 커뮤니케이션을 거의 모두 맡아서 진행했는데, 좋은 방법이라고 생각하지 않았다. 나의 의도와 다르게 팀원들을 못 미더워한다고 느낄 수도 있었고, 나도 결국에는 같이 개발을 진행하는 팀원이었기 때문에 더 많은 시간과 노력이 들었기 때문이다. 이러한 부담을 분배하고 팀 전체가 프로젝트에 대한 책임의식을 느끼게 하는 것도 팀장으로서 해내야하는 부분이라고 생각했다.

 

군 복무 중에 응급처치 교육을 들었던 내용 중에 인상깊었던 부분이 있다.

 

응급처치 시에는 누군가를 "지목"하고 필요한 것에 대한 명확한 지시를 내려주지 않으면 다른 누군가가 해줄 거란 생각에 필요한 행동을 해주지 않는다는 얘기였다. 누군가 회의록을 정리하고, 의견을 취합하는 역할이 필요하다면 명확히 역할을 지정해주는 것도 좋다고 생각했다.

 

만약 팀장 역할을 다시 맡게 된다면 팀의 일을 균등하게 분배하기 위해 각자에게 명확한 역할을 부여하는 것이 좋겠다는 생각이 들었다.


3. 정말 진짜 진짜 꼼꼼히 찾아봤나요?

이후에는 일사천리로 진행됐다.

 

팀 문서가 준비되었고, 각자 균등하게 파트를 나누어 진행했다. 

 

 

각자 맡은 페이지를 진행하며 테스크의 단위를 세분화했고, 하나의 페이지 진행에 있어 특정 기능을 구현했다면 커밋 후 PR을 올려 서로의 코드를 리뷰했다. 사전에 논의를 통해 준비한 태블릿에 맞춰 구현한 기능과 공유 사항에 대해 작성하고, 구현한 기능의 gif 파일을 올려 작동 방식을 보다 잘 이해할 수 있게 했다.

 

 

코드 리뷰를 통해 해당 코드에 대한 개선 방안이 있다면 이를 공유하고, 커밋한 코드의 장단점에 대해 의견을  나눈다. 이후에 타당하고 개선이 필요한 부분이 있다면 수정을 통해 추가적인 코드 리뷰를 진행했다. 이 과정을 반복해 PR을 완료한 후 다음 테스크를 진행한다.

 

모든 진행 사항은 매일 지정된 시간에 모여 일일 진척도와 일일 목표를 공유하고, 기록이 필요한 부분이 있다면 서기를 통해 커뮤니케이션 툴(우리팀은 디스코드를 사용했다)을 통해 공유한다.

 

하지만 모든 일이 술술 풀리기만 한 것은 아니다.

 

 

각자의 파트를 진행함에 있어 막히는 부분들이 있었는데, 나같은 경우 주소지 검색 api 사용에 있어 주소지 검색 후 선택 시 전체 페이지가 다운되는 오류를 해결하는데 가장 큰 시간을 소요했다.

 

 

당시 에러코드를 통해 관련된 코드를 모두 확인하며 state값의 오류, 핸들러 함수의 문제점 등 가능성이 있다고 생각한 부분들을 모두 살펴보았다. 하지만 API, 타입스크립, 리액트가 접목된 에러였기 때문에 정확히 어떤 과정에서 페이지 전체를 다운시키는 문제가 발생중인지 쉽게 파악하기 어려웠다.

 

오랜 고민 끝에 멘토링 세션을 통해 멘토분께 도움을 요청했고 함께 해결할 수 있었는데, 의외로 매우 간단한 문제였다.

 

 

답은 API 공식 문서에 있었다.

 

해당 API는 고유 컴포넌트를 사용하여 우편번호 검색 서비스를 임베드 방식으로 사용할 수 있게 해 두었기 때문에 해당 컴포넌트에서 주소지 선택 시 최상위 엘리먼트를 돔에서 삭제(!!)하는 기능이 있었다.

 

즉 해당 고유 컴포넌트 DaumPostCode에 autoclose="false"로 attribute값을 설정해주기만 하면 문제를 해결할 수 있었던 것이다.

 

 

분명 API 공식 문서를 읽어봤고, 잘 살펴보았다고 생각했기에 문서를 다시 "꼼꼼히" 읽어볼 생각을 못했다는 점에서 약간은 억울했다. 하지만 어찌하리, 내가 API 문서에 정리된 기능을 꼼꼼히 읽어보지 않아 정확한 구동 원리를 알지 못했던 것은 명백한 나의 잘못이었다.

 

API 사용에 있어 문제가 발생했다면 공식 문서를 천천히, 꼼꼼히 정독할 것을 다짐했다.


4. 너 운동하면서 코딩하고 있니?

크고 작은 사건들을 뒤로 한 채, 프로젝트는 끝을 향해 달려갔다.

 

대부분 페이지가 완성되었기 때문에 서버와의 통신 문제와 데이터 상에서 필요한 필드값이 누락되었는지 등을 교류하는 과정을 거치고 있었다.

 

이전 포스팅에서 설명했듯, 이때부터 몸에서 적신호가 들어오기 시작했다. 

 

이러한 이상 현상(?)은 나만 겪는 것은 아닌지 팀원들이 코로나에 걸리는 등 프로젝트를 아우르는 잔병치레가 많았다. 

 

고민이 많아졌다.

 

어떻게 해야 건강관리도 하면서 개발 일정을 맞출 수 있을까?

 

결론은 의외로 간단했다.

 

무조건적으로 운동 시간을 보장하면 된다.

 

프로젝트 진행에 있어 어려움이 있는 부분에서 시간이 아까운 것은 사실이지만, 건강 관리에 소홀하면 그 이상의 손해를 보게 되었다. 주기적으로 병원을 찾아야 하는 시간과 컨디션 난조로 인해 일의 효율이 떨어지면 결국 그 이상의 손해를 볼 수 있었다.

 

프로젝트를 마치고 돌이켜 생각해보면, 건강한 팀원은 운동을 꾸즌히 했었다.

 

팀장님은 이러한 시간을 인정하고 일과 시간 이후에 불가피하게 회의를 진행해야 할 경우 각자의 휴식 시간이나 운동 시간을 최대한 보장하면서 일정을 조율했는데, 팀의 효율을 생각한 사려깊은 행동이었던 것 같다.

 


팀장이 아닌 한 명의 팀원으로 보고 느끼다

다른 관점, 다른 시각

프리프로젝트에서 팀장으로서 역할을 수행하면서 "새롭게 시작하는 프로젝트에서는 팀장이 아닌 한 명의 팀원으로서 개발을 경험해보고 싶다"는 마음을 먹었다. 단순히 이전 직책에 대한 부담감을 내려놓고 싶은 것은 아니었다. 팀원으로서의 관점과 생각은 어떠한지 더 자세히 알아야 이후에 팀장 직책을 맡더라도 더 잘 할 수 있는 계기가 될 것이라고 생각했기 때문이다.

 

나를 돌아볼 수 있는 귀중한 경험이었다.

 

내가 팀장으로 느꼈던 나의 부족한 점을 새로운 팀장님이 어떤 식으로 보완하고 있는지, 다른 팀장님은 어떤 식으로 팀과 소통하는지  내가 팀장으로서 아쉬웠던 부분에 대해 어떻게 보완할 수 있을지 참고하고 배울 수 있는 시간이었다. 또, 내가 팀장일 때 가졌던 강점은 무엇인지 생각해 볼 수 있었다.

 

나아가 단순히 프로젝트에 열심히 참여하는 것 외에 "좋은 팀원"이란 무엇인가에 대해 생각해 볼 수 있는 기회이기도 했다.

 

댓글