[책 리뷰] 일 잘하는 엔지니어의 생각 기법

팀원의 추천으로 "일 잘하는 엔지니어의 생각 기법"을 읽게 되었습니다. 
이 책은 기술 서적이 아니고 저자가 수십 년 동안 현장에서 문제를 해결하며 쌓은 사례와 사고방식을 공유하는 책입니다. 2025년 해외에서 출간되었고 번역본으로 읽을 수 있습니다.
 
이 책은 개인적으로 경험이 적은 엔지니어에게는 추천하기 어렵습니다. 어느 정도 일에 익숙해지고 현장에서 몇 번의 갈등을 겪어본 사람이 읽으면 좋을 것 같습니다.
 
이 책에는 저자가 직접 겪은 여러 교훈과 사례가 담겨 있습니다. 그중 몇 가지를 소개합니다.
 

1. 기술 종사자들은 대체로 자신의 고객을 방문하지 않으려 한다

저자는 회사에서 풀지 못한 문제를 들여다보다가, 담당자들이 전화나 FAX로만 응대하고 있었다는 사실을 깨닫습니다. 장거리였지만 직접 고객사를 방문했고, 현장을 보자마자 문제를 간단히 해결합니다.
문제가 잘 해결 안될 때는 직접 현장에 가서 확인하면 좋다는 교훈이 줍니다. 저도 1~2주전에 채팅으로 잘 해결이 안되어 직접 대면으로 이야기나눠 5분안에 해결한 적이 있습니다.
 

2. 증상을 나열하고 비즈니스 우선순위에 따라 하나씩 해결한다

문제가 생기면 보통 한 가지가 아니라 여러 증상이 동시에 나타납니다. 이 사례에서 저자의 회사는 고소를 당할 만큼 오랫동안 해결하지 못한 문제들을 안고 있었습니다. 저자는 긴급히 파견을 가서 증상을 모두 나열하고, 비즈니스 영향도에 따라 순서를 매긴 뒤 하나씩 해결해 나갑니다. 나열하지 않았다면 어떤 증상이 어떤 리스크로 이어지는지 파악할 수 없었고, 결국 고객의 고소를 막지 못했을 것입니다.
당연한 말 같지만 실제 우선순위를 나열하고 판단하는 것은 쉽지 않습니다. 
 

3. 부하와 응답 시간은 선형 관계가 아니다

부하가 큰 시스템에 부하를 더하면 응답 시간은 급격히 증가합니다. 반대로 무거운 작업의 부하를 조금만 줄여도 응답 시간이 크게 개선됩니다. 이런 관계를 비선형이라고 하며, 어느 지점에서 개선 효과가 나타날지 예측하기 어렵습니다.
부하에 따른 응답 시간을 계산할 때 사람들은 보통 선형 그래프를 떠올립니다. 하지만 저자는 부하의 실제 양상은 선형이 아니라고 말합니다. 부하가 커질수록 응답 시간은 기하급수적으로 늘어나는 곡선 형태가 됩니다. 그래서 부하가 큰 지점을 조금만 줄여도 응답 시간이 크게 낮아지는 효과를 얻을 수 있습니다.
 

4. 답할 수 없는 질문 앞에서는 대체 질문에 만족하는 경향이 있다

저자는 문제를 해결하는 과정에서 다양한 유형의 사람을 만납니다. 그중에는 자신이 답할 수 없는 문제를 마주했을 때, 진짜 해답이 아니더라도 뭔가 해결될 것처럼 보이는 방향으로 기우는 사람이 많다고 합니다.
 

5. 전체 최적화보다 우선순위가 높은 병목 하나에 집중한다

시스템 전체를 최적화하고 싶은 마음은 이해하지만, 가장 좋은 방법은 증상을 한 번에 하나씩 처리하는 것입니다. 전체를 동시에 다루면 엉뚱한 방향으로 벗어나기 쉽습니다.
따라서 비즈니스 우선순위가 가장 높은 증상의 병목에 집중해야 합니다. 2번 사례와 마찬가지로, 우선순위가 높은 병목 하나에 집중하면 전체 시스템의 많은 부분이 함께 개선됩니다.

