2018년 10월 29일 자카르타, 인도네시아에서 팡칼핀랑, 인도네시아로 가는 737 MAX 8 편 Lion Air Flight 610편이 이륙 후 13분만에 바다로 추락하여 승객 189명이 전원 사망했습니다. 추락의 정확한 원인에 대한 조사는 진행 중이지만, 조사관들은 기체가 공속, 고도 및 공격각 센서의 읽기에 의존하여 위험을 피하기 위해 비정상적으로 명령을 활성화했을 가능성이 있다고 믿고 있습니다.
2019년 3월 10일, 이티오피아 항공 302편도 737 MAX 8편으로 비슷한 상황에서 추락하여 승객 157명이 전원 사망했습니다. 302편도 가능한 비정상적인 비행기< 노즈 다운(Aircraft Nose Down) > 명령을 보고했습니다. 위키백과에 따르면:
2차 사고 후 보잉 737 Max는 전 세계적으로 운항 중단되었고, 회사의 시장 가치가 하룻밤에 거의 $60억 달러가 소멸되었습니다.
단기적 영향은 시작에 불과해요. 하지만 보잉이 위기를 효과적으로 해결하지 못하고 대중 신뢰를 회복하지 못하면 장기적으로 회사의 안정성에 실질적인 영향을 미칠 수 있어요. 골드만 삭스에 따르면, 보잉 737 판매는 다음 5년 동안 보잉의 예상 판매의 33%를 차지하고 있어요.
좋은 소식은 CNN 비즈니스에 발언한 한 보잉 관계자에 따르면:
MCAS 시스템이 실패할 수 있어서 비행기를 급격한 코끼리 코끼리로 보내 비행사들이 회복할 수 없는 상황에 몰리는 것으로 보여요.
이 결함이 소프트웨어인지 마이크로프로세서 하드웨어인지는 알 수 없지만, 생명에 대단히 중요한 시스템의 컴퓨팅 시스템 장애예요. 일반적으로 이와 같은 시스템의 경우에는 품질 통제를 보장하기 위해 많은 방어선을 활용하는 것이 일반적이에요.
소프트웨어 개발에서 일반적인 방어 수단에는 다음이 있습니다:
- 요구사항 수집
- 요구사항 명세 및 검토
- 위험 분석
- 테스트 주도 개발 (TDD)
- 소프트웨어 Linting
- 정적 분석
- 소프트웨어 검토 / 코드 리뷰
- 모델 시뮬레이션
- 형식적 방법
- 인수 테스트
저는 수백만 명의 사용자를 위한 비생명 중요 시스템을 다루는 소비자 애플리케이션을 주로 작성합니다. 최근 이끌고 또는 참여한 모든 팀은 요구사항 수집 시스템, 명세 검토 (동료 검토와 함께 기술적 Readme 중심 개발 사용), TDD, 제품 시뮬레이션(지속적 통합/지속적 배포를 이용한 프로덕션 시뮬레이션) 사용 등을 사용하여 소프트웨어가 프로덕션 환경에서 작동할 것을 보장하고 있습니다. 린팅, 정적 분석, 코드 리뷰 (소프트웨어 검토의 정리된 버전) 및 인수 테스트도 사용합니다.
우리는 소프트웨어 품질에 큰 비중을 두고 있으며, 세계 어디에 사는지에 상관없이 심지어 우리의 초급 엔지니어들에게도 최소한 1억원/년을 지불하여 최고의 소프트웨어 엔지니어를 유치하여 유지보수가 쉬운 고품질의 소프트웨어를 만들 수 있도록 노력하고 있습니다.
저희는 주니어 개발자들을 고용하지만 항상 시니어 레벨 엔지니어가 충분하게 있어 멘토십, 코드 리뷰 및 지원을 제공합니다. 또한 모든 엔지니어가 신뢰할 수 있는 소프트웨어 시스템을 구축하는 데 필요한 이해를 얻을 수 있도록 교육 및 멘토십에 많은 투자를 합니다.
생명에 치명적인 시스템을 책임질 경우, 품질에 더욱 집중하고 보다 철저한 교육, 멘토십, 요구 사항 수집, 위험 평가, 소프트웨어 검사 (예: NASA의 Power of 10 규칙을 코드 검사 체크리스트로 사용하는 것과 같은 언어 관련 데이터를 기반으로 한 변형), 정적 분석 및 심지어 크리티컬 시스템을 위한 형식적인 방법을 추가하여 우리의 알고리즘들이 올바르게 명시되었음을 수학적으로 증명할 것입니다.
보잉의 예산이 있었다면, 프로그래밍 언어 선택이 차이를 만들 수 있는지 연구하는 것에도 투자할 것입니다. 제 경험상, 이미 언급한 멘토십 및 다른 품질 조치에 투자하는 것이 언어 선택보다 훨씬 더 큰 영향을 미칩니다만, 생명에 치명적인 시스템에서 약간이라도 결함 가능성을 줄일 수 있는 데이터에 기반한 결정은 삶과 죽음을 가를 수 있습니다. 우리는 소프트웨어 품질에 대해 더 나은 연구가 필요하며, 2000억 달러 이상의 시가총액을 보호해야 하는 상황에서 Boeing에게 이러한 연구를 지원하는 것이 당연한 선택이라고 생각할 것입니다.
우리는 소프트웨어 품질에 크게 투자하는 이유가 우리 팀이 큰 예산을 가지고 있기 때문은 아닙니다 (Boeing의 엔지니어링 예산과 비교하면 물방울에 불과합니다). 우리는 소프트웨어 품질에 대한 투자가 더 나은 속도로 전진하고 장기적으로 비용을 절약할 수 있기 때문에 크게 투자합니다.
빠르면 느리고 저렴하면 비싸다, 그래서 왜 그렇게 많은 매니저들이 저렴하게 하는 걸까요?
비용을 절감하기 위해, 엔지니어링 매니저들은 종종 개발자들을 서두르게 하거나 임의로 현실적이지 못한 마감일을 부여하거나, Boeing의 경우처럼, 생산 대역폭을 늘리려고 싼 계약업체에 엔지니어링을 아웃소싱하는 등의 조치를 취합니다.
Boeing의 비용 절감에 대한 문화적 강조가 737에 작업 중인 엔지니어들에게 온두라온 것으로 보입니다. Boeing이 아웃소싱한 인도 회사 HCL의 737 계약 소프트웨어 엔지니어 중 한 명은 그 비용 절감 문화를 이력서에 보여주며 설명하고 있습니다.
어떤 시스템을 작업하든, 개발자들이 경영진이 지속적인 진전과 고품질 소프트웨어보다 속도와 저렴함을 가치 있다고 느끼도록하는 엔지니어링 문화를 조성한다면, 그것은 소프트웨어의 품질과 제때 배송에 엄청난 부정적 영향을 미칠 것입니다. 결함 있는 소프트웨어는 더 많은 시간이 소요됩니다.
경영진이 비용 절감을 과도하게 강조하면 개발자들이 서둘러야 한다고 느낍니다. 개발자들이 서둘러야 할 때:
- 멘토링과 코드 리뷰가 중단됩니다
- 버그가 쌓입니다
- 테스트가 건너뛰어집니다
- 커뮤니케이션이 떨어집니다
- 개발자들이 지치게 됩니다
- 생산성이 저하됩니다
보잉 737 맥스를 지원하는 보잉 비행 시험 그룹에서 일한 마크 라빈은 HCL에 공학 업무를 외주하는 결정이 보잉 엔지니어가 코드를 직접 작성하는 것보다 효율적이지 않았기 때문에 '논란이 많았다'고 블룸버그에 전했습니다. "코드가 올바르게 작성되지 않았기 때문에 여러 라운드의 피드백이 이뤄졌습니다."
라빈에 따르면, 한 명의 매니저가 모든 직원을 대상으로 한 회의에서 "보잉 제품이 성숙했기 때문에 시니어 엔지니어가 필요하지 않다"고 발언했습니다. 그 에피소드가 바로 이 기사를 쓰게 된 계기입니다. 의심이 생기더라도, 주니어 엔지니어들이 시니어 엔지니어의 검토와 지도 없이 코드를 작성한다면, 코드 베이스 전체에 시한폭탄을 설치하는 것과 같습니다.
공학 분야에서는 빠르다는 것이 느리다는 뜻이며, 싼 것이 비싸다는 뜻입니다.
“느리다는 빠르다”라는 문구는 공학 분야에서 잘 알려진 말입니다. 군대 용어인 “느린 것이 부드럽고 부드러운 것이 빠르다”에서 시작되었으며, 이는 상식적인 이치의 한 형태입니다. 모두가 그것이 사실임을 알고 있지만, 특히 압박을 받을 때 이것을 실천하는 데 능숙한 기업은 매우 드뭅니다.
보잉은 경쟁사인 에어버스로부터 심각한 경쟁 위협을 받았습니다. 2010년, 에어버스는 연료 효율성이 7% 더 뛰어난 새로운 A320neo를 발표하였으며, 해당 모델은 보잉 737의 전년도 판매량보다 한 주 동안에 더 많이 팔렸습니다.
보잉은 신속하게 대응해야 했습니다. 항공사에게 유력한 옵션을 제공하기 위해, 그들은 새로운 플랫폼을 처음부터 설계하는 시간을 절약하고, 1960년대부터 이어져 온 이전 모델들과 유사한 컨트롤 및 계측 장치를 갖춘 유산 플랫폼에 기반을 두기로 결정했습니다. 이 선택은 많은 변경을 가하면 조종사들을 재인증해야 하는 항공사들에게 중요한 판매 포인트가 되었습니다. 이는 심각한 공학적 과제가 될 것입니다.
에어버스와의 격차를 벌리지 않으려고, 보잉은 에어버스가 A320neo를 출하한 지 몇 달 후에 새로운 737을 출시하려고 결정했습니다. 새 모델을 제공할 시간이 6년이 주어졌는데, 이는 787과 777을 출하하는 데 걸린 시간을 1년 이상 단축시키는 결과였죠.
다시 말해, 보잉은 낙관적인 기한으로 프로젝트를 시작했지만 비전을 가지고 달성하기로 결심했습니다. 프로젝트 관리 삼각형의 모든 제약 사항을 정리하기 전에 시작하기로 했어요.
범위는 경쟁사에 의해 미리 설정된 야심찬 공학 목표들로 제한되어 있었습니다. 시간은 에어버스에게 기본 승리를 내주지 않기 위해 미리 제한되었구요. 따라서 프로젝트의 품질을 보장하기 위한 마지막 수단은 프로젝트에 충분한 예산이 할당되었음을 확신하는 것이었습니다. 하지만 보잉의 문화는 이미 예산 절감을 요구하는 방향으로 고정되어 있었습니다. 희생될 수 있는 유일한 것은 품질이었습니다.
비용 절감 문화의 문제는 보잉과 같은 기업들이 이에 광신적으로 몰두하여 최종적으로는 그들이 절약한 것보다 훨씬 많은 비용을 들게 되는 것입니다. 보잉의 737 맥스 프로젝트의 초기 예산은 30억 달러였습니다. 시간을 절약하고 돈을 아끼기 위한 노력들에도 불구하고, 그들은 예산을 수십 억 달러나 초과하고 늦게 제품을 출시하게 되었습니다.
이후 발생한 재앙은 시장가치 수십 억 달러를 손해보게 만들었으며, 항공사 주문 취소 위협으로 300억 달러의 손실을 입게 했으며, 보잉 브랜드에도 상당한 피해를 끼쳤습니다. 더 나은 공학 관행을 따르기 위해 수십억 달러 더 투자할 수 있었고, 그럼에도 훨씬 더 발전된 상황에서 이득을 볼 수 있었을 것입니다.
이 모든 것은 모든 소프트웨어 매니저와 엔지니어들에게 좋은 교훈입니다: 소프트웨어에서 빠르다고 해서 항상 좋은 것은 아니며, 저렴하다고 해서 항상 비용이 싸지는 것도 아닙니다.
비용 절감에 과도하게 집착하지 않았다면 보잉에게 큰 승리가 될 수 있었던 것이 대신 비용 절감에 집착하여 보잉 브랜드에 큰 타격을 입히는 대형 재앙으로 변했습니다.
보잉의 실수를 되풀이하지 마세요.
자바스크립트 개발자를 위한 관련 기사
만약 여러분이 자바스크립트 개발자라면, 다음 리소스들이 소프트웨어 품질 과정을 향상하는 데 도움이 될 수 있습니다:
- TDD가 내 삶을 바꿨다
- TDD Day - TDD 훈련을 위한 하루
- ES Lint와 Prettier로 코드 리뷰 간소화하기
- 균형 잡힌 개발 팀 구축을 위한 필수 가이드
에릭 엘리엇은 기술 제품 및 플랫폼 고문으로, "Composing Software"의 저자이자 EricElliottJS.com 및 DevAnywhere.io의 공동 창립자이며 개발팀 멘토입니다. 그는 Adobe Systems, Zumba Fitness, 월스트리트 저널, ESPN, BBC 및 Usher, Frank Ocean, Metallica를 포함한 세계적인 음악가들을 위한 소프트웨어 경험에 기여했습니다.
그는 세계에서 가장 아름다운 여성과 함께 원격 생활을 즐깁니다.