Friday, September 7, 2018

개발자를 괴롭히는 RDS 한글 인코딩 문제, 근본 원인부터 해결까지
  /   No comments   

밤늦게까지 이어진 코딩, 드디어 서비스를 배포하고 데이터를 입력하는 순간, 데이터베이스에 저장된 자랑스러운 한글 데이터가 '???'라는 알 수 없는 물음표로 가득 차 있는 것을 발견한 개발자의 절망감은 이루 말할 수 없습니다. 혹은 분명 한글을 저장했는데, 웹 페이지에서는 '안녕하세요'와 같이 외계어로 보이는 글자들이 출력되는 황당한 경우도 있습니다. 이는 명백한 '인코딩(Encoding) 불일치' 문제입니다. 특히 클라우드 데이터베이스의 표준으로 자리 잡은 AWS RDS(Relational Database Service)를 사용하면서 이러한 문제를 겪는 개발자들이 매우 많습니다.

이 문제는 단순히 파라미터 한두 개를 수정해서 해결될 때도 있지만, 근본적인 원인을 이해하지 못하면 임시방편에 그치거나 더 큰 데이터 유실로 이어질 수 있습니다. 이 글에서는 AWS RDS에서 발생하는 한글 깨짐 현상의 근본적인 원인을 A부터 Z까지 파헤치고, MySQL(MariaDB 포함)과 PostgreSQL 환경에서 각각 어떻게 문제를 진단하고 완벽하게 해결할 수 있는지, 나아가 이미 깨져버린 데이터를 복구하는 방법과 앞으로의 프로젝트에서 인코딩 문제를 원천 차단하는 예방책까지, 실무에 바로 적용할 수 있는 깊이 있는 가이드를 제공합니다. 더 이상 '???'와의 전쟁으로 밤을 새우지 마십시오.

1. 모든 문제의 근원: 문자셋(Character Set)과 콜레이션(Collation)

한글 깨짐 문제를 해결하려면, 먼저 컴퓨터가 문자를 어떻게 이해하고 저장하는지에 대한 기본적인 이해가 필요합니다. 바로 '문자셋'과 '콜레이션'입니다.

1.1. 문자셋 (Character Set) 이란?

문자셋은 간단히 말해 '문자-숫자 매핑 테이블'입니다. 컴퓨터는 0과 1밖에 모르기 때문에, '가'라는 한글이나 'A'라는 영어를 저장하기 위해서는 특정 숫자(코드 포인트)와 약속을 해야 합니다.

  • ASCII (아스키): 초창기 인터넷을 지배했던 문자셋으로, 128개의 영문자, 숫자, 특수기호만을 표현할 수 있었습니다. 당연히 한글은 표현할 수 없습니다.
  • EUC-KR: 한글을 표현하기 위해 만들어진 한국 표준 문자셋입니다. 완성형 한글 2,350자를 표현할 수 있었지만, '뷁'이나 '꿿' 같은 현대 한글이나 다양한 특수문자, 이모티콘 등은 표현하지 못하는 한계가 있었습니다.
  • UTF-8: 전 세계의 거의 모든 문자를 표현하기 위해 만들어진 유니코드(Unicode) 표준을 구현하는 방식 중 하나입니다. 1바이트에서 4바이트까지 가변 길이를 사용하여 문자를 표현하기 때문에 효율적이며, 사실상 현대 웹의 표준 문자셋입니다.
  • UTF-8mb4: 우리가 주목해야 할 가장 중요한 문자셋입니다. MySQL에서 'utf8'은 최대 3바이트 문자까지만 지원하도록 구현되었습니다. 이 때문에 4바이트가 필요한 현대 이모티콘(😂👍)이나 일부 고대 문자를 저장하려고 하면 오류가 발생하거나 데이터가 깨집니다. UTF-8mb4는 이러한 문제를 해결하고 진짜 UTF-8, 즉 4바이트 문자까지 완벽하게 지원하는 문자셋입니다. 따라서 현대적인 서비스를 개발한다면 무조건 utf8mb4를 사용해야 합니다.

1.2. 콜레이션 (Collation) 이란?

