하트블리드와 오픈소스

4월의 일이니까 한참 지난 얘기지만, 그래도 한 번 쯤 정리하고 넘어가야 할 것 같다. 하트블리드 얘기 말이다. 처음에는 너무나 간단해서 누구도 눈치채지 못했던.
그러니까 올해 상반기 세계를 떠들석하게 했던 이 보안 오류는 기술이 세계를 지배한 21세기형 ‘공유지의 비극’이라고 할 만 했다. 2014년 4월1일, 핀란드의 작은 보안회사 코데노미콘은 세계에서 가장 널리 쓰이는 보안 기술인 OpenSSL에 심각한 결함이 있다고 발표했다. 마치 만우절 장난처럼 보였다. 그도 그럴 것이 OpenSSL은 구글과 페이스북 같은 세계 최대 인터넷 기업들부터 은행과 보험사 같은 금융회사까지 보편적으로 사용했던 세계에서 가장 널리 쓰이던 보안 기술이었기 때문이다.

OpenSSL의 원리는 간단하다. 인터넷을 통해 오가는 모든 정보를 암호로 바꿔놓는 것이다. 예를 들어 보내는 쪽이 “1234”라는 문자를 보내려 한다면 이를 1234 대신 4567로 보내는 식이다. 그러면 받는 쪽은 받은 숫자 각각에서 3을 빼라는 암호해독 키를 갖고 이를 1234라고 해석한다. 실제 작동 방식은 이보다 훨씬 복잡하지만, 대충 말하자면 원리는 이렇다. 그런데 문제는 이런 문자를 주고받지 않을 때다. 예를 들어 사용자가 은행 사이트에 접속해 아무 것도 입력하지 않아도 은행은 계속 접속상태를 확인해야 한다. 그래야 5분 동안 아무 입력이 없다는 걸 확인해 접속을 종료할 수도 있고, 사용자가 잠시 다른 일을 하다가 돌아와서 전에 하던 일을 이어서 해도 이게 새 접속이 아니라 기존 일의 연장이란 걸 파악할 수 있다. 이 때 사용하던 기술이 ‘하트비트’(Heart Beat), 즉 심장박동이란 기술이다. 일단 연결된 사용자 컴퓨터와 웹사이트 서버는 사용자의 입력없이도 끊임없이 서로 아주 적은 양의 문자를 주고받으며 접속 여부를 확인하는 것이다.

보통은 서버가 몇 글자 정도를 요구한다. “아직 접속중이라면 ‘ABC’라는 문자 세개를 나한테 보내봐”라는 식이다. 하트블리드는 이 과정에서 생긴 버그다. 즉 “ABC라는 문자 세개를 보내봐”라는 말 대신 “1234라는 문자 ‘500개’를 보내봐”라고 잘못된 명령을 하는 것이다. 그러면 서버는 통신을 유지하기 위해 3개의 문자만 보내면 되는데도 바보처럼 4번째부터 500번째까지의 문자 497개를 더 보낸다. 아무 거나. 그러다보니 이 뒤에 괜히 더 보내는 문자 속에 사용자가 입력한 암호, 신용카드 정보, 대화창에 입력한 비밀대화 등이 끼어 있을 수 있다.

애초에 이 버그가 생긴 건 2011년 12월31일밤 11시59분. 그리고 세상에 공개된 건 2014년 4월1일이다. 만 2년 3개월 이상 이 버그가 유지됐던 셈이니 문제는 심각했다. 피해대상도 광범위했다. 페이스북, 구글, 야후가 자신들의 OpenSSL 취약점을 인정했고, 안드로이드 운영체제(OS) 4.1 이하 버전을 사용하는 구형 스마트폰도 위험에 빠졌다. 또한 수많은 금융회사의 온라인 서비스도 그대로 정보유출 위험에 노출돼 있음을 인정할 수밖에 없었다.

심지어 이렇게 피해를 입은 서버 가운데 상당수가 공신력 있다는 인증기관에서 안전한 서비스로 인증 받은 서버였다. 보안업계에서는 이런 안전 인증을 받은 서버 가운데 약 17%(약 50만대)가 위험에 노출됐다고 추정한다. 한마디로 역사상 최악의 보안 사고였던 셈이다. 하지만 이 폭풍을 피해갔던 서비스도 있는데, 서버가 어떤 운영체제를 사용하느냐에 따라 희비가 갈렸다.

