TWO CHAPTERS
20242026
Team demo댓글 알림 → REST → Client
Return & verifyQuery guard → Stock invariant
01
왜 시작됐는가
교내에서 쓰지 않는 물건을 빌리고 돌려주는 흐름을 짧은 해커톤 안에 제품으로 연결했습니다.
02
누구와 어떤 상황에서 만들었는가
- Setting
- 2024 GGUM 해커톤 · 11인 팀
- Audience
- 가톨릭대학교 이메일을 사용하는 교내 구성원
- Role
- 댓글 기반 알림과 REST 전환, 이후 개인 품질 보강
03
내가 맡은 범위
- 댓글이 달리면 소유자에게 알림을 남기는 entity·repository·controller 흐름을 구현했습니다.
- 서버 화면 중심 controller를 REST API로 바꾸고 프론트엔드와 연결해 팀 시연에 포함했습니다.
- 2026년에는 현재 코드를 다시 검토해 상품 목록 query-count와 동시 예약 재고 불변식을 회귀 테스트로 고정했습니다.
04
실제 사용자 흐름
- 01
사용자가 대여 물품에 댓글을 남깁니다.
- 02
서버가 물품 소유자의 알림 목록에 새 댓글 알림을 기록합니다.
- 03
프론트엔드가 REST API로 알림을 불러와 소유자가 댓글로 돌아가게 합니다.
- 2024년 댓글 알림과 REST endpoint를 팀 클라이언트에 연결했습니다.
- 2026년 개인적으로 같은 저장소를 다시 검토했습니다.
- 현재 조회 SQL 상한과 재고 불변식을 회귀 테스트로 남겼습니다.
05
전환점과 발견한 문제
팀 시연을 끝낸 코드는 시간이 지나면 설명보다 회귀 방지 장치가 더 중요해진다는 점을 확인했습니다.
2024 · Team build
알림이 실제 제품 흐름에 들어가게 만들기
댓글 알림을 구현하고 프론트엔드가 호출할 REST 경계로 전환해 팀 시연까지 연결했습니다.
2026 · Return
과거 코드를 현재 기준으로 다시 보기
과거 성능 숫자를 반복하는 대신 현재 저장소에서 재현되는 SQL 상한과 재고 불변식만 남겼습니다.
06
현재 결과
현재 저장소는 과거 팀 제품을 운영 서비스로 주장하지 않고, 다시 검증 가능한 Spring 프로젝트로 유지합니다.
- 팀 개발과 이후 개인 보강의 기여 시점을 분리했습니다.
- 상품 수가 늘어도 조회 SQL 상한이 깨지지 않도록 테스트했습니다.
- 동시 예약에서도 성공 수와 남은 재고의 합이 초기 재고와 일치하도록 검증했습니다.
Engineering cases
한 번에 한 경계만 깊게
07
공개 근거
08
말하지 않는 것
- 당시 프론트엔드와 시연은 사용자 확인 사실이며 현재 공개 클라이언트는 없습니다.
- 공개 회귀 검증은 로컬 실행 범위이며 출처가 불완전한 과거 비교 수치는 사용하지 않습니다.
JavaSpring BootMySQLJPATestcontainers