콜레이션은 문자셋으로 저장된 문자들을 '어떻게 비교하고 정렬할 것인가'에 대한 규칙의 집합입니다. 예를 들어, 'a'와 'A'를 같은 것으로 취급할지(대소문자 미구분), '가' 다음에 '나'가 오는지 '다'가 오는지 등을 결정합니다.

  • utf8mb4_general_ci: _ci는 Case Insensitive의 약자로, 대소문자를 구분하지 않습니다. 비교 속도가 빠르지만, 다국어 환경에서의 정확성은 다소 떨어질 수 있습니다.
  • utf8mb4_unicode_ci: 유니코드 표준 정렬 규칙을 따르므로 다국어 환경에서 훨씬 더 정확한 정렬 결과를 보장합니다. 특별한 이유가 없다면 utf8mb4_unicode_ci 사용을 권장합니다.
  • utf8mb4_bin: 바이너리(Binary) 데이터로 취급하여 문자 그대로, 바이트 값으로 비교합니다. 대소문자를 포함한 모든 문자를 칼같이 구분하며 정렬 속도가 가장 빠릅니다.

1.3. 한글이 깨지는 시나리오: 인코딩의 연쇄 고리

한글 데이터는 여러 단계를 거쳐 데이터베이스에 저장됩니다. 이 과정에서 단 하나의 고리라도 인코딩 설정이 다르면 문제는 발생합니다.

  1. 클라이언트(브라우저/앱): 사용자가 입력한 데이터를 UTF-8로 인코딩하여 전송.
  2. 애플리케이션 서버(WAS): 받은 데이터를 처리. 이 과정에서 서버 자체 설정이나 코드에 의해 인코딩이 변경될 수 있음.
  3. 데이터베이스 커넥션(Connection): 애플리케이션이 DB에 연결할 때 사용하는 설정. "이제부터 너랑 나랑은 이 문자셋으로 대화하자"고 약속하는 단계.
  4. 데이터베이스 서버(RDS): 최종적으로 데이터를 받아 저장하는 곳. 서버 자체, 특정 데이터베이스, 테이블, 심지어는 컬럼 단위까지 모두 고유한 문자셋 설정을 가질 수 있습니다.

예를 들어, 애플리케이션은 UTF-8로 데이터를 보냈는데, 데이터베이스 커넥션이 latin1(서양 언어 문자셋)으로 설정되어 있다면, DB 서버는 "아, 이건 latin1 데이터구나"라고 오해하고 데이터를 잘못 변환하여 저장합니다. 이 결과가 바로 '???' 입니다.

2. 적을 알아야 이긴다: 내 RDS의 현재 상태 진단하기

문제를 해결하기 위해 무작정 설정을 바꾸기 전에, 현재 내 RDS 인스턴스의 인코딩 상태가 어떤지 정확히 진단하는 것이 가장 중요합니다.

2.1. MySQL / MariaDB 환경 진단

HeidiSQL, DBeaver, MySQL Workbench 등 선호하는 DB 툴로 RDS 인스턴스에 접속한 후, 다음 쿼리를 실행해 보세요. 

SHOW VARIABLES LIKE 'c%';

이 쿼리는 현재 데이터베이스 연결과 서버에 적용된 모든 문자셋 관련 변수를 보여줍니다. 여기서 주목해야 할 핵심 변수들은 다음과 같습니다.

변수명 설명 권장 값
character_set_client 클라이언트가 보내는 SQL문의 문자셋입니다. utf8mb4
character_set_connection 클라이언트로부터 받은 SQL문을 서버가 처리할 때 사용하는 문자셋입니다. utf8mb4
character_set_database 현재 사용 중인 기본 데이터베이스의 문자셋입니다. utf8mb4
character_set_results 쿼리 결과를 클라이언트에게 반환할 때 사용하는 문자셋입니다. utf8mb4
character_set_server 데이터베이스 서버의 기본 문자셋입니다. utf8mb4
character_set_system 서버가 메타데이터 저장에 사용하는 문자셋으로, 보통 UTF-8이며 사용자가 변경할 수 없습니다. utf8 (고정)
collation_connection connection 문자셋의 콜레이션입니다. utf8mb4_unicode_ci
collation_database 데이터베이스의 콜레이션입니다. utf8mb4_unicode_ci
collation_server 서버의 기본 콜레이션입니다. utf8mb4_unicode_ci

만약 위 변수들 중 하나라도 latin1이나 euckr과 같이 utf8mb4가 아닌 값으로 설정되어 있다면, 그것이 바로 문제의 원인일 가능성이 매우 높습니다.

