SW 개발이 좋은 사람

앞서서 실행해 본 호텔 예약 챗봇 예제를 Intent와 Entity의 두 용어(메뉴)를 중심으로 정리하였다.

여기에서는 이 두 가지가 어떻게 구성되어 있는지(만드는지) 간단하게 정리하였다.

이 문서는 Dialogflow로 챗봇을 만드는 방법이 아니라 전체 개념과 몇 가지 용어에 익숙해지기 위해

앞서서 실행해 본 호텔 예약 챗봇 예제를 구성하는 요인에 대해서 정리한 문서이다.

Entity

먼저, Entity는 데이터 베이스의 데이터 타입와 비슷한 개념으로 개체 종류를 의미한다.

Entities 메뉴를 실행해 보면 [CUSTOM] 탭에 @room이라는 Entity가 등록되어 있다.

@room를 클릭하면 A, B, C가 등록되어 있다.

A, B, C는 싱글룸, 더블룸, 스위트룸 같은 호텔 방 종류가 room이라는 개체(Entity)로 정의되어 있다.

하단의 [Add a row]를 눌러서 추가할 수 있다.

다시 Entities 메뉴를 실행하고, 이번에는 [SYSTEM] 탭을 선택한다.

[CUSTOM]은 사용자가 등록한 개체고,

[SYSTEM]은 Dialogflow가 제공하는 것으로 숫자(number), 날짜(date), 위치(location) 등의 개체들이 정의 되어 있다.

Intent

왼쪽 메뉴에서 Intents를 선택한다.

Dialogflow가 기본 제공하는 2개 intent와 가져오기로 추가된 1개의 intent가 있다.

1. Default Fallback Intent

이 리스트에서 [Default Fallback Intent]를 클릭해 보면,

대부분 빈 내용이고 하단에 있는 [Response](대답)에 무슨 말인지 모르겠으니 다시 말해달라는 문장이 다양하게 적혀있다.

말 그대로 고객의 말을 못 알아 들었을 때, 

사용하는 문장들로 하나만 사용하면 지겨워서(?) 여러 가지를 등록한다고 한다.

2. Default Welcome Intent

Intents 리스트에서 [Default Welcome Intent]를 선택하면,

Training phrases(학습문장)과 Response(대답)만 채워져 있고 다른 부분은 비어있다.

[Add user expression]로 표시된 입력창에서 문장을 추가 할 수 있다.

Training phrases(학습문장)은 고객이 입력하는 문장으로,

고객이 이상과 같이 입력하면(Training phrases), 다음과 같이 Response(대답)하게 된다.

Response(대답)에서는 [Enter a text response variant]에 새로운 문장을 입력해서 추가한다.

내용을 추가하거나 수정 한 뒤에는 우측 상단의 [SAVE]버튼을 눌러서 저장한다.

3. room.reservation

가장 중요한 Inent인 실제 예약 (room.reservation)을 클릭해서 앞서의 Inent처럼 상세 내용을 보거나,

∧와 ∨ 아이콘을 눌러서 하위 Inent을 확인 할 수 있다.

room.reservation 하위에 4개의 Intent가 더 있다.

이 구조를 다르게 표현하면 다음과 같다.

예약에 필요한 위치(location), 날짜(date) 등의 정보를 대화를 통해 수집하고 (room.reservation),

호텔 방 종류를 선택하면 (room.reservation - choose room)

예약이 맞는지 확인하고 예약(yes)거나 취소(no, cancel)하는 구조이다.

방 선택과 예약 확인은 상세 내용을 보면 쉽게 이해 할 수 있지만

정보를 수집하기 위해 대화하는 과정은 이 예약 챗봇의 핵심으로 조금 복잡하고 어려울 수 있다.

리스트에서 room.reservation를 선택하면, 

핵심 부분이라 제법 많은 내용들이 출력되는데,

전체 구조는 Contexts, Event, Training phrases, Action and parameters, Responses, Fulfilment로 구성되어 있다.

