<일 잘하는 엔지니어의 생각 기법>, 캐리 밀샙, 장현희 옮김

 

점점 더 많은 사람들이 복잡성complexity을 정교함sophistication이라고 잘못 해석하는 것 같다. 당혹스러운 일이 아닐 수 없다. 뭔가를 이해할 수 없다면 감탄이 아니라 의구심을 가져야 한다. - 니클라우스 비르트Niklaus Wirth

미국 내에서 운항하는 여객기를 인증받으려면 연방항공청(FAA)에서 요구하는, 항공기가 정상적인 운항 중에 마주할 것으로 예상되는 가장 큰 부하의 150%에 해당하는 부하로 날개 탄성 테스트를 통과해야 한다. 하지만 보잉사는 테스트를 실시해 날개가 실제로 부러질 때까지 굽혀볼 것이다. 이렇게 하면 날개에 150% 부하라는 요구사항을 넘어 어느 정도의 여력이 있는지 알 수 있으며, 날개가 부러졌을 때 어떤 일이 발생할지를 엔지니어가 예측하는 수학적 모델을 검증하는 데 필요한 데이터를 제공할 수 있다.
이와 같은 파괴적 테스트를 통해, 의사결정은 더 쉽게 내려질 수 있다. 그리고 더 신뢰할 수 있다.
308쪽

테스트를 프로젝트 마무리 시점에나 수행하는 별도의 단계로 취급하는 것은 좋은 생각이 아니다. 엔지니어가 기능을 구현하는 동안, 테스터는 최선을 다해 결함을 찾아내고 재현할 수 있는 테스트 케이스를 만드는 경쟁적 과정이어야한다. 이런 테스트는 프로젝트가 진행되는 전과정에서 지속적으로 이뤄져야 한다. 새 시스템을 프로젝트 막바지에 한번 돌려보고 모든 기능이 잘 동작하는지를 보여주는 것, 그건 테스트가 아니다. 그건 그저 데모일 뿐이다.
309쪽

 

프로젝트의 초기에 관찰하기를 잘한다면 어떤 문제든 예방할 수 있다. 실제와 같은 데이터 양과 트래픽 강도를 이용해 테스트 시스템을 추구한다면 프로덕션 환경의 문제를 해결할 때 사용하는 것과 동일한 관찰하기 방법론(R 방법론)을 사용할 수 있다.
1. 비즈니스가 해결해야 하는 증상의 목록을 만든다.
2. 증상의 목록을 비즈니스의 우선순위에 따라 재정렬한다.
3. 우선순위가 매겨진 목록의 각 증상 S에 대해
4.  증상 S가 여전히 최우선순위일 경우,
5.    (이상적이라면) 오동작이 발생하는 시점에 증상 S를 관측한다(관찰하라!).
6.    오동작을 유발하는 원인 C를 찾는다.
7.     원인 C에 대한 조치를 통해 증상 S를 해결한다.

프로덕션 환경에서의 문제해결과 마찬가지로, 비즈니스 측면에 대한 이해를 1단계와 2단계에 통합해야 한다. 그리고 이른 단계부터 비즈니스를 이해하는 것은 처음에는 불편하게 느껴질 수도 있지만 테스트의 우선순위를 비즈니스의 우선순위와 맞추는 데는 도움이 된다.
시간이 지나면, 테스트 시스템을 사용하는 사람들은 프로덕션 시스템을 사용할 때와 같은 압박을 자연스럽게 느끼기 시작할 것이다.
"오늘 이 보고서가 상당히 느리게 동작하네요. 어디 변경한 부분이 있나요?"
이상적으로는, 소프트웨어 수명주기의 이른 시점에 테스트 시스템에 충분한 부하를 시뮬레이션해서 실제 서비스를 출시하는 시점에 문제가 없게 하는 것이 좋다.
315쪽

 

재미있는 이야기 하나. 어느 날 밤, 한 남자가 이름 속에서 자동차 열쇠를 잃어버려 한참을 찾고 있었다. 마침 인근을 지나던 친구가 다가와 열쇠 찾기를 도왔다. 몇 분간 함께 찾다가 실마리를 얻고자 한 친구는 남자에게 어디쯤에서 열쇠를 잃어버렸는지를 물었다.
"아, 아마 저쪽에서 떨어뜨린 거 같아."
그러자 친구가 답했다. "근데 왜 여기를 뒤지고 있는 거야?"
남자는 가로등을 가리키며 말했다. "저기는 불빛이 없잖아."
흠, 사람들이란.
여러분이 좀 더 잘 기억하길 바라면서 이 이야기에 양념을 쳐보겠다.
하수구에 빠뜨린 열쇠를 화분에서 찾을 리는 만무하다.
문제를 해결하기 위한 방법이 어렵다면-예컨대 비용이 너무 비싸거 나 시간이 너무 많이 들거나 정치적 위험이 있거나 그냥 불편하거나 등등- 적어도 다음 두 가지는 확실하게 입증해야 한다.

