AI는 쉽게 따라 하기 어려운, 인간 개발자와 엔지니어가 자신의 능력치를 최대로 발휘할 수 있는 신속하고 정확한 문제 해결력과 사고법을 알려주는 책! “문제의 본질”을 면밀히 관찰해서 시스템과 솔루션의 “성능”을 개선하고 최적화함으로써, 눈앞의 문제를 빠르고 정확히 해결하기 위한 “엔지니어적 사고의 기술” -- 시스템이 느려지면 심각한 문제가 발생한다. 시간과 비용을 낭비하게 되기 때문이다. 심지어 프로젝트가 중단될 수도 있고 경력에 위기가 닥칠 수도 있다. 하지만 무슨 일이 일어나고 있는지를 잘 이해한다면, 성능에 대해 꾸준히 좋은 결정을 내리는 것은 놀라울 정도로 쉽다. 이 책에서는 시스템이 왜 그렇게 동작하고 있는지의 이유를 명확하고 사려 깊게 설명해준다. 30여 년이 넘는 현장 경력을 보유한 저자 캐리 밀샙은 흥미로운 스토리텔링 기법을 활용한 111가지 일화 속에서 컴퓨터 소프트웨어든 일상 작업이든 (말 그대로) 모든 시스템의 성능을 개선하는 최적화 스킬을 알려준다. 또한, 엔지니어나 개발자가 어떤 사고와 마인드셋을 갖춰야 할지, 어떻게 하면 더욱 일관되고 자신있는 최적화를 수행할 수 있을지를 재미있게 들려준다. 컴퓨터 프로그램과 프로세스가 여러분의 시간을 어떻게 사용하고 있는지, 그리고 그것을 개선하려면 무엇을 해야 하는지 알고 싶어하는 모든 이를 위한 책이다.

저자 : 캐리 밀샙 (Cary Millsap) 1990년대 십여 년간 오라클 컨설턴트로 일하며 일생일대의 많은 기술적, 정치적 교훈을 익혔다. 1999년 무렵에는 백여 곳에 달하는 다양한 고객사들과 함께 일하며 인상적인 실적을 쌓았고, 오라클이 전 세계 수백 곳의 고객사를 지원하기 위해 운영한 85명의 엘리트 성능 전문가 팀을 구축하고 교육했다. 2004년에 집필한 『오라클 성능 최적화(Optimizing Oracle Performance)』(오라일리) 책으로 연구자 제프 홀트(Jeff Holt)와 함께 〈오라클 매거진〉이 선정한 ‘올해의 저자’로 선정되기도 했다. 2008년에는 메서드R사(Method R Corporation)를 설립해서 전 세계 굴지 고객사들을 대상으로 서비스를 제공하며, 수천 개의 오라클 추적 파일을 관리, 마이닝, 조작할 수 있는 세계 최초의 소프트웨어 시스템을 만들기도 했다. 경력 전반에 걸쳐 글쓰기, 교육, 그리고 각종 공개 행사에서의 강연 등을 통해 수천 명의 정보기술 전문가들을 교육해 왔다. 역자 : 장현희 지난 10여 년간 호주와 캐나다에서 시니어 엔지니어 및 스태프 엔지니어로 경험을 쌓았으며 현재는 프린시펄 소프트웨어 엔지니어(principal software engineer)로서 소프트웨어 개발은 물론 성공적인 엔지니어링 팀과 문화의 구축에 힘을 쏟고 있다. 지금까지 30권이 넘는 개발 관련서를 집필/번역하면서 책이라는 매개체로 멀리서나마 국내 개발자들과 꾸준히 소통하고 있으며 대표적인 번역서로는 『필독! 개발자 온보딩 가이드』(책만, 2023), 『딱 한 줄로! 파이썬 제대로 코딩하기』(책만, 2024),『스태프 엔지니어』(길벗, 2022), 『SRE를 위한 시스템 설계와 구축』(한빛미디어, 2022), 『엔터프라이즈 데이터 플랫폼 구축』(책만, 2020), 『사이트 신뢰성 엔지니어링』(제이펍, 2018), 『클라우드 네이티브 자바』(책만, 2018) 등이 있다.

