[회고] 두번째 해커톤, 소통의 중요함을 깨닫다.

이번 회고에서는 대외비 문제로 개발 내용보다는 협업에 대한 회고를 진행해보려 합니다.

📢 블레이버스 MVP 개발 해커톤 참여 확정.

블레이버스 MVP 해커톤 포스터

1월 인턴이 끝난 후 일정을 계획하던 도중, 흥미로운 해커톤을 하나 발견했고 곧바로 백엔드 포지션으로 참가 신청서를 작성했습니다.

창업 아이템 실전 MVP 구현이라는 주제가 되게 흥미로웠고, 사전 팀 구성을 하는 것보다는 새로운 사람들을 만나 소통하며 배우기위해 1인 신청을 하게 되었어요.🙂

 

벌써 설레..

얼마 지나지 않아 참가 확정 메일을 받을 수 있었고, 어떤 사람들과 어떤 개발을 하게될까 라는 설렘과 함께 킥오프를 시작했습니다.🎉

---

😳 새로운 팀원들과의 첫 만남

2월 9일 킥오프가 시작되고, 전반적인 일정과 함께 2개의 창업 아이템에 대한 개요를 들을 수 있었습니다.

 

이후 팀매칭을 위한 아이템 선호도 투표에서는 꽤나 빠르게 선택할 수 있었는데요.

 

두 가지 아이템 모두 기획이 매력적이고, 고민이 꽤나 필요한 백엔드 시스템을 개발할 수 있어서 좋았어요.

그러나 선택했던 아이템의 경우 기획은 물론 어느정도 사업 검증을 진행중이였고, 개발 도메인에 대한 지식과 시스템 구조도, 그리고 아이템에 대한 그림이 전반적으로 정해져 있었기 때문에 짧은 기간 내에 명확한 소통이 가능할 것이라 판단했습니다.

 

투표를 하고 얼마 지나지 않아 팀매칭이 확정되었고, 저를 포함하여 총 9명의 팀원들의 리스트를 받을 수 있었습니다.

PM(기획) 1명, UI/UX디자이너 2명, 프론트 2명, 백엔드 4명으로 구성되었고 PM분의 주도하에 첫 팀미팅까지 진행하게 되었습니다. (이틀차에 백엔드 한분의 하차로 프론트 한분을 구인하여 진행했습니다.)

 

아무래도 다들 처음보는 사이였고, 미팅 진행에 관련한 가이드라인이 제공되어있지 않아 어색함이 가득한 시작이였습니다.😳😳

 

이러한 분위기에 고맙게도 PM분께서 리드해주시면서 자기소개와 함께 팀장을 정하는 시간을 가질 수 있었는데요.

저의 경우 한번의 해커톤 경험을 말씀드렸고, PM분께서 개발에 대한 지식이 부족하여 팀장은 다른 분께서 했으면 좋겠다라는 의견과 함께 과반수의 추천으로 제가 팀장을 맡게 되었습니다!.. (이게 바로 경력자 우대?.....)

 

이후 미팅은 제가 진행하게 되었고, 가장 먼저 이번 해커톤에 참여하는 팀원들 각각의 목표와 마음가짐에 대해 듣는게 좋을 거라 판단하여 투입 가능 시간을 비롯한 추가적인 자기소개를 가졌어요.

(생각보다 현업에 계신 분들이 많으셔서 든든했었던 것 같은 느낌이..)

 

아이템에 대한 기획과 요구사항은 창업팀에서 어느정도 나온 상태였기에 곧바로 파트 별 미팅을 할 수 있게 디스코드 방을 개설하여 30분 정도의 추가적인 미팅을 진행 후 첫 팀미팅을 마칠 수 있었습니다.

---

🏃‍♂️ 본격적인 10일간의 온라인 협업

🙎‍♂️ 팀장을 맡으면서..

PM과 기획을 담당하시는 분이 따로 계셨기에 "팀장은 무엇을 하면 좋을까?"에 대해 고민을 많이 했었던 것 같아요.

왜냐하면 저의 잘못된 판단이 PM분의 영역을 침범하게 될 수도 있고, 지나친 개입이 팀원들의 자율성을 해칠 수 있기 때문에 팀장의 역할에 대해 먼저 생각해봤어요.

 

그렇게 내린 결론은 개발 일정이 아닌 운영진 및 창업팀과 저희 팀 사이의 다리 역할을 하는 것이였는데요.

개발 외에 부가적인 일정에 대해서 제가 정리하고 공유하는 것으로 팀원들이 최대한 팀 일정에만 신경쓸 수 있는 환경을 만들고자 했습니다.

