[자료제공: NHN] - 3년 만에 다시 오프라인으로… 6,500명이 넘는 사전 참가 신청자 기록, 추첨을 거쳐 2,500여 명 참가자 초청 - 키노트에서 NHN 그룹사의 주요 기술분야 리더가 등장해 NHN 기술 개발 여정 공유 - ▲AI ▲클라우드 ▲백엔드 ▲프런트엔드 ▲인프라/보안 ▲성능개선 ▲데이터활용 ▲UI ▲협업툴 등 총 42개 세션에서 참가자에 ‘전문 개발지식 전수’와 ‘기술 트렌드 공유’ 발표 엔에이치엔이 오늘(24일) 삼성동 그랜드 인터컨티넨탈 서울 파르나스에서 기술 컨퍼런스 ‘NHN FORWARD’를 열였다. 3년 만에 다시 오프라인으로 개최한 NHN FORWARD에는 6,500명이 넘는 신청자가 사전 참가 신청을 하며 행사에 뜨거운 관심을 보였다. 사전 참가 신청자 가운데 추첨을 거쳐 행사 당일에는 2,500여 명의 참가자가 행사에 참석했다. 이번 행사 키노트에는 NHN 기술위원회를 총괄하고 있는 박근한 이사를 필두로 게임기술센터장 류희태 이사, NHN DATA 이진수 대표, NHN Cloud 김명신 CTO 등 NHN의 주요 기술 리더가 나와 현재 NHN이 글로벌 톱 티어 테크 기업을 목표로 실행하고 있는 기술 개발 여정을 소개했다. 키노트에서 박근한 이사는 NHN 기술위원회 수장으로서 “NHN이 제공하는 클라우드/AI, 게임, 결제, 광고, 커머스, 콘텐츠 등 다양한 서비스의 원천은 역시 기술”이라며 “각 분야 기술의 유기적 연결을 바탕으로 가치를 드높이며 앞으로도 최신 기술을 모든 사람들이 편리하게 누릴 수 있도록 노력해 나가겠다”고 강조했다. NHN 게임기술센터장 류희태 이사는 게임기술 개발 리더로서 NHN의 캐주얼 게임 제작 노하우를 녹여 만든 신규 퍼즐 게임 개발 엔진 ‘엠브릭’을 선보였다. 또한 NHN DATA 이진수 대표는 NHN DATA의 글로벌 사업 청사진과 데이터 기반 기술의 방향성을 제안했다. 이어 NHN Cloud 김명신 CTO는 클라우드 기술 리더로서 내년 개소 목표로 건립 중인 ‘광주 국가 AI 데이터센터’를 포함한 데이터센터 확대 전략과 표준을 준수하는 클라우드 네이티브 플랫폼, 통합 메시징 플랫폼 ‘노티피케이션’ 서비스 등 사업과 기술 성장 내용을 소개했다. 이어진 트랙별 세션에서는 ▲AI ▲클라우드 ▲백엔드 ▲프런트엔드 ▲인프라/보안 ▲성능개선 ▲데이터활용▲UI ▲협업툴 등 다양한 주제의 총 42개 세션으로 ‘전문 개발지식 전수’와 ‘기술 트렌드 공유’를 아우르는 폭 넓은 발표들이 진행됐다. 특히 ▲시스템 부하를 분산하여 처리하는 방법을 공유하는 <편안한 휴식 시간을 지켜줄 안정적인 백엔드 운영과 개발 기법>, ▲AI로 나를 닮은 캐릭터를 만드는 기술과 개선 방안을 설명하는 <Face Style Transfer: 만화로 그린 내 얼굴은?>, ▲NHN Cloud에서 새로운 API 개발을 설계하고 구현 방식을 소개하는 <API 우선 접근 방식과 OpenAPI Specification> ▲게임 개발에서 클라이언트 성능을 향상 노하우를 담은 <Unity에서 Web Cache와 성능 향상: CacheStorage의 활용>, ▲변화무쌍한 커머스 서비스의 리소스 사용량에 대응하기 위해 클라우드 서버로 이전하는 과정을 담은<더 나은 이커머스 서비스를 위한 클라우드로 이전하기> ▲효과적인 쿠폰 마케팅 캠페인의 방법론을 소개하는<정말 마케팅 때문에 매출이 증가했을까?, 페이코 쿠폰 마케팅 타깃 선정 전략 수립 및 효과 분석> 등 기술/개발 실무에 도움이 되는 세션들이 발표돼 참가자의 호응을 얻었다. 아울러 행사장 별도 공간에서는 기술과 일상 생활을 주제로 경험을 공유하는 ‘라운지 토크’, NHN을 비롯해 코오롱베니트, 인텔코리아, 레드햇코리아, 깃허브, 이테크시스템 등 기술기업이 자사 서비스를 소개하는 ‘전시 부스’, 참가자가 유익하게 즐길 수 있는 ‘이벤트’ 등이 열려 발표 세션 외에도 참가자의 높은 행사 참여를 이끌었다. NHN 기술위원회 박근한 이사는 “NHN은 기술로 자사 서비스와 외부의 이용자를 연결하고 있는 만큼 기술을 공유하는데 누구보다 앞장서고 있다”며, “이 같은 기술 공유 문화를 바탕으로 글로벌 톱 티어 테크 기업으로 성장하고 궁극적으로는 더 나은 세상을 만들어 나가겠다”고 말했다. 한편, 올해 5회째를 맞은 NHN FORWARD는 ‘Small Steps Big Difference(작은 발걸음이 큰 차이를 만든다)’의 슬로건 아래 개발자들과 기술 및 개발 지식을 공유하고, 실무 고민을 함께 나누는 자리로 마련되고 있다. 라이엇 공지사항 둘러보다가 이상하게 여기만 불친절하게 번역이 안되어 있길래 봤는데 별 내용도 아닐 뿐더러 왜 안했는지 알겠더군요 지금 신클라 문제점이 몇가지 나오는 중인데 민망할정도로 찬양일색이라.. 번역이 발퀄이라 보시는분들 입장에서 이해 할지도 모르겠고 정작 번역해보는 저도 용어가 너무 생소하고 특히 기술적인 부분들이그렇네요 의역도 심하게 되있고 오역은.. 아마 없을거임 ㅡㅡ 걍 심심해서 해봤습니다 반갑습니다! 저는 앤드류(Andrew Mcveigh)이고 라이엇에서 소프트웨어 아키텍쳐 분야를 담당하고 있습니다. 리그오브레전드 클라이언트를 새로 뜯어고치는데 막바지에 다다랐고 우리는 클라이언트 업데이트라고하죠. 이 글에서 저는 이 업데이트의 소프트웨어 기술에 대해 간략하게 설명할 것이고, 우리가 선택해야만 했던 그 이유와 배경들을, 그리고 현재(구버전)의 한계에 대해서 짚어낼 예정입니다. 왜 클라이언트를 바꾸는가? 지금의 클라이언트는 2008년에 프런트엔드기술인 어도비에어로 만들었습니다. 그리고 애니메이션과 효과를 제공했습니다. 빠르게 7년이란 세월이 지나면서
2015년이 되었고 주목할만한 세가지 문제점이 에어 클라이언트에서 극명하게 대두되기 시작했습니다. 새로운 기술구조만이 해결하는 문제였죠. 문제 #1 - HTML5의 표준화 HTML5와 자바스크립트는 독자적인 데스크톱 클라이언트 기술이 되었습니다. 문제 #2 - 소환사들은 게임에 떠나도 계속 접속하길 원했습니다. 문제 #3 - 라이엇 개발자들은들은 조화롭게 일하길 원합니다. 놀라운 아키텍쳐로의 확장. 이러한 문제점들을 해결하기 위한 몇가지 방법이 있습니다.
단계 A : 자바스크립트는 세계의 왕이다! 이 라이브러리는 자바스크립트가 RTMP를 통해 송수신이 가능하게 하죠. 내부 몇가지 프로토타입을 가지고 우리는 ember.js를 단일 페이지 응용 프로그램으로, ember-orbit을 데이터 레이어로 사용하기로 결정했습니다. 어떤 문제점이 생겼을까요? 몇가지가 나타났습니다. 웹티어에서 비동기 작업을 처리하다보니 자바 스크립트 코드가 매우 복잡해기 시작했습니다. 더 나아가 플레이어의 상태가 자바스크립트 상태다 보니 우리가 메모리 쉬이 점유율을 낮출 수 없었죠. 그래서 이 아키텍쳐는 상기된 1번 문제를 해결할진 몰라도 2번 문제나 3번문제에는 아무런 도움이 되지 못했습니다. 단계 B : 웹응용 프로그램(그러나 데스크톱에서)의 재발견! 우리는 일반 웹 응용프로그램들이 어떻게 설계되었는지 생각하기 시작했고 중간 단계 부분을 빼먹었다는것을 깨달았습니다. 아래의 다음 사진은 Swagger UI로 기반 패치 리소스의 일부를 보여주고 있는 사진입니다. 또한 우린 이 아키텍쳐에서 추가적인 이점을 발견 할 수 있었는데요. 단계 C : 한발자국씩.. 다음단계는 확장성 아키텍처를 추가하는것입니다. 개발팀들이
마이크로서비스와 기능을 개발하기 시작하면서 새로운 문제에 직면했습니다. 확장성에 대해 알기 쉽게 비유하자면, 열명의 사람들이 하나의 책을 쓴다고 생각해보세요. 저희는 비슷한 문제를 클라이언트 업데이트에서 겪었습니다. 저는 이 확장성 아키텍쳐 작업에 상당한 시간을 소비했고 개발자간의 충돌 문제에 대해 어떻게 라이엇이 해결했는지 잘 알고 있습니다. 그래서, UI 화면이나 기능들이 우리가 부르는 프론트엔드(FE) 플러그인으로 들어가고 C++ 커뮤니케이션 로직은 (말도 어렵게 생긴)백엔드(BE) 플러그인으로 들어갑니다. 이 아키텍처로 옮기는 과정에서 저희는 우리만의 획일적인 자바스크립트 데이터 레이어를 풀어야했습니다. 그래서 우린 Orbit을 사용하는걸 포기하고 프론트엔드 플러그인들이 가지고 있는 단순한 리소스 캐쉬를 사용했습니다. 단계 D : N 자바 스크립트 개발자에게 그들이 가장 좋아하는 MVC 프레임워크를 물어봤고 N+1의 답을 얻었습니다. 우리는 각 기능팀이 자체적으로 그들만의 자바 스크립트 프레임워크를 선택 할 수 있도록 허용했습니다. 그러나 이번에 닥친 문제는 개발자 문제였습니다. 일부팀은 Ember.js를 좋아하지 않았고 웹 구성요소를 사용하길 원했습니다. 이 시점에서 우린 단지 개발자의 기호 때문에 "모든것을 Ember.js로"라는 규칙을 완화 시킬 순 없었죠. 터닝포인트는
모든 사람들을 Ember로 강요할 수 없단것을 우리가 깨달았을때였습니다. 상기에 잠재적이란 단어에 유의해주세요. 최종 설계 업데이트 된 클라이언트는 앞에 언급되었던 세가지 근원적인 문제를 잘 해결하고 있습니다. 우리는 앞에서 언급했던 개발자를 상대로한 설문조사를 다시 시행했고, 대략 15%가 상황이 향상되었음을 그리고 빠르게 상승하고 있음을 나타내 주었습니다. 한 개발자는 우리가 데스크톱에서 데이터 센터를 만들었다고 말하기도 했습니다. 질문이 너무 많아 이 게시물에서 다루지 못한 내용도 있습니다. 흥미로운 주제이고 많은 관심이 있으시다면 이러한것들을 가지고 심도있는 대화를 다음에 해보겠습니다. |