이 글의 파라미터 이름과 기본값은 MySQL 8.4 LTS의 비동기 binlog 복제 기준입니다. SQL 예제와 워커 수 변경, GTID 대기는 MySQL Community Server 8.4.11의 소스·보조 서버 구성에서 확인했습니다. RDS와 Aurora는 지원 버전·파라미터 적용 방법·복제 구조를 따로 확인해야 합니다.

먼저 복제 구조를 구분합니다

같은 Aurora 클러스터의 Writer→Reader 복제에 replica_parallel_workers 튜닝을 그대로 적용하면 안 됩니다. Aurora 내부 Reader는 공유 스토리지 구조를 사용하고, 외부·클러스터 간 binlog 복제는 별도 경로입니다. Aurora Global Database도 별도 구성으로 구분합니다.¹²

복제 지연이 발생하는 이유

• 수신 경로: 네트워크 지연·재연결, 소스의 binlog 공급 지연
• 적용 작업: 큰 트랜잭션, 행 탐색 비용, 잠금·커밋 순서 대기
• 자원과 설정: CPU·스토리지·메모리 경쟁, 워커 수와 버퍼 설정

적용이 중단된 서버를 단순히 “느린 서버”로 보면 잘못된 파라미터를 조정하게 됩니다. 먼저 스레드 상태와 오류를 확인하고, 수신이 밀리는지 이미 받은 트랜잭션의 적용이 밀리는지 나눕니다.

스토리지 증설도 측정 후 결정합니다. 같은 지연이라도 대형 트랜잭션을 나눠 해결할 수 있고, DDL 잠금을 해소해야 할 수도 있습니다. 파라미터 조정은 병목이 확인된 뒤의 단계입니다.

수신 구간은 소스의 binlog 위치와 보조 서버의 수신 위치 사이이고, 적용 구간은 수신 위치와 적용 위치 사이입니다. 지연을 좁힐 때는 어느 구간이 벌어져 있는지부터 가릅니다.

지연을 먼저 측정합니다

파라미터를 만지기 전에 지연을 재는 지표부터 정해야 합니다. 8.4 에서는 SHOW SLAVE STATUS 같은 옛 문장이 문법 오류가 되므로 SHOW REPLICA STATUS 를 씁니다. 필드 이름도 Seconds_Behind_Source 이고, 옛 이름 Seconds_Behind_Master 를 찾는 모니터링 스크립트는 함께 고쳐야 합니다.

SHOW REPLICA STATUS\G

복제 중단 → 수신 지연 → 적용 지연 순서로 봅니다

여러 채널을 사용한다면 같은 Channel_Name의 상태를 이어서 비교합니다.³

소스의 현재 binlog 위치는 소스 서버에서 확인합니다.

SHOW BINARY LOG STATUS;

비교할 위치는 다음 세 쌍입니다.

• 소스: File + Position
• 보조 서버 수신: Source_Log_File + Read_Source_Log_Pos
• 보조 서버 적용: Relay_Source_Log_File + Exec_Source_Log_Pos

파일명이 다른 위치의 숫자만 빼면 안 됩니다. 파일·위치는 시간 지연 자체도 아니며, 병렬 적용에서 실행 위치는 완료된 작업의 하한을 나타낼 수 있습니다. 한 번의 스냅샷보다 각 위치가 전진하는지, 간격이 줄어드는지를 반복해서 봅니다.³

GTID 구성에서는 소스의 Executed_Gtid_Set, 보조 서버의 Retrieved_Gtid_Set·Executed_Gtid_Set도 참고합니다. GTID_SUBTRACT()로 미적용 집합을 구할 수 있지만 그 결과는 지연 시간이나 남은 바이트 수가 아닙니다. 보조 서버의 실행 집합에는 다른 채널이나 로컬 트랜잭션도 포함될 수 있으므로 비교 범위를 확인합니다.⁴

Seconds_Behind_Source의 한계

Seconds_Behind_Source 는 꺼내 보기 편하지만 그대로 믿을 수 있는 값이 아닙니다. 공식 문서는 이 필드가 본질적으로 적용(applier) 스레드와 수신(receiver) 스레드 사이의 시간 차를 재는 값이며 빠른 네트워크에서만 유용하다고 적습니다. 네트워크가 느리면 적용 스레드가 느린 수신 스레드를 자주 따라잡아 버려서, 수신 스레드가 소스보다 한참 뒤처져 있어도 값이 0 으로 보입니다.

문서가 밝히는 나머지 제약입니다.

• 소스와 보조 서버의 시계가 달라도, 수신 스레드가 시작할 때 계산한 차이가 그대로 유지되는 한 계산은 성립합니다. NTP 갱신을 포함한 시각 변경은 이 값을 덜 믿을 만한 것으로 만듭니다.
• 이벤트에 실린 타임스탬프는 최초 소스의 것이 보존됩니다. 3단 복제에서 중간 서버가 클라이언트 쓰기까지 함께 받으면, 마지막 이벤트가 최초 소스에서 온 것일 때와 중간 서버에서 생긴 것일 때가 섞여 값이 들쭉날쭉해집니다.
• 멀티스레드 복제에서는 이 값이 Exec_Source_Log_Pos 를 기준으로 하므로 가장 최근에 커밋된 트랜잭션을 반영하지 않을 수 있습니다.

워커별 상태와 적용 시간을 확인합니다

멀티스레드 복제라면 performance_schema.replication_applier_status_by_worker를 함께 봅니다. threads와 연결하면 워커가 실행 중인지 잠금·커밋 순서를 기다리는지도 확인할 수 있습니다.⁵⁶

SELECT w.CHANNEL_NAME, w.WORKER_ID, w.SERVICE_STATE,
       t.PROCESSLIST_STATE,
       w.APPLYING_TRANSACTION,
       w.APPLYING_TRANSACTION_START_APPLY_TIMESTAMP,
       w.APPLYING_TRANSACTION_RETRIES_COUNT,
       w.LAST_APPLIED_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP AS committed_on_source,
       w.LAST_APPLIED_TRANSACTION_END_APPLY_TIMESTAMP AS applied_on_replica,
       w.LAST_ERROR_NUMBER, w.LAST_ERROR_MESSAGE
FROM performance_schema.replication_applier_status_by_worker AS w
LEFT JOIN performance_schema.threads AS t ON t.THREAD_ID = w.THREAD_ID
ORDER BY w.CHANNEL_NAME, w.WORKER_ID;

커밋 시각은 복제로 전달되지만 적용 시작·종료 시각은 보조 서버에서 수집합니다. 그래서 Performance Schema 를 끄면 적용 시각 칼럼이 0 으로 나옵니다. APPLYING_TRANSACTION_START_APPLY_TIMESTAMP 는 첫 시도 시각이므로, 오래 걸리는 트랜잭션을 볼 때는 APPLYING_TRANSACTION_RETRIES_COUNT 와 함께 읽어 재시도 때문인지 구분합니다.

NOTE — START REPLICA 로 복제를 다시 시작하면 APPLYING_TRANSACTION 으로 시작하는 칼럼들이 초기화됩니다.

두 시각의 차이는 해당 워커에서 마지막으로 완료한 트랜잭션의 소스 커밋→복제 적용 완료 시간입니다. 현재 대기 중인 전체 작업의 지연은 아닙니다. 유휴 서버에서 현재 시각과 마지막 커밋 시각의 차이를 계산하면, 새 쓰기가 없는데도 지연이 늘어나는 것처럼 보입니다. 서로 다른 서버의 시각을 비교하므로 시계 동기화도 확인합니다.

파라미터로 해결되지 않는 원인을 먼저 봅니다

하나의 큰 트랜잭션

단일 트랜잭션은 여러 워커로 나눠 적용되지 않습니다. 대량 UPDATE·DELETE 하나가 오래 걸리면 워커 수를 늘려도 그 트랜잭션 자체는 빨라지지 않습니다. 소스에서 오래 실행 중인 InnoDB 트랜잭션은 다음처럼 찾습니다.⁷

SELECT trx_mysql_thread_id, trx_started, trx_state,
       trx_rows_modified, trx_query
FROM information_schema.INNODB_TRX
ORDER BY trx_started;

이 목록은 현재 활성 트랜잭션입니다. 이미 소스에서 커밋됐지만 보조 서버에서 적용 중인 작업은 여기서 보이지 않습니다. 그 경우 워커의 APPLYING_TRANSACTION, 적용 시작 시각, 배치 실행 이력과 binlog를 대조합니다.

예를 들어 백만 행을 한 트랜잭션으로 갱신하던 배치는, 업무상 분할 커밋이 가능할 때 PK 구간별 작은 트랜잭션으로 나눌 수 있습니다. 배치 크기와 실행 간격은 지연·잠금·처리량을 보며 조절하고, 분할 후 재시도와 부분 완료도 처리합니다. 전체 원자성이 필요한 작업을 임의로 나누지는 않습니다.

PK나 적절한 인덱스가 없는 테이블

ROW 복제의 UPDATE·DELETE도 보조 서버에서 변경할 행을 찾아야 합니다. MySQL은 PK, 적합한 유니크 키 등 사용 가능한 키를 검토하고, 적합한 인덱스가 없으면 테이블 스캔 비용이 발생할 수 있습니다. PK가 없다는 사실만으로 매 행마다 전체 스캔한다고 단정하면 안 됩니다. 실제 키와 행 탐색 방식을 확인합니다.⁸

다음 쿼리는 사용자 InnoDB 테이블 중 PK가 없는 후보를 찾습니다.

SELECT t.TABLE_SCHEMA, t.TABLE_NAME
FROM information_schema.TABLES AS t
WHERE t.TABLE_TYPE = 'BASE TABLE' AND t.ENGINE = 'InnoDB'
  AND t.TABLE_SCHEMA NOT IN ('mysql', 'sys', 'performance_schema', 'information_schema')
  AND NOT EXISTS (
    SELECT 1 FROM information_schema.TABLE_CONSTRAINTS AS c
    WHERE c.TABLE_SCHEMA = t.TABLE_SCHEMA AND c.TABLE_NAME = t.TABLE_NAME
      AND c.CONSTRAINT_TYPE = 'PRIMARY KEY'
  )
ORDER BY t.TABLE_SCHEMA, t.TABLE_NAME;

후보 테이블은 SHOW CREATE TABLE과 SHOW INDEX로 확인합니다. 키를 추가할 때는 소스와 보조 서버의 스키마를 일관되게 유지하고, 기존 데이터의 중복과 DDL 비용도 확인합니다.

읽기 트랜잭션이 막는 DDL과 행 잠금

보조 서버의 긴 읽기 트랜잭션이 메타데이터 잠금(MDL)을 유지하면, 복제로 전달된 ALTER TABLE이 기다릴 수 있습니다. read_only 설정만으로 읽기 작업의 이런 영향까지 없어지지는 않습니다. MDL 대기와 InnoDB 행 잠금 대기는 별도로 조회합니다.⁹

-- 복제 DDL을 막고 있는 메타데이터 잠금 후보
SELECT object_schema, object_name, waiting_pid, blocking_pid, waiting_query
FROM sys.schema_table_lock_waits;

-- InnoDB 행 잠금 대기 후보
SELECT locked_table, waiting_pid, blocking_pid, waiting_query
FROM sys.innodb_lock_waits;

워커 상태의 Waiting for table metadata lock과 차단 세션을 대조합니다. 장기 조회를 짧게 나누거나 트랜잭션을 적시에 종료하고, DDL 실행 시점을 조정합니다. 세션 종료는 해당 업무와 트랜잭션 영향을 확인한 뒤 결정합니다.

복제 지연에 영향을 주는 파라미터

innodb_io_capacity 와 innodb_io_capacity_max

innodb_io_capacity 는 InnoDB 가 백그라운드 작업, 특히 버퍼 풀의 더티 페이지를 디스크로 플러시하는 작업에 쓸 수 있는 I/O 작업량의 기준입니다. 보조 서버가 변경을 적용하는 속도도 이 값에 달려 있어 복제 지연과 직접 이어집니다.

기본값이 8.0 과 8.4 사이에서 크게 바뀐 파라미터입니다.

8.4 문서는 기본값 10000 이면 일반적으로 충분하고, innodb_io_capacity_max 의 기본값인 2배가 대부분의 작업 부하를 겨냥한 값이라고 적습니다. 8.0 에서 쓰던 “기본값 200 에서 시작해 올린다”는 절차를 8.4 에 그대로 옮기면 값을 오히려 내리는 셈이 됩니다.

올리고 내리는 판단 기준은 디스크의 IOPS 정격이 아니라 증상입니다.

• 체크포인트 때문에 처리량이 주기적으로 떨어지면 innodb_io_capacity 를 올립니다. 더 자주 플러시해서 밀린 작업이 쌓이지 않게 합니다.
• 플러시가 밀리지 않는다면 실용적인 선에서 낮게 유지합니다. SHOW ENGINE INNODB STATUS 에서 히스토리 리스트 길이가 수천 아래이고, 버퍼 풀의 변경된 페이지 비율이 innodb_max_dirty_pages_pct 보다 꾸준히 낮고, Log sequence number - Last checkpoint 가 로그 전체 크기의 7/8 보다 작으면 내릴 여지가 있습니다.

값을 정한 뒤에는 Performance Schema 와 모니터링 도구로 복제 지연과 디스크 I/O 사용률을 함께 관측해 확인합니다.

RDS 의 스토리지 타입에 따른 IOPS 상한

이 절은 RDS for MySQL의 EBS 기반 스토리지에 관한 설명입니다. Aurora 클러스터 볼륨에 그대로 적용하지 않습니다. IOPS는 초당 I/O 작업 수이고, 처리량은 초당 전송 바이트 수입니다. 실제 I/O 요청 크기와 병합·분할이 영향을 주므로 InnoDB의 기본 페이지 크기 16KiB로 처리량을 나눠 스토리지 IOPS를 단정하면 안 됩니다.¹⁰

gp2

gp2 는 IOPS 를 직접 지정할 수 없습니다. 1 GiB 당 3 IOPS 로 스토리지 크기가 성능을 결정하고, 최소값은 100 IOPS 입니다. MariaDB·MySQL·PostgreSQL 기준입니다.

1,000 GiB 미만 볼륨은 I/O 크레딧이 남아 있는 동안 버스트할 수 있습니다. 4,000 GiB 이상에서는 기준 성능이 버스트 성능을 넘어서므로 버스트가 의미를 잃습니다. 400 GiB 이상이면 볼륨 네 개로 스트라이핑되어 기준 처리량과 버스트 IOPS 가 네 배가 됩니다.

gp3

gp3 는 크기와 성능을 따로 정합니다. 기준 성능은 3,000 IOPS·125 MiB/s 이고, 400 GiB 를 넘으면 스트라이핑이 적용되어 기준선 자체가 올라갑니다. Db2·MariaDB·MySQL·PostgreSQL 기준입니다.

추가 성능은 400 GiB 이상에서만 지정할 수 있습니다. MariaDB 와 MySQL 에서 IOPS 를 32,000 위로 올리면 처리량 값이 500 MiB/s 에서 자동으로 함께 올라갑니다. 예를 들어 IOPS 를 40,000 으로 두면 처리량이 최소 625 MiB/s 가 됩니다. 처리량과 IOPS 의 비율은 최대 0.25 입니다.

스토리지와 인스턴스 클래스 양쪽의 IOPS·처리량 한도를 확인합니다. innodb_io_capacity를 올려도 물리적 용량이 늘어나지는 않습니다. 반대로 현재 관측한 WriteIOPS가 장치의 최대 성능이라는 뜻도 아니므로, 관측값 자체를 설정의 상한으로 삼지 않습니다.

NOTE — 위 수치는 Amazon RDS DB 인스턴스 스토리지 문서 기준입니다. gp2·gp3 는 범용 SSD 이고, 프로비저닝 IOPS 계열인 io1·io2 Block Express 는 상한이 더 높습니다(io2 는 최대 256,000 IOPS). 스토리지 타입을 혼동하면 낼 수 없는 IOPS 를 기대하게 됩니다.

스토리지 사양을 실제 지표와 연결합니다

CloudWatch에서 지연이 발생한 같은 시간대의 보조 서버 지표를 함께 봅니다. 아래 해석은 원인을 좁히는 단서이며, 하나의 수치만으로 원인을 확정하지 않습니다.¹¹

예를 들어 gp2의 BurstBalance가 소진되고 I/O 지연·큐 길이가 함께 늘어난다면 버스트 의존도를 줄이는 방향을 검토합니다. 반대로 스토리지 지표가 여유로운데 한 워커만 오래 실행 중이라면 트랜잭션 크기와 적용 작업부터 확인합니다.

replica_parallel_workers

8.4 문서가 쓰는 이름은 replica_parallel_workers이고 기본값은 4입니다. slave_parallel_workers는 옛 이름입니다. 값 0은 단일 적용 스레드 방식이고 폐기 예정(deprecated)이므로, 워커를 하나만 사용할 새 설정에는 1을 검토합니다.¹³

값이 0 이면 보조 서버는 적용 스레드 하나로 릴레이 로그를 읽어 트랜잭션을 실행합니다. 1 이상이면 워커 스레드가 그 수만큼 생기고, 릴레이 로그에서 트랜잭션을 순서대로 읽어 워커에 배분하는 코디네이터 스레드가 하나 더 붙습니다. 이 상태를 멀티스레드 복제라고 부릅니다. 복제 채널을 여러 개 쓰면 채널마다 이 수만큼 스레드가 생깁니다.

워커를 늘리는 효과는 독립적으로 적용할 트랜잭션과 자원 여유가 있을 때 나옵니다. 워커 수와 CPU 사용량이 일정 비율로 늘어나는 것은 아닙니다. 대형 트랜잭션, 같은 데이터에 대한 의존성, 잠금·I/O 대기는 워커 증가만으로 해소되지 않습니다.

특히 Waiting for preceding transaction to commit은 앞선 트랜잭션의 커밋을 기다린다는 뜻입니다. 기다리는 워커를 더 늘리기 전에 선행 작업이 무엇을 하는지 확인합니다. replica_preserve_commit_order는 8.4에서 기본 ON이며, 대기를 없애려고 끄면 보조 서버에서 관측하는 커밋 순서가 달라질 수 있습니다.⁶¹³

현재 설정과 실제 활성 워커 수를 구분해서 확인합니다.

SELECT @@GLOBAL.replica_parallel_workers,
       @@GLOBAL.replica_preserve_commit_order;

SELECT CHANNEL_NAME, COUNT(*) AS active_workers
FROM performance_schema.replication_applier_status_by_worker
WHERE SERVICE_STATE = 'ON'
GROUP BY CHANNEL_NAME;

변수 변경은 실행 중인 워커 수에 즉시 반영되지 않고 다음 START REPLICA에 적용됩니다. 아래는 직접 운영하는 MySQL의 기본 채널에서 적용 스레드를 멈추고 워커를 8개로 바꾸는 예제입니다. 8은 실험값이며 권장 고정값이 아닙니다. 중지 중에는 적용 지연이 늘어나므로 읽기 트래픽과 변경 시점을 먼저 조정합니다.¹³

STOP REPLICA SQL_THREAD FOR CHANNEL '';
SET GLOBAL replica_parallel_workers = 8;
START REPLICA SQL_THREAD FOR CHANNEL '';

명명된 채널에서는 빈 문자열 대신 실제 채널명을 사용합니다. 재시작 후 활성 워커 수·오류·지연 변화·CPU·I/O를 다시 확인합니다. SET GLOBAL은 서버 재시작 후 유지되지 않으므로 검증한 값만 설정 파일이나 적절한 영속 설정에 반영합니다. RDS·Aurora에서는 파라미터 그룹과 해당 서비스가 제공하는 복제 제어 절차를 따릅니다.

병렬 적용 관련 변수도 8.4에서의 상태를 기준으로 확인합니다.

binlog_transaction_dependency_tracking이 사라진 뒤에도 writeset 기반 의존성 추적 동작은 남아 있습니다. 8.4에서 제거된 앞의 두 변수는 옛 옵션 파일에서 정리해야 합니다. 9.x의 변수 제거·기본값 변경을 8.4에 그대로 적용하지 않습니다.¹⁴

