[6~7주 차] 달려보자 스프린트!!! (feat.첫 야근)

 

안녕하시렵니까🙇‍♂️  어김없이 6-7주 차 회고가 찾아왔습니다!

아.. 또 밀려버렸습니다. 한 주에 한 편씩, 주 회고를 목표로 했으나 눈 한 번 깜빡👀하니 2주 차 더라고요 ㅋ...

변명 아닌 변명, 핑계 아닌 핑계를 해보자면! 저번 주부터 새로운 스프린트가 시작되며 굉장히 바쁜 한 주를 보냈기 때문에 회고 쓸 시간이 없었습니다 ㅠ 그래서 이번 회고는 '스프린트'에 대한 경험과 느낀 점을 중심으로 풀어볼 예정입니다! 그럼 시작해 보죠!

 

 

스프린트? 그게 뭔데요!

저희 팀은 서비스의 방향성과 그에 따른 우선순위를 두어 feature 개발을 스프린트 단위로 진행하고 있는데요, feature 주제가 정해지면 각 시나리오를 기획하고 최종 선정된 시나리오를 바탕으로 본격적으로 파트별 스프린트를 시작합니다. 이때 WBS를 설정하게 되는데요,

WBS는 Work Breakdown Structure의 약어로, 프로젝트의 전체 업무를 분류 및 구분해서 더 세부적인 작업으로 나누고 일정을 설정하는 작업 분할 구조도를 의미합니다! 이 과정을 통해 프로젝트 관리자는 프로젝트의 진행 과정을 쉽게 파악할 수 있고 조율할 수 있죠.

이번 스프린트에서 FE팀의 task는 크게 3가지로 API 명세 작성, API 구성, API와 화면 연동이었는데 이 중에서 저는 `API 구성` 작업을 맡게 되었습니다. API 구성? 흠.. 그게 뭐지.. 란 생각이 들었지만 일단 WBS에 맞춰 task 일정을 설정했습니다. 살짝 설명을 들어보니 꽤나 간단한(?) 작업인 것 같아서 좀 어려워 보이는 제목의 task를 제외한 대부분의 task의 일정을 30분으로 설정했습니다. 

아.. 안돼 과거의 나 멈춰..

 

 

첫 야근, 두 번째 야근, 세 번째 야근..

스프린트는 본격적으로 월요일에 출발했습니다. 와아아~ 스프린트를 처음부터 제대로 진행했던 건 처음이었기 때문에, 약간 설레는 마음을 안고서 업무를 시작했습니다 ㅎ 기존의 작성된 코드를 참고하며 모르는 부분은 질문하기도 하면서 첫 task를 시작했는데.. 어라?

 

 

첫 task를 끝냈는데 오후 3시 30분이었습니다; WBS로 설정한 오늘의 task는 총 8개.. 퇴근까지 남은 시간은 2시간 30분.

이때부터 뭔가 잘못됐음을 직감할 수 있었습니다 🙈 6시까지 완료한 task는 2개였고, 내일은 또 내일 할당된 task가 있기 때문에 이대로라면 계속해서 밀리는 게 뻔했습니다! 그래서 퇴근은 잠시 접어두고 입사 후 첫 야근을 하기로 마음먹었죠! 사실 10분 ~ 20분 정도는 여러 번 했었는데 본격적으로 야근을 하는 건 이번이 처음이었어요. 그렇게 나머지 task를 끝내기 위해 남아서 고군분투했습니다! 하지만 아직 익숙하지 않아서인지 10시가 넘어서도 끝날 기미는 보이지 않았고.. 막차는 타야 했기에 일단 퇴근 후, 집에서 추가로 작업해서 새벽이 되어서야 오늘의 task를 마무리 지을 수 있었습니다 🫠

 

그다음 날에도, 그 다다음 날에도 6주 차에는 야근이 이어졌지만..ㅎ.. 그래도 주 후반으로 가면서 조금은 익숙해져서 훨씬 빠르게 task를 마무리 지을 수 있었습니다..! 파트장님께서는 일정을 미뤄도 괜찮다고, 집 가서 작업하지 말라고 극구 말리셨지만, 오늘 할당된 작업을 마무리 짓고 싶은 욕심에 그럴 수가 없었습니다 ㅠ 여담으로.. 최대한 알림이 안 가게 하려고 했으나 PR 등록할 때 gmail 알람은 계속 갔더라구요 파트장님 죄송합니다 ㅠㅎ

 

 

