Amazon Web Services 한국 블로그

Amazon Linux 2017-09 버전 업데이트 출시

https://media.amazonwebservices.com/blog/2017/announcing_amazon_linux_2017_09_400x218_1.gif최신 Amazon Linux 버전 AMI (2017.09) 업데이트를 발표합니다. 최신 AMI에는 EC2에서 실행되는 응용 프로그램에 안정적이고 안전한 고성능 환경을 제공하도록 설계된 지원 및 유지 관리되는 Linux 이미지가 포함되어 있습니다.

간편한 업그레이드
두 개의 명령을 실행하고 리부팅하여, 기존 인스턴스를 업그레이드 할 수 있습니다.

$ sudo yum clean all
$ sudo yum update

다양한 기능
AMI에는 많은 새로운 기능이 포함되어 있으며이 중 많은 기능이 고객의 요청에 따라 추가되었습니다

  • Kernel 4.9.51 – 4.9 안정 커널 시리즈를 기반으로하는이 커널에는 ENA 1.3.0 드라이버와 함께 TCP Bottleneck Bandwidth 및 RTT (BBR)가 지원됩니다. ENA에 대해 자세히 알아 보려면 블로그를 참고하세요.   BBR을 사용 가능하게 설정하는 방법은 출시 정보를 살펴보세요.
  • Amazon SSM Agent – Amazon SSM Agent가 기본적으로 설치됩니다. 즉, 이제 EC2 실행 명령을 사용하여 추가 설정없이 인스턴스에서 스크립트를 구성하고 실행할 수 있습니다. 자세한 내용은 Systems Manager를 사용한 명령 실행블로그 글을 살펴 보세요.
  • Python 3.6 – Python의 최신 버전이 포함되어 있으며 virtualenvalternatives을 통해 관리 할 수 있습니다. 다음과 같이 Python 3.6을 설치할 수 있습니다.
    $ sudo yum install python36 python36-virtualenv python36-pip
  • Ruby 2.4 – 2.4 버전의 Ruby 최신 버전을 사용할 수 있습니다. 다음과 같이 설치하십시오.
    $ sudo yum install ruby24
  • OpenSSL – AMI는 OpenSSL 1.0.2k로 업데이트되었습니다.
  • HTTP/2 – HTTP/2 프로토콜은 AMI의 httpd24, nginx 및 curl 패키지에서 지원됩니다.
  • 관계형 데이터베이스Postgres 9.6 및  MySQL 5.7 를 사용할 수 있으며 다음과 같이 설치할 수 있습니다.
    $ sudo yum install postgresql96
    $ sudo yum install mysql57
    
  • OpenMPIOpenMPI 패키지가 1.6.4에서 2.1.1로 업그레이드되었습니다. OpenMPI 호환 패키지를 사용할 수 있으며 이전 OpenMPI 응용 프로그램을 빌드하고 실행할 수 있습니다.
  • 추가 사항 –  Squid 3.5, Nginx 1.12, Tomcat 8.5GCC 6.4 패키지 등이 업데이트 되었습니다.

정식 출시
본 AMI를 사용하여 모든 AWS 리전에서 EC2 인스턴스를 시작할 수 있습니다. EBS 및 Instance Store 기반 인스턴스에서 사용할 수 있으며 HVM 및 PV 모드를 지원합니다.

Jeff;

이 글은 Now Available – Amazon Linux AMI 2017.09 의 한국어 번역입니다.

AWS 주간 소식 모음 – 2017년 10월 9일

안녕하세요! 여러분~ 매주 월요일 마다 지난 주에 업데이트된 국내 AWS관련 콘텐츠를 정리해 드립니다. AWS 클라우드에 대한 새로운 소식을 확인하시는데 많은 도움 되시길 바랍니다. 혹시 빠지거나 추가할 내용이 있으시면, 저에게 메일 주시면 추가 공유해 드리겠습니다.

aws-korea-weekly

AWS코리아 블로그

AWS 관련 뉴스 및 추천 콘텐츠

AWS 글로벌 신규 소식 (영문)

AWS 제품별 블로그(영문)

AWS 주요 행사 온라인 세미나

AWS 공인 교육 일정

AWSKRUG 소모임

AWS 관련 새 소식을 확인하고 싶으시다면, 매주 업데이트 되는 AWS 주간 소식 모음을 살펴 보시기 바랍니다! 좀 더 빠르게 새소식을 접하시고 싶다면, 공식 트위터공식 페이스북을 팔로우 하세요!

이번 한주도 즐겁게 보내시고, 다음주에 다시 만나요!.

– AWS코리아 마케팅팀;

Amazon EC2 Container Service(ECS) 서울 리전 출시!

드디어 오늘 Amazon EC2 Container Service (Amazon ECS)를 아시아-태평양(서울) 리전에 출시합니다.

Amazon ECS는 Docker 콘테이너를 프로덕션 환경에 배포 및 확장하기위한 관리 서비스로서, Amazon ECS를 사용하면 클러스터 구성에 필요한 서버 용량을 추가하고, 콘테이너 이미지를 업로드 할 수 있습니다. Amazon ECS는  서버 클러스터 전체에 콘테이너를 배포하고 상태를 모니터링하며, 콘테이너 부하 분산 및 크기 조정을 처리하는 동시에 데이터베이스 및 기타 리소스에 대한 각 콘테이너 접근 제어를 안전하게 할 수 있도록합니다.

Amazon ECS는 이미 다양한 한국 고객들이 콘테이너 기반 애플리케이션에서 사용하고 있습니다. 삼성SDS  신우용 상무는 “AWS 클라우드를 선택한 이유는 Amazon EC2 컨테이너 서비스(Container Service)를 이용한 첼로 구축 POC를 진행하여 2시간 이내로 아주 빠르게 첼로를 구축할 수 있었고, 네트워크 응답 속도도 빠르고 안정적이었다. AWS 클라우드 서비스를 이용하여 고객에게 첼로를 빠르고, 안정적으로 서비스 할 수 있게 됐다”라고 설명하였습니다.

또한, 삼성전자 장수백 상무는 삼성 IoT 서비스인 Samsung Connect 구축을 위해 “오토 스케일링(Auto scaling) 적용, 아키텍처 재정비, 지역적이고 분산된 개발, 자동화 되고 독립적인 배포 및, 다양한 서비스에 최적화될 수 있는 인스턴스 타입이 적용돼야 한다. 이에 대한 적절한 해법이 AWS 클라우드를 사용한 마이크로 서비스 아키텍처(Micro services architecture) “라고 소개했습니다. 특히, 삼성전자 송주영 선임은 Samsung Connect를 위한 Amazon ECS 활용 사례를 들어 “Amazon ECS는 AWS 상의 멀티 계정을 지원하여, 다양한 보안 및 접근 제어, 그리고 확장성 및 비용 절감과 기술 지원을 받을 수 있다”라고 밝혔습니다.

좀 더 자세한 정보는 아래에서 주요 기업들의 사례를 보실 수 있습니다.

다양한 동영상을 통해 Amazon ECS에 대한 내용을 살펴 보실 수 있습니다.

지난 AWS DevDay에서 있었던 콘테이너 트랙의 최선 정보도 참고하시기 바랍니다.

Amazon ECS 서울 리전 출시와 함께, 앞으로 콘테이너 기반 서비스를 하는 많은 한국 고객들의 활용 방법도 안내해 드리도록 하겠습니다. 자세한 내용은 Amazon ECS 제품 페이지설명서블로그를 참조하십시오.

윤석찬 (Channy);

AWS 주간 소식 모음 – 2017년 10월 2일

안녕하세요! 여러분~ 매주 월요일 마다 지난 주에 업데이트된 국내 AWS관련 콘텐츠를 정리해 드립니다. 추석 연휴에도 어김없이 찾아 왔습니다. AWS 클라우드에 대한 새로운 소식을 확인하시는데 많은 도움 되시길 바랍니다. 혹시 빠지거나 추가할 내용이 있으시면, 저에게 메일 주시면 추가 공유해 드리겠습니다.

즐거운 연휴되세요~

AWS코리아 블로그

AWS코리아 발표 자료

AWS코리아 동영상

AWS 관련 뉴스 및 추천 콘텐츠

AWS 글로벌 신규 소식 (영문)

AWS 제품별 블로그(영문)

AWS 주요 행사 온라인 세미나

AWS 공인 교육 일정

AWSKRUG 소모임

AWS 주요 파트너사 블로그

AWS 관련 새 소식을 확인하고 싶으시다면, 매주 업데이트 되는 AWS 주간 소식 모음을 살펴 보시기 바랍니다! 좀 더 빠르게 새소식을 접하시고 싶다면, 공식 트위터공식 페이스북을 팔로우 하세요!

