긍정적 사고, 음식의 절제, 규칙적인 운동

포켓와이파이 사용시, 데이터로밍완전 차단하기 부가서비스 신청

1. KT 고객센터 앱 설치
2. 자주 찾는 메뉴로 들어가서 "부가서비스 신청" 터치
3. 내 핸드폰번호 확인하고, "로밍상품" 탭으로 들어간다.
4. "데이터로밍 완전 차단", "데이터로밍 완전 차단(MMS가능)" 두개 있는데, 그냥 완전차단 선택. 
   어차피 카톡으로 연락올것이라 문자는 광고성뿐이다. 
5. 신청하기 하면 완료됨.
   * 단, 다음에 해외여행갈때 데이터로밍하려면 부가서비스 해제하는거 잊지말고.

혹시나 앱 없으면, 이미 해외에 나갔으면  

해외에서 (KT 로밍 콜센터) +82-2-2190-0901 

무료통화해서 문의 후 해결하면 된다. 

.

MySQL 클론의 역습 – 1 (MariaDB 편)  https://mariadb.org/

https://embian.wordpress.com/2013/06/26/mysql-%ED%81%B4%EB%A1%A0%EC%9D%98-%EC%97%AD%EC%8A%B5-1-mariadb-%ED%8E%B8/

사실 이 글의 제목을 처음에는 “MySQL의 형제들” 이었다.

source가 fork된것이니 형제보다는 부모 자식 관계가 더 맞지 않을까 생각되서, “MySQL의 자식들”이라고 제목을 바꾸었다가 어감이 좋지 않아서 MySQL의 창시자가 자신의 첫째딸 이름을 따서 MySQL이라고 작명한 것에 착안해 “MySQL의 딸들”이라고 바꾸었다.

그런데, 그만 코드가 복제되서 다시 분화된 것인데 이것을 부모 자식간이라고 해야 하나 형제간이라고 해야 하나 쓸데없는 고민에 빠져버렸다.

결국, 장고 끝에 제목은 “MySQL 클론의 역습”이라고 결정했다. (그런데 실제로 MySQL과 클론들끼리 정말 싸우지는 않는다. 심지어 그들 간은 사이가 좋아 보이기 까지 한다.)

헛소리는 여기까지 하고 본문으로 들어가 보자. ^^;

우리나라에서 DB라고 하면 Oracle 아니면, MySQL이다. 특히 웹서비스 환경은 MySQL이 현재까지도 대세라고 할 수 있다.

최근들어 NoSQL이니 BigData니 하는 새로운 페러다임과 프로그램들이 등장하면서 광풍의 조짐이 보이고는 있지만, 여전히 사용함에 있어서는 제한적이고 진입장벽이 만만치가 않다.

아직까지 DB의 메인스트림은 RDBMS이고, 새로운 웹 프로젝트가 진행되면, 당연하듯 DBMS로는 MySQL이 거론되곤 한다.

사실 좀 지루했었다.

뭔가 MySQL이 아닌 새로운 것을 만지고 싶었을 뿐이었다.

그래서 어떤 프로젝트에서 Postfix를 도입해 볼까 하다가 MySQL에 익숙한 엔지니어들과 개발자들의 반대에 부딛혀야 했고,  본인 스스로도 딱히 그 프로젝트에서 Postfix를 써야 할 당위성을 찾기도 힘들어서 포기한적이 있다.

최근 모바일 게임 관련 프로젝트를 진행하면서 MySQL에서 fork된 몇가지 DBMS들을 만져볼 수 있게 되었다. 이해 당사자도 적고, 약간 도전적인 프로젝트이다 보니 아무런 태클 없이 혼자서 자유롭게 DBMS를 선택할 수 있는 기회였다.

이 글은  그 때 research 했던 MySQL fork program 들에 대한 간단한 소개 글이다.

MySQL이 Oracle에 편입된 후, MySQL의 향후 운명에 대한 우려의 목소리가 많아졌다.

