이 글은 YES24 리뷰어클럽 서평단 자격으로 도서를 제공받고 작성한 리뷰입니다.

"일 잘하는 엔지니어의 생각 기법"

이 책은 오라클 성능 분석의 대가인 캐리 밀샙(Cary Millsap)이 쓴 IT 기술 서적이다. 하지만 나는 오늘 이 책을 IT 분야 엔지니어가 저술한 내용을 플랜트 엔지니어의 입장에서 재해석하여 리뷰해보고자 한다.

소프트웨어를 다루는 IT와 거대한 설비/장치를 다루는 플랜트 산업은 겉보기에 전혀 다른 세상 같다. 하지만 '문제 해결(Problem Solving)'이라는 엔지니어링의 본질적 측면에서, 이 책이 던지는 메시지는 플랜트 현장에서도 놀랍도록 유효하며 깊은 울림을 준다.

1. 정의되지 않은 업무는 AI도 해결 못 한다 (p.006)

저자는 AI 시대 엔지니어의 핵심 경쟁력을 "필요한 일을 스스로 찾아내고 업무로 정의하는 능력"이라고 말한다.

이는 플랜트 엔지니어링에서도 마찬가지다. 설계 자동화 툴이 발전하고 AI가 도입되어도, 프로젝트 초기에 Scope(업무 범위)를 명확히 정의하고 무엇이 문제인지(Problem Definition)를 파악하는 것은 여전히 인간 엔지니어의 몫이다. 문제를 정의하지 못하면, 아무리 좋은 툴(Tool)이나 시공 기술이 있어도 엉뚱한 결과물을 내놓을 뿐이다.

2. 성능 문제의 90%는 '기술'이 아닌 '정치'다 (p.007, p.009, p.355)

IT 시스템의 성능 저하 원인이 대부분 조직 내 정치와 협업 문제라는 지적은, 복잡한 공종(Process, Mechanical, Electrical, Civil 등)이 얽혀있는 플랜트 프로젝트에서 더욱 뼈아프게 다가온다.

"해야 할 일을 하게끔 사람들을 설득하는 것이 프로젝트에서 가장 어려운 부분이다." (p.355)

플랜트 프로젝트의 지연(Delay)이나 병목 현상 역시 기술적 난이도보다는, 부서 간의 이기주의나 책임 회피성 커뮤니케이션에서 비롯되는 경우가 많다. "성능 최적화에는 정치적 스킬이 필요하다"는 저자의 말은, 성공적인 프로젝트 완수를 위해 엔지니어가 도면 검토 능력만큼이나 '협업과 설득의 기술'을 갖춰야 함을 시사한다.

3. 기계의 효율 vs 인간의 안전 (p.251, p.265)

저자는 '대기 시간 숨기기(Latency Hiding)'를 설명하며 기계와 인간을 명확히 구분한다. 기계는 멀티태스킹이 효율적이지만, 인간에게는 스트레스와 기억 상실을 유발한다.

플랜트 현장에서 이는 '안전(Safety)'과 직결된다. 기계처럼 효율성만을 좇아 작업자에게 멀티태스킹을 강요하거나 무리한 공기를 밀어붙이는 것은 사고를 부르는 지름길이다. "기계와 인간은 다르다"는 명제는, 시스템 효율을 추구하되 인간의 한계와 안전을 최우선으로 고려해야 하는 엔지니어링 윤리를 상기시킨다.

4. 화재 진압보다 '화재 예방'이 인정받는 조직 (p.310, p.314)

배리 보엠의 연구(결함 수정 비용은 뒤로 갈수록 기하급수적으로 증가)는 플랜트 산업의 불문율과도 같다. 설계 단계(FEED/Basic Design)에서 오류를 잡는 비용과, 시공(Construction)이나 시운전(Commissioning) 단계에서 수정하는 비용은 천지 차이다.

"화재 예방보다는 화재 진압이 더 멋져 보인다." (p.314)

