프론트엔드 데브코스 4차 단위 기간 월간 회고, 프로젝트 looky 회고
Thank You! & Farewell Team looky
정신 차려보니 또 월간회고를 쓸 시간이 왔다. 거의 의무가 되다시피 한 회고들이 나에게는 개인적으로 큰 도움이 되고 있어서 이 시간이 나쁘지는 않지만, 점점 회고를 써야 하는 횟수가 줄어들 때마다 데브코스를 끝내고 본격적인 취업시장에 뛰어들어야 한다는 압박이 동시에 생기기도 한다.
인간은 적응의 동물이라고 했다. 그새 데브코스 학습방식에 적응되었던 것 같은데 슬슬 작년에 했던 것처럼 이력서와 자소서를 다듬고 취업 전선에 뛰어들 준비를 해야겠다.
데브코스 2/3 지점을 통과했다. 여러 강의들을 통해서 나와 동료들의 실력을 높였고, 향상된 실력을 바탕으로 1차 프로젝트를 진행했다. 프로젝트 회고를 작성하는 경험은 처음인데 어떤 순서로 작성을 할까 고민을 하다가 프로젝트 시작 전, 후의 생각 및 느낀 점과 프로젝트가 진행되며 기억에 남았던 특징적인 사건을 중점적으로 스토리 형식으로 풀어가며 회고를 진행해보려고 한다.
우선 간단하게 요약해 보면 이번 단위기간은 돌이켜보면 개인적인 아쉬움이 많았다. 프로젝트를 잘 마무리한 것과 팀원들에게 너무 감사하다는 것 빼고는 없다. 아무래도 프로젝트를 총력전처럼 모든 정신적 에너지를 투자하기도 했고 프로젝트를 하며 고갈된 에너지를 채우려고 이외 시간에는 휴식을 하려고 하다 보니 다른 활동을 전혀 하지 못했다.
🙌 어쩌다 팀장
사실 프로젝트에서의 팀장은, 아니 성인이 된 이후 어떤 조직에서 리더를 경험한 것이 군대에서 분대장을 단 것 이후로는 사실상 처음이다. 즉 사회에서는 나의 첫 팀장을 맡은 경험을 한 프로젝트였다. 그런 내가 팀장을 맡다니 돌이켜서 생각해 봤을 때 `내가 왜 팀장이 됐지?`라는 생각이 들었다. 팀에서 기술적으로 가장 뛰어나지도 않았고, 디자인을 잘하는 것도 아니고 아이디어가 특출 난 것도 아니었다.
솔직한 내면의 얘기와 함께 보면 2가지 이유로 인해서 나는 팀장이 되었던 것 같다.
첫 번째 이유는 `팀원들과 함께 빠르고 재미있게 프로젝트를 완성하고 싶어서`이고 두 번째 이유는 `개인적인 성장`때문인 것 같다.
이번 데브코스에서는 아무래도 지난날들보다, 그리고 나의 평소 에너지 레벨보다 훨씬 더 적극적으로 마음가짐으로 임하다 보니 아무래도 어떤 일정이나 계획을 추진하는 데에 있어서 팀원들에 눈에는 나의 추진력이 굉장히 높아 보였을 것이라고 생각된다. 그래서 추천..? 아니면 암묵적으로..? 팀장이 되기도 했던 것 같다.
솔직하게 내면의 생각을 꺼내보면 나도 성장하고 싶어서 거부감 없이 팀장이라는 직책을 맡았던 것 같다. 앞서 언급하였듯이 사회에서, 그리고 개발 프로젝트에서 리더의 역할을 맡아본 경험은 전무하다. 그러다 보니 `리더를 맡아본 경험의 부재`는 개인적인 결핍으로 다가왔고 그런 마음가짐이 있다 보니 자연스럽게 팀장이라는 역할을 받아들이게 된 것 같다.
⏩ 빨리빨리 팀장(PM)
프론트엔드로만 구성된 프로젝트 특성상 자연스럽게 PM의 역할도 맡아서 같이 진행했다. 그중 내가 가장 신경 쓰고자 했던 것은 속도였다.
이번 프로젝트를 진행하면서 팀원들과 얘기했던 내용은 바로 프로젝트를 최대한 빠르게 진행하는 것이었다. 이번 프로젝트의 기간은 단 17일로 주말과 공휴일을 포함한다고 하여도 27일 정도 되는... 짧은 기간을 가지고 있었다. 또한 중간발표와 최종발표도 존재하였기에 신경을 써야 했고 그랬기에 개발을 더 효율적이고 빠르게 진행해야 했다.
아이디어 구상과 커다란 컨벤션을 정하는 활동을 프로젝트 시작 4일 전부터 진행했고 API가 나오자마자 명세서 작성을 시작해서 큰 기능을 명시하고 팀원들과 토의한 결과 2일 차부터 개발에 진입할 수 있었다.
팀원들을 독촉(?)했다기보다는 최대한 계속 의미부여와 동기부여를 하려고 노력했다. 특히 기간이 짧다는 것을 최대한 어필하려고 노력했고 그 결과 대부분의 일정을 약간 빠르게 마무리할 수 있었던 것 같다. 다만 그렇게 빠르게 개발을 진행하려고 하다 보니 고민거리가 생겼다. 아무래도 빠르게 개발을 하다 보니 발생하는 지속적인 병합 충돌과 여러 이유로 인한 개발 속도 격차, 프로젝트 전반에 대한 방향성 공유에 대한 고민이 생겼다.
해결 방법으로는 후술 할 페어 코딩을 통해서 해결했다.
🖥️ 🖥️ 🖥️ 🖥️ 페어 코딩
너 내 코딩 동료가 돼라
가장 처음 페어 코딩에 대해 용기를 냈던 건 라이브 쉐어 기능을 사용한 것이 아닌, 지금까지 개발한 기능 중 dev 브랜치에 병합된 내용을 디스코드의 라이브 공유 기능을 켜서 싹 훑는 것이었다. 전체적으로 개발 사항을 공유하고 수정사항이나 요구사항을 얘기했던 걸로 기억하는데 처음이라 굉장히 어버버 했는데 끝나고 나니 팀원들이 나름 괜찮아했던 걸로 기억한다. 여기서 1차로 용기 + 공유하는 형태의 개발의 필요성을 느꼈다.
본격적인 페어 코딩에 대한 힌트는 1차 팀에서 얻었다.(돌돌현님들 늘 감사합니다💕) 1차 팀에서 간단한 사이드 프로젝트의 초기 설정을 진행하는 과정에서 VSC의 라이브 쉐어라는 확장 기능을 사용해 본 경험이 있다. 간단하게 기능을 언급하면 코딩을 라이브로 동시에 한 환경에서 진행할 수 있는 것이다.
사실 저 때 라이브 쉐어를 사용한 이유를 기억하기로는 따로따로 작업하는 게 불편하고 한 사람이 도맡아서 하기에는 너무 불편한 부분이 있어서 저렇게 작업을 했었다. 하지만 막상 저렇게 개발을 해보니 내가 모르는 건 동료들이 알려주고, 동료들이 모르는 건 내가 알고 있고 이런 상황이 자주 있었다.
그러다 보니 위에서 언급했던 ` 아무래도 빠르게 개발을 하다 보니 발생하는 지속적인 병합 충돌과 여러 이유로 인한 개발 속도 격차, 프로젝트 전반에 대한 방향성 공유에 대한 고민` 을 해결하기에는 괜찮은 방법이지 않을까 하는 생각이 들었고..
바로 진행했다.
첫 번째는 나와 비슷한 기능을 구현하는 팀원이었고 오전 코어타임이 끝나고 장장 8시간 정도 개발을 진행했다. 목표한 대부분의 개발을 진행함으로써 개발 속도를 향상할 수 있었다는 의의가 있었다. 특히 개인적으로 여기서 내가 개발해야 하는 기능에 대한 로직의 아이디어를 대부분 얻어올 수 있었다.
두 번째는 나와 약간 다른 기능을 구현하는 팀원이었다. 아무래도 나도 처음 접하는 부분이어서 어려움이 있었지만 이 역시 CTO 역할을 맡고 계신 팀원이 같이 문제를 해결해 주셨다. 이때도 코어타임 끝나고 한 10시간 했던 것 같은데 힘들었지만 큰 기능들을 다 개발할 수 있어서 뿌듯했다.
이후로도 우리의 페어코딩은 계속됐다. 큰 기능을 dev에 Merge 한 경우, 공통 요구사항을 수정해야 하는 경우, dev -> main으로 배포 버전을 업데이트하는 경우 등 해당 기능을 최대한 활용하며 고민들을 해결해 가며 빠르게 프로젝트를 진행할 수 있었다.
🤝 서로의 단점을 커버하는 진정한 의미의 협업
우리는 살아온 인생이 다른 만큼 개발에 대한, 그리고 개발 주변 지식에 대한 내용 역시 각각 차이가 있었다. 어떻게 보면 어쩔 수 없는 부분이다라고 표현할 수 있지만 조금 다르게 생각해 보면 당연히 그럴 수밖에 없지 않은가라는 생각이 들기도 한다. 그리고 이번 프로젝트에서는 그런 특성이 오히려 장점으로 다가왔다.
아무래도 이 글을 쓰는 필자는 나이기에 내 생각으로 우리 팀의 얘기를 해보면 우리 팀의 역할 분배는 다음과 같았다.
- 나: 팀장 겸PM
- 팀원 1: 디자인, 지식 자산 총괄
- 팀원 2: CTO, 기술 지식 총괄
- 팀원 3: 개발 열정과 팀 내 분위기 향상
솔직히 프로젝트하면서도, 지나고 나서도 느낀 거지만 황금밸런스였다. 특히 나는 디자인과 아이디어 부분에서 정말 부족한 부분이 많은데 이번 프로젝트를 진행하면서 우리 팀원들이 그런 부분을 너무 잘 채워주셔서 감사했다. 그리고 이렇게 프로젝트를 진행하다 보니 정말 재미있었다.
왜 팀을 이루어 개발을 진행해야 하는가에 대해서 면접에서 질문이 들어온다면 나는 이번 경험을 얘기하고 싶다.
🔥 내가 할 수 있는 건 내가 하기
팀장의 역할이랑 별개로 몇몇 분들에게는 얘기했지만 약간의 지난날에 과오처럼 느껴지는 부분이 개인적으로 있다. 그래서 앞으로 경험하는 팀 프로젝트나 회사 생활에서는 내가 가진 역량을 최대한 발휘하고자 마음먹었고 이번에도 최대한 나의 있는 역량을 다 발휘하고 주어진 업무들을 처리하려고 했다.
단순하게 나열해 보면 개발과 관련된 여러 문서 작성과 Wiki 페이지 생성과 작성, Readme 내용 작성, 발표 준비와 같은 것들이 있다. 팀원들과 회의하거나 지나가면서 정했던 내용들을 최신화하고 업데이트하고, 우리가 구현한 내용들을 문서화하는 것들을 주로 했던 것 같다.
대단한 일을 한 것은 아니지만 필요한 일을 했다는 점에서 개인적으로 만족했다.
⌛ Project End
그런 고민들과 개발, 개발 외적인 작업들을 처리하다 보니 어느새 우리 looky팀의 추억이 담긴 소중한 프로젝트가 끝났다. 메타 태그 사진 수정이 조금 필요할 것 같긴 하다.
(위 링크 만료 시, https://looky-working.vercel.app)
최종 발표 자료
📝 프로젝트를 마친 소감
빠르게 달려서 일정에 맞추어 프로젝트 요구사항을 다 완성했다. 우리의 목표 중 하나는 기본 요구사항을 다 구현하는 것이었고 잘 완수했다. 힘들긴 했지만 너무 재미있고 즐거웠다.
어떻게 내용을 이어갈까 고민하다가 이후 작성할 내용은 주로 아쉬운 점을 위주로 기술하려고 한다. 잘 한 부분도 정말 많지만 나의 회고의 목적은 잘한 점을 기록하기보다는 못한 점을 기록하고 다음 프로젝트에서 해당 내용들을 보완하는 데에 더 집중하고 싶다. 사람의 특성상 잘한 것은 어떻게든 기억하게 되는 것 같다. 그리고 잘했다고 생각하는 내용은 따로 포스팅을 작성할 예정이기도 하고.
🖐️ 팀에서의 아쉬움
- 기술 학습 시간의 부족
많은 팀이 공통적으로 겪었을 것 같은데 기술적인 부분에 대한 충분한 이해와 학습가 더 있었더라면 하는 아쉬움이 있다.
- 기능 개선, 리팩토링
이 역시 비단 우리 팀만의 문제가 아닐 것 같긴 하지만 아직 많이 남아있는 기능개선과 리팩토링 요소 역시 프로젝트를 마치면서 아쉬운 점이기는 하다. 시간 날 때 종종 건드리며 차근차근 프로젝트의 완성도를 높여보려고 한다.
🖖 개인에서의 아쉬움
- 프라밸을 챙기자
팀원에게 `제발 좀 쉬세요`라는 말을 들었다. 확실히 내가 봐도 무리하는 주간이 있기는 했다. 다행히도 체력이 어느 정도 버텨줘서 잘 버틸 수 있었던 것 같은데 그래도 휴식을 잘 취해야겠다.
- 무의식적인 스트레스
처음으로 팀장을 맡았고, 여러 측면에서 잘 끝난 프로젝트라고 생각한다. 그럼에도 불구하고 프로젝트 기간 중 무의식적으로 프로젝트에 대한 전반적인 내용을 신경 써야 한다는 생각이 들어서 그런지 쉴 때도 편히 쉬지 못하는 나의 모습을 볼 수 있었는데 컨디션 저하의 원인이 되기도 했던 것 같다. 다음 프로젝트에서는 너무 걱정하지 말아야겠다.
- 주변의 것들을 잘 챙기자
`프로젝트만` 했다. 정말 지난 한 달간 다른 공부는 다 제쳐두고 프로젝트만 했다. 굉장히 문제가 심각한 부분이다. 여러 공부가 병행되어야 했고 다양한 지식을 흡수해야 하는 기간에 그러지 못했기 때문이다. 특히 PS, CS를 놓으니까 해당 지식들이 빠르게 머릿속에서 잊히더라. 그리고 책도 못 읽고 블로그 글도 거의 못쓰다 보니... 글을 쓰는 능력이 많이 떨어진 것 같은 느낌이다. 프로젝트와 다른 일들의 균형을 찾으면서 효율적으로 계획을 진행해 보도록 해야겠다.
- 쓸데없는 말이 길고 많다.
말이 길다. 사실 여러 고민이 내재되어 있는 부분이긴 하다. 상대방을 존중하며 대화해야 하기 때문에 고민이 많아지고 그러다 보니 말의 사족이 길어지는 느낌이다. 하지만 말은 길어질수록 신뢰도와 설득력을 잃어버리는 느낌이라.. 고민이 큰데 주장, 근거를 명확하게 하되 상대방을 존중하며 간단명료하게 의견을 표현할 수 있도록 더 연습해야겠다.
⚖️ 회고를 마치며
사실 프로젝트를 굉장히 빠르게 달렸다. 개인적으로도 그런 방향성을 지향하기도 하고 `우리는 요구 사항과 개발 기간에 맞추어 프로젝트를 완성해야 한다`는 멘토님의 조언이 뼈에 와닿았다. 앞으로 현업에 가면 고객과의 약속은 물론이고 사내 동료들, 협력 업체들, 투자자 등 수많은 사람들과의 약속이 되어버린다. 그런 걸 잘 맞추려면 지금부터 잘 지키는 연습이 되어야 한다고 생각했고 그런 이유들로 인해 빠르게 일정을 진행했다.
그렇게 일정을 진행하다 보니 팀원들이 힘들었을 것 같은데 오히려 최종 회고를 보면서 정말 감사했다. 아무래도 처음 맡는 팀장이다 보니 부족한 점이 많았고 팀원들의 역량에 비해서 많이 부족하다고 생각했고, 그런 상태에서 너무 빠르게 일정을 진행했다고 생각해서 나에 대한 평가를 걱정했는데 오히려 최종 회고와 마지막 날에 소회를 얘기하면서 나에 대한 칭찬과 응원을 너무 많이 해주셔서 정말 감동받았다.
그래서 더더욱 우리 팀원들에게 감사한 이번 프로젝트였다. 일단 열심히 프로젝트를 한다는 것이 기저에 깔려있는 팀이었고 아이디어 회의와 개발에서도 모두 적극적으로 참여하고 의견을 냈다. 그리고 정말 감사했던 것은 본인과 상반된 의견이 있더라도 팀적으로 결정된 사안에서는 인정하고 진행했던 점이 멋있으면서도 좋았다. 서로의 부족한 점을 잘 메울 수 있는 점도 매우 행복했다.
우리 팀은 마지막 날에 빠르게 프로젝트 최종 발표 영상을 빠르게 제출하고 우리 만의 시간을 보낼 수 있었다. 소회도 얘기하고 이런저런 활동도 하면서 마지막 날을 굉장히 즐겁게 보냈다. Farewell looky!
이별은 아쉽고, 하고 싶은 말도 더 많지만 이쯤에서 줄여보고 이제 앞으로의 얘기를 해보려고 한다.
이제 최종 프로젝트이다. 데브코스의 끝맺음을 누구와 할지 아직은 모르지만 이번 팀을 통해서 프로젝트에 대한 방향성을 어떻게 진행해야 할지, 보완할 점은 무엇인지 많이 경험을 쌓았다. 그런 내용을 바탕으로 이번처럼 커뮤니케이션을 잘하되 아쉬운 점을 잘 개선하고 싶다.
팀장이던 팀원이던 맡은 자리에서 열심히 하고 싶고 무엇보다도 나도 동료들도 즐겁게 개발을 진행했으면 좋겠다.
++ 팀이 결정되었는데 다들 어찌어찌 인연이 있다! 탐구 학습 동료에서 세 분과 즐겁게 이야기를 나눴었기도 하고 그중 두 분은 나를 선정까지 해주셔서 덕분에 맛있는 커피와 케이크를 먹을 수 있었다. 새로운 팀원들도 너무 반가웠고 내가 외부에 있어서 이야기를 많이 못 나눈 것이 아쉽지만 3차 팀원분들도, 새로운 멘토님과의 커피챗도 많이 기대되고 재미있을 거라는 생각이 든다.
MIL 작성 소요 시간 약 3시간
'개발 > 회고록' 카테고리의 다른 글
[프론트엔드 데브코스 월간 회고] 5,6차 단위기간(24.01.19 ~ 24.03.25) 프로젝트 kiwing 회고 (1/2) (3) | 2024.04.07 |
---|---|
프로젝트에서 팀장 역할을 맡으며 했던 고민들 (3) | 2024.01.28 |
주니어 개발자 지망생의 2023년 회고 (0) | 2023.12.31 |
[프론트엔드 데브코스 월간 회고] 3차 단위기간(23.11.19 ~ 23.12.18) 회고 (4) | 2023.12.25 |
[프론트엔드 데브코스 월간 회고] 2차 단위기간(23.10.19 ~ 23.11.18) 회고 (50) | 2023.11.22 |