C++26 정의되지 않은 동작 대응: 컴파일 오류로 바뀌는 코드를 점검하는 법

C++26의 안전성 변화에서 실무자가 먼저 읽어야 할 문장은 “새 문법이 무엇인가”가 아니다. 지금은 빌드가 통과하지만, 타입 정보나 초기화 상태를 놓친 채 실행하면 데이터 손상·보안 누출·교착 상태로 이어질 수 있는 경로가 어디인가다. 나는 이 흐름을 언어가 갑자기 엄격해졌다는 소식보다, 오래된 경고를 운영 부채로 남겨 두지 말라는 신호로 본다. 2026년 7월 29일 Sandor Dargo가 정리한 C++26 변경 중 대표 사례인 P3144R2는 불완전한 클래스 타입을 delete하는 패턴을 ill-formed, 즉 컴파일 오류로 바꾼다. 컴파일러가 소멸자나 사용자 정의 operator delete의 존재를 알 수 없는 지점에서 “대개 괜찮겠지”라고 넘어가지 않게 하는 선택이다. 레거시 코드를 C++26으로 옮길 때는 표준 전환 자체보다 먼저, 기존 경고를 전부 보이게 만들고 타입 완전성·초기화·수명 경계를 작은 단위로 고쳐야 한다.

C++26이 줄이려는 것은 ‘희귀한 크래시’만이 아니다

정의되지 않은 동작(undefined behavior, UB)은 테스트에서 한 번도 문제를 일으키지 않았다는 사실만으로 안전하다고 말할 수 없는 영역이다. 같은 소스라도 컴파일러 최적화, 빌드 옵션, 입력, 플랫폼에 따라 전혀 다른 결과를 낼 수 있다. 그래서 UB는 단순한 예외 처리가 아니라, 컴파일러가 전제하는 규칙과 프로그램이 실제로 지킨 규칙 사이의 계약 문제다.

Dargo의 C++26 정리는 이 계약을 조금씩 더 이른 단계에서 확인하는 변화들을 묶어 보여 준다. 글은 UB가 보안 누출, 데이터 손상, 교착 상태 등 매우 넓은 범위의 나쁜 동작으로 이어질 수 있다는 제안서의 문제의식을 인용한다. 핵심은 “모든 런타임 문제를 컴파일러가 잡는다”는 약속이 아니다. 컴파일러가 이미 구조적으로 판단할 수 있는 위험한 패턴은, 배포 뒤의 우연한 재현에 맡기지 말자는 방향이다.

이 관점은 C++26을 도입하지 않는 팀에도 유효하다. Apple clang 21.0.0처럼 현재의 주요 컴파일러는 오래전부터 위험한 삭제 패턴에 경고를 내는 경우가 있다. 경고를 무시한 채 표준 버전만 올리면 빌드가 깨진다는 불편이 남지만, 그 실패는 오히려 오래된 수명 버그를 발견하는 가장 값싼 시점이다.

가장 먼저 찾을 패턴: 불완전한 타입을 통한 delete

P3144R2가 다루는 상황은 전방 선언(forward declaration)만 보이는 곳에서 포인터를 삭제하는 코드다. 헤더에서 타입의 구현을 감추려는 의도는 흔하고, 특히 PImpl 패턴에서 자주 등장한다. 하지만 삭제 지점에서 클래스 정의가 보이지 않으면 컴파일러는 실제 소멸자를 호출해야 하는지, 클래스별 해제 함수가 있는지 확정할 수 없다.

struct Widget;  // 전방 선언

void deleteWidget(Widget* p) {
    delete p;   // C++26에서는 문제를 드러내야 하는 경로
}

문제는 Widget이 다른 번역 단위에서 비자명 소멸자나 사용자 정의 operator delete를 가질 수 있다는 점이다. P3144R2의 제안은 이 불확실한 패턴을 무조건 ill-formed로 만들자는 것이다. P3144R2 원문은 이 변경의 배경과 대안을 기록한다. Dargo의 해설도 실무적 결론을 간단히 정리한다. 삭제하는 위치에서 타입을 완전하게 보이게 하거나, 소유권을 완전한 타입을 아는 구현 파일로 이동해야 한다.

PImpl을 쓴다면 공개 헤더에는 소멸자 선언만 두고, 구현 파일에서 완전한 Impl 정의를 포함한 뒤 소멸자를 정의하는 구조가 안전하다.

#include <memory>
struct WidgetImpl;

