EEOS - 5월 4주차 진행 상황

EEOS 3.0

EEOS는 새로운 전환점을 맞았다. 이제 우리 서비스의 핵심 가치는 다음과 같다.

주간발표 with EEOS!

기존의 EEOS가 동아리 내의 모든 행사들에 대한 관리를 지향했다면, EEOS 3.0은 오직 주간발표라는 행사 하나에만 초점을 맞추기로 했다. 그렇다면 우선 주간 발표가 무엇인지 샅샅이 살펴볼 필요가 있다.

주간발표란?
에코노베이션의 주요 행사 중 하나로, 매주 동아리원을 상대로, 팀 별 발표를 진행합니다. 팀의 진행상황, 개발 중에 얻은 인사이트 등을 자유롭게 공유합니다.

• 주간 발표는 에코노베이션의 아이덴티티를 나타내는 중요한 행사 중 하나이다. 그러다보니, 모든 동아리원이 매주 필수적으로 참여하는 행사이며, 출석관리가 필요하다.

• 또한 우리는 발표 자료를 모두 에코노베이션 GitHub에 업로드를 하는데, 매번 GitHub에 들어가서 레포를 찾고, 원하는 팀의 폴더에 들어가야 한다.

• 발표가 끝나면, 동아리원들은 자유롭게 질문을 주고 받는다. 하지만 시간상의 문제로 모든 질문에 대한 답변을 할 수 없다. 또한 질문들은 향후 프로젝트를 발전해나갈 수 있는 인사이트가 될 수도 있지만, 따로 녹화가 진행되지는 않기에 아카이빙이 불가능하다.

이러한 주간발표의 특징들을 고려하여 우리는 EEOS3.0의 기능을 고민했다.

출석관리

기존의 출석관리는 모두 동아리원의 자율에 맡겼다. 행사가 생성되면 동아리원들은 자신의 출석 상태를 행사 당일까지 자유롭게 수정할 수 있었다.

물론 동아리원을 믿지 못하는 것은 아니지만.. 기존의 출석 관리 시스템은 신뢰성의 확보가 어려웠다. 자신의 출석 상태를 속여서 입력하는 회원은 없었지만, 주로 불참하는 회원들은 EEOS에 출석 상태를 기입하지 않는 경우도 있었다.

그래서 우리는 출석관리 기능의 "신뢰성 확보"를 목표로 삼았다.

이를 해결하기 위해 여러가지 아이디어들이 나왔다.

1. 관리자에게 매번 행사마다 비밀키를 제공하고, 현장에서 비밀키를 동아리원에게 공유한다.

2. 학교 와이파이에 접속한 인원만 출석 체크를 할 수 있게 한다.

3. 관리자가 행사를 생성하면, 출석체크를 직접 열고 닫을 수 있다.

1번의 문제는, 비밀키라는 기능 자체가 회원들에게 거부감을 줄 수도 있다는 것이였다. 동아리의 성격 상 자발적으로 참여하는 것을 유도하게 해야지, 점점 더 강제로 규율을 만들다 보면 그 자체로 거부감이 생길 수도 있다는 우려가 있었다.

2번의 문제는, 신뢰성의 확보에서 상당히 떨어진다는 것이다. 주로 학교에 있으면 학교 와이파이를 사용하기 때문에, 특히나 지각 같은 경우에는 체크가 어렵다.

그래서 우리는 3번을 채택하기로 했다.
관리자가 행사를 생성하고, 출석체크를 연다. 그 후 관리자는 출석 체크가 열린 상태에서 현재의 출석을 참석으로 받을지, 지각으로 받을지 선택할 수 있다.
사용자들은 관리자가 출석체크를 열어야만, 출석체크를 할 수 있다. 사용자는 더 이상 참석과 지각, 불참과 같은 자신의 출석 상태를 선택할 수 없고, 오직 출석 체크만 할 수 있다.

발표 자료

앞서 언급하였듯이, 우리 동아리는 발표자료를 깃허브에 업로드를 한다. 그렇기 때문에 발표가 시작될 때마다 회원들은 발표자료를 보기 위해서 Githubd에 접속한다. 우리는 이러한 발표 자료를 EEOS 내부에서 보여주고 싶었다.

EEOS 내부에서 발표 자료를 확인할 수 있도록 하자!

이를 해결하기 위해 여러가지 아이디어들이 나왔다.

1. EEOS 안에서 Github 페이지 전체를 보여준다. (iframe)

