brunch

You can make anything
by writing

C.S.Lewis

by 호영 Sep 22. 2023

AI 해커톤 1등 수상 후기 (1)

사이드 프로젝트에 대한 시행착오와 교훈

······

저번 달에 수상 받은 대회에 대한 내용과 서비스는 아래 글을 참고해 주시면 감사하겠습니다.

https://brunch.co.kr/@hotorch/15




이 글은 제가 팀원들과 해커톤 대회를 이끌고 가면서 개발하면서 느낀 생각과 감정들을 기록하고자 하기 위함임을 밝힙니다. 또한 회고 양식을 따르지 않고 자유롭게 서술하고자 합니다. 


해커톤을 1등 수상한 경험은 운도 따라 주었지만 여러 시행착오들과 경험들이 누적된 것이 큰 몫이었고 생각합니다.

글 목차를 작성하다 보니 글 하나로 안 끝날 것 같다는 생각이 들었습니다. 그래서 1편 팀적인 관점에서 해커톤에서 1등을 수상 받기 전 사이드 프로젝트에서 느낀 경험과 시행착오들을 녹였고, 2편해커톤 대회기간 때 느낀 개인적인 생각과 후기들을 작성해보려 합니다. 


이 글이 도움 될 것 같은 사람들을 한번 작성해 보면 다음과 같습니다.

사이드 프로젝트나 대회, 공모전을 참여하는 사람들

팀 프로젝트를 진행하거나 협업 중인 사람들

팀 리딩을 하시는 분들



1. 사이드 프로젝트

IT에서 사람들이 본인 직무 역량과 개발 실력이 향상되면서 시간적인 여유가 생긴다면, 자기 자신만의 서비스를 만들거나 사이드 프로젝트를 하는 니즈가 생기는 현상을 많이 관찰했습니다. 사이드 프로젝트하는 이유 & 이점은 상당히 다양합니다. 


직장에서 내 역량과 흥미가 떨어지는 일을 수행하는 데, 다른 성취 욕구를 충족시키기 위해

최신 기술들을 적용해 보는 경험을 쌓기 위해

운이 정말 좋으면 본업보다 더 큰 수익을 얻을 수 있음

정말 여기서 BM이 확실하고 hype을 받으면 창업의 기회까지 연결이 가능함

PM이나 풀스택 개발자와 같이 다양한 경험을 쌓으면서 커리어 상향시키기 위해

나 말고 다른 직군, 산업군에 있는 사람들은 도대체 어떻게 일을 하는지 알 수 있음

나도 배우고 성장하고 나도 좋은 것을 다른 사람들에게 알려주고 기여하기 위해

협업을 하면 커뮤니케이션과 같은 소프트 스킬들이 향상될 수 있음. (인격적으로 좋은 사람들을 만난다는 가정이 필요함)


위와 같은 여러 가지 이유들 때문에 호기롭게 시작하지만 현실은 쉬운 일은 아닙니다. 저 또한 끝을 마무리해 본 사이드 프로젝트도 있고 하다가 포기하거나 유기시킨 프로젝트들이 꽤 있습니다. 포기하는 이유 또한 정말 다양한데 생각나는 것들을 서술하면 다음과 같습니다.


의욕이 1달 이상 끌고 가기 힘들어서, 내적 동기를 길게 유지하기 힘들어서

갑자기 여러 가지 이유로 시간적인 여유가 전혀 안 생길 때

(혼자 진행하지 않는다면) 팀원 누군가 그만두게 되면 간혹 팀 전체 사기 저하를 불러일으킬 수 있어서(매년 느끼는 현상)


그래서 위와 같은 문제들을 해결하기 위해 데드라인이 정하고 진행하거나, 일정 금액을 참가비로 지출하거나 특정 사이드 프로젝트 플랫폼을 활용하여 진행하는 경우를 많이 본 것 같습니다. 


위와 같이 IT 업계 사람들을 모집해서 경험치와 성장을 위해 사이드 프로젝트를 하는 프로그램, 스터디, 네트워킹이 다양하게  존재한다.



2. 해커톤 대회 참가 이전에 겪은 시행착오와 Lessons Learned Points


공모전이나 경진대회 같은 경우는 주제가 정해져 있어서 상대적으로 기획 난이도가 낮습니다. 하지만 사이드 프로젝트 레벨로 넘어오면 아이템 도출, 서비스 구체화 부분 생각해 보면 정말 쉽지 않습니다. 우선 제 경험을 빗대서 설명해 보면, 올해 초에 따로 진행했었던 아이템 선정은 아래와 같이 각자 하고 싶은 아이디어들을 list up 하고 이를 다수결로 투표하여 아이템을 선정하였습니다. 그리고 3개월 정도 진행을 해봤었습니다. 


실제 팀원들이 AI가 관련되고 나름 돈이 될만한 아이디어들을 리스트업을 해놨었고, 페이지 내부에는 구체적인 요건들이 기술이 되어있었다.


아이템 선정이 다수결이라는 방식이 최선이라고 생각을 했었지만 개인적으로는 미흡했던 부분이 있었습니다. 3개월 정도 짧게 해 보면서 얻은 것들과 Lessoned Learn Point들을 핵심만 정리하면 다음과 같습니다.


얻은 점

기획, 개발, 디자인, 배포까지 팀 전체가 한 사이클을 돌아보았다. 팀워크가 한 층 더 올라갔다.

나는 팀원들을 이해를 했다고 생각했지만 큰 오산이었다. 하지만 한 사이클을 돌면서 팀원들이 무엇을 잘하고 싫어하고 좋아하는지 더 이해를 하게 되었다.

