#1. 프로젝트에서 나의 역할

 

본론부터 말하자면

팀장을 맡았으며 주문 및 장바구니 기능을 담당했습니다

 

주문과 장바구니는 나중에 코드와 함께 포스팅할 예정이니

이번엔 팀장으로서 무엇을 했었는지 이야기하듯이 말해보겠습니다

 

우리팀의 팀장은 어떻게 선정이 되었을까요?

개발 실력이 좋은 사람? 리더십이 좋은 사람? 대화를 정말 잘 하는 사람?

 

아닙니다

그냥 사다리타기로 뽑았고 

저는 그 사다리타기로 뽑혔습니다

 

사실 이 정도 규모에서 팀장이 그렇게 거창하거나 그런 자리는 아니지만 부담되는 자리이기는 합니다

만약 제가 전공자이면서 프로젝트 경험이 다수 있고 개발 실력도 뛰어나지 않는 이상 말이죠

저는 심지어 사회 경험도 군대를 제외하고는 만무하다시피 했기 때문에 그냥 냅다 걱정만 하게 되었던 것 같습니다

게다가 솔직하게 말하자면 팀장이라는 직함을 달 수 있을 정도로 리더십도 특출나지 않았구요

 

---

 

Q. 그러면 팀장을 못하겠다고 하셨나요? 하더라도 제대로 못하셨을 것 같은데 아닌가요?

그렇진 않았습니다, 결국 제가 놓아버리면 길잡이가 없기 때문에 프로젝트 완성은 해야했거든요

 

만약에 제가 지금 리더십을 키우거나 카리스마 있게 행동해보자와 같이

개인적인 성향에 영향을 많이 받는 걸 바꾸려고 했다면 오히려 더욱 더 안좋아지게 되었다고 말할 수 있습니다

어차피 개인 성격은 쉽게 고치는게 아니고 쉽게 고칠 수 없는 것에 시간을 너무 허비했었을 테니까요

 

때문에 바꿀 수 있는 것 부터 확인해보자가 먼저였습니다

그래서 일단 다 찾아봤습니다

프로젝트 팀장, 리더, PM은 무슨 역할을 하고 우리랑 똑같이 프로젝트를 진행하는 팀들의 팀장은 어떤 걸 했는지 등등

결국 이것도 찾아보니 다 나오더군요

 

제가 찾아봤던 것 중에 PM이라는 직책의 경우 '팀원 컨디션 관리'가 있는 걸 볼 수 있었습니다

팀원 관리가 되지 않으면 일정에 큰 차질이 생겨 딜레이가 생길 수 있으니
이걸 방지하기 위해 총괄이 맡고 관리하는 부분이죠

근데 제가 무슨 권한이 있다고 제 팀원들을 개인 일정을 함부로 관리할 수 있을까요?

그래서 그냥 단 하나의 절대적인 규칙을 만들었습니다

 

'무조건 기한안에 우리가 정한 기능을 모두 구현시키자' 라는 것이었네요

정말 당연한 소리지만 계속 인지시키기 위해서 정한 규칙이었습니다

 

아플때 맘대로 쉬고 그냥 쉬고 싶을때 조퇴해서 집을 가셔도 된다

단, 제대로 못해서 기능을 넣지도 못하거나 모양이 엉망진창으로 나오는 경우는 없으셔야한다

그렇게 된다면 프로젝트에서 제외한다

 

과장이 많이 되었지만 아무튼 저런 느낌이었습니다

역할이 부여되는 순간에 책임감 하나로 진행했다고 볼 수 있겠네요

 

---

 

그리고 프로젝트를 진행하면서 다 같이 보고 공유할 수 있는 문서의 필요성을 느껴 노션을 사용하게 되었고

제가 혼자 한달 정도만 결제해서 토큰 제한 없는 팀스페이스를 만들어 사용하게 되었죠

 

추가로 git을 활용한 협업이 모든 팀원들이 다 처음이었습니다

저는 git을 그나마 조금은 알고 있었기 때문에 이것도 제가 도맡아서 했던 것 같네요

예를들어 커밋 메시지는 대충 작성하는 경우 나중에 알아보기가 힘들기 때문에
다른 분이 작성한 포스팅을 드리면서 어떻게 작성해야하는지 설명도 해주었고

브랜치를 생성해서 merge, rebase하는 작업도 미리 예시를 작성해주면서 길을 만들어두었습니다

 

rebase 같은 경우는 제가 잘 모르고 있었는데 공부해서 팀원들에게 알려드렸습니다

merge만 사용하려니 커밋 기록도 더러워지고, PR할때 대량 충돌나는 경우 처리하는 방식이 귀찮았는데

다른 팀이 조언을 해주셔서 원리랑 방법을 공부한 다음 팀원들 설득시키고 적용시켰던 기억이 있네요

 

또한 수업으로 배웠던 EC2와 S3의 세팅을 혼자 한번 해보고 properties 파일로 설정을 만들어 뿌려주었습니다

이건 학원에서 배웠던 방식이라 복습이라고 생각하고 EC2 인스턴스 생성부터 서버에 있는 mariaDB와 DB툴을 연결,

IAM으로 S3 권한 주기 등 처럼 다시 시도해봤었습니다

팀장이 설정파일을 공유해서 사용하는게
팀원들과 미리 DB를 맞춰볼 수 있으니 데이터 정합성이랑 실제 데이터 처리 방식을 바로바로 볼 수 있어서 좋았습니다

 

기능 구현 기간에서는 팀장으로서는 할 게 별로 없었고

저보다 잘 하는 팀원 한 분이 계셨기에 그 분과 같이 나머지 팀원 3분을 도와주는 상황이 종종 있었습니다

물어본 게 있다면 직접 코드를 쳐주기 보다는 검색어나 키워드를 알려주는 방식으로 도와드렸네요

 

기억에 남는 아쉬운 점은 종종 기능 구현중에 애매모호한 것이 있었습니다

예를들어 회원 탈퇴의 데이터 완전 삭제를 해야하는지와 같은 문제를 저한테 물어보곤 했는데

애초에 기능이 바뀐게 아니라서 좀 더 디테일하게 설정하고 넘어갔어야 했을 것 같다는 판단이 들었습니다

즉, 요구사항을 명확하게 짚고 넘어갔어야 했어야 오히려 시간을 더 절약하게 된다는 생각이
프로젝트 진행중에 팀장으로서도 개인으로서도 아쉽다는 생각이 자꾸 들긴 했었습니다

 

마지막으로 배포같은 경우에도 팀장이 했었지만

이건 Jenkins와 github action과 같은 CD/CI 방법을 적용하지 않고 수동으로 war 파일을 배포하는 직접 빌드하는 방식으로 했었습니다

이는 나중에 수동배포인 현 상황을 github action을 이용해 자동 배포가 되게 하는 포스팅을 공부해서 올릴 예정입니다

 

 

 

 

 

쭉 읽어보니 뭔가 팀장의 역할보다는 그냥 잡담하는 것 처럼 보이실 것 같은데요

맞습니다 정확하시네요

 

 

다음 포스팅은 git 관리에 대해서 작성하도록 하겠습니다

감사합니다