당최 회고를 잘 적지 않았지만, level1, level2에 무엇을 했는지 돌이켜 보면 잘 기억에 남지 않기도 하고 주변 사람들도 열심히 적고 있어서 그것에 영향을 받아서 회고를 적어보고자 합니다.
우테코 level3는 팀 프로젝트 입니다. level2때 만들고 싶은 기획서를 작성한 뒤, 코치들의 검열을 통해 뽑힌 약 40여개의 기획서를 발표해서, 인기 투표로 뽑힌 기획이 level3의 기획 초안이 되는 형식입니다. 팀 배정은 기획자를 제외하고 랜덤이고 본인이 투표한 기획에 뽑히지 않을 수도 있습니다. 저는 식물 관리, 카페 쿠폰, 전기차 충전소 지도 이렇게 3개의 기획에 투표를 했었습니다. 그리고 운이 좋게도 저는 원했던 기획인 ‘식물 관리’팀에 배정이 되면서 시작부터 운이 좋았습니다.
레벨 3는 크게 4개의 챕터로 이루어져 있습니다. 각각의 챕터는 2주 기간을 가지고 2주 마지막 금요일에 ‘데모데이’를 진행합니다. 특별할 건 없고 해당 주차동안 우리 팀이 어떤 것을 했는지 코치들앞에서 발표하는 시간을 갖습니다. 그리고 데모데이 까지 수행해야 하는 최소 충족 요건들이 있습니다.
1차 스프린트
요구 사항
공통
- 프로젝트 설명
- 팀의 문화/원칙
- 사용자 스토리 & 기능 명세 공유
- 기능 명세 전체를 발표하기 보다, 제출한 기능 명세 중 서비스의 "핵심 기능(가치)" 를 발표한다.
프로젝트 세팅
- Webpack 기반의 React & TypeScript 환경 세팅
- 개발(코드 컨벤션 등) 문서 만들기
- 서비스 타겟 환경 및 브라우저 지원 범위 선정
- 스타일링 방법 선택 및 이유 정리 (기술 사용 가이드 참고)
팀 빌딩
팀 빌딩은 랜덤으로 뽑한 6명과 기존 기획자 1명해서 총 7명이서 앞으로 한 팀이 되는 것이고, 팀만의 독자적인 개발 문화와 코드 컨벤션, 그라운드 룰을 정하는 과정입니다.
저희 팀이 정한 그라운드 룰은 다음에서 볼 수 있습니다.
- 책임은 모두의 책임
- 정시 출근(10:00) 정시 퇴근(18:00). 지각시 10분당 5000원
- 매일 2회 데일리 미팅 진행
- 부정적인 언어 지양
- 꾸준히 기록하기 (팀 블로그)
프로젝트를 몇 번 해봤지만 시작하기 전에 사전에 모든 규칙을 정하고, 브랜치 정책 등을 정하고 하는 것은 처음이었습니다. 처음 해보는 경험에 두려움이 있으면서도 새로운 것들에 대해 알아가는 기분이 너무 좋았습니다.
위와 같이 팀 규칙을 만들었고, 이제 본격적으로 기획을 할 단계입니다. 기획의 최초 지점은 ‘식물을 잘 키우자’ 였습니다. 이를 통해 단순히 물주기 알림이 있으면 되겠다고 생각을 했고, 그 아이디어를 토대로 서비스를 기획해 나갔습니다. (기획 단계 아이디어 도출 과정)
하지만, 사용자의 진짜 문제점을 파악하지 못한 채로 이러면 되겠지? 라는 생각을 가지고 기획을 해서 그런지 뭔가 특별한 차별점이라던지, 명확한 문제점을 파악하지 못하고 있다는 생각을 했습니다. 가장 큰 문제는 팀원들 중에서 식물에 관심을 갖고, 식물을 키워본 사람이 없다는 점이었습니다. 따라서, 같은 크루원들 중에서 식물을 키우는 크루원들을 수소문 해서 짧은 인터뷰를 진행했습니다.
식물을 키우는 사람들이 느낀 가장 큰 문제점은 “물 주기를 찾기 어렵다.” 였습니다. 같은 식물이라도 키우는 환경에 따라 물 주기가 서로 다른데, 이를 기억하고 기록하기 어렵다는게 식집사들이 말한 공통된 문제였습니다. 또한, 식물을 몇 번 떠나 보내면서 알게되는 지식들도 많다고 했습니다. 따라서 저희는 “각각의 식물의 주기를 찾기 편하게 해주고, 식물의 관리 이력을 살펴볼 수 있도록 하는 서비스를 만들자” 라는 생각으로 ‘피움’을 기획했습니다.
초기 세팅
초반 세팅 과정은 webpack으로 React 구축하기와 환경 설정에 그 과정을 적었습니다.
1차 데모데이때는 앞으로 구현할 서비스에 대해 소개가 중점이 되었고, 코치들의 질의응답도 기획과 팀 문화와 관련된 부분이 많이 있었습니다. 저희 팀은 나름 기획을 탄탄하게 작성했다고 생각해서 나쁘지 않게 발표했습니다.
2차 스프린트
요구 사항
공통
- 지난 2주간 진행한 프로젝트 요구사항 적용 결과 공유
- 2주동안 구현한 핵심 기능 발표
- 3차 스프린트에서 구현할 핵심 기능 목록 공유
프로젝트 세팅
- 프론트엔드 리소스 빌드 및 배포 환경 구축 (AWS)
- 테스트 전략 수립 및 자동화된 테스트
본격적으로 개발을 하기 전에 인프라 구축을 하는 단계입니다. 서비스를 배포와 테스트 자동화를 통해 (CI/CD) 앞으로의 개발 일정에 큰 차질이 없도록 구축하는 단계입니다. 이 단계가 중요한가? 라는 생각이 들 수도 있지만, 배포 서버에 올라가는 코드의 품질과 신뢰성 측면에서 매우 필요한 단계라고 생각했습니다. 결국 서비스를 배포한다는 것은 검증된 코드가 올라가는 것을 의미하는 것이고, 배포를 할 때마다 테스트를 통해서 해당 코드의 신뢰성을 테스트 하는 것이 좀 더 완성된 서비스를 제공하는 것이라 생각했습니다.
말은 이렇게 썼지만 사실 CI/CD를 한번도 해본 적이 없기 떄문에 좀 많이 막막했습니다. 서버에 빌드해서 배포한다는 것도 어떤 의미인지 잘 모르겠고 젠킨스는 뭐고 AWS를 통한 배포는 어떻게 하고… 예전에 해본 적은 있지만, 그냥 gh-pages나 netfily를 통해서 자동화 한 경험 뿐 주체적으로 직접 해본 경험은 없기 때문에 두려움이 조금 앞서있었습니다.
다행히 CI/CD 구축은 쉽게(?) 끝낼 수 있었습니다. 바로 백엔드에서 배포 자동화를 해 놓았고, 저희는 백엔드에서 작성해 놓은 코드를 프론트에 알맞게 변경하는 것과 스토리북 배포된 파일을 ec2에 올리도록 처리해 주면 됐습니다. 인프라에 대해서는 진짜 겉핥기 수준으로만 지식을 얻어서 그런지 레벨4때 좀 더 깊게 공부해 봐야 할 것 같습니다.(백엔드 분들 감사합니다.)
저희는 2차 데모데이때 까지 정말 간단한 사전 식물 검색과 상세 조회만을 제공하기로 일정을 추산하고 개발을 했습니다. 어느정도 프로젝트 세팅과 기획 보강 회의(진짜 하루종일 회의만 함…) API 명세 작성 등에 시간을 쏟느라 간단한 기능 개발도 빠듯했습니다.
단순히 검색창 구현과 식물 등록 상세페이지 마크업 작업 뿐이었지만 시간이 상당히 많이 들었습니다. 왜 그렇게 시간이 많이 들었나에 대해 나름 생각을 해봤는데, 개발을 bottom-up 방식으로 진행해서 그렇게 된 것 같습니다. 첫 번째 기능을 할 때는 완전히 CDD 그 자체로 개발을 진행했는데, 컴포넌트 분리가 쉽지 않고 공용 컴포넌트를 만든다는 것 자체가 상당히 까다롭고 시간이 많이 걸리는 일이었습니다. 제가 input 컴포넌트를 만들어도 상태관리와 쓰임새에 따라 props가 변경되어야 하는 일이 있었기 때문에, 결국 마지막에 전체적으로 변경이 되었습니다. 범용성 있는 컴포넌트를 만들고자 했지만, 그저 희망 사항으로만 끝나버렸기에 좀 아쉬웠습니다. (실력의 부재인가 싶기도 합니다.)
어찌됐든 2차 데모데이도 별 탈 없이 잘 마무리가 됐습니다.
3차 스프린트
요구 사항
- 웹 표준 준수 및 시맨틱 태그 사용
- 웹 접근성 관리 대상 선정 및 개선
3차 데모데이 권장 요구사항은 웹 표준 준수하기 였습니다. 웹 표준.. 사실 들어만 봤지 별로 중요하게 생각하지 않고 시맨틱 태그만 잘 사용하면 되는 것인줄 알고 있었습니다. 하지만 웹표준을 준수하며 코드를 개발하기는 생각보다 쉽지 않았고 할것도 많이 있었습니다.
웹 표준은 웹 기술과 관련된 가이드라인 입니다. 이를 통해서 웹 접근성과 호환성을 향상시킬 수 있습니다. 데모데이 요구사항에는 서비스의 핵심이라고 생각하는 기능을 웹 접근성을 통해 구현해 보는 것이었습니다.
웹 표준에 대해서 알아보기 위해서 제일 처음 한 것이 시맨틱 태그에 대해서 알아본 것이었습니다. 사실 어떤 태그가 있는지만 알고 있고 정확하게 어떤 곳에 활용해야 하는지 몰랐지만, 이번에 코드를 작성할 때 의식적으로 알맞는 시맨틱 태그 사용하기 위해 노력했습니다. 또한, 색 비율도 1:4.5를 맞춰야 하고, 이미지 alt 작성과 wai-aria에 관련된 지식도 상당히 많이 얻을 수 있었습니다.
3차 스프린트를 하면서그리고 가장 큰 변수가 하나 있었는데, 바로 코로나였습니다. 팀원이 걸리고 제가 걸리면서 프론트에 악재가 겹치게 되었습니다. 거의 3일을 날렸고 정신이 좀 들었어도 컨디션은 여전히 좋지 못했습니다. 그 와중에 리마인더에서 날짜 선택을 하는 옵션을 처음에는 <input type="date" />를 사용함으로써 손쉽게 가려고 했는데, 접근성 테스트 하던 도중 날짜 선택을 할 때 tab을 통해 이동을 하는데 바로 날짜가 나오지 않고 바로 선택 되어버리는 문제가 발생습니다. input을 통해서 해결이 할 수 있나 하고 방법을 찾아봤지만, type이 date인 경우에는 event가 change밖에 적용이 되지 않았습니다. 따라서 빠르게 달력 컴포넌트를 만들었습니다. 코로나로 인한 재택을 해서 좀 더 집중할 수 있었던 것 같긴 합니다.
요구 사항에 백엔드와의 협업이 같이 있었는데, 해당 요구 사항은 CI/CD에 대한 개념 설명을 함으로써 해결했습니다. 일방적인 배움의 시간이었지만, 인프라에 대해 많이 모르고 있던 찰나에 많은 도움이 되었습니다.
데모데이때 협업 과정이 제대로 이루어 졌는지 확인하기 위해 코치가 인프라 구조를 그려보는 시간이 있었는데, 이 때 다같이 나가서 살펴보는게 약간 “동료”가 된 느낌을 받았습니다. 이렇게 3차 데모데이도 끝났습니다.
4차 스프린트
요구 사항
- development/production 빌드 및 배포 환경 구분
- 시멘틱 버저닝, 사용자가 가장 최신 배포 버전을 항상 바라볼 수 있도록 세팅
4차 데모데이때 저희가 개발할 기능들은 캘린더와 로그인 기능이었습니다. 하지만 초반 회의에서 캘린더 기능이 과연 필요할까? 라는 이야기가 나왔고, 회의에서 캘린더 기능 보다는 식물 상세 내역 고도화가 좀 더 필요할 것 같다는 이야기가 나왔습니다. 또한 저희가 3차 스프린트까지 거의 리팩터링을 하지 않고 달려왔기 때문에 공통으로 사용하는 타입과 api의 컨벤션 통일이 필요했습니다. 이 부분은 약간 재미있게 3명이서 페어(?)프로그래밍을 통해서 해결했습니다.
공통 리팩터링을 제외하고도, 짜잘한 리팩터링 사항들이 많이 있었습니다. 관리이력 고도화, 짜잘한 리팩터링, 로그인 이 3가지 중에서 제가 맡은 역할은 ‘로그인’ 기능이었습니다. OAuth를 뭔가 제대로 해 본 기억이 없어서 해보고 싶은 기능이었는데, 운이 좋게 맡게 되어서 기분이 좋았습니다. 덕분에 OAuth에 대한 이해를 얕게나마 할 수 있었습니다.
dev와 prod 빌드 및 배포 환경 구분 역시 얕게나마 경험해 봤는데 쉽지 않았습니다. 가장 필요한게 환경 변수로 설정한 KEY값들과 API HOST 주소인데, 각각을 로컬, 개발, 배포로 나누어서 값 변경이 필요했습니다. 저희는 env파일을 나눠서 webpack내부에서 빌드 할 당시에 설정한 값을 기준으로 환경변수 설정과 배포 환경을 구분했습니다. 이 과정에서 참새가 좀 많이 고생을 했습니다.
8주차에 접어들고 로그인 기능을 완료한 다음에 한 2일 정도의 시간이 있었는데, 이 때 좀 시간이 붕 뜬다는 느낌이 들었습니다. 무엇을 해야할지 모르겠고 갑자기 모든게 귀찮아(?)지기 시작했습니다. 8주동안 쉬지않고 달려와서 체력적인 한계도 부딪힌 것 같았습니다. 일정 추산이나 업무 분배가 좀 더 잘 되었으면 좋겠다고 생각을 하면서도 내가 할 일을 좀 더 찾아서 해보면 어떨까 하는 생각도 했습니다. 레벨4에서는 좀 더 주체적으로 할 일을 찾아서 해봐야 겠습니다.
4차 스프린트는 데모데이가 아닌 론칭 페스티벌을 했습니다. 각자 만든 서비스들을 홍보하는 시간을 가졌는데, 이제 크루와 코치들이 서비스를 사용해보고 피드백을 남겨주는 방식으로 진행했습니다. 다른 팀들이 만든 서비스를 보니 신기하면서도 대단하다는 생각도 들었습니다. 포비가 와서 피드백(?)을 하는 스티커를 붙여줬는데, 우리 팀은 6개를 받는 쾌거(?)를 이룰 수 있었습니다.
그렇게 2달동안 열심히 달려온 레벨3가 끝이 났고 팀원들과 회식 후에 헤어졌습니다. 프로젝트를 여러번 해봤지만 이렇게 만족도가 높았던 팀 프로젝트는 처음이었습니다. 팀원들과 잘 맞기도 했고, 소통도 잘 되고, 뭔가 생각의 싱크가 잘 맞아서 소외(?) 혹은 방치(?)된다는 느낌도 없어서 더욱 그랬던 것 같습니다.