1장 관찰하기 #001 팀장 밥 #002 필리스의 테스트 #003 진짜 목표 #004 낸시의 좁은 칸막이 책상 #005 올바른 지점을 관찰하기 #006 관찰할 수 없는 상황이라면 2장 방법론 #007 49가지 고충 #008 배송 송장 출력 문제 #009 더 많은 고충들 #010 우선순위 #011 그냥 시스템 전체가 느리다고요 #012 부수적 혜택 #013 은탄환에 대한 기대 #014 증상 목록 #015 R 방법론 3장 프로파일링 #016 급여명세서 #017 시퀀스 다이어그램 #018 간트 차트 #019 애플리케이션 동작의 추적 #020 프로파일 #021 프로파일의 생성 4장 성능 측정하기 #022 성능도 기능이다 #023 재현 가능한 테스트 케이스 #024 간헐적으로 발생하는 문제 #025 얼마나 많은 데이터를 추적해야 할까 #026 경험의 확인 #027 측정 침입 5장 최적화 #028 수수께끼 #029 게임 #030 이벤트 카운트 #031 이벤트 실행 시간 #032 필터링은 되도록 빨리 #033 왼쪽을 바라보자 #034 토우-밀샙의 법칙 #035 병목 #036 ‘시스템 병목’의 이해 #037 서브시스템 최적화의 문제 #038 모든 문제는 왜곡 문제다 #039 주요 실행 경로 6장 지연 #040 케빈 #041 대기 지연 #042 대기열 이론 #043 쌍곡선 #044 트래픽 강도 #045 점유율 #046 쌍곡선 효과 #047 일관성 지연 #048 지연과 처리량 7장 낭비 #049 컨설턴트 데브라 #050 램프 문제 #051 회계 전문가 마사 #052 효율성 #053 문제를 고칠까 아니면 자원을 추가할까 #054 전설 속 설인 예티 #055 빠른 속도 vs 효율성 #056 확장성 8장 문제 해결 #057 4가지 간단한 질문 #058 데이터를 끝까지 살펴보기 #059 임원의 피드백 루프 #060 부수적 피해 #061 과유불급 #062 IT 본부장 더그 #063 완료란 무엇인가 9장 예측 #064 엔터프라이즈 아키텍트 리차드 #065 예측이 필요한 이유 #066 프로파일을 통한 예측 #067 할지 말지에 대한 예측 #068 선형 동작 #069 왜곡 #070 이벤트 간의 상호의존성 #071 비선형 동작 10장 대기 시간 숨기기 #072 엄마의 초단시간 요리 노하우 #073 도미닉 #074 병렬화 #075 시스템 녹이기 게임 #076 멀티태스킹 #077 인간의 멀티태스킹 11장 논리적 오류 #078 사악한 램프요정 지니 #079 가죽 자켓 #080 묻혀 있는 이상치 #081 요청을 할 때는 주의 깊게 #082 백분위수 명세 #083 적중률 문제 #084 연비 문제 #085 비율의 문제 #086 처리량과 응답 시간은 어떨까 #087 비율은 쓸모없는 것일까 #088 비율을 신뢰할 수 있는 경우 #089 개선된 성능에 대해 설명하기 #090 ‘n배 빨라짐’의 미신 12장 테스팅 #091 테스트가 필요한 이유 #092 위험 #093 파괴적 테스트 #094 테스트는 그저 하나의 단계가 아니다 #095 자동화 테스트 #096 문제 예방하기 13장 계획 #097 유틀리 선생님 #098 용량 계획 #099 사용량 목표 #100 하드웨어 업그레이드가 필요한 시점 14장 정치적 견해 #101 입증 #102 더 적은 것을 약속할 때의 문제 #103 프로젝트의 위험을 확인하는 7가지 방법 #104 빨리 실패하기 #105 체면 #106 보석상의 판매 전략 #107 변경 관리 #108 기록 남기기 #109 실패 #110 긴장은 하되 걱정은 금물 15장 재미삼아 #111 꼬맹이들 최적화

“최적화는 기술적이라기보다는 정치적인 경우가 많다. 그렇다면 왜 최적화에 대한 책들은 거의 항상 기술적인 측면만을 다루는지가 궁금해진다.” __p29

““잘 모르겠습니다. 하지만 문제 해결을 도와드릴 순 있어요”라고 말해보자. 그게 바로 리더십이 발휘되는 순간이다.” __p48

“하지만 진짜 성능 문제는 서버실이나 네트워크 케이블에 있지 않았다. 해답은 고작 3킬로미터 떨어진 낸시의 좁은 칸막이 사무실 책상에 있었다. 우리는 서버실에서 문제를 제대로 보고는 있었지만, 그 문제의 엉뚱한 부분을 바라보고 있었던 것이다.” __p49

