RGB 값을 정규화할 때 255로 나눠야 할까, 256으로 나눠야 할까? 모두가 헷갈리는 그 문제

사소해 보이지만 사실 중요한 질문

그래픽 프로그래밍을 조금이라도 해본 사람이라면 한 번쯤 마주치는 의문이 있어요. RGB 값은 0부터 255까지의 정수인데, 이걸 0.0 ~ 1.0 사이의 실수(부동소수점)로 바꿀 때 255로 나눠야 할까, 256으로 나눠야 할까? 사소해 보이는 질문이지만, 셰이더, 이미지 처리, 머신러닝 데이터 전처리, 게임 엔진 어디에서나 끊임없이 다시 등장하는 주제예요.

사실 둘 다 "틀린" 답은 아니에요. 다만 상황에 따라 더 맞는 선택이 따로 있고, 그 이유를 모르면 나중에 미묘한 색상 차이나 정밀도 오차로 골치를 앓게 돼요. 30fps.net의 글이 이걸 수학적으로 깔끔하게 정리해줬는데, 이 글에서는 우리 식으로 풀어볼게요.

255로 나누는 경우 - 양 끝점이 정확하다

가장 흔히 보는 방식이 value / 255.0 이에요. 이렇게 하면 0은 정확히 0.0이 되고, 255는 정확히 1.0이 돼요. 이게 뭐가 좋냐면, 흰색(255,255,255)이 진짜 흰색(1.0, 1.0, 1.0) 으로, 검정(0,0,0)이 진짜 검정으로 떨어진다는 거예요. 직관적이고, 색상의 "끝값"이 정확하게 보존돼요.

OpenGL이나 Vulkan 같은 그래픽 API에서 UNORM 포맷(0~255를 0.0~1.0에 매핑하는 표준 포맷)도 이 방식을 따라요. 머신러닝 쪽에서 이미지를 정규화할 때 pixels / 255.0이 사실상 표준이 된 것도 같은 맥락이에요. 양 끝이 깔끔하고 다루기 쉬우니까요.

단점은 256개의 정수 값을 1.0이라는 구간에 등간격으로 배치할 수 없다는 점이에요. 0, 1/255, 2/255, ..., 255/255 이렇게 가는데, 간격이 1/255 ≈ 0.003921568... 처럼 깔끔한 이진수로 안 떨어져요. 부동소수점에서는 이게 미세한 누적 오차를 만들어요. 그래픽 카드 안에서 빈번하게 곱셈/덧셈이 일어나는 셰이더라면 이런 오차가 신경 쓰일 수 있어요.

256으로 나누는 경우 - 비트 시프트와 친하다

반면 value / 256.0은 "양 끝이 안 맞는다"는 직관적 단점이 있어요. 255를 256으로 나누면 0.99609... 가 되거든요. 흰색이 1.0이 되지 않으니 사람 눈에 별로 자연스럽지 않죠.

그런데 컴퓨터에게는 256이 훨씬 친해요. 256은 2의 8제곱이라서, >> 8(오른쪽 8비트 시프트)이 곧 256으로 나누기예요. 정수 곱셈 후 시프트만으로 빠르게 정규화할 수 있어요. 옛날 GPU나 임베디드 환경, 그리고 고정소수점(fixed-point) 연산을 쓰는 코드에서는 이게 결정적으로 빨라요.

또 "바이트 두 개를 합쳐서 0~65535 만들기" 같은 작업이나, 알파 블렌딩 공식에서도 256 기반 산수가 깔끔하게 떨어져요. 알파 블렌딩의 정석 공식 (a src + (255 - a) dst) / 255를 그대로 쓰면 나누기 연산이 비싸지만, 약간의 트릭으로 >> 8로 근사하면 시각적으로 거의 차이가 없으면서 훨씬 빨라요.

그래서 언제 뭘 써야 하나

실용적으로 정리하면 이래요. 셰이더, 머신러닝 전처리, 일반적인 이미지 처리에서는 / 255.0이 정답이에요. 양 끝이 깔끔하고, GPU가 부동소수점을 다루는 데 최적화돼 있어서 성능 손해도 사실상 없거든요. 흰색이 1.0이 되어야 곱셈 단위원으로 동작하기 때문에 색 공간 변환 행렬을 그대로 적용할 수 있어요.

반면 저수준 비트 연산, 고정소수점 알파 블렌딩, 옛 하드웨어 호환이 필요하면 256 기반이 유리해요. 또 (value + 0.5) / 256 같은 "중심 보정" 트릭도 자주 등장하는데, 이건 "각 정수 값이 0~1 구간의 어떤 칸 한가운데를 차지한다"고 가정하는 방식이에요. 픽셀을 점이 아니라 작은 사각형으로 보는 관점이죠.

한국 개발자에게 주는 시사점

이런 디테일이 진가를 발휘하는 순간이 있어요. 예를 들어 머신러닝 모델 학습 시에는 / 255.0으로 했는데 추론 코드에서는 / 256.0을 쓰면, 모델은 미세하게 다른 입력 분포를 보게 돼서 성능이 떨어져요. 또 셰이더에서 텍스처 한 장만 다른 정규화를 거치면 그 부분만 살짝 어둡거나 밝게 보이는 식의 버그가 생기죠.

우리 팀의 정규화 규약을 한 줄로 정해두는 것이 의외로 큰 효과를 줘요. "이 프로젝트에선 무조건 / 255.0"이라고 README에 적어두기만 해도, 협업자가 다른 코드를 짜올 때 한 번 더 확인하게 되거든요. 작은 약속이지만 후반에 디버깅 비용을 크게 줄여줘요.

마무리

결국 답은 "상황에 따라 다르지만, 90%의 경우엔 255"예요. 더 중요한 건 본인이 왜 그 선택을 하는지를 설명할 수 있는가이고요. 여러분의 코드베이스를 한 번 grep 해보면 어떨까요? / 255와 / 256이 한 프로젝트 안에 섞여 있다면, 그게 다음 디버깅의 시작점일지도 몰라요.