험난한 세상에서 생존할 시스템을 설계하고 배치하라!

야근과 특근으로 채워진 여러분의 개발 프로젝트가 내일모레면 끝난다. 충혈된 두 눈을 커피로 자극하며, 마지막 혼신을 다해 코딩을 하는 동료가 있으니. 힘든 여정이었지만 프로젝트의 끝을 볼 것 같다.

잠깐! 프로젝트를 끝내기만 하면 어딘가로 떠나 편하게 며칠 쉴 수 있다고 생각하는가?

끝이라고 생각하지만 왠지 으스스한 게, 프로젝트 골목 어디선가 프레디가 튀어나올 것 같지 않은가?

그렇다. 프로젝트가 끝났다고 모든 게 끝난 것은 아니죠. 프로젝트의 끝은 새로운 시작을 의미한다는 것을 우리 모두는 잘 알고 있다. 프로젝트 동안 겨울잠을 자고 있던 전화기는 긴 잠에서 깨어나 아침부터 저녁까지 배고프다고 울어댄다. 얼굴도 모르고 목소리도 처음 듣는 분노에 찬 누군가가 전화기 건너 편에서 여러분을 잡아 먹으려고 한다.

여러분이 저지른(?) 죄라고는 설계서대로 구현해 놓았다는 미필적 고의(?)밖에 없다.

아기 예수의 탄생이 기독교 역사의 이정표 역할을 하듯이, 프로젝트 완료는 프로젝트 인생의 새로운 랜드마크인 셈이다. 정규분포의 평균에서 돌아가던 여러분의 시스템은 6Sigma의 품질을 요구하는 험난한 세상으로 방출된다. 미숙한 아기가 엄마의 손길이 필요하듯이, 반쯤 완성된 시스템은 오랫동안 여러분의 따스한 타이핑과 클릭으로 보살펴 주어야 한다

  • 갓 태어난 아기를 보살피는 부모의 삶을 두 번 다시 겪고 싶지 않다면
  • 어디선가 본듯한데 잘 기억이 나질 않는 메멘토의 삶이 싫다면
  • 프로젝트가 끝난 것이 진짜 끝났다는 것을 의미하는 사전을 갖고 싶다면

우리는 ‘Release it!’ 이후의 삶에 대비해야 한다.

오프라인 서점, 인터넷 서점 그리고 여러분의 책장에 있는 개발서적은 완료 이전의 삶을 다룹니다. 물론 이런 서적이 있기에 험난한 프로젝트를 눈부신 완료로 탈바꿈할 수 있다. 그러나 50퍼센트가 부족하다. 항상 경험하게 되는 50퍼센트의 삶을 알려주지 않기 때문이다.

‘Release it!’은 바로 나머지 50퍼센트의 삶을 편하게 만들기 위해서, 프로젝트 동안 무엇을 고민해야 하는지 알려준다

누가 이 책을 읽어야 하는가?

이 책은 아키텍트, 설계자, 엔터프라이즈 급(enterprise-class, 여기에는 웹사이트, 웹 서비스, EAI 프로젝트 등이 포함된다) 소프트웨어 시스템 개발자를 대상으로 한다. 내 경우, 간단하게 ‘엔터프라이즈 급’이라는 것은 소프트웨어가 항상 사용 가능한 상태여야 하고, 그렇지 않다면 회사가 손해를 보는 것을 뜻한다. ‘엔터프라이즈 급’ 소프트웨어는 판매를 통해서 직접적으로 수익을 창출하는 상거래 시스템이나 직원들이 업무를 수행하기 위해 사용하는 핵심적인 내부 시스템일 수 있다. 시스템이 작동을 멈췄기 때문에 직원 중 한 사람이라도 일찍 퇴근해야 했다면, 이 책은 바로 여러분의 것이다.

이 책은 어떻게 구성되어 있나?

