2진수 덧셈과 오버플로: 앱 개발 예제로 이해하기

2진수 덧셈과 오버플로: 앱 개발 예제로 이해하기

발행 수정 작성자:

핵심 요약
2진수 덧셈의 캐리 규칙은 체크섬·픽셀·오디오보다 먼저 정수 폭과 오버플로 정책을 이해하는 데 사용해야 합니다.

검수 범위
일반 덧셈과 비트 플래그 OR를 구분하고, 경계값 테스트가 필요한 사례만 남기도록 검수했습니다.

앱 개발에서 “덧셈”은 화면에 보이는 숫자 합산을 넘어, 바이너리 데이터 처리·성능 최적화·오버플로 버그 방지 같은 실무 이슈와 직결됩니다. 고수준 언어에서 + 한 번을 눌러도, CPU는 결국 2진수 덧셈(캐리 포함)으로 처리합니다. 그래서 2진수 덧셈 규칙을 이해하면, 타입 폭(8/16/32/64비트)과 오버플로, 바이트 파싱, 체크섬, 암호/해시, 멀티미디어 처리에서 생기는 문제를 훨씬 빠르게 진단할 수 있죠.

앱 개발에서 2진수 덧셈

덧셈 규칙

2진수 덧셈은 LSB(오른쪽)에서 MSB(왼쪽)로 진행하며, 합이 1을 넘으면 캐리(올림) 1을 다음 비트로 넘깁니다.

  • 0 + 0 = 0 (캐리 0)

  • 0 + 1 = 1 (캐리 0)

  • 1 + 0 = 1 (캐리 0)

  • 1 + 1 = 10 (합 0, 캐리 1)

예를 들어 001(1) + 101(5)는 LSB부터 계산해 최종 110(6)이 됩니다. 이때 핵심은 “각 자리에서 실제로는 A 비트 + B 비트 + 이전 캐리까지 3개를 더한다”는 점입니다.

비트 연산 매핑

앱 개발에서 성능이나 암호/해시를 다루다 보면, 덧셈을 논리연산으로 쪼개는 관점이 유용합니다.

  • 두 비트의 합 비트는 A XOR B

  • 두 비트의 캐리는 A AND B

실제 구현은 3비트 덧셈(전가산기)이라 캐리까지 포함해 더 복잡해지지만, “합은 XOR, 캐리는 AND에서 나온다”는 감각은 디버깅에 큰 도움을 줍니다.

타입 폭 관리

모바일 앱에서 가장 흔한 버그 유형 중 하나가 타입 폭(비트 수)을 의식하지 않은 덧셈입니다. 특히 네트워크·파일·바이너리 포맷을 다룰 때, Byte/UInt8 같은 작은 타입을 더하면 쉽게 범위를 넘습니다.

예를 들어 8비트(0~255)에서 250 + 10은 수학적으로 260이지만, 8비트에선 표현이 안 되므로 상위 비트가 잘려 결과가 달라질 수 있습니다(언어/옵션에 따라 예외, 래핑, 정의되지 않음 등).

Kotlin 사례

Kotlin/Java의 Byte는 **부호 있는 8비트(-128~127)**라, 네트워크 바이트를 그대로 더하면 예상과 다른 값이 나옵니다. 따라서 바이트를 합산하거나 길이를 계산할 때는 보통 toInt() and 0xFF로 승격해 처리합니다.

val b1: Byte = 0xFA.toByte() // 250로 보이지만 Byte로는 음수
val b2: Byte = 0x0A.toByte() // 10

val sum = (b1.toInt() and 0xFF) + (b2.toInt() and 0xFF) // 260

Swift 사례

Swift는 기본 UInt8 덧셈에서 오버플로 시 런타임 에러가 날 수 있고, “래핑(wrapping) 덧셈”이 필요하면 &+를 씁니다.

let a: UInt8 = 250
let b: UInt8 = 10
let wrap = a &+ b   // 4 (260 mod 256)
let clamp = min(255, Int(a) + Int(b)) // 255 (포화 덧셈)

