숏커톤 회고 -‘뚝딱’하면 ‘짠’할 수 있는 그 날까지!-

⏰ 프로젝트 제출 D-0.75

숏커톤 시작 전부터 계주 경기 직전 받는 스트레스를 느꼈다. 기대감이 주는 긴장감이어야 하는데, 이제 막 당근 써는 법을 배우다가 회를 뜨자니 시작 전부터 걱정이 아니 될 수 없었다. ‘Change’라는 주제가 나오고 아이디어 회의를 시작했다. 추상적이었던 주제인 만큼 ‘이거 하면 좋겠다!’라는 생각으로 계속해서 아이디어를 뿜어내야 했는데, ‘이걸 만들 수 있을까?’ 라는 의심에 막혀 주춤거렸다.

뭐든 시작하기 전 변수에 당황하지 말자며 다짐을 하면서 당황을 금치 못하는 편이지만, 이번 변수는 정말 변수다운 변수였다. 기획, 디자인을 순조롭게 거치고 개발단계에서 가장 애를 쓸 것이라 생각했던 것과는 달리 주제에 맞는 아이디어를 뽑는 과정이 가장 어려웠다. ‘숏커톤 주제에 맞는’, ‘빠르게 구현할 수 있는(데이터베이스 없이 구현 가능한)’, ‘첫 페이지에 흥미를 보일 수 있는’ 웹 서비스를 생각해야 했다. 역시 막막할 때 만만한 게 브레인스토밍이었고, 아이디어 제시에 방해되었던 구현 가능성을 잠시 내려둔 채 이래도 되나 싶을 정도의 자유로운 아이디어를 쏟아냈다. 그 결과로 나온 꽤 많은 아이디어가 나왔고, 정해놓았던 세 가지 조건들로 필터링하여 최종 서비스를 결정하였다.

개발 과정에서 파트 분배 이후부터는 “푸시 했어?!”, “푸시할게?!”와 같은 대화가 오간 것밖에 기억이 나지 않는다. 개발자 3명 모두 생초보 개발자였음에도 정말 감사하게 분배한 파트를 모두 시간 내에 구현해주었다. 짧은 시간 안에 완성해야 하는 서비스 구현과정에서 상대적으로 경험이 많은 기획과 디자인에 기댈 법도 했지만, 나를 포함한 여섯 명의 팀원 모두가 부여받은 임무를 온전히 수행하였다. 평범해 보일 수 있는 서비스에 디자인과 기획의 노력으로 돋보이는 결과를 만든 것은 분명하지만, ‘팀 내에 영웅은 없다’는 정신으로 모두가 제 몫을 해내었기 때문에 상위권의 결과를 얻을 수 있었다고 생각한다.

서비스에 대한 구체적인 설명

✋ 숏커톤에 두고 가기(반성의 시간)

• 개발자끼리 파트를 배분하였지만, 급한 마음에 나의 파트에서의 우선순위 및 시간 분배를 하지 못한 채 무작정 코드를 작성해나갔다.

• 키보드만 두드리는 것은 협업이 아니다. 개발자라고 소통을 아껴선 안 된다.

• 막히는 부분을 해결하기 위해서는 기획자와 디자이너에게도 충분한 설명이 필요하다. 나부터 막히는 이유를 정확히 이해하고, 현재 상황과 어떻게 진행되고 있는지를 분명하게 전달해야 한다. 해결이 안 되더라도 “어려워서 안 될 것 같아요” 가 아니라 왜 안되는지 정확히 알고, 기획자와 디자이너가 이해하고 이해할 수 있는 핑계를 대자.

• 개발자의 시각에서 선택에 따른 결과가 왜 이렇게 나오는지 정리하며 마지막 발표준비를 도와주었어야 했는데, 개발이 끝났다고 긴장이 풀려 발표준비를 돕지 못했다. 숏커톤 과정에서 가장 반성하는 부분이다.

• 개발자끼리 각자 파트에서 분명 가장 막혔던 부분이나, 이에 대한 해결방법, 새롭게 알게 된 것들을 숏커톤 후 나누지 못했다.

👍 다가오는 롱커톤에 그대로 가져가기

• 막히는 부분을 고집부리지 않고, 솔직하게 전달 후 다른 대안을 제시했던 것이 진행 속도에 도움을 주었던 것 같다.

• 아예 새로운 것을 제시하는 방법만 있는 것이 아니라 기존에 어떤 서비스가 있었는지 찾아보고, 변형해 보았던 것이 시간싸움에 유리했던 것 같다. 롱커톤에서는 개발단계에서 기존에 어떤 기능이 주로 쓰였는지 찾아보며 사용하거나, 변형해보면 도움이 될 것 같다.

한동대학교 전산전자공학부 박지성