“이 이야기의 교훈은 무엇이겠는가? 증상이 발현된 곳으로 가서 관찰하라는 것이다. 부차적 현상이 아니라 실제 증상을, 쉽게 측정할 수 있는 대체 지표가 아니라 실제로 벌어지는 상황을 관찰해야 한다.” __p59

“시스템 관리 도구를 통해서가 아니라, 업무를 처리하지 못해 고통받는 실제 개개인의 관점에서 문제를 관찰해야 한다.” __p62

“우위를 가리기 위한 정보가 필요하다면, 우선 순위가 동일한 증상을 깊이 파헤쳐보기 전에 우선 겉으로 드러난 현상부터 분석해보자. 그래야 어떤 증상이 가장 빨리 완화될 수 있는지를 알아낼 수 있다.” __p64

“여러분이 이 직업에 어울리는 중요한 이유 중 하나는 호기심이다.” __p70

“성능과 관련된 지표는 쉽게 측정하고 개선할 수 있으므로 좋은 성능을 유지하는 데 관측용이성은 무엇보다 중요하다.” __p99

“문제를 발견했을 때 다른 사람의 도움을 받을 수 있는 가장 좋은 방법은 다음의 정보를 포함하는 재현 가능한 테스트 케이스(reproducible test case)를 제공하는 것이다.” __p102

“추적의 반대급부가 사람들이 두려워하는 만큼 나쁜 경우는 거의 없다. 잘 설계한 추적 기능은 풍부하면서도 가볍다.” __p113

“사람들이 원하지 않는 데이터를 프로그램이 더 빠르게 리턴하게 하는 것보다는, 더 적은 데이터를 리턴하게 하는 것이 더 쉽고 저렴하며 훨씬 효율적이다.” __p137

“성능 개선이란 결국 병목(bottleneck)을 제거하는 것이라는 말을 들어본 적이 있을 것이다. 사실 병목이라는 단어 자체가 은유다. 주어진 시간 내에 병에서 따라낼 수 있는 액체의 양은 병의 크기나 용량이 아니라 병 끝에 있는 작은 구멍의 크기에 따라 달라진다.” __p138

“응답 시간에서 가장 많은 비중을 차지하는 부분이 프로그램 실행의 병목이다.” __p138

“나의 설명 덕분인지, 이 프로젝트에서 가장 어려웠던 경청-진정-설득의 절차를 무사히 마칠 수 있었다.” __p187

“문제 해결 과정에서 진전은 현재 일어나고 있는 일에 대해 더 많은 것을 알게 될 때 가능해진다. 즉 읽고 질문하고 더 많은 데이터를 수집하거나 이런 저런 실험을 해봐야 한다는 뜻이다.” __p210

“더그는 우리의 노고에 감사하다는 인사를 남기곤 자리를 떴다. 의사결정권자가 회의실에 있으면 사실 결정은 쉬운 것이었고, 더그에게는 그 결정을 내릴 권한이 있었다. 왜 7시가 아니라 더 일찍, 5시에 더그에게 연락하지 않았을까? 피드백 루프는 최대한 빠르게 가져가자.” __p219, p220

“사람들이 병렬화를 오용하지 않도록 시스템을 관리하는 것은 시스템 관리자의 의무다. 흔히 말하듯 “과유불급”이므로.” __p261

“다시 말해, 사람은 한 번에 하나 이상의 일을 하려 한다면 몸만 축날 뿐 바보가 되어 버릴 수도 있다. 스스로 높은 성과를 내길 원한다면 멀티태스킹은 관두라. 그건 컴퓨터가 할 일이다.” __p266

“최적화를 할 때는, 여러분이 정말로 원하는 것이 무엇인지를 골똘히 생각해보자. 여러분이 정말 관심을 가지는 경험의 속성들을 열거해보자. 그리고 최상의 결과를 만들어 낼 수 있는 트레이드오프 지점을 찾아내자.” __p293

“테스트는 왜 필요할까? 분주한 대규모 시스템 상에서 애플리케이션의 각 기능이 얼마나 빠르게 실행되는지 알 수 있다. 실제로 기능을 작성하는 동안 시스템의 약점이 어디인지는, 테스트를 통해서 알 수 있다. 계획은 테스트를 대체할 수 없다.” __p303

