인프라 관리자로 성장하기 위한 지침서 - 코드로 인프라 관리하기

코드로 인프라 관리하기 - 효율적인 인프라 관리를 위한 자동화 방법
키프 모리스 지음, 강재준 옮김 / 한빛미디어 / 2017년 3월

최근 몇년간 IT업계의 화두이자 관심사 중 하나로 '클라우드'와 '가상화'를 꼽는 사람은 나 뿐만은 아닐 것이다. 아마존이나 구글의 사업 영역을 예로 들자면, 아마존은 이미 자사의 웹서비스의 유휴 자원을 AWS라는 플랫폼으로 만들어 판매한지 오래이고, 구글도 자사의 플랫폼을 가상화 서버로 관리하여, 다양한 사내 요구(연구, 개발, 서비스 등)를 충족하는 한편 직접 클라우드 판매를 하는 데에도 나서고 있다. 

이러한 경향은 국내의 유력한 B2C 업계나 B2B 업계를 가리지 않고 나타나고 있어서, 업계의 인프라 엔지니어들은 대중화된 서비스를 이용하거나(AWS, Azure 등) 자사에 직접 구축(openstack, VMWare vCenter 등)하기도 한다.

또한, 5-6여년 전부터 입에 오르내리는 'DevOps' 라는 용어와 최근에 회자되는 'fullstack 개발자' 는 운영자와 개발자간 경계를 넘어 서로의 고유한 업무를 흐리게 하는 데까지 이르고 있다.

이번에 읽게된 '코드로 인프라 관리하기(Infrastructure as Code)'는 위에서 언급한 '클라우드'와 '가상화' 시대에 인프라 엔지니어로써 'DevOps'가 되는데 필요한 인프라 관리 '자동화'를 깊게 다루는 전문서적이다.

사실 이 책을 리뷰하는 나는 하드웨어에 탑재되는 펌웨어를 개발하는 '개발자'로 '인프라 엔지니어'의 세계에 초보라 책의 내용이 아주 깊게 이해되지는 않았다. 즉 'DevOps'를 지향하기 보다는 'fullstack' 개발자를 지향하는 측인데, 어쨋든 이 책이 개별 플랫폼이나 코드를 소개하기 보다는 인프라 자동화를 위한 '원칙', '패턴', '관례', '지침' 등에 중점을 두고 있기 때문에 나 같은 초보자가 시작하기에도 무난하다. 다만, 인프라를 자동화하는 전문적인 방법을 다루는 책의 후반부는 전반부에 비해 난이도가 급격히 올라가는 듯한 느낌이 든다.

책은 총 3부로 나뉘어져 1부에서는 가상화 확산 등 현재 인프라 관리의 문제점을 설명하고, '동적 인프라 플랫폼', '인프라 정의 도구', '서버 구성 도구'를 각각 나누어 설명하고 이를 사용하는 '활용예'를 설명하고 있다. 일종의 '개론' 또는 '총론'인 셈.

2부에서는 실제 '코드로써의 인프라'를 활용하는 패턴을 설명하고 있는데, '안티패턴'을 함께 소개해서 셜명해서 좋은 예와 나쁜 예를 비교하며 볼 수 있게 되어 유용하다. 

마지막 3부에서는 품질(10장)과 자동 test(11장), CI(12장) 등 개발의 여러 단계를 차용하여 코드로써의 인프라를 설명한다. 13-14장은 코드로써의 인프라를 대하는 엔지니어의 자세를 안내하고 15장에서는 조직 측면에서 코드로써의 인프라를 설명한다.

핵심 주제로 '자동화'를 기반에 두고 있는데, '코드로써의 인프라'가 인프라 관리/운영을 '코드'같이 작성하고 실행하며, 업데이트 하는 방식을 의미하니 각 부분에 '자동화'하지 않은 툴이나 외부 접근이 어려운 플랫폼은 피하라고 조언하기도 한다. 'GUI'보다 'CLI'를 선호하는 것도 같은 이유이다.

