일본IBM의 'Bluemix 여자 사람 미팅' 레포트 - 번역기사

Server Side Architecture Group에서 진행하는 Bluemix에 대한 블로그 이벤트로서 IBM Bluemix에 대한것을 구글링 해 보다가 흥미있는 기사가 있기에 소개해 보고자 한다.

시작하기전에 이 글의 일체의 저작권은 원저자인 Impress사에 있음을 밝혀둔다.

일본IBM의 'Bluemix 여자 사람 미팅' 레포트

원제 : クラウドでも女子会？！　日本IBM「Bluemix女子会」レポート


PaaS 서비스 "Bluemix"관련 이벤트 "Bluemix 여성 모임"이 일본 IBM에 의해 7 월 8 일 저녁에 개최되었다.

 IT 계 스터디 그룹에서는 최근 여성이 주최하는 여성 엔지니어를위한 이벤트 이름에 "여성 모임" 라고 붙이는 케이스를 볼 수있게되어 왔으며, 여성 엔지니어가 전문적인 지식을 교환하며 서로 친목을 다지고 있다.

 처음에 일본 IBM의 미야 사카 마유미 씨 (소프트웨어 사업 본부 소프트웨어 파트너 사업부 파트너 솔루션 사업 개발 부장)가 인사말로 "IBM에서 여성 모임 이벤트를 여는 것은 처음"이라고 말했다. 미야 사카 씨는 IBM 본사의 현재의 사장 겸 CEO 인 버지니아 M·로멧티 씨가 여성임을 소개하며 일부 국가에서는 여성이 더 많은 거점도 있고, 다양성을 중시하는 문화라고 참가자들에게 어필했다.

 이벤트에는 31 명이 참가하였고 그 중 60 %가 대학생, 40 %가 사회인이라는 비율이다. 대부분의 참가자가 Bluemix을 처음 접한다고 하며 이번 이벤트는 Bluemix에서 응용 프로그램의 작성과 배포를 체험하는 형식으로 진행되었다.

이벤트 회장으로 사용된 IT계 모임을 위한 이벤트 공간
21cafe(시부야).  은은한 전구 조명이 멋진 느낌 있는 공간이다.

이벤트 시작. 인사말과 Bluemix해설.

 우선 미야사카씨가 Bluemix를 소개 했다. IBM의 IaaS서비스 "SoftLayer"상에서 동작하는 PaaS서비스로 2월에 베타버전이 공개되었고 미국에서 6월30일 정식버전의 서비스가 출시되었다. 또한, 당초에는 BlueMix라고 표기되었지만 정식버전에서는 Bluemix(M이 소문자로)로 표기가 변경되었다.

 Bluemix는 VMware가 개발한 오픈소스 PaaS구축 플랫폼 Cloud Foundry를 베이스로 하고있다. 따라서 응용 프로그램이 특정 플랫폼에 종속되지 않고 Cloud Foundry 기반 PaaS라면 어디든 이식이 가능하다.

 Bluemix의 특징은 Clud Foundry위에서 당양한 구성 요소가 되는 서비스를 제공하고, 그것들의 전형적인 Web 시스템의 패턴을 정의하여 템플릿으로 제공하고 있는 점이다. 다양한 어플리케이션이 자동으로 설치되어 사용자측은 간편하게 사용할 수 있다고 미야사카씨는 어필한다. 얼마전 퀴즈프로그램에서 우승해 화제를 모았던 인공지능 Watson도 API에서 사용할 수 있다. 또한 서비스 마켓 플레이스도 있으므로 모두에게 즐거운 비즈니스가 되었으면 좋겠습니다 라고 말했다.

 실습은 IBM연구소의 타카하시씨의 사회로 진행되었다. 참가자는 사전에 Bluemix계정과 절차를 설명하는 자료가 배포되었고 각자 소지한 노트북 PC를 이용해 실습하며 필요한 경우 직원이 서포트 하는 형식으로 진행하였다.

 첫번째 세션은 Bluemix서버 환경을 구축하는것으로 시작했다. Bluemix의 Web화면에서 Node.js를 선택하여 응용 프로그램 템플릿을 선택하면, 기반이되는 응용  프로그램이 만들어진다. 또한 데이터베이스 템플릿을 선택하고 응용프로그램을 지정하기만 하면 응용 프로그램과 데이터 베이스가 연결되는 곳을 실습했다.

 두번째 세션은 통합 개발 환경 Eclipse에 Bluemix 플러그인을 추가하여 공개 된 샘플 응용프로그램을 Bluemix에 배포하는것 이었는데, 일부 참가자들은 이클립스 환경구축에 애를 먹기도 하였다.

 세번째 세션은 Bluemix의 Web화면의 GUI조작으로 Web어플리케이션이나 모바일 웹을 개발하는 도구 "RapidApps"를 이용하여 준비된 표 데이터를 RapidApps로 가져와서 데이터 간이나 데이터와 화면 요소 사이의 연관을 GUI에서 설정하여 모바일 Web응용 프로그램을 개발하고 RapidApps 모바일 브라우저 시뮬레이터로 동작을 확인하였다.

실습중인 모습

실습 내용에 대한 설명

자료를 보면서 실제로 자신의 Bluemix환경을 조작

IBM직원 도우미 (누구냐 넌?)

체엄이 끝난 후에는 도넛을 먹으면서 일본 IBM 토쿄 기초연구소의 에노키 미키씨에 의해 "연구소와 클라우드와 나"라는 타이틀로 발표가 이어졌다. 에노키씨는 일본 IBM에 근무하면서 오차노미즈 여자대학의 박사과정에 재학중이라고 한다. 자신의 연구 내용이나 세계의 IBM기초 연구소 및 연구를 소개하고, IBM의 클라우드 비젼 "Cloud V3.0"을 설명했다.

또한 이번 행사에는 오차노미즈 여자대학 정보 과학과 교수 이토 타카유키씨가 협력했다. 이토씨는 일본 IBM출신으로 학생들에게 실습의 장으로서 자교 학생 참가자를 모집했다고 한다.

한입만 깨물어도 다이어트따윈 개나줘버려를 외치게 된다는 악마의 도너츠가 제공되고...

간식과 함께 발표를 듣는 참가자들

 여자들만 모아서 진행하는 이벤트가 무슨 의미가 있겠냐고 물을지도 모르지만 프로그래머의 세계에서는 여성 엔지니어가 그 수에 있어서 절대적으로 적다. 이에따라 여성 엔지니어분들도  남성 엔지니어들과 마찬가지로 신기술에 대한 관심도 있고 배워보고자 하는 의욕도 강하지만 현실적으로는 남자들만 득실거리는 스터디나 세미나에 나가기가 꺼려진다는 의견이 상당히 많은것도 사실이다.

 일본의 경우 외국계 기업을 중심으로 꾸준히 여성 IT엔지니어 인력을 적극적으로 활용하려는 움직임이 퍼지고 있으며, 그 결과 근무중에 다도를 즐길 수 있게 한다던지 여성 엔지니어만의 모임을 활성화 시키는등 다양한 형태의 시도가 진행되고 있다. 하지만 무엇보다 여성 인력이 IT업계에서 안정적으로 오래 일 할 수 있게 하려면 승진/급여에 대한 차별이나 출산/육아에 대한 부담을 줄여야 한다는 과제가 반드시 해결 되어야한다. 기업과 사회 전체의 더 많은 투자가 필요한 까닭이다.

 한국 IBM이나 다른 기업에서도 여성 엔지니어들을 적극적으로 포용하는 이러한 세미나를 개최해 보는것은 어떨까?