그 밖에 복제 지연에 영향을 줄 수 있는 파라미터

sync_binlog 와 innodb_flush_log_at_trx_commit

두 값 모두 기본값이 1 이고, 이 조합이 가장 안전하면서 가장 느립니다. 공식 문서는 sync_binlog 를 두고 가장 안전한 값은 기본값인 1 이지만 동시에 가장 느리다고 적습니다. sync_binlog 를 1 보다 큰 N 으로 두면 커밋 그룹 N 개마다 디스크와 동기화합니다.

보조 서버에서 이 조합을 내리면 적용 커밋이 빨라질 수 있지만, 이것은 장애 시점의 유실 범위를 성능과 바꾸는 거래입니다. 감당할 유실 범위를 먼저 정한 다음 값을 고릅니다. Aurora MySQL 버전 3 에서는 innodb_flush_log_at_trx_commit 을 1 이 아닌 값으로 바꾸려면 innodb_trx_commit_allow_data_loss 를 먼저 1 로 설정해야 하고, 그것은 데이터 유실 위험을 인정한다는 뜻입니다.

log_replica_updates

보조 서버가 적용한 복제 이벤트를 자신의 바이너리 로그에도 남길지 결정합니다. 옛 이름은 log_slave_updates 입니다. 8.4 에서는 바이너리 로깅이 기본으로 켜져 있고, 그 경우 복제 갱신 로깅도 기본 동작입니다. 보조 서버를 다시 소스로 쓰는 다단 구성에서는 켜 두어야 합니다. 반대로 이 서버가 소스 역할을 하지 않고 장애 때 소스를 세울 다른 방법이 있다면, 문서는 이 값을 끄는 선택을 제시합니다.

innodb_buffer_pool_size

적용할 페이지가 버퍼 풀에 없으면 적용 스레드가 매번 디스크에서 읽어야 하므로 지연이 커집니다. 기본값은 128MB 이고 SET GLOBAL 로 재시작 없이 늘릴 수 있습니다. 단 값은 innodb_buffer_pool_chunk_size 와 innodb_buffer_pool_instances 의 곱의 배수여야 하며, 맞지 않으면 서버가 자동으로 올려 맞춥니다. 전용 서버라면 innodb_dedicated_server 로 자동 산정하게 하는 방법도 있습니다.

innodb_flush_method

InnoDB 가 데이터와 로그를 디스크에 쓸 때 쓰는 방식입니다. 8.4 의 리눅스 기본값은 지원되면 O_DIRECT, 아니면 fsync 입니다(8.0 은 fsync). 동적 변경이 불가하므로 초기 구축 때 정해야 합니다. 8.4 부터는 --innodb-dedicated-server 가 이 값을 자동으로 설정하지 않습니다.

relay_log_space_limit

릴레이 로그 전체가 쓸 수 있는 최대 용량입니다. 기본값은 0 이고 제한이 없다는 뜻입니다. 값을 준다면 max_relay_log_size(이 값이 0 이면 max_binlog_size)의 2배보다 작게 잡지 말라고 문서가 적습니다.

innodb_thread_concurrency

InnoDB 안에서 동시에 실행되는 스레드 수를 제한합니다. 기본값은 0 이고 제한이 없다는 뜻입니다. 문서는 대부분의 작업 부하가 제한 없이도 잘 돌아간다고 적고, 제한을 걸기 전에 멀티코어 성능에 영향을 주는 다른 설정을 먼저 보라고 권합니다. 복제 지연을 이 값으로 푸는 경우는 드뭅니다.

리두 로그 용량

innodb_log_file_size 와 innodb_log_files_in_group 은 8.0.30 에서 deprecated 됐습니다. 지금은 innodb_redo_log_capacity 로 정하고 기본값은 100MB 입니다. innodb_redo_log_capacity 가 정의되지 않은 상태에서 옛 두 변수만 남아 있으면 리두 용량이 두 값의 곱으로 계산되므로, 예전 옵션 파일을 그대로 옮겨 오면 의도하지 않은 용량이 잡힙니다.

innodb_flush_neighbors

플러시할 때 인접한 페이지를 함께 플러시할지 결정합니다. 회전형 디스크를 위한 최적화이고 기본값은 비활성입니다. 비회전형 스토리지이거나 회전형과 섞여 있는 구성에서는 끄라고 문서가 적습니다.

쓰기 직후 읽기는 애플리케이션에서도 처리합니다

저장 직후 읽기 복제본을 조회하면 “저장했는데 결과가 없다”는 문제가 생길 수 있습니다. 비동기 복제의 지연을 줄이는 작업과, 해당 요청이 방금 쓴 데이터를 읽게 보장하는 작업은 구분해야 합니다.

가장 단순한 방법은 최신성이 필요한 쓰기 직후 조회를 소스의 새 조회로 라우팅하는 것입니다. 일정 시간 sleep하거나 특정 시간 동안만 소스로 보내는 규칙은 최악의 복제 지연까지 보장하지 않습니다.

GTID 기반 binlog 복제에서는 해당 쓰기의 GTID가 보조 서버에 적용될 때까지 기다리는 방법도 있습니다. 다음 순서로 처리합니다.⁴¹⁵

1. 소스에서 쓰기를 커밋하고, 그 커밋의 GTID를 얻습니다. 지원하는 드라이버라면 쓰기 세션의 session_track_gtids=OWN_GTID와 프로토콜의 세션 추적 정보를 사용합니다.
2. 조회할 보조 서버의 연결을 확보하고 WAIT_FOR_EXECUTED_GTID_SET()을 제한 시간과 함께 실행합니다.
3. 반환값이 0일 때 새 스냅샷으로 조회합니다. 1은 타임아웃이며, 오류나 NULL도 성공으로 처리하지 않습니다.
4. 타임아웃이면 정책에 따라 소스로 조회를 보내거나 재시도 가능한 응답을 반환합니다.

-- UUID:번호는 예시입니다. 실제로 커밋한 트랜잭션의 GTID로 바꿉니다.
SELECT WAIT_FOR_EXECUTED_GTID_SET(
  '3E11FA47-71CA-11E1-9E33-C80AA9429562:23', 1
) AS wait_result;
-- 0: 적용 완료, 1: 1초 안에 적용되지 않음

대기는 조회할 바로 그 보조 서버 연결에서 실행합니다. 커넥션 풀이나 로드밸런서가 대기 후 다른 복제본으로 조회를 보내면 보장이 깨집니다. REPEATABLE READ에서 이미 만든 오래된 스냅샷을 재사용하지 않도록, 대기를 마친 뒤 새 읽기 트랜잭션을 시작합니다.

소스의 전체 @@GLOBAL.gtid_executed를 매 요청의 토큰으로 사용하면 관련 없는 커밋까지 기다릴 수 있습니다. 또한 GTID 적용 완료는 복제 필터로 제외한 데이터까지 존재한다는 보장이 아니므로, 읽을 데이터가 실제로 복제되는 구성에서 사용합니다. 같은 Aurora 클러스터의 내부 Reader에 이 binlog용 절차를 그대로 적용하지 않습니다.

정리

복제 지연을 만나면 복제 구조 확인 → 중단·오류 확인 → 수신·적용 구간 분리 → 트랜잭션·잠금·자원 확인 → 설정 변경과 재측정 순서로 접근합니다. 지연이 낮아진 것뿐 아니라 오류가 없는지, 밀린 작업이 줄어드는지, 읽기 서비스가 필요한 최신성을 만족하는지 함께 확인합니다.

참고 자료

이 글은 MySQL 8.4 LTS·InnoDB를 기준으로 설명합니다. SQL 예제는 MySQL Community Server 8.4.11, ngram_token_size=2, 기본 불용어 활성 상태에서 확인했습니다. MyISAM과 다른 동작은 별도로 표시합니다.

LIKE와 FULLTEXT 중 무엇을 써야 할까요

먼저 필요한 검색의 의미를 정합니다.

LIKE가 항상 느리고 FULLTEXT가 항상 빠른 것은 아닙니다. 조회 범위가 작은 경우에는 단순한 패턴 검색으로 충분할 수 있습니다. 필요한 결과를 먼저 정하고 실제 조건의 실행계획과 처리 시간을 비교합니다.³

한국어에도 띄어쓰기가 있습니다. 기본 파서가 공백으로 나눈 어절을 검색하는 데는 사용할 수 있지만, 조사·어미가 붙은 어절 내부를 찾거나 띄어쓰기 차이를 처리하는 데 한계가 있습니다. ngram은 이를 일정 길이의 문자 조각으로 나누며, 조사·어간을 이해하는 한국어 형태소 분석기는 아닙니다.⁴

재현용 테이블과 데이터

mysql CLI에서 실습용 데이터베이스를 선택하고 아래 쿼리를 같은 연결에서 실행합니다. 첫 예제는 인덱스를 포함해 테이블을 생성하므로, 이어서 같은 이름의 인덱스를 다시 ADD하면 안 됩니다.

SET NAMES utf8mb4;

SELECT VERSION(), @@ngram_token_size,
       @@innodb_ft_min_token_size, @@innodb_ft_enable_stopword;