이번 한주도 즐겁게 보내시고, 다음주에 다시 만나요!.

– AWS코리아 마케팅팀;

Lumberyard, Github에 소스 코드 공개

아마존이 만들고 있는 게임 엔진인 Lumberyard 소스 코드를 공개합니다.  공식 저장소는 Github에서 확인할 수 있습니다. Lumberyard 엔진은 게임 개발에 있어 다양한 도움을 주고 있으며, 소스 코드를 통해 아래에 크게 두 가지 혜택을 받을 수 있습니다.

1. Github통하여Lumberyard 받기
지금까지 Lumberyard 코드를 받는 유일한 방법은 표준 설치 프로그램을 사용하여 Lumberyard를 설치하는 것이었습니다. 이렇게하면 원본을 포함하여 모든 Lumberyard가 시스템의 새로운 별도 폴더에 복사됩니다. 우리는 개발자 커뮤니티의 의견을 반영하여, Github를 통한 더 쉬운 점진적 엔진 업그레이드를 지원하게 되었습니다.

이제 GitHub 저장소에서 Lumberyard 소스 코드를 직접 가져와 GitHub를 통한 코드 관리를 할 수 있습니다. 이제 Lumberyard의 새 버전을 통합하는 작업은 비교적 간단해졌습니다. 그리고 Lumberyard가 새로 출시 될 때마다 별도의 브랜치로 제어되므로 어떤 버전간에도 통합이 가능합니다. 또한 자신의GitHub 계정을 통해 자신만의 형상 관리를 할 수 있고 이를 원격 저장소로 사용하여 팀과 손쉽게 공동 작업 할 수 있습니다.

2. 변경/수정이 필요한 사항을 Github통해 공헌하기
과거에는 Lumberyard 개발자가 포럼을 통해 최대 50 줄의 Lumberyard 코드를 제출하는 방법으로 Lumberyard 기능 수정 요청을 할 수 있었지만, 이 방법은 간단한 변경 사항 수정 조차도 제한적이었습니다. (이때까지의 모든 수정 요청사항에 대해 다시 한 번 감사드립니다!) 이제 GitHub를 사용하여 Lumberyard 팀에 모든 크기의 변경 사항과 수정 사항을 제출하는 간단한 방법이 있습니다.

Github의 Pull-Request 요청을 통하여 원하는 만큼의 수정 코드를 제출할 수 있습니다. 이를 통하여 변경 내용이 간결하고 정확한 방식으로 관리됩니다. 여러분의 피드백과 지원은 우리 팀을 이끄는 요소이며, 우리는이 엔진을 여러분과 나란히 만들 수 있게 되어 매우 기쁩니다.

하지만, Lumberyard의 메인 브랜치를 안정적으로 유지하려면 Pull-Request 요청을 즉시 라이브 릴리스 브랜치에 병합 할 수는 없습니다. 대신 Lumberyard의 향후 릴리스에서 승인 된 변경 사항이 반영됩니다. 여러분들의 수정 요청이 수락되었는지 확인하거나 코드의 의도를 명확히 하기 위해 연락 드리겠습니다. 성공적인 Pull-Request 를 제출 한 사람은 릴리스 노트에 공헌한 것으로 표시됩니다!

또한 자신만의 자체 복제(fork) 브랜치를 만들고 코드를 올리거나 수정할 수 있습니다. (자세한 정보는 Readme.md 파일 참조) Lumberyard는 AWS 고객 계약Lumberyard 서비스 약관의 적용을 받지만 쉽게 사용할 수 있습니다. 이 저장소는 Github의 공개모드로 되어 있기에 코드를 받기 위해 로그인 할 필요가 없습니다.

언제나처럼, 당신이 생각하는 것을 저희에게 알려주십시오. 우리는 앞으로 몇 달 동안 Script Canvas 및 몇 가지 새로운 애니메이션 도구를 포함한 흥미 진진한 것들을 공개할 예정입니다. 계속 지켜봐 주십시오! 추가적으로 Lumberyard에 대한 자세한 내용은 튜토리얼, 커뮤니티 포럼, 기술 문서를 통해 제공됩니다.

이 글은 Now Available – Lumberyard on GitHub의 한국어 번역으로 Amazon Game Service의 구승모 엔지니어가 번역하였습니다. 이 글의 저자인 Todd Gilbertsen은Lumberyard팀의 선임 제품 기술 관리자로 1980 년대 후반부터 전문적으로 게임 엔진, 비디오 게임 및 기타 소프트웨어를 제작 해 왔습니다. 그는 게임 개발자가 창의력을 발휘할 수 있도록 하는 직관적인 도구와 기술을 만드는 데 열정적입니다.

Amazon GameLift 커스터마이징 가능한 매치메이킹 기능인 FlexMatch 소개

멀티 플레이어 게임의 중요한 부분 중 하나는 플레이어가 신속하고 일관되게 만족스러운 경기에 참여하도록 하는 것입니다.

Amazon GameLift는 이런 경험을 제공하기 위한 개발자들의 부담을 덜어주기 위해 효율적인 매치메이킹 시스템인FlexMatch를 제공합니다. 이 기능은 강력한 매치메이킹을 신속하게 처리하는 데 사용할 수 있는 강력한 사용자 정의 기능을 제공합니다. 당신이 게임 기획자이든 백엔드 엔지니어든 관계 없이 FlexMatch의 사용자 정의 가능한 규칙 기반 구문은 개발 과정을 단순화하고 원하는 방식으로 매치메이킹을 할 수 있도록 합니다.  또한, 관리 콘솔에서 분석과 GUI를 사용하여 여러 설정을 빠르게 실험하여 경기의 품질에 미치는 영향을 확인할 수도 있습니다. GUI를 사용하면 실험을 원하는 게임 기획자가 직접 분석 데이터에 접근 할 수 있습니다.

이 글에서는 FlexMatch가 게임 세션 대기열과 어떻게 상호 작용하는지, 유연한 규칙을 사용하여 매치메이킹 및 자동으로 게임 배치를 수행하는 방법에 대해 설명합니다. 또한 분석을 사용하여 게임 규칙을 추적하는 방법을 설명합니다. 마지막으로, 게임의 매치메이킹 과정을 더욱 커스터마이징 할 수 있는 고급 FlexMatch 설정에 대해서도 설명합니다.

매치메이킹 시스템 설계를 위한 요구 사항
매치메이킹의 과제는 얼마나 빨리 매치가 되고 그 매칭이 얼마나 최적인지의 균형을 맞추는 것입니다. 게임 개발자인 여러분들이 플레이어를 가장 잘 압니다. 어쩌면 당신의 플레이어는 가능한 한 작은 대기 시간을 원할 것입니다. 어쩌면 최선의 경기를 위해 오랜 시간을 기다릴 수도 있습니다. 아마, 매치메이킹 이런 두 가지 기준간 균형을 맞추어야 할지도 모릅니다.