이 책은 사례연구로 시작하는 네 개의 파트로 나뉘어져 있다. 1부는 시스템을 생존시키는 방법을 보여준다. 즉, 시스템 가동시간을 유지하는 방법이다. 이중화(redundancy)를 이용한 신뢰성의 보장에도 불구하고, 분산 시스템은 기대하는 ‘99.999’ 대신 고작 ‘88’에 해당하는 가용성(availability)을 보여준다. 안정성(stability)은 다른 어떤 것보다 중요한 필수조건이다. 시스템이 날마다 멈추고 죽는다면, 어떤 사람도 시스템의 먼 미래에 대해서 관심을 두지 않는다. 이러한 환경에서는 단기적인 수정과 단기적인 사고가 지배한다. 안정성이 없이 생존할 수 있는 미래는 없기 때문에, 안정적으로 동작하는 기초 시스템을 어떻게 마련할지 살펴보는 것으로 시작하자.

안정성을 달성하고 나면, 여러분의 다음 관심사는 용량(capacity)이다. 2부에서 용량에 대해서 살펴볼 것이다. 즉, 시스템의 용량을 어떻게 측정하는지 살펴보며, 용량이란 실제로 무엇이고, 시간이 흐르면서 용량을 어떻게 최적화하는지 배울 것이다. 좋은 디자인과 나쁜 디자인 그리고 이러한 디자인이 시스템의 용량에 주는 극적인 효과(즉, 한밤 중에 받을 삐삐 호출이나 전화)를 보여주기 위해 몇 가지 패턴과 안티패턴(antipattern)을 보여줄 것이다. 3부에서, 데이터 센터에서 사용하는 소프트웨어를 만들 때 아키텍트가 고려해야 하는 일반적인 디자인 이슈를 살펴볼 것이다. 지난 십 년 동안 하드웨어와 인프라스트럭처 설계는 많이 변했다. 예를 들어, 상대적으로 드물었던 멀티호밍(multihoming)과 같은 방법이 이제 거의 보편화되었다. 네트워크는 계층화되었고 자체 처리 능력을 지닐 정도로 더욱 복잡해졌다. 아울러 스토리지 전용 네트워크(storage area network)는 흔한 것이 되었다. 소프트웨어가 데이터 센터에서 원활하게 운영되기 위해 소프트웨어 설계는 이러한 변화를 고려하고, 변화의 장점을 살려야 한다.

4부에서, 여러분은 전체 정보 생태계의 일부로서 시스템의 지속적인 삶을 살펴볼 것이다. 상자 안에 갇힌 슈뢰딩거의 고양이와 비슷한 실전 시스템이 너무나 많다. 즉, 시스템의 실제 상태를 관찰할 방법이 없다. 이렇게 해서는 건강한 생태계를 꾸미지 못한다. 정보가 없다면, 계획적인 개선을 하기란 불가능하다.이 책 뒷부분에 나오는 실전에 배치된 시스템(시스템은 여러분이 확실한 교훈을 얻을 수 있는 유일한 장소다)에서 배우기 위해 필요한 동기, 기술, 프로세스에 대해 얘기해 보자. 시스템의 건강 상태, 성능, 특징이 드러나면, 이 정보들을 기초로 작업할 수 있다. 사실 이러한 정보는 선택이 아닌 필수다. 즉, 여러분은 새로운 지식의 불빛 아래에서 행동해야 한다. 때때로 말은 쉬워도 행동으로 옮기기는 어렵다. 따라서 변화를 막는 장애물을 살펴보고 이러한 장애물들을 줄이고 극복하는 방법도 함께 배울 것이다.

사례연구에 대해서

이 책의 주요한 주제를 설명하기 위해서 폭넓은 사례연구 몇 가지를 실었다. 이러한 사례연구는 개인적으로 관찰한 실제 사건과 실제 시스템의 고장(failure)에서 뽑았다. 이러한 고장들 때문에, 관련된 이들은 많은 대가를 치르고 당황했다. 따라서 회사와 사람들의 신원을 보호하기 위해 일부 정보를 감추었다. 아울러 시스템, 클래스, 메서드 이름도 바꾸었다. 즉, ‘핵심이 아닌’ 세부사항만 변경했다. 그러나 각 사례에서, 나는 사례와 동일한 산업, 일련의 사건들, 고장 유형(failure mode), 에러 전파(propagation)와 결과는 유지했다. 이런 고장 때문에 발생한 비용은 과장되지 않았다. 실제 회사들에서 발생한 일들이며 지출된 비용도 진짜다. 사례연구의 진지함을 강조하기 위해 이런 숫자들을 기록했다. 시스템이 고장 나는 순간, 진짜 돈이 관련된다.

