MySQL 데이터베이스에서 JSON과 TEXT 기반 저장 방식의 성능 비교

2-1 연구 배경

현대의 웹 및 데이터 기반 시스템에서는 구조화된 데이터와 비정형 데이터가 혼합되어 사용되며, 이에 따라 데이터 저장 방식은 단순한 스키마 설계를 넘어 시스템의 성능과 확장성에 중요한 영향을 미친다. 특히 JSON은 복잡한 데이터를 하나의 필드에 구조화된 형태로 저장할 수 있어, API 통신, 사용자 설정, 로깅 등에서 널리 활용되고 있다.

MySQL은 5.7 버전부터 JSON 타입을 도입하여 키 기반 검색, 정렬, 조건 필터링 등을 SQL 내에서 직접 처리할 수 있도록 지원하고 있다. 그럼에도 불구하고 실무 현장에서는 JSON 형식의 데이터를 단순 문자열로 TEXT 컬럼에 저장하는 방식도 여전히 많이 사용되며, 이는 삽입 속도, 개발 편의저장 내용은 유사하더라도 MySQL의 처리 방식, 지원 기능, 성, 구조 유연성 등 실용적 이점 때문이다. 이러한 두 방식은 성능 특성에서 뚜렷한 차이를 보이므로, 실무적으로도 명확한 비교가 필요하다.

2-2 JSON 기반 저장 방식

JSON(JavaScript Object Notation)은 사람과 기계가 모두 이해하기 쉬운 형태로 데이터를 표현할 수 있도록 설계된 경량 데이터 포맷이다. 주로 키-값 쌍(key-value pair)의 구조를 기반으로 하며, 중첩된 트리 구조를 통해 복잡한 데이터도 유연하게 표현할 수 있다. 이러한 특징 덕분에 JSON은 웹, 모바일, 서버 환경 등 다양한 시스템 간 데이터 교환에 널리 활용되며, 언어에 독립적인 포맷으로 대부분의 프로그래밍 언어에서 쉽게 처리할 수 있다. JSON은 간결하고 직관적인 문법을 통해 개발자와 시스템 모두가 손쉽게 데이터를 읽고 작성할 수 있게 하며, 특히 비정형 또는 반정형 데이터를 다루는 데 적합한 구조를 제공한다. 이로 인해 오늘날 API 통신, 로그 기록, 사용자 설정 저장 등 다양한 분야에서 표준 데이터 표현 방식으로 사용되고 있다[3].

2-3 TEXT 기반 저장 방식

TEXT 타입은 단순한 긴 문자열을 저장하는 데이터 타입으로, MySQL에서는 구조화에 대한 정보 없이 순수한 텍스트로만 처리된다. JSON 형식의 문자열을 TEXT로 저장할 경우, MySQL은 이를 구조화된 데이터로 인식하지 못하므로 내부 쿼리로는 개별 필드에 접근하거나 조건을 설정할 수 없다.

그 결과, SELECT나 정렬, 그룹화 연산에서 구조화된 조건을 적용하기 위해서는 외부 애플리케이션에서 파싱(json.loads 등)을 먼저 수행해야 하며, 이는 성능 저하를 유발하는 주요 원인이 된다. 그러나 저장 속도 측면에서는 구조화 과정이 생략되기 때문에 JSON 타입보다 유리한 경우도 존재한다.

2-4 관련 연구 및 실무적 논의

기존 연구들에서는 JSON 저장 방식이 조건 기반 검색, 정렬과 같은 구조화된 연산에 적합하다는 점이 지속적으로 강조되어 왔다. 이는 JSON 타입이 데이터베이스 내부에서 키 기반 접근과 전용 쿼리 함수(JSON_EXTRACT 등)를 지원함으로써, 복합 조건 필터링이나 정렬 작업에서 효율적인 성능을 발휘할 수 있기 때문이다[4].