SSAFY 반장을 하며 다져온 공지 실력..

 

또한 협업을 위한 툴 선택과 환경 조성에 대해서는 아래와 같이 디스코드 채널을 활용해 자료/미팅과 관련한 협업을 진행했고, 공통으로 필요한 문서화의 경우 Notion을 통해 정리했어요.

최대한 이쁘게 꾸미려 했었던...

 

이렇게 원활하게 진행될 것 같았던 온라인 협업은 생각외의 문제에 부딪히게 되었습니다.😥😥

 

💤 소통의 부재

제일 큰 문제는 아무래도 '소통의 부재'였던 것 같아요.

 

디자인, 프론트, 백엔드 각 파트 별로 병렬적으로 개발을 진행할 수 있는 부분도 있지만, 특정 파트가 끝나야 할 수 있는 부분들이 많았어요.

그렇다보니 각 파트의 진행 상황 공유와 연계되는 협업은 중요했고, 이 부분이 팀 전체적으로 부족했던 것 같다고 생각해요.

 

우선 저로 하여금 소통하는 분위기가 될 수 있도록 개발 현황과 문제 사항들에 대한 공유를 시작했어요.

무엇보다 팀 내에서 예측 가능한 사람이 되고자 노력했던 것 같아요.

제 생각처럼 극적으로 분위기가 바뀌진 않았지만 팀원들로 하여금 조금이나마 전보다 편하게 소통을 하는 듯한 느낌을 받을 수 있었습니다.

 

그럼에도 불구하고 소통이 없어서 생기는 문제는 훨씬 많았는데요.

특히 디자인과 관련한 프론트/백엔드 의견 차이가 많았습니다.

예로 백엔드에서는 기능 명세에 나온 데이터들을 기반으로 테이블과 API를 설계했지만, 디자인에서는 추가적인 데이터들이 필요했고 프론트는 이러한 디자인과 관련한 필요한 데이터가 넘어오지 않는다는 언급이 많았어요.

 

이밖에도 특정 화면의 디자인이 나오기까지의 시간, 프론트 API 연동 테스트 유무, 백엔드 API 개발 소요 시간 및 인프라 배포 현황 등 다양한 요소들에 대한 소통이 부족했다고 생각해요. 물론 이러한 소통의 부재는 개발 일정이 더뎌진다는 좋지않은 결론으로 이어졌었구요. 

 

돌이켜 생각해보니 오로지 온라인으로만 진행 했던 협업은 이번이 처음이더라구요.💦

그래서 어떻게 소통을 원활히 할 수 있을지에 대한 고민이 부족했던 것 같아요.

 

그래도 여차저차 모두가 힘써준 덕분에 추가 기능을 제외하고는 아슬아슬하게 마무리할 수 있었던 것 같아요.

---

부족했던 파이널데이

파이널데이는 역삼에 있는 마루180이라는 공간에서 진행했고, 팀 별 5분 발표와 Q&A 진행 후 시연 부스를 운영하는 순으로 진행됐습니다.

 

발표와 관련하여 사전에 미팅을 진행하여 발표자를 선정하기로 했었는데요. 미팅 시작 후 놀랍게도 아무도 마이크를 키시질 않았습니다..🤐 (침묵 어떡할건데...)

끝나고도 의견을 전달 해달라고 부탁드렸지만.. 당일전까지도 아무도 말씀이 없으셔서 제가 맡아서 진행을 하게 되었습니다. (괜찮아 난 뭐든 잘해낼 수 있으니까!?)

이젠 발표가 두렵지않은 Chill Guy

이전 해커톤에서도 발표 경험이 있다보니 그렇게 크게 떨리진 않았던 것 같아요.

발표에서는 시스템 구성에 대해서 고민했던 부분들을 위주로 전달 드리고자 노력했었습니다. 다른 팀들의 발표를 보니 발표자 중 저만 개발자였던 것 같았어요. (나만 개발 관련 어쩌고 저쩌고...)

 

Q&A에서는 다른팀들과 달리 설계쪽의 질문들이 들어왔었고(당연스럽게도..) 제 기준에서는 이해하실 수 있도록 명확하게 답변드렸던 것 같습니다.

 

이후에는 시연을 위한 부스를 준비하고 곧바로 시연을 시작했는데요. 디자이너 한분께서 엄청 열심히 준비를 해주셔서 너무 고마웠던 기억이 있어요.😭😭

우리 부스가 제일 예뻤던 (??)