이 책은 인프라 관리자로 오랜동안 일한 필자가 쓰고, 역시 오랜동안 현업에서 근무한 역자가 번역했다. 용어의 선택에 약간의 어색함 - 예를 들면, 곳곳에 '팀은', '팀이' 등의 표현이 있는데, 그냥 '팀'이 아니라 역할이 드러나도록 개발팀, 인프라팀 등으로 표현하거나 '조직'으로 바꿔 썼으면 어떨까 하는 생각이 들었다. 

또한, 각주와 역주를 섞거나 참조URL을 본문에서 현지화(연결이 가능한 경우 en -> ko로 변경)하는 등 일관성이 떨어져 원문과 비교시 어렵지 않을까 했는데, 역자의 경력과 번역품질을 볼 때 굳이 원서를 사서 비교해 볼 필요까진 없지 않겠나 생각한다.

'클라우드'와 '가상화' 뿐 아니라 '인공지능' 등 기존의 방식으로는 효율이 떨어지거나 어려운 업무가 늘고 있다. 책 '코드로 인프라 관리하기'는 기존의 방식을 탈피하여 일을 하는 새로운 방식을 제시하는 좋은 책이라고 본다.

벤츠 타는 프로그래머

벤츠 타는 프로그래머 - 행복한 프로그래밍을 위한 어느 선배 개발자의 조언
정금호 지음 / 제이펍 / 2013년 8월

대체로 이런 식의 책에서는 이런 정도의 감상 밖에 쓸 말이 없을 것 같다.

"읽어보았다." 아니 "훓어보았다."는 편이 더 적절할 듯.

자신의 성공에 대한 자서전 격인 책이며, 좋은 정보나 큰 깨달음은 없었다.

20대 초반의 사회 생활을 막 시작하는 사람이었다면 롤 모델로 삼고싶었을 지도 모르지만. 

지금은 나도 꽤나 노쇄해져 버렸다.

==

10년 정도 한 가지에 몰두하면, 전문가 소릴 듣게 되는데 그냥 듣는 건 아니고 다음의 세 가지를 할 줄 알아야 한다고 한다.

define : 내가 하고있는 분야를 정확하게 정의할 줄 안다.

classification : 내가 하고있는 일의 종류를 정확하게 분류할 줄 안다.

여기까지는 대부분의 사람들이 도달하는 범위이고, 진짜 전문가가 되려면

naming : 내가 하고있는 일의 이름을 붙일 줄 알아야 한다.

즉, 새로운 개념/가치를 창조할 줄 알아야 한다는 의미이다.

==

그런 의미에서 저자는 define과 classification은 어느 정도 하는 것 같지만 naming은 아직 먼 것 같다.

이 책을 읽으면서 몰랐던 사실 하나를 알게 된 것이 있는데, 

델파이가 오브젝트 파스칼의 개발 툴이었다는 사실이다. 델파이는 자체로 언어인 줄 알았다. ㅡ.ㅡ

이게 유일한 깨달음이라는 사실이 안타깝다.

뽀모도로 테크닉, 나는 좀 더 익은 시간 요리가 필요하다

시간을 요리하는 뽀모도로 테크닉 - 지금 일에 집중하는 25분의 힘
스타판 뇌테부르 지음, 신승환 옮김 / 인사이트 / 2010년 12월

뽀모도로 테크닉, 토마토(뽀모도로) 모양 주방 시계를 25분(또는 원하는 시간)에 맞춰 놓고, 그 시간 동안은 한 가지 업무에만 집중하는 방법. 25분 이후 5분간은 아무것도 안 하는 휴식시간. 이 두 시간을 한 사이클로 반복하는 시간관리 기법이다.

이 기법의 특징은 여러 가지 다양한 시간 관리 기법 중에서도 실행에 가장 초점을 맞추었다는 점이다. 저자인 스타판 뇌테부르가 최초 아이디어 제공자는 아니며, 따라서 이 책은 뽀모도로 테크닉을 잘 사용하는 방법에 대한 응용서라고 할 수 있다.

내용은 크게 뽀모도로 기법의 과학적 타당성 등을 이야기하는 전반부와 실제 사용시 발생할 수 있는 여러가지 질문에 대한 저자의 팁을 실은 후반부로 나누어져 있다. 저자의 팁 중 가장 유용해 보이던 것은 특정 업무에 대한 estimation(예측)이 가능하다는 것.

