[우테코 Level 3] 3주차

해커톤

우테코 최초로 해커톤이 개최됐다. 6기에 새로 시도되는 것이 많다고 느꼈는데 해커톤이라니 또 한번 예상치 못했던 행사였다! 주제는 현재 팀 프로젝트의 핵심 기능 하나를 구현해서 시연하는 것으로, 월요일 아침을 시작으로 화요일 오후 2시에 시연하는 일정이었다. 해커톤을 나가본 적이 없어서 인생 첫 해커톤이기도 하고, 우테코 캠퍼스를 심야 시간에도 사용할 수 있게 하는 경우도 처음이라고 해서 이래저래 설렜다.

하지만 생각보다 시간 관리가 어려웠던 것 같다. ERD 구조는 처음부터 잘 잡아놔야 나중에 수정 사항이 적지 않을까? 하는 생각으로 하다보니 초반의 기반을 잡는 과정이 오래 걸렸던 것이다. 결국 11시까지 기능 구현을 마치지 못했다. 하지만, 다들 캠퍼스에서 밤을 새는 건 컨디션상 안좋을 것 같다고 생각해서 아쉽게도(?) 밤을 새진 못했다. 결국 각자 집에 가서 원격 페어로 기능 구현을 마무리했다.

다음날, 프론트와 백을 합치는 과정에 오류가 있었고 시연 시간 내에 해결하기 어려웠다. 따라서 아쉽지만 프론트, 백의 결과물을 따로따로 시연하게되었다😂 포비가 이런 상황에 대해서 찐한 협업의 부족이라고 언급하면서 이 시간 관리, 협업에 대해 다시 생각해보게되었던 것 같다. 그래서 팀끼리 회고 시간에 이에 대해 이야기를 나눠보았다.결론적으로는, 우리팀만의 ‘단기 스프린트’를 만들어서 자주 합쳐보자는 새로운 액션 플랜을 만들게되면서 해커톤이 마무리되었다!

항상 드는 생각이지만 팀 프로세스의 방향성을 잘 잡아가는 것이 제일 어려운 것 같다. 이렇게 포비, 코치들이 중간 중간 잡아주고, 또 팀끼리 회고하면서 계속 잡아가다보면 어느정도 잘 잡아갈 수 있지 않을까 생각한다!

기능 구현 시작

해커톤을 시작으로 본격적인 기능 구현을 하기 시작했다. swagger 적용(페어), 리뷰 그룹 검증(개인) 등의 기능을 맡아서 했었었다.
그러면서 코드 리뷰도 본격적으로 시작했는데 좋은 점을 많이 느꼈다.

1. 내 코드의 오류를 잡고 발전시킬 수 있음
2. 내가 구현하지 않은 우리 코드의 전반을 계속 파악할 수 있음
3. 다른 사람의 코드를 이해하다보니 관점이 넓어짐 등이 있었다.

다만, 구현이든 코드리뷰든 내가 스스로 속도가 빠르지 않은지라 여기서의 시간 관리가 조금 어려웠다.

1. ‘니가 짠 코드 내 코드처럼’이 우리팀의 기조라 더 꼼꼼하게 코드를 이해하고 리뷰하려고 했기 때문에.
2. all aprove를 받아야 merge되는 방식이기때문에, 팀원 코드 리뷰 + 내 리뷰 반영 + 답 리뷰… 의 프로세스가 꽤나 시간이 걸렸던 것 같다.

그래서 이 정신없는 과정 속에서 허덕이며 ‘난 왜 이렇게 오래 걸리지.. 팀에게 피해주는 건 아닐까..’하며 우울감이 들기도 하는 요즘이다.

스프린트 진행 방식 ver 2.0.0

주말에 테드랑 리뷰어 그룹 기능 구현을 페어로 하려다보니 문제가 생겼다. 생각해보니 이 기능에 대한 와이어프레임이 없었던 것이다. 와이어프레임이 없으니 주고받은 API 문서, 기능 명세도 없었고, 그러면서 뭔가 우리팀의 작업 순서가 제대로 잡히지 않았다는 생각이 들었다.

그래서 이김에 테드와 우리팀의 작업 진행 방식과 순서를 깊게 생각해보고 액션 플랜을 하나 만들어서 제안해보기로했다.

우선 현재 느끼는 문제점을 정리해보았다.

1. 기능 별로 와이어프레임을 만들어서 백이 전달받으니, 와이어프레임 없이 기능 구현을 하게되는 상황이 발생한다.
2. 각 기능별 예외 검증 사항 정리된 게 없다.(현재, 이슈에 산발적으로 분포) QA 리스트가 필요하다.
3. 프론트와 백이 함께 볼 수 있는 와이어프레임+기능명세 역할의 문서가 필요하다.

정리해보니 우리에겐 1. 문서(와이어프레임+기능명세/ QA용)와 2. 이 문서를 합의해서 만들기 위한 회의가 필요했다는 결론을 얻게되었다. 물론 문서화와 이를 위한 회의에 시간이 꽤 걸릴 것이라는 걱정도 있지만 적응되면 속도가 빨라질 것이고, 실제 현업 구현 사이클을 경험해본다는 점에서 의미있는 시도라고 생각한다!

역시 작업 프로세스 만들기가 제일 어려워😇  이 프로세스는 또 어떤 결과를 가져올지 궁금하다! 일단 해보자!