C++ mutable Keyword | 'mutable 키워드' 가이드

mutable이란?

mutable 키워드는 const 멤버 함수에서도 수정 가능한 멤버 변수를 선언할 때 사용합니다.

class Cache {
    mutable int accessCount = 0;
    
public:
    int getData() const {
        accessCount++;  // OK: mutable
        return 42;
    }
};

왜 필요한가?:

• 캐싱: const 함수에서 캐시 업데이트
• 통계 수집: 읽기 함수에서 카운터 증가
• 동기화: const 함수에서 뮤텍스 잠금
• 지연 초기화: const 함수에서 리소스 초기화

// ❌ mutable 없이: 에러
class Counter {
    int count = 0;
    
public:
    void increment() const {
        count++;  // 에러: const 함수에서 수정 불가
    }
};

// ✅ mutable 사용: OK
class Counter {
    mutable int count = 0;
    
public:
    void increment() const {
        count++;  // OK: mutable
    }
};

mutable의 동작 원리:

class Example {
    int normal;
    mutable int mutableVar;
    
public:
    void constFunc() const {
        // normal = 10;     // 에러: const 함수
        mutableVar = 10;    // OK: mutable
    }
};

// 내부 동작 (개념적)
// const 함수는 this 포인터가 const Example*
// mutable 멤버는 const 제약에서 제외됨

논리적 const vs 물리적 const:

개념	설명	예시
물리적 const	메모리 상태 변경 불가	const int x = 10;
논리적 const	외부에서 보이는 상태 불변	캐싱, 통계 수집

class Cache {
    mutable bool cached = false;
    mutable double cachedValue = 0.0;
    
public:
    // 논리적으로는 const (외부에서 보이는 상태 불변)
    // 물리적으로는 non-const (캐시 업데이트)
    double getValue() const {
        if (!cached) {
            cachedValue = expensiveComputation();
            cached = true;
        }
        return cachedValue;
    }
};

const 멤버 함수에서의 mutable

const 멤버 함수 안에서는 this가 const T*로 고정되므로, 일반 데이터 멤버는 읽기 전용처럼 취급됩니다. 그런데 관측 가능한 동작(observable behavior)은 그대로인데 구현만 바꾸고 싶은 경우가 있습니다. 대표적으로 캐시·계측·동기화 객체입니다. 이때 해당 멤버만 mutable로 표시해 “논리적 constness는 유지하고, 구현 세부만 갱신한다”고 컴파일러와 독자에게 알립니다.

• 바깥 계약: const 메서드는 “객체의 추상적 상태를 바꾸지 않는다”는 뜻에 가깝습니다.
• 안쪽 구현: 캐시나 락은 그 계약을 깨지 않으면서도 비트는 바뀔 수 있습니다.

반대로 mutable로 “실제 의미 있는 데이터”까지 const 안에서 바꾸기 시작하면 const가 무의미해지므로 설계가 흐트러집니다.

캐싱 패턴 심화

읽기 연산이 반복될 때 같은 입력에 대해 같은 결과를 보장한다면, 내부에 지연 계산 + 무효화를 둘 수 있습니다.

• 키: 입력이 바뀌면 캐시 비트를 끈다 (valid = false 등).
• 스레드: 읽기만 const로 노출하고 캐시를 mutable로 두되, 다중 스레드면 캐시 필드 접근도 뮤텍스나 원자 변수로 보호해야 합니다. mutable은 스레드 안전을 보장하지 않습니다.

class Stats {
    mutable std::mutex m_;
    mutable bool cacheValid_{false};
    mutable double cache_{};
    double input_{};

public:
    void setInput(double x) { input_ = x; cacheValid_ = false; }

    double meanExpensive() const {
        std::lock_guard<std::mutex> lk(m_);
        if (!cacheValid_) {
            cache_ = input_ * 2;  // 실제로는 무거운 계산
            cacheValid_ = true;
        }
        return cache_;
    }
};

뮤텍스와 mutable

std::mutex, std::shared_mutex 등은 잠그는 행위 자체가 객체 상태를 바꿉니다. 그런데 const 메서드에서도 “상태를 읽되, 동시 접근만 막고 싶다”는 요구는 흔합니다. 그래서 뮤텍스 멤버는 거의 항상 mutable입니다.

