[ECC 2026 Summer Project] SplitOpt - Week 1

Posted Jul 18, 2026

By Shin-SuBin

views 9 min read

기간: 2026. 07. 13 – 07. 19 (1주차)

내용: 주제 선정, 팀 규칙 확정, GitHub Organization 세팅, API 명세서 초안

파트: 백엔드

ECC 2026 여름 프로젝트가 시작됐다. 약 한 달 동안 하나의 서비스를 기획부터 구현까지 진행하고, 개인별로 주차별 진행상황을 기록한다. 1주차는 코드보다 “무엇을 어떻게 만들지”를 정하는 주였다. 첫 회의 안건은 다섯 가지였다.

프로젝트 주제
팀 미팅 요일
팀 명
GitHub Organization 및 Repository 생성
API 명세서

1. 프로젝트 주제

먼저 조건을 세웠다.

결제(비용)가 필요한 기능은 제외한다. (예: AI API 키처럼 매달 요금이 나가는 요소)
기능 범위가 명확해서 한 달 안에 완결할 수 있어야 한다.
팀원 모두가 겪어본 문제여야 의견을 모으기 쉽다.

이 조건으로 후보를 두 개로 좁혔다.

반려동물 건강관리 플랫폼
더치페이 정산 최적화 서비스

두 후보 중 더치페이 정산 최적화 서비스로 정했다. 반려동물 쪽은 사람마다 경험·관심도 편차가 커서 요구사항 합의가 어렵고, 한 달이라는 기간과 다양한 경험 수준의 팀원을 고려하면 기능 범위가 명확하고 모두가 겪어본 문제가 낫다고 판단했다. 여행·모임·MT 정산은 누구나 해봤고 문제가 구체적이다.

2. 서비스 개요

핵심은 이렇다.

여러 사람이 각자 결제한 비용을 입력하면, 각자 부담할 금액을 계산하고 최소한의 송금 횟수로 정산하도록 도와주는 서비스

단순히 총액을 사람 수로 나누는 계산기가 아니다. 두 가지가 다르다.

누가 어떤 비용을 썼는지 반영하고, 일부 인원만 쓴 비용도 따로 나눈다.
가장 효율적인 송금 방법(최소 송금 횟수)까지 계산한다.

전체 흐름

모임 생성 → 참여자 추가 → 지출 등록 → 비용 부담 대상 설정
→ 개인별 부담 금액 계산 → 실제 결제 금액 계산 → 최종 잔액 계산
→ 정산 최적화 → 최소 송금 횟수 정산 결과 → 정산 완료 처리

정산 예시

숙박비 20만 원(A 결제), 식비 8만 원(B 결제), 교통비 4만 원(C 결제)을 네 명이 똑같이 나누면 각자 8만 원을 부담한다. 실제 결제액에서 부담액을 빼면 최종 잔액이 나온다.

사람	실제 결제	부담 금액	최종 잔액
A	200,000	80,000	+120,000 (받을 돈)
B	80,000	80,000	0
C	40,000	80,000	−40,000 (보낼 돈)
D	0	80,000	−80,000 (보낼 돈)

채권·채무 관계를 정리하면 두 번의 송금으로 끝난다.

C → A : 40,000원
D → A : 80,000원

참여자가 많아지면 관계가 복잡해지는데(예: 8번 송금 → 3번 송금), 송금 횟수를 최소로 줄이는 것이 이 서비스의 핵심 기능이다.

3. 기능 정리

필수(MVP)와 확장으로 나눴다.

모임 & 참여자 관리 — 모임 생성/조회/수정/삭제, 참여자 추가/수정/삭제, 초대 코드·링크 참여(확장)
지출 관리 — 지출 등록/조회/수정/삭제 (변경 시 부담 금액·잔액·정산 결과 자동 재계산)
비용 분배 — 전체 N등분 / 일부 인원 분배 / 개별 금액 지정
정산 계산 & 최적화(핵심) — 개인별 부담·결제·잔액 계산 → 최소 송금 횟수 도출
정산 진행 관리 — 정산 결과 확인, 완료 처리, 미정산/전체 완료 여부 표시
조회 & 통계 — 전체 지출, 참여자별/카테고리별 집계, 개인별 정산 요약

차별화 아이디어로는 여행·모임 전체 지출 관리 확장, 정산 관계 그래프 시각화(최적화 전/후 비교), 정산 커뮤니케이션(부드러운 문구·공유 메시지), 정산 신뢰도 지표 등을 후보로 임시 선정했고 후속 검토로 확정하기로 했다.

4. 팀 운영

팀 미팅: 매주 토요일 21:00
팀 명: SplitOpt — Split(나누기) + Optimization(최적화). 지출을 나누고 정산 경로를 최적화한다는 뜻.

5. GitHub

프론트엔드/백엔드 레포를 분리했다.

Organization: 26-ECC-SplitOpt
Frontend: splitopt-frontend
Backend: splitopt-backend

6. API 명세서 초안

1주차의 실질적 결과물은 API 명세서 초안이다. 총 49개 엔드포인트를 도출했고, 아래는 핵심(필수) 영역 발췌다.

인증 / 사용자

기능	Method	Path
회원가입	POST	`/api/auth/signup`
로그인	POST	`/api/auth/login`
로그아웃	POST	`/api/auth/logout`
내 정보 조회	GET	`/api/auth/me`

모임 & 참여자

기능	Method	Path
모임 생성 / 목록	POST·GET	`/api/groups`
모임 상세/수정/삭제	GET·PUT·DELETE	`/api/groups/{groupId}`
참여자 추가 / 목록	POST·GET	`/api/groups/{groupId}/participants`
참여자 수정/삭제	PUT·DELETE	`/api/groups/{groupId}/participants/{participantId}`

지출 내역

기능	Method	Path
지출 등록 / 목록	POST·GET	`/api/groups/{groupId}/expenses`
지출 상세/수정/삭제	GET·PUT·DELETE	`/api/groups/{groupId}/expenses/{expenseId}`
지출 부담 대상 설정	PUT	`/api/groups/{groupId}/expenses/{expenseId}/shares`

정산 계산 / 최적화 (핵심)

기능	Method	Path
개인별 잔액 조회	GET	`/api/groups/{groupId}/balances`
정산 최적화 실행	POST	`/api/groups/{groupId}/settlements/optimize`
정산 결과 조회	GET	`/api/groups/{groupId}/settlements`
내 정산 내역 조회	GET	`/api/groups/{groupId}/settlements/me`
정산 완료 처리	PATCH	`/api/groups/{groupId}/settlements/{settlementId}/status`

확장 기능(일정·예산, 정산 그래프, 정산 메시지/리마인드, 신뢰도) 엔드포인트도 초안에 함께 잡아 나중에 붙일 때 구조가 흔들리지 않도록 했다.

7. 회고 & 다음 주 계획

API 명세를 정리하면서 이 서비스의 백엔드 난이도가 CRUD가 아니라 계산에 있다는 걸 확인했다.

지출 하나를 수정하면 부담 금액 → 최종 잔액 → 정산 결과가 연쇄 재계산된다. 이 흐름을 어디서 트리거하고 일관성을 어떻게 지킬지가 관건이다.
settlements/optimize의 최소 송금 횟수 최적화가 알고리즘 코어다. 채권·채무를 상계한 뒤 송금 횟수를 줄이는 문제라 자료구조·알고리즘 설계를 따로 봐야 한다.

ECC, 2026-Summer-Project-SplitOpt

This post is licensed under CC BY 4.0 by the author.