삼육대학교 멋쟁이사자처럼 14기 홈페이지
syu-likelion
분산된 동아리 운영을 하나의 플랫폼으로
멋쟁이사자처럼 삼육대학교의 모집·운영 플랫폼입니다. 지원서 작성부터 서류·면접 평가, 합격 후 공지·자료·과제·일정까지 이어지는 화면을 구현하고 운영 중 발견한 문제를 수정했습니다.
The Problem
홍보, 지원서, 면접 평가, 수업 자료, 공지가 모두 다른 곳에 흩어져 있어, 지원자도 동아리원도 필요한 정보를 찾느라 시간을 쓰고 있었습니다.
- 기간
- 2026.01 — 현재
- 역할
- Frontend Developer
- 상태
- 운영 · 유지보수 중
내가 맡은 것
- 지원서 작성 · 임시 저장 · 제출 후 수정
- 면접 시간 선택 · 예약
- 운영진 서류 · 면접 평가와 합격 관리 화면
- 공지 · 세션 자료 · 과제 · 일정 등 부원 공통 공간
- 운영 중 후속 수정
팀원 · 다른 파트가 맡은 것
- 초기 인증 · 헤더 · 관리자 구조
- 출결 관리
모집과 운영에서 제가 맡은 화면
프론트엔드 2명, 백엔드 2명, 디자이너 1명이 함께 만들었습니다. 저는 지원자 화면과 운영진 평가·운영 화면을 담당했습니다.
- Main · FAQ · 운영진 소개
- 지원서 작성 · 임시 저장 · 파일 업로드
- 결과 상태별 화면 · 면접 시간 예약
- 마이페이지 활동 · 일정
- 운영진용 지원자 관리
- 서류 평가 · 면접 평가
- 최종 합격 관리
- STAFF 역할 기반 화면 접근 제어
- 공지 · 세션 자료 관리
- 과제 제출 현황 · 평가
- 운영 일정 관리
- 동아리원 커뮤니티 · 자유게시판
출결 관리는 다른 팀원이 구현했습니다. 아래 개인 기여에는 포함하지 않습니다.
네 도구에 흩어진 운영을 한곳으로
지원서는 Google Forms로 받고 Excel로 옮겨 정리했습니다. 지원자 한 명을 평가할 때 답변과 점수를 대조하고, 다른 운영진의 의견은 Discord와 KakaoTalk에서 찾아야 했습니다.
기존 모집 업무
- Google Forms로 지원서 수집
- Excel로 옮겨 정리
- Discord · KakaoTalk으로 의견 교환
- 수작업으로 대조하며 합격자 결정
플랫폼에서의 모집 업무
- 플랫폼에서 지원서 제출
- 지원서를 보며 그 자리에서 점수 · 코멘트 입력
- 면접 평가
- 최종 합격 관리
지원자·동아리원·운영진이 같은 서비스에서 각자의 업무를 수행하도록 구성했습니다. 최종 합격자는 지원할 때 쓰던 계정으로 동아리원 권한을 받아 학기 중 활동을 이어갑니다.
지원서 작성부터 결과 확인·면접 예약까지
작성 중인 지원서와 제출한 지원서를 다른 상태로 두었습니다. 자기소개나 포트폴리오를 준비하다가 중단해도 임시 저장한 지원서에서 이어 쓸 수 있습니다.
제출 이후에도 수정이 필요했습니다. 다만 발표 이후에 답변이 바뀌면 이미 확정된 평가와 어긋날 수 있어 수정 가능한 시점을 화면에 안내했습니다.
제출한 지원서를 언제까지 수정할 수 있게 할지 정해야 했습니다.
- 제출하면 수정 불가
- 지원 마감 전까지만 수정 가능
- 1차 결과 발표 전까지 수정 가능
1차 결과 발표 전까지 수정 가능
1차 결과 발표를 수정 가능 여부의 경계로 정했습니다. 제출 완료 화면에 발표 일정과 수정이 불가능해지는 시점을 함께 적고, 그 전에는 지원서 수정과 취소를 제공했습니다.
- 1. 1차 결과 발표일과 면접 기간을 제출 완료 화면에 함께 적었습니다.
- 2. 발표 전까지는 지원서 수정과 지원 취소를 할 수 있습니다.
- 3. 수정이 불가능해지는 시점을 버튼 바로 아래에 안내합니다.
서류 합격자는 결과 화면에서 면접 날짜와 시간을 고릅니다. 최종 합격자는 OT 일정과 커뮤니티 채널 안내로 이어집니다.
지원자 한 명을 평가하는 화면
운영진 목록은 서류 지원자부터 최종 합격자까지 모집 단계에 맞춰 나눴습니다. 기수·파트·상태·내 평가 여부 필터로 확인할 지원자를 좁힐 수 있습니다.
모집 운영 단계
- 01지원서 제출
- 02지원서 조회
- 03운영진 코멘트 · 점수 입력
- 04서류 합격자 결정
- 05면접 평가
- 06최종 합격자 결정
지원서를 평가하려면 지원자의 답변과 다른 운영진의 점수·코멘트를 함께 봐야 하는데, 이 정보가 서로 다른 화면에 있어 대조가 어려웠다.
- 평가 화면에 지원서 요약만 함께 노출한다
- 지원서와 평가를 별도 화면으로 두고 링크로 연결한다
- 하나의 상세 화면 안에서 서류 보기 · 점수 매기기 · 점수 현황을 전환한다
하나의 상세 화면 안에서 탭으로 전환
요약만 보여주면 결국 원본을 다시 열게 되고, 화면을 나누면 대조할 때마다 이동이 생깁니다. 지원자 한 명이라는 맥락을 유지한 채 보는 대상만 바꾸는 편이 실제 평가 행동에 가장 가까웠습니다.
- 1. 지원자 목록을 서류 지원자부터 최종 합격자까지 모집 단계별로 나눴습니다.
- 2. 지원자 한 명 안에서 서류 보기 · 점수 매기기 · 점수 현황만 바꿔 봅니다.
- 3. 총점이 같아도 어느 문항에서 갈렸는지 보이도록 문항별 점수를 함께 둡니다.
운영 중에는 블라인드로 진행하는 서류 평가와 신원을 확인하는 면접 평가에 필요한 정보가 다르다는 피드백을 받았습니다. API 명세와 프론트엔드를 함께 고쳐 면접 단계에서는 후보 이름을 보여주고, 목록을 모집 단계별로 나눴습니다.
목록
- 서류 지원자 목록 (지금 보는 목록)
- 서류 합격자 목록
- 최종 합격자 목록
지원서 상세
- 지원자
- 이름 비공개 · 블라인드
- 파트
- FRONTEND
- 평가
- 서류 보기 · 점수 매기기 · 점수 현황
- 1. 서류 단계에서는 서류 지원자 목록에서 지원자를 고릅니다.
- 2. 블라인드로 평가하므로 지원자 이름을 보여주지 않습니다.
목록
- 서류 지원자 목록
- 서류 합격자 목록 (지금 보는 목록)
- 최종 합격자 목록
지원서 상세
- 지원자
- 지원자 A (가상)
- 파트
- FRONTEND
- 평가
- 서류 보기 · 점수 매기기 · 점수 현황
- 1. 면접 단계에서는 서류 합격자 목록에서 고릅니다.
- 2. 신원을 확인하며 진행하는 단계라 후보 이름을 보여줍니다.
두 단계에서 바뀌는 것은 지원자 이름 표시와 지원자를 고르는 목록입니다. 이 예시는 화면 판단만 설명하며, 실제 평가 저장이나 권한 판별, 서버 보안과는 관계가 없습니다.
프론트엔드에서는 활성 역할이 STAFF일 때 운영진 화면을 열고, 인증 정보가 없는 경우와 권한이 없는 경우를 구분했습니다. 이는 화면 접근을 제어한 범위이며 서버 전체의 권한 검증을 구현했다는 의미는 아닙니다.
합격 이후에도 이어지는 과제와 일정
합격 후에는 같은 계정으로 공지·세션 자료·과제·질의응답을 이용합니다. 공통 공간은 콘텐츠 종류와 트랙으로 필터링하고, 과제 카드에서 마감일 확인·파일 제출·평가 결과 확인을 이어갈 수 있게 했습니다.
운영진에게는 공지·자료 관리, 과제 제출 현황과 평가, 일정 등록 기능을 제공했습니다. 등록된 세션과 과제 마감일은 동아리원의 마이페이지 캘린더에도 표시됩니다.
2026-08-16 기준 공지·세션 자료가 30건 등록되어 있었습니다. 모집 이후에도 자료 공유와 과제·일정 운영에 사용했습니다.
API 명세와 응답이 달랐을 때
API 명세와 실제 응답이 달라 화면이 예상대로 동작하지 않는 일이 반복됐습니다. 백엔드 개발자에게 바로 문의하기 전에 오류를 재현하고 Network Response를 명세와 대조했습니다.
불일치를 처리한 순서
- 01문제 재현
- 02Network Response 확인
- 03API 명세와 비교
- 04백엔드 개발자와 필드 · 응답 계약 조율
- 05프론트엔드 수정
- 06정상 동작 확인
재현한 상황과 응답을 근거로 필요한 필드와 응답 형식을 조율한 뒤, 프론트엔드를 수정하고 정상 동작을 확인했습니다. 처음부터 응답 예시까지 문서로 맞췄다면 반복되는 확인을 줄일 수 있었을 것입니다.
운영 중에는 다음 문제도 수정했습니다.
- 로그인 이후 원래 가려던 화면으로 돌아가지 않던 리다이렉트 흐름
- 노출되면 안 되는 필드가 특정 조건에서 보이던 숨김 필드 정책
- 과제 승인 페이지의 잘못된 URL Routing
운영 결과와 다음에 바꿀 것
14기 지원서 접수부터 서류·면접 평가, 합격 이후 부원 운영까지 이 서비스로 진행했고, 지금도 동아리 부원들이 사용하고 있습니다.
- 정적 배포에서 관리자 상세 경로와 조회 오류를 겪고, 서버 담당자에게 Next 산출물을 전달하는 통합 배포로 전환했습니다.
- 계정을 바꾸면 과제 제출 파일명이 섞이지 않도록 캐시 기준을 계정과 과제로 나누고, 미제출 상태에서는 캐시를 보여주지 않았습니다.
- 반려된 과제의 재제출을 새 제출이 아니라 기존 제출 수정 요청으로 연결했습니다.
- 제출 현황 조회가 실패해도 과제 상세가 성공하면 운영자가 수정 폼을 쓸 수 있도록 실패 처리를 나눴습니다.
운영진의 평가 정보를 같은 지원자 화면에 모으고, 지원서·결과 상태에 따라 다음 행동을 안내한 구성이 실제 운영에 쓰였습니다.
다시 만든다면 운영진 화면을 먼저 만들겠습니다. 실제로 평가 업무를 해 보기 전에는 필요한 정보와 화면 이동의 불편이 잘 드러나지 않았습니다. API 협업은 응답 예시와 상태별 동작을 문서로 먼저 맞추겠습니다.