JSConf JP 2019 참석기 DAY2

Build and scale multiple voice application by using Typescript

일반적으로 인공지능 비서와 연동하는 앱을 만드는 것이 그리 복잡하지는 않다. 사용자의 발화를 텍스트로 변환하거나 반대로 텍스트를 음성으로 변환하는 것은 서비스의 몫이며, 개발하는 측에서는 대화나 단어에 대한 반응을 넣는 것 만으로도 충분히 앱을 만들 수 있다.

Webhook을 사용하는 것과도 비슷한데, POST로 날아온 JSON 데이터를 처리한 후 다시 JSON으로 돌려보내는 작업이라는 공통점이 있다. 기본적으로는 하나의 대화에 하나의 웹훅 실행이기 때문에 stateless한 작업으로도 볼 수 있다. 그러나 좀 더 복잡하게 만들려면 과거 대화나 문맥 등이 포함되기 때문에 DB가 필요한 경우가 생기기도 한다.

아마존에서 개발하는 Alexa에서 실행할 수 있는 앱을 스킬이라고 부른다. 기본적으로는 스마트 홈 스킬, 플래시 뉴스(맞춤형 기사) 스킬, 비디오 스킬, 음악 스킬 등이 있으며 외부에서 만들어지는 게임, 음식 배달 등은 커스텀 스킬로 취급된다.

스킬 개발에는 보통 AWS를 사용하는데, AWS Lambda 또는 HTTPS API를 사용할 것인지 지정할 수 있으며, node.js로 개발할 때는 주로 AWS Lambda를 사용하는 경우가 많다고 한다.

javascript계열에서는 개발할 때 ask-sdk 라이브러리를 사용해야 한다. typescript 사용자를 위한 ask-sdk-model을 사용하면 IDE에서 request 타입 정보를 제공 받을 수 있다.

Handler 코드를 작성할 때는 canHandle 함수에서 사용하는 명령어가 맞는지 확인 한 후, handle 함수에서 실제로 요청에 대해 처리해야 한다.

// Skill에 대한 Handler의 구조
export const Handler = {
    canHandle: () => {
      // 처리해야할 리퀘스트인지 판단
        return isHandleType;
    },
    handle: () => {
     // 리퀘스트와 Alexa의 응답에 대한 처리

            return skillBuilders
                .speak('안녕하세요')
                .reprompt('안녕하세요')
                .getResponse();
    }
}

이런 알렉사 앱 개발자 사이에서는 하나의 스킬에 여러 기능을 넣을 것인가, 하나의 기능을 가진 여러 스킬을 배포할 것인가에 대해 논의가 이루어지고 있다고 하였다.

다기능 스킬은 최초에 어떤 기능을 사용할 것이냐는 대화가 필요하므로 짧은 대화로 사용자의 목적을 달성하기 힘들어진다. 반면 스킬명과 기능명을 동일시 한 단기능 스킬의 경우 이런 문제는 없지만 코드의 반복사용이 심해지고 사용자가 내 스킬을 찾기 힘들어진다는 단점이 있다.

발표자는 50가지 정도의 스킬을 공개하고 관리 중인 경험에 의거하여 이에 따른 고충과 자신이 해결한 방법을 소개하였다.

1. 인프라가 스킬 수에 비례해서 함께 늘어난다 - 런타임 갱신 등 관리 코스트가 늘어간다
   • IaC(Infrastructure as Code)방식을 적용하여 인프라를 한 곳에서 한 번에 관리하도록 하여 수정이나 추가 시에 실수가 없도록 한다
2. 비슷한 처리의 반복 - 한 스킬에서 수정한 것을 다른 스킬에서 수동으로 일일히 적용해주어야 한다
   • ask-sdk는 말 그대로 기본적인 공통 기능만 가지고 있으므로, 스스로 범용 함수를 만드는 것이 중요하다
   • 또한 ask-sdk 자체가 계속 발전 중이므로 필요한 함수가 있다면 PR을 해보는것도 좋다
3. 비슷한 기능을 가진 단기능 스킬을 만들었을 때 반복이 너무 많다
   • 애플리케이션 그 자체를 재이용 한다
   • RequestHandler / SkillBuilders / Lambda를 애플리케이션끼리 공유할 수 있다

WEB의 자체무게

Web의 무게에 대해 논하기 위해서는 Web의 정의에 대해 알아보아야 한다. Web은 어떤 것을 할 수 있고, 무엇을 하기 위한 것일까? 사실 WHATWG나 RFC 등에서도 Web 스펙에 대한 정의나 제한이 분명하게 다루어진 적은 없다고 한다.