대표적으로 애플은 하트블리드 사태의 영향을 거의 받지 않았다. 애플은 4월10일 자신들의 서비스가 안전하다고 공언했다. 2012년부터 OpenSSL이 불안정하다며 사용하지 않았기 때문이다. 누구나 무료로 사용할 수 있던 공개 소프트웨어였던 OpenSSL을 쓰지 않겠다며 거부한 애플을 두고 개발자들은 “역시 애플은 폐쇄적인 회사”, “자신들이 모든 걸 통제하려 든다” 등의 비난을 쏟아냈다. 하지만 결과적으로는 애플이 옳았다. 애플은 자신들의 OSX 운영체제를 쓰는 서버와 iOS를 쓰는 모바일 기기에서 이미 OpenSSL을 걷어낸 바 있었다. 이동이 제한적인 구역에 전염병 확산이 일어나지 않는 원리처럼 애플은 위협을 비껴갔다. 마이크로소프트의 윈도 운영체제를 쓰는 서버도 괜찮았다. 윈도 운영체제를 쓰는 서버는 OpenSSL을 쓰지 않고 마이크로소프트가 만든 자체 암호화 기술을 쓰기 때문이었다.

하트블리드는 일찌기 겪지 못했던 엄청난 보안 위협이었다. 그런데 너무나도 단순한 실수, 즉 해당 소프트웨어 작성자가 요구되는 문자길이를 제대로 확인하는 과정을 빼먹었다는 실수가 불러 일으킨 재앙이었다는 게 사람들을 더 놀라게 만들었다. 이는 마치 댐을 관리하는 직원이 실수로 수문을 열어 아랫마을이 밤새 물에 잠기는 사고가 일어난 것과 비슷한 지경이었다. 이 때문에 과연 이것이 단순한 실수에 불과했겠느냐는 음모론이 돌기 시작했다.

특히 문제가 된 건 광범위한 민간인 사찰을 통해 전 세계의 인터넷망을 감시해 왔다고 비난받은 미 국가안보국(NSA)이었다. 언론은 NSA에게 하트블리드 버그를 알고 있었느냐, 이를 통해 개인정보를 수집한 일이 있느냐고 질문했고 NSA는 아무런 코멘트도 하지 않았다.

하트블리드 문제는 해결 가능했다. 많은 기업들이 이미 하트블리드 문제를 해결한 상태다. 개인들로서도 우려할 일이 그렇게 크지는 않다. 하지만 정작 끔찍한 건 그동안 유출됐을 잠재적 정보다. 무려 2년 3개월의 기간 동안 얼마나 많은 정보가 누구에게 어떻게 유출됐는지 거꾸로 추적하는 게 불가능하다는 것, 이 점이 하트블리드가 재앙이라고 일컬어지는 가장 큰 이유다. 과연 정보 수집에 혈안이 된 모든 기관은 이 정보 유출 사고를 어떻게 보고 있었을까.

이와 별도로 무엇보다 하트블리드 사태는 ‘오픈소스’에 대한 의문을 남겼다. 오픈소스, 즉 공개 소프트웨어는 프로그램을 만드는 핵심 소스코드를 일반인에게 공개한다. 누구나 기여하고, 누구나 수정하는 일종의 ‘소프트웨어 위키피디아’인 셈이다. 위키피디아가 브리타니카 백과사전보다 정확성에 앞선다는 평가를 받는 것처럼 오픈소스 소프트웨어도 대기업이 개발한 소프트웨어보다 더 정밀하리라는 게 세상의 통념이었다. 그러니까 여럿이 함께 만들면 여럿이 함께 검토하기 때문에 버그도 없을 거라는 생각 말이다. 심지어 이런 믿음은 라이너스의 법칙(Linus’s Law), 그러니까 대표적인 오픈소스 소프트웨어로 유명한 리눅스의 개발자 라이너스 토발즈의 이름을 딴 법칙이란 이름으로 지지돼 왔다. 라이너스의 법칙은 “충분히 많은 사람이 주의깊게 지켜본다면 버그란 아주 사소한 문제일 뿐”(Given enough eyeballs, all bugs are shallow.)이라는 얘기였다. 그리고 라이너스의 법칙은 이번에 어긋나도 아주 심하게 어긋났다. 블랙스완이 발견된 셈이랄까.