스프린트 후반 - 2주 차

스프린트 첫 주와는 다르게 2주 차는 평화롭게 지나갔습니다. 야근 없이 그날의 할당량을 채울 수 있었고, 오히려 간간히 수정되는 명세에 따른 refactoring 작업이 주가 되었습니다. 그리고 스프린트가 후반으로 갈수록 작업했던 파일이 많아지면서, 처음에는 괜찮았지만 점점 혼동을 줄 수 있는 이름의 파일들이 생겨나 네이밍을 수정하는 작업과, 코드를 수정하고 병합하면서 못 보고 지나친 실수들이 없는지 전체적인 검수를 진행했습니다. 약간의 여유가 생기면서 추가적으로 할 일을 찾던 중, 작업을 진행하면서 prettier와 eslint 설정이 없어서 불편했던 기억이 생각나 파트장님께 말씀드렸더니,

 

그거 저도 불편했었는데, 이번 기회에 한 번 맡아서 적용해 보실래요?

 

 

파트장님께서도 불편했었는데 이번 기회에 한 번 맡아서 적용해보지 않겠냐라고 의뢰(?)를 주셨습니다. 그래서 본격적으로 의뢰를 해결하기 위해 작업에 착수했죠! 이번 스프린트는 Admin 프로젝트인데, Svelte와 tailwindcss를 사용하고 있어서 기존의 알고 있던 React/Next.js + @의 prettier & eslint 적용과는 차이가 있었습니다. 일단 제가 Svelte에 관해 잘 알지 못했어서 Svelte의 문법을 prettier와 eslint가 잘 이해하고 실수 없이 formatting 할 수 있도록 공식문서, 블로그를 많이 찾아봤습니다. 그렇게 열심히 정보들을 모아서 필요한 패키지들을 설치, prettier config 설정, eslint rules 설정 등등을 마치고 테스트를 해보니 정상적으로 동작함을 확인할 수 있었습니다! 🎉 이제 코딩할 때마다 큰 따옴표, 작은따옴표에 대한 고민, 공백 등등에 관한 스트레스에서 해방!

 

 

+ Git Alias 공유

이번 스프린트를 진행하면서 prettier & eslint의 부재 말고도 불편했던 점이 있었는데요, 바로 반복적인 타이핑이었습니다!

그중에서도, git 명령어가 특히나 반복적인 타이핑의 끝판왕이라고 느껴졌어요. 자주 사용하는 git 커맨드는 사실 정해져 있어서, 명령어가 길다면 계속해서 불편함을 감수하고 타이핑할 수밖에 없는데요, 이 불편함을 해소하고자 명령어를 원하는 형태로 축약할 수 있도록 도와주는 git alias를 설정했습니다. 결과는 대만족! 그래서 이미 알고 계실지도 모르지만, 개발 팀원들에게 제가 사용하는 git alias를 정리해서 공유드렸습니다. 혹시 코딩하시면서 아직 적용 안 하셨다면 무조건 설정하시는 걸 추천드립니다!

 

따봉 5개!

6-7주 차 느낀 점

제대로 처음부터 스프린트를 진행했던 건 이번이 처음이라, 인상 깊었던 2주가 아니었나 싶네요. 다음 스프린트에는 WBS를 좀 더 여유 있게 설정하자..라는 교훈도 얻었구요! 좀 더 업무적으로 느낀 점이 있다면, 새로 생성하는 branch, 파일들이 많아지다 보니 명세가 바뀌거나 추 후에 수정이 필요한 순간이 오면, 해당 브랜치를 찾고, 파일을 찾기 위해 노션과 PR을 계속 들락날락거리면서, 소요되는 시간이 꽤나 많았습니다. 그래서 다음 스프린트부터는 새로 생성하는 브랜치와 파일들을 나중에도 쉽게 찾을 수 있도록, 그때 그 때 문서화 해야겠다고 생각했습니다. 또 API 명세 - API 구성 - API와 화면 연동의 긴밀한 task flow를 경험하면서 전체적인 흐름을 파악할 수 있는 계기가 됐어서 좋았던 것 같습니다.

 

상상하는 다음 주 내 모습

스프린트 후반을 실수 없이 잘 마무리하면서 팀에게 기여할 수 있는 어떤 무언가가 또 없는지 찾아봐야겠습니다!