해설 — 장비 내구도 소모·파괴 처리의 원자성 (C++)

난이도: 상

요약

getEquipped 만 뮤텍스로 보호하고, 반환된 원시 포인터를 락 밖에서 읽고 쓴다. C# 버전과 달리 C++ 에서는 갱신 유실·중복 지급에 더해 비원자 접근에 의한 데이터 레이스(UB) 와, 파괴 경로에서 맵의 unique_ptr 을 지운 뒤 그 포인터를 계속 쓰는 use-after-free 까지 겹친다.

문제점

1) 반환된 원시 포인터의 무보호 접근 — (A) [데이터 레이스/UB]

• 증상: 디버그 빌드에서는 재현이 잘 안 되다가 최적화 빌드에서 내구도가 튀거나 파괴가 누락된다. ThreadSanitizer 를 켜면 durability, destroyed 에 대한 레이스가 즉시 잡힌다.
• 재현 조건: 두 워커가 같은 EquipmentItem* 에 동시에 진입.
• 근본 원인: mutex_ 는 equipped_ 조회만 보호한다. durability 는 비원자 int, destroyed 는 비원자 bool 이며 동시 읽기/쓰기가 일어난다. C++ 메모리 모델에서 이는 정의되지 않은 동작이라 "값이 하나 틀리는" 수준이 아니라 컴파일러가 조건 검사를 재배치·제거할 수도 있다.

2) 갱신 유실과 파괴 중복 지급 — (A)+(B) [check-then-act]

• 증상: 파편 보상 중복 지급(아이템 증식), 내구도 소모량 누락.
• 재현 조건: 내구도 5에 두 워커가 각각 5를 소모 → 둘 다 destroyed == false 통과.
• 근본 원인: 검사와 갱신이 하나의 원자 단위가 아니다. 승자 판정 수단이 없다.

3) 컨테이너에서 지운 뒤의 포인터 사용 — (B) [수명/use-after-free]

• 증상: 간헐적 크래시, 혹은 해제된 메모리에서 읽은 쓰레기 itemId 로 알림 전송.
• 재현 조건: eraseEquipped 가 unique_ptr 을 파괴한 직후 notify(ownerId, item->itemId) 가 같은 item 을 역참조한다. 단일 스레드에서도 100% 재현되는 결함이다.
• 근본 원인: 소유권이 unordered_map 의 unique_ptr 에 있는데 호출 측은 소유권 없는 원시 포인터를 들고 있다. 소유자가 사라지는 시점과 사용 시점의 관계가 코드로 표현되어 있지 않다. 동시 시나리오에서는 다른 스레드가 먼저 erase 하면 (A) 지점의 접근도 UAF 가 된다.

4) erase 와 부수효과의 순서 — (B) [정합성]

• 인벤토리 제거·파편 지급이 먼저 일어나고 equipped_ 제거가 나중이라, 그 사이 다른 요청이 이미 파괴된 장비를 여전히 착용 중으로 관측한다.

수정안

소유권을 shared_ptr 로 바꿔 사용 중 수명을 보장하고, 상태 전이는 아이템 자체의 뮤텍스로 원자화하며, 파괴 승자만 부수효과를 수행한다.

struct EquipmentItem {
    std::mutex m;                     // 이 아이템의 가변 상태를 보호
    std::int64_t itemId = 0;
    int durability = 0;
    bool destroyed = false;
    int shardReward = 3;
};

class DurabilityService {
public:
    void consumeDurability(std::int64_t ownerId, int slot, int amount) {
        std::shared_ptr<EquipmentItem> item = getEquipped(ownerId, slot);  // 수명 연장
        if (!item) return;

        bool iDestroyedIt = false;
        std::int64_t itemId = 0;
        int shards = 0;
        {
            std::lock_guard<std::mutex> lk(item->m);
            if (item->destroyed) return;
            item->durability = std::max(0, item->durability - amount);
            if (item->durability > 0) return;
            item->destroyed = true;        // 승자는 단 하나
            iDestroyedIt = true;
            itemId = item->itemId;         // 락 안에서 필요한 값 복사
            shards = item->shardReward;
        }

        if (!iDestroyedIt) return;
        eraseEquipped(ownerId, slot);      // 맵에서 제거 (shared_ptr 이므로 item 은 아직 유효)
        inventory_.remove(ownerId, itemId);
        inventory_.addShards(ownerId, shards);
        notify(ownerId, itemId);           // 해제된 메모리 역참조 없음
    }

private:
    std::shared_ptr<EquipmentItem> getEquipped(std::int64_t ownerId, int slot) {
        std::lock_guard<std::mutex> lk(mutex_);
        auto it = equipped_.find(ownerId * 100 + slot);
        return it == equipped_.end() ? nullptr : it->second;   // 복사 → refcount 증가
    }

    std::mutex mutex_;
    std::unordered_map<std::int64_t, std::shared_ptr<EquipmentItem>> equipped_;
    InventoryService inventory_;
};

핵심 포인트 세 가지: (i) 부수효과에 쓸 값(itemId, shards)을 락 안에서 지역 변수로 복사해 락 밖 역참조를 없앤다. (ii) shared_ptr 복사본이 살아 있으므로 다른 스레드가 맵에서 지워도 UAF 가 나지 않는다. (iii) 부수효과는 iDestroyedIt 인 스레드만 수행한다.

락 없이 가고 싶다면 내구도를 std::atomic<int> 로 두고 CAS 루프로 승자를 판정한다.

int prev = dur.load(std::memory_order_relaxed), next;
do {
    if (prev == 0) return;                       // 이미 파괴
    next = std::max(0, prev - amount);
} while (!dur.compare_exchange_weak(prev, next,
             std::memory_order_acq_rel, std::memory_order_relaxed));
if (next == 0) { /* prev>0 && next==0 인 스레드가 유일한 승자 */ }

더 나은 설계

• 소유권을 타입으로 표현: 조회 API 가 원시 포인터 대신 shared_ptr 이나 (index, generation) 핸들을 반환하면 UAF 가 구조적으로 차단된다. 트레이드오프 — refcount 원자 연산 비용, 핸들 방식은 resolve 단계 추가.
• 엔티티 단위 커맨드 큐(액터): 캐릭터별 단일 스레드 처리로 락 자체를 제거. 트레이드오프 — 교차 엔티티 연산에 별도 조정 필요, 큐 지연.
• 파괴를 지연 회수(deferred destroy) 로: 틱 경계에서만 실제 파괴/제거를 수행하면 사용 중 파괴가 원천 봉쇄된다. 트레이드오프 — 한 틱 동안 좀비 상태가 관측될 수 있어 조회 측 필터 필요.

면접 포인트

1. "컨테이너를 락으로 보호했다"와 "컨테이너가 담은 객체를 락으로 보호했다"의 차이. 원시 포인터를 반환하는 순간 락의 보호 범위가 끝난다는 점.
2. 락 안에서 필요한 값을 복사해 나오는 패턴(copy-out)이 락 보유 시간 단축과 UAF 방지를 동시에 달성하는 이유.
3. C# 이었다면 GC 덕분에 UAF 는 없고 논리적 중복 지급만 발생한다. 같은 결함이 언어에 따라 "데이터 손상"과 "메모리 안전성 붕괴"로 갈리는 이유를 설명할 수 있는가.