내가 전제조건이라는 말로 너무 두루뭉실하게 설명하고 넘어가서 그런데... 내용이 많이 깊어질 각오를 하고 조금 더 자세히 설명을 해볼게.

위 글에서 전제조건이라고 한 걸 정확히 설명하자면 '코드의 behavior가 명확하게 정의될 것' 이야. 명확하게 정의된다는 것은 언어에 달린 문제인데, 어떤 코드를 언어의 문법 (스펙이라고도 해)에 따라 해석했을 때 behavior가 단 한 가지로 정해진다면 behavior가 명확하다고 해. 예를 들어 c++ 코드 `int a = 1 + 1;` 의 behavior는 [a라는 이름의 int 변수를 선언하고 거기에 1+1 의 결과를 계산해서 대입한다] 라고 명확하게 정의할 수 있겠지? char 변수를 선언해버린다거나 0이 대신 들어간다거나 하지 않고 '항상' 우리가 의도한 behavior가 나온다는 뜻이야.

그런데 대부분의 언어는 안 그렇지만, 유독 c++는 문법 자체에 고의적인 'UB 함정' 이 많아. 예를 들어서 std::vector / std::array 에서 index를 잘못 접근했을 때라거나, 초기화하지 않은 정수형 변수의 값을 이용하는 경우 등등이 UB라는 게 언어 스펙에 명시돼 있어.
이걸 보면 아마 두 가지 질문이 떠오를 텐데, "왜 언어에다가 이렇게 고의적으로 함정을 걸어두는 거지?" 와 "index를 잘못 접근하면 항상 프로그램이 튕기던데 왜 behavior가 정의되지 않았다고 하는 거지?" 일 거야.

우선 이런 '고의 함정'은 아무 이유 없이 걸어둔 건 아닌데, c++의 철학이 "Trust the programmer. Pay only for what you use" 라서 그래. 이게 무슨 뜻이냐고? 좀 거칠게 말하면 "너의 실수를 커버치기 위해서 프로그램을 느려지게 할 수는 없다" 란 뜻;
예를 들어서 index를 잘못 접근하면 프로그램이 "invalid index!" 를 띄우면서 종료돼야 한다고 생각해보자. 그러면 컴파일러는 index 접근이 있을 때마다 index가 잘못됐는지 체크하는 어셈블리 몇 줄을 추가해줘야 해. 이건 c++ 입장에서 그야말로 용납할 수 없는 대역죄거든. "너가 코드를 잘 짜면 될 것이지 이딴 쓸데없는 짓을 하게 만들다니! 갈!" 같은 느낌.

두 번째는 사실 컴파일러를 통해 나온 프로그램의 동작을 언어의 스펙으로 오해하고 있는 경우인데, c++ 컴파일러들은 이런 경우에 위에서 말한 언어 철학에 아주 충실하게 index bound check따위 하지 않고 바로 addr + size * index 주소로 접근하도록 어셈블리를 만들어버려. 하지만 그렇게 계산된 주소는 '거의 항상' 제대로 된 주소, 즉 프로그램이 OS에게 정식으로 할당받은 주소일 리가 없으니 OS 입장에선 "갑자기 허락 안 받은 주소에 접근하네? 위험하니 강제로 종료시켜야겠다" 라고 판단해서 폴트를 띄우는 거고.
근데 안 그럴 수도 있어. 정말정말정말 운이 좋게 그렇게 잘못 접근한 주소도 이 프로그램이 할당받았던 메모리 공간에 걸쳐 있을 수 있잖아? 물론 그 순간부터 이 프로그램은 온갖 이상한 값을 읽기 시작하면서 개판이 나겠지만 말야.
이런 식으로 index를 잘못 접근했을 때 발생하는 behavior는 문법 같은 거로 정의할 수도 없어. 결국 c++에선 이런 경우엔 UB라고 정의할 수밖에 없단 거지.

아, 참고로 대부분의 언어는 이런 식으로 index에 잘못 접근한 경우에 behavior가 명확하게 (대부분 예외의 형태로) 정의돼 있어. 예를 들어서 java는 '항상' IndexOutOfBoundsException을 띄우도록 정의돼 있고, Rust는 '항상' panic하도록 정의돼 있는 식이야.
이러면 bound check가 매번 들어가야 하니까 성능 손해가 좀 있겠지만, 대부분의 언어는 c++와 달리 성능보다 안정성을 훨씬 중요시하거든 ㅡ.ㅡ;;

이렇게 코드의 behavior가 명확해야 하는 이유를 설명하려면 Behavioral Refinement라는 정말 골치아픈 개념으로 이어지는데, 정말 간단하게 지금 필요한 부분만 설명하자면 애초에 behavior가 불명확한 프로그램에서 behavior가 명확한 프로그램이 나올 수는 없기 때문이야.
Behavior가 명확하지 않으면 어떤 코드를 변형시켜 최적화했을 때 무슨 결과가 나올지 알 방도가 없잖아. 그래서 모든 컴파일러 최적화는 애초에 source에 undefined behavior가 있는 상황은 완전히 배제하고 최적화를 실행해. 하지만 그 대전제가 깨져서 원본 코드에 undefined behavior가 있었다면 온갖 최적화들이 (behavior적으로) 아무말대잔치를 하면서 프로그램을 작살낼 거고, 프로그래머는 머리를 싸매고 "알고리즘에 틀린 게 없는데 왜 이렇게 이상하게 돌아가는 거야?!" 라면서 울부짖겠지....

그래서 내가 원래 쓴 글을 조금 정정하자면, 사실 undefined behavior는 대부분 프로그래머가 정의하지 않은 behavior라기보단 프로그래머가 behavior를 불명확하게 정의해준 경우가 대부분이야. 제대로 된 프로그래머라면 당연히(?) 이런 경우를 최대한 피해야겠지만... 그럼 이런 걸 잘 피할 수 있게 언어를 만들어 주든가!!!!!!

참고로 예시로 들어준 double free도 무슨 일이 일어날지 c++ 문법상으로 정의할 수가 없기 때문에 undefined behavior로 적혀 있으니까 이런 프로그램을 짜면 무슨 일이 일어날지 아무도 몰라 :o