반면, 삽입 속도와 디스크 저장 효율성 측면에서는 일반적인 문자열(TEXT) 기반 저장 방식이 상대적으로 유리하다는 분석도 존재한다. 특히 데이터 구조를 단순히 원본 형태로 저장하거나, 외부 애플리케이션에서 파싱과 가공을 수행하는 시스템 구조에서는 TEXT 저장 방식이 더 적합하게 작용할 수 있다. 이 방식은 별도의 구조화 연산이 불필요하며, 저장 시 처리 과정이 단순해 삽입 성능이 향상될 수 있다[5],[6].

이처럼 실무 환경에서는 저장 방식의 선택이 시스템 아키텍처, 데이터 처리 흐름, 외부 연계 방식 등에 따라 달라지기 때문에, 어느 한 방식이 절대적으로 우월하다고 보기는 어렵다. 일부 개발 환경에서는 JSON을 단순 로깅 용도로 사용하거나, TEXT 컬럼에 전체 구조를 저장한 뒤 외부에서 유연하게 처리하는 방식을 선호하기도 한다. 따라서 저장 방식을 선택할 때에는 단순 성능 지표뿐만 아니라 데이터 활용 목적과 시스템 전반의 요구사항을 종합적으로 고려할 필요가 있다.

3-1 실험 환경

본 연구는 Windows 10 Pro 운영체제 환경에서 수행되었으며, 데이터베이스 관리 시스템으로는 MySQL 8.0.41 버전을 사용하였다. 실험 스크립트는 Python 3.9 기반으로 작성되었고, MySQL 연결을 위해 mysql-connector-python 라이브러리를 활용하였다. 개발 및 테스트는 Spyder 4.2.5 환경에서 진행되었다. 하드웨어는 AMD Ryzen 5 3600 6-Core 프로세서와 DDR4 16GB 메모리를 사용하였으며, 모든 실험은 동일한 시스템 사양 하에서 수행하여 결과의 일관성과 신뢰성을 확보하였다.

3-2 데이터 구성 및 테이블 설계

실험에 사용된 데이터는 실제 서비스를 가정하여, 사용자 관련 정보를 포함하는 다항목(JSON 객체 기반) 구조로 생성하였다. 각 데이터는 다음과 같은 10개 필드로 구성된다.

Table 1.

Configuring data fields

Fig. 1.

Experimental algorithm flowchart

데이터 저장은 다음 두 방식으로 각각 설계된 테이블에 수행되었다:

• 1. json_data 테이블: payload 컬럼을 JSON 타입으로 생성
• 2. string_data 테이블: payload 컬럼을 TEXT 타입으로 생성

각 테이블은 동일한 데이터 구조를 가지되, 컬럼 타입만 다르게 하여 저장 방식의 성능 차이를 분석하였다.

3-3 실험 내용

실험은 데이터 삽입(이하 “INSERT”, SQL의 INSERT 문 사용), 복합 조건 검색(이하 “SELECT”, 파이썬 조건 필터링), 정렬(이하 “ORDER BY”, ORDER BY 쿼리), 그룹화(이하 “GROUP BY”, SQL의 GROUP BY 구문) 성능을 비교하는 방식으로 진행되었다. 또한 저장된 데이터의 디스크 사용량을 측정하여 저장 효율성도 함께 분석하였다.

본 실험 알고리즘을 기반으로, 이후 삽입/검색/정렬/그룹화 실험을 각각 수행하였다. 데이터 삽입 실험은 각각 json_data 테이블과 string_data 테이블에 랜덤으로 생성된 데이터를 1,000개, 5,000개, 10,000개, 50,000개, 100,000개씩 삽입하는 방식으로 진행되었다. 삽입 성능 비교를 위해 Python 스크립트에서 각각 JSON 타입과 TEXT 타입으로 데이터를 구성하고, 동일한 양의 데이터를 각 테이블에 삽입하였다. 또한 모든 실험은 동일 조건에서 10회 반복 수행하였다.

