이번글은 덕력이 솟구친다는!!!은 아니고요(진짜 아니에요), 혹시 "하츠네 미쿠"라는 캐릭터를 보신 적 있으신가요?하츠네 미쿠! 설마 처음보는 분들이 계신가요?? 출처: https://ec.crypton.co.jp/pages/prod/vocaloid하츠네 미쿠는 VOCALOID(보컬로이드)로서, 간단히 설명하면, 야마하에서 만든 음성 엔진입니다(자세한 내용은 링크를 확인!). 해당 엔진을 기반(자세히는 VOCALOID2인데... 아, 저는 잘 몰라요 진짜예요...)을 기반으로 크립톤 퓨처 미디어사가 아티스트를 만들고, 이를 지적 재산권(이하 IP라고 하겠습니다)으로 창출해 낸 사례입니다! 해당 세션은 이 보컬로이드가 성공할 수 있게 된, 창작자들에게 프로그램 번들 시디를 팔던, 크립톤 퓨처 미디어사가 새로운 미디어와 아트의 중심에 설 수 있게 된 이유를 들을 수 있게 된 좋은 시간이었습니다. 앞으론 말이 매우 딱딱하니 이점 히해해 주세요~! 시작하겠습니다!씨디파는 회사가 인터넷 시대를 맞이하며 겪게 된 위기, 그리고 해결방안. 앞서 말씀드렸든, 크립톤 퓨처 미디어(이하 크립톤이라고 하겠습니다)는 창작자들을 위한 서비스(또는 프로그램)를 번들 또는 디스크 형식으로 판매하는 회사였습니다. 그리고 새로운 세대로 들어서면서, 해당 사업이 사양되고 있고(디스크 판매> 콘텐츠 다운로드의 변화), 특히 음악 제작 서비스의 경우, 작은 시장의 규모 때문에 비즈니스에 대한 한계를 느끼고, 새로운 사업 영역을 펼쳐나가기 위해 방향 모색하기 시작했다고 합니다. 그리고 크립톤이 생각할 수 있는 "자사가 가장 잘할 수 있는 것"을 생각해 보았을 때, "소리"라는 콘텐츠를 방점으로 서비스를 응용해 나가면서 스팩트럼을 넓히자!라는 생각을 했다고 합니다. 그래서 시작한 것이 바로, 보컬로이드!라는 것이었죠.보컬 합성 기술(보컬로이드) + IP의 도입은 처음부터 성공적이진 않았습니다. 처음 크립톤은 야마하의 보컬로이드 기술을 기반, Leon과 Lola라는 소프트웨어를 제작,  당사에서 유통을 시작했을 때에는, 타깃 유저를 잡는데 실패해 매출에 전혀 도움이 되지 않았다고 합니다(아래 사진을 보면 왠지 알 거 같...)첫 보컬로이드 레온과 로라입니다..... 음... 입술이 매력적 이네요.... 출처: http://vocaloid.wikia.com/wiki/Forever_(Zero-G_song) 그 이유는 해당 서비스를 사용할 것이라고 타게팅한 아티스트들의 경우, 목소리에 관해 리얼함을 추구하는 데, 해당 소프트웨어는 하드웨어로 조정하는 음과 음성들이 리얼함이 다소 떨어져 전혀 니즈가 없었던 것이죠.그래서 트립톤은"해당 서비스를 진짜 사용하는 유저들은 어떤 사람들 일까?"에 대한 고려를 기반으로,"메이코"라는 일본어로 노래하는 보컬로이드를 제작, 흥미를 끌 수 있도록 캐릭터를 모티브로 하는 커버 디자인 작업 시작(안드로이드 아니 보컬로이드 이니깐요!)이제는 버전 쓰리가 된 메이코! (출처:http://vocaloid.wikia.com/wiki/MEIKO) 첫 출시 당시, 거부감도 있었지만, 당시 KPI 목표인 500개를 훌쩍 넘어 3,000개의 판매 성공을 거뒀고, 성공의 요인은 패키징 디자인과 단순한 아티스트뿐만이 아닌, 다양한 콘텐츠에 관심을 가지는 다양한 유저들을 유저들을 이끌 수 있는 요소들이 있어서 라고 판단하였다고 합니다. (서비스를 사용할 것이다 라는 사용자의 경험에 대한 고려를 더 많이 한 포인트라고 생각되는 부분이지요!)메이코 이후 드디어 그분을 만들어 내는 것을 준비합니다.크립톤은 이때부터 정말로 사용자들이 무엇을 원하는가에 대한 생각을 많이 한 것 같다고 보이는 포인트입니다. 메이코의 등장 이후, "하츠네 미쿠"라는 캐릭터 산업으로 만들어 내는 것을 준비합니다. 그리고 해당 캐릭터를 하나의 "사업전략"으로 생각해 낸 이유는 메이코의 KPI달성도 있겠지만, "사람의 목소리와 극히 다른 목소리로 노래를 부르게 된다면, 이상하지 않을까?라는 부분을 오히려 역으로 기획, "인간이 아닌 다른 안드로이드가 하는 노래"라는 새로운 존재로서 IP를 만들어 버린 것이죠!또,  캐릭터를 기반으로 다양한 성격을 가질 수 있도록 "성우"라는 시스템을 집어넣어 "특별한 존재"라는 특징 성을 추가하였고, 기존의 보컬로이드는 "인간의 가수를 대체하는 것"이었으나, 하츠네 미쿠는 "안드로이드 가 부르는 진짜 보컬로이드"라는 접근을 통해 새로운 존재를 만들고, 메이코 디자인을 기반으로, "아이돌 라이즈 된 새로운 사이버 가수"를 만든 것이죠!아아.... 이제 고인이 되신 사이버 가수 아담... (http://beautinaru.tistory.com/196 또한, 해당 콘텐츠를 기반으로 음악을 만들었던 유저들에게 레트로 한 마크들을 집어넣어서 예전에는 이랬었지 라는 향수를 불러일으키고, 해당 콘텐츠를 기반으로 다시 작업을 할 동기를 줄 수 있도록 유저들의 의견을 듣고 반영하는 일들을 굉장히 많이 했다고 합니다!그리고 하츠네 미쿠의 진정한 아이덴티티를 생성합니다. 그것은 바로 Chain of Co-creation!!!하츠네 미쿠가 이렇게 성장할 수 있었던 이유는 저는 하나만 꼽으라 라고 한다면 이쁘잖아요! 가아니라... "확산 가능 여부"에 대한 많은 고려가 있었기에 가능했다고 생각합니다.인터넷 덕분에 음악 등을 만드는 사람들이 쉽게 업로드하고 공유할 수 있는 많은 플랫폼들이 생성되는 현실.덕이 많은 분들이 공유를 통해 자아실현을 하는 공감대를 형성할 수 있는 움직임이 확산.콘텐츠가 콘텐츠를 만들고 퍼져나가는 순기능적인 부분들이 늘어나는 현상들을 확인하고,2차 3차 저작물을 통한 확산> Chain of co-creation의 순선환 적인 기능들이 생겨나는 것이죠!! 그리고 그런 상황을 기반으로, 궁극적으론,모든 사람들이 제작자가 될 수 있는 현실 상황을 받아들이고,제작할 수는 있지만,  저작에 관련한 법률 등에서 막히는 상황을 막기 위해, 창작자들의 창작활동을 돕고, 실제 업로드된 콘텐츠를 기반으로, 실제 사업이 일어날 수 있는 방향으로 전개합니다!그리고 수익화를 통해서 창작자들이 창작활동 = 수익활동이 될 수 있도록 플랫폼 화를 추진한 것이죠!그래서 처음 하츠네 미쿠가 나온 2007년부터 10년이 지난 지금까지도 "보컬로이드"의 선두 주자로 전 세계적으로 콘서트를 다니며 성공적인 투어를 하고 있습니다.투어는 계속된다. (출처: http://mikuexpo.com/) 저는 하츠네 미쿠가 단지 덕후들의 승리라고 요만큼도 생각하지 않습니다.하츠네 미쿠를 성장시킬 수 있었던 건 "우리가 제공하는 서비스가 어떤 유저들에게 더 많은 강점이 있고, 해당 유저들은 어떤 행동을 통해서 자아를 성찰할 수 있을까? 그리고 해당 행동을 통해 유저가 얻는 궁극적인 이익들이 잇을까?"를 생각했던, 크립톤의 유저를 생각하는, 유저의 직접적인 경험을 서비스에 반영하려고 하는 강한 의지가 해당 서비스를 성공시킬 수 있게 한 요인이라고 생각해요. 그런 의미에서 저에겐 정말로 뜻깊고 즐거웠던 세션이었습니다!P.S.: 이제 슬슬 NDC2017 영상들이 올라오기 시작하네요! 관심 있는 분들은 https://ndc.nexon.com/main에서 확인해 보세요~오늘도 긴 글 읽어주셔서 감사합니다! 다소 글이 엉망진창이라도 이해해 주세요! #코인원 #블록체인 #기술기업 #암호화폐 #스타트업인사이트

