「오늘 누가 쏘냐?」 정산 2.0 — 분담 방식 5가지, 송금 목록, 계좌·카카오페이 링크

오늘 누가 쏘냐? 개발기의 후속이다. 연재 5편에서 등수별 커피값 분담 공식 ComputeShares를 만들었고, 9편에서 1.6(버전 코드 10)까지 Play 스토어 비공개 테스트에 올렸다.

1.6까지 앱이 하는 일은 「누가 얼마 낼지」 계산하는 데서 끝났다. 그 다음 단계, 즉 한 사람이 먼저 계산하고 나머지가 그 사람에게 보내는 일, 2차를 다른 사람이 계산하는 경우, 누가 보냈는지 확인하는 일은 앱 밖에 있었다. 1.7에서 이 부분을 앱 안으로 들였다. 내부에서는 「정산 2.0」이라고 불렀다.

이번 판에 들어간 것은 네 가지다.

기능	내용
분담 방식 선택	등수대로 · 독박 · 꼴등 둘이 반반 · N빵 · 1등만 면제, 반올림 10 / 100 / 1,000원
정산 화면	차수(1차·2차…), 계산한 사람, 사람별 합계, 송금 목록, 입금 체크, 정산 내용 공유
계좌·송금 링크	받는 사람 계좌와 카카오페이 송금 링크 등록, 복사·열기·공유
기록 화면	탭 3개 — 벌칙 횟수 · 이번 달 부담액 · 정산 내역

시작하기 전에 설계 문서(Docs/settlement-v2.md)를 먼저 썼다. 데이터 구조, 화면 배치, 검증 항목, 단계별 진행 순서를 정리하고, 실제 코드와 대조해 틀린 전제를 고친 뒤 구현에 들어갔다. 그 문서에서 정한 원칙 하나가 이번 작업 전체를 묶는다. 같이 하기 규약 버전은 12 그대로 둔다. 1.6 게스트와 1.7 방장이 같은 방에서 놀 수 있어야 하기 때문이다.

분담 방식 다섯 가지

5편의 공식은 「상위 2명 면제, 하위 최대 4명이 40:30:20:10」 하나뿐이었다. 1.7에서는 꼴등 혼자 다 내는 독박, 똑같이 나누는 N빵 등 다섯 가지 중에서 고를 수 있게 했다. 기본값은 예전과 같은 「등수대로」다.

방식은 ShareRule enum(Ranked·Dokbak·HalfTwo·Even·WinnerFree, 0~4)으로 정의했다. 숫자가 PlayerPrefs에 저장되므로 값은 바꾸지 않는다.

계산은 Unity API를 쓰지 않는 순수 정적 클래스 Settlement로 옮겼다. 핵심은 두 가지만 바꾼 것이다. 돈을 내는 사람 수를 방식별로 정하고, 가중치를 「등수대로」일 때만 등차로, 나머지는 모두 1로 둔다.

돈을 내는 사람 수는 독박 1, 꼴등 둘이 반반 2, N빵 전원, 1등만 면제 count - 1, 등수대로는 5편과 같은 count - 2를 1~4로 자른 값이다.

public static List<int> ComputeShares(int total, int count, ShareRule rule, int unit)
{
    // ... 0으로 채운 리스트, total <= 0 이면 그대로 반환
    int payers = PayerCount(count, rule);
    bool ranked = rule == ShareRule.Ranked;
    long weightSum = ranked ? (long)payers * (payers + 1) / 2 : payers;
    int assigned = 0;
    for (int i = 0; i < payers; i++)
    {
        long weight = ranked ? payers - i : 1;
        int amount = (int)((long)total * weight / weightSum / unit * unit);
        shares[count - 1 - i] = amount;
        assigned += amount;
    }
    shares[count - 1] += total - assigned; // 단위로 자르고 남은 금액은 꼴등이
    return shares;
}

5편의 / 100 * 100이 / unit * unit으로 바뀌었고, 끝전은 여전히 꼴등에게 몰린다. 그래서 어떤 방식이든 몫의 합은 총액과 정확히 같다.

기존 GameData.ComputeShares(total, n)은 시그니처를 그대로 두고, 저장된 방식과 단위로 Settlement.ComputeShares를 부르게만 바꿨다. 게임 15개와 사다리·룰렛의 사전 계산 코드는 이 함수만 부르므로 손대지 않아도 됐다.

27,500원, 5명으로 비교

