6주간의 그룹 스프린트를 돌아보며 경험한 설계의 시행착오, 협업의 기술, 그리고 시니어 피드백을 통한 성장을 정리한 기록
입력한 비밀번호는 비밀 댓글 열람, 수정, 삭제에 사용됩니다.
아직 등록된 댓글이 없습니다.
1월 1일이 되자마자 제일 먼저 할 일: 스프린트 후기 쓰기!
10주간의 학습 스프린트에 이어 6주간의 그룹 스프린트도 순식간에 지나갔습니다. 오랜만의 팀 프로젝트라 시작 전에는 긴장이 컸지만, 뜻이 맞고 실력 있는 팀원들을 만나며 값진 경험을 충분히 쌓을 수 있었습니다.
그룹 스프린트에 임하면서 처음에는 부담이 컸습니다. 챌린지와 학습 스프린트 과정 동안 한 번도 작업을 완전히 마무리해본 경험이 없었고, 백엔드 영역을 팀원들의 속도에 맞춰 따라갈 수 있을지에 대한 걱정도 컸기 때문입니다.
다행히도 작업 결과보다 협업 과정 자체에 집중하자는 공감대를 가진 팀원들을 만나, 함께 배우고 서로의 코드를 이해하는 데에 초점을 맞춘 스프린트를 경험할 수 있었습니다.
아침부터 새벽까지 회의를 이어갈 만큼 많은 대화를 나누었고, 하나의 주제를 함께 설계하고 리뷰하는 과정을 반복했습니다. 효율적인 방식이었는지에 대한 평가는 다를 수 있지만, 모든 팀원이 동일한 맥락을 공유하고 충돌을 직접 경험하며 설명하는 연습을 충분히 했다는 점에서는 분명 의미 있는 경험이었다고 생각합니다.
프론트엔드 지망생 네 명이 모였지만, 프로젝트 주제는 백엔드 비중이 상당히 컸습니다. 프론트엔드는 UI를 표현하는 역할에 가깝고, 핵심 로직은 백엔드에서 처리하는 것이 목표였기 때문에 설계 단계에서 어려움이 많았습니다. 비전공자(저)가 포함된 팀 구성과 설계 경험의 부족이 겹치며 시행착오도 잦았습니다.
돌이켜보면 사전에 요구사항을 더 명확히 정리하고, 모듈화를 철저히 한 상태에서 구현했다면 불필요하게 돌아가는 부분을 줄일 수 있었을 것이라 생각합니다. 그럼에도 실제 구현을 통해 어떤 설계가 문제를 만들었는지, 다시 설계한다면 무엇을 바꿔야 하는지를 체감할 수 있었던 점은 큰 수확이었습니다.
다음 프로젝트에서는 모듈 간 상호 참조와 같은 구조적 문제를 초기에 차단할 수 있도록, 설계 단계에 더 많은 시간을 투자하고 싶습니다.
이번 주제는 이전 과제들보다 CS 기초 지식에 대한 요구가 컸습니다. 설계 경험과 CS 이해도가 모두 부족한 상태였기에 팀의 설계 논의에 적극적으로 기여하지 못한 점은 개인적으로 아쉬움이 남았습니다.
프론트엔드 개발자들이 모인 팀 특성 상 UI뿐 아니라 lint, prettier, GitHub Project, PR 규칙 등 전반적인 컨벤션을 중요하게 다뤘습니다. 평소 팀 프로젝트에서 이러한 기준이 잘 지켜지기를 바랐는데 이번 스프린트에서는 비교적 잘 정착시킬 수 있어 만족스러웠습니다.
다른 팀들이 Husky나 GitHub Actions를 활용해 커밋, 린트, 테스트를 자동으로 검증하는 모습을 보며, 다음 프로젝트에서는 이러한 도구를 도입해 팀원 간의 피로도를 줄여보고 싶다는 생각이 들었습니다.
감사하게도 운영진분께서 채널에 저희 CS 학습을 보고 좋은 말씀을 남겨주셨습니다.
이번 그룹 스프린트 기간 중, CS 퀴즈 운영 방식이 기존의 주차별 진행에서 3주 단위로 변경되었습니다. 이를 어떻게 활용할지 팀 차원에서 논의했고, 다음과 같은 방식으로 진행했습니다.
같은 질문을 매주 다른 관점에서 바라보며 사고를 확장할 수 있었고, 퀴즈의 의도에 대해서도 자연스럽게 고민하게 되었습니다.
설계 전에 CS 학습을 진행했다면 더 도움이 되었을 것이라는 아쉬움은 남지만, 명확한 목표 없이 진행했다면 깊이 있게 다루지 못했을 것 같아 전반적으로는 매우 긍정적인 경험이었습니다.
이전 스프린트까지는 구현에 집중하느라 문서화를 거의 하지 못했습니다. 하지만 팀 프로젝트에서는 모든 팀원이 진행 상황을 이해하고, 필요할 때 다시 확인할 수 있어야 한다는 점을 절실히 느꼈습니다.
스크럼 기록, 회의록, 컨벤션, PR 내용을 중심으로 문서화를 진행했고, 초반에는 노션을 중심으로 회의록을 정리했습니다.
이후 다른 팀들의 사례를 참고해 노션 AI를 활용한 요약이나 ADR 작성 방식도 도입했습니다. 특히 ADR은 의사결정의 맥락이 잘 드러난다는 점에서 인상 깊었고, 다음 프로젝트에서는 초반부터 적극적으로 활용하고 싶다는 생각이 들었습니다.
리팩토링 기간에는 AI 기능을 프로젝트에 적용하는 작업을 맡아 관련 내용을 velog에 정리해 팀원들과 공유했습니다. 구현 과정이 복잡하다 보니 문서 작성에도 많은 시간이 들었고, 구현 방식보다 **"왜 이렇게 구현했는지"**를 더 명확히 설명하면 좋겠다는 피드백을 받았습니다.
🤔 고민
핵심만 전달하면서도 맥락을 이해하기 쉬운 문서화를 어떻게 할 수 있을지에 대한 고민이 남았습니다.
대학 시절부터 팀 프로젝트에서는 함께 모여 긴 시간 논의하며 문제를 해결하는 방식을 선호해왔습니다. 다만, 팀원 대부분이 내향적인 경우 회의 방식에 부담이 되지 않을지 걱정도 있었습니다.
다행히 이번 팀에서는 긴 회의에 대한 큰 불편함이 없었지만, 앞으로 다른 성향의 팀원과 협업 할 경우를 대비해 더 효율적인 소통 방식에 대해 고민하게 되었습니다.
팀원 피드백 중에는, 아직 머릿속의 결론이 나지 않았을 때 침묵보다는 생각 중이다, 크게 상관없다 와 같이 의사를 표현해 달라는 피드백이 있었습니다. 평소 본인도 상대방이 명확한 반응이 없을 경우 눈치를 보는 스타일 임에도 몇 차례 이를 신경 쓰지 못했던 것 같습니다.
보다 유연하고 끊김 없는 팀 프로젝트를 위해서 명확한 의사 표현이 필요하다는 점을 다시 한 번 인식하게 되었습니다.
대학에서 발표 경험이 있었던 덕분에 데모 준비 과정은 비교적 수월했습니다. 팀원들 역시 적극적으로 참여해 주었고, 자료 제작도 원활했습니다.
다만 리팩토링 기간을 포함해 보고서를 작성하는 시점에 이르러, 결과를 조금 더 정량적인 수치화를 했으면 좋았을 것이라는 아쉬움이 남았습니다.
다른 팀들의 경우, 전반적으로 회사의 결과 보고서에 가까운 형식을 취하고 있었고, 저희 팀 역시 마스터 클래스 당시 '좋은 보고서'라는 피드백을 받기는 했지만, 개발 분야에서는 정량적인 지표가 포함된 보고서가 더 설득력을 갖지 않을까 하는 생각이 들었습니다.
이러한 형태의 보고서를 더 많이 연습하는 것이 향후 취업 과정에서도 분명 도움이 될 것이라고 느꼈습니다.
또한 주차가 지날수록, 데모 시점에 다른 팀들이 알지 못하는 작업들이 점점 쌓이게 되면서 이를 어떻게 효과적으로 전달할 것 인가에 대한 고민도 생겼습니다. 우리가 수행한 모든 작업을 공유하는 것이 좋은지, 아니면 이전 작업 중 일부를 선별해 공유하는 것이 더 효과적 인지에 대해 지속적으로 생각하게 되었습니다.
매 데모마다 받고 싶은 피드백을 사전에 정리해 가기는 했으나, 기대했던 만큼의 피드백을 받지 못한 경우도 많았습니다. 이 과정에서 우리가 문제 상황을 충분히 명확하게 공유하지 못했던 것은 아닐지 되돌아보게 되었고, 데모를 통해 더 좋은 피드백을 이끌어내기 위한 방식에 대해 고민해 볼 필요성을 느꼈습니다.
그동안 저는 리팩토링을 코드 정리, 중복 제거, 단일 책임 원칙에 따른 컴포넌트 분리, 접근성 강화와 같은 관점에서 주로 인식하고 있었습니다. 그러나 다른 팀들의 데모를 보며, 리팩토링의 초점이 성능 향상에 맞춰진 경우가 많다는 인상을 받았습니다.
이번 2주차 리팩토링을 진행하며, "우리 팀이 이 과정에서 무엇을 얻고자 하는가" 라는 질문을 여러 차례 하게 되었습니다. 저희 팀은 초반부터 코드 리뷰와 컨벤션 정립이 잘 이루어져 있었기 때문에, 앞서 언급한 구조적 문제나 스타일 불일치가 거의 없었습니다. 반면 프로젝트를 교환한 다른 팀의 경우, 각자가 기능 구현 자체에 집중했던 만큼 파일 간 스타일 차이나 재사용성 측면에서 개선할 여지가 보였습니다.
이러한 작업은 장기적인 프로젝트에서는 분명 의미가 있지만, 2주라는 짧은 기간 안에서 수치화할 수 있는 성과를 만들기에는 한계가 있다는 생각이 들었습니다. 그 결과 저희 팀은 초기에는 구조 정비에 집중했으나, 점차 이보다는 우리가 실제로 얻어갈 수 있는 학습과 결과에 초점을 맞추게 되었습니다.
리팩토링 기간의 기본 규칙은 로직을 변경하지 않고 코드만 개선하는 것이었지만, 저희 팀은 이전 프로젝트에서 완전히 마무리하지 못했던 설계를 보완하는 방향으로, 일부 기능을 추가하는 작업도 병행했습니다. 제한된 시간 안에서 단순한 코드 정리에 그치기보다는, 프로젝트 전체의 완성도를 높이는 선택을 한 경험이었습니다.
리팩토링 막바지에는 좋은 기회로 시니어 피드백을 받을 수 있었습니다. 그동안 겪어왔던 문제와 고민을 정리해 문서로 정리한 뒤, 긴장된 마음으로 피드백에 임했습니다.
이번 회고 리뷰를 통해, 문제 상황 자체는 비교적 잘 파악하고 있으나 이를 기술적인 용어로 정확하게 설명하는 능력이 부족하다는 점을 분명히 인식하게 되었습니다. 문제 해결 과정을 설명할 때 다소 추상적인 표현에 머무르는 경향이 있어, 구체성과 전문성을 보완할 필요가 있다는 피드백을 받았습니다.
설계와 CS 기초가 스스로 가장 부족하다고 느끼던 부분이었는데, 이를 정확히 짚어 주셔서 당황스러우면서도 앞으로 무엇을 학습해야 할지 방향이 더욱 명확해졌습니다.
어떤 결정을 내리게 된 배경과 그 과정을, 모두가 공통적으로 사용하는 용어를 기반으로 논리적으로 설명하는 경험이 충분히 필요하다는 점을 절실히 느끼는 시간이었습니다.
또한 이번 시니어 피드백은 팀 프로젝트 전반에 대한 고민과 개인적인 학습 방향성 위주로 진행되어 기술적인 논의는 상대적으로 적었는데, 다른 캠퍼 분들이 기술에 대해 깊이 있는 질의응답을 주고받는 모습을 보며 스스로 더 분발해야겠다고 느꼈습니다.
지금 수준에서는 그러한 질문에 충분히 답하기 어려웠겠지만, 익숙한 프론트엔드 기술뿐만 아니라 다양한 기술 영역을 꾸준히, 그리고 정확하게 학습해 자신 있게 설명할 수 있는 개발자가 되고 싶다는 목표를 다시 한 번 다지게 되었습니다.
시니어 피드백과 그룹 스프린트에서 느낀 부족한 점들을 바탕으로, 설계 관련 도서를 선정해 주도적으로 설계 역량을 기르는 학습 과정을 경험해 보고자 합니다. 그동안은 학교 수업을 병행하며 개인 학습에 충분한 시간을 확보하기 어려웠지만, 이제 남은 기간 동안은 부스트캠프 학습에 집중할 수 있는 환경이 되었습니다.
앞으로는 매주차마다 떠올랐던 의문과 보완이 필요한 부분을 중심으로 학습하며, 부족한 역량을 체계적으로 채워 나가고자 합니다.
그룹 프로젝트를 진행하며 팀원에게 부담을 주지 않겠다는 생각으로 밤늦게까지 작업한 날이 많았습니다. 그러나 이러한 방식이 오히려 낮 시간의 집중력을 떨어뜨리고, 전체적인 효율을 저해한다는 점도 함께 체감하게 되었습니다.
챌린지 기간에는 수면을 줄이며 버틸 수 있었지만, 멤버십 과정에서는 전날의 무리가 다음 날의 학습과 협업에 직접적인 영향을 준다는 사실을 분명히 느끼게 되었습니다. 앞으로는 팀에 기여하면서도 개인의 컨디션과 삶의 균형을 유지할 수 있는 작업 방식을 고민하고, 보다 지속 가능한 협업 방식을 찾아가고 싶습니다.
팀원들과 함께한 6주라는 시간은 길면서도 매우 빠르게 지나갔습니다. 이 기간 동안 스스로 어떤 부분이 부족한지, 그리고 어떤 점을 개선해야 함께 일하고 싶은 팀원이 될 수 있는 지를 몸소 느낄 수 있었습니다.
이번 회고를 통해 정리한 고민과 배움을 잊지 않고, 앞으로의 성장 과정에 꾸준히 반영해 나가고자 합니다.
부족한 점이 많았음에도 함께 성장하며 이끌어 준 F4 7팀 팀원 분들께 감사의 마음을 전합니다.