어떤 IaaS 클라우드 플랫폼을 택할 것인가? EC2 vs GCE 철저비교

오늘은 클라우드 플랫폼의 절대강자 아마존 웹 서비스(이하 AWS)와 최근 Google Compute Engine(이하 GCE)를 발표하며 공격적인 행보에 나선 구글 클라우드 플랫폼(이하 GCP)에 대해 양 사의 IaaS서비스를 중심으로 비교해 보는 시간을 가져보고자 한다.

서비스 개요

	아마존	구글
서비스명	Amamzon Web Service	Google Cloud Platform
IaaS	Elastic Compute Cloud (EC2)	Google Compute Engine (GCE)
스토리지	Relational Database Serivce(RDS) MySQL 데이터베이스기반의 RDB Simple Storage Service(S3) AWS전용 스토리지 서비스	Cloud SQL MySQL 데이터베이스기반의 RDB Cloud Storage GCP전용 스토리지 서비스
네트워크	Elastic Load Balancer(ELB) 부하분산기능	구글이 제공하는 검색엔진등 글로벌 서비스와 동일한 네트워크 인프라 사용
글로벌 리전	Asia Pacific (Tokyo) Region Asia Pacific (Singapore) Region Asia Pacific (Sydney) Region Asia Pacific (China) Region (※중국 국내 사업자만 사용 가능) EU (Ireland) Region South America (Sao Paulo) Region US East (Northern Virginia) Region US West (Northern California) Region US West (Oregon) Region	us-central1-a us-central1-b us-central1-f europe-west1-a europe-west1-b asia-east1-a asia-east1-b asia-east1-c 1.보안상 데이터센터의 위치는 정확하게 알려져 있지 않지만 아시아의 세 곳중 두 곳은 타이완과 싱가폴에 각각 위치해 있는것으로 알려져 있다. 2.중국의 경우 구글에 대한 차단정책을 실시하고 있어 대 중국 비즈니스의 경우 GCP사용에 주의가 필요함.
가상화 아키텍처	비공개(EC2의 경우 Xen을 사용한다는 설이 있음)	KVM
지원OS	2014년 8월 6일 현 시점으로 아마존 마켓플레이스에 등록된 OS는 80종류이며 리눅스는 물론 상용 윈도우즈와 아마존이 자체적으로 패키징한 전용 리눅스도 제공.	Debian 7 Wheezy Debian 7 Wheezy Backports CentOS 6 openSUSE CoreOS Red Hat Enterprise Linux SUSE Windows Server FreeBSD SELinux

아마존의 경우 아마존 마켓플레이스를 통해 다양한 OS 뿐 만 아니라 목쪽에 따라 다양하게 패키징된 어플리케이션을 이미지 형태로 제공하고 있어 목적에 따라 간단히 클라우드 상에서 서버환경을 구축 할 수 있다는 점이 큰 장점이다.
구글의 경우 인터넷 서비스회사의 절대강자 답게 네트워크 인프라에 있어서 안정적인 속도로 평판이 높으며 특히 자체 개발한 로드벨런싱 서버는 구글 검색등 구글 자체 서비스에 사용되는것과 동일한것이 제공되고 있는것이 큰 강점이다.

 AWS는 2002년부터 서비스를 시작해 오늘에 이르기까지 부동의 1위 자리를 지켜오고 있는 명실상부한 클라우드계의 본좌이다. 긴 역사 만큼 풍부한 도큐먼트와 레퍼런스가 강점이지만 무엇보다 시장의 선도적인 위치에 있는 만큼 많은 클라우드 지원 서비스/제품중에 AWS를 지원하지 않는것은 없다고 봐도 무방하며 가장 중요한 서비스의 품질 또한 업계 탑 클래스이다.

 한편 GCP의 경우 후발 주자로서 2012년 10월 의욕적으로 출사표를 던진 이후 엄청난 물량을 쏟아 부으며 클라우드 가격경쟁을 주도하고 있다. 비공개 이긴 하지만 분기당 수조원 이상의 예산이 클라우드 서비스 인프라 확충에 투입되고 있는것으로 알려져 있으며 인터넷 서비스업계의 최강자라는 이점을 살려서 인프라나 네트워크에 대한 기술력도 클라우드 플랫폼 사업에 그대로 가져오고 있다. 무엇보다 최근 알게된 충격적인 사실은 구글이 클라우드 플랫폼 서비스를 사내 모든 개발에 있어서 최 우선으로 하고 있다는 점 이다.

클라우드 서비스 기업으로의 전환을 선언한 구글의 야망

 사실 구글이 클라우드 사업에 어느정도 비중을 두고 있는지는 지금까지 외부에 잘 알려져 있지 않았지만 얼마전 개최된 Google Atmosphere Tokyo 2014에서 밝혀진 바에 의하면 지금까지의 구글 크라우드 정책이 자사 서비스에 사용된 인프라나 API들을 그대로 외부에 공개하여 제공해 왔던 것에 대해 우선순위를 사외 클라우드 플랫폼 고객을 최 우선으로 하여 모든 인프라와 API를 재 구축하도록 한 것이 확인되었다. 말 그대로 인터넷 서비스 기업에서 클라우드 서비스 기업으로의 변신을 꾀하고 있는것이다. 크롬북, 구글앱스, 구글맵, 그리고 검색에 이르기까지 전 방향에서 진형을 갖추고 본격적인 공략에 나선 구글의 엔터프라이즈 전략의 중심에 클라우드 플랫폼 서비스가 있음은 의심할 여지가 없다.

가격비교

시간당 OS인스턴스 비용 (단위:달러, 1CPU, 3.75GB)

	EC2(m3.medium)	GCE(n1-standard)
CentOS	0.101	0.077
RHEL	0.161	0.137
Windows	0.151	0.117
SLE	0.201	0.187

 기본적으로 책정된 시간당 가격은 GCE가 20%정도 더 싸다. 구글의 경우 1개월을 풀로 사용할 경우 30%가 자동적으로 디스카운트 되고 EC2는 리저브드 인스턴스라는 개념이 있어 장기로 계약하여 이용하는 경우 60%까지 디스카운트가 가능하다.

인터넷 트레픽 과금

우선 아마존 EC2를 살펴보자. (숫자의 단위는 달러/GB이다.)

최초 1GB	무상
다음10TB까지	0.201
다음40TB까지	0.158
다음100TB까지	0.137
다음350TB까지	0.127

다음은 GCE다.

	아시아리전	미주/유럽리전
0-10TB	0.21	0.12
1-10TB	0.18	0.11
10TB이상	0.15	0.08

아시아리전을 이용할경우 GCE가 약간 비싸지고 미주/유럽리전을 사용할경우엔 GCE가 좀 더 저렴하다.

스토리지 과금

다음은 스토리지에 대한 과금을 살펴보자.

	EC2 (Elastic Block Store 스텐더드 볼륨)	GCE
디스크 사용비용 (100GB/월)	$8	$4
디스크I/O에 대한 과금	0.08달러/백만 리퀘스트 (2백만 리퀘스트까지 무료)	없음
스넵샷 영역에 대한 과금 (100GB/월)	$9.5	$12.5

 위 조사는 2014년 8월 기준의 가격으로 실시된 것으로 현재 양사가 서로 경쟁적으로 내리고 있는 상황이므로 가격변동은 그때그때 체크해 보아야 한다.

성능

다음은 마지막으로 성능을 살펴보자.
벤지마크 툴은 UnixBench 5.1.3을 사용하였다.

	인스턴스 타입	OS	CPU	가격(달러/시간)	UnixBench