이중에서  Event, Fulfilment는 여기에서 사용하지 안았다.

Contexts는 Intent의 순서들을 의미한다.

현재의 Intent를 실행하기 위해 먼저 실행해야 할 Intent와 (input context)

현재의 Intent를 실행한 뒤에 실행할  Intent(output context)을 지정한다.

즉, 앞서의 트리 구조를 지정하는 곳으로

예약 정보(room.reservation) 수집 전에는 먼저 실행할 Intent가 없고,

예약 정보가 수집되었으면 방선택(room.reservation - choose room) Intent을 실행한다.

(고객이 인사를 하면 환영인사 후에 실행 될 수 있고, 고객이 바로 예약을 진행 할 수 있다)

Training phrases(학습 문장)에는 예약과 관련 74개의 다양한 문장이 입력되어 있다.

Training phrases(학습 문장)은 고객이 하는 말이고,

Responses(대답)는 챗봇이 하는 말을 의미한다.

환영인사(Default Welcome Intent)에서는 이 두 대화 문장만 있었지만,

대화를 통해 정보를 수집하기 위한 Action and parameters가 작성되었다.

tomorrow와 같은 색상이 있는 단어를 클릭하면, 그림과 같은 메뉴가 나타난다.

tomorrow는 날짜(date)로 지정되어 있다.

