2. 룰 단위 테스트

 

먼저 사용자 입력문이 들어 오면 CS 내부에서 어떻게 전처리(pre-processing) 하는지부터 알아 보기로 하자.

 

①    :prepare 입력문

 

:prepare 명령어는 주어진 입력문을 챗봇이 어떻게 전처리 하는지 보여준다. 만약 이 전처리가 의도와 다르다면 룰매칭이 안되는 것은 당연하기 때문에, 룰매칭이 안되는 경우 전처리에서 잘못되고 있지는 않은 지 알아 봐야 한다. 사용법은 :prepare 명령어 뒤에 확인해 보려는 문장을 넣으면 되는데, 예를 들면,

 

A.     :prepare 내가 제일 잘 나가 들어 봤어요?[1]

 

이 결과는 아래의 <표> "prepare 명령을 실행한 결과 화면"에서 볼 수 있는데, ①번은 명령어이고 ②번은 전처리의 작업목록을 보여 주고 있다. 여기에서는 모두 7가지 전처리를 하고 있는데, 순서대로 각각의 의미를 정리해 보면 <표> "토큰 컨트롤의 종류와 의미"와 같다. 이 전처리 지시는 simplecontrol.top 파일의 세번째 줄인 $cs_token에 명시되어 있다. 이곳에서 지우거나 추가함으로써 전처리를 조정할 수 있다.

뒤이어서 전처리한 결과를 단계별로 보여 주고 있다. 최초 사용자의 입력문(Original User Input)에서부터 최종 룰 매칭에 보내기 직전의 단계(Actual Used Input)까지 차례로 제시하는데, 이 중 ƒ번의 결과가 중요하다. ƒ번은 CS가 맞춤법 교정을 하라는 지시에 따라 스스로 맞춤범 교정을 한 것인데 “들어”를 “당신”으로 바꿔 버렸다. 이는 CS가 한국어의 특성이나 어법을 모르는 상황에서 영어의 철자 교정 논리에 따라 임의로 한글 맞춤법 교정을 한 것이다.

이 오류는 심각한 문제가 되기 때문에, 장차 CS의 맞춤법 교정 방법을 한국어의 특성에 맞게 바로잡기 전까지는 DO_SPELLCHECK 지시자를 꺼 두어야 한다. simplecontrol.top 파일의 셋째줄에 있는 이 지시자를 삭제하면 된다.

마지막 …번이 유념해서 볼 사항이다. 띄어쓰기 한 복합명사 “내가 제일 잘 나가”를 하나의 단어로 인식하였다는 표시이다. 이는 이 문자열을 미리 등록해 놓았기 때문에 가능한 것으로, 띄어쓰기가 되어 있지만 한 단어의 고유명사로 처리하고 있다는 점을 확인할 수 있다.

이 전처리는 이 외에도 축약어, 사투리, 비속어 등을 표준어로 전환함으로써 룰매칭이 올바르게 되도록 하는 역할을 할 수 있다. 만약 챗봇의 개발자가 replace 명령어로 축약어나 비속어 등의 전환을 등록시켜 놓았다면 prepare 명령어를 이용하여 올바르게 처리되고 있는 지 확인해 볼 수 있다.

 

②    :testpattern (패턴) 입력문

 

패턴만 단독으로 테스트하는 명령어이다. 테스트할 패턴과 입력문을 차례로 써 주면 되는데 이때 테스트할 패턴에 라벨이 있다면 라벨로 써 주어도 된다.

예를 들어, 스크립트에

 

B.     u: ST1 ( <<~노래 좋아*>>) ^reuse(MyFavorite)

 

라는 룰이 있다면, testpattern을 다음 둘 중의 어느 하나로 써도 똑 같은 테스트 결과를 얻을 수 있다.

 

:testpattern ( <<~노래 좋아*>>) 좋아하는 노래 있어요?

:testpattern (ST1) 좋아하는 노래 있어요?

 

 

 

③    :verify pattern 또는 :verify ~topicname pattern

 

prepare명령어나 testpattern명령어로 룰을 하나씩 자세히 들여다 볼 수도 있지만 토픽이나 파일 전체에 대해 한 번에 패턴매칭 여부를 테스트할 수도 있다. verify pattern명령어가 그것인데 다만 이를 위해서는 스크립트를 작성할 때 예제 입력문을 작성해 두었어야 한다. 즉 룰을 작성하면서 그 룰이 어떤 입력문에 대응하도록 고안된 것인지를 예제 입력문으로 작성해 놓았다면 verify명령어로 룰매칭 여부를 쉽게 테스트할 수 있다.

아래의 예는 ":verify ~kpop pattern" 명령을 수행한 결과 화면인데 매칭에 실패한 패턴이 하나 있다(Pattern failed to match 1)는 경고문과 함께 해당 룰과 예제 입력문을 함께 보여 주고 있다.

위의 예제는 설명을 위해 작성한 예제로, 패턴에는 ‘씨엘’과 ‘영화’라는 두 단어가 있는데 반해 입력문에는 ‘씨엘’과 ‘영화’ 사이에 ‘함께’라는 단어가 있기 때문에 매칭에 실패한 것이다. 따라서 패턴을 다음 둘 중 하나로 수정해 주면 Pattern failed 경고는 없어질 것이다.

 

u: (~씨엘 *~1 영화*)

u: (<<~씨엘 영화*>>)

 

예제 입력문을 입력할 때 패턴에 변수가 있다면 예제 입력문에도 동일한 변수를 포함시켜 작성하면 되고, 하나의 패턴 위에 여러 개의 예제 입력문을 작성해도 된다. 중요한 것은, 그 패턴이 매칭하려고 하는 사용자 입력문의 예제를 잊지 말고 작성하는 습관을 가져야 한다는 점이다.

 

④    :verify ~topicname blocking

 

각각의 룰 별로 단위 테스트를 끝낸 후에는 룰의 순서가 올바르게 배치되어 있는지, 즉 블로킹 당하고 있는 룰이 없는지 점검을 한다[2].

예를 들어 룰이 다음과 같은 순서로 작성되어 있다고 하고 blocking 여부를 조사하면,

 

?: (~음악) 예. 음악 좋아해요.

?: ( <<~투애니원 ~음악 좋아*>> )

위의 결과 화면에서 보다시피 7번 룰이 12번 룰을 블록킹 하고 있다는 경고를 볼 수 있다. 이 이야기는 사용자가 "좋아하는 투애니원 음악이 있어요?"라고 입력했을 때, (<<투애니원 ~음악 좋아*>>)라는 룰과 매칭되기 전에 (~음악)이라는 룰과 매칭이 된다는 의미이다. 즉 의도했던 룰이 다른 룰에 의해 차단되고 있다는 뜻인데, 이는 넓은 범위를 포괄하는 룰이 앞에 배치될 경우 나타나는 현상이다. 따라서 룰의 배치를 바꾸면 위의 '블록킹 현상'은 해결될 수 있다.

---

[1] MS-Windows 환경의 콘솔에서는 한글을 UTF-8 형식으로 입력할 수가 없다. 그래서 6장 (2)절에서 설명한 것처럼 :source 명령어를 이용하거나, 브라우저 메시지창에서 명령어를 입력하여야 한다. 브라우저에서 명령어를 입력하면 화면을 보기가 어려우니 :source명령어를 이용하는 것이 좀 더 낫다.

[2] 블로킹의 개념 및 예제와 해결책은 5장 (7)절을 참조