이 글은 회사 기술 블로그에 올리고 있는 내용입니다.회사 기술 블로그에는 이슈가 되고 있는 기술 트렌드와 개인적으로 관심있는 기술 이야기의 주제를 번갈아 가며 연재할 예정입니다. ES2015 리팩토링에 관한 이야기가 다음번 이야기가 될 거 같습니다.

필자는 Agile Core Team 에서 테크리드를 담당하고 있습니다.
OSGeo에서 오픈소스 활동을 하고 있습니다. 잘 모르는 기술에 대해서 낯선 사람들과 이야기 하면서 배워 나가는 것을 좋아합니다.

기술 트렌드에 관련해서 - 1. github

개발자들이 기술 트렌드를 얻는 루트는 생각보다 많지는 않다. 소셜 미디어에서 유명한 개발자들을 팔로우 하거나 그룹에 가입하는 방법들이 많은데, 필자가 주로 기술 트렌드를 얻는 되는 루트는 github 과 hacker news다. 물론 기술 트렌드를 얻는 방법은 여러가지다. 오늘은 먼저 github 에서 어떻게 기술 트렌드를 따라갈 수 있는지에 대해서 이야기를 잠깐 언급하고 현재 핫한 프로젝트 하나를 소개하고자 한다.

이 글을 읽게 될 대부분의 독자들은 아마도 github를 잘 알고 있으리라고 생각이 든다. 하지만, 그럼에도 불구하고 윤석찬 님이 정의하신 깃허브에 대해서 다시 한번 상기 하고자 한다

“gitHub는 한마디로 ‘소셜 소스 코드 공유’를 모토로 한 분산형 협업 개발 호스팅 서비스 입니다. 생소한 개념 같지만 한마디로 ‘오픈 소스 개발 모델’에다가 요즘 한창 유행인 ‘소셜 네트웍’을 접목했다고 보시면 됩니다.”

• 출처 : http://channy.creation.net/blog/626#.WS_iOBPyib8

현재 유명한 오픈 소스는 거의 대부분 이 github 안에 서식하고 있다고 보면 될 정도로 압도적인 곳이다. 이 곳에서 우리는 많은 개발자들이 어떤 프로젝트를 좋아하고 팔로우 하는지를 알아 볼 수 있는데 지금은 첫 메뉴에서 링크로 보이지는 않지만 내가 주로 찾는 URL은 아래와 같다.

• 깃헙 트렌드 : https://github.com/trending

한번에 25개 정도의 결과를 지금 핫한 프로젝트와 개발자를 리스팅해서 보여준다.

오른쪽 콤보 박스를 이용해서 일간, 주간, 월간 결과를 나누어서 확인할 수 있다.
필자는 이런 내용이 너무 좋아서 팀원들과 https://github.com/TeamSEGO/github-trend-kr 같은 페이지를 운영했던 적이 있다. 그리고 https://techstory.shma.so/ 에 한참동안 매일 깃헙 이라는 형태의 블로깅을 하곤 했었다. 이런 활동들이 주는 유익한 점은 개인적으로 개발 트렌드를 파악하는 데에 굉장한 도움을 주고 다음에 무엇을 준비할 지 알 수 있는 자양분이 되었다.

굳이 이런 활동을 하지 않아도 이런 내용을 확인할 수 있는 방법들이 있다. https://github.com/trending 페이지를 직접 방문하거나 아니면 구글 플레이나 앱스토어에 github 이라고 치면 트렌트를 확인할 수 있는 앱들이 굉장히 많다.

25개나 되는 프로젝트에서 무엇을 보면 좋을까.
필자의 경험 상으로는 시작할 때는 다음의 원칙을 지키면 유익했던 것 같다. 먼저 daily와 weekly 는 보지 않을 것. 매일 좋아요(깃허브에서는 스타)를 많이 받는 프로젝트는 굉장히 많이 바뀐다. 하지만 하루 반짝하는 프로젝트는 굉장히 많다. 이런 것들은 과감히 보지 않고 monthly를 선택하고 리스트를 주욱 훑어 보는 것이 첫번째다. 두번째는 본인이 아는 회사나 그룹의 프로젝트만 챙겨본다. 예를 들어 google, facebook, spring 같은 애들이 오면 꼼꼼하게 챙겨본다. 마지막으로 본인이 아는 언어를 사용한 프로젝트를 챙겨본다. 모든 언어를 다 섭렵할 수는 없는 노릇이고 내가 익숙한 내용들부터 챙겨봐도 다 보기가 쉽지 않다. 오늘 소개할 prepack이라는 프로젝트는 위의 순으로 내가 선택한 프로젝트다. (차후 설명)