삽입 시에는 Python의 time 모듈을 이용해 시작 시간과 종료 시간을 측정하여, 삽입에 소요된 시간을 정밀하게 기록하였다. 삽입은 각각 독립적으로 수행되었으며, 삽입 완료 후에는 즉시 COMMIT을 수행하여 데이터가 디스크에 반영되도록 하였다[7].

그림 2는 실험에 사용된 랜덤 데이터를 생성하여 각각 json_data 테이블과 string_data 테이블에 삽입하는 과정을 보여준다. JSON 저장 방식에서는 Python의 json.dumps()를 이용해 데이터를 직렬화하여 저장하고, TEXT 방식에서는 동일한 필드를 문자열 포맷팅을 통해 직접 생성하여 삽입하였다.

Fig. 2.

JSON and TEXT data insertion algorithms

삽입 과정은 NUM_INSERTS로 정의된 반복 수만큼 수행되며, 각각 삽입 시작 전과 종료 후 시간을 기록하여 총 삽입 소요 시간을 측정하였다. 삽입 완료 후에는 commit()을 호출하여 데이터베이스에 반영하였다. JSON 저장 방식과 TEXT 저장 방식 모두 데이터 구조는 동일하지만, 삽입 과정과 내부 처리 방식에서 차이가 발생한다.

복합 조건 SELECT 쿼리 실험 방식은 저장된 데이터에 대해 복합 조건(job = ‘Engineer’ AND hobby = ‘reading’)을 적용하여 검색 성능을 비교하는 실험하였다. JSON 저장 방식과 TEXT 저장 방식 각각에 대해 검색 시간이 측정되었으며 반복 실험에 의해 평균값과 표준편차를 산출하였다. JSON 저장 방식에서는 MySQL의 JSON_EXTRACT 함수를 이용하여 조건을 직접 SQL 쿼리에 적용하여 검색을 수행하였다. 반면 TEXT 방식에서는 전체 레코드를 조회한 후, Python의 json.loads()를 이용하여 데이터를 파싱하고 조건을 검사하는 방식으로 검색을 수행하였다. 이 실험을 통해 구조화된 검색과 비구조화된 검색 간의 성능 차이를 정량적으로 비교하였다[8].

ORDER BY 정렬 실험 방식의 경우는 저장된 데이터에 대해 age 필드를 기준으로 오름차순 정렬을 수행하는 과정을 보여준다. JSON 저장 방식에서는 MySQL의 JSON_EXTRACT 함수를 사용하여 payload 컬럼 내부에서 age 값을 추출하고, 이 값을 기준으로 SQL 쿼리 내에서 직접 정렬을 수행하였다.

JSON_EXTRACT 함수는 JSON 데이터 구조 안에서 특정 키를 지정해 값을 가져올 수 있게 하며, 이를 기반으로 정렬을 수행할 수 있도록 한다. TEXT 저장 방식에서는 모든 레코드를 조회한 후 Python에서 JSON 문자열을 파싱하고 각 객체로 변환하여 age 값을 기준으로 정렬하였다. 이는 SQL 쿼리 내에서 정렬이 불가능하기 때문에, 조회 이후 애플리케이션 레벨에서 파싱과 정렬을 별도로 수행해야 한다. 이때 Python의 json.loads() 함수로 문자열을 JSON 객체로 변환하고, list.sort() 메서드를 통해 정렬을 수행하였다.

GROUP BY 정렬 실험 방식은 저장된 데이터에 대해 job 필드를 기준으로 그룹화하고, 각 그룹별 데이터 수를 집계하는 과정을 보여준다. JSON 저장 방식에서는 SQL 쿼리 내에서 JSON_EXTRACT 함수를 사용하여 payload 컬럼 내부의 job 값을 추출한 뒤, 이 값을 기준으로 그룹화를 수행하였다. 이 방식은 데이터베이스 엔진 수준에서 그룹 연산이 이루어지기 때문에, 결과가 직접적으로 집계되어 반환된다.

