서론: 우주선에 짐을 싣는 법
우주 탐사 프로젝트에서 가장 큰 적은 '무게'입니다. 로켓에 화물을 1kg 더 싣는 데 수천만 원의 비용이 들기 때문입니다. 그래서 엔지니어들은 볼트 하나, 전선 한 가닥의 무게까지 계산합니다. 편지 한 장을 보내는데 거대한 컨테이너 박스를 쓰는 낭비를 절대 용납하지 않습니다.
프로그래밍 세계, 특히 C언어의 세계도 이와 똑같습니다. 우리가 무심코 사용하는 데이터 타입(Data Type)은 데이터가 차지할 '메모리의 크기(규격)'를 미리 정하는 행위입니다.
"그냥 큰 상자에 다 담으면 안 되나요?"라고 묻는다면, 오늘 5편의 이야기를 귀담아들으셔야 합니다. 왜 정수는 4바이트이고 문자는 1바이트인지, 그 속에 숨겨진 비트와 바이트의 경제학을 파헤쳐 봅니다.
본론 1: 그릇의 크기가 다르면 담는 양도 다르다
C언어에는 다양한 자료형이 존재합니다. 이를 '그릇'에 비유해 보겠습니다.
- char (1바이트): 소주잔입니다. 알파벳 문자 하나('A', 'B')나 매우 작은 숫자(-128 ~ 127)를 담기에 딱 적당합니다.
- int (4바이트): 머그컵입니다. 우리가 흔히 쓰는 정수(약 -21억 ~ 21억)를 담을 수 있는 표준적인 크기입니다.
- double (8바이트): 커다란 물통입니다. 소수점이 있는 정밀한 실수나 아주 큰 숫자를 담을 때 사용합니다.
만약 숫자 '1'을 저장하기 위해 8바이트짜리 double을 쓴다면, 1바이트만 쓰고 나머지 7바이트(56비트)는 텅 빈 채로 낭비하게 됩니다. NASA의 시스템에서 이런 낭비가 수백만 번 반복된다면, 메모리는 금방 바닥나고 탐사선은 멈춰버릴 것입니다.
본론 2: 왜 하필 정수는 '4바이트'일까?
여기서 한 가지 의문이 생깁니다. "왜 애매하게 3바이트나 5바이트가 아니라 4바이트인가요?" 여기에는 CPU의 설계 철학이 담겨 있습니다.
CPU가 한 번에 씹을 수 있는 크기
우리가 흔히 '32비트 컴퓨터', '64비트 컴퓨터'라고 말할 때의 그 숫자가 바로 힌트입니다.
32비트 CPU는 한 번에 32개의 0과 1을 처리할 수 있습니다. 32비트를 바이트로 환산하면? 바로 4바이트(8비트 × 4)입니다. 즉, CPU가 가장 빠르고 효율적으로 처리할 수 있는 데이터의 기본 단위가 4바이트이기 때문에, C언어의 표준 정수형인 int가 4바이트로 굳어진 것입니다. (최근 64비트 시스템에서도 호환성을 위해 int는 주로 4바이트를 유지합니다.)
본론 3: 오버플로우(Overflow), 컵에서 물이 넘칠 때
데이터 타입을 잘못 선택하면 어떤 일이 벌어질까요? 1바이트짜리 char(최대 127까지 저장) 변수에 숫자 128을 넣으면 어떻게 될까요?
컵에 물을 계속 부으면 넘쳐흐르듯, 컴퓨터에서도 오버플로우(Overflow)가 발생합니다. 놀랍게도 컴퓨터는 넘친 것을 버리고, 숫자를 다시 맨 처음(-128)으로 되돌려버립니다. 128이 되어야 할 숫자가 갑자기 -128이라는 음수로 변하는 끔찍한 오류가 발생하는 것입니다.
실제로 1996년, 유럽 우주국(ESA)의 아리안 5호 로켓이 발사 40초 만에 폭발한 사고가 있었습니다. 원인은 64비트 숫자를 16비트 변수에 억지로 구겨 넣다가 발생한 오버플로우 때문이었습니다. 자료형 선택의 실수가 수천억 원을 공중분해 시킨 것입니다.
결론: 개발자의 덕목은 '절약'이다
최근에는 하드웨어 성능이 좋아져서 메모리 몇 바이트 낭비하는 것을 대수롭지 않게 여기기도 합니다. 하지만 진정한 엔지니어라면 데이터가 차지하는 물리적 무게를 느낄 수 있어야 합니다.
내 데이터에 딱 맞는 '그릇'을 찾아주는 것. 그것이 시스템의 성능을 최적화하고 예기치 못한 폭발(오류)을 막는 첫걸음입니다.
이제 우리는 C언어의 기초 문법과 메모리 구조(Part 1~5)를 모두 마스터했습니다. 다음 [Part 6. 포인터(Pointer) 재해석: 데이터의 지도] 편부터는 C언어의 중급 과정이자 가장 강력한 무기인 포인터의 세계로 깊숙이 들어가 보겠습니다. 기대하셔도 좋습니다.