3. 대본의 논리적 구조

대본은 토픽으로 구성되고 토픽은 룰로 구성된다. 최종 단위인 룰을 올바르게 작성하는 것이 중요하지만 그 룰을 담는 그릇으로서 토픽도 논리적으로 구성되어야 한다. 토픽의 논리적 구성을 머리 속에 담고 있어야 필요한 룰을 빠뜨리지 않고 포함시킬 수 있기 때문이다. 이번 절에서는 챗봇을 개발할 때 염두에 두어야 할 토픽의 논리적 구조에 대해 설명하기로 하겠다[1]. 토픽은 유형별로 Story topic, Reactor topic, Quibble topic으로 대별할 수 있는데 그 중 가장 중요한 Story topic부터 살펴 보기로 한다.

 

①    Story topic의 구조는 3단 구성

가.   말걸기 : 대화를 시작하기 위해 사용자에게 던지는 질문. 화제에 대한 간략한 소개를 포함할 수도 있으며 이 질문하기가 많을수록 대화를 오래 이어나갈 수 있다.

나.   그 질문에 대한 봇의 대답 : 위 ‘가’의 질문을 사용자가 똑 같이 했다고 가정했을 때 챗봇의 답변

다.   말걸기의 질문을 사용자가 먼저 하는 경우 : 의미 상으로 ‘나’보다 앞에 기술해야 하지만 코드의 중복과 룰의 반복을 피하기 위해 맨 마지막에 작성

  

이제 아래의 예를 보면서 3단 구조를 확인하기로 하자.

룰A는 챗봇에게 대화의 통제권이 왔을 때 사용자에게 던질 질문으로 준비한 것이다. 이때  룰B와 룰C를 세트로 작성하는 것을 강력히 추천한다. 대화는 서로에게 비슷한 질문을 하는 것이 상례이기 때문이다. 내 휴가 계획을 말한 후에는 상대방의 휴가 계획을 듣고 싶고, 상대방이 감명깊게 본 영화를 얘기해 주면 나도 비슷한 경험을 얘기하는 것이 대화의 기본이기 때문이다. 따라서 챗봇의 대본을 작성할 때는 위와 같은 3단 구조를 먼저 작성한 후 각각에 살을 붙여 나가는 식으로 진행하면 룰을 누락하는 경우를 최소화 할 수 있을 것이다.

 

위의 3단 구성에서 특히 1단은 아래와 같이 좀 더 세부구조를 갖는다.

 

Story topic의 완성된 모습은 위와 같은데, 이를 작성하는 과정은 다음과 같이 먼저 질문을 하고 그 질문에 대한 챗봇의 답을 작성하고, 다시 질문을 하고 그 질문에 대한 챗봇의 답을 적고 하는 순서로 적어 나간 후 나중에 소팅을 하는 것이 효율적이다.

 

Topic: ~KPOP [ ~투애니원 ~티아라 ~맘마무 ~노래 ]

t: K-POP 좋아하세요?

t: 저는 K-POP을 좋아해요

t: 좋아하는 가수가 있어요?

t: 저는 투애니원을 좋아해요

t: 즐겨듣는 노래가 있어요?

t: 저는 I love you를 자주 들어요.

 

이때 소팅 순서는 이야기의 흐름에 맞도록 먼저 말할 내용을 앞쪽에 배치한다. 맨 위에서부터 차례로 사용자에게 전달될 것이기 때문에 이야기의 전개 순서에 맞춰 앞에서부터 배치해 나간다. 이 과정에서 Topic의 키워드 목록과 비교해 가며 키워드를 추가로 보완한다. 또한 어휘, 문장, 문체 등이 앞서 작성하였던 챗봇의 신상명세나 자기소개서 등과 부합하는지도 확인한다. 어느 정도 뼈대가 완성되면 이제는 내가 한 질문을 사용자가 질문하는 것으로 가정하고 응답 규칙을 작성한다.

 

Topic: ~KPOP [ ~투애니원 ~티아라 ~맘마무 ~노래 ]

t: 혹시 K-POP 좋아하세요?

t: 저는 K-POP을 좋아해요

t: 좋아하는 가수가 있어요?

t: 저는 투애니원을 좋아해요