플레이어들에게 일어나는 매치메이킹은 간단하게 보입니다. 개발자는 유연하고 효율적인 매치메이킹 시스템을 만들고 관리하는 것이 단순하다는 것을 알고 있습니다. 어디서부터 시작해야 할까요? 플레이어가 성공으로 간주 할 시스템을 어떻게 구축합니까? 다음은 매치메이킹 시스템 설계 시 묻는 몇 가지 질문입니다.

  1. 플레이어는 얼마나 오래 기다릴 수 있을까요? 여러분들은 게임 플레이어들의 속성을 잘 압니다. 그래서 여러분은 경기를 기다리는 그들의 의지에 대해 어떻게 생각하십니까? 어쩌면 그들은 빨리 매치하고 싶을 수도 있고, 아마도 가장 좋은 매치를 기다리고 싶을 수도 있습니다. 게임 세션 길이가 매치메이킹에 대해 어떤 의미를 가질까요? 짧은 세션의 게임의 경우 가능한 한 적은 시간 내에 가능한 한 많은 매치메이킹이 되는 방식으로 최적화 되기를 원할 것입니다. 더 긴 세션 시간을 가진 게임의 경우 플레이어는 더 나은 경기를 찾기 위해 더 오래 기다리는 것을 선호 할 수 있습니다. 여러분의 플레이어 기반은 서로 다른 요구를 가진 경쟁력 있는 캐주얼 게이머를 보유하고 있습니까? 이 경우, 빠른 매칭을 원하는 캐주얼 플레이어와 보다 균형 있고 경쟁적인 매치를 원하는 플레이어들을 위한 매치메이킹 로직을 여러 개 설정할 수 있습니다.
  2. 플레이어는 지연(latency) 시간에 얼마나 영향을 받습니까? 일반적으로 플레이어는 가능한 한 플레이어의 클라이언트와 서버 사이에서 가장 낮은 지연 시간을 원하며 동일한 낮은 지연 시간을 공유하는 플레이어와의 경기를 원합니다. 플레이어들의 지연 시간과 관련하여 그들이 허용하는 수준은 어떻습니까? 플레이어가 비슷한 지연 시간을 가진 플레이어와 더 긴 시간을 함께 기다릴 의향이 있습니까? 플레이어는 지연 시간에 관계없이 친구와 게임을 우선시합니까? 지연 시간과 관련하여 우선 순위가 다른 여러 플레이어가 있습니까? 여기서 답을 알고 있으면 플레이어를 구분하는 방법을 결정하는 데 도움이 됩니다.
  3. 플레이어의 숙련도(skill)얼마나 중요합니까? 플레이어는 게임을 재미있게 만드는 방법을 여러 가지 방법으로 정의하고 동일한 숙련도 수준을 가진 다른 플레이어와 함께 플레이 하는 것이 게임을 재미있게 유지하는 데 많은 도움이 됩니다. 비슷한 숙련도를 가진 플레이어와의 경기에 귀중한 가치를 부여합니까? 그들은 도전하는 것을 선호하고 그들이 가진 것보다 더 나은 플레이를 원하고 있습니까? 그들은 숙련도에 전혀 신경 쓰지 않고 가능한 한 빨리 매치하고 싶습니까? 플레이어의 숙련도가 당신의 매치메이킹에 어떻게 부합하는지 이해하면 생성 된 매치를 더 세분화하는 데 도움이 됩니다.
  4. 여러분의 매치메이킹은 얼마나 유연합니까? 대기 시간, 지연(latency) 시간 및 숙련도 레벨 모두가 매치메이킹에 영향을 미치므로 시스템이 얼마나 유연해야 하는지에 질문을 해야 합니다. 우선 순위를 결정하고 선택할 수 있습니까? 선택 사항이 플레이어에게 미치는 영향을 알려주는 분석 기능이 있습니까? 여러분의 시스템은 이상적인 상황에서도 게임을 찾기 위해 자동으로 매치메이킹 요구 사항을 자동으로 완화합니까? 시스템을 통해 플레이어를 분류하여 모든 사람에게 최고의 경험을 제공 할 수 있습니까?

얼마전 Amazon GameLift 및 기타 AWS 서비스를 사용하여 서버리스 매치메이킹 패턴을 만드는 방법을 설명했습니다. 이제는 FlexMatch의 강력하고 유연한 매치메이킹 기능을 통하여 다음 단계로 나아가 봅시다.

FlexMatch 사용법
표면적으로, FlexMatch는 상대적으로 단순해 보이지만 깊이와 유연성이 있습니다. FlexMatch의 기능 중 일부는 Amazon GameLift의 게임 세션 대기열에 직접 연결되어 있습니다. FlexMatch를 사용하면 선택한 기준에 따라 플레이어를 특정 항목으로 그룹화 할 수 있습니다. 그런 다음 대기열을 사용하여 모든 플레이어를 특정 플랫폼이나 특정 지역 또는 게임 모드/맵/언어에 따라 배치할 수 있습니다. FlexMatch와 대기열을 함께 사용하면 여러 지역의 플레이어들 심지어 여러 지역에서도 최적화된 저 지연(low latency)의 경험을 제공 할 수 있습니다. 대기열 기능과 함께 FlexMatch를 사용하는 방법을 더 잘 이해할 수 있도록 FlexMatch 구성부터 시작하는 예시를 살펴 보도록 하겠습니다.

세션 기반의 슈팅 대전 게임이 최소 4 명의 플레이어와 (팀당 최대 8 명의 플레이어) 동일한 팀 크기의 대전 상대를 필요로 한다고 가정 해 봅시다. 플레이어들은 경쟁적인 경기를 원하기 때문에 팀은 서로 평균 10 점 이내의 평균적인 플레이어 숙련도 점수를 가져야 합니다. 마지막으로, 플레이어가 경기를 찾기 위해 너무 오래 기다리는 것을 원하지 않으므로, 5 초 후 팀 간 50 포인트 이내의 평균 숙련도 점수와 15 초 후 팀 간 100 포인트로 규칙을 완화하려고 합니다.

다음은 위의 상황에 맞게 FlexMatch 규칙(Rule)을 구성하는 방법입니다.

{
    "name": "aliens_vs_cowboys",
    "ruleLanguageVersion": "1.0",
    "playerAttributes": [{
        "name": "skill",
        "type": "number",
        "default": 10
    }],
    "teams": [{
        "name": "cowboys",
        "maxPlayers": 8,
        "minPlayers": 4
    }, {
        "name": "aliens",
        "maxPlayers": 8,
        "minPlayers": 4
    }],
    "rules": [{
        "name": "FairTeamSkill",
        "description": "The average skill of players in each team is within 10 points from the average skill of players in the match",
        "type": "distance",
        // get skill values for players in each team and average separately to produce list of two numbers
        "measurements": [ "avg(teams[*].players.attributes[skill])" ],
        // get skill values for players in each team, flatten into a single list, and average to produce an overall average
        "referenceValue": "avg(flatten(teams[*].players.attributes[skill]))",
        "maxDistance": 10 // minDistance would achieve the opposite result
    }, {
        "name": "EqualTeamSizes",
        "description": "Only launch a game when the number of players in each team matches, e.g. 4v4, 5v5, 6v6, 7v7, 8v8",
        "type": "comparison",
        "measurements": [ "count(teams[cowboys].players)" ],
        "referenceValue": "count(teams[aliens].players)",
        "operation": "=" // other operations: !=, <, <=, >, >=
    }],
    "expansions": [{
        "target": "rules[FairTeamSkill].maxDistance",
        "steps": [{
            "waitTimeSeconds": 5,
            "value": 50
        }, {
            "waitTimeSeconds": 15,
            "value": 100
        }]
    }]
}

Figure 1 – Example FlexMatch rules syntax.

이렇게 매치메이킹을 구성한 후, 대기열을 구성하도록 합니다.

아시아의 모든 플레이어가 서로 어우러지길 원한다고 가정 해 봅시다. 이를 위해 매치메이커를 서울 (ap-northeast-2) 또는 동경(ap-northeast-1) 리전에 설치 한 다음, GameLift Fleet을 위한 대기열은 서울 (ap-northeast-2), 동경 (ap-northeast-1), 싱가포르 (ap-southeast-1) 리전에 둘 수 있습니다.  이 대기열은 플레이어 지연 시간을 사용하여 매치된 플레이어 세트가 가장 낮은 지연 시간을 갖도록 구성 될 수 있습니다. 최저 지연 시간 기반 배치 방법은 기존 블로그 글을 참고하세요.

해외 리전에서 게임을 출시할 계획이라면 추가 매치메이커와 대기열을 만들고 각 리전 또는 리전 그룹마다 다른 매치메이킹 규칙을 설정할 수 있습니다. 이 접근 방식은 전 세계 다른 리전에서 다른 버전의 게임을 출시 할 때 특히 유용합니다. 또한 플레이어의 취향에 따라 정규전 (래더 게임) 대기열과 야생전 (캐주얼 게임) 대기열로 분리 할 수도 ​​있습니다.

즉, FlexMatch는 규칙(Rule)을 사용하여 매치 조건을 조합하고 대기열 구성을 사용하여 게임 서버에 매치된 플레이어들을 배치하는 구조입니다. 또한, 대기열의 깊이에 따라 GameLift의 자동 확장 기능을 연동할 수도 있습니다. 대기열에 있는 플레이어의 수에 따라 더 빠르게 게임 서버들을 자동으로 늘이거나 줄일 수 있습니다.

고급 규칙(Rule)
FlexMatch 규칙에는 플레이어 경험을 더욱 세밀하게 제어 할 수 있는 고급 기능도 있습니다. 예를 들어, 깃발 잡기 (Capture the Flag) 또는 특정 맵 종류 선호와 같은 특정 게임 모드를 선호하는 플레이어를 함께 그룹화 할 수 있습니다. 또한 플레이어 캐릭터의 여러 클래스 중 적어도 하나를 특징으로 하는 팀과의 경기를 만들 수도 있습니다. 예를 들어, 게임을 시작하기 전에 유효한 팀에게 전사가 1 명, 도적이 1 명, 마법사가 1 명 이상 필요하다고 결정할 수 있습니다. 새로운 게임 모드를 지원하기 위해 1 대 5대전과 같은 비대칭 매치메이킹을 허용 할 수도 있습니다. 간단히 말하면, FlexMatch의 다양한 옵션을 통해 세심한 컨트롤이 가능합니다.