하지만 현실에서는 사고 없이 프로젝트를 끝낸 사람보다, 터진 사고를 수습하며 밤새운 사람이 영웅 대접을 받곤 한다. 저자는 이것이 잘못된 문화임을 꼬집는다. 진정으로 일 잘하는 엔지니어는 화려한 트러블 슈팅 이전에, 지루해 보일지라도 철저한 사전 검토와 예방에 힘쓰는 사람이다.

5. 평정심과 용기, 그리고 도움 요청 (p.356, p.359)

거대한 규모와 예산이 투입되는 플랜트 프로젝트에서 엔지니어는 늘 긴장 속에 산다. 저자가 제시한 멘탈 관리법은 현장의 엔지니어들에게 큰 위로가 된다.

• 평정심: 천재지변이나 자재 납기 지연 등 내 힘으로 어쩔 수 없는 일은 받아들일 것.

• 용기: 내가 바꿀 수 있는 엔지니어링 이슈는 끝까지 시도해 볼 것.

• 협력: 모르는 것은 부끄러워 말고 도움을 청할 것.

긴장감을 "의미 있는 순간을 위해 몸이 주는 에너지"로 받아들이라는 조언은, 시운전을 앞둔 혹은 중요한 입찰을 앞둔 엔지니어들이 마음에 새겨야 할 태도다.

총평

캐리 밀샙은 컴퓨터 속의 데이터 트레이스(Trace)를 다루는 사람이지만, 그가 꿰뚫어 본 것은 결국 '시스템을 움직이는 사람과 조직'이었다.

2002년 대한민국이 월드컵 4강으로 뜨거웠을 때. 제가 개발하던 MPH-2000 (삼성 최후의 PDA 핸드폰) 기반의 삼성전자 물류서비스 앱이 전국의 물류센터에 배포가 되었습니다. 일반 가정에서 전자제품을 주문하면, 물류 배송 기사들이 배송을 완료하고 송장을 폰으로 확인하고, 처리 결과를 전송하면 데이터가 처리되는 시스템이었죠. 당시 휴대폰에는 GPS 기능이 없었기 때문에 기지국 정보로 배송 위치를 추정하고, 배송 완료 시간을 기록해서 물류 정보에 통합하는 것만으로도 획기적이었습니다. 
 
그런데, 당시에는 매우 심각한 문제가 하나 있었습니다. ARM 기반의 별도 버전의 gcc로 개발한(뭔지 몰라도 그냥 매우 생소한 프로그래밍 언어라고 생각하시면 됩니다.) 라이브러리에서 Memory Leak이 아주 미세하게 발생하고 있었지만, 그걸 개발한 종합연구소의 박사님도, 그걸 기반으로 앱을 만든 저도 원인을 밝혀낼 방법이 없었습니다. 프로그램에서 쌓인 메모리의 피로감은 점점 앱을 느려지게 만들었고, 두 달 정도 지나면 폰이 느려지기 시작했어요. 결국 폰이 너무 느려져서 앱 실행조차 힘들다는 문의가 들어오기 시작했고요. 회사에서는 후속 기종 개발이나 라이브러리 업데이트 계획이 없었으니, 회사의 향후 지원도 없을 예정이었습니다. 
 
가장 즉각적인 조치 방법은 폰을 한 번 껐다 켜는 거였습니다. 컴퓨터가 제대로 동작하지 않으면, 껐다 켜는 것이 해답일 때도 있다는 것이 바로 이런 방법이죠. (당시 메모리가 256kb 밖에 안되었던 폰을 껐다켜면, 메모리가 깔끔하게 비워졌다.) 그렇지만, 고객사에 프로그램의 문제인데, 당장 고칠 방법이 없으니 껐다 켜면 된다고 말할 수는 없는 노릇이었습니다. 그런 와중에 고객사에서 고객 사인을 터치펜으로 받아서 전송하는 기능을 추가해달라는 요청이 왔어요. 그 때, 번뜩하고 떠오른 생각이 있었습니다. 당시 피처폰들은 OS와 하드웨어의 구조상 메모리와 프로세서가 제한적이라서, 새로운 앱을 메로리에 로딩하기 위해서 반드시 재부팅을 해야했거든요. 
 
