사고를 부르는 C++ 코드 패턴들

C++ 사고 코드를 보면
대부분 “몰라서” 그렇게 쓴 게 아니다.

• 바쁘고
• 일정에 쫓기고
• 일단 돌아가니까

그 결과로
비슷한 패턴들이 반복해서 쌓인다.

아래는 현장에서 정말 자주 보이는,
그리고 시간이 지나면 반드시 문제를 만드는
C++ 사고 패턴들이다.

---

1) shared_ptr로 모든 걸 해결하려는 구조

C++ 사고 패턴의 단골 1번이다.

• 어디서 생성됐는지 모르고
• 누가 마지막 소유자인지 모르고
• 왜 살아 있는지도 모른다

shared_ptr 자체가 문제는 아니다.
문제는 공유가 필요한 이유를 설명하지 못하는 구조다.

순환 참조가 생기고,
객체는 사라지지 않고,
메모리는 조용히 새어나간다.

shared_ptr는 설계의 결과여야지
설계의 출발점이 되면 안 된다.

---

2) 수명보다 인터페이스를 먼저 만든 클래스

인터페이스는 깔끔한데
객체 수명은 아무도 모르는 클래스.

• 누가 만들고
• 누가 들고 있고
• 언제 파괴되는지

이 질문에 답이 없으면
그 클래스는 이미 위험하다.

C++에서 객체는
존재하는 시간 전체가 계약이다.
수명을 설명할 수 없는 객체는
언젠가 반드시 사고를 만든다.

---

3) 값처럼 보이지만 값이 아닌 타입

C++에서는
값처럼 보이지만 실제로는
무거운 자원을 들고 있는 타입이 많다.

• 내부에 포인터를 가진 객체
• 복사 비용이 큰 컨테이너
• 암묵적으로 공유되는 리소스

이 타입을
아무 생각 없이 복사하고 넘기는 순간
성능 문제나 미묘한 버그가 생긴다.

“이건 그냥 객체니까 괜찮겠지”
이 판단이 사고의 씨앗이다.

---

4) 예외를 숨긴 라이브러리 경계

라이브러리 경계에서
예외 정책이 불분명하면
사고는 두 배로 커진다.

• 이 함수는 예외를 던지는가
• noexcept는 진짜 지켜지는가
• 호출자는 그걸 알고 있는가

예외가
인터페이스에 드러나지 않으면
호출자는 방어할 수 없다.

C++에서 예외는
편의 기능이 아니라
공개된 계약이어야 한다.

---

5) 추상화 계층이 너무 얇거나, 너무 두꺼울 때

사고를 부르는 두 극단이다.

• 너무 얇은 추상화
  → 내부 구현이 그대로 노출됨
• 너무 두꺼운 추상화
  → 실제 비용과 동작이 보이지 않음

둘 다
디버깅을 어렵게 만든다.

좋은 추상화는
숨길 것과 드러낼 것을
명확히 구분한다.

---

6) “이건 관례야”로 유지되는 코드

C++ 코드베이스에서
가장 위험한 말 중 하나다.

“원래 이렇게 써.”

• 문서 없음
• 타입으로 표현되지 않음
• 코드에 의도가 남아 있지 않음

이 관례를 아는 사람이 떠나는 순간
코드는 지뢰밭이 된다.

관례로 유지되는 안전은
안전이 아니다.

---

C++ 사고 패턴의 공통점은 분명하다.

• 책임이 타입으로 드러나지 않고
• 수명이 코드에 보이지 않고
• 의도가 문장으로 설명되지 않는다

이건 언어의 문제가 아니다.
설계에서 피한 질문들이
나중에 사고로 돌아온 것이다.

C++은
잘 쓰면 아주 안전한 언어다.
하지만 그 안전성은
패턴이 아니라 기준에서 나온다.

이 글까지 포함해
C++ 시리즈에서 이야기한 건
결국 하나다.

사고는 우연히 나지 않는다.
항상 반복되는 선택의 결과다.