일 잘하는 엔지니어의 생각 기법, Back to the basic.

2002년 대한민국이 월드컵 4강으로 뜨거웠을 때. 제가 개발하던 MPH-2000 (삼성 최후의 PDA 핸드폰) 기반의 삼성전자 물류서비스 앱이 전국의 물류센터에 배포가 되었습니다. 일반 가정에서 전자제품을 주문하면, 물류 배송 기사들이 배송을 완료하고 송장을 폰으로 확인하고, 처리 결과를 전송하면 데이터가 처리되는 시스템이었죠. 당시 휴대폰에는 GPS 기능이 없었기 때문에 기지국 정보로 배송 위치를 추정하고, 배송 완료 시간을 기록해서 물류 정보에 통합하는 것만으로도 획기적이었습니다. 

 

삼성 SPH-M2000 당시엔 획기적인 폰으로 터치펜 기능도 가진 풀터치 플립형 디자인이 주목받았다 < 사진 : 창원 통신박물관 - 네이버 블로그 >

 

그런데, 당시에는 매우 심각한 문제가 하나 있었습니다. ARM 기반의 별도 버전의 gcc로 개발한(뭔지 몰라도 그냥 매우 생소한 프로그래밍 언어라고 생각하시면 됩니다.) 라이브러리에서 Memory Leak이 아주 미세하게 발생하고 있었지만, 그걸 개발한 종합연구소의 박사님도, 그걸 기반으로 앱을 만든 저도 원인을 밝혀낼 방법이 없었습니다. 프로그램에서 쌓인 메모리의 피로감은 점점 앱을 느려지게 만들었고, 두 달 정도 지나면 폰이 느려지기 시작했어요. 결국 폰이 너무 느려져서 앱 실행조차 힘들다는 문의가 들어오기 시작했고요. 회사에서는 후속 기종 개발이나 라이브러리 업데이트 계획이 없었으니, 회사의 향후 지원도 없을 예정이었습니다. 

 

가장 즉각적인 조치 방법은 폰을 한 번 껐다 켜는 거였습니다. 컴퓨터가 제대로 동작하지 않으면, 껐다 켜는 것이 해답일 때도 있다는 것이 바로 이런 방법이죠. (당시 메모리가 256kb 밖에 안되었던 폰을 껐다켜면, 메모리가 깔끔하게 비워졌다.) 그렇지만, 고객사에 프로그램의 문제인데, 당장 고칠 방법이 없으니 껐다 켜면 된다고 말할 수는 없는 노릇이었습니다. 그런 와중에 고객사에서 고객 사인을 터치펜으로 받아서 전송하는 기능을 추가해달라는 요청이 왔어요. 그 때, 번뜩하고 떠오른 생각이 있었습니다. 당시 피처폰들은 OS와 하드웨어의 구조상 메모리와 프로세서가 제한적이라서, 새로운 앱을 메로리에 로딩하기 위해서 반드시 재부팅을 해야했거든요. 

 

그러니까, 정리하자면 폰에 메모리가 가득차서 느려지기 시작하는건 2달이 걸리고, 제가 새로운 기능을 2달에 한 번씩 추가해서 앱을 배포하면 고객은 자연스럽게 폰을 껐다 켜게 된다는 거였습니다. 물론, 새로운 기능을 추가로 넣는 것이 어렵기는 했지만, 해결할 수 없는 문제를 손쉽게 해결하는 최선이었죠. 1년 반 정도의 시간 동안 새로운 부가 기능을 6개를 만들어서, 버전 6까지의 앱 업그레이드가 이뤄졌습니다.

 

배송기사도 만족하는 2개월 마다의 업그레이드 덕분에 해결할 수 없는 문제를 회피할 수 있었다. < 사진 : Gemini >

 

결국, 고객인 물류배송기사 분들은 새로운 버전으로 앱을 설치할 때마다 속도가 점점 빨라지고, 기능도 늘어난다며 만족도가 오히려 높아졌습니다. 새로운 산업용 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의 차이는 생각보다 월등한 차이다. < 출처 : 해당 도서 >

 

 

 