논란이 들끓었다. 오픈소스는 필연적으로 인기 있는 주제로만 사람들을 모으기 때문에, 암호화 관리처럼 재미없고 복잡한 부분에는 자발적인 참여자가 줄어서 이런 버그가 나올 수밖에 없는 운명이었다는 비관론자들의 주장이 힘을 얻었다. 이들은 또한 개인에게 책임을 부여하는 기업과 달리 책임을 부여하지 않는 오픈소스는 꼼꼼한 관리가 어렵다고 주장했다.

하지만 여전히 기업이 만드는 상용 소프트웨어의 버그도 끊이지 않고, 대부분의 오픈소스 소프트웨어는 매력적인 가격(무료)과 빠른 업데이트, 최신 기술의 선도적인 적용 등의 장점을 잃지 않고 있다. 즉, 하트블리드는 뭔가를 결론내거나 끝을 보게 한 게 아니다. 대신 하트블리드는 기술이 지배하는 세상에 큰 질문 몇 가지를 남겼다.

첫째, 인터넷은 과연 안전한가?

둘째, 인터넷의 약점을 이용하는 세력이 나타난다면 우리는 그들을 어떻게 통제할 것인가.

셋째, 인터넷은 과연 대중의 지혜와 집단지성을 발휘하도록 돕는 도구가 될 수 있는가?

답은 없다. 하지만 우리에겐 이제 답을 찾아야만 할 이유가 생겼다. 이는 분명 새롭게 대두된 위협이고, 우리는 위협의 시작을 알게 됐으니까. 하트블리드가 그냥 한 차례 스쳐 지나가는 사고만은 아닌 이유다.

광고

Etsy의 비판없는 자아비판

모든 사람들은 실수하게 마련. 실수를 다시 하지 않는 게 중요하다고 말은 하지만, 어떻게 다시 실수를 하지 않게 만드는지가 사실 실수 자체를 줄이는 것보다 훨씬 더 중요하다.
Etsy에서 실수를 줄이기 위해 사용하는 방법은 실수를 비난하지 않는 것. 비난하지 않을 뿐만 아니라 실수를 한 사람에게 다음에 실수를 하지 않도록 시스템을 개선하는 업무를 맡긴다.

일반적으로 기업에서 쓰는 방식은 이렇다. 1. 실수가 생긴다 2. 관련자를 찾는다 3. 문책하거나 해고한다 4. 다음 관련자는 실수가 생기면 실수를 감추려고 책임을 돌리거나 혹은 실수가 없었다는 듯 위장한다 5. 더 큰 실수가 생긴다.

Etsy의 방식은 좀 다르다. 1. 실수가 생긴다 2. 관련자를 찾는다 3. 문책하는 대신 실수 개선 업무를 맡기고 시스템 개선의 모든 권한을 준다 4. 실수가 줄어드는 시스템이 완성된다 5. 동일한 실수가 크게 줄어든다.

이런 시스템이 거저 생기는 건 아니다. Etsy는 몇 가지 독특한 방식을 만들었다. 비즈니스 인사이더는 이 방식에 대한 기사를 써서 화제를 모았는데, Etsy의 운영담당 수석부사장 존 올스포가 좀 더 구체적이고 자세한 내용을 소개했다.

First Stories Second Stories
Human error is seen as cause of failure Human error is seen as the effect of systemic vulnerabilities deeper inside the organization
Saying what people should have done is a satisfying way to describe failure Saying what people should have done doesn’t explain why it made sense for them to do what they did
Telling people to be more careful will make the problem go away Only by constantly seeking out its vulnerabilities can organizations enhance safety

