24년도 7월 해커톤 회고

들어가며

AWS에서 지원하는 해커톤에 참여했습니다.

 

학부생 수준의 서비스를 무리없이 구현 가능한 범위 내에서

AWS의 서비스를 지원해주는 좋은 해커톤이었습니다.

 

이번 해커톤은

기술 관점에서 AWS로 서비스를 구현해보았다는 점에서 좋았으나,

서비스 관점에서 많은 아쉬움이 남았습니다.

 

제가 제안 했던 최근 아이디어 중 가장 좋은 아이디어였고,

중간 평가에서 심사위원을 포함한 사람(예비 서비스 이용자)들의 좋은 반응을 얻었지만

 

끝끝내 최종 발표에서 저희 팀의 제안을 설득시키지 못했고

심지어 시연 중 프론트 페이지가 렌더링되지 않은 참사가 발생해

더욱 아쉬웠던 것 같습니다.

 

발표에도 아쉬움이 남았습니다.

발표자가 저였는데, 무박 2일 밤샘 해커톤임에도 불구하고

"그래도 잘 할 수 있겠지"라는 미련한 생각으로

체력관리를 하지 않았고, 발표 준비도 엉성하게 했기 때문입니다.

 

추가적으로,

팀플레이를 적극적으로 하지 않는 팀원에 대해

그 당시에는 어떻게 해야할 지 몰라 방관만 했지만,

앞으로는 더 나은 대처를 하기 위해 해당 경험도 회고해보려 합니다.

 

 

 

해커톤 정보

24년도 7월 경 여러 대학교와 AWS가 연합하여 주최된 해커톤입니다.

참여자 수는 약 60명 정도로, 14팀 가량 존재했습니다.

 

팀 구성에 대해서 설명하겠습니다.

팀원분들이 그간 쌓아온 개발 스택 관점에서 이분적으로 분류하자면

백엔드(본인 포함) 2명, 프론트 2명이었습니다.

 

회고 방식

KPT - Keep, Problem, Try 방식으로 회고를 진행하려 합니다.

 

KPT 회고

Keep, Problem, Try

• Keep: 잘한 것
  • 잘 해와서 유지하고 싶은 것
• Problem: 아쉬운 것
  • 어려움을 느껴서 개선하고 싶은 것
• Try: K와 P 기반으로 무엇을 할 지에 대해 작성
  • 구체적인 시도할 내용

 

해커톤 회고

기획 관점

• Keep
  • 슬랙 채널을 이용한 해커톤 물물교환 서비스
    • 중간 평가 내내 "아이디어 자체는 좋다" "나도 이거 써볼거 같다"라 평가 받았습니다.
    • 대형 행사는 비품과 상품같은 아이템이 항상 많이 남기도 하고, 참여자에게 수여된 아이템이 당사자에게는 원하지 않는 것일 수도 있습니다. 그런 비품이 다른 참여자에게는 필요한 것일 수도 있구요.
      • 제가 기획했던 서비스는 이러한 간극을 좁혀 버려지는 비품을 줄이자! 는 취지였습니다.
      • Zero-waste 였던 대회의 주제와도 부합했습니다.
  • 아이템 교환 정보가 많이 쌓이면, 이를 바탕으로 한 인사이트도 행사 주최측에 제공할 수 있는 방안이었습니다.
• Problem
  • 그러나 결국 지적받았던 부분 중 하나인 시장성을 제대로 증명하지 못했고,
    • 미흡한 기획은 결국 발표까지 매끄럽지 못하는 결말을 만들었습니다.
  • 정리하자면 설득력이 떨어졌다고 할 수 있을 것 같습니다.
    • 해커톤에서는 시장성을 무조건 증명해야 하는 것 같습니다.
    • 서비스 운영의 최소 비용만 따지더라도, 이 돈은 누군가에게 그냥 받을 수 있는 비용이 아니기 때문입니다.