“프로젝트의 막바지에 결함을 수정하는 것은 초기에 일찍 수정하는 것보다 훨씬 더 많은 비용이 들어간다.” __p310

“하수구에 빠뜨린 열쇠를 화분에서 찾을 리는 만무하다.” __p330

“분산식 권한 모델도 여러분이 필요한 권한을 얻을 수 있다면 더 쉽게 진전을 이룰 수 있다. 중요한 것은 필요한 권한을 얻는 것이다.” __p338

“그러니 내가 여러분이 빨리 실패하기를 바란다는 것은, 저주가 아니라 축복을 내리고자 함이다.” __p342

“내 동료 안조 콜크(Anjo Kolk)는 성능 문제의 90%는 정치적인 문제이고 10%만이 기술적인 문제라고 했다. 여러분이 뭔가를 고친다는 것은 곧 다른 누군가가 일을 망쳤다는 암시를 만들어낼 수 있음을 깨달아야 한다.” __p344

“솔직함에는 책임감이 필요하다. 효과적인 솔직함이란 단순히 떠오르는 모든 생각을 여과 없이 내뱉는 것이 아니라 사실이 무엇인지를 신중하게 판단한 후에 사실을 말하는 것이다.” __p345

“대부분의 실패 사례는, 우리 팀은 정확히 어떤 일을 해야 할지 알고 있었음에도 결국 고객사를 설득하지 못한 경우다. 해야 할 일을 하게끔 사람들을 설득하는 것이 프로젝트에서 가장 어려운 부분이다.” __p355

“긴장되는 상황을 두려워하지 말자. 의미 있는 순간을 마주하기 위해 몸이 더 많은 힘과 집중력을 선물해주는 것이라고 받아들이자.” __p359

