정수 오버플로가 알려주는 것: C의 침묵과 Ada의 거부

프로그래밍의 세계를 사람의 시선으로 그린 짧은 우화 한 편이 개발자 사이에서 회자되고 있다. 'The Integer'라는 제목의 이 글은 메모리 안에 살아가는 정수 하나를 화자로 삼는다. 0에서 시작해 1, 2, 그리고 수만까지 늘어나던 이 정수는 자신이 선언된 범위의 끝, 즉 2,147,483,647에 다다르는 순간 존재의 경계와 마주한다. 문학적 장치이지만 그 밑바탕에는 모든 시스템 프로그래머가 반드시 이해해야 할 정수 오버플로라는 실제 현상이 깔려 있다.

경계에서 벌어지는 일

2,147,483,647은 우연한 숫자가 아니다. 부호 있는 32비트 정수가 표현할 수 있는 최댓값(2^31 - 1)이다. 여기에 1을 더하면 값은 표현 가능한 범위를 벗어난다. 이야기 속 화자가 두려워하는 것이 바로 이 순간이다. 산술적으로는 그다음 값이 '금지된 별'처럼 떠오르지만, 그 결과는 32비트 상자 안에 담기지 않는다. 진짜 문제는 이 넘침을 각 언어와 런타임이 어떻게 다루느냐에 있다.

C의 침묵, Ada의 거부

글은 C 프로그램에서 들려온 이야기를 언급한다. 경계를 넘은 정수가 '반대편에서 거대한 음수로 나타난다'는 대목이다. 실제로 많은 C 구현에서 부호 있는 정수 오버플로는 값이 최솟값 쪽으로 되돌아가는(wrap-around) 형태로 관측되곤 하며, 언어 표준상으로는 정의되지 않은 동작(undefined behavior)에 해당한다. 즉 컴파일러는 그런 일이 일어나지 않는다고 가정하고 최적화하며, 프로그램은 아무런 경고 없이 잘못된 값을 안은 채 계속 흘러간다. 화자의 표현을 빌리면 '소리 없는 공포'다.

반면 이야기의 주인공이 사는 세계는 Ada다. 값이 선언된 범위를 벗어나려는 순간 Ada 런타임이 이를 알아차리고, 화자의 말처럼 '우주가 거짓말하도록 놔두지 않는다'. Ada는 타입에 범위를 부여하고 실행 중 그 범위를 벗어나는 값을 만들려 하면 예외를 발생시켜, 잘못된 값이 조용히 퍼지는 것을 막는다. 화자가 한순간 안도한 이유가 여기에 있다. 틀린 값으로 계속 살아남느니, 진실이 상자에 담기지 못한다는 사실 자체가 명시적으로 드러나는 편이 낫다는 것이다.

스택이 무너지는 장면

이후의 묘사는 예외가 처리되지 않았을 때 프로그램이 종료되는 과정을 그린다. 화자는 콜 스택을 거슬러 올라가며 자신을 붙잡아 줄 무언가를 찾지만, 스택 프레임이 하나씩 사라지고 지역 변수들이 애초에 선언된 적 없던 것처럼 지워진다. main.adb의 14번째 줄에 적힌 지시가 그 운명을 결정했다는 대목은, 오버플로가 발생한 코드 위치와 거기서 시작된 스택 되감기(unwinding)를 은유한다. 마침내 프로그램은 죽고 그 너머에서 셸이 다시 살아난다. 프로세스가 종료되고 제어가 운영체제로 돌아가는 순간이다.

실무자에게 남는 것

이 우화가 던지는 실질적 교훈은 분명하다. 우선 정수 타입의 경계는 추상적 이론이 아니라 언제든 마주칠 수 있는 물리적 한계다. 금액 합산, 인덱스 증가, 타임스탬프 계산처럼 값이 단조롭게 커지는 로직은 특히 위험하다. 또한 언어와 런타임의 오버플로 정책을 아는 것이 중요하다. 조용한 래핑은 눈에 보이지 않는 버그로 남지만, 명시적 오류는 최소한 문제를 그 자리에서 드러낸다. 항공·철도·국방처럼 안전이 중요한 분야에서 Ada가 오래 쓰여 온 배경도 이 '거부하는 설계'와 무관하지 않다.

다만 이 글은 어디까지나 문학적 우화이며 벤치마크나 코드 예제를 담은 기술 문서가 아니라는 점은 분명히 해 둘 필요가 있다. 런타임 검사에는 성능 비용이 따르고, 실무에서는 검사 활성화 여부와 예외 처리 전략을 상황에 맞게 선택해야 한다. C 진영에도 부호 없는 정수의 정의된 래핑, 컴파일러의 오버플로 감지 옵션, 정적 분석 도구처럼 대응 수단이 존재한다. 그럼에도 이 짧은 이야기가 오래 남는 이유는, 우리가 매일 다루면서도 좀처럼 그 존재를 의식하지 않는 정수 하나에 다시 시선을 돌려 놓기 때문이다.