추천의 글

톰 포펜딕(Tom Poppendieck), Poppendieck.LLC

애자일 개발은 반복주기(iteration)마다 실전에 준비된 코드를 인도할 것을 강조한다. 이 말이 오늘날의 매우 중요한 시스템에서 실제로 무엇을 의미하는지, 마침내 이 책이 정확하게 제시하였다. 여러분의 손에 최고의 책이 있다.

제러드 리차드슨(Jared Richardson), Agile Artisans, Inc.

이 책은 소름 끼칠 정도로 뛰어나다. 이 책은 (실제 대기업의) 최근의 릴리스에서 수십만 달러(수 백만 달러가 아니라면)의 손실을 막았다.

아런 뱃처(Arun Batchu), Enterprise Architect, netrii LLC

조심해라! 경험, 통찰력 그리고 패턴들을 집대성한 이 책은 여러분이 미처 깨닫지 못한 과거의 모든 잘못들을 들추어낼 가능성이 농후하다. 기뻐하라! 지금 당장 여러분의 명예를 회복할 비법을 마이클이 알려줄 것이기 때문이다. 이 책은 여러분의 실용주의 서가에 새로운 소장품이다.

마이클 나이가드(Michael T. Nygard)

마이클 나이가드는 15년이 넘는 경력의 전문 프로그램이자 아키텍트다. 그는 미국 정부, 군대를 포함하여 은행, 재정, 농업 그리고 유통업에 시스템을 인도하였다. 마이클은 수 많은 기사와 사설을 기고했고 컴덱스에서 연설을 했으며 초창기 자바서적을 공동으로 집필하기도 했다.

저자 서문

여러분이 프로젝트에 공을 들인 지 1년이 넘었다. 드디어, 모든 기능들이 실제로 완성된 것처럼 보이고, 대부분의 기능들을 위한 단위 테스트도 있다. 안도의 한숨을 쉬어도 좋다. 일은 끝났다.

정말 그럴까?

‘기능이 완성되었다는 것’이 ‘제품을 출시할 준비가 되었음’을 뜻할까? 여러분의 시스템은 정말로 배치될 준비가 됐는가? 여러분이 없더라도, 시스템은 운영요원에 의해 잘 돌아가고 실제 사용자들과 부딪히는데 문제가 없겠는가? 한밤중에 비상 전화나 호출기가 울린다면 수렁에 빠지는 기분이 들지 않을까? 결국 지금까지 구현된 모든 기능보다 앞으로 개발할 것이 훨씬 많다는 사실을 알게 된다.

너무나 자주, 프로젝트 팀은 실전에서 (정말로 원활한) 운영을 목표로 삼는 대신, QA 테스트 통과를 목표로 삼는다. 즉, 여러분이 하는 많은 일들은 십중팔구 테스트 통과에 초점을 맞춘다. 그러나 테스트만으로(애자일 테스트, 실용주의 테스트, 자동화된 테스트일지라도) 소프트웨어가 실제 세상에 나갈 준비가 되었다는 것을 증명하는 데는 충분하지 않다. 유별난 실제 사용자, 엄청난 트래픽, 들어보지도 못한 나라의 바이러스를 만드는 일당으로 가득한 실제 세상의 스트레스와 스트레인(strain)은, 우리가 테스트의 대상으로 삼았던 것들을 훌쩍 뛰어넘는다.

여러분의 소프트웨어가 실제 세상의 가혹한 현실에 맞설 준비가 되었는지 확인해야 한다. 이 책의 목적은 이러한 문제들이 어디에 있는지, 문제들을 극복하려면 무엇이 필요한지 보여주는 데 있다. 그러나 시작하기 전에, 널리 알려진 몇 가지 오해에 대해 얘기해 보자.

