해커톤에서 경험하고 싶은 것
- 제한 시간 내에 팀원들과
원활하게 의사소통하여 프로젝트의 목표를 설정하기 - 제한 시간 내에 목표에 가장 가까운 프로젝트를 완성(해커톤 완주)
- 해커톤에서
필요한 전략을 생각하고 팀원에게 도움주기 - 내가 직접 작성한 코드를 만들기
해커톤에서 경험한 것
사전준비
해커톤 참여 여부가 확정되고 해커톤 진행하기 전 사전 준비가 필요하다고 생각했다. 한 번의 해커톤 경험이 있지만 그때는 프로젝트도 완성 못하고 끝난 경험이 있어 경험이 많은 동료와 멘토님께 해커톤의 조언을 얻고 싶었다. 팀장으로 해커톤을 많이 경험한 동료에게는 해커톤 진행하면서 느낀 경험에 관해 물어보고 멘토님께는 사전 준비를 어떻게 해야 할지 질문을 했다.
동료는 프로젝트의 원활한 진행을 위해 팀원들을 압박하면 안 되며 가능한 것을 정하는 게 좋다고 했다. 멘토님은 환경설정과 필요한 코드도 미리 준비하는 것이 좋다고 조언받았다. 들었던 조언과 나의 경험을 생각해보니 해커톤에서 개발 프로세스의 A-Z를 경험하는 것이 불가능하다고 생각했다.
그래서 해커톤 시작하기 전 팀원과 대화하고 레포지토리, 환경설정, 브랜치 전략, PR방식, 디렉토리 구조를 미리 대화하고 해커톤에 임했다.
주제선정의 어려움
사전 준비에서도 언급했듯이 내가 생각한 해커톤은 24시간 동안 기획, 설계, 개발, 테스트를 하는 것이 부족한 시간이라고 생각했고 내가 개발 속도가 느리다는 것을 충분히 알고 있었다. 그래서 나는 프로젝트의 완성도가 중요한 대회이기에 최대한 기획에 투자하는 시간을 간략하게 하는 것을 우선으로 생각했다. 팀원들에게는 해커톤 참여시 작성한 자신의 주제를 후보로 선정하고 팀원들이 원하는 주제를 뽑자고 제시했다.
각자 가져온 주제가 마음에 들지 않아 계속 고민하게 되어 1시간 동안 회의하기로 했지만 5시간 동안 하게 됐다. 회의 중간에 괜찮은 주제가 나와서 과반수가 넘었고 개발 시간이 부족할 것 같아 이 주제를 가지고 개발을 진행하자고 제안했다. 하지만 내키지 않은 팀원들이 있어 계속 회의를 진행하게 됐다.
시간이 흐르면서 개발 시간이 부족한 나는 초조했지만 팀원을 압박하는 행동을 하면 안 된다는 동료의 조언을 생각하니 시간이 걸리더라도 모두가 만족하는 주제를 선정하기 위해 적극적으로 회의를 참여했다. 만약 시간이 부족하면 기능을 축소해도 된다고 생각했기에 그때는 오히려 편하게 회의를 할 수 있었다. 마침내 언택트 시대에 원하는 사람과 함께 소통하며 롤 경기 관람을 매칭해주는 주제가 나오고 팀원들도 만족하며 개발을 진행했다.
밤샘 작업
회의를 마치고 개발을 시작하니 12시간 남은 상황이었다. 프론트엔드 작업 특성상 UI에 맞는 컴포넌트 디자인, 기능 구현, 테스트를 해야 하기 때문에 함께하는 팀원과 일 분배가 필요했다. 그래서 나는 이전 프로젝트 경험을 바탕으로 공통컴포넌트 만들기, 페이지별로 작업, API기능 붙이기를 점진적으로 하자고 제안했다. 팀원도 동의하고 깃 컨벤션은 사전에 정해놨기 때문에 작업에 바로 들어갈 수 있었다.
12시간 안에 앞에서 언급한 작업을 하기에 쉽지 않아 서로 작업한 영역이 충돌되지 않게 “지금 팀원분이 작업하신 곳이랑 겹치는 거 같으니 PR확인 해주세요~”, “네 확인했고 이 부분 저랑 겹치는거 같으니 저는 이 부분 rebase한 후에 merge할게요~” 이런 식으로 대화하면서 팀원과 마감 10분 전까지 작업을 했었다.
코드의 재활용
처음에는 내가 직접만들어봐야지라는 생각하고 작업을 했었다. 하지만 마감시간이 다가오면서 생각이 바뀌게 되었다. 내가 직접짠 코드도 중요하지만 해커톤을 하기전 다짐과 결과물이 없는 프로젝트는 의미가 없을 거 같다라는 생각했다.
그래서 라이브러리를 사용하기보다는 내가 지금까지 했던 프로젝트에서 코드를 가져와 프로젝트에 알맞게 변형해서 작업을 진행했다.
백엔드에 필요한것을 요구
회원가입이 유지 되지않는 상황이 발생하여 왜 그런지 검사해보니 API통신할 때 ID값이 누락되어 있어 문제가 발생한것을 파악했다. 그래서 백엔드개발자에게 로그인을 유지하려면 Id값이 필요한데 회원가입하고 또 다시 회원검증하는것 대신 회원가입시 Id값도 같이 보내주실수 있냐고 설명했다.
상황을 듣고 API 통신을 두번하는것보다 한번하는거에 동의하고 고쳐주셨다.
해커톤에서 지속하고싶은것들
- 팀원들에게 무리한 요구를 하지 않는것
- 작은 단위의 작업을 완료하면 팀원에게 말해주기
- 할수있는것과 할수없는것을 나누기
- 합당한 이유로 필요한것을 제시하기
해커톤에서 배운것들
적당히 밀당하기
회의를 할 때 무작정 길어지는 회의는 효율적이라고 생각하지 않는다. 하지만 의미있게 길어지는 회의는 좋다고 생각한다. 이번 해커톤에서 주제선정 회의를 생각보다 길게 한건 사실이지만 길게 했기 때문에 좋은 아이디어가 도출되고 2등까지 될수 있었다고 생각한다. 또 반대로 내가 개발을 어느정도 빨리 들어가야된다고 적극적이지 않지만 팀원들에게 인식을 심어주었기 때문에 괜찮은 주제가 나왔을 때 결정을 할 수 있었다고 생각한다.
그래서 회의를 할 때는 시간을 정하고 미뤄지더라도 팀원들에게 “우리 회의 마감시간 지났으니 회의만할 수 없어”라는 인식을 심어주는것을 알게 됐다.
끊임없는 의사소통
짧은 시간안에 결과물을 만들기 위해 팀원과 의사소통이 중요한것을 알게 됐다. 혼자 개발하면서 문제가 생기는것은 되지만 결과물에 합칠 때 오류가 난다면 그것을 해결하기 위해 팀이 합류하기 때문에 팀 전체에 위기라고 생각했다.
이번 해커톤에서는 매번 작업이 끝나면 팀원과 대화를 하고 검토받는 과정을 통해 충돌나는 경우를 줄였기에 크게 보면 팀에게 유리한 활동이라고 생각했다.
요구할 때는 명확히
API통신할 때 Id값을 넘겨받기 위해 요구를 명확하게 설명했기 때문에 상대도 쉽게 받아드릴수 있었다. 하지만 명확히 설명하지 않고 무작정 필요하니 주세요라는 표현은 아니라고 생각했다. 이전의 나는 잘몰라서 요구할 때도 필요한거 같다 라고 표현했지만 이제는 상대도 이해되게 표현하여 팀에게 도움이 됐다.