경매장/거래소 시스템: 게임 내 인플레이션을 막는 자원 소모처(Tax) 및 거래 제약 설계

라이브 게임 경제와 인플레이션의 위험성

일부 MMORPG나 라이브 서비스에서는 몬스터 처치, 퀘스트, 일일 콘텐츠 같은 활동으로 게임 재화가 계속 발행됩니다. 발행량과 속도는 게임의 보상 규칙에 따라 다르며, 모든 게임에서 재화가 무한히 생산되는 것은 아닙니다.

재화 발행이 소모와 수요를 웃돌아 골드가 게임 경제에 쌓이면 인플레이션 압력이 커질 수 있습니다. 다른 조건이 같다면 골드의 구매력이 낮아지고 일부 아이템 가격이 오를 수 있지만, 실제 가격은 아이템 공급과 수요, 거래량 등에도 좌우됩니다. 신규 유저가 필수 장비를 구하기 어려워지거나 기존 유저가 보유 골드의 구매력 하락을 체감할 수도 있습니다.

골드 소각(Gold Sink)은 게임 경제의 균형을 관리하는 여러 수단 중 하나입니다. 유저 간 거래를 중개하는 경매장이나 거래소에도 적절한 수수료와 등록비를 적용해 재화를 회수하는 방안을 고려할 수 있습니다.

경매장 시스템에서 재화 순환과 거래 수수료를 통한 골드 소각 구조

위 그림은 세금과 등록비를 둔 가상의 거래소를 설명하는 개념도이며, 특정 게임의 실제 수치나 경제 데이터를 나타내지 않습니다.

거래소 수수료(Tax) 및 등록비 메커니즘 설계

거래소에 적용할 수 있는 한 가지 골드 싱크는 거래가 성사될 때 판매 대금의 일정 비율을 회수해 삭제(소각)하는 거래 수수료(Transaction Tax)입니다. 효과는 발행량, 다른 소모처, 수수료가 거래량에 미치는 영향에 따라 달라집니다.

단일 판매 수수료만 둘 수도 있고, 필요에 따라 등록 수수료(보증금)와 거래 성사 수수료(판매세)를 함께 둘 수도 있습니다. 두 수수료의 환불 및 부과 시점은 거래 정책에 맞춰 정해야 합니다.

등록 수수료 (Registration Fee): 매물을 거래소에 올리는 시점에 선불로 징수합니다. 수수료 크기와 환불 규칙에 따라 고가의 장기 매물이나 반복 등록을 줄이는 효과를 기대할 수 있지만, 거래 비용과 허위 매물 억제 효과를 함께 테스트해야 합니다. 유찰 또는 취소 시 일부나 전부를 환불하는 선택지도 있습니다.
거래 성사 수수료 (Transaction Tax): 구매자가 나타나 실제로 매매가 체결되었을 때 판매 대금에서 차감되는 비용입니다. 다른 소모처와 비교해 규모가 클 경우 주요 골드 싱크가 될 수 있습니다.

판매자가 아이템을 성공적으로 팔았을 때 손에 쥐게 되는 최종 정산 금액( $Net$ )은 다음과 같은 흐름으로 계산됩니다.

Net = P - \lceil P \times r_{tax} \rceil - F_{reg}

여기서 $P$ 는 최종 체결 가격, $r_{tax}$ 는 거래 수수료율, $F_{reg}$ 는 환불되지 않는 등록 수수료입니다. 이 식은 골드 단위가 정수이고 거래세를 올림한다고 가정하며, 반올림 규칙은 프로젝트 정책에 맞춰 정해야 합니다.

초고가 아이템의 시세 왜곡이나 투기성 거래에 대응하려면 거래 금액 구간별로 다른 요율을 적용하는 누진 수수료제를 실험할 수 있습니다. 소액 거래의 비용을 낮추고 고액 거래의 수수료를 높이는 설계가 가능하지만, 거래량과 이용자 행동에 미치는 효과를 테스트해야 합니다.