서버 전체 설정뿐만 아니라, 특정 테이블이나 컬럼에만 다른 문자셋이 설정되었을 수도 있습니다. 다음 쿼리로 테이블의 생성 구문을 확인하여 문자셋을 점검할 수 있습니다. 

SHOW CREATE TABLE your_table_name;

결과로 나온 CREATE TABLE 구문 마지막에 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci와 같이 명시되어 있는지 반드시 확인해야 합니다.

2.2. PostgreSQL 환경 진단

PostgreSQL은 MySQL과 다르게 데이터베이스 클러스터(인스턴스)를 생성할 때 인코딩이 결정되며, 한번 결정되면 변경이 매우 까다롭습니다. 현재 데이터베이스의 인코딩을 확인하는 방법은 다음과 같습니다.

psql 툴로 접속하여 다음 명령어를 실행합니다. 

\l

또는 SQL 쿼리를 통해 확인할 수도 있습니다. 

SELECT datname, pg_encoding_to_char(encoding) FROM pg_database;

이 명령은 현재 인스턴스에 존재하는 모든 데이터베이스의 목록과 각 데이터베이스의 인코딩을 보여줍니다. 여기서 한글을 사용하려는 데이터베이스의 인코딩이 UTF8로 되어 있는지 확인해야 합니다. 만약 SQL_ASCII 나 다른 값으로 되어 있다면, 이것이 문제입니다.

서버의 기본 인코딩은 다음 쿼리로 확인할 수 있습니다. 

SHOW server_encoding;

마찬가지로 클라이언트의 인코딩 설정도 중요합니다. 

SHOW client_encoding;

만약 client_encoding이 server_encoding과 다르다면 PostgreSQL이 자동으로 변환을 시도하지만, 이 과정에서 문제가 발생할 수 있습니다.

3. 최종 해결책: AWS RDS 파라미터 그룹 완벽 설정

진단이 끝났다면, 이제 치료에 들어갈 차례입니다. AWS RDS는 직접 서버의 설정 파일(my.cnf 등)을 수정할 수 없으므로, '파라미터 그룹(Parameter Group)'을 통해 데이터베이스의 설정을 변경해야 합니다.

3.1. [공통] 파라미터 그룹 생성 및 적용

먼저, 기존의 default 파라미터 그룹은 수정이 불가능하므로, 새로운 커스텀 파라미터 그룹을 생성해야 합니다.

  1. AWS Management Console에 로그인하여 RDS 서비스로 이동합니다.
  2. 왼쪽 탐색 창에서 '파라미터 그룹'을 클릭합니다.
  3. '파라미터 그룹 생성' 버튼을 클릭합니다.
  4. '파라미터 그룹 패밀리'에서 현재 사용 중인 DB 엔진 버전에 맞는 것을 선택합니다. (예: mysql8.0, mariadb10.6, postgres14 등)
  5. 그룹 이름(예: my-custom-utf8mb4-group)과 설명을 입력하고 '생성'을 클릭합니다.
  6. 방금 생성한 파라미터 그룹을 선택하고 '파라미터 편집'을 클릭합니다.

이제 아래에서 설명할 DB 엔진별 파라미터를 수정합니다.

3.2. MySQL / MariaDB 파라미터 그룹 설정

생성한 파라미터 그룹의 편집 화면에서, 다음 파라미터들을 검색하여 값을 변경하고 저장합니다. 진단 단계에서 확인했던 모든 변수들을 서버 레벨에서 교정하는 과정입니다.

  • character_set_server: utf8mb4
  • character_set_database: utf8mb4
  • character_set_connection: utf8mb4
  • character_set_client: utf8mb4
  • character_set_filesystem: utf8mb4
  • character_set_results: utf8mb4
  • collation_server: utf8mb4_unicode_ci
  • collation_connection: utf8mb4_unicode_ci

※ 필살기: `skip-character-set-client-handshake`

위 설정을 모두 마쳤음에도 불구하고 문제가 해결되지 않는 경우가 종종 발생합니다. 이는 애플리케이션의 DB 커넥터(JDBC, PyMySQL 등)가 연결 시 자체적으로 "나는 `latin1`으로 통신할래!" 와 같이 서버에 잘못된 문자셋을 강요하는 경우에 발생합니다. 서버는 클라이언트의 요구를 존중하여 character_set_client, character_set_connection, character_set_results를 클라이언트가 요청한 값으로 변경해버립니다.

