가끔은 소프트웨어도 둥글다

 얼마 전 중국의 우주 정거장이었던 텐궁이 다행히 인명피해를 주지 않고 대서양에 추락했습니다. 추락하기 2일 전부터 뉴스에선 우주 위기 위험경보를 알리며 텐궁이 곧 지구에 추락하겠으나 아직 위치는 알 수 없으며 시간은 몇 시께라고 모호한 답변을 내놨습니다. 대기오염뿐만 아니라 이제는 우주에서도 말썽을 부리는 중국을 원망하면서도 한 가지 의문이 들었습니다. 인공지능이 바둑을 이기는 시대인데 어째서 위성 추락 지점 하나 제대로 계산을 못하는 거지? 물론 시속 20,000KM일 정도로 빠르고 변화무쌍한 날씨 외에도 여러 가지 요인에 영향을 많이 받을 수 있으니 그럴 수도 있다고 칩시다, 그런데 추락 12시간 전까지도 여전히 정확한 추락 지점을 예측하지 못하고 다행히 우리나라에 떨어지진 않는다라는 짧은 답변만 내놓았죠. 아니 이건 너무 심한 거 아닙니까? 인명 피해가 발생할 수도 있는 시급한 상황인데 아직도 예측만 하고 있다니요!

그림 1. 텐궁 추락 예상 그림

날카롭게 비판을 했지만 한편으론 찔리기도 합니다. 제대로 예측하지 못하는 건 텐궁 추락 지점뿐만 아니라 소프트웨어도 그렇거든요. 사실 소프트웨어는 간단한 실수로 인해 천문학적 비용이 발생한 유구한 역사를 가지고 있습니다. 1996년 유럽이 2000년대 세계상업위성시장 석권을 위해 야심 차게 내놓았던 위성 적재 로켓 아리안 5호는 발사 1분도 안돼 공중 폭발했었습니다. 유럽도 인간을 우주에 보낼 수 있다는 꿈을 안고 프랑스를 주축으로 유럽 12개국이 약 6조 7천억 원을 투자했는데 1분도 안돼서 꿈이 산산조각이 난 셈입니다. 그런데 손해액과 자존심에 금이 간 것에 비해서 원인은 참 간단했습니다. 바로 전 모델인 아리안 4호의 로켓 항법 장치 코드를 그래도 옮겨왔는데 이 코드에서 64비트 Double형 값을 16비트로 받아 Overflow가 일어난 것이 문제였습니다. 이 정도 실수는 처음 소프트웨어를 배우신 분들이 주로 저지르는 실수입니다. 세계 최고의 전문가들이 이런 실수를 했다는 게 아이러니하죠?

그림 2. 아리안 5호 폭발. 10년의 노력이 물거품이 되는데는 48초면 충분했습니다.

2014년 급발진 문제로 기업 역사상 최대 위기를 맞은 도요타도 SW 결함이 원인이었습니다. SW 컴포넌트 간에 정보를 전달하기 위해 ECU(차량 내 CPU로 보면 됩니다) 내의 메모리 영역에서 공유 메모리 기능을 사용하는 도중 특정 지점에 간섭 현상이 일어났고 이것이 잘못된 지시로 이어져 급발진이 일어나게 된 것이죠. 공유 메모리를 사용할 때는 Lock을 이용해 간섭을 배제하는 것이 원칙이라고 운영체제를 수강한 학부생이라면 기본적으로 알고 있는데 어떻게 이런 실수를 저지를 수 있었을까요? 그것도 사람 생명을 위협할 수 있는 자동차 소프트웨어에서 말이죠.

그림 3. 오랜시간 발뺌한 것에 비하면 1조 2천억원은 관대한 벌금입니다

+) NASA 엔지니어까지 매수하며 끝까지 발뺌하던 도요타는 결함을 시인했고 당시 자동차업체 역사상 최고의 벌금인 12억 달러(약 1조 3천억원)를 물게 됐습니다. 

