3강 / 20강

숫자와 글자 — 돈 계산이 틀리는 이유

2의 보수 · 오버플로 · 실수 오차 · 한글 인코딩

메모리에 11111111 11111111 이 들어 있습니다. 이건 얼마일까요?

부호 없는 수로 읽으면 → 65535
부호 있는 수로 읽으면 → -1
글자로 읽으면 → 깨진 문자

비트 자체에는 뜻이 없습니다. 어떻게 읽기로 약속했는지가 전부예요. 이 약속을 헷갈리면 쇼핑몰에서 주문 금액이 음수가 되는 사고가 납니다.

고등학생돈 계산이 틀리는 이유

이 강의에서 가장 실전적인 내용입니다. 쇼핑몰에서 실제로 사고가 나는 곳이거든요.

컴퓨터의 숫자는 수학의 숫자가 아니다

세 가지 함정

함정	증상
오버플로	큰 수가 음수가 된다
실수 오차	0.1 + 0.2 ≠ 0.3
인코딩	한글이 깨진다

셋 다 자리가 유한하기 때문에 생긴다

비유 — 자동차 주행거리계

계기판이 여섯 자리입니다. 999,999km 를 넘으면?

000,000 으로 돌아갑니다. 100만 km 를 달렸는데 새 차 처럼 보이죠.

자리가 모자라면 넘친 부분이 사라진다

컴퓨터도 똑같습니다. 다만 더 이상하게 돌아가요 — 0 이 아니라 가장 큰 음수로 갑니다. 왜 그런지는 2의 보수를 보면 압니다.

음수를 만드는 법 — 2의 보수

비트에는 마이너스 기호가 없습니다. 그래서 이렇게 약속했어요.

🔄

① 뒤집는다

모든 비트를 반대로

➕

② 1을 더한다

그게 음수다

왜 이렇게 이상하게 만들었을까요? 뺄셈기를 따로 만들 필요가 없어지기 때문입니다. 5 - 3 을 5 + (-3) 으로 계산해도 덧셈기 하나로 답이 맞아떨어져요. 회로가 절반으로 줄어듭니다.

뺄셈이 덧셈으로 둔갑하는 마술.

Python 브라우저에서 실행

def 보수(n, 비트=8):
    return format(n & (2**비트 - 1), f"0{비트}b")

print("  3 =", 보수(3))
print(" -3 =", 보수(-3), "  ← 3을 뒤집고(11111100) 1을 더한 것")
print()

# 뺄셈을 덧셈으로 해 보자: 5 - 3
결과 = (5 + (-3)) & 0xFF
print("5 + (-3) =", 보수(5), "+", 보수(-3), "=", 보수(결과), "=", 결과)
print()

# 8비트가 표현할 수 있는 범위
print("부호 없음:", 0, "~", 2**8 - 1)
print("부호 있음:", -2**7, "~", 2**7 - 1)

고등학생2의 보수 — 뺄셈을 없애는 발명

음수를 어떻게 나타낼까요? 가장 단순한 생각은 맨 앞 비트를 부호로 쓰는 겁니다.

그런데 그러면 +0 과 −0 이 따로 생긴다

그래서 나온 것이 2의 보수

발상이 재미있습니다 — "−3 은 3 을 더하면 0 이 되는 수"

4비트로 봅시다. 3 은 0011. 여기에 뭘 더하면 0000 이 될까요?

	비트
3	0011
−3	1101
합	10000 → 넘친 1 은 버린다 → 0000 ✔

그래서 뺄셈 회로가 필요 없다 — 덧셈만 있으면 된다

비유 — 시계

시계에서 3시간 뒤로 가는 것과 9시간 앞으로 가는 것은 같습니다.

12시간짜리 원이라서요. −3 = +9 인 셈이죠.

유한한 자릿수는 원처럼 돌아온다

이제 오버플로가 왜 음수가 되는지 보입니다

8비트에서 127 + 1 을 하면 10000000 인데, 이건 2의 보수로 −128 입니다.

계산	결과
127 + 1	−128 ⚠

가장 큰 수 다음이 가장 작은 수 — 원이니까

note 가 든 사고들이 전부 이겁니다. 재고가 21억을 넘으면 갑자기 음수 가 되죠.

미니 CPU로 오버플로를 직접 일으켜 봅시다

아래는 이 강의에서 쓰는 미니 CPU의 어셈블리입니다. 16비트 레지스터라서 32767을 넘으면 음수로 돌아버려요. ▶ 실행을 눌러 보세요.

합계가 33,000원이 되어야 하는데 …

미니 CPU 브라우저에서 실행

; 32000원짜리 상품을 카트에 담고, 1000원짜리를 하나 더 담는다
        LOADI R0, #32000    ; 지금까지의 합계
        LOADI R1, #1000     ; 새로 담는 상품
        ADD   R0, R1        ; 합계 = 33000 … 16비트에 들어갈까?
        OUT   R0            ; 결과를 찍어 본다
        HALT

결과가 -32536 이 나왔을 겁니다. 33000은 16비트 부호 있는 수의 최댓값(32767)을 넘거든요. CPU는 V(오버플로) 플래그를 세워서 "넘쳤다"고 알려 주지만, 프로그램이 그 플래그를 확인하지 않으면 그냥 음수인 채로 넘어갑니다.

그래서 실무에서는 돈은 넉넉한 정수 타입(64비트)이나 고정소수점으로 다룹니다.

실수는 왜 항상 조금 틀릴까

파이썬에서 0.1 + 0.2 를 해 보면 0.30000000000000004 가 나옵니다. 버그가 아니라 2진법으로는 0.1을 정확히 적을 수 없기 때문입니다. 10진법으로 1/3을 0.3333… 이라고 영원히 적어야 하는 것과 같아요.

