우테코: Level3 2차 스프린트 기간 회고

2차 스프린트. 그러니까 2차 데모데이가 종료되었는데 까먹고 작성하는 것을 놓쳐버렸다.. 그래서 지금이라도 작성해본다.

2차 스프린트 시작과 함께 우테코 해커톤

스크린샷 2024-08-06 19 13 58

2차 스프린트가 시작되는 7월 15일 월요일. 우테코에서 처음으로 개최한 해커톤이 진행되었다. 해당 해커톤 기간은 우테코에서 유일하게 밤을 샐 수 있는 기회라고 하셨다. 그래서 이런 기회를 그냥 놓칠 수 없는 나는 월-화 캠퍼스에서 자기로 결정했다.

아침 데일리 스크럼 시간에 우리 프로젝트의 핵심 기능은 어떤 것일지 꽤 긴 논의를 거쳤다. 그러면서 필요없는 기능도 쳐냈고 가장 우선순위를 두어야 할 것이 무엇인지 알 수 있었다. 또한, 각자 같은 기능에 대해서 다르게 생각하는 것들이 존재했기에 컨텍스트를 맞출 수 있었다.
생각보다 같은 기능을 다르게 생각하는 것이 많다는 것을 이 일을 계기로 처음 알게 되었다. 팀원들과 컨텍스트를 맞추는 것이 중요하구나를 페어 미션 이후에 또 느끼게 되었다.

스크린샷 2024-08-06 19 13 58 스크린샷 2024-08-06 19 14 10

우리 팀의 핵심 기능 단위는 “행사 정산 기능”으로 정했다. 지난번에 설문을 통해 사람들에게 행사를 진행/참여하면서 가장 필요하다고 느끼는 것이 어떤 것인지 물어봤었다. 그 중 가장 많은 비율을 차지한 것이 정산과 관련된 것이었다. 물론 정량평가이긴 했지만, 이 문항들도 팀원들이 직접 공통적으로 느꼈던 부분들을 추린 것이기 때문에 나름 신빙성이 존재하는 결과라고 생각한다. 따라서 위에 말한 “행사 정산 기능”을 우리의 핵심 기능 단위로 정했다.

이렇게 우리 팀의 핵심 기능 단위를 정했고 백엔드와 프론트엔드 각자 해커톤 기간동안 할 일을 정했다. 프론트엔드는 최소 기능을 담는 페이지 퍼블리싱을 완료하고자 했다. 이 Task를 각각 2명씩 나눴다. 디자인 시스템 담당 2명과 퍼블리싱 담당 2명으로. 퍼블리싱을 담당하는 팀이 디자인 뼈대만 잡아두고 기능을 구현하면 추후에 디자인시스템 팀에서 만든 컴포넌트를 붙이는 형식으로 진행하고자 했다.

이렇게 디자인시스템까지 들고 가게된 이유는 해커톤을 위해 코드를 얼렁뚱땅 작성하지 말자고 이야기를 나눴다. 시간에 쫒기고 싶지 않아서 내린 결론이었다.
하지만 돌이켜보면 우리가 했던 것은 그저 밤새 개발이었지 해커톤은 아니었던것 같다는 생각이 든다. 돌아가는 쓰레기를 만들어두고 나중에 리팩토링을 작업하는 것이 더 좋았을 수도 있겠다라는 생각이 드는데.. 그 당시에는 리팩토링을 하는 것에 겁을 먹었던 것 같다.

그래서 일단 결과적으로 2명씩 나눠서 Task를 맡았던 것은 사실 그닥 결과는 좋지 않았다. 디자인시스템을 배포하는 과정에서 문제가 발생하여 결국 퍼블리싱 페이지에 디자인시스템을 붙히지 못했다. 그래서 우리는 뼈대만 존재하는 페이지로 시연을 진행해야 했다.. 하하

스크린샷 2024-08-06 19 13 58 <img align="center" width="50%"" alt="스크린샷 2024-08-06 19 13 58" src="https://github.com/user-attachments/assets/ddfd0532-8cde-46dc-bf1a-f3fabf3cb37e"/>

우테코에서 제공한 해커톤 저녁 및 간식

일 작업 방식을 바꿔보자

해커톤 기간 동안에 페어로 개발을 진행하면서 효율적이지 않은 것 같다는 생각이 들었다. 사실 1박 2일이라는 짧은 기간이기 때문에 코드 컨텍스트를 맞추고자 페어로 진행한 것도 있다.
그래서 이번에는 각자 Task를 나눠 개발을 진행하기로 했다. 각자 구현해야 할 기능들을 나눴고 정한 due date까지 기능 구현을 완료해 와야 했다. 이 방식으로 바꾼 후에 나는 굉장한 스트레스에 휩싸였다..

일단 내가 스트레스에 받게 된 이유를 정의하자면 다음과 같다.

  1. 정해진 기간동안 내가 할 수 없는 분량이었다.
  2. 정해진 기간 안에 완료할 수 없다는 생각이 강하게 드니까 압박감이 들었다.
  3. 스트레스를 너무 받다 보니 일 효율이 더 떨어진다.
  4. 기간은 부족한데 일 효율도 안 나니까 더 스트레스를 받는다.

위 1~4번의 무한 반복이었다.
이런 문제점을 깨닫고 due date에 다 못했음을 말했고 기간은 넘겨서까지 일을 진행하게 되었다. 이 일주일도 조금 안되는 기간동안 엄청난 스트레스를 받다 보니 어떻게 이 문제를 해결해야 할지 감이 잡히지 않았다. 그런 순간 포비랑 준과 팀 단위 티타임을 가지게 되었다.

