1. 발자국 — 조별과제 과정기록 & 평가지원 서비스
1.1 정의 및 사용자
| 항목 | 내용 |
|---|---|
| 정의 | 조별과제의 산출물과 완료확인을 과정 기록으로 남기고, 그 근거를 보면서 사람이 동료평가를 입력하는 웹 서비스 |
| 단위 | 과제 하나에 조 여러 개. 교수는 과제를 한 번 만들고 조마다 조장을 지정 |
| 사용자 | 조별과제를 수행하는 학생(조장·조원), 과제를 평가하는 교수 |
| 역할 | 교수(과제 생성·조장 지정·열람), 조장(역할 관리), 조원(기록·평가) |
| 사용 환경 | PC 웹 |
| 스택 | React / Spring Boot 3 / JPA / Spring Security(JWT) / PostgreSQL |
| 인증 | 학교 이메일(g.yju.ac.kr) 인증 |
| 성격 | 팀 프로젝트. 학교 공식 시스템(LMS)이 아니며 학교 명의를 쓰지 않음 |
| 범위 밖 | LMS 연동, 성적 산출. 시스템은 점수를 계산하지 않음 |
1.2 문제
| 구분 | 내용 |
|---|---|
| 현행 | 동료평가는 서면 또는 구글 폼(본교 LMS에 동료평가 기능 없음). 과정 관리는 노션·드라이브·카톡 조합 |
| 한계 1 | 평가 시점에 "누가 무엇을 언제 했는지" 볼 근거가 없음. 기억과 인상으로 점수를 매김 |
| 한계 2 | 친분·발언권에 따라 평가가 좌우됨 |
| 한계 3 | 파일이 남지 않는 기여(회의 진행, 자료 취합, 일정 조율)는 어디에도 기록되지 않음 |
| 한계 4 | 과정 관리 도구와 평가 도구가 분리되어 있어 근거와 평가가 연결되지 않음 |
원칙: 판단은 사람, 시스템은 근거만. 점수 자동 계산·순위·가중치 없음.
근거: 조원 4명에게 조별과제 평가 경험을 물은 결과, 3명이 "파일로 남지 않는 기여가 평가에 반영되지 않는다", 1명이 "친분과 발언권에 따라 평가가 달라진다"를 문제로 들었다.
1.3 기존 서비스 비교
| 서비스 | 구조 | 구조상 불가한 것 |
|---|---|---|
| 서면 / 구글 폼 | 과제 종료 후 점수 입력 | 과정 기록 없음. 평가 시점에 근거를 볼 수 없음 |
| 노션 · 드라이브 · 카톡 조합 | 각자 도구에 흩어진 기록 | 역할·담당·완료 여부가 구조화되지 않음. 평가와 연결 안 됨 |
| 타교 LMS 동료평가(Canvas·Moodle 등) | 제출물에 대한 상호 평가·점수 입력 | 과정 기록(누가 언제 무엇을 했는지) 없음. 파일로 남지 않는 기여 반영 불가 |
차별점: 산출물·완료확인 기록과 동료평가가 한 화면에 연결. 과정 기록과 동료평가를 함께 다루는 도구는 확인한 범위에서 없음.
1.4 기능
| 번호 | 기능 | 설명 | 비고 |
|---|---|---|---|
| 1.4.1 | 과제 생성 | 교수가 과제명·기간을 등록하고, 조 개수만큼 조장을 지정 | 생성 주체는 교수. 조는 과제 아래 여러 개 |
| 1.4.2 | 역할 배정 | 초대 링크로 조원 합류, 조장이 역할명 배정 | |
| 1.4.3 | 기여 항목 등록 | 파일이 없는 기여(회의 진행, 자료 취합, 일정 조율)를 조장이 항목으로 등록, 담당자 지정 | |
| 1.4.4 | 산출물 업로드·열람 | 파일 업로드. 같은 역할의 파일은 버전 순으로 쌓이고 최신 버전이 상단에 표시. 조원·교수가 열람·다운로드 | 시각은 서버 기록. 조회·다운로드 여부는 집계하지 않음. 파일당 용량·형식 제한은 구현 시 설정 |
| 1.4.5 | 완료확인 | 담당자 보고 → 다른 조원이 확인. 산출물·기여 항목 모두 대상. 확인자 여러 명 가능 | 혼자 소급 입력 불가 |
| 1.4.6 | 진척 시각화 | 역할별로 언제·몇 번 올렸는지 타임라인 표시. 업로드 시점이 그대로 기록됨 | 고정 문구: "업로드 횟수는 기여도가 아닙니다 · 점수는 시스템이 계산하지 않습니다" |
| 1.4.7 | 근거 패널 | 산출물 / 완료확인을 종류별로 분리 표시. 평가 화면 옆에 고정 | |
| 1.4.8 | 동료평가 | 항목 2개(역할 수행 / 팀 소통), 각 5점 척도. 근거 패널 보며 사람이 입력. 개별 입력, 조원 간 비공개 | 파일로 남지 않는 기여는 팀 소통에서 반영 |
| 1.4.9 | 교수 열람 | 근거 기록과 평가 결과 열람. 집계·합산 없음 | 평가 결과는 교수만 |
※ 용어 — 산출물: 조원이 역할 수행의 결과로 올린 파일. 업로드 시각·담당자·역할과 함께 저장 · 완료확인: 담당자가 완료를 보고하고 다른 조원이 확인하는 절차 · 근거 패널: 동료평가 화면 옆에 붙는 산출물·완료확인 기록 목록
1.5 화면
| 번호 | 화면 | 진입 | 구성 | 관련 기능 |
|---|---|---|---|---|
| 1.5.1 | 과제 목록 | 로그인 후 | 참여 중 과제, 역할, 기간 | 1.4.1 |
| 1.5.2 | 과제 생성 | 교수 | 과제명, 기간, 조 목록과 조장 지정 | 1.4.1 |
| 1.5.3 | 역할 배정 | 조장 | 조원 목록, 역할명, 초대 링크 | 1.4.2 |
| 1.5.4 | 기록 | 과제 상세 | 산출물 업로드, 기여 항목 등록, 내 담당 목록 | 1.4.3, 1.4.4 |
| 1.5.5 | 산출물 보기 | 과제 상세 | 역할별 파일 목록(버전 순, 최신 상단), 파일 정보, 다운로드 | 1.4.4 |
| 1.5.6 | 진척 보드 | 과제 상세 | 역할별 타임라인, 고정 문구 | 1.4.6 |
| 1.5.7 | 완료확인 | 알림 또는 진척 보드 | 확인 대기 항목, 확인 버튼 | 1.4.5 |
| 1.5.8 | 동료평가 | 과제 종료 후 | 왼쪽 근거 패널, 오른쪽 평가 입력(조원별 2항목) | 1.4.7, 1.4.8 |
| 1.5.9 | 교수 열람 | 교수 | 과제 아래 조 목록 → 조별 근거 기록, 평가 결과 | 1.4.9 |
1.6 시스템 구조
| 구분 | 구성 요소 | 담당 |
|---|---|---|
| 화면군 | 조장·조원(역할·기록·진척·완료확인·평가) / 교수(과제 생성·열람) | React |
| 도메인 | 과제·역할 / 산출물·기여 / 완료확인·평가 / 리포트(열람용, 집계 없음) | Spring Boot 3 |
| 저장 | PostgreSQL, 오브젝트 스토리지(S3 호환) — 산출물 파일 | 서버와 분리 저장 |
| 외부 의존 | 오브젝트 스토리지, SMTP(초대·알림 메일) |
호출 관계: 화면군 → 도메인(REST). 권한 검사는 조 단위 소속 기준(1.8 참조).
엔티티
| 엔티티 | 역할 | 주요 속성 |
|---|---|---|
| 회원 | 학생·교수 | 이메일, 이름, 구분 |
| 과제 | 수업 단위 | 과제명, 기간, 교수, 상태 |
| 조 | 과제 아래 팀 | 과제, 조장 |
| 조 참여 | 회원-조 관계 | 역할명 |
| 기여 항목 | 파일 없는 기여 | 항목명, 담당자, 등록자 |
| 산출물 | 업로드 파일 | 파일, 파일명, 시각, 담당자, 역할, 버전 |
| 완료확인 | 산출물·기여 항목에 대한 확인 | 대상, 확인자, 시각 |
| 평가 | 조원 → 조원 | 평가자, 대상, 역할 수행, 팀 소통 |
1.7 범위
| 구분 | 내용 |
|---|---|
| 1차 핵심 | 1.4.1 과제 생성 · 1.4.2 역할 배정 · 1.4.4 산출물 · 1.4.5 완료확인 · 1.4.7 근거 패널 · 1.4.8 동료평가 · 1.4.9 교수 열람 — 이것만 있어도 서비스 성립 |
| 1차 부가 | 1.4.3 기여 항목 · 1.4.6 진척 시각화 — 핵심 완성 후 |
| 구현 순서 | ① 인증·과제·역할 → ② 산출물 업로드·열람 → ③ 완료확인·기여 항목 → ④ 근거 패널·동료평가·교수 열람 → ⑤ 진척 시각화 |
| 기능 확장 | 1차 완성 후 검토 |
1.8 기술적 핵심 과제 — 조 단위 권한
| 항목 | 내용 |
|---|---|
| 과제 | 교수·조장·조원이 같은 화면에서 보는 것과 할 수 있는 것이 다르며, 그 구분이 조 단위로 달라짐. 같은 과제라도 다른 조의 기록은 볼 수 없음 |
| 왜 어려운가 | URL 단위 권한(로그인 여부, 역할)으로는 "이 조의 조원인가"를 판단할 수 없음. 리소스 단위 검사가 필요함 |
| 배워야 할 것 | Spring Security 메서드 단위 인가(@PreAuthorize), 조-사용자 소속 검사 로직 |
| 그 외 학습 필요 | 파일 업로드와 오브젝트 스토리지 연동, 버전 관리 |
1.9 리스크와 대응
| 번호 | 리스크 | 대응 |
|---|---|---|
| 1 | 사후 일괄 입력 — 평가 직전에 몰아서 올리면 과정 기록의 의미가 사라짐 | 기록 시각은 서버가 기록하므로 소급 불가. 완료확인은 다른 조원이 확인해야 하므로 혼자 채울 수 없음 |
| 2 | 보이는 기여 편향 — 파일이 남는 일이 유리해 보임 | 평가 항목을 역할 수행 / 팀 소통으로 분리. 진척 화면에 고정 문구 "업로드 횟수는 기여도가 아닙니다" |
1.10 예상 질문
Q1. 지금은 조별과제 평가를 어떻게 하고 있고, 무엇이 문제입니까?
서면이나 구글 폼으로 과제가 끝난 뒤 점수를 적습니다. 그 시점에는 누가 무엇을 했는지 볼 근거가 없으므로 기억과 인상에 의존하게 됩니다. 저희는 과정 기록을 남겨 평가할 때 참고하게 하려는 것입니다.
Q2. 점수를 시스템이 계산하지 않으면 무엇을 해주는 겁니까?
근거를 정리해서 보여주는 것까지만 합니다. 산출물 기록과 완료확인 기록을 평가 화면 옆에 붙여 두고, 점수는 사람이 입력합니다. 계산을 시스템이 하면 기록 횟수가 곧 점수가 되기 때문에 의도적으로 제외했습니다.
Q3. 파일을 많이 올리는 사람이 유리한 것 아닙니까?
평가 항목을 "역할 수행"과 "팀 소통" 둘로 나눴습니다. 회의 진행이나 자료 취합처럼 파일로 남지 않는 기여는 기여 항목으로 따로 등록하고 조원이 완료확인을 합니다. 진척 화면에는 "업로드 횟수는 기여도가 아닙니다"라는 문구를 고정으로 표시합니다.
Q4. 평가 직전에 몰아서 올리면 의미가 없지 않습니까?
기록 시각은 서버가 기록하기 때문에 과거로 돌릴 수 없습니다. 완료확인은 다른 조원이 확인해야 하므로 혼자 한꺼번에 채울 수 없습니다. 올린 시점이 그대로 남습니다.
Q5. 조원끼리 서로 준 점수를 볼 수 있습니까?
아니요. 평가 결과는 교수만 봅니다. 산출물과 완료확인 같은 근거 기록은 조원도 함께 봅니다.
Q6. 평가 데이터와 파일은 과제가 끝난 뒤 어떻게 됩니까?
과제 종료 후 일정 기간 보관하고 삭제합니다. 보관 기간은 교수님과 협의해 정하고, 교수님 요청이 있으면 즉시 삭제합니다. 파일과 평가 결과는 해당 과제의 조원과 담당 교수 외에는 접근할 수 없습니다.