해설 — 커맨드 재전송 시 서버측 중복 실행 방지(dedup) 부재

난이도: 상

요약

OnUseItemCommand(A)는 수신한 커맨드의 commandId 이력을 전혀 기억하지 않고 매번 새 요청처럼 실행한다. ACK(B)가 네트워크에서 유실되는 흔한 시나리오에서 서버는 이미 아이템을 정상 소모했는데도 클라이언트는 이를 모른 채 같은 commandId 로 재전송하고, 서버가 이를 구분 없이 다시 실행해 효과가 중복 적용된다. 서버가 IOCP/epoll 등으로 여러 워커 스레드가 수신 콜백을 처리하는 구조라면, 같은 commandId 를 가진 재전송이 거의 동시에 서로 다른 스레드에서 처리될 수도 있어 dedup 자료구조 자체의 스레드 안전성도 함께 고려해야 한다.

문제점

• 분류: 멱등성(idempotency) 부재 / 재전송에 대한 dedup 누락
• 증상: 소모성 아이템이 두 번 소모되거나 스킬 쿨다운·즉시 데미지가 중복 적용되는 등 "요청 1회 = 효과 1회" 원칙이 깨진다.
• 재현 조건: 클라이언트가 commandId=N 커맨드 전송 → 서버 정상 실행 후 ACK 응답 → ACK 유실 → 클라이언트가 타임아웃 후 같은 commandId=N 으로 재전송 → 서버가 (A)에서 새 요청으로 재실행.
• 근본 원인: 서버가 commandId 별 처리 이력을 저장하지 않는다. 재전송과 신규 요청을 구분할 정보(commandId)는 프로토콜에 이미 있는데 실행 로직이 이를 참조하지 않는다. 추가로, 여러 수신 스레드가 존재하는 서버 구조에서는 dedup 여부를 확인하고 등록하는 두 단계 사이에도 경쟁이 생길 수 있어, dedup 자료구조에 대한 접근 자체를 원자적으로 만들어야 한다.

수정안

플레이어별로 최근 처리한 commandId 를 스레드 안전하게 기억해두고, 확인과 등록을 하나의 원자적 연산으로 묶는다. 무한정 커지지 않도록 슬라이딩 윈도우(최근 K개)로 크기를 제한한다.

#include <cstdint>
#include <deque>
#include <mutex>
#include <unordered_map>
#include <unordered_set>

struct UseItemCommand
{
    int64_t  commandId;
    uint64_t playerId;
    int      itemId;
};

class Inventory
{
public:
    bool ConsumeItem(uint64_t playerId, int itemId) { return true; }
};

class AckSender
{
public:
    void SendAck(uint64_t playerId, int64_t commandId) { /* 전송 (구현 생략) */ }
};

// 플레이어별로 최근 처리한 commandId 를 제한된 크기로 기억하는 dedup 캐시.
class CommandDedupCache
{
public:
    // 이미 처리한 commandId 라면 false 를 반환한다(재실행 금지).
    // 처음 보는 commandId 라면 등록하고 true 를 반환한다(실행 허가).
    bool TryMarkProcessed(uint64_t playerId, int64_t commandId, size_t windowSize = 256)
    {
        std::lock_guard<std::mutex> lock(mutex_);

        auto& state = perPlayer_[playerId];
        if (state.seen.count(commandId) != 0)
            return false; // 이미 처리됨 — 재실행 금지

        state.order.push_back(commandId);
        state.seen.insert(commandId);

        // 슬라이딩 윈도우: 오래된 commandId 는 제거해 메모리를 제한한다.
        while (state.order.size() > windowSize)
        {
            state.seen.erase(state.order.front());
            state.order.pop_front();
        }
        return true;
    }

private:
    struct PerPlayerState
    {
        std::deque<int64_t>          order; // 삽입 순서 유지(만료 판단용)
        std::unordered_set<int64_t>  seen;
    };

    std::mutex mutex_;
    std::unordered_map<uint64_t, PerPlayerState> perPlayer_;
};