일반인들의 눈에는 이런 실수를 한 기업들은 바X, 멍X이 정도로 보일 것입니다. 결함의 원인이 전문적인 지식이 필요한 것이 아니라 기본적인 원칙을 준수하지 못해서 발생한 것이었으니까요. 나라면 저 정도 실수는 하지 않을 것이라고 생각합니다. 정말 그럴까요? 한번 만들어 봅시다. 버스 터미널이나 열차 역에 설치된 무인 티켓 발매기의 소프트웨어를 만든다고 해보죠. 예상 시나리오는 간단합니다. 사용자가 원하는 목적지를 선택하고 신용카드를 이용해 결제를 한 후 티켓과 영수증을 출력해주는 시스템을 만든다고 해봅시다. 개발의 편의를 위해 현금을 받는 경우는 제외합시다. 목적지 정보와 비용 데이터 베이스, 유저 인터페이스는 이미 개발된 상태고 카드사들과 결제 시스템도 이미 연계돼있습니다. 우리가 할 일은 각 모듈을 연결시켜 무인 발매기 안에 넣고 혹시 모를 예외 상황에 대해서 처리를 해주기만 하면 됩니다. 어떤 예외상황들이 있을까요?

유효기간이 지난 신용카드를 사용한다거나 목적지 버튼을 누른 후 오랜 시간 동안 결제를 하지 않는 경우에 대한 예외 처리는 자주 나오는 답변 중에 하나입니다. 그런데 혹시 티켓과 영수증은 생각해보셨나요? 만약 결제를 다 했는데 용지랑 잉크가 없다면 어떻게 해야 할까요? 이건 소프트웨어가 처리할 일이 아니라고 하시면 곤란합니다. 지금 용지와 잉크가 부족하니 역무원을 불러오라고 디스플레이에 출력하던지 아니면 사전에 결제를 막던지 했어야 합니다. 아무런 처리도 하지 않는다면 사용자는 비용은 지불했고 승차 시간은 5분밖에 남지 않았는데 버스표는 나오지 않는 매우 난감한 상황에 처하게 됩니다. 명절처럼 버스표가 대부분 매진일 때를 생각해보면 매우 아찔하네요. 빗발친 민원을 감당한 역무원은 분노에 찬 얼굴로 손해 비용을 청구할 것입니다. 그리고 만든 개발자의 신뢰는 추락할 겁니다.

경력이 5-6년이 넘은 소프트웨어 개발자도 잉크와 프린트가 없는 경우에 대해선 예측하지 못했습니다. 이분들은 업계에선 꽤 유능하다고 인정받던 분들이었습니다. 이 사례가 의미하는 바는 명료합니다. '똑똑한 사람도 모든 경우를 예측할 수는 없다'는 것입니다. 법을 만들고 시행하는 엘리트 공무원들도 미꾸라지 같은 편법까지 막지 못하는 것처럼 소프트웨어 개발자도 모든 예외 상황을 막지 못합니다. 가끔은 소프트웨어는 물 샐 틈 없이 꼼꼼히 막아놨다고 생각했는데 어딘가에서 물이 새고 있는 배와 같기도 합니다. 만들기 전에 튼튼히 설계를 하고 운행 중 문제가 생기면 최대한 빨리 구멍을 막는 것 또한 중요합니다. 윈도우 업데이트도 예측하지 못했던 구멍을 메우는 작업과 같습니다.

그림 4. 제 PC에 설치된 윈도우 업데이트 

'공은 둥글다'는 표현은 공이 어디로 튈지 모르기 때문에 압도적인 전력을 가진 팀도 승리를 보장 할 수 없다는 뜻으로 쓰입니다. 전 무슨 일이든 완벽히 예측 할 순 없다는 점을 빌려 이 표현을 소프트웨어에도 적용할 수 있을 것 같습니다. 하지만 완벽한 소프트웨어를 만들려는 개발자들의 노력을 생각해 사족 한마디만 덧붙이겠습니다.

가끔은 소프트웨어도 둥글다

아래의 링크에서 사진과 자료를 가져왔습니다

1. "도요타 급발진은 SW 결함이 원인" 도요타 조사 보고서 파장, http://www.etnews.com/20140320000188?rccode=lvRc, 

2. 도요타 리콜 사태 - 나무위키 https://namu.wiki/w/%ED%86%A0%EC%9A%94%ED%83%80%20%EB%A6%AC%EC%BD%9C%20%EC%82%AC%ED%83%9C

3. 아리안5호 로켓 발사실패 따른 파장, http://news.joins.com/article/3279252

4. 지구로 추락중인 중국의 우주정거장 '텐궁1호' http://principlesofknowledge.kr/archives/54310

5. 토요타, '급발진' 1조 2천억원 보상 합의 http://mn.kbs.co.kr/news/view.do?ncd=2588592