• lock()/unlock()이 const 메서드에서 호출 가능해야 하므로, 뮤텍스가 mutable이 아니면 설계가 꼬입니다.
• 읽기/쓰기 잠금을 나눌 때는 std::shared_mutex + shared_lock/unique_lock 패턴과 함께 쓰입니다.

class Registry {
    mutable std::shared_mutex rw_;
    std::map<std::string, int> data_;

public:
    int get(const std::string& k) const {
        std::shared_lock<std::shared_mutex> lk(rw_);
        auto it = data_.find(k);
        return it == data_.end() ? 0 : it->second;
    }
    void set(std::string k, int v) {
        std::unique_lock<std::shared_mutex> lk(rw_);
        data_[std::move(k)] = v;
    }
};

언제 사용해야 하나

적합한 경우:

• 논리적 불변을 유지한 채, 프로파일링·캐시·지연 초기화만 필요할 때.
• const 인터페이스를 넓게 유지하고 싶을 때 (예: const 객체에 대해서도 size()가 캐시를 채움).
• 동기화 프리미티브처럼 “계약과 무관한” 내부 도구를 둘 때.

다른 선택을 먼저 고려할 경우:

• 진짜 상태 변경이면 mutable 대신 non-const 메서드로 올리는 편이 명확합니다.
• 스레드 공유가 복잡하면 std::atomic, 외부 동기화, 또는 값 의미론으로 경쟁을 없애는 설계가 나을 수 있습니다.

남용 주의

• mutable로 “비즈니스 데이터”를 const API 안에서 숨겨 바꾸기 → 호출자가 const 참조로 안전하다고 믿기 어렵습니다.
• 동일한 const 메서드가 여러 스레드에서 캐시를 갱신하는데 락이 없음 → 데이터 경쟁.
• 과도한 mutable는 “이 객체는 사실상 항상 변한다”는 신호이므로, API를 const가 아닌 메서드로 재구성하는 편이 낫습니다.

사용 이유

// const 함수에서 멤버 수정 필요
class Logger {
    mutable std::mutex mtx;
    
public:
    void log(const std::string& msg) const {
        std::lock_guard<std::mutex> lock(mtx);  // OK
        // ...
    }
};

실전 예시

예시 1: 캐싱

class ExpensiveCalculation {
    mutable bool cached = false;
    mutable double cachedValue = 0.0;
    
public:
    double calculate() const {
        if (!cached) {
            // 복잡한 계산
            cachedValue = /* ....*/;
            cached = true;
        }
        return cachedValue;
    }
};

예시 2: 통계 수집

class DataProcessor {
    mutable size_t readCount = 0;
    mutable size_t writeCount = 0;
    std::vector<int> data;
    
public:
    int get(size_t index) const {
        readCount++;  // OK: mutable
        return data[index];
    }
    
    void set(size_t index, int value) {
        writeCount++;
        data[index] = value;
    }
    
    size_t getReadCount() const {
        return readCount;
    }
};

예시 3: 지연 초기화

class Database {
    mutable std::unique_ptr<Connection> conn;
    
public:
    Connection* getConnection() const {
        if (!conn) {
            conn = std::make_unique<Connection>();
        }
        return conn.get();
    }
};

예시 4: 멀티스레딩

#include <mutex>

class ThreadSafeCounter {
    mutable std::mutex mtx;
    int count = 0;
    
public:
    void increment() {
        std::lock_guard<std::mutex> lock(mtx);
        count++;
    }
    
    int get() const {
        std::lock_guard<std::mutex> lock(mtx);  // OK: mutable
        return count;
    }
};

자주 발생하는 문제

문제 1: 남용

// ❌ 논리적 const 위반
class BadClass {
    mutable int value;
    
public:
    void setValue(int v) const {
        value = v;  // const 의미 상실
    }
};

// ✅ 올바른 사용
class GoodClass {
    mutable int cacheHits;
    
public:
    int getData() const {
        cacheHits++;  // 통계만 수정
        return 42;
    }
};

문제 2: 스레드 안전성

// ❌ 경쟁 조건
class Counter {
    mutable int count = 0;
    
public:
    void increment() const {
        count++;  // 스레드 안전하지 않음
    }
};