class CommandHandler
{
public:
    CommandHandler(Inventory* inventory, AckSender* ackSender, CommandDedupCache* dedup)
        : inventory_(inventory), ackSender_(ackSender), dedup_(dedup) {}

    // 여러 워커 스레드에서 동시에 호출될 수 있다.
    void OnUseItemCommand(const UseItemCommand& cmd)
    {
        // 확인과 등록을 하나의 원자적 호출로 묶어, 재전송이 동시에 도착해도
        // 정확히 하나의 호출만 실행 허가를 받는다.
        if (!dedup_->TryMarkProcessed(cmd.playerId, cmd.commandId))
        {
            ackSender_->SendAck(cmd.playerId, cmd.commandId); // 재전송에도 ACK는 응답
            return;
        }

        bool consumed = inventory_->ConsumeItem(cmd.playerId, cmd.itemId);
        if (consumed)
        {
            ApplyItemEffect(cmd.playerId, cmd.itemId);
        }

        ackSender_->SendAck(cmd.playerId, cmd.commandId);
    }

private:
    void ApplyItemEffect(uint64_t playerId, int itemId) { /* 구현 생략 */ }

    Inventory*         inventory_;
    AckSender*         ackSender_;
    CommandDedupCache* dedup_;
};

더 나은 설계

• 단조 증가 시퀀스 번호 기반 dedup: 클라이언트가 세션 단위로 단조 증가하는 시퀀스 번호를 커맨드 ID 로 쓰도록 프로토콜을 설계하면, 플레이어별로 "마지막으로 처리한 시퀀스 번호" 하나만 저장해도 그 이하의 재전송을 O(1)로 걸러낼 수 있다. 위 예시의 unordered_set 기반 윈도우보다 메모리 효율이 훨씬 좋지만, 클라이언트가 커맨드를 병렬로 여러 개 동시 전송(파이프라이닝)하는 구조라면 "마지막 처리 번호"만으로는 순서가 뒤섞인 재전송을 구분하기 어려워질 수 있어 별도의 작은 슬라이딩 윈도우와 병행해야 한다.
• 실행 결과 캐싱: 재실행을 막는 것에 그치지 않고 최초 실행 결과(성공/실패)까지 캐싱해두면, 재전송에 대해서도 최초와 동일한 결과를 클라이언트에 돌려줄 수 있다. 캐시 항목당 메모리 비용이 늘어나는 트레이드오프가 있다.
• 락 경합 최소화: 위 구현은 플레이어별 상태를 하나의 전역 뮤텍스로 보호한다. 동시 접속자가 많다면 플레이어 ID 해시 기반 샤딩된 뮤텍스(예: 256개 버킷)로 나눠 경합을 줄일 수 있다. 다만 구현 복잡도가 늘고, 버킷 수를 잘못 잡으면 오히려 캐시 라인 경합(false sharing)이 생길 수 있어 벤치마크로 검증해야 한다.
• 트레이드오프: 시퀀스 번호 방식이 메모리·성능 면에서 가장 우수하지만 프로토콜에 순서 보장이 필요하다. 순서 없는 UDP 기반 커맨드 채널이라면 윈도우 기반 집합 방식이 더 현실적이다.

면접 포인트

• ACK 기반 재전송 프로토콜에서 클라이언트는 "요청 유실"과 "응답 유실"을 구분할 수 없다는 전제를 항상 깔아야 하며, 따라서 서버가 재전송에 대해 멱등하게 동작할 책임을 진다.
• 멱등성 보장의 표준 패턴은 "요청 식별자를 서버가 기억했다가 동일 식별자 재수신 시 재실행 대신 이전 결과를 반환"하는 것이며, 이 dedup 자료구조 자체도 멀티스레드 환경에서는 확인+등록을 원자적으로 묶어야 한다는 점(TOCTOU) 을 짚을 수 있어야 한다.
• dedup 캐시는 무한정 커지면 안 되므로 슬라이딩 윈도우/시퀀스 번호 기반으로 메모리를 제한하는 설계까지 고려해야 하며, "정확성"과 "리소스 유한성"의 절충을 설명할 수 있어야 한다.