graph TD
    A[아이템 판매 등록] --> B[등록 수수료 차감 및 소각]
    B --> C[거래소 매물 등재]
    C --> D[다른 유저의 구매 결제]
    D --> E[거래 수수료 계산 및 소각]
    E --> F[최종 정산금 판매자 전달]

거래 제약(Restriction)을 통한 매크로 및 시세 조작 방지

수수료율 조정만으로 작업장이나 매크로 계정의 어뷰징을 완전히 차단하기는 어렵습니다. 통정 거래를 통한 골드 세탁, 특정 매물의 매점매석, 시세 조작 같은 행위는 게임에 따라 위험이 될 수 있으므로 거래 규칙과 탐지 정책을 함께 설계할 수 있습니다.

프로젝트의 경제 구조와 악용 유형을 살펴본 뒤 다음 장치를 선택적으로 적용할 수 있습니다.

상하한가 밴드 (Price Banding): 최근 체결가를 기준으로 판매 등록 가능 금액의 최저가와 최고가 범위를 제한할 수 있습니다. ±20~30%는 테스트용 시작 예시일 뿐이며, 밴드는 허용 범위 안의 시세 조작이나 계정 간 이전을 막지 못하므로 다른 탐지 정책과 함께 평가해야 합니다.
거래 쿨다운 (Trade Cooldown): 거래소에서 아이템을 구매한 뒤 일정 시간 재등록을 제한할 수 있습니다. 24시간~3일은 검토용 예시이며, 재판매를 늦추는 효과는 있어도 매크로나 단기 시세 교란을 차단하지는 못합니다.
거래 후 귀속 (Bind on Trade / 거래 횟수 제한): 장비가 파괴되지 않고 신규 공급이 계속되면, 수요와 소모처가 충분하지 않은 게임에서는 공급 과잉과 가격 하락 압력이 생길 수 있습니다. 핵심 아이템을 거래 후 계정 귀속으로 바꾸거나 재포장 가능 횟수를 제한하는 방식은 유통량을 줄일 수 있지만, 거래 편의와 아이템 가치에 미치는 영향도 함께 평가해야 합니다.

가상의 거래소 UI 개념도: 27,500 골드 판매가에서 세금 1,375와 등록비 550을 차감한 정산액은 25,575 골드입니다. 실제 게임의 시세나 측정 결과가 아닙니다.

인디 게임 및 MMO 개발을 위한 실전 적용 가이드

거래소 시스템의 초기 수치를 고정한 뒤 경제 변화에 대응하지 못하면 문제가 될 수 있습니다. 콘텐츠 소모 속도와 파밍 방식에 따라 게임 경제가 달라질 수 있으므로, 초기 설계부터 운영 중 점검과 조정을 고려해야 합니다.

오픈 초기와 안정기의 밸런스 분리: 출시 초반의 수수료와 거래 규칙은 거래 데이터와 이용자 반응을 보며 조정할 수 있습니다. 수수료가 거래 참여나 외부 거래에 미치는 영향은 게임마다 다르므로, 초기에 낮은 수수료를 적용하거나 경제 지표에 따라 설정을 바꾸는 방안을 테스트하고 서버 설정으로 관리할 수 있습니다.
일일 재화 흐름 모니터링: 재화 발행량, 거래소 세금과 등록비를 포함한 각종 소모량, 총 보유량의 변화를 함께 추적할 수 있습니다. 거래소 소각량을 총 발행량과 비교하면 거래소가 전체 소모처에서 차지하는 비중을 보는 데 도움이 되지만, 그 비율만으로 경제가 위험한지 판단할 수는 없습니다. 지표의 변화와 가격·거래량·이용자 행동을 함께 살펴보고, 수수료 조정은 영향 평가 후 선택해야 합니다.

시세 조작을 막는 동적 가격 밴드: 단순 평균의 함정

상하한가 밴드 정책을 구현할 때 흔히 저지르는 실수는 최근 N일간의 체결가를 단순히 산술 평균(SMA) 내어 기준가로 삼는 것입니다.