이러한 우려 속에서 MySQL의 대안을 찾으려는 움직임이 많아지고 있는데, 그것들 중 대표적인 것으로 MySQL에서 fork된 프로젝트들을 꼽고 싶다.

이 글에서는 MySQL fork 프로젝트들 중 가장 많이 알려진 세가지 프로젝트에 대해서 정리 하려고 한다.

1. MariaDB

MariaDB 의 주요 개발자는 Michael Monty Widenius라는 사람으로 MySQL을 개발했던 사람이고, 그 MySQL을 Sun에 10억 달러(약 1조원)에 매각하면서 핀란드 10대 부자중 한 명이 된 사람이기도 하다.

하지만 MySQL을 인수했던 Sun이 다시 Oracle로 인수되자, Monty Program AB이라는 회사를 설립하고 MySQL의 소스를 기반으로 MySQL과 완벽하게 호환이 되는 DBMS를 개발 하는데, 이것이 MariaDB이다.

MySQL, MariaDB 둘 다 Monty의 딸 이름을 따서 만들었는데 MySQL은 첫째 딸, MariaDB는 둘째딸의 이름에서 따론 것이라고 한다.(딸바보인가보다)

MariaDB는 MySQL의 소스를 가져다 만들기도 했지만, 목표자체가 MySQL을 완벽하게 대체하는 것이다 보니, 기존 MySQL과 완벽하게 호환이 된다.

프로그램의 룩앤필도 거의 똑같고 지원하는 함수들도 모두 일치하며 심지어 파일 이름들도 그대로 MySQL의 것을 가져다 쓰고 있다.

개발자들이 그냥 보기에는 이게 MariaDB인지 MySQL인지 모를 정도이다. (Client의 프롬프트가 “MariaDB” 로 뜨는 것 말고는 정말 똑같다.)

당연히 php-mysql 이라던지, jdbc-mysql-connector같은 기존 db connection library도 그대로 사용할 수 있기 때문에 실제로 개발자들은 MySQL에서 MariaDB로 DB 서버가 바뀐다고 해도 전혀 소스코드 수정이 필요없으며, 추가적인 DBMS에 대한 학습도 거의 필요가 없다.

즉, MySQL을 다룰줄 아는 개발자라면 MariaDB의 진입장벽은 거의 없는 수준이라고 할 수 있다.

하지만, MySQL을 완벽하게 대체한다는 사실만으로 기존에 MySQL을 잘 사용하던 사람들이 막연한 불안감이나 새로운 프로그램에 대한 단순한 호기심만으로 MariaDB로 갈아타지는 않을 것이다.

그럼 MySQL 대신 MariaDB를 썼을 때 얻을 수 있는 잇점들은 어떤 것이 있을까?

첫번째 장점은 월등히(?) 빠른 쿼리 타임을 들 수 있다.

인터넷이 돌아다니는 다양한 퍼포먼스 테스트 결과를 보면 전반적인 쿼리 성능이 MySQL에 비해 좋은 것을 알 수 있다.

특히, sub query나 join query 같은 경우 따로 MariaDB의 특징으로 소개할 만큼 성능 향상이 있다.

그리고 본인이 직접 테스트한 결과에서는 Partitioning table에 대한 select 쿼리 결과가 특히 눈길을 끌었는데, 자세한 테스트한 결과는 따로 추가 글을 작성할 예정이다.

두번째 장점은 다양한 추가 기능들이다.

이 글에서는 다양한 추가 기능들중 몇가지만 소개하고자 한다.

1. Microseconds in MariaDB

테이블을 생성할 때 시간관련 자료형에 정밀도를 설정 할 수 있다.

CREATE TABLE example(

col_microsec DATETIME(6),

col_millisec TIME(3)

);

정밀도는 0부터 6까지 설정할 수 있으며, 설정된 값만큼의 microseconds가 출력된다.

SELECT CURTIME(4);

–>10:11:12.3456

