|
|
|
 |
판매가 |
25,000원 → 18,750원  25% |
|
|
마일리지 |
 0% 0원 |
|
|
발행일 |
2007-11-28
|
|
ISBN |
8992939108 | 9788992939102
|
|
기타정보 |
번역서 | 442쪽
|
|
|
예상출고일
|
1일 (근무일기준) |
|
배송비 |
2,000원 (20,000원이상 무료배송)
|
| |
|
|
|
|
|
 |
| 클라이언트/서버 컴퓨팅
|
|
|
| |
|
※ 네이버 체크아웃으로 구매시 비회원으로 구매가
됨으로 강컴 마일리지는 적립 되지 않습니다. |
|
|
|
 |
|
험난한 세상에서 생존할 시스템을 설계하고 배치하라!
야근과 특근으로 채워진 여러분의 개발 프로젝트가 내일모레면 끝난다. 충혈된 두 눈을 커피로 자극하며 마지막 혼신을 다해 코딩을 하는 동료가 있으니, 힘든 여정이었지만 프로젝트의 끝을 볼 것 같다.
잠깐! 프로젝트를 끝내기만 하면 어딘가로 떠나 편하게 며칠 쉴 수 있다고 생각하는가?
끝이라고 생각하지만 왠지 으스스한 게, 프로젝트 골목 어디선가 프레디가 튀어나올 것 같지 않은가?
그렇다. 프로젝트가 끝났다고 모든 게 끝난 것은 아니다. 프로젝트의 끝은 새로운 시작을 의미한다는 것을 우리 모두는 잘 알고 있다. 프로젝트 기간 동안 겨울잠을 자고 있던 전화기는 긴 잠에서 깨어나 아침부터 저녁까지 배고프다고 울어댄다. 얼굴도 모르고 목소리도 처음 듣는 분노에 찬 누군가가 전화기 건너 편에서 여러분을 잡아 먹으려고 한다.
여러분이 저지른(?) 죄라고는 설계서대로 구현해 놓았다는 미필적 고의(?)밖에 없다.
아기 예수의 탄생이 기독교 역사의 이정표 역할을 하듯이, 프로젝트 완료는 프로젝트 인생의 새로운 마일스톤인 셈이다. 정규분포의 평균에서 돌아가던 여러분의 시스템은 6Sigma의 품질을 요구하는 험난한 세상으로 방출된다. 미숙한 아기가 엄마의 손길을 필요로 하듯이, 반쯤 완성된 시스템은 오랫동안 여러분의 따스한 타이핑과 클릭으로 보살펴 주어야 한다
* 갓 태어난 아기를 보살피는 부모의 삶을 두 번 다시 겪고 싶지 않다면
* 어디선가 본 듯한데 잘 기억이 나질 않는 메멘토 같은 삶이 싫다면
* 프로젝트가 끝난 것이 진짜 끝났다는 것을 의미하는 사전을 갖고 싶다면
우리는 ‘Release it!’ 이후의 삶에 대비해야 한다.
오프라인 서점, 인터넷 서점 그리고 여러분의 책장에 있는 개발서적은 완료 이전의 삶을 다룬다. 물론 이런 서적이 있기에 험난한 프로젝트를 눈부신 완료로 탈바꿈할 수 있다. 그러나 50퍼센트가 부족하다. 항상 경험하게 되는 50퍼센트의 삶을 알려주지 않기 때문이다.
『Release it: 성공적인 출시를 위한 소프트웨어 설계와 배치』는 바로 나머지 50퍼센트의 삶을 편하게 만들기 위해서, 프로젝트 동안 무엇을 고민해야 하는지 알려준다.
[누가 이 책을 읽어야 하는가]
이 책은 아키텍트, 설계자, 엔터프라이즈 급(enterprise-class, 여기에는 웹사이트, 웹 서비스, EAI 프로젝트 등이 포함된다) 소프트웨어 시스템 개발자를 대상으로 한다. 간단하게 ‘엔터프라이즈 급’이라는 것은 소프트웨어가 항상 가용(available)해야 하고, 그렇지 않다면 회사가 손해를 보는 것을 뜻한다. ‘엔터프라이즈 급’ 소프트웨어는 판매를 통해서 직접적으로 수익을 창출하는 상거래 시스템이나 직원들이 업무를 수행하기 위해 사용하는 핵심적인 내부 시스템일 수 있다. 시스템이 작동을 멈췄기 때문에 직원 중 한 사람이라도 일찍 퇴근해야 했다면, 이 책은 바로 여러분의 것이다.
[이 책은 어떻게 구성되어 있나]
이 책은 사례연구로 시작하는 네 개의 파트로 나뉘어져 있다.
1부는 시스템을 생존시키는 방법을 보여준다. 즉, 시스템 가동시간을 유지하는 방법이다. 이중화(redundancy)를 이용한 신뢰성의 보장에도 불구하고, 분산 시스템은 기대하는 ‘99.999퍼센트’ 대신 고작 ‘88퍼센트’에 해당하는 가용성(availability)을 보여준다. 안정성(stability)은 다른 어떤 것보다 중요한 필수조건이다. 시스템이 날마다 멈추고 죽는다면, 어떤 사람도 시스템의 먼 미래에 대해서 관심을 두지 않는다. 이러한 환경에서는 단기적인 수정과 단기적인 사고가 지배한다. 안정성이 없이 생존할 수 있는 미래는 없기 때문에, 안정적으로 동작하는 기초 시스템을 어떻게 마련할지 살펴본다.
2부에서는 용량에 대해서 살펴본다. 시스템의 용량을 어떻게 측정하는지 살펴보며, 용량이란 실제로 무엇이고, 시간이 흐르면서 용량을 어떻게 최적화하는지 배운다. 좋은 디자인과 나쁜 디자인 그리고 이러한 디자인이 시스템의 용량에 주는 극적인 효과를 보여주기 위해 몇 가지 패턴과 안티패턴(antipattern)을 보여준다.
3부에서는 데이터 센터에서 사용하는 소프트웨어를 만들 때 아키텍트가 고려해야 하는 일반적인 디자인 이슈를 살펴본다.
4부에서는 전체 정보 생태계의 일부로서 시스템의 지속적인 삶을 살펴본다. 상자 안에 갇힌 슈뢰딩거의 고양이와 비슷한 실전 시스템이 너무나 많다. 즉, 시스템의 실제 상태를 관찰할 방법이 없다. 이렇게 해서는 건강한 생태계를 꾸미지 못한다. 정보가 없다면, 계획적인 개선을 하기란 불가능하다. 시스템의 건강 상태, 성능, 특징이 드러나면, 이 정보들을 기초로 작업할 수 있다. 사실 이러한 정보는 선택이 아닌 필수다. 때때로 말은 쉬워도 행동으로 옮기기는 어렵다. 따라서 변화를 막는 장애물을 살펴보고 이러한 장애물들을 줄이고 극복하는 방법도 함께 배울 것이다.
[사례연구에 대해서]
이 책의 주요한 주제를 설명하기 위해서 폭넓은 사례연구 몇 가지를 실었다. 이러한 사례연구는 저자가 관찰한 실제 사건과 실제 시스템의 고장(failure)에서 뽑아서 설명한다.
[책 속으로]
여러분이 프로젝트에 공을 들인 지 1년이 넘었다. 드디어, 모든 기능들이 실제로 완성된 것처럼 보이고, 대부분의 기능들을 위한 단위 테스트도 있다. 안도의 한숨을 쉬어도 좋다. 일은 끝났다.
정말 그럴까?
‘기능이 완성되었다는 것’이 ‘제품을 출시할 준비가 되었음’을 뜻할까? 여러분의 시스템은 정말로 배치될 준비가 됐는가? 여러분이 없더라도, 시스템은 운영요원에 의해 잘 돌아가고 실제 사용자들과 부딪히는데 문제가 없겠는가? 한밤중에 비상 전화나 호출기가 울린다면 수렁에 빠지는 기분이 들지 않을까? 결국 지금까지 구현된 모든 기능보다 앞으로 개발할 것이 훨씬 많다는 사실을 알게 된다.
너무나 자주, 프로젝트 팀은 실전에서 (정말로 원활한) 운영을 목표로 삼는 대신, QA 테스트 통과를 목표로 삼는다. 즉, 여러분이 하는 많은 일들은 십중팔구 테스트 통과에 초점을 맞춘다. 그러나 테스트만으로(애자일 테스트, 실용주의 테스트, 자동화된 테스트일지라도) 소프트웨어가 실제 세상에 나갈 준비가 되었다는 것을 증명하는 데는 충분하지 않다. 유별난 실제 사용자, 엄청난 트래픽, 들어보지도 못한 나라의 바이러스를 만드는 일당으로 가득한 실제 세상의 스트레스와 스트레인(strain)은, 우리가 테스트의 대상으로 삼았던 것들을 훌쩍 뛰어넘는다.
여러분의 소프트웨어가 실제 세상의 가혹한 현실에 맞설 준비가 되었는지 확인해야 한다. 이 책의 목적은 이러한 문제들이 어디에 있는지, 문제들을 극복하려면 무엇이 필요한지 보여주는 데 있다. 그러나 시작하기 전에, 널리 알려진 몇 가지 오해에 대해 얘기해 보자.
우선, 온갖 노력을 다해 계획했어도, 나쁜 일들은 여전히 생긴다는 사실을 받아들여야 한다. 물론 가능하다면 나쁜 일을 예방하는 것이 현명하다. 그러나 가능한 모든 나쁜 사건들을 예측하여 제거했다고 가정하는 것은 너무나 치명적이다. 대신에, 여러분은 가능한 조치를 취하고 예방할 수 있기를 바라야 하지만, 예상치 못한 심각한 트라우마가 시스템에 생기더라도 전체 시스템이 복구될 수 있다고 확신해야 한다.
둘째로, ‘릴리스 1.0(Release 1.0)’은 개발 프로젝트의 끝이 아니라 시스템의 삶이 시작되는 것임을 깨달아야 한다. 이런 상황은 부모가 다 자란 자녀를 처음으로 떠나 보내는 것과 비슷하다. 여러분은 성인 자녀가 돌아와 여러분과 함께 지내길 바라지 않을 것이다. 더구나 배우자, 손자 네 명, 개 두 마리 그리고 애완용 앵무새와 함께라면 말이다.
이처럼, 개발하는 동안 여러분이 내리는 설계 결정은 릴리스 1.0 이후에 펼쳐질 여러분 삶의 질에 큰 영향을 미칠 것이다. 실전 환경에 맞도록 시스템을 설계하는 데 실패한다면, 릴리스 이후 여러분의 삶은 ‘흥분’으로 채워질 것이다. 물론 좋은 의미의 흥분이 아니다. 이 책에서, 중요한 설계 트레이드오프(trade-off)를 살펴보고, 어떻게 영리하게 설계 트레이드오프를 결정하는지 알게 될 것이다.
그리고 마지막으로, 기술에 대한 우리들의 공동체적인 애착과 멋진 신기술, 근사한 시스템에도 불구하고, 여러분은 결국 이러한 기술들이 전혀 중요하지 않다는 사실과 마주쳐야 한다. 우리에게 일용할 양식을 주는 세계, 즉 비즈니스 세상에서 모든 것은 돈으로 귀착되기 때문이다. 시스템은 비용을 지출한다. 이 비용을 만회하기 위해 시스템은 직접적인 수익이나 비용을 절약하는 방법으로 돈을 벌어야 한다. 추가 작업은 비용을 지출하며 서비스 중단을 일으킨다. 자금과 운영 비용을 높이기 때문에 비효율적인 코드는 많은 돈을 지출케 한다. 여러분은 운영되고 있는 시스템을 이해하기 위해 이런 비용을 추적해야 한다. 그리고 여러분은 사업을 유지하기 위해 돈을 벌어야 한다. 아니면 적어도 잃지는 말아야 한다.
나는 이 책이 변화를 만들어서 여러분과 여러분의 조직이 거대한 손실과 일반적으로 엔터프라이즈 소프트웨어의 특성으로 표현되는 돈 낭비를 피하는 것을 도울 수 있기를 바란다
- 서문 중에서
[독자 추천의 글]
애자일 개발은 반복주기(iteration)마다 실전에 준비된 코드를 인도할 것을 강조한다. 이 말이 오늘날의 매우 중요한 시스템에서 실제로 무엇을 의미하는지, 마침내 이 책이 정확하게 제시하였다. 여러분의 손에 최고의 책이 있다.
- 톰 포펜딕(Tom Poppendieck), Poppendieck.LLC
이 책은 소름 끼칠 정도로 뛰어나다. 이 책은 (실제 대기업의) 최근의 릴리스에서 수십만 달러의 손실을 막았다.
- 자레드 리차드슨(Jared Richardson), Agile Artisans, Inc.
조심해라! 경험, 통찰력 그리고 패턴들을 집대성한 이 책은 여러분이 미처 깨닫지 못한 과거의 모든 잘못들을 들추어낼 가능성이 농후하다. 기뻐하라! 지금 당장 여러분의 명예를 회복할 비법을 마이클이 알려줄 것이기 때문이다. 이 책은 여러분의 실용주의 서가에 새로운 소장품이다.
- 아런 뱃처(Arun Batchu), Enterprise Architect, netrii LLC
|
 |