대표적인 방법이 ‘두번째 이야기’. 그러니까 첫째 이야기(First Stories)는 우리가 알던 실수에 대한 고정관념이다. 인간의 실수란 실패의 원인이고, 실패를 막기 위해서는 실수했던 사람이 마땅히 취했어야 할 조치들을 되새겨야 하며, 사람들을 더 조심하게 만들어야 문제가 해결된다는 것이다. 하지만 두번째 이야기는 다른 방법으로 문제에 접근한다. 인간의 실수란 조직 내부에 감춰져 있던 취약점이 시스템 바깥으로 드러난 결과란 것이다. 따라서 실수했던 사람이 마땅히 취했어야 할 조치를 얘기해봐야 도대체 왜 그 사람들이 그런 조치를 취하지 않았는지는 설명할 수 없다. 따라서 문제를 해결하려면 조직을 운영하는 시스템의 취약점을 끊임없이 살펴야만 한다는 것이다. 첫째와 둘째 이야기는 전혀 다른 관점으로 실수에 접근한다. 당연히 Etsy는 실수에 두번째 이야기로 접근한다.

이렇게 되면 실수가 생겼을 때 실수를 저지른 사람은 즐거운 마음으로 자신의 실수에 대한 디테일을 조직에 설명하기 시작한다. 자기가 뭘 실수했는지 가장 잘 아는 사람은 자기 자신이니까 당연히 경험은 생생하고, 전달도 잘 된다. “넌 그 때 이렇게 했어야 했어. 그래야 그 실수가 안 생겼지!”라는 말만 꾹 참는다면 이렇게 변화가 시작된다는 얘기다.

조심하지 않아서 실수를 했다, 미안하다, 이렇게 얘기하는 건 실수를 개선하는데 아무런 도움도 되지 않는다. 나중에는 더 조심하려다 더 큰 실수를 하게 마련이다. 시스템이 개선되지 않았으니까. 말은 쉬운데, 어떻게 이런 어려운 과정을 관리하는지 신기할 지경이다. 올스포는 여러 방법을 설명한다. 인상적인 대목들만 소개하면 이렇다.

– 실수가 생기면 우리는 ‘두번째 이야기’를 찾아낸다. 부주의가 원인이라고 간단히 얘기하는 대신 정말 여러 각도와 관점에서 실패를 분석한다.

– 실수를 처벌하는 대신 실수를 행한 사람에게 실수를 줄일 시스템 개선 권한을 부여한다. 그리고 조직 내 다른 구성원들에게 해당 실수에 대해 가르치도록 만들어 유사한 실수를 줄이게 한다.

– 간트차트의 시작부분 담당자(주로 기획부서)가 실제로 일이 어떻게 완수되는지 완성부분 담당자(주로 실무부서)의 일을 상상하지 말고 직접 확인하도록 권한다. 실무부서에서도 기획부서에 끊임없이 실현가능성에 대한 피드백을 주고, ‘기획이 무리했다’ 식으로 넘어가지 않도록 노력하게 한다.

마지막 부분이 와 닿았는데, 요즘 협업도구를 쓰면서 처음으로 간트차트를 실무에서 써보기 시작했다.

GanttChartAnatomy간트차트라는게 그렇게 대단한 건 아니고, 그림에서 보듯 작업일정을 정해놓고 예상 리소스, 선후관계 등을 정리하는 방식이다. 협업도구를 쓰는 회사라면 많이 봤을 그래프다. 그런데 이게 효율적이란 생각은 드는데 문제가 있다. 처음 프로젝트를 기획해서 할당하는 부서야 상상력을 발휘해 맘껏 일을 할당한다. 그런데 간트차트가 인과가 뚜렷하게 물리다보니 한 부서에서 프로젝트 할당량이 일정을 초과하면 뒤로 갈수록 점점 빡빡해지는 일정이 나올 수밖에 없다. 게다가 데드라인이 정해진 프로젝트는 도중에 간트 차트를 바꾸는 것도 쉽지 않다. 결국 군대에서 행군할 때 맨 앞줄이 일정 페이스를 지키며 걷지 못하면 뒷줄에선 20km를 계속 구보로 이동하는 일이 협업 프로젝트에서도 똑같이 벌어지는 셈이다.

