IT 동아리 디프만 15기 운영 후기 (1)
사이드 프로젝트, 어차피 종료할 건데.. 왜 만들지?
어차피 종료할 건데, 왜 만들지?
IT 동아리에 2년 정도 참여하던 어느 날, 문득 회의감이 들었다. 가장 큰 이유는 “서비스 종료의 반복”이었다. 지금까지 진행했던 대부분의 사이드 프로젝트가 유의미한 사용자 수를 확보하지 못한 채 기수가 끝남과 동시에 종료되면서, 무언가를 빠르게 만들어내기만 하는 것에 대한 회의감이 커져갔다.
사이드 프로젝트 자체에는 흥미를 잃었지만, 사람들과 만나 이야기하고 협력하는 과정은 여전히 좋았다. 그래서 자연스럽게 운영진 역할에 관심이 생겼다.
2024년 2월, 디프만 14기가 마무리되고 내가 만든 서비스가 ‘또’ 종료되었을 때, 나는 운영진이 되어야겠다고 결심했다. 이제 동아리 멤버가 아닌 운영진으로서, 서비스 종료 확률을 줄여보고 싶었다.
운영진 커피챗
디프만 운영진이 되기 위한 면접 겸 커피챗 자리가 있었는데, 간단한 마인드맵으로 생각을 정리해 준비를 하고 면접에 들어갔다. 이후 면접 결과를 전달받는 자리에서 “부회장을 해보면 어떻겠냐”는 제안을 받았다. 나보다 더 잘할 수 있는 친구들이 많다고 생각해서 고민을 많이 하다가 승낙했는데 지금 생각해 보면 참 잘한 선택이었다. 더 큰 책임이 주어진 덕분에 후회 없이 시도해 볼 수 있었다.
내가 느꼈던 여러 가지 문제들
디프만은 완성도 높은 서비스를 모든 팀이 100% 론칭하는 것으로 잘 알려져 있다.
그런데 16주라는 짧은 기간 안에 완성도 서비스를 출시해 발표해야 하다 보니, 대부분의 팀이 짧은 기간 안에 기획을 확정하고 곧바로 디자인 작업에 들어가곤 했다. 나 역시도 “빠르게 만들고 빠르게 시장의 반응을 본다”는 MVP 방법론을 무기로, 해결하지 않아도 될 문제를 문제로 정의하며 서비스를 만들어본 경험이 있다.
그러나 나중에 이 서비스가 사용자가 원한 서비스가 아니었다는 것을 알게 되더라도, 기획을 수정하거나 문제를 재정의하기는 쉽지 않았다. IT 동아리 특성상 매주 정해진 커리큘럼이 있기 때문에 한 번 설정된 기획을 다시 0부터 시작하기가 현실적으로 어렵기 때문이다.
몰아치는 디프만 세션들아쉬운 상황을 직접 경험하며, 동아리 차원에서 문제 정의를 위한 커리큘럼을 탄탄하게 제공하는 것이 필수적이라고 느꼈다.
문제 정의를 잘하면, 솔루션은 따라온다
사용자의 진짜 문제를 찾으면, 그에 따른 솔루션과 완성도를 높이는 것은 어렵지 않다고 생각했다. 그래서 이번 기수는 ‘완성도’에 대한 부담감을 내려놓고 문제 검증 과정을 더 깊이 경험할 수 있는 기수로 만들어보고 싶었다.
운영진 회의에서 처음 이 아이디어를 제안했을 때, 우려의 목소리도 있었다. 특히 완성도에 대한 높은 기대감과 16주라는 제한된 시간 속에서 새로운 접근 방식을 적용하는 것이 가능할지에 대한 우려가 많았다.
그럼에도 불구하고, 과거에 겪었던 ‘서비스 종료’라는 반복적인 경험 덕분에 운영진들은 이 시도의 필요성에 공감해 주었다. 우리는 아래의 3가지 시도를 해보기로 했다.
목표: 검증을 통해 사용자의 진짜 문제를 해결하는 15기 만들기
1. 속도보다 검증이 중요하다는 분위기 형성하기
초반에 세운 가설은 당연히 틀릴 수 있으며, 이를 검증하는 데 시간이 오래 걸려도 괜찮다는 점을 멤버들에게 전달하고자 했다.
2. 검증할 수 있는 세션 늘리기
서비스를 만들다 보면, 마치 사용자가 원하는 것을 내가 다 맞출 수 있을 것 같은 착각에 빠지기 쉽다. 주관에 의존에 서비스를 만드는 것을 방지하기 위해, 제삼자가 객관적으로 브레이크를 걸 수 있는 피드백 시간들을 많이 제공하고자 했다.
3. 액션으로 끝나지 않도록 회고시간 만들기
일정이 촉박하면 피드백을 받더라도 실제 개선까지 이어지지 않는 경우가 많다. 검증 후엔 반드시 회고 세션을 마련하여, 팀원들이 얻은 인사이트를 공유하고 다음 단계에서 이를 어떻게 반영할지 고민할 수 있는 시간을 제공하고자 했다.
이를 위해서 6개월간 정말 많은 고민과 시도를 했다. 그리고 15기가 끝난 후 멤버들에게 피드백을 받았다. 구체적인 이야기와, 멤버들의 피드백은 다음글에서 더 자세히 소개할 예정이다.
