사고를 줄이는 C++ 설계 기준

C++에서 사고를 줄이는 방법은
새로운 문법을 더 배우는 데 있지 않다.

이미 대부분 알고 있다.
문제는 그걸 기준으로 쓰느냐다.

C++ 사고가 적은 코드에는
항상 공통된 설계 기준이 있다.
아래는 현장에서 실제로 효과가 있었던 기준들이다.

---

1) 소유권을 먼저 설계하고 코드를 쓴다

C++에서 가장 먼저 정해야 할 건
클래스도, 인터페이스도 아니다.

누가 소유자인가

• 이 자원의 소유자는 누구인가
• 공유가 필요한가
• 이전이 가능한가

이 질문에 답이 나오면
스마트 포인터 선택은 자동이다.

• 단일 소유 → unique_ptr
• 명시적 공유 → shared_ptr
• 소유권 없음 → 참조 또는 raw pointer

소유권이 정리되지 않은 상태에서
스마트 포인터를 쓰면
delete는 사라지고, 혼란만 남는다.

---

2) 수명은 “생성보다 소멸”을 기준으로 본다

C++ 사고의 절반은
소멸 시점에서 발생한다.

• 소멸 순서 의존
• 이미 정리된 자원 접근
• 종료 시점 크래시

그래서 클래스 설계 시
항상 이 질문이 따라야 한다.

이 객체는 언제 사라지는가

생성자는 눈에 띄지만
소멸자는 조용하다.
조용한 지점일수록
의도를 더 분명히 해야 한다.

---

3) RAII를 형식이 아니라 원칙으로 쓴다

RAII는 문법이 아니다.
습관이다.

• 리소스 획득 = 객체 생성
• 리소스 해제 = 객체 소멸

이 원칙이 깨지는 순간
코드는 다시 C처럼 위험해진다.

• init / release 함수 쌍
• 예외 경로에서 누락된 정리
• 조건부 해제 로직

RAII는
예외가 있어도 안전하게 만들기 위한 약속이다.
형식만 흉내 내면 효과가 없다.

---

4) 예외는 “편의”가 아니라 “계약”으로 다룬다

C++ 예외는 강력하지만
흐름을 숨긴다.

그래서 예외를 쓰는 코드에는
명확한 기준이 필요하다.

• 어디서 던질 수 있는지
• 어디까지 전파되는지
• 누가 처리 책임을 지는지

이게 문서나 인터페이스에 드러나지 않으면
예외는 사고를 줄이지 못한다.

예외를 쓰는 순간
코드는 더 명시적이어야 한다.

---

5) 추상화 뒤에 비용을 숨기지 않는다

C++은 추상화가 잘 된다.
그래서 비용도 잘 숨겨진다.

• 복사 비용
• 동기화 비용
• 메모리 할당

이 비용을 감춘 채
인터페이스만 깔끔하게 만들면
성능 사고는 시간문제다.

좋은 추상화는
사용하기 쉬운 동시에
비용을 예측 가능하게 만든다.

---

6) “이건 안전하다”는 말을 금지한다

사고가 적은 팀에는
공통 규칙이 하나 있다.

“이 코드는 안전하다”라는 말을 쓰지 않는다.

대신 이렇게 묻는다.

• 어떤 조건에서 깨질 수 있는가
• 어떤 전제를 깔고 있는가
• 그 전제가 바뀌면 어떻게 되는가

안전하다는 말이 나오는 순간
의심은 멈춘다.
의심이 멈추면
사고는 시작된다.

---

C++에서 사고를 줄이는 건
테크닉의 문제가 아니다.

• 소유권을 먼저 정하고
• 수명을 설계하고
• 흐름을 숨기지 않는 것

이 기준을
매번 지키는 사람이
결국 가장 적게 고친다.

C++은 안전한 언어가 될 수 있다.
하지만 그 안전성은
작성자의 기준 위에서만 작동한다.

다음 글에서는
이 기준들이 실제 코드에서
어떻게 형태로 드러나는지,
C++에서 특히 조심해야 할 패턴들을
조금 더 구체적으로 살펴보려 한다.