저는 야놀자 CX 서비스실의 API 파트에서 백엔드(90%)와 웹 프론트엔드(10%) 프로그래머로 일하는 송요창입니다.개정된 근로기준법에 따라 2018년 7월 1일부터 300인 이상 규모 기업인 경우주 40시간(최대 52시간) 근로합니다. 이에 따라 야놀자에서도 업무 집중도 향상과 함께 업무 시간을 명시하는 방안이 논의되었습니다. 이런 배경 속에서 만들어진워크로그개발 경험을 이야기하겠습니다.개인의 업무 시간 작성근로 시간이 기존 대비 단축되면서 각 개인의 업무 시간을 기록하고 기준 근로 시간을 초과하였을 때 이를 소진하도록 하는 방향이 결정되었지만 어떤 도구를 사용할지가 문제였습니다. Timing, TMetric, 출퇴근 기록기 알밤 등 다양한 도구를 사용해서 각자 기록을 시작했습니다.1차 시도 - Workflow + Alfred 활용그러던 중에 캘린더를 이용해서 출/퇴근 기록을 남기고 슬랙(Slack)으로 메시지를 발송하는 방법을 CX 서비스실 강미경 님이 공유합니다.캘린더와 - 유료인 경우 - 슬랙 모두에 기록이 남는 장점이 있습니다. 사용하기 쉽습니다.iOS 앱인 Workflow를 이용해서 캘린더에 이벤트를 등록하고 슬랙으로 메시지를 전송.데스크톱이나 노트북은 Alfred의 Workflows 기능으로 해결할 수 있었습니다.Workflow + Alfred로 워크로그를 기록하는 단점개인적으로 편리했지만 CX 서비스실 내부로 전파하여 사용하기에는 문제가 있었습니다.안드로이드 휴대전화를 사용하는 경우 Workflow를 사용할 수 없습니다.아이폰을 쓰더라도 유료로 판매되는 Workflow를 사지 않으면 쓸 수 없습니다.Alfred를 쓰더라도 Power Pack을 구매한 사용자만 Workflows를 적용할 수 있습니다.2차 시도 - 슬랙봇 활용위에서 언급된 문제를 해결하고 구성원 누구나 추가 앱 설치 없이 손쉽게 접근할 수 있는 슬랙봇에 주목합니다. 캘린더가 아니라 데이터베이스를 활용해서 개발하면 어떨지 논의했습니다.늦은 저녁(대략 23시부터 03시)에 Firebase 실시간 데이터베이스(Realtime Database)와 Firebase 클라우드 함수(Functions)를 활용해서 단순한 슬랙봇을 만들었습니다.슬랙을 실행한 뒤 슬래시 커맨드(slash command)로 /wl 출근을 입력하면 출근 로그가 추가되고 완료 메시지를 수신합니다.슬랙의 3초 이내 응답 요구단순한 기능이었지만 슬랙봇을 활용해서 워크로그를 작성하는 동료가 조금 늘었을 때 치명적인 문제가 발생했습니다.슬랙의 슬래시 커맨드는 3초 이내로 응답할 때 완료 메시지를 노출합니다. 3초를 초과하면 아래 메시지를 노출합니다.Firebase 클라우드 함수로 작성한 코드에 문제가 있었습니다. 단순한 로그 데이터와 사용자 요청에 대한 기록을 모두 완수한 후에 응답을 보내도록 했습니다. 이 부분에서 응답 지연이 발생합니다.기록은 된다고 변명해봤지만, 사용자가 기록 여부를 알 수 없으니 재시도하는 횟수가 늘어났습니다. 중복된 데이터를 삭제 요청하는 사용자가 늘었습니다. 이런 불편을 겪고 초기 사용자가 이탈했습니다.위 문제를 제외하고도 다수 사용자의 특정 기간 내 로그를 모두 살펴보기에 슬랙봇은 그다지 좋은 도구가 아니었습니다.제가 잘 못 쓴 것이지 슬랙봇에게는 죄가 없습니다.3차 시도 - 웹페이지 도입앞서 말한 문제가 대두하기 전 다수의 로그를 살펴보기 위해 웹페이지를 제작 중에 있었습니다. 프로그래밍에는 야놀자 앱 하이브리드에서 다뤄본 React.js 외에 최근 소개받은 razzle, After.js를 사용했습니다(이에 관한 회고는 아래서 짧게 다룹니다).Firebase 실시간데이터 베이스에 쌓인 로그를 Firebase 클라우드 함수로 제작된 API로 사용자별, 일자별로 불러서 표시하는 정도로 개발 착수.웹페이지로 조회 기능을 만든 시점과 맞물려 슬랙봇이 무용지물이 되었습니다. 로그인 기능을 제작하고 웹페이지에서 워크로그를 추가할 수 있도록 했습니다. 기록과 조회가 웹페이지로 대체 된 것입니다????????.Firebase 인증은 정말 편리합니다.대형 이벤트이렇게 만들었지만 떠나버린 사용자를 돌아오게 만드는 일은 불가능했습니다. 저를 제외하고 몇몇 분들만 사용하는 소소한 서비스로 사라질 예정이었습니다. 그런데 CX 서비스실 실장이신 하희진 님이 전격적으로 CX 서비스실 전 구성원이 워크로그를 통해 기록을 남겨달라고 요청하셨습니다. DAU가 10배는 급상승했습니다(1~2명에서 20명 이상으로). 많은 트래픽????이 들어오니 부족한 기능과 어설픈 기록 시스템 등이 문제가 되기 시작합니다.엎친 데 덮친 격으로 초과 근무 차감이란 주 기능 오픈에 대한 관리자(희진 님)와 사용자의 요구가 커졌습니다.할 일이 넘쳐난다.DAU 20의 공포요구사항을 분석하고 구현하면서 미비한 규칙을 관리자와 자주 논의했습니다. 논의 결과에 따라 메뉴가 생겼다가 사라졌다가를 반복해서 사용자의 혼란이 가중되었습니다. 아직 제작되지 않은 관리자 기능 때문에 데이터베이스를 직접 수정하는 일도 빈번했습니다.무엇보다 갑자기 새로운 도구를 사용하는 사용자의 질문이 쏟아졌습니다. 주 40시간을 어떻게 측정할지, 초과근무시간의 근거나 법정 휴식시간 발생 요건 등 대부분은 규칙에 관한 질문이었습니다. 30분 안에 같은 질문을 5번 듣고 동일하게 답변하는 헤프닝도 있었습니다.???? 어디서 많이 본 모습인데? 바로 IT산업 전체에서 자주 일어나는 일입니다.점진적 개선우선 비슷한 질문을 모아 FAQ 페이지를 개설했습니다(우리 PO가 자주 하는 업무라서 배운 풍월이 도움이 되었습니다). 지나치게 사용자 기능을 제한하여 CS가 늘어난 측면이 있어서 규칙이 확정된 부분만 사용자 기능 제한을 풀었습니다.금주 내의 로그는 언제든 추가 및 수정할 수 있도록 변경했습니다.누적된 초과시간은 금주 중 언제라도 사용할 수 있도록 변경했습니다.한 주가 끝나면 잘못된 로그가 있는지 검사한 뒤 로그 수정 후 초과시간 확정하는 일은 하고 있습니다.배포되는 버전마다 변경사항을 문서에 남기고 전체 사용자에게 공지했습니다.차감 기능은 자투리 시간과 CX 서비스실 구성원의 배려로 개발하였습니다.다행히 6월에 태어난 둘째가 새벽 4~5시면 한 번씩 울어서 알람 없이 기상할 수 있었습니다????.개인 회고워크로그를 제작하면서 크게 2가지를 느꼈습니다.미비한 요구사항 분석은 개발 비용을 상승시킨다하나의 요구사항은 여러 기능을 필요로 합니다. 자세한 분석 없이 뇌내 망상으로만 개발에 착수했더니 구조를 변경하느라 시간을 많이 소모했습니다.초과 시간을 예로 들면 우선 차감 메뉴를 만들고 있었습니다. 그런데 차감에 근거가 되는 누적 시간이 없습니다. 그럼 누적을 기록할 수 있는 모델을 제작합니다. 1일 8시간 기준으로 기록하도록 개발합니다. 주 40시간이 넘을 때 초과 시간이 발생하는 규칙이라서 1주일 단위로 마감하는 방식으로 변경합니다.이렇게 우왕좌왕하며 개발하니 밀고 나가는 힘이 약했습니다. 프로덕트 개발 시 PO가 이 부분을 많이 돌봐줘서 기본 없는 프로그래머가 되었습니다(????).개발은 50%. 운영이 나머지 50%다마이너 버전이라도 개발을 완료하고 배포할 때마다 한고비 넘었다고 생각했습니다. 그렇지만 진짜 서비스가 단단해지는 것은 사용자를 만날 때부터였습니다.사용자는 관리자보다 인내심이 없습니다. 개선 사항을 슬랙을 통해서 말해주고, 잘못된 기록이 있으면 수정을 요구했습니다. 이상한 규칙이 발견될 때마다 피드백이 왔습니다. 정당한 요구와 피드백이지만 1인 개발자가 감당하기는 벅찬 부분이 있었습니다.피드백을 정리해서 수정할 부분을 JIRA에 정리하고 작업하기를 반복했습니다. 이 과정을 통해 초기보다 더 다듬을 수 있었습니다.저는 근무시간 중에만 CS 대응을 했음에도 피곤했습니다. 이런 일을 매일 매시간 겪고 있는 야놀자 PO와 IT 업계 동료들은 정말 대단한 사람입니다. 이 자리를 빌려 다시 한번 존경합니다.개발 관련 회고(신약???? 임상 결과)토이 프로젝트이기 때문에 회사에서 사용하는 기술 외에 새로운 기술을 다뤄봤습니다. React.js와 함께 엄청나게 사랑받고 있는 vue.js가 아닌 이유는 개발 시간이 촉박해서 공부할 시간이 없었다고 핑계 대봅니다.razzle + After.js = ????React.js를 사용할 때 주로 Next.js를 사용해왔지만 이번에는 razzle과 After.js를 사용했습니다.razzle은 create-react-app처럼 React.js 애플리케이션을 제작할 수 있도록 초기 구성을 도와줍니다. React.js 외에도 Vue, Angular, Preact, Elm 등을 지원합니다.After.js는 Next.js처럼 서버사이드 렌더링을 지원합니다. Next.js와 다르게 React Route 4를 이용해서 라우팅을 지원합니다.사용해본 소감은 razzle이 아무런 설정도 하지 않도록 도와주고 있어서 편리했습니다. TypeScript 도입도 예시가 있어서 쉽게 적용할 수 있었습니다. 코드 수정 후 웹페이지를 다시 로딩하는 핫 리로드(hot reload)도 잘 작동합니다. After.js는 서버사이드 렌더링 시 getInitialProps 를 사용할 수 있어서 Next.js에 익숙한 저에게 편리했습니다. 무엇보다 Next.js처럼 route를 변경하기 위해서 next-route에 의존하지 않아서 편리했습니다(대신 React Route를 의존합니다).저처럼 프로젝트 셋업을 어려워하는 초심자에게 유용합니다(검색할 때 사례를 더 많이 찾으려면 Next.js가 더 유리합니다).배포는 초기에 Aws의 beanstalk을 활용하다가 Zeit가 운영하는 now로 변경했습니다. Node.js나 docker에 익숙하고 커맨드 라인 인터페이스(cli)를 사용하는 데 어려움이 없다면 사용할만 합니다. 리전이 모두 해외라서 응답속도가 빠르진 않습니다.Zeit는 Next.js 프레임워크를 제작한 회사입니다.도움 주신 분???? 아이디어와 기획에 도움을 주고 사용자가 돼주신 R&D CX 서비스실 강미경 님???? 제보에 적극적인 R&D CX 서비스실 노현석 님DAU를 비약적으로 높여주신 R&D CX 서비스실 하희진 님미약한 사용성과 구린 UI임에도 잘 사용해주고 계신 R&D CX 서비스실 모든 구성원!!공감의 ????????! 눈물 흘리는 역할로 열연해주신 R&D UX/UI팀 김하연 님이 글을 리뷰해주신 유관종 님, 노현석 님, 구본한 님무엇보다 이런 프로젝트가 가능하도록 도와준 R&D CX 서비스실 내 API파트 전원에게 ????‍ 감사합니다.참고한 자료https://medium.com/evenbit/building-a-slack-app-with-firebase-as-a-backend-151c1c98641dhttps://api.slack.com/slash-commandshttps://firebase.google.com/docs/database/web/start#야놀자 #개발자 #개발팀 #문제해결 #버그수정 #백엔드 #인사이트 #경험공유