EC2	m3.medium (Tokyo)	Amazon Linux AMI	3 ECU	0.101	295.6 (2014년5월측정)
GCE	n1-standard-1 (Asia)	CentOS 6	1 vCPU	0.077	1187 (2014년8월측정)

ServerBear.com에서 공개한 벤치마크 결과

PLAN	HOST	HDD	RAM	UnixBench
Small	EC2	160GB	1.7GB	180.3
Medium	EC2	410GB	3.75GB	393
Large	EC2	850GB	7.5GB	661.9
Extra Large	EC2	1.69TB	15GB	1155.1
High-CPU Medium	EC2	350GB	1.7GB	721.4
High-CPU Extra Large	EC2	1.69TB	7GB	1805.9
High-MEM Extra Large	EC2	420GB	17.1GB	966.2
High-MEM Double Extra Large	EC2	850GB	34.2GB	1427.7
High-MEM Quadruple Extra Large	EC2	16.9TB	68.4GB	2403.8
Cluster GPU Quadruple Extra Large	EC2	1.69TB	22GB	1569.5
High I/O Quadruple Extra Large Instance	EC2	2TB	60.5GB	2652.2
f1-micro	GCE	-	600MB	442.1
n1-standard-1	GCE	-	3.75GB	2082.7
n1-standard-4-d	GCE	1.77TB	15GB	3530.6

 UnixBench는 서버성능의 지표로 많이 사용되고 있는데 CPU와 메모리 그리고 디스크I/O에 대한 성능을 종합적으로 평가하여 수치화 한다. 일단 스코어 자체는 4배정도로 GCE가 압도적이며 ServerBear.com에서 발표한 수치로는 무려 5배가 넘게 차이가 나는데 이는 VM에서 사용되는 하드웨어 자원의 구성에따른 차이라고 보여진다. 아마도 구글측에서 하드웨어에 상당한 투자를 하고 있는만큼 최신 아키텍처와 더불어 더 풍부하게 하드웨어 리소스를 사용하고 있기 때문이 않을까 추측해 본다.

결론

과금이나 벤치마크의 결과로는 GCE가 우세한 모습을 보이고 있지만 AWS는 연륜 만큼이나 풍부한 레퍼런스를 보유하고 있는것을 잊지 말자. 그리고 아마존 마켓플레이스라는 서버 사이드 솔루션의 생태계또한 비즈니스의 간편한 전개를 돕는 든든한 지원군이 되어준다. 가격에 있어서도 대체적으로 GCE가 우세한 가운데 AWS는 장기적으로 사용할 경우 좀 더 폭넓게 디스카운트를 받을 수 있는 가격정책을 실시하고 있는것도 눈여겨 볼 만 하다.


 현재 춘추 전국시대와 같이 새로운 기업들이 생겨나고 또 사라가지 있는 클라우드 컴퓨팅 산업은 박리다매라는 사업의 특성상 결국 최후에 살아남은 2,3개사 정도가 시장을 싹쓸이 할 것으로 보여지며 그 중에서도 1위 업체가 시장 점유을 대부분을 가져가는 승자 독식 현상도 뚜렷하게 나타날 것으로  예상된다.

 아마존은 시장을 개척하고 또 오랫동안 클라우드 컴퓨팅이라는 분야를 사실상 만들어낸 장본인이며 선도적인 위치에 있으면서도 노력을 게을리 하지 않은 덕분에 그간 제대로된 적수가 없는상태였다. 하지만 인터넷 서비스 업계의 절대 강자 구글이 참전하면서 세력 지도에 큰 변동이 일어나려 하고 있다. 구글은 규모의 싸움인 클라우드 컴퓨팅에 있어서 머니게임에서도 밀리지 않을뿐더러 스스로 클라우드 컴퓨팅에 기반을 두고 서비스를 제공하고 있는 회사이기 때문이다. 그리고 무엇보다 세계 최강이라고 불리우는 엔지니어 집단을 보유하고 있다.

 어찌되었든 양쪽 다 만만치 않은 상대이고 앞으로 물러설 수 없는 진검승부가 이어질 것이다. 이것이 내가 사용자로서 두 회사의 대결을 흥미진진하게 바라보고 있는 이유다.

서평 - IT엔지니어의 제로부터 시작하는 영어공부법

오늘의 주제는 영어공부다. 그것도 프로그래머를 위한 영어공부. 

IT엔지니어의 제로부터 시작하는 영어공부법
ITエンジニアのゼロから始める英語勉強法

제목에서 부터 medicine의 smell이 느껴지지 않는가?

 원래는 아는분께 선물할 요량으로 구입을 하였는데, 일본어를 전혀 못하는 분인지라 책 내용을 번역해 소개해 보기로 한다. 책 내용은 일본인을 대상으로 하였지만 한국어에도 대부분 그대로 적용되므로 일본어를 한국어로 바꾸었다.

 이 책은 저자인 牛尾剛Ushio Tsuyoshi씨(필자가 소속한 Mamezou와도 인연이 있으신 분이다)가 영어 강연(Agile2011)에 연사로 초청되어 10개월만에 직접 체득한 영어공부법을 설명한 책이다. 저자는 IT엔지니어 답게 시중에 나와있는 여러 영어공부방법을 분석하여 자신에게 적용시킨 후 이 책을 내 놓았다. (역자: 책 전체적으로는 정찬용씨의 '영어공부 절대로 하지마라(영절하)'에서 많은 영향을 받은듯 하며 책 내용중에서도 직접 서명을 언급하며 일독을 권하고 있다. 영절하의 일본어판은 현재 일본에서도 상당히 많이 팔리는 영어공부 관련 서적중에 하나다.)

 우선 저자는 여러 영어공부법을 벤치마킹하여 다음의 다섯가지 공통되는 원칙을 찾아내었다.

 영어 공부법의 다섯가지 원칙

 사운드 퍼스트의 원칙Sound First

 먼저 귀가 뚤려야 한다. 이해를 하지는 못하더라도 우선 말로서 들릴수 있어야 한다. 인간의 뇌는 소리에 대해서 필터링을 적용하여 언어와 그 외의 소리(노이즈)로 구분하여 처리하는데, 외국어에 대해서는 언어가 아닌 노이즈로 인식을 하게 된다. 귀를 뚫는데 있어서 저자가 제시한 포인트는 다음과 같다.

• 원어민의 발음에 최대한 가깝게 소리를 낼 수 있게 발음과 억양을 연습하는것이 맨 처음 이뤄져야 한다. (역주: 저자는 American Accent Training을 이용하여 매일 30분씩 한달정도 연습하여 그렇저렇 쓸만한 발음을 낼 수 있게 되었다고 책에 적고 있다. 문제는 이 책의 저자가 영어로 강연하는 모습을 유투브 어디에서도 찾아 볼 수가 없기때문에 스스로 말하는 쓸만한 발음이 어느정도인지 확인할 길이 없다는 점 이다. 이 책이 일본인에 의해 쓰여졌다는 사실을 잊지 말자.)
• 영어에 사용되는 음을 머저 이해하지 않으면 듣기도 읽기도 잘 늘지 않는다.
• 처음에는 의미를 이해하지 못하는게 당연하다. "음"에 대한 감을 단련해 두자. 

다이렉트 이해의 원칙Direct Understanding

• 영어를 번역해서 생각하지말고 영어 그대로 이해한다.
• 영어는 한국어로 1대1 번역이 불가능하다.