—————-
스크랩:
p48 기술 종사자들은 대체로 자신의 고객을 방문하지 않으려 한다
p49 그 문제를 내가 이해해야 한다는 것이다. 그래야 나가 도움을 주거나 받을 수 있다
p49 문제의 증상을 사용자가 바라보는 방식으로 관찰해야한다
p67 증상의 목록을 나열하고 비지니스 우선순위에 따라 나열한 후 증상을 관찰하고 지연이 발생하는 원인을 찾아 조치한다
p71 원인이 한가지라고 생각하지 말자
p74 가장 비용이 적게 드는 방법은 실패해도 타격이 크지 않는다
p102 재현 가능한 테스트 케이스를 제공한다. 어떻개 해야 다른 사람이 이 문제를 재현할 수 있을까? 기대했던 동작은 무엇인가? 실제로 발생항 동작은 무엇인가?
p105 workload -> 작업부하
p108 프로그램을 재시작하지 않고도 추적을 사용할수 있게 하는 기능은 매우 바람직하다
p111 개발자들이 사용할 도구를 제공하는 것만으로는 충분하지 않다. 개발자들 역시 스스로 도구를 사용할 의지와 기술을 갖추어야 한다
p119 프로그램의 속도를 느리게 만든 적이 있는 몇가지 이벤트 종류만 이해하면 된다.
p119 프로파일은 프로그램이 시간을 어떻게 사용하는지를 보여준다. 또한 어떻게 시간을 하지하는지도 보여준다
p132 데이터베이스에 인덱스가 존재하는 이유도 필터링을 일찍 수행하기 위해서이다
p141 전체 시스템을 최적화하고 싶어하는건 이해하지만 가장 좋은 방법은 한 번에 증상을 하나씩 처리하는 것이다. 전체를 하면 엉뚱한 방향으로 벗어날 수 있다. 따라서 비지니스에서 가장 우선순위가 높은 증상의 병목에 집중해야 한다
p144 여러 항목의 연관관계를 파악하는 것이다. 그러러면 프로파일상의 각 이벤트의 의미를 해해야 한다
p155 여러분이 분석하고자 하는 프로그램 기능이 정상적일때는 어떻게 동작하는지 이해를 할 수 있다면 믄제 해결을 쉬워진다
p160 어떤 리소스 사용량이 많아지면 그 리소스를 획득하기까지 기다리는 시간이 많아진다
p205 비즈니스에 중요한 증상을 가장 빠르게 완화할수 있는 다음 4가지 질문에 답할 수 있다
1.  얼마나 걸리나
2. 왜
3. 만일 한다면
4. 그 밖에
p206 자신이 답할 수 없는 질문을 맞닥뜨릴 경우 대체질문에 만족하는 경향을 보인다
p210 문제해결과정에서 진전은 현재 일어나고 있는 일에 더 많은 것을 알게 될때 가능해진다
p243 이벤트 간의 상호의존성을 이해하면 예측의 정확도를 높읠 수 있다
p246 부하가 큰 시스템에 부하를 더하면 응답시간이 급증하게 된다. 반대로 무거운 작업 무하를 줄일 수 있다면 응답시간이 엄청나게
개선된다. 이런 것을 비선형이라고 하며 비선형적으로 개선괴는 부분을 예측하기 어렵다
p257 병렬작업으로 응답시간은 줄일 수 있지만 부하가 줄어들지 않는다
p290 비율(처리량, latency 등)을 확인할때는 의구심을 들어야한다. latency를 줄인다고 하면 처리량이 빠른 task를 많이 실행하면된다.
p303 테스트를 하려면 1)실질적인 데이터와 2) 실제 트래픽 강도 이 2가지 없이는 발견하기 어려운 성능 문제도 많다.
p309 10개월 전 작성한 프로그램을 수정하는 것은 어제 작성한 프로그램을 수정하는 것보다 훨씬 많은 시간이 걸린다. 그 시기의 배경지식을 다시 떠올리는 시간도 필요하며 지난 10개월간 새로 나타난 상호의존성을 처리하는 것은 그보다 많은 시간이 걸릴 수 있다.
p310 개발자와 관리자는 완전히 겁을 먹는 정도는 아니더라도 코드 변경을 꺼리기도 한다. 만에 하나 다음 테스트 시점에 어떤 부수적 피해가 발견될지 몰라 두려움에 시달리는 것이다.
p320 용량계획(capacity planning)
p322 최적화는 둘 중 하나로 진행해야 한다. 1. 이벤트 카운트를 줄이거나 2. 각 이벤트의 평균 실행 시간을 줄이면 된다.
p334 프로젝트의 위험을 확인하는 7가지 방법
1. 잠재 고객객의 목표: 결과물일까? 안도감일까?
2. 잠개 고객의 성향: 배타적인가? 수용적인가?
3. 잠재 고객의 문화: 정치적인가? 기술적인가?
4. 잠재 고객의 분위기: 공황 상태인가? 침착한 상태인가?
5. 잠개 고객의 주의력: 방치하는가? 배려하는가?
6. 잠재 고객의 자기 인식: 환상인가? 실제인가??
7. 권한에 대한 접근: 불가능한가? 가능한가?
p344 여러분이 뭔가를 고친다는 것은 곧 다른 누간가가 일을 망쳤다는 암시를 만들어 낼 수 있음을 꺠달아햐 한다.
p351 단순히 제안서를 작성하는 것보다는, 기업의 비지니스 문제를 해결하기 위해 지속적으로 노력할 사람에게 영감을 주는 편이 훨씬 나은 방법이다.