안녕하세요. 스타일쉐어 개발팀의 김현준입니다. 훌륭한 엔지니어링 경험을 공유하고 싶어 만든 블로그이지만, 아직까지는 그런 일이 없었던지라, 창피한 장애 경험을 공유하고자 합니다.배경:웹 서비스 디플로이는 프로덕션 웹 서버에서 업스트림 master를 풀 받아 리로드하는 방식으로 진행하고 있습니다.CSS, JS 등의 파일들은 CDN을 위해 매 빌드마다 디플로이 이전에 S3에 업로드합니다. Git 커밋의 SHA1 해시를 키로 사용합니다.장애:어제 새벽 서비스에 긴급한 패치가 있었습니다. 하지만 이 커밋은 8분 후 다시 롤백되는데…오늘 오후 디플로이 이후에 갑자기 웹 사이트의 스타일이 전부 깨져보이기 시작했습니다.심지어 아무리 커밋 로그를 살펴봐도 존재하지도 않는 커밋 해시로 파일을 요청하고 있었습니다.원인:롤백을 git revert 명령으로 하는 대신에, 이전 커밋으로 HEAD를 돌리고 git push --force로 업스트림을 덮어썼습니다.해당 커밋은 이미 디플로이가 되어있었지만, 되돌린 이후에 다시 디플로이를 하지 않았습니다.다음 디플로이할 때 해당 웹 서버 로컬에서 업스트림 master를 풀 받자, (개발자의 로컬이나, GitHub에서 보이는 커밋 트리와 달랐기 때문에) 서로 다른 커밋 해시를 가지게 되었습니다.404교훈:force-push를 (창피한 실수라던지, 지저분한 여러개의 커밋이라던지) 이력을 남기고 싶지 않을 때 사용하는 경우가 있는데요. 이는 위의 사례처럼 해당 커밋을 이미 풀 받은 다른 개발자의 로컬을 꼬이게 하거나, 장애를 유발할 수가 있습니다. 롤백을 하고 싶은 경우엔 revert 명령을, 커밋을 정리하고 싶은 경우엔 각자의 브랜치에서 충분히 rebase를 한 뒤에 올리는 습관을 꼭 가져야겠습니다.#스타일쉐어 #개발 #개발자 #개발팀 #인사이트 #후기 #일지

