산학연계 SW프로젝트 · SW중심대학사업단 · 마이크로스톤
수기·메신저 출석의 대리 출석 문제를 없애기 위해, BLE 비콘 근접 감지와 현장에서만 알 수 있는 4자리 비밀번호를 동시에 요구합니다. 출석 인정 여부·지각 판정·미출석자 일괄 처리는 전부 서버가 결정합니다.
제가 속한 개발 동아리 마모키에서, 동아리원들이 실제로 쓰려고 만든 출석체크 앱입니다. 매주 모임마다 운영진이 이름을 부르고 수기로 적던 출석을 앱이 대신하게 하는 것이 목표였습니다.
사용자가 곧 제 팀원들이다 보니 “대리 출석을 어떻게 막을 것인가”가 바로 현실적인 문제로 돌아왔습니다. 비콘만 쓰면 복도에서도 출석이 되고 비밀번호만 쓰면 원격으로 전달받아 찍을 수 있어서, 결국 두 조건을 모두 요구하는 구조로 갔습니다. 쓰는 사람이 가까이 있으니 문제 제보가 그날 바로 들어왔고, 그 피드백을 반영해 고치는 주기가 가장 짧았던 프로젝트입니다.
출석은 “어느 동아리의, 어느 세션의” 출석인지가 항상 함께 필요하므로 경로에 소속 관계를 그대로 담았습니다. 실시간 피드만 별도 스트림 경로로 분리했습니다.
| 경로 | 접근 주체 | 역할 |
|---|---|---|
| /api/v1/auth/login | POST | 학번·비밀번호 인증 → access · refresh 토큰 발급 |
| /api/v1/clubs/{clubId}/sessions/{sessionId}/attendance | POST · GET | 출석 제출 및 조회 — 서버 4단계 검증 |
| /api/v1/clubs/{clubId}/attendance | GET (SSE) | 진행 중 세션의 실시간 출석 이벤트 스트림 |
응답은 RsData<T> 공통 래퍼로 통일하고, springdoc이 코드에서 통신 규격 문서를 자동 생성합니다. 웹 대시보드는 그 문서로부터 타입을 생성하므로, 서버와 클라이언트의 규약이 어긋나면 빌드 단계에서 바로 드러납니다.
통신 지연으로 같은 멤버의 출석 요청이 시차를 두고 두 번 도달하면, 서비스 코드의 “이미 출석했는지” 검사만으로는 두 요청이 검사 구간을 나란히 통과해 출석 기록이 두 건 생성될 수 있었습니다.
검사와 기록 사이의 시간 간격이 아무리 짧아도 중복 기록이 남지 않게 됐습니다.
처음에는 로그인 요청 본문에 fcmToken을 실어 저장했습니다. 그런데 FCM 토큰은 앱 재설치·기기 변경·만료로 로그인과 무관한 시점에 바뀝니다. 그때마다 재로그인을 해야만 갱신되는 구조였습니다.
fcmToken을 제거하고, 토큰 갱신 전용 API를 만들어 앱이 변경을 감지한 시점에 바로 호출하도록 변경기기를 바꿔도 재로그인 없이 알림이 정상 수신되고, 로그인 API의 책임도 인증 하나로 정리됐습니다.
4자리 인증코드가 세션 내내 유효하면, 참석하지 않은 사람에게 코드를 전달해 대리 출석하는 것을 막을 수 없습니다. 지각 여부를 관리자가 눈으로 판단하는 것도 기록마다 기준이 달라집니다.
“그 장소에 있었을 것”과 “그 시각에 현장에서 안내를 받았을 것”을 동시에 요구하는 구조가 되어, 위치나 비밀번호 한쪽만 확보한 우회 경로가 사라졌습니다.
v* 태그로 둔 이유는, 개발 중 변경이 그대로 운영에 나가지 않게 하고 어떤 이미지가 배포됐는지를 태그로 되짚기 위해서입니다.temurin:21-jdk-alpine)와 실행 단계(21-jre-alpine)로 나누고, 의존성 다운로드를 소스 복사보다 먼저 두어 레이어 캐시가 유지되도록 구성.env로만 주입하고 저장소에는 남기지 않음docker compose up 한 줄로 DB까지 함께 뜨도록 구성해, 팀원이 OS와 무관하게 같은 환경에서 실행
앱은 Flutter, 웹 대시보드는 React로 팀원들이 구현했습니다. 저는 이 화면들이 호출하는 출석 검증·지각 판정·통계 집계·푸시 발송 API를 담당했습니다.