이러한 '배신'을 막기 위한 파라미터가 바로 skip-character-set-client-handshake 입니다. 이 값을 1(또는 `True`)로 설정하면, 서버는 클라이언트가 어떤 문자셋을 요청하든 무시하고, 서버의 기본 설정(character_set_server, collation_server)을 강제로 사용하게 됩니다. 이는 클라이언트 측의 잘못된 설정을 서버 단에서 무력화시키는 강력한 해결책입니다.

  • skip-character-set-client-handshake: 1 (또는 `True`)

참고: 예전 MySQL 버전에서는 character_set_client_handshake 값을 0으로 설정하는 방식이었으나, 최신 버전에서는 skip-character-set-client-handshake를 `1`로 설정하는 것이 올바른 방법입니다.

3.3. 파라미터 그룹 적용 및 재부팅 (가장 중요!)

파라미터 수정이 완료되었다면, 이 그룹을 실제 RDS 인스턴스에 적용해야 합니다.

  1. RDS 대시보드의 '데이터베이스' 메뉴로 이동하여 대상 DB 인스턴스를 선택합니다.
  2. '수정' 버튼을 클릭합니다.
  3. '데이터베이스 옵션' 섹션에서 'DB 파라미터 그룹'을 방금 생성하고 수정한 커스텀 파라미터 그룹(예: my-custom-utf8mb4-group)으로 변경합니다.
  4. 페이지 하단으로 내려가 '계속'을 클릭한 후, 변경 사항 요약을 확인하고 '즉시 적용'을 선택한 뒤 'DB 인스턴스 수정'을 클릭합니다.

가장 중요한 단계가 남았습니다. 파라미터 그룹의 변경 사항 중 상당수(특히 character_set_server 같은 static 파라미터)는 DB 인스턴스를 재부팅해야만 적용됩니다. RDS 대시보드에서 해당 인스턴스를 선택하고 '작업' -> '재부팅'을 실행하세요. 재부팅이 완료된 후 다시 DB에 접속하여 SHOW VARIABLES LIKE 'c%'; 쿼리를 실행해 보면 모든 값이 utf8mb4로 변경된 것을 확인할 수 있습니다.


3.4. PostgreSQL 파라미터 그룹 설정 및 해결 전략

PostgreSQL의 경우, 아쉽게도 파라미터 그룹에서 server_encoding 같은 핵심 인코딩 파라미터는 수정할 수 없습니다. 이는 '읽기 전용'으로 설정되어 있기 때문입니다. 만약 RDS PostgreSQL 인스턴스를 생성할 때 인코딩을 잘못 선택했다면, 해결 방법은 훨씬 더 번거롭습니다.

유일한 해결책은 새로운 데이터베이스를 올바른 인코딩으로 생성하고 데이터를 마이그레이션하는 것입니다.

  1. 새 데이터베이스 생성: psql 이나 DB 툴로 접속하여, UTF-8 인코딩을 명시하여 새로운 데이터베이스를 생성합니다. 
    CREATE DATABASE my_new_db ENCODING 'UTF8' TEMPLATE template0 LC_COLLATE 'ko_KR.UTF-8' LC_CTYPE 'ko_KR.UTF-8';
    참고: LC_COLLATE와 LC_CTYPE은 OS 로캘 설정에 따라 다르므로, `C`나 `en_US.UTF-8` 등으로 설정할 수도 있습니다.
  2. 데이터 마이그레이션: pg_dump와 pg_restore 유틸리티를 사용하여 기존 데이터베이스의 데이터를 덤프한 후, 새로운 데이터베이스에 복원합니다. 이 과정에서 인코딩 변환이 일어나도록 옵션을 설정할 수 있습니다. 
    # 기존 DB 덤프 (latin1 이었다고 가정)
pg_dump -h YOUR_RDS_ENDPOINT -U YOUR_USER -E latin1 -f old_db.dump old_db_name

# 새 DB에 복원 (UTF8로 자동 변환)
pg_restore -h YOUR_RDS_ENDPOINT -U YOUR_USER -d my_new_db --no-owner --role=YOUR_USER old_db.dump
  3. 애플리케이션 연결 정보 변경: 애플리케이션이 새로운 데이터베이스(my_new_db)를 바라보도록 설정을 변경합니다.

