백엔드 프로젝트의 성패를 기능 개수로 판단하기 어렵습니다. 예약 API 같은 작은 주제에서도 데이터 무결성, 동시 요청, 권한과 오류 응답을 다루면 설계 선택을 설명할 수 있습니다.
규칙 정하기
예약 가능 시간과 취소 조건, 누가 조회·수정할 수 있는지를 먼저 적습니다. 이 규칙이 없으면 API와 데이터베이스에서 서로 다른 판단이 생길 수 있습니다.
데이터와 동시성
중복 예약을 막는 제약을 데이터 모델과 요청 처리에서 함께 검토합니다. 두 요청이 거의 동시에 들어오는 테스트를 만들어 예상 결과와 실제 결과가 일치하는지 확인하세요.
검증 자료
성공·실패 요청 예시, 테스트 결과, 남은 한계를 README에 남깁니다. 트래픽 수치를 측정하지 않았다면 성능 개선 효과를 만들어내지 말고 측정 조건을 설계하세요.
관련 기술의 공식 설명은 Spring 공식 가이드에서 확인하세요. 관련 주제: 신입 백엔드 프로젝트 7가지보다 중요한 설계·테스트 기준.
자주 묻는 질문
복잡한 서비스를 만들어야 하나요?
작은 범위라도 규칙·테스트·오류 처리까지 완성하면 본인의 설계 판단을 더 분명히 보여줄 수 있습니다.