따라서 Web에 기능을 추가할 때 중요한 것은 "Web에 필요한가/필요하지 않은가"(애시당초 불분명한 부분)이 아니라, "현재 Web 상에서 올바르게 설계할 수 있는가"이다. 기능이 Web 호환성에 어긋나지 않는지, 보안 이슈는 없는지 등을 살펴봐야 하며, 모질라에서는 mozilla specification positions에서 기능에 대하여 평가하고 있다.

결론적으로 Web은 어떤 기술이나 스펙으로 정의할 수 있는것이 아닌, 사용자의 수많은 UseCase의 집합이라고 할 수 있다.

이와 관련하여 최근 브라우저의 다양성이 줄어가는 것에 대한 우려 또한 생기고 있다. UseCase라고 하는 것은 시간이 지날수록 많아질 수 밖에 없으며 사용자의 추가 스펙 요구도 함께 늘어나게 된다. 그렇게 계속 스펙이 추가되다가 웹 자체가 너무 무거워지면 어떤 브라우저는 나가 떨어지게 되고, 결국 부담은 고스란히 남은 브라우저에게 넘어가게 된다. 그렇다면 신규 브라우저의 진입장벽은 늘어날 수 밖에 없다.

그러면 Web 무게를 줄이기 위해서는 어떻게 해야할까? 1차원적으로는 Web은 UseCase의 집합이므로 이걸 줄여야한다고 생각할 수 있다. 그러나 이 것을 정하는 기준은 사람마다 너무 다르고 막연하므로 현재 상황에서는 고르기 어려운 선택지이다. 현실적으로 가능한 방법은 브라우저의 스펙 자체를 낮은 레이어 단계로 줄여 브라우저의 부담을 앱으로 옮기는 것이다. 예를 들면 Style에 대한 스펙을 이것저것 규정하지 말고 Canvas를 사용하게 해서 개발자에게 권한을 넘기면 웹의 부담은 많이 줄어들 것이다.

물론 이런 식으로 모든 스펙을 줄여버리고 개발자에게 일임해버리면 개발자의 책임이 너무 커지게 되므로 어느정도의 기본적인 기능과 API는 브라우저에서 가지고 있어야 한다.

애초에 현재 Web에 존재하는 스택으로 모든 UseCase를 만족시킬 수 있냐는 의문 또한 있다. 발표자가 말하길, 답은 동작은 하지만 최적은 아니라는 것이었습니다. 극단적인 예로는 게임에 대한 UseCase가 있는데, 현재도 그래픽을 DOM으로 나타내기는 부적절해서 Canvas로 만드는 것이 일반적이다. 더 깊게 파고 들면 디바이스나 OS까지 내려가서 연결한 컨트롤러로부터 입력을 받는 부분도 필요한데, 이런 부분에 대해서 Web에서는 레이어에 안전하게 접근하는 방법을 마련할 필요가 있다.

이렇게 안정성과 호환성을 고려하면서 계속 낮은 레이어의 스택을 유지해야 사용자들이 원하는 UseCase를 만족시키면서도 Web이 자신의 무게로 인해 무너지지 않을 수 있을 것이다.

최신 웹 기술로 IOT 개발하기

IoT를 시작하는 법

IoT가 실생활에 보급되고는 있지만 직접 만들기에는 시작할 엄두는 잘 나지 않는다. 준비해야 할 것도 많아보이고 알아야 할 것도 많아보인다. 그러므로 일단 단순하게 IoT가 무엇인지 부터 생각해보자. 세션에서는 IoT를 그저 "인터넷"과 "사물"의 연결이라고 정의하였다.

여기서 인터넷에 해당하는 것은 친숙하며 우리가 언제든지 준비할 수 있는 것들이 많다. 반대로 사물에 해당하는 센서, 모터 등은 완제품이 아니면 보기조차 힘든 물건들이고, 어렵게 느껴지기 마련이다. 그래서 하드웨어가 익숙하지 않은 대부분의 개발자는 여기에서 막히고 만다.

그런데 사실 아주 밀접한 곳에 "사물"로 사용할 수 있는 물건이 있다. 바로 스마트폰이다. 인터넷으로 연결이 되고 각종 센서가 있다는 점에서 충분히 IoT 사물의 조건을 만족한다. 그러므로 간단하게 IoT를 시도해보고 싶다면 먼저 스마트폰 앱으로 시작해보는 것이 좋다.

