Amazon Redshift, SUPER 문자열 한도를 65,535바이트에서 1,600만 바이트로 상향: 매개변수 활성화 필요, 프로비저닝 클러스터는 재부팅, 테이블 VARCHAR(MAX) 열은 그대로, 설정 후 기본값 복귀 불가

2026년 11월 6일 AWS는 Amazon Redshift의 SUPER 데이터 형식에 개별 문자열을 최대 1,600만 바이트까지 저장할 수 있게 되었다고 발표했습니다. 기존 한도는 65,535바이트였습니다. JSON, PARQUET, TEXT, CSV 파일에서 읽어 들이는 데이터와 추출·적재·변환(ELT) 작업이 만든 데이터에 적용되며, AWS는 Redshift가 제공되는 모든 AWS 리전(AWS GovCloud(US) 리전 포함)에서 쓸 수 있다고 말합니다. 핵심 조건은 발표의 첫 문단에 있습니다. 데이터베이스 매개변수로 직접 켜야 하며, 켜지 않으면 아무것도 바뀌지 않습니다.

용도는 예전에는 적재 전에 나누거나 잘라야 했던 반정형 데이터입니다. AWS는 이용 약관과 계약서처럼 긴 문서를 꼽고, 관련 블로그 글은 상세한 상품 카탈로그, 전체 애플리케이션 로그, 고객 상호작용 이력을 더합니다. 이런 데이터가 Redshift에 들어오면 SQL로 조회하고, PartiQL 언어로 탐색하고, 문자열 함수로 변환할 수 있습니다. AWS는 JSON_PARSE, CONCAT, LISTAGG 같은 함수가 이제 최대 1,600만 바이트의 입력 문자열을 받고 같은 길이까지의 출력 문자열을 돌려줄 수 있다고 말합니다.

Redshift 문서는 켜면 무엇이 되고 한도가 어디서 멈추는지를 설명합니다. 매개변수는 enable_large_strings_opt_in이고 값은 Yes, No, 미설정이며, 미설정은 클러스터의 기존 동작을 그대로 둡니다. Yes로 하면 SUPER 안의 개별 문자열이 16,000,000바이트에 이를 수 있고, 메모리 내 문자열 함수가 그 크기의 VARCHAR 값을 처리할 수 있으며, CAST 식, 뷰, 사용자 정의 함수, 저장 프로시저 같은 식 문맥에서 VARCHAR(MAX)가 VARCHAR(16000000)으로 해석됩니다. 저장되는 열이 넓어지지는 않습니다. VARCHAR(MAX)로 CREATE TABLE을 하면 여전히 VARCHAR(65535) 열이 만들어집니다. 따라서 큰 크기는 SUPER 값과 메모리 안에 있고, 일반 VARCHAR 열에는 없습니다. patch 206 이상이 필요합니다. 기존 뷰·UDF·저장 프로시저는 다시 만들기 전까지 65,535바이트 한도가 유지되고 일반 VARCHAR 열은 넓어지지 않습니다. 기존 SUPER 객체 전체의 16 MB 한도와 이번 개별 문자열의 16,000,000바이트 한도는 서로 다릅니다.

켜기 전에 중요한 운영상 세부 사항이 몇 가지 있습니다. 프로비저닝된 클러스터는 매개변수를 적용하려면 재부팅해야 하고, Amazon Redshift Serverless는 매개변수 그룹 대신 워크그룹의 구성 매개변수를 씁니다. 매개변수를 Yes나 No로 설정하면 기본값으로 되돌릴 수 없고, ResetClusterParameterGroup으로 재설정해도 원래 값이 유지됩니다. `SELECT is_large_string_enabled();` 명령으로 현재 상태를 볼 수 있습니다. 관련 블로그의 예시는 COPY로 큰 JSON 문서를 적재할 때 `FORMAT JSON 'noshred'` 옵션을 써서 각 문서를 하나의 SUPER 값으로 유지합니다. 블로그는 세 가지 개선을 함께 다룹니다. 큰 문자열, 잘림 없는 메모리 내 문자열 연산, 대소문자를 구분하지 않는 데이터베이스에서의 SUPER 지원이며, 카멜케이스 속성 이름을 위한 `enable_case_sensitive_super_attribute` 설정도 있습니다. 저희는 이 중 어느 것도 실행하지 않았습니다. 데이터 공유에서는 생산자와 소비자 웨어하우스의 enable_large_strings_opt_in 설정이 같아야 합니다. 미설정 기본값으로 되돌릴 수 없다는 뜻이지 No를 명시적으로 선택할 수 없다는 뜻은 아닙니다.

발표와 문서에는 1,600만 바이트에 가까운 문자열의 적재 시간, 메모리 사용량, 쿼리 지연 수치가 없고 가격 영향도 설명하지 않습니다. 요금은 별도로 확인해야 합니다. 관련 블로그는 과거 디스크 스필이 성능에 영향을 줬다고 언급하지만 측정은 보여 주지 않습니다. 클라이언트 도구·드라이버·내보내기의 큰 값 호환성은 실측하지 않아 도구별로 확인해야 합니다. 기존 객체와 데이터 공유 설정 제한은 관련 블로그에 명시돼 있습니다.

참고로 SUPER는 JSON 같은 반정형 데이터를 한 열에 통째로 담고 PartiQL로 조회하게 해 주는 Redshift의 데이터 형식입니다. 예전에는 65,535바이트를 넘는 문자열을 적재하기 전에 잘라 내거나 나누어야 했고, 이 때문에 데이터 파이프라인이 복잡해지고 정보가 사라질 수도 있었습니다. 문자열이 길어지면 한 행의 크기도 커지므로 복제, 백업, 결과 전송에 부담이 늘 수 있는데, 이는 저희의 추론이며 자료에는 나와 있지 않습니다.

저희의 판단은, SUPER에 큰 JSON 문서를 두는 사람에게 엄격한 한도를 없애 주는 유용하고 범위가 좁은 변경이며, 직접 켜는 방식이 기존 부하를 보호한다는 것입니다. 또한 Yes나 No를 고르면 미설정 기본 상태로 돌아갈 수 없고, 테이블 정의는 바뀌지 않습니다. 팀은 먼저 비운영 클러스터에서 재부팅 시간대까지 포함해 시험하고, 클라이언트 도구와 후속 쿼리가 매우 큰 값을 감당하는지 확인한 뒤에야 운영에서 매개변수를 설정할지 결정해야 합니다.