우선, 온갖 노력을 다해 계획했어도, 나쁜 일들은 여전히 생긴다는 사실을 받아들여야 한다. 물론 가능하다면 나쁜 일을 예방하는 것이 현명하다. 그러나 가능한 모든 나쁜 사건들을 예측하여 제거했다고 가정하는 것은 너무나 치명적이다. 대신에, 여러분은 가능한 조치를 취하고 예방할 수 있기를 바라야 하지만, 예상치 못한 심각한 트라우마가 시스템에 생기더라도 전체 시스템이 복구될 수 있다고 확신해야 한다.

둘째로, ‘릴리스 1.0(Release 1.0)’은 개발 프로젝트의 끝이 아니라 시스템의 삶이 시작되는 것임을 깨달아야 한다. 이런 상황은 부모가 다 자란 자녀를 처음으로 떠나 보내는 것과 비슷하다. 여러분은 성인 자녀가 돌아와 여러분과 함께 지내길 바라지 않을 것이다. 더구나 배우자, 손자 네 명, 개 두 마리 그리고 애완용 앵무새와 함께라면 말이다.

이처럼, 개발하는 동안 여러분이 내리는 설계 결정은 릴리스 1.0 이후에 펼쳐질 여러분 삶의 질에 큰 영향을 미칠 것이다. 실전 환경에 맞도록 시스템을 설계하는 데 실패한다면, 릴리스 이후 여러분의 삶은 ‘흥분’으로 채워질 것이다. 물론 좋은 의미의 흥분이 아니다. 이 책에서, 중요한 설계 트레이드오프(trade-off)를 살펴보고, 어떻게 영리하게 설계 트레이드오프를 결정하는지 알게 될 것이다.

그리고 마지막으로, 기술에 대한 우리들의 공동체적인 애착과 멋진 신기술, 근사한 시스템에도 불구하고, 여러분은 결국 이러한 기술들이 전혀 중요하지 않다는 사실과 마주쳐야 한다. 우리에게 일용할 양식을 주는 세계, 즉 비즈니스 세상에서 모든 것은 돈으로 귀착되기 때문이다. 시스템은 비용을 지출한다. 이 비용을 만회하기 위해 시스템은 직접적인 수익이나 비용을 절약하는 방법으로 돈을 벌어야 한다. 추가 작업은 비용을 지출하며 서비스 중단을 일으킨다. 자금과 운영 비용을 높이기 때문에 비효율적인 코드는 많은 돈을 지출케 한다. 여러분은 운영되고 있는 시스템을 이해하기 위해 이런 비용을 추적해야 한다. 그리고 여러분은 사업을 유지하기 위해 돈을 벌어야 한다. 아니면 적어도 잃지는 말아야 한다.

나는 이 책이 변화를 만들어서 여러분과 여러분의 조직이 거대한 손실과 일반적으로 엔터프라이즈 소프트웨어의 특성으로 표현되는 돈 낭비를 피하는 것을 도울 수 있기를 바란다.

신승환

LG전자 생산연구원에서 제품개발 지원시스템을 설계, 개발하였다. 2007년 현재 오토에버시스템즈에서 책임연구원으로 근무하며, 차량용 임베디드 소프트웨어 프로세스 개선과 개발도구 표준화 작업을 한다. http://talk-with-hani.com에서 소프트웨어와 인생에 관한 글을 쓰고 있으며, 공역한 책으로 『실천가를 위한 실용주의 프로젝트 관리』(위키북스), 『레일스와 함께하는 애자일 웹 개발』, 『애자일 프랙티스』(인사이트)가 있다. 고려대학교와 고려대학교 대학원을 졸업했다. 이메일은 root@talk-with-hani.com

정태중

고려대학교 기계공학과와 동대학원을 졸업하였고, 현재 LG전자 생산연구원에 근무하면서 자동화 장비 프로그램과 비전 알고리즘 개발 업무를 수행하고 있다. 공역한 책으로 『실천가를 위한 실용주의 프로젝트 관리』(위키북스), 『애자일 프랙티스』(인사이트)가 있다

역자서문(신승환)