2. Microseconds Precision Processlist

INFORMATION_SCHEMA.PROCESSLIST 테이블에 TIME_MS 컬럼이 추가 되었다.

processlist를 볼때 MySQL에서는 실행타임이 초단위까지 밖에 나오지 않았다면 MariaDB에서는 microseconds 단위까지 확인 할 수 있다.

3. Table Elimination

여러개의 table 조인으로 구성된 쿼리의 경우, 사용하기 편하기 view table을 따로 구성하기도 하는데, view table에서 특정 컬럼을 select할 경우 실제로 조인된 table들중 쿼리에 필요 없는 테이블이 발생할 수 있다.

MariaDB는 이런 경우 자동으로 쿼리에 필요 없는 테이블을 조인쿼리에서 제거해주는 기능을 가지고 있다. (이 특징은 성능 향상쪽에 가까운것 같기도 하다.)

4. Virtual Column

다음의 테이블 스키마를 보자.

create table table1 (

-> a int not null,

-> b varchar(32),

-> c int as (a mod 10) virtual,

-> d varchar(5) as (left(b,5)) persistent);

table1의 c 컬럼은 가상컬럼이다. 실제로 storage에 저장되지 않고 query 실행시간에 계산되어 출력된다.

table1의 d 컬럼은 실제로 storage에 저장이 되는 가상컬럼으로, insert나 update 때 계산되어 저장 되는 컬럼이다.

더 많은 추가 기능들이 있는데, 추가기능에 대한 설명은 여기에서 확인 할 수 있다.

한가지 주의할 점은 MariaDB의 추가 기능들을 사용할 경우 혹시라도 부득이하게 MySQL로 돌아가야 될 경우 호환이 안될 수도 있다는 점을 유의해야 한다.

마지막으로 MariaDB는 다양한 Storage Engine을 지원한다.

1. Aria

Aria 엔진은 MyISAM과 호환되면서 추가적으로 Transactional기능이 추가된 Engine이다.

2. XtraDB

InnoDB의 대체 Engine으로 다음에 설명할 Percona사에서 개발한 Storage Engine이다.

3. PBXT

일반적인 목적의 transactional storage engine으로 현재 더이상 maintaine 되지 않고 있어서 MariaDB에 기본 탑제되어 있지 않지만, 필요한 경우 재컴파일을 통해 사용할 수 있다.

4. FederatedX

Federated Storage Engine의 fork engine으로 Federated engine은 원격 서버의 table에 접근해서 Insert, Update, Delete, Select 를 할 수 있도록 해주는 engine이다.

5. OQGRAPH

Open Query Graph storage engine의 약자로 트리나 그래프 형태로 출력될 수 있도록 데이터를 저장하는 engine이다.

6. IBMDB2I

MySQL 5.1.55에서 빠졌던 엔진인데, MariaDB에서는 아직까지 지원하고 있다.

7. SphinxSE

Full Text Search Engine 으로 Full Text Search가 필요한 경우 사용할 수 있을 듯 하다.

8. Cassandra in MariaDB-10.0

NoSQL DBMS인 Cassandra cluster에 MariaDB를 통해 접근 할 수 있도록 10.0 버전에 추가되었다.

3가지 측면에서 MariaDB의 장점에 대해서 설명했는데, 개인적으로는 첫번째 장점인 성능 향상 만으로도 MariaDB를 쓰는 이유는 충분한 것 같다.

본인 입장에서는 추가 기능의 필요성은 아직까지 피부로 와닿지 않았고, 추후 MySQL이나 Percona로 전환해야 될지도 모르는 이슈 때문에 전혀 고려대상이 되지는 못했다.

.

“지도자의 첫 번째 규칙을 모르는가?

모든 것이 너의 책임이다.”

- 디즈니 만화영화, ‘벅스 라이프’ 대사 중에서

책임이 나에게 있다고 생각하면

환경 탓, 남 탓을 하지 않게 됩니다.

