1. Graduation Coach 프로젝트 소개
1학기 때 진행했던 팀 프로젝트 “Graduation Coach”는
학생과 학사팀을 위한 졸업요건 관리 웹서비스다.
-
학생
- 현재까지 이수한 과목/학점
- 전공/교양/인증별 충족 여부
- 앞으로 필요한 졸업요건을 한 화면에서 확인
-
학사팀
- 학부·전공·입학년도별 졸업 규정을 등록/수정
- 외국어/정보 인증 등 비과목 요소까지 함께 관리
프로젝트 환경은 다음과 같았다.
- Backend : Spring Boot, Java, JPA, MySQL
- Frontend : Thymeleaf, HTML/CSS/JS, Bootstrap
- 협업/환경 : GitHub, Gradle, Docker(개발환경)
팀은 총 7명이었고, 프로젝트 PPT 기준 내 역할은 이렇게 정의되어 있다.
포지션: BE
R&R: MVP 백엔드 개발
백엔드는 두 명이 나눠 진행했고,
나는 로그인·회원가입 같은 인증 플로우와 외국어/정보 인증 관리,
그리고 학사 대시보드와 연결되는 부분을 중심으로
서비스가 실제로 동작하는 MVP 백엔드를 구현했다.
이 글은 전체 프로젝트가 아니라, 그 중에서도 내가 맡았던 백엔드 구현 파트를 중심으로 정리한 기록이다.
GitHub 저장소
- Graduation Coach 팀 프로젝트 레포지토리: https://github.com/Lova-clover/Graduation-Coach
2. 내가 담당한 핵심 기능
2-1. Spring Security 기반 로그인·회원가입 플로우
가장 먼저 했던 일은 이 서비스에 “진짜 로그인/로그아웃/회원가입”을 붙이는 것이었다.
Security 설정
-
spring-boot-starter-security추가 -
SecurityConfig에서/welcome,/login,/signup, 정적 리소스(css/**)는permitAll()- 그 외 URL은 인증 필요
- 로그인 성공 시 학생/학사 대시보드로 이동
- 로그아웃 시 웰컴 페이지로 이동
- 비밀번호 암호화를 위해
BCryptPasswordEncoderBean 등록
이전까지는 단순 HTML 폼 수준이었던 로그인 페이지가,
이 설정을 기점으로 “계정–세션–권한이 실제로 도는 구조”로 바뀌었다.
회원가입 API & 서비스 로직
-
APIController의/signupPOST 핸들러 구현- 비밀번호 / 비밀번호 확인 검증
- 실패 시 에러 메시지와 함께 회원가입 페이지로 리턴
- 성공 시
UserDTO를 만들어UserService.register()호출
-
UserDTO / UserRepository / UserService수정-
existsByUserId()로 아이디 중복 체크 -
UserService.register()에서- 비밀번호를 BCrypt로 암호화하여
UserEntity저장 UserType(학생/학사)에 따라 분기- 학생인 경우, 학번·전공·입학년도 정보와 연결되는
StudentEntity까지 함께 생성
- 비밀번호를 BCrypt로 암호화하여
-
UserService가UserDetailsService를 구현하도록 변경- 로그인 시
loadUserByUsername()에서 DB 유저 정보를 로드
- 로그인 시
-
결과적으로,
“회원가입 → 로그인 → 세션/권한 부여 → 대시보드 진입”까지 이어지는 인증 플로우
를 처음부터 끝까지 구현했다.
2-2. 학교 입력을 ID 기반 select box로 정리
초기 회원가입 화면에서 학교 입력은 단순 텍스트 입력이었다.
"연세대학교", "연대", "Yonsei" ...이렇게 들어가면, 나중에 통계나 필터링, 조인할 때 전부 문제가 된다.
그래서 다음과 같이 수정했다.
input type="text" name="university"
→<select name="univ">(value는 숫자 ID)- 화면에는 학교 이름이 보이지만,
서버로 넘어가는 값은 고유번호(ID) 만 전달
이 작업을 통해
- 화면 레벨: 유저는 학교 이름으로 선택
- 백엔드 레벨: 항상 ID 기준으로 학교를 식별
하는 구조를 만들었다.
이 경험 이후로, 전공/학과/과목/인증 같은 도메인도
항상 “보이는 이름 vs 내부 ID를 분리해서 설계”하는 습관이 잡혔다.
2-3. 외국어/정보 인증(Communication / Foreign Cert) 관리 기능
졸업요건에는 과목 외에도 외국어/정보 인증 같은 요소가 포함된다.
- 예: 토익, 텝스, 자체 시험, 컴활, MOS 등
학사팀이 이 인증들을 전공·입학년도별로 등록하고, 필요 시 삭제할 수 있는 기능을 맡아서 구현했다.
Repository / Service 계층
-
ForeignCertRepository,CommunicationCertRepository- 학부/입학년도 조건으로 인증 리스트 조회
- 선택된 UID 리스트를 받아 일괄 삭제하는 메서드 추가
-
ForeignCertService,CommunicationCertService- DTO → 엔티티 변환 및 저장
- 체크박스로 넘어온 UID 리스트를 기준으로 인증 일괄 삭제
이를 통해 학사팀은:
- 전공·입학년도 선택 → 해당 조건의 인증 리스트 조회
- 체크 후 삭제 → 해당 인증이 실제로 DB에서 제거
라는 흐름으로 인증을 관리할 수 있게 됐다.
학사 대시보드 연동
-
학사팀 대시보드 컨트롤러에서
- 학부/전공/입학년도를 선택하면
- 그 조건에 맞는 외국어/정보 인증 리스트를 모델에 담아 화면으로 전달
-
추가/삭제 요청 처리
- 추가: DTO 생성 → Service에서 저장 → 성공/실패 메시지 처리
- 삭제: 선택된 UID 리스트를 Service로 전달 → 일괄 삭제
즉,
“학사팀이 졸업요건 중 인증 항목을 직접 관리할 수 있는 전체 백엔드 플로우”를
Repository → Service → Controller → View까지 연결한 파트였다.
에러 디버깅
초기에는 Repository 메서드를 deleteAllByIdIn(...)으로 작성했는데,
실제 PK 필드 이름이 uid라 런타임 에러가 발생했다.
이를 deleteAllByUidIn(...)으로 수정하고,
Service/Controller 호출부까지 전부 맞추면서
화면 → Controller → Service → Repository → DB
까지의 흐름을 서비스 수준으로 안정화했다.
3. 이 프로젝트에서 내가 얻은 것
이전까지 GitHub는 나에게 그냥
“사람들이 거기에 코드 올리는 곳”
정도의 이미지였다.
이 프로젝트를 하면서 처음으로:
- 팀 레포를 기준으로 기능 단위 커밋을 만들고
- “이 커밋은 회원가입 플로우”, “이 커밋은 인증 CRUD”처럼
기능 단위로 기록을 남기는 습관을 들이기 시작했다.
Spring도 마찬가지였다.
- Security를 직접 붙여 보면서
“폼 → 필터 → UserDetailsService → 세션/권한” 흐름을 처음부터 따라갔고 - DTO / Service / Repository 구조를
실제 코드에서 나눠보면서 레이어드 아키텍처 감각을 잡기 시작했다.
이 프로젝트 하나만으로 내 백엔드 역량이 전부 설명되지는 않지만,
백엔드와 GitHub 협업을 제대로 시작한 첫 팀 프로젝트였다는 사실은 분명하다.
4. 첫 백엔드 팀프로젝트로서의 의미
Graduation Coach는 내가 처음으로 끝까지 맡아본 백엔드 팀프로젝트였다.
이 프로젝트에서 처음으로
- 로그인/회원가입/권한까지 이어지는 인증 플로우를 내가 책임지고 붙여 보고
- 학교·졸업요건·인증 같은 데이터를 문자열이 아니라 ID 기반 도메인으로 설계해 보고
- 학사·졸업요건이라는 실제 요구사항을 기준으로 API와 화면 흐름을 맞춰 보는 경험을 했다.
프로젝트 자체는 거대한 서비스는 아니었지만,
“유저가 로그인하고, 권한에 따라 다른 데이터를 보고 조작하는 서비스의 백엔드”를 처음부터 끝까지 직접 만들어 본 경험이라는 게 중요했다.
이때 쌓은 경험이 이후 프로젝트(Spring 기반 사이드 프로젝트와 AI 서비스들)의 기본 골격을 잡는 데 기준점이 될 것이다.
