마루는 학생들이 직접 만들어 나가는 부산소프트웨어마이스터고등학교의 새로운 입학 전형 플랫폼입니다.
올해 3월 30일 계획발표회부터 11월 30일 소프트웨이브까지 장장 246일 간의 여정을 돌아보며 이 회고록을 작성했습니다.
제 고등학교 2학년을 바친 프로젝트인 만큼 뜻 깊고 또 애정이 가는 프로젝트입니다.
재미있게 읽어주시면 감사하겠습니다.
실제로 기획 단계에서 올해 입학한 3기 학생 5명을 대상으로 인터뷰를 진행한 결과, 4명의 학생이 입학 과정에서 입학 전형 플랫폼이 사용하기 어려워서 애를 먹었다고 답했어요. 이를 통해 단순히 UI 개선 뿐만 아니라 유저 플로우 자체의 개선이 필요하다는 것을 알게 되었어요.
입학 기간에는 학교 홈페이지와 입학 전형 플랫폼 두 개의 사이트가 동시에 운영이 되고 있었어요. 하지만 입학 설명회 신청, 자주 묻는 질문, 공지사항 같은 입학 관련 기능들은 학교 홈페이지에 있었고, 특히 입학 설명회 신청 기능은 입학 공지사항의 게시글을 통해 이루어지고 있었죠.
이로 인해 사용자는 학교 홈페이지와 입학 전형 플랫폼을 왔다갔다해야하는 번거로움이 있었어요.
인터뷰를 진행하며 학생들이 공통적으로 말했던 불편함이 두가지 있었습니다.
첫번째는 복잡한 교과 성적 산출식을 일일이 직접 계산해야 한다는 점이었어요.
저희 학교 입학 요강에 위 사진 처럼 교과 성적 산출식이 기재되어 있는데, 이를 통해 성적을 점수로 변환하여 반영하게 돼요. 하지만 워낙 복잡한 탓에 사용자가 직접 계산을 하기가 쉽지 않았어요.
두번째는 원서가 자동으로 중간 저장이 안된다는 점이었어요.
오랫동안 작성을 해야하는 원서 특성상 저장이 필수적인데, 자동으로 저장되지 않으니 실수로 페이지를 나가거나, 예상치 못한 오류로 튕겼을 경우 작성하고 있던 원서 내용이 모두 날라가버리는 문제가 있었죠.
기존 입학 전형 플랫폼은 외주 업체에게 외주를 맡겨 운영되고 있었는데, 이를 위해 매년 350만원 이상이 발생하고 있었어요.
또한 선생님이 추가 기능이나 변경 사항을 주문할 경우 반영이 늦어진다는 문제도 있었죠.
위 이미지는 기존 입학 전형 플랫폼의 메인 페이지 모습입니다.
메인페이지에서 대부분의 기능들에 접근할 수 있다는 장점이 있지만 단점도 있었어요.
바로 입학 절차마다 사용자가 취해야 할 행동을 직관적으로 제시해주지 못한다는 점이었어요.
우측에 원서 작성 페이지로 이동할 수 있는 버튼이 있는데, 입학 과정 내내 원서만 작성하는 건 아니거든요.
원서 접수 기간에는 원서를 작성해서 제출해야하고, 1차 합격자 발표 때는 합격자인지 아닌지를 확인해야하고, 2차 전형 때는 직접 학교에 찾아와서 시험을 치뤄야해요.
그래서 입학 절차마다 알맞은 CTA를 제공해서 사용자가 메인페이지에서 CTA를 누르기만 하더라도 입학 절차마다 취해야할 행동을 바로 취할 수 있도록 개선했어요.
또한 그 하단에는 사용자의 접근 빈도가 높았던 정보들을 배치하여서
메인페이지에서 사용자가 원하는 목표에 바로 도달할 수 있도록 했어요.
앞서 언급했던 기능의 분산을 해결하기 위해서 기존에 파편화되어있던 기능들을 마루로 통합했어요.
이를 통해 입학설명회 신청 기능, 공지사항 기능, 자주묻는질문 기능을 통합하여 사용자가 마루 내에서 모든 입학 관련 기능을 사용할 수 있게 되었어요.
복잡한 성적 산출식을 자동으로 계산해주는 기능이에요.
교과성적, 출결 상황, 봉사시간, 자격증 정보를 입력하면 자동으로 전형 별 점수를 계산해줘요.
또한 졸업예정과 검정고시 두가지 케이스 중 선택할 수도 있어요.
성적 모의 계산 기능은 아래 링크에서 로그인 없이 사용해볼 수 있어요.
성적모의계산 하러 가기
원서를 자동으로 저장해주는 기능이에요.
언제든지 마지막으로 작성한 내용 그대로 이어서 작성할 수 있어요.
원서 접수 기간은 끝났지만 원서를 작성하는 것은 아직 할 수 있어요. (제출해도 접수는 안되지만요)
직접 작성하고 나갔다 들어오면 저장되어있는 모습을 보실 수 있으실 거예요.
원서 작성해보기
원서 초안을 제출하기 전에 자동으로 입력하지 않은 곳을 검사해주는 기능이에요.
생각보다 원서 초안을 잘못 제출하여서 교무실에 전화해서 수정하는 분들이 많았어요.
이는 사용자에게도 선생님에게도 그렇게 좋은 경험은 아니죠.
그래서 제출하기 전에 입력하지 않은 곳이 있는지, 있다면 어디를 입력하지 않았는지를 안내해줬어요.
저희는 클라이언트 뿐만 아니라 어드민 페이지도 개발했어요.
기존에 선생님들이 엑셀로 명단을 관리하실 때 불필요한 반복 작업을 하신다는 것을 알게되었고, 이를 해결하기 위해 엑셀 포맷을 제공하고 선생님이 그 포맷 상에서 데이터를 수정하고 엑셀을 업로드만 하더라도 데이터가 반영이 되도록 했어요.
앞에서 언급한 4가지의 개선점을 포함해서 마루의 모든 기능들은 아래 시연 영상에서 확인할 수 있어요.
마루 시연영상
4월부터 9월까지 5개월 남짓한 기간내에 완성을 해야 했기에 그동안 저희는 조직 내에서 보다 효율적인 협업을 위해 여러가지 시도를 해왔어요.
프론트엔드가 UI 퍼블리싱을 할 때 문제가 발생했어요.
단기간에 후다닥 개발을 하다보니 피그마 상의 디자인과 다르게 개발을 해버리는 문제가 생긴거죠.
원래는 디자이너가 배포된 사이트를 보고 오류를 개발자에게 전달해줬는데,
배포를 매일하는 것이 아니다 보니까 개발자의 개발 화면과 디자이너가 보는 화면이 차이가 나서 이도 썩 효율적이진 못했어요.
마루는 gitflow 방식을 통해 기능 단위 PR을 올리고 있었어요.
디자이너인 제가 깃허브를 사용할 줄 알았기 때문에 제가 직접 PR에 참여하는 것이 가능했죠.
그래서 저희가 시도한 방법은 개발자가 퍼블리싱한 것을 PR을 올릴 때 개발된 화면을 녹화하거나 캡쳐해서 PR에 기재하면 디자이너인 제가 그것을 보고 검토를 한 후에 머지를 하는 방식이었어요.
디자이너의 PR참여를 통해 배포하기 전에 미리 대처 가능한 오류들을 수정할 수 있었고, 이는 불필요한 프론트엔드의 수고를 덜어주었죠.
성공적인 시도였지만 만약 디자이너가 깃허브를 사용할 줄 모른다면 도입하기 어렵다는 단점도 있었어요.
이 시도가 가장 빛났던 순간은 아래의 PR이었어요.
궁금하시다면 확인해보세요.
Feat/#33
마루는 버튼부터 6가지 이상의 종류가 있었을 만큼 디자인 시스템이 복잡했어요.
사용되는 UI의 종류도 제가 디자인해본 서비스 중 가장 많았죠.
그래서 중간 발표회쯤부터 디자인 시스템 관리가 필요하다고 느꼈고 이를 위해서 Zeplin과 StoryBook 도입을 시도했어요.
피그마에서 디자인 후 Zeplin으로 업로드를 하면 Zeplin에 UI가 반영이 되고, Zeplin과 StoryBook을 연동하여 StoryBook으로도 확인할 수 있도록 하였어요.
하지만 이 시도는 얼마 가지 못했어요.
앞서 말했듯이 시간은 너무 촉박했고 디자인 시스템 관리에 자원을 투입할 여력이 없었죠.
또한 제플린에서의 몇몇 기능들은 피그마에서도 충분히 대체 가능했기 때문에 도입하기 어려웠어요.
비록 실패했지만 저에게는 의미있는 경험이었어요.
4월부터 12월까지 진짜 열심히 달려왔지만 아직도 마루를 런칭하지 못했다는 점이 너무 아쉬워요.
조금만 더 성실했다면 런칭할 수 있지 않았을까라는 후회도 들구요.
하지만 그랬기에 최종발표회에서 우수상이라는 좋은 성적을 받을 수 있었다고 생각해요.
그래도 마루는 저에게 있어서 정말 의미있는 프로젝트였어요.
단기간에 팀원들과 협업하면서 정말 많은 에피소드가 있었고 그 중 몇몇은 저의 협업 가치관에 큰 영향을 주었죠.
디자인적으로도 마루를 디자인하면서 많이 성장했다고 느껴요.
이 정도 규모의 서비스를 디자인 해본 것도 처음이었고, 그 과정에서 정말 많은 리서치를 진행하면서 더 나은 디자인에 대해서도 끊임없이 고민했죠.
마루 로고를 만들면서 고민하던 때가 엊그제 같은데 벌써 회고록을 쓴다는 게 믿기지가 않네요.
마루 개발한다고 정말 고생 많이한 김석진, 이명재, 그리고 김한울 선배한테 수고많았다고 얘기하고 싶습니다.
마루의 개발이 멈춘 것은 아니지만 당분간은 접어둘려고 합니다.
정말 고마웠어, 굿바이 마루!