// ✅ 뮤텍스 사용
class Counter {
    mutable std::mutex mtx;
    mutable int count = 0;
    
public:
    void increment() const {
        std::lock_guard<std::mutex> lock(mtx);
        count++;
    }
};

문제 3: 캐시 무효화

class Cache {
    mutable bool valid = false;
    mutable int cachedValue;
    
public:
    void invalidate() {
        valid = false;  // 비const 함수
    }
    
    int getValue() const {
        if (!valid) {
            cachedValue = compute();
            valid = true;
        }
        return cachedValue;
    }
};

문제 4: const 포인터

class MyClass {
    mutable int* ptr;
    
public:
    void modify() const {
        ptr = new int(10);  // OK: 포인터 수정
        *ptr = 20;          // OK: 가리키는 값 수정
    }
};

사용 가이드라인

C/C++ 예제 코드입니다.

// ✅ 적절한 사용
// 1. 캐싱
mutable bool cached;
mutable double cachedValue;

// 2. 통계/로깅
mutable size_t accessCount;

// 3. 동기화
mutable std::mutex mtx;

// 4. 지연 초기화
mutable std::unique_ptr<Resource> resource;

// ❌ 부적절한 사용
// 논리적 const 위반
mutable int importantData;

실무 패턴

패턴 1: 지연 계산 캐시

class Matrix {
    std::vector<std::vector<double>> data_;
    mutable bool determinantCached_ = false;
    mutable double cachedDeterminant_ = 0.0;
    
public:
    Matrix(std::vector<std::vector<double>> data) : data_(std::move(data)) {}
    
    double determinant() const {
        if (!determinantCached_) {
            cachedDeterminant_ = computeDeterminant();
            determinantCached_ = true;
        }
        return cachedDeterminant_;
    }
    
    void modify(size_t i, size_t j, double value) {
        data_[i][j] = value;
        determinantCached_ = false;  // 캐시 무효화
    }
    
private:
    double computeDeterminant() const {
        // 복잡한 계산
        return 1.0;
    }
};

패턴 2: 스레드 안전 접근

#include <mutex>
#include <shared_mutex>

class ThreadSafeData {
    mutable std::shared_mutex mtx_;
    std::map<std::string, int> data_;
    
public:
    int get(const std::string& key) const {
        std::shared_lock lock(mtx_);  // 읽기 잠금
        auto it = data_.find(key);
        return it != data_.end() ? it->second : 0;
    }
    
    void set(const std::string& key, int value) {
        std::unique_lock lock(mtx_);  // 쓰기 잠금
        data_[key] = value;
    }
};

패턴 3: 디버깅 정보

class Logger {
    mutable size_t logCount_ = 0;
    mutable std::chrono::steady_clock::time_point lastLog_;
    
public:
    void log(const std::string& message) const {
        logCount_++;
        lastLog_ = std::chrono::steady_clock::now();
        
        std::cout << "[" << logCount_ << "] " << message << '\n';
    }
    
    size_t getLogCount() const {
        return logCount_;
    }
};

FAQ

Q1: mutable은 언제 사용하나요?

A:

• 캐싱: const 함수에서 캐시 업데이트
• 통계 수집: 읽기 함수에서 카운터 증가
• 뮤텍스: const 함수에서 동기화
• 지연 초기화: const 함수에서 리소스 초기화

class Cache {
    mutable bool cached_ = false;
    mutable double cachedValue_ = 0.0;
    
public:
    double getValue() const {
        if (!cached_) {
            cachedValue_ = compute();
            cached_ = true;
        }
        return cachedValue_;
    }
};

Q2: const 위반이 아닌가요?

A: 논리적 const는 유지됩니다. 외부에서 보이는 상태는 변하지 않고, 구현 세부사항만 수정합니다.

// 논리적 const: 외부에서 보이는 상태 불변
class Cache {
    mutable int accessCount = 0;  // 통계 (내부 상태)
    
public:
    int getData() const {
        accessCount++;  // 외부에 영향 없음
        return 42;
    }
};

Q3: 스레드 안전한가요?