어릴 적 읽었던 동화에서는, 백마 탄 왕자님이 못된 마녀에게서 어여쁜 공주님을 구한 후, 성으로 돌아와 모두의 축복 속에서 결혼하여 행복하게 사는 것으로 끝난다. 순수의 화신이었던 소년시절을 지나 인생의 맛은 달콤함보다는 씁쓸함이라는 사실을 알게 되었을 무렵, 진짜 인생은 왕자와 공주의 결혼생활처럼 “행복하게 잘 살았습니다.”라는 한 문장으로 요약될 수 없다는 것을 온몸으로 깨달았다.

물론 동화속 거짓말은 세상의 황량함보다는 아름다움을 가르치기 위한 선의의 것이었지만. 동화 속에서는, 언젠가 인생의 일부로 받아들여야 하는 엄연한 현실을 희망이라는 베일이 가려버렸던 것이다. 어차피 알게 될 세상이라면, 단맛과 쓴맛을 같이 보여주는 것이 더 인간적이지 않았을까?

동화속 이야기는 현실에 존재하지 않는다는 것을 깨닫고, “동화속 새하얀 거짓말 같은 것에 속지 않겠어!”라고 세상을 향해 외쳤다. 외침이 세상의 끝에 닿아 메아리로 돌아올 때쯤. 나는 희망과 좌절이 살아 숨쉬는 진짜 인생, 프로젝트의 세계에서 살게 되었다.

프로들의 세계는 냉엄했다. 빠듯한 공수(man month) 때문에 야근을 밥 먹듯이 했으며, 위기가 아닌 날이 없었다. 날마다의 삶은 폭탄이 떨어지는 전쟁터 한 가운데서 목숨을 보존하는 처절한 순간, 순간이었다. 그럴 때마다 “프로젝트만 끝나면 우린 행복할 수 있어!”라고 독려하는 PM의 한마디에 젊은 날의 땀과 코피를 쏟으며 우리는 프로젝트 고지를 향해 달려갔다.

그리고 그 끝이 보이는 듯했다.

설계서 곳곳에 숨어있던 지뢰밭을 빠져 나와, 빗발치는 요구사항변경을 온몸으로 막으며, 벙커 깊은 곳에 숨어있는 버그들을 섬멸하고, 우리는 프로젝트 고지 위에 찬란한 ‘완료 깃발’을 꽂았다. ‘완료 깃발’이 휘날리는 파란하늘 아래에서, 가슴 깊은 곳의 응어리는 뜨거운 눈물이 되어 눈시울을 적셨다.

“저건 뭐지?”

동료의 당황한 목소리에 오랜만의 평온함이 깨져버렸다. 동료가 가리킨 곳을 재빨리 바라봤다. 시커먼 물체들이 파란하늘을 가득 메운 채 빠르게 다가왔다. 우리들은 불안한 눈빛으로 서로를 바라봤다. 그 물체는 바로……

사용자였다.

소리보다 더 빨리 날아온 사용자들은 우리들 머리 위에 세션폭탄을 무차별적으로 투하했다. 이제 막 휘날리던 ‘완료 깃발’을 사수하기 위해, 우리는 온몸으로 사용자들의 공격을 막았지만, 아무 소용이 없었다. 무자비한 사용자들이 짓밟고 간 자리에는 쓰러진 동료들, 꺾여버린 깃발, 망가져버린 시스템만이 남았다.

사용자들의 세션 융단폭격 이후, 우리들은 프로젝트 고지를 두고 사용자와 피가 마르는 지루한 전투를 벌였다.

데이터베이스 보급소를 방어하기 위해서, 연결 풀(connection pool) 대공포를 설치했으며, ‘광속클릭 새로고침(reload button)’ 기관총으로 무장한 람보 사용자의 총알을 피하기 위해, 시스템을 빛보다 빠르게 달리도록 만들어야 했다. 하지만 우리가 어설프게 설치한 SQL쿼리 지뢰 때문에 빛보다 빨리 달리게 된 시스템이 다시 한번 쓰러지고 말았다.

밤낮을 가리지 않는 동료들의 헌신적인 노력 덕분에 프로젝트 고지를 완전히 사수하게 되었다. 그러나 우리는 ‘완료 깃발’을 처음으로 고지에 꽂기 위해 흘렸던 피와 땀 이상을 흘려야만 했다.