이처럼 PostgreSQL은 사후 처리 비용이 매우 크므로, 최초 RDS 인스턴스 생성 시점에 '추가 구성'에서 '데이터베이스 이름'과 함께 올바른 '파라미터 그룹' (미리 `client_encoding` 등을 `utf8`로 설정한)을 선택하는 것이 무엇보다 중요합니다.

4. 서버만이 아니다: 애플리케이션과 클라이언트 설정 점검

DB 서버 설정을 완벽하게 마쳤다고 해도 안심할 수 없습니다. 애플리케이션이 DB와 통신하는 '연결' 단계에서 인코딩을 명시하지 않으면 모든 노력이 수포로 돌아갈 수 있습니다.

4.1. 데이터베이스 커넥션 URL

사용하는 프로그래밍 언어나 프레임워크의 DB 연결 설정에 문자셋을 명시적으로 지정해야 합니다.

  • Java (JDBC):

    커넥션 URL 끝에 ?useUnicode=true&characterEncoding=utf8 파라미터를 추가합니다. `utf8`만 적어도 드라이버가 알아서 서버와 협상하여 `utf8mb4`로 통신하는 경우가 많지만, 명시적으로 `utf8`을 적어주는 것이 안전합니다.

    jdbc:mysql://YOUR_RDS_ENDPOINT:3306/your_db?useUnicode=true&characterEncoding=utf8
  • Python (PyMySQL / mysql-connector-python):

    connection을 생성하는 함수나 객체에 charset='utf8mb4' 인자를 전달합니다.

    import pymysql

connection = pymysql.connect(host='YOUR_RDS_ENDPOINT',
                             user='YOUR_USER',
                             password='YOUR_PASSWORD',
                             db='your_db',
                             charset='utf8mb4', # <-- 이 부분!
                             cursorclass=pymysql.cursors.DictCursor)
  • Node.js (mysql / mysql2):

    connection을 생성하는 설정 객체에 charset: 'utf8mb4' 속성을 추가합니다.

    const mysql = require('mysql2');

const connection = mysql.createConnection({
  host: 'YOUR_RDS_ENDPOINT',
  user: 'YOUR_USER',
  database: 'your_db',
  password: 'YOUR_PASSWORD',
  charset: 'utf8mb4' // <-- 이 부분!
});
  • PostgreSQL (모든 언어 공통):

    PostgreSQL 드라이버는 보통 클라이언트의 로캘(locale) 설정을 따르거나, PGCLIENTENCODING 환경 변수를 통해 인코딩을 설정할 수 있습니다. 대부분의 최신 드라이버는 서버의 server_encoding이 UTF8이면 자동으로 클라이언트 인코딩도 UTF8로 맞추므로 특별한 설정이 필요 없는 경우가 많습니다.

4.2. 웹 프론트엔드 설정

데이터베이스와 백엔드 서버 간의 통신이 완벽하더라도, 최종적으로 사용자에게 보여주는 브라우저가 HTML 문서를 잘못된 방식으로 해석하면 한글이 깨질 수 있습니다. 모든 HTML 문서의 태그 안에 다음 메타 태그를 반드시 포함시켜야 합니다. 




    
    My Awesome Page


    ...

이 태그는 브라우저에게 "이 문서는 UTF-8로 인코딩되었으니 그렇게 해석해달라"고 알려주는 역할을 합니다.

5. 이미 엎질러진 물: 깨져버린 데이터 복구 시도하기

인코딩 설정을 모두 마쳤지만, 이미 `???`나 외계어로 저장된 데이터는 저절로 복구되지 않습니다. 데이터가 깨진 유형에 따라 복구 가능성이 다릅니다.

유형 1: '???'로 저장된 경우

데이터가 물음표(???)로 저장되었다면, 이는 데이터가 저장되는 시점에 문자셋에 없는 문자로 인식되어 '알 수 없는 문자'를 의미하는 '?'로 영구적으로 대체된 것입니다. 이 데이터는 복구가 불가능합니다. 원본 데이터가 유실된 것이므로, 유일한 방법은 데이터가 깨지기 전의 시점으로 데이터베이스를 백업에서 복원하는 것입니다. AWS RDS의 시점 복원(Point-in-time recovery) 기능을 활용할 수 있습니다.

유형 2: 외계어('안녕하세요')로 저장된 경우