규칙(Rule)어떻게 동작하는지 분석할 있는 기능 제공
FlexMatch 규칙을 모니터링하고 최적화하는 것은 게임 디자인을 섬세하게 조정하는 중요한 부분입니다. 규칙을 모니터링하기 위해 FlexMatch는 관리 콘솔을 통해 쉽게 액세스 할 수 있는 일련의 통계를 제공합니다. 게임을 테스트 할 때 이러한 통계 분석을 통하여 플레이어 환경의 균형을 맞출 수 있습니다. 측정할 수 있는 항목은 다음과 같습니다.

  • Match Success/Failure Rates: 예상되는 플레이어를 그룹화하여 게임에 신속하게 참여시킬 수 있는 매치메이커의 결과를 확인하세요. 매치메이커가 제안한 매치를 얼마나 잘 수용하는지 보기 위해 플레이어가 수락하거나 거절하는 비율을 추적합니다.
  • Player Demand: 현재 처리중인 매치 요청 수를 확인하십시오. 새로운 요청 및 새 플레이어의 비율을 추적하여 플레이어 수요 급등에 대한 사전 통지를 얻을 수 있습니다.
  • Time to Ticket Success: 새로운 매치를 성공적으로 생성하는 데 걸리는 평균 시간을 모니터링 합니다. 이 데이터를 사용하여 가능한 가장 최적의 매치 결과를 찾는 것과 플레이어를 게임으로 빠르게 매치하는 것 사이에서 균형을 찾는데 도움이 됩니다.
  • Matchmaking Rule Effectiveness: 매치메이커에서 개별 규칙의 성공/실패 비율을 추적합니다. 이 데이터를 사용하여 각각의 규칙을 미세 조정하여 매치메이킹 규칙을 전반적으로 최적화할 수 있습니다.

매치메이킹 규칙에 대한 세부 정보는 개발자 가이드를 참고하세요.

예를 들어, 분석 결과 매치 요청의 80 %가 시간 초과되었다고 표시되면 규칙이 너무 엄격하기 때문에 규칙을 수정해야 할 필요가 있습니다. 좋은 플레이어 경험에 대한 정의에 따라 매치메이킹에 걸리는 시간이 초과되는 (Time Out) 경우를 10% 이내로 하기를 추천드립니다. 반대로, 여러분의 매치메이킹 요청 시간 중 2% 만 시간 초과 될 수 있습니다. FlexMatch 규칙이 완벽할 수 있지만, 또 다른 문제를 가질 수 있습니다. (지루하거나 대전하기 편한 상대와 일상적인 게임만 하게 될 수도 있습니다)  그래서, 분석 기능을 사용하여 이 같은 주요 문제를 다음과 같은 방식으로 추적할 수 있습니다.

이러한 분석 데이터를 AWS Lambda에 연결하여 특정 기능을 수행하거나 통지를 받을 수도 있습니다.

규칙 완화
예제 규칙에 표시된 것처럼 매우 유용한 FlexMatch 기능 중 하나는 규칙 완화입니다. 규칙 완화를 사용하면 플레이어가 경기를 기다릴 때 플레이어 기준을 완화하는 시기와 방법을 제어 할 수 있습니다. 규칙 기반 프레임 워크에서는 직관과 어긋나게 느낄 수도 있지만 규칙을 완화하면, 매치되기 어려운 플레이어가 다음 게임으로 빠르게 진입하는 데 도움이 됩니다. 예를 들어, 숙련도 레벨의 범위 내에 있는 플레이어들만을 포함 시키길 원할 수 있습니다. 숙련도 레벨 차이는 +/- 10 포인트를 초과해서는 안되길 원하더라도 플레이어 풀에 해당 범위 내의 플레이어가 충분하지 않으면 이 규칙을 완화해야 합니다. 어쩌면 플레이어가 +/- 15 포인트로 완화한 조건을 대신 사용하기를 기대할 수도 있습니다.

또 다른 예로, 플레이어가 적어도 90 초 동안 기다린 후에 더 먼 지역의 플레이어를 검색하기 위해 규칙을 완화해야 할 수도 있습니다. 즉, 남아시아 지역의 플레이어가 동아시아 지역에 배치 될 수 있음을 의미합니다. 대기 시간은 약간 더 높을 수 있지만, 매치메이킹을 더 기다리는 대신 플레이어가 바로 게임을 시작할 수 있습니다.

궁극적으로, 이러한 상황들은 (예를 들어, 언제 얼마나 어려운 경기를 펼칠 수 있는 플레이어를 규칙을 완화해야 하는지) 여러분이 대답 할 수 있는 질문입니다. FlexMatch를 사용하면 매치 조건에 잘 맞지 않는 경우도 허용 할 수 있도록 선택할 수 있습니다.

마무리하며
FlexMatch는 게임 관리의 중요한 부분을 자동화하는 동시에 깊이 맞춤식 멀티 플레이 환경을 만드는 데 필요한 강력한 기능과 유연성을 바탕으로 매치메이킹 프레임워크를 제공합니다. 이것은 멀티 플레이어 게임 관리를 강력하고 유연하고 빠르고 비용 통제 가능하도록 합니다. FlexMatch를 시작하려면 Amazon GameLift SDK를 다운로드하고 게임을 Amazon GameLift에 업로드 한 다음 규칙 구성을 시작하세요.

이 글은 Matchmaking, Your Way: Amazon GameLift FlexMatch and Game Session Queues의 한국어 번역으로, Amazon Game Services의 구승모 엔지니어가 번역하였습니다. 저자인 Justin Miles는 Amazon GameLift 팀의 소프트웨어 엔지니어이며 지난 3 년 동안 Amazon에서 근무했습니다. 그는 펜실베니아 주립 대학을 졸업했으며 전자 상거래, 건강 관리 및 게임을 비롯한 여러 산업 분야에서 10 년을 보냈습니다. 현재 그는 Hex TCG와 젤다: 야생의 숨결을 플레이하고 있습니다. 또한 마리오, 젤다의 전설, 볼펜 슈타인의 광팬입니다.

 

Stephen Orban – 파트너와 함께 클라우드 전략 가속화 하기

“당신은 내가 못 하는 걸 할 수 있고 나는 당신이 못 하는 걸 할 수 있으니, 함께한다면 우리는 보다 대단한 일을 할 수 있다.” – Mother Teresa

 

기술 전문성을 위해 타사와 파트너 관계를 맺는 방식은 조직마다 다릅니다. 자체적인 기술 구축에 치우치는 조직이 있는가 하면 기술 개발, 유지 관리, 지속적 운영의 일부 또는 전부를 하나 이상의 파트너에게 아웃소싱하는 조직도 있습니다. 하지만 모든 조직은 어떠한 형태로든 고객에게 제품과 서비스를 제공하기 위해 하드웨어, 도구 및/또는 클라우드 공급업체와 파트너십을 맺고 있을 것입니다.

https://cdn-images-1.medium.com/max/1091/1*W9gSRKJSrKve9EivWwLxRg.jpeg

저는 지난 몇 년간 조직의 기술 전략을 발전시키고 있는 수많은 임원과 이야기를 나눠 봤는데, 상당수는 클라우드가 비즈니스 혁신에 어떤 도움이 되는지 이해하게 되면서부터 파트너십에 대한 접근 방식을 재평가하고 있었습니다. 따라서 이 게시물은 기술 클라우드로 인한 기술 생태계의 변화에 대한 제 견해를 제시하고, 엔터프라이즈 클라우드 여정 시리즈의 네 번째 모범 사례인 파트너 참여라는 주제에 관한 시리즈를 시작하는 글입니다.

빠르게 성장하는 생태계의이해

클라우드를 중심으로 한 생태계의 성장 속도는 저를 끊임없이 놀라게 합니다. 지난 4년 동안 AWS re:Invent에 참가해왔지만 해마다 커지는 규모를 보고 항상 놀라곤 합니다. 좀 더 자세히 설명하자면, 2012년부터 2015년까지 파트너 부스는 두 배 이상 늘었고,최신 도구와 서비스에 대해 알아보기 위해 돌아다니는 시간은 한 시간에서 하루로 늘어났습니다. 따라서 AWS re:Invent는 시장이 움직이는 방향과 벤처 캐피털의 투자 동향을 알아보기에 가장 적합한 장소라고 생각합니다.