아래 정산 화면 스크린샷과 같은 금액으로 다섯 방식을 계산해 보면 이렇다(100원 단위, 1등 → 꼴등).

방식	내는 사람	1등	2등	3등	4등	5등
등수대로	3	0	0	4,500	9,100	13,900
독박	1	0	0	0	0	27,500
꼴등 둘이 반반	2	0	0	0	13,700	13,800
N빵	5	5,500	5,500	5,500	5,500	5,500
1등만 면제	4	0	6,800	6,800	6,800	7,100

등수대로는 가중치 합이 6이다. 27,500 × 3 ÷ 6 = 13,750 → 13,700, × 2 ÷ 6 = 9,166 → 9,100, × 1 ÷ 6 = 4,583 → 4,500. 합이 27,300이라 남는 200원이 꼴등에게 가서 13,900원이 된다. 1등만 면제는 27,500 ÷ 4 = 6,875 → 6,800씩, 남는 300원이 꼴등 몫에 붙는다.

반올림 단위는 끝전 크기를 정한다. 10,000원을 3명이 N빵하면 10원 단위는 3,330 / 3,330 / 3,340, 100원 단위는 3,300 / 3,300 / 3,400, 1,000원 단위는 3,000 / 3,000 / 4,000원이다.

2명일 때는 방식끼리 겹친다. 꼴등 둘이 반반은 N빵과 같고, 1등만 면제는 독박과 같다.

게임 선택 화면과 결과 화면

게임 선택 화면의 안내 줄은 버튼이 됐다. 「분담: 등수대로 · 꼴등 13,900원 ›」처럼 보이고, 누르면 방식 선택 창이 뜬다. 창에는 방식 다섯 개가 한 줄씩 있고, 각 줄 옆에 지금 인원과 금액으로 계산한 꼴등 몫과 1등 몫을 함께 보여 준다. 아래에는 반올림 단위 버튼 세 개가 있다.

게임 안의 안내 문구도 같이 바꿔야 했다. 13개 게임이 「총 12,000원 · 늦게 누를수록 많이 냅니다」처럼 등수대로를 전제로 한 문장을 띄우고 있었다. N빵인데 이 문구가 뜨면 틀린 안내다. GameData.AmountStatus(rankedPhrase) 헬퍼를 만들어, 등수대로일 때만 게임별 문장을 쓰고 나머지 방식은 「꼴등이 다 냅니다」「모두 똑같이 나눠 냅니다」 같은 방식별 문장으로 바꿨다.

결과 화면 제목도 손봤다. N빵에서 「민수님이 5,500원!」이라고 하면 혼자 내는 것처럼 보인다. 몫이 같은 사람이 여럿인 방식은 꼴등 바로 앞 사람의 몫을 기본 몫으로 보고 「모두 5,500원씩」으로 쓴다. 끝전이 있으면 부제에 「끝전 100원은 민수님」을 붙인다. 등수대로·독박은 예전처럼 꼴등 이름과 금액이다.

「결과 복사」 자리는 「정산하기」가 차지했다. 텍스트 복사는 정산 화면으로 옮겼다.

같이 하기: 게스트 폰 설정을 읽지 않게

같이 하기에서 분담액은 방장 폰이 계산하고 결과 메시지의 shares로 게스트에게 보낸다(7편의 호스트 권위 구조). 방식 이름은 보내지 않는다. 규약을 바꾸지 않기로 했기 때문이다.

그래서 게스트 화면에서 「지금 분담 방식」이나 「총액」을 자기 폰 설정에서 읽는 곳이 있으면 안 된다. 코드를 대조해 보니 두 군데가 있었다. 눈치 게임 결과판의 등수 색은 「금액이 없으면 꼴등만 빨강」을 게스트 폰의 총액으로 판단하고 있었고, 폭탄 돌리기는 게스트 분기 전에 게스트 폰 총액으로 안내 문구를 만들고 있었다. 앞의 것은 「받은 shares가 모두 0인가」로 판단하게 바꾸고, 뒤의 것은 게스트일 때 금액 문구를 비웠다. 게임 설명 창의 「커피값은 등수대로.」 같은 방식 문장도 게스트에게는 띄우지 않는다. 게스트는 방장이 무엇을 골랐는지 모르기 때문이다.

