테오의 스프린트 17기에 프론트엔드 포지션으로 참여한 후기입니다.
진행 기간은 2024.04.03 ~ 2024.04.08 총 6일이었습니다.
1일차 OT
1일차가 끝나고 받은 테오의 스프린트 안내 메일입니다.
저는 여기서 테오의 스프린트의 취지에 깊은 공감을 했는데 "포트폴리오를 위한 프로젝트의 개발이 아니라 좋은 협업 과정을 체험하고 이해하는 것이다" 가 테오의 스프린트의 취지라고 안내되어있더라구요
그만큼 이번 테오의 스프린트에 참여하면서 그럴듯한 프로젝트, 포트폴리오를 만드는것을 목표로 하는 게 아니라 다양한 사람들과 이야기하고 협업해보는 경험을 가져가는데에 중점을 두어야겠다라는 생각을 하면서 참여해야겠다는 목표를 세웠습니다.
다시 본론으로 돌아가서 1일차에는 "내 아이디어를 소개합니다"를 했는데요
각자 자신이 준비한 아이디어를 1분 이내로 스피치하는 것입니다.
사실 부랴부랴 준비해갔는데 생각보다 반응이 괜찮았어서 조금 놀랐습니다.
1N명 분들의 하트를 받고 최종 아이디어 선정 후보까지 올라갔으나
이 아이디어가 쓰이는 일은 없었습니다. 최종에서 떨어졌거든요 하하..
이렇게 피그잼, 피그마를 이용하면서 프로젝트의 기획부터 진행해보니 부트캠프에서 최종 프로젝트 할 때 생각이 나더라구요
뭔가 부트캠프의 향수가 느껴져서 즐거웠던 시간이었습니다.
2일차
2일차의 메인이 되는 슬로건은 "결정하지 않기" 였습니다.
우선 상상력을 제한시키지 않고 모든 생각들을 자유롭게 펼친 뒤에 정리하는 것은 잘 알려진 방법론이기도하죠
사실 빠르게 빠르게 소거법을 통하여 결정하고 시도해보면서 피봇하기를 선호하는 제 성향과는 조금 대척점에 있는 시간이라서 최대한 평소의 생각 흐름과 반대로 생각하려고 노력했습니다.
아이디어를 배제하지 않는다는 게 말로 들으면 쉬워보이지만 막상 실천하기는 꽤 어렵다고 생각이 들어요
2일차는 많은 아이디어가 쏟아지는 시간이다보니 팀원들과 많이 친해지기도하고 또 시간을 넘기면서 오랫동안 이야기하게 되는 시간이기도 했습니다.
서로 다양한 아이디어들과 키워드를 가감없이 떠올리고 표현하면서 서로의 생각에 영향을 받아 꼬리에 꼬리를 물고 더 좋은 생각들이 나오는 경험은 혼자서 기획하고 생각할 때에는 얻을 수 없는 경험이라고 생각해요 그래서 저는 이 시간이 가장 협업에서 매력적인 순간들이 많이 나온 시간이라는 생각을 했습니다.
3일차
3일차는 대망의 결정을 하는 시간이었습니다.
2일차에서 꼬리에 꼬리를 물고 나온 아이디어들 중 우리가 스프린트 기간동안 해내야할 우선순위가 높은 가치들을 채택하고 집중하는 시간이 바로 3일차인것이죠
그런데 저는 3일차에서 팀의 의사결정이 점점 더뎌지고 있다는 시그널을 느낄 수 있었는데요
팀이 총 8명으로 구성되어서 꽤 많은 인원들이 의견을 내야하는 상황이다보니 개개인의 잘못이라기보다는 빠르게 의사결정을 하고 | 빠르게 의견을 취합할 수 있는 시스템의 부재로 인하여 비효율이 발생하고 있다는 생각이 들었습니다.
이 과정에서 팀이 바라보아야할 곳을 한곳으로 정리해주고 신속히 의사결정할 수 있는 구조와 중재자의 존재가 중요하겠다는 생각도 들었어요 다만 중재자 개개인의 역량에 의존하게되면 그 사람만 중재자를 할 수 있겠죠 시스템적으로도 빠르게 의사결정을 할 수 있는 구조가 되면 좋겠다는 생각이 들었습니다.
그래서 저는 모두의 시간과 (나의 수면 시간)은 소중하기 때문에 제가 할 수 있는 선에서 빠르게 의사결정을 할 수 있는 구조를 만들고자 바쁘게 움직였던 기억이 많이 나는 것 같아요
4, 5일차 개발 시간
만들고자한 서비스가 "코드리뷰 커뮤니티" 였기 때문에 이번 스프린트에서 아무리 시간이 부족하더라도 코드리뷰는 꼭 수행해야겠다라는 생각이 들었습니다.
github에는 일정 인원의 Approve를 받아야지만 PullRequest를 Merge할 수 있는 브랜치 보호 규칙을 설정할 수 있는데요. 이를 활용하여 최소 한명은 코드리뷰를 수행하고 Approve를 해주어야지만 Merge를 할 수 있도록 강제하여 팀원들이 코드리뷰를 자연스럽게 할 수 있는 환경을 만들었습니다.
이런식으로 반드시 리뷰를 해야지만 Merge를 할 수 있었죠
여기에 추가로 Husky 를 통하여 prepush 시에 테스트 , 린트, 빌드 규칙을 통과하지 못하면 푸시를 막고 CI 환경에서의 검증이 실패하면 Merge를 하지 못하게하는 규칙도 추가로 정의하였어요
혼자 개발할때에는 사실 이런 부분에서 실패할일이 거의 없지만 이번 협업에서는 꽤 높은 확률로 CI에서 잘못된 코드를 검증하거나 husky 에서 잘못된 코드를 검증하는 일이 많았습니다. 프리티어의 경우에는 윈도우 - 맥 차이로 인한 이슈도 있었고요
혼자 개발할때에는 안전해진 기분이 드는 정도에서 끝났다면 이번 협업상황에서는 철저한 CI 와 코드 검증 자동화의 편의성을 많이 체감할 수 있었습니다.
6일차
6일차는 데모데이로 각자 자기 팀의 서비스를 사용당하고, 다른 팀의 서비스를 사용해보는 시간과 회고를 하는 시간을 가졌습니다.
각자 상대팀의 서비스를 리액션 대표가 나와서 실제로 사용해보는 시간이었는데 제가 있던 팀에서는 제가 리액션 대표로 떠밀려 나오게 되었습니다.
상대팀(9팀 프리무스)의 완성도가 매우 높아서 편하게 아쉬운 점들에 대해 막말(?) 했던 기억이 나네요
https://github.com/primus-teoSprint/FE
제가 참여한 10팀의 github 링크는 아래와 같습니다
https://github.com/ccondae/anycode
저희 서비스는 아쉽게도 백엔드와의 CORS 에러로 인하여 핵심 밸류는 거의 구현이 되었지만 데모데이에 실 서비스를 이용할 수 없는 안타까운 현상이 발생했습니다.
사실 평소에는 next.js를 통해서 개발을 하다보니까 CORS 에러를 우회해야하는 상황이 있어도 크게 어려움 없이 우회가 가능해서 이부분이 병목이 될 것이라는 생각을 하지 못했던 게 큰 것 같아요
다음에 또 테오의 스프린트와 같이 짧은 기간안에 개발해야하는 협업을 하게 된다면 스캐폴딩 과정에서 CI 까지만 수행하고 끝내는게 아니라 CD까지 미리 수행해두고 개발하는 전략을 고려할 것 같습니다.
후기
스프린트를 진행하면서 개발을 좋아하는 많은 사람들과 교류할 수 있어서 즐거웠고 좋은 인연들을 많이 얻어간 것 같습니다.
하지만 두번 참여하기에는 제 체력이 따라줄지 모르겠네요 하하
함께 개발하셨던 모든 분들 수고하셨고 즐거웠습니다
'프로젝트 회고' 카테고리의 다른 글
[PliP] 프로젝트 회고 (4) | 2023.07.25 |
---|---|
[ShoppingApp] 프로젝트 회고 (3) | 2023.05.19 |