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정도는 반드시 사용하도록 하자.
• 클라우드 서비스 회사의 서포트 담당자와 친하게 지내자: 아직 이 바닥은 좁다. 고객을 직접 상대하는 클라우드 서비스의 고객 담당자는 자사 및 클라우드 업계의 여러 정보에 정통한 고급 정보원이기도 하다. 어설프게 갑질하려 들지 말고 이들과 정기적으로 연락하며 신뢰관계를 쌓아놓도록 하자. 말 한마디에 천냥 빚도 갚는다는 말은 그냥 나온 이야기가 아니다. 필자의 경험상 어떠한 고가의 외부 보안 컨설팅 보다도 이들의 조언은 큰 가치를 지닌다.

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