t: 즐겨듣는 노래가 있어요?

t: 저는 I love you를 자주 들어요.

 

?: (K-POP 좋아하세요)

?: (좋아하는 가수가 있어요)

?: (즐겨듣는 노래가 있어요)

 

이렇게 3단 구조를 갖춘 후 이제 각각 세부 내용을 다듬는다.

 

Topic: ~KPOP [ ~투애니원 ~티아라 ~맘마무 ~노래 ]

t: 혹시 K-POP 좋아하세요?

A: 왜 물으세요?

A: 예

A: 아니요

t: FaveKPOP ()저는 K-POP을 좋아해요

t: 좋아하는 가수가 있어요?

왜요? 예, 아니요 등의 예상응답 작성

t: FaveSinger ()저는 투애니원을 좋아해요

t: 즐겨듣는 노래가 있어요?

      왜요? 예, 아니요 등의 예상응답문

t: FaveSong ()저는 I love you를 자주 들어요.

 

?: (K-POP 좋아하세요) reuse(FaveKPOP)

?: (좋아하는 가수가 있어요) reuse(FaveSinger)

?: (즐겨듣는 노래가 있어요) reuse(FaveSong)

 

    이때 응답(responder) 규칙을 배치하는 순서는 구체적이고 세세한 규칙을 먼저 적고 일반적이고 넓은 범위를 포괄하는 규칙은 뒤에 배치해야 한다. 예를 들면

 

u: (투애니원 음악 좋아하세요?)

u: (K-POP 좋아하세요)

u: (음악 좋아하세요)

 

의 순서로 적어야 올바르게 매치될 수 있다. 만약 반대 순서로 적으면 블로킹이 될 수 있는데 이에 대해서는 이 장의 (5)절에서 설명하기로 한다.

 

②    Reactor topic

대화를 나누다 보면 음악, 영화, 애완동물, 연예인, 음식, 여행, 스포츠 등 상대방의 선호, 소유, 경험 등이 화제에 오르게 되는데, 이때 적절한 반응을 할 수 있도록 초점 맞춰 작성하는 토픽이 reactor topic이다. 예를 들어 영화배우에 대해 대화를 나눈다고 가정해 보자. 영화배우는 무척 많고(아마 톱스타만 꼽아도 수 백명 될 것이다.) 사용자가 이 중에 누구를 언급할 지 알 수 없으므로 가능한 많은 영화배우에 대해 준비해 두어야 하는데 이럴 때 reactor토픽을 사용하는 것이다. 예를 들면 영화 배우의 이름과 각각에 대한 적합한 멘트를 담은 ~movie_react topic을 작성할 수 있다. 나중에 영화를 주제로 대화를 나누다가 챗봇이 영화배우 이름과 함께 ~movie_react 토픽을 호출해서 만약 그 영화배우에 대한 멘트가 있다면 그 영화배우에 맞는 특별한 언급이 출력될 것이고 만약 없다면 일반적인 멘트, 예를 들면 “그 배우는 훌륭한 배우이지요” 또는 “최근 작이 무엇이지요?” 등을 내 보내게 될 것이다. 대화를 하는 상대방 입장에서는 일반적인 멘트보다는 딱 맞춘 멘트를 들었을 때 “말이 통한다”고 느낄 수 있을 것이기 때문에 CS에는 맞장구를 효율적으로 작성할 수 있는 reactor topic이라는 장치를 만들어 놓은 것이다. reactor topic을 사용하지 않아도 상관없으나 reactor topic을 사용하지 않을 경우 수 많은 영화배우에 관한 멘트를 본문에 일일이 작성하게 되어 줄거리를 파악하는데 방해가 될 수 있고, 다른 곳에서 재사용할 수 없게 되므로 reactor topic으로 모듈화해서 작성하는 것이다.

 

Reactor topic의 구조는 다음과 같다

l  우연히 호출되는 일이 없도록 키워드를 할당하지 않는다

l  다른 토픽에서 respond함수를 이용하여 호출하여 사용한다

l  가능한 선택지를 모두 나열한다.

l  보통 한 줄 정도 길이의 응답으로 구성한다