CREATE TABLE article (
  article_id INT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
  title VARCHAR(255) NOT NULL,
  body TEXT NOT NULL,
  FULLTEXT KEY fts_article_title_body (title, body) WITH PARSER ngram
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;

INSERT INTO article (title, body) VALUES
('데이터베이스 성능', '인덱스와 쿼리 실행 계획을 점검합니다.'),
('데이터 분석', '집계와 시각화를 다룹니다.'),
('로그 보관', '베이스 설정과 보관 주기를 점검합니다.'),
('검색 기능', '검색 파서와 토큰을 설명합니다.'),
('서울 여행', '경복궁을 방문합니다.'),
('트랜잭션 잠금', '잠금과 커밋을 설명합니다.'),
('금', '');

WITH PARSER ngram을 생략하면 기본 파서를 사용합니다. FULLTEXT 인덱스는 CHAR, VARCHAR, TEXT 계열 컬럼에 만들 수 있으며, 같은 FULLTEXT 인덱스에 포함된 컬럼들은 문자셋과 콜레이션이 같아야 합니다.¹⁵

ngram의 자연어 모드와 불리언 모드는 결과가 다릅니다

ngram_token_size=2에서 데이터베이스는 다음 다섯 토큰으로 나뉩니다.

데이 / 이터 / 터베 / 베이 / 이스

NATURAL LANGUAGE MODE

모드를 생략하면 자연어 모드입니다. ngram 파서는 검색어를 토큰들의 합집합으로 검색하므로, 긴 검색어의 일부 토큰만 가진 문서도 결과에 포함됩니다.⁴

SELECT article_id, title,
       MATCH(title, body) AGAINST('데이터베이스' IN NATURAL LANGUAGE MODE) AS score
FROM article
WHERE MATCH(title, body) AGAINST('데이터베이스' IN NATURAL LANGUAGE MODE)
ORDER BY score DESC, article_id ASC;

결과에는 1·2·3번이 포함됩니다.

따라서 %데이터베이스%를 이 자연어 검색으로 교체하면 검색 범위가 넓어집니다. 두 방식의 결과가 같다고 가정하면 안 됩니다.

BOOLEAN MODE

ngram의 불리언 모드는 검색어 하나를 연속된 ngram 구문 검색으로 변환합니다. 아래 예제에서는 1번만 검색됩니다.⁴

SELECT article_id, title
FROM article
WHERE MATCH(title, body) AGAINST('데이터베이스' IN BOOLEAN MODE)
ORDER BY article_id;

여러 검색어에 필수 포함·제외 조건을 지정할 수도 있습니다.

SELECT article_id, title,
       MATCH(title, body) AGAINST('+데이터 -분석' IN BOOLEAN MODE) AS score
FROM article
WHERE MATCH(title, body) AGAINST('+데이터 -분석' IN BOOLEAN MODE)
ORDER BY score DESC, article_id ASC;
-- 1번: 데이터는 포함하고 분석은 제외합니다.

구문 검색도 토큰화·불용어·콜레이션의 영향을 받습니다. 원문의 공백·구두점까지 보존한 정확한 부분 문자열 일치가 필요하면 해당 조건을 별도로 검증해야 합니다.⁶⁷

관련성 점수와 정렬

InnoDB의 관련성 계산은 BM25·TF-IDF 기반 알고리즘을 사용합니다. 엔진과 검색 대상 문서 집합에 따라 점수가 달라지므로, 점수를 고정된 “정답 확률”처럼 해석하지 않습니다.⁶

자연어 모드는 특정 실행계획 조건에서 관련도순으로 반환하지만, 불리언 모드는 자동으로 관련도순 정렬하지 않습니다. 화면의 정렬 계약은 예제처럼 ORDER BY score DESC, article_id ASC로 명시하는 편이 분명합니다. 같은 점수에 대한 보조 정렬도 있어야 순서가 안정적입니다.⁷⁶

50% 임계값은 MyISAM의 자연어 검색에 해당합니다

InnoDB 자연어 검색에는 MyISAM의 50% 임계값이 적용되지 않습니다. 테스트 데이터가 적다는 이유로 InnoDB 검색을 무조건 불리언 모드로 바꿀 필요는 없습니다.⁷

기본 파서로 만든 다음 InnoDB 테이블에서는 모든 행에 database가 있어도 두 행이 검색됩니다.

CREATE TABLE word_demo (
  id INT PRIMARY KEY,
  body TEXT NOT NULL,
  FULLTEXT KEY fts_word_demo_body (body)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

INSERT INTO word_demo VALUES
(1, 'database indexing'),
(2, 'database tuning');

SELECT COUNT(*) AS matched
FROM word_demo
WHERE MATCH(body) AGAINST('database' IN NATURAL LANGUAGE MODE);
-- matched = 2

MyISAM의 자연어 모드는 전체 행의 50% 이상에 나타나는 단어를 검색에서 제외합니다. MyISAM에서도 불리언 모드에는 그 임계값이 적용되지 않습니다. 불용어 목록과 토큰 길이 제한은 별개의 조건입니다.⁷⁶

Query Expansion은 검색어를 문서에서 확장합니다

Query Expansion은 첫 검색에서 상위에 나온 문서의 단어를 검색어에 추가해 다시 검색합니다. 의미를 이해해 동의어를 생성하는 기능은 아닙니다. 관련 없는 결과가 늘어날 수 있으므로, 정확한 필터보다 탐색용 검색에 적합한지 평가합니다.⁸

SELECT id, body
FROM word_demo
WHERE MATCH(body) AGAINST('indexing' WITH QUERY EXPANSION)
ORDER BY id;

ngram의 한 글자 검색과 와일드카드

bigram 인덱스는 길이 2의 토큰을 저장합니다. 길이 1의 검색어를 그대로 검색하면 필요한 토큰이 없어 결과가 나오지 않습니다.

SELECT article_id FROM article
WHERE MATCH(title, body) AGAINST('금' IN BOOLEAN MODE)
ORDER BY article_id;
-- 결과 없음

SELECT article_id FROM article
WHERE MATCH(title, body) AGAINST('금*' IN BOOLEAN MODE)
ORDER BY article_id;
-- 6번: 본문의 '잠금과'에서 '금과' 토큰이 만들어집니다.

SELECT article_id FROM article
WHERE title LIKE '%금%' OR body LIKE '%금%'
ORDER BY article_id;
-- 6번, 7번

금*은 인덱스에 있는 금으로 시작하는 토큰을 찾습니다. 7번의 단독 한 글자 금에는 bigram 토큰이 없으므로, *를 붙여도 검색되지 않습니다. 반대로 ngram 크기보다 긴 접두 검색어는 ngram 구문 검색으로 변환되며 *가 무시됩니다.⁴

한 글자 검색이 필수라면 ngram_token_size=1 또는 범위를 제한한 다른 검색 경로를 검토합니다. *만 붙여 모든 한 글자·부분 문자열 검색을 해결할 수는 없습니다.

토큰 길이와 불용어 설정

기본 파서와 ngram의 설정은 다릅니다

MyISAM 기본 파서는 ft_min_word_len과 ft_max_word_len을 사용하고 최소 길이 기본값은 4입니다. 이 최소·최대 단어 길이 변수들은 ngram 인덱스에 적용되지 않습니다.⁴⁹

ngram은 공백을 가로질러 무조건 토큰을 만들지도 않습니다. 예를 들어 크기 2에서 ab cd는 ab, cd로 나뉘며 bc 토큰은 만들지 않습니다.⁴

영문 불용어가 ngram에도 영향을 줍니다

ngram도 기본적으로 영문 불용어 목록을 사용합니다. 예를 들어 a가 불용어이면 ab 토큰도 제외될 수 있습니다. 한국어와 영문 상품명·코드를 함께 저장하는 서비스에서 확인할 부분입니다.⁴¹⁰

CREATE TABLE stopword_demo (
  id INT PRIMARY KEY,
  body TEXT NOT NULL,
  FULLTEXT KEY fts_stopword_demo_body (body) WITH PARSER ngram
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

INSERT INTO stopword_demo VALUES (1, 'abcd');

SELECT COUNT(*) AS ab_hits FROM stopword_demo
WHERE MATCH(body) AGAINST('ab' IN BOOLEAN MODE);
-- ab_hits = 0: 기본 불용어 a를 포함하는 ab 토큰은 제외됩니다.

SELECT COUNT(*) AS bc_hits FROM stopword_demo
WHERE MATCH(body) AGAINST('bc' IN BOOLEAN MODE);
-- bc_hits = 1

불용어는 innodb_ft_enable_stopword, innodb_ft_server_stopword_table, innodb_ft_user_stopword_table로 제어합니다. 사용자 불용어 테이블은 공식 문서가 요구하는 스키마로 만들고 인덱스 생성·재구축 전에 지정합니다. MyISAM은 ft_stopword_file을 사용합니다.¹⁰

설정 변경은 기존 인덱스 재구축까지 포함합니다

ngram_token_size는 읽기 전용 시작 옵션입니다. 예를 들어 크기를 1로 바꾸려면 설정을 변경하고 서버를 재시작한 뒤, 영향을 받는 ngram FULLTEXT 인덱스를 재구축해야 합니다. 서버 재시작만으로 기존 인덱스의 토큰이 다시 만들어지지는 않습니다.⁴⁹

[mysqld]
ngram_token_size=1

InnoDB 기본 파서의 최소·최대 단어 길이를 변경할 때도 서버 재시작과 해당 인덱스 재구축이 필요합니다. 불용어 정책 변경 역시 기존 인덱스가 자동 갱신된다고 가정하지 않습니다.

다음은 앞의 실습 테이블에서 불용어를 끄고 인덱스를 재구축하는 예제입니다. 이 예제는 ngram 크기를 바꾸지 않으며, 같은 연결에서 실행합니다.

SET SESSION innodb_ft_enable_stopword = OFF;

ALTER TABLE stopword_demo DROP INDEX fts_stopword_demo_body;
ALTER TABLE stopword_demo
  ADD FULLTEXT KEY fts_stopword_demo_body (body) WITH PARSER ngram;

SELECT COUNT(*) AS ab_hits FROM stopword_demo
WHERE MATCH(body) AGAINST('ab' IN BOOLEAN MODE);
-- ab_hits = 1

SET SESSION innodb_ft_enable_stopword = ON;

이 예제는 삭제와 생성을 별도 문장으로 실행합니다. 그 사이에는 해당 FULLTEXT 인덱스가 없으므로 운영에서는 검색 트래픽과 작업 시간을 조정해야 합니다. 마지막 SET은 연결의 설정을 되돌리는 것이며, 방금 만든 인덱스를 다시 불용어 적용 상태로 재구축하는 명령은 아닙니다. 선택한 정책의 적용 범위·영속 설정·재구축 대상을 함께 관리합니다.

기존 기본 파서 인덱스를 ngram으로 바꿀 때도 현재 인덱스를 확인한 뒤 교체해야 합니다. SHOW CREATE TABLE·SHOW INDEX로 이름과 컬럼을 확인하고, 동일한 이름의 인덱스를 중복으로 추가하지 않습니다.

MATCH 컬럼과 트랜잭션에서 자주 만나는 문제

복합 FULLTEXT는 B-Tree의 왼쪽 접두 규칙과 다릅니다

이 글의 인덱스는 (title, body)입니다. InnoDB에서 MATCH(title)만 사용하면 이 복합 인덱스로 대신 검색할 수 없어 오류가 납니다.⁵

SELECT article_id FROM article
WHERE MATCH(title) AGAINST('데이터' IN BOOLEAN MODE);
-- ERROR 1191 (HY000): Can't find FULLTEXT index matching the column list

제목만 검색해야 한다면 제목만의 FULLTEXT 인덱스를 별도로 만들거나, 요구에 맞는 다른 조회를 사용합니다. MATCH(title, body)로 바꾸면 본문까지 검색한다는 점도 함께 고려해야 합니다.

INSERT 직후 같은 트랜잭션에서도 검색되지 않을 수 있습니다

InnoDB FULLTEXT의 삽입·갱신 반영은 커밋 시점에 처리됩니다. 같은 트랜잭션에서 일반 SELECT로 보이는 새 행이 FULLTEXT로는 아직 보이지 않을 수 있습니다.²

START TRANSACTION;
INSERT INTO article (title, body) VALUES ('초신성 관측', '새 관측 기록입니다.');

SELECT COUNT(*) AS ordinary_select FROM article WHERE title = '초신성 관측';
-- ordinary_select = 1
SELECT COUNT(*) AS before_commit FROM article
WHERE MATCH(title, body) AGAINST('초신성' IN BOOLEAN MODE);
-- before_commit = 0

COMMIT;

SELECT COUNT(*) AS after_commit FROM article
WHERE MATCH(title, body) AGAINST('초신성' IN BOOLEAN MODE);
-- after_commit = 1

저장 직후 같은 트랜잭션에서 저장 결과를 확인하는 용도로 FULLTEXT를 사용하지 않습니다. 그 경우 PK로 조회하는 편이 목적에 맞습니다.

운영에 적용하기 전에 확인할 것

• 인덱스와 실행계획: 실제 서비스의 필터·정렬·LIMIT을 포함한 쿼리로 측정합니다. FULLTEXT 인덱스가 있다고 모든 조회가 빨라지는 것은 아닙니다.
• DDL 비용: 첫 FULLTEXT 인덱스를 추가할 때 사용자 정의 FTS_DOC_ID가 없으면 테이블 재구축이 발생합니다. InnoDB의 FULLTEXT 인덱스 추가는 동시 DML을 허용하지 않으므로, ALGORITHM=INPLACE를 무중단 쓰기 허용으로 해석하면 안 됩니다.¹¹
• 지원 범위: MySQL 8.4에서는 InnoDB·MyISAM이 FULLTEXT를 지원하며 파티션 테이블에는 사용할 수 없습니다.⁵
• 검색 입력: SQL 바인딩과 검색 문법 처리를 구분합니다. 값을 바인딩해도 BOOLEAN MODE의 +, -, 따옴표 등이 일반 문자로 바뀌지는 않습니다. 일반 검색창과 고급 검색 문법의 허용 범위를 정하고 빈 검색어·문법 오류를 처리합니다.
• 검색 품질: 한 글자, 조사·어미, 띄어쓰기, 영문 코드, 불용어, 구두점에 대해 기대 결과를 정해 테스트합니다. 형태소·동의어·오타 보정이 필요한 경우에는 그 요구를 지원하는 별도 검색 시스템을 검토합니다.

EXPLAIN
SELECT article_id, title
FROM article
WHERE MATCH(title, body) AGAINST('데이터베이스' IN BOOLEAN MODE)
ORDER BY article_id
LIMIT 20;

이 실습에서는 접근 방식 type=fulltext, 사용 인덱스 key=fts_article_title_body를 확인할 수 있습니다. 실제 데이터량과 검색어 빈도에서도 실행 시간과 반환 결과를 함께 확인합니다.

FULLTEXT를 도입할 때는 LIKE를 기계적으로 교체하기보다, 찾아야 할 결과 → 파서와 검색 모드 → 토큰·불용어 정책 → 재구축과 검증 순서로 결정합니다.

참고 자료

본문의 생성·변경 예제는 같은 리전의 Aurora 클러스터를 대상으로 합니다. 리전 ap-northeast-2와 클러스터·인스턴스·엔드포인트 이름은 실제 환경에 맞춰 바꿉니다. 기존 엔드포인트가 있다면 새로 생성하는 절차 대신 타입과 멤버 설정을 확인하는 절차를 사용합니다.

1. 커스텀 엔드포인트란?

커스텀 엔드포인트는 Aurora 클러스터 안에서 직접 고른 DB 인스턴스 그룹을 하나의 엔드포인트로 묶는 기능입니다. 연결이 들어오면 Aurora가 그룹 안의 인스턴스 중 하나를 골라 처리합니다. AWS 콘솔과 한국어 문서에서는 사용자 지정 엔드포인트라고 표기합니다.

예전에는 같은 효과를 내려고 CNAME으로 DNS 별칭을 만들어 두는 방식을 썼습니다. 커스텀 엔드포인트를 쓰면 클러스터가 커지거나 줄어들 때마다 CNAME 레코드를 손보지 않아도 되고, TLS/SSL 연결도 그대로 쓸 수 있습니다.

1.1. Aurora 엔드포인트 네 종류

클러스터에는 DDL과 DML을 처리하는 프라이머리 인스턴스 하나와, 읽기 전용 쿼리를 받는 Aurora 복제본을 최대 15개까지 둘 수 있습니다. 커스텀 엔드포인트로 그룹을 나눠 쓰기 시작하면 그 클러스터의 리더 엔드포인트는 보통 쓰지 않습니다.

기본 리더 엔드포인트는 reader가 하나도 없으면 writer에 연결됩니다. READER 타입 커스텀 엔드포인트에는 같은 writer 대체 연결을 기대하면 안 됩니다. 연결 가능한 reader가 그룹에 남아 있는지 따로 확인해야 합니다.¹²

1.2. 주요 특징

• 프로비저닝 클러스터와 Aurora 서버리스 클러스터 모두, 클러스터당 커스텀 엔드포인트를 5개까지 만들 수 있습니다.
• 멤버를 지정하는 방식은 정적 목록(static list)과 제외 목록(exclusion list) 두 가지이고, 한 엔드포인트는 둘 중 하나만 가집니다.
• 엔드포인트 이름은 최대 63자입니다. 같은 리전 안에서 다른 클러스터와 이름을 겹쳐 쓸 수 없습니다.
• 엔드포인트에는 타입이 있습니다. Aurora 사용자 가이드는 현재 쓸 수 있는 타입을 READER와 ANY로 적습니다. 콘솔에서 만든 엔드포인트는 모두 ANY이고, 타입을 지정하거나 바꾸려면 AWS CLI나 RDS API를 써야 합니다.²

1.3. 연결이 분산되는 방식

커스텀 엔드포인트는 세션을 중계하는 프록시가 아닙니다. DNS가 그룹 안 인스턴스 중 하나의 IP 주소를 무작위로 돌려주는 방식으로 연결을 분산합니다. ANY 타입이면 연결이 멤버 인스턴스에 같은 확률로 배정되고, 라이터도 ANY 타입의 멤버가 될 수 있으므로 쓰기 인스턴스로 연결이 갈 수 있습니다. 읽기 인스턴스만 받게 하려면 타입을 READER로 지정합니다.

• 그룹 안의 인스턴스 하나가 응답하지 못하면, 사용 가능한 다른 대상이 있을 때 새 연결을 그 대상으로 보낼 수 있습니다. 이미 열린 연결의 실행 중 쿼리까지 다른 인스턴스로 옮겨 주는 기능은 아닙니다.
• 응답하지 못하는 인스턴스도 멤버에서 빠지지는 않습니다. 중지·재부팅·비정상 상태에서도 멤버로 남고, 다시 사용 가능해질 때까지 그 인스턴스로 연결되지 않습니다.
• 멤버를 추가하거나 제거해도 해당 인스턴스에 이미 열려 있는 연결은 끊기지 않습니다.²
• AWS 문서는 엔드포인트 단위의 DNS 전파 시간이나 초당 연결 수 상한을 제시하지 않습니다. 동시 연결 수는 엔드포인트가 아니라 각 인스턴스의 max_connections에 걸립니다.

2. 내부 조회용 인스턴스와 서비스 읽기 인스턴스 그룹 설정

2.1. 인스턴스 생성

먼저 Aurora 클러스터 안에 다음 용도의 인스턴스들을 만듭니다.

내부 조회용 인스턴스 (devops-aurora-test-instance-3)

• 데이터 분석 및 내부 보고서 생성용
• 대용량 조회 배치
• BI 도구 연동
• ETL의 읽기·추출 단계

서비스 읽기 인스턴스 (devops-aurora-test-instance-1, devops-aurora-test-instance-2)

• 실시간 사용자 요청 처리
• API 서비스 지원
• 빠른 응답이 필요한 조회 작업

이 예제에서 초기 writer는 1번, reader는 2번과 3번입니다. 서비스 그룹의 후보에 1번이 있더라도 READER 타입에서는 writer인 동안 연결 대상이 아닙니다. INSERT·UPDATE·DDL을 수행하는 ETL 적재 단계나 운영 배치는 writer 엔드포인트로 분리합니다.³

인스턴스 타입 권장사항

• 분석용 인스턴스: 메모리 최적화 인스턴스
• 서비스용 인스턴스: 범용 인스턴스

한 엔드포인트에 묶인 인스턴스는 어느 쪽으로 연결이 가도 성능이 같아야 하므로, 같은 그룹 안에서는 인스턴스 클래스와 파라미터 그룹을 맞추는 편이 좋습니다.

NOTE — 분석용 인스턴스에서 Aurora MySQL 병렬 쿼리를 쓸 계획이라면 인스턴스 클래스가 db.r* 여야 하고, db.t2·db.t3에서는 쓸 수 없습니다. 병렬 쿼리는 버퍼 풀을 채우지 않으므로 같은 쿼리를 반복해도 I/O 비용이 그대로 발생합니다. Aurora I/O-Optimized 스토리지 구성에서는 병렬 쿼리를 지원하지 않습니다.

여기에서는 동일한 사양으로 3번을 내부 조회용(ETL 및 분석 등), 1, 2번을 서비스로 구성했습니다.

2.2. AWS Aurora 커스텀 엔드포인트 생성 가이드

콘솔을 이용한 생성 방법

콘솔에서는 Attach future instances added to this cluster 체크박스가 멤버 지정 방식을 결정합니다. 체크를 비우면 화면에서 고른 인스턴스만 담는 정적 목록이 되고, 체크하면 고르지 않은 인스턴스만 빼는 제외 목록이 됩니다. 정적 목록으로 만든 엔드포인트에는 나중에 추가된 복제본이 들어오지 않고, 제외 목록으로 만든 엔드포인트에는 자동으로 들어옵니다.

1. AWS Management Console에서 Aurora 클러스터 선택

2. Endpoints 탭으로 이동

3. Create Custom Endpoint 버튼 클릭

1. 서비스 읽기용 커스텀 엔드포인트 설정

• 엔드포인트 이름 지정
• 서비스 읽기 인스턴스 선택

1. 내부 조회용 커스텀 엔드포인트 설정

• 엔드포인트 이름 지정
• 내부 조회용 인스턴스 선택

1. 생성된 커스텀 엔드포인트 확인

다음 단계 전에 두 엔드포인트를 READER 타입으로 변경합니다. 콘솔 생성 직후에는 ANY이므로 이름에 read-only를 넣거나 reader를 선택한 것만으로 역할 변경 시의 동작까지 정해지지 않습니다. 아래의 멤버·페일오버 설명은 이 전환을 마친 상태를 전제로 합니다.²⁴

aws rds modify-db-cluster-endpoint \
  --region ap-northeast-2 \
  --db-cluster-endpoint-identifier read-only \
  --endpoint-type READER

aws rds modify-db-cluster-endpoint \
  --region ap-northeast-2 \
  --db-cluster-endpoint-identifier service-read \
  --endpoint-type READER

변경 요청의 응답이 modifying이면 완료된 것이 아닙니다. 다음 조회에서 해당 엔드포인트의 Status=available, CustomEndpointType=READER를 확인합니다.⁵

aws rds describe-db-cluster-endpoints \
  --region ap-northeast-2 \
  --db-cluster-identifier devops-aurora-test \
  --query "DBClusterEndpoints[?EndpointType=='CUSTOM'].{Name:DBClusterEndpointIdentifier,Type:CustomEndpointType,Status:Status,Address:Endpoint,Static:StaticMembers,Excluded:ExcludedMembers}" \
  --output json

EndpointType=CUSTOM은 엔드포인트의 종류이고, 역할 필터는 CustomEndpointType입니다. 정적·제외 목록은 설정된 목록이므로, 이것만으로 현재 접속 가능한 인스턴스가 모두 정상인지까지 판단하지 않습니다. 기존 연결도 자동 교체되지 않으므로 마지막에는 새 연결로 접속 대상을 확인합니다.

1. Read-Only 커스텀 엔드포인트를 확인해보면 3번 인스턴스만 있는 것을 확인할 수 있습니다. 정적 목록으로 만들었기 때문에 앞으로 인스턴스를 추가해도 이 엔드포인트의 멤버는 그대로입니다.

1. READER 전환 후 초기 Service-read의 연결 대상은 2번입니다. 1번은 writer이고 3번은 제외 목록에 있기 때문입니다. 앞으로 추가되는 인스턴스는 제외 목록에 없고 reader이면 연결 대상이 됩니다. Aurora Auto Scaling이 붙인 복제본도 같은 멤버 지정 규칙을 따릅니다.

1. 다음 화면은 서비스 읽기용 4번 reader를 추가한 뒤, writer를 1번에서 4번으로 바꾸는 페일오버 예제입니다. 페일오버 전에는 서비스 읽기 대상이 2·4번이고, 이후에는 1·2번이 되는지 확인합니다. 페일오버는 실행 중 연결과 업무에 영향을 주므로 검증 환경에서 동작과 복구 절차를 확인한 뒤 운영 계획에 반영합니다.

1. 4번이 writer로 승격되면 READER 대상에서 빠지고, reader로 복귀한 1번이 연결 대상이 되는지 확인합니다. 콘솔 표시뿐 아니라 새 DB 연결에서 접속 인스턴스도 확인합니다.

1. 분석용 3번의 장애조치 우선순위를 낮춥니다. promotion-tier는 0이 가장 높고 15가 가장 낮습니다. 15는 승격 금지가 아닙니다. 다른 후보의 상태에 따라 3번이 writer가 될 수 있으며, 그때는 분석용 READER 엔드포인트의 연결 대상에서 빠집니다.⁶

aws rds modify-db-instance \
  --region ap-northeast-2 \
  --db-instance-identifier devops-aurora-test-instance-3 \
  --promotion-tier 15

역할과 승격 우선순위는 다음과 같이 대조합니다. 우선순위 변경 자체가 페일오버를 실행하는 것은 아닙니다.⁶³

aws rds describe-db-clusters \
  --region ap-northeast-2 \
  --db-cluster-identifier devops-aurora-test \
  --query "DBClusters[0].DBClusterMembers[].{Instance:DBInstanceIdentifier,Writer:IsClusterWriter,Tier:PromotionTier}" \
  --output table

IMPORTANT — ANY를 그대로 유지하면 writer·reader 역할 변경에 맞춘 자동 멤버 조정을 기대할 수 없습니다. 이 글의 읽기 분리 구성은 READER 전환, 멤버 목록 확인, 새 연결 확인까지 완료해야 합니다.

AWS CLI를 이용한 생성 방법

내부용(배치용) 엔드포인트 생성

aws rds create-db-cluster-endpoint \
  --region ap-northeast-2 \
  --db-cluster-identifier devops-aurora-test \
  --db-cluster-endpoint-identifier read-only \
  --endpoint-type READER \
  --static-members devops-aurora-test-instance-3

서비스 읽기용 엔드포인트 생성

aws rds create-db-cluster-endpoint \
  --region ap-northeast-2 \
  --db-cluster-identifier devops-aurora-test \
  --db-cluster-endpoint-identifier service-read \
  --endpoint-type READER \
  --excluded-members devops-aurora-test-instance-3

콘솔 생성과 CLI 생성은 같은 엔드포인트를 만드는 두 가지 경로입니다. 콘솔에서 이미 만들었다면 위 create 명령을 다시 실행하지 않습니다. CLI로 새로 만들 때는 처음부터 --endpoint-type READER를 지정하고, 앞의 조회 명령으로 생성 완료와 실제 타입을 확인합니다. writer 연결에는 기존 클러스터 엔드포인트를 사용합니다.³

--static-members와 --excluded-members는 함께 쓰지 않습니다. 제외 목록을 쓰면 목록에 없는 인스턴스 중 엔드포인트 타입에 맞고 사용 가능한 대상에 연결합니다. 이 글의 READER 타입에서는 writer가 제외됩니다. 만든 뒤 멤버를 손볼 때는 aws rds modify-db-cluster-endpoint, 목록을 확인할 때는 aws rds describe-db-cluster-endpoints를 씁니다.

2.3. 애플리케이션 설정

연결 풀 설정 예시

최소 연결 수: 10
최대 연결 수: 100
연결 타임아웃: 30초
유휴 연결 제거: 300초

이 숫자는 출발점입니다. 최대 연결 수는 엔드포인트에 묶인 인스턴스의 max_connections와 애플리케이션 인스턴스 대수를 함께 계산해서 정합니다.

예를 들어 애플리케이션 8개가 각각 최대 100개 연결을 가지면 전체 상한은 800개입니다. 정상 상태에서 reader가 두 개라고 해서 항상 400개씩 배정된다고 가정하면 안 됩니다. 장애로 한 개만 남았을 때의 여유와 운영·모니터링 연결도 고려합니다.

새 연결과 연결 풀 재사용을 나눠 검증합니다

DNS 기반 분산은 새 연결의 대상을 고르는 과정입니다. 연결 풀에서 이미 열린 연결을 재사용하면 쿼리마다 다른 인스턴스로 이동하지 않습니다. 멤버를 추가해도 기존 풀의 연결이 자동으로 새 인스턴스로 옮겨 가지 않고, 멤버를 제거해도 기존 연결은 유지될 수 있습니다.²

Aurora MySQL에서는 접속한 연결에서 다음을 확인합니다.³

SELECT @@aurora_server_id AS instance_id,
       CONNECTION_ID() AS connection_id;

1. 커스텀 엔드포인트로 새 연결을 여러 번 만들고 instance_id를 기록합니다.
2. 위의 역할 조회 결과와 비교해 서비스 그룹에는 허용한 reader만 나타나는지 확인합니다.
3. 같은 풀 연결을 재사용할 때와 연결을 닫고 새로 만들 때를 구분합니다. 짧은 표본이 균등하지 않다는 이유만으로 오류라고 판단하지 않습니다.
4. 멤버 변경·페일오버 이후에는 기존 연결의 상태와 새 연결의 대상을 따로 확인합니다. 애플리케이션과 드라이버의 DNS 캐시·연결 수명·재연결 정책도 함께 점검합니다.

Status=available만으로 애플리케이션의 DNS·TLS·인증·접속 대상까지 검증된 것은 아닙니다. 반대로 연결 하나가 실패했다고 모든 연결을 한꺼번에 폐기하면 재접속 부하가 커질 수 있으므로, 풀의 오류 처리와 재시도 정책을 실제 장애 시나리오에서 확인합니다.

분석 세션의 쿼리 타임아웃

분석용 세션은 배치나 리포트 쿼리가 중간에 끊기지 않도록 타임아웃을 길게 잡습니다. 변수 이름과 단위는 엔진마다 다릅니다.

-- Aurora MySQL: 밀리초 단위이고, 읽기 전용 SELECT 에만 적용됩니다
SET SESSION max_execution_time = 3600000;

-- Aurora PostgreSQL
SET statement_timeout = '3600s';

2.4. 단일 멤버 그룹의 가용성

이 예제의 분석용 read-only는 3번 하나만 정적으로 지정합니다. 성능 분리를 보여 주는 구성이지 분석 조회의 고가용성까지 보장하는 구성은 아닙니다.

분석 작업의 가용성이 필요하면 서로 다른 가용 영역에 복수의 분석용 reader를 두고 같은 그룹에 명시적으로 포함하는 방법을 검토합니다. 단, 여러 인스턴스의 동시 장애까지 없애 주는 것은 아니므로 재시도·복구 정책도 필요합니다.⁶²

기본 reader 엔드포인트로 무조건 대체하면 분석 쿼리가 서비스용 reader로 갈 수 있고, reader가 전혀 없으면 writer로 연결될 수 있습니다. 원래의 워크로드 분리 목적을 유지할지, 장애 시에는 조회를 중단할지 먼저 정합니다.¹

3. 커스텀 엔드포인트 활용의 장점

3.1. 성능 최적화

워크로드 분리

• 장시간 실행 쿼리와 빠른 응답 쿼리의 분리
• 리소스 경합 최소화
• 쿼리 타임아웃 설정의 유연성

버퍼 풀 분리

인스턴스마다 버퍼 풀이 따로 있으므로, 분석용 인스턴스의 대용량 스캔이 서비스 인스턴스의 캐시를 밀어내지 않습니다.

이 분리는 주로 인스턴스의 CPU·메모리·캐시 경합을 줄이는 방법입니다. 클러스터 데이터와 스토리지는 공유하므로, 완전히 독립된 클러스터 수준의 성능·장애 격리를 의미하지는 않습니다.⁶

3.2. 운영 효율성

모니터링 및 관리

• 워크로드별 독립적인 모니터링
• 리소스 사용량 추적 용이
• 장애 원인 신속 파악

확장성

• 워크로드 그룹별 인스턴스 사양·멤버 수 조정
• 인스턴스가 늘거나 줄어도 애플리케이션의 접속 정보는 그대로 유지
• 트래픽 피크 대응

Aurora Auto Scaling의 범위

기본 Aurora Auto Scaling은 커스텀 엔드포인트별 인스턴스 수를 따로 관리하는 기능이 아닙니다. reader CPU·연결 수를 사용하는 사전 정의 지표는 클러스터의 모든 reader 평균을 기준으로 하며, 수동으로 만든 reader와 커스텀 엔드포인트 소속 reader도 포함합니다.⁷

따라서 분석용 3번의 CPU 상승이 클러스터 평균을 올리고, 그 결과 새 reader가 추가될 수 있습니다. 이 글의 서비스 그룹은 3번만 제외하므로 새 reader가 서비스 그룹에 들어가지만, 정적 목록인 분석 그룹에는 자동으로 들어가지 않습니다. 분석 부하로 증설했는데 분석 그룹의 용량은 그대로인 상황을 검토해야 합니다.

그룹별로 용량을 따로 늘려야 한다면 인스턴스 생성·멤버 목록 변경을 함께 관리하는 운영 절차나 별도 자동화가 필요합니다. Auto Scaling 정책을 만들었다는 사실만으로 그룹별 독립 확장이 완성되지는 않습니다.

3.3. 비용 최적화

• 별도의 프록시 계층을 두지 않으므로 그 계층의 요금과 운영 부담이 없습니다.
• 워크로드에 맞는 인스턴스 클래스를 그룹별로 따로 고를 수 있습니다.

3.4. 보안

커스텀 엔드포인트는 보안 경계가 아닙니다. Aurora의 보안 그룹 변경은 같은 클러스터의 모든 DB 인스턴스에 적용됩니다. 같은 클러스터의 분석용 인스턴스와 서비스용 인스턴스에 서로 다른 보안 그룹 경계를 둔 것처럼 설명하면 안 됩니다.⁸

워크로드별 계정·DB 권한을 별도로 정하고, 읽기 애플리케이션에는 필요한 조회 권한만 부여합니다. read-only라는 DNS 이름이나 READER 라우팅 타입이 DB 계정의 쓰기 권한을 제거하는 것은 아닙니다. 페일오버 전부터 열려 있던 연결도 고려해야 합니다.

IAM 데이터베이스 인증을 사용하더라도 네트워크 접근, 접속 인증, DB 안에서 실행할 수 있는 SQL 권한은 각각 확인합니다. 네트워크 수준의 분리가 요구된다면 커스텀 엔드포인트만으로 충족했다고 보지 말고 클러스터·네트워크 설계까지 검토합니다.⁸

4. 운영 및 모니터링

4.1. 핵심 모니터링 지표

• CPU 사용률
• 메모리 사용량
• IOPS
• 지연 시간
• 쓰레드 수
• 연결 수

4.2. 알림 임계값 예시

아래 값은 출발점입니다. 인스턴스 클래스와 쿼리 특성에 맞춰 조정합니다. 특히 분석용 인스턴스는 CPU가 오래 높게 유지되는 것이 정상이므로, 서비스 인스턴스와 같은 기준을 쓰면 알림이 계속 울립니다.

성능 관련
- CPU 사용률 > 80%
- 가용 메모리 < 20%
- 평균 지연 시간 > 100ms

연결 관련
- 활성 연결 수 > 설정된 임계값
- 연결 거부 발생
- 연결 타임아웃 발생

WARNING — 커스텀 엔드포인트는 스냅샷에 포함되지 않습니다. 스냅샷으로 클러스터를 복원하면 엔드포인트를 다시 만들어야 하고, 원본과 같은 리전에 복원했다면 이름도 새로 지어야 합니다. 복원 절차를 문서로 남길 때 이 단계를 함께 적어 두는 편이 좋습니다.

4.3. 변경·장애 시 검증할 항목

CPU·연결 수·쿼리 지연은 실제 연결된 DB 인스턴스와 애플리케이션 풀 단위로 대조합니다. 커스텀 엔드포인트 하나의 상태만 보고 그룹 전체가 정상이라고 판단하지 않습니다.

5. 결론 및 베스트 프랙티스

AWS Aurora의 커스텀 엔드포인트를 활용하면 별도 SQL Proxy 없이 내부 조회용 인스턴스와 서비스 읽기 인스턴스 그룹을 나눌 수 있습니다. 분석과 서비스 조회의 인스턴스 자원 경합을 줄이되, 역할 변경·기존 연결·단일 멤버 장애·공유 클러스터의 제약까지 함께 설계해야 합니다.

5.1. 설계 원칙

• 워크로드 특성에 따른 명확한 분리
• 한 엔드포인트 안의 인스턴스는 사양과 파라미터를 맞춰 구성
• 앞으로 추가될 인스턴스를 어느 엔드포인트가 받을지 정적 목록과 제외 목록으로 미리 결정
• 페일오버로 역할이 바뀔 때의 멤버십 동작을 엔드포인트 타입으로 결정
• 승격 우선순위를 승격 금지로, 연결 대상 분리를 보안 격리로 해석하지 않기
• Auto Scaling 지표와 새 reader의 그룹 편입 규칙을 함께 확인

5.2. 운영 체크리스트

• 정기적인 성능 모니터링
• 보안 설정 검토
• 비용 최적화 리뷰
• 장애 대응 시나리오 검증
• 스냅샷 복원 절차에 엔드포인트 재생성 포함
• 변경 완료 상태뿐 아니라 새 연결의 실제 접속 인스턴스 확인
• 단일 멤버 장애와 기존 연결 풀의 잔류에 대한 대응 확인

참고 자료

데이터베이스로 가는 트래픽을 암호화하라는 권고는 어디서나 볼 수 있습니다. 그런데 AWS VPC나 사내 내부망처럼 외부 접근이 통제된 구간이라면 어떨까요? 애플리케이션 서버와 MySQL 사이에도 TLS를 걸어야 할까요?

이 글은 그 질문을 세 축으로 나눠 봅니다. 법령이 실제로 무엇을 요구하는지, 암호화가 막는 위협이 그 구간에 있는지, 켜기로 정했을 때 무엇을 설정해야 하는지입니다.

NOTE — 2026-09 현재 지원되는 MySQL 라인은 8.4 LTS와 9.7 LTS입니다. 8.0은 2026-04-21부로 Oracle Sustaining Support로 넘어갔습니다. 이 글의 설정값은 8.4 기준입니다.

1. TLS/SSL의 기본 개념

TLS는 네트워크 구간에 세 가지를 제공합니다.

• 기밀성 — 데이터를 암호화해 제3자가 읽지 못하게 합니다.
• 무결성 — 전송 중 변경·유실·재전송을 탐지합니다.
• 인증 — X.509 인증서로 통신 상대의 신원을 확인합니다.

이름부터 짚고 갑니다. MySQL 공식 문서는 TLS를 SSL이라고 부르는 관행을 인정하면서도, SSL의 암호화가 약하기 때문에 MySQL이 실제로 SSL 프로토콜을 쓰지는 않는다고 명시합니다. 설정 변수와 상태 변수에 ssl_ 접두어가 남아 있는 것은 역사적 이유입니다.

지금 이 연결이 암호화되고 있는가

-- 값이 비어 있으면 이 연결은 암호화되지 않았습니다
SHOW STATUS LIKE 'ssl_cipher';

-- 어떤 프로토콜로 붙었는지까지 확인합니다
SHOW SESSION STATUS LIKE 'Ssl_version';

두 값 모두 지금 세션에 대한 값입니다. SHOW STATUS는 범위를 생략하면 SESSION입니다.

8.4가 받아들이는 프로토콜

MySQL 8.4는 TLSv1.2와 TLSv1.3만 지원합니다. TLSv1과 TLSv1.1은 8.0.26에서 폐기 예고됐고 8.0.28에서 제거됐습니다. 문서는 두 프로토콜이 쓰는 알고리즘이 약하고 낡았다는 이유를 적습니다.

tls_version의 기본값은 서버가 링크한 SSL 라이브러리와 해당 릴리스가 지원하는 프로토콜 전체이고, 8.4에서는 보통 TLSv1.2,TLSv1.3입니다. TLSv1.3은 OpenSSL 1.1.1 이상으로 컴파일된 서버에서만 쓸 수 있습니다. 서버는 기동할 때 OpenSSL 버전을 확인해 1.1.1보다 낮으면 기본값에서 TLSv1.3을 빼고 TLSv1.2만 남깁니다.

켜지 않았는데 켜져 있을 수 있습니다

서버는 인증서와 키 파일을 자동으로 찾습니다. 데이터 디렉터리에 ca.pem·server-cert.pem·server-key.pem이라는 이름의 유효한 파일이 있으면 암호화 연결 지원을 스스로 켜고 에러 로그에 기록을 남깁니다. OpenSSL로 컴파일한 서버는 이 파일이 없을 때 기동 시점에 자동 생성할 수도 있습니다. 클라이언트 기본값도 같은 방향입니다. MySQL 클라이언트 프로그램은 서버가 지원하면 암호화 연결을 시도하고, 맺지 못하면 평문으로 내려갑니다.

그래서 “우리는 TLS를 안 씁니다”가 사실이 아닐 수 있고, “TLS를 켰습니다”가 모든 연결에 대해 참이 아닐 수도 있습니다. 논의의 출발점은 위 상태 변수로 실제 연결을 확인하는 것입니다.

2. 내부 네트워크에서의 TLS/SSL: 장단점 분석

장점

1. 기밀성 보장 — 같은 세그먼트에 올라온 스니핑과 중간자 공격을 막습니다.
2. 심층 방어 — 네트워크 통제가 무너졌을 때 남는 계층입니다. 저장 데이터 암호화는 이 구간을 보호하지 않습니다. MySQL 문서는 데이터가 네트워크에 올라간 시점에는 평문 형태라고 명시합니다.
3. 규정 준수 — 적용받는 기준이 전송 구간 암호화를 요구하는 경우입니다(3절).

단점

1. 성능 오버헤드 — 암복호에 CPU를 쓰고 지연이 늘어납니다. 비용이 몰리는 지점은 핸드셰이크입니다(5절).
2. 인증서 수명 관리 — 발급·배포·갱신이 운영 업무로 남고, 만료는 장애로 옵니다.
3. 관찰 비용 — 패킷 캡처로 쿼리를 들여다보던 방식이 막힙니다.

3. 법령은 무엇을 요구하는가

국내에서 전송 구간 암호화 의무의 근거는 「개인정보의 안전성 확보조치 기준」 제7조입니다. 현행 고시는 개인정보보호위원회고시 제2026-9호이고 2026-07-01 시행입니다. 상위 근거는 시행령 제30조제1항제4호 다목입니다.

제7조에서 전송 암호화를 요구하는 항은 둘이고, 적용 구간이 서로 다릅니다.

이 차이가 질문의 핵심입니다. 제4항은 인터넷망 구간을 전제하므로, 문언대로 읽으면 내부망 안의 애플리케이션 서버와 DB 사이 구간은 제4항의 범위 밖입니다. 고시 제2조제12호는 내부망을 인터넷망 차단이나 접근 통제시스템으로 인터넷 구간에서의 접근이 통제·차단되는 구간으로 정의합니다. DB 연결에 TLS를 쓰라고 직접 요구하는 조문은 없습니다.

그런데 제1항은 구간을 제한하지 않습니다. DB 접속은 그 자체로 인증정보를 실어 보냅니다. 내부망이라도 인증정보가 같은 연결을 타고 흐른다면 제1항이 그 구간에 걸립니다. 조문만 근거로 “내부망이니 켜지 않아도 된다”고 정리하기 어려운 이유가 여기 있습니다.

조문 좌표와 이용자·비이용자 트랙 구분은 데이터 암호화 문서에 정리해 두었습니다.

조문과 별개로, 내부망이어도 TLS를 켜는 쪽으로 기울게 하는 조건이 있습니다.

1. 멀티 테넌트 환경 — 같은 VPC나 클러스터에서 여러 고객의 데이터를 처리하는 경우
2. 민감도가 높은 데이터 — 결제 정보나 의료 기록처럼 유출 시 피해가 큰 데이터를 다루는 경우
3. 복잡한 네트워크 토폴로지 — 여러 세그먼트·리전·계정을 지나 어느 구간이 인터넷망인지 단정하기 어려운 경우
4. 일관된 보안 정책 — 개발·테스트·운영에서 같은 설정을 유지하려는 경우. 운영에만 켜 두면 인증서 문제를 배포 시점에 발견합니다.

4. TLS/SSL 없이 보안을 강화하는 방법

내부망에서 TLS를 켜지 않기로 정한다면, 그 판단을 받쳐 줄 통제가 필요합니다.

1. 네트워크 분리 — VLAN, 서브넷, NACL로 데이터베이스 트래픽을 격리합니다.
2. 강력한 인증 — 다단계 인증(MFA)과 IAM 역할을 사용합니다.
3. 암호화된 스토리지 — 저장 데이터(data at rest) 암호화를 사용합니다.
4. 최소 권한 원칙 — 필요한 최소한의 권한만 부여합니다.
5. 네트워크 모니터링 — 이상 징후를 탐지하기 위한 실시간 모니터링을 구현합니다.

AWS 환경에서는 다음과 같이 구성할 수 있습니다.

VPC:
  SecurityGroups:
    - InboundRule:
        Protocol: TCP
        Port: 3306
        Source: 10.0.0.0/16  # 내부 네트워크만 허용
  NetworkACLs:
    - Rule:
        Action: ALLOW
        Protocol: TCP
        Port: 3306
        Source: 10.0.0.0/16  # 내부 네트워크만 허용

RDS:
  EncryptionAtRest: true
  IAMDatabaseAuthentication: enabled

CloudWatch:
  Alarms:
    - Metric: DatabaseConnections
      Threshold: 100
      Period: 5 minutes

이 조치들은 네트워크에 올라간 평문 자체를 바꾸지 않습니다. TLS를 대체하는 것이 아니라, 접근 경로를 좁혀 위험을 낮추는 쪽입니다.

5. 켤 때 확인할 설정과 성능

강제 지점은 셋입니다

require_secure_transport는 Boolean이고 기본값은 OFF입니다. 켜면 서버는 TLS로 암호화된 TCP/IP 연결, Unix 소켓 파일 연결, Windows 공유 메모리 연결만 허용하고 나머지는 ER_SECURE_TRANSPORT_REQUIRED로 거절합니다. 이 변수만으로는 모든 연결이 TLS라고 말할 수 없습니다. 소켓 파일 접속은 통과합니다.

계정별 요구가 이 변수보다 우선합니다. 문서는 REQUIRE SSL로 만든 계정이라면 require_secure_transport를 켜도 Unix 소켓 파일로는 접속할 수 없다고 적습니다.

[mysqld]
require_secure_transport=ON
tls_version=TLSv1.2,TLSv1.3

클라이언트 쪽은 --ssl-mode로 갈립니다.

문서는 기본값 PREFERRED가 서버 신원을 확인하지 않는다는 점을 짚고, 정교한 중간자 공격을 막으려면 VERIFY_CA나 VERIFY_IDENTITY를 쓰라고 권합니다. 두 값이 기본이 아닌 이유는 모든 클라이언트에 CA 인증서를 안정적으로 배포하지 않으면 가용성 문제가 생기기 때문입니다. 서버가 자동 생성한 자기서명 인증서에는 Common Name에 서버 이름이 없어 VERIFY_IDENTITY가 동작하지 않으므로, 1절의 자동 발견으로 켜진 TLS를 그대로 두면 신원 검증까지는 가지 못합니다.

세 지점을 다 지나야 암호화 연결입니다. 하나만 켜 두면 아래 칸의 결과 가운데 하나로 떨어지고, 그중 평문 연결은 오류 없이 조용히 맺힙니다.

암호군은 프로토콜별로 변수가 다릅니다. TLSv1.2는 서버 ssl_cipher와 클라이언트 --ssl-cipher, TLSv1.3은 서버 tls_ciphersuites와 클라이언트 --tls-ciphersuites입니다. tls_ciphersuites를 설정하지 않으면 기본값 NULL로 기본 집합을 허용하고, 빈 문자열로 두면 활성 암호군이 없어 암호화 연결을 맺을 수 없습니다.

대체로 기본값을 그대로 쓰는 편이 안전합니다. 8.4가 TLSv1.2에 기본으로 넘기는 암호군은 ECDHE·DHE 키 교환과 GCM·CCM·CHACHA20-POLY1305 조합뿐입니다. 순방향 비밀성과 AEAD 모드를 갖춘 것만 켜 둔 셈입니다. 반대로 aNULL·eNULL·EXPORT·LOW·MD5·DES·RC2·RC4·PSK·SSLv3은 영구 제한입니다. ssl_cert에 지정한 인증서가 제한된 암호군을 쓰면 서버는 암호화 연결 지원을 끈 상태로 기동합니다.

인증 플러그인이 이미 전송 보안을 전제합니다

8.4의 기본 인증 플러그인은 caching_sha2_password입니다. 이 플러그인으로 접속하려면 보안 연결이거나, RSA 키페어로 비밀번호를 교환하는 평문 연결이어야 합니다. 보안 연결이면 RSA 키페어가 필요 없고, 평문 연결이면 비밀번호만 RSA로 암호화해 보냅니다. 서버는 기본적으로 공개키를 클라이언트에 보내지 않으므로, 아무 준비 없이 평문으로 붙으면 이렇게 끊깁니다.

ERROR 2061 (HY000): Authentication plugin 'caching_sha2_password'
reported error: Authentication requires secure connection.

--get-server-public-key로 서버에서 공개키를 받거나 --server-public-key-path로 로컬 사본을 지정하면 통과합니다. 한 번 성공하면 서버 캐시에 항목이 남아 이후 연결은 보안 연결도 RSA 키페어도 요구하지 않습니다. 계정 생성, 비밀번호 변경, RENAME USER, FLUSH PRIVILEGES 뒤의 첫 연결은 다시 둘 중 하나를 요구하고, 캐시는 서버 재시작 사이에 유지되지 않습니다.

TLS를 끄더라도 비밀번호가 평문으로 흐르지는 않는다는 뜻입니다. 다만 그 뒤에 흐르는 쿼리와 결과는 평문입니다.

성능

TLS 오버헤드로 인용할 만한 공개 측정 자료는 마땅치 않습니다. 쿼리 특성과 연결 수립 빈도에 따라 결과가 갈리므로, 도입 판단은 자기 워크로드에서 측정해 정합니다.

비용이 몰리는 지점은 대칭키 암복호보다 핸드셰이크입니다. 그래서 먼저 볼 값이 정해져 있습니다.

두 시스템 변수를 바꾼 값은 ALTER INSTANCE RELOAD TLS를 실행하거나 서버를 재시작한 뒤에 적용됩니다.

측정은 구간을 나눠서 합니다.

• 연결을 재사용하는 정상 상태의 응답시간 분포와 서버 CPU 사용량
• 연결을 새로 맺을 때의 지연. 커넥션 풀이 없거나 자주 비는 워크로드가 여기서 드러납니다
• 재시작이나 페일오버 직후처럼 연결이 한꺼번에 몰리는 구간

커넥션 풀로 연결을 재사용하면 핸드셰이크 비용은 대부분 지나갑니다. 요청마다 접속을 새로 맺는 구조라면 TLS보다 그 구조를 먼저 봅니다.

6. 의사결정 가이드

1. 위험 평가 — 데이터 민감도는 어느 정도인가, 이 구간이 고시 제2조제12호가 말하는 내부망인가, 인증정보가 이 연결로 흐르는가
2. 조문 판정 — 제7조제1항과 제4항 중 무엇에 걸리는지 확인하고 판단 근거를 기록으로 남깁니다
3. 성능 측정 — 5절 항목을 테스트 환경에서 재 봅니다. 감당하기 어려운 수치가 나오면 연결 재사용 구조를 먼저 고칩니다
4. 대안 검토 — IPsec이나 서비스 메시처럼 네트워크 계층에서 암호화하는 방식이 더 맞는지 봅니다. 이쪽은 애플리케이션 코드와 DB 계정 설정을 건드리지 않습니다
5. 단계적 적용 — 서버에서 암호화 지원을 켜고, 클라이언트를 --ssl-mode=REQUIRED 이상으로 옮긴 뒤, 평문 연결이 남지 않았는지 세션 단위로 확인하고 마지막에 require_secure_transport를 켭니다

7. 결론

내부망 MySQL 연결에 TLS가 필요한지는 한 문장으로 답하기 어렵습니다. 다만 판단을 흐리게 만드는 두 가지는 정리할 수 있습니다.

첫째, 조문이 직접 요구하지 않는다는 것과 켜지 않아도 된다는 것은 다릅니다. 고시 제7조제4항은 인터넷망 구간을 전제하므로 내부망은 그 범위 밖이지만, 제7조제1항은 인증정보에 대해 구간을 제한하지 않습니다.

둘째, 성능 부담은 대개 막연하게 추정됩니다. 남의 수치로 결정할 문제가 아니라, 연결 재사용 패턴을 확인하고 자기 워크로드에서 재보면 대부분 답이 나옵니다.

내부망이 통제돼 있고 다른 계층의 통제가 갖춰져 있다면 TLS 없이 운영하는 선택도 성립합니다. 그때 남길 것은 설정이 아니라 판단의 근거입니다. 어느 조문에 걸리는지, 어느 통제로 대체했는지, 무엇을 측정했는지를 남기면 다음 담당자가 같은 질문을 처음부터 다시 하지 않습니다.

EKS 에 올라가는 작은 서비스나 Superset·Airflow 같은 솔루션의 메타 정보를 담을 DB 하나 때문에 RDS 인스턴스를 따로 띄우는 것은 비용이 아깝습니다. 그런데 컨테이너로 그냥 올리면 파드가 종료될 때 데이터가 같이 사라집니다. 그래서 DB 컨테이너에는 파드와 수명이 분리된 스토리지를 마운트해야 합니다.

쿠버네티스는 이 목적으로 PersistentVolume(PV), PersistentVolumeClaim(PVC), StorageClass(SC) 를 제공하고, Amazon EKS 에서는 그 뒤를 Amazon EBS 같은 AWS 스토리지가 받습니다. 이 글에서는 세 가지를 비용·백업·고가용성 측면에서 비교합니다.

NOTE — 동작 설명은 Amazon EKS 표준 지원 버전인 쿠버네티스 1.34·1.35·1.36 을 기준으로 합니다. EKS 는 마이너 버전마다 표준 지원 14개월, 이어서 연장 지원 12개월을 제공합니다.

스토리지 옵션 비교

먼저 세 가지의 특징을 표로 정리합니다.

세 가지는 서로 대체재가 아닙니다. PVC 가 필요한 용량을 요청하고, StorageClass 가 그 요청을 어느 드라이버로 어떻게 만들지 정하고, 그 결과로 EBS 볼륨과 PV 가 생깁니다. 이제 각각을 자세히 보겠습니다.

1. PersistentVolume 과 PersistentVolumeClaim

PersistentVolume 은 관리자가 미리 프로비저닝하거나 StorageClass 를 통해 동적으로 프로비저닝하는 클러스터의 스토리지 조각입니다. 파드는 PV 를 직접 참조하지 않고 PVC 로 요청하며, 바인딩된 PVC 를 볼륨으로 마운트합니다.

장점

• 스토리지와 사용을 분리해 관리하기 쉽습니다.
• NFS, iSCSI, 클라우드 블록 스토리지 등 다양한 백엔드를 CSI 드라이버로 붙일 수 있습니다.
• 데이터 수명을 파드 수명과 분리할 수 있습니다.

단점

• PV 를 직접 만드는 방식은 용량·AZ·재사용을 사람이 관리해야 합니다.
• 볼륨 수가 늘어나면 남은 볼륨을 추적하기 어려워집니다.

비용과 백업, 고가용성

PV 자체는 과금 대상이 아니고, 비용과 내구성은 뒤에 있는 스토리지가 결정합니다. 온프레미스라면 하드웨어 투자, 클라우드라면 해당 서비스의 가격 정책을 그대로 따릅니다. 백업도 마찬가지로 백엔드가 스냅샷을 지원하는지에 달려 있고, 지원하지 않으면 덤프 같은 별도 수단을 마련해야 합니다.

StatefulSet 이 만드는 PVC 의 수명

데이터베이스는 보통 Deployment 가 아니라 StatefulSet 으로 띄웁니다. StatefulSet 의 volumeClaimTemplates 에 PVC 템플릿을 적으면 파드마다 전용 PVC 가 만들어지고, 파드가 재시작해도 같은 PVC 에 다시 붙습니다. 안정 버전 API 인 apps/v1 을 씁니다.

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: postgres
spec:
  serviceName: postgres
  replicas: 1
  # selector, template 은 생략
  volumeClaimTemplates:
    - metadata:
        name: data
      spec:
        accessModes: ["ReadWriteOnce"]
        storageClassName: ebs-gp3
        resources:
          requests:
            storage: 20Gi

주의할 점은 정리 동작입니다. StatefulSet 을 지우거나 레플리카를 줄여도 쿠버네티스는 그 PVC 와 볼륨을 함께 지우지 않습니다. 공식 문서는 자동 삭제보다 데이터 안전이 더 중요하기 때문이라고 설명합니다. 그래서 StatefulSet 만 지우고 잊으면 EBS 볼륨이 그대로 남아 매달 요금이 나갑니다. kubectl get pvc 로 확인하고 직접 지워야 합니다.

정리를 자동화하려면 .spec.persistentVolumeClaimRetentionPolicy 를 씁니다. apps/v1 StatefulSet 스펙의 필드이며 whenDeleted 와 whenScaled 에 각각 Retain 또는 Delete 를 줄 수 있고, 기본값은 둘 다 Retain 입니다.

spec:
  persistentVolumeClaimRetentionPolicy:
    whenDeleted: Retain
    whenScaled: Delete

이 정책은 StatefulSet 이 삭제되거나 스케일 다운되어 파드가 사라지는 경우에만 적용됩니다. 노드 장애로 파드가 없어진 경우에는 PVC 가 남고, 대체 파드가 같은 볼륨에 다시 붙습니다. StatefulSet 이 만든 PVC 의 자동 정리는 쿠버네티스 1.32 에 들어갔으므로, 현재 EKS 표준 지원 버전에서는 모두 쓸 수 있습니다.

2. StorageClass (SC)

StorageClass 는 관리자가 제공하는 스토리지의 “클래스”를 기술하는 방법입니다. 어떤 프로비저너를 쓸지, 어떤 파라미터로 볼륨을 만들지, PVC 를 지웠을 때 볼륨을 어떻게 할지를 한곳에 모읍니다.

장점

• 동적 볼륨 프로비저닝을 지원합니다.
• 스토리지 타입과 성능 특성을 추상화해 PVC 쪽 매니페스트를 단순하게 유지합니다.
• 클라우드 제공업체의 스토리지 서비스와 CSI 드라이버로 연결됩니다.

단점

• 드라이버 설치와 권한 설정 등 초기 구성이 필요합니다.
• 쓸 수 있는 파라미터는 드라이버가 정하므로 백엔드마다 다릅니다.

EKS 에서 쓰는 gp3 StorageClass

EBS 볼륨을 동적으로 받으려면 프로비저너가 ebs.csi.aws.com 인 StorageClass 가 필요합니다. EBS CSI 드라이버는 type 을 지정하지 않으면 gp3 볼륨을 만들지만, 클래스에 명시해 두면 의도가 드러납니다.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ebs-gp3
provisioner: ebs.csi.aws.com
parameters:
  type: gp3
  encrypted: "true"
reclaimPolicy: Delete
allowVolumeExpansion: true
volumeBindingMode: WaitForFirstConsumer

이 네 줄이 운영 결과를 좌우합니다.

• volumeBindingMode — 비워 두면 Immediate 가 적용되어 PVC 를 만드는 즉시 볼륨이 생깁니다. WaitForFirstConsumer 는 그 PVC 를 쓰는 파드가 스케줄될 때까지 볼륨 생성을 미룹니다.
• reclaimPolicy — 지정하지 않으면 Delete 입니다. PVC 를 지우면 동적으로 만들어진 볼륨까지 지워집니다. 데이터를 남기려면 Retain 으로 둡니다.
• allowVolumeExpansion — true 여야 PVC 의 요청 용량을 키워 볼륨을 확장할 수 있습니다. 줄이는 것은 불가능합니다.
• encrypted — 드라이버 기본값은 false 이므로 암호화가 필요하면 직접 켭니다.

클러스터에 기본 StorageClass 가 있는지는 kubectl get storageclass 로 확인합니다. storageclass.kubernetes.io/is-default-class: "true" 애노테이션이 붙은 클래스가 PVC 에 storageClassName 을 적지 않았을 때 쓰입니다. EKS Auto Mode 는 StorageClass 를 만들어 주지 않으므로 직접 만들어야 하고, 이때 프로비저너는 ebs.csi.eks.amazonaws.com 입니다.

WARNING — EBS 볼륨은 만들어진 가용 영역 하나에만 속합니다. AWS 문서는 볼륨과 인스턴스가 같은 가용 영역에 있어야 한다고 적습니다. Immediate 로 먼저 만든 볼륨이 a 존에 있는데 파드가 c 존 노드로 스케줄되면 마운트가 실패하고 파드는 Pending 에 머뭅니다. 노드 그룹이 여러 AZ 에 걸쳐 있다면 WaitForFirstConsumer 를 쓰거나 allowedTopologies 로 AZ 를 고정합니다.

3. Amazon EBS (Elastic Block Store)

EBS 는 AWS 의 블록 스토리지 서비스입니다. 쿠버네티스는 1.23 부터 AWS EBS 의 CSI 마이그레이션을 기본으로 켰고, 현행 쿠버네티스 볼륨 문서의 in-tree 볼륨 타입 목록에 AWS EBS 는 들어 있지 않습니다. EKS 에서 EBS 볼륨을 쓰려면 Amazon EBS CSI 드라이버를 설치해야 합니다.

드라이버 설치와 IAM 권한

AWS 는 EBS CSI 드라이버를 EKS 애드온으로 설치하라고 권고합니다. 애드온 이름은 aws-ebs-csi-driver 이고, 클러스터가 요구하는 플랫폼 버전은 다음 명령으로 확인합니다.

aws eks describe-addon-versions --addon-name aws-ebs-csi-driver

드라이버는 EC2 API 를 호출하므로 IAM 권한이 필요합니다. AWS 는 EKS Pod Identity 를 권하며, 서비스 어카운트용 IAM 역할(IRSA)도 쓸 수 있습니다. 관리형 정책 AmazonEBSCSIDriverPolicyV2 를 붙인 역할을 만들어 애드온에 연결하면, 애드온이 kube-system 네임스페이스에 ebs-csi-controller-sa 서비스 어카운트를 만들어 사용합니다.

권한이 없으면 볼륨이 생기지 않고 kubectl describe pvc 에 다음 문구가 찍힙니다.

failed to provision volume with StorageClass
could not create volume in EC2: UnauthorizedOperation

스냅샷 기능을 쓰려면 CSI 스냅샷 컨트롤러를 먼저 설치해야 합니다. EKS Auto Mode 클러스터에서는 EBS CSI 컨트롤러를 설치하지 않아도 되지만, 블록 스토리지가 별도 프로비저너 ebs.csi.eks.amazonaws.com 로 동작하며 ebs.csi.aws.com 이 만든 볼륨과 따로 관리됩니다. 기존 볼륨을 Auto Mode 로 옮기려면 스냅샷을 거쳐야 합니다.

제약

• Fargate 파드에는 EBS 볼륨을 마운트할 수 없습니다. 컨트롤러는 Fargate 노드에서 실행할 수 있지만, 노드 DaemonSet 은 EC2 인스턴스에서만 실행됩니다.
• EBS 볼륨과 EBS CSI 드라이버는 EKS Hybrid Nodes 와 호환되지 않습니다.
• 애드온 지원 범위는 최신 버전과 그 직전 버전입니다.

비용

EBS 는 프로비저닝한 용량 기준으로 과금하므로, 파드를 내려도 볼륨이 남아 있으면 요금이 계속 나갑니다. gp3 는 용량과 IOPS·처리량을 따로 지정할 수 있어 성능과 비용을 나눠 조절하기 좋습니다. 스냅샷은 증분으로 저장되므로 세대마다 전체 용량이 중복 과금되지는 않습니다.

백업

스냅샷 기능이 서비스에 내장돼 있고 AWS Backup 과 연동해 정책으로 관리할 수 있습니다. 쿠버네티스 쪽에서 VolumeSnapshot 리소스로 다루려면 앞서 말한 CSI 스냅샷 컨트롤러가 필요합니다.

고가용성

내구성은 볼륨 타입마다 다릅니다. AWS 문서는 gp2·gp3·io1·st1·sc1 을 99.8~99.9%(연간 장애율 0.1~0.2%), io2 Block Express 를 99.999%(연간 장애율 0.001%) 로 적습니다.

내구성과 AZ 장애 대비는 다른 문제입니다. 볼륨은 단일 AZ 자원이므로 AZ 하나가 죽으면 그 볼륨에 붙은 DB 파드를 다른 AZ 에서 되살릴 수 없습니다. AZ 장애까지 견뎌야 한다면 데이터베이스 자체의 복제를 구성하거나, 복제와 장애 조치를 서비스가 맡아 주는 RDS 를 선택하는 편이 낫습니다.

결론

스토리지 솔루션을 고를 때는 워크로드 특성, 필요한 성능, 예산, 운영 팀의 숙련도를 함께 봐야 합니다.

• PersistentVolume 과 PVC 는 데이터 수명을 파드와 분리하는 계층입니다. PV 를 손으로 만드는 방식은 온프레미스나 특수한 요구가 있을 때로 남겨 두는 편이 좋습니다.
• StorageClass 는 그 생성을 자동화하는 규칙입니다. EKS 에서는 volumeBindingMode 와 reclaimPolicy 를 잘못 잡으면 마운트 실패나 데이터 삭제로 이어지므로 먼저 확인합니다.
• Amazon EBS 는 EKS 에서 가장 손이 덜 가는 백엔드지만, CSI 드라이버 애드온과 IAM 권한이 전제이고 볼륨이 단일 AZ 에 묶입니다.

작은 메타 DB 하나를 컨테이너로 두는 것은 합리적인 선택입니다. 다만 영속성은 볼륨을 붙이는 데서 끝나지 않고 복구를 해 보는 데서 끝납니다. 운영에 넣기 전에 PVC 를 지웠을 때 볼륨이 어떻게 되는지, 스냅샷에서 되살린 볼륨으로 DB 가 기동하는지 소규모로 확인해 보시기 바랍니다.

데이터베이스 이론서는 대부분 정규화의 필요성을 강조합니다. 정규화로 데이터 중복을 피하고, 무손실 분해와 종속성 유지 분해의 조건이 갖춰지면 데이터 무결성과 종속성을 유지할 수 있습니다. 보이스 코드 정규화(BCNF)까지 구현할 수 있으면 가장 좋지만, 최소 3정규화까지는 해야 구조에서 오는 데이터 중복을 막을 수 있습니다. 데이터 중복은 불필요한 공간을 차지하는 문제만이 아니라 데이터베이스 I/O 처리에도 문제를 불러오기 때문에, 중복을 제거하는 일은 데이터베이스를 다루는 데 중요한 부분입니다.

데이터베이스 성능은 결국 I/O에서 갈리고, 데이터 중복은 읽기와 쓰기 양쪽의 I/O를 늘립니다. 그래서 DBA와 DA는 I/O를 줄이려고 정규화를 하고 SQL 튜닝을 합니다.

데이터의 속성에 따라 정규화할 필요가 있다고 이론서는 늘 말합니다. 하지만 그 속성을 어떻게 나누고 분류할지 결정하는 것은 어려운 문제입니다. DBA나 DA가 없는 상황에서 개발자가 서비스에 필요한 수준으로만 설계한 DB는 이런 기본 원칙이 잘 지켜지지 않습니다. 성능 문제가 드러난 시점에는 구조가 이미 얽히고 꼬여 있어서 손을 댈 수 없는 경우가 많습니다.

1:1 항목은 굳이 테이블을 분리할 필요가 없다고 말하는 분도 있습니다. 하지만 데이터가 많아지고 서비스가 커지면 한 테이블에 컬럼이 너무 많이 담겨 문제가 되는 상황이 반드시 옵니다.

데이터베이스는 인덱스를 타든 풀스캔을 하든, 특정 값을 읽으려면 그 값이 들어 있는 행이 담긴 블록 전체를 먼저 읽습니다.

1. 인덱스를 통해 해당 값이 있는 row에 도착하지만,
2. Row 값의 일부분인 해당 값만 읽어오는 것이 아니라 해당 값이 있는 Row 전체 블록을 읽어옵니다.

입출력의 최소 단위는 행이 아니라 이 블록이고, InnoDB에서는 페이지라고 부릅니다. 기본 크기는 16KB이며 innodb_page_size 로 정해집니다. 그래서 행이 넓어지면 한 페이지에 담기는 행 수가 줄고, 같은 건수를 읽는 데 읽어야 할 페이지가 늘어납니다. 컬럼이 많을수록 읽기가 많아진다는 말의 실제 내용이 이것입니다.

1:1 매칭이라고 해서 컬럼을 마구 늘렸다가 속성이 맞지 않는 값이 섞이고 나중에 안 쓰는 컬럼이 생기면, 구조 문제뿐 아니라 성능 이슈도 함께 따라옵니다.

컬럼이 많은 테이블의 행을 불러올 때, 비슷하게 컬럼이 많은 다른 테이블과 조인한다고 가정하면 실제 필요한 데이터보다 훨씬 많은 페이지를 읽어야 결과가 나옵니다. 데이터가 쌓일수록 점점 더 느려지는 결과를 가져옵니다.

복합 인덱스를 잘 구성하면 어느 정도는 해소됩니다. 조회에 필요한 컬럼이 인덱스 안에 모두 들어 있으면 테이블 접근 없이 인덱스만 읽는 커버링 인덱스가 되기 때문입니다. 그래도 한 테이블에 컬럼이 100개씩 있는 구조에서 성능이 잘 나오기를 바라는 것은 무리죠.

회원 테이블의 비즈니스 로직과 구조화하기

회원 테이블은 한 번 구성하면 거의 모든 서비스에서 참조하는 테이블입니다. 따라서 회원 테이블에 불필요한 데이터가 많거나 컬럼이 많으면 좋지 않습니다. 속성이 다른 데이터가 많으면 1:1로 매칭되더라도 정규화하여 분리하는 편이 낫습니다.

회원 테이블은 회원 가입과 로그인에 가장 먼저 쓰이고, 이후 서비스가 돌아가면 정산이나 통계, 서비스 이용 목록을 조회할 때 계속 쓰입니다.

모든 서비스가 이런 비즈니스 로직을 가진다는 뜻은 아니고, 일반적이고 단순한 앱 서비스를 기준으로 그려 본 것입니다. 회원 가입과 로그인은 대부분 이 로직으로 동작합니다. 그에 따라 테이블 설계도 이 로직을 커버할 수 있어야 합니다.

RDBMS 테이블 설계

MySQL 8.4 LTS를 기준으로 작성했고, 한 인스턴스 안에서 스키마 단위로 첫 번째 분리를 했습니다. ERD의 레이어 한 칸이 스키마입니다. MySQL 8.0은 2026-04-21부터 Oracle Sustaining Support 단계로 넘어갔으니, 새로 만드는 서비스라면 8.4 LTS 이상에서 시작합니다.

스키마로 나누는 첫 번째 이유는 권한입니다. SQL 인젝션 자체는 파라미터 바인딩으로 막는 것이고, 스키마 분리가 하는 일은 계정별 접근 범위를 갈라 사고가 났을 때 닿는 데이터를 줄이는 것입니다. 「개인정보의 안전성 확보조치 기준」 제5조도 업무 수행에 필요한 최소한의 범위로 권한을 차등 부여하라고 요구합니다. 두 번째 이유는 속성별로 나눠 두면 서비스 규모가 커졌을 때 스키마를 인스턴스로 떼어내 MSA까지 이어갈 수 있다는 점입니다.

member 스키마부터 살펴보겠습니다

member.user

• 가장 기본적인 회원 ID를 저장하는 방식인데, user_name은 일반적으로 사이트나 서비스에서 회원 가입할 때 사용하는 ID라고 보시면 됩니다.
• 로그인 ID에 유니크 인덱스를 걸 때는 콜레이션을 확인해야 합니다. MySQL 8.0 이후 기본값인 utf8mb4_0900_ai_ci 는 호환 자모 분해형(ㄱㅏㄴㅏㄷㅏ)과 완성형(가나다)을 같은 값으로 판정합니다. Oracle은 UCA 표준 동작으로 보아 버그가 아니라고 처리했습니다. 한국어 전용 콜레이션은 없으니, 분해형 입력을 막을지 저장 전에 정규화할지는 애플리케이션에서 정해야 합니다.

• MySQL에서는 user_no 를 AUTO_INCREMENT 로 순차 할당했습니다. Oracle과 PostgreSQL에서는 시퀀스를 쓰고, PostgreSQL은 GENERATED ALWAYS AS IDENTITY 컬럼이 표준 문법입니다.

  순차 번호 대신 UUID로 고유 식별 코드를 만드는 구성도 있습니다. 36자 문자열을 그대로 두지 말고 UUID_TO_BIN() 으로 BINARY(16) 에 저장합니다. 시간 기반 UUID라면 두 번째 인자에 1을 주어 시간 하위·상위 부분의 순서를 바꿔 두면 연속 생성한 값이 인덱스에서 이웃하게 되고, 읽을 때는 BIN_TO_UUID() 로 되돌립니다.

• 최소한의 데이터로 구성해 두면 휴면(dormant)으로 넘어가거나 탈퇴(withdrawal)할 때까지 어떤 update도 하지 않고, 계정 상태가 바뀔 때 delete만 하는 것으로 정리됩니다.

member.authentication

• 회원의 인증 정보를 담습니다. 암호화가 필요한 개인정보만 이 테이블에 모으는 구조이고, 나중에 배송지나 주소록이 필요해지면 그 테이블만 따로 암호화하면 됩니다.
• 암호화 대상은 항목 이름만으로 정해지지 않습니다. 「개인정보의 안전성 확보조치 기준」(개인정보보호위원회고시 제2026-9호) 제7조제2항은 이용자의 주민등록번호·여권번호·운전면허번호·외국인등록번호·신용카드번호·계좌번호·생체인식정보를 조건 없는 저장 암호화 대상으로 둡니다. 신용카드번호와 계좌번호가 이 목록에 있다는 점을 놓치기 쉬운데, 고유식별정보가 아니라는 이유로 결제·정산 테이블을 평문으로 두면 근거가 없습니다. 조문 좌표는 데이터 암호화에 정리해 두었습니다.
• 컬럼을 암호화하면 그 컬럼으로는 동등 비교 외에 검색·정렬·범위 조건을 쓸 수 없습니다. 암호화 대상을 한 테이블로 모으는 설계가 이 제약과도 맞습니다. 목록이나 통계 화면에 필요한 값은 연령대·지역 구분처럼 범주화한 파생 컬럼을 평문으로 따로 둡니다.
• 개인정보를 담는 이유는 서비스를 개선할 근거가 필요하기 때문입니다. 어떤 사용자가 있고 연령층과 성별 분포가 어떤지 같은 통계가 그렇습니다. 여기 담기는 정보는 본인 인증 서비스를 제공하는 타업체의 인증으로 가입하는 경우만 기록됩니다.

member.profile

• 사용자가 직접 등록하는 정보인데, 닉네임과 프로필 사진은 앱 서비스에서 자주 여기저기서 불려 다니는 데이터입니다.
• 나머지 컬럼은 자주 읽히지는 않지만, 회원 조회나 닉네임을 클릭했을 때 대체로 같이 보이는 데이터입니다.

member.subscription

• 요즘 앱 서비스는 구독 모델을 많이 쓰는데, 해당 사용자가 무료 이용자인지, 유료면 어떤 플랜인지 기록해 둡니다.
• 로그인할 때 세션 정보와 함께 캐싱해 두면 처리가 빨라집니다. 세션 정보는 Redis나 Valkey 같은 캐시에 두는 편이 좋습니다.

member.device

• 사용자가 로그인하는 기기 정보를 담습니다. 어떤 기기가 많이 들어오는지 통계를 모으고, 사용자별 기기 대수를 제한하고, 인증되지 않은 기기의 사용을 막아 보안성을 높이는 것이죠.

그다음은 auth 스키마입니다

auth.password

• ID 방식으로 가입하면 password를 받습니다. 소셜 로그인과 ID 방식이 섞인 서비스에서 password를 user 테이블에 같이 기록하면 password가 null인 행이 생깁니다. 정규화로 이런 부분을 줄이고, 비밀번호 해시에 닿을 수 있는 계정을 따로 떼어 두기 위해 이렇게 분리합니다.
• 비밀번호는 복호화할 수 있는 형태로 저장하지 않습니다. 고시 제7조제1항 단서가 복호화되지 아니하도록 일방향 암호화하여 저장하라고 요구하고, 시행령 제30조제1항제4호 가목도 일방향을 명문으로 씁니다.
• 일방향이라고 아무 해시나 되는 것은 아닙니다. SHA 계열 같은 범용 해시는 빠른 것이 목적이라 대입 공격에도 그만큼 빠릅니다. 연산 비용을 조절할 수 있는 키 유도 함수를 쓰고, 솔트는 계정마다 다르게 생성해 해시와 함께 보관합니다. 반복 횟수는 기본값을 그대로 쓰지 말고 실제 서버에서 로그인 지연을 측정해 정하고, 하드웨어를 바꿀 때 다시 올립니다.
• 알고리즘 선택은 환경에 따라 좁아집니다. 공공 조달처럼 검증필 암호모듈이 요구되는 환경에서 검증대상 키 유도 함수는 KBKDF와 PBKDF이고 Argon2·bcrypt·scrypt는 그 목록에 없습니다. 민간 서비스에는 검증필 모듈 사용 의무가 없으므로 선택은 자유롭지만, 그 선택이 안전하다는 근거를 기록으로 남깁니다. ISMS-P 심사나 내부 감사에서 요구받는 것은 설정 화면이 아니라 이 기록입니다.
• 컬럼 폭은 넉넉하게 잡습니다. 해시 값과 솔트, 알고리즘과 반복 횟수 식별자가 함께 들어가고 알고리즘을 교체하면 길이가 또 바뀝니다.

auth.social_login

• 소셜 로그인 정보는 서비스 단위로 테이블을 나눌 필요 없이 social_code 값으로 (1:apple, 2:google, 3:kakao, 4:naver …) 구분하고 external_id 를 기록하면 됩니다. 계정을 잇는 데 필요한 값은 external_id 입니다.
• 액세스 토큰은 성격이 다릅니다. 유효기간이 짧고 갱신되는 자격증명이라, 회원 DB에 오래 들고 있을 이유가 있는지부터 따집니다. 소셜 서비스의 API를 대신 호출해야 해서 보관한다면 평문 컬럼으로 두지 않고, 만료나 연동 해지 시점에 지우는 경로까지 함께 설계합니다.
• 소셜 로그인으로 가입하면 user_no 를 자동으로 생성하고 user_name 에 랜덤 ID를 부여하는 프로세스를 추가해야 합니다.

auth.cidi

• 휴대폰 인증이나 아이핀처럼 본인 인증 절차를 거쳤을 때 인증 업체로부터 받는 값입니다. CI는 법령 용어로 연계정보이고, 생성·처리는 「정보통신망 이용촉진 및 정보보호 등에 관한 법률」 제23조의5, 안전조치 의무는 제23조의6에 있습니다.
• CI는 어느 업체에서 인증을 받더라도 한 사람에게 하나의 값만 부여됩니다. 그래서 서비스 간 동일인 판정에 쓸 수 있고, 같은 이유로 한번 유출되면 되돌릴 수 없습니다.
• DI는 사이트 중복 가입을 방지하는 데 쓴다고 하는데, 인증 업체마다 다른 값이 올 수도 있기 때문에 사용하는 데 주의가 필요합니다.
• 연계정보는 시행령 제19조가 정하는 고유식별정보 네 가지(주민등록번호, 여권번호, 운전면허의 면허번호, 외국인등록번호)에 들어가지 않고 고시 제7조제2항의 조건 없는 암호화 대상 목록에도 없습니다. 그래도 제23조의6이 안전조치 의무를 따로 두고 있으니, 이 컬럼을 어떻게 보호할지는 판단과 근거를 남겨 둡니다. 주민등록번호로 대신하는 선택은 정보통신망법 제23조의2가 사용을 제한합니다.

휴면(dormant) 스키마입니다

• member 스키마의 오브젝트에 특별한 FK를 가지고 있지는 않지만 스키마 이상으로 떼어 두는 편이 낫습니다. 휴면에 빠진 회원 정보는 member에서 delete하고 기존 값을 그대로 dormant로 옮깁니다. member뿐만 아니라 auth의 데이터도 함께 옮겨 휴면 회원의 데이터는 전부 한곳에 자리하게 됩니다.
• 다만 휴면 분리 자체를 법정 의무로 적어 두면 근거가 어긋납니다. 일정 기간 접속하지 않은 이용자의 개인정보를 자동으로 삭제하게 했던 유효기간제는 구 정보통신망법 제29조에 있었고 2020-02-04 개정으로 삭제됐습니다. 현행에서 보유기간과 파기를 정하는 조문은 개인정보 보호법 제21조입니다. 보유기간이 지나거나 처리 목적을 달성해 불필요해진 개인정보는 지체 없이 파기하고, 다른 법령에 보존 의무가 있는 항목만 예외로 남기되 그때는 다른 개인정보와 분리하여 저장·관리합니다. 분리 보관을 스키마 분리로 구현하는 근거가 이 단서입니다.
• 휴면 스키마로 옮겨온 시점부터 회사 정책에 따라 1년, 3년, 5년 등의 단위로 복구하지 않는 회원을 공지와 함께 자동 탈퇴 처리하는 프로세스를 가지게 됩니다. 이 기간은 법령이 정한 값이 아니라 정책 값이므로, 처리방침에 공개한 보유기간과 파기 배치 주기가 서로 맞는지 대조합니다.

탈퇴(withdrawal) 스키마입니다

• 탈퇴한 회원의 개인정보를 계속 보유할 근거는 사전 통보가 아니라 다른 법령의 보존 의무입니다(법 제21조). 환불 고지에 필요한 연락처처럼 남겨야 하는 항목이 있다면 근거 법령과 보존 기간을 항목별로 적어 두고, 나머지 개인정보와 분리해 저장·관리합니다.
• 탈퇴한 회원이 재가입해 가입 시에만 받는 혜택을 중복으로 받지 않도록 CI를 일정 기간 보관하는 구성도 씁니다. 이때도 보관 기간과 근거를 먼저 정하고, 기간이 지나면 지우는 배치를 함께 만듭니다.
• is_deleted = true 같은 플래그는 파기가 아닙니다. 시행령 제16조제1항은 전자적 파일 형태의 개인정보를 복원이 불가능한 방법으로 영구 삭제하라고 정합니다. 논리 삭제로 운영한다면 물리 삭제나 복원 불가 처리로 넘어가는 후속 단계를 따로 둡니다. 파기 범위에서 자주 빠지는 곳은 백업본, 리드 레플리카, 바이너리 로그, 개발·스테이징으로 복사한 덤프입니다.
• 탈퇴는 서비스에 따라 구성 내용이 많이 바뀌기 때문에 오브젝트를 구성하지 않았고, Billing 테이블이나 CI를 별도로 남기는 테이블을 구성하거나 withdrawal 테이블에 컬럼으로 기록할 수도 있습니다.

Log 스키마의 오브젝트를 보면 기존 테이블과 구성이 다릅니다

• 로그를 설계할 때 많은 개발자가 실수하는 부분이 테이블의 row 값을 그대로 복사해서 날짜만 붙이는 것인데, 로그의 설계 원칙은 모두 코드값으로 표현하는 것이 기본입니다. 코드만 보고 어떤 행동이 어떻게 발생했는지 알 수 있어야 합니다.
• 데이터 중복을 만드는 것보다 행위의 결과와 원인을 나타내는 것을 기본으로 해야 합니다.
• 서비스 행위 로그와 개인정보처리시스템의 접속기록은 목적이 다르므로 같은 테이블에 섞지 않습니다. 접속기록의 보관 기간은 고시 제8조가 정하는데, 기본은 1년 이상이고 5만명 이상 정보주체의 개인정보를 처리하거나 고유식별정보·민감정보를 처리하는 시스템은 2년 이상입니다. 기준이 바뀌면 보존 기간이 두 배가 되니 월 단위 파티션에 드롭 정책을 걸어 두면 정책 값만 고치면 됩니다. 관련 조문은 데이터 3법에 모아 두었습니다.

앱 서비스에 필요한 기본적인 테이블 설계로 1:1 매칭 데이터가 어떤 속성을 가지고 분리되는지, 위 ERD 모델을 보고 천천히 분석해 보면 테이블 모델링이 조금은 이해되지 않을까 해서 그려 봤습니다.

만 14세 미만 아동의 법정대리인 동의나 성인 인증이 필요한 경우를 저 모델의 어디에 어떻게 추가할지 스스로 고민해 보시면, 앞으로 새로운 설계를 하는 데 많은 도움이 될 것이라 생각합니다.

1:1 정규화로 조인해야 하는 테이블 간 블록 읽기를 최소화하면 데이터 출력 속도도 빠르게 유지할 수 있고, 속성별로 테이블을 분리했기 때문에 적재적소에 필요한 컬럼이나 별도의 테이블을 추가해서 서비스를 늘려가는 것이 어렵지 않습니다.

테이블정의서를 첨부합니다.

MERN은 스택을 구성하는 4가지 핵심 기술을 따서 MongoDB, Express, React, Node를 나타냅니다.

• MongoDB – document database
• Express.js – Node.js web framework
• React.js – a client-side JavaScript library
• Node.js – JavaScript server platform

Express.js 및 Node.js는 중간(애플리케이션) 계층을 구성합니다. Express.js는 서버 측 웹 프레임워크이며 Node.js는 JavaScript 서버 플랫폼입니다. React.js 대신 다른 프론트엔드 기술을 선택하면 ME(RVA)N 스택이 됩니다.

• R – React.js
• V – Vue.js
• A – Angular

MERN Stack은 어떻게 동작할까요?

MERN 아키텍처를 사용하면 JavaScript 및 JSON으로 3-tier 아키텍처(프론트엔드, 백엔드, 데이터베이스)를 구성할 수 있습니다.

React.js Frontend

MERN 스택의 가장 앞단은 React.js입니다. 동적 HTML을 클라이언트 단에서 생성하는 선언적 JavaScript 라이브러리입니다. React.js를 사용하면 간단한 구성 요소로 복잡한 인터페이스를 구축하고, 백엔드 서버의 데이터에 연결해 HTML로 렌더링할 수 있습니다.

React.js의 강점은 최소한의 코드로 데이터 기반 인터페이스를 처리하는 것입니다. 최신 UI 라이브러리에서 기대할 수 있는 모든 기능을 갖추고 있습니다.

Express.js and Node.js Server Tier

다음 레벨은 Node.js 서버 내부에서 실행되는 Express.js 서버 측 프레임워크입니다. Express.js는 스스로를 “Node.js를 위한 빠르고, 의견이 없는, 미니멀리스트 웹 프레임워크”라고 칭하고 있습니다. Express.js는 URL 라우팅(서버 기능과 수신 URL 일치)과 HTTP 요청 및 응답 처리 모델을 제공합니다.

React.js 프론트엔드에서 HTTP 요청(XHR, fetch API)을 통해 Express.js 서버의 기능에 연결할 수 있습니다. 서버 측 기능은 MongoDB Node.js 드라이버를 이용해 데이터베이스의 데이터에 액세스하고 업데이트합니다.

MongoDB Database Tier

애플리케이션이 데이터(사용자 프로필, 콘텐츠, 댓글, 업로드, 이벤트 등)를 저장하는 경우 React.js, Express.js 및 Node.js만큼 쉽게 작업할 수 있는 데이터베이스가 필요합니다. 바로 여기에서 MongoDB가 등장합니다.

React.js 프론트엔드에서 생성된 JSON 문서가 유효하면 Express.js 서버로 전달되어 문서를 처리하고, MongoDB에 저장할 수 있습니다.

MERN은 풀스택 솔루션

MERN은 프론트엔드 디스플레이 계층(React.js), 애플리케이션 계층(Express.js 및 Node.js), 데이터베이스 계층(MongoDB)을 포함한 기존의 3계층 아키텍처 패턴을 따르는 풀스택입니다.

MERN 스택을 선택하는 이유는 무엇일까?

MERN 스택의 기반인 MongoDB는 JSON 데이터를 저장하도록 설계되었습니다(기술적으로는 BSON이라는 JSON의 이진 버전을 사용). 명령줄 인터페이스부터 쿼리 언어(MQL, MongoDB 쿼리 언어)까지 모든 것이 JSON과 JavaScript를 기반으로 합니다.

MongoDB는 Node.js와 호환성이 좋으며, 애플리케이션의 모든 계층에서 JSON 데이터를 저장, 조작, 표현할 수 있습니다. 클라우드 네이티브 애플리케이션의 경우 MongoDB Atlas는 선택한 클라우드 플랫폼에서 자동 확장되는 MongoDB 클러스터를 제공합니다.

Express.js(Node.js에서 실행)와 React.js를 결합하면 전체 스택을 JavaScript/JSON으로 구축할 수 있습니다. Express.js는 HTTP 요청과 응답을 처리하고 URL을 서버 측 기능에 매핑합니다. React.js는 대화형 사용자 인터페이스를 구축하고 원격 서버와 통신하는 프론트엔드 JavaScript 라이브러리입니다. JSON 데이터가 프론트엔드부터 백엔드까지 자연스럽게 흐르므로 구축이 빠르고 디버그가 간단합니다. 전체 시스템을 이해하려면 하나의 프로그래밍 언어와 JSON 문서 구조만 알면 됩니다.

MERN 사용 사례

모든 웹 스택과 마찬가지로 MERN에서 원하는 모든 것을 구축할 수 있지만 JSON이 많고 클라우드 네이티브이며 동적 웹 인터페이스가 있는 경우에 가장 이상적입니다.

몇 가지 예는 다음과 같습니다.

• 워크플로 관리
• 뉴스 집계
• Todo 앱 및 캘린더
• 대화형 포럼/소셜 제품 등

이번에 MongoDB Korea에서 오프라인 핸즈온 세미나를 열었습니다.

전 세계 게임업계의 MongoDB 레퍼런스를 소개하고, Google Cloud의 BigQuery와 함께 MongoDB로 데이터 분석 파이프라인을 구축하는 법을 알 수 있는 좋은 기회였습니다.

또 MongoDB가 주력하는 관리형 클라우드 MongoDB 서비스인 Atlas의 핸즈온이 아젠다에 포함되어 있었습니다.

세미나 시작

우선 전 세계 게임업계가 MongoDB를 어떻게 사용하고 있는지를 다룬 아젠다로 시작했습니다. 이번 아젠다에서 MongoDB 측이 소개한 게임 회사들은 아래와 같습니다.

• 스퀘어 에닉스
• 텐센트
• Epic Games
• 세가
• EA Sports
• 이름이 기억 안나는 중국 2위의 게임 회사

이런 큰 게임회사들이 MongoDB를 사용하는 이유와 이점을 설명했습니다.

중국의 거대 기업 텐센트는 왜 MongoDB를 사용하는가?

• 유연한 개발 요구사항 충족
• 주변 플레이어 지원 (위치 기반)
• 대량의 데이터 지원 및 무중단 업그레이드
• 운영 데이터 분석 지원
• 개발언어와 접근성 호환성 높음 – Node.js

스퀘어 에닉스의 효율성을 위한 빅데이터 게임 플랫폼 구축

• SQL 서버 비용 감소
• 데이터 처리 능력 0.5TB/day
• 데이터 분석 3weeks → 2min

즉, MongoDB가 강조하는 장점은 “실시간 운영, 실시간 분석에 최적화된 데이터베이스”입니다. 운영과 분석을 동시에 할 수 있다는 점에 초점을 맞춰 소개했습니다.

그리고 MongoDB를 제대로 이해하지 못하고 사용하는 많은 사용자가 겪는 “MongoDB는 성능이 안 좋아요!”에 대한 해명도 해주셨죠.

• 20%의 사용자: MongoDB에 최적화된 모델링 설계를 하지 못함 (RDBMS처럼 설계)
• 80%의 사용자: 인덱스를 제대로 활용하지 못함 (인덱스 설계가 매우 중요)

MongoDB to BigQuery 데이터 분석 파이프 라인

앞서 MongoDB에서 자체적으로 분석할 수 있는데도 BigQuery를 사용해야 하는 이유를 다음과 같이 설명했습니다.

데이터 분석을 하게 되면 더 많은 요구사항과 더 많은 데이터를 다루게 되는데, 점점 커져가는 데이터 분석 환경에 따라 BigQuery 같은 뛰어난 제품이 필요하다는 것이 핵심 메시지였습니다.

BigQuery가 좋은 이유는 구글이 데이터 분석 플랫폼으로 시작한 회사이기 때문에 인프라보다 분석 기술에 집중했으며, 접근이 쉽다는 장점이 있습니다.

최근 데이터 분석 트렌드가 AI, 머신러닝 분야이며, 예전처럼 분석의 최종 지점이 시각화가 아닌 AI와 머신러닝 쪽으로 변해가고 있기 때문에 사용하기 쉬운 BigQuery가 적합하다고 설명했습니다. 도구가 쉬워질수록 분석가의 학습 곡선이 완만해져 접근이 편합니다.

그리고 기존에는 스토리지 비용이 비쌌기 때문에 DW 형태로 저장했지만, 머신러닝에는 원본 데이터를 그대로 저장하는 것이 필요합니다. BigQuery는 DW+Lake를 함께 사용할 수 있는 데이터 저장소이기 때문에 원본 데이터를 바로 저장해 머신러닝에 이용할 수 있다는 점이 특징입니다.

또한 데이터 분석을 위한 포괄적인 BI 솔루션인 ‘구글 데이터 스튜디오’(현재는 Looker Studio)가 무료라는 점도 강조했습니다.

GCP는 BigQuery를 혁신적이고 개방적인 서버리스 제품으로 소개했습니다. 완전 관리형 서비스로 증설이 필요 없고, 연산이 필요한 만큼 리소스를 모두 제공하기 때문에 사양에 얽매이지 않는 것이 서버리스의 장점입니다.

예를 들어 BigQuery에서 1,000억 건, 4.06TB 데이터를 처리하는 데 걸리는 시간은 20~30초 사이이며, 데이터 분석 시스템이 왜 빨라야 하는가에 대한 답변으로 “분석을 하는 사람들은 시간과 싸움을 하고 있으며, 분석이 빨라야 빠른 의사 결정이 이루어지기 때문”이라고 설명했습니다.

다른 DW처럼 Data Mart로 데이터 복제가 필요 없기에 별도의 자원 낭비가 없으며, Standard SQL을 지원합니다.

세미나 당시 소개된 비용 정보는 다음과 같습니다.

• 저장: 1TB / 월 $20
• 장기 저장: 1TB / 월 $10

또한 BigQuery는 데이터를 이전하지 않고 머신러닝에 바로 사용할 수 있습니다.

데이터 분석 파이프라인

BigQuery에 데이터를 적재하는 방법을 소개했습니다. 초기 데이터를 적재하는 방법으로는 두 가지를 설명해 주셨고, 실시간 데이터 전송 파이프라인도 설명해 주셨습니다.

• 초기 로딩: Mongo → Cloud Dataflow → BigQuery
• 초기 로딩: Mongo → ETL 도구 (Data Fusion) → BigQuery

• 실시간 동기화: Mongo (Change Stream) → Cloud Pub/Sub (like Kafka) → Cloud Dataflow (분산 처리 엔진 like Spark) → BigQuery

특히 MongoDB Change Stream 기능을 이용하여 변경 이벤트를 실시간으로 분석 시스템에 전달할 수 있다는 점으로 MongoDB와 BigQuery의 연계성을 강조했습니다.

MongoDB 핸즈온 세션

MongoDB Atlas는 AWS나 GCP, Azure 등의 퍼블릭 클라우드와 함께 사용할 수 있는 멀티 클라우드를 지원하는 관리형 MongoDB 클라우드 서비스입니다.

쉽게 DB 클러스터를 구축하고 배포하는 것뿐만 아니라 AWS, GCP와의 연계 등 하나의 클러스터에서 각각의 노드를 서로 다른 클라우드로 배포할 수 있는 것이 강점입니다.

동일한 데이터베이스 노드를 각기 다른 클라우드에 배포할 수 있다는 것이 큰 장점입니다.

직접 Atlas에서 클러스터를 배포하고, 간단한 MongoDB 실습까지 진행했습니다.

그동안 온라인을 통해서 기승전 Atlas였던 MongoDB의 웨비나들은 실습까지는 어려운 부분이 많았지만, 드디어 오프라인 세션이 열리면서 실습을 해볼 수 있는 환경이 마련된 것이 참 좋았습니다.

오랜만에 오프라인 행사여서 그런지 MongoDB Korea에서 굿즈도 많이 준비해 주셨고, 함께한 지인분이 2등 선물에 당첨되는 등 여러 가지 재미있는 순간들이 있었습니다.

그리고 DB 오픈 카톡방에서 활동하시는 다른 DBA분들과 마주하여 다양한 이야기를 나눌 수 있었던 기회가 된 것 같아 좋은 경험이었습니다.

이상 MongoDB Developer Workshop 후기였습니다.

읽어 주셔서 감사합니다.

라이선스와 자료형

Redis는 8.0부터 제품 이름이 Redis Open Source로 바뀌고 라이선스가 3중 구조가 되었습니다. 사용자가 세 가지 중 하나를 골라 적용합니다 — Redis Source Available License v2(RSALv2), Server Side Public License v1(SSPLv1), GNU Affero General Public License v3(AGPLv3). 공식 문서는 RSALv2와 SSPLv1을 오픈소스 라이선스가 아니라고 명시하고, 세 가지 중 AGPLv3만 OSI 승인 오픈소스라고 적습니다.

BSD 라이선스를 유지하려는 쪽에서는 Redis OSS 7.2.4를 포크한 Valkey가 나왔습니다. Valkey는 INFO 응답에 여전히 redis_version:7.2.4를 함께 보고하므로, 버전 문자열만 보고 제품을 판별하면 안 됩니다.

자료형도 2021년보다 넓어졌습니다. 현재 Redis Open Source가 구현하는 자료형은 String(Bitmap·Bitfield 포함), Array, Geospatial index, Hash, JSON, List, 확률형 자료형(Bloom filter·Cuckoo filter·Count-min sketch·HyperLogLog·t-digest·Top-K), Set, Sorted Set, Stream, Time series, Vector set입니다. 별도 모듈로 배포되던 RediSearch·RedisJSON·RedisTimeSeries·RedisBloom은 Redis 8부터 Redis Open Source의 구성 요소로 편입되어 같은 라이선스를 따릅니다.

Redis Cluster와 Sentinel의 차이점

Sentinel

Redis Sentinel은 고가용성(HA)에 집중한 솔루션입니다. 단일 primary를 여러 개의 replica로 복제하고, primary 장애 시 자동으로 replica를 승격시킵니다.

특징

• Redis 본체와 별도 프로세스로 동작합니다 (기본 포트 26379)
• 최소 3개 이상의 Sentinel 인스턴스가 필요합니다 (quorum 확보를 위해)
• Sentinel을 통해 접근하며, 클라이언트 라이브러리의 Sentinel 지원이 필요합니다
• 단일 인스턴스와 마찬가지로 Redis의 모든 기능(0~15번 DB, 전체 명령)을 사용할 수 있습니다

Failover 동작 방식

1. SDOWN (Subjectively Down) — 개별 Sentinel이 primary로부터 30초(down-after-milliseconds 기본값 30000ms) 동안 PING/INFO 응답을 받지 못하면 “주관적 다운”으로 판단합니다
2. ODOWN (Objectively Down) — 설정한 quorum 이상의 Sentinel이 동시에 다운을 인지하면 “객관적 다운”으로 인정합니다. 실제 failover 개시에는 Sentinel 과반의 투표가 추가로 필요합니다
3. Sentinel 과반(majority)의 투표로 failover 리더를 선출합니다
4. 리더가 replica 중 하나를 primary로 승격시키고, 기존 primary는 replica로 강등합니다
5. 다른 replica들은 새 primary로부터 데이터를 받도록 재구성됩니다

과반수가 필요한 이유: 네트워크 파티션 상황에서 소수 파티션이 독단적으로 failover를 하지 못하도록 방지합니다. 예를 들어 Sentinel 5개 중 2개만 격리되면, 격리된 쪽은 과반을 확보하지 못해 failover를 시도할 수 없습니다.

주의사항

단점

• Single primary 구조이므로 데이터가 커지면 수직 확장(scale-up)이 필요합니다
• 샤딩을 제공하지 않습니다

Cluster

Redis Cluster는 고가용성(HA)과 샤딩을 동시에 제공하는 Redis 자체 클러스터링 시스템입니다.

특징

• 모든 데이터를 primary 단위로 샤딩하고, replica 단위로 복제합니다
• 최소 3개의 primary 노드가 필요하며, 배포 권장은 6노드(primary 3 + replica 3)입니다
• Primary마다 최소 하나 이상의 replica를 두는 것이 좋습니다

해시 슬롯(Hash Slot)을 이용한 샤딩

Redis Cluster는 CRC-16 해시 함수를 이용해 키를 정수로 변환하고, 그 값을 16384로 모듈 연산합니다. 16384개의 슬롯을 primary 노드 수만큼 균등하게 분할합니다.

slot = CRC16(key) mod 16384

예를 들어 primary 3개라면:

• 노드 A: 슬롯 0~5460
• 노드 B: 슬롯 5461~10922
• 노드 C: 슬롯 10923~16383

클러스터 HA 동작

• Primary 노드가 shutdown되면 gossip protocol로 상태를 확인하고, replica 중 하나를 primary로 승격시킵니다
• Gossip은 Redis 노드 간 직접 연결로 동작하며, 기본값은 클라이언트 포트 + 10000 입니다 (예: 클라이언트 포트 6379 → 버스 포트 16379). cluster-port 설정으로 따로 지정할 수 있습니다
• 기존 primary가 재시작되면 자동으로 승격된 replica의 새 replica로 구성됩니다
• primary 과반에 도달하지 못한 노드는 쿼리 수용을 중단합니다 (cluster-node-timeout 경과 후)

클러스터 관리

Redis 8.x에서는 redis-cli --cluster 명령으로 클러스터를 관리합니다. 기존의 redis-trib.rb는 deprecation stub으로 대체되었습니다.

# 클러스터 생성 (6노드, replica 1개씩)
redis-cli --cluster create 127.0.0.1:7000 ... 127.0.0.1:7005 \
  --cluster-replicas 1

# 노드 추가
redis-cli --cluster add-node 127.0.0.1:7006 127.0.0.1:7000

# 리샤딩
redis-cli --cluster reshard 127.0.0.1:7000

# 상태 점검
redis-cli --cluster check 127.0.0.1:7000

주의사항

Docker / NAT 환경

공식 문서는 Redis Cluster가 NAT 환경과 IP·포트가 재매핑되는 환경을 지원하지 않는다고 못 박고, Docker에서는 호스트 네트워킹 모드(--net=host)를 쓰라고 안내합니다. 포트를 그대로 노출할 수 없다면 redis.conf에서 노드가 알릴 주소를 정적으로 지정합니다:

cluster-announce-ip 10.1.1.5
cluster-announce-port 6379
cluster-announce-tls-port 6380
cluster-announce-bus-port 16379

Redis 샤딩 (직접 구현)

클러스터 기능을 사용하지 않고 직접 샤딩을 구현할 수도 있습니다. 일반적으로 Consistent Hashing 아키텍처를 사용합니다.

일반 모듈러 해싱 vs Consistent Hashing

샤딩 전략

• Range — 특정 범위(예: A-M, N-Z)를 정의해 저장. 데이터가 특정 범위에 몰리거나 비어있을 수 있습니다
• Modular — 하나씩 추가하면 리밸런싱이 빈번하므로, 2배씩 늘려 규칙적으로 데이터를 이동시킵니다
• Indexed — 키가 저장될 위치를 관리 서버가 따로 보관. 인덱스 서버가 SPOF가 됩니다

Consistent Hashing도 완벽하게 균등하지는 않으므로, virtual node를 둔 Adaptive Consistent Hashing을 고려할 수 있습니다.

Data Persistence (데이터 영속성)

Redis는 인메모리 DB이지만 디스크에 데이터를 기록하는 두 가지 방식을 제공합니다.

RDB (Redis Database)

주기적으로 point-in-time 스냅샷을 생성합니다.

장점

• 단일 파일로 저장되어 백업과 복구가 간편합니다
• 부모 프로세스가 자식 프로세스를 fork해 persist I/O를 처리하므로, 메인 프로세스 성능에 미치는 영향이 적습니다
• 재시작 시간이 짧습니다 (snapshot을 그대로 메모리에 로드)

단점

• 스냅샷 간격 사이에 Redis가 멈추면 데이터 유실 가능성이 있습니다
• Fork 시 순간적으로 메모리가 2배까지 증가할 수 있습니다 (Copy-on-Write)

설정

배포되는 redis.conf에는 세 개의 저장 지점이 기본값으로 적혀 있습니다.

save 3600 1 300 100 60 10000
# 3600초 동안 1번 이상 변경 or 300초 동안 100번 이상 변경 or 60초 동안 10000번 이상 변경

비활성화: save ""

AOF (Append Only File)

모든 쓰기 작업을 로그로 기록하고, 재시작 시점에 replay합니다.

장점

• RDB보다 데이터 유실 가능성이 낮습니다
• 증분 파일은 Redis 프로토콜과 같은 포맷이라 사람이 읽고 편집할 수 있습니다. 예를 들어 실수로 FLUSHALL을 실행했다면, rewrite가 일어나기 전이라면 서버를 멈추고 그 명령 한 줄을 지워 되살릴 수 있습니다

단점

• 같은 데이터셋에 대해 RDB보다 파일 크기가 큽니다
• 쓰기 요청이 많을 때 RDB보다 반응성이 느릴 수 있습니다

AOF Rewrite

데이터가 많아지면 현재 시점의 데이터셋을 만들어낼 수 있는 최소한의 로그만 남기고 압축합니다. 예를 들어 같은 키에 100번의 SET이 있었다면 마지막 값 하나만 기록합니다.

Redis 7.0부터는 AOF가 단일 파일이 아니라 multi-part AOF 구조입니다. base 파일(최대 1개, RDB 또는 AOF 포맷 스냅샷)과 증분 파일 여러 개를 appenddirname 디렉터리에 두고 manifest 파일로 추적합니다. rewrite 중에는 부모 프로세스가 새 증분 파일에 계속 기록하므로, 예전처럼 rewrite 중 쓰기가 메모리에 버퍼링되지 않습니다.

설정

AOF는 기본적으로 꺼져 있고(appendonly no), 켜면 appendfsync의 기본값은 everysec입니다.

appendonly yes
appendfsync everysec   # always | everysec | no

권장 설정

• 관계형 DB 수준의 데이터 안전성이 필요하면 공식 문서는 RDB와 AOF를 함께 쓰라고 권합니다. AOF 단독 구성은 백업·재시작 속도와 AOF 엔진 버그 대비 때문에 권하지 않습니다
• 몇 분 정도의 유실을 감수할 수 있다면 RDB만 써도 됩니다. 캐시로만 쓴다면 둘 다 off해도 됩니다
• 둘 다 켜져 있으면 재시작 시 AOF로 복구합니다. AOF가 더 완전한 데이터셋을 보장하기 때문입니다
• 복제를 쓴다면 primary와 replica 양쪽에 영속성을 켜는 것이 공식 권고입니다

WARNING — 디스크가 느려서 primary의 영속성을 껐다면 자동 재시작을 반드시 끄십시오. 빈 데이터셋으로 살아난 primary가 replica 전체를 비워 버립니다. Sentinel 환경에서는 primary가 너무 빨리 재시작되어 Sentinel이 장애를 감지하지 못하는 경로로 같은 일이 벌어집니다.

Redis 사용 시 주의사항

1. Collection 크기 제한

Collection 안에 너무 많은 아이템을 저장하지 마세요. Hash/Set/Sorted Set은 규격상 2³²-1 요소까지 가능하지만, 큰 컬렉션은 O(N) 명령(예: HGETALL)과 메모리 사용으로 문제가 될 수 있습니다. redis-cli --bigkeys로 진단하세요.

• Hash, Sorted Set, Set은 메모리를 많이 사용합니다
• 작은 컬렉션은 listpack으로 압축 저장되고, hash-max-listpack-entries 같은 임계값을 넘으면 해시테이블·스킵리스트 인코딩으로 전환됩니다. 임계값을 크게 올리면 메모리는 줄지만 조회가 선형 탐색에 가까워집니다
• Hash는 Redis 7.4부터 HEXPIRE 계열 명령으로 필드별 TTL이 가능하고, Set/Sorted Set/List는 여전히 키 단위 TTL만 지원합니다

2. 메모리 관리

메모리 모니터링과 관리가 필수입니다.

• Redis는 자기가 사용하는 정확한 메모리 양을 모릅니다 (단편화 포함)
• 쓰기가 많은 Redis는 fork 시 메모리를 최대 2배까지 사용할 수 있습니다 (Copy-on-Write)
• 작은 인스턴스 여러 개로 나누는 것이 큰 인스턴스 하나보다 안전합니다

maxmemory-policy 선택

Redis 8.6 기준 축출 정책은 다음과 같습니다:

선택 기준

• 일부 키가 나머지보다 훨씬 자주 접근된다면 → allkeys-lru (문서의 “좋은 기본값”)
• 읽기는 많지만 갱신 여부로 신선도를 판단하고 싶다면 → allkeys-lrm
• 모든 키가 대략 균등 접근(반복 순회)한다면 → allkeys-random
• 가능하면 캐시와 영속 키를 인스턴스 분리하세요. volatile-*은 한 인스턴스에 섞어 쓰는 경우용이지만 권장하지 않습니다

3. 단일 스레드와 io-threads

명령 실행은 여전히 한 번에 하나씩입니다. Redis 6.0에 도입된 io-threads는 소켓 읽기·쓰기와 프로토콜 파싱을 별도 스레드로 넘기는 설정이고, 명령 실행 자체를 병렬화하지는 않습니다.

redis.conf에서 이 스레딩은 기본적으로 꺼져 있습니다. 공식 설정 파일은 코어가 4개 이상인 머신에서만 켜기를 권하고, io-threads 1은 예전처럼 메인 스레드만 쓴다는 뜻이라고 적습니다.

# redis.conf (기본 비활성)
# io-threads 4

주의할 명령

시간이 오래 걸리는 명령은 다른 클라이언트를 블로킹합니다:

• KEYS 패턴 — O(N). 프로덕션에서 절대 사용하지 마세요. 대신 SCAN 사용
• FLUSHALL / FLUSHDB — 모든 키 삭제
• DEL Collection — Collection이 크면 UNLINK(비동기 삭제) 사용
• Get All Collections — HGETALL, SMEMBERS 등. 요소가 많으면 HSCAN, SSCAN 사용
• 큰 컬렉션을 읽을 때는 HSCAN, SSCAN, ZSCAN 커서 순회를 사용하세요

진단 도구

# 빅키 / 메모리 많이 쓰는 키 찾기 (SCAN 기반)
redis-cli --bigkeys
redis-cli --memkeys
redis-cli --keystats

# 핫키 찾기 (maxmemory-policy가 *lfu일 때만 동작)
redis-cli --hotkeys

# 레이턴시 측정
redis-cli --latency
redis-cli --latency-history

4. Replication 사용 시 주의사항

비동기 복제 특성

• Replication은 비동기 방식입니다. Primary에서 ack된 쓰기도 failover 시 유실될 수 있습니다
• WAIT 명령으로 N개 replica의 ack를 확인할 수 있지만, 이것으로 CP 강일관성이 되지는 않습니다. 유실 확률을 크게 낮추는 장치일 뿐입니다

설정 지시어

Redis 5.0부터 slave 표기가 replica로 바뀌었고, master/primary 표기는 문서·옵션명에 혼재합니다:

• REPLICAOF <host> <port> — replica 설정 (구 명령 SLAVEOF는 deprecated이지만 호환성을 위해 동작)
• replicaof <host> <port> — 설정 파일 지시어
• replica-read-only yes — 기본값. Replica를 읽기 전용으로 유지 (writable replica는 비권장)

기타 주의사항

• redis-cli --rdb는 복제 첫 동기화와 같은 경로로 RDB를 받아 갑니다. fork와 전체 데이터셋 전송이 일어나므로 운영 인스턴스에 아무 때나 걸지 않습니다
• 연결이 끊긴 동안 밀린 양이 primary의 replication backlog를 넘어서면 partial resync가 불가능해져 full sync로 떨어집니다. 이때 fork와 전송 부하가 다시 발생합니다

5. 권장 운영 설정

# 클라이언트 연결 수
maxclients 10000   # 기본값. 파일 디스크립터 한도에 걸리면 실제 상한이 더 낮아짐

# 영속성
save ""           # RDB off (캐시용)
appendonly no     # AOF off (캐시용, 기본값)

# 위험 명령은 rename-command 대신 ACL 로 차단
# ACL SETUSER default -keys -flushall -flushdb -config

# 보안
requirepass <강력한_비밀번호>

maxclients는 프로세스가 열 수 있는 파일 디스크립터 soft limit을 확인해 그보다 크면 자동으로 낮춰 잡습니다. 연결 수를 올릴 때는 ulimit -n도 같이 올려야 합니다. 명령 차단에는 rename-command를 쓰지 않는 편이 낫습니다 — 공식 설정 파일이 이 항목을 deprecated로 표시하고, 기본 사용자에서 명령을 제거하는 ACL 방식을 권합니다.

KEYS와 예기치 않은 save 트리거는 대표적인 장애 원인입니다. KEYS는 O(N)이라 정규 애플리케이션 코드에서 사용하지 말아야 하고, save 설정은 “N초 안에 키가 M개 바뀌면 자동으로 RDB를 dump”하는데, 예상치 못한 시점에 fork가 발생해 메모리를 2배로 소비할 수 있습니다.

Sentinel과 Cluster의 역할 차이, 영속성 메커니즘, 그리고 운영에서 피해야 할 함정 — 이 세 가지가 Redis 운영의 뼈대입니다. 버전이 올라가면서 라이선스와 자료형은 크게 바뀌었지만, 단일 스레드로 명령을 처리하고 fork로 디스크에 쓴다는 기본 구조는 그대로입니다.

이 글은 2026-09-20에 MySQL 8.4·9.7 공식 매뉴얼과 유니코드 표준을 확인해 갱신했습니다. SQL 결과는 MySQL Community Server 8.4.11에서 재현했습니다. 다른 버전이나 관리형 서비스에서는 아래 쿼리로 실제 동작을 확인해야 합니다.

이름과 적용 범위부터 확인합니다

utf8mb4_0900_ai_ci의 이름은 다음 뜻입니다.²

• utf8mb4: 문자 하나를 최대 4바이트로 표현하는 UTF-8 문자셋입니다.
• 0900: Unicode Collation Algorithm(UCA) 9.0.0에 기반한 비교·정렬 규칙입니다.
• ai: 악센트를 구분하지 않습니다. 예를 들어 e와 é가 같습니다.
• ci: 대소문자를 구분하지 않습니다. 예를 들어 a와 A가 같습니다.

이 글의 0900_ai_ci는 1차 가중치로 비교하고, 0900_as_ci는 2차까지, 0900_as_cs는 3차까지 비교합니다. 3차 차이에는 대소문자 외의 문자 형태 차이도 포함되므로, 한글에 대소문자가 없다고 해서 ci와 cs의 결과가 항상 같은 것은 아닙니다.³

UCA 9.0 기반 콜레이션은 이전 UCA 기반 콜레이션보다 빠르도록 구현되어 있지만, 그것만으로 기본값 변경의 이유나 모든 데이터에서의 성능 우위를 설명할 수는 없습니다. 보조 문자 지원과 비교 정확성도 함께 봐야 합니다.²

완성형과 호환 자모가 같은 값으로 검색됩니다

mysql CLI에서 실습용 데이터베이스를 선택한 뒤, 같은 연결에서 아래 쿼리를 실행합니다. 임시 테이블은 연결을 종료하면 사라집니다.

SET NAMES utf8mb4 COLLATE utf8mb4_0900_ai_ci;
SELECT VERSION(), @@character_set_connection, @@collation_connection;

CREATE TEMPORARY TABLE korean_collation_demo (
  id INT PRIMARY KEY,
  name VARCHAR(30) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;

INSERT INTO korean_collation_demo (id, name)
VALUES (1, '가나다'), (2, 'ㄱㅏ나다'), (3, 'ㄱㅏㄴㅏㄷㅏ');

SELECT id, name, CHAR_LENGTH(name) AS chars,
       LENGTH(name) AS bytes, HEX(name) AS hex_value
FROM korean_collation_demo
WHERE name = '가나다'
ORDER BY id;

바이트도 문자 수도 다른 세 행이 모두 나옵니다. 조건을 name = 'ㄱㅏ나다'나 name = 'ㄱㅏㄴㅏㄷㅏ'로 바꿔도 같은 세 행이 나옵니다. 반면 비교식에 utf8mb4_general_ci를 명시하면 첫 번째 행만 나옵니다.

SELECT id, name
FROM korean_collation_demo
WHERE name COLLATE utf8mb4_general_ci = '가나다'
ORDER BY id;

이 예제는 = 비교에 관한 것입니다. LIKE는 문자 단위로 비교하므로 같은 결과라고 가정하면 안 됩니다.⁴

SELECT
  _utf8mb4'가나다' COLLATE utf8mb4_0900_ai_ci = _utf8mb4'ㄱㅏㄴㅏㄷㅏ'
    AS equal_result,
  _utf8mb4'가나다' COLLATE utf8mb4_0900_ai_ci LIKE _utf8mb4'ㄱㅏㄴㅏㄷㅏ'
    AS like_result;
-- equal_result = 1, like_result = 0

콜레이션은 GROUP BY, DISTINCT, 유니크 인덱스의 중복 판정에도 영향을 줍니다. 위 테이블에서 COUNT(DISTINCT name)은 1입니다.

SELECT COUNT(DISTINCT name) AS distinct_names FROM korean_collation_demo;
-- distinct_names = 1

CREATE TEMPORARY TABLE korean_unique_demo (
  name VARCHAR(30) NOT NULL,
  UNIQUE KEY uq_korean_unique_demo_name (name)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;

INSERT INTO korean_unique_demo (name) VALUES ('가나다');
INSERT INTO korean_unique_demo (name) VALUES ('ㄱㅏㄴㅏㄷㅏ');
-- 두 번째 INSERT는 ERROR 1062 (23000): Duplicate entry ... 로 실패합니다.

애플리케이션에서 코드포인트나 바이트로만 중복 검사했다면, 검사 결과와 DB의 유니크 판정이 달라질 수 있습니다. 중복 조회와 저장의 비교 기준을 맞추고, 동시에 들어오는 요청에 대해서도 최종 유니크 제약 위반을 처리해야 합니다.

UCA 비교와 유니코드 정규화를 구분합니다

UCA 9.0의 가중치표에서 결합 자모 ᄀ(U+1100)와 호환 자모 ㄱ(U+3131)는 1차·2차 가중치가 같고 3차 가중치가 다릅니다.⁵ 따라서 두 형태의 차이가 ai_ci 비교에서 사라지는 것은 UCA의 가중치 규칙으로 설명됩니다. 버전 업그레이드만 기대하기보다, 서비스에서 필요한 동일성 기준을 정해야 합니다.

또한 확인한 8.4·9.7 매뉴얼에는 utf8mb4_ko_0900_ai_ci 같은 한국어 전용 콜레이션이 없습니다.²⁶ euckr_korean_ci는 다른 문자셋용이므로 utf8mb4 컬럼에 사용할 수 없습니다.

여기서 호환 자모와 NFD 분해형은 다릅니다. 둘을 모두 “분해형”이라고 부르면 해결 방법을 잘못 고르게 됩니다.

NFC는 정준적으로 동등한 문자를 정규화하며 호환성 차이는 유지합니다. 따라서 NFC만 적용해서는 이 글의 호환 자모 입력을 완성형으로 바꿀 수 없습니다. NFKC는 호환성 정규화까지 하지만, 전각 문자·동그라미 숫자 등의 차이도 함께 없애므로 입력 정책에 맞춰 선택해야 합니다.⁷

Python 표준 라이브러리로 차이를 확인할 수 있습니다.

import unicodedata

# 결합 자모는 NFC로 합쳐지지만 호환 자모는 그대로 남습니다.
assert unicodedata.normalize("NFC", "\u1100\u1161\u1102\u1161\u1103\u1161") == "가나다"
assert unicodedata.normalize("NFC", "ㄱㅏㄴㅏㄷㅏ") == "ㄱㅏㄴㅏㄷㅏ"
assert unicodedata.normalize("NFKC", "ㄱㅏㄴㅏㄷㅏ") == "가나다"

정규화는 키보드 입력기의 한글 조합 과정도 아닙니다. 예를 들어 NFKC가 ㄱㅏㄱ을 받침 있는 각으로 조합해 주지는 않습니다. 따라서 임의의 호환 자모 나열을 복원하는 방법으로 취급해서는 안 됩니다.

요구사항에 맞는 콜레이션을 컬럼에 지정합니다

아래는 MySQL 8.4.11에서 각 쌍을 =로 비교한 결과입니다. “같음”은 1, “다름”은 0입니다. NFD 열은 위 표의 결합 자모 문자열을 뜻합니다.

각 환경에서 재검증할 때는 다음 비교식의 COLLATE 이름을 바꿔 실행하면 됩니다. NFD 문자열은 편집기에서 모양을 구분하기 어려워 UTF-8 바이트로 지정했습니다.

SELECT
  _utf8mb4'가나다' COLLATE utf8mb4_0900_as_cs = _utf8mb4'ㄱㅏㄴㅏㄷㅏ'
    AS compatibility_equal,
  _utf8mb4'가나다' COLLATE utf8mb4_0900_as_cs =
    CONVERT(0xE18480E185A1E18482E185A1E18483E185A1 USING utf8mb4)
    AS nfd_equal;
-- compatibility_equal = 0, nfd_equal = 1

UCA 비교를 유지하면서 호환 자모를 구분할 때

utf8mb4_0900_as_cs를 검토합니다. 호환 자모와 완성형을 구분하지만, 악센트와 영문 대소문자도 함께 구분합니다. 완성형과 NFD 분해형은 여전히 같은 값입니다.

utf8mb4_0900_as_ci만으로는 호환 자모 문제가 해결되지 않습니다. 이 예제의 차이는 2차까지 비교해서는 드러나지 않고 3차 비교에서 드러납니다. 대소문자 무시도 필요한 계정명이라면, as_cs로 바꾸기 전에 입력 정규화·대소문자 처리·유니크 판정을 함께 설계해야 합니다.

문자 코드의 차이와 후행 공백까지 구분할 때

utf8mb4_0900_bin을 검토합니다. 이 콜레이션은 MySQL 8.0.17에 추가되었고 NO PAD입니다. 기존 utf8mb4_bin도 문자 코드에 따른 비교를 하지만 PAD SPACE라서 후행 공백을 무시합니다.⁸

_bin 콜레이션을 쓰는 VARCHAR는 여전히 문자열 타입입니다. utf8mb4_bin을 “바이트를 그대로 비교하는 타입”이라고 설명하면 부정확합니다. 인코딩 변환 없이 바이트 자체를 저장·비교해야 한다면 VARBINARY나 BLOB을 검토해야 합니다.⁹ 또한 바이너리 계열의 정렬은 언어별 정렬 규칙과 다르므로 표시 순서도 확인합니다.

기존 utf8mb4_general_ci를 유지할 때

기존 서비스가 이 비교 규칙에 의존한다면 유지할 수 있습니다. 다만 이를 한국어 전용 해결책이나 단순 코드포인트 정렬로 설명해서는 안 됩니다. general_ci는 대소문자·악센트를 무시하는 레거시 비교 규칙이며, 확장·축약·무시문자 처리가 제한됩니다.²

보조 문자도 주의해야 합니다. 같은 문자셋이라 저장은 가능하지만, 비교는 기대와 다를 수 있습니다. 아래 이모지 비교도 MySQL 8.4.11에서 재현됩니다.

SELECT
  _utf8mb4'😀' COLLATE utf8mb4_general_ci = _utf8mb4'😁' AS general_equal,
  _utf8mb4'😀' COLLATE utf8mb4_0900_ai_ci = _utf8mb4'😁' AS uca_equal;
-- general_equal = 1, uca_equal = 0

한글 호환 자모만 구분하려고 전체 DB를 general_ci로 바꾸면, 이모지의 유니크 판정과 후행 공백 등 다른 동작까지 바뀝니다. 한글이라는 이유만으로 하나의 콜레이션을 일괄 적용하기보다, 컬럼이 무엇을 식별하는지에 맞춰 선택하는 편이 낫습니다.

연결 설정만으로 기존 컬럼은 바뀌지 않습니다

collation_connection이나 Connector/J의 connectionCollation을 지정해도 기존 컬럼의 콜레이션은 변경되지 않습니다. 일반적인 컬럼과 문자열 리터럴의 비교에서는 컬럼의 우선순위가 더 높습니다. MySQL의 coercibility 값은 명시적 COLLATE가 0, 컬럼이 2, 리터럴이 4이며 작은 쪽을 적용합니다.¹⁰

앞서 만든 임시 테이블로 확인할 수 있습니다.

SET NAMES utf8mb4 COLLATE utf8mb4_general_ci;

SELECT @@collation_connection;
-- utf8mb4_general_ci
SELECT COUNT(*) AS matched FROM korean_collation_demo WHERE name = '가나다';
-- matched = 3: 컬럼의 utf8mb4_0900_ai_ci를 따릅니다.

SET NAMES utf8mb4 COLLATE utf8mb4_0900_ai_ci;

연결 설정은 문자 인코딩과 리터럴끼리의 비교 등에 필요하지만, 컬럼의 비교 정책을 대신하지 않습니다. 실제 대상 컬럼은 다음과 같이 확인합니다. 테이블명은 예시입니다.

SHOW FULL COLUMNS FROM korean_collation_demo;
SHOW CREATE TABLE korean_collation_demo;

SELECT COLLATION_NAME, PAD_ATTRIBUTE
FROM information_schema.COLLATIONS
WHERE COLLATION_NAME IN (
  'utf8mb4_0900_ai_ci', 'utf8mb4_0900_as_cs',
  'utf8mb4_0900_bin', 'utf8mb4_bin', 'utf8mb4_general_ci'
)
ORDER BY COLLATION_NAME;

위의 SET NAMES는 mysql CLI 재현용입니다. Connector/J 애플리케이션에서는 characterEncoding·connectionCollation 등 드라이버 설정을 사용합니다. Connector/J는 애플리케이션이 직접 실행한 SET NAMES의 변경을 감지하지 못하므로, 공식 문서도 이를 사용하지 말라고 안내합니다.¹¹

기존 컬럼을 변경하기 전에 확인할 것

기존 컬럼은 ALTER TABLE ... MODIFY로 문자셋과 콜레이션을 지정할 수 있습니다. 아래는 앞의 실습 테이블에 대한 예제이며, 운영 테이블에서는 SHOW CREATE TABLE로 확인한 타입·길이·NULL 허용·기본값·COMMENT 등의 속성을 보존해야 합니다. 생략한 컬럼 속성은 자동으로 유지되지 않습니다.¹²

ALTER TABLE korean_collation_demo
  MODIFY name VARCHAR(30)
  CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_as_cs NOT NULL;

SELECT COUNT(*) AS matched FROM korean_collation_demo WHERE name = '가나다';
-- matched = 1

서버·데이터베이스·테이블의 기본값만 변경해도 이미 존재하는 컬럼이 함께 변환되는 것은 아닙니다. 실제 컬럼 정의를 확인해야 합니다.¹²

운영 데이터에는 다음을 점검합니다.

• 변경 후 중복: 대상 콜레이션으로 GROUP BY ... HAVING COUNT(*) > 1을 실행해 유니크 충돌 후보를 찾습니다. 복합 유니크 키라면 전체 키 조합을 기준으로 검사합니다.
• 공백과 정규화: NO PAD에서 PAD SPACE로 바꾸면 a와 a 가 충돌할 수 있습니다. 입력 정규화를 새로 도입할 때도 기존 데이터의 충돌을 확인합니다.
• 쿼리와 조인: 대소문자·악센트의 일치 여부, 정렬 순서, 조인 상대 컬럼과의 콜레이션 호환성을 확인합니다. 조회식의 COLLATE로 우회한다면 인덱스 사용도 EXPLAIN으로 확인합니다.
• 변경 비용: 컬럼 콜레이션 변경에 따른 테이블·인덱스 재구성, 잠금, 필요한 디스크 공간을 사본에서 확인합니다. 운영 테이블에 같은 DDL을 즉시 실행할 수 있다고 가정하지 않습니다.

후행 공백 비교는 값을 실제로 잘라 저장한다는 뜻도 아닙니다. VARCHAR의 저장과 콜레이션의 비교를 구분해야 하며, CHAR에는 별도의 패딩·조회 규칙이 있습니다. 또한 LIKE의 후행 공백 처리를 =와 같다고 가정해서는 안 됩니다.¹³

완성형·결합 자모·호환 자모·영문 대소문자·후행 공백을 각각 같은 값으로 볼지 정하고, 그 기준을 입력 처리와 컬럼의 유니크 제약에 일관되게 적용해야 합니다.

참고 자료