A: mutable 자체는 스레드 안전하지 않습니다. 뮤텍스를 함께 사용해야 합니다.

class ThreadSafe {
    mutable std::mutex mtx_;
    mutable int count_ = 0;
    
public:
    void increment() const {
        std::lock_guard lock(mtx_);
        count_++;  // 스레드 안전
    }
};

Q4: 성능 영향은?

A: 없습니다. mutable은 컴파일 타임 키워드로, 런타임 비용이 없습니다.

// mutable 유무는 성능에 영향 없음
int count_;          // 일반 멤버
mutable int count_;  // mutable 멤버

Q5: 남용 위험은?

A: const의 의미가 상실될 수 있습니다. 신중히 사용해야 합니다.

// ❌ 남용: 논리적 const 위반
class Bad {
    mutable int value_;
    
public:
    void setValue(int v) const {
        value_ = v;  // const 의미 상실
    }
};

// ✅ 적절한 사용: 통계만 수정
class Good {
    mutable int accessCount_;
    int value_;
    
public:
    int getValue() const {
        accessCount_++;  // 통계만 수정
        return value_;
    }
};

Q6: 람다에서도 사용할 수 있나요?

A: 가능합니다. 람다의 operator()를 non-const로 만듭니다.

C/C++ 예제 코드입니다.

int x = 0;
auto lambda = [x]() mutable {
    x++;  // OK: mutable
    return x;
};

lambda();  // 1
lambda();  // 2

Q7: mutable과 const_cast의 차이는?

A:

• mutable: 컴파일 타임에 const 제약 해제
• const_cast: 런타임에 const 제거 (위험)

class Example {
    mutable int x_;
    
public:
    void func() const {
        x_ = 10;  // OK: mutable
        
        // const_cast (위험)
        const_cast<Example*>(this)->x_ = 10;
    }
};

Q8: mutable 학습 리소스는?

A:

• “Effective C++” by Scott Meyers (Item 3)
• “C++ Concurrency in Action” by Anthony Williams
• cppreference.com - mutable

관련 글: const, mutex, lambda.

한 줄 요약: mutable은 const 멤버 함수에서도 수정 가능한 멤버 변수를 선언하는 키워드입니다.

---

같이 보면 좋은 글 (내부 링크)

이 주제와 연결되는 다른 글입니다.

• C++ const 완벽 가이드 | “const 정확성” 실전 활용
• C++ static 멤버 | “Static Members” 가이드
• C++ this Pointer | “this 포인터” 가이드

관련 글

• C++ const 완벽 가이드 |
• C++ const 에러 |
• C++ Initialization Order 완벽 가이드 | 초기화 순서의 모든 것
• C++ 람다 기초 완벽 가이드 | 캡처·mutable·제네릭 람다와 실전 패턴
• C++ 람다 표현식 | [=]·[&] 캡처와 sort·find_if에서 람다 활용법

심화 부록: 구현·운영 관점

이 부록은 앞선 본문에서 다룬 주제(「C++ mutable Keyword | ‘mutable 키워드’ 가이드」)를 구현·런타임·운영 관점에서 다시 압축합니다. 도메인별 세부 구현은 글마다 다르지만, 입력 검증 → 핵심 연산 → 부작용(I/O·네트워크·동시성) → 관측의 흐름으로 장애를 나누면 원인 추적이 빨라집니다.

내부 동작과 핵심 메커니즘

flowchart TD
  A[입력·요청·이벤트] --> B[파싱·검증·디코딩]
  B --> C[핵심 연산·상태 전이]
  C --> D[부작용: I/O·네트워크·동시성]
  D --> E[결과·관측·저장]

sequenceDiagram
  participant C as 클라이언트/호출자
  participant B as 경계(런타임·게이트웨이·프로세스)
  participant D as 의존성(API·DB·큐·파일)
  C->>B: 요청/이벤트
  B->>D: 조회·쓰기·RPC
  D-->>B: 지연·부분 실패·재시도 가능
  B-->>C: 응답 또는 오류(코드·상관 ID)