스피킹중심의 원칙Speaking Centered

• 네이티브의 발음과 억양을 흉내내어 음독하는것은 영어를 유창하게 말하기 위한 초필살기이다.
• 단, 한국식 발음으로는 해 봤자 아무소용 없다. 반드시 네이티브의 발음을 최대한 흉내낼것!
• 음독시에는 스마트폰의 녹음기 기능등을 이용해 자신의 발음을 체크해 볼 것

문맥이해의 원칙Contextual Experienced

자잘한 단어나 문법이 아닌 전체적인 문맥으로서 대량의 문장을 이해하는 방법.

• 단어도 표헌도 그 상황 안에서 의미를 파악해야 함.
• 같은 상황에서 몇번이고 같은 표현을 마주함으로서 그 의미가 자연히 통하게됨.
• 단어나 문법을 따로 공부할 필요는 없다. 그것보다 실생활의 영어를 대량으로 접해보자. 그러면 자연스럽게 몸에 익혀진다. 

선택과 집중의 원칙Choice and Focus

• 영어는 크게 미국식과 영국식이 있어 어느쪽이든 선택해야만 한다.
• 자신이 주로 사용하고 싶은 쪽으로 타겟팅을 해서 그쪽 분야의 영어를 집중적으로 공략한다. 예를들면 저자는 Agile개발이라는 분야에 타겟팅을 하여 집중적으로 공부했다고 함.

필자는 영어를 잘 하기 위해서는 뇌에 새로운 언어영역을 만들어야 한다고 말하고 있는데, 이를 영어뇌라 부른다.

이 책에서 제안하는 영어학습의 큰 그림

이 책의 저자가 제안하는 영어학습의 전체적인 모습은 다음과 같다.

 각각의 세부적인 사항은 인터넷에 공개된 정보가 많으므로 여기서 따로 설명하지는 않겠다. 다만, 기간을 정해놓고 각 기간마다 공부의 성과가 어느정도인지 스스로 체크해보고 레벨이나 학습법을 체크할 필요가 있다. 맞지 않는 레벨이나 방법이라면 셀프 피드백을 통해 자신에게 맞는 방법으로 바꿔 나갈 필요가 있다고 저자는 말한다. 이른바 영어공부의 린 방법론이다.

 위의 전체상에 대해 저자가 소개한 몇가지 팁은 다음과 같다.

• 다독 : 영어에 기반이 아주 없는 사람이라면 우선은 영어동화책부터 시작한다. 이 책은 절대적인 '양'을 강조한다. 쉬운것 부터라도 많이 읽는것이 중요하다. (역자: 영어동화책 읽기는 필자 주변의 지인들도 많이 권하는 방법이다. 킨들이나 iBook,구글 플레이를  통해 무료 또는 상당히 저렴하게 구할 수 있다. 반드시 미리보기 등을 통해 자신의 레벨에서 사전 없이 읽을 수 있는 수준인지 살펴보고 구입하자. 참고로 필자는 수년전 동화책인줄 알고 헤리포터를 아마존서 샀다가 고스란히 헌책방에 헌납한 경험이 있다. 살아있는 영어를 접하고 싶다면 외국인의 SNS를 팔로우 하는것도 효과적이다. 자신이 배우고자 하는 영역의 인물이라면 자연스럽게 그 분야의 어휘를 늘려갈 수 있을것이다. 일단 관심사와 연관시켜 모든 생활의 주 사용 언어를 영어로 바꾸는 노력이 필요하다.) 
• 슈퍼메모 : 단어 암기 툴로 유명한 anki를 사용해 본 단어들을 정리해 놓자. (역자주: 단기 기억에서 장기기억으로 옯겨가기위해서는 반복적으로 기억하는것이 반드시 필요하다. anki는 플래시 카드 툴 중에서도 가장 추천할만 하다.) 
• 영영사전 : 필자는 롱맨 영영사전을 추천하고 있다. 영영사전으로 봐도 단어의 뜻이 이해가 가지 않을경우 구글 이미지 검색을 이용한다. (역자주: 이미지 검색 뿐만 아니라 그냥 구글 검색을 이용해도 관련된 생생한 정보들이 나열되므로 기억하는데 많은 도움이 된다.)

결론

 여기까지 책의 앞부분을 소개해 보았다. 뒷 부분은 피드백을 통해 영어공부법에 대한 자신만의 방법론을 확립하는 팁을 위주로 쓰여져 있다. 제목과는 달리 딱히 IT엔니니어를 위한 영어공부법이라는 느낌은 들지 않지만 어찌되었든 영어공부법의 이론적 방향을 잡는데는 참고가 되리라 본다.

 사실 필자는 영어공부법에 대한 책을 사는것에 반대하는 입장이다. 모처럼 마음잡고 공부를 해 보려던 귀중한 의욕을 책 한권 읽는데 다 써 버리고는 왠지 모를 달성감에 정작 공부는 흐지부지 된 적이 많기 때문이다. 다만, 이 포스팅을 한번 읽는 정도의 시간이라면 충분히 투자해 볼 만 하지 않을까?

 영어공부를 본격적으로 해 볼 요양이라면 반드시 검색엔진의 검색결과 언어설정을 영문으로 해 놓고 사용 하자. 브라우저에 영어 사전 확장기능을 넣어 놓자. 인터넷의 등장으로 비록 사이버상에서 이지만 마음먹기에 따라서는 얼마든지 영어권에서 생활하는 사람들과 같은 인터넷 환경을 누릴 수 있게 되었다. 영어권 커뮤니티에 가입하고 영어뉴스를 보고 영어권 사람들과 SNS를 즐기자. 어찌되었든 생활상에서 영어를 문화의 일부로서 정착시키려는 노력이 필요하다.

 모쪼록 실패하더라도 도전해 보자. 영어공부만큼 적은 투자로 많이 얻을 수 있는 공부도 없다. 인터넷 세상에선 영어구사가 가능한 것 만으로도 세상이 나와 직접 링크되기 때문이다.  마지막으로 필자가 좋아하는 영화의 대사를 소개하는것을 끝으로 포스팅을 마무리 짓고자 한다.

You, me, or nobody is gonna hit as hard as life. But it ain't about how hard ya hit. It's about how hard you can get it and keep moving forward. How much you can take and keep moving forward. That's how winning is done!

Robert "Rocky" Balboa, Sr.

TDD는 벌거벗은 임금님의 투명옷인가? (3) - TDD는 UT가 아니다.

TDD는 벌거벗은 임금님의 투명옷인가?

• 1. TDD는 죽었다. 테스트여 영원하라!
• 2. TDD의 사망에 대한 검증
• 3. TDD는 UT가 아니다

 각종 커뮤니티에서 난리가 나고 업계의 거두가 모여서 현피맞장까지 뜬 TDD를 둘러싼 일련의 소동에 대한 핵심은 다음의 한문장으로 요약될 수 있을것이다.