이 방식은 유동성이 적은 비인기 아이템이나 새벽 시간대에 취약합니다. 작업장이나 악의적인 유저가 새벽에 헐값의 아이템을 고가에 자전거래(Wash Trading) 2~3회만 체결시켜도 기준가가 왜곡되어 상한가가 비정상적으로 치솟기 때문입니다.

기준가에는 거래량 가중 평균(VWAP: Volume-Weighted Average Price)을 고려할 수 있지만, 조작 위험과 거래량 분포에 맞는 산정 방식을 선택해야 합니다.

VWAP = \frac{\sum (P_i \times Q_i)}{\sum Q_i}

여기서 $P_i$ 는 $i$ 번째 거래의 체결 단가, $Q_i$ 는 체결 수량입니다. 거래량 가중은 적은 수량의 거래가 기준가에 미치는 영향을 낮출 수 있지만, 큰 수량의 자전거래까지 막지는 못합니다. 계정 관계, 거래 상대, 최소 표본 수와 함께 검증해야 합니다.

유효 거래가 없거나 총 체결 수량이 0이면 이 식은 계산할 수 없으므로, 가격 밴드를 비활성화하거나 사전에 정의한 기준가를 사용하는 등의 초기화 규칙이 필요합니다.

여기에 직전 기준가 대비 갱신 폭 상한(예: 하루 최대 ±15%라는 프로젝트별 시험값)을 두는 서킷 브레이커(Circuit Breaker) 로직을 더해 급격한 기준가 변화를 제한할 수 있습니다. 이 값은 표준이나 보장된 안전 수치가 아니므로 게임별 데이터로 조정해야 합니다.

서버 관점에서의 동시성 제어와 데이터 무결성(ACID)

거래소 시스템 구축에서 기획만큼이나 중요한 것이 바로 서버 동시성(Concurrency) 제어입니다.

라이브 서비스에서 발생하는 가장 치명적인 사고 중 하나는 “마지막 남은 1개의 인기 매물을 서로 다른 두 유저가 동시에 구매 버튼을 눌렀을 때, 아이템은 1개인데 둘 다 결제가 성공하거나 아이템이 2개로 복사되는 버그”입니다.

이를 방지하기 위해 데이터베이스 및 분산 환경에서 다음과 같은 트랜잭션 방어 전략을 수립해야 합니다.

flowchart TD
    A["구매자 구매 요청 인입"] --> B["분산 락 (Distributed Lock) 획득 - 매물 ID 기준"]
    B --> C{"매물 상태 확인: ACTIVE 여부"}
    C -->|"아니오 (이미 판매됨 또는 취소)"| D["락 해제 및 즉시 구매 실패 반환"]
    C -->|"예 (판매 중)"| E["DB 트랜잭션 시작"]
    E --> F["구매자 골드 차감 검증"]
    F --> G["수수료 계산 및 소각 로그 기록"]
    G --> H["매물 상태 SOLD 전환 및 아이템 소유권 이전"]
    H --> I["DB 트랜잭션 커밋"]
    I --> J["분산 락 해제"]
    J --> K["판매자 정산 우편/인박스 비동기 발송"]

분산 락(Distributed Lock) 활용: Redis 같은 분산 락은 ListingId 단위의 중복 작업을 줄이는 데 활용할 수 있습니다. 임대 만료나 연결 장애로 락이 풀릴 수 있으므로 DB의 행 잠금 또는 조건부 상태 갱신을 최종 무결성 기준으로 삼아야 합니다.
원자적 상태 검증 (Optimistic / Pessimistic Locking): DB 공급자와 격리 수준에 따라 지원되는 방식은 다릅니다. 예를 들어 일부 RDBMS의 트랜잭션에서 SELECT ... FOR UPDATE로 매물 행을 잠그거나, 조건부 UPDATE의 영향 행 수를 확인해 상태를 원자적으로 선점할 수 있습니다. 구매자 잔액도 조건부 차감 후 영향 행 수를 검사해야 합니다.
정산과 알림의 비동기 분리 (Outbox Pattern): 매매와 정산 메시지 발행을 각각 별도로 처리하면 한쪽만 성공하는 불일치가 생길 수 있습니다. 매물·아이템·지갑 변경과 같은 DB 트랜잭션 안에 Outbox 메시지를 함께 기록하고, 별도 워커가 재시도와 중복 방지를 포함해 전달하는 방식을 고려할 수 있습니다. 긴 트랜잭션의 성능 영향은 DB와 부하에 따라 측정해야 합니다.

