온라인 게임에서 트랜잭션을 모르면 왜 아이템과 재화 버그가 반복되는가
온라인 게임에서 자주 문제가 되는 버그는 생각보다 비슷한 얼굴을 하고 있다. 아이템이 사라지거나, 중복되거나, 재화가 맞지 않게 늘어나거나, 거래가 절반만 반영되는 식이다. 겉으로는 다른 버그처럼 보여도, 안쪽에서 보면 여러 변경이 한 묶음으로 처리되지 않았다는 공통 원인이 숨어 있는 경우가 많다.
이때 필요한 기본 도구가 트랜잭션이다. 트랜잭션은 데이터베이스 안에서 여러 변경을 하나의 작업 단위로 묶어, 전부 성공하거나 전부 취소되게 만드는 장치다.
트랜잭션은 “여러 줄을 한 번에 안전하게 바꾸는 방법”이다
PostgreSQL 문서는 Transactions에서 트랜잭션을 데이터베이스의 기본 개념이라고 설명한다. 특히 송금 예시를 들며, 어떤 갱신이 일부만 반영되면 안 되고, 완료된 뒤에는 영구적으로 기록되어야 하며, 동시 실행 중인 다른 작업은 중간 상태를 보면 안 된다고 말한다.
이 설명은 게임 서버에도 그대로 적용된다.
- 아이템 줍기
- 우편 발송
- 거래소 구매
- 플레이어 간 재화 이동
- 보상 지급
이런 작업은 보통 한 줄의 SQL로 끝나지 않는다. 그래서 중간에 하나라도 실패하면 전체를 되돌릴 수 있어야 한다.
게임에서 문제가 되는 것은 보통 “절반만 성공한 상태”다
예를 들어 플레이어 간 거래를 생각해 보자.
- A의 인벤토리에서 아이템을 뺀다
- B의 인벤토리에 아이템을 넣는다
- 양쪽 재화와 로그를 갱신한다
이 셋이 따로 처리되면 중간에 실패했을 때 이상한 상태가 생긴다.
- A에게서 아이템은 빠졌는데 B에게는 안 들어가거나
- 아이템은 옮겨졌는데 재화는 갱신되지 않거나
- 로그만 남고 실제 데이터는 바뀌지 않을 수 있다
트랜잭션은 이런 반쯤 성공한 상태를 막기 위해 존재한다.
동시성 문제까지 생각하면 트랜잭션은 더 중요해진다
PostgreSQL 문서는 여러 트랜잭션이 동시에 실행될 때, 하나가 다른 하나의 미완성 상태를 보면 안 된다고 설명한다. MySQL의 InnoDB Transaction Model도 행 단위 잠금과 일관된 읽기를 통해 동시성 문제를 다룬다고 말한다.
게임 서버에서는 이 문제가 더 자주 드러난다.
- 같은 창고를 동시에 열고 수정하거나
- 같은 거래 대상에 여러 요청이 몰리거나
- 같은 보상을 중복 수령하려고 시도할 때
동시성 제어가 약하면 두 요청이 서로의 중간 상태를 덮어쓰면서 복사 버그나 손실 버그가 만들어질 수 있다.
그래서 중요한 것은 ACID 암기보다 “어디를 한 묶음으로 볼 것인가”다
트랜잭션을 배울 때 흔히 원자성, 일관성, 격리성, 지속성 같은 용어를 외운다. 물론 의미는 중요하다. 하지만 실무에서 더 중요한 질문은 이것이다.
이 기능에서 무엇과 무엇이 반드시 함께 성공해야 하는가?
예를 들면:
- 인벤토리 변경과 로그 기록을 분리할 수 있는가
- 우편 발송과 첨부 아이템 이동은 같은 단위여야 하는가
- 보상 지급과 중복 지급 방지 표시는 같이 커밋되어야 하는가
이 질문에 제대로 답하지 못하면, 트랜잭션을 안 쓴 것과 비슷한 결과가 나온다.
핵심 정리
트랜잭션은 데이터베이스 이론 수업의 용어가 아니라, 온라인 게임의 아이템·재화·인벤토리 버그를 막는 기본 장치다. 핵심은 여러 갱신을 하나의 단위로 묶어, 전부 성공하거나 전부 취소되게 만드는 데 있다.
게임 서버에서 자주 터지는 문제는 대부분 데이터가 너무 복잡해서가 아니라, 함께 움직여야 할 변경을 따로 처리해서 생긴다. 그래서 트랜잭션을 이해한다는 말은 결국 어디까지를 하나의 사실로 저장할 것인가를 이해한다는 말과 같다.