프로젝트가 끝이 나고 나면, 완성된 결과를 보고 뿌듯함을 느끼곤 한다.
그러나 결과는 결과일뿐이다. 프로젝트가 상업적 목표를 향해 나아갔다면, 결과는 결과 나름대로 의미가 있겠다. 하지만 단순히 더 나은 기획자가, 더 나은 개발자가 되기 위해서 만든 프로젝트에게 결과는 중요하지 않다. 그 과정에서 어떤 것을 얻었으며, 어떤 것이 부족했고, 추후에 그것을 어떻게 채워나갈지가 진정으로 중요한 것이다.
이러한 관점에서, 그동안의 여러 프로젝트들의 과정이 사라진 것은 꽤나 뼈아픈 일이다. 지금이라도 하나씩 과정들을 기록해보자.
Term2 : 2023.10.30 ~ 2024.01.12
Term2는 우리 팀이 가장 고생을 많이 한 시기이기도 하고, 팀으로서의 구색이 잡혀나가기 시작할 무렵이기에 개인적 소회가 유독 남다른 것 같다. Temr2동안 우리가 가졌던 고민들을 하나씩 살펴보도록 하자.
FEAT : 태그와 카테고리
Term1의 사용자에게 들었던 첫번째 피드백이었다.
행사에 태그를 달 수 있는 기능
지금 행사 제목을 2023-2 A팀 2차 주간발표 이렇게 해놓았는데, 이것보다는 2차 A팀 주간발표라는 제목을 가지고 태그로 2023-2, 주간발표 등의 속성을 가질 수 있게 하는게 후에 지속적으로 사용했을 때 데이터 정리에 더 효과적일 것 같아요. (태그별 검색 등)
사실 우리가 처음에도 고려했던 기능이었다.서비스가 지속될 때, 행사의 개수가 늘어나면 이를 분류하기 위한 기능이 필요한 것은 당연한 수순이었다. 하지만 첫번째 버전에서만큼은 최대한 빠르게 MVP를 적용하고 싶었고 기능을 다음으로 미루게 되었다. 이제는 본 기능에 대한 피드백을 받기도 하였고, Term1에서도 충분히 고려했던 내용이였기에 우리는 빠르게 분류를 할 수 있는 기능을 추가하기로 하였다.
태그를 도입해보자!
처음에 기획 단계에서 요구했던 것은 태그 기능이었다. 사용자의 피드백 역시도 태그 였다. 노션의 데이터베이스를 사용할 때 ‘다중선택’처럼, 사용자가 카테고리를 직접 만들고, 행사에 태그를 붙이고 삭제를 할 수 있게 하는 방식을 적용해보자는 것이었다.
하지만 회의를 거치고 나서, 개발팀에서는 태그 기능은 기술적 리소스가 꽤나 많이 들어간다는 답변을 내주었다. 그래서 우리는 다시 고민하였다.
“태그”라는 기능을 기술적 리소스의 소비를 감안하면서까지 만들어야 하는 기능인가?
행사의 성격 :분류의 기준은 그렇게 많지 않을 수도 있다.
어떻게 분류할까에 대해서 고민하기 앞서서, 행사의 성격을 살펴보았다.
에코노베이션에서는 고정적인 행사들이 있다. 동아리 내의 필수 참여 행사인 주간 발표가 대표적인데, 매주 금요일마다 진행된다.
유동적인 행사들도 존재한다. 에코노베이션의 ‘행사부’는 언제든 자신들이 원하는 행사를 개최한다. 또한 행사부가 아니더라도 모든 인원들은 함께하고 싶은 행사가 있다면 편하게 행사를 만든다.
사용자가 직접 태그를 작성하기에는 행사의 분류는 생각보다 많지 않다. 사용자에게 분류를 맡기기보다는 우리가 먼저 카테고리를 만들어서 정해진 기준에서 분류를 하도록 유도한다면 굳이 태그 기능을 만들 필요가 없었다.
Solution : 카테고리
그래서 우리는 행사의 주최에 따라 카테고리를 분류하였고, 전체 탭을 통해서 모든 행사들을 볼 수 있게끔 하였다.
한정된 시간 내에서 100%를 구현할 수는 없다.
(여담이긴 하지만 우리 팀의 BE개발자인 Mandu가 공유해준 내용과 일맥상통하는 면이 있는 것 같다.)
태그 기능이 카테고리 기능보다 서비스에서 완성도가 높을 수 있다. EEOS가 지속된다면, 우리가 만든 카테고리와 다른 성격의 행사들이 늘어날 수도 있고, 그러면 기타 행사 카테고리에만 행사들이 쌓일 수도 있다. 하지만, 우린 지금 당장 사용자를 만나야만 했다. 배포에는 마감기한 있었기에 어떻게든 필요한 기능을 구현해야만 했다.
문제가 있을 때 그것을 해결할 방법이 뛰어난 기술만이 있는 것이 아니다. 문제의 근본적인 성격을 짚어본다면 새로운 해결책이 나올수도 있다.
