수강신청 API

개요

이 프로젝트는 학회 스터디 자람 허브의 최종 과제로 진행했다. 단순 CRUD 구현보다도, 명확한 제약조건을 가진 도메인을 어떻게 API로 설계할 것인지를 직접 고민해 보는 게 핵심이었다.

저장소

https://github.com/bnbong/JaramUniv_Sugang-API

과제의 핵심 요구사항

원래 과제는 회원, 과목, 수강신청이라는 세 도메인을 다루면서도 몇 가지 까다로운 제약을 함께 줬다.

• 교수는 수강신청을 할 수 없다.
• 과목 정원이 차면 신청할 수 없다.
• 과목 폐강 시 수강신청 기록을 삭제해야 하지만 CASCADE는 금지된다.
• request/response body, API path 구조를 스스로 설계하고 근거를 설명해야 한다.

이 프로젝트의 진짜 목표는 "기능을 많이 만드는 것"이 아니라 도메인 제약을 API 설계와 트랜잭션 처리로 풀어내는 것이었다.

왜 두 버전으로 만들었는가

이 프로젝트는 같은 기능을

• v1 : FastAPI
• v2 : Spring Boot

두 방식으로 구현하도록 설계했다. 이유는 당시 FastAPI를 먼저 익숙하게 사용하고 있었고, 스터디를 통해 배우던 Spring Boot로도 동일한 문제를 다른 프레임워크에서 어떻게 푸는지 비교해 보고 싶었기 때문이다.

프레임워크를 바꾸는 것이 목적이 아니라, 도메인 설계는 유지한 채 구현 방식만 바꿨을 때 무엇이 달라지는지 직접 체감하기 위한 프로젝트였다.

설계 포인트

도메인 모델링

수강신청 시스템은 간단해 보이지만, 실제로는

• 사용자 역할 분기
• 정원 제한
• 과목/수강신청 관계
• 폐강 시 데이터 정리

같은 제약이 동시에 걸린다. 그래서 단순 테이블 3개로 끝내지 않고, 각 연산이 어떤 불변조건을 지켜야 하는지를 먼저 정리한 뒤 API를 설계했다.

CASCADE 없이 폐강 처리

이 과제에서 가장 재미있었던 제약은 CASCADE 금지였다. 과목 삭제는 단일 SQL 한 번으로 끝나는 것이 아니라,

1. 해당 과목의 수강신청 레코드를 조회하고
2. 관련 레코드를 명시적으로 삭제한 뒤
3. 마지막에 과목을 삭제

하는 순서를 지켜야 했다. 이 제약 덕분에 "DB 기능을 쓰면 끝나는 문제"가 아니라, 애플리케이션 레이어에서 데이터 정합성을 어떻게 지킬 것인가를 고민하게 됐다.

버저닝

저장소 구조도 v1, v2로 나눠 관리했다. 이는 단순 정리가 아니라, 동일한 요구사항이더라도 구현 언어와 프레임워크에 따라 코드 조직과 운영 방식이 어떻게 달라지는지 명확하게 비교하려는 의도였다.

기술 스택

v1

• Python 3.10.10
• FastAPI
• MariaDB

v2

• Java OpenJDK 11
• Spring Boot 2.7.11
• MariaDB

공통 운영 환경

• Docker / Docker Compose
• Nginx
• Oracle Cloud Instance
• GitHub Actions, Jenkins

왜 이 프로젝트가 의미 있었는가

규모가 큰 서비스는 아니지만, 나에게는 API 설계 훈련으로서 의미가 컸다.

• 요구사항을 그대로 코드로 옮기지 않고, 도메인 불변조건으로 다시 해석하는 경험
• 같은 문제를 FastAPI와 Spring Boot라는 서로 다른 도구로 비교하는 경험
• 과제 수준에서도 문서화와 운영 환경까지 같이 생각하는 경험

특히 API path와 body를 "관습적으로" 정하지 않고 이유를 설명해야 했던 경험이, 이후 다른 백엔드 프로젝트를 설계할 때도 큰 도움이 됐다.

역할

• 도메인 모델 설계
• FastAPI / Spring Boot 기반 API 구현
• Docker 기반 실행 환경 구성
• 문서화 및 테스트 코드 작성

배운 점

• 백엔드 과제에서 가장 중요한 건 CRUD 수가 아니라 도메인 제약을 어떻게 보존할지다.
• 같은 문제를 두 프레임워크로 풀어 보면, 문법 차이보다 설계 자체가 얼마나 견고한지가 더 잘 드러난다.
• API 문서화는 구현 후 부가 작업이 아니라, 설계 검증 과정의 일부라는 점을 다시 확인했다.