이거 하나면 될 줄 알았는데, 결국 몇 번은 다시 열게 됐다

처음에 HxD를 만진 건 거창한 이유는 아니고, 그냥 파일 하나를 빨리 뜯어봐야 해서였다. 프로그램 설정 파일이 평범한 텍스트는 아니고, 그렇다고 전용 툴을 찾아 깔기엔 일이 너무 커질 것 같았다. 예전에는 이런 거 보면 바로 다른 사람이 만들어둔 패처나 전용 에디터부터 찾았는데, 이번엔 그냥 내가 직접 확인하는 게 더 빠르겠다는 생각이 들었다.

사실 헥스 에디터는 이름부터 좀 부담스럽다. 괜히 잘못 건드리면 파일 하나 통째로 망가뜨릴 것 같고, 화면도 숫자 투성이라 처음엔 손이 잘 안 간다. 그런데 HxD는 막상 열어보면 생각보다 덜 위협적이다. 인터페이스가 복잡하게 덕지덕지 붙어 있지 않고, 파일 여러 개를 탭으로 열어두고 비교하기도 편해서 일단 시작은 쉬웠다.

문제는 시작이 쉬운 거랑, 실제로 원하는 지점을 정확히 찾는 건 또 다른 얘기라는 점이었다. 이번에 그걸 꽤 여러 번 느꼈다. 그래도 중간에 막히면서 같이 알게 된 것들이 좀 있어서, 결과만 말하면 “쓸 만했다”인데 과정은 꽤 돌아갔다.

처음엔 그냥 텍스트 좀 보려던 거였다

처음 열었던 파일은 게임 쪽 데이터 파일 비슷한 거였는데, 메모장으로 열면 당연히 글자가 다 깨졌다. 그래서 아예 헥스로 보면 뭔가 패턴이 보이지 않을까 싶었다. HxD로 열자마자 왼쪽엔 16진수 값이 쭉 나오고 오른쪽엔 ASCII 영역이 보여서, 어디쯤 사람이 읽을 수 있는 문자열이 있는지 대충 감이 왔다.

여기서 첫 번째로 좋았던 건 검색이었다. 그냥 막 스크롤하는 건 의미가 없어서, 아는 문자열 몇 개를 검색해봤다. 파일 구조를 모를 때는 이런 식으로 앵커를 먼저 찾는 게 생각보다 도움이 된다. 텍스트가 조금이라도 남아 있으면 그 주변을 기준으로 앞뒤 패턴을 볼 수 있어서, 무작정 바이트를 세는 것보다 훨씬 덜 막막하다.

다만 이때 첫 번째 시행착오가 바로 나왔다. 나는 당연히 오른쪽 문자열 영역에 보이는 글자 기준으로 찾으면 될 줄 알았는데, 인코딩이 섞여 있거나 문자열이 중간에 끊겨 있으면 생각보다 검색 결과가 안 잡혔다. 처음엔 파일이 압축됐나 싶어서 괜히 다른 툴까지 찾았다.

결국 다시 돌아와서 검색 옵션을 바꿔봤다. 텍스트 검색만 고집하지 말고, 헥스 값 기준으로도 찾아보니까 바로 잡히는 구간이 있었다. 이때 좀 체감한 게, HxD는 단순히 “파일을 숫자로 보는 창”이 아니라 검색 방식 바꾸는 것만으로도 작업 흐름이 꽤 달라진다는 점이었다. 비슷한 일 할 때 텍스트가 안 잡히면 바로 포기하지 말고 값 자체로 찾는 쪽도 같이 보는 게 낫다.

빨간색 표시가 의외로 제일 도움 됐다

일단 수정할 만한 위치를 찾고 나서는 몇 바이트를 바꿔봤다. 아주 작은 값 하나만 바꾸는 작업이었는데, 이런 게 더 무섭다. 바꾸는 건 1초인데, 나중에 어디를 건드렸는지 잊어버리면 다시 처음부터 봐야 한다.

HxD에서 수정된 부분이 빨간색으로 표시되는 건 알고는 있었는데, 이게 실제로 해보니까 예상보다 훨씬 유용했다. 특히 여러 군데를 조금씩 만질 때 “내가 방금 건드린 곳”과 “원래부터 이런 값이던 곳”이 구분되는 게 크다. 헥스 편집은 화면이 다 비슷비슷해서, 잠깐 다른 파일 보고 오면 금방 헷갈린다.

여기서 두 번째 시행착오가 있었다. 나는 처음에 값을 하나 바꾸고 바로 저장한 뒤 실행해서 확인하는 방식으로 갔다. 그런데 한 번은 너무 성급하게 저장해서 원본 상태를 다시 비교하기 애매해졌다. 자동 백업이 있어서 완전히 망하진 않았지만, 그 뒤로는 파일을 복사본으로 하나 더 두고 작업했다.