이렇게 가파른 속도로 성장하는 생태계가 알맞은 파트너를 찾는 것을 더 어렵게 만든다고 생각하실 수 있지만, 여러 공급업체를 경쟁하게 할 수 있다는 이점도 있습니다. 그 과정에서AWS 어카운트 매니저와AWS 파트너 디렉터리는  선택의 폭을 좁히는 데 도움이 되며, AWS Marketplace는 몇 초 안에 다양한 공급업체와 카테고리에서 솔루션을 찾고 배포하는 데 도움이 될 수 있습니다. 원하는 것을 AWS Marketplace에서 당장 찾을 수 없다면 알려 주십시오.

문화 혁신

저는 최근 대기업들이 보다 열린 생각을 가지고 작고 단촐하며 덜 “검증된” 조직들과 엔터프라이즈를 위한 도구, 전문 서비스, 관리형 서비스 구축을 위해 파트너십을 맺는 것을 보면 뿌듯합니다. 15년도 더 전에 조직의 기술 구매 일을 시작했을 때는 오랜 기간 실적을 쌓고 규모가 크며 입지가 탄탄한 대형 회사들과만 파트너십를 맺으라고 배웠기 때문입니다. 현재는 많은 Fortune 500 기업들이 난제를 해소하기 위해 저의 네 살짜리 딸보다도 어린 공급 업체와 파트너십을 맺고 도움을 받고 있습니다. 그리고 상황에 따라 이 과정이 전체 사업의 혁신을 돕기도 합니다.

디지털 및 고객 위주의 미래를 계획하는 기업의 많은 기술 임원들은 클라우드에서 비롯된 젊은 공급업체 고유의 문화를 도입한다면 조직의 혁신을 가속화 할 수 있다는 것을 깨닫고 있습니다. 제가 Dow Jones의 CIO로 있을 때 AWS와 파트너 관계를 맺은 중요한 동기 중 하나도 Amazon의 문화 일부를 우리 문화에 접목시키기 위해서였습니다. 저는 Amazon이 그토록 고객에게 집중하고 발 빠르게 움직일 수 있었던 도구를 원했고 실험정신을 장려하는 DevOps 문화도 발전시키고 싶었습니다. 젊은 공급업체 상당수 (몇몇만 꼽자면 2nd WatchCloudreachCloud Technology PartnersMinjarNew RelicApp DynamicsChefPuppetCloudEndure)도 바로 똑같은 이유로 새로운 비즈니스를 모색하고 있습니다.

하지만 이는 기존의 대형 서비스 공급업체가 이러한 변화속에서 도태되고있다는 뜻은 아닙니다. 오히려 많은 경우, 기존 관계를 활용한 비즈니스 및/또는 문화 혁신이 더 적절할때도 있습니다. 그 예시로, AWS는 최근 Accenture와 함께 새로운 공동 비즈니스 그룹을 발표했고, 함께 클라우드 전략 및 마이그레이션, 빅 데이터, 분석, IoT 중심의 제품을 통해 대기업의 비즈니스 혁신을 돕고있습니다. 그리고 2016년에는 이러한 발표가 더 늘어날 것으로 전망됩니다.

집중 사업의입증된 파트너 찾기

기업은 늘 조직의 비즈니스 목표에 맞는 조직과 파트너 관계를 맺는 것을 목표로 삼아야 합니다. DevOps 컴피턴시를 구축할 방법을 모색 중이고 팀이 자산 개발 및 운영 방법을 배우게 하고 싶다면, 파트너가 그 분야에서 입증되었는지 확인이 필요합니다. 바로 이것이AWS가 AWS 컴피턴시 프로그램을 개발한 이유 중 하나입니다. 우리는 고객이 우리 플랫폼에서 성공하기를 바라며, 이 프로그램은 고객이 특별히 집중하는 분야에서 성공을 도울 파트너를 찾도록 도와줄 것입니다. AWS는 현재 생태계가
DevOps모바일보안디지털 미디어마케팅 및 상거래빅 데이터스토리지의료생명 과학Microsoft 워크로드SAPOracle 분야의 컴피턴시를 개발하도록 돕고 있으며, 2016년에는 마이그레이션 분야의 컴피턴시 개발이 예정되어 있습니다.

파트너십을 맺는 것에 대한 조직의 관점이 어떻든 AWS는 목표 달성에 적합한 파트너를 찾으실수 있도록 기꺼이 돕겠습니다. 이 시리즈에서 다루었으면 하는 주제가 있으면 의견을 보내 주십시오. 기꺼이 경청하겠습니다.
-Stephen
@stephenorban
http://aws.amazon.com/enterprise/

본 블로그 글은 Stephen Orban의 엔터프라이즈 클라우드 여정 시리즈 입니다. 더 자세한 것은 전체 목록을 참고하시기 바랍니다.

 

 

Stephen Orban – 클라우드 성공을 위한 인재는 이미 있다!

“교육은 세계를 변화시키기에는 데 사용할 수 있는 가장 강력한 무기입니다.”- Nelson Mandela

 

저는 비즈니스 및 IT 전략에 대해 다양한 기업의 수많은 임원들과 이야기할 수 있는 기회를 얻게 된 것을 행운으로 생각합니다. 모든 임원과 기업은 저마다 다른 과제를 안고 있지만,  직원들로 하여금 미래의 꿈을 향해 전진할 수 있도록 도움을 줄 기술이 필요하다는 것은 모두가 공감합니다. 클라우드의 경우에도 사정은 다르지 않습니다. 뻔한 이야기이지만, 몇몇 임원들은 조직 내 클라우드 기술 부족이 클라우드 여정에 진전이 없는 가장 큰 이유라고 밝혔습니다.

직원 교육은 성공적인 클라우드 전략을 갖춘 기업들이 따르는 7가지 모범 사례 중 두 번째로 중요합니다. 참고로 경영 리더십이 첫 번째이며, 이후 게시물에서는 그 밖의 사례들에 대해서도 살펴보기로 하겠습니다. 교육은 회의적인 직원들에게 믿음을 불어넣을 수 있기때문에, 클라우드 활용속도에 있어서 큰 변화를 가져올 것입니다.

여러분은 필요한 것들을 이미 보유하고 있습니다.

사람들은 알 수 없는 것을 두려워 하며, 변화는 약간의 불편함을 초래합니다. 그러한 두려움 완화에 가장 효과적인 것 중 하나는 바로 교육입니다. 회사는이미 기술을 갖춘 새로운 인재들을 확보하는 방안을 고려해볼 수도 있겠지만, 이러한 방안은 대체로 소규모 조직에서만 효과를 나타낼 뿐 큰 조직에 더 넓게 확장되기는 어렵습니다.

대부분의 조직들은 이미 풍부한 조직적 지식과 문화적 사례들을 갖추고 있으며, 이러한 사례들은 장기 근속한 직원들 사이에 잘 정착되어 있습니다. 만약 위와 같은 기존 직원들이 조직의 지식과 문화를 클라우드 기술과 접목하는 방법을 익히게 된다면 조직에 유리할 수 있습니다. 다시 말하면, 클라우드를 추진하기 위해 필요한 모든 인력은 이미 현장에 있기 때문에 단지 그들을 활용하기만 하면 됩니다.

다음 사항들은 직원들을 대상으로 클라우드 기술을 교육할 때 임원들이 고려했으면 하는 몇 가지 영역들입니다. 저는 대체로 AWS 관련 서비스 또는 솔루션을 배재한 채 전략 및 리더십 지침을 주제로 글을 게시하려고 하지만, 이 주제에 잘 어울리는 AWS 프로그램의 일부를 언급하지 않을 수 없습니다. 저와 다른 생각을 가진 여러분의 의견을 꼭 듣고 싶습니다!

AWS 교육 및 자격증 팀

AWS의 자기 주도식 및 강의식 교육 과정들은 여러분의 팀이 신속하게 시작하고 최신 기술을 새롭게 습득하도록 돕습니다. 저는 이미 웹 사이트에서 매우 설득력 있게 제공되는 세부 내용을 여기서 반복하지는 않겠지만, 저와 이야기를 나눴으며 AWS의 교육 프로그램을 이용 중인 모든 회사는 향상된 클라우드 운영에 따른 혜택을 지금 이 순간 누리고 있다고 말할 수 있습니다. 또한, 많은 분들이 이러한 교육을 통하여  회사 조직 내 팀 간 마찰이 감소했다고 보고합니다.

제가 Dow Jones에 있을 때 팀의 거의 모든기술 담당자를 교육했습니다. 그리고 이 과정은 추후  AWS Technical Fundamentals 과정이 되었습니다. 또한, 시간이 흐를 수록 유의미한 클라우드 도입에 관심이 있는 사람들은 더 높은 수준의 교육 과정도 수강했습니다.