팀장 업무를 맡고 나서 시간을 효율적으로 사용하는 것에 대한 압박이 심하던 차였다. 특히 집중 시간을 계량하고 실제 업무에 소요되는 시간을 측정함으로써 시간 예측이 가능하다는 서평에 이 책을 사 보고 나서 2-3일 따라해 보았다. 아래는 나의 감상.

1. 하루동안 집중해서 일할 수 있는 시간의 양이 얼마되지 않음을 알게 된다. 나의 경우, 아침부터 밤까지 꽤나 긴 시간 동안 책상에 앉아 있지만, 딴 생각, 잡무, 인터넷 서핑 등 업무와 관계없이 허비하는 시간이 꽤 많았다. 물론 두 가지 일(업무와 비업무)를 한꺼번에 처리하는 경우나 피치못할 사정 등으로 25분을 채 집중할 수 없는 경우 등(중요 업무 전화)은 제외했기 때문에 시간을 손해보는 경우가 있었지만 이를 감안해도 채 50%가 되지 않는 집중 업무 시간에 반성하게 되었다.

2. IT업무와 같이 한번 집중하면 오랜동안 집중력이 연장되어야 하는 작업에 25분은 너무 짧은 경향이 있다. 책에서 저자는 '25분간의 집중 후에 아무것도 하지 않는 5분이 새로운 영감이나 집중력을 꾸준히 발휘할 수 있는 원동력이 된다'고 하였는데, 이를 IT 업무 (특히 디버깅 업무와 같이 나 또는 남이 예전에 완성한 코드를 꼼꼼히 봐야 하는 경우)에는 25분이 매우 짧았다. 25분이 경과한 후에도 업무가 끝나지 않는 경우 저자는 '추가 시간을 5분 이상 두지 말 것'을 권고하고 있는데 이 시간을 다 더한 후에도 한가지 작업이 끝나지 않는 경우가 많았다. 이 때, 두 가지 해결 방법을 제안하고 있는데 첫번째는 '업무를 25분 단위로 끊을 수 있도록 재분배'하는 것이지만 쉽지 않을 것 같고, 다른 한가지는 '단위 집중 시간을 25분보다 크게 늘이는 방법'인데 '처음 시작부터 시간을 늘이는 방법은 좋지 않고 25분으로 우선 2주 정도 습관을 들인 이후에 시간을 늘여보라'고 조언하고 있다.

3. 이메일 처리, 미팅 등의 업무는 수시로 작업하여야 하는 경우도 많고 개인의 의지로 중단하기가 쉽지 않은데, 특히 이슈 트래킹에는 이메일 처리가 필수 요소이기 때문에 적용하는 데 문제가 있다. 다만, 오전 첫 25분과 오후 점심 이후 첫 25분간은 메일을 처리하는 일감으로 두어서 사용하였는데, 부족한 경우가 종종 발생했다.

첫 2일 간의 성과를 보니, 확실히 의식하고 있지 않을 때보다 업무 처리량이 는 것을 확인할 수 있었다. 다만, 25분의 집중 시간을 지키는 것을 의식하다 보니 자꾸 시계를 쳐다보게 되고 "평소 방해가 없을 때

집중 가능했던 시간보다는 집중력이 떨어짐"을 알 수 있었다. 개발 업무에 좀 더 맞는 효율적인 뽀모도로 기법이 필요하고 당장 적용하기에 쉽지않다는 결론이지만, 예전의 개발 패턴으로 돌아간다고 하더라도 집중의 영향을 확인할 수 있었기에 의의가 있다고 할 수 있을 것 같다.

여담으로 책의 품질을 평가하자면, 전반부 뽀모도로 기법의 과학적 근거 부분은 머리에 잘 들어오지 않는 지식의 나열이 계속되는데, 이 부분은 책의 몰입을 방해하는 큰 요소라고 생각한다. 그 원인이 저자의 문체 때문인지 편집자의 편집 실패인지 번역자의 번역 수준 문제인지 이유는 잘 모르겠다. 