C# 기반 거래 체결 및 수수료 정산 구현 예제

아래 코드는 판매 시점에 거래세만 계산합니다. 등록 수수료는 매물을 등록할 때 이미 별도로 징수했다고 가정하므로 판매자 정산액에서 다시 차감하지 않습니다. 관계형 DB와 EF Core 7 이상을 전제로 한 개념 예시이며, IGameDbContext, 엔티티, 분산 락 공급자, 결과 타입은 프로젝트 구현에 맞춰 제공해야 합니다. ExecuteUpdateAsync는 변경 추적기를 거치지 않고 즉시 실행되므로 여러 업데이트를 원자적으로 묶기 위해 명시적 DB 트랜잭션을 사용합니다. 이전 EF Core 버전에서는 같은 조건을 원자적으로 검사하는 DB별 UPDATE 또는 행 잠금으로 대체해야 합니다.

public class AuctionHouseService
{
    private readonly IDistributedLockProvider _lockProvider;
    private readonly IGameDbContext _dbContext;
    private readonly decimal _taxRate = 0.05m; // 5% 거래세

    public async Task<TradeResult> PurchaseListingAsync(long buyerId, long listingId)
    {
        // 1. 매물 ID 기준으로 분산 락 획득 (동시 구매 요청 방지)
        var lockKey = $"auction:listing:{listingId}";
        await using var handle = await _lockProvider.TryAcquireLockAsync(lockKey, TimeSpan.FromSeconds(3));
        if (handle == null)
        {
            return TradeResult.Fail("다른 유저가 거래를 진행 중입니다.");
        }

        // 2. DB 트랜잭션 시작 (ACID 보장)
        await using var tx = await _dbContext.Database.BeginTransactionAsync(IsolationLevel.ReadCommitted);
        try
        {
            // DB 행 잠금 또는 ACTIVE 조건부 갱신으로 단일 구매자만 매물을 선점해야 합니다.
            var listing = await _dbContext.AuctionListings
                .AsNoTracking()
                .FirstOrDefaultAsync(l => l.Id == listingId && l.Status == ListingStatus.Active);

            if (listing == null)
            {
                return TradeResult.Fail("이미 판매되었거나 취소된 매물입니다.");
            }

            if (listing.SellerId == buyerId)
            {
                return TradeResult.Fail("자신의 매물은 직접 구매할 수 없습니다.");
            }

            int claimed = await _dbContext.AuctionListings
                .Where(l => l.Id == listingId && l.Status == ListingStatus.Active)
                .ExecuteUpdateAsync(setters => setters
                    .SetProperty(l => l.Status, ListingStatus.Sold)
                    .SetProperty(l => l.SoldAt, DateTime.UtcNow));
            if (claimed != 1)
            {
                return TradeResult.Fail("다른 구매자가 먼저 매물을 처리했습니다.");
            }

            int debited = await _dbContext.UserWallets
                .Where(w => w.UserId == buyerId && w.Gold >= listing.Price)
                .ExecuteUpdateAsync(setters => setters
                    .SetProperty(w => w.Gold, w => w.Gold - listing.Price));
            if (debited != 1)
            {
                return TradeResult.Fail("지갑이 없거나 보유 골드가 부족합니다.");
            }

            // 아이템이 여전히 판매자 소유이며 거래 가능한 경우에만 소유권을 이전합니다.
            // 이 예시는 등록 시 아이템이 판매자 인벤토리에 남아 있고, 귀속 아이템은 거래할 수 없다는 모델을 가정합니다.
            int transferred = await _dbContext.InventoryItems
                .Where(i => i.Id == listing.ItemId &&
                            i.OwnerId == listing.SellerId &&
                            !i.IsBound)
                .ExecuteUpdateAsync(setters => setters
                    .SetProperty(i => i.OwnerId, buyerId)
                    .SetProperty(i => i.IsBound, true)
                    .SetProperty(i => i.TradeCount, i => i.TradeCount + 1));
            if (transferred != 1)
            {
                return TradeResult.Fail("아이템 소유권이 바뀌었거나 거래할 수 없습니다.");
            }

            // 4. 수수료 계산 및 소각 (Gold Sink)
            long fee = (long)Math.Ceiling(listing.Price * _taxRate);
            long sellerPayout = listing.Price - fee;

            // 5. 아이템 소유권 이전 및 거래 후 귀속(Bind) 처리
            var item = await _dbContext.InventoryItems
                .SingleAsync(i => i.Id == listing.ItemId);

            // 6. 판매자 정산 대기열(Outbox) 등록 (비동기 정산용)
            _dbContext.SettlementOutbox.Add(new SettlementTask
            {
                SellerId = listing.SellerId,
                PayoutGold = sellerPayout,
                FeeBurned = fee,
                ListingId = listing.Id
            });

            // 7. 경제 지표 분석용 소각 로그 기록
            _dbContext.EconomyLogs.Add(new GoldSinkLog
            {
                SinkType = SinkType.AuctionTax,
                Amount = fee,
                CreatedAt = DateTime.UtcNow
            });

            await _dbContext.SaveChangesAsync();
            await tx.CommitAsync();

            return TradeResult.Success(item, sellerPayout, fee);
        }
        catch (Exception ex)
        {
            await tx.RollbackAsync();
            // 로깅 및 장애 대응
            throw new TradeException("거래 처리 중 예외 발생", ex);
        }
    }
}

