라즈베리파이로 NUGU 스피커 프로젝트 해 본 이야기 #2

이번 포스팅에선 NUGU Play를 작성하는 이야기를 해보겠다. NUGU Play Builder는 NUGU Play를 만드는 일종의 툴인데 컴퓨터 프로그래밍에 익숙하지 않아도 간단하게 제작할 수 있도록 만든 점이 특징이다. 간단히 대답하는 수준의 Play는 쉽게 제작할 수 있지만 필자처럼 백앤드의 활용이 필요하다면 어쩔 수 없이 서버 프로그래밍을 어느 정도 할 줄 알아야 한다.

 

NUGU Play Builder 화면. 프로그래밍 지식 없이도 간단한 대화를 만들 수 있다.

 

NUGU developers 소개

위 링크는 Play Builder의 가이드이다. 설명을 정말 잘 해두었으니 적극적으로 참고해도 좋다. 필자는 이 프로젝트에선 어떻게 설계했고 어떤 고민을 했는지를 위주로 써보도록 하겠다.

 

---

 

NUGU Play의 작동방식은 Play 호출어를 인식, intent와 entity 인식 후 action 실행, 필요할 경우 추가 명령 실행으로 이루어진다. 여기서 "Play 호출 이름이 따로 있어야하나? 아리아라고 부르면 되지 않는가?"라고 할 수 있는데, 아니다. 실제로 필자도 헷갈렸던 부분인데 Play의 이름을 지정하면 NUGU Play에서는 해당 Play를 실행하겠다는 명령을 해주어야 한다. '누구사진'으로 호출 이름을 설정한 우리 프로젝트를 예로 들면, "아리아, 누구사진 실행해줘.", 혹은 "아리아, 누구사진으로 고양이 사진 찾아줘." 라고 Play 호출 이름을 말해야 한다. 그런데 이를 설정하는 과정은 모든 개발을 마치고 마지막에 등록하는 과정에서 지정해주므로 개발하면서 천천히 생각해봐도 되는 부분이다.

 

등록 때 설정하는 모습. 테스트로만 돌려보고 배포는 하지 않았어서 해당 play는 여러분이 시도해도 못 쓸 것이다.

 

Play 서비스명과 Play 호출 이름이 다른 것을 의아해 할 수 있는데, 테스트 해 본 결과 '누갤러'는 호출 이름으로써 인식하지 못했다. 필자의 생각이건데, NUGU 스피커는 음성 인식을 할 때 탑재된 사전에 있는 단어로만 인식하지 않을까 한다. 이 부분에 대해선 skt 개발자이신 심사위원님께서 말씀하시길 곧 한 글자씩 독립적으로 인식하는 음성인식을 지원할 것이라 하셨다.

 

---

 

Intent와 Entity를 설정하는 부분에선 우리 팀이 설계한 모든 명령어와 단어를 NUGU Play에 입력해두어야 했다. 그런데 우리가 설계한 Play는 Entity를 통해 태그를 검색해야했고 수많은 단어들에 대한 정보를 모두 입력해야했다...!

 

012

좌측부터 Intent 입력, Intent 세부 정보 입력, Entity 입력 화면. 정말 별 걸 다 적었다. 다른 팀원들이 많이 도와줬다.

 

사진에서 봤듯이 정말 동의어까지 다 입력했다. 근데 따지고 보면 Google Vision API가 영어 단어로 labeling을 진행하기 때문에 한글로 입력 받는 우리의 프로젝트의 경우 영어 단어로 인식 하게끔 Entity를 입력해 줄 필요가 있었다.

 

여담으로 skt 측 심사위원님께서 우리가 했던 것과 유사한 프로젝트를를 생각해보셨다고 했다. 그 분들처럼 실력있는 개발자님들이 한글로 이루어지는 이미지 분석 api를 개발한다면 이러한 서비스 개발도 훨씬 수월했을 것이다. 그러나 과연 NUGU 스피커로 사진 찾는 행위를 할까에 대한 의문 때문에 개발단계까지는 가지 못한 것 같다. 우리 팀도 이에 대한 마땅한 답을 찾은 것은 아니었지만 실제로 개발하고 구현해냈다는 것에서 큰 점수를 받았다.

 