안녕하세요, Hyper-X에서 AI Camera Picai를 개발 중인 Android 개발자, Trent 입니다. 저는 지난 5월 8일부터 5월 10일까지 JH 님, Evan 님과 함께 다녀온 Shoreline Amphitheatre 에서 열렸던 Google I/O 2018 에 대해서 전하려고 합니다. Google I/O는 Mountain View, California에서 매년 6월에 열리는 Developer Festival로서, Sundar Pichai의 Google Keynote를 시작으로 Google의 새로운 기술들과 프로덕트를 선보이는 Session들이 3일에 걸쳐 진행되었습니다. 놀라운 AI 기술의 발전이 돋보였던 올해의 행사였습니다.SessionsKeynoteSundar Pichai의 Keynote로 시작된 올해의 행사에선 AI 기술의 발전과 그 활용이 단연 돋보였습니다. Google Duplex 가 Keynote의 가장 큰 화제였는데요, Google Assistant가 직접 헤어샵이나 식당 같은 업체에 전화하여 예약을 수행해주는 기능입니다. ‘음…‘같은 소리들을 포함하며 매우 자연스럽게 종업원과 전화를 하는 모습을 보였는데요, 어려운 질문들도 척척 대답하는 모습이 놀라웠고, Google의 ML 기술에 놀라움을 금치 못했습니다.또한 Google의 독보적인 AI 기술은 Google의 기존 서비스들에도 큰 변화와 개선점들을 가져왔는데요, Gmail 의 Smart Compose 기능이 그 중 하나입니다. 이메일 작성 시 문장 전체를 AI가 autocorrect 해주는 기능인데요, 반복적인 이메일 업무를 획기적으로 줄일 수 있을 것으로 기대되었습니다. 역시 Google의 엄청난 양의 데이터를 통해 이뤄낸 기술로 보입니다. 그 외에도 Google News의 자동 뉴스 큐레이션 시스템, Google Lens를 활용한 Google Maps의 AR 기능 등으로 기존 서비스들에 큰 변화를 선도해가는 면모를 보였습니다.Android P는 Adaptive Battery, Adaptive Brightness, App Actions, App Slices 등의 새로운 AI 기반 기능들을 Android에 가져왔습니다. 배터리를 30% 절약하고, 밝기를 자동으로 조절해주며, 시간 및 행동에 따라 연관된 앱들을 추천해주는 등 전반적으로 Android가 매우 똑똑해지는 부분을 보여 줬습니다. 이런 직관적인 AI 를 활용한 API 를 활용하면, 앱 개발자가 효율적으로 자기 앱의 접근성을 높일 수 있을 것으로 보입니다.또한 Android P 는 소소한 UX 개선 점들과 더불어 스마트폰 중독 방지 기능들을 탑재했습니다. 서양에서는 과도한 스마트폰 사용이 많은 사회적 문제가 되고 있는데요, 이를 방지하기 위해 App들에서 보낸 시간을 트래킹하고, App 시간 제한을 스스로 설정한다던가, 핸드폰을 뒤집어서 중요한 연락처의 전화가 아니면 받지 않는 등의 기능을 탑재하였습니다.What’s new in AndroidAndroid App Bundle 이 소개되었습니다. 하나의 패키지를 Google Play에 업로드 함을 통해 Android 디바이스가 필요한 리소스만 다운받을 수 있게 해주는 시스템인데요, 이미 Twitter, LinkedIn 등의 어플리케이션에 적용되어 20% 가 넘는 APK 사이즈 개선을 이뤄냈다고 합니다. 저희 팀이 개발 중인 Picai에도 APK 사이즈 문제가 있는데, 이를 통해 해결 가능할 것이라 생각하고 큰 기대를 하는 중입니다. 차후 버전인 Android Studio 3.2 버전부터 지원합니다.Android Jetpack 이 소개되었습니다. Support Library, Architecture Components, KTX 등의 라이브러리를 통합한 모양새 인데요, 이와 함께 AndroidX 로의 패키지 명 변경이 이뤄지었습니다. 그 외에도 새로운 Navigation 라이브러리, WorkManager 라이브러리 등이 소개 되었습니다. Google의 새로운 Android 개발 Best Practice 제시라고 할 수 있겠습니다. Picai에서 이미 적극적으로 사용하던 기술들이라 큰 감흥은 없었는데요, Google이 직접 나서서 Android 개발자 에코시스템을 정리하려는 노력은 좋았습니다.또한 Kotlin의 전반적인 지원 확대와 다양한 라이브러리들에 대한 소식, Android Studio 의 많은 내부 변경 및 Energy Profiler, Google Assistant와 관련된 다양한 API 들 제공, Android P에 변경된 Background 카메라 및 마이크 권한 제한 및 ImageDecoder 등에 대한 뉴스 및 다양한 안드로이드 최적화에 관한 세션이 있었습니다. 특히 Android Testing 관련 세션이 매우 인상깊었는데요, 모든 Android 테스팅에 관련된 불편함을 해결해 줄걸로 기대했지만 아쉽게도 런칭이 아직 안됬는지, 컨퍼런스 밖에서는 자취를 찾을 수 없었습니다... And MoreFirebase ML Kit 및 TFLite(TensorFlow Lite) 에 대한 발표가 인상깊었습니다. 머신러닝에 대한 접근성을 높여 어떤 개발자라도 ML을 활용한 콘텐츠를 쉽게 만들게 할 수 있도록 노력하는 모습이 돋보였습니다. 컨퍼런스 후 팀원들과 함께 자세하게 검토를 해보았으며, 아직 여러가지 제약사항이 있어 적극적으로 쓰고 있진 않지만, 앞으로의 간편한 ML 활용에 대한 기대를 불러일으키는 세션들이었습니다.Google의 새로운 Cross-Platform Framework Flutter 에 대한 세션도 참가하였는데, 개발 난이도가 쉬워 보이고 좋은 애니메이션의 UI Component 들이 제공됨은 동의 함에도 기능 분리 적인 면에서 노력이 많이 필요하겠다는 생각이 들었습니다. Hyper-X의 여러 팀들에서 도입을 검토로 하고 있지만, 아직 실무에서 적용하기는 시기 상조로 보였습니다.Snapchat Camera API 에 대한 설명을 들었는데, 기기 및 유저 데이터 기반으로 두 버전의 Camera API 및 캡쳐 메커니즘을 전부 지원하는 백엔드를 세세히 설계한 부분이 매우 인상 깊었으며, 차후 Picai에 직접 적용해보고 싶다는 생각을 가지게 되었습니다. 특히 관련하여, Fragmentation이 심한 Android Camera의 Testing을 어떻게 진행하나 궁금하여 강연 후 연사에게 찾아가 여쭤보았는데요, 만족할 만한 수준의 대답은 아니었지만 향후 Picai를 개발 함에 있어 자신감을 가질 수 있게 하는 답변을 받았습니다.Office Hour개인적으로 Google I/O 참가하면서 기대했던 것은 Office Hour 인데요, Jake Wharton, Kotlin 개발팀, Flutter 팀, TFLite 팀 등을 직접 만나서 질문을 할 수 있었다는 것이 기대되었습니다. Kotlin 개발팀과 바람직한 Kotlin 코드 스타일(Effective Kotlin 유무) 및 Jetbrains가 지향하는 패러다임(FP vs OOP), Kotlin Native의 런칭 일정 및 Coroutine 후 추가 목표 피쳐 등에 대해 토의하였으며, Flutter 팀에게는 Dart 채택 이유와 Flutter가 적합한 어플리케이션 타입이 무엇이냐에 대해 물었고, TFLite 팀에게는 회사 동료의 ML에 관한 질문을 슬랙으로 전달하고 답변 받는 등 뜻깊은 시간을 보냈습니다. Google I/O TipsUber 사용법을 숙지하라Silicon Valley 답게 차를 렌트하지 않은 경우 Uber를 통해 대부분 이동하게 되는데, Shoreline Amphitheatre 근처에서는 주차가 금지되어서 특정한 Uber 존으로 이동하여 차를 잡아야 합니다. 이 위치를 인지 못하고 앱만 보면서 돌아다니게 되면 길을 잃기 쉬우니, 주의하여 미리 탑승 존을 인지하면 좋습니다. 특히 야간에는 사람이 몰려서, 주의하여야 합니다. 오히려 더 아래쪽으로 내려와서, Google Campus 내에서 잡는 게 좋을 수도 있습니다.또한 Uber 운전사한테 얻은 정보인데요, Ride-sharing을 하는 Uber 플랜을 사용하면 운전사들이 쉽게 취소한다고 하니, 조금 비싸더라도 개인으로 탑승하는 Uber 플랜을 사용하는 것이 좋다고 합니다.복장을 조심하라(?)캘리포니아는 6월에 더울때는 엄청 덥고, 추울때는 엄청 춥습니다. 특히 야외에서 오래 돌아다녀야 하기 때문에, 충분한 대비가 필수 입니다. 후디같은 옷을 입으시거나, 얇은 외투를 입는 등 충분히 준비해가면 좋습니다. 저는 행사장에서  CODE 가 젹혀진 후디를 구입해서, 매일 입고 다녔는데요, 매우 유용했습니다. 선크림 같은게 제공되긴 하지만, 그래도 제때 실내에서 휴식을 취하고 물을 많이 마시는 것이 좋습니다.마치며행사장을 돌아다니며 구글의 생태계에 푹 빠져 볼 수 있었던, 뜻깊은 경험이었습니다. 특히 그들이 곧 완성되고 릴리즈 된다고 자신하는 새로운 기능들은 상상하지 못했던 것들이라 놀라웠고, 이 시점에 직접 볼 수 있다는 것이 감사했습니다. Hyperconnect에서도 Mobile AI의 심화된 적용을 위해 많은 노력을 하고 있는데요, Azar 및 새로 시도하고 있는 Picai 같은 앱들을 통해 더 특별한 가치를 제공할 수 있도록 노력하고 있으니, 많은 기대 바랍니다!링크Android PApp BundleAndroid JetpackAndroidXML KitTFLiteFlutter#하이퍼커넥트 #개발자 #이벤트 #구글 #참여후기 #꿀팁 #인사이트 #이벤트참여 #미국 #캘리포니아