가장 작은 단위로

이 티타임 동안 정말 많은 깨달음과 해결책을 얻었다.
나의 이런 스트레스를 받고 있는 상황을 준에게 이야기하게 되었다. 준은 당연히 현업 개발자도 며칠 뒤의 기간동안의 계획을 세우기는 어렵다고 했다. 그렇기에 하루 단위로 Task를 할당하라고 했다.
Level2 수업에서도 준이 매번 말했던 것은 “가장 작은 단위로” 였다. 그렇다. 일 분배 또한 가장 작은 단위로 나눠서 진행하는 것이 좋은 해답이었다. 그날 할 일을 정하고 그 일을 오늘 안에 끝낼 수 있는지 %를 매겨본다. 80%가 넘는다면 해결 할 수 있는 Task라는 것이다. 80 이하라면 더 작게 나눠서 다시 Task를 만든다. 그렇게 가장 작은 단위 하나를 오늘의 할 일로 할당하는 것이다. 이렇게 일을 분배한다면 Task를 끝냈다는 성취감이 올 것이다.

일을 진행하면서 가장 중요한 것은 성취감인 것 같다. 내가 힘들었던 이유도 아무리 해도 일이 끝나지를 않으니 성취감이 존재하질 않았다. 그러니 더더욱 쳐지게 되는 것이고, 내가 뭘 얼마나 더 해야 할지 감이 잡히질 않았을 것이다. 앞으로는 이런 방법으로 일을 나눠봐야 겠다고 생각했다.

각개전투가 아닌 협업

모두가 공통적으로 생각하는 부분은 협업을 하고 있지 않다고 느껴진다였다. 프론트는 프론트끼리 일을 나눠 작업을 하니 협업하는 느낌이 들지 않았다. 그리고 백엔드와는 일단 통신을 진행하는 부분이 없다 보니 백엔드와 협업한다는 느낌이 들지 않았다.

그렇기에 우리는 다음과 같이 작업을 바꿔보자고 결론을 내렸다.
프론트엔드 2명씩 짝 지어서 기능을 개발해보자. 그리고 백엔드 2명과도 한 팀이 되어 기능을 구현해보자. 아직 이 방법을 실천하는 것은 2차 데모데이가 종료되고 스프린트3 기간에 진행하자고 논의를 마쳤다. 해당 방식을 사용한 부분에 대해서는 3차 스프린트 회고에 적도록 하겠다.

2차 데모데이

하기 전에 일단 회식

스크린샷 2024-08-06 19 13 58

2차 데모데이 전날인 목요일.. 우리는 우리가 개발한 기능을 데모데이에 보여주기 위해서 전날 회식하고 직접 사용해보자고 하였다. 그래서 우리는 배포한 서버가 백호 말고 아무도 접속할 수 없는 상황임에도.. 냅다 회식을 했다. 그래도 우리 팀이 화목한 것 같아서 좋았다.

“초기 기획 및 구현은 이렇게 하는걸 의도한 것이다.”

우리 팀이 듣게 된 최고의 칭찬이다. 앞으로도 이 칭찬을 뛰어 넘을 것은 사실 없을 것 같다.

스크린샷 2024-08-06 19 42 48

데모데이는 2시라서 그 전까지 목요일에 해결하지 못한 서버 접속 에러를 해결하고 자잘한 디자인 및 기능을 수정했다. 다행이도 데모데이 전에 무사히 해결하여 코치님들 앞에서 시연을 할 수 있었다.

시연을 진행하면서 참석해주신 코치님(포비, 준, 브라운, 레아)들에게 극찬을 받았다. 가장 작은 단위의 핵심 기능을 잘 구현해온 팀이라고 해주셨다. 그리고 이미 완성도가 높다고 해주셨다. 이런 칭찬을 받으니 그간 기획에 대해 오랫동안 회의한 보람을 느낄 수 있었다. 기능 개발을 한 기간은 그리 길지 않음에도 만족시킬 수 있다니.. 모두가 오래 회의를 진행한 보람이 있었다.

그리고 내가 프로젝트를 진행하면서 걱정한 부분이 있었다. 바로 우리 프로젝트는 행사를 위한 프로젝트인데 너무 정산에 초점이 맞춰진 것 아닌가? 처음 기획 의도에서 좀 벗어나게 된 것 같다는 생각이 들었다.
이런 생각에 대해 여쭤보니 오히려 좋은 방향이라고 말씀해주셨다. 그렇게 좀 다른 방향으로 프로젝트가 흘러가게 되어도 좋게 서비스가 발전해나가고 있다는 것이니까 괜찮다고 본다!

2차 스프린트를 마치며

사실 2차 스프린트 2주의 기간동안 지옥과 천국을 맛 보았다.
개인적으로 스트레스를 너무 많이 받아서 너무 힘들었기도 했지만 티타임을 기점으로 멘탈을 회복하면서 데모데이에 칭찬을 받으며 천국을 맛 보았다.

또한, 1차 스프린트와는 다르게 프로젝트 진행 방식을 개별 기능 구현으로 변경했는데 이것 또한 문제점이 많이 보여서.. (시간이 부족하니 제대로 리뷰하지 않고 그냥 무작정 approve하기, due date에 치이기 등 ) 다음 스프린트에는 또 다시 페어로 돌아가게 될 것 같다. 이렇게 진행 방식을 바꿔가며 우리 팀에게 맞는 방향을 찾아가는 것이겠지 뭐 ~

Comments