불평불만도 사라집니다.

스스로 문제 해결에 나서게 됩니다.

주도적이 되고, 결과적으로 탁월한 성과도 뒤따라옵니다.

매사에 책임을 지겠다고 결심하는 순간,

자연스레 리더의 반열에 오르게 됩니다.

.

행복하기 위해서는 

진짜 경험에 자신을 던져야 합니다. 

기분 좋은 느낌은 현실 속 경험의 축적에서 

비롯됩니다. 몸에서 일어나는 그 느낌, 

지금 이 순간의 경험에 충분히 

빠져들 수 있어야 합니다. 

- 김병수의《감정의 온도》중에서 - 

* 껍데기에 머문

가짜 경험이 너무 많습니다.

깊은 경험, 경이로운 경험. 인생을 바꾸는 경험은

진짜 경험의 축적에서 비롯됩니다. 여기에는

얼마쯤의 자기 희생과 용기, 몸을 던지는

깊은 몰입이 요구됩니다. 진짜 경험이

진짜 공부입니다.

.

Helloween - I Want Out (1988)

바풀, 세계 최초 ‘자동답변’ 에듀테크 기술 개발 2016-09-26

http://news.naver.com/main/read.nhn?mode=LSD&mid=sec&sid1=101&oid=014&aid=0003711273

에듀테크 시대 새로운 공부문화를 창조하는 ㈜바풀은 전 세계 최초로 사진 속 수학문제를 인식해 같은 문제와 유사 문제를 찾아 풀이와 답변을 제공하는 ‘자동답변’ 기술을 개발했다고 26일 밝혔다. 

㈜바풀은 바로풀기 서비스를 통해 모르는 문제가 생기면 스마트폰으로 사진을 찍어 질문하고 답변 받는 무료 공부 Q&A서비스를 운영 중이다. 이번에 개발한 ‘자동답변’ 에듀테크 기술은 지난 6년 간 바로풀기 서비스를 통해 구축한 400만 개 가운데 답변이 달린 100만 개의 DB를 검토하여 똑같은 질문을 찾아서 풀이와 답변을 보여주는 기술이다. 

똑같은 질문이 없을 경우, 수학문제의 수식과 텍스트(한국·영어)를 인식해서 유사한 질문의 답변을 제공하는 방식으로 문제풀이를 도와준다. 

세계 최초로 개발한 ‘자동답변’ 기술은 세 가지 기술이 융합되어 얻어진 결과다. 

먼저 ‘사진 후처리 기술’은 사용자가 촬영한 수학 문제로부터 각종 노이즈를 제거하고, 회전각과 비틀림 각을 보정해 문제 사진이 수평이 되도록 만든다.

이렇게 보정된 사진은 20여 단계로 구성된 독자적인 OCR(OpticalCharacter Reader/Recognition, 광학적 문자 판독) 기술을 통해 사진 속의 텍스트와 수식을 분리하고 이를 메타 정보로 기록한다. 

마지막으로 6년간의 서비스에서 얻어진 각 학년별 수학 단원 및 개념 맵을 활용함으로써 DB로부터 해당 문제의 답변, 그리고 사용자에게 도움이 될 수 있는 유사 문제를 제공한다. 

지금까지의 OCR기술은 한글보다 상대적으로 쉬운 언어인 영문 환경에 한해서만 그 기능을 수행할 수 있었고, 수학 문제에서는 수식으로만 이루어진 간단한 계산문제에 대해서만 풀이를 제공하는 수준이었으나, ㈜바풀은 세계 최초로 한글과 수식이 혼합된 환경에서도 그 둘을 각각 분리하여 사진 형태의 문제를 분석해 3초 정도의 시간이면 답변을 찾아준다. 

