쿼리 (Query)

쿼리(Query)는 데이터베이스나 검색 시스템에 어떤 데이터를 어떤 조건으로 돌려받을지 적어 보내는 요청입니다. 개발 문맥에서는 주로 SQL 같은 질의 언어로 쓴 데이터베이스 질의를 가리키고, 웹 주소의 물음표 뒤에 붙는 쿼리 문자열(query string)을 줄여 부를 때도 씁니다. 검색과 RAG에서는 사용자가 입력한 질문이나 검색어 자체를 쿼리라고 부릅니다.

SQL SELECT 문으로 쓰는 데이터베이스 쿼리

PostgreSQL 공식 문서의 표 조회 튜토리얼은 표에서 데이터를 꺼내는 일을 표를 쿼리한다고 부르고, 이 작업에 SQL SELECT 문을 쓴다고 설명합니다. SELECT 문은 돌려받을 열을 적는 선택 목록, 데이터를 가져올 표를 적는 표 목록, 필요할 때 제한 조건을 적는 한정 부분으로 나뉩니다. SELECT * FROM weather;는 weather 표의 모든 행을 가져오며, 여기서 *는 모든 열을 뜻하는 줄임 표기입니다. 선택 목록에는 열 이름뿐 아니라 (temp_hi+temp_lo)/2 같은 계산식도 쓸 수 있습니다. SELECT는 데이터를 꺼내는 문장이고, 표에 행을 넣는 작업은 같은 튜토리얼의 앞 절에서 따로 다룹니다.

원하는 행만 고르는 조건은 WHERE 절에 씁니다. 같은 튜토리얼에 따르면 WHERE 절에는 참과 거짓을 내는 불리언 식이 들어가고, 그 식이 참인 행만 결과로 돌아옵니다. WHERE city = 'San Francisco' AND prcp > 0.0은 샌프란시스코의 날씨 기록 가운데 강수량이 0보다 큰 날만 고르는 조건이며, 조건 안에서 AND, OR, NOT을 쓸 수 있습니다.

결과의 순서와 중복도 쿼리에 적어야 정해집니다. ORDER BY city처럼 정렬 기준을 일부만 주면 같은 도시의 행은 어느 순서로든 나올 수 있고, ORDER BY city, temp_lo는 같은 도시 안에서 최저기온으로 정렬합니다. 두 기준값이 모두 같은 행끼리의 순서는 보장하지 않습니다. PostgreSQL은 DISTINCT로 중복 행을 없앤 결과가 정렬된다고 보장하지 않으므로, 일정한 순서가 필요하면 ORDER BY를 함께 씁니다. 이 문서는 SELECT *가 임시로 확인하는 질의에는 편하지만 표에 열이 추가되면 결과가 달라져 운영 코드에서는 나쁜 습관으로 여겨진다고 덧붙입니다.

URL 쿼리 문자열과 URLSearchParams

웹에서 쿼리는 주소의 물음표 뒤에 이름과 값을 &로 이어 붙인 쿼리 문자열을 가리키기도 합니다. MDN의 URLSearchParams 문서는 이 인터페이스를 URL의 쿼리 문자열을 다루는 메서드 모음으로 소개하고, q=URLUtils.searchParams&topic=api 같은 문자열을 키와 값의 쌍으로 읽는 예를 듭니다. 주소 끝에 ?foo=a가 붙은 페이지에서 location.search를 넘겨 만든 객체는 get("foo")로 a를 돌려줍니다.

쿼리 문자열에서는 같은 이름이 여러 번 나올 수 있습니다. foo=bar&foo=baz에서 get()은 첫 값 bar만, getAll()은 두 값을 모두 돌려줍니다. 생성자는 전체 URL을 해석하지 않고 맨 앞의 물음표만 떼어 내므로, 주소 전체에서 값을 읽을 때는 URL 객체의 search 값을 넘깁니다.

인코딩 규칙도 따로 있습니다. URLSearchParams는 직렬화할 때 공백을 +로 바꾸고, 문자열을 읽을 때는 +를 공백으로 해석합니다. 그래서 Base64처럼 +가 들어간 값을 문자열 보간으로 넣으면 값이 바뀌고, 문서는 이런 값을 append()로 넣는 방법을 안내합니다. 서버 코드가 쿼리 문자열의 값을 읽어 데이터베이스 쿼리의 조건으로 옮기는 일은 흔하지만, 두 쿼리를 만드는 규칙과 도구는 서로 다릅니다.

검색과 RAG에서 말하는 쿼리

검색 엔진과 검색 증강 생성(RAG) 문맥의 쿼리는 사용자가 입력한 질문이나 검색어입니다. Azure AI Search의 벡터 검색 설명처럼 시스템은 쿼리를 색인된 문서와 견주어 관련 있는 문서를 찾습니다. 키워드 검색은 쿼리의 단어가 문서에 나오는지를 보고, 벡터 기반 의미 검색은 쿼리를 임베딩 벡터로 바꾼 뒤 가까운 문서를 찾습니다. 두 방식을 함께 쓰는 하이브리드 검색도 같은 쿼리에서 출발합니다.

사용자가 쓴 문장이 검색에 그대로 맞지 않을 때는 쿼리를 고쳐 쓰는 단계를 넣기도 합니다. 대화 중에 나온 "그거 가격은?" 같은 질문은 앞 대화의 대상을 채우면 검색 범위가 명확해집니다. LangChain의 대화 이력 기반 검색기는 대화 이력이 있으면 언어 모델로 검색 쿼리를 생성해 검색기에 전달합니다. 이런 처리를 쿼리 재작성이라고 부릅니다. RAG에서는 쿼리가 찾아온 문서가 모델에 근거로 전달되므로, 쿼리를 어떻게 쓰느냐에 따라 모델이 읽는 근거가 달라집니다.

바이브 코딩에서 AI 도구에 쿼리를 고쳐 달라고만 요청하면 데이터베이스, 웹 주소, 검색 가운데 어느 쿼리인지가 문맥에 맡겨집니다. 데이터베이스 쿼리라면 표 이름과 원하는 조건과 정렬을, URL 쿼리라면 매개변수 이름과 예상 값을, 검색 쿼리라면 검색 대상과 기대하는 결과를 함께 적을 때 요청의 범위가 분명해집니다.