실수는 이 무리한 마지막 단계에서 자주 발생한다. 기획이야 완벽해 보이지만 실행하다보면 예상치 못한 변수가 수없이 생기니까. 그래서 기획팀에게는 실행 과정을 직접 보는 게 중요한 일이 된다. 실행팀에게는 단계별로 피드백을 정확히 주는게 중요한 일이 되고. 하지만 현실에선 기획팀이 “해보지도 않고 무슨 소리”라며 권위로 일을 밀어내고, 실무팀에선 “탁상공론이나 벌이는 기획팀 노름”이라며 실수를 해부해 드러내기보다 그냥 덮고 넘어가기 급급하다. 그러니, 언제나 아는 것만큼 실제로 행하는 것이 중요하게 마련이다.

바다 위의 빅데이터

인사를 나누고 명함을 받았다. CIO라는 세 개의 머릿글자가 눈에 들어왔다. 학부는 서울대 계산통계학과를 졸업했고, KAIST에서 전산학으로 석사와 박사 학위를 받았다고 했다. 이력을 쌓은 곳은 삼성SDS와 삼성종합기술원, 현대정보기술. 환갑을 눈앞에 둔 그는 이론과 실무 모든 측면에서 평생을 소프트웨어와 씨름하면서 살아온 국내에서 손 꼽히는 소프트웨어 전문가다.
그와 함께 일하는 후배는 한양대 전자공학과에서 학부와 석사과정을 마쳤다. 이후 SK텔레콤에 들어가 인터넷 사업을 담당했고 ‘넷츠고’라는 인터넷 서비스도 만들었다. 자기 사업을 해보겠다며 SK텔레콤을 나와서는 브리태니커 백과사전을 CD롬에 담아 판매하던 벤처기업 에임텍도 창업했다. 소프트웨어와 인터넷 분야에서 잔뼈가 굵은 사람이었다. 그의 책상 위에는 새로 번역돼 나온 클레이튼 크리스텐슨 교수의 ‘혁신가의 딜레마’가 놓여 있었다.

두 사람을 만난 곳은 울산의 현대중공업 조선소였다. 현대중공업 전체의 최고정보책임자(CIO)인 황시영 부사장과 황 부사장과 함께 배를 스마트하게 바꿔가는 ‘스마트십(Smart Ship)’ 사업을 책임지고 있는 통합전산실 조성우 상무다. 본인들도 배를 만들 거란 생각은 해본 적이 없었다고 했다. 하지만 결국 2000년대 중반에 두 사람 다 현대중공업으로 자리를 옮겼고, 이후 지금까지 왔다.

스크린샷 2013-07-25 오후 5.31.29

배란 덩치가 커서 그렇지 기본적으로 탈 것이고, 자동차와 크게 다르지 않다. 엔진을 돌리고 조향장치로 방향을 정한다. 그래서 조선소도 자동차 공장과 비슷하다. 다만 덩치가 크고 조립에 시간이 많이 걸릴 뿐이다. 자동차 공장에선 건물 한 채에서 차 한 대를 만들 것을, 조선소에서는 건물 한 채에서 한 공정을 하는 것 정도가 다를 뿐이다. 그러니까 차와 비교하면 편하다.

스마트십은 기본적으로 스마트카와 비슷하다. 아직 개념만 있고 초기 단계에 불과하며 진정으로 스마트해지지는 못했다는 점에서도 차와 다를 게 없다. 스마트카의 핵심은 ‘연결성’이다. 인터넷을 통해 세계 모든 정보에 언제나 연결돼 있어야 스마트카다. 오늘날 자동차들은 무선통신 기술을 이용해 수많은 정보를 실시간으로 처리한다. 막히지 않는 길을 알려주는 내비게이션 시스템은 기본이고, 차량에 큰 사고가 나면 사고 신고를 해준다거나, 조만간 문제가 생길 것 같은 부품이 발견되면 정기점검 기간 이전에라도 서비스 센터를 방문하도록 권하고, 이 정보를 서비스센터로도 전송한다.