이러한 형태는 그나마 희망이 있습니다. 이는 'UTF-8'로 인코딩된 데이터를 'latin1' 문자셋으로 오해하여 바이트 스트림을 그대로 저장하고, 다시 그것을 'UTF-8'로 읽어오면서 발생하는 이중 인코딩(Double Encoding) 문제입니다. 즉, 원본 데이터의 바이트 정보는 손실되지 않고 보존되어 있습니다.

이 경우, 다음과 같은 SQL 쿼리를 통해 데이터를 복구해볼 수 있습니다. 단, 이 작업은 매우 위험하므로 반드시 테이블을 백업한 후 테스트용 테이블에서 먼저 시도해 보시길 바랍니다. 

-- !! 경고: 실행 전 반드시 테이블 전체를 백업하세요 !!

-- 1. 임시로 컬럼 타입을 BINARY로 변경하여 문자셋 해석을 중단시킵니다.
-- 2. latin1으로 저장된 것을 다시 latin1 바이트로 되돌립니다.
-- 3. 그 결과물(원본 UTF-8 바이트)을 최종적으로 utf8mb4로 해석하여 업데이트합니다.

UPDATE your_table_name 
SET your_column_name = CONVERT(CAST(CONVERT(your_column_name USING latin1) AS BINARY) USING utf8mb4) 
WHERE ... ; -- 특정 조건에 맞는 데이터만 업데이트하는 것을 권장

위 쿼리는 your_column_name 컬럼의 데이터를 'latin1으로 한번 해석' -> '바이너리 데이터로 변환' -> '다시 utf8mb4로 최종 해석'하는 과정을 거쳐 원래의 한글로 되돌립니다.

6. 백전불패: 새 프로젝트를 위한 한글 깨짐 방지 체크리스트

지금까지의 내용을 바탕으로, 새로운 프로젝트를 시작할 때 인코딩 문제를 원천 봉쇄할 수 있는 체크리스트를 정리했습니다.

  1. [RDS] 커스텀 파라미터 그룹 생성: mysql/mariadb의 경우 모든 character_set_*과 collation_* 계열 파라미터를 utf8mb4와 utf8mb4_unicode_ci로 설정하고, skip-character-set-client-handshake를 1로 설정. postgres의 경우 client_encoding을 utf8로 설정한 그룹을 미리 생성.
  2. [RDS] 인스턴스 생성: RDS 인스턴스 생성 시 '추가 구성'에서 반드시 위에서 만든 커스텀 파라미터 그룹을 지정. PostgreSQL의 경우 DB 생성 시 인코딩을 UTF8로 지정.
  3. [DB 스키마] 테이블 생성: 모든 `CREATE TABLE` 구문 마지막에 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci 옵션을 명시적으로 추가. (PostgreSQL은 해당 없음)
  4. [백엔드] DB 커넥션 설정: JDBC, PyMySQL, Node-mysql 등 모든 DB 연결 라이브러리 설정에 문자셋을 utf8 또는 utf8mb4로 명시.
  5. [프론트엔드] HTML 설정: 모든 HTML 파일의 <head>에 <meta charset="UTF-8"> 태그를 포함.

이 5가지 원칙만 지킨다면, 당신의 서비스에서 '???'와 외계어는 더 이상 찾아볼 수 없게 될 것입니다.

결론: `utf8mb4`로 대동단결

AWS RDS 환경에서의 한글 인코딩 문제는 복잡해 보이지만, 그 핵심 원리는 '모든 단계의 문자셋을 일치시키는 것'으로 귀결됩니다. 그리고 현대적인 웹 환경에서 그 해답은 명확합니다. 클라이언트부터 애플리케이션 서버, 데이터베이스 커넥션, 그리고 최종 저장소인 데이터베이스 서버와 테이블까지, 모든 것을 `UTF-8`, 특히 MySQL/MariaDB에서는 이모티콘까지 완벽히 지원하는 `utf8mb4`로 통일하는 것입니다.

이 글에서 제시한 진단법과 해결책, 그리고 예방 체크리스트를 통해 지긋지긋한 인코딩 문제와의 전쟁을 종식시키고, 안정적인 데이터 관리에 더 많은 시간을 쏟을 수 있기를 바랍니다. 이제 당신의 데이터는 언제나 '안녕'할 것입니다.


0 개의 댓글:

Post a Comment