URL의 쿼리 문자열은 존재하는 데이터 전달 형식 중 가장 단순하다 — &로 구분된 key=value 쌍의 목록일 뿐이다. 하지만 평평한 문자열 목록보다 복잡한 것을 전달해야 하는 순간, 이 단순함은 곧바로 문제가 된다.
쿼리 문자열이 제한적인 이유
쿼리 문자열 형식은 원래 단순한 HTML 폼을 위해 설계된 것이라 데이터 타입, 중첩 구조, 배열이라는 개념이 애초에 내장되어 있지 않다. 그 안의 모든 것은 텍스트이므로, 숫자 42와 문자열 "42"는 어떤 코드가 명시적으로 파싱하기 전까지는 구분되지 않는다.
배열 인코딩: Spring 진영의 관례
한국의 대형 백엔드 시스템, 특히 네이버·카카오 등 국내 대기업 개발 문화에서 오랫동안 표준처럼 여겨져 온 것이 Java 기반 Spring 프레임워크다. Spring MVC 환경에서는 배열 파라미터를 보통 같은 키를 대괄호 없이 반복하는 방식(tags=a&tags=b)이나 콤마로 구분한 값(tags=a,b)으로 표현하는 경우가 많다. 반면 PHP는 tags[]=a&tags[]=b 표기를 별도 라이브러리 없이 네이티브로 배열로 해석한다. 클라이언트와 서버가 서로 다른 관례를 기대하면 배열 데이터는 조용히 유실되거나 뒤틀린다.
JSON이 이 문제를 해결하는 이유
JSON은 숫자, 불리언, null 같은 내장 타입을 가지고 있고, 어떤 인코딩 규칙도 없이 중첩된 객체와 배열을 자연스럽게 지원한다. 그래서 POST 요청 본문의 복잡한 데이터는 보통 JSON으로 전송하고, 쿼리 문자열은 필터나 페이지 번호처럼 단순하고 평평한 파라미터를 위해 남겨둔다.
어디에 쓰는가
- 백엔드가 쿼리 문자열에서 배열 파라미터를 정확히 어떤 형식으로 기대하는지 확인한다.
- 디버깅을 쉽게 하기 위해 URL 파라미터를 JSON으로 변환한다.
- 복잡한 데이터 구조를 GET 파라미터 대신 다른 방식으로 전달해야 하는 이유를 이해한다.
URL 길이 제한
대부분의 브라우저와 서버는 URL 길이를 약 2000자로 제한한다(정확한 값은 브라우저와 웹 서버에 따라 다르다). 그래서 쿼리 문자열은 물리적으로 대량의 데이터를 전달하기에 적합하지 않다. 이것이 복잡한 폼이나 배열 데이터에는 JSON 본문을 가진 POST 요청이 표준으로 쓰이고, 쿼리 문자열이 있는 GET은 짧고 단순한 파라미터에만 남겨두는 또 다른 이유다.