승리의 쾌감을 맞보기도 전에, 난 더욱 강력한 사용자가 기다리는 고지로 투입되었다. 터빈엔진 소리가 진동하는 수송기 속에서, 요구사항변경이 빗발치던 전장에서 PM이 입버릇처럼 했던 말이 생각났다.

“프로젝트만 끝나면 우린 행복할 수 있어!”

PM의 말을 되씹을수록 어릴 적 읽었던 동화속 마지막 구절, “둘은 행복하게 잘 살았습니다.”가 떠올랐다. 동화속 반쪽 진실을 피해 살아왔던 진짜 인생 속에서도, 현실속 반쪽 진실만을 떠드는 사람의 말에 내 인생을 걸었다는 허탈감이 밀려왔다.

그제서야 진실된 삶을 살아가는 데 필요한 것은, 반항을 위한 맹목적인 부정이나 현실을 잊기 위한 거짓된 믿음도 아닌, 세상의 진실을 바라볼 수 있는 냉철한 눈이라는 것을 깨달았다.

이런 깨달음을 얻고 몇 년이 흘렀다. 비록 풋내기 개발자 시절보다 많은 것을 알게 되었지만. 빛의 속도로 확장되는 IT시스템의 정글 속에서 생존하려면 현재의 지혜에 만족해서는 안 된다.