방장이 정산 화면을 열 때도 문제가 있었다. 방장은 화면이 바뀔 때마다 게스트에게 화면 이름을 알리고, 게스트 게임 화면은 그 이름이 자기 게임이나 ResultScreen이 아니면 로비로 돌아간다. 그래서 ScreenBase에 알릴 이름 NetScreenName(기본값은 클래스 이름)을 두고, 정산 화면과 기록 화면은 "ResultScreen"이라고 알리게 했다. 메시지 형식이 그대로라 1.6 게스트도 영향이 없다.

결과 기록은 한 번만

정산 화면이 생기면 결과 화면과 정산 화면을 오가게 된다. 그런데 결과 화면은 OnShow마다 벌칙 횟수를 1 올리고 있었다. 돌아올 때마다 꼴등의 벌칙이 늘어나는 셈이다.

GameData.SetResult에서 결과마다 ResultId를 하나씩 올리고, 그 시점의 총액·방식·단위를 LastTotal/LastRule/LastUnit으로 함께 저장하게 했다. 결과 화면은 처음 보는 ResultId일 때만 벌칙 횟수를 올리고 효과음·진동을 내며, 금액이 있으면 정산 기록도 이때 한 번 만든다.

LastRule을 따로 남긴 이유는 정산 1차 때문이다. 결과를 본 뒤에 게임 선택 화면에서 방식을 바꿔도, 이미 끝난 판의 정산 1차는 결과 화면에 나온 금액과 같아야 한다.

정산 화면

정산 한 건은 게임 한 판이다. 구조는 이렇게 잡았다.

public class SettleRound          // 1차, 2차 카페 …
{
    public string title;
    public int amount;
    public int rule;              // ShareRule
    public int unit;              // 반올림 단위
    public int payer;             // 계산한 사람 (members 인덱스)
    public List<int> joined;      // 참여한 사람
    public List<int> shares;      // members 순서의 몫 (불참 0)
}

public class SettleTransfer { public int from, to, amount; public bool paid; }

public class SettlementRecord
{
    public string id, createdAt, month, game;
    public List<string> members;  // 이름, 게임 등수 순서(1등 → 꼴등)
    public List<SettleRound> rounds;
    public List<SettleTransfer> transfers;
}

금액이 있는 판이면 결과 화면이 뜰 때 정산 기록이 자동으로 하나 생긴다. 1차는 결과 화면과 같은 금액·방식·단위, 참여는 전원, 계산한 사람은 꼴등이다. 「+ 차수 추가」로 만드는 2차부터는 기본 방식을 N빵으로 정했다. 계산한 사람 기본값은 역시 꼴등이다.

차수를 누르면 편집 창이 뜬다. 제목, 금액, 방식, 참여자, 계산한 사람을 고친다. 입력칸은 창 위쪽에 두었다. 아래에 두면 Android 키보드에 가린다. 참여자·계산한 사람 칩은 4명씩 한 줄이고, 인원에 맞춰 창 높이가 바뀐다.

빠진 사람이 있는 차수

2차에 한 명이 먼저 갔다면 그 사람을 빼고 나눠야 한다. 이때 등수대로 같은 방식은 「남은 사람 중 누가 꼴등인가」가 문제다. RoundShares는 참여자만 남긴 뒤 게임 등수의 상대 순서를 그대로 두고 ComputeShares를 부른다.

var order = new List<int>();
foreach (int m in joined)
    if (m >= 0 && m < memberCount && !order.Contains(m)) order.Add(m);
if (order.Count == 0) return result;
order.Sort();   // members 는 1등 → 꼴등 순서라, 인덱스 정렬이 곧 등수 순서

var shares = ComputeShares(amount, order.Count, rule, unit);
for (int j = 0; j < order.Count; j++) result[order[j]] = shares[j];

송금 목록: 가장 큰 쪽끼리

사람마다 잔액을 「계산한 금액 합 − 몫 합」으로 구한다. 양수면 받을 돈, 음수면 보낼 돈이고 합은 0이다. 송금 목록은 가장 많이 보낼 사람이 가장 많이 받을 사람에게 보내는 일을 반복해서 만든다.

for (int guard = 0; guard < b.Count * 2; guard++)
{
    int debtor = -1, creditor = -1;
    for (int i = 0; i < b.Count; i++)
    {
        if (b[i] < 0 && (debtor < 0 || b[i] < b[debtor])) debtor = i;
        if (b[i] > 0 && (creditor < 0 || b[i] > b[creditor])) creditor = i;
    }
    if (debtor < 0 || creditor < 0) break;
    long amount = Math.Min(-b[debtor], b[creditor]);
    list.Add(new Transfer(debtor, creditor, (int)amount));
    b[debtor] += amount;
    b[creditor] -= amount;
}

