C++ mutable: const 멤버 함수에서 캐시·카운터·mutex를 수정하는 경우와 남용 주의
이 글의 핵심
mutable은 비트 단위 const 대신 논리적 const를 지키기 위한 도구입니다. const 함수에서 캐시를 갱신하면 여러 스레드가 동시에 호출할 때 데이터 레이스가 생길 수 있어 mutable mutex를 함께 두는 패턴이 필요하고, 캐시 무효화 시점을 놓치면 오래된 값을 돌려준다는 점도 짚습니다.
mutable이란?
mutable 키워드는 const 멤버 함수에서도 수정 가능한 멤버 변수를 선언할 때 사용합니다.
class Cache {
mutable int accessCount = 0;
public:
int getData() const {
accessCount++; // OK: mutable
return 42;
}
};읽기 전용 함수라도 내부적으로는 무언가를 바꿔야 하는 경우가 있습니다. 비싼 계산 결과를 캐시에 저장하거나, 호출 횟수를 세거나, 동시 접근을 막으려고 뮤텍스를 잠그거나, 처음 호출될 때 리소스를 만드는 경우입니다. mutable이 없으면 이런 멤버 때문에 함수 전체를 non-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
}
};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 멤버 함수 안에서 this의 타입이 const Example*가 되면, this->normal로 접근하는 모든 멤버의 타입에 const가 붙습니다. mutable은 이 규칙에서 특정 멤버만 빼 달라고 컴파일러에 알리는 지정자입니다. 그래서 적용 대상에도 제약이 있습니다. static 멤버(객체에 속하지 않음), 참조 멤버, 그리고 자기 자신이 const로 선언된 멤버(mutable const int x;)에는 붙일 수 없어 컴파일 에러가 납니다. mutable은 const 객체에도 적용되므로, const Cache c; c.getData();처럼 const로 선언한 객체의 mutable 멤버를 바꾸는 것도 정의된 동작입니다. 반면 mutable이 아닌 멤버를 const_cast로 억지로 바꾸는 것은 원래 const 객체였다면 미정의 동작입니다.
여기서 구분해야 할 것이 물리적(비트 단위) const와 논리적 const입니다. 물리적 const는 객체의 메모리가 한 비트도 바뀌지 않는다는 뜻이고, 논리적 const는 외부에서 관측할 수 있는 상태가 바뀌지 않는다는 뜻입니다. 아래 캐시는 메모리는 바뀌지만 getValue()가 돌려주는 값은 언제 호출해도 같으므로 논리적으로는 const입니다. C++ 컴파일러가 검사하는 것은 물리적 const이고, mutable은 그 검사에서 특정 멤버를 빼서 논리적 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_;
}
};이 예제에는 쉽게 놓치는 레이스가 하나 있습니다. 읽기 쪽 meanExpensive()는 락을 잡지만 setInput()은 락 없이 input_과 cacheValid_를 씁니다. 한 스레드가 setInput을 호출하는 동안 다른 스레드가 meanExpensive를 부르면 락이 한쪽에만 있으므로 보호가 되지 않습니다. 락은 같은 데이터를 건드리는 모든 경로가 함께 잡아야 의미가 있으므로, setInput에도 std::lock_guard<std::mutex> lk(m_);를 넣어야 올바릅니다.
C++ 표준 라이브러리는 “const 멤버 함수는 여러 스레드에서 동시에 호출해도 안전하다”는 가정을 깔고 설계되어 있습니다. 예를 들어 여러 스레드가 같은 std::vector의 size()나 operator[] const를 동시에 호출하는 것은 레이스가 아닙니다. 사용자 타입이 const 함수 안에서 mutable 캐시를 락 없이 갱신하면, 이 타입을 const&로 여러 스레드에 넘긴 사용자는 안전하다고 믿다가 데이터 레이스를 만나게 됩니다. 그래서 mutable 캐시를 둔 순간, 그 const 함수를 스레드 안전하게 만들 책임도 함께 생긴다고 보는 것이 좋습니다.
뮤텍스와 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;
}
};뮤텍스를 멤버로 두면 따라오는 부작용도 알아 두어야 합니다. std::mutex는 복사도 이동도 할 수 없으므로, 뮤텍스 멤버를 가진 클래스는 컴파일러가 복사 생성자와 이동 생성자를 자동으로 만들지 못해 use of deleted function 에러가 납니다. std::vector<Registry>에 넣거나 값으로 반환하려다 이 에러를 처음 보는 경우가 많습니다. 복사가 필요하다면 복사 생성자를 직접 작성해 원본의 락을 잡은 상태에서 데이터만 복사하고 뮤텍스는 새로 만드는 식으로 구현해야 합니다.
언제 사용해야 하나
mutable이 잘 맞는 경우는 객체의 논리적 상태는 그대로 두고 프로파일링 카운터, 캐시, 지연 초기화 같은 구현 세부만 갱신할 때입니다. const 객체에 대해서도 비싼 계산 결과를 캐시해 두고 싶을 때, 그리고 뮤텍스처럼 객체의 계약과 무관한 동기화 도구를 둘 때도 여기에 해당합니다.
반대로 정말로 의미 있는 상태가 바뀐다면 mutable로 숨기지 말고 non-const 메서드로 만드는 편이 명확합니다. 스레드 공유가 복잡해진다면 std::atomic, 호출자 쪽의 외부 동기화, 또는 값을 복사해 넘기는 설계로 경쟁 자체를 없애는 방법이 나을 수 있습니다.
남용 주의
mutable로 비즈니스 데이터를 const API 안에서 몰래 바꾸면, 호출자는 const 참조로 넘긴 객체가 바뀌지 않는다고 믿을 수 없게 됩니다. 같은 const 메서드가 여러 스레드에서 캐시를 락 없이 갱신하는 것도 데이터 레이스입니다. 그리고 클래스의 멤버 대부분에 mutable이 붙어 있다면 그 객체는 사실상 항상 변한다는 신호이므로, 해당 메서드들을 const가 아닌 메서드로 재구성하는 편이 낫습니다.
// 논리적 const 위반: 호출자가 보는 값이 바뀜
class BadClass {
mutable int value;
public:
void setValue(int v) const {
value = v; // const 의미 상실
}
};
// 외부에서 관측되는 값은 그대로, 통계만 수정
class GoodClass {
mutable int cacheHits = 0;
int value_ = 42;
public:
int getData() const {
cacheHits++;
return value_;
}
};실전 예시
통계 수집
class DataProcessor {
mutable size_t readCount = 0;
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++; // non-const 함수이므로 mutable 불필요
data[index] = value;
}
size_t getReadCount() const {
return readCount;
}
};writeCount는 non-const 함수에서만 바뀌므로 mutable이 필요 없습니다. mutable은 const 함수 안에서 바뀌어야 하는 멤버에만 붙이는 것이 의도를 정확히 드러냅니다. 이 카운터도 여러 스레드가 get()을 동시에 부른다면 std::atomic<size_t>로 바꿔야 합니다.
지연 초기화
class Database {
mutable std::unique_ptr<Connection> conn;
public:
Connection* getConnection() const {
if (!conn) {
conn = std::make_unique<Connection>();
}
return conn.get();
}
};지연 초기화 예제는 단일 스레드에서만 안전합니다. 두 스레드가 동시에 getConnection()을 호출하면 둘 다 !conn을 보고 연결을 두 번 만들고, 한쪽이 다른 쪽의 unique_ptr를 덮어써 먼저 반환된 포인터가 해제된 객체를 가리킬 수 있습니다. 여러 스레드에서 부를 수 있다면 mutable std::once_flag initFlag;를 두고 std::call_once(initFlag, [this] { conn = std::make_unique<Connection>(); });로 초기화를 한 번만 실행하게 하는 것이 표준적인 방법입니다. 또 const 함수가 non-const Connection*를 돌려주므로 호출자가 연결 상태를 바꿀 수 있다는 점도 설계상 의도인지 확인해야 합니다.
뮤텍스로 보호한 카운터
#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;
}
};여기서 count는 mutable이 아닙니다. get()은 읽기만 하고, 값을 바꾸는 increment()는 non-const이기 때문입니다. mutable이 필요한 것은 const 함수에서도 잠가야 하는 mtx뿐입니다. 단순 정수 카운터라면 뮤텍스 대신 std::atomic<int>가 더 가볍습니다.
캐시 무효화
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 {
// 실제로는 LU 분해 등으로 계산
return 1.0;
}
};캐시를 두면 원본 데이터를 바꾸는 모든 non-const 경로가 캐시를 무효화해야 합니다. 나중에 resize()나 operator= 같은 수정 함수를 추가하면서 무효화를 빠뜨리면, determinant()는 아무 오류 없이 오래된 값을 돌려줍니다. 수정 경로가 많아지면 데이터 변경을 private 함수 하나로 모으고 그 안에서만 캐시를 끄는 식으로 실수 여지를 줄이는 것이 좋습니다.
const는 얕다: 포인터 멤버
class MyClass {
mutable int* ptr;
public:
void modify() const {
ptr = new int(10); // 포인터 자체를 바꾸려면 mutable 필요 (이전 값은 누수)
*ptr = 20; // 가리키는 값 수정은 mutable이 없어도 허용됨
}
};이 예제는 const가 얕다(shallow)는 점을 보여 줍니다. const 멤버 함수 안에서 int* ptr은 int* const, 즉 “포인터 변수는 못 바꾸지만 가리키는 int는 바꿀 수 있는” 타입이 됩니다. 그래서 두 번째 줄 *ptr = 20은 mutable이 없어도 컴파일되고, mutable이 필요한 것은 첫 줄처럼 포인터 자체를 다시 대입할 때뿐입니다. std::unique_ptr<T> 멤버도 같아서 const 함수에서 ptr_->modify()가 통과됩니다. 이 구멍을 막고 싶다면 Library Fundamentals TS v2의 std::experimental::propagate_const 같은 래퍼를 쓰거나, 가리키는 대상에 대한 const 접근자만 노출하는 식으로 설계해야 합니다.
람다의 mutable
int x = 0;
auto lambda = [x]() mutable {
x++; // 클로저 안의 복사본을 수정
return x;
};
lambda(); // 1
lambda(); // 2
// 바깥의 x는 여전히 0람다의 mutable은 멤버 변수의 mutable과 이름만 같을 뿐 동작 위치가 다릅니다. 값 캡처한 변수는 람다 객체(클로저)의 멤버가 되고, 람다의 operator()는 기본이 const라서 그 멤버를 수정할 수 없습니다. mutable을 붙이면 operator()가 non-const가 되어 클로저 안의 복사본을 바꿀 수 있게 됩니다. 또 람다를 복사하면 상태도 복사되므로, std::function에 넣거나 알고리즘에 값으로 넘긴 뒤에는 원래 람다와 상태가 따로 놉니다. 상태를 공유해야 한다면 참조 캡처나 shared_ptr를 써야 합니다.
mutable과 const_cast
mutable은 멤버 선언에 “const 문맥에서도 수정 가능”을 새겨 두는 것이라 const 객체에서도 정의된 동작입니다. const_cast는 표현식에서 const를 벗겨 내는 캐스트일 뿐이어서, 원래 const로 선언된 객체를 그렇게 수정하면 미정의 동작입니다.
class Example {
mutable int x_ = 0;
int y_ = 0;
public:
void func() const {
x_ = 10; // OK: mutable
const_cast<Example*>(this)->y_ = 10; // 객체가 원래 const였다면 미정의 동작
}
};
void demo() {
const Example ce;
ce.func(); // y_ 수정 부분이 미정의 동작
}참고 자료
같이 보면 좋은 글
- C++ const 에러: passing as const 컴파일 에러 원인과 const 정합성
- C++ static 멤버 변수와 함수: 초기화 순서, 스레드 안전성, C++17 inline static
- C++ this 포인터: 메서드 체이닝, 자기 대입 검사, 람다 this 캡처 수명
- C++ 정적 초기화 순서