선택하고 나면 (클릭해서 해당 페이지로 이동) 프로젝트 메인 페이지로 들어갈 수 있다. 깃헙 프로젝트 메인페이지는 기본적으로 프로젝트의 파일 리스트와 소개로 크게 나뉘어져 있다. 파일 리스트는 일반적으로 master 브랜치에 담긴 파일들을 보여준다. 소개는 리드미(Readme) 파일로 작성이 되어 있고 깃허브에서 기본적으로 리드미 파일은 마크다운 형식을 따른다.

리드미 파일에 대한 소개는 art of readme를 번역해서 소개한 부분을 인용한다.

• 이름 — 이름이 무엇보다 중요합니다. react-router라는 이름은 이름만으로 무슨 프로젝트인지 알 수 있으니까요
• 한줄 요약 — 이름이 중요한 것 처럼 한줄로 이 프로젝트의 정체성을 나타내 주는 것이 좋습니다
• 사용법 — API 문서로 바로 가는 것보다 사용법을 설명해 주는 것이 좋습니다.
• API — 이름, 설명, 사용법이 보여지고 나면 API의 상세함이 프로젝트의 품격을 결정합니다
• 설치방법 — 자, 이제 전체를 읽어봤으니 어떻게 설치할 지를 알 수 있어야 사용자가 마지막 결정을할 수 있습니다.
• 라이센스 — 이 프로젝트를 내가 사용할 수 있는지에 대한 중요한 정보를 담고 있죠.

art of readme 링크 : https://github.com/noffle/art-of-readme
소개 링크 : https://techstory.shma.so/art-of-readme-cd19f86b0456

이렇게 프로젝트들을 매일 매일 정복해 나가다 보면 최신 개발 트렌드를 파악하기에 매우 유용하다. 이 방법은 의외로 시간을 많이 소모하는 방법이기 때문에 시간을 절약하기 위해서 사용하는 다른 몇가지 방법들을 다음번에 이야기 하도록 하고 오늘은 새로운 프로젝트를 하나 소개하려고 한다.

6월의 첫 프로젝트 - prepack

깃허브 링크 : https://github.com/facebook/prepack
홈페이지 링크 : https://prepack.io/

facebook에서 최근에 prepack이라는 프로젝트를 공개했다.
이 프로젝트는 JavaScript를 작성하고 나면 최적화한 소스 코드로 변경시켜주는 역할을 할 것을 목표로 지금 개발 중에 있으며 이미 어느 정도의 코드는 변경이 가능하고 시연도 가능한 형태로 공개가 되어 있다.

예를 들어 보면 다음 처럼 코드를 작성해 보자

1
2
3
4
5

(function () {
  function hello() { return 'hello'; }
  function world() { return 'world'; }
  global.s = hello() + ' ' + world();
})();

hello world를 출력하는 소스지만 조금 비효율 적으로 보인다. prepack이 어떻게 변환하는지를 살펴보자.

1
2
3

(function () {
  s = "hello world";
})();

우리가 원하는 것처럼 간결하게 줄여준다!

기술적 배경 설명

최근에 소스코드를 변경해주는 작업들을 하는 오픈 소스들이 많다. 예를 들어 타입스크립트라던지, ES2015를 브라우저에 맞춰 변경해 준다던지 등의 compile 혹은 transpile 로 대변되기도 하지만 꼭 하나의 용어로만은 꼬집어 말할 수 없는 일련의 작업들이 JavaScript에서는 일어나고 있다. 기존 JavaScript가 어려운 것도 하나의 이유지만 개발자들의 소스코드가 일정 품질에 도달하지 못하는 것도 그 원인 중에 하나라고 보여진다.

가장 주목을 받았던 프로젝트는 Babel 이라는 프로젝트인데 이 프로젝트는 보통 ES2015로 코드를 짜면 기존 ES5의 JavaScript로 변환해 주는 일들에 많이 사용되었다. 이유는 브라우저 호환성 때문인데 구형 브라우저에서 이해하지 못하는 최신 JavaScript 문법에 맞춰서 코드를 구형 브라우저에서 이해하도록 바꿔주는 역할 들을 했다. 이 Babel 에서 사용하는 AST(Abstract Syntax Tree) 기술을 이용해서 자바스크립트를 이해(parsing)하고 소스코드를 만들어 내었다.

아래 코드를 보자.
출처 : http://resources.jointjs.com/demos/javascript-ast

1
2
3
4
5
6

