일주일 간 이루어진 미니 프로젝트가 마무리됐다.
정말 후련하기도 하고 오늘 발표 자료를 준비하면서 사실
"다른 조에 비해 형편없어서 일주일간 스크럼이니 회고니 하며 조율한게 물거품으로 돌아가지 않을까?
다른 조의 작품을 본 적이 없으니 이런 생각도 살짝 들었는데 돌이켜보면 가장 핵심으로 여겼던 협업과 소통의 시작 이라는 가치를 굉장히 살리려고 노력해서 쌩고생 머지와 리뷰와 회의를 거쳤던 것이니 발표 하기도 전에 성공했다고 여기기로 했다.
천만 다행히도 전체 발표는 무사히 마무리 됐고 핵심으로 여겼던 협업과 소통 과정 또한 매니저님과 튜터님의 긍정적인 피드백을 많이 받아서 우리 조의 텐션도 정말 많이 올라갔다.
나도 그렇고 첫 프로젝트치고 꽤 진지한 일정으로 무거운 마음으로 보낸 일주일이었을텐데도 잘 도와주시고 뛰어난 퀄리티의 결과물을 내주신 팀원분들께 이 감사를 돌린다.
Github pages에 배포하기
Env Secrets 사용해보기 (실패함)
원래 배포 없이 repo 주소로만 제출하려고 했는데 튜터님과 매니저님이 배포된 페이지를 따로 보신다고 하셔서 마감 직전에 부랴부랴 Github pages로 배포를 하기 시작했다.
그냥 하드코딩 했으면 고민할 부분이 없었겠지만 우리 프로젝트는 파일 분리하고 Firebase Key를 .gitignore로 제외했기 때문에 Clone이나 Fork만으로는 안돼서 readme에도 대충 config.js 관련해 가이드를 조금 적었는데 배포를 하게 생겼으니 Github pages가 Secrets를 관리하는 방법으로 environment를 사용해보기로 했다.
문제는 등록한 secrets를 config.js 파일에 KEY값대로 속 편하게 사용이 가능했냐인데 아쉽게도 아니라서 이리저리 구글링과 GPT의 도움을 받아본 결과 github actions 기능에서 사용 가능한 env Workflow를 통해 배포될 때 API Key를 사용가능한 상태로 지정하는 방법이 있었다.
어제는 http-server로 로컬호스트를 처음 열었는데 오늘은 github pages로 정적 호스팅된 페이지에서 secrets를 써야하니 당연히 사전 지식이라곤 부족했고 문법 이해조차 못하는 Workflow를 여기저기서 베껴오고 등록해보니 Action에서는 액션중 뭐가 실패했다고 계속 메일도 날라오고 망했나 싶었는데 process.env.FIREBASE_API_KEY를 불러오는 데까진 어찌저찌 성공했다.
어 이게 왜 되지? 그럼 이제 끝난 거군!
놀랍게도 아니었고 리뷰를 위해 로그를 짜며 테스트를 이어나가다 보니 캐싱 문제(로 추정되는) 일도 겪고 로컬호스트에서 겪은 것처럼 강력 새로고침으로도 왠지 모르게 해결이 되지 않았다. 결국 이거 저거 더 수정하다보니 이거 왜 안되지? 까지 도착했고 결국 Secrets env를 써먹는건 포기하고 FIREBASE_API_KEY를 하드코딩해서 배포하는 걸로 마무리했다.
이게 왜 되지? 단계까지 왔는데 원인 파악도 실패한 건 오랜만이라 어지러웠고 튜터님이나 매니저님께 도움을 처음부터 청했다면 풀었겠지만 실마리를 잡아서 해석할 수 있을지도 모르겠다고 생각한게 하드코딩 배포의 결과로 이어진 것 같다.
시간적 여유가 있었다면 반드시 질문을 드렸을 텐데 이건 추후 백엔드 트랙에서 정적 배포를 할 일이 더 생길지도 모르니 이렇게 기록으로도 남겨두고 마음에도 남겨두기로 했다.
마감 회고하기 - KPT
일주일동안 협업해본 팀원끼리 서로 평가하기
회고 과정에서 긴 수다로 이어지다가 훈훈하게 각 팀원에 대한 평가도 말해보자고 하셔서 팀원분들의 내 평가도 들을 수 있었는데 좋은 점을 말씀해주실 때 특히 조장의 역할을 잘 수행했구나를 느꼈다.
- Git을 그래도 조금 써본 사람이라 Git 기능을 체험하기 위한 설계를 먼저 제시한 덕분에 나중에 다 같이 체험해보며 Git 경험을 많이 쌓을 수 있었다.
- 첫 미니프로젝트에 처음 보는 사람들과 함께 실제로 진행한 협업 경험을 살려서 프로젝트 개발 과정을 짠 리더쉽이 돋보였고 머지 과정에서 Conflict를 해결할 때 쌓여있는 기본기를 많이 볼 수 있었다.
- 하고 싶은 일을 스크럼 때마다 많이 제안했는데도 프로젝트가 무너지지 않고 조율에 성공하고 짬에서 나오는 바이브가 정말 좋았다.
이 다면평가같은 느낌의 칭찬을 듣고나니 이번 프로젝트가 나한테 정말 좋은 경험이 됐다는게 느껴졌다.
이전에 항상 아침 스탠드업 미팅이 되면 억지로 안건을 쥐어짜내고 진척도를 공유하던 소심한 개발자1이 어깨 너머로 배운 기술을 가지고 미니프로젝트의 그림을 매일 체크하며 목표한 바를 초과달성 했다는 게 최고로 만족스러운 부분같다.
이렇게 각자에 대한 회고도 훈훈한 분위기에서 마치고 본격적인 KPT 정리 내용을 간단히 쓰자면:
K (Keep)
- 스크럼, 회고를 통한 진척도 체크로 프로젝트에 대한 몰입도 증가
- 코드 리뷰를 통해서 실력 증진과 개발자간의 소통을 배우고 고민거리도 해결하면서 리뷰를 즐김
- Git을 써서 프로젝트 마감하는 과정까지 체험함
- 단계별 진행으로 기능적 구현보단 공부에 중점을 둬서 복습에 큰 도움이 됨
- 프로젝트 시작부터 설계된 부분이 있어 갈팡질팡하지 않음
P (Problem)
- 코드 네이밍 컨벤션을 정하지 않아서 병합할 때 왜 불편한지 느낌
- 비대면 부트캠프라 몰입감이 아쉬움
- 팀 스케쥴 관리가 잘 되지 않음
특히 휴식을 확실히 정하고 숨을 돌릴 수 있었으면 좋았을 듯 - 첫 주차 미니프로젝트 치고 욕심이 생겨 목표치가 점점 올라감
- 팀 분위기가 조금 딱딱하게 시작함
스크럼, 회고부터 정하고 진행하다보니 사무적인 느낌이 있었음
T (Try)
- ERD Cloud로 조금이나마 Collection, Field 스키마를 명시한 것처럼 코드, Git 네이밍 컨벤션도 프로젝트 시작부터 정해보기
- 단계별 구현은 했으니 기능별 구현으로 Branch도 다른 방식으로 쪼개보고 각자 구현 실력 뽐내기
- Firestore처럼 NoSQL 말고 RDBMS에서 스키마대로 작성해보기
- 운동, 영양제로 부트캠프동안 쓸 체력 증진하기
회고를 보고 든 생각중 하나가 다들 이번 프로젝트 기간동안 몰입해서 즐겨주셨구나를 느꼈던 것 같다. 지루하고 하기싫은 시간이 되었다면 결과가 어찌 되었든 실패였을텐데 좋았던 점도 적극적으로 얘기하시고 아쉬운 점에서도 경험한 점을 많이 말씀해주시면서 다들 개발자스러운 호기심도 많이 생기신 것 같다.
회고는 매일같이 했는데도 KPT로 딱 포인트 집어서 정리하자니 처음 해보는 거라 이게 맞나? 싶었지만 팀원분들 모두 그냥 하던 일처럼 여겨주셔서 편한 분위기에서 KPT 회고를 마감할 수 있었다. KPT 같은 느낌의 회고가 틀에 맞춰서 작성하는 건 아니니 좋은 경험했다고 생각하기로 했다.
그리고 코드카타는 오늘도 갑자기 배포를 진행하게 되면서 여유가 없어져가지고 진행하지 못했다. 아침에 두뇌 회전을 위해 알고리즘 매일 한 문제씩은 풀어보자고 스크럼마다 적은건 나면서 내가 제일 실천을 안했으니 좀 아쉬움이 남는다.