참 시의적절한 시기에 책이 출간됐다. 저자 캐리는 무려 사반세기 동안 이 책에서 다루는 주제를 가르쳐오며 실전에서 사용해왔다. 나는 이 책을 이미 여러 번 읽었고, 여러분도 재미있게 읽을 것이라 믿는다. 어쩌면 여러분의 인생을 바꿀 수도 있는 책이다. 내 삶 또한 이 책에서 설명하는 원리들에 의해 바뀌었기 때문이다. 이미 나는 18년 전에 캐리의 덕을 봤다. 이 책의 본질은 2003년 캐리가 제프 홀트(Jeff Hold)와 공저한 『오라클 성능 최적화(Optimizing Oracle Performance)』의 본질과 같기 때문이다. 그 본질이란 ‘R 방법론(Method R)’이다. R 방법론은 내 삶을 바꾸고, 내 경력의 토대가 됐다. R 방법론을 알기 전에는 그저 데이터베이스 관리자로서 알아야 하는 ‘보편적인’ 팁과 요령, 도구와 기법을 연구하고 적용해왔다. 물론 성공한 적도 있지만 그 결과는 대체로 일관적이지 못했으며 모든 것이 복잡하고 어렵게만 느껴졌다. R 방법론은 최적화에 대한 내 생각을 거의 완전히 바꿔놓았다. 그러자 모든 것이 명료하고 간단해졌다. 비단 오라클과 관련된 것뿐만이 아니었다. R 방법론을 알게 되면서 내가 개선해야 하는 모든 것에 대해 어떤 정보를 수집해야 하는지를 분명하게 파악할 수 있었다. 성능 이슈의 근본 원인을 어디서 찾아야 하고 어떻게 수정해야 하는지를 알 수 있었다. 하지만 특히 좋았던 점은 내 방식과 그 방식을 행하는 이유를 다른 사람에게 설명할 수 있게 됐다는 점이었다. 특히 성취감도 컸다. 문제의 원인과 개선 방법을 단순히 추정하는 것이 아니라 R 방법론을 통해 명확히 알 수 있었기에 가능했다. 실제로 많은 이가 오라클을 넘어 다양한 분야에 R 방법론을 적용할 수 있다는 가능성을 엿보았지만, 2003년 캐리가 집필한 책은 그저 오라클에 관한 책일 뿐이었다. 하지만 이번 책은 다르다. 이 책은 결정을 내려야 하는 ‘사람들’에 대한 책이다. 단순히 오라클 관련자나 실행 시간이 긴 배치 작업(batch job) 등을 실행하는 IT 종사자들을 위한 책이 아니다. 식사를 준비하거나 아이들을 운동 수업에 데려다줘야 하는 모든 이를 위한 책이다. 즉 뭔가를 더 빠르게, 더 좋게, 더 우아하게 만들고 싶어 하는 모두를 위한 책이다. 이 원리는 모든 것에 동일하게 적용된다. 처음 R 방법론을 적용할 때 나는 “이게 정말 이렇게 간단할 수 있을까?”라고 생각했다. 그 답은 분명히 “그렇다!”이다. 이 책은 읽기에도 편하다. 캐리는 뛰어난 기술 전문가이자 탁월한 이야기꾼이다. 캐리는 (기술 분야든 아니든) 여러분이 만나게 될 최고의 발표자 중 한 명이며 캐리의 그런 재능은 이 책에 고스란히 녹아 들어 있다. 많은 이의 발목을 잡아온 제법 난해한 주제를 편안한 어조로 풀어가는 캐리를 보면 만족감과 참신함이 동시에 느껴진다. 캐리가 소개하는 일화는 IT 분야든 아니든 거의 모든 이의 경험과 관련이 있다. 이 책을 읽다 보면 여러분도 “맞아, 나도 이런 상황을 맞닥뜨렸었지”라고 회상할 수 있는 일화를 마주하게 될 거라고 생각한다. 이 책에서 캐리가 소개하는 일화는 재미도 있지만 그로부터 얻는 깨달음은 여러분을 변화시킬 것이다. 이 책에서 여러분은 상황을 올바르게 관찰하는 간단한 행위만으로도 세상을 바꿀 만한 차이를 만들어 낼 수 있음을 깨닫게 될 것이다. 자신있고 일관되게 성능 문제를 식별하고 확인하며, 범위를 정해 분석하고 해결하는 방법도 배우게 될 것이다. 동료의 감정을 긍정의 힘으로 승화시키는 방법도 익힐 것이다. 또한 더 나은 테스트를 통해 문제에 부딪히지 않고 그 문제를 ‘회피’하는 방법도 알게 될 것이다. 더 많은 개선이 가능한지 여부에 대한 확실한 증거를 찾는 방법도 배울 것이며, 그리고 결국 이해하게 될 것이다. 원한다면 이 책을 교과서라고 생각해도 된다. 필요하면 아무 때고 꺼내 들어 읽을 수 있는 책이기도 하다. 바로 여러분과 같은 수많은 이들이 세상에 긍정적인 영향을 주는 데 도움을 줄 수 있을 책이라고 굳게 믿는다. - 구드문두르 요셉손 / 이나리스(Inaris)의 성능 전문가이자 디렉터 처음 책만 출판사에서 이 책의 원서인 『How to Make Things Faster』의 검토를 요청하셨을 때 기껏해야 성능 튜닝을 주제로 하는 지루한 기술 서적일거라고 생각하면서 읽기 시작했다가 단숨에 3장까지 읽었던 기억이 납니다. 이 책은 단순히 “어떻게 무언가를 빠르게 동작하게 할 것인가”에 대한 책이 아니라 문제가 무엇인지, 어디를 관찰해야 하는지, 어떤 데이터가 진짜 문제 해결의 단서를 줄 수 있는지를 알아내는 방법을 소개하는 책입니다. 저자는 무려 111가지의 실제 사례를 통해 문제 해결의 본질을 보여줍니다. 그 과정에서 단순히 “느리다”는 증상에만 집착하고 엉뚱한 곳에서 그 원인을 찾는, 엔지니어라면 공통적으로 겪는 실수들을 마주하게 됩니다. 이 책을 번역하면서 가장 인상 깊었던 점은 성능 개선과 관련된 이야기가 사고의 전환과 관찰의 훈련으로 이어진다는 점입니다. ‘문제를 올바르게 해결한다’는 것은 결국 어디를 관찰할 것인지, 어떤 것을 무시할 것인지를 결정하는 과정입니다. 그리고 이 책을 모두 읽은 후에야 수많은 엔지니어들이 이 과정에서 어떻게 잘못된 결정을 내리게 되는지, 그리고 올바른 결정을 내리려면 어떤 식으로 사고를 이어가야 하는지를 알 수 있었습니다. 엔지니어라면 늘상 마주하게 되는 문제 해결의 과정에 이 책이 큰 도움이 되어 주길 바랍니다. 늘 좋은 책을 번역할 수 있는 기회를 주신 책만 출판사, 그리고 사랑하는 가족들에게 지면을 빌려 감사의 인사를 전합니다. - 장현희