그에 반해 하반절의 뽀모도로 기법 사례 설명에서는 자연어 수준으로 쉽게 읽혀졌다. 작가나 번역가 중 한 쪽이 2명이라고 해도 믿을 만큼 수준의 차이가 있다. 이 책의 번역가는 유명 블로그 'talk with hani' 의 신승환씨라고 하는데, 어쨋든 아리송하다.

고전, 리팩토링을 읽다

리팩토링 Refactoring - 코드 품질을 개선하는 객체지향 사고법
Martin Fowler 지음, 김지원 옮김 / 한빛미디어 / 2012년 11월

리팩토링은 마틴 파울러가 쓴 SE의 고전 중 고전으로 우리 나라에도 2002년 번역서가 나올 정도로 그 출판 연도가 오래되었다. 이 책은 비디오 대여점의 관리 소프트웨어를 자바 기반으로 작성하면서 발생하는 코드상의 여러 논리 오류나 모순을 기능을 변경하지 않으면서 내부 구조를 개선하는 전형적인 리팩토링 튜토리얼이다. 너무나 유명한 책이기 때문에 책 이름이 보통명사 같이 활용되고 있는 점 또한 특색이다.

이 책은 2002년 대청사에서 번역서가 나왔다가 절판된 이후 만 10년 만에 새로운 번역으로 한빛미디어에서 출판하였으며, 번역서 두 권을 비교해 보건데 두 번역서 모두 일부 번역이 위트 있지만 오역도 일부 있는 등 장단이 있는 만큼 최신본을 구매하는 것이 현실적으로 해답이란 생각이다.

사실 이 책을 리뷰하면서 꼭 같이 언급하고 싶은 책이 있어, 리뷰를 미뤄왔다. 바로 2012/12/25 - [서평] - '리펙토링'보다 쉽게 리펙토링하기 에서 리뷰한 'The Art of Readable Code'이다.

이 책 리뷰의 대부분을 위 책과 비교할 텐데 그렇다고 어느 책이 더 좋다거나 나쁘다는 의미는 아니고 내가 또는 우리가 보기에 가장 좋은 방법이 무엇이냐를 찾기 위한 과정에서 나온 리뷰라는 점을 미리 알려둔다.

우선, 본 책은 java기반의 언어로 쓰여진 책이다. 물론 코드의 기초는 다른 언어들도 대동소이하고, 리팩토링의 개념은 얼마든지 응용하여 사용할 수 있지만 아무래도 자바 특유의 prefix들을 java를 접해본 경험이 많지 않은 사람들로써는 어색한 것이 사실이기도 하다. 이러한 면에서는 '읽기 좋은 코드가 좋은 코드다'가 더 쉬운 접근성을 제공한다고 볼 수 있다.

한편, 본 책은 비디오 대여점 관리 프로그램을 예로 하고 있기 때문에 스토리에 기반한 책 전개가 장점이다. 즉, 코드 부분의 난해함을 제외하면 죽 훓어 읽기에 무리가 없을 정도로 스토리가 있다는 것인데, 이 부분은 위 책보다 장점이다. 다만, 이러한 책의 특성상 일독한 이후에도 수시로 책을 찾아볼 수 있는데, 이를 위해서 각 리팩토링 패턴에 대한 인덱스를 제공하고는 있지만, 리팩토링 패턴의 제목만으로는 활용에 필요한 정보가 제약되는 점이 단점으로 작용한다. 이에 비해 전 책에서는 변수, 함수, 주석, 조건문, 클래스 등 개발 요소에 맞추어 각 기법을 설명하고 있기 때문에 뒤에 찾아보기가 더 수월할 수 있다.

두 책 모두 일장일단이 있는 만큼 같이 보고 두 책의 장점만 취하면 좋겠다는 생각도 해 본다. 다만, 우리가 너무~ 시간에 쪼들리는 분야이다 보니 두 책을 순서대로 읽어야 겠다면 일단 'The Art of Readable Code'를 읽어 기초를 다지고 실무에 활용한 다음, 응용할 만큼의 실력이 받쳐줄 때 이 책 '리팩토링'을 읽어 생각을 정리하면 좋겠다는 생각이다. 이 두 책 모두 필독서로 권하고 싶다.