시연과 관련해서는 당일 인프라 문제로 제대로 보여드리진 못했었습니다.😥 그러나 저희가 노력했던 부분들을 못보여주는 건 아쉽기에 구두를 통해서라도 적극적으로 어필했었던 것 같아요. (옆 부스 사람들과도 재밌어서 웃었던 ㅋㅋ.....)

 

창업팀 측 백엔드 개발자분도 찾아오셔서 설계와 관련해 열띤 토론도 했었는데요. 제가 고민했던 부분들을 공감해주시고 피드백을 비롯해 엄청 재밌게 얘기 나눴던 것 같아요 :)

 

비록 시상은 못했지만, 다른 팀들과도 얘기를 나누는 네트워킹 시간을 즐기며 파이널데이를 마무리 했었습니다.

---

🕑 지난 과정을 돌이켜보며..

✅ 코어 타임을 정해놓았더라면

해커톤이 끝나고 어떤 점이 부족했었을까 생각했더니 문득 팀원 간 피드백이 지연되는 상황들이 생각났습니다.

현업에서도 코어 타임을 정해놓고 근무하는 경우가 있다고 들었었는데요.

그냥 지나쳐 들어서 코어 타임의 존재 가치를 몰랐었던 것 같아요.

 

이번 온라인 협업에서 이러한 코어 타임을 정해놓았더라면 조금 더 원활한 소통이 가능해지고, 불필요한 시간을 줄일 수 있었을 것 같다고 생각했어요.

 

소통이 중요하다는 걸 알고 있어도 "맡은 부분만 해준다면 괜찮겠지..."라는 생각이 기저에 있었던 것 같아요.

이 점에 대해서 반성하고 다음 온라인 협업을 주도할 기회가 생긴다면 코어 타임에 대한 논의를 꼭 하고 싶어요.

 

✅ 백엔드와 프론트, 그리고 디자인의 연결고리

앞서 디자인과 관련하여 소통의 문제가 있었다고 말씀드렸는데요.

이번 협업을 통해 백엔드는 단순한 서버 개발이 아니라, 프론트엔드와 디자인팀과의 긴밀한 협업이 필수적이라는 것을 깨달았습니다.

 

물론 서버의 응답 데이터 형식, 상태 코드 등이 프론트 개발의 생산성에 영향을 끼친다는 사실은 이미 알고 있었습니다.

그러나 짧은 기간으로 인해 최대한 병렬적으로 개발을 진행해야 했고, 이에 따라 디자인에서 변경 사항들이 자주 변경되었습니다. 이러한 변경으로 인해 프론트에서 요구하는 데이터 형식 또한 자주 변경되고, 백엔드의 데이터 모델링 및 API 설계도 자주 영향을 받았었습니다.

 

이후에는 이러한 변경에 대해 사후 대응을 하는 것이 아닌 전체적인 서비스 흐름을 이해하고 사전 조율을 하며 능동적인 참여가 가능하도록 노력해야 겠다고 생각했습니다.

 

✅ 협업을 통한 배움

이번에 Spring Security와 OAuth 소셜 로그인을 처음 개발하게 되었는데, JWT 페이로드에 간단한 정보들에 대해서만 저장했었어요.

엔드포인트에서 user id는 PathVariable 혹은 RequestParam으로 받아서 로직을 처리하도록 개발했는데, 이에 대해서 같은 백엔드 파트 한분께서 이렇게 받게될 경우 클라이언트에서 다른 유저의 리소스 조작이 가능해질 수 있다는 보안적인 측면이 고려된다는 피드백을 주시더라구요.

 

아차 싶었죠. 아무리 MVP 개발이라 빠른 개발이 중요하다지만 이러한 부분을 놓치는게 말이 안되는건데.. 너무 부끄러웠습니다.

몰랐더라고 하더라도 이러한 부분들에 대해 피드백을 받고 성장할 수 있음을 느끼며 협업의 장점을 또 한번 느끼게 되었던 것 같아요.

빠르게 Security Context 수정 마쳤답니다 :)

---

🗯️ 마무리 하며

개발에서 이런저런 문제들이 생기고, 시연에서도 문제가 생겨 파이널데이가 끝나며 실패 했다고 생각을 했었는데요.

그러나 이번 회고를 작성하면서 실패라고 생각했던 과정에서 배운점들이 되게 많았다는 걸 알게 되었습니다.

 

다음에도 이러한 기회가 있다면 서슴치않고 도전하고 많은 걸 경험해보고 싶어요.

고마운 팀원들 :)