팀 프로젝트(3) 회고

거의 한 달간 진행되었던 세 번째 프로젝트가 끝이 났습니다. 2025년의 처음 한 달간의 시간을 쏟았던 프로젝트에 대해서 회고하려고 합니다.

Keep

좋은 질문을 하기

세번째 프로젝트를 시작하면서 팀에 대해서 생각할 때 서로 많이 소통했으면 좋겠다고 생각했습니다. 그리고 그 중심에 질문 이라는 키워드를 떠올리게 되었습니다. 개발 공부를 시작하면서 많은 선생님의 도움을 받았습니다. 이때 가장 어려웠던 부분이 질문하기였습니다. 질문하려면 내가 어떤 것을 알고 어떤것을 모르는지에 대해 알아야 했고, 많은 질문이 이런 질문준비과정(?)을 통해 해결되는 것을 경험했습니다.질문을 통해 성장하는 것을 경험했기 때문에 팀원을 배정받고 ＇어떻게 해야 질문을 편하게 많이 하는 팀이 될 수 있을까?＇에 대해 고민하게 되었습니다.

프로젝트를 시작할 때 팀장-부팀장으로 함께 지원할 수 있다는 것을 알게 되어 첫 번째 프로젝트를 함께한 팀원 Y에게 연락을 드려 팀장과 부팀장으로 함께 프로젝트를 진행하게 되었습니다. Y님과 함께하고 싶었던 가장 큰 이유는 질문을 많이 하시는 분이었기 때문입니다. 저의 예상처럼 분위기를 말랑하게 하는데 일조해 주셨고, 프로젝트 피드백 받을 때 팀 분위기가 좋다고 피드백을 많이 받았습니다. 프로젝트 마감을 기념해 온라인 학습공간 zep에서 함께 찍은 증명사진을 공개합니다!

Problem

개발 일정 관리, 자신을 관리하기

첫 프로젝트 회고 때 일정 관리가 어렵다고 적었었는데, 마지막 프로젝트를 마치면서도 제일 어려운 부분은 여전히 일정관리라는 생각이 듭니다. 거의 한 달간의 프로젝트였지만 2주간의 MVP 기간, 해커톤과 추가 개발까지 바쁘게 달려왔습니다. 제가 맡았던 부분은 알림 부분이었는데, 카프카를 사용해 발행된 이벤트를 소비해 슬랙으로 사용자에게 알림을 보내는 부분을 한 달간의 담당했습니다. 미리 이벤트 발행과 수신하는 부분에 대해 예습을 하고 프로젝트를 진행했는데도 실제로 연동 테스트할 때 이벤트를 수신하지 못하는 이슈가 발견되어 며칠을 해결하는 데 사용했습니다. 이런 예상치 못한 일들이 개발 중에 늘 발생하는데 짧은 단위 안에 어떻게 개발을 하지? 라는 생각이 들었습니다.

제가 스스로 생각하고 적용한 방법은 한가지 목표에 대해 온전히 집중할 수 있는 시간을 갖는것 이었습니다. 오전과 오후 각각 두 시간 씩 최소 집중시간으로 정해 물리적인 시간을 확보하려고 노력했습니다. 회사에서의 업무시간과 비슷하게 일과시간에는 중간에 생기는 해결할 일들이 있어 방해받지 않는 시간을 찾았습니다. 그 결과 개발과 회의시간에 조금씩 더 집중할 수 있었던것 같습니다. 이런 작은 규칙이 목표에 파묻히지 않고 빠져나오는 방법 이라는 생각이 들었습니다.

Try

완벽주의에서 완성주의로

이번 프로젝트를 진행하면서 개발이 절대로 한번에 완벽할 수는 없다는 것을 다시 한번 알게 되었습니다. 개발 속도가 느려 고민이 될 때 도움을 받았던 경험을 소개하고 싶습니다. 저희 팀에 개발을 가장 빨리 그리고 많이 하신 분이 계셨는데 그분의 PR은 어떤 기능에 대해 완벽한 개발 내용이 들어가 있지 않았습니다. 차례대로 한가지씩 작은 단위로 PR을 올려 수정할 부분이 있다면 다음 PR에 바로 반영할 수 있도록 했습니다. PR의 단위를 작게 나누는 부분에 대해서 고민 한 것을 첫번째 프로젝트 회고에서 나눴었는데, 제 고민에 대해 좋은 예시를 발견했다는 생각이 들었습니다.

완벽주의가 아닌 완성주의를 지향하게 되면서 개발할 때 저희 태도가 많이 달라진 것을 느끼는데, 그럼에도 여전히 제 코드에서 문제가 없으면 좋겠다는 생각이 듭니다. QA로 일하면서 완벽한 코드는 없다는 테스트의 기본 원칙을 늘 생각하며 결함을 찾았었는데 제 일이 되어보니 결함이 없으면 좋겠다는 생각이 듭니다. 온 힘을 다하되 당연히 수정할 부분이 있다는 것을 늘 마음속에 생각하면서 개발해야겠습니다.