by
Feb 14. 2020
아이디어톤은 개인적이고 심플하게
{멋쟁이 사자처럼 직장인} 후기 4편
멋쟁이 사자처럼의 아이디어톤. 수강생들이 만들고 싶은 '웹서비스'에 대해 발표하는 시간이다. 시간제한은 2~3분 정도 주어지는데, 짧은 시간 안에 배경/목적/특징을 요약해 얘기해야 한다.
2기 때는 아이디어톤이 '의무'는 아니었다. 그래서 약 40명이나 되는 수강생들 전부가 각자 발표하진 않았다. 오히려 그 절반도 안 되는 19명만 발표를 했다. 살짝 아쉬운 부분이었다. 나는 다른 수강생들이 어떤 아이디어를 갖고 있는지 구경하는 것도 큰 재미였는데, 아이디어톤 발표가 의무가 아니다 보니 발표도 하지 않고 다른 아이디어를 선택해 합류하는 분들도 많았다.
아이디어톤에서 가장 중요한 포인트를 3가지 뽑자면..
1. 사회를 뒤바꿀
대단한 아이디어를 내겠다고
끙끙대지 말자
아이디어톤이라고 해서 대단한 아이디어만 나올 필요는 없다. 스타트업 창업이 목적이 아니기 때문이다. 소소하고 개인적인 아이디어들이 제일 재밌고 매력 있더라. 오스카 받은 봉준호 감독이 시상식에서 인용한 마틴 스콜세지의 명언처럼, "가장 개인적인 것이 가장 창의적인 것이다."
자기 아이디어가 뭔가 부족해 보이고 민망해서 발표 자체를 망설이는 분들도 계신데, 뭐가 됐든지 일단 발표는 하는 걸 추천한다. 아이러니하지만 가벼운 주제일수록 사람들이 더 재밌게 듣는다. (무거운 아이디어는 진부하다)
2. 결국 본인이
책임지고 개발해야 한다
심플한 기능만 생각하자
멋직은 아이디어톤에서 인기 많다고 끝나는 게 아니다. 본인이 발표한 아이디어를 해커톤 당일까지 개발을 완성시켜야 하는 게 최종 목표인 점을 잊으면 안 된다.
솔직히 자기 아이디어로 발표 자료를 만들다 보면, 상상의 꿈나래가 펼쳐지면서 이 기능도 넣고 저 기능도 넣고 싶어 진다. 애정이 생기니까. 하지만 과도한 기능 욕심은 곧 밤샘으로 이어진다. 조금 어려운 말로 표현하면 기술 부채(technical dept)가 쌓이는 건데, 개발 초보들끼리 방법론 없이 다양한 기능을 얼기설기 붙이다 보면 갑자기 DB에서 충돌을 일으키거나 어디부터 건드려야 할지 모를 정도로 백엔드가 꼬일 수 있다.
이쯤 되면 강사도 도움을 주기 힘들다. 강사가 한 팀에 붙어있기도 어려울뿐더러, 해커톤에 가까워질수록 모든 팀의 백엔드가 각자 나름의 사연으로(..) 꼬이기 마련이라서, 특정 팀에만 붙어 100% 해결을 해줄 수가 없다.
즉, 기능은 심플하게 1개 또는 2개만 생각하는 게 좋다. 많이들 아시겠지만, 그 유명한 MVP(Minimum Value Product) 방법론으로 접근해야 한다. 가장 기초적인 기능부터 만들고 조금씩 개선해나가는 식으로 개발하자.
아이디어와 기능은 일단 심플하게3. 팀원 많다고 유리하지 않다
책임지고 끌고 갈 사람이 있어야 한다
아이디어톤이 끝나면, 참여하고 싶은 아이디어를 중심으로 사람들이 모인다. 안타깝지만, 참여자가 없는 아이디어는 아예 사라지는 일도 꽤 생긴다. 물론 본인이 혼자서라도 개발을 하겠다고 하면 아이디어를 지킬 수는 있는데, 혼자 하면 쉽지 않다. 최소 의지할 1명의 팀원은 필요하다.
반면 팀원이 많다고 마냥 유리한 것도 아니다. 어차피 모두가 이제 막 개발 기초를 배운 초보들이 뭉친 것에 불과하다. 중요한 건 1명이 총대를 매고 끌고 가야 한다는 건데, 보통은 아이디어를 낸 '팀장'이 그 역할을 해야 한다.
그러니 다른 팀에 합류를 결정할 때, 팀장이 자기 아이디어에 얼마나 확신이 있는지를 꼭 확인해보자.
어느새 멋직 3기 접수가 끝났다. 이번에도 Ruby를 쓰는 건 바뀌지 않았지만 클래스가 화/토반과 수/토반으로 나뉘었다. 고정된 일정 때문에 참여가 어려웠던 직장인들에게는 좋은 기회가 될 듯.
만약 이 글을 읽는 3기 수강생 분들이 있다면, 조금이라도 도움이 됐으면 좋겠다.