|
 |
서문
1장 소개
1.1 올바른 목표를 향해서
1.2 힘을 사용하라
1.3 삶의 질
1.4 도전의 범위
1.5 여기도 백만달러, 저기도 백만달러
1.6 실용주의 아키텍처
1부 안정성(Stability)
2장 항공사를 정지시킨 예외(Exception) 사건
2.1 정지 사태
2.2 결과
2.3 사후검토
2.4 확실한 증거
2.5 약간의 예방?
3장 안정성 소개
3.1 안정성이란?
3.2 고장 유형
3.3 크랙 전파
3.4 고장의 연쇄
3.5 패턴과 안티패턴
4장 안정성 안티패턴
4.1 통합지점
4.2 연쇄 반응
4.3 연속적인 고장
4.4 사용자들
4.5 블록된 스레드
4.6 자기부정 공격
4.7 확장 효과
4.8 불균형 용량
4.9 느린 응답
4.10 SLA 역전
4.11 끝이 없는 쿼리 결과
5장 안정성 패턴
5.1 제한시간을 사용하라
5.2 차단기
5.3 칸막이
5.4 정상 상태
5.5 빠른 고장
5.6 핸드셰이킹
5.7 테스트 하니스
5.8 분리하는 미들웨어
6장 안정성 요약
2부 용량(Capacity)
7장 고객에게 짓밟히다
7.1 카운트다운과 런칭
7.2 QA를 향해
7.3 부하 테스트
7.4 군중에 의한 살인
7.5 테스트와의 차이
7.6 사고 여파
8장 용량 소개하기
8.1 용량 정의하기
8.2 제한조건
8.3 상관관계
8.4 확장성
8.5 용량에 대한 미신
8.6 요약
9장 용량 안티패턴
9.1 리소스 풀 경쟁
9.2 지나친 JSP 프라그먼트
9.3 AJAX 대량살상
9.4 너무 오래 머무는 세션
9.5 HTML 안에 낭비된 공간
9.6 새로고침 버튼
9.7 손으로 만든 SQL
9.8 데이터베이스 부영양화
9.9 통합지점 지연
9.10 쿠키 괴물
9.11 요약
10장 용량 패턴
10.1 풀 연결
10.2 캐싱을 신중하게 사용하자
10.3 콘텐트를 미리 계산해두자
10.4 가비지 콜렉터를 튜닝하자
10.5 요약
3부 일반적인 디자인 이슈
11장 네트워킹
11.1 멀티홈드 서버
11.2 라우팅
11.3 가상IP 주소
12장 보안
12.1 최소 권한의 원칙
12.2 설정된 비밀번호
13장 가용성
13.1 가용성 요구사항 모으기
13.2 가용성 요구사항 문서화
13.3 로드 밸런싱
13.4 클러스터링
14장 관리
14.1 QA가 실전과 일치하나?
14.2 설정 파일
14.3 시작과 종료
14.4 관리자 인터페이스
15장 디자인 요약
4부 운영(Operation)
16장 경이적인 우주의 힘, 하찮은 삶의 터전
16.1 피크 시즌
16.2 아기의 첫 번째 크리스마스
16.3 맥박을 짚다
16.4 추수감사절
16.5 검은 금요일
16.6 바이탈 사인
16.7 진단 테스트
16.8 전문가에게서 호출
16.9 해결책 선택사항을 비교하다
16.10 해결책은 효과가 있었을까?
16.11 진정국면
17장 투명성
17.1 관점
17.2 투명성을 위한 설계
17.3 권능을 부여하는 기술
17.4 로깅
17.5 모니터링 시스템
17.6 법률적이며 사실상의 표준
17.7 운영 데이터베이스
17.8 지원 프로세스
17.9 요약
18장 적응
18.1 시간이 흐르면서 적응하기
18.2 적응 가능한 소프트웨어 설계
18.3 적응 가능한 엔터프라이즈 아키텍처
18.4 릴리스가 고통을 줘서는 안 된다
18.5 요약 |
|
|
 |