스마트십도 마찬가지다. 최적의 항로를 계산하고 최적의 예방 정비를 가능하게 도와준다. 별 것 아닌 것 같지만 배에서는 차와 달리 불가능했다. 물리적인 한계 탓이다. 스마트폰이나 자동차가 언제 어디서나 인터넷에 연결될 수 있는 건 통신사들이 육상 대부분의 지역에 기지국을 설치해 전파를 송출하기 때문이다. 그런데 바다에는 기지국을 세울 수가 없다. 대신 위성 통신이 있긴 하다. 하지만 위성통신은 값도 비싸고, 속도도 느렸다. 그런데 최근 이런 환경이 급변하고 있다. 영국의 위성통신 회사인 인마샛은 2014년 말부터 약 50Mbps 속도를 내는(이 정도면 대략 지금 우리가 쓰는 LTE 속도와 맞먹는다. LTE는 이론상 75Mbps 속도까지 낸다) 위성통신을 서비스할 예정이다. 이는 지금 위성통신으로 주고받는 데이터 속도보다 100배 이상 빠른 속도다. 주고받을 수 있는 통신량이 늘어나면 자연스레 통신료도 싸지게 마련이다. 현대중공업은 이런 통신망에 대응하는 배를 만들고 있다.

스크린샷 2013-07-30 오후 2.13.40

차가 모을 수 있는 정보는 다양하다. GPS를 이용해 현재 위치를 파악할 수 있고, 이를 차량 내비게이션용 지도와 연결지어 운전자에게 경로를 안내할 수 있다. 외부에서 수집된 실시간 교통정보를 기반으로 최적 경로 안내가 가능하고, 차량의 전후방 카메라를 이용해 도로 표지판 등을 인식하는 것도 가능하다. 초음파 센서를 사용해서 충돌 상황을 예상하고, 자동 주차도 돕는다. 또 와이퍼 동작용 센서는 비가 오는지, 얼마나 오는지에 대한 기후 조건을 수집하고, 엔진의 회전수와 제동장치 작동 상황 등을 이용해 순간 연비와 평균 연비도 파악해낸다. 차량 내 네트워크(CAN, Controller Area Network)을 통해 각 부품을 통제하는 차량의 ECU는 차 자체의 상태 정보도 실시간으로 파악해 저장하고 있다.

배도 마찬가지다. GPS와 전자해도 덕분에 오늘날의 항해사들은 별과 달과 태양에 의존하지 않고도 훨씬 쉽게 항로를 찾는다. 배에 설치된 레이더는 바다 위의 해도와 다른 장애물(다른 선박 또는 유빙 등)을 쉽게 찾아내도록 도와주고, 지상의 관제소는 선단의 움직임을 데이터로 파악해 최적 경로를 계산한다. 선박 내 네트워크(SAN, Ship Area Network)를 통제하는 선박 제어장치는 배에서 수집된 모든 부품과 기계장치의 데이터를 통제하며 전송할 수도 있게 된다. 실제의 기상 상황과 기상 예보 등을 토대로 항로의 기상 상황 예측도 가능해진다.

차에선 이미 이 정도의 내용이 상용화돼 있다. 하지만 배에선 이제 시작이다. 현대중공업이 ETRI와 함께 SAN을 만든 게 겨우 2년 전이다. SAN과 연결되는 레이더를 현대중공업이 직접 만들어 완성한게 겨우 이달 초였고, 이런 정보를 육상과 실시간으로 주고받을 수 있는 위성통신망의 완성은 내년 말에나 가능할 예정이다. 그러니까 배를 똑똑하게 만드는 일은 이제 겨우 첫 발을 뗀 셈이다.

하지만 스마트십의 이점은 굉장히 크다. 차량이 연료를 아끼는 기술은 아직도 엔진에 달려 있다. 전기를 함께 쓰건(하이브리드) 엔진의 배기량을 낮추면서도 파워를 최대한 유지하건(다운사이징) 아예 전기만 쓰건(전기차) 간에 대부분 차량 설계가 연료 절감에 직결된다. 강철 대신 탄소섬유를 써서 차체 무게를 가볍게 하는 기술도 마찬가지다. 여기에 ‘덜 막히는 도로’를 안내해 주는 스마트한 길 안내는 크게 주목받지 못한다. 차는 기본적으로 운전자의 개인 이동수단이라 변화무쌍한 도로를 다니기 때문이다.

3도크전경