• Try
  • 투입되는 비용과 이로 인한 효용을 설득력 있게 제시하는 게 중요한 것 같습니다.
    • 나름의 시나리오를 설정하고,
    • 레퍼런스(논문, 기사) 및 통계 자료와 같이 이미 검증된 자료로 내 아이디어를 검증하거나
    • 아니면 직접 조사를 하며 아이디어를 검증해야 합니다.
  • 기술도 중요하지만, 기술을 왜 사용하고자 했는지 의미부터 확실하게 다지는게 좋습니다.

 

 

서비스 관점

• Keep
  • 핵심 기능의 수를 적게 정의했고, 앞으로도 그럴 계획입니다.
    • 덕분에 1박 2일의 일정에 맞춰 개발이 가능했습니다.
    • 서비스 이용시 사용자는 랜딩페이지를 포함해 단 3페이지만에 물물교환을 할 수 있도록 구성했습니다.
    • 서비스에서는 간편함과 사용성이 정말 중요하다고 생각해왔는데, 본 해커톤에서 이를 잘 반영한 서비스를 구상할 수 있어 좋았습니다.
• Problem
  • 기획이 완벽하지 않았음에도 불구하고, 우선 서비스 개발부터 하자! 라는 느낌이어서 시간이 흐를수록 서비스의 의미에 대해 팀원 모두가 의심을 품게되었습니다.
  • 로그인 기능을 추가로 구현하지 않기 위해, 기존에 행사 참여자 정보가 기록되어있던 슬랙 채널의 사용자 정보를 적극 이용하기로 했습니다.
    • 이는 곧 슬랙에 대한 의존성을 의미했는데, 이 의존성에서 발생할 수 있는 문제(ex 시장성, 확장성)를 고민하지 않았고, 이어질 질문에 대해서도 답변이 깔끔하지 못했습니다.
• Try
  • "기술은 도구다" 를 명심하려 합니다.
    • 해커톤 참여자를 제 서비스로 직접 모으지 않고, 이미 모여있는 '채널'을 사용해 사용 편의성을 증대하려 했기 때문에 슬랙을 '선택'한 것이었습니다.
    • 처음에 이런 결정을 정말 쉽게 내렸고, 팀원도 쉽게 설득할 수 있었습니다.
      • 그러나 이 '쉽다'라는 생각은 고민을 덜 하게 만들었고, 결국 미흡한 결과를 만들어 낸 것 같네요.
  • 결국 '끊임없는 고민'이 중요하다 생각되고, 앞으로 명심하려합니다.

 

기술 관점

• Keep
  • 없다.
• Problem
  • AWS를 기반으로 배포 및 운영을 하려 했습니다.
  • 서비스가 간단했던 만큼 1일차 저녁10시 전에 실 운영을 목표로 했지만, 구현 기술에 문제가 있었습니다.
  • 코드 를 도커이미지로 말아 AWS ECR 및 AWS Lambda로 배포하는 방식을 채택했는데, 해본적도 없었고 이해도도 떨어졌었습니다.
    • 결국 기존 목표에서 7시간정도 초과된 다음날 새벽 5시가 되어서야 백엔드 개발을 완료했습니다.
  • 잘 모르는 방식이었는데도 불구하고
    • "레퍼런스가 존재하고? 경험있는 팀원이 있으니까? 잘 되겠지?" 라고 안일하게 생각했습니다.
    • 제대로 이해하지 않은 상태에서 문제가 발생하고, 트러블슈팅하려니 시간이 예상했던 것보다 훨씬 많이 걸렸습니다.
      
      • 심지어 "프레임워크 런타임을 람다로 배포하는게 맞나"라고 고민이 계속 들었지만, 후에 기술할 소통 방식의 문제 때문에 혼자 계속 끙끙 앓아서, 시간이 많이 걸렸습니다.
• Try
  • 내가 경험해 본 것이 아니라면, 레퍼런스 '코드'가 존재한다고 해도 구조를 완벽히 이해하고 채택 및 개발하려 합니다.
  • 잘 모르는 것에 대해서 혼자 고민할 때, 30분 이상 고민하게 되면 무조건 내용을 정리해 팀원에게 도움을 요청하려 합니다.

 