이건 HxD만의 팁이라기보다 이런 류 작업 전체에 해당하는 얘기인데, 수정 전 원본 하나, 실험용 하나, 아예 다른 시도용 하나 이렇게 최소 두세 개로 분리하는 게 정신 건강에 좋다. 특히 값이 하나만 다를 때는 뭐가 문제인지 찾기 쉬울 것 같지만, 막상 아니었다. 한 번 꼬이면 “이게 원래 이랬나? 내가 건드렸나?”가 바로 시작된다.

찾기는 찾았는데, 내가 고른 값이 틀렸던 구간

가장 시간을 많이 쓴 건 사실 기능을 몰라서가 아니라, 내가 뭘 바꿔야 하는지 잘못 짐작했던 부분이었다. 어떤 설정값처럼 보이는 바이트를 찾아서 바꿨는데, 결과가 전혀 예상과 다르게 나왔다. 처음엔 프로그램이 그 값을 체크섬으로 검증하나 싶었고, 그래서 괜히 파일 비교나 체크섬 계산 쪽도 좀 봤다.

그런데 한참 뒤에 보니 문제는 더 단순했다. 내가 보고 있던 값이 실제 설정값이 아니라 표시용 캐시 비슷한 데이터였던 거다. 즉, 눈에 띄는 숫자 하나 찾았다고 바로 답이 아니었다. 이건 파일 포맷을 정확히 모를 때 자주 생기는 실수인 것 같다. “이상하게 그럴듯한 값”이 제일 위험하다.

그래서 방향을 바꿨다. 바로 원하는 값처럼 보이는 걸 찍어서 바꾸는 대신, 원본 파일 두 개를 만들고 프로그램 안에서 설정을 하나만 다르게 저장한 뒤 그 둘을 비교했다. 이 방식은 돌아가는 것 같아 보여도 오히려 시간을 줄여줬다. 어떤 바이트가 실제로 달라지는지 보면 감으로 찾는 것보다 훨씬 정확하다.

HxD에서 파일 비교 기능을 쓸 때 좋았던 건, 단순히 다르다/같다만 보는 게 아니라 어디 구간이 어떻게 달라졌는지 훑기가 편하다는 점이었다. 물론 구조 분석 툴처럼 친절한 건 아니지만, “설정 하나 바꿨더니 여기만 달라졌네”를 확인하기엔 충분했다. 이때부터는 괜히 모든 걸 한 번에 이해하려 하기보다, 바뀌는 부분만 좁혀서 보는 쪽으로 생각이 바뀌었다.

메모리까지 열어본 건 좀 욕심이었다

중간에 한 번은 파일이 아니라 실행 중인 프로그램 메모리 쪽도 건드려볼까 싶었다. 설명만 보면 HxD가 메모리 편집도 된다고 해서, 파일에 저장되지 않는 임시 값도 잡을 수 있지 않을까 기대했다. 실제로 프로세스를 열 수 있는 건 꽤 신기했고, 처음엔 “이제 더 빨리 찾겠는데” 싶었다.

그런데 여기서 세 번째로 크게 막혔다. 파일은 적어도 저장-비교-복구 흐름이 있는데, 메모리는 값이 실시간으로 바뀌거나 여러 번 복제돼 있어서 생각보다 훨씬 헷갈렸다. 내가 찾은 값이 진짜 그 값인지, 표시용인지, 잠깐 계산에 쓰는 건지 구분이 잘 안 됐다.

결국 이쪽은 오래 안 붙잡고 접었다. 메모리 편집 자체가 나쁘다기보다, HxD 하나만으로 끝내려는 내 욕심이 컸다. 메모리 값 추적은 오히려 전용 디버거나 스캔 도구가 더 맞는 경우가 많다. HxD는 “볼 수 있다, 급하면 수정도 된다” 정도로는 충분히 좋지만, 상태 추적까지 깊게 들어가면 다른 도구가 편하다.

그래도 이 시도 덕분에 기준은 좀 생겼다. 파일 구조 확인, 고정된 데이터 수정, 바이트 단위 비교는 HxD가 생각보다 편했고, 반대로 실시간 동작 분석은 다른 툴을 섞는 게 낫다. 이 구분이 생기니까 괜히 한 도구에 모든 걸 기대하지 않게 됐다.

디스크 이미지 쪽은 편했는데, 그래서 더 조심하게 됐다

파일 하나 수정하는 데 익숙해지고 나니까, 예전에 미뤄뒀던 디스크 이미지 안쪽 확인도 해봤다. 이것도 처음엔 “열리기만 하면 대충 보이겠지” 싶었는데, 막상 열리니까 영역이 워낙 커서 괜히 손대기가 더 무서웠다. 파일은 망가져도 한 개지만, 디스크 쪽은 잘못 건드리면 범위가 커진다.