2. Github안의 파일들을 모두 크롤링해서 EEOS에서 파일을 보여준다.

3. 실시간 화면을 송출한다.

4. 팀 별 Github 링크까지만 보여준다.

1번의 문제는, Github가 ifarme을 지원하지 않기에 애초에 불가능한 문제였다.
2번의 문제는 너무 많은 리소스가 든다는 것이다. Github에서 팀 별 파일을 수합해서 서버에 저장시킨다. 이 후 EEOS에서 각 파일들을 보여준다. 우선 파일의 용량이 굉장히 크다. 이걸 언제까지 저장할 수도 없다. 또한 파일의 형식이 모두 다르다. 어떤 파일은 Figma링크일수도 있고, PPT파일일수도 있고, Pdf 파일 형식일 수도 있다. 그러다보니 실제 EEOS에서 파일을 보여줄 때의 기준을 잡기가 어렵다. 마지막으로는 파일 자체를 찾는 것이 어렵다. 팀원들마다 파일에 대한 PR의 시점이 다르기 때문에, 파일의 수합시점이 애매하다.
3번의 문제는, 2번보다 더 많은 리소스가 든다는 것이다. 실시간 송출에 대해서는 더 이상 얘기하지 않겠다....
그러다보니 우리는 4번을 결정하기로 했다. 하나의 Github 링크를 받아와서 프론트 단에서 팀 별 폴더를 확인하고, EEOS 화면에는 그 폴더에 대한 링크를 제공할 예정이다.

질문 게시판

질문들을 기록할 수 있는 게시판을 만들기로 하였다. 사실 여기서는 크게 아이디어가 갈리는 일은 없었다. 단순히 게시판 형식이 EEOS에 추가되기 때문에 크게 어려운 점은 없었다.

네이버의 댓글 시스템을 차용하기로 했다. 우선 팀 별로 카테고리를 만들고, 팀 별로 질문을 남길 수 있다. 또한 답글은 댓글 당 한개 씩 작성할 수 있으며 모든 댓글과 답글은 작성한 사용자가 수정과 삭제를 할 수 있다.

관리자(Admin)

사실 이전까지 관리자를 만들자는 의견은 많았지만, 회원들이 스스로 관리할 수 있다는 믿음이라는 방패로 관리자를 페이지를 계속 미루었다. 하지만 3.0으로 전환하는 마당에 더 이상 관리자 페이지를 미룰 수 없다는 의견이 팀 내부적으로 생겼고, 우리는 관리자 페이지를 도입하기로 했다.

관리자 페이지의 필요한 기능은 다음과 같다:

팀 관리하기

우선 앞선 질문 게시판의 팀 별 카테고리를 위해 현재 활동하는 팀들의 이름을 저장할 필요가 있다.

회원 관리하기

에코노베이션에는 회원의 활동 상태를 크게 4가지로 구분한다. AM(활동회원) / RM(휴식회원) / CM(수료회원) / OB(졸업회원)이다. 현재는 회원들이 직접 자신의 상태를 변경할 수 있게 하였지만, 관리자 페이지가 있는 이상 굳이 직접 변경하게 할 이유가 없었다. 특히 회원들이 그렇게 성실하게 자신들의 활동 상태를 변경하지 않았고, 그럴 바에는 관리자가 직접 한 학기에 한번씩 회원 상태를 업데이트 하는게 낫다는 판단이였다.

행사 생성하기

기존에는 모든 회원이 행사를 생성할 수 있었지만, 이제 주간발표에 초점을 맞추기로 한 EEOS는 더 이상 모든 회원에게 행사 생성의 권한을 줄 필요가 없었다. 그렇기에 관리자 페이지에서만 행사를 생성할 수 있게 하였다.

행사 수정하기

수정 권한 역시 행사 생성하기와 같은 맥락이다.

행사 Detail -> 출석 체크 열고 닫기

행사 디테일에서는 출석관리로부터 비롯된다. 관리자가 행사를 생성하고, 출석 체크를 열여서 관리자가 회원의 출석 상태를 출석으로 할지 지각으로 할지 선택할 수 있게 하였다.

그래서 우리는...

본격적인 기능들을 정했다. 이제 개발할 일만 남았다! 개발하기 전에 꼭 필요한 문서들을 정하였다.

• WireFrame
• 기능명세서
• 정책정의서
• ERD
• API명세서

다음 주에는 본 문서들을 작성하는 과정들과 문서들을 토대로 한 백로그 구분과 일정 수립에 대해서 공유하고자 한다.