돈을 float 으로 다루면 안 되는 이유.

Python 브라우저에서 실행

print(0.1 + 0.2)
print(0.1 + 0.2 == 0.3)
print()

# 쇼핑몰에서 이게 어떤 사고가 되는가
가격 = 0.1
합계 = 0.0
for _ in range(10):
    합계 += 가격
print("100원짜리를 10번 담으면:", 합계, "→ 1원이 맞나?", 합계 == 1.0)
print()

# 해법 ① 정수(원 단위)로만 다룬다  ← 실무의 정답
합계원 = sum([100] * 10)
print("정수로 계산:", 합계원, "원")

# 해법 ② 십진 소수 타입
from decimal import Decimal
print("Decimal:", sum([Decimal("0.1")] * 10))

고등학생0.1 + 0.2 가 0.3 이 아닌 이유

파이썬에서 직접 해 보세요. 0.30000000000000004 가 나옵니다. 버그가 아니라 설계입니다.

2진법으로는 0.1 을 정확히 쓸 수 없다

왜 못 쓰나

10진법에서 1/3 을 생각해 보세요. 0.3333… 무한히 갑니다. 정확히 못 씁니다.

2진법에서 0.1 이 딱 그렇습니다. 0.000110011001100… 무한 반복이에요.

수	10진법	2진법
1/2	0.5 ✔	0.1 ✔
1/4	0.25 ✔	0.01 ✔
1/10	0.1 ✔	무한 반복 ✗

분모가 2의 거듭제곱이 아니면 2진법에서 무한소수

그래서 어딘가에서 끊습니다

64비트에 담을 만큼만 쓰고 버립니다. 그 버린 부분이 오차예요.

아주 작은 오차지만 쌓이면 보인다

쇼핑몰에서 무엇이 문제인가

상황	결과
1원짜리 100만 번 더하기	1,000,000 이 아닐 수 있다
부가세 계산	1원 이 틀린다
정산 대조	안 맞는다 — 원인을 못 찾는다

돈은 절대 실수(float)로 다루지 않는다

그럼 어떻게 하나

방법	설명
정수로	원 단위 정수 — 소수점을 아예 안 쓴다
Decimal	10진법으로 계산하는 자료형

/python 강의에서도 나온 이야기예요. 돈과 float 는 섞지 않는다.

한글은 몇 바이트인가

영어 한 글자는 1바이트(ASCII)입니다. 그런데 한글은요?

지금 표준인 UTF-8에서 한글 한 글자는 3바이트입니다. 그래서 DB에 VARCHAR(10)이라고 잡아 놓고 "열 글자 들어가겠지" 했다가 세 글자만 들어가는 사고가 나요.

한글 한 글자 = 3바이트. 자르는 위치를 잘못 잡으면 깨집니다.

Python 브라우저에서 실행

for 글자 in ["A", "가", "😀"]:
    b = 글자.encode("utf-8")
    print(f"{글자}  → {len(b)}바이트  {b.hex(' ')}  {' '.join(format(x,'08b') for x in b)}")
print()

이름 = "김민준"
print("글자 수 :", len(이름))
print("바이트 수:", len(이름.encode('utf-8')))
print()

# 바이트 한가운데서 자르면 글자가 깨진다 — 로그를 자를 때 실제로 일어나는 일
b = 이름.encode("utf-8")
print("7바이트에서 자르면:", b[:7])
try:
    print(b[:7].decode("utf-8"))
except UnicodeDecodeError as e:
    print("→ 깨짐!", e)

가상 서버에서 한글의 바이트를 벗겨 봅니다.

bash 브라우저에서 실행

# 서버에서도 확인해 본다
echo -n "가" | xxd
echo -n "가" | wc -c        # 바이트 수

고등학생관리자를 위한 한 줄 규칙

note 가 정리한 규칙들을 왜 그런지와 함께 봅시다.

규칙	왜
돈은 정수로	실수는 오차가 쌓인다
ID 는 64비트로	32비트는 21억에서 넘친다
인코딩은 UTF-8 로 통일	섞이면 깨진다
길이는 글자 수로	바이트로 자르면 한글이 깨진다

21억이 얼마나 가까운가

"우리 쇼핑몰이 21억 건이나 되겠어?" 라고 생각하기 쉽죠. 그런데 주문 ID 가 아니라 로그 ID 라면?

초당	21억까지
100건	약 8개월
1,000건	약 25일

생각보다 훨씬 빨리 온다

그리고 넘칠 때 조용합니다

오류가 안 납니다. 그냥 음수가 되거나 0 으로 돌아갑니다. 그러면 기존 자료를 덮어씁니다.

가장 무서운 버그는 소리 없이 틀리는 것

인코딩 규칙도 같은 성격입니다

깨진 글자는 되돌릴 수 없습니다. 원본이 이미 다른 바이트 로 저장됐으니까요.

처음부터 UTF-8 로 — 나중에 고치는 건 늘 어렵다

이 네 규칙은 외워 두세요. 전부 실제로 회사를 아프게 한 사고들입니다.

🤔 확인 문제

8비트 부호 있는 정수에 저장된 재고가 -128 입니다. 여기서 1을 더 빼면?

🤔 확인 문제

쇼핑몰 DB에 상품 설명을 VARCHAR(30)으로 잡았는데 한글 12자를 넣으니 거절당했습니다. 가장 그럴듯한 원인은?

해설 DB가 길이를 바이트로 세는 설정이면 한글 12자 = 36바이트라 넘칩니다. 그래서 요즘 MySQL은 utf8mb4 + 문자 단위로 세도록 설정하는 게 기본이에요.