9월 4일 코엑스에서 열린 if kakao 2018 컨퍼런스를 정리한 글입니다.
발표내용은 SlideShare와 세션을 들으며 메모한 내용을 참고하여 작성했습니다.
발표내용을 요약해서 생략된 내용이 있을 수 있습니다. 발표자료와 같이 보시는 것을 추천드립니다.
글의 길이와 가독성을 고려해서 모든 글은 두괄식으로 썼습니다.
세션별로 다음과 같은 형식을 유지하고 있습니다.
# [세션제목]
## [세줄요약]
## [발표내용 요약]
## [새로 알게 된 점]
## [느낀 점]
모든 피드백은 환영입니다.
AI에는 세 가지 요소가 있다.
그 중 NUI에 대해 카카오가 어떻게 적용하는지 발표.
CLI -> GUI -> NUI -> VUI
GUI를 상용화한 매킨토시 이후로
30년 넘게 컴퓨터는 GUI를 유지하고
터치 인터페이스를 처음으로 사용한 스마트폰인 아이폰을 시작으로
10년 넘게 스마트폰은 계속 터치 인터페이스를 사용하고 있다.
둘 다 스티브 잡스의 작품이라는게 신기함.
N-depth 와 멀티태스킹
그리고 새로 등장한 VUI
처음으로 GUI를 배제한 새로운 음성인터페이스의 등장.
이전까지 음성 인터페이스는 보조적 역할로만 사용되었다.
장점: Zero-Depth, 음성만으로 이용가능하다.
NUI는 유행이 아닌 사용자 경험의 혁신이다.
집에서 멜론으로 노래를 듣기까지의 과정
스마트폰을 사용할 때
스마트 스피커를 사용할 때
모바일 앱 full package이지만 -> 스피커 기능 단위 실행이다.
비즈니스 로직 단위, 패키징 단위로 쪼개서 생각해야함.
카카오 미니에 있는 서비스는 40개, 피쳐(기능)는 500개가 있다.
하지만 자주 쓰이는 피쳐(기능) 1 ~ 2개가 전체 사용의 6 ~ 70%를 차지한다.
그렇기 때문에 NUI로 개발할 때 핵심기능, 본질적 기능을 먼저 구현하고 디테일한 부분은 나중에 구현해도 된다!
그리고 App의 주요 기능과 스피커 서비스 기능은 다르다
AI시대에 맞는 서비스 개발을 하기 위해서는...
VUI에서 사용자가 말한 내용에 대한 피드백이 약점이라고 생각하는데 카카오 미니는 어떻게 해결하고 있나요?
화자식별 기능에 대한 질문. 차에서 운전자가 말할 때, 동승자가 말할 때 차이를 어떻게 두나요?
VUI에서 먼저 wake up 한 다음 명령을 내린다. (헤이 구글, 헤이 알렉사)
스마트 스피커의 화자인식과 디바이스 개인화는 계속 고민중인 문제이다.
GUI는 depth가 있고, 멀티태스킹이 안되는데 VUI는 이 점에서 장점이 있다. 예) 아침에 출근 준비하면서 스마트 스피커로 뉴스, 날씨, 교통 정보 Zero-Depth로 멀티태스킹하면서 물어볼 수 있음.
발표자분 소개 때 이번 컨퍼런스에서 유일하게 개발자가 아닌 발표자라고 하셨는데 발표자분의 관점에서 본 VUI와 스마트 스피커, 그리고 VUI로 서비스를 고려할 때 개발자가 어떤 것에 집중해야 하는지 알 수 있었다.
다른 분들의 질문을 들으면서 핵심을 짚는 질문 내용에 감탄했고 답변도 매우 좋아서 다른 분들의 질문 덕분에 세션의 내용이 더 깊어지는 느낌을 받았다.
발표내용과 요약이 잘 정리된 글 링크를 첨부합니다.
https://brunch.co.kr/@kakao-it/278
하이브리드 앱이 아닌 네이티브 앱으로 개발했을 때 생기는 단점을 보완하고 해결하는 방법과
은행 앱에서 더더욱 신경써야 하는 부분(보안, 업데이트 대응)에 대해서 알 수 있었습니다.
무엇보다도 발표자분이 말씀을 잘하셔서 발표가 재미있었습니다. 앱을 개발하고 런칭하기까지의 흐름을 시간순서에 따라 편하게 들을 수 있었다.
네이티브 앱과 하이브리드 앱의 장단점에 대해 내가 갖고있던 생각과 비교할 수 있었고, 보완책에서 미처 생각하지 못한 내용을 알게 되었다.
사용하기 편한 은행 앱을 만들자는 의지가 발표에서 느껴졌다. 개발 과정에서부터 철저한 테스트까지...
험난했지만 흔들리지 않았던 경영진 이라는 부분에서 조직에서 결정권자가 서비스에 미치는 영향을 간접적으로 느낄 수 있었다.
오픈소스 라이선스는 나중에 문제가 될수도 있기 때문에 사전에 조사해야함!
쉽게 이해할 수 있게 설명된 그림.
왼쪽은 copyright 오른쪽으로 갈수록 copyleft이다.
아래로 갈수록 강한 조건
화살표 연결된 라이선스는 compatible을 의미함.
예를들면 Apache 2.0과 GPL 2.0은 화살표로 연결되어있지 않기 때문에 incompatible하다.
개인적 사용, 회사 내부에서 사용한다면 라이선스 적용 X
배포가 일어날 때 라이선스 적용됨
오픈소스 compliance 이슈가 증가하는 추세이다.
유명한 사례에는 Google - Oracle, VMWare - Linux 이 있다.
라이선스 분쟁 이슈
오픈소스 라이선스를 신청하지 않으면, 프로젝트에 기여한 모든 사람도 자신의 저작물의 독점적인 저작권자가 됩니다.
즉, 아무도 자신의 기여를 사용, 복사, 배포 또는 수정할 수 없으며 “아무도”에서는 귀하를 포함하지 않는다는 의미입니다.
라이선스에 대해 검색하면서 알게 된 사이트 : https://opensource.guide/ko/legal/
MongoDB는 다중 라이선스 적용도 가능하다.
Mongo DB는
공개 SW 포털, OLIS 에서 오픈소스 가이드 문서를 제공하며, 라이선스 지원 확인도 해준다.
https://github.com/kakao 에서 CLA 참고해서 오픈소스 프로젝트에 적용시켜보면 더 나은 오픈소스 프로젝트를 만들 수 있을 것 같다.
잘 알고 있다고 생각했던 주제인 오픈소스 라이선스에서 새로운 사실(배포의 정의)을 많이 배움. 발표를 정리하면서 공부하며 흩어진 지식을 체계화한 느낌.
사용 목적에 따라서 알맞은 라이선스 적용해야함 - 다중 라이선스도 그중 한 방법.
매일 라이선스 쓸때마다 compatibility 검색했는데 그림 덕분에 쉽게 이해했다.
서비스 대상 지역의 네트워크 품질과 Latency 고려해서 최적의 장소를 선정 - 싱가폴
Cloud? IDC? 비용과 상황 고려해서 - Cloud 사용!
외부에 있는 api gateway와
가속솔루션과 GSLB(Global Server Load Balancing, 현재 지역에서 가장 가까운 서버에 연결시켜주는 DNS 서버)
서버 통신에서 병목 구간은 최초 연결시 TCP handshake with TLS에서 생긴다.
3-way handshake에 TLS 과정까지 포함하면 오래걸림.
가속 솔루션의 원리는 이 병목을 해결하는 것.
TCP handshake with TLS 를 진행할 때 클라이언트와 서버가 가까우면 빨라진다.
가장 느린 구간의 속도를 빠르게 만들어 병목을 해결하자!
Relay service를 만들어 가속솔루션을 대체하자!
api gateway를 싱가폴에 두고, Relay service를 서울에 둔다.
가속 솔루션과 비교했을 때 성능차이가 없었다.
하지만 서버 모니터링, 배포, auto-scaling등 관리 이슈가 증가함.
서버 모니터링은 cloudwatch에 기록하고 api 커맨드패턴은 hystrix, ELK로 모니터링
이슈 1 : 배포 프로세스 중 서울에서 싱가폴로 배포 파일 크기가 커서 latency가 증가하면 배포가 불안정해진다.
해결방법 : 서울에 있는 S3에서 binary file을 싱가폴 서버에 바로 전달. timeout과 retry 설정 쉽게함. rollback 관리만 잘하면 됨.
이슈 2 : DNS Policy 적용 실패
해결방법 : 클라이언트에서 ip를 이용해서 위치파악
이슈 3 : API서버의 Latency가 높음
해결방법 : GSLB의 GeoIP DB를 업데이트
이슈 4 : Global network 불안정, 이벤트 유실
해결방법 : kafka, kinesis에 이벤트 저장하고 log 기록
게임존 진출과 후퇴를 반복하면서 쌓은 노하우를 플랫폼화시킴.
안정적이고 scalable하고 기민하고 유연하게 움직일 수 있는 플랫폼과 인프라를 추구
GSLB와 가속솔루션에 대해서 공부하게 됨.
Global Server Load Balancing.
DNS 서비스가 전세계 단위로 확장된 형태.
지역별로 서버가 운영될 때 기존 DNS의 한계와 단점을 보완함.
주기적으로 서버의 Health Check를 모니터링하면서 다운된 서버의 IP는 응답에서 제외한다.
사용자가 다운된 서버에 연결되지 않게 한다.
기존 Round-Robin 방식의 DNS 서버는 다른 서버의 상태를 알 수 없다.
GSLB서버는 연결된 서버의 부하 상태를 체크하면서 로드가 적은 서버의 IP를 반환한다.
사용자와 서버 사이의 RTT를 측정을 통해 각 지역별 서버의 Latency정보를 저장한다.
요청이 들어오면 응답이 빠른 서버를 사용자와 연결한다.
사용자의 지리적 위치를 고려해서 가장 가까운 서버를 연결한다.
https://www.joinc.co.kr/w/man/12/GSLB
GSLB 에서는 연결할 서버의 정보를 캐싱하는데 캐싱하는 시간이 길면 서버의 변동에 민감하게 반응하지 못하고, 시간이 짧으면 GSLB에 부하가 증가한다.
서비스의 특성에 따라 캐싱 시간을 조절해야하며, 일반적으로 GSLB에 부하를 주더라도 시간을 짧게 설정한다.
Reverse Proxy와 Load Balancing의 차이점.
글로벌 플랫폼에서 고려해야하는 이슈들이 정말 많다... Latency, 보안 이슈, 배포, DNS서버 연결
글로벌 플랫폼을 진출한 경험과 노하우를 플랫폼화 시켰다는 점에서 내가 했던 삽질을 다른 사람이 하지 않게 기술축적.
기술축적의 관점에서 당연하다고 생각될 수 있지만 그 뒤에 숨은 노력이 대단하다고 느껴짐.
팀 규모가 4명밖에 안된다고??? 정말 고생이 많으셨겠다..
해외에 진출한 뒤 사용자 수가 줄어들어서 다시 edge존 철수한다는 얘기 들을 때 마음아팠음.
다음웹툰 2.0을 개발하면서 UX를 중요하게 다뤘다.
애니메이션 넣기 위한 디자인 작업은 개발자와 디자이너가 같이 하게 되는데, 디자인 협업에서 가장 중요한 것은 UX 컨셉이다.
일관된 컨셉이 있어야 작업이 원활하게 진행되기 때문이다.
Creative - 새로운 것
Natural - 프레임 드랍 x
Focusing - UX가 시선 분산시키지 않아야한다.
Meaningful - 의미가 있어야 한다.
디자이너와 같이 작업할 때 어떤 방식으로 작업을 진행할 것인가.
Design Prototyping - 디자이너가 원하는 프로토타이핑을 만들어 온다.
Consultation - 디자인 관점, 개발 관점에서 검토
Development Prototyping - 개발자가 프로토타이핑을 만든다.
Review - 리뷰
Retry - 디자이너와 개발자 둘 다 만족할 때까지 1 ~ 4 반복
메인 화면에서 서버와 통신시간을 확보하는 의미가 있다.
디자인 관점 :
사각형 3개는 각각 Vertical, Contents, Container을 의미하고 세개가 합쳐져서 웹툰이 된다.
구현방법 :
빨간 사각형의 움직임은 3개인데 가속도는 2개이다.
사각형이 합쳐지고, 줄어들면서 옆으로 길이가 늘어난다.
이때 합쳐지고 줄어드는 과정에서 사각형 3개의 top,bottom 컨트롤이 구현할 때 까다롭다.
그래서 발상의 전환으로 배경사각형 1개와 여백사각형 2개로 나누어서 가속도 1개로 간단하게 구현함.
디자이너가 만든 프로토타이핑과 실제로 구현된 결과물을 비교해보고 만족함.
디자인 관점 :
아이콘이 탭마다 GIF, 동영상으로 플레이되었으면 좋겠다.
Issue :
빠르게 탭 이동시 프레임 드랍, 메모리를 많이 차지.
각 도형을 6등분하고 path에 점을 모핑하고 canvas rotate로 자연스럽게 path를 이동시킴.
구현을 했는데 각 도형의 좌표가 너무 멀어서 애니메이션이 부자연스러운 문제가 있었다.
이동할 때 중간에 마름모 형태를 거쳐서 그리자.
마름모 형태가 다른 도형과 가장 유사한 형태이기 때문에 자연스럽게 애니메이션이 그려짐.
다음 웹툰의 List Animation을 구현한 방법
android.support.v7.widget.DefaultItemAnimator의 코드를 복사해서 Callback을 추가함.
Custom Callback 구현해서 리스트에 계단형태로 추가된다.
디자인 Request : Depth가 느껴지지 않게 구현해달라.
스케일 업/ 다운되기 때문에 커브를 살짝만 넣어도 착시효과 발생함.
Ripple Effect : 물방울이 퍼지는 듯한 효과
서버 통신 시간을 확보하기 위해서 리스트 불러오는 동안 애니메이션이 필요하다.
디자이너와 의사소통할 때 논리적인 이유가 필요하다.
왜 애니메이션이 들어가야 하는지 / 들어가면 안되는지. 상대방을 설득시키는 과정이 필수적이라는 것을 알게 되었다.
디자이너가 요구하는 프로토타이핑을 구현하고,원하는 사용자 경험을 만들기 위해서는 디테일한 부분 모두 처리해야하고 완벽하게 구현해야 UX를 전달할 수 있다고 느낌.
디자인 프로토타이핑과 개발 프로토타이핑을 일치시키고 디자인관점, 개발 관점에서 모두 만족시켜야하는 과정이 절대 쉬운 일은 아니라는 생각이 듦.
애니메이션은 예쁘게 꾸미려는 목적만 있다고 생각했는데 UX의 관점과 기술적인 관점에서 모두 의미가 있다고 느낌.
세션 발표를 들으면서 최근에 디자이너와 같이 프로젝트를 재미있게 했던 경험이 떠올라서 기회가 되면 다시 협업하고 싶다고 생각함.
디자인 작업을 하기 위해서는 일관된 프로젝트의 컨셉과 철학이 중요하다고 생각.
