이보시오 구글양반 내가 xx 라니...

직업적인 정체성의 문제로 고민하다가 알게된 충격적인 사실을 여기 공개한다.

맨 위부터 차례대로

프로그래머는 모두 사원으로 사원의 약 10%를 차지하고 있다
프로그래머는 두번 죽는다(으잉?)
프로그래머 파견
프로그래머는 노라고 말할 수 없다(!)
프로그래머 파견단가
junit테스트에 빠진 프로그래머는 테스트를 적는것이 좋아지게 된다

"프로그래머는 두번 죽는다"는 일본 트위터상에서 유명했던 농담임. 내용은 다음과 같다.

사춘기 딸을 둔 프로그래머가 듣는 상처받는말 

"아이고 우리 공주님. 아빠랑 같이 빌드 한번 해볼까?"
"싫어! 아빠가 썼던 변수는 같이 쓰기 싫어! 초기화 해도 싫어!"
빌어먹을... 저는 그저 웃을 수 밖에 없었습니다.

대한민국 개발자들에게 무슨일이 있었던 것일까...

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