따라서, 우리는 마침내 자체적으로 기술 교육을 제도화 했습니다. 그 예시로, 당시 DevOps 팀은 “DevOps Days” 행사를 개최했는데, 이 행사를 통하여 조직 내 다른 구성원들도 클라우드를 기반으로 하여 개발된 모범 사례, 프레임워크 및 거버넌스 모델에 대해 알게 되었습니다.

이러한 유형의 풀뿌리 교육은 직원들의 업무 방식에 유의미한 영향을 미쳤으며, 클라우드가 중심이 되는 미래의 환경에서 우리가 구축하려고 했던 문화 요소들을 강화하는 데 도움이 되었습니다. 또한, 교육은 조직 내부의 장벽을 허무는 데 가장 효과적인 메커니즘 중 하나로 성장했습니다. DevOps Days 행사에 참석하게 되면 우리가 클라우드를 통해 하고 있는 일들에 마음을 뺏기지 않을 수 없었기 때문입니다. 그 이후 저는 비슷한 경로를 밟고 있는 다른 대기업 관계자들과도 이야기를 나누었습니다. 그들은 AWS 교육 및 자격증 팀과 협력하여 회사 내 특정 조직의 요구에 맞는 대규모 교육 프로그램을 마련 및 확장하고 있다고 했습니다.

그럼에도 직원들이 반발하고 있다는 생각이 든다면 indeed.com에서 일자리 동향을 보여주는 이 차트를 공유해 볼 수 있습니다.

클라우드 기술에 대한 수요는 분명하면서도 가파르게 상승하고 있으며, 이러한 추세가 쉽게 변화할 것으로 보이지 않습니다. 저는 클라우드 교육이 향후 수년 동안 여러분과 귀사의 직원들에게 이익을 배당할 것이라고 말해도 과언이 아니라고생각합니다.

생태계 활용

여러분은 각자가 속한 조직의 클라우드 여정을 주도할 수 있겠지만 특히 교육에 있어서는 독립적으로 진행할 필요는 없습니다. 동료들과 대화를 나누고 클라우드 관련 이벤트에 참석하며 다른 회사들이 하고 있는 일에 대해 읽어 보십시오. 클라우드 생태계가 얼마나 빠르게 성장했는지, 또 그렇게 짧은 기간 내에 얼마나 많은 클라우드 기반 비즈니스가 성공을 거두었는지 놀라울 정도입니다. 많은 기업들이 무엇을 성취했으며 또 그들이 학습한 교훈을 어떻게 활용할 수 있는지를 설명하는 정보는 인터넷에서 충분히 확인할 수 있습니다.

AWS 파트너 네트워크(APN)는 생태계를 알아보는 방법 중 한 가지이며 학습의 출처가 되는 리소스들로 가득합니다. 특정한 니즈를 해결하는 데 도움이 될만한 도구를 찾고 있거나 혹은 대규모 마이그레이션을 지원할 구현 파트너를 찾고 있다면 도움이 될 만한 다양한 파트너들이 존재합니다. 적절한 파트너를 찾는 데 도움을 얻고 싶다면 언제든지 AWS 어카운트 매니저에게 문의하면 됩니다. 다음 게시물에서 파트너 커뮤니티에 대해 좀 더 자세히 살펴보기로 하겠습니다.

마지막으로 AWS Professional Services는 수백 명의 임원들이 클라우드 전략을 실행하는 데 필요한 역할과 기술을 파악하는데에 도움을 주었습니다. AWS Professional Services 팀은 조직의 현재 준비 상태를 평가하는 한편, 수백 곳의 유사한 기업들을 지원했던 경험을 기반으로 조직이 필요한 기술들을 습득하도록 도와줍니다.이러한 참여를 통해 AWS Professional Services는 AWS 클라우드 도입 프레임워크를 개발했습니다. 이 프레임워크는 조직을 클라우드 운영 모델로 전환할 때 이를 필요로 하는 모든 조직에게 무료로 제공되고 있습니다.

경험을 대신할 만한 것은 없습니다

적절한 기술과 적극적인 태도를 가진 사람은 클라우드에서 반드시 본인의 입지를 찾을것입니다. 많은 사람들이 모든 것이 가능하다고 생각은 할 수 있겠지만, 경험이 없는 사람은 이를 입증하기가 어려울 것입니다.

교육은 새로운 개념의 노출과 다양한 예들을 설명 할 수 있게 해 주는 훌륭한 방법입니다. 하지만  저는 최상의 교육은 경험의 형태로 제공된다고 생각합니다. 팀이 클라우드를 통해 비즈니스에 유의미한 일을 할 수 있는 실질적이면서도 한시적인 기회를 제공하고 어떤 일이 발생하는 지 확인하십시오. 웹 사이트를 만들거나, 일부 데이터를 위한 API를 만들거나, 위키를 호스팅하거나, 팀이 이미 수행하고 있는 작업에 맞는 유형을 개발하도록 하십시오. 저는 약간의 시간 압박 속에서 올바른 동기가 얼마나 빨리 결과로 이어지는 지 볼 때마다 항상 놀라움을 느낍니다. 희소성은 창출을 촉진합니다. 또한 저는 목표가 명확하고 사용할 도구가 미리 정해져 있을 때 혁신이 얼마나 짧은 시간 내에 일어날 수 있는 지 보았습니다.

이러한 직접적인 경험은 판도를 바꿀만한 혁신이 될 수도 있으며 적어도 다음 프로젝트에서 활용할 일부 교육이 될 수 있습니다. 어느 쪽이든 간에, 그러한 경험들은 사업의 발전을 추진하는 데 도움을 줄 것이며 여러분의 팀이 교훈을 얻을 수 있는 기회가 될 것입니다.
– Stephen
@stephenorban
http://aws.amazon.com/enterprise/

본 블로그 글은 Stephen Orban의 엔터프라이즈 클라우드 여정 시리즈 입니다. 더 자세한 것은 전체 목록을 참고하시기 바랍니다.

Stephen Orban – 휼륭한 리더는 새로운 규칙을 창조한다

“나를 둘러싼 규칙이 그 무엇이든 간에 나는 자유롭다. 만일 내가 어떤 룰을 받아들일수 있다고 판단하면 받아들이면 되고, 몹시 불쾌하다면 어기면 된다. 내가 자유로울수 있는 이유는 내가 하는 모든 일에 대해 오로지 나만이 도덕적 책임을 진다는 사실을 알고 있기 때문이다.”
– Robert A. Heinlein

 

좋은 리더들은 규칙을 시행합니다. 훌륭한 리더들은 기존의 규칙이 더 이상 적용되지 않는 시점을 알고 있으며, 비로소 그 때가 새로운 규칙을 만들 시점이라는 것도 알고 있습니다. 앞서 인용한 글에서 Heinlein이 말한 것처럼 이것은 때때로 실제로 규칙을 어기는 것을 때때로 의미하기도 합니다. 그러나 조직 전반에 걸친 행동적 변화에 영향을 미치고 싶어하는 훌륭한 리더들이라면 규칙을 어기거나 새 규칙을 만들기 전에 먼저 기존의 규칙을 인지한 후 이를 변경할 지 여부와 변경 시점 및 방법을 각각 결정해야 합니다.

클라우드 여정에서 조직을 이끄는 것은 기술 리더들이 새로운 룰을 만들 수 있는 최고의 기회 중 하나에 속합니다. 저는 기술 임원의 모습을 한 최고 변화 관리 책임자(CCMO™)는 자신의 프로세스를 검사한 후, 클라우드를 사용하는 엔터프라이즈를 관리하는 데 있어 여전히 적합한 규칙이 무엇인지를 판단해야 할 의무가 있다고 주장하곤 합니다.

새로운 임무를 위한 새로운 룰


©Hernán Piñera https://www.flickr.com/photos/hernanpc/7115374283/

많은 이들은 ITIL, ITSM 및 계획-구축-실행과 같은 프로세스 기반 프레임워크를 잘 알고 있습니다. 이 프레임워크들은 대규모 조직 내에서 IT를 제공하고 운영하는 방식을 표준화하기 위해 지난 수십 년 동안 개발되었습니다. 이처럼 다양한 프레임워크의 창안자들은 조직 내에서 역할, 책임 및 프로세스를 명확히 정의함으로써 효율성, 효과, 품질 및 비용의 일부 조합을 개선할 수 있다고 자랑합니다.

