키노트
키노트에서는 네이버 랩스에서 진행하고 있는 신기술 개발 발표에 많은 시간을 할애했다. 크게 세 가지 기술이 소개됐다.
WHALE
첫 번째는 네이버의 새로운 웹 브라우저 WHALE, 이전부터 네이버 정도면 자체 브라우저 만들어볼만한데 왜 하지 않을까라는 의문이 약간 있었는데, 역시나 개발중이었다. 여러가지 기능들도 같이 소개됐는데 솔직히 Killing feature는 없다는 느낌이다. 그러나 좋은 시도다. 이전에도 이스트소프트에서 만든 스윙브라우저 등 한국에서 자체 개발한 브라우저가 없는 것은 아니었지만 솔직히 방향은 약간 엇나간 느낌이 있었다. ActiveX를 지원하려고 한다던지 하는.. 뭐 WHALE도 까봐야 알겠지만 크게 이상한 방향으로 흘러갈 것 같지는 않다. 일단 네이버니까 어느 정도는 신뢰가 된달까. 다만 커스텀 V8 엔진을 쓴다고 하는데 그 커스텀이 웹 개발자로서 조금 신경쓰인다. 파파고의 번역 엔진이 결합된 번역 기능은 꽤나 도움이 될 거 같다. 구글 번역에 비해 파파고의 번역이 월등한 품질을 보여주기 때문에 기대가 된다.
Amica
두 번째는 Amica라는 녀석으로 쉽게 말해 Siri같은 음성인식 인공지능이다. 아미카는 단순히 음성인식을 넘어서 Ambient Intelligence(생활환경지능)를 지향한다고 한다. 발화자의 문맥을 이해하겠다는 취지다. 티저 영상만 봤을 때는 뭐 거의 대적할 상대가 없을 정도로 다재다능, 완벽한 모습이었지만 실제로 그 수준은 당연히 아닐 거라고 생각한다.이것도 까봐야 알듯하다. 아미카는 동시에 Amica.ai라는 기술도 공개했다. 구체적인 스펙에 대해서는 알 수 없지만 네이버의 대화 자연어 처리 기술 API정도로 유추할 수 있다. 이걸 기반으로 Amica라는 인공지능을 개발하고 기반 기술을 공개한 것이다. 사실 한국어 자연어 처리에 있어서는 네이버가 1인자이기 때문에 한국어 기반 챗봇을 만든다면 이만한 API가 있을까 싶다.
M1
세 번째는 M1이라는 이름을 가진 실내 공간 정보를 데이터로 매핑하는 로봇이었다. 사실 이 로봇보다 놀라웠던 건 네이버도 자율주행기술을 개발중이라는 사실이었다. 로봇자체는 신기하긴 했지만 나로서는 크게 흥미롭지는 않았다.
이보다 자세한 내용은 블로터에서 확인할 수 있다.
Web Payment API의 현재와 미래
Web Payment API는 W3C에서 새롭게 만들고 있는 웹 결제 기술이다. 지금까지는 쇼핑몰이나 결제 업체측에서 제공하던 결제 인터페이스를 브라우저에서 제공하는게 주요 골자다.
지원하는 브라우저는 사실상 크롬과 삼성 브라우저 밖에 없는 단계로 아직은 지원률이 좀 많이 낮긴하지만 제대로 지원만 된다면 앞으로는 새로운 웹사이트를 개발하는 때 결제관련 처리의 공수가 많이 줄어들 것으로 예상된다. 인터페이스를 브라우저에서 제공하므로, 인터페이스를 디자인 하거나 마크업할 필요도 없을 뿐더러, 근미래에 구현되어있는 브라우저에서는 모두 인터페이스를 제공할 것이므로 크로스 브라우징을 신경쓸 필요도 없겠다. 물론 IE를 버린다는 전제하에..(-_-;) 뭐 사실상 이걸 서비스에 도입하려면 최소한 1~2년 정도는 기다려야 될 것같다. 아직 모던 브라우저 조차 지원하지 않는데..
Web Payment API는 Payment App이라는 별도의 모듈도 포함할 수 있는데, Payment App이란 익히 우리가 알고 있는 삼성 페이, 애플 페이같은 서드파티 결제 서비스를 말한다. 물론 지금 바로 사용할 수 있는 건 아니고, 이 서비스들이 Web Payment API를 대응해야 한다.
발표에서는 Service Worker를 기반으로 Payment App을 구현하는 방법을 소개했다. Service Worker도 현재 Working draft 단계에 있는 기술인데, 생명주기가 일반 JavaScript 어플리케이션과는 달라, Document가 닫히더라도 살아있을 수 있다. 브라우저 지원률은 현재 크롬과 파이어폭스 정도만 지원하는 단계다. 나도 몇 번 들어보기만 했지 잘 아는 기술은 아니라 자세한 설명은 링크로 대체한다.
REST에서 GraphQL과 Relay로 갈아타기
요즘에 GraphQL에 대한 언급이 많은데, 뭔지도 잘 모르고 해서 선택한 세션이다. REST를 대체하겠다는 말도 조금 걸렸고..
REST는 익히 알고있겠지만, 지금까지 웹 서버에서 가장 권장되었던 서버 인터페이스 스타일이었다. 설계를 잘하면 이해도 쉽고 보기좋은 URI를 사용해서 인터페이스를 구성할 수 있지만, 기본적인 프로토콜, HTTP method와 URI만을 이용하여 설계하므로 한계점도 명확하다. 발표에서는 크게 중구난방의 설계 방식이나, 데이터 타입, Query Hell, 라이브러리 부족 등을 한계로 꼽았다.
GraphQL은 이런 한계점을 깨트리기 위해 나온 쿼리 언어다. 코드를 보니 확실히 표현력이 좋다는 생각이 들었다. 애초에 목적 자체가 모던 어플리케이션을 위한 서버 인터페이스 설계이기 때문에 위에서 REST의 단점으로 꼽은 것들을 제외하고도 부자연스러웠던 것들을 심플하고 우아하게 해결할 수 있는 것 같았다.
GraphQL의 특성상 클라이언트에서 HTTP Request를 래핑해야 하는데, 어차피 요즘에는 클라이언트에서 HTTP Request를 래핑하는 일은 흔하기 때문에 단점으로 꼽기는 어려울 것 같다. 나는 GraphQL이 거기에 여러가지 추상화를 더한 것이라고 생각한다.
약간 의문점도 있는데, GraphQL을 위해서 Schema를 정의하게 된다면 데이터베이스 스키마와 중복되는 거 아닌가하는 생각이 든다. 내가 잘못생각하는 것일 수도 있지만.
Relay를 사용하면 React와의 연결 또한 긴밀하게 수행할 수 있다고 한다. 내가 React에 대해서 잘 알지 못해서 Relay에 대해서는 특별히 코멘트하지 않으려고 한다.
Electron : 웹 개발자들을 위한 Desktop Application 제작
이번 세션은 내가 일하고 있는 Studio XID에서 발표를 맡은 세션이다. 발표는 CTO님이 해주셨다.
Electron은 웹 개발에서 사용되는 언어를 통해 데스크탑 어플리케이션을 개발할 수 있는 도구다. GitHub에서 발표하였으며 Slack이나 Atom, Visual Studio Code 같은 어플리케이션도 Electron을 이용하여 개발되었다. 물론, StudioXID에서 개발하고 있는 ProtoPie 역시 Electron 기반의 어플리케이션이다.
Event-based Asyncronous Pattern
Electron으로 개발된 어플리케이션은 기본적으로 소스를 까볼 수 있다. ProtoPie는 서비스가 아니라 툴이기 때문에 소스가 공개되면 치명적일 수 있으므로 소스를 최대한 숨기는 것이 당면과제였다. ProtoPie는 주요 비즈니스 로직을 숨기기 위해서 대부분의 비즈니스 로직을 백엔드에서 처리하고 백엔드를 바이너리로 빌드하여 해결했다.
이 때문에 백엔드에서는 비즈니스 로직을 처리하고 클라이언트에서는 이벤트만 받아 처리하는 Event-based Asyncronous 패턴을 사용하게 되었다.
Command Pattern
데스크탑 어플리케이션이기 때문에 유저는 당연히 Undo, Redo가 될 것이라고 예상하고 그게 되어야 유저가 편리한 것도 당연하다. 클라이언트는 View에 집중하고 유저의 커맨드를 서버에 전달하게 되며, 서버에서 이를 처리하게 된다. 이 때 유저의 모든 동작은 Undo Redo가 가능한 Command로 추상화하고 CommandQueue로 관리된다.
Front-End Framework
이건 개인적인 코멘트인데, 앞서 말한 사항들을 보면 모던 웹 개발과는 많은 부분이 다르다는 걸 알 수 있다. 점점 비즈니스 로직을 프론트 쪽으로 옮기고 있는 추세와는 달리 ProtoPie는 백엔드 쪽으로 옮기고 있다. 따라서 프론트엔드 프레임워크의 필요성 자체가 낮다. (그래도 View에다 그냥 React 정도는 써볼만 하지 않을 까 싶다)
대신, Electron 기반으로 하므로 크로스 브라우징을 고려할 필요가 없어 크로미움이 지원하는 만큼 ECMAScript를 충분히 사용할 수 있기 때문에 프레임워크 없이도 어느 정도는 개발자 입장에서도 어렵지 않은 개발을 할 수 있다. 여기에 ProtoPie는 TypeScript를 사용하여 안정성도 확보하였다.
Build
먼저 백엔드 코드를 숨겨야하기 때문에 Node.js 바이너리 빌드가 가능한 EncloseJS라는 유료 라이브러리를 사용하게 되었다. 문서화가 좋지 않은 상태지만 피드백은 괜찮다고 한다.
빌드는 Electron builder를 사용한다.
Deploy
유저는 업데이트를 싫어하기 때문에 강제로 업데이트를 시켜야 한다. 그래서 백그라운드에서 업데이트를 하는 Auto update가 제공된다.
또한 CDN을 사용해서 업데이트가 매우 느린 지역을 커버했다.
Angular2 VS React
제목부터 대놓고 “이거 궁금해 죽겠지? 듣고싶지? 재밌겠지?” 말하는 거 같아서 나에게 다른 선택권 따위는 없었다. 사실 둘 다 그리 익숙한 프레임워크는 아니지만 개인적으로는 Angular은 프로덕션 경험도 있고 지금도 TypeScript를 시작으로 Angular2를 공부하는 중이고 해서 여전히 흥미로운 주제다.
시작하기 전 투표하는 공간이 있었는데 나는 Angular에 투표했다 ㅋㅋ 어쨌든 Angular2에 더 호감이 있는 쪽이라서 글 내용이 사실 편파적일 수도 있다(…)
언어 생산성
소제목의 이름은 언어 생산성이지만 사실상 TypeScript 갑론을박이었던 것 같다. React의 경우에는 특별히 JavaScript가 아닌 다른 언어랑 사용하는 케이스가 높지 않다고 한다. 발표에서는 Flow를 언급하였는데, React는 Flow랑 같이 사용하는 비율이 4%도 채 안된다고. 반면에 Angular2는 TypeScript로 구현되었으며 TypeScript를 기본적으로 추천한다.
나도 TypeScript를 배우고, 쓰고 있지만 당연히 트레이드오프가 있는 기술이다. 발표에서 지적된 것은 기본적으로 JavaScript 외부 모듈을 갖다쓰게 될텐데, 모듈 인터페이스 정의 비용이 있다는 것이었다. 뭐 실제로 개발해보니 대부분 typings를 통해 정의가 잘 되어있었고, 꼭 외부 인터페이스를 사용하기 위해 any를 사용해서 코딩해야하는 경험은 아직까지 갖지 못했다. 발표 때 언급된 것처럼 공부하기는 어렵지만, JavaScript의 미래라고 생각한다면 투자비용으로 볼 수 있다는 것에도 동의한다.
컴포넌트
이쪽은 주로 JSX에 대한 갑론을박이 많이 벌어졌던 것 같다. 먼저 Angular2에서는 HTML, CSS, JS를 통합해 컴포넌트를 만들기 때문에 한데 묶어 캡슐화 할 수 있다. 반면 React의 경우에는 컴포넌트 단위의 CSS를 지원하지 않으며 JSX라는 언어를 사용하는 방식으로 HTML을 통합한다.
JSX를 사용하면 JavaScript파일에서 마크업도 같이 가져가게 되므로 마크업 개발자와의 협업에 문제가 생긴다는 지적이다. 하지만 Angular2도 순수한 HTML이 아니므로 협업에 문제가 있다는 것이 동일하다는 내용이 있었다. 나는 마크업 개발자와 협업을 해본 경험이 없는데, 사실 이런 프레임워크를 쓰게 된다면 HTML과 CSS만 다룰 수 있는 마크업 개발자와는 협업하기 어려울 것 같다는 생각이 들기는 한다. 따라서 나는 요즘에 프론트엔드 개발자가 마크업까지 책임을 져야한다고 생각한다.
JSX에 대해 말하자면, 나는 큰 거부감은 없으나 발표때 언급된 것처럼 className같은 건 좀 꺼림칙하다. 그렇지만 이건 그냥 취향일 뿐이지 절대로 큰 문제는 아니라고 생각한다. 그리고 요즘에는 JSX처럼 구조와 로직을 함께 가져가는 것도 이제는 오히려 자연스러워 보인다. Angular에서도 전부터 ng-repeat처럼 일종의 프로그래밍 로직이 포함되었기 때문에 결국 구조와 로직이 섞이는 건 프론트엔드 개발에서는 피할 수 없는 문제라고 본다.
데이터 동기화
데이터 바인딩에 대해서 말하는 세션이었다. 먼저 Angular1의 양방향 데이터 바인딩을 까고 시작하며, React의 단방향 데이터 플로우에 대한 설명이 이어졌다. Angular1은 디폴트로 양방향 데이터 바인딩을 지원하기 때문에 성능상으로도 React에 밀렸고, 데이터 흐름도 복잡했던 것이 사실이다. 따라서 이런 과오를 인정하고 Angular2에서는 디폴트 바인딩이 단방향으로 바뀌었다.
덧붙여 Zone.js라는 것이 소개되었다. Angular에서 새롭게 도입한 라이브러리인데, 나도 정확히 이해하지는 못하고 있지만 이 라이브러리를 통해 Angular2에서는 더 이상 비동기 동작 이후에도 명시적으로 동기화를 수행해 줄 필요가 없다는 것이 언급되었다.
참고
React보다 Angular2에 더 주목해야하는 이유 - 발표자인 손찬욱님이 쓴 글이고, 발표내용이 Angular2 입장에서 잘 녹아들어가 있다.
마치며
작년 Deview는 내 내공이 부족해서 그랬던 건지 몰라도 별로 기억에 남았던 것이 없었다. 이번 Deview는 1일 차에 웹 관련 기술을 집중적으로 몰아넣은 것 같은데, 덕분에 작년보다는 훨씬 즐겁게 관람했다. (2일 차는 예비군으로 빠짐 ㅠㅠ) 안타깝게도 행사 막바지 졸음이 쏟아져 마지막으로 들어갔던 Clean FE Development 세션은 거의 듣질 못해서 정리할 내용이 없다. 물론 발표자료는 남아있기 때문에 이 링크에서 감상하면 되겠다.