테스트를 먼저 작성하고 코드를 적는것이 정말로 개발에 그만큼의 가치를 가져다 주는가? 

 그리고 당연하게도 이 물음이 TDD. 즉 테스트 퍼스트 개발을 둘러싼 논쟁의 핵심이 되었어야만 했다.

 TDD의 창시자는 누구이던가? 오늘날의 개발자에게 있어서 십계명이나 다름없는 그 유명한 애자일 선언에 참여한 맴버중에서도 맨 첫머리에 이름을 올린 Kent Beck선생이 아니시던가! 하지만 이러한 '이름의 권위' 앞에서 TDD는 자동화 테스트와 동일시 되어 버려 그 가치를 올바로 평가받을 기회를 잃어버렸던게 아닐까?

 하지만 TDD에만 포커싱을 했으면 좋았을 DHH의 지적질에 애먼 유닛 테스트(이하 UT)가 포함되는 순간, 토론의 목적지는 저 멀리 안드로메다로 재 설정 되어 버리고 만다. Mock오브젝트에만 의존하는 생각없는mindless UT에 대한 반감은 TDD옹호론자라고 해도 공감하는 부분이지만, 엄연히 TDD와 UT에 대한 논쟁은 구분되어 이루어져야 만했었다.

 결론적으로 Martin Flower가 주최한 6회에 걸친 토론중에서 순수하게 TDD자체의 유용성에 대한 토론은 얼마 되지 않았으며, UT에 대한 유용성은 지금와서 이야기 하는것 자체가 무의미할 정도로 업계 전반에서 이미 상식으로 받아들여지고 있는 상황 이므로 아무런 의미가 없었다.

 나름 업계의 존경을 받는 머리 좋은 양반들이 그 귀중한 시간을 내어서 공개적으로 진행한 이벤트 치고는 참으로 어처구니 없는 전개가 아닌가? (그런데 토론을 자세히 보면 능구렁이 같은 Kent Beck이 덩치에 어울리지 않는 애교를 섞어가며 TDD에 대한 논점을 교묘히 흐리는 장면을 자주 볼 수 있다.)

 다시 TDD의 이야기로 돌아와 보자. 

 UT와 뒤섞여 버린 진흙탕 싸움에서 TDD에 관련된 쟁점을만을 분리해 보면 다음의 세가지로 요약된다.

1. TDD는 오버헤드가 너무 크다  TDD는 커버리지를 중시하지는 않는다고 하면서도 모든 코드에 대한 테스트코드의 작성을 의무화 함으로서 이에 위배되는 모습을 보인다. 결국 개발자는 쓸데 없는 UT작성에 많은 시간을 빼앗길 수 밖에 없다. 하지만, 어느정도 비용이 소요된다 하더라더 테스트 코드가 없는 코드 보다야 훨씬 나을수도 있지 않을까?
2. TDD가 설계를 망친다  테스트를 먼저 작성해야만 본 코드를 작성하도록 강제하는 룰은 시간에 쫒기는 개발자에게 유닛 테스트를 작성하기 쉬운 설계를 은연중에 강요하게 된다. 이는 결국 유닛테스트를 작성하기 어려운 시스템 횡단적인 기능을 기피하게 만들고 시스템의 설계를 기형적인 모습으로 만들것이다.  
3. TDD가 테스트를 망친다  1,2와 관련하여 결국 UT만이 너무 강조되는 상황에서는 mock에 의존한 하나마나한 형식적인 테스트로 흐르기 쉬우므로 우리는 이 점을 경계해야만 한다. 또한 UT만큼이나 시스템테스트, 시나리오 테스트도 자동화에 힘을 기울일 수 있어야 할 것이다. 

Tip 요즘 많은 프로젝트들에서 빠르게 실행되는 UT와 시간이 걸리는 DB를 사용하는 결합테스트, 또는 시스템 테스트를 분리해서 구성하고 있다. UT는 커밋시에 개발자 스스로 체크하도록 하고 시간이 걸리는 DB나 그 밖의 미들웨어를 사용하는 테스트는 UT와 함께 젠킨스 등의 CI툴을 이용해 코드 변경시에 실행되도록 해 놓으면 개발자의 시간을 절약하는데 많은 도움이 될 것이다. 아울러 특정 DB에 종속되지 않는 퍼시스턴스라면 UT에도 인메모리 DB를 사용해 테스트 속도를 고속화 할 수 있다.

 TDD가 유용한지 아닌지는 현재 작성하는 프로그램의 성격과 내용, 그리고 작업자의 숙련도에 따라 달라지겠지만 어느정도 오버헤드를 감수해야 함에는 틀림없는 사실이다.

 그리고 여기서 한가지 간과하지 말아야 할 사실은 TDD의 태생이다. TDD는 초기 에자일 프로세스중 하나인 eXtreme Programming과 함께 2000년대 초반에 등장하였는데, 당시엔 오늘과 같이 xUnit테스트가 일반적이지 않았고 대부분의 테스트가 수작업에 의존하던것이 당연하던 시절이다. 이러한 당시 상황속에 UT의 작성을 의무화 하기 위한 하나의 충격요법으로서 XP와 함께 탄생한 TDD를 오늘날에 와서까지 굳이 이를 따라야 할 필요가 있을까?

 필자는 UT가 실행코드와 함께 필수로 받아들여지고 있는 현 시점에서 TDD가 더이상 큰 역할을 하기 어렵다는 DHH의 주장에 동감한다. 이상적인 자동화 테스트 코드는 맹복적인 코드 커버리지보다는 프로그램이 어떻게 움직여야 할지를 기술하는 문서화의 한 형태여야만 하기 때문이다. 반대로 자동화 테스트가 프로그램의 동작을 충분히 설명해 주지 못하고 있다면 추가나 보완이 필요하다고 봐야 한다.

 TDD의 채택여부는 프로젝트의 내용이나 구성원의 취향에 따라 충분히 어느쪽도 선택 가능할 것이다. 하지만, 어떠한 경우라도 자동화 테스트가 없는 개발만큼은 피해야 한다. 이것이야 말로 현대 소프트웨어 개발에 있어서 의심할 여지가 없는 진리이다.

TDD는 벌거벗은 임금님의 투명옷인가? (2) - TDD의 사망에 대한 검증

TDD는 벌거벗은 임금님의 투명옷인가?

• 1. TDD는 죽었다. 테스트여 영원하라!
• 2. TDD의 사망에 대한 검증
• 3. TDD는 UT가 아니다

이번 포스팅에서는 지나번 소개한 Rails의 개발자 DHH의  "TDD는 죽었다. 테스트여 영원하라!"에 뒤이어 펼쳐진 TDD에 대한 일련의 논쟁을 다뤄보도록 하겠다.

 DHH는 이후 "테스트를 위한 설계의 폐해Test-induced design damage"과 "데이터베이스 테스트는 느리다라는 편견Slow database test fallacy"라는 포스팅을 추가로 발표한다. 시간도 많고 영어에 자신이 있다면 위의 글들을 한번 읽어 보는것도 좋겠지만 요점정리 중심의 참고서 교육에 길들여진 분들을 위해 InfoQ관련 기사('TDD 사망'에 대한 검증Examining the 'TDD is Dead' Controversy) 내용을 소개한다. (필자의 견해는 - 이후 각주 형태로 추가하였다.)

원문 :  Examining the 'TDD is Dead' - InfoQ

DHH의 주장 요점정리

