[ECC 2026 Summer Project] SplitOpt - Week 7
기간: 2026. 08. 24 – 08. 30 (7주차)
내용: 최종 발표, 프로젝트 마무리
파트: 백엔드
8월 28일에 최종 발표를 했다. 새로 추가한 기능은 없고, 6주 동안 만든 것을 정리해 발표 자료로 옮기는 작업이 대부분이었다.
1. 발표 구성
초안에는 작업한 내용을 순서대로 넣었다. 동시성 처리, 락, 마이그레이션, 시간대, 테스트 개수 순이다. 이 구성에서는 서비스가 왜 필요한지가 드러나지 않아, 문제 → 해법 → 알고리즘 → 설계·구현 → 결과 순으로 다시 배치하고 앞의 두 장에서는 구현 얘기를 뺐다.
문제 정의는 세 가지로 정리했다.
- 번갈아 결제하면 결제자와 부담자가 어긋나 개인이 추적할 수 없다
- 인원이 N명이면 주고받을 수 있는 관계가 최대 N(N−1)/2건이다. 6명이면 15건이다
- 누가 아직 보내지 않았는지 확인할 공용 기록이 없어 독촉이 반복된다
해법은 4인 모임 기준 송금 6건이 3건으로 줄어든다는 수치로 요약했다. 사용자가 최종적으로 보는 결과는 “D가 A에게 40,000원” 형태의 실행 가능한 문장이다.
2. 알고리즘 설명
내 파트 발표는 정산 최적화였다. 코드 흐름을 그대로 설명하면 길어져, 세 단계로 정리했다.
- 잔액이 양수면 채권자 큐, 음수면 절댓값으로 채무자 큐에 넣는다. 두 큐 모두 금액이 큰 순으로 정렬한다
- 양쪽 최댓값을 꺼내 작은 금액만큼 상쇄한다. 매 단계에서 최소 한 명의 잔액이 0이 되어 큐에서 빠진다
- 남은 금액은 다시 큐에 넣고 반복한다
2번이 핵심이라, 참여자가 N명이면 송금은 최대 N−1건을 넘지 않는다.
그리디가 항상 이론적 최소해를 주지는 않는다는 점은 발표에서 그대로 밝혔다. 실제 모임 규모에서 충분한 결과가 나오고, 총합이 0이며 각자의 잔액이 정확히 해소된다는 정확성은 보장된다. 이 부분은 테스트로 검증한 내용이다.
3. 발표
데모는 배포된 화면으로 진행했다. 프론트엔드에서 지출을 몇 건 등록하고 최적화를 실행해 송금 건수가 줄어드는 과정을 보였다.
트러블슈팅 장은 “기능이 동작하지 않는 버그가 아니라 값이 조용히 틀리는 문제”를 축으로 잡고 다섯 건을 증상–원인–조치로 정리했다.
4. 최종 결과
| 항목 | 결과 |
|---|---|
| 구현 API | 40개 (명세 전체) |
| 자동화 테스트 | 287개 / 29개 클래스 |
| main 실패 테스트 | 0개 |
| 배포 | 프론트 Netlify, 서버 Render(Docker), DB Railway MySQL 8 |
| CI | GitHub Actions, PR마다 ./gradlew test |
내 파트인 정산 최적화·상태 관리(23~29)와 예산(38~40)은 전부 구현했고, 진행 중 다른 파트에서 확인한 문제도 함께 고쳤다.
품질 장치로 남긴 것은 네 가지다.
- Testcontainers로 실제 MySQL에 Flyway를 적용해 제약이 잘못된 INSERT를 거부하는지 확인
- 엔티티와 운영 스키마가 어긋나면 실패하는 스키마 드리프트 테스트
- main으로 향하는 모든 push·PR에서 테스트 실행
- CodeRabbit 자동 리뷰와 브랜치·커밋·PR 컨벤션 통일
5. 남은 작업
발표 자료 마지막 장에 다음 단계로 정리한 항목이다.
- 범위 밖으로 미룬 정산 관계 그래프 시각화, 정산 리마인드, 신뢰도 지표
- 알림 기능 — 현재는 상태를 조회해야만 확인할 수 있다
- 성능 측정 — N+1은 몇 군데 제거했지만 실제 부하를 측정한 적은 없다
마지막 항목이 가장 큰 공백이다. 쿼리 개수가 줄어든 것은 확인했지만 응답 시간을 재고 고친 것은 아니다.
6주 동안 쓴 커밋과 PR을 비교하면 초반에는 무엇을 만들었는지만 적혀 있고, 후반에는 왜 그렇게 했고 다른 방법은 왜 아닌지가 함께 적혀 있다.
프로젝트 전체 회고는 따로 정리했다.