그러니까, 정리하자면 폰에 메모리가 가득차서 느려지기 시작하는건 2달이 걸리고, 제가 새로운 기능을 2달에 한 번씩 추가해서 앱을 배포하면 고객은 자연스럽게 폰을 껐다 켜게 된다는 거였습니다. 물론, 새로운 기능을 추가로 넣는 것이 어렵기는 했지만, 해결할 수 없는 문제를 손쉽게 해결하는 최선이었죠. 1년 반 정도의 시간 동안 새로운 부가 기능을 6개를 만들어서, 버전 6까지의 앱 업그레이드가 이뤄졌습니다.
 
 
결국, 고객인 물류배송기사 분들은 새로운 버전으로 앱을 설치할 때마다 속도가 점점 빨라지고, 기능도 늘어난다며 만족도가 오히려 높아졌습니다. 새로운 산업용 PDA가 도입되어 교체되는 1년 넘는 시간 동안 메모리나 속도 문제는 아무도 문제를 삼지 않았죠. 
 
 
문제를 해결하는 엔지니어의 사고 방식을 배울 수 있는 책
 
이 책, '일 잘하는 엔지니어의 생각 기법'의 원제는 How to make things faster 입니다. 1990년대부터 오라클 컨설턴트로 현장에서 DB와 시스템에서 발생하는 문제들을 해결해 왔던 저자 캐리 밀샙의 일화 등을 중심으로, 어떻게 시스템을 빠르게 만들 것인가에 대해 이야기하는 책이죠. 그렇다면 프로그래머나 아키텍트, DBA 들이 이 책을 보는 것이 좋겠다고 여길 수 있지만, 실제로는 이건 기술서라기 보다는 개발 철학, 경영 전략 도서에 가깝습니다. 문제를 인식하고, 측정 한 다음, 해결책을 도출하고, 문제를 해결한 다음 피드백을 공유하는 일종의 PDCA(Plan-Do-Check-Action)이 왜 필요한지를 설명하거든요. 그것도 우리의 주변에서 간과했던 작은 경험들을 모아 큰 가르침을 던집니다.
 
예를 들면, 앞에서 얘기한 저의 과거 경험도 알고 보면, 이 책에서 언급한 '문제 해결'의 선택 방식입니다. 
 
저자인 캐리는 고객사의 시스템의 성능 향상을 위해 다른 동료들과 회의실에 모여 끝장 회의를 합니다. 고객사 시스템 성능, 가용성을 99.999%까지 확보하기 위한 목표가 주어졌기 때문이에요. 실제 시스템의 업타임을 99.99%로 하면 1년 동안 52분의 장애나 사용불가 상태가 있을 수 있지만, 99.999%가 된다면 겨우 5분 정도의 다운타임이 발생하는 차이입니다. 
 
수백만 달러의 투자를 한다고 해도 실제 이런 가용성을 확보한다는 보장을 할 수도 없었고, 병목이나 효율화 대상을 더 이상 찾기도 어려웠던 주인공은 고객사의 IT본부장에게 가서 이걸 꼭 달성해야 하는지 물어보는 것이 가장 빠른 해결 방법이라고 생각했습니다. 
 



주인공은 본부장에게 99.99%의 가용성은 해결했지만 합리적인 비용에 99.999%를 달성할 수 있는 아키텍처를 만들 방법이 없다고 설명했어요. 그러자, IT본부장인 더그는 비용이 얼마나 드는지 물었고, 고민하다 주저없이 "좋아요. 99.99%면 충분합니다."라고 답했고, 그걸로 회의는 끝났습니다. 물론, 이 챕터의 교훈은 '피드백 루프를 최대한 빨리 가동하자'는 것이었지만, 큰 의미에서 저는 이걸 문제 해결 방식의 선택이 중요하다고 봤습니다. 
 