앱에서는 “래핑이 맞는 상황”과 “오버플로를 막아야 하는 상황”을 명확히 구분해야 합니다.

프로토콜 파싱

앱에서 커스텀 TCP/UDP 프로토콜, BLE 패킷, 바이너리 파일 포맷을 다루면, 길이(length)와 오프셋(offset)을 계속 더하게 됩니다. 이때 2진수 덧셈의 본질은 “캐리가 옆 비트로 전파되고, 타입 폭이 고정이면 MSB 밖은 버려진다”는 점입니다.

실무에서 흔한 패턴은 다음과 같습니다.

  • 헤더에서 payloadLength를 읽는다(보통 2바이트 또는 4바이트)

  • offset = headerSize + payloadLength를 계산한다

  • 다음 프레임 시작 위치를 찾기 위해 offset += ...를 반복한다

이때 payloadLength를 UInt16로 읽어놓고 offset도 UInt16로 유지하면, 큰 파일/큰 프레임에서 쉽게 오버플로가 납니다. 실무에서는 오프셋은 Int 또는 UInt32/UInt64로 넉넉하게 잡고, 입력 길이는 검증하는 방식이 안전합니다.

체크섬 합산

앱에서 다운로드 무결성, 스트리밍 청크 검증, IoT/센서 데이터 검증을 직접 구현할 때 체크섬이 등장합니다. 많은 체크섬이 내부적으로 “바이트/워드를 더해서” 값을 만들며, 이 덧셈은 흔히 모듈러(래핑) 덧셈입니다. 즉 “타입 폭을 넘어가는 캐리는 버리고 계속 더한다”는 방식이 자주 쓰입니다.

대표적으로 16비트 단위 합산을 할 때는, 16비트 밖으로 나간 캐리를 다시 아래로 접어 넣는(캐리 래핑) 형태가 등장합니다. 이 구조를 이해하려면 “캐리는 MSB 밖으로 나가면 끝이 아니라, 규칙에 따라 다시 더해질 수도 있다”는 관점이 필요합니다.

색상 채널

이미지 처리에서 픽셀은 보통 ARGB/RGBA처럼 각 채널이 8비트(0~255)입니다. 이 상태에서 밝기 증가, 블렌딩, 누적 합산을 하면 **오버플로 또는 클리핑(포화)**을 반드시 고려해야 합니다.

  • 잘못된 접근: UInt8끼리 바로 더해서 래핑 발생(색이 갑자기 어두워지거나 이상한 톤)

  • 올바른 접근: Int로 승격해 더한 뒤 0~255로 클램프

예를 들어 “하이라이트를 더한다” 같은 기능을 만들 때, 덧셈 결과를 그대로 8비트에 넣으면 255를 넘는 순간 다시 0 근처로 돌아가 버릴 수 있습니다. 이건 사용자 입장에서는 “필터가 망가진 것”처럼 보이는 대표적인 앱 버그입니다.

오디오 클리핑

오디오 샘플(PCM)은 16비트 또는 32비트 정수로 다뤄지는 경우가 많고, 믹싱은 샘플을 더하는 작업입니다. 여기서도 덧셈은 2진수 덧셈이며, 범위를 넘으면 “왜곡”이 생깁니다.

  • 래핑 오버플로: 파형이 뒤집히며 거친 노이즈가 증가

  • 포화 덧셈(클리핑): 최대/최소값에서 눌려 왜곡은 있지만 상대적으로 예측 가능

오디오 엔진을 직접 다루지 않더라도, 간단한 녹음/합성/이펙트 앱에서는 이 문제가 현실적으로 발생합니다.

암호 해시

현대 암호/해시/PRNG 계열 구현에는 mod 2^32 또는 mod 2^64 형태의 덧셈이 빈번하게 등장합니다. 즉 “32비트/64비트에서 오버플로는 버그가 아니라 설계”인 경우가 있습니다. 이런 코드를 앱에서 직접 작성하거나 포팅할 때, 일반 덧셈(+)과 래핑 덧셈의 차이를 모르면 결과가 완전히 달라집니다.