TEXT 저장 방식에서는 모든 레코드를 조회한 후, Python 애플리케이션 레벨에서 JSON 문자열을 파싱하여 객체로 변환하고, job 필드를 기준으로 그룹핑을 수행하였다. 이 과정은 Python의 collections.defaultdict 자료구조를 활용하여 각 job 값에 대한 출현 횟수를 집계하는 방식으로 구현되었다. 본 실험은 JSON 저장 방식과 TEXT 저장 방식 간의 그룹화 처리 방식과 데이터 핸들링 구조의 차이를 비교할 수 있도록 설계되었다.

저장된 JSON 데이터와 TEXT 데이터를 대상으로 테이블별 디스크 사용량을 측정하는 과정은 MySQL 데이터베이스 시스템 테이블인 INFORMATION_SCHEMA.TABLES를 이용하여 수행되었다. data_length와 index_length 항목을 합산하여 테이블이 실제로 사용하는 총 저장 공간을 계산하고, 이를 KB 단위로 변환하였다. 또한 특정 테이블(json_data, string_data)에 대해서만 쿼리를 실행하여, 각각의 디스크 사용량을 비교 분석할 수 있도록 데이터를 수집하였다. 측정 결과는 Pandas 라이브러리를 사용하여 테이블 형태로 변환하고 출력하였다.

4-1 데이터 삽입 성능 비교

데이터 삽입 성능 비교 실험은 각각 JSON 저장 방식과 TEXT 저장 방식을 대상으로 수행되었다. 각 데이터 수(1,000, 5,000, 10,000, 50,000, 100,000)별로 랜덤 생성된 데이터를 삽입하는 과정을 10회 반복 수행하고, 삽입 완료까지 소요된 시간을 측정하였다.

그림 3은 실험을 통해 수집된 JSON 및 TEXT 저장 방식의 삽입 성능 결과를 정리한 것으로, 데이터 수 증가에 따른 평균 삽입 시간이 각 방식에서 어떻게 달라지는지를 정량적으로 보여준다. 모든 데이터 수 구간에서 TEXT 방식이 JSON 방식보다 짧은 삽입 시간을 기록하였으며, 그 차이는 일정하게 유지되는 경향을 나타냈다. 이러한 결과는 TEXT 방식이 구조화 과정 없이 단순 문자열로 저장되는 반면, JSON 방식은 삽입 시 내부적으로 데이터 구조를 분석하고 바이너리 포맷으로 변환하는 연산이 추가로 수행되기 때문으로 해석된다.

Fig. 3.

Data insert performance comparison results

그림 4에서 나타낸 평균 시간에 따른 결과를 보면, TEXT 저장 방식은 전 구간에 걸쳐 JSON 저장 방식보다 삽입 시간이 더 짧게 나타났다. 평균적으로 TEXT 저장 방식은 JSON 저장 방식에 비해 약 15% 빠른 삽입 성능을 보였으며, 데이터 수가 증가함에 따라 양 방식 모두 삽입 시간이 증가하는 경향을 보였으나, 성능 차이는 비교적 완만하게 유지되었다.

Fig. 4.

Insert performance comparison graph (average time required)

4-2 복합 조건 검색 성능 비교

복합 조건 검색 실험은 job = ‘Engineer’ AND hobby = ‘reading’ 조건을 적용하여, JSON 저장 방식과 TEXT 저장 방식 간 검색 소요 시간을 비교하는 방식으로 수행되었다. 데이터 수 구간별로 10회 반복 수행하고 평균값과 표준편차를 계산하였다. 이를 통해 구조화된 쿼리 검색(JSON)과 파싱 기반 검색(TEXT) 간 성능 차이를 확인하였다.

복합 조건 검색 실험 결과, 그림 5에서 확인할 수 있듯이 JSON 저장 방식이 TEXT 저장 방식에 비해 일관되게 빠른 응답 속도를 보였다. 이는 JSON 타입이 MySQL 내부에서 키 기반 접근을 지원하는 반면, TEXT 타입은 애플리케이션 레벨에서 문자열을 파싱해야 하기 때문으로 해석된다. 또한 데이터 수가 증가할수록 TEXT 저장 방식의 성능 저하 폭이 더 크게 나타났다.