㈜바풀의 ‘자동 답변’기술을 통해 얻어진 학생의 정보는 ‘KnowledgeTracing’이 가능하며, 학생의 학습이력 관리 및 수준에 맞는 맞춤 강의와 선생님을 추천할 수 있다. 또한, 문제를 바탕으로 메타 콘셉트 데이터를 구축해서 문제 하나가 갖고 있는 여러 개념들을 묶어주고 분류할 수 있게 되어 학생들에게 유용한 정보를 제공할 수 있게 된다. 

바풀 김영재 CTO는 “바풀의 ‘자동답변’ 신기술을 통해 많은 학생들이 수학을 포기하지 않고 공부에 대한 재미를 느꼈으면 좋겠다”며 “㈜바풀은 교육과 IT를 접목한 에듀테크 신기술로 모든 학생들이 동등한 교육환경 속에서 양질의 교육을 경험할 수 있도록 노력하겠다”고 전했다. 

챗봇, 혁신적 저널리즘 출구될까

http://www.bloter.net/archives/258321

디지털 미디어 업계에는 매년 새로운 키워드가 등장한다. 소셜, 빅데이터, 알고리즘, 사물인터넷, 클라우드 등 전에는 거의 들어보지 못했던 단어들이 었다. 그런데 올해는 특이하다. 우리가 익히 알고 있던 단어가 새로운 키워드로 등장했다. ‘메신저’다.

1990년대 중반부터 우리가 사용해 오던 서비스다. 메신저는 간단한 질문이나 확인, 회의나 작업 조정, 즉석 친교 만남 조정, 친구나 가족과 지속적인 연락 등을 위하여 주로 사용되면서 큰 인기를 끌어왔다. 이러한 가운데 스마트폰 보급률이 2015년을 기준으 로 83.2% 1에 이를 정도로 대중화되면서 모바일 메신저의 활용이 급속히 늘어났다. 이를 입증하듯 우리나라의 대표적 모바일 메신저인 카카오톡의 경우 지난 1분기 기준으로 한 달 평균 적극 이용자수가 4,117만 명 2에 이르고 있다. 우리나라 전체 국민 중 80% 이상이 매월 카카오톡을 이용하고 있다는 뜻이다.

새롭다고 하기에는 너무나 많은 사람이 이미 사 용하고 있는데 왜 또 메신저인가? 메신저 뒤에 붙은 ‘챗봇(chatbot)’ 때문이다. 챗봇이란 전자게시판이나 통신망에서 여러 사용자가 다양한 주제를 가지고 실시간으로 모니터 화면을 통하여 대화를 나누는 채팅과 자동으로 사람이 하던 일을 수행하는 기계인 로봇에서 한 글자씩을 따와 만들어진 용어로 인공지능(AI)을 기반으로 사람과 자동으로 대화를 나누는 소프트웨어를 말한다.

페이스북의 차세대 중심 ‘챗봇’

[사진1] 페이스북은 일반 챗봇 개발자들을 위해 인공지능 엔진 ‘위트닷에이아이’를 제공하기도 했다. ‘위트닷에이아이’를 통한 챗봇 학습 화면.

챗봇은 사람이 아닌 일종의 인공지능이라고 할 수 있는 ‘(로)봇’이 자동으로 이용자에게 메시지를 보내고 이에 대한 이용자의 질문에 실시간으로 응답 하면서 다양한 기능 활용을 유도한다. 이용자의 질문을 분석해 자동으로 답변을 제시하는 방식으로 작동하는 챗봇은 메신저 플랫폼을 활용한 일종의 가상 비서라고도 할 수 있다. 메신저라는 개인적 커뮤니케이션 도구를 통해 대화를 나누기 때문에 그동안 알기 어려웠던 개인의 미세한 맥락까지 파악할 수 있어 새로운 수익원에 항상 목말라 하는 기업들에게 새로운 기회로 받아들여지고 있다. 챗봇은 “모바일에서 앱 이후 가장 중요한 것”(Hadfield, 2016. 3. 17.) 3이라는 전망까지 나올 만큼 크게 주목받고 있다.