• 많은 개발자들이 TDD를 사용하지 않는 코드는 더티한 코드라고 생각하도록 몰아넣고 있다. - 사실상 DHH가 이 논쟁을 시작하도록 한 직접적인 원인이 아닌가 싶다. 누군가 DHH에게 "니 코드는 구려. 유닛 테스트가 없쟎아?" 이렇게 말한것이 아닐까?
• 유닛테스트 주도의 설계는 좋은 생각이 아니다. - TDD 근본주의자들은 제대로 된 설계는 테스트하기가 쉽다고 말한다. 필자는 이것을 부정하진 않는다. 하지만 '테스트하기 좋은 설계' = '좋은 설계'가 성립하는것은 아니다.
• TDD의 개념인 "테스트는 빨라야 한다"는 근시안적인 생각이다. - 아무래도 테스트의 속도는 개발자 환경에선 부담이 될 수밖에 없다. 다행이도 젠킨스와 같은 자동화CI 툴이 도입된 이후로는 이러한 부담이 많이 줄었다. 자동화 테스트를 돌릴 수 있는 환경만 만들어 놓는다면 개개인은 자신의 코드에 대한 풀테스트 결과는 CI서버 상에서 확인 가능하게 되며 개인레벨에서 코드 커밋 이전에 수행해야만 하는 테스트는 코드에 의해 새로 작성된 테스트 케이스의 결과 확인만으로 충분할 것이다.
• TDD에 대한 믿음은 시스템 테스트를 완전히 잋어버리도록 만든다. - DHH의 이러한 생각은 시스템 테스트나 시나리오 테스트를 자동화 하도록 권장하는 BDD의 영향을 받은듯 싶다. 실제로 Ruby에서는 BDD툴인 RSpec이 큰 인기를 누리고 있다.
• 유닛테스트에 포커싱을 하거나 유닛테스트만을 행하는것은 큰 규모의 시스템을 만드는데에 도움이 되지 않는다. - 큰 규모의 시스템을 만들기 위해서는 반드시 여러 레이어를 횡단하는 테스트의 도움이 필요하다.
• 100% 커버리지는 웃기는 이야기다 - 100% 커버리지 달성에 목매는 개발현장을 심심찮게 본다.  이런 현장에는 십중팔구 생각하기 싫어 하는 PM이 존재한다. 100% 커버리지는 품질에 대한 그 어떤 보장도 되어주질 않는다.
• 프로그래머는 소프트웨어가 과학이 되길 원한다. 하지만 소프트웨어는 과학이 아니다. 그것은 좀 더 문학 창작에 가깝다. - 얼마전에 해커와 화가를 읽으면서 공감했던 부분.
• 좋은 소프트웨어는 엔지니어링과는 다르다. 
• 그것은 마치 글쓰기와 같다.  명확하고 간결한 글이 난해한 글보다 낫다.
• 명확함은 좋은것이다. 따라서 테스트 커버리지나 테스트 스피드가 아니라 명확함이야 말로 추구하는 목표중 하나가 되어야 한다. 
• 좋은 개발자가 되는것은 좋은 작가가 되는것만큼 어렵다. - 아무리 그래도 좋은 작가가 되기 보다는 쉽지 않을까? 아무리 생각해 봐도 좋은 개발자의 수가 좋은 작가의 수보다는 많아 보인다.
• 글쓰기와 마찬가지로 좋은 프로그래머가 되기위한 가장 명확한 방법은 많은 소프트웨어를 만들어 보고, 또 좋은 소프트웨어의 코드를 읽어보는것이다. - 100%공감한다. 

커뮤니티에서 이에대한 반응은 광범위하게 나타났으며(트위터의 관련 해시태그#tddisdead를 보라), 반응또한 "역시 그렇군"에서 "멍청한 소리다"까지 다양하게 나타났다.

응답의 대부분은 TDD를 좀 더 실용적으로 적용할 필요가 있음에 초첨을 맞추고 있다.

스스로를 소프트웨어 장인집단으로 부르는 8thlight의 대표 Martin은 자신의 블로그에서 "만약 당신이 TDD를 하지 않으면서 TDD 만큼 효과적인 다른 무언가를 하려고 한다면, 기분이 나빠지게 될 것이다."라고 말한다. 그의 이야기를 좀 더 들어보자.

왜 우리는 TDD를 하는가? 우리는 TDD를 한가지 가장 중요한 이유와 다른 몇가지 덜 중요한 이유때문에 실시한다. 덜 중요한 이유들은 다음과 같다.

1. 디버깅에 쓰는 시간을 줄일 수 있다.
2. 테스트 자체가 정확하고 꼼꼼하며 명확한 가장 저레벨의 시스템 사양이 된다.
3. 테스트 우선 개발에 있어 각각의 테스트는  다른 테스트들과 디커플링 될 필요가 있다. 우리는 이러한 디커플링이 유익하다고 믿는다.

이러한 것들이 덜 중요한 TDD 도입의 필요성들이다. 그리고 이것들은 아직 논쟁의 여지가 있다. 그렇지만 가장 중요한 이유에 대해서는 논쟁의 여지가 없을것이다.

• 만약 당신이 실뢰할 수 있는 자동화 테스트를 가지고 있다면,  그리고 그 테스트가 언제든지 실행될 수 있다면 , 당신은 테스트가 모두 통과되었다는것 하나만 가지고도 아무런 두려움 없이 빠르고 간편하게 코드를 개선해 나갈 수 있다.

Martin Fowler “Hey. Soap. You wanna know this week’s Lotto numbers?”

Martin Fowler "My war ends with you."

Martin Fowler는 DHH와 Kent Beck을 초대하여 둘 사이의 논쟁을 중계하였다. (Kent Beck은 DHH의 포스팅에 대해 즉각적으로 반응했었다.)

리즈시절의 Kent Beck 사진.

2014년 7월 시점의 Kent Beck 페북 프로필 사진.
외모와는 달리 구글 플러스의 이벤트로 진행된  토론에서의 모습은 애교가 넘치신다.

Martin Fowler는 이번 토론에 대해서 다음과 같이 요약했다.

1)우리는 TDD의 흐름에 대해 우리들의 경험을 이야기 했는데, 방법론으로서의 TDD와 자동화 코드는 자주 혼동되어졌다.
2)DHH는 hexagonal rails와 같은 테스트 주도 개발의 접근방식에 의한 테스트 코드를 의식한 설계가 과도한 간섭과 복잡성으로 인해 망가질 수 있다고 생각한다. Kent는 그것이 TDD에 기인한 문제라기 보다는 설계 자체의 품질 문제라고 생각한다.
3)우리는 프로그래밍을 하는동안 피드백을 얻을 수 있는 당양한 체널을 통해 논의를 진행하고, 품질보증의 피드백을 개발자들에게 제공한다.
4)우리는 테스팅과 TDD의 몇몇 단점들에 대해서 논의했다. 당신은 너무 많은 테스팅을 하고 있는가? 그리고 그러한 테스팅은 기능 코드가 가져다 주는 가치보다 팀에게 더 많은 가치를 제공하는가? - 테스트 코드와 실행코드 사이의 밸런스에 대해서 생각해 보자.

Gergely Brautigam은 "TDD는 죽었다. - 사실이 아님TDD is Dead - Not really"라는 제목의 포스트에서 다음과 같이 말하고 있다.

TDD는 죽지 않았다.  명백하게 아직도 많은 사람들의 지지를 받고 있는데 어떻게 죽었다고 할 수 있는가?  이것은 마치 디자인 패턴은 죽었는가? 또는 Functional Automation이 죽었는가? 또는 오레오 쿠키는 죽었는가? 와도 같은 질문이다.
그렇다. TDD는 죽지 않았다. 그리고 지금까지 죽은적도 없다. 그것은 아마도 새로운것으로 변화 하거나 보다 나은것으로 바뀔 수는 있을것이다. 하지만 절대 죽지는 않는다. 그러므로 이 이야기는 이제 그만두자.

그는 다양한 레벨에서의 데트팅의 중요성과 일반적으로 테스트가 제대로 이뤄지지 않는 많은 팀들에 대한 이야기를 이어갔다. 그는 테스트 코드를 작성하지 않는 일반적인 이유로서 품질에 대한 관심부족과 시간에 쫓기는 많은 개발자들을 예로 들었다.
그의 결론은 다음과 같다.