Fig. 5.

Composite conditions search performance comparison results

특히 그림 6을 보면, 데이터 수별 평균값 기준으로 JSON 저장 방식의 검색 시간은 TEXT 저장 방식의 소요 시간 대비 약 9~19% 수준으로 나타났다. 데이터 수가 1,000개일 경우 JSON은 TEXT의 약 19% 수준의 시간만 소요되었으며, 100,000개일 경우에는 약 9% 수준으로 감소하였다. 이는 데이터 규모가 커질수록 JSON 저장 방식의 상대적 검색 성능이 더욱 두드러짐을 의미하며, 두 방식 간 성능 차이가 일정하게 확대되는 경향을 보여준다.

Fig. 6.

Composite conditions search performance graph (average time required)

4-3 정렬 성능 비교

정렬 실험은 age 필드를 기준으로 오름차순 정렬을 수행하는 방식으로 진행되었다. JSON 저장 방식은 SQL 쿼리에서 JSON_EXTRACT 함수를 사용하였으며, TEXT 저장 방식은 전체 데이터를 조회한 후 Python에서 문자열을 파싱하여 정렬을 수행하였다.

실험 결과, 그림 7에 따르면 데이터 수가 1,000건에서 10,000건 이하인 구간에서는 TEXT 저장 방식이 JSON 저장 방식보다 다소 짧은 정렬 시간을 보이는 경향을 나타냈다. 그러나 데이터 수가 증가함에 따라 두 방식 간 성능 차이는 점차 반전되었으며, 50,000건 이상의 구간에서는 JSON 저장 방식이 상대적으로 더 낮은 정렬 시간을 기록하였다. 이는 TEXT 저장 방식이 정렬 시 모든 데이터를 메모리로 로드하고 파싱한 뒤 정렬을 수행해야 하므로, 데이터가 많아질수록 메모리 사용량과 연산 비용이 누적되는 구조적 한계가 반영된 결과로 해석된다. 이러한 구조적 차이와 처리 방식에 따른 성능 변화는 기존 연구에서도 유사한 관점에서 다루어진 바 있다[9].

Fig. 7.

Alignment performance comparison results

또한 그림 8을 보면, 평균값 기준 비교 결과, 1,000건 구간에서는 JSON 저장 방식이 TEXT 대비 약 35% 더 긴 시간이 소요된 반면, 50,000건과 100,000건 구간에서는 각각 TEXT의 약 45%, 40% 수준으로 처리 시간이 감소하였다. 이를 통해 데이터 규모가 커질수록 정렬 성능에 있어 JSON 저장 방식의 상대적 우위가 뚜렷해지는 경향이 확인되었다.

Fig. 8.

Alignment performance graph (average time required)

4-4 그룹화 성능 비교

그룹화 실험은 job 필드를 기준으로 그룹별 데이터 수를 집계하는 과정을 비교하는 방식으로 수행되었다. JSON 저장 방식은 SQL 내에서 직접 그룹화를 수행하였고, TEXT 저장 방식은 파싱 후 Python 레벨에서 그룹핑을 수행하였다. 이는 그룹화 연산 성능을 통해 데이터 구조화 여부가 집계 작업에 미치는 영향을 분석한다.

그림 9를 보면 알 수 있듯이, 모든 데이터 수 구간에서 JSON 저장 방식이 TEXT 저장 방식보다 일관되게 짧은 처리 시간을 기록하였다. 예를 들어, 1000건 기준으로 JSON은 평균 0.0018초, TEXT는 0.0054초가 소요되었고, 100,000건에서는 JSON이 0.1405초, TEXT가 0.5421초로 네 배 가까운 차이를 보였다. 데이터 수가 증가함에 따라 두 방식 모두 소요 시간이 증가하였으나, TEXT 저장 방식의 증가 폭이 훨씬 크게 나타나며 성능 저하가 두드러졌다. 이는 TEXT 방식이 그룹화 시 전체 데이터를 메모리로 로드하고 파싱한 후 Python 단에서 연산을 수행해야 하므로, 데이터가 많아질수록 처리 효율이 급격히 떨어지는 구조적 한계를 드러낸 결과로 해석된다.