기업뿐만 아니라 미국 공화당 대선 경선 후보인 도널드 트럼프도 ‘드럼프봇(DRUMPF Bot)’으로 명명된 챗봇 4을 개발해 유권자들과 대화를 나누고 있을 정도다. 구글, 마이크로소프트, 라인, 위챗, 텔레그램 등 글로벌 IT 회사를 비롯한 거의 대부분의 메신저 서비스 회사들이 챗봇 개발에 열을 올리고 있다. 전 세계 최대 소셜네트워크 서비스인 페이스북이 현지 시각으로 지난 4월 12일 ‘F8 2016’ 콘퍼런스를 통해 메신저 챗봇 플랫폼을 선보인 이유가 자연스럽게 설명된다. 마크 저커버그 페이스북 CEO는 이번 F8 기조연설에서 “메신저 챗봇앱은 앞으로 5년간 페이스북의 중심이 될 것이다”라고 말했다.

플랫폼은 이용자 사이의 거래에 필요한 구성 요소와 규칙의 집합이라고 할 수 있다(Eisenmann, et al., 2009) 5. 플랫폼의 구성 요소에는 소프트웨어, 하드웨어 등이 모두 포함되며 규칙은 플랫폼 참여자들 사이의 이해관계를 조율하는 역할을 한다. 플랫폼 제공자들은 다양한 기술적 요인들로 이루어진 구성 요소들과 규칙을 만들어 배포하고 이를 지지하는 집단 및 개인이 등장하면서 점차 플랫폼이 확산된다. 페이스북이 지난 4월 F8에서 발표한 것 중 하나가 페이스북 메신저 플랫폼의 구성 요소들과 규칙 6이었다.

페이스북 메신저 플랫폼의 구성 요소 중 핵심은 이용자들과 메시지를 주고받을 수 있도록 해주는 송신/수신 API 7다. API는 일반적인 컴퓨터 응용 프로그램에서 사용할 수 있도록 운영체제나 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만든 인터페이스 혹은 규칙을 말한다. 이 인터페이스에 따라 작성하면, 페이스북 메신저를 통해 사용자와 메시지를 주고받을 수 있다. 채팅창에 펼쳐지는 대화 내용 형식이나 버튼 모양도 설정이 가능하다. 그런데 이러한 플랫폼이 없던 시절에도 우리는 페이스북 메신저를 통해 대화를 주고받았다. 이번에 발표한 송신/수신 API는 사람을 위한 것이 아니다. 자동으로 사용자와 대화를 나누는 (로)봇, 즉 챗봇을 위한 것이다.

챗봇은 인공지능 기술과 텍스트 메시지를 기반으로 하는 일종의 자동 대화형 소프트웨어다. 이용자는 사람이 아닌 봇과 대화를 나누지만 실제 사람과 대화하는 것과 같은 친숙한 느낌을 가지면서 인터넷 검색, 뉴스, 쇼핑, 결제 등과 같은 다양한 서비스를 이용할 수 있다. 봇이 사람처럼 대화를 나누기 위해 필요한 기술이 인공지능이다. 이를 위해서는 학습된 데이터가 필요하지만 일반 개발자나 규모가 작은 곳에서는 관련한 기술을 보유하고 있기가 쉽 지 않다. 페이스북은 이들을 위해 자신들의 학습 데이터에 기반한 봇 인공지능 엔진 기술을 함께 제공 한다. ‘위트닷에이아이(wit.ai)’ 8라는 봇엔진이다.

아직은 뉴스 추천 서비스 수준

[사진2] 페이스북 메신저 플랫폼을 이용해 실제 서비스를 실시 중인 CNN 페이스북 뉴스 챗봇의 대화 화면. 아직은 사람처럼 자연스러운 대화를 나누지는 못하고 질문을 단순 검색 문장으로 이해하여 답변하는 수준이다.

