로그는 멀쩡한데 파일이 안 열릴 때 찾게 되는 프로그램
업무 중에 가장 난감한 순간 중 하나는 파일 확장자는 맞는데 내용이 깨졌을 때다. 문서라면 다시 받으면 되지만, 장비에서 뽑아온 설정 백업 파일이나 특정 프로그램의 바이너리 설정값은 그렇게 단순하지 않다. 겉으로는 *.bin이나 *.dat 파일인데 메모장으로 열면 글자가 다 깨지고, 어떤 값이 바뀌었는지 감도 오지 않는다.
처음에는 메모장++, VS Code 확장, 간단한 변환 툴 정도로 버텨봤다. 텍스트 일부를 찾는 데는 되지만 바이트 단위로 정확히 고쳐야 할 때는 금방 한계가 왔다. 특히 2MB짜리 설정 파일 두 개를 비교하면서 00 01이 00 00으로 바뀐 지점을 찾아야 할 때, 일반 편집기로는 시간만 쓰고 확신은 못 얻는 식이었다.
그때 찾게 된 게 HxD였다. 이름만 보면 개발자용 특수 도구 같지만, 막상 써보면 파일이 왜 안 열리는지, 어디가 달라졌는지, 무엇을 고쳐야 하는지 확인하는 흐름이 꽤 명확하다. 기능이 많은 편인데도 첫 화면이 과하게 복잡하지 않아서, 급하게 파일 한 개 열어 확인해야 하는 상황에서도 진입 장벽이 낮았다.
먼저 해본 우회 방법과 왜 답답했는가
처음 시도한 방법은 두 가지였다. 하나는 메모장++의 헥스 보기 플러그인 계열이고, 다른 하나는 명령줄에서 fc /b 같은 바이너리 비교였다. 둘 다 아주 못 쓸 정도는 아니었지만, 손이 자꾸 꼬였다.
메모장++ 쪽은 텍스트 편집기 감각으로 접근할 수 있다는 장점이 있었다. 다만 큰 파일에서 스크롤과 선택이 매끄럽지 않았고, 어느 바이트를 수정했는지 추적하기가 애매했다. 수정 후 표시가 확실하지 않아서, 내가 바꾼 값인지 원래 다른 값이었는지 다시 확인하는 데 시간을 더 썼다.
명령줄 비교는 더 건조했다. 예를 들어 18MB짜리 펌웨어 덤프 두 개를 비교하면 차이 위치는 나오는데, 그 바이트 앞뒤 문맥을 한 화면에서 읽기 어렵다. 숫자 오프셋만 보고 다시 다른 툴로 열어 점프해야 했고, 한 번에 끝나는 일이 거의 없었다. 파일 하나 확인하려다 비교 -> 위치 메모 -> 다시 열기 -> 이동 -> 수정 -> 저장 전 재확인 순서로 5단계 이상을 반복하게 되니, 단순 작업도 피로도가 높아졌다.
바꿔야겠다고 느낀 결정적인 이유는 실수 비용 때문이었다. 장비 설정 파일은 1바이트만 잘못 건드려도 통째로 읽히지 않을 수 있는데, 우회 조합은 수정 이력과 위치 확인이 약했다. 빠른 것보다 덜 불안한 쪽이 필요했고, 그 기준에서 HxD가 맞았다.
HxD를 고른 이유와 대안 비교
선택 기준은 화려한 분석 기능이 아니라 세 가지였다. 큰 파일을 안정적으로 열 것, 바이트 단위 수정이 명확할 것, 비교와 검색이 한 흐름으로 이어질 것. HxD는 여기서 균형이 괜찮았다.
가장 먼저 체감한 건 화면 구성이다. 왼쪽에는 오프셋, 가운데는 헥스 값, 오른쪽에는 문자 표현이 같이 보인다. 텍스트처럼 읽히는 구간과 순수 바이너리 구간이 한눈에 분리돼서, 파일 구조를 감으로 파악하기 좋다. 수정된 바이트가 색으로 표시되는 점도 단순하지만 꽤 중요했다. 실무에서는 “뭘 바꿨는지”보다 “내가 지금 뭘 바꿔놨는지”를 잃지 않는 게 더 중요할 때가 많다.
비교 대상으로는 010 Editor와 WinHex도 한 번씩 검토했다. 010 Editor는 템플릿 기반 분석이 강해서 파일 포맷 구조를 깊게 파고들 때 좋다. 반대로 말하면, 구조 분석까지 필요 없는 단순 패치 작업에는 약간 무겁게 느껴질 수 있다. WinHex는 기능 범위가 넓고 디스크 쪽 작업에 강하지만, 가벼운 파일 수정만 필요한 사람에게는 메뉴와 옵션이 다소 부담스럽다.
정리하면 이렇다. 파일 구조 연구나 포맷 리버스에 비중이 크면 010 Editor가 더 잘 맞을 수 있다. 디스크 포렌식이나 저장장치 단위 작업 비중이 높다면 WinHex 쪽이 앞선다. 반면 설정 파일 수정, 바이너리 비교, 값 치환, 간단한 메모리 확인처럼 반복적으로 손이 가는 작업은 HxD가 더 직선적이다. 과장 없이 말해, 켜서 바로 쓰기 좋았다.
내가 자주 쓰는 작업 흐름: 비교부터 수정까지
가장 많이 쓴 흐름은 “정상 파일과 문제 파일 비교 -> 차이 확인 -> 필요한 바이트만 수정 -> 다시 저장”이다. 예를 들어 동일한 프로그램에서 생성된 config.dat 두 개가 있고, 하나만 실행 오류를 낸다고 가정하자. HxD에서 두 파일을 열고 비교 기능으로 차이 구간을 먼저 잡는다.
실제 순서는 단순하다. 분석 계열 메뉴에서 비교 기능을 실행하고 두 파일을 지정한다. 차이 위치가 잡히면 해당 오프셋으로 이동해서 앞뒤 값을 함께 본다. 여기서 중요한 건 한 바이트만 보지 않고 주변 16~32바이트 정도를 같이 보는 일이다. 설정 플래그 하나가 바뀐 건지, 길이 값과 체크값이 같이 틀어진 건지 구분이 되기 때문이다.
수정 단계에서는 입력 모드를 헥스 기준으로 두고 필요한 값만 바꾼다. 숫자를 바로 넣을 수 있어 텍스트 인코딩 문제를 신경 쓸 필요가 적다. 저장 전에는 수정된 부분이 색으로 남아 있어서 마지막 검토가 빠르다. 내 경우 6MB 로그 캐시 파일에서 문제 지점 3곳을 찾고 바꾸는 데 10분 남짓 걸렸는데, 같은 일을 우회 조합으로 했을 때는 25분 이상 걸렸고 중간에 위치를 한 번 놓쳤다.
여기서 작은 차이가 꽤 크게 느껴진다. 한 번 수정하고 끝나는 파일보다, 비슷한 패턴의 바이너리 파일을 주기적으로 다루는 경우가 그렇다. 매번 오프셋 확인과 저장 전 점검이 반복되는데, 이 과정이 짧아지면 작업 속도보다 피로가 먼저 줄어든다.
검색과 치환, 배치성 작업에서 체감한 부분
헥스 에디터를 쓸 일이 생기면 많은 사람이 “한두 바이트만 고치는 프로그램 아닌가”라고 생각한다. 그런데 실사용에서는 검색과 치환 비중이 더 높았다. 특정 텍스트 시그니처, 정수값, 부동소수점 값, 혹은 반복되는 패턴을 찾아내는 일이 의외로 자주 생긴다.
예를 들어 장비에서 추출한 BIN 파일 12개를 확인하면서 특정 헤더 문자열과 체크섬 직전 패턴을 찾은 적이 있다. HxD에서는 검색 조건을 바이트 값이나 텍스트로 바꿔가며 볼 수 있어, “문자열로는 안 보이는데 실제 값은 있나”를 빠르게 확인하기 좋았다. 파일 하나가 40MB 안팎이었는데, 적어도 탐색 자체가 버벅여서 흐름이 끊기진 않았다.
파일 분할과 병합도 생각보다 실용적이다. 4GB에 가까운 이미지 파일을 통째로 옮기기 어려운 환경에서는 분할 기능이 한 번씩 필요하다. 입력 파일 지정 후 분할 크기를 정하고 실행하면 001, 002 식으로 잘라진다. 반대로 합칠 때도 순서만 맞으면 다시 이어 붙일 수 있어, 외부 유틸리티를 찾을 필요가 없었다.
자동 백업도 사소해 보여도 중요하다. 헥스 편집은 실수했을 때 원상복구가 텍스트 문서보다 어렵다. 한 번 덮어쓴 뒤 바뀐 오프셋을 기억 못 하면 답이 없다. 저장 전에 백업본이 남는 설정은 시간을 절약한다기보다 사고를 줄여준다. 일 잘 되는 도구보다 사고 안 나는 도구가 오래 남는데, HxD는 그쪽 성격이 강하다.
메모리 열기 기능은 강력하지만, 누구나 바로 써야 하는 건 아니다
메모리(RAM) 열기 기능은 이름만 보면 가장 눈에 띄지만, 모든 사용자에게 필요한 기능은 아니다. 실행 중인 프로세스를 열어 특정 값을 확인하거나 바꿀 수 있다는 점은 분명 강력하다. 다만 파일 수정과 달리 잘못 건드렸을 때 프로그램이 바로 비정상 동작할 수 있어서, 목적이 분명할 때만 쓰는 편이 낫다.
내가 써본 사례는 캐시 값이 메모리에 어떻게 잡히는지 확인하는 정도였다. 프로세스를 열고, 알려진 문자열이나 숫자를 검색한 뒤, 반복 갱신되는지 보는 식이다. 여기서 중요한 건 결과가 한 번에 안 나온다는 점이다. 값이 복사본으로 여러 군데 존재할 수 있고, 10진수로 보던 값이 실제로는 리틀 엔디언 바이트 배열로 저장될 수도 있다. 처음부터 수정까지 가기보다, 검색 -> 후보 확인 -> 변화 관찰 -> 필요한 경우에만 수정 순서로 가야 실수를 줄인다.
그래서 추천 대상을 나누게 된다. 파일이 깨졌거나 바이너리 설정값을 조정해야 하는 사람에게는 진입 가치가 높다. 반면 메모리 패치까지 기대하고 설치하는 사람이라면, 시스템 구조나 프로세스 메모리 개념이 없을 때 금방 벽을 느낄 수 있다. 기능이 있다는 것과 바로 유용하다는 건 다르다.
그래서 누구에게 맞고, 어디서 멈추는가
HxD의 장점은 만능이라서가 아니라, 손이 자주 가는 바이너리 작업을 과하게 비틀지 않고 처리하게 해준다는 데 있다. 파일 비교, 특정 오프셋 이동, 값 수정, 저장 전 확인, 백업 유지까지 이어지는 흐름이 단순하다. 업무 중간에 잠깐 열어 문제 파일을 확인해야 할 때 특히 강했다.
반대로 한계도 분명하다. 파일 포맷을 구조적으로 해석해주는 템플릿 시스템까지 기대하면 부족할 수 있고, 메모리 수정은 초보자에게 친절한 영역이 아니다. 텍스트 편집기처럼 의미 단위로 설명해주지 않기 때문에, 바이트를 건드리는 이유를 모르면 화면만 보고 멈추게 된다.
추천할 사람은 이렇다. JPG, PNG, BIN, DAT, ZIP 같은 파일을 열어 헤더나 특정 값 확인이 필요한 사람, 정상본과 문제본을 비교해 원인을 좁혀야 하는 사람, 외부 툴 여러 개를 이어 붙이는 작업이 귀찮아진 사람에게 맞다. 반대로 파일 포맷을 깊게 분석해야 하거나, 처음부터 메모리 해킹 성격의 작업만 기대하는 사람에게는 첫 선택지가 아닐 수 있다. 내가 굳이 권하지 않을 상황도 있다. 텍스트 기반 설정 파일만 다루고 있고, 바이트 단위 수정이 전혀 필요 없다면 HxD까지 갈 이유는 없다. 그럴 때는 기존 편집기가 더 빠르다.