Fig. 9.

Grouping performance comparison results

그림 10에서 보면 평균값 기준으로 분석한 결과, JSON 저장 방식은 모든 구간에서 TEXT 저장 방식보다 짧은 그룹화 시간을 기록하였으며, 데이터 수와 관계없이 일관된 성능 차이를 나타냈다. 구체적으로 JSON 저장 방식은 TEXT 저장 방식의 약 24~33% 수준의 처리 시간만을 소요하였으며, 데이터 수가 증가하더라도 이 비율은 비교적 안정적으로 유지되었다. 이는 두 방식 간 처리 구조의 차이로 인한 성능 격차가 데이터 규모에 관계없이 지속적으로 유지됨을 보여준다.

Fig. 10.

Grouping performance graph (average time required)

4-5 디스크 사용량 비교

디스크 사용량 비교 실험은 데이터 삽입 완료 후 MySQL의 INFORMATION_SCHEMA.TABLES를 조회하여 테이블별 저장 용량을 측정하는 방식으로 수행되었다.

그림 11에서 볼 수 있듯이, 평균값 기준으로 분석한 결과, JSON 저장 방식은 TEXT 방식에 비해 약 6.7%에서 21.1%까지 더 많은 저장 공간을 사용하는 것으로 나타났다. 데이터 수가 증가함에 따라 이 차이는 다소 변동이 있었으나, 대체로 110~120% 수준에서 유지되었다. 이는 JSON 타입이 구조화된 데이터를 바이너리 포맷으로 저장하면서 추가적인 메타데이터가 포함되기 때문으로 해석되며, 두 방식 모두 데이터 수에 비례하여 저장 용량이 증가하는 추세는 동일하였다.

Fig. 11.

Disk usage graph

4-6 종합 분석

동일한 JSON 데이터를 MySQL에서 각각 JSON 저장 방식과 TEXT 저장 방식으로 저장하였을 때, 두 방식은 삽입, 검색, 정렬, 그룹화 성능 및 디스크 저장 효율성 측면에서 뚜렷한 차이를 보였다. 다양한 데이터 수를 기준으로 반복 측정한 실험 결과에 따르면, 삽입 성능과 저장 공간 효율성에서는 TEXT 저장 방식이 더 우수하였다. 이는 구조 해석 없이 단순 문자열로 저장되는 TEXT의 특성에 기인하며, 디스크 사용량 역시 JSON에 비해 적게 나타났다. 반면, 복합 조건 검색, 정렬, 그룹화 성능에서는 JSON 저장 방식이 전반적으로 높은 처리 성능을 보였으며, 특히 데이터 규모가 클수록 성능 안정성이 두드러졌다. JSON은 키 기반 접근, 조건 필터링, 정렬 및 집계 연산 등을 MySQL 내부에서 직접 수행할 수 있기 때문에 이러한 결과가 나타난 것으로 해석된다.

이러한 분석을 바탕으로, 실무 환경에서는 단일 성능 지표에만 근거한 저장 방식 선택은 적절하지 않으며, 시스템의 주요 연산 유형과 데이터 활용 방식, 확장성 등을 종합적으로 고려해야 한다. JSON 저장 방식이 범용적으로 채택되는 추세에 있지만, 삽입 효율성과 단순 저장을 중시하는 로그 수집 시스템이나 대용량 보존 중심의 환경에서는 TEXT 방식이 유효한 대안이 될 수 있다. JSON과 TEXT 저장 방식 간의 성능 및 효율성 차이를 정량적으로 비교한 본 연구의 결과는, 데이터베이스 설계 및 운영에서 상황에 맞는 저장 전략 수립을 위한 실질적 판단 근거를 제공한다는 점에서 의의를 가진다.