한 번 보낼 때마다 둘 중 적어도 한 사람의 잔액이 0이 되므로, 송금은 「사람 수 − 1」건을 넘지 않는다. 송금 건수를 정말 최소로 만드는 문제는 일반적으로 NP-hard라서 최소 건수까지는 보장하지 않기로 했다. 참가자는 최대 8명이므로 송금도 최대 7건이다.

스크린샷의 판은 간단하다. 민수가 27,500원을 계산했고 몫은 13,900원이니 잔액은 +13,600원이다. 철수 −9,100원, 지영 −4,500원이다. 가장 많이 보낼 철수가 먼저 민수에게 9,100원, 다음으로 지영이 4,500원을 보낸다.

차수가 둘이면 조금 더 재미있다. 자체 점검에 넣어 둔 사례는 4명, 1차 12,000원(등수대로, 4등 계산), 2차 18,000원(N빵, 2등 계산, 3등 빠짐)이다.

	1등	2등	3등	4등
1차 몫	0	0	4,000	8,000
2차 몫	6,000	6,000	0	6,000
계산한 금액	0	18,000	0	12,000
잔액	−6,000	+12,000	−4,000	−2,000

4등은 1차를 계산했지만 몫 합이 14,000원이라 오히려 2,000원을 보내야 한다. 송금은 1등 → 2등 6,000원, 3등 → 2등 4,000원, 4등 → 2등 2,000원 세 건이다.

입금 체크와 다시 계산

송금 줄마다 「입금 전 / 입금 완료」 버튼이 있고, 누르면 바로 저장한다. 문제는 차수를 고치면 송금 목록을 새로 만든다는 점이다. 그래서 Recalc는 이전 송금 중 보내는 사람·받는 사람·금액이 모두 같은 건의 입금 표시를 이어받는다. 금액이 바뀐 송금은 다시 「입금 전」이 된다. 이 동작도 자체 점검에 넣었다.

정산 내용 공유

「정산 내용 복사」는 클립보드로, 「공유」는 Android 공유 창으로 보낸다. 공유는 9편에서 만든 ShareService에 텍스트 공유 메서드를 공개로 하나 추가했고, Android가 아니면 클립보드 복사로 대신한다. 만들어지는 글은 이런 모양이다.

[오늘 누가 쏘냐?] 정산 · 10/11 사다리 타기
1차 27,500원 (등수대로, 민수 계산)

각자 몫
1등 영희 0원
2등 현우 0원
3등 지영 4,500원
4등 철수 9,100원
5등 민수 13,900원

보낼 돈
철수 → 민수 9,100원
지영 → 민수 4,500원

민수: 카카오뱅크 0000-00-0000000 (김민수)
민수 카카오페이: https://qr.kakaopay.com/AbCd1234

빠진 사람이 있는 차수에는 괄호 안에 「지영 빠짐」처럼 붙고, 입금이 끝난 송금에는 「(입금 완료)」가 붙는다. 마지막 계좌 줄은 받는 사람 중 계좌나 링크를 등록한 사람만 나온다.

받는 사람 계좌와 카카오페이 송금 링크

송금 목록까지 나오면 다음은 「민수 계좌가 뭐였지?」다. 사람마다 은행명, 계좌번호, 예금주, 카카오페이 송금 링크를 등록할 수 있게 했다. 편집 창 PayInfoEditor 하나를 정산 화면과 참가자 화면이 같이 쓴다. 정산 화면에서는 받는 사람 줄 아래에 「계좌 등록」이나 계좌 + 「계좌 복사」「카카오페이」「수정」 버튼이 붙고, 참가자 화면에는 사람마다 「+ 계좌」/「계좌」 버튼이 붙는다.

처음 설계에는 토스 송금 링크(toss.me) 칸도 있었다. 확인해 보니 토스아이디 서비스가 종료돼 있었다. 그래서 빼고, 계좌 복사를 기본으로, 카카오페이 링크를 선택으로 두었다.

링크는 코드만 받는다

카카오페이 앱의 「링크 복사」 결과는 https://qr.kakaopay.com/코드 형태다. 입력칸은 앞부분을 고정 글자로 보여 주고 코드만 받는다. 전체 링크를 붙여 넣어도 PayInfo.LinkFromInput이 https://, http://, www., 호스트 부분을 차례로 떼어 내고, 남은 코드가 글자·숫자·. _ -로만 되어 있을 때 https://qr.kakaopay.com/ 뒤에 붙여 저장한다.