해결할 수 없는 문제를 붙잡고 시간을 보내기 보다는 가장 빠른 방법이 무엇인지, 의사결정자가 누구인지를 통해 고객의 문제를 해결하는데 집중하는 것이 어쩌면 중요하거든요. 
 
 
은 탄환(Silver Bullet)으로 모든 문제를 해결한다는 환상
여러분들은 저의 일화에서 중요한 것은 바로 메모리 누수 현상을 잡아 내서, 근본 원인을 해결하는 것이라고 생각했을지 모릅니다. 그러나, 그것은 원인이지 문제가 아닙니다. 문제는 고객의 배송 앱이 점점 느려지고 있는 문제였고, 현장에서 배송을 완료하도고 완료 처리를 할 수 없는 것이 문제였습니다. 즉, 배송 완료만 빨리 처리할 수 있다면, 꼭 메모리 누수를 잡아내야 할 필요는 없었겠죠. (실제로는 매일 한 번씩은 스마트폰을 껐다 켜달라는 안내를 할 수 없는 회사의 분위기가 더 문제라는데는 동의합니다.)
 
많은 엔지니어들이 빠지는 환상이자, 큰(?) 숙제는 바로 한 방에 모든 문제를 풀어 낼 알렉산더 대왕의 가위처럼, 은 탄환이라는 해결책이 존재한다고 믿는 것입니다. 그걸 발견할 때까지, 여러 번의 반복과 조사, 연구를 해내려고 하죠. 그렇지만, 엔지니어에게 중요한 것은 문제를 정확히 관찰하고, 측정한 다음, 개선하는 것이겠으나, 제일 중요한 것은 문제를 정의하는 것입니다. 
  


 

그리고, 여기서 엔지니어가 놓치기 쉬운 '우선 순위'라는 것이 존재합니다. 고객의 목표를 달성하기 위해 우리가 만든 기계나 앱, 서비스 들이 동작하지 않을 때, 아니면 정상적으로 동작할 때 가장 정상적이고 우수해야 하는 항목이 바로 우선 1순위가 되는 것이죠. 이게 중요한 이유는 많은 엔지니어들이 고객의 우선 순위와 본인의 우선 순위를 제대로 맞추지 않고, 엔지니어링의 의미를 제대로 이행하지 못하기 때문입니다. 엔지니어링은 '돈을 버는 기술'입니다. 우리는 '원리를 찾고, 새로운 걸 만드는 과학'과는 다른 일을 합니다. 고객의 문제를 빨리 해결해서, 돈을 벌 수 있도록 하는 것이 엔지니어링입니다. 

이 책은 실제 현장에서 간과하기 쉬운 '화장실에 쌓여있던 출력물', 'ERP 화면에서 업체를 찾기 위해 다음 페이지 버튼을 26번 누른 회계 직원', '최종 청구서 발행 이후 청구서만 출력의 체크박스를 체크하지 않아 수십 박스의 종이를 낭비한 직원' 들의 이야기를 늘어놓으면서, 그런 가르침을 차곡차곡 쌓아서 머리에 강제 주입시키는 책입니다. 고객을 관찰하고, 고객의 우선 순위를 나의 우선 순위에 맞추며, 근본적인 질문부터 가슴에 새기도록 만드는 책이랄까요?
 
이런 꿈도 꾸었을 정도로 책에 빠져들었어요. 'Jet Brains IDE에서 TAB키를 여기서 누르면, 테스트 결과코드를 미리 여기 삽입할 수 있으니 시간이 20분 정도 줄었던 경험을 회사 전체 개발자들이 알게 된다면 얼마의 시간이 줄어들까? 무려 1만분 정도의 시간이 생기는 거잖아? 누구나 줄일 수 있는 이벤트의 수행시간은 일상에도 있는 거였어'라는 꿈을 꾼 겁니다. (직업  의식이 이렇게 무섭습니다.)
 
