Hexter vs. Hex Fiend: 어떤 Mac 16진수 편집기를 써야 할까
Mac에서 16진수 편집기를 검색해 봤다면 거의 틀림없이 Hex Fiend를 마주쳤을 것입니다. 무료에 오픈 소스이고, 거의 모든 “Mac 최고의 16진수 편집기” 목록에서 기본 추천으로 꼽힙니다. 실제로도 정말 좋은 소프트웨어입니다. 이 글은 “왜 우리 앱이 더 낫다"는 식의 글이 아닙니다. Hex Fiend가 여전히 올바른 선택인 지점과, Hexter가 의미 있게 다르게 접근하는 지점을 솔직하게 들여다보는 글입니다.
짧게 요약하면
Hex Fiend는 성숙하고 무료인 오픈 소스 도구로, 주로 대규모 파일을 다루는 원시 편집 성능을 중심으로 만들어졌습니다. Hexter는 다른 우선순위를 중심으로 만들어진 신생 앱입니다. 그저 들여다보려던 파일을 실수로 망가뜨리기 어렵게 만드는 것이 그 우선순위입니다. 자기가 뭘 하는지 이미 정확히 알고 있고 수십 기가바이트 크기의 파일을 편하게 diff하거나 편집해야 한다면, 그 용도로는 오늘날 Hex Fiend가 더 유능한 도구입니다. 기본적으로 신중하게 동작하고 흔한 파일 구조를 처음부터 이해하는 16진수 편집기를 원한다면, 그것이 바로 Hexter가 만들어진 목적입니다.
기능별 비교
| Hex Fiend | Hexter | |
|---|---|---|
| 가격 | 무료, 오픈 소스(BSD 라이선스) | 아직 Mac App Store에 출시되지 않음 |
| 대용량 파일 처리 | 파일을 메모리에 불러오지 않고 약 118 GB까지 처리 | 청크 캐시를 통해 필요할 때 바이트를 읽음. 아직 Hex Fiend 규모에서 벤치마크되지 않음 |
| 편집 안전성 | 켜거나 기본값으로 설정할 수 있는 명시적인 읽기 전용 모드가 있지만, 그 자체가 기본 상태는 아님 | 언제나 모든 파일을 읽기 전용으로 열며, 그 기본값을 바꿀 설정이 없음. 편집하려면 명시적인 토글이 필요하고, 편집 내용은 저장하기 전까지 되돌릴 수 있는 패치 레이어에 담김 |
| 덮어쓰기 보호 | 표준 저장. 문서에 별도의 백업 단계가 언급되어 있지 않음 | 원본 파일을 덮어쓰려면 확인이 필요하며 자동 백업 사본을 제공(타임스탬프가 붙은 이력이 아니라, 저장할 때마다 교체되는 단일 .hexter-backup 파일) |
| 바이너리 diff | 삽입/삭제를 인식하는 diff. 문서나 릴리스 노트 어디에도 크기 제한이 명시되어 있지 않음 | 실제 diff 알고리즘을 쓰지만, 현재 매우 큰 비교에는 상한이 있어 그 크기를 넘으면 더 거친 결과로 대체됨 |
| 내장 구조 파싱 | 상당히 큰 내장 템플릿 라이브러리(약 17개 카테고리)를 제공하지만, 템플릿을 직접 찾아 수동으로 적용해야 함 | PNG, ZIP, Mach-O, WAV, SQLite 구조를 열 때 자동으로 감지하고 파싱함. 고를 템플릿이 없음 |
| 해싱 | 내장 기능 아님 | CRC32, Adler32, MD5, SHA-1, SHA-256, SHA-512를 백그라운드에서 파일 전체에 대해 계산 |
| 문자열, 북마크, 이상 징후 감지 | 내장되지 않음 | 모두 내장: 문자열 추출, 메모가 달린 명명된 북마크, 그리고 엔트로피 급등과 의심스러운 바이트 연속, 포맷 시그니처 불일치를 찾는 스캔 |
| 인터페이스 | AppKit, 실용적, 10년 넘게 이어져 옴 | 네이티브 SwiftUI, 다크 모드, 현행 macOS를 위해 제작 |
| 확장성 | 2조항 BSD 라이선스, 다른 앱에 프레임워크로 임베드 가능 | 임베드용으로 설계되지 않음. 독립 실행형 앱 |
| 사용자 정의 바이너리 템플릿 | 템플릿 시스템을 통해 임의의 포맷을 지원 | 아직 미지원. 다섯 개의 내장 파서가 흔한 포맷을 다루지만 사용자 정의 템플릿 언어는 없음 |
Hex Fiend가 여전히 더 나은 선택인 지점
수십 기가바이트 크기의 파일, 펌웨어 덤프, 디스크 이미지, 대용량 데이터베이스 익스포트를 정기적으로 다룬다면, Hex Fiend의 메모리 모델과 그 규모에서의 실적은 반박하기 어렵습니다. diff 도구에는 문서화된 크기 제한이 없는데, 이는 대용량 바이너리를 비교하는 일이라면 중요한 점입니다. 또한 무료라는 점 자체로도 가치가 있고, 16진수 편집 컴포넌트를 임베드해야 하는 도구를 만든다면 BSD 라이선스와 프레임워크 설계 덕분에 독립 실행형 앱으로는 불가능한 방식으로 그것이 가능합니다.
Hex Fiend는 이미 상당한 내장 템플릿 라이브러리도 제공합니다. 실행 파일, 아카이브, 오디오 등을 아우르는 약 17개 카테고리라, 구조화된 포맷에서도 맨바닥부터 시작하는 것은 아닙니다. 아직 다뤄지지 않는 난해하거나 독점적인 무언가를 위한 사용자 정의 템플릿이 필요하다면, Hex Fiend의 템플릿 시스템(그리고 이 방향으로 더 나아간 010 Editor나 ImHex 같은 도구)이 해결해 줄 것입니다. Hexter의 구조 파싱은 아는 다섯 개 포맷(PNG, ZIP, Mach-O, WAV, SQLite)에 대해서는 잘 작동하지만, 직접 포맷을 정의하게 해주지는 않습니다.
Hexter가 다르게 하는 지점
핵심 차이는 기능이 아니라 기본값입니다. Hex Fiend에도 읽기 전용 모드가 있지만, 그것을 켜야 한다는 걸(또는 환경설정에서 기본값으로 설정해야 한다는 걸) 알아야 합니다. 기본 상태로는 파일을 편집 가능한 모드로 엽니다. Hexter는 언제나 모든 파일을 읽기 전용으로 열며, 그것을 바꿀 설정이 없습니다. 편집은 의도적으로 켜는 것이고, 변경 내용은 원본 파일에 반영되기 전에 검토하고 되돌릴 수 있는 패치 레이어에 담깁니다. 파일을 편집하기보다 들여다보는 데 더 많은 시간을 쓴다면, 그리고 대부분의 16진수 편집기 작업은 사실 편집이 아니라 검사라면, 그 기본값은 들리는 것보다 더 큰 의미를 갖습니다. 낯선 파일, 남의 설정 파일, 다운로드한 펌웨어 이미지, 디버깅 중인 파일을 여는 일이 스위치를 먼저 켜는 걸 기억하지 않아도 기본적으로 아무 위험이 없다는 뜻이기 때문입니다.
두 번째 차이는 Hexter가 인식하는 파일을 열었을 때 자동으로 벌어지는 일입니다. 밋밋한 16진수의 벽 대신 실제 구조를 볼 수 있습니다. 타입과 CRC가 붙은 PNG 청크 경계, ZIP 아카이브의 로컬 파일 헤더, Mach-O 바이너리의 로드 커맨드, SQLite 파일의 헤더 필드가 원시 바이트 옆에 파싱되어 나란히 놓이며, 설정은 전혀 필요 없습니다. Hex Fiend의 내장 템플릿으로도 비슷한 수준의 세부 정보를 얻을 수 있지만, 먼저 템플릿 목록을 뒤져 하나를 직접 적용해야 합니다.
그 밖에도 해싱, 문자열 추출, 이상 징후 감지(엔트로피 급등, 시그니처 불일치, 의심스러운 바이트 연속)가 Hexter에는 곧바로 내장되어 있는 반면, Hex Fiend의 세계에서는 그런 것들이 보통 별개의 도구입니다.
솔직한 추천
이미 16진수 편집기에 익숙하거나, 매우 큰 파일을 다뤄야 하거나, 오랜 실적과 활발한 커뮤니티를 갖춘 무료 도구를 원한다면 Hex Fiend를 쓰세요. 아직 완전히 신뢰하지 못하는 파일을 들여다볼 수도 있다고 전제하고, 기본적으로 그 파일에 손대지 않으며, 흔한 포맷에 대해 아무 설정 없이도 더 많은 것을 알려주는 16진수 편집기를 원한다면 Hexter를 쓰세요. 어느 쪽도 틀리지 않았습니다. 둘은 누가, 왜 쓰는지에 대한 서로 다른 전제를 중심으로 만들어졌을 뿐입니다.
Hexter는 활발히 개발 중입니다. 기본값이 읽기 전용이라는 점, 내장 구조 파싱, 현대적인 네이티브 인터페이스가 16진수 편집기에서 바라던 것처럼 들린다면, 눈여겨볼 앱입니다.