RGB 색상 값 변환할 때 255로 나눠야 할까, 256으로 나눠야 할까?

요약 이미지 처리 프로그램을 작성할 때 8비트 정수 RGB 값(0~255)을 부동소수점(float)으로 변환한 뒤 다시 8비트로 저장하는 과정은 매우 흔하게 쓰입니다. 이때 개발자들 사이에서 종종 논쟁이 되는 주제가 바로 '255로 나눌 것인가, 아니면 256으로 나눌 것인가'입니다. 표준적인 방식은 255.0으로 나누는 것입니다. 이 방식은 정수 0을 0.0으로, 255를 1.0으로 깔끔하게 매핑하며 GPU 하드웨어도 이 방식을 사용합니다. 0.0이 곧 완벽한 검은색을 의미하므로 직관적이고 이미지 처리 로직이 특정 비트 깊이에 종속되지 않는다는 장점이 있습니다. 반면 256으로 나누는 대안 방식은 (img + 0.5) / 256.0 공식을 사용합니다. 일부 개발자들은 표준 255 나눗셈이 수직선 상에 양 끝단(0과 255)의 구간(bin) 크기가 절반밖에 되지 않아 [0, 1] 균등 난수를 생성해 정수로 변환할 때 0과 255가 다른 숫자에 비해 절반 빈도로만 나타난다는 '양극단 축소' 문제를 지적합니다. 또한 128 / 255는 약 0.501961이지만 128 / 256은 정확히 0.5로 떨어지는 등 이진수 기반의 정확도와 심미적인 이유를 들기도 합니다. 하지만 본문 작성자는 255 나눗셈의 양극단 왜곡이나 미세한 반올림 오차(32비트 float 기준 0.00001% 미만의 지터)가 실제 이미지 처리 작업에서 손실 없는 왕복 변환(uint8 → float → uint8)을 저해하거나 문제를 일으키는 실질적인 사례를 찾기 어렵다고 분석합니다. 결국 검은색을 0.0으로 직관적으로 다룰 수 있는 255 나눗셈이 여전히 견고하고 실용적인 표준이라는 결론을 제시합니다.