그것은 소프트웨어 테스팅에 대한 10년간의 관찰과 경험속에서 얻은 저의 결론입니다. 시작은  가벼운 틀 위에서 진행하고, 몇가지 선행 테스트들은 당신이 이것을 오래 지속하는데 도움을 줄 것입니다. 적어도 한두개의 납입테스트는 당신의 비즈니스 로직을 더 잘 이해하는데 도움을 줄 것입니다. 한두개의 유닛테스트 역시 당신이 당신의 로직을 이해하는데 도움이 될껍니다. 나는 빌어먹을 모든 테스트를 전부 다 하라고 말하는게 아닙니다. 내가 아는 한 당신은 그럴 필요가 없습니다. 하지만,  품질을 위해서 최소한 몇개는 작성해야 합니다.

Gil Zilberfeld는 애자일 선언문으로부터 다음과 같은 포인트를 찾아내었다.

우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을 도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고 있다. 우리는 아직 완벽한 방법을 알아내지는 못했다.  TDD는 다른것들과 마찬가지로 보다 나은 소프트웨어 개발을 위한 여정에서 찾아낸 아이템들중 하나일 뿐이다.

Docker 전용 경량 리눅스 - CoreOS

지난번 구글에서 개발한 차세대 PaaS 클라우드 플랫폼인 docker의 소개에 에 이어서 오늘은 이 docker를 구동하기 해 최적화된 CoreOS를 소개한다.

CoreOS는 Docker구동에 특화된 리눅스OS를 목표로 탄생한 OS이며 다른 리눅스들과 구분되는 CoreOS의 특징은 크게 다음의 세가지 이다.

최소화된OS : CoreOS는 114M의 메모리만을 사용하며 CoreOS측에 의하면 일반적인 리눅스에 비해 40%적은 메모리 사용량이라 한다.

빠른OS업데이트 : CoreOS는 OS용으로 2개의 부트파티션을 지니며, 이를 이용해 업데이트 작업을 빠르고 안정적으로 수행한다.(이를 CoreUpdate라 부른다.)

이게 무슨 이야기 인가 하면, 아래 그림과 같이 A파티션에서 동작하는 CoreOS는 B파티션에 동일한 내용을 지니고 있다. OS업데이트는 B파티션에서 수행함으로서 현재 운영중인A파티션의 실행에는 영향이 없고, 업데이트가 끝나면 리부트 후 바로 업데이트가 적용된 B파티션 OS로 스위칭 되므로 매우 빠르고 안정적인 OS업데이트가 가능해진다.

이러한 일련의 OS업데이트 작업은 만약 업데이트에 문제가 발생했을경우 A파티션이 남아 있으므로 손쉬운 롤백이 가능하다는 장점이 있있으며 조작 또한 웹콘솔상에서 원격 제어가  가능하다.  CoreUpdate는 상용 서포트에서만 사용 가능한 기능이다.

Docker구동에 최적화된 아키텍처 채용: CoreOS는 잠시후에 소개할 etcd나 웹인터페이스를 이용한 모니터링 기능등 대규모 클러스터링에서 안정적으로 Docker를 서포트 하는것에 특화된 OS이다.

컨테이너 로드벨런싱

요즘 대세인 미려한 UI의 Web관리콘솔.
CoreUpdate도 이 콘솔을 이용해 수행이 가능하다.
개인적으론 커맨드라인 인터페이스를 선호하지만
요즘 개발자들은 이런게 없으면 어플리케이션이 고급지지 못하다고 생각하는듯 싶다. 

etcd란?

etcd는 go언어와 Raft프레임워크 이용해 작성된 오픈소스 key-value 저장소로 대규모 Docker 클러스터링에 있어서 컨테이너들을 유기적으로 연동시키고 억세스하기 위한 세련된 아키텍처를 제공한다.

etcd Overview

좀 더 설명하자면 OS에 배당된 IP어드레스에 비해 탑재된 컨테이너들의 수는 엄청나게 많은데 이러한 컨터이너들에 접근하기 위해서는 IP어드레스 이외의 효율적인 어드레싱 수단을 필요로 하게 된다. etcd는 이러한 어드레싱을 HTTP/JSON을 이용해 구현하고 있으며 빠른 성능과 암호화 제공등으로 현재 Docker사용자들에게 주목받고 있다.

Docker컨테이너 실제 구성예. 효율적인 어드레싱 수단이 필요한 이유이다.

지원하는 플랫폼

직접 물리서버에 설치도 가능하고, Vagrant,Amazon EC2, Azure, QEMU/KVM, VMware그리고 OpenStack에 이르기까지 요즘 인기있는 가상화/클라우드 플랫폼은 충실하게 지원하고 있다.

특히, docker를 이용한 대규모 클러스터링 구현은 vagrant에 의존하지 않고는 무척 고된작업이 되어버릴 것 이다. 지금부터 docker를 이용한 클러스터링에 관심을 가지고 사용해 보려는 유저는 이 CoreOS와 함께 vagrant를 같이 익혀두면 크게 도움이 될 것이다.

참고자료

• Using CoreOS
• Rails Development Using Docker and Vagrant

클라우드 잔혹사 - 사고로 살펴보는 클라우드 컴퓨팅의 흑역사

요즘은 어딜가나 IT 관련 스타트업 성공에 클라우드 컴퓨팅의 이야기를 빼 놓을 수 없다. 이러한 성공사례는 각 클라우드 서비스 제공사에서 친절하게 설명하고 있으므로 굳이 여기서 소개하지는 않겠다.

각사의 클라우드 성공 사례 소개 페이지

• SaaS Salesforce 
• PasS Microsoft Azure 
• IaaS Amazon AWS

오늘의 주제는 제목에서 쉽게 짐작 할 수 있겠지만 클라우드 컴퓨팅의 어두운면을 살펴 보고자 한다.

이미지 출처 : linkedin

 바로 얼마전인 6월 17일, AWS를 이용해 코드 호스팅 서비스를 제공하는 직원 여섯명의 영국 벤처기업인 Code Spaces는 DDos공격에 직면한다. 그리고 뻔한 이야기 이지만 이 공격을 멈추고 싶다면 거금을 지불하라는 협박 메일도 받게된다.

 당연히 Code Spaces측에서는 이 협박에 응할 생각이 없었고, 대책을 세우기 위해 AWS의 설정을 변경하려 했다. 하지만, 이미 해커는 Code Spaces의 AWS계정 패스워드를 확보해 놓은 상태였으며 곧 패스워드를 바꿔 제어권을 완전히 가져가 버린다. 황급히 Code Spaces가 아마존에 연락하여 제어권을 되찾아 왔을 즈음에는 이미 해커가 모든 데이터와 기기설정, EBS를 이용한 백업, 스냅샷등 AWS상에서 관리되던 모든 자원을 지워버린 이후였다.

사고 이후 Code Spaces의 홈페이지
아마도 인터넷을 이용한 서비스기업에서 생각할 수 있는 최악의 경우에 해당할 것이다. 작은 스타트업이라 해도 해커는 봐 주는 법이 없고, 오히려 보안에 허술하다는 점을 이용해 집중적인 타겟이 되기 쉽다. 

 사내에 물리서버를 두고 운영했다면 이러한 사태를 막을수 있었을까? 물론 이러한 종류의 보안 사고는 클라우드사용이 근본적인 원인이라고 보긴 어려운 측면이 있다.  다만, 여기서 다음과 같은 클라우드 보안과 관련한 몇가지 사항을 짚고 넘어 갈 필요가 있다.