이러한 방법들은 인프라 관리와 같은 유사한 활동들을 관리하기 위해 적용할 때 알맞은 것이었습니다. 하지만 오늘날 회사들은 고객을만족시키면서 동시에 조직을 차별화하는 제반 활동에 점점 더 주력하고 있습니다. Talen Energy는 다양한 연료원을 사용하는 일련의 발전소에서 전력을 생산하는 데 주력하려고 합니다. Nike는 전 세계의 모든 운동 선수들에게 영감과 혁신을 전달하려고 합니다. GE는 세계를 건설하고 감동시키며 필요한 에너지를 공급하고 치유하고자 합니다. 이전에는 인프라 관리가 그러한 임무를 수행하기 위한 기반으로 간주되기도 했습니다. 이제는  클라우드가 기반을 제공하고,오늘날의 CCMO는 기존의 프로세스 기반 프레임워크에서 통하는 것들을 유지하면서도 새롭고 보다 현대적이며 점점 더 디지털화되는 운영 모델을 관리할 새로운 규칙을 망설이지 말고 만들어야 한다는 결론을 내릴 수 있습니다.

조직 전반의 기회를 모색

클라우드 여정 (또는 변경 관리 프로그램) 에서 여러분의 현재 위치에 관계 없이 저는 클라우드가 우선이 되는 미래 세계에서 여러분의 역할, 책임 및 프로세스가 과연 어떤 모습일지 고려해 볼 것을 적극 권합니다. 이는 약간의 탐색이 필요하며 조직마다 다를 것입니다. 운영, IT 감사 및 재무 관리는 규칙 변경과 관련해 제가 엔터프라이즈 임원들과 자주 논의하는 주제들입니다.

저는 이러한 주제가 빙산의 일각이라는 점을 밝히고 싶습니다 – 여기서 모든 주제를 장황하게 논하는 것은 불가능할 것입니다. 여러분이 찾고 있는 다른 모든 주제들을 일부라도 알고 싶습니다. 또한 언제든 여러분의 답변을 환영합니다!

운영. 올해 초에 저는 DevOps로의 전환을 고려 중인 엔터프라이즈에 관한 몇 개의 게시물을 작성한 바 있습니다. 여기에는 고려해야 할 많은 규칙 변경 사항들을 포함됩니다.

고객 (내부 또는 외부) 이 필요로 하는 것들을 이해하고자 노력하며 어떤 솔루션을 어떻게 제공할지에 대해 항상 열린 태도를 유지하는 고객 서비스 중심의 IT 부서를 만드는 데 중점을 두십시오.

반면, 자산 개발 및 운영(run-what-you-build) 개념은 말 그대로 자산 개발과 운영에 중점을 둡니다. 제 경험으로 볼 때, 이러한 과제는 엔터프라이즈에서 실천하기에는 무엇보다도 어려운 변화들 중 하나에 속하는데, 그 이유는 아무래도 종래의 IT 프로세스 기반 프레임워크와는 사뭇 동떨어진 개념이기 때문입니다. 자산 개발 및 운영(run-what-you-build)과 그와 관련된 고유한 규칙 변경을 도입하는 데에는 여러 가지 충분한 이유들이 있는데, 저는 변화로부터 많은 이득을 얻지 못한 조직을 아직까지 발견하지 못했습니다.

마지막으로 이 개념은 이러한 변화와 그 외 운영상의 변화들을 일으킬 때 기대할 수 있는 것들을 파악하는 데 도움이 됩니다. 인내심을 잃지 마십시오. 수십 년 이상 적용되어 왔던 규칙들을 변경하는 일은 결코 하루 아침에 이루어지지 않습니다.

프로세스 감사. 감사자는 엔터프라이즈의 클라우드 여정에서 없어서는 안 될 중요한 역할을 담당합니다. 지금 기업의 많은 임원들은 “감사 기능”이라는 문구를 접할 때 여전히 부정적인 생각들과 골칫거리를 연상하기 쉬운데 그 이유는 감사 활동이 그들의 업무 진행을 지연시킬 소지가 있다고 판단하기 때문입니다. 하지만 이는 상황을 생산적으로 혹은 진보적으로 바라보는 방식이 결코 아니며,특히 새로운 규칙을 정하려고 할 때에는 더욱 그렇습니다. 감사는 여러분의 적이 아니라 친구입니다. 감사를 통해 사람들에게 현재 만들고 있는 규칙이 훨씬 더 도움이 된다는 것을 알리고 피드백을 받으십시오. 감사자들과 초기에 자주 협업하면서 여러분이 성취하려는 목표에 대해 설명하십시오. 여러분이 감사자들의 의견을 수렴하면 여러분의 생각과 결과가 개선될 것으로 확신합니다.

Dow Jones에 근무할 당시에 저는 DevOps 및 자산 개발 및 운영을 도입하려는 당사의 계획을 감사자들에게 설명하는 것에 상당히 조바심을 느꼈습니다. 이러한 조바심 때문에 회사 측은 감사 대비 태세에 들어갔는데 정작 우리의 걱정은 어느 정도 기우에 그치고 말았습니다. 자동화를 중심으로 우리가 활용했던 새로운 규칙들 덕분에 회사의 경영 관리가 크게 향상되었다고 설명했을 때 감사자들은 회사의 미래에 대해 더욱 납득하게 되었습니다. 서로 옆에 앉아 있으면서도 티켓을 통해 의사소통하는 분리된 팀들에게 오너십을 분산하지 않고, 또 이를 통해 인적 착오가 훨씬 줄어들었다는 사실을 감사자들에게 일찌감치 보여줌으로써 회사 측은 감사자들과 꼭 필요한 확신과 신뢰 관계를 구축할 수 있었습니다.

이와 똑같은 전략은 귀사의 보안 팀 및 법무 팀을 상대할 때에도 적용됩니다. 모든 구성원의 요구를 충족할 수 있도록 보장하기 위해 이들 팀을 조기에 자주 참여시키면서 그들과 협력하십시오. 귀사의 경영 이해관계자들에 대해서는 공감을 표시해야 하며, 귀사의 규칙을 통해 그들의요구를 해결할 방법을 꼭 찾으십시오.

재무 관리. 적정 용량을 예측하기 힘들어 종종 과매입되기 쉬운 대규모 초기 자본 투자에서 벗어나 선불형 종량 요금제 (사용한 만큼만 지불) 모델로 전환할 경우, 대개는 현금 흐름이 개선되는 효과가 나타납니다. 그렇지 않더라도 가변 비용을 관리하면 귀사의 기존 재무 관리 방식을 변화시킬 수 있습니다. 대개의 경우, 클라우드가 제공하는 투자 수단을 이용하면서 예산을 최대한 활용할 수 있도록 새로운 규칙을 만들기 위해서는 재무 부서와 긴밀히 협력하는 것이 최선입니다.

Dow Jones에 근무하던 당시, 회사 측의 클라우드 지출비용은 인프라 투자액이 감소하는 것보다 더 완만하게 증가했습니다. 당시 회사 측은 많은 일을 했을 수도 있겠지만 결국에는 회사의 과금액 증가가 재무 팀의 관심을 사로잡았으며, 재무 팀은 회사의 예산을 최적으로 조정하는 파트너가 되었습니다.

회사가 보유한 리소스가 점점 더 제품 개발에 집중되면서 우리는 예측, 예약 인스턴스(RI) 구매 및 인건비 증가율의 자본 평가 등을 중심으로 회사 측 감사자들과 매월 생산적인 케이던스를 도출했습니다. 컴퓨팅 요구 사항이 진화하면서 우리는 수개월에 걸쳐RI 구매를 진행하는 것이 최선이라는 것을 알게 되었으며, 재무 관리에 도움이 될 수 있는 파트너들이 많다는 사실도 알게 되었습니다. Cloudability는 그러한 파트너들 중 하나에 속하며 이들 파트너는 간격을 두고 RI 구매를 진행하는 것에 관하여 최근 1건의 훌륭한 논문을 게시한 바 있습니다. 상세한 설명은 이 논문을 참고하십시오.

앞서 언급했듯이, 이들은 클라우드 여정에서 면밀히 조사할 가치가 있는 몇 가지 규칙일 뿐입니다.저는 여러분이 직면하는 여러 다른 문제들에 대해 알고 싶습니다. 어떤 문제든 간에 새로운 규칙을 만드는 것을 결코 두려워하지 마십시오.
– Stephen
@stephenorban
http://aws.amazon.com/enterprise/

본 블로그 글은 Stephen Orban의 엔터프라이즈 클라우드 여정 시리즈 입니다. 더 자세한 것은 전체 목록을 참고하시기 바랍니다.

Stephen Orban – 리더의 자질을 높일 수 있는 조건

“혼돈과 좌절은 명료성의 부족에서 비롯된다. 이러한 감정은 모든 인간의 목표에 독이 된다.” -Steve Maraboli

 