건강한 게임 경제를 위한 설계 체크리스트

마지막으로 프로젝트에 거래소를 도입하기 전, 기획서와 기술 명세서에서 점검해야 할 핵심 체크리스트입니다.

점검 항목	권장 설계 방안	미비 시 발생할 수 있는 리스크
등록비(보증금) 정책	프로젝트별 등록비와 환불 규칙을 시험	비용이 너무 낮거나 높을 때 창고 이용·등록 남용 또는 거래 위축 가능성
소각 수수료율	프로젝트별 기준값을 시험하고 고액 누진세 검토	발행과 소모의 불균형이 지속되면 인플레이션 압력이 커질 수 있음
시세 기준가 산정	VWAP 등 기준가와 변동 제한을 데이터로 평가	적은 표본이나 자전거래가 기준가를 왜곡할 수 있음
매물 재등록 쿨다운	프로젝트별 쿨다운을 시험	재판매 속도를 낮출 수 있지만 거래 편의도 줄일 수 있음
장비 유통 수명	거래 후 귀속 또는 재포장 횟수 제한을 검토	신규 공급이 수요를 웃돌면 가격 하락 압력이 커질 수 있음
서버 동시성 방어	DB 조건부 갱신·트랜잭션 등으로 중복 처리를 방지	동시 요청 처리에 결함이 있으면 중복 판매나 잔액 불일치가 발생할 수 있음

자주 묻는 질문 (FAQ)

Q1. 수수료율을 높이면 유저들이 1:1 직거래나 외부 음성 거래로 이탈하지 않나요?

수수료가 높아지면 일부 유저가 직거래나 외부 커뮤니티 거래로 이동할 수 있지만, 보편적인 심리적 저항선 하나로 단정하기는 어렵습니다. 거래 편의성과 안전성, 아이템 가치, 게임의 거래 관행을 함께 살펴 실험으로 확인해야 합니다.