주인공은 본부장에게 99.99%의 가용성은 해결했지만 합리적인 비용에 99.999%를 달성할 수 있는 아키텍처를 만들 방법이 없다고 설명했어요. 그러자, IT본부장인 더그는 비용이 얼마나 드는지 물었고, 고민하다 주저없이 "좋아요. 99.99%면 충분합니다."라고 답했고, 그걸로 회의는 끝났습니다. 물론, 이 챕터의 교훈은 '피드백 루프를 최대한 빨리 가동하자'는 것이었지만, 큰 의미에서 저는 이걸 문제 해결 방식의 선택이 중요하다고 봤습니다. 

 

해결할 수 없는 문제를 붙잡고 시간을 보내기 보다는 가장 빠른 방법이 무엇인지, 의사결정자가 누구인지를 통해 고객의 문제를 해결하는데 집중하는 것이 어쩌면 중요하거든요. 

 

 

은 탄환(Silver Bullet)으로 모든 문제를 해결한다는 환상

여러분들은 저의 일화에서 중요한 것은 바로 메모리 누수 현상을 잡아 내서, 근본 원인을 해결하는 것이라고 생각했을지 모릅니다. 그러나, 그것은 원인이지 문제가 아닙니다. 문제는 고객의 배송 앱이 점점 느려지고 있는 문제였고, 현장에서 배송을 완료하도고 완료 처리를 할 수 없는 것이 문제였습니다. 즉, 배송 완료만 빨리 처리할 수 있다면, 꼭 메모리 누수를 잡아내야 할 필요는 없었겠죠. (실제로는 매일 한 번씩은 스마트폰을 껐다 켜달라는 안내를 할 수 없는 회사의 분위기가 더 문제라는데는 동의합니다.)

 

많은 엔지니어들이 빠지는 환상이자, 큰(?) 숙제는 바로 한 방에 모든 문제를 풀어 낼 알렉산더 대왕의 가위처럼, 은 탄환이라는 해결책이 존재한다고 믿는 것입니다. 그걸 발견할 때까지, 여러 번의 반복과 조사, 연구를 해내려고 하죠. 그렇지만, 엔지니어에게 중요한 것은 문제를 정확히 관찰하고, 측정한 다음, 개선하는 것이겠으나, 제일 중요한 것은 문제를 정의하는 것입니다. 

 

제대로 된 문제 인식 없이 은 탄환을 바라기만 하는 것은 환상에 가깝습니다. < 사진 : Gemini >

 

 

 

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

 

이 책은 실제 현장에서 간과하기 쉬운 '화장실에 쌓여있던 출력물', 'ERP 화면에서 업체를 찾기 위해 다음 페이지 버튼을 26번 누른 회계 직원', '최종 청구서 발행 이후 청구서만 출력의 체크박스를 체크하지 않아 수십 박스의 종이를 낭비한 직원' 들의 이야기를 늘어놓으면서, 그런 가르침을 차곡차곡 쌓아서 머리에 강제 주입시키는 책입니다. 고객을 관찰하고, 고객의 우선 순위를 나의 우선 순위에 맞추며, 근본적인 질문부터 가슴에 새기도록 만드는 책이랄까요?

 

이런 꿈도 꾸었을 정도로 책에 빠져들었어요. 'Jet Brains IDE에서 TAB키를 여기서 누르면, 테스트 결과코드를 미리 여기 삽입할 수 있으니 시간이 20분 정도 줄었던 경험을 회사 전체 개발자들이 알게 된다면 얼마의 시간이 줄어들까? 무려 1만분 정도의 시간이 생기는 거잖아? 누구나 줄일 수 있는 이벤트의 수행시간은 일상에도 있는 거였어'라는 꿈을 꾼 겁니다. (직업  의식이 이렇게 무섭습니다.)

 

은 탄환으로 모든 문제를 해결하기 보다, 하나씩 문제를 맞닥뜨리고 해결해 나가는데 이 책은 중요한 지침 중의 하나가 되지 않을까 싶습니다. 

 

참고로 이 책을 한 권 샀는데, Yes24 서평단에 당첨되면서 덜컥 책이 2권이 되었습니다. (한 권은 우리 개발자 줘야겠어요. ^^)

 

덜컥 2권이 되어버린.. 두껍다고 생각할지 모르지만 차트만 무시하면 금세 읽힌다. < 사진 : From me >