리더들은 매우 다양한 방법으로 조직을 이끌어갑니다.. 어떤 리더는 공포를 조성하고, 어떤 리더는 모범을 보이며, 어떤 리더는 카리스마로, 그리고 어떤 리더는 다른 사람들을 통해 이끌어갑니다. 모든 리더의 방식에 다소  차이가 있기는 하지만, 지금까지 경험한 바에 따르면 모두 동일한 점이 한 가지 있습니다. . 사람들은 자신이 이해하는 리더를 따르기 마련이라는 점입니다.

사람들은 자신이 이해할 수 있는 정보를 믿습니다. 변화 관리에 있어서도 자신을 이끄는 방향을 이해하지 못할 때  본인이 편안하게 느끼는 상황, 즉 현재 상태로 되돌아가려는 경향을 보입니다. 리더들은 쉽게 이해할 수 있는 간결한 방향을 제시하여 이러한 딜레마를 해결할 수 있습니다. 이렇게 명료한 목적을 제시할 수 있는 능력이야말로 좋은 리더와 뛰어난 리더를 구분하는 기준입니다.

저는 오늘날의 기술 임원들이 자신을 기업의 클라우드 여정을 진두지휘하는 최고 변화 관리 책임자(CCMO™)로 생각해야 한다는 글을 최근에 쓴 적이 있습니다. CCMO에게는 비즈니스와 기술의 융합을 처리하는 동시에 명료한 목적을 제시해야 하는 책임이 있습니다. 이 말은 전략, 전략에 대한 팀의 적합성, 유연한 부분과 그렇지 않은 부분, 결단력, 인내심 등을 명확하게 표현할 수 있어야 한다는 것을 의미합니다.

기업들은 여러 가지 이유로 클라우드로의 전환을 계획합니다. 이러한 이유 중에는 비용 절감, 글로벌 확장, 보안 태세 강화, 대응 민첩성 개선 등이 있습니다. 저의 경험상 기업들은 더 많은 리소스를 중요한 비즈니스에 온전히 투입하는 데 클라우드가 효과적이라는 사실을 깨닫게 되면 클라우드를 플랫폼으로서 기업 전체에 도입하기 시작합니다. 위에서 이야기기한 이유들은 고객과 이해관계자 모두에게 매우 중요한 활동입니다. 하지만 인프라 제공업체가 아니라면 이러한 활동들은 인프라 관리와는 관계가 없습니다.

장단기적 동기가 무엇이든, 모든 직원에게 동기를 알리고 그것을 측정할 수 있도록 해야합니다. 또한 팀을 비롯한 관계자 모두에게 동기와 목적에 대해서 명료하게 알리고, 전 직원이 올바른 방향으로 나아갈 수 있도록 책임 의식을 가져야 합니다.

총괄 책임자로 재임한 초기에는 – 순진하게 들릴지 모르지만 – 제가 총괄 책임자라는 이유 하나만으로 모두가 내 지시에 따를 것이라고 생각했습니다. 물론 실제 리더십은 그렇지 않다는 사실도 어렵게 깨달았습니다. 우리의 전략에서 무엇이 중요한지 명료하게 밝히고 나서야 팀원들의 행동에도 변화가 보이기 시작했습니다. 팀에게 새로운 아이디어 또는 목표를 제시하기 전에 먼저 전략에 대한 팀원의 적합성, 그리고 비즈니스 및 직원의 향후 커리어 계획과의 연계성까지 먼저 고민했습니다. 그런 다음, 이러한 주장들을 보강하기 위해 모든 기회를 이용해야 했습니다.

이는 분기별 타운홀, 사내 블로그, 스프린트 계획 세션에서 전략에 대해 공유하고, 모든 회의를 통해 현재 논의되는 작업을 전략과 연결시키는 것을 의미합니다. 간혹, 불필요하다고 느낄 때도 있었지만 팀의 규모가 클수록 정기적인 개인별 논의의 기회도 줄어들기 마련입니다. 자신의 커뮤니케이션에 대한 결단력과 일관성을 유지하는 것도 매우 중요합니다.

모든 변화 관리 프로그램에서 미지에 대한 두려움은 갈등을 유발하는 가장 흔한 원인 중 하나입니다. 이 점에 대해서는 다음 게시물에서 클라우드 여정을 위한 직원 교육의 모범 사례를 다루면서 설명하겠습니다. 여기에서는 팀원 모두에게 향후 각자의 역할에 대해 명료하게 설명하는 방법이야 말로 리더가 갈등을 해결할 수 있는 효과적인 방법이라는 것을 분명하게 해 둘 필요가 있습니다.

직원 모두가 변화하는 방향을 고려하여 자신의 선택권이 무엇인지 명확히 하는 것은  그들이 변화에 참여하는 방법을 이해할 수 있는 명확한 길을 제시할 뿐만 아니라 심리적 안정감까지도 줄 수 있습니다. 제가 Dow Jones에서 CIO로 재직할 당시에는 부서의 전 직원에게 교육의 기회를 제공한 것은 물론 회사 내에서 새로운 역할로 이동할 수 있는 기회를 제공하였습니다. 우리는 모든 직원들이 클라우드 여정의 일원이 되기를 바란다는 것을 명확히 했고, 실제로 직원들은 가끔 새로운 역할을 맡을 기회를 얻기도 했습니다. 직원들은 모두의  이익극대화를 위해 자신이 알고 있는 풍부한 제도적 지식을 이용하였고, 많은 경우 다른 영역이나 분야로 이동할 때 더욱 요긴하게 사용되었습니다. 이러한 지식은 대체하기 어렵기 때문에 이를 유지하기 위한 모든 노력을 기울이라고 말하고 싶습니다.

변화와 관련된 거의 모든 전략에는 반드시 지켜야 하는 요소도 있고, 더 함축적일 수 있는 요소도 있습니다. 팀원들에게 각각의 전략이 어떤 성격을 띄었는지 명확하게 전달하는 것은 모두가  적합한 영역을 계속해서 확장할 수 있는 기회를 창출하고, 조직의 변함없는 학습 의지를 보여주기도 합니다.

Dow Jones에 재직할 당시, 클라우드 여정의 초기에는 우리가 수행하는 모든 작업을 필수적으로 자동화하였습니다. 일단 클라우드 운영에 대한 전문 지식을 충분히 쌓은 후에야 수십 곳의 데이터 센터를 AWS로 마이그레이션하는 경제적으로 매력적인 비즈니스 사례를 만들어낼 수 있었습니다. 이 시점부터는 플랫폼을 전환하는 리플랫포밍(“lift-tinker-and-shift”) 전략이 목표를 향해 다가가는 데 더욱 효과적이었습니다. 이를 올바르게 수행하기 위해서는 명확한 목적이 필요했고 – 몇 차례 커뮤니케이션을 거쳐야 했지만 -,  자동화 제약을 다소 완화하고 광범위한 마이그레이션 기법을 적용한 이후부터는 발전이 상당히 가속화되었습니다.

모든 엔터프라이즈의 클라우드 여정은 도중에 난관에 부딪히기도 합니다. 앞으로 모든 것이 완벽할 것이고, 업계는 모든 기업들이 여정을 향해 나아가면서 필요한 처방에 대해서 이미 알고 있다고 말할 수 있다면 얼마나 좋을까요. AWS는 고객을 위해 헌신하면서 발생하는 상황에 따라 더욱 규범적으로 대처할 수 있도록 노력하고 있지만 전체 프로세스가 완전히 규격화되어 일괄적으로 처리할 수 있게 될 확률은 낮습니다. 저는 팀의 실수를 꾸짖는 대신, 여정에서 맞닥뜨릴 수 있는 걸림돌을 배움의 기회로 삼아 (동일한 실수를 반복하는 것을 용인하면 안되겠지만) 본인의 목적에 반하는 회의적 태도를 빠르게 없애는 것이 최선의 방법이라는 것을 깨달았습니다. 이전 상태로 돌아가는 것을 택하는 사람들이 여러분의 미래 비전의 잠재력에 영향을 미치지 않도록 하십시오. 분명 쉽지는 않지만, 오랜 인내심과 끈기가 결실을 맺을 날이 올 것입니다..

기억하세요, 연습이 영속성을 만든다(Practice makes permanent)는 말이 있습니다. 여러분에게는 어떤 것이 효과가 있었나요? 있다면 꼭 들어보고 싶습니다.

늘 발전하시기를,

– Stephen;
@stephenorban
http://aws.amazon.com/enterprise/

본 블로그 글은 Stephen Orban의 엔터프라이즈 클라우드 여정 시리즈 입니다. 더 자세한 것은 전체 목록을 참고하시기 바랍니다.