발표 관점

• Keep
• Problem
  • 발표 시간 5분 내에 모든 것을 담아내지 못했습니다.
    • 추가
  • 문제 제기에 대한 설득력이 많이 떨어졌습니다.
    • 추가
  • "슬랙에 대한 의존도는 어떻게 해결할 것인가?" 라는 질문에 대답을 엉뚱하게 했습니다.
    • 추가
• Try

 

협업 관점

• Keep
  • 아이스 브레이킹을 잘 한 것 같습니다.
    • 먼저 나서서 자기소개 하거나, 팀원 모두가 편하게 대화할 수 있도록(특히 웃으며 말할 수 있도록, 먼저 웃기거나 하면서) 분위기를 조성했습니다.
    • 사실 이렇게 처음 보는 사람과 협업하는 기회가 흔치 않습니다.
      • 해커톤은 '공동의 목표를 달성하기 위한 의사소통'이 뭔지 정말 잘 알게되는 행사라 생각합니다.
        • 편한 분위기에서, 웃으면서 소통할 때가 정말 재밌는 것 같습니다.
  • 제가 어떤 일은 할 수 있고, 어떤 일은 못하는 지 확실하게 표현했고, 덕분에 역할 분담이 수월했습니다.
• Problem
  • 아쉽게도, 팀플레이 의지가 약했던 팀원이 있었습니다. 맡은 역할에 제대로 임하지 않았고, 태스크 완료 기한도 알 수 없어 답답함이 있었습니다.
    • 그러나 여기서 정말 문제였던건 해당 팀원은 프론트 파트였고, 저는 백 파트였기 때문에 신경을 더 쓰지 않았다는 것입니다. 프론트 파트의 다른 팀원이 "알아서 잘 조율해주시겠지?"라고 안일하게 생각했습니다.
      • 프론트 페이지가 완성되긴 했으나, 연동에 불안전함이 있었고, 이런 저런 핑계(발표준비같은)로 제대로 확인하지 않았고, 결국 발표 당시 실제 페이지와 연동이 되지 않는 사고가 발생했습니다.
    • 팀플레이를 하지 않는 게 눈에 보였어도, 파트가 다르다는 이유로 방관했습니다.
  • 최고의 협업은 팀원 모두가 원하는 바를 이루는 상황에서 이뤄진다 생각했고
    • 그래서 아이스브레이킹 및 아이디어 기획 당시 의견 조율을 충분히 했다 생각했지만 미흡했던 것 같습니다.
• Try
  • "이가 없으며 잇몸으로"라는 말이 자꾸 생각납니다.
    • 팀원이 맡은 역할을 잘 수행하지 못하더라도, 목표를 달성하기 위해서는 결국 누군가가 해야 합니다.
      • 그 누군가가 되는 것에 거리낌이 없어야 성장하고, 신임을 받고, 더 나은 사람이 될 수 있는 것 아닐까요.
      • "이거 하기 싫으신가요? 그럼 어떡하나요, 저도 못 하는데요??." 가 아니라
      • "이거 하기 싫으신가요? 그럼 이렇게 할까요?"를 적극적으로 표현해야겠습니다.
  • 어떤 이슈를 해결 중일 때, 30분 이상 고민해야하는 경우라면 혼자 고민하지 않고 적극적으로 공유하려 합니다.
    • 혼자만 고민하다보니까 10분 걸릴게 30분 걸리기도하고, 이게 1시간... 2시간... 넘어가곤 했는데
      • 사실 10분 걸려 해결할게 2시간 걸린것이 아니라,
        • 원래 2시간 걸릴 걸 저 혼자 10분 걸린다고 착각했습니다. 정말로요.
    • 잘 모르는 방법에 대해 자신감을 가지고 도전하는 건 좋지만, 제대로 된 이해 없이 무턱대고 "내가 할 게!" 하는 건 자만에 불과한 것 같습니다.