다만 스마트폰으로 본격적인 IoT를 만들기는 어렵다. 첫째로 스마트폰을 오로지 사물로 쓰기에는 너무 고가라는 점, 둘째로 지나치게 고사양인 디스플레이 등 필요없는 기능이 너무 많다는 점, 셋째로는 반대로 물리적인 움직임이나 온도 계측 센서 등 필요한 센서가 다 있지 않다는 점도 걸림돌이다.

결국 제대로 IoT를 만들고 싶다면 커스텀 하드웨어를 만들어야 한다. 하드웨어는 몇가지 부품을 조립하면 만들 수 있는 간단한 조립 컴퓨터라고 생각하면 쉽다. 부품은 크게 4가지로 구분할 수 있다.

가장 신중하게 선택해야 하는 것은 CPU이다. CPU에 따라서 프로그램이 돌아가는 환경과 사용할 수 있는 언어가 달라지기 때문에 만들어지는 결과물이 달라지게 된다. CPU를 결정하면 나머지 부품은 필요에 따라 추가하거나 변경해주면 된다.

Javascript로 IoT를 만들 떄의 선택

IoT에서 사용하는 CPU는 보통 C언어를 지원하는 것이 많다. Javascript를 지원하는 CPU는 적은데다가, 파워가 많이 필요하기 때문에 가격또한 비싸진다.

세션에서는 그 중에서도 javascript를 지원하는 적당한 두 가지 CPU를 소개하였다.

• ESP32
  • CPU 위에서 Javascript가 돌아감
  • javascript를 바이너리로 컴파일하고 usb를 통해 기기에 설치
  • 내부에서 코드가 돌아가므로 동작이 빠름
  • 업데이트가 불편하고 CPU 사양이 부족한 케이스가 생김
• obniz
  • 서버에서 Javascript가 돌아감
  • 인터넷을 통해 결과를 매번 통신(API통신과 비슷)
  • javascript가 서버 환경에 의존하기 때문에 CPU에 부담이 가지 않음
  • 통신이 필요하므로 빠른 응답이 나타나지 않음

이 중에서 obniz는 발표자가 제작에 참여하고 있는 CPU로, 코드 예시 또한 obniz에서 사용하는 것으로 볼 수 있었다.

obniz로 Web을 활용하여 IoT 만들기

위 슬라이드는 HTML에서 버튼을 누르면 obniz에 연결된 LED가 켜지는 코드를 보여주고 있다. obniz가 연결되면 obniz 객체에서 기기에 연결된 led 객체를 가져오고, 버튼을 누르면 led.on을 실행하는 간단한 코드이다.

이 코드는 버튼을 누르면 모터를 작동시킨다. 위 코드랑 비교했을 때 작동하는 객체만 달라진 것을 알 수 있다.

obniz로 만든 재미있는 IoT 기기 영상이 있다.

• 슈퍼마리오에서 코인을 얻으면 실제 동전이 나오는 기계
• https://twitter.com/qurihara/status/1014656354978447360
• 사족보행 로봇
• https://twitter.com/google_homer_/status/1048485487113986048

발표자는 위와 같이 javascript로 코드를 짤 수 있다면 센서와 모터를 구해 IoT를 만들 수 있으니, javascript 개발자들은 겁내지 않고 IoT 개발에 흥미를 가져주기를 바랐다.

후기

해외에서 컨퍼런스를 들은 건 처음이지만 한국에서 진행하는 컨퍼런스와는 분위기가 많이 다르다고 느꼈다. 먼저 비일본인 사람들의 비율이 굉장히 많은 것이 놀라웠고, 스탭과 발표자, 참가자가 다들 친밀한 사이처럼 보였다. 심화된 논의 보다도 가볍게 담소를 나누는 느낌이었는데, 이런 분위기 덕에 발표도 가볍게 듣기 좋았던 것 같다.

한국에서는 주로 프로젝트를 진행하면서 어려웠던 점이나 어떤 기술을 깊게 파보는 세션이 많았던 반면, 앞서 말했듯이 일본에서는 자바스크립트로 할 수 있는 재미있고 가벼운 기능을 소개하고 새로운 것을 시도해보자는 취지의 세션이 많았던 것 같다.

Web의 자체무게 세션은 생각해본 적도 없는 Web의 정의나 스펙에 대해 고민하는 시간을 가질 수 있었고, 실무에는 적용하기 어렵지만 재미있는 프로젝트로 할 수 있는 IoT나 PROC-GEN 세션, 작지만 중요한 사실을 알려주는 리액트 라이선스 관련 세션 등 알찬 발표를 많이 들을 수 있는 시간이었다.