거래소 이용의 편의성과 안전성을 개선하고, 직접 거래의 정책·수수료를 함께 검토할 수 있습니다.

거래소의 편의성 및 안전 가치 개선: 거래소에 에스크로 방식의 결제와 편리한 체결 절차를 제공하면 사기 위험을 낮추는 데 도움이 될 수 있습니다. 다만 실제 보호 수준은 구현과 운영에 달려 있습니다.
거래 채널 정책 검토: 1:1 개인 거래의 수수료나 거래 가능한 아이템 범위도 함께 검토할 수 있습니다. 거래 채널 제한은 이용자 편의와 정책 목적을 고려해 선택해야 합니다.

Q2. 상하한가 밴드를 적용하면 신규 아이템 출시 직후 가격 왜곡이나 거래 마비가 생기지 않나요?

신규 장비나 재료가 업데이트된 직후에는 누적 거래 데이터가 부족할 수 있습니다. 이때 기존 가격을 기준으로 좁은 밴드를 적용하면 매수 대기나 매물 적체가 생길 가능성이 있으므로, 출시 초기에는 별도 규칙을 검토할 수 있습니다.

신규 아이템이 추가된 직후에는 초기 가격 탐색 기간(Price Discovery Period)을 별도로 둘 수 있습니다. 출시 후 3~7일, ±50% 이상의 밴드, 체결 500건 같은 값은 테스트용 가정일 뿐 권장 표준이 아닙니다. 표본 수와 거래량을 살펴 밴드 폭과 갱신 주기를 조정하되, 이를 통해 적정가가 빠르게 형성된다고 보장할 수는 없습니다.

Q3. 거래소 알고리즘만으로 작업장의 골드 세탁이나 통정 거래를 100% 차단할 수 있나요?

VWAP, 거래 쿨다운, 상하한가 밴드 같은 제약은 일부 형태의 시세 교란 위험을 낮추는 데 도움이 될 수 있지만, 분산된 거래를 모두 탐지하거나 차단한다고 보장하지는 않습니다.

거래소 정책에 이상 거래 탐지와 운영 검토 절차를 추가하는 방안을 고려할 수 있습니다. 필요성과 구현 방식은 게임의 거래 구조와 운영 역량에 따라 정해야 합니다.

신규 계정이 생성 직후 고가 아이템을 특정 계정과 반복 거래하는 패턴
동일 IP 대역이나 디바이스에서 최저가/최고가 매물을 독점 매수하는 행위
정상 시세와 동떨어진 잡템 거래가 단시간에 집중되는 현상

위와 같은 신호는 게임의 정책과 오탐 대응 절차에 따라 추가 검토나 임시 거래 제한을 유발할 수 있습니다. 정산 보류나 제재는 근거와 이의 제기 절차를 마련한 뒤 적용하고, 운영팀의 검수를 거치도록 설계할 수 있습니다.

마치며: 경제 시스템은 ‘완벽한 통제’가 아닌 ‘완충재’다

게임 내 경제를 설계할 때 개발자가 가장 경계해야 할 태도는 “모든 거래를 완벽하게 틀어막아 통제하겠다”는 생각입니다.

너무 높은 수수료와 지나친 거래 제약은 거래량과 이용자 경험을 해칠 수 있습니다. 반대로 제한과 탐지가 부족한 시장은 작업장이나 시세 조작에 취약해질 수 있으므로, 게임별 거래 데이터와 이용자 경험을 바탕으로 균형을 조정해야 합니다.

결국 성공적인 거래소 시스템의 핵심은 “일반 유저의 거래 자유도는 최대한 존중하되 보이지 않는 곳에서 시스템이 꾸준히 재화를 태우고(Gold Sink), 이상 징후에는 부드럽게 브레이크를 걸어주는 완충 구조”를 만드는 것입니다. 철저한 데이터 시뮬레이션과 안전한 서버 트랜잭션 설계를 바탕으로 오랫동안 숨 쉬는 건강한 인게임 경제를 구축해 보시길 바랍니다.