이런 현실 속에서, 릴리스 이후 시스템의 생존을 위해 하나부터 열까지 철저하게 알려주는 이런 책이 있다는 게 얼마나 다행스러운 일인지 모르겠다. 비록 이 책은 ‘완료 이후에 또 다른 현실’이 존재한다는 냉혹한 진실을 알려주지만, 완료가 ‘진짜 완료’가 될 수 있는 비법도 제시해 줄 것이다.

  • 서문
  • 누가 이 책을 읽어야 하는가?
  • 이 책은 어떻게 구성되어 있나
  • 사례연구에 대해서
  • 감사의 글
  •  
  • 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 요약
  • 서문 xix 5행

    antipattern -> (antipattern)

  • 39쪽 20행

    상대편 반대편에서 -> 상대편에서

  • 51쪽 <새벽 5시 문제>제목에서부터 6번째 줄

    불행하게도, 이 현상은 그 날의 트랙픽~ ---> 트래픽

    ---> '트랙픽'으로 돼 있는 단어를 '트래픽'으로 정정합니다. -임세영-

  • 51쪽 18행

    thick client -> (thick client)

  • 51쪽 주석 12

    삭제

  • 67쪽 11행

    칸막이들이 이것을 -> 칸막이를

  • 68쪽 4행

    로드 밸런서와 -> 로드 밸런서에

  • 70쪽 17행

    끊으려고 하면서 -> 끊을 때

  • 72쪽 7행

    '더 끔찍한 것은' 삭제

  • 72쪽 9행

    행진한다. -> 행진한다는 것이 더 끔찍하다.

  • 74쪽 22행

    우회 계층(layer of indirection)를 -> 우회 계층(layer of indirection)을

  • 80쪽 3행

    모든 다른 데이터베이스 트랜잭션은 블록된다. -> 다른 데이터베이스 트랜잭션은 모두 블록된다.

  • 80쪽 8행

    악의는 없고 -> 악의는 없으며

  • 80쪽 11행

    알려진 것으로, -> 알려진

  • 81쪽 12행

    서버에서 클라이언트로 -> 서버와 클라이언트 사이에서

  • 83쪽 6행

    '제일 좋은 경우는' 삭제

  • 83쪽 7행

    생성하는 것이다. -> 생성하는 것이 제일 좋다.

  • 83쪽 14행

    '자신이' 삭제

  • 88쪽 7행

    실제로 사용자는 자주 엄청나게 큰 폭도들이 -> 사용자는 자주 큰 폭도들이

  • 88쪽 8행

    사이트로 -> 사이트에

  • 88쪽 9행

    큰 폭도들은 -> 폭도들은

  • 89쪽 16행

    만드는데 -> 만들며

  • 99쪽 5행

    의도로서의 -> 의도로서

  • 100쪽 8행

    고장대치 모드(fallback mode)로 -> 고장대치 모드(fallback mode)를

  • 101쪽 6행

    '어떤' 삭제

  • 102쪽 4,5행

    '^' 윗첨자로 표시

  • 104쪽 16행

    만들라."라는 -> 만들라."는

  • 111쪽 16행

    '사이트는' 삭제

  • 112쪽 14행

    광고 효과에 의한 트래픽 패턴에서의 -> 광고 효과로 트래픽 패턴에서 일어나는

  • 116쪽 마지막행

    프라미츠가 할 수 -> 프라미츠가 제공할 수

  • 127쪽 9행

    고수준 API에서 -> 고수준 API는

  • 129쪽 끝에서 두 번째 행

    이들 들은 -> 이들은

  • 131쪽 14행

    3/4인치 -> 1.9센티미터

  • 133쪽 2행

    '사용자에게' 삭제

  • 133쪽 3행

    던지면 유용하다. -> 던지면 사용자에게 유용하다.

  • 137쪽 7행

    작은 용량이도 된다. -> 작은 용량이라도 괜찮다.

  • 153쪽 4행

    부가적인 일도 -> 부가적인 일을

  • 154쪽 8행

    애플리케이션 수준의 -> 애플리케이션 수준에서

  • 159쪽 10행

    실제 애플리케이션을 호출하면 그 애플리케이션이 고의도 만든 에러만을 테스트할 수 있다.

    -> 실제 애플리케이션을 호출하는 것은 그 애플리케이션이 고의로 만들 수 있는 에러만을 테스트하게 한다.

  • 172쪽 마지막행

    html. -> html

  • 176쪽 2행

    매기는데 -> 매기는 데

  • 189쪽 9행

    다루는데 -> 다루는 데

  • 191쪽 4행

    있다는데 -> 있다는 데

  • 194쪽 끝에서 여섯 번째

    미녀 -> 마녀

  • 243쪽 13행

    않는데 -> 않는 데

  • 243쪽 위에서부터 5번째~6번째 줄에

    생성하는 것보다 더 비살 ---> 비쌀 뿐이다

    ---> '비살'로 돼 있는 단어를 '비쌀'로 정정합니다. -임세영-

  • 299쪽 5행

    된다... -> 된다......

  • 324쪽 1행

    '하나의' 삭제

  • 326쪽 7행

    회수 -> 횟수

  • 326쪽 끝에서 다섯 번째 행 뒤에 나오는

    회수 -> 횟수

  • 335쪽 2행

    실전에서의 -> 실전에서

  • 335쪽 6행

    설정은 어떤 것이든 자동으로 지우는 -> 설정을 자동으로 삭제하는

  • 335쪽 끝에서 여섯 번째 행

    비지니스 논리 -> 비지니스 로직

  • 339쪽 끝에서 두번 째 행

    발굴해야 -> 구해야

  • 340쪽 8행

    잘못된 긍정 -> 거짓 양성

    잘못된 부정 -> 거짓 음성

  • 347쪽 끝에서 세번 째 행

    '그' 삭제

  • 359쪽

    회수 -> 횟수

  • 364쪽 10행

    블록block -> 블록(block)

  • 367쪽 1행

    거짓된 긍정의 위험 -> 거짓 양성의 위험

  • 376쪽 9행

    thffntus -> 솔루션

  • 378쪽 6행

    시스템의 능력에 -> 시스템의 능력과

  • 387쪽 끝에서 9행

    게아니라 -> 게 아니라

  • 387쪽 끝에서 4행

    아주 나쁜 것은, 복잡한 머신은~것이다

    --> 하향식 아키텍처는 폭넓게 분리된 그룹에 걸쳐 동시에 변경해야 한다는 점이 가장 나쁘다.

  • 394쪽 끝에서 5행

    '더 나쁜 것은' 삭제

  • 394쪽 끝에서 4행

    된다는 것이다. -> 것은 더 나쁘다.

  • 395쪽 3행

    '그냥' 삭제

  • 398쪽 끝에서 8행

    이들~것들이다. -> 이 모든 것을 뜻한다.

도서 소개자료

관련 글


엮인 글

엮인 글 주소: http://wikibook.co.kr/release-it/trackback/