class Widget {
public:
    Widget();
    ~Widget();                 // 선언만 공개 헤더에 둔다
private:
    std::unique_ptr<WidgetImpl> impl_;
};

// widget.cpp
#include "widget.h"
struct WidgetImpl { /* 완전한 정의 */ };
Widget::~Widget() = default;  // 여기서는 WidgetImpl이 완전하다

이 예시는 소유권을 숨기기 위해 delete를 아무 곳에서나 호출하는 관행보다, 파괴 책임도 타입 정의와 함께 두는 편이 낫다는 뜻이다. 무작정 모든 전방 선언을 제거할 필요는 없다. 포인트는 삭제와 파괴 책임이 발생하는 번역 단위에는 완전한 타입 정보가 있어야 한다는 것이다.

경고를 마이그레이션 작업 목록으로 바꾸는 순서

대규모 코드베이스에서 UB를 한 번에 없애겠다는 목표는 너무 넓다. 대신 컴파일러의 경고를 재현 가능한 목록으로 만들고, 수명·초기화·범위 세 축으로 좁히는 편이 효과적이다. 다음 명령은 macOS의 Clang 계열 프로젝트에서 경고를 숨기지 않고 빌드 로그를 남기는 출발점이다. 프로젝트의 실제 빌드 시스템이 있다면 해당 시스템의 컴파일 플래그에 같은 원칙을 적용해야 한다.

clang++ -std=c++2c -Wall -Wextra -Wpedantic -Werror \
  -c src/widget.cpp -o /tmp/widget.o

-Werror를 모든 브랜치에 즉시 강제하라는 뜻은 아니다. 먼저 CI의 별도 경고 수집 작업에서 어떤 경고가 새로 생기고, 어떤 경고가 기존 부채인지 구분하자. 그다음 다음 순서로 처리한다.

1. 수명: 불완전한 타입 삭제, 댕글링 참조, 소유권이 불분명한 raw pointer를 검색한다.
2. 초기화: 생성 경로마다 값이 설정되는지, 조건 분기가 일부 필드를 비워 두지 않는지 확인한다.
3. 범위와 계약: 배열 인덱스, null 가능성, 전제조건이 호출자와 구현 양쪽에서 문서화·검증되는지 본다.
4. 경고 기준선: 기존 경고는 이슈로 연결하고, 새 경고는 CI에서 실패시키는 기준선을 만든다.

여기서 테스트는 여전히 중요하다. 다만 테스트 통과는 UB 부재의 증거가 아니다. 경고와 정적 진단은 위험한 구조를 일찍 찾고, 경계 입력 테스트와 sanitizer 실행은 그 구조가 실제 경로에서 어떻게 드러나는지 확인한다. 둘을 경쟁시키지 말고 다른 증거 레인으로 유지해야 한다.

의견: 표준 업그레이드는 호환성 비용이 아니라 진단 창을 여는 기회다

내 의견은 분명하다. C++26의 엄격한 진단을 “기존 코드를 깨뜨리는 규칙”으로만 읽으면 팀은 경고를 끄거나 표준 업그레이드를 미룰 가능성이 크다. 하지만 더 중요한 사실은, 기존 코드가 이미 컴파일러에게 모호한 파괴 책임을 요구하고 있었다는 점이다. 가벼운 반론도 있다. 실제 제품은 서드파티 헤더와 오래된 ABI에 얽혀 있어 당장 -Werror를 켜기 어렵다. 맞다. 그래서 전체 빌드를 멈추기보다 신규 경고 금지와 고위험 모듈 우선 점검으로 시작해야 한다. 표준을 올리는 목적은 문법을 최신으로 보이게 하는 일이 아니라, 런타임까지 숨어 있던 실패를 리뷰 가능한 컴파일 단계로 옮기는 데 있다.

김덕환 운영자 관점

김덕환 운영자 관점에서는 C++ 표준 업그레이드를 툴체인 교체 티켓 하나로 닫지 않는 편이 낫다. 빌드 로그에서 경고를 수집해 수명·초기화·범위 세 그룹으로 분류하고, 불완전 타입 삭제처럼 파괴 책임이 모호한 코드부터 소유권 경계를 다시 잡자. 컴파일 오류가 늘어나는 초기 비용은 있지만, 배포 뒤에만 재현되는 데이터 손상과 보안 문제를 앞당겨 발견하는 비용보다 작다.

참고 자료

• C++26: Reducing undefined behaviour — Sandor Dargo, 2026-07-29
• P3144R2: Deleting a Pointer to an Incomplete Type Should be Ill-formed — WG21