은 탄환으로 모든 문제를 해결하기 보다, 하나씩 문제를 맞닥뜨리고 해결해 나가는데 이 책은 중요한 지침 중의 하나가 되지 않을까 싶습니다. 
 
참고로 이 책을 한 권 샀는데, Yes24 서평단에 당첨되면서 덜컥 책이 2권이 되었습니다. (한 권은 우리 개발자 줘야겠어요. ^^)
 

간단한 문장으로 설명할 수 없다면 그건 제대로 이해한 것이 아니다.

15장 재미삼아 #111 꼬맹이들 최적화, p362

이 책은 단순한 기술서라기보다는 문제를 어떻게 바라보고, 어디서부터 해결해야 하는지를 알려주는 책입니다.

AI가 코드를 대신 써주는 시대에 여전히 사람에게 필요한 사고력과 판단력이 무엇인지 짚어줍니다.

📌 이런 분들께 추천합니다

✔️ 문제를  해결해야 하는 개발자, 엔지니어

✔️ 코딩은 하는데 개선하는게 어려운 분

✔️ 기술보다 사고 방식, 문제 접근법이 궁금한 분

✔️ 비전공자거나 바이브 코딩을 하지만 엔지니어적 사고를 기르고 싶은 분

성능 문제의 답은 코드보다 관찰, 질문, 판단에 있다.

이 책은 시스템 성능 개선을 다루지만 CPU, 메모리 같은 기술 설명에만 머물지 않습니다. 문제를 어디서 관찰해야 하는지, 지금 보고 있는 수치가 진짜 문제인지, 전체 평균에 속지 않고 중요한 병목을 찾는 법등을 실제 사례(111가지 이야기)로 풀어냅니다.

기술 용어를 나열하기보다 일상적인 비유와 그림, 스토리텔링으로 설명해 비전공자도 충분히 따라갈 수 있었습니다.

1️⃣ 문제의 본질은 대부분 왜곡이다

모든 시스템은 균일하지 않고, 중요한 프로그램, 이벤트는 항상 소수라는 관점이 인상 깊었습니다. 전체 평균만 보고 판단하면 정작 중요한 문제를 놓치게 된다는 점은 개발뿐 아니라 업무 전반에 활용 할 수 있습니다.

2️⃣ 성능 문제의 90%는 기술이 아니라 사람의 문제

조직 내 우선순위, 협업, 정치적 판단이 문제 해결을 더 어렵게 만든다는 이야기는 실제 협업하면서 느꼈던 생각들이 적혀 있어 현실적인 공감 포인트였습니다.

이 책은 일 잘하는 엔지니어 = 코드만 잘 짜는 사람이 아니라 문제를 정의하고, 설득하고, 결정하는 사람임을 계속 강조합니다.

3️⃣ 대기 시간 숨기기 같은 개념의 생활 밀착 설명

요리, 골프, 일상 예시로 설명되는 지연, 병렬화, 멀티태스킹 이야기는 개념을 오래 기억하게 만들어줍니다.

전문 용어에 부담이 없어서 바이브 코딩으로 개발을 시작한 분들에게도 잘 맞을 것 같습니다.

한 번에 읽기에도 부담이 없고 한 장씩 끊어 읽기에도 좋고 필요한 부분만 다시 펼쳐보기에도 편합니다.

이 책은 어떻게 하면 더 빨리 동작하게 할까?보다 지금 내가 풀고 있는 문제가 맞는가?를 먼저 묻게 만듭니다.

개발자, 엔지니어뿐 아니라 복잡한 문제를 다루는 모든 직군에게 일을 잘한다는 것이 무엇인지 다시 생각하게 해주는 책이었습니다.

기술을 넘어 사고력을 기르고 싶은 분들께 추천합니다.

간단한 문장으로 설명할 수 없다면 그건 제대로 이해한 것이 아니다