봇엔진은 인공지능 채팅봇을 쉽게 제작할 수 있도록 돕는다. 베타 수준인 위트닷에이아이 봇엔진은 충분한 데이터가 없는 초기 개발자가 [사진1]과 같이 규칙에 따라 ‘대화(story)’를 진행하고 몇몇 대화 들이 쌓이면 그것을 기계가 학습하도록 유도한다. 따로 코딩이 필요하지도 않다. 예를 들어, “한국언론 진흥재단에 어떻게 가나요”라는 질문을 입력하고, “1호선 시청역 4번 출구로 나와 프레스센터 쪽으로 50m가량 가세요”라는 답변을 입력한다. 이 대화들에 등장하는 각 개체명은 장소, 기관 등 기준에 따라 등록된다. 이렇듯 대화들을 학습한 내용에 따라 봇 엔진은 봇이 다음에 할 말을 예측한다. 이 예측에는 위트닷에이아이가 이미 구축해 놓은 데이터들이 결 합되기에 새로 봇을 만드는 개발자들이 너무 많은 학습을 진행하지 않아도 된다. 이후 실제 사용 내용에 따라 봇 엔진은 봇을 실시간으로 최적화하고 수정한다. 복잡한 규칙을 만들지 않고 간단한 규칙 몇 개만 만들어서 봇을 만들면 위트닷에이아이가 기존 학습 내용을 바탕으로 챗봇을 만들어주는 것이다. 물론, 영어에 한정돼 있다.

디지털 시대 내내 항상 위기의식을 느끼고 있는 언론사들도 챗봇에 주목하고 있다. 언론사들은 챗봇이 독자 참여도 향상, 수백, 수천만 명에 이르는 메신저 이용자들을 대상으로 한 새로운 독자층 개발, 독자와 새로운 방식으로의 연결, 커뮤니티 건설 등을 가능하게 해 줄 것이라는 기대를 품고 있다(Barot & Oren, 2015, p. 19). 9 독자적인 챗봇 플랫폼을 구축한 텔레그램의 봇 스토어에는 현재 뉴스 분야 10에만 120개의 챗봇이 등록돼 있다. 2016년은 ‘뉴스의 봇화(the botification of news)’가 본격적으로 시작될 것이라는 전망이 나올 정도다(Barot, 2015). 11

페이스북 메신저 플랫폼은 아직 베타 버전으로 완전한 수준은 아니다. 페이스북이 전 세계에서 가장 많은 이용자를 보유하고 있는 SNS이기에 페이스북 메신저 플랫폼 기반의 챗봇 개발에 나서려는 언론사들은 많지만, 실제 서비스를 실시 중인 곳은 CNN 외에는 거의 없다고 할 수 있다. CNN 챗봇과 대화하기 위해서는 CNN 페이스북 페이지에 방문해서 메신저 창을 클릭하면 된다.

[사진2]는 PC 화면 12을 통해 CNN 챗봇과 대화를 나눈 장면을 갈무리한 것이다. ①번 화면을 통해 챗봇에 대해 안내한 후 설정을 유도한다. 설정이 끝나면 ②번 화면과 같이 대화 방법을 소개한 후 주요 기사(Top stories), 추천 기사(Stories for you), 문의(ASK CNN) 등을 선택할 수 있는 화면을 제시한다. 이용자는 제시된 선택 사항을 클릭하거나 자신이 원하는 내용을 입력할 수 있다. ③번 화면은 ②번 화면에서 주요 기사 선택 후 나타난 화면으로 주요 기사를 보여준 후 기사 내용 전체를 읽을 것인지 요약문을 읽을 것인지를 선택하게 한다. 요약문은 채팅 창 내에서 대화 형식으로 보여주지만, 전체 기사 읽기는 링크를 통해 다른 창에서 읽게 한다. ④번 화면은 원하는 내용이 없어서 ‘트럼프(trump)’라는 단어를 입력한 결과다. 입력된 대화 내용과 맞는 기사와 요약문을 제시한다. 트럼프의 경우는 미리 입력된 정보가 있기에 요약문을 제시하지만 정보가 없을 경우에는 가능한 관련된 기사 등을 호출해 보여준다.

