<aside> ✅
SoonCHeck · 관리자 버전과 학생 버전으로 구분한 출석체크 앱
관리자는 일정·QR·참여 현황을 관리하고, 학생은 일정 확인·QR 스캔·개인 기록 조회를 수행합니다. 아래에는 이 역할별 구조를 완성해 간 실제 협업 기록을 정리했습니다.
</aside>
2024.09.27 — 10.29
프론트엔드 · 백엔드 · 디자인
관리자 · 학생
교내 학술제 우수상
<aside> 💻
GitHub · 출석체크 앱
</aside>
<aside> 🧭
선택 기준: 제한된 개발 기간에 관리자와 학생의 서로 다른 모바일 흐름을 구현하고, 일정과 출석 상태가 여러 기기에서 빠르게 반영되며, 화면 변경에도 데이터 로직을 수정하기 쉬운지를 기준으로 선택했습니다.
</aside>
| 기술·구조 | 선택한 이유 | 실제 적용과 트레이드오프 |
|---|---|---|
| Flutter · Dart | 관리자·학생 모바일 화면을 하나의 코드베이스로 만들고 Figma 수정 사항을 빠르게 반영하기 위해 선택 | QR 카메라와 알림은 OS 권한·생명주기 차이를 별도로 확인해야 함 |
| Cloud Firestore | 일정, 사용자와 출석 현황을 문서 구조로 저장하고 관리자 화면에서 참여 상태를 실시간으로 갱신하기 위해 선택 | 클라이언트 화면 숨김만으로 권한을 보장할 수 없어 관리자 역할·출석 가능 시간·소유권을 Security Rules에서도 검증해야 함 |
| Provider · Flutter Hooks | 사용자 역할, 일정 카드, 출석 상태와 앱 설정을 Widget의 지역 상태에서 분리하면서 중간 규모 앱의 구조를 단순하게 유지하기 위해 선택 | 기능이 커지면 상태 범위가 넓어질 수 있어 ViewModel 책임을 기능 단위로 제한 |
| QR Scanner · QR 생성 | 학생이 명단을 검색하거나 관리자가 수기로 확인하는 단계를 줄이고 현장에서 빠르게 출석시키기 위해 선택 | QR 문자열만 신뢰하지 않고 일정 ID, 학생 ID, 유효 시간과 중복 출석을 함께 확인해야 함 |
| MVVM | 화면 표시, 상태 전환, Firebase 접근을 분리해 관리자·학생 기능이 늘어도 수정 범위를 줄이기 위해 적용 | 초기 파일 수와 구조 설계 비용은 늘지만 View 재사용과 테스트 가능성이 높아짐 |
| Local Notifications · AlarmManager | 별도 Push 서버 없이 기기에서 일정 알림과 예약 작업을 제공하기 위해 선택 | Android 절전 정책과 OS 버전에 따라 정확한 실행 시점이 달라질 수 있어 권한 안내와 재예약 정책이 필요 |
| Secure Storage | 사용자 식별 정보와 토큰처럼 일반 설정값보다 보호가 필요한 최소 정보를 기기 보안 저장소에 분리하기 위해 선택 | 대용량 출석 기록은 저장하지 않고 Firestore를 원본 데이터로 유지 |
| 관리자·학생 역할 분리 | 공통 일정 모델과 UI 자산은 재사용하되 역할별 핵심 행동과 정보량을 다르게 제공하기 위해 선택 | 화면 분리는 UX 결정이며 실제 권한 보장은 데이터 접근 단계에서 다시 수행해야 함 |
| 버전 | 핵심 기능 | 대표 흐름 |
|---|---|---|
| 🧑💼 관리자 | 일정 등록, 일정별 QR 표시, 현재 참여 학생, 승인 목록, 출석 기록, 추첨 | 일정 생성 → QR 제시 → 출석 현황 확인 → 승인·기록 관리 |
| 🎓 학생 | 일정 확인, QR 스캔, 출석 결과 확인, 개인 기록 조회 | 일정 확인 → QR 스캔 → 출석 완료 → 참여 기록 확인 |
<aside> 🔐
두 사용자는 같은 데이터 구조를 사용하지만, 역할에 따라 진입 화면과 접근 가능한 기능을 분리했습니다.
</aside>
| 구성원 | 당시 회의 카드에 기록된 담당 |
|---|---|
| 김형은 | 프론트엔드 · 백엔드 · 디자인 |
| 박상현 | 백엔드 |
| 민지희 | 디자인 |
| 박찬우 | 데이터 |
| 김해성 | 팀 명단에는 있으나 첫 회의 카드에는 담당 미기재 |