---

 

012

죄측부터 action 목록, action 세부 설정과 action 발화 설정 화면(두번째와 같은 페이지)

 

action은 설정해준 intent와 연결하여 명령을 인식했을 때 실질적으로 수행되는 동작을 설정한다. 여기서 동작이라 함은 실제로 사진을 찾아주는 등의 동작이 아닌 백엔드로 해당하는 데이터를 전송하는 동작을 의미한다. 백엔드로 보내는 parameter를 두번째 사진처럼 설정하여 보내면 되는데 이는 이전에 설정한 Entity에서 지정해 준 데이터가 된다. 이것이 어떻게 전달되고 어떠한 형식으로 전달되는 지는 누구 개발자 문서에도 자세히 써 있어 참고하면 좋다. 또한 다음 글에서 이에 대해 다룰 것이다.

 

action의 종류는 response만을 지정하여 발화문 재생 후 곧바로 끝내는 것과 branch action을 별도로 지정하여 다른 액션을 연달아 실행하는 것이 있다. 이번 프로젝트를 예로 들자면 find_photo 액션이 전자에 속하고 create_album 액션이 후자에 속했다. find_photo 액션의 경우 사진을 찾는 액션으로, 찾아준다고 발화 후 해당 액션은 종료하면 되는 반면, create_album 액션은  앨범 생성을 해주는 액션이었기에 앨범을 생성해 준다고 발화 후 어떤 이름의 앨범을 만들 것인지 되물어야 했기 때문이다.

 

여담으로 필자는 발화문에도 실제로 서비스를 운영한다 생각하고 고민했다. 이전 글에서 기술했듯이 라즈베리파이의 처리 속도는 상용 클라우드 서버보다는 느릴 수 밖에 없는데 이것이 문제였다. 원래 설계했던 발화문에는 사진을 찾은 후, 총 몇 장이 검색되었는 지까지 알려주려 했었다. 그런데 사진을 검색하고, 검색 결과 테이블을 비우고, 검색 결과를 테이블에 다시 채우고, 총 몇 장인지 계산하는 것을 NUGU 스피커는 기다려주지 않았고, 똑같은 액션을 추가로 보내어 액션과 서버가 꼬이는 상황이 되었다. 결국 세번째 사진처럼 라즈베리파이에서는 무조건 응답을 보내어 "열심히 찾아보고 있어요. 찾으면 스마트폰으로 알려드릴게요!"를 발화하는 것으로 설계를 변경했고, 결과적으로 이 판단은 한 심사위원 분에게 "발화문을 고민한 느낌이 난다"며 칭찬을 받게 된다.

 

---

 

01

Play 빌드와 Play 관리 탭 위치. 거의 다 했다.

개발을 마쳤다면 등록하면 되는데, 그 전에 본인이 갖고 있는 NUGU 스피커를 테스트 기기로 지정해 줄 필요가 있다. 그런 후 Play를 빌드하고 Play Builder로 들어갔던 페이지에서 관리 탭에 들어가 Play 등록을 진행해주면 된다. 그러면 다른 사람들은 해당 Play를 사용하지 못하지만 테스트 기기로 지정해준 NUGU 스피커가 같은 skt 계정으로 연결되어 있다면 해당 스피커로만 테스트 할 수 있다.

 

우리 프로젝트는 사실 Play 제작에서는 큰 어려움이 따르지 않았다. 그러나 앱과 NUGU 스피커의 정보를 모두 받아 처리해야 했던 서버 코드는 꽤 복잡했다. 내가 작성한 코드는 사실 보여주기엔 수준이 부족한 코드일 수 있다. 구동만을 생각했기에 가독성이 많이 떨어질 수 있기 때문이다. 그러나 부족한 수준이더라도 다음 글에선 내 코드를 중심으로 어떻게 서버를 구동시켰는 지에 대해 기술하도록 하겠다.

 

#그리고 스크린샷 품질에 관해 양해를 구한다. PC를 사용할 수 없어 폰으로 작성하고 있음을 이해해주길 바란다.