Sketch App 도입은 Zeplin을 활용하여 효율적으로 개발자와 소통하기 위해 시작되었습니다. 도입하는 과정에서 안드로이드 UI를 담당하게 되었고, 심볼의 구조화와 적절한 플러그인의 사용을 통한 작업의 효율, 가지고 있던 문제점들을 해결하는 것에 중점을 뒀습니다.기존 작업방식과 문제점디자인 작업 패턴디자인 작업 패턴을 분석했을 때, 기존의 PSD 파일들에서 컴포넌트를 가져와 재조합하는 경우가 가장 많았습니다. 디자이너간 협업 시 최근 릴리즈된 디자인이 맞는지, 요소간 간격 같은 디테일한 부분에 대해 묻는 경우가 많았으며, 개발자와의 협업 시 지칭하는 용어가 달라서 생기는 커뮤니케이션 미스가 종종 발생했습니다. 구조화에 앞서, 분석하고 내린 작업의 키포인트는 다음과 같습니다.1. 최근 릴리즈된 디자인이 영향을 받는 모든 화면에 동기화되어야 합니다.2. 개발자와의 협업 시, 심볼의 네이밍을 기준으로 커뮤니케이션합니다.3. 디자이너가 사용 시, 시안 작업을 빠르고 편하게 할 수 있어야 합니다.4. 컴포넌트, 디자인 요소들이 서로 유기적으로 연결되어있어야 합니다.5. 시안 작업 시, 유저 데이터를 사용하기 편리해야 합니다.심볼 생성 기준심볼로 만들어야 하는 경우는 다음과 같이 정의했습니다.1. 다양한 상태값을 가진 요소2. 같은 크기의 영역 안에서 다양한 형태를 가진 요소3. GNB처럼 자주 쓰이는 컴포넌트4. 카드 형태의 디자인5. 아이콘Overrides 예시심볼 폴더 구조심볼 폴더 구조디자이너들이 사용하기 때문에 첫 번째 분류는 보이는 형태, 디자이너끼리 자주 사용하는 용어로 합니다. 두 번째 분류는 원활한 커뮤니케이션을 위해 목적 혹은 개발자분들이 사용하는 용어로 지정하며, 세 번째 분류까지 해야하는 경우 2 Column, 3 Column(스타일쉐어 내부에선 Grid라는 용어를 주로 사용합니다.)과 같은 다양한 변화에 대한 것이므로, 똑같이 커뮤니케이션에 용이하게 판단하여 결정합니다.Elements 폴더는 심볼을 구성하는 심볼들이 있는 폴더입니다. 직접 심볼 폴더트리를 타고 들어가 생성하는 경우는 없으므로, 분류에 더 목적을 두고 폴더 구조가 복잡해지는 것을 감수했습니다.그리고 Overrides를 대비하여 이해하기 쉬운 용어로 작성합니다.심볼의 활용자주 쓰는 컬러들을 심볼화하고 마스크 기능을 활용하면, 아이콘들의 색상을 더 편하게 변경할 수 있습니다. 추후에 브랜드 컬러, 그레이스케일이 변경되는 경우에도 컬러 심볼만 수정하면 큰 문제없이 바로 적용할 수 있습니다.플러그인의 활용작업에 주로 사용하는 플러그인은 Auto Layout, Button, Clipboard Fill입니다.Auto Layout의 Stacked Group 기능으로 심볼이나 요소들을 유기적으로 연결시킵니다. Button은 Tag, List item 등에 사용하며 짜잘한 수정작업을 줄여 시안작업에 더 집중할 수 있도록 합니다. Clipboard Fill은 스타일쉐어 특성때문에 활용 가치가 높은 플러그인입니다. 유저 이미지, 게시글의 사진을 스타일쉐어 웹에서 복사하여 시안을 작업할 때 활용합니다. 실 데이터를 사용하기 때문에 설득력이 높아지고, 조금 더 객관적으로 작업할 수 있다는 장점이 있습니다.플러그인 사용 Gif페이지 구성모든 화면이 모여있는 Master_Android.sketch 파일에서는 페이지로 분류합니다. 이 분류와 구글 드라이브 폴더 구조를 일치시켜 빠르게 파일을 찾을 수 있도록 하였으며, 탐색이 용이하기때문에 새로운 디자이너가 오더라도 쉽게 파악가능합니다.디자인 작업 프로세스시안 작업 시, 실제 데이터를 사용하여 설득력을 높이는 것을 가장 큰 목표로 합니다.1. 디자인 작업 전, 사용할 심볼들을 모두 Detatch합니다.2. 문제해결에 맞게 컴포넌트를 디자인합니다.3. 플러그인을 활용하여 웹에서 실제 데이터들을 가져와 채웁니다.4. 시안 작업이 끝난 후, 정리하여 Zeplin으로 내보냅니다.5. 심볼을 만들어야 한다면, Master파일 Symbols에 업데이트합니다.6. Master파일에 심볼을 사용하여 화면을 정리합니다.이 과정에서 생기는 큰 문제점은 모든 작업자가 심볼 구조화에 같은 기준을 가지고 있어야 한다는 점입니다. 생성 여부, 심볼 이름을 정하는 규칙 등에 대해 문서화하여 공유해도 익숙하지 않기때문에 실수가 생기기 마련입니다. 그래서 안정화되기까지 첫 구조를 잡았던 담당자가 정기적으로 확인하여, 다듬어나가는 것으로 결정했습니다. 비효율적인 방법일 수도 있지만, 동시에 구조화를 더 탄탄하게 하는 기회였습니다.잘가 포토샵.Sketch App의 업데이트에 따라 해결할 수 있는 방법이 달라지는 경우가 많았습니다. 그에 대비하여 의존성을 줄여나가는 고민을 계속하고 있으며 UI 뿐만 아니라, 작업툴 사용에 제약이 없다는 조건 하에 Overrides 기능과, Clipboard Fill, Auto Layout을 활용하여 다양한 템플릿 작업에도 사용할 수 있다고 생각합니다.#스타일쉐어 #개발팀 #개발자 #개발환경 #인사이트