2진수→텍스트 변환에서 엉뚱한 문자가 나오는 이유

1과 0의 나열은 모호할 게 없어 보입니다. 2진수니까 해석할 여지가 없는 것 같죠. 하지만 실제로 2진수→텍스트 변환은 16진수→텍스트와 정확히 같은 계열의 방식으로, 같은 근본적 이유 때문에 실패합니다. 비트의 나열은 어떻게 묶고 해석할지에 대한 여러 가정을 정하기 전까지는 텍스트가 아니고, 그 가정 중 하나만 틀려도 특정하고 진단 가능한 방식으로 틀린 출력이 나옵니다.

원인 1: 잘못된 비트 묶음 (7비트 vs 8비트)

표준 ASCII는 문자당 7비트면 충분하지만, 대부분의 2진수→텍스트 도구는 8비트 바이트를 기본값으로 씁니다. 실제 시스템에서 텍스트가 그렇게 저장되기 때문이죠. 어떤 2진수 문자열이 7비트 묶음을 가정하고 생성됐는데(일부 교과서 예제와 오래된 시스템은 아직 그렇습니다) 8비트 바이트로 디코딩하면, 모든 문자가 하나도 빠짐없이 밀려서 나옵니다. 묶음 경계가 첫 비트부터 틀렸기 때문에, 처음엔 멀쩡하다가 중간부터 망가지는 게 아니라 출력 전체가 균일하게 깨집니다.

단서: 출력의 문자가 일부가 아니라 말 그대로 전부 틀렸다면, 무엇보다 먼저 비트 묶음 가정을 확인하세요.

원인 2: 비트 하나가 남거나 빠지면 그 뒤가 전부 밀린다

16진수의 홀수 자릿수에 해당하는 2진수판 문제입니다. 엇나간 0이나 1 하나(복사-붙여넣기에서 딸려 온 여분의 문자, 빠진 숫자, 데이터로 파싱된 공백)가 그 지점 이후 모든 묶음의 바이트 경계를 밀어 버립니다. 원인 1과 달리 이 경우 텍스트는 어느 지점까지는 올바르다가 그 뒤부터 깨집니다. 인코딩 방식 전체가 틀린 게 아니라 문자열 어딘가에서 비트 개수 자체가 어긋났다는 강력한 신호입니다.

먼저 전체 비트 수를 세어 보세요. 문자열 길이는 8(또는 7비트 묶음임을 확인했다면 7)의 정확한 배수여야 합니다. 그렇지 않다면 버그는 디코더가 아니라 남거나 빠진 그 비트입니다.

원인 3: 문자 인코딩, 16진수 때와 정확히 동일

비트가 올바르게 바이트로 묶였더라도, 그 바이트 값이 문자로서 무엇을 의미하는지는 여전히 정해야 합니다. UTF-8, ASCII, Latin-1처럼요. 16진수→텍스트의 경우와 동일합니다. 다중 바이트 UTF-8 문자(악센트 붙은 글자, 기호, 비라틴 문자)를 각 바이트가 독립된 문자인 것처럼 한 바이트씩 디코딩하면, 올바른 한 글자 자리에 두세 개의 깨진 기호가 나옵니다. 비트 묶음이 올바른 게 확인됐고(원인 1과 2 배제) 출력이 비ASCII 문자 주변에서만 여전히 틀리다면, 거의 언제나 남은 원인은 이것입니다.

원인 4: 엔디언 — 텍스트가 아닌 숫자를 나타내는 2진수의 경우

2진수 문자열이 문자 데이터가 아니라 숫자 값 — 길이 접두사, 체크섬, 텍스트 옆에 박힌 ID — 을 인코딩한다면, 비트/바이트 순서가 중요해지고 보편적인 기본값은 없습니다. 단독 바이트로서의 00000001은 모호하지 않지만, 다중 바이트 숫자 값은 생성한 시스템에 따라 최상위 바이트부터 저장될 수도, 최하위 바이트부터 저장될 수도 있습니다. 잘못된 가정으로 읽으면 눈에 띄는 에러 대신, 그럴듯해 보이지만 틀린 다른 숫자가 조용히 나옵니다.

순서대로 진단하기

전체 비트 수가 가정한 묶음 크기(보통 8)의 정확한 배수인지 확인하세요. 어긋난 개수는 원인 2를 뜻하니 입력부터 고치세요.
처음부터 모든 문자가 균일하게 틀렸다면, 인코딩을 건드리기 전에 묶음 크기 자체(원인 1)를 의심하세요.
처음엔 깨끗하다가 중간부터 망가진다면, 인코딩 문제가 아니라 그 위치의 남거나 빠진 비트(원인 2)를 정확히 가리키는 겁니다.
묶음과 비트 수가 모두 정상인데 비ASCII 문자만 틀려 보인다면 문자 인코딩(원인 3)입니다.
데이터가 텍스트가 아닌 숫자를 나타내고 값이 그럴듯해 보이지만 틀렸다면, 변환 로직 자체가 고장 났다고 단정하기 전에 바이트 순서(원인 4)를 확인하세요.

16진수 때와 마찬가지로 변환 단계 자체는 사소합니다. 진짜 버그는 거의 언제나 변환 코드가 아니라 이 네 가지 가정 중 하나에 살고 있습니다.