RE:MIT
Fullstack학과 스터디룸 예약 관리 시스템
학과 사무실에서 수동으로 관리하던 스터디룸 예약을 웹 서비스로 전환한 예약 시스템입니다. 배포 이후 사용자 문의와 개선 요청을 반영하며 실제 학과에서 운영 중입니다.
프로젝트 개요
- 목표
- 수작업으로 운영하던 가천대학교 금융수학과 스터디룸 예약과 학과생 인증을 웹 서비스로 전환했습니다.
- 배경
- 예약 처리·학과생 여부 확인·열쇠 관리가 대면 업무와 상주 인력에 의존해 학생과 관리자 모두에게 반복적인 운영 부담이 발생했습니다.
- 주요 기능
- 학과생 이메일 기반 회원가입·로그인과 비밀번호 찾기를 Google SMTP 메일 인증으로 구현했습니다.
- 스터디룸 예약 생성·조회, 그룹 예약, 최대 4시간 예약 제한, 진행 중 예약 표시를 제공합니다.
- 예약자에게만 열쇠함 접근 정보를 제공하고, 노출 시간을 10분으로 제한했습니다.
- 유저·예약·알림·페널티를 관리하는 관리자 페이지와 페널티 가이드라인·알림을 운영합니다.
- 자체 관리자 통계와 Microsoft Clarity를 결합해 실제 예약 지표와 사용자 행동을 함께 확인하는 운영 모니터링 체계를 구축했습니다.
- 기능 개선하기 버튼을 통해 사용자 피드백을 반영하고 기능을 지속적으로 개선하고 있습니다.
역할·팀 구성
팀 내 역할 분담 · 5인 팀
- PM / Fullstack · 본인
- 요구사항 정리와 일정 관리, 예약·관리자 기능 개발, 운영 개선
- 팀원 · 전체 5인 구성
- 화면과 기능 단위로 프론트엔드·백엔드 구현을 분담
담당 역할
PM · Fullstack Developer
서로 다른 이해관계자의 요구를 인증·예약 기능으로 구체화하고, 배포 이후 개선까지 맡았습니다.
이용 기준 협의 및 인증 절차 구현
- 이용 기준·물품 관리 수칙 협의
PM 겸 풀스택 개발자로 교수님과 이용 기준·물품 관리 수칙 협의 및 정의
- 학과생 전용 인증 절차 구현
학과생 전용 인증 절차 구현
기능 구현 및 안정화
- 예약·관리자·알림 기능 구현
예약·관리자·알림 기능 구현
- QA 기반 예외 처리 안정화
예약 중복, 인증되지 않은 접근, 비정상 요청에 대한 처리 로직을 QA 관점에서 점검·보완, 운영 시나리오 기반으로 안정화
뷰 리팩토링으로 파일 크기 개선
- 리팩토링 범위 설정
비대해진 뷰의 유지보수성을 높이기 위한 리팩토링 범위 설정
- 이미지·SVG 분리 성과
base64 이미지와 인라인 SVG를 분리해 핵심 파일 크기를 82.7KB에서 8.3KB로 약 90% 감소
서비스 운영·개선
- 운영 방식 디지털 전환
대면과 상주 인력에 의존하던 운영 방식을 디지털로 전환해 학과의 관리 자원 부담 감소
- 사용자 피드백 기반 개선
배포 이후 접수된 사용자 문의와 개선 요청을 수집·분석해 실제 이용 환경에 맞게 기능 개선 중
- 운영 모니터링 체계 구축
회원·예약·취소·재이용 지표를 제공하는 자체 관리자 통계와 Clarity의 히트맵·세션 기록을 함께 구성하고, 운영 환경에서만 수집되도록 분리해 민감 정보 마스킹 적용
사용 기술 & 이유 & 구현
Laravel · PHP · Blade
- 선택 이유
- 인증·라우팅·DB 처리와 서버 렌더링 화면을 하나의 MVC 구조에서 구현하기 위해 사용했습니다.
- 구현 내용
- 가입·인증·예약·관리자 기능을 개발하고 Blade 뷰에서 정적 에셋과 반복 UI를 분리했습니다.
MySQL
- 선택 이유
- 사용자·스터디룸·예약 간 관계와 이용 기록을 관리하기 위해 사용했습니다.
- 구현 내용
- 예약 생성·조회·취소와 관리자 통계에 필요한 관계형 데이터를 처리했습니다.
Google SMTP
- 선택 이유
- 학과 이메일 목록과의 일치 여부뿐 아니라 실제 이메일 소유 여부도 확인해야 했습니다.
- 구현 내용
- 학과생 이메일 대조 후 인증 메일을 보내 가입·비밀번호 찾기 흐름을 구성했습니다.
Microsoft Clarity
- 선택 이유
- 예약 건수와 같은 결과 지표만으로 설명하기 어려운 클릭·이탈 흐름을 살펴보기 위해 사용했습니다.
- 구현 내용
- 자체 회원·예약 통계와 히트맵·세션 기록을 함께 확인하고, 운영 환경에서만 수집하며 민감 정보를 마스킹했습니다.
문제 해결 사례
사례 1프로토타입을 활용해 학과생 인증에 필요한 정보 확보
1. 오류 분석
- 문제 현상
- 학과생만 이용할 수 있는 서비스를 구현하려면 학생 이메일을 활용한 인증이 필요했습니다. 하지만 교수님께서 개인정보 제공에 대한 우려를 가지고 계셔서 이메일 정보를 받을 수 없었고, 학과생 여부를 확인해야 한다는 핵심 요구사항을 구현하기 어려운 상황이었습니다.
- 원인
- 학과생 인증에 필요한 이메일의 사용 목적과 범위가 충분히 공유되지 않아 개인정보 활용에 대한 합의가 어려웠습니다.
- 추가 확인 사항
- 별도 증빙 없이 가입하려는 학생 요구와 학과생만 이용해야 한다는 운영 기준을 함께 충족해야 했습니다.
2. 개선 과정
- 1.이해관계자 요구 확인
- 2.이메일 사용 범위 정리
- 3.가입 흐름 문서화
- 4.프로토타입 시연
- 5.활용 동의·인증 기준 확정
- 6.인증 구현
단순히 이메일 정보가 필요하다고 요청하는 대신, 회원가입부터 로그인, 학과생 여부 확인까지 이메일이 실제로 어떻게 사용되는지 과정을 정리했습니다. 또한 설명만으로는 서비스 구조를 전달하기 어렵다고 판단해 회원가입과 로그인 화면을 직접 구현한 프로토타입을 만들고 시연했습니다. 이를 통해 이메일이 다른 목적으로 사용되는 것이 아니라 학과생 여부를 확인하기 위한 최소한의 정보라는 점을 설명했습니다.
3. Before & After 비교
| 항목 | Before | After |
|---|---|---|
| 인증 방식 | 미정 | 이메일 대조 + SMTP |
| 이메일 활용 | 사용 범위에 대한 우려 | 목적·범위 합의 |
| 운영 방식 | 학과 사무실 수작업 | 실제 학과 웹 서비스 |
해결 결과
프로토타입을 통해 개인정보의 사용 목적과 범위를 구체적으로 설명하면서 교수님의 동의를 얻어 학생 이메일 정보를 제공받을 수 있었습니다. 이를 바탕으로 학과생만 가입하고 서비스를 이용할 수 있는 인증 기능을 구현했고, 서비스의 핵심 요구사항을 충족해 실제 학과 운영까지 이어갈 수 있었습니다.
사례 2비대해진 Blade 뷰를 기준에 따라 분리해 유지보수성 개선
1. 오류 분석
- 문제 현상
- Blade 뷰 내부에 이미지가 base64 형태로 포함되고 아이콘도 SVG 코드가 직접 작성되어 있어 파일 크기가 커지고 같은 요소를 여러 화면에서 재사용하기 어려웠습니다. 전체 뷰를 확인한 결과 base64 이미지 5개와 인라인 SVG 54개가 사용되고 있었으며, 가장 큰 파일은 82.7KB까지 증가한 상태였습니다.
- 원인
- Base64 이미지와 반복 SVG 코드를 뷰에 직접 포함해 화면과 에셋의 관리 책임이 섞였습니다.
- 추가 확인 사항
- 정규식으로 여러 파일을 수정할 때 예상 변경 개수와 실제 화면 동작을 함께 확인했습니다.
2. 개선 과정
- 1.뷰 크기·인라인 에셋 분석
- 2.분리 기준 수립
- 3.이미지 정적 파일화
- 4.SVG 공통 컴포넌트화
- 5.화면·변경 개수 확인
- 6.파일 크기 재측정
먼저 개선 기준을 정했습니다. Blade 파일은 150줄 이하로 관리하고, 반복해서 사용하는 SVG는 컴포넌트로 분리하도록 기준을 세웠습니다. 이후 base64 이미지는 정적 파일로 분리하고 반복되는 아이콘은 공통 컴포넌트로 변경했습니다. 여러 파일을 한 번에 수정해야 하는 부분은 정규식을 활용하되, 예상한 개수만큼 변경됐는지 확인하는 검증 과정을 추가해 기존 화면의 동작이 달라지지 않도록 했습니다.
3. Before & After 비교
| 항목 | Before | After |
|---|---|---|
| 가장 큰 Blade 파일 | 82.7KB | 8.3KB · 약 90% 감소 |
| 뷰 내부 Base64 이미지 | 5개 | 0개 |
| 인라인 SVG | 54개 | 30개 |
해결 결과
가장 큰 Blade 파일의 크기를 82.7KB에서 8.3KB로 약 90% 줄였습니다. 뷰 내부의 base64 이미지는 5개에서 모두 제거했고, 인라인 SVG도 54개에서 30개로 줄였습니다. 반복되는 에셋을 별도로 관리할 수 있게 되면서 파일 구조가 단순해졌고, 같은 아이콘을 여러 화면에서 재사용할 수 있도록 개선했습니다.
프로젝트 성과 및 결과
- 가천대학교 금융수학과에서 실제 스터디룸 예약·관리 서비스 운영
- 학과생 여부와 이메일 소유 여부를 함께 확인하는 가입 기준 구현
- Blade 파일 82.7KB → 8.3KB, 약 90% 감소
- 자체 예약 통계와 Clarity를 활용한 운영 모니터링 및 사용자 피드백 반영
프로젝트 회고
기술적 한계와 개선 방안
- 한계·아쉬운 점
- 초기에는 기능 구현에 집중해 뷰와 정적 에셋을 충분히 분리하지 못했습니다.
- 개선 방향
- 새 기능을 개발할 때부터 Layout·Component·Asset의 책임과 파일 관리 기준을 적용할 계획입니다.
- 한계·아쉬운 점
- 사용자 행동을 확인했지만 UI 개선 전후의 예약 완료율을 체계적으로 비교하지 못했습니다.
- 개선 방향
- 배포 시점부터 가입·예약 완료율을 수집해 문제 발견 → UI 개선 → 지표 재측정으로 이어갈 계획입니다.