개발 역량, 팀원들의 태도, 내적동기도 중요하지만 기획이 제일 중요하다는 생각이 들었다.


Lessons Learned Points

기획서를 만들 때 개발할 수 있는 인원에게 이게 되는지 안되는지 여러 차례 물어보고 구현 가능성 및 기술 검토를 진행해야 한다. → 개발하는 인원이 고통스러워했던 장면을 목격하였고, 사이드 프로젝트를 진행하는데 각자의 업무량의 큰 불균형이 생겼었습니다.

아이템 선정 시 내가 하고 싶은 아이디어들을 모아서 다수결 투표보다는 다른 방식으로 아이템을 선정을 하는 것이 좋은 것 같다. → 각자가 "내가 정말 내가 만든 서비스를 사용할 용의가 있는가?"라는 생각이 드는 만장일치 아이템이 제일 Best이다. 또 다른 방법은 팀원들이 좋아하는 것/잘하는 것 들을 리스트업을 해보고 그 교집합 아이디어 속에서 수익성이나 BM 부분을 다 같이 검토를 하는 것이 좋다. 

개발 초기에는 다들 에너지가 넘치지만 지속적으로 동기부여, 보상체계, 명확한 목표 등을 제시해주어야 한다. → 이 부분이 잘 되지 않는다면 책임감 결여로 이어질 수 있다.

아직까지 현재 나의 그릇은 7~8명 이상의 사람들을 이끌고 간다는 부분은 무리인 것 같다. → EO 채널에서 보던 한 인터뷰에서는 페이스북에서 팀원 3~4명 + 1 팀장 체제로 팀장이 팀원들에게 개발에 최적화된 환경을 조성하는 데에 집중한다는 이야길 들었는데, 너무 다양한 사람들을 모으려고 했고 욕심이 많았었다.


Lessons Learned point에서 위와 같이 복합적입니다. 몇몇 팀원들에 대해 역량 이해 부족에서 업무량의 불균형이 생겼었고 번아웃이 생기거나 팀 사기도 떨어진 경험들을 했었습니다. 

제가 프로젝트에서 생각하는 '업무 총량'에 대한 생각을 공식처럼 아래와  같이 표현해 보았습니다. (수식의 곱하기는 비례/반비례를 크게 신경 쓰지 않았습니다. 어떤 팩터들이 고려되는지 작성만 해보았습니다.)


프로젝트 완성 시 총 업무량 = ∑(각자 개인의 총 업무 할당량) ··············· ①

(각자 개인의 총 업무 할당량) = (개인이 투자하는 시간) X (본인의 역량) X (할당된 업무의 난이도)  ···②


①처럼 아주 간단명료하게 프로젝트를 끝마치려면, 개인이 견뎌낼 수 있는 업무들을 책임감을 가지고 명확하게 클리어하면 됩니다. 하지만 ②와 같은 경우에는 각자 개인의 총 업무 할당량은 살펴보면 조금 복잡하게 느껴질 수 있습니다. 팀원들마다 받은 업무 할당된 일 자체로도 상이하지만 시간과 역량과 난이도 전부 다르기 때문입니다. 




3. 이번 해커톤 Case에 적용해 보기


그래서 이번 해커톤에서는 이전에 경험한 Lessons Learned point들을 인지하고 교훈 삼아 해커톤에서 개선된 프로젝트를 이끌고 가고 싶었습니다. 아래와 같은 생각을 하면서 팀 운영을 해보았습니다.


각자의 개인의 총업무량에 대해 "불균형"이 생기는 부분은 깔끔하게 인정하기. 하지만 그 업무량에 대한 불균형을 "책임지고 최소화시키기". 마지못해 생긴다면 배워서라도 서포트해주기.

팀원들에게 기획 단계에서 개발 아이디어, 아이템 선정 안건에 대해서는 "이런 아이템이 있다면 너도 이용해 볼 용의가 있는지?" 동의를 구하기. 기획 아이템에 대해 만족성 끌어올리기. → 모두가 이용할 용의가 있다면, 팀을 리딩하는 사람 입장에서는 '동기부여'에 대한 가성비가 상대적으로 뛰어나다.

기획할 때 기간 내에 개발할 수 있을 것 같은 부분, 못하는 부분들을 깔끔하게 나누고 손절할 수 있는 부분을 손절해서 매몰비용 오류에 빠지지 않기

task에 대해서 할 일들을 list-up 하고 이를 우선순위 나눠서 접근하기 (앞으로는 not-to-do list 같은 부분도 생각해서 운영해 볼 생각)

기술 Stack을 최대한 분산시켜서 각자의 강점들을 살리기. 

주기적으로 동기부여(최소한 단순한 외재적인 동기부여라도)해주고 최소한의 1차원적인 보상이라도 챙겨주기 

제일 중요한 건 나부터 열심히 하는 건 기본값이고, 성과를 내면서 솔선수범을 보여주기


이렇게 개선점을 적용해서 팀을 이끌었을 때, 팀원이 힘이 들다가도 다른 팀원이 열심히 하는 모습을 보고 어떻게든 마무리하고 성과를 내는 경험을 보았습니다. 따라서 자연스럽게 팀원들이 성과 내는 모습에 팀 합이 더욱 좋아지는 경험을 느꼈습니다. (최소 지금 손흥민이 이끌고 있는 토트넘 라커룸 분위기)


해커톤 수상 후기는 다음 글에 자세히 작성해 보겠습니다. 이 글이 IT 섹터에서 사이드 프로젝트를 하는 사람이나 팀을 이끌고 있는 사람들에게 좋은 경험으로 작용되면 좋겠습니다. 긴 글 읽어주셔서 감사합니다 :)



브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari