Mac에서 대용량 SQL 덤프 파일 여는 방법 (충돌 없이)

운영 데이터베이스 덤프는 손쉽게 수십 기가바이트에 이를 수 있습니다. 이를 일반 텍스트 에디터에서 여는 순간 Mac의 팬이 돌기 시작하고, 무지개 커서가 나타나며, 결국 앱이 종료됩니다. 때로는 다른 창의 저장하지 않은 작업까지 함께 날아갑니다.

에디터가 대용량 덤프에서 버벅이는 이유

VS Code, TextEdit, Sublime Text 같은 에디터들은 즉시 스크롤, 검색, 하이라이트를 하기 위해 파일 전체를 메모리에 로드하도록 설계되었습니다. 2MB짜리 소스 파일이라면 문제없습니다. 하지만 40GB 덤프에서는 에디터가 40GB(게다가 내부 자료구조를 위한 오버헤드까지)를 RAM에 할당하려 든다는 뜻입니다.

당신의 Mac에는 16GB 또는 32GB가 있습니다. 파일이 완전히 로드되기 훨씬 전에 시스템은 물리 메모리가 바닥나고, 디스크로 스와핑을 시작하며, 멈춰버립니다. 대부분의 에디터는 아예 거부하기도 합니다. VS Code는 전체 에디터 기능을 약 50MB에서 제한하고 기능이 축소된 모드로 전환하며, TextEdit은 그냥 멈추고, Sublime은 크래시할 때까지 메모리를 할당합니다. 설령 파일을 열더라도 구문 강조와 검색이 키를 누를 때마다 수 기가바이트를 다시 스캔합니다.

핵심 문제는 이렇습니다. 이 도구들은 문서 전체에 대한 임의 접근을 전제로 합니다. 하지만 덤프는 그럴 필요가 없습니다. 순차적인 문장 목록일 뿐입니다. 그저 스트리밍으로 훑기만 하면 됩니다.

커맨드라인 방식

Mac의 Unix 도구들은 이미 스트리밍 방식이라 파일 전체를 로드하지 않습니다. 이것이 고전적인 첫 번째 수단입니다:

# 파일 전체를 열지 않고 처음과 마지막 줄만 살짝 보기
head -n 50 dump.sql
tail -n 50 dump.sql

# 덤프를 part_aa, part_ab, ... 로 이름 붙은 100MB 조각으로 분할
split -b 100m dump.sql part_

# 두 마커 사이에서 한 테이블 블록만 뽑아내기
sed -n '/CREATE TABLE `users`/,/UNLOCK TABLES/p' dump.sql > users.sql

이 방법은 동작하지만 취약하고 번거롭습니다. split -b는 원시 바이트 경계에서 자르므로 INSERT 문 한복판을 그대로 잘라버립니다. 그렇게 나온 조각들은 그 자체로는 유효한 SQL이 아닙니다. sed 범위 트릭은 특정 덤프 도구가 마침 내보내는 정확한 마커에 의존합니다. MySQL 버전을 바꾸거나 PostgreSQL로 전환하면 패턴이 더 이상 맞지 않습니다. 게다가 이 중 어느 것도 파일 안에 실제로 무엇이 들어 있는지 보여주지 않습니다. 30GB짜리 테이블이 어느 것인지 짐작으로 알아낸 다음에야 겨우 겨냥할 수 있습니다.

DumpCleaner로 열고 필터링하기

DumpCleaner는 바로 이 파일 크기를 위해 만들어졌습니다. 커맨드라인처럼 덤프를 스트리밍하되 SQL 구조를 이해하므로, 진짜 테이블 목록과 문장 단위로 안전한 출력을 얻습니다:

1. 파일을 끌어다 놓습니다. DumpCleaner는 덤프를 약 1MB 단위 청크로 스트리밍해서 엽니다. 50GB 파일도 대략 50MB의 RAM으로 열리므로 아무것도 멈추지 않습니다.
2. 모든 테이블을 봅니다. 덤프를 스캔해 각 테이블을 크기와 함께 목록으로 보여주므로, 어느 것이 파일을 부풀리는지 즉시 알 수 있습니다.
3. 필요 없는 것을 선택 해제합니다. 거대한 로그, 세션, 분석 테이블의 체크를 해제하세요. DumpCleaner는 문장 전체를 온전히 유지합니다. 반쯤 잘린 INSERT는 없습니다.
4. 내보냅니다. 마침내 여유롭게 열리고 가져올 수 있는 더 작은 .sql 파일을 새로 씁니다. 원본 파일은 절대 수정되지 않습니다.

50GB 이상의 덤프를 일정한 메모리로 처리하기 때문에 Mac의 RAM은 신경 쓸 필요가 전혀 없습니다. 그리고 원본을 읽어 별도의 출력 파일에 쓰기 때문에, 시작할 때의 덤프는 그대로 남습니다.

자주 묻는 질문