• 불변 조건(Invariant): 버퍼 경계, 프로토콜 상태, 트랜잭션 격리, FD 상한 등 단계별로 문장으로 적어 두면 디버깅 비용이 줄어듭니다.
• 결정성: 순수 층과 시간·네트워크·스케줄에 의존하는 층을 분리해야 테스트와 장애 분석이 쉬워집니다.
• 경계 비용: 직렬화, 인코딩, syscall 횟수, 락 경합, 할당·GC, 캐시 미스를 의심 목록에 둡니다.
• 백프레셔: 생산자가 소비자보다 빠를 때 버퍼·큐·스트림에서 속도를 줄이는 신호를 어디에 둘지 정의합니다.

프로덕션 운영 패턴

영역	운영 관점 질문
관측성	요청 단위 상관 ID, 에러율·지연 p95/p99, 의존성 타임아웃·재시도가 대시보드에 보이는가
안전성	입력 검증·권한·비밀·감사 로그가 코드 경로마다 일관적인가
신뢰성	재시도는 멱등 연산에만 적용되는가, 서킷 브레이커·백오프·DLQ가 있는가
성능	캐시·배치 크기·커넥션 풀·인덱스·백프레셔가 데이터 규모에 맞는가
배포	롤백 룬북, 카나리/블루그린, 마이그레이션·피처 플래그가 문서화되어 있는가
용량	피크 트래픽·디스크·FD·스레드 풀 상한을 주기적으로 검증하는가

스테이징은 데이터 양·네트워크 RTT·동시성을 프로덕션에 가깝게 맞출수록 재현율이 올라갑니다.

확장 예시: 엔드투엔드 미니 시나리오

앞선 본문 주제(「C++ mutable Keyword | ‘mutable 키워드’ 가이드」)를 배포·운영 흐름에 맞춰 옮긴 체크리스트입니다. 도메인에 맞게 단계 이름만 바꿔 적용할 수 있습니다.

1. 입력 계약 고정: 스키마·버전·최대 페이로드·타임아웃·에러 코드를 경계에 둔다.
2. 핵심 경로 계측: 요청 ID, 단계별 지연, 외부 호출 결과 코드를 로그·메트릭·트레이스에서 한 흐름으로 본다.
3. 실패 주입: 의존성 타임아웃·5xx·부분 데이터·락 대기를 스테이징에서 재현한다.
4. 호환·롤백: 설정/마이그레이션/클라이언트 버전을 되돌릴 수 있는지 확인한다.
5. 부하 후 검증: 피크 대비 p95/p99, 에러율, 리소스 상한, 알림 임계값을 점검한다.

handle(request):
  ctx = newCorrelationId()
  validated = validateSchema(request)
  authorize(validated, ctx)
  result = domainCore(validated)
  persistOrEmit(result, idempotentKey)
  recordMetrics(ctx, latency, outcome)
  return result

문제 해결(Troubleshooting)

증상	가능 원인	조치
간헐적 실패	레이스, 타임아웃, 외부 의존성, DNS	최소 재현 스크립트, 분산 트레이스·로그 상관관계, 재시도·서킷 설정 점검
성능 저하	N+1, 동기 I/O, 락 경합, 과도한 직렬화, 캐시 미스	프로파일러·APM으로 핫스팟 확인 후 한 가지씩 제거
메모리 증가	캐시 무제한, 구독/리스너 누수, 대용량 버퍼, 커넥션 미반납	상한·TTL·힙/FD 스냅샷 비교
빌드·배포만 실패	환경 변수, 권한, 플랫폼 차이, lockfile	CI 로그와 로컬 diff, 런타임·이미지 버전 핀
설정 불일치	프로필·시크릿·기본값, 리전	스키마 검증된 설정 단일 소스와 배포 매트릭스 표준화
데이터 불일치	비멱등 재시도, 부분 쓰기, 캐시 무효화 누락	멱등 키·아웃박스·트랜잭션 경계 재검토

권장 순서: (1) 최소 재현 (2) 최근 변경 범위 축소 (3) 환경·의존성 차이 (4) 관측으로 가설 검증 (5) 수정 후 회귀·부하 테스트.

배포 전에는 git add → git commit → git push 후 npm run deploy 순서를 권장합니다.

---

이 글에서 다루는 키워드 (관련 검색어)

C++, mutable, const, keyword, member 등으로 검색하시면 이 글이 도움이 됩니다.