var a = 42;
var b = 5;
function addA(d) {
return a + d;
}
var c = addA(2) + b;

이렇게 만들어진 코드를 AST 로 변환을 하면 아래 형태 처럼 만들어진다.

이 visualization 을 위해서는 Esprima 와 JointJS를 사용했다.

어떻게 사용할 것인가

설치는 아래와 같다.

1

>npm install -g prepack

소스 코드를 helloprepack.js 라고 작성했을 경우는 아래와 같이 실행한다.

1

>prepack helloprepack.js

다른 코드로 변경하기 위해서는 아래와 같이 사용한다.

1

>prepack helloprepack.js --out helloprepack_new.js

어떤 의미가 있을까

Babel 의 경우는 사용된 분야가 아무래도 JavaScript가 빠르게 스펙이 올라가는 것을 쫓아가기에 주요하게 사용되었다고 하면 JavaScript VM이 이해하기 더 빠른 코드로 변경하는 역할을 장기적으로 목표로 가지고 작업할 수 있을 것 같다.

이런 비슷한 일을 하고 있는 코드중에 하나가 asm.js 와 WebAssembly 가 있는데 기계어에 가깝게 코드가 짜여질 수록 브라우저에서 더 빠른 성능을 위한 또 하나의 로드맵으로 보여진다.

• 링크 : WebAssembly – hello world 어셈블리를 브라우저에 올려보자

사이트의 중간 로드맵에서도 같은 이야기를 하고 있다.
최종 목표로는 플랫폼처럼 사용하고 싶고 분석과 자동 테스트 코드 작성까지 보고 있다.

AI vs Human Brain
최근 급하게 프로젝트에 두달간 투입이 되면서 블로그 포스팅을 할 여유가 전혀 없었다.
좀 반성하는 차에 진행한 프로젝트에서 얻은 인사이트를 공유하고자 한다.

챗봇을 위한 디자인 원칙들이 속속 나오고 있다.

어떤 절대적인 가이드라인은 사실 없기 때문에 마음대로 만들 수는 있고 마음대로 기획할 수는 있지만 많은 경우에 지금 활용할 수 있는 가이드라인들은 존재한다. 이른바 먼저 가본 사람들이 적어 놓은 가이드 라인들이 있다.

여기 가장 유명한 두개의 가이드라인만 소개를 할까 한다.

1. 궁극가이드 — 9가지 원칙이라고 국내에는 알려져 있는…

• 사용자에게 거짓말하지 않는다 (봇이라고 알려라!)
• 대화를 유도하라
• 사용자의 감성을 고려해 디자인한다
• 대화에 제한을 두지 않는다(지속적으로 개선하라!)
• 경계를 만든다 (사람들이 몰입할 수 있는 경계를 쳐 주라)
• 사람들을 실망시킬 때는 조심하라
• 모든 인터랙션은 의미가 있다.(사용자가 이탈하는 부분을 정확히 트래킹하라)
• 사용자를 잘 도와줘야 시스템이 도움을 받는다.
• 사용자의 감정을 확인하고 감정을 목표점으로 한다.

1. 디자인 8원칙

• 인간인 척 하지 말기
• 단순함을 극도로 유지하기
• 채팅이라는 표현수단 이해하기
• 최종 사용자에게 맞추기
• 간단하게 응답하기
• 봇으로 안될 경우를 대비할 것
• 가능하면 구조적인 입력을 만들것
• 모두가 같은 것을 볼 것 (응답이 제각각이지 않을 것)

이 중에서 가장 첫번째 원칙인 인간인척 하지 않는 것. 즉 사용자에게 사람인척 하지 않는 것이 중요한데 사람은 챗봇이라고 생각할 때와 사람이라고 생각할 때에 다르게 행동(입력)하고 기대하는 바도 매우 다르기 때문이다. 그래서 사람이 아닌 챗봇이라 버튼을 활용한다던지 다른 인터페이스에 대한 디자인을 하는 것은 무척이나 중요하다.

인공지능에 대한 이해 보다 중요한 게 있다.

사람
디자인 원칙에서 보았듯이 가장 중요한 원칙은 사람에 대한 이해다.
사용자가 어떻게 챗봇을 활용할 지를 이해하지 못하면 서비스가 제대로 쓸모 없는 서비스를 하게 마련이다. 그런 의미에서 아직은 인공지능과 사람의 인터페이스는 투박하다.
사용자가 어떻게 챗봇을 쓸 것인지를 정의하려면 내가 하려는 서비스가 어떤 것인지를 명확하게 정의해야 하고 어떤 기능을 대체를 하려는지를 기획자 혹은 개발자 스스로가 알고 있어야 한다.