[저자 소개]
마이클 나이가드(Michael T. Nygard)
마이클 나이가드(Michael Nygard)는 15년이 넘는 경력의 전문 프로그래머이자 아키텍트다. 그는 미국 정부, 군대를 포함하여 은행, 재정, 농업 그리고 유통업에 시스템을 인도하였다. 마이클은 수많은 기사와 사설을 기고했고 컴덱스에서 연설을 했으며 초창기 자바서적을 공동으로 집필하기도 했다.
[역자 소개]
신승환
LG전자 생산연구원에서 제품개발 지원시스템을 설계, 개발하였다. 2007년 현재 오토에버시스템즈에서 책임연구원으로 근무하며, 차량용 임베디드 소프트웨어 프로세스 개선과 개발도구 표준화 작업을 한다. http://talk-with-hani.com에서 소프트웨어와 인생에 관한 글을 쓰고 있으며, 공역한 책으로 『실천가를 위한 실용주의 프로젝트 관리』(위키북스), 『레일스와 함께하는 애자일 웹 개발』, 『애자일 프랙티스』(인사이트)가 있다. 고려대학교와 고려대학교 대학원을 졸업했다. 이메일은 root@talk-with-hani.com
정태중
고려대학교 기계공학과와 동대학원을 졸업하였고, 현재 LG전자 생산연구원에 근무하면서 자동화 장비 프로그램과 비전 알고리즘 개발 업무를 수행하고 있다. 공역한 책으로 『실천가를 위한 실용주의 프로젝트 관리』(위키북스), 『애자일 프랙티스』(인사이트)가 있다
[역자 서문]
어릴 적 읽었던 동화에서는, 백마 탄 왕자님이 못된 마녀에게서 어여쁜 공주님을 구한 후, 성으로 돌아와 모두의 축복 속에서 결혼하여 행복하게 사는 것으로 끝난다. 순수의 화신이었던 소년시절을 지나 인생의 맛은 달콤함보다는 씁쓸함이라는 사실을 알게 되었을 무렵, 진짜 인생은 왕자와 공주의 결혼생활처럼 “행복하게 잘 살았습니다.”라는 한 문장으로 요약될 수 없다는 것을 온몸으로 깨달았다.
물론 동화 속 거짓말은 세상의 황량함보다는 아름다움을 가르치기 위한 선의의 것이었지만. 동화 속에서는, 언젠가 인생의 일부로 받아들여야 하는 엄연한 현실을 희망이라는 베일이 가려버렸던 것이다. 어차피 알게 될 세상이라면, 단맛과 쓴맛을 같이 보여주는 것이 더 인간적이지 않았을까?
동화 속 이야기는 현실에 존재하지 않는다는 것을 깨닫고, “동화 속 새하얀 거짓말 같은 것에 속지 않겠어!”라고 세상을 향해 외쳤다. 외침이 세상의 끝에 닿아 메아리로 돌아올 때쯤. 나는 희망과 좌절이 살아 숨쉬는 진짜 인생, 프로젝트의 세계에서 살게 되었다.
프로들의 세계는 냉엄했다. 빠듯한 공수(man month) 때문에 야근을 밥 먹듯이 했으며, 위기가 아닌 날이 없었다. 날마다의 삶은 폭탄이 떨어지는 전쟁터 한가운데서 목숨을 보존하는 처절한 순간, 순간이었다. 그럴 때마다 “프로젝트만 끝나면 우린 행복할 수 있어!”라고 독려하는 PM의 한마디에 젊은 날의 땀과 코피를 쏟으며 우리는 프로젝트 고지를 향해 달려갔다.
그리고 그 끝이 보이는 듯했다.
설계서 곳곳에 숨어있던 지뢰밭을 빠져 나와, 빗발치는 요구사항변경을 온몸으로 막으며, 벙커 깊은 곳에 숨어 있는 버그들을 섬멸하고, 우리는 프로젝트 고지 위에 찬란한 ‘완료 깃발’을 꽂았다. ‘완료 깃발’이 휘날리는 파란하늘 아래에서, 가슴 깊은 곳의 응어리는 뜨거운 눈물이 되어 눈시울을 적셨다.
“저건 뭐지?”
동료의 당황한 목소리에 오랜만의 평온함이 깨져버렸다. 동료가 가리킨 곳을 재빨리 바라봤다. 시커먼 물체들이 파란하늘을 가득 메운 채 빠르게 다가왔다. 우리들은 불안한 눈빛으로 서로를 바라봤다. 그 물체는 바로……
사용자였다.
소리보다 더 빨리 날아온 사용자들은 우리들 머리 위에 세션폭탄을 무차별적으로 투하했다. 이제 막 휘날리던 ‘완료 깃발’을 사수하기 위해, 우리는 온몸으로 사용자들의 공격을 막았지만, 아무 소용이 없었다. 무자비한 사용자들이 짓밟고 간 자리에는 쓰러진 동료들, 꺾여버린 깃발, 망가져버린 시스템만이 남았다.
사용자들의 세션 융단폭격 이후, 우리들은 프로젝트 고지를 두고 사용자와 피가 마르는 지루한 전투를 벌였다.
데이터베이스 보급소를 방어하기 위해서, 연결 풀(connection pool) 대공포를 설치했으며, ‘광속클릭 새로고침(reload button)’ 기관총으로 무장한 람보 사용자의 총알을 피하기 위해, 시스템을 빛보다 빠르게 달리도록 만들어야 했다. 하지만 우리가 어설프게 설치한 SQL쿼리 지뢰 때문에 빛보다 빨리 달리게 된 시스템이 다시 한 번 쓰러지고 말았다.
밤낮을 가리지 않는 동료들의 헌신적인 노력 덕분에 프로젝트 고지를 완전히 사수하게 되었다. 그러나 우리는 ‘완료 깃발’을 처음으로 고지에 꽂기 위해 흘렸던 피와 땀 이상을 흘려야만 했다. 승리의 쾌감을 맞보기도 전에, 난 더욱 강력한 사용자가 기다리는 고지로 투입되었다. 터빈엔진 소리가 진동하는 수송기 속에서, 요구사항변경이 빗발치던 전장에서 PM이 입버릇처럼 했던 말이 생각났다.
“프로젝트만 끝나면 우린 행복할 수 있어!”
PM의 말을 되씹을수록 어릴 적 읽었던 동화 속 마지막 구절, “둘은 행복하게 잘 살았습니다.”가 떠올랐다. 동화 속 반쪽 진실을 피해 살아왔던 진짜 인생 속에서도, 현실 속 반쪽 진실만을 떠드는 사람의 말에 내 인생을 걸었다는 허탈감이 밀려왔다.
그제서야 진실된 삶을 살아가는 데 필요한 것은, 반항을 위한 맹목적인 부정이나 현실을 잊기 위한 거짓된 믿음도 아닌, 세상의 진실을 바라볼 수 있는 냉철한 눈이라는 것을 깨달았다. 이런 깨달음을 얻고 몇 년이 흘렀다. 비록 풋내기 개발자 시절보다 많은 것을 알게 되었지만. 빛의 속도로 확장되는 IT시스템의 정글 속에서 생존하려면 현재의 지혜에 만족해서는 안 된다.
이런 현실 속에서, 릴리스 이후 시스템의 생존을 위해 하나부터 열까지 철저하게 알려주는 이런 책이 있다는 게 얼마나 다행스러운 일인지 모르겠다. 비록 이 책은 ‘완료 이후에 또 다른 현실’이 존재한다는 냉혹한 진실을 알려주지만, 완료가 ‘진짜 완료’가 될 수 있는 비법도 제시해 줄 것이다.
- 신승환 |
|
|
|
|
|
|
|
|
|
|
|
|
Home > 
POD(Printed On Demand)
I 조회수(367)
I 공감 (0)
I 