그래서 AbCd1234, qr.kakaopay.com/AbCd1234, http://qr.kakaopay.com/AbCd1234/는 모두 https://qr.kakaopay.com/AbCd1234가 되고, https://example.com/x나 https://toss.me/... 같은 다른 주소, 공백이나 ?가 섞인 값은 거부한다.

「카카오페이」 버튼은 Application.OpenURL로 이 링크를 연다. 카카오페이 앱이 있으면 앱으로, 없으면 브라우저로 열린다. 열기 직전에도 https://로 시작하고 공백이 없는지 한 번 더 확인한다. 계좌번호는 숫자와 하이픈만 받고, 사이 공백은 저장 전에 지운다. 「계좌 복사」는 「은행명 계좌번호」를 복사한다. 은행 앱에 붙여 넣으면 은행과 계좌를 같이 알아보는 형식이다.

어디에 저장하나

계좌 정보는 이 기기의 PlayerPrefs 한 키(whopays.payinfo)에 JSON 리스트로 저장한다. 이름이 키다. JsonUtility가 Dictionary를 직렬화하지 못해서 리스트로 두었다. 서버로도, 같이 하기로 연결된 다른 폰으로도 보내지 않는다. 계좌번호와 링크는 Debug.Log로도 찍지 않는다. 편집 창에도 「이 폰에만 저장되고 다른 곳으로 보내지 않아요」라고 적었다. 앱 밖으로 나가는 경우는 사용자가 「계좌 복사」·「정산 내용 복사」·「공유」를 직접 누를 때뿐이다.

정산 기록도 같은 방식으로 whopays.settlements 한 키에 저장한다. 최근 100건, 6개월까지만 남기고 오래된 것부터 지운다. 저장할 때 정리하고, 불러올 때도 6개월 지난 기록은 목록에서 뺀다.

기록 화면: 탭 3개

5편의 「벌칙 기록 보기」는 이번 달 꼴등 횟수만 셌다. 이제 정산 기록이 있으니 돈도 셀 수 있다. 기록 화면을 탭 세 개로 나눴다.

• 벌칙 횟수 — 예전과 같다. 이번 달 꼴등 횟수.
• 부담액 — 이번 달 정산 기록의 몫을 이름별로 합해 막대로 보여 준다. 부제에 정산 건수와 총액이 붙는다.
• 정산 내역 — 최근 정산 목록. 날짜·게임·참가자·차수·총액과 「남은 입금 2건」 또는 「입금 완료」를 보여 준다. 누르면 그 정산 화면이 다시 열리고, 돌아오면 보던 탭 그대로다.

부담액은 따로 쌓지 않는다. 볼 때마다 이번 달 정산 기록을 돌며 사람별 몫(ShareOf)을 이름으로 더한다. 부담액을 결과가 나올 때마다 더해 두면, 정산 화면에서 금액을 고치거나 2차를 추가했을 때 이중으로 집계된다. 원본 하나에서 계산하면 그런 일이 없다.

초기화는 지금 보고 있는 탭만 지우고, 두 번 눌러야 지워진다. 부담액과 정산 내역은 같은 데이터라서, 둘 중 어디서 누르든 「정산 내역과 부담액이 함께 지워져요 · 한 번 더」라고 먼저 알려 준다. 타이틀 화면의 버튼 이름도 「기록 · 정산 내역」으로 바꿨다.

계산은 에디터 메뉴로 점검

이 프로젝트는 테스트 패키지를 추가하지 않는다는 규칙을 지켜 왔다. 대신 에디터 메뉴 「WhoPays > 정산 계산 자체 점검」을 만들었다. 누르면 Console에 통과·실패가 찍힌다. Settlement를 Unity API 없는 순수 클래스로 만든 이유가 여기에 있다.

점검하는 내용은 이렇다.

• 등수대로 + 100원이 1.6의 값과 같은지. 2~8명 × 여러 총액의 1.6 결과를 하드코딩해 비교한다.
• 다섯 방식, 세 단위, 모든 인원에서 합계 = 총액, 음수 없음, 1등 → 꼴등으로 갈수록 몫이 줄지 않음.
• 2명일 때 반반 = N빵, 1등만 면제 = 독박.
• 총액이 단위보다 작을 때(N빵 4명 50원 → 꼴등 50원).
• 불참자 몫 0, 참여자 등수 순서 유지.
• 송금: 잔액 합 0, 송금 후 모두 0, 건수 ≤ 사람 수 − 1. 위의 2차수 사례와 무작위 500회.
• 링크 입력 사례, 계좌번호 형식.

