6주에 걸친 팀 프로젝트가 마무리 되었습니다.🥳
긴 시간이 아니어서 그랬는지 시간이 정말 빠르게 흘러 발표까지 마무리 되었네요
이번 회고에서는 프로젝트의 기술적인 성과 보다는 제가 어떤 마음 가짐으로 프로젝트에 참여하였고, 이를 위해 취했던 행동과 그 결과에 대해 써보려고 합니다.
기술적인 내용이 궁금하시다면 아래 남겨놓은 링크를 참고해주세요😊
이제 각 항목들을 살펴보면서 회고를 진행해보겠습니다.
개인 목표
프로젝트를 시작하기 전, 저는 애자일스러운 개발을 개인 목표로 정했어요
신입 개발자를 채용할 여력이 있는 회사들은 어느정도 규모가 있는 회사인 경우가 대부분이라고 생각합니다.
그러한 이유로 신입 개발자들은 이미 만들어져있는 환경을 잘 활용할 수 있도록 성장이 유도된다고 느껴졌어요
그래서 기존 환경에 잘 적응하고 난 후에는 단순 운영 업무들이 많은 것 같고, 기존 개발자들과 역량 차이가 많이 나는 상황에서는 새로운 업무나 규모가 큰 작업등 중요한 역할에 대해 기회를 받기 어려운 상황인 것 같습니다.(물론 사바사 팀바팀)
- 때문에 큰 회사에 재직중이더라도 어느정도 연차가 쌓였을 때 스타트업 등으로 이동하는 경우가 종종 보이는 것 같아요
이처럼 서비스가 빠르게 성장 또는 변화, 진화해나가는 경험은 큰 회사에 다니던 사람들이 이직을 선택하게 되는 큰 이유중 하나라고 생각합니다.
저는 짧은 기간동안 빠르게 릴리즈를 배포하는 경험은 이러한 과정의 축소, 압축판 이라고 생각했고, 이러한 애자일한 개발 경험을 동료들과 함께 해보고 싶었어요
이러한 도전에서 이미 정점을 찍고 내려오는 서비스를 운영해봤던 경험이 있던 저는, 다른 동료들에게 방향을 제시해 줄 수 있다고 생각했습니다.
- 완벽하진 않아도 확장을 고려할 수 있는 아키텍처
- 적절한 리펙토링 시점
- 테스트 코드
- 릴리즈 단계별로 필요한 환경과 도구들
프로젝트 수행하며 원활하게 진행될 수 있도록 위와 같은 내용들에 대해서 많은 신경을 기울였습니다.😊
프로젝트 목표
초기 소규모 서비스에서 시작하여 점진적인 확장을 통한 기술적으로 완성도 높은 서비스 만들기
결과부터 말씀드리면, 초기 소규모 서비스에서 시작하여 점진적인 확장을 통한 기술적으로 완성도 높은 서비스 만들기를 프로젝트의 핵심 목표로 선정하였습니다.
처음 팀 빌딩 과정에서 저의 개인 목표인 애자일한 개발 경험을 말씀드렸고, 아래와 같은 내용들을 통해 팀원분들의 공감을 얻을 수 있었습니다.
- 프로젝트 기간 중 실질적으로 개발할 수 있는 기간은 4주 정도 뿐임
- 프로젝트의 일정을 정확히 산정하는 것이 어려움
- 처음부터 규모를 크게 잡을 경우 이후 변수가 생겼을 때 프로젝트를 엎어야 하는 상황도 종종 발생함
- 이러한 경우 기술적 완성도 자체가 흔들릴 수 있음 등
다른 분들도 개발 경험을 위한 프로젝트의 가장 중요한 부분은 기술적 완성도가 핵심이라는 것에 공감해주셨고, 앞서 말씀드린 여러 이유들에도 납득 해주셔서 점진적으로 완성도 높혀나가는 방향으로 진행하는 것이 저희 팀의 기준이 되었습니다.
팀 구성
프로젝트 시작 전 1, 2, 3순위 개발 주제와 온라인, 오프라인 진행 여부를 사전 설문으로 선택하였습니다.
- 저는 실시간 서비스, 오프라인 진행을 선택했어요
팀원은 사전 설문을 기준으로 랜덤하게 뽑혔습니다.(거리도 어느정도 고려해주시는 것 같았어요)
결과적으로 저희 팀은 세부 선택 분야 기준으로 백엔드 4명, 프론트엔드 1명인 비대칭한 비율로 인원이 구성되었습니다.
- 온라인 편집 도구 같은 경우 프론트엔드 5명으로 구성된 팀도 있었습니다😂
다행히도 프론트엔드를 선택하신 인원이 인턴 및 대외활동 등으로 프로젝트 경험이 많으셨던 편이어서 최악은 아니었지만, 프론트엔드 영역의 업무 부하가 심할 것으로 예상되었어요
그래서 원래 풀스택 개발자로 일했던 경험이 있던 제가 백엔드와 함께 프론트엔드 영역을 같이 개발하는 것으로 이야기 되었습니다.
페어 프로그래밍
모든 구성원들의 프로젝트 이해도를 높이려 노력했습니다.
저희 팀은 프로젝트의 대부분을 페어 프로그래밍을 적극적으로 활용했는데, 이유는 다음과 같았습니다.
- 백엔드 영역을 선택하신 세 분의 프로젝트 수행 경험 부재
- 백엔드 영역을 선택하신 세 분 중 두 분이 프론트엔드 영역 개발 참여 의지가 있었음
- 저의 풀스택 개발 및 CI/CD 등 폭넓은 프로젝트 및 서비스 운영 경험
저의 개인적인 경험으로는 팀원의 역량 간격이 큰 팀 구성에서 일정이 촉박해질수록 역량이 좋은 인원이 대부분의 업무를 수행하게되는 즉, 소수의 인원이 캐리하는 방식으로 진행되는 경우가 많았어요
이러한 상황이 발생했을 때 아래와 같은 문제들이 우려되었습니다.
- 캐리하는 인원 역량에 프로젝트의 완성도가 결정됨
- 캐리하는 인원의 피로도로 인해 완성도 낮은 결과물이 만들어짐
- 고생은 고생대로 하지만 얻는 것이 많이 없음
- 피로도로 인해 예민해지고, 다툼 등으로 감정까지 상함
- 캐리 받는 입장에서도 막상 챙겨가는 것은 없음
저는 이러한 문제가 프로젝트에 대한 이해도가 가장 큰 문제라고 생각했어요
그래서 현업에서 새로운 인원을 팀에 빠르게 적응시키기 위해 기존 인원과 페어 프로그래밍을 시도하는 것 처럼 저희 팀에도 페어 프로그래밍을 제안 드렸고 적용해보려했습니다.
이러한 결정으로 주차별 목표에 맞게 페어를 구성하되, 제가 해당 목표에 맞는 문제 해결 방법을 개략적으로 정해드리고 수행하는 방식으로 진행되었어요
본격적인 페어 프로그래밍이 시작된 후 진행 초반에 약간의 갈등도 있었습니다🥲
프론트엔드 영역의 경우 가장 먼저 공통 컴포넌트를 구현하고 스토리북을 적용하는 것을 목표로 진행되었었는데, 프론트엔드 영역 개발에 의지가 있었던 두 분이 개발에 참여하면 이후에 큰 도움이 될 것이라 판단하여 기존 프론트엔드 개발을 원하셨던 한 분을 주축으로 총 세 분을 페어로 구성했어요
이 과정에서 두 분이 프론트엔드 영역에 대한 이해도가 부족하셨기 때문에, 주도해주신 한 분이 나머지 두 분을 이해시키며 진행하는 과정에 많은 시간이 필요했습니다.
이로 인해 진행 속도가 더뎌 프론트엔드를 주도하신 인원이 일정에 대한 우려를 표했고, 나머지 두 분도 본인들로 인해 프로젝트 일정에 지장이 생기는 것을 걱정하여 자신감이 떨어지고있는 상황이었어요
그래서 저희 팀에서 목표로 했던 1순위 개발 목표를 0순위 개발 목표로 더 작게 만들어 작업 분량을 최소한으로 줄이는 것으로 일정에 대한 부담을 덜어드림과 동시에 “당장 진행 속도가 느리더라도 프로젝트 후반부에 가면 훨씬 큰 이득을 볼 수 있을 것” 이라는 믿음을 드리려고 노력했습니다.
결과적으로 프론트엔드를 잘 몰랐던 두 분이 React에 대한 기본적인 활용 뿐만 아니라 개발 영역에 대한 이해를 바탕으로, 프로젝트 막바지 진행했던 사용성 개선 및 안정화 작업을 수행할 때 큰 도움을 주셨습니다😄
데일리 스크럼
편하게 공유할 수 있는 분위기를 만들기위해 노력했습니다.
부스트캠프에서 프로젝트 일정 가이드를 통해 데일리 스크럼을 진행할 것을 권장하였는데요
저희 팀은 점진적인 개선을 목표로 하는만큼 형식적인 데일리 스크럼이 아닌 실질적으로 도움이 되는 데일리 스크럼이 될 수 있도록 많은 노력을 기울였습니다.
특히 이를 위해 편하게 공유할 수 있는 분위기를 만드려 노력했어요
신입 개발자가 프로젝트 일정 지연이 발생하는 이유로 진행 상황과 당면한 문제에 대해 공유하지 않는 것을 많이 꼽아 주시는 것 같습니다.
저도 이전에 업무를 수행하며 그런 경험이 있었기 때문에 프로젝트 경험이 적은 인원이 많은 이번 프로젝트에서도 그러한 문제가 발생될 것 이라고 예상되었어요
저 같은 경우는 아래와 같은 이유들이 가장 큰 원인이었는데
- 진행에 어려움을 겪고 있다는 것 자체가 부끄러움
- 도움을 요청하는 것에 대한 부담
- 조금 더 고민해보면 좋은 방법이 떠오를 것 같다는 생각
그래서 잘 모르는 것과 어려움을 겪는 것에 대해 부끄러운 일이 아님을 끊임없이 강조하며 자신감을 가질 수 있도록 많은 노력을 기울였습니다.
그리고 저의 예상보다 진행이 더딘 경우 먼저 어려움을 느끼는 부분에 질문하고 방향성을 잡아 드리려 노력했어요
코드 리뷰와 리팩토링
스스로 잘 할 수 있을 것이란 믿음을 드리려 노력했습니다.
이전까지의 경험으로 프로젝트를 진행하며 어려움을 느꼈던 부분 중 하나는 내가 올바르게 구현하고 있을까? 에 대한 의문이었어요
이로 인해 저 같은 경우는 구현이 망설여지고, 계속해서 같은 영역을 새로 구현하는 등의 문제가 있었습니다.
- 프로젝트 초반에 역시나 다른 인원들에게서도 이러한 모습들이 조금씩 보이고 있었어요
그래서 적극적인 코드 리뷰를 통해 더 나은 방법에 대해 이야기해볼 수 있는 기회를 만들기위해 노력했을 뿐만 아니라, 리팩토링을 함께 수행하며 실제로 더 나은 결과물을 만들었습니다.
이를 통해서 당장 완벽하지는 않아도 결과적으로 더 좋은 결과물을 만들어갈 것이라는 믿음을 만들어드리려고 노력했어요
이러한 노력 덕에 다른 인원들이 조금 더 자신감있게 개발을 진행할 수 있지 않았을까 생각해봅니다🤣
TDD와 테스트 코드
TDD 애자일 개발 방법론에서 빠지지않고 언급되는 내용인데요
저희도 점진적은 개발과 배포를 목표로 삼았던 만큼 TDD를 했으면 좋겠다고 제안하였습니다.
TDD에 대해 개발 진행 속도에 대해 우려해주시는 분들에 대해 단순 구현 시간만 따진다면 더 느릴수 있지만, QA 등을 포함한 배포까지의 기간을 따진다면 오히려 빠를 수도 있다고 설득하여 진행하며 일정에 문제가 있을 경우 테스트 코드만 활용하는 조건으로 채택되었어요
테스트 코드는 프로젝트의 스펙을 표현할 수 있다는 조언을 토대로 기획 단계에서 에픽, 스토리, 태스크를 명확히 만들려고 노력했습니다.
개발 초반에는 꼼꼼하게 만든 백로그를 기반으로 잘 진행이 되었는데, 프로젝트가 진행될 수록 짐으로 느껴졌어요
특히 프론트엔드 영역의 경우는 UI의 작은 변경만으로도 테스트가 크게 변경되는 경우가 많았습니다.
결과적으로 주요 서비스 로직에만 테스트 코드 적용을 방식으로 자연스럽게 전환되었어요
- 주요 로직은 커버리지 90% 정도 였습니다.😂
저희가 판단한 원인들은 아래와 같았습니다.
- 백로그 자체의 변경
- 초기 설계가 크게 변경
- 너무 빠른 스프린트 주기
- 테스트 도구 숙련도 (ex.
ws-supertest) 등
제가 생각하는 가장 큰 문제는 스프린트 주기가 너무 짧았던 것이 아닐까 생각해봤어요
테스트 코드 자체가 미래 변경을 위한 투자라는 말을 자주 들었는데, 같은 영역에 대한 변경이 너무 잦게 발생하다보니 장점보다 단점을 더 크게 느낀것이 아닐까 생각해봅니다.
생성형 AI 활용
생성형 AI는 오랜 시간 만에 현업에 가까운 개발은 진행한 만큼 이전과 가장 달라진 부분 중 하나였습니다.
특히 생성형 AI를 통해 문서화와 성능 분석에서 큰 도움을 받았어요
- PR 및 Commit 메시지 생성
- StoryBook, Swagger 등의 적용
- 리팩토링 성과 측정
- 부하 테스트 결과 분석
- 성능 평가 결과 분석 등
저는 평소에 문서화를 힘들어 하는 편 이었는데, 생성형 AI의 도움 받아보니 너무 쉽게 느껴졌습니다.
이번 기회를 통해 생성형 AI가 개발 생산성에 큰 도움을 줄 수 있다는 것을 체감할 수 있었고, 잘 활용할 수 있도록 많은 시도를 해봐야겠다는 생각이 들었어요
끝으로
이번 프로젝트는 리더 역할을 수행하며 프로젝트가 잘 수행될 수 있도록 많은 시도를 해봤던 것 같습니다.
개인적으로는 부분 부분 아쉬운 점이 보이긴 하지만 대체로 원활하게 진행된 것으로 보아 역할 수행을 꽤 잘하지 않았을까 라는 생각을 해봅니다.😁
1월 6일부터 프로젝트 리팩토링을 진행하게 되었는데요, 기존 팀원들 중 가능한 인원들이 모여서 진행했던 프로젝트를 개선하기로 했습니다.
오버 엔지니어링에 대한 우려 때문에 적용하지 않았던 기술들을 적극적으로 적용해볼 것 같고, AI를 활용한 기능 개선도 고려해볼 수 있을 것 같네요
마지막은 부끄럽지만 프로젝트 수행에 대한 동료들의 평가를 자랑하고 가겠습니다🤣
끝까지 읽어주셔서 감사합니다.