내일 회의가 있어서 회의실을 예약 할거야(I have a meeting tomorrow let's book a conference hall)란 문장에서

내일(tomorrow)이 예약에 필요한 핵심 키워드로 추출되고, 내일(tomorrow)은 날짜형으로 보관된다.

사람은 날짜를 인식할 수 있지만, 챗봇은 알 수 없기 때문에 이렇게 미리 지정해 둔다.

다음 주 월요일 11시에 예약할거야(I need to book a meeting room on next Monday at 11 am)에서는

다음 주 월요일(next Monday)과 11시(11 am)가 지정되어 있다.

다른 문장들도 이렇게 지정되어 있으며, 같은 색상은 같은 타입을 의미하고

이렇게 예약에 필요한 위치(location), 날짜(date), 시간(time), 체류기간(duration), 인원수(guests)를 수집한다.

참고: 개인적으로는 이 부분의 대화 양이 챗봇의 성능을 판단하는 기준이 되는 것 같다. 얼마나 많은 대화가 잘 정리되어 등록되는 냐에 따라서 사람(?) 같이 대화하는 것 같다.

이상처럼 수집되는 정보들에 대한 정의 / 종류를 지정하는 부분이 Action and parameters이다.

수집해야 할 위치(location), 날짜(date), 시간(time), 체류기간(duration), 인원수(guests)에 대한 속성을 ENTITY로 지정한다. 

예로 인원수는 숫자(number)라고 지정하고,

3명과 같이 고객이 숫자를 입력하면 인원수를 입력한 것으로 처리한다.

해당 정보를 얻기 위해 챗봇이 해야할 질문은 PROMTS에 등록한다.

PROMTS를 클릭하면 다음과 같은 팝업창이 실행된다.

대화중에 3명이라고 이야기 한 경우에는 넘어가지만,

정보가 수집되지 않으면 "몇명이 묵을 겁니까?(How many people are attending)"라고 물어서 정보를 수집한다.

예약에 필요한 위치(location), 날짜(date), 시간(time), 체류기간(duration), 인원수(guests)를 수집했으면,

"방을 선택하세요(Choose a room please)"라고 응답하고(Resposes)

앞서 Context에서 output으로 지정한 [room.reservation - choose room] Intent로 넘어간다.

참고: 이상에서 PROMPT로 수집한 정보를 어떤 자료에서는 Intent로 만들어서 처리하기도 한다.

4. room.reservation - choose room

방 선택(room.reservation - choose room)은

그림처럼 room.reservation이 끝나면 실행되고(input context), 끝나면 확인 Intent(output context)가 실행된다.

학습 문장(Training phrases)에는 A, B, C만 등록되어 있다.

방 종류를 의미하고, 이외의 문장을 입력하면 방 선택을 하라고 한다.

방 종류(A, B, C)가 노란색으로 표시 되어 있고,

Action and parameters에도 @room만 노란색으로 활성화 되어 있다.

방 종류(A, B, C)는 @room 개체로 앞서서 Entity로 지정한 타입이라는 의미이다.

즉, 여기서는 방 종류에 대한 정보만 수집한다.

참고: room.reservation에서 Prompt로 처리한 것을 이렇게 Intent로 처리 할 수 있다.

방 종류를 선택하면 다음과 같이 수집한 정보를 채워서 고객에게 출력하고(Response)

다음 Intetnt로 넘어가 응답을 기다린다.

예약을 확인후 고객의 대답에 대한 처리는 정리하지 않는다.

이상과 같은 구조로 되어 있기 때문에 상세 내역을 확인하면 쉽게 이해 할 수 있을 것이다.

모두 고객의 예상되는 대답(Traning phrases)과 그것에 대한 챗봇의 대답(Response) 구조로 되어있다.

이 대화 속에 필요한 정보를 추출한다.

이상으로 챗봇 제작에 필요한 Entity와 Intent에 대해서 정리했다.

이 내용을 처음부터 하나 하나 생성하는 방법은

구글 Dialogflow 문서에서 [에이전트를 처음부터 빌드하기]를 따라하거나 다른 자료를 참고하면 된다.

이 문서는 만드는 방법이 아니라 전체 개념과 몇 가지 용어에 익숙해지기 위해 정리한 문서이다.

이 외에도 많은 예제가 제공되니 읽어보는 것이 도움이 될 것이다.

추가적으로 날짜를 yesterday(어제)를 입력해도 예약이 된다.

방 종류를 모르면 예약을 할 수 없다.

이외에도 많은 문제점이 있고,

이 문제점들은 프로그램과 연동이 필요한 것으로 Dialogflow만으로는 완벽한 챗봇을 만들 수 있는 것이 아니다.

챗봇을 만들기 위해 이제 첫 걸음을 내민 것이다.

회사에서 오픈 소스 검색엔진인 Lucene을 기반으로 하는 Elasticsearch 도입을 진행하면서,

이전에 조금 다루었던 Solr (Lucene을 기반으로 하는 또 다른 검색엔진)를 개인적으로 정리 하고 있다.

둘 다 조금 부족한 형태소 분석기 (정확하게는 사전)를 이용하는데,

부족한 부분을 채우기 위해 이것 저것 시도하면서 찾은 데이터들 중에서 다른 이들에게도 중요 할만한 데이터들을 공유한다. 

특히, 검색 엔진, 형태소 분석기 등의 프로그램에 대한 자료는 많이 공개되어 있어서 쉽게 구할 수 있는데, 

이들을 제대로 사용할 수 있게 하는 사전에 대한 자료가 부족한 것 같다 (못 찾아서?).

이하의 데이터들을 여러 가지로 적용해서 활용 방법을 정리할 계획으로, 언제 끝날지 알 수 없어 가치 있어 보이는 데이터 리스트부터 정리한다.

유사한 맥락에서 심심풀이로 진행하는 챗봇(Dialogflow와 Rivescript/ChatScript) 제작에 도움 될 것 같아서 찾은 한국어 대화 데이터를 구할 수 있는 정보도 공유한다.

한글형태소 사전(NIADic) 

• 국립 국어원에서 제공하는 데이터로, 약 100만건의 단어 사전 제공
• “중소기업, 연구자, 일반인 등이 쉽게 NIADic을 활용하여 텍스트 분석을 수행할 수 있도록 KoNLP의 기초 형태소 사전으로 추가하여 제공”한다고 하는데 자연어 처리쪽에서 많이 사용하고, 검색엔진에 적용된 것을 보지 못해서 방법을 찾고 있다 (정보가 있으신 분 공유를 부탁드립니다).
• 최소한 검색엔진에서 사용자 사전용으로 사용할 수 있을 것 같다.
• 빅데이터 사이트에서 직접 다운로드 받으면 된다.

유의어 사전

• 한국언론재단(빅카인즈)에서 정리하여 제공하는 시소러스 및 텍사노미 사전
• 2016년에 제작된 pdf 파일은 구글 검색으로 쉽게 구할 수 있지만, PDF 파일이라 활용하기 어렵고,
• 홈페이지 하단에 있는 이메일(bigkinds@kpf.or.kr)로 연락하면, 친절한 안내와 함께 2017년에 개정된 엑셀 파일을 받을 수 있다.
• 시소러스 사전은 조금 가공해서 유의어 사전으로 사용하고,
• 텍사노미 사전은 복합어 사전으로 유용할 것 같아서 가공해서 사용할 계획이다.

불용어 사전

• 검색엔진 설정(SEO)을 도와주는 업체에서 제공하는 사전으로
• 40여개 언어의 불용어가 정리되어 있으며, 약 700개의 한국어 불용어가 있다.
• 웹 페이지의 내용을 복사해서, 검색엔진 불용어 사전 파일에 그대로 붙여넣으면, 바로 사용 할 수 있다.
• Geitgey라는 사람이 개인적으로 작업하여 23개 언어, 70개 단어로 정리한 한국어 불용어 사전도 있다.
• 형태소 분석기에서 품사에 따라 불용어 처리 기능을 제공하지 않는 경우 유용하다.

한국어 대화 데이터

• 챗봇 개발에 유용한 데이터로 어떻게 활용할 것인지 검토 중인 데이터로, 대화 시나리오 구성 등에 참고용으로도 가치가 있어 보인다.
• "소상공인 및 공공민원 10개 분야에 대한 1만건 이상의 대화(Dialog) 데이터를 구축"했다고 하고 상세한 내용은 사이트를 참고하면 된다.
• 회원 가입하고 데이터 다운로드를 신청하면 되는데, 연구 목적 등을 적지 않으면 반려되고, 안내사항이 메일로 수신된다.
• 연구 목적이 아니라도 조금 상세한 이용 계획을 소속과 함께 적어서 신청하면 무난하게 데이터를 다운받을 수 있다.
• 이외에도 AI허브(aihub.or.kr)를 지향하는 사이트 답게 온갖 데이터가 제공된다.

기타 사전

금융기관용 사용자 사전 구축에 용이한 금융용어사전, 국방과학에 유용한 국방과학기술용어사전 등이 있다. 

특히 국방과학기술용어를 제공하는 사이트에서는 (왼쪽 트리형식의 메뉴에)

기타 사전으로 세종과학기술전문용어집, 항공기술용어집, 민간물류용어집 등 

다양한 산업에 사용할 수 있는 사전을 검색할 수 있고 엑셀로 다운 받을 수 있도록 되어 있다.

마지막으로, 위키에 정리된 비속어 사전도 나름 유용하다.

오픈소스 루씬(Lucene)을 기반으로 하는 대표적인 검색엔진인 Solr와 Elastic Search 중에서 

Elastic Search(이하 ES)가 더 폭넓게 사용되고, Solr는 다소(?) 위축된 것 같다.

이 사이트에 따르면 2012년 이후로 ES가 대세가 되었다고 한다.

온라인 서점에서 검색해 보면, ES 관련 서적은 매년 출판되어 2019년에도 몇 권이 출판되었다.
(Elastic Search, 엘라스틱서치, 일래스틱서치 등으로 검색)

Solr는 Solr 4 (최신 버전은 8) 버전이 2014년에 세 권 출판된 것이 전부다 (못 찾은 것일 수 있음).

하지만 일반적인 문서 검색은 Solr가 쉽게 구현할 수 있고, 웹 로그와 같은 소형 데이터는 ES가 좋다고 생각한다.

새로 이직한 회사에서 ES로 검색 서버를 구축하면서

외부 데이터를 검색 서버에 넣어주는(색인하는-Indexing) DIH (Data Import Handler) 관련 기술이 필요했다.

ElasticSearch는 Logtash를 이용해서 웹 로그나 메일 같은 외부 데이터를 쉽게 색인 할 수 있는데,

RDBMS의 Parent / Child 데이터를 처리하는 방법을 찾기 어려웠다.

게시판을 예로 들면, 게시글(Parent)과 댓글(Child)을 색인 하기 어려웠다. 

더욱이 첨부 파일이 있는 경우에는 게시글에 맞춰서 색인해야 하기 때문에 더 어려웠다.

방법을 찾던 중에 몇 년 전 교육 받은 Solr에서 쉽게 처리했던 기억이 났다.

같이 교육 받았던 직원이 며칠 만에 구현했다며 나에게 준 소스를 찾았다.

Solr에서는 쉬운 것이, ES에서는 자료를 첮지 못해 결국 색인 프로그램을 개발해야 했다.

찾은 자료를 정리하는 차원과 이 좋은 Solr도 많이 사용되길 바라면서 정리한다.

자세한 장단점은 이 사이트를(영어) 읽어보면 되고,

여기에서는 Solr를 쉽게 익히기 위해  Solr에서 제공하는 예제를 중심으로 정리한다.

Solr 예제는 Solr 사이트의 시작하기에 정리되어 있는데,

개인적으로 처음 시작하는 사람에게는 어려운 것 같아서 이 내용에 개인적인 해석을 넣어서 정리한다.

1. 설치
2. 기술제품과 검색식
3. 스키마(Schema)
4. DIH (Data Import Handler)

먼저 Solr 사이트에서 압축 파일을 다운 받아 압축을 풀어서 설치를 완료한다.

         http://lucene.apache.org/solr/downloads.html

이 글을 정리하는 시점에는 8.4.0버전이 최신 버전이고,

운영체제에 맞는 압축 파일(tgz/zip)을 받아서 사용하면 된다.

좀더 상세한 설명은 이전 블로그 글을 참고해도 되고, Solr 설치 매뉴얼을 참고 해도 된다.

압축 파일을 푼 다음,

다음 그림과 같이 콘솔 창에서 실행 파일이 있는 bin 폴더로 이동해서 

solr start를 입력해서 Solr를 실행한다.

경고 메시지는 일단 무시하고,

마지막의 “Started Solr server on port 8983.” 문장이 출력되면 

Solr 검색 엔진 서버가 잘 실행된 것이다.

웹 브라우저에서 8983포트로 접속해서 Solr 관리자가 잘 실행되는지 확인한다.

       http://localhost:8983

관리자 페이지에는 서버만 실행한 것이기 때문에 별다른 내용이 없다.

예제를 실행하면,

이 관리자 페이지에서 다양한 Solr 설정이나 기능을 확인할 수 있다.

예제에는 클라우드 예제를 먼저 정리하고 있는데, 여기에서는 클라우드 관련 내용은 정리하지 않는다.

서버나 네트워크 전문가가 아니라서 잘 모르는 것도 있고, 개인적으로 클라우드의 필요성을 잘 모르기 때문이다.

어느 정도 규모에 어떻게 적용할지를 모르면 낭비가 발생하고 (서버 규모 === 돈)

그냥 중소 규모의 기업에서 발생하는 데이터는 단독모드로 사용해도 된다고 생각한다.

더우기 검색 엔진을 잘 모르는데, 클라우드 등 다양한 개념이 시작하는 사람에게 도움이 되지 않는다고 생각하기 때문이다.

두 번째 예제인 기술상품(Index the Techproducts Data)부터 정리한다.

모든 예제는 설치 경로의 예제(example) 폴더에 있고, Solr 예제에서는 이 폴더의 내용을 지정해서 설치한다.

Solr 예제에 있는 방식으로 실행하면 오류가 발생한다.

데이터를 저장할 techproducts 코어를 생성하라는 설명 없이, 데이터를 저장하는 (post) 명령어만 설명되어 있다.

        solr create -c techproducts

따라서 콘솔에서 위와 같은 명령어를 실행해서 코어를 생성하고, 

Linux/Mac 일때는
        bin/post -c techproducts example/exampledocs/*

Windows는
        java -jar -Dc=techproducts -Dauto example\exampledocs\post.jar example\exampledocs\*

으로 실행하라고 한다.

여기에서 실행 경로는(example\exampledocs) Solr 설치 경로의 하위이지 bin 경로의 하위가 아니다.

각자 다르겠지만, 여기에서는 그림처럼 D:\dev\solr-8.4.0가 Solr 설치 경로이다.

앞서 코어를 생성한 것은 bin 폴더에서 실행한 것이니, 폴더 경로를 잘 맞추어 실행해야 한다.

Solr 설치 경로에서 작업할 경우에는 

        bin/solr create -c techproducts          <= Linux/Mac
        bin\solr create -c techproducts         <= Windows

처음에는 Solr 파일들을 보기 위해 bin에서 시작했고, 이후로는 편의를 위해 Solr 설치 경로를 기준으로 정리한다.

즉, solr start가 아닌 위와 같이 bin\solr start와 같이 정리한다.

그리고, 별도의 표시가 없으면 윈도우 기준으로 정리한 것이다.

코어를 생성하고, 데이터를 저장하는 (post) 명령어를 실행해면 뭔가 잘되는 것 같다가 오류가 발생한다.

example\exampledocs 폴더에는 XML 등 다양한 파일이 있는데, post.jar 등의 파일을 색인 할 수 없다는 오류 메시지가 출력된다.

명령어에서 모든 파일(example/exampledocs/*)을 색인 하라고 지정해서 발생한 것으로,

별도의 설정을 하면 되겠지만,

여기서는 빼고 example/exampledocs/*.xml로 수정해서 xml 파일만 색인 하도록 한다.

또는 example/exampledocs/*.json으로 바꿔서 한번 더 실행해도 된다.

문서에서 제시하는 방법으로 하지 말고, 다음과 같이 실행해도 된다.

먼저 실행 중 인 Solr가 있으면 다음 명령어로 중지한다.

            bin\solr stop –all

코어를 생성하지 않고 다음과 같이 예제를 실행하는 e 옵션으로 다시 실행한다.

           bin\solr start -e techproducts

기술 제품(techproducts) 예제를 실행하라는 명령어이다.

위 문장들을 읽어보면

techproducts 코어 (Created new core 'techproducts')를 생성하고

D:\dev\solr-8.4.0\example\exampledocs 폴더에 있는 XML 파일을 색인했다는 의미이다 (14 files indexed).

그리고, 마지막에 예제를 잘 실행했으니 관리자 페이지에서 결과를 확인하라고 출력한 것이다.

코어(core)는 색인한 데이터를 저장하는 장소로,

RDBMS로는 테이블, 엑셀로는 시트(sheet)와 비슷한 의미이다.

기술 제품을 저장할 코어(techproducts)를 생성하고, 14개의 XML 파일을 읽어서 이 저장소에 저장했다는 의미이다.

저장하다는 것을 검색 엔진에서는 색인 - Indexing 한다고 한다.

웹 브라우저로 관리자 페이지에 접속하면,

[Core Selector]에 생성한 techproducts 코어가 추가된 것을 확인할 수 있다.

이 코어를 선택하면,

다음 그림과 같이 하단에는 코어에서 사용할 수 있는 메뉴들이 나오고

우측에는 저장된 데이터 수(Num Docs), 저장된 데이터의 위치(data)등의 개요(Overview)가 출력된다.

기술 문서 데이터가 32건 저장된 것을 확인할 수 있다.

Replication(복제)은 데이터에 오류가 생겼을때 복구하기 위해 생성하는 것으로 기본 2개가 생성되어 있다.

복제도 클라우드와 마찬가지로 여기서 정리하지 않는다.

코어를 선택하고 "Query" 메뉴를 클릭하면 다양한 데이터 조회(질의-Query)를 할 수 있는 화면(중앙부분)이 나타난다.

중앙부분 하단에 있는 파란 색 버튼 - Execute Query를 클릭하면,

다음 그림과 같이 우측에 저장된 기술 제품 예제 데이터가 Json 형태로 출력된다.

중앙 부분이 검색식을 입력하는 부분이고, 우측 부분은 실행 결과 화면이다.

우측 실행 결과 화면의 상단에 있는 URL을 클릭하면 

웹 브라우저의 주소가 해당 URL로 바뀌면서 다음 그림과 같이 실행된다.

              http://localhost:8983/solr/techproducts/select?q=*%3A*

이 결과는 이전 페이지의 JSon 결과와 같은 것으로,

Solr 검색을 URL로 실행할 수 있다는 것을 의미한다 (RESTful).

즉, URL의 내용을 수정해서 다른 웹브라우저나 탭, 프로그램curl, wget, PostMan등에서 사용할 수 있다.

URL의 내용을 정리하면,

http://localhost:8983/solr은 Solr 검색 엔진 서버 주소이고

techproducts는 데이터를 저장하는 코어

select는 데이터 조회를 의미한다.

q는 Query, 즉 검색식을 의미하며 *:* (%3A = : )

콜론(:) 앞의 *는 모든 필드를, 뒤의 *는 모든 값을 의미하는 것으로 모든 데이터를 조회한다는 의미가 된다.

(뒤의 * 대신에 찾고자 하는 값을 지정해서 실행하면, 모든 필드에서 지정한 값을 찾는 검색이 된다.)

저장된 데이터가 32건이니 모든 데이터는 32건이 출력될 것 같지만 10개만 출력된다.

전체 데이터를 조회하는 경우에는 알아서 10개만 반환된다.

이 URL은 앞서의 Query 화면에서 (http://localhost:8983/solr/#/techproducts/query)

Execute Query 버튼을 클릭하면서 자동으로 생성된 것으로,

"Query" 메뉴는 검색식을 잘 모르는 초보자들이 검색 조건을 쉽게 만들어서 테스트 해 볼 수 있는 메뉴이다.

개발자들이 각 검색 조건에 값을 지정하고 실행하면, 즉시 실행 결과를 확인할 수 있고

Java와 같은 개발 언어에서 RESTful로 호출해서 사용할 수 있는 URL을 알려주는 것이다.

위 그림에서 동그라미로 표시된 q *:*를 보면

좌측의 q *:*이 조건식을 입력한 것이고

우측 상단의 url이 Query 페이지에서 자동으로 생성된 실행 명령어(URL - q *:*)이고

우측 중앙에 있는 responseHeader에

Solr가 실행한 결과를 반환하면서 무엇을 실행했는지(params, q *:*)가 표시되어 있다.

response에 numFound가 찾은 전체 개수이고, start가 몇번째 것 부터 가지고 온 것인지 표시한 것이다.

좌측의 검색 조건 입력부분에서 start 값을 변경하면 response의 값도 동일하게 바뀐다.

즉, 검색한 데이터 중 몇 번째 부터(start), 몇 개(rows) 를 가지고 오라고 지정하는 것이다.

페이징(Paging)처리를 위한 것이다.

docs 다음의 배열( [ ] )은 찾은 데이터의 필드 이름과 필드 값들이 Json 형태로 출력된다.

id, name, features, price, price_c 등의 필드 값이 출력된다.

검색 조건들을 지정하는 부분에는 q, start, rows외에도 fq(Filter Query), Sort(정렬),  fl (반환할 필드 리스트), df (default search field 기본 검색 필드), wt (writer type 결과 표시 방법 Json, XML등) 등의 설정을 지정해서 검색 할 수 있다.

보다 자세한 내용은 Solr 문서를 읽어보길 바라고 (값 넣고 실행해 보면 대충 파악 가능), 다른 블로그에 정리된 내용을 참고 해도 된다.

여기에서는 Solr 예제와 관련된 내용을 중심으로 하나씩 정리할 예정이다.