첫 번째 항목이 특히 중요했다. 기본값인 등수대로가 1.6과 1원이라도 다르면, 같은 판을 한 사람은 1.6으로, 한 사람은 1.7로 볼 때 금액이 어긋난다.

1.7 빌드와 스토어 정리

마지막으로 버전 1.7, 버전 코드 11로 AAB를 빌드했다. 크기는 23MB다. 같이 하기 규약은 12 그대로다. 9편의 출시 노트 규칙대로 1.6에서 올라오는 경우(A)와 1.5 이하에서 올라오는 경우(B) 두 안을 썼다. A에는 규약이 같으니 「같이 하기는 모든 폰이 최신 버전이어야」 줄을 넣지 않고, B에는 1.5 → 1.6에서 규약이 바뀌었으므로 넣었다.

개인정보 처리방침도 고쳤다. 시행일을 2026-10-05로 올리고, 기기에 저장되는 정보에 정산 내역(참가자 이름, 차수별 금액·방식·참여자·계산한 사람, 송금과 입금 여부)과 사용자가 입력한 계좌 정보(은행명·계좌번호·예금주·카카오페이 링크)를 넣었다. 둘 다 기기 안에만 저장되고 개발자 서버나 같이 하기로 연결된 다른 기기로 보내지 않는다는 점, 정산 내역은 100건·6개월까지만 보관한다는 점, 「카카오페이」 버튼은 링크를 열 뿐 앱이 송금·결제를 처리하지 않는다는 점을 적었다. 다른 사람의 계좌를 입력할 때는 그 사람의 동의를 받아 달라는 문장도 넣었다.

Play Console의 데이터 보안 답변도 다시 검토했다. 정산 내역과 계좌 정보는 기기 안에만 있고 개발자에게 전송되지 않으므로 「수집」에 해당하지 않는다. 정산 내용 공유는 사용자가 직접 고른 앱으로 보내는 것이라 「공유」에도 해당하지 않는다. 그래서 답은 바꾸지 않았다. 금융 기능 항목도 「없음」이다. 앱은 금액을 계산하고 계좌를 복사하고 링크를 열 뿐이다.

스토어 스크린샷은 1.7 화면으로 새로 만들었다. Windows 테스트 빌드에 -storeshots 폴더 인자를 주고 실행하면 예시 데이터를 넣고 화면 10개를 1080x1920 PNG로 찍은 뒤 종료한다. 캔버스를 카메라 모드와 렌더 텍스처로 바꿔 찍으므로 창 크기와 상관없이 기준 해상도로 나오고, 인자가 없으면 아무 일도 하지 않는다. 그 위에 소개 문구를 얹는 일은 Python 스크립트(gen_store_shots.py)가 한다. 이 글의 스크린샷 세 장이 그 결과물이고, 이름과 계좌는 모두 예시 데이터다. 1080x1920(9:16)은 휴대전화와 태블릿 규격을 모두 만족해서 같은 파일을 쓴다.

정리

• 분담 방식은 PayerCount와 가중치 두 곳만 바꿔서 다섯 가지가 됐다. 반올림 단위로 내리고 끝전은 꼴등이 내는 규칙은 5편 그대로라, 합은 언제나 총액과 같다.
• 정산은 「차수별 몫 → 사람별 잔액 → 가장 큰 쪽끼리 송금」 순서다. 송금은 사람 수 − 1건을 넘지 않고, 다시 계산해도 같은 송금의 입금 표시는 남는다.
• 계좌와 카카오페이 링크는 이 기기에만 저장하고, 링크는 qr.kakaopay.com 코드만 받아 https://로 만든다.
• 부담액은 쌓지 않고 정산 기록에서 계산한다. 원본을 하나로 두니 이중 집계가 없다.
• 같이 하기 규약은 12 그대로다. 게스트는 방장이 보낸 shares만 쓰고, 정산·기록 화면은 게스트에게 결과 화면으로 보인다.

이번 업데이트 노트는 1.7(버전 코드 11) 빌드와 스토어 자료 갱신까지를 정리했다.