보안주권의 상실

 클라우드 사용에 있어서 가장 민감하면서 까다로운 부분은 보안정책이 사용하는 클라우드 서비스에 귀속되어 버린다는 점 이다. 클라우드 서비스를 사용하는 이상 네트워크 및 하드웨어에 관련한 사항들에 대해서는 일체의 권한이 서비스 제공자에게 종속되어 버린다. 물론 그만큼 편해지자고 하는거지만 파이어월같은 보안 장비도 클라우드서비스의 일부로 의존하게 되는만큼 무조건 믿고 맡겨 보자는 식의 태도는 대단히 위험하다.

 모든종류의 공격 시도에 대해서 파이어월은 외부와의 관문으로서 중요한 단서를 제공하는  장소이다. 하지만 필자가 아는 한 아마존은 보안상의 이유로 공식적으로든 비공식적으로든 파이어월에 대한 로그를 일체 제공하지 않고 있다. 아마존 입장에서는 당연한 이야기 일 수도 있겠지만, 네트워크를 공유하게 되는 클라우드 서비스의 성격상 그 파이어월은 당신의 서비스 만을 위한것이 아니기 때문이다.

 보안관련 이슈 전문 블로거인 Bruce Schneier씨는 2013년 열린 QCon New York의 기조연설에서 봉건적 보안세상에서 살아남기라는 타이틀로 이 문제에 대해 지적했는데, 클라우드 컴퓨팅을 사용할때엔 소프트웨어 파이어월등을 통해 최소한의 스스로의 몸을 지킬 수단은 마련 할 수 있어야 한다고 조언한다.

종속성의 함정

클라우드 컴퓨팅의 도입을 고려할때 또 한가지 고려해야 할 점은, 어떤 클라우드 서비스 업자든 결국에는 자신들의 서비스에 의존성이 생기도록 하는 여러 장치들을 마련해 두고 있다는 점 이다. 이른바 원숭이 꽃신 전략이라고 하는 것인데, 일단 의존성이 생기게 되면 만에 하나 해당 클라우드 업체에 문제가 생길경우 상당히 곤란한 상황에 처하게 된다.

예를 들면 갑작스러운 클라우드 업체의 폐업같은거 말이다.

Cloud Storage Provider Nirvanix Shutting Down

Nirvanix는 폐업을 선언하기 전까지 7년 넘게 클라우드 스토리지 사업을 진행해 오고 있었지만 이메일을 통해 다른곳으로 데이터를 이전하라고 하면서 준 기간은 고작 2주에 불과했다. 클라우드 서비스 사업은 앞으로도 빠르게 성장해 나가는 추세이지만 박리다매에 기반한 비즈니스모델이라는 점 에서 업계 탑클래스 이외의 곳을 선택하는것은 큰 위험이 따른다는 점에 주의를 기울여야 한다.

그러나 업계 탑클래스의 기업이라고 해서 100% 안전한것도 아니다.

Dropbox gets hacked ... again

위 기사에 따르면 2011년 자사직원의 실수로 발생한 보안사고로 인해 네시간동안 드롭박스의 인증체계가 무력화 되었었다 하는데 더 큰 문제는 사용자 입장에서 정말로 네시간만 그런일이 발생했는지, 또 이에 따라 발생된 피해는 어떤것이 있는지에 대해 조사할 방법이 전무하다는 점 이다.

여기에 아마존, 마이크로소프트, 구글등의 미국 국적 회사들은 기본적으로 애국자법이라 불리우는 테러대책법(Anti-terrorism legislation)으로부터 자유로울 수 없다는 점 또한 잊지말자. 물리적으로 서버가 해외에 있거나 해외법인이라 할 지라도 본사가 미국인 이상 모두 이 법의 적용을 받는다. (AWS동경 리전도 마찬가지이다) 테러와 관련이 있다고 미국 정부가 판단하는 사안에 대해서는 클라우드 서비스 내에 들어 있는 데이터에 대해 무제한적인 억세스 권한을 지니며 통지의 의무도 없기 때문에 들여다 봤는지 조차 사용자 입장에서는 알 방도가 없다.
참고로 애국자법은 2011년 오바마 대통령이 법안의 연장에 서명한 덕분에 2015년까지도 유효 하다.

구더기 무서워서 장 못담그랴

 이러한 여러 문제점에도 불구하고 클라우드 컴퓨팅은 분명히 매력적이다. 필자는 20년 넘게 IT업계에서 벌어지고 있는 개척시대의 풍경을 보아오고 있지만 최근 수년간 클라우드 컴퓨팅이 가져오는 변화는 그 20년의 세월동안 보아온것들 중에서도 단연코 놀라운것이다.

 클라우드 컴퓨팅은 개인이 가진 아이디어와 기술이 자본으로부터 자유롭게 날개를 펼칠 수 있는 기틀을 제공해 주고 있다.

하지만, 이러한 클라우드 컴퓨팅이라 할지라도 위험에 대해서 알고 사용하느냐 모르고 사용하느냐는 큰 차이를 가져온다. 세계 최고의 회사가 제공하는 서비스이니 당연히 좋겠지라는 막연한 생각만으로 서비스를 이용하다가는 언젠가 세계 최고의 변호사와 상대해야 할 지도 모르는 일이다.

마지막으로 당신의 안전한 클라우드 컴퓨팅을 위해 다음의 사항을을 고려해 볼 것을 제안한다.

• 오프라인 백업 전략 수립: 해커가 모든 패스워드를 알고 접근루트를 확보한 상태라 할지라도 절대 접근할 수 없는 오프라인의 백업 스토리지를 가져야 한다. 명심하라! 명백한 서비스 제공자의 실책에 의한 데이터 손실이라 할 지라도 클라우드 서비스 제공자는 고작 월 사용료의 10%정도의 보상금(AWS의 경우)을 지급할 뿐이다.
• 자체 보안 정책 수립 및 모니터링: 클라우드 서비스회사는 다양한 보안 옵션을 제공한다. 이를 살펴보고 자신의 서비스를 위한 솔루션을 찾아보자. 침입자에대한 감시와 경고 또한 마찬가지이다. AWS를 사용한다고 하면 멀티팩터인증MFA정도는 반드시 사용하도록 하자.
• 클라우드 서비스 회사의 서포트 담당자와 친하게 지내자: 아직 이 바닥은 좁다. 고객을 직접 상대하는 클라우드 서비스의 고객 담당자는 자사 및 클라우드 업계의 여러 정보에 정통한 고급 정보원이기도 하다. 어설프게 갑질하려 들지 말고 이들과 정기적으로 연락하며 신뢰관계를 쌓아놓도록 하자. 말 한마디에 천냥 빚도 갚는다는 말은 그냥 나온 이야기가 아니다. 필자의 경험상 어떠한 고가의 외부 보안 컨설팅 보다도 이들의 조언은 큰 가치를 지닌다.

보안의 세계에서 이정도면 충분하다는 없다. 당신의 시스템을 노리는 해커는 높은 동기부여를 지니고 창의적으로 일하며 밥도 안먹고 잠도 안자고 일 할 정도로 근면하다. 늘 변화하는 보안관련 트렌드를 파악하고 당신의 서비스에 적용하려는 노력이 없다면 언제든지 당신의 시스템도 뜻하지 않은 재앙에 직면할 수 있다는 점을 명심하길 바란다. 보안에 대한 첫번째 이자 가장 중요한 투자는 끊임없는 공부이다.