예를 들어, ‘present’라는 일반명사를 입력할 경우 CNN 챗봇은 “이 내용과 관련해 당신이 가장 읽을 것 같은 기사(Based on what you asked for, here’s a story I thought you might want to read)”라고 말하며 관련된 기사의 링크를 제공한다. 하지만 단어의 의미를 이해한다기보다는 단순한 검색 수준이다. “너는 누구냐(who are you)”고 말을 하면, “당신에게 가장 도움이 될 만한 것을 추천하고 싶다. 당신을 위한 기사가 여기 있다(I hope I’ll be able to assist you as much as possible. Here’s a story for you)”며 기사를 추천한다. 문장의 의미를 이해하기보다는 단순 검색 문장으로 이해하여 답변하는 것이다. 즉, 사람과 같은 자연스러운 대화를 나누고 있지는 못하다. 물론, 충분한 대화의 양 이 쌓인 후에는 더욱 자연스러워질 것이겠지만 아직은 제한적 수준이다. 현재 수준에서 페이스북 뉴스 챗봇은 대화 형식의 뉴스 추천 서비스에 가깝다 고 할 수 있다.

이 또한 그냥 지나갈 수도…

[사진3] 조선일보(왼쪽)와 한겨레신문(오른쪽) 페이스북 페이지 대화 화면. 페이스북 페이지에서 사람 운영자가 답변한 사례들로, 운영자들이 수많은 사람들에게 일일이 대응하는 것은 사실상 불가능하기 때문에 ‘부재중’과 같은 형식적 대화만 하거나 불러도 대답이 없을 수밖에 없다.

[사진3]은 페이스북 페이지에서 챗봇이 아닌 사람으로서 운영자가 답변한 사례들이다. 굉장히 소수일 것으로 추측되는 운영자들이 수많은 사람들에게 일일이 대응하는 것은 사실상 불가능하다. ‘부재중’ 과 같은 형식적 대화만 하거나 불러도 대답이 없을 수밖에 없다. CNN의 경우도 챗봇을 개발하기 전에는 평균 답변 기간이 하루 정도였다. 제한적이지만, 챗봇이 훨씬 나은 이유다. 하지만 향후 뉴스 분야에서 챗봇이 얼마나 혁신적 모델로 자리잡을지를 전망한다는 것은 현 시점에서 사실은 불가능하다. 인공지능 기술은 분명히 발전해 나갈 것이지만, 당장 1~2년 내에 챗봇이 뉴스 시장을 장악한다는 식의 전망은 아직 섣부르다. ‘이 또한 지나간’ 사례들을 그동안 충분히 봐 왔기 때문이다.

‘챗봇 저널리즘’ 13이라는 말까지 등장하고 있지만, 그 진화의 방향이 어떻게 될지는 아무도 확신할 수 없다. 구글 글래스가 등장했을 당시 유행했던 ‘글래스 저널리즘’이라는 말은 더 이상 사용되지 않고 있다. 이용자 개인의 맥락을 분석한 맞춤형 광고로 새로운 수익원을 창출할 것이라는 전망도 있지만 그것이 언론사가 아닌 플랫폼의 수익원으로만 돌아간 사례들도 우리는 꾸준히 봐 왔다. 게다가 챗봇의 핵심은 인공지능이지만 언론사가 독자적으로 인공지능 기술을 갖춘다는 것은 말처럼 쉬운 일이 아니다. ‘이 또한 지 나갈지 모를’ 새로운 기술을 무조건 따라갈 것이 아니라 미디어의 관점에서 기술의 방향을 비판적으로 지켜보는 것도 방법일 수 있다. 마이크로소프트가 사람과 대화를 나누는 인공지능 챗봇 ‘테이(Tay)’를 선보였다가 16시간 만에 운영을 중단한 사례 14는 많은 점을 시사한다.

.