챗봇에 대한 기대는 굉장히 천차 만별이다.

사용자들과 인터뷰를 하다보면 정작 사용할 사용자들은 챗봇에게 큰 기대를 하지 않는다. 마치 우리가 시리와 빅스비에게 심드렁한 것 처럼. 하지만 기획단계에서의 기획자와 발안자들은 굉장히 많은 기대를 가지고 프로젝트에 접근한다.

심지어 챗봇을 위한 디자인 원칙들을 읽어 보지도 않고 말이다. 챗봇들이 무엇인가 세상을 바꿀 것 처럼 굉장히 멋진 장표들과 아키텍처들을 보고 있지만 정작 이것이 어떤 문제를 해결할 지 알고 있는 사람은 없다.

개발을 진행하면서 이 프로젝트들이 꽤나 많은 분야의 인력에 대한 감축을 전제로 하고 그런 미래가 바로 닥쳐 있다는 사실을 부정할 수는 없지만 굉장한 청사진 또한 동의할 수 없다. 그래서 현실적이지 않은 요구사항들을 사용자 인터뷰와 가이드라인을 기준으로 다 잘라내고 있지만 의사 결정자들 마저도 굉장한 기대감을 가지고 있다는 사실은 어떻게 보면 슬픈 일이다.

하지만 심지어 페이스북과 같이 작업을 했던 항공 티케팅 분야의 챗봇 담당자는 이렇게 이야기 한다
“아무도 챗봇으로 티켓을 사려고 하지는 않아요.”

개발의 대부분은 인공지능과 관련이 없다.

우리는 구글이 아니다. 이걸 인정하면 마음은 굉장히 편해지지만 대부분의 어른들(?)은 그걸 인정하기가 아들 딸 성적표보다 어려운 모양이다. 하지만 우리에게도 희망은 있다. 챗봇의 아키텍처에서 인공지능이 차지하는 부분은 우리가 기대하는 부분보다 굉장히 작다. 오히려 룰을 어떻게 만들고 어떻게 처리할 것인가 하는 부분이 훨씬 중요한 문제로 다가오게 된다.

개발자는 그래서 또 너무나 중요하다.

위의 주제의 연속이다. 챗봇의 대부분은 소프트웨어 엔지니어의 영역이다. 그래서 챗봇 엔진을 잘 만들기 위해서는 좋은 엔지니어와 좋은 아키텍트가 당연히 필요하다. 물론 NLU라던지 딥러닝을 잘 하면 할 수록 더욱 좋다. 하지만 좋은 개발만큼 중요한 부분은 없다.

좋은 개발자는 여러가지 복잡하게 얽혀있는 챗봇의 어려움들을 풀어줄 시작과 마지막이다. 점점 인공지능의 세상이 오면 올 수록 사용자의 입장에서 이해하는 개발자가 더 중요해 질 것이다.

우리는 기존의 레거시를 대체해야 한다.

이렇게 죽어있는 레거시는 곤란하다

상담이라던지, 견적이라던지 모든 챗봇이 풀고자 하는 문제들은 기존의 시스템이 자리잡고 있다. 그럼 이 레거시들을 어떻게 유기적으로 풀고 어떻게 서비스를 대체할 수 있을까? 마이크로 서비스 아키텍처는 그 중의 좋은 대답이 될 수 있다. 하지만 이것은 만병통치약은 아니다. 가장 중요한 것은 기존 레거시 함수를 묶어주는 표준을 만들어 주는 것이고 그 레거시를 어떻게 접근할지에 대한 해답은 챗봇이 가지고 있어야 한다.

그렇다면 사용자의 자연어와 레거시간의 연계는 어떻게 이루어 질 것인가. 여기에는 기존에 없던 인공지능 분야의 기술이 필요하다.

과소 평가해서도 곤란하다.

stay tuned
이 쪽은 지속적으로 계속 발전할 것이다. 그렇다는 것은 지금 발을 들이기에 무척이나 좋은 시기라는 것이다.
아무래도 발전에 대한 틀은 대부분이 갖춰지는 것 같다.
누군가가 기가막힌 사용자 인터페이스를 제시할 것이고 그 때 쯤이면 아직까지는 기대할 것 없는 챗봇 분야의 인공지능도 수준이 많이 올라갈 것이다.
언제나 관심을 기울이고 있어야 한다는 이야기다.

Originally published at 개발바보들.

By Keen Dev on May 30, 2017.

Exported from Medium on May 31, 2017.