실무 포인트는 단순합니다. 해당 알고리즘이 “래핑을 전제로 한다면” 언어에서 래핑 덧셈을 명시해야 하고, 반대로 금융/통계처럼 “정확한 합”이 목적이면 타입을 넉넉하게 잡고 오버플로를 방지해야 합니다.

플래그 조합

앱 개발에서 상태를 비트 플래그로 관리하는 경우가 많습니다(권한, 기능 토글, 옵션 조합). 이때 플래그를 “더해서” 합치는 실수가 종종 나오는데, 덧셈은 캐리를 만들 수 있어 특정 조합에서 값이 깨집니다. 플래그 결합은 덧셈이 아니라 OR이 정석입니다.

  • 잘못: flags = flagA + flagB

  • 정석: flags = flagA or flagB (Kotlin) / flags = flagA | flagB (C계열) / Swift의 OptionSet 조합

이 실수는 “2진수 덧셈에서 캐리가 발생한다”는 사실을 모르면 더 잘 발생합니다.

오버플로 대응

앱에서 덧셈을 안전하게 다루는 방법은 상황별로 정리됩니다.

  • 사용자 금액/포인트/통계 누적: 넓은 타입(Int64/Decimal) + 입력 검증 + 범위 체크

  • 바이트/프로토콜: 승격(Int) 후 연산 + 마스킹 + 길이/오프셋 검증

  • 멀티미디어(이미지/오디오): 승격 후 포화(클램프) 또는 표준 라이브러리의 안전 함수 사용

  • 암호/해시: 래핑 덧셈을 명시적으로 사용하고, 테스트 벡터로 검증

이렇게 구분만 해도 “덧셈이 맞는데 값이 이상하다” 류의 디버깅 시간이 크게 줄어듭니다.

디버그 습관

2진수 덧셈 기반 문제는 로그만으로는 놓치기 쉽습니다. 앱 개발에서는 아래 습관이 효과적입니다.

  • 동일 값을 10진수와 16진수(HEX)로 같이 출력하기

  • 작은 타입(Byte/UInt8) 연산은 승격한 중간값을 함께 로깅하기

  • 오버플로가 설계인지 버그인지 먼저 결정한 뒤, 래핑/클램프/예외 중 하나로 정책을 고정하기

  • 테스트에서 경계값(최대값 근처) 케이스를 반드시 포함하기

결론

앱 개발에서 2진수 덧셈은 단순한 이론이 아니라 데이터가 움직이는 모든 구간에서 실제로 작동하는 핵심 원리입니다. 화면에 표시되는 숫자 합산부터 네트워크 패킷의 길이 계산, 체크섬과 해시의 누적, 이미지 픽셀과 오디오 샘플의 합성까지 결국은 고정된 비트 폭 안에서 LSB부터 캐리를 전달하며 더하는 방식으로 수렴합니다.

문제가 되는 지점은 대부분 비트 폭의 한계를 무시할 때 발생합니다. 작은 타입(Byte, UInt8, UInt16)에서의 덧셈은 오버플로가 쉽게 발생하고, 언어별로 예외가 나거나 값이 래핑되는 등 결과가 달라져 버그로 이어집니다. 반대로 암호·해시처럼 모듈러 덧셈이 설계인 영역에서는 오버플로가 의도된 동작이므로 래핑 덧셈을 명시하고 테스트 벡터로 검증해야 합니다.

결국 실무에서 중요한 것은 덧셈 자체보다 정책입니다. 이 덧셈이 정확한 합을 보장해야 하는지, 래핑이 맞는지, 포화(클램프)가 맞는지 먼저 결정하고, 그에 맞는 타입 선택과 변환, 경계값 테스트를 고정하면 2진수 덧셈 기반 오류는 대부분 예방할 수 있습니다.

검증 기준과 참고 자료

이 글은 2026-09-08에 아래 공식 문서와 공개 기술 문서를 기준으로 내용과 용어를 다시 검수했습니다. 제품 버전과 기기 제조사에 따라 화면 이름은 달라질 수 있으므로 실제 화면과 공식 문서를 함께 확인하세요.

관련 글