1. 여러분이 제안한 그 어려운 방법이 실제로는 효과가 있다는 것
2. 그보다 더 효과가 있는 방법은 없다는 것

확실한 증거가 없으면(안타깝지만 간혹 확실한 증거가 있어도) 사람들은 매번 쉬운 길을 택할 것이다. 하지만 말도 되지 않는 것 같은 해결책이 실질적인 유일한 해결책이라면 다른 방법을 시도하는 것은 그냥 시간 낭비일 뿐이다. 열쇠를 하수구에 빠뜨렸다면 일찌감치 장갑을 끼고 하수구를 뒤지는 것이 열쇠를 더 빨리 찾게 되는 길이다.
증명은 여러분의 평판에도 중요하다. 사람들이 하수구를 뒤지도록 설득했다면 우리가 찾으려는 열쇠는 반드시 거기에 있어야 한다. 따라서 증명은 주변 사람이 정확한 정보를 토대로 결정을 내리는 것을 도울 뿐만 아니라 조언자로서 여러분의 신뢰를 보호하는 데도 도움이 된다.
331쪽

 

"미리 말씀드리는데요. 여러분의 견해에 x를 하는 것이 권장된다면 그런 일은 절대로 없을 겁니다"라는 말을 들어본 것이 있을 것이다. 그렇다면 분석 결과에 의거해서 (1) x를 통해 회사가 가장 우선순위를 두는 실행 시간이 1시간에서 1초로 줄어들 것이며 (2) x 외에는 그만큼의 개선을 이루는 방법이 없다고 판단된다면, 여러분은 어떻게 하겠는가?

더 심한 관료주의, 더 많은 정책, 더 많은 이해관계자. 시스템의 단일 책임 결정에 대한 어려움 등은 프로젝트의 위험을 증가시킨다. 더 많은 분권화, 더 많은 자유, 더 책임지려는 의지가 있어야만, 위험은 감소한다.
326쪽

 

내 동료 안조 콜크는 성능 문제의 90%는 정치적인 문제이고 10%만이 기술적인 문제라고 했다. 안조의 세계관은 일본에서 장기간 프로젝트를 수행한 경험에서 영향을 받았다. 일본은 문화적으로 체면이 강조되는 국가다. 어떤 문화에서든 함께 일하는 이들의 명예와 평판을 존중하는 것은 중요하다. 여러분이 뭔가를 고친다는 것은 곧 다른 누군가가 일을 망쳤다는 암시를 만들어낼 수 있음을 깨달아야 한다. 어떤 문화에서는 이로 인한 고통이 참을 수 없을 정도로 클 때도 있다.
주로 내가 프로젝트를 수행했던 미국의 기업 문화는 감정보다는 사실을 존중하는 것이 일반적이지만, 실패를 대하는 태도 또한 다양하다. 어떤 회사는 충분히 대담한 길을 가는 과정에서 실패는 불가피한 단계라고 받아들이기도 하지만, 어떤 대가를 치르더라도 비난을 피하는 것을 최우선시하는 회사도 있다.
(안조의 고향인) 네덜란드의 문화는, 나도 동의하는 편인데, 아무리 뼈를 때리더라도 사실을 말해주는 것을 중시한다. 물론 일장일단이 있다. 네덜란드 사람들의 솔직함은 명쾌하지만, 옷을 잔뜩 껴입은 나만 방에서 덥다고 느낄 때 "빌어먹을 스웨터 좀 벗어"라는 네덜란드인의 말에도 기분이 나빠지지 않도록 계속 스스로를 다스려야 한다. 그리고 핵심을 너무 주저리주저리 말하면 네덜란드인들의 인내심은 쉽게 바닥난다는 점도 기억해야 한다.
솔직함에는 책임감이 필요하다. 효과적인 솔직함이란 단순히 떠오르는 모든 생각을 여과 없이 내뱉는 것이 아니라 사실이 무엇인지를 신중하게 판단한 후에 사실을 말하는 것이다. 그러니 내 주변 사람들이 멍청이라고 단언해서는 안 된다. 진짜 사실(과 더 유용한 발견점)은 이 모든 사람이 자신이 배운 대로 정확히 하고 있는 것인지도 모른다.
여러 문화적, 정치적 장애에도 불구하고 성공하기 위한 스킬을 개발하는 데 도움이 되는 자료는 많다. 내가 특히 권장하는 자료는 다음과 같다.
• 위키피디아의 승무원 자원 관리 문서. 이 문서에 따르면, 1970년대에 항공업계에서 발생했던 일련의 사고 중 기술적인 문제가 아니라 의사소통, 리더십, 의사결정 문제에서 비롯된 것이었음이 드러났다. 이에 대한 효과적인 대응이 바로 CRM이다. 나는 의사소통, 리더십, 의사결정 문제가 정치적 문제의 전형적인 예시라고 생각한다.
345쪽