--- title: "MyISAM, MEMORY, ARCHIVE 엔진의 특징과 현대 운영에서의 제한점" description: "MySQL의 MyISAM, MEMORY, ARCHIVE 스토리지 엔진이 어떤 목적으로 쓰였고 현대 운영에서 왜 제한적으로만 다뤄야 하는지 정리한다." tags: [ MySQL, 아키텍처, 운영, DBA ] image: "mysql-report-bg.png" published: "2026-05-24" updated: "2026-05-24" author: "MySQL 기술 노트" source_url: "" --- ## 1. 왜 지금도 오래된 스토리지 엔진을 이해해야 하는가 MySQL을 새로 구축하는 환경에서는 대부분 InnoDB를 기본 스토리지 엔진으로 사용한다. 트랜잭션, crash recovery, row-level locking, foreign key, redo/undo 기반 복구, 온라인 DDL, replication 안정성까지 고려하면 InnoDB가 일반 업무 테이블의 사실상 표준이다. 그러나 운영 현장에서는 여전히 MyISAM, MEMORY, ARCHIVE 엔진을 만나게 된다. 오래된 시스템의 잔존 테이블, 임시 집계 구조, 로그성 보관 테이블, 마이그레이션 과정에서 가져온 덤프, 또는 애플리케이션이 명시적으로 `ENGINE=...`을 지정한 DDL 때문이다. 이 글의 목적은 세 엔진을 “사용 권장 목록”으로 소개하는 것이 아니다. 각 엔진이 어떤 내부 전제 위에서 동작하는지, InnoDB와 비교했을 때 어떤 운영 리스크가 생기는지, 현대 MySQL 8.0 이상 및 Aurora MySQL 환경에서 어떻게 판단해야 하는지를 정리하는 것이다. 특히 운영자는 다음 질문에 답할 수 있어야 한다. - 이 테이블이 왜 InnoDB가 아닌 다른 엔진인가? - 장애 복구, 백업, replication, failover 상황에서 데이터 일관성이 보장되는가? - 잠금 단위와 메모리 사용 방식 때문에 장애나 성능 병목을 만들 가능성이 있는가? - 지금 유지할 근거가 충분한가, 아니면 InnoDB로 전환해야 하는가? ## 2. 스토리지 엔진은 SQL 계층 아래의 물리 구현이다 MySQL 서버는 대략 SQL layer와 storage engine layer로 나누어 볼 수 있다. SQL layer는 parser, optimizer, privilege check, query execution orchestration을 담당하고, storage engine은 실제 데이터 접근과 저장 방식을 담당한다. 같은 `SELECT`, `INSERT`, `ALTER TABLE` 문이라도 테이블의 엔진이 다르면 다음과 같은 세부 동작이 달라진다. | 구분 | InnoDB | MyISAM | MEMORY | ARCHIVE | | --- | --- | --- | --- | --- | | 주 용도 | 일반 OLTP 기본 엔진 | 과거의 읽기 중심/비트랜잭션 테이블 | 메모리 기반 임시성 테이블 | 압축 보관성 append 데이터 | | 트랜잭션 | 지원 | 미지원 | 미지원 | 미지원 | | 잠금 단위 | row 중심, 필요 시 gap/next-key | table lock 중심 | table lock 중심 | 제한적, append 중심 | | crash recovery | redo/undo 기반 | 제한적, 손상 검사/복구 필요 | 서버 재시작 시 데이터 소실 | 트랜잭션 복구 관점에서는 제한적 | | foreign key | 지원 | 미지원 | 미지원 | 미지원 | | 대표 리스크 | 설정/undo/lock 관리 필요 | 장애 후 손상, writer 병목 | 메모리 고갈, 재시작 시 소실 | 조회/변경 제한, 범용 테이블 부적합 | 스토리지 엔진 선택은 단순한 성능 옵션이 아니라 장애 복구 모델과 데이터 수명 주기를 결정한다. `ENGINE=MEMORY`는 “빠른 테이블”이 아니라 “서버 프로세스의 메모리에 의존하는 휘발성 테이블”이다. `ENGINE=MyISAM`은 “단순한 파일 기반 테이블”이 아니라 “트랜잭션과 crash-safe 복구가 없는 테이블”이다. `ENGINE=ARCHIVE`는 “압축되는 테이블”이지만 범용 변경과 인덱싱을 기대할 수 있는 테이블이 아니다. 먼저 현재 MySQL 8.0 테스트 인스턴스에서 세 엔진의 지원 상태를 확인하는 쿼리를 보자. ```sql SELECT ENGINE, SUPPORT, TRANSACTIONS, XA, SAVEPOINTS, COMMENT FROM information_schema.ENGINES WHERE ENGINE IN ('InnoDB', 'MyISAM', 'MEMORY', 'ARCHIVE') ORDER BY FIELD(ENGINE, 'InnoDB', 'MyISAM', 'MEMORY', 'ARCHIVE'); ``` 실행 결과(MySQL 8.0.46): ```text +---------+---------+--------------+------+------------+------------------------------------------------------------+ | ENGINE | SUPPORT | TRANSACTIONS | XA | SAVEPOINTS | COMMENT | +---------+---------+--------------+------+------------+------------------------------------------------------------+ | InnoDB | DEFAULT | YES | YES | YES | Supports transactions, row-level locking, and foreign keys | | MyISAM | YES | NO | NO | NO | MyISAM storage engine | | MEMORY | YES | NO | NO | NO | Hash based, stored in memory, useful for temporary tables | | ARCHIVE | YES | NO | NO | NO | Archive storage engine | +---------+---------+--------------+------+------------+------------------------------------------------------------+ ``` 위 쿼리는 실제 운영 서버에서도 안전하게 실행할 수 있는 메타데이터 조회다. 단, 특정 배포판이나 managed service에서는 플러그인 정책에 따라 `ARCHIVE` 지원 여부가 다를 수 있으므로 `SUPPORT` 값을 먼저 확인해야 한다. ## 3. MyISAM: 단순한 파일 구조와 table-level locking의 대가 MyISAM은 MySQL 초기 시절에 널리 쓰였던 비트랜잭션 스토리지 엔진이다. 데이터 파일과 인덱스 파일을 비교적 단순하게 관리하고, 과거에는 일부 읽기 중심 워크로드에서 빠른 성능을 보이기도 했다. 그러나 현대 운영 기준에서는 기본 업무 테이블로 선택하기 어렵다. ### 3.1 내부 동작 관점 MyISAM은 트랜잭션 로그를 이용한 crash recovery 모델을 제공하지 않는다. 서버나 호스트가 비정상 종료되면 테이블 파일이 일관된 상태인지 확인해야 하고, 필요하면 `CHECK TABLE`, `REPAIR TABLE`, `myisamchk` 같은 절차가 필요할 수 있다. 운영자는 이 지점에서 InnoDB와의 차이를 명확히 이해해야 한다. InnoDB는 장애 후 redo log와 undo log를 이용해 committed transaction은 보존하고 incomplete transaction은 rollback하는 방향으로 복구한다. MyISAM은 그런 트랜잭션 경계가 없다. 또한 MyISAM의 잠금은 기본적으로 table-level이다. 하나의 세션이 테이블에 쓰기 작업을 수행하면 다른 세션의 쓰기뿐 아니라 읽기까지 영향을 받을 수 있다. 읽기 중심이고 쓰기가 거의 없는 정적 참조 테이블에서는 큰 문제가 드러나지 않을 수 있지만, 동시 쓰기가 조금만 늘어도 병목이 단순하고 강하게 나타난다. MyISAM이 foreign key를 지원하지 않는다는 점도 중요하다. DDL에 foreign key처럼 보이는 구문을 작성하더라도 InnoDB와 같은 참조 무결성 enforcement를 기대할 수 없다. 애플리케이션이 모든 무결성을 직접 보장한다는 전제가 필요한데, 장기 운영에서는 이 전제가 쉽게 깨진다. ### 3.2 운영상 제한점 MyISAM 테이블은 다음 상황에서 특히 위험하다. - 장애 후 자동 복구가 아니라 별도 점검과 복구 절차가 필요할 수 있다. - table lock 때문에 쓰기 경합이 생기면 전체 테이블 단위로 지연이 전파된다. - `mysqldump`나 파일 복사 백업에서 일관성 확보 방법을 별도로 고려해야 한다. - foreign key, row-level locking, MVCC가 없으므로 InnoDB 기준의 설계를 그대로 적용할 수 없다. - replication에서는 statement 기반 비결정성, 장애 후 테이블 손상, 수동 복구가 복제 지연이나 불일치로 이어질 수 있다. 현대 운영에서 MyISAM을 유지할 수 있는 경우는 매우 제한적이다. 예를 들어 거의 변경되지 않는 legacy lookup table, 특정 제품이 여전히 요구하는 시스템 테이블, 마이그레이션 전 임시 호환 단계 정도가 있을 수 있다. 그러나 일반 애플리케이션 데이터라면 InnoDB 전환 계획을 세우는 것이 원칙이다. ## 4. MEMORY: 빠른 임시 저장소가 아니라 제한된 휘발성 구조 MEMORY 엔진은 테이블 데이터를 메모리에 저장한다. 이름 때문에 “InnoDB보다 빠른 고성능 테이블”처럼 오해되지만, 운영 관점에서는 휘발성, 메모리 제한, 잠금 모델을 먼저 보아야 한다. ### 4.1 데이터 수명 주기 MEMORY 테이블의 정의는 데이터 딕셔너리에 남지만, 데이터 행은 서버 재시작 시 사라진다. 즉 재시작 후 테이블은 존재하지만 비어 있을 수 있다. 이 특성은 캐시성 데이터나 재생성 가능한 중간 결과에는 맞을 수 있지만, 업무 원장이나 상태 저장 테이블에는 치명적이다. 다음 예제는 MEMORY 테이블의 기본적인 사용 형태와 엔진 정보를 확인한다. ```sql DROP TABLE IF EXISTS tech_note_memory_sample; CREATE TABLE tech_note_memory_sample ( id INT NOT NULL PRIMARY KEY, category VARCHAR(20) NOT NULL, score INT NOT NULL, KEY idx_category (category) ) ENGINE=MEMORY; INSERT INTO tech_note_memory_sample VALUES (1, 'read', 10), (2, 'write', 20), (3, 'read', 30); SELECT category, COUNT(*) AS row_count, SUM(score) AS score_sum FROM tech_note_memory_sample GROUP BY category ORDER BY category; SHOW TABLE STATUS LIKE 'tech_note_memory_sample'; DROP TABLE tech_note_memory_sample; ``` 실행 결과(MySQL 8.0.46): ```text +----------+-----------+-----------+ | category | row_count | score_sum | +----------+-----------+-----------+ | read | 2 | 40 | | write | 1 | 20 | +----------+-----------+-----------+ +-------------------------+--------+---------+------------+------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+-------------+------------+--------------------+----------+----------------+---------+ | Name | Engine | Version | Row_format | Rows | Avg_row_length | Data_length | Max_data_length | Index_length | Data_free | Auto_increment | Create_time | Update_time | Check_time | Collation | Checksum | Create_options | Comment | +-------------------------+--------+---------+------------+------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+-------------+------------+--------------------+----------+----------------+---------+ | tech_note_memory_sample | MEMORY | 10 | Fixed | 3 | 89 | 127008 | 10369212 | 253968 | 0 | 1 | 2026-05-24 00:02:53 | NULL | NULL | utf8mb4_0900_ai_ci | NULL | | | +-------------------------+--------+---------+------------+------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+-------------+------------+--------------------+----------+----------------+---------+ ``` 이 예제에서 보듯 MEMORY 테이블은 SQL로 일반 테이블처럼 다룰 수 있다. 그러나 데이터가 메모리에 있으며, 서버 재시작 후 지속성을 기대하면 안 된다. 또한 MEMORY 테이블의 전체 메모리 사용은 `max_heap_table_size`와 관련되며, 세션/쿼리에서 생성되는 internal temporary table과 혼동해서는 안 된다. 명시적으로 만든 `ENGINE=MEMORY` 테이블과 옵티마이저가 내부적으로 만드는 임시 테이블은 운영 관점에서 다른 관리 대상이다. ### 4.2 메모리와 잠금 리스크 MEMORY 테이블은 메모리 기반이라는 이유로 디스크 I/O가 줄어들 수 있지만, 메모리 자원은 더 엄격한 shared resource다. 큰 MEMORY 테이블을 여러 개 만들거나 애플리케이션이 정리하지 않으면 mysqld 프로세스의 메모리 압박으로 이어질 수 있다. 또한 MEMORY도 트랜잭션을 제공하지 않으며, table-level locking 특성을 가진다. 동시 쓰기가 많은 캐시 테이블을 MEMORY로 만들면 “빠른 캐시”가 아니라 “전체 테이블 잠금이 걸리는 공유 병목”이 될 수 있다. 운영자가 MEMORY 테이블을 허용할 때는 다음 기준을 적용해야 한다. - 데이터는 언제든 재생성 가능해야 한다. - 서버 재시작 후 비어 있어도 애플리케이션이 정상 동작해야 한다. - 테이블 크기 상한과 정리 정책이 명확해야 한다. - 동시 쓰기 경합이 장애를 만들지 않는 구조여야 한다. - InnoDB temporary table, Redis, 애플리케이션 캐시 등 대안과 비교한 근거가 있어야 한다. Aurora MySQL에서도 이 판단은 크게 다르지 않다. Aurora의 분산 스토리지 계층은 InnoDB 데이터의 내구성과 복구 모델을 강화하지만, MEMORY 테이블의 행 데이터가 인스턴스 메모리에 의존한다는 사실을 바꾸지는 않는다. failover 후 writer instance가 바뀌면 MEMORY 테이블에 기대던 상태는 보존된다고 가정할 수 없다. ## 5. ARCHIVE: 압축 보관 목적의 특수 엔진 ARCHIVE 엔진은 대량의 append-oriented 데이터를 압축 저장하는 목적에 맞춰 설계된 엔진이다. 과거에는 로그성 데이터를 싸게 보관하기 위한 선택지로 검토되기도 했다. 그러나 현대 운영에서는 범용 로그 테이블도 InnoDB partitioning, 압축, 보관 정책, 외부 object storage, 데이터 웨어하우스 연계 등을 함께 검토하는 경우가 많다. ARCHIVE의 핵심은 “보관”이지 “일반 조회/수정”이 아니다. 트랜잭션, 일반적인 인덱스 설계, update/delete 중심 운영을 기대하면 맞지 않는다. MySQL 버전과 설정에 따라 지원 여부도 확인해야 한다. 다음 예제는 ARCHIVE 엔진 지원 여부를 확인하고, 지원되는 경우에만 별도의 환경에서 생성 테스트를 진행하는 방식의 기본 점검이다. 아래 블록은 단일 MySQL 8.0 테스트 컨테이너에서 실행 가능한 형태로 작성되어 있다. ```sql SELECT ENGINE, SUPPORT, COMMENT FROM information_schema.ENGINES WHERE ENGINE = 'ARCHIVE'; ``` 실행 결과(MySQL 8.0.46): ```text +---------+---------+------------------------+ | ENGINE | SUPPORT | COMMENT | +---------+---------+------------------------+ | ARCHIVE | YES | Archive storage engine | +---------+---------+------------------------+ ``` ARCHIVE 엔진을 실제 운영 설계에 넣기 전에는 다음 질문이 필요하다. - 조회 패턴이 대부분 append 후 장기 보관인가? - 데이터 수정이나 삭제가 거의 없다는 전제가 확실한가? - 복구, 백업, logical dump, restore 리허설이 검증되어 있는가? - 인덱스가 제한적인 구조에서도 필요한 조회 SLA를 만족하는가? - Aurora MySQL 또는 사용 중인 managed service에서 해당 엔진이 지원되고 운영상 허용되는가? 보관성 데이터라고 해서 반드시 ARCHIVE가 정답은 아니다. 보관 데이터도 장애 복구, 감사 추적, 삭제 정책, 개인정보 보존 기간, 비용 모델을 함께 갖는다. InnoDB partitioned table에 기간별 purge 정책을 두거나, S3 같은 object storage로 내보낸 뒤 Athena/Glue/Redshift 등 분석 계층에서 조회하는 방식이 더 명확한 경우가 많다. ## 6. 현재 서버에서 비-InnoDB 테이블을 찾는 진단 쿼리 운영자가 가장 먼저 해야 할 일은 “우리 서버에 이런 엔진이 실제로 남아 있는가”를 확인하는 것이다. 다음 쿼리는 시스템 스키마를 제외하고 InnoDB가 아닌 base table을 찾는다. ```sql SELECT TABLE_SCHEMA, TABLE_NAME, ENGINE, TABLE_ROWS, CREATE_TIME, UPDATE_TIME FROM information_schema.TABLES WHERE TABLE_TYPE = 'BASE TABLE' AND TABLE_SCHEMA NOT IN ('mysql', 'information_schema', 'performance_schema', 'sys') AND ENGINE <> 'InnoDB' ORDER BY TABLE_SCHEMA, TABLE_NAME; ``` 테스트 컨테이너에서는 사용자 테이블이 없으면 0건이 나오는 것이 정상이다. 운영 서버에서는 이 결과를 엔진 전환 후보 목록으로 삼을 수 있다. 단, 결과가 있다고 해서 즉시 `ALTER TABLE ... ENGINE=InnoDB`를 실행해서는 안 된다. 테이블 크기, foreign key 추가 가능성, application compatibility, replication lag, online DDL 가능 여부, 백업/복구 리허설을 먼저 검토해야 한다. 필요하면 특정 스키마에서 엔진별 테이블 수와 대략적인 크기를 집계한다. ```sql SELECT TABLE_SCHEMA, ENGINE, COUNT(*) AS table_count, ROUND(SUM(DATA_LENGTH + INDEX_LENGTH) / 1024 / 1024, 2) AS size_mb FROM information_schema.TABLES WHERE TABLE_TYPE = 'BASE TABLE' AND TABLE_SCHEMA NOT IN ('mysql', 'information_schema', 'performance_schema', 'sys') GROUP BY TABLE_SCHEMA, ENGINE ORDER BY TABLE_SCHEMA, ENGINE; ``` 이 쿼리는 migration planning에서 유용하다. 엔진별 테이블 수만 보는 것이 아니라 데이터와 인덱스 크기를 함께 보아야 전환 작업의 잠금 시간, 디스크 여유, replication 영향, 백업 시간을 추정할 수 있다. ## 7. InnoDB 전환을 판단하는 기준 비-InnoDB 테이블을 발견했을 때 일반적인 방향은 InnoDB 전환이다. 그러나 운영 테이블을 바꾸는 작업은 항상 영향도를 가진다. 다음 순서로 판단하는 것이 안전하다. 1. **업무 중요도 확인** 테이블이 실제 업무 경로에서 쓰이는지, 단순 legacy 잔재인지, 배치/리포트/캐시용인지 확인한다. 2. **DDL 원천 확인** 애플리케이션 마이그레이션 도구, ORM, 수동 SQL, vendor package 중 어디에서 `ENGINE=...`을 지정하는지 찾는다. 원천을 고치지 않으면 전환 후에도 다시 생성될 수 있다. 3. **데이터 지속성 요구 확인** MEMORY 테이블처럼 재시작 시 데이터 소실이 정상인 구조인지, 사실상 영속 데이터인데 잘못 선택된 엔진인지 구분한다. 4. **전환 리허설** staging이나 복제본에서 `ALTER TABLE ... ENGINE=InnoDB`를 실행해 시간, 잠금, 디스크 증가량, 인덱스 변화, 쿼리 계획 변화를 확인한다. 5. **백업과 롤백 계획** logical dump 또는 physical backup을 확보하고, 전환 실패 시 되돌릴 방법을 정한다. 6. **점진 실행** 작은 테이블부터 전환하고, 큰 테이블은 online schema change 도구나 maintenance window를 검토한다. 예시 DDL은 다음과 같다. 이 문장은 운영 테이블 구조를 변경하므로 테스트 컨테이너에서 임의 테이블을 만들어 실제 DDL 형태만 검증한다. ```sql DROP TABLE IF EXISTS tech_note_myisam_to_innodb; CREATE TABLE tech_note_myisam_to_innodb ( id INT NOT NULL PRIMARY KEY, note VARCHAR(100) NOT NULL ) ENGINE=MyISAM; SHOW TABLE STATUS LIKE 'tech_note_myisam_to_innodb'; ALTER TABLE tech_note_myisam_to_innodb ENGINE=InnoDB; SHOW TABLE STATUS LIKE 'tech_note_myisam_to_innodb'; DROP TABLE tech_note_myisam_to_innodb; ``` 운영에서는 위와 같은 DDL을 그대로 적용하기 전에 반드시 테이블 크기와 트래픽 특성을 확인해야 한다. 작은 테이블에서는 즉시 끝나는 작업도 대형 테이블에서는 긴 metadata lock, replication 지연, 디스크 사용량 급증을 만들 수 있다. ## 8. Aurora MySQL에서의 해석 Aurora MySQL은 MySQL 호환 인터페이스를 제공하지만 스토리지 계층과 장애 조치 방식이 Community MySQL과 다르다. 이 차이는 비-InnoDB 엔진을 볼 때 더 보수적인 판단을 요구한다. Aurora의 장점은 InnoDB 중심 워크로드에서 분산 스토리지, 빠른 crash recovery, reader endpoint, failover orchestration과 결합될 때 가장 잘 드러난다. MyISAM이나 MEMORY 같은 엔진을 사용하면 Aurora가 제공하는 내구성/복구 모델의 일부 기대와 어긋날 수 있다. 특히 MEMORY는 인스턴스 메모리 기반이므로 failover 후 상태 보존을 기대할 수 없고, MyISAM은 InnoDB와 같은 트랜잭션 복구 모델을 제공하지 않는다. Aurora 환경에서는 다음 정책을 권장한다. - 신규 업무 테이블은 명시적으로 InnoDB를 사용한다. - DDL 리뷰에서 `ENGINE=MyISAM`, `ENGINE=MEMORY`, `ENGINE=ARCHIVE`를 예외 승인 대상으로 분류한다. - MEMORY는 재생성 가능한 캐시성 데이터 외에는 금지한다. - MyISAM은 vendor 호환성 같은 강한 사유가 없으면 전환 대상으로 등록한다. - ARCHIVE는 지원 여부와 조회/백업/복구 제약을 확인한 뒤, 가능하면 외부 보관 계층과 비교한다. - failover 리허설에서 비-InnoDB 테이블의 상태를 별도로 확인한다. ## 9. 흔한 오해와 장애 패턴 ### 9.1 “MyISAM은 단순하니 더 안전하다” 단순한 파일 구조가 운영 안전성을 의미하지 않는다. 트랜잭션 경계와 crash recovery가 없는 단순함은 장애 후 수동 점검 부담으로 돌아온다. 데이터가 중요할수록 단순한 저장 파일보다 검증된 복구 모델이 더 중요하다. ### 9.2 “MEMORY는 디스크를 쓰지 않으니 항상 빠르다” 메모리는 빠르지만 무한하지 않다. 또한 table-level locking과 트랜잭션 미지원이라는 제약은 그대로 남는다. 성능 문제를 MEMORY로 해결하려 하기 전에 쿼리 계획, 인덱스, InnoDB buffer pool, 임시 테이블 발생 원인, 애플리케이션 캐시 구조를 먼저 봐야 한다. ### 9.3 “보관 데이터는 ARCHIVE로 넣으면 된다” 보관 데이터도 조회, 삭제, 감사, 복구, 이관 요구가 있다. ARCHIVE는 특수 목적 엔진이며, 운영 정책이 명확하지 않은 상태에서 선택하면 나중에 데이터 생명주기 관리가 더 어려워질 수 있다. ### 9.4 “엔진 전환은 ALTER 한 번이면 끝난다” 엔진 전환은 물리 저장 구조를 다시 쓰는 작업이다. 테이블 크기와 MySQL 버전에 따라 metadata lock, 임시 디스크 사용, replication lag, 통계 변화, 쿼리 계획 변화가 발생할 수 있다. 전환 후에는 `ANALYZE TABLE`, 주요 쿼리 실행 계획 확인, 애플리케이션 에러 로그 점검까지 포함해야 한다. ## 10. 운영 점검 체크리스트 - [ ] `information_schema.TABLES`에서 비-InnoDB 테이블 목록을 정기적으로 확인한다. - [ ] 신규 DDL 리뷰에서 `ENGINE` 지정 여부를 확인하고, 기본값에 의존하더라도 서버의 `default_storage_engine`을 점검한다. - [ ] MyISAM 테이블은 사용 사유, 데이터 중요도, 장애 복구 절차, InnoDB 전환 가능성을 문서화한다. - [ ] MEMORY 테이블은 재시작/장애 조치 후 데이터 소실을 애플리케이션이 허용하는지 확인한다. - [ ] ARCHIVE 테이블은 append-only 성격, 조회 요구, 백업/복구 리허설, managed service 지원 여부를 확인한다. - [ ] 전환 작업 전에는 staging 또는 replica에서 `ALTER TABLE ... ENGINE=InnoDB` 리허설을 수행한다. - [ ] 대형 테이블 전환 시 metadata lock, replication lag, 디스크 여유, 백업 상태를 사전에 점검한다. - [ ] Aurora MySQL에서는 failover 후 MEMORY/MyISAM/ARCHIVE 관련 동작을 별도 점검 항목으로 둔다. - [ ] vendor 애플리케이션이 특정 엔진을 요구한다면 제품 문서와 지원 정책을 확인하고, 임의 전환을 피한다. - [ ] 비-InnoDB 엔진을 예외적으로 유지할 때는 만료일과 재검토 일정을 둔다. ## 11. 결론 MyISAM, MEMORY, ARCHIVE는 MySQL의 스토리지 엔진 다양성을 보여 주지만, 현대 운영의 기본 선택지는 아니다. MyISAM은 트랜잭션과 crash-safe 복구 부재, MEMORY는 휘발성과 메모리 자원 압박, ARCHIVE는 특수한 append 보관 모델이라는 제약을 가진다. 이 엔진들을 이해해야 하는 이유는 새 시스템에 적극적으로 쓰기 위해서가 아니라, 기존 시스템의 위험을 정확히 식별하고 InnoDB 중심의 안정적인 운영 모델로 정리하기 위해서다. 다음 기술노트에서는 InnoDB 내부 구조를 더 구체적으로 살펴보며, buffer pool, redo log, undo log, doublewrite, page 구조가 왜 현대 MySQL 운영의 핵심이 되는지 이어서 다룬다.