배는 다르다. 전기의 힘으로 연료를 절감하기엔 일단 너무 대형이라 동력이 부족하다. 대부분의 전기차와 하이브리드 차가 소형차 형태인 것도 이런 이유다. 선체와 프로펠러, 엔진의 설계를 아무리 바꾸고 개선해봐야 1%의 연료절감을 얻기가 쉬운 게 아니다. 그런데 항로를 바꾸면 얘기가 달라진다. 비가 적고, 해류의 방향이 유리하며, 타 선박의 이동이 뜸해 충돌 회피를 위한 경로 이동 필요가 줄어드는 길을 찾으면 된다. 요트라면야 개인 항해사의 기분이 중요하겠지만 상선은 늘 정해진 항로로 이동한다. 한두 척의 배로는 이런 최적 항로를 찾기 힘들지만 수백 척이 수년 간 데이터를 쌓
다면 최적 항로 계산 공식을 만드는 건 그리 어려운 일이 아니다. 이런 알고리즘 개발이 현대중공업 통합전산실의 일이다. 이들은 자신들이 만들어 판매하는 배들이 바다에서 수집하는 각종 정보를 한 곳에서 수집해 최적 항로를 계산해 주면 약 3%의 연료절감 효과가 기대된다고 했다. 최근 널리 쓰이는 1만3000TEU(컨테이너 1만3000개 적재가능 선박)급 컨테이너선으로 치면 한 척 당 연 8억 원의 연료비를 아끼는 효과다. 그러니까 ‘T맵’을 바다용으로 바꾸는 정도의 노력만으로도 200억 원 정도를 아낀다는 얘기다.(배들은 보통 25년 정도 항해한다.)

그러니까 무엇보다 중요한 건 데이터다. 그것도 많은 데이터. 이걸 모으려면 가장 많은 배를 만들어 바다 위에 가장 많이, 오래 띄워 놓는 회사가 가장 좋은 데이터를 확보할 수 있다. 그리고 이 데이터를 소유해야 돈벌이가 되는 서비스를 판매하게 된다. 현대중공업은 조선 업계에서 규모로 세계 최대다. 이른바 ‘빅데이터’를 수집할 기본은 갖춘 셈이다. 물론 이 데이터에 눈독을 들이는 곳은 많다. 당장 해운업체들이 직접 데이터를 모아 관련 서비스에 뛰어들고 싶어한다. 또 위성인터넷을 선원들이 일상적으로 사용하게 된다면 그 데이터만 모아도 배의 이동경로와 속도 등을 파악할 수 있다. 인터넷 기업들이 관심을 가질만한 B2B 사업모델이 나오는 셈이다. 위성인터넷 시장을 사실상 독점한 셈인 인마샛 같은 회사도 통신망을 제공한다는 이유로 데이터에 접근 가능하다. 그래서 이 분야는 이제 겨우 걸음마 단계다. 누가 주도권을 쥐게 될지는 모른다.

이외에도 스마트십의 장점은 많다. 예를 들어 운항 중단 기간도 최소화 할 수 있다. 항구에 들어와 정비를 시작하는 대신 바다 위에서 컴퓨터가 자체 진단을 실시간으로 벌인다면 유지관리 업무는 정박과 함께 가장 효율적으로 이뤄져 운항 중지 기간을 극적으로 줄일 수 있다. 선원 관리에도 도움이 된다. 국제해사기구(IMO) 규정에 따라 배는 안전을 위해 선장과 1등 항해사 등 선박 규모에 따라 규정된 일정 수의 승무원을 반드시 탑승시켜야 항해가 가능하다. 수개월 이상 항해하는 배에서 이들의 인건비도 큰 비용인 셈이라서 대부분의 해운회사들은 자국 선원보다는 동남아시아 국가 등 인건비가 상대적으로 싼 제3국 선원을 선호한다. 문제는 이들의 영어 실력 등이 원활한 의사소통을 가능하게 할 만큼 높지 않다는 점이다. 관제소에서 선박의 상태와 주위 환경 변화를 거의 대부분 모니터할 수 있는 스마트십은 항해중인 승무원들과의 의사소통 수준을 쉽게 높여준다.

거대한 쇳덩어리 같지만 결국 이 무지막지한 구조물들이 각축을 벌이는 시장을 아래에서부터 근본적으로 바꾸고 있는 건 소프트웨어다. 소프트웨어가 세상을 집어삼킨다.