다행히 HxD는 큰 파일이나 이미지도 꽤 안정적으로 여는 편이었다. 이런 부분은 확실히 인상이 좋았다. 느리게 버벅거리면 작업하다가 집중이 끊기는데, 적어도 보는 단계에서는 답답함이 덜했다. 여러 탭으로 원본과 수정본을 같이 띄워두는 것도 여기서 꽤 유용했다.

다만 여기서도 한 번 돌아갔다. 처음엔 이미지 전체에서 문자열 검색만으로 필요한 구간을 찾으려 했는데, 결과가 너무 많거나 전혀 안 나오거나 둘 중 하나였다. 결국 섹터 경계나 파일 시그니처 쪽을 같이 봐야 했다. PNG면 89 50 4E 47, ZIP이면 50 4B처럼 익숙한 시그니처 몇 개라도 알고 있으면 찾는 속도가 달라진다.

이건 실무에서도 꽤 쓸모가 있다. 꼭 복구 작업이 아니어도, “이 파일이 실제로 뭐가 들어 있는지” 확인할 때 확장자만 믿기 어려운 경우가 있다. 그럴 때 헥스에서 헤더 몇 바이트만 확인해도 감이 온다. 너무 설명글처럼 말하긴 싫지만, 이런 건 한 번 써보면 의외로 자주 쓰게 된다.

다른 툴이 더 나은 순간도 분명 있었다

쓰다 보니 HxD가 만능처럼 느껴질 때도 있었는데, 막상 몇 번 부딪히고 나니까 선이 좀 보였다. 예를 들어 단순 치환이나 빠른 검색은 충분히 편한데, 구조화된 바이너리를 본격적으로 해석하려면 전용 분석 툴이 더 낫다. 필드 이름이 보이고 타입까지 따라가 주는 쪽이 당연히 편하다.

반대로 전용 툴이 더 불편한 순간도 있었다. 괜히 형식을 너무 많이 알아서, 내가 보고 싶은 원시 데이터보다 “해석된 결과”를 앞세우는 경우가 있다. 그럴 땐 오히려 HxD처럼 날것 그대로 보는 쪽이 편하다. 해석기가 틀릴 수도 있고, 지원하지 않는 포맷이면 더 답답해진다.

파일 분할이나 병합 같은 기능도 한 번 써봤는데, 자주 쓰진 않아도 이런 게 한 군데 들어 있는 건 은근 편하다. 별도 유틸을 찾지 않아도 되니까. 다만 개인적으로는 이 프로그램의 핵심 장점은 부가 기능보다도, 기본 편집 흐름이 덜 거슬린다는 쪽에 더 가깝다. 여는 것, 찾는 것, 바꾸는 것, 비교하는 것까지 이어지는 과정이 무난하다.

결국 남은 건 조심해서 쓰면 꽤 든든하다는 정도

이번에 HxD를 다시 만지면서 제일 크게 바뀐 건, 예전처럼 헥스 에디터를 “최후의 수단”으로만 보지 않게 됐다는 점이다. 물론 여전히 아무 생각 없이 열 도구는 아니다. 파일 포맷을 모른 채 막 바꾸면 높은 확률로 돌아가게 된다. 나도 실제로 두세 번은 쓸데없이 멀리 갔다가 다시 왔다.

그래도 작은 수정, 차이 확인, 숨은 문자열 찾기, 헤더 확인 같은 일에는 생각보다 바로 실무에 붙는다. 특히 원본/수정본 비교하면서 바뀐 구간 좁혀가는 방식은 앞으로도 자주 쓸 것 같다. 감으로 때려 맞추는 것보다 훨씬 덜 지친다.

완전히 만족스럽냐고 하면 그건 또 아니다. 메모리 쪽은 여전히 내 기준에선 애매했고, 구조를 모르는 파일을 다룰 때는 결국 다른 도구나 문서가 필요했다. 그리고 헥스 편집 자체가 실수 비용이 큰 작업이라, 편하다고 해도 늘 긴장감은 남는다.

그래도 “이런 건 전문가만 하는 일” 정도로 겁먹을 필요는 없겠다는 생각은 들었다. 적어도 HxD는 진입할 때 불필요하게 위협적이지 않았고, 몇 번 삽질해도 다시 시도할 만한 정도의 안정감은 있었다. 아마 다른 방법으로 더 빠르게 하는 사람도 있을 것 같고, 메모리 쪽은 특히 그렇다. 비슷하게 써본 사람들 중에 더 덜 돌아가는 방식이 있으면 나도 좀 궁금하다.