l  NOSTAY로 선언하여 출력이 끝난 후 컨트롤을 호출한 토픽에 되돌려 준다.

 

예제를 보면서 위의 구조를 다시 한 번 확인하기로 하자.

 

#! 애완동물 키우기.

s: (~동물 * ~키우기) ^respond[2](~pet_react)

 

그리고 ~pet_react topic은 다음과 같이 작성되어 있을 것이다.

topic: ~pet_react nostay[ ]

#! 앵무새

u: ( ~새) 새는 기르기가 쉽지요. 저는 십자매를 키우고 있어요.

#! 뱀

u: ([ 뱀 도마뱀 악어 ] ) 도마뱀을 키우는 친구가 있어요. 근데 파충류는 좀 무서워요.

#! ant

u: (~곤충) 곤충은 시끄럽지도 않고 공간도 별로 차지 하지 않고. 기르기 좋죠.

…… (이곳에 훨씬 많은 사례를 쭉 열거할 수 있다)

 

위의 예에서 ~pet_react 토픽이 reactor topic인데, 특징을 보면 키워드 목록이 없고 nostay로 선언되었으며 응답(respond)만 가지고 있는 점을 확인할 수 있다. 수 십 개 이상의 예상 가능한 응답이 상관관계나 위계관계 없이 동등한 수준에서 나열되어 있다. 예상응답의 수가 풍부하게 준비되어 있을수록 사용자의 어떤 반응이라도 캐치해 낼 수 있을 것이고 “이런 것까지 알아 듣네”하는 느낌을 줄 수 있을 것이다. rector토픽을 사용하면, 스크립트의 줄거리를 읽는데 방해 받지 않으면서도 디테일한 답변을 작성할 수 있는 장점이 있다.

 

③    Quibble topic

사용자 입력문과 매칭되는 규칙이 없을 때 CS는 퀴블 토픽을 검토하게 된다. 퀴블 토픽이란 사용자 입력문의 한 두 단어에만 매칭되도록 작성한 룰들을 모아 놓은 토픽이다. 따라서 출력문은 모호한 답변이 될 수 밖에 없다. 사용자 입력문을 명확하게 파악하지 못한 상태이기 때문이다. 이에 따라 듣는 사람 입장에서는 챗봇이 얼버무리고 있다고 느끼게 된다. 그렇지만, 매칭되는 규칙이 없을 때는 사용자가 한 말의 한 두 단어와 만이라도 일치하는 규칙을 준비해서 모호하게라도 답변하고 다른 화제로 전환을 유도하는 것이 필요하다.

 

Quibble topic의 구조는 다음과 같다

 

l  우연히 호출되는 일이 없도록 키워드를 할당하지 않는다

l  다른 토픽으로부터 호출되어 사용된다

l  응답으로 구성되어 있다

l  출력문은 2개 이상의 다중으로 작성하는 것도 좋다 ([ ]을 이용)

l  매칭되는 룰이 없을 때 사용되는 룰이므로 사용자 입력문 중 한 두 단어라도 매치되도록 넓은 영역의 단어를 사용하여 작성한다. (예를 들면 누구, 어디서, 언제, 어떻게 등등)

 

얼버무림 토픽의 대표적인 예는 다음과 같다.

 

topic: ~quibblewho system []

?: (~누가 ~알다) [아는 사람 없을 것 같은데요…] [글쎄요…, 저는 모르겠어요]

?: (~누구 ~하다) [아무도 못 할 겁니다.] [누가 감히 해 보겠어요]

 

    앞서의 반응전용 토픽과 차이점은 패턴에 있다. 반응전용 토픽은 패턴에 애완동물, 영화배우, 작곡가 등 특정 영역의 구체적인 단어가 포함되는데 비해 얼버무림 토픽은 패턴에 대명사나 의문사, 기본동사 등을 포함시켜 넓은 영역과 매칭되도록 한다는 점이다.

  

---

[1] 토픽의 기본 개념에 대해서는 2장 (3)절을 참조

[2] ^respond 함수는 인수로 넘겨진 토픽을 호출하여 그 토픽에 소속된 규칙이 사용자 입력문과 일치하는 지 조사하는 함수이다. 일치하는 규칙이 있으면 그 규칙을 실행한다.