트랜젝션
여러 작업을 하나의 묶음으로처리해서, 전부 성공하거나 전부 실패하게 만드는 것.
Unity 클라이언트 개발자가 알아야 하는 이유는
내가 직접 DB를 다루지 않더라도 서버가 트랜잭션을 어떻게 처리하는지에 따라서 클라이언트 코드 설계가 완전히 달라지기 때문이다.
1. 정의와 ACID
트랜잭션은 하나의 논리적인 작업 단위이다.
예를 들어 "인벤토리에서 재료 3개를 소모하고 아이템 1개를 생성한다."는 두 개의 DB 연산이지만,나로 묶여야 한다. 중간에 실패하면 재료만 사라지고 아이템은 안 생기는 최악의 상황이 벌어지니까.
이걸 보장하는 4개의 속성이 ACID 이다.
Atomicity (원자성)
전부 성공 또는 전부 실패. 중간 상태가 존재하면 안됨
Consistency (일관성)
트랜잭션 전후로 데이터규칙 (잔액이 음수가 될 수 없다 등)이 항상 지켜짐
Isolation (격리성)
동시에 여러 트랜잭션이 실행돼도 서로 간섭하지 않음 (같은 아이템을 두명이 동시에 구매 시도할 때 중요)
Durability (지속성)
커밋된 결과는 서버가 죽어도 사라지지 않음
unity 개발자가 이 4가지를 구현할 일은 거의 없다. (서버/DB의 책임). 하지만 이게 깨졌을 때 클라이언트에서 어떤 증상으로 나타나는 지는 반드시 알아야 한다.
2. 실전 상황
인앱 결제 (IAP)
결제는 앱스토어/구글플레이 -> 게임서버 -> 게임 클라이언트 3자가 얽히는 가장 대표적인 트랜잭션 시나리오다. 영수증 검증 -> 재화 지급이 하나로 묶이지 않으면 결제는 됐는데 아이템을 못 받는 최악의 CS 케이스가 생긴다.
인벤토리/재화 시스템
장비 강화, 아이템 합성, 상점 구매 처럼 "여러 값을 동시에 바꾸는" 로직은 전부 트랜잭션 대상입니다. 강화 재료만 소모되고 강화는 실패 처리 안 됐다거나 하는 버그가 여기서 나온다.
멀티 플레이어 상태 동기화
서버 베이스에서는 클라이언트의 행동 요청이 서버에서 검증,적용 된 후에야 "확정" 된다. 클라이언트가 먼저 화면을 바꿨다가 (낙관적 업데이트) 서버 응답이 다르면 되돌리는 구조 자체가 트랜잭션의 클라이언트 측 대응입니다.
로컬 저장 데이터
PlayerPrefs나 로컬 세이브 파일에 여러 값을 나눠서 저장하다가 중간에 앱이 꺼지면 저장 데이터가 깨질 수 있다. 이때도 "임시 파일에 다 쓴 뒤 한번에 교체" 하는 방식으로 원자성을 흉내 낸다.
나의 경험 ✨
게임 개발 중 간헐적으로 던전 클리어시 보상을 받을 때 deadlock 이라고 서버 에러가 뜬 적이 있었다.
기존 던전 클리어 보상 api 에는 던전 보상 Currency 와 함께 Quest(일일퀘,주간퀘 등)도 response로 업데이트 하고 있었다.
그때 서버 개발자 분이 기존 Quest 정보를 response로 한번에 받지 말고, 따로 GetQuestInfo 통신을 보내줄 수 있냐고 여쭤봐서 그렇게 작업했다.
그때는 그 이유를 자세히 몰랐는데, 이번 트랜잭션을 공부하면서 그 이유를 알 거 같다.
-
Quest 조건 중에 "아무 던전 클리어", "특정 던전 클리어" 이런식으로 던전 하나에 중복 체크 될 수 있는 조건이 있었고,
-
서버에서 내려주는 Quest 정보 중에 실제 특정 퀘스트의 진행도와, 전체 퀘스트 진행도를 얼마나 진행했는지 표기하는 QuestPoint 정보도 같이 있었다.
그렇다면 클라이언트에 Quest 정보를 내려주기 위해 2번(퀘스트 진행도 계산)을 진행하면 앞서 말한 2가지 조건 모두에서 계산을 진행함으로 서로 다른 트랜잭션과 충돌 했다는 추측을 할 수 있다.
물론 지금은 영원히 알 수 없게 됐지만
3. 실전 Unity 코드 적용
- 클라이언트는 결과의 확정자가 아니다. (서버베이스로 개발 필요)
- 낙관적 업데이트를 사용할 땐 반드시 롤백 경로를 같이 설계한다.
- 모든 상태 변경 요청에 고유 요청 ID(멱등키)를 붙인다.
- 결제, 보상 처럼 중요한 트랜잭션은 클라이언트에 pending 상태를 남긴다.
