1회에 이어 2회에도 참석하게 되었습니다. ^^;

다음세대재단, (주)다음커뮤니케이션, ZDNet Korea에서 후원하기 때문에 웹 관련 업무에 종사하시는 분들이 많이 참석하고 이와 관련된 주제로 발표가 많긴 하지만, IT 업계 흐름도 익히고 오랜만에 지인도 만날 목적으로 참가하게 되었습니다.

1회 참석자는 발표를 안해도 무관하나 그래도 뭔가 이야기를 전달하고 싶어서 부랴부랴 "웹브라우저 이야기"라는 주제를 가지고 발표 준비를 하였습니다. 많은 개발자들이 리눅스 커널에 관심을 갖듯이 웹개발자 역시 브라우저 내부에 대해 좀 더 관심을 가져보자는 취지로 발표를 준비했습니다.

우선 등록을 확인하고 후원업체에서 마련한 기념품을 받았습니다.. ^^; 공짜는 언제나 즐겁습니다. 온넷에서 준비한 보온컵, 야후에서 준비한 휴대용 핸드폰 충전기, 다음에서 준비한 바캠프 검은 티를 받았습니다..


출처: http://www.flickr.com/photos/barcampkorea by 정진호

1회 때 만나뵙던 분들과 인사를 나누고 새로 참가한 분들과도 명함을 나누었습니다. 그리고 자유롭게 발표할 주제를 포스트잇에 적어서 원하는 트랙에 붙였습니다. 저는 아직 발표자료가 미완성이라서 늦은 시간때에 자리를 잡았습니다.

오전 11시 부터는 간단한 자기 소개시간이 있었는데, 참가 인원이 많다 보니 1시간이 훌쩍 넘었습니다. 날 좋은 토요일날 가족들 몰래 오신분들도 있었고 상사 눈치를 피해 오신분, 전날 다음 DevNight행사에서 밤새고 참석한 분도 계셨습니다.

12시 부터 다음세대재단에서 마련한 맛있는 뷔페를 먹었습니다. 많은 분들과 이야기를 나누느라 사실 밥은 제대로 못먹었습니다. 2층에 마련된 다음 카페(?)에서 라떼 한잔을 마셨는데, 회사안에 정말 멋진 까페가 있더군요.

이번 바캠프의 가장 큰 특징은 인문/사회학을 공부하신 분들의 참가가 눈에 띄게 많았다는 점입니다. Creative Commons Korea, 미디어문화행동 , 정보공유연대, 민노당정책위와 같은 단체에서 사회운동을 하시는 분들과 덕성여대 문헌정보학과에서 새로운 주제를 선보였습니다. 이쪽 분야에서도 정보공유, F/OSS에 많은 관심을 갖고 있었고 이를 사회운동화하려는데, IT분야사람들은 업무 활용이나 자신들만의 관심사에 머물고 있다면, 이 분들은 이를 통해 사회를 좀 더 평등하게 발전시키기 위해 노력하고 있었습니다. 그리고 덕성여대 문헌정보학과 이소연 교수임을 통해 디지털 아카이브에 대한 최근 동향과 문제점을 공유할 수 있는 좋은 기회도 가질수 있었습니다.

IT업계에서 기술만 쫓다보면 기술이 사회에 미치는 영향을 대해 소홀하게 됩니다. 이런 부분들에 관한 문제 의식을 갖고 고민하는 분들의 생생한 목소리를 듣게 되어 참 좋았습니다.

바캠프는 사실 어려운 자리입니다. 참석하시는 분들이 업계에서는 어느 정도 위치에 계신 분들이고, 그 분들이 던지는 화두는 많은 분들에게 방향을 제시하고 문제를 제기합니다. 그래서 경험이 다소 부족한 개발자가 엔지니어적 입장에서 어떤 주제를 가지고는 사람들의 관심을 끌기가 좀 어렵습니다. 너무 기술적인 내용보다는 누구나 알고 있는 내용을 배경으로 평소 인식하고 있지 못한 부분에 관해 이의를 제기해야 많은 관심을 끌 수 있습니다. 그러면에서 사회운동 또는 기획하시는 분들이 여러 사람의 관심을 이끌 수 있는 주제를 갖고 나오셨습니다.



(우선 무단으로 퍼왔습니다.. ^^; 처음 소개할 때 모습입니다..)

저도 첫번째 트랙에서 맨 마지막으로 발표를 했습니다. 웹브라우저 연대기와 각 브라우저의 연관 관계를 설명하고 몇몇 웹브라우저 아키텍쳐를 간단히 소개하였습니다. 마지막으로 브라우저의 간단한 실행 흐름과 다가올 HTML5에 관한 이야기를 하였습니다.

이번 행사에서는 me2day라는 한줄 블로그 서비스로 행사의 전반적인 분위기를 생생하게 공유할 수 있었는데, 호응이 대단히 좋았습니다. 행사가 끝난 이후에도 계속해서 그날의 분위기와 느낌을 이어갈수 있었습니다. 이날 CEO도 직접 바캠프에 참석하셨는데, 이미 많은 분들이 가입하여 세일즈에는 큰 영양가가 없는 듯 보였습니다. ^^; 하지만 한줄 블로그 서비스의 유용성을 다시 한번 입증하는 좋은 기회였던 것 같습니다.

개인적으로 이번 바캠프를 통해 앞선 선배님들의 현장에서의 생생한 목소리를 들을 수 있는 좋은 기회였습니다. 특히, Creative Commons Korea를 이끌고 계시는 윤종수 판사님, FON Korea 허진호 사장님의 참석이 이번 행사를 더욱 뜻 깊게 했다고 생각합니다.


출처: http://www.flickr.com/photos/barcampkorea by 정진호

마지막으로 channy님의 "공유가 이처럼 아름다운적은 없었습니다"라는 말을 떠올리며, 이번 행사가 무척 뜻 깊은 행사였다는 사실을 다시 한번 생각하게 되었습니다.

고맙습니다~

1회에 이어 bacamp Seoul 2회에 참가하게 되었습니다. 행사 주관은 다음에서 일하면서 한국 모질라 커뮤니티를 이끌고 있는 윤석찬님이 하고 있으며 IT관련 특히, 웹 분야를 주도하고 있는 분들을 만날수 있고 동향을 살필수 있는 자발적 모임이라고 할수 있습니다.

지난 1회 때는 준비할 시간이 많지 않아 지금까지 그려온 만화를 가지고 "프로그래머 이야기"라는 발표을 했었습니다. 2회때 부터는 1회때 발표를 한 사람은 그냥 참관으로 참석할 기회가 있어서 발표 신청은 하지 않았습니다. 하지만 뭔가를 준비는 해야 할 것 같습니다.

오픈소스나 웹브라우저와 관련해서 저만의 이야기를 풀어볼 생각입니다.

참고

* barcamp Seoul 1회 참가 후기

* barcamp Seoul 1회 소개

스프링노트에 대해 잘 모르시는 분도 많을 것 같습니다.

한마디로 위지위그(WYSWYG) 위키서비스라고 하는 것이 좋겠습니다. 웹기반 문서 저작 서비스인데, 위키위키 방식으로 문서 편집하고 쉽게 관리할 수 있습니다.

이번 모임은 서비스를 개발한 오픈마루가 주관하였고 개발자와 사용자가 직접 만나 향후 추가될 새로운 기능 소개와 사용자의 의견을 받는 행사였습니다.

우선, 개발자와 사용자 모두의 참여로 스프링노트를 개발하는 열린 모습이 무척 좋아 보였습니다. 소프트웨어를 개발하는 저로서는 무척 부러운 모습이였습니다. 앞으로 이런 방식으로 소프트웨어 또는 서비스를 개발하는 것이 큰 흐름으로 자리 잡을것 같습니다. (SW개발 2.0 쯤 되려나..)

스프링노트가 위키와는 또 다른 새로운 모습을 갖고 있기 때문에 사람들마다 사용목적, 사용방식이 다 다른 것 같습니다. 이런 모든 요구사항을 일반화해서 서비스를 만든다는 것이 쉬운 일은 아닐 것입니다.

특히 컴퓨터와 인터넷에 익숙하지 못한 사람들도 쉽게 쓸 수 있는 서비스를 만들어야 하는데, 이미 위키에 익숙한 사용자도 함께 만족시키려면 많은 부분을 고려해야하겠지요.

사용자와 직접 머리를 맞대고 소프트웨어 개발하는 새로운 모습을 경험한 좋은 시간이였고, 짦은 시간이지만 제가 느낀 스프링노트에 대해 개발자분들께 직접 이야기 나눌 수 있는 좋은 기회였습니다.

앞으로 문서작성이 좀 더 재밌고 창의적이고 구조화될 수 있는 방향으로 발전하기를 기대해봅니다.

금융결재원이 파이어폭스, 사파리와 같은 웹브라우저에서 공인인증서 지원을 거부했다고 합니다.

정말 웃기는 일이지만, 우리나라는 윈도에서 인터넷 익스플로러에서만 가지고 공인인증서를 사용할 수 있습니다. 리눅스와 매킨토시 사용자는 인터넷 뱅킹도 쇼핑도 할 수 없습니다.

그 이유가 정말 황당합니다.

이와 관련 금결원 전자인증센터 안순용 인증관리팀장은 “우리는 오픈웹과 기본적인 법률해석이 다르기 때문에 오픈웹의 제안을 받아들이지 않은 것 뿐”이라고 반박했다.

그는 “공인인증 기관은 (모든 사용자에 맞춰) 가입자설비 소프트웨어를 배포할 의무가 없고, 현실적으로 (비(非)IE를 사용하는 시장도 없다”면서 “이미 기술을 확보하고 있지만 시장이 없어 배포하지 않고 있다”고 일갈했다.

비IE를 사용하는 시장이 없다는데, 현재 애플이 열심히 매킨토시를 판매하고 있고 리눅스 사용자도 많이 있습니다. 게다가 이미 기술은 확보했는데 배포하지 않는 이유가 무엇인지 정말 궁금하군요. 그리고 공인인증 기관이면 당연히 다른 운영체제도 지원해야하는 것이 아닐까요?

물론, 그 시장이 작다는 것은 인정합니다. 하지만 그 동안 MS기술에 의존해온 결과 우리는 많은 혼란을 겪어왔습니다. 윈도나 인터넷 익스플로러가 업그레이드 될 때마다 크고 작은 호환성 문제로 많은 사용자와 웹사이트 운영자가 혼란과 불편함을 감수해왔고, 정부도 MS에 윈도98 기술지원 연장을 구걸했지만 거절당하고 말았습니다.

이것은 MS의 문제가 아닌 아무 생각없는 정부 정책자와 사리사욕만 채우는 금융기관의 문제입니다.

하루 빨리 이 문제가 해결되기를 희망하며, 관련 소식이 나오는데로 계속 전하겠습니다.

* 관련기사

http://www.ddaily.co.kr/news/?fn=view&article_num=23053

* 관련 의견

http://kldp.org/node/81358

*바깥고리

http://openweb.or.kr/

SW 개발자의 큰 걱정 중 하나는 계속 공부를 해야 한다는 것입니다. SW분야 만큼 기술의 변화, 발전 속도가 빠른 분야도 없을 것입니다. 저 개인적으로는 이런 변화를 즐긴다고 자부해왔지만, 가끔은 애써 나하고는 무관하다라고 외면하는 경우도 있습니다. 물론, 변하지 않는 핵심을 잘 이해하고 있으면 새로운 기술에 대한 적응은 쉽습니다. 하지만 관심마저 저버린다면 누구와 대화라도 나누기가 힘들어집니다.

90년대 부터 제가 경험한 SW 개발환경의 변화와 향후 발전 방향에 대해 간략하게 알아보도록 하겠습니다. 이런 글을 쓰게 된 이유는 앞으로의 일어날 변화가 지금까지 경험한 변화 가운데 가장 크다고 생각하고 있고 저 자신도 이러한 변화에 발맞추어 나가려고 하기 때문입니다.

객체지향 프로그래밍(OOP)와 GUI 프로그래밍
90 년대 초반, 이 때는 대부분의 SW 개발자가 도스에서 C 프로그래밍을 하던 시절이였습니다. 이 때 두가지 변화의 물결이 다가왔는데, 바로 OOP와 윈도 프로그래밍이였습니다. 볼랜드의 OWL(Object Windows Library)과 비주얼 C++의 MFC(Microsoft Foundation Class Library)와의 전쟁에서 비주얼C++가 승리하면서 마이크로소프트는 개발툴에서도 독점을 이어나갔습니다. 하지만 진짜 비주얼 개발툴은 바로 비주얼 베이직이였습니다. 수 많은 초보 개발자를 윈도 개발자로 다시 태어나게한 일등 공신이라고 생각합니다.

기상기계(Virtual Machine)기반의 자바 언어 등장
97년이였던 것 같습니다. 자바(Java)의 등장은 많은 개발자에게 신선한 충격으로 다가왔습니다. 크로스 플랫폼을 지원하며 개발툴도 무료로 제공되었고 네트워크 어플리케이션 부터 GUI 프로그램까지 쉽게 개발할 수 있었습니다. 지금까지 개발된 어떤 언어보다 명시적이고 풍부한 기능을 제공하였고 쉽게 배울 수 있었습니다. 한 때, 웹 브라우저에서 동작하는 유일한 어플리케이션 실행 환경으로 각광을 받았지만, 플래시(Flash)에 밀렸고 현재는 모바일이니 서버쪽에서 많이 쓰이고 있습니다. 하지만 이클립스(Eclipse)와 같은 네이티브(native) UI기반의 SW 프레임웍(framework)이 등장하면서 현재는 데스크탑 환경에서 풍부한 UI를 제공하고 있습니다.
자바는 현재도 JSR(Java Sepcification Request)을 통해 새로운 기술과 기능에 대한 자바 API 규약이 나오고 있으며 계속 진화, 발전하고 있습니다.

웹과 스크립트 언어
많 은 소프트웨어가 웹을 기반으로 개발되면서 스크립트 기반의 개발환경 또는 언어가 대중화되기 시작합니다. 서버측면에서는 ASP, JSP, PHP가 대중화되었고 웹브라우저에서는 자바스크립트(JavaScript)가 사용되었습니다. 자바스크립트는 자바 보다는 오히려 C언어와 유사한 부분이 많죠. 물론 이전부터 파이썬(python), 펄(perl)도 CGI 개발에 사용되고 있었죠. 하여간 스크립트 언어 하면 웹을 연상할 만큼 웹 어플리케이션 개발에 많이 사용되고 있습니다. 하지만 스크립트 언어는 유닉스의 역사와 함께할 만큼 오랜 세월 동안 사용되어 왔습니다. 근래들어 루비가 많은 관심을 끌고 있더군요. 이러한 사실은 몇 년전 부터 시작된 대안언어축제라는 행사를 통해 알게되었습니다.

Win32API와 MFC의 종말(?)


얼마 전 뉴욕타임즈 리더라 는 프로그램을 다운로드 받았는데, UI가 좀 색다르게 구성되었고 글꼴 출력이 무척 미려했습니다. 닷넷(.Net) 프레임워크에서 제공하는 WPF(Windows Presentation Framework)를 사용해서 개발된 프로그램이였습니다. 비록 닷넷 프레임웍 런타임(runtime) 환경을 다운로드 받아야 했지만, 기존 윈도 프로그램에서 볼 수 없었던 부드러움과 신선함을 느낄 수 있었습니다. 닷넷 프레임워크는 마이크로소프가 자바를 대항에서 만든 윈도 기반의 어플리케이션 실행 환경입니다. 비주얼 베이직과 같은 런타임 실행 환경과 다양한 소프트웨어 컴포넌트로 구성되어 있습니다. C#이라는 언어에 의존적이지 않고 다양한 언어를 지원할 수 있도록 공통 언어 인프라스트럭쳐(Common Language Infrastructure)를 제공하고 있습니다. 단순히 자바를 죽이기 위해 개발된 것 보다 윈도의 차세대 SW 플랫폼을 만들기 위한 전략으로 개발된 것 입니다.

이런 사실 때문에 Win32 API와 MFC가 윈도 개발의 모든 것이라고 생각했던 많은 개발자에게 또 다른 고민거리를 안겨주었습니다. 이것은 비주얼 베이직이 등장할 때와 또 다른 문제였습니다. 마이크로소프트가 닷넷 프레임워크를 향후 윈도 프로그래밍의 주력으로 밀 것이 분명해보였고 이것은 윈도 비스타가 출시되면서 현실이 되었습니다.
윈도 비스타의 새로운 기능인 벡터 방식의 그래픽, 3D기능, 애니메이션 기능은 바로 닷넷 프레임워크 3.0에서 제공하는 WPF의 기능이며 현재 윈도XP에서도 지원하고 있습니다. 이 기능을 제대로 활용하려면 닷넷 프레임웍을 새로 공부해야 하고 비주얼 스튜디오2005에도 익숙해야 하며 무엇보다는 UI를 만들려면 XAML(eXtensible Application Markup Language)을 잘 알아야합니다. UI가 기존의 대화상자나 콘트롤 위주가 아니라 벡터 그래픽, 3D, 애니메이션, 동영상이 결합되기 때문에 이를 통합 할 도구의 사용법도 익혀두어야 합니다. 앞으로 플래시 만큼 상큼하고 역동적인 UI를 윈도 어플리케이션에도 흔히 볼 날도 머지 않았습니다. 물론 많은 개발자들이 이를 지원할 수 있도록 공부를 해야겠지요.

웹에서 데스크탑으로
소프트웨어를 개발할 수 있는 방법이 점점 더 다양해져가고 있습니다. 이전에는 나름대로 고유영역이 있었습니다. C,C++는 높은 성능과 최척화가 필요한 부분에 사용되었고, 자바는 네트웍 환경에서 서비스나 데이터를 처리하는데 많이 사용됩니다. 웹은 브라우저 기반의 정보 서비스와 같은 주로 정적인 정보 제공하는 역할을 제공했었지요. 플래시는 벡터 방식의 단순한 애니메이션을 보여주는 기능을 해왔습니다. 하지만 지금은 그 경계가 무너지고 있습니다. 특히 웹브라우저와 플래시는 자신의 영역을 계속 넓혀가고 있습니다. 웹브라우저는 Ajax기술을 이용하여 웹 페이지 변경 없이, 마치 데스크탑 어플리케이션 처럼 풍부한 UI를 지원합니다. 플래시도 마찬가지로 단순한 애니메이션 저작툴이 아닌 다양한 응용 어플리케이션도 개발할 수 있는 소프트웨어 플랫폼의 역할을 할 수 있을 정도로 기능이 강화되고 있습니다. 이들 인터넷 기반의 새로운 어플리케이션 형태를 RIA(Rich Internet Application)라는 부르고 있습니다. 웹브라우저를 기반으로 마치 전통적인 데스크탑 어플리케이션과 같은 기능을 제공하는 소프트웨어를 부르는 말입니다. 지금 RIA가 데스크탑 어플리케이션을 따라가고 있다면 데스크탑 어플리케이션은 WPF와 같은 기술을 통해 한 발짝 더 나아가려 하고 있습니다. 이런 흐름에서 도도하게 옛 방식만을 고수하기는 힘들 것입니다.

변화가 싫다면 발전 속도가 느린 시스템 프로그래밍 이하를 파고 들던지 아니면 새로운 환경에서 좀 더 유연한 개발 언어, 개발 환경을 통해 지금 보다 나은 풍부한 사용자 경험과 편리함을 제공하면 어떨까요? 물론 SW 개발도 이전보다 더 쉽고 재미있어야 하겠죠?

요즘 왠지 기억력이 떨어지고 뭔가 집중이 잘 안되서 "이제 조금씩 늙어가는구나" 하는 생각을 했었습니다. 하지만, 저를 안심시키는 글이 경향신문에 올라와있네요.

다행이 기사를 보니 바로 전의 일을 기억하지 못하거나 갑자기 생각이 안떠오르는 "브레인 프리즈"현상은 반드시 머리가 나쁘거나 노인에게 일어나는 현상이 아니라 오히려 한가지 분야만을 오랜시간 동안 연구해온 학자나 인터넷을 많이 사용하는 젊은이들에게서 나타날 확률이 더 높다고 합니다. 저 같은 SW 개발자도 그럴수도 있겠군요.. ^^;

뇌는 쾌락을 통해 발전해 나간다고 합니다. 정말 자신이 좋아하는 일을 하면서 목표를 이루고 그 뒤에 느끼는 성취감이 뇌를 발전시킨다고 합니다. 제 경험에도 뭔가 흥미롭고 새로운을 것을 공부하거나 뭔가를 잘 정리하고 나면 머리가 상쾌해지는 것을 느낄때가 있는데, 그런 현상 같습니다. 그리고 오감을 활용해서는 기억을 하면 더 뇌가 더욱 활성화되어 잘 기억할 수 있다고 합니다.

가장 맘에 드는 기사 내용은 "멀티플레이어가 되라" 입니다. 사실 전 관심 분야도 많고 다양한 일을 해왔습니다. 그렇다 보니 마땅히 내세울만한 특기가 없었는데, 너무 한가지에만 몰두하면 뇌가 경직될 가능성이 크다고 합니다. 성격이 다르고 분야가 다른일을 고루하는 것도 뇌발달에 도움이 될 듯 싶습니다. 이런 의미에서 제가 꾸준히 그림을 그리는 것도 좋은 습관인 것 같습니다. 사실 제 경력에 큰 도움도 안되는데, 괜히 그림이나 그리고 있는 것이 아닌가 생각할 때마 종종 있었습니다.

천재 물리학자인 아인쉬타인은 평생 자신의 뇌를 20%밖에 못썼다고 합니다. 어떤 기준인지는 알 수 없으나 그 만큼 사람의 뇌의 가능성은 무궁무진합니다.

집중하되, 다양한 경험을 쌓는 것이 뇌를 젊게 하고 좋은 아이디를 만들어 낼 수 있는 방법인 것 같습니다.

* 바깥고리

제목이 너무 자극적인 것 같군요.
어떻게 보면 낚시성 제목인 것 같기도 하고요. 이런 글을 쓰게 된 이유는 다름이 아니라 더 이상 설치형 블로그를 운영할 이유가 없다는 생각이 들었습니다.

이글루스를 시작으로 블로거들 입맛에 맞는 블로그 서비스가 시작되었지만 뭔가 부족한 부분이 있었습니다. 구글에서 운영하는 블로거 처럼 여러 블로그를 운영할 수 없다는 부분과 애드센스 광고를 삽입할 수 없었지요. 물론 다른 포털에 비해 자유도가 높아서 큰 인기가 있었지요.
얼마 전 태터툴즈의 서비스형 블로그인 티스토리에 가입을 했습니다. 초청에 의해서만 가입이 진행되다가 이제는 신청하면 가입할 수 있게되었습니다. 아시다시피 태터툴즈는 국내에서 가장 인기가 높은 설치형 블로그입니다. 다음과의 제휴가 진행되면서 설치형 블로그에서 한걸음 더 나아가 직접 블로그 서비스를 시작하였습니다. 아직 충분히 사용해보지는 못했지만 멀티 블로그를 만들 수 있다는 부분이 참 좋고 그 많은 태터툴스의 플러그인과 테마를 직접 설치하지 않아도 바로 사용할 수 있다는 점도 마음에 듭니다.

무엇보다도 스팸 댓글과 트랙백에서도 벗어날 수 있을 것 같습니다. 사실 현재 워드프레스를 쓰기전 설치해둔 태터툴스를 방치해 놓았다가 엄청난 스팸 댓글과 트랙백 때문에 어쩔 수 없이 차단 기능이 있는 새 버전으로 업그레이드를 하긴 했는데, 여전히 기승을 부리고 있습니다. 티스토리에서는 그런 문제를 해결해 놓았겠지요?

설치형 블로그의 장점을 계승한 티스토리는 게으른 저에게는 한 줄기 단비와 같습니다. 하지만 기존 태터툴스에 대한 지원도 티스토리 못지 않아야겠습니다.

앞으로 서비스형 블로그가 기존 설치형 블로거들의 입맛을 완전히 사로 잡는다면, 단순 웹호스팅 사용자도 많이 줄어들 것 같습니다. 설치형 블로그의 운명이 웹호스팅 사업자의 행방에도 큰 영향을 미칠 것 같군요.

편리함과 자유스로움이 많은 블로거의 마음을 움직이고 있습니다.

김윤수님께서 소스코드 복사의 위험성에 관해서 좋은 글을 써주셨습니다.

결함이 포함된 코드를 이 프로젝트 저 프로젝트에서 쓰다보면 예상치 못한 문제를 겪을 수 있습니다.

대표적인 사례로 아리안 5호 Flight 501의폭발사건을 살펴볼 수 있습니다.

1996년 6월 4일 Flight 501은 아리안5호 발사체로 처음 발사되었습니다. 그런데, 발사된지 37초만에 제어 소프트웨어의 오동작으로 인해 그만 궤도를 벗어나고 말았고, 결국 컴퓨터에서 초과된 고도 변경 명령을 내려 과도한 공기압력을 받아 폭발하고 말았습니다.

이 문제는 아리안5호가 Ada로 작성된 아리안4호의 일부 모듈을 그대로 재사용하며서 발생하였습니다.

문제가 된 모듈은 16비트 정수값을 처리할 때는 문제가 없으나 64비트 부동소수 값을 처리할 때, 그만 수치 오버플로우(numeric overflow)가 발생하였고, 이를 제대로 처리를 못해 문제가 발생한 것입니다.

아마 아리안4호에서는 16비트 정수값만 들어왔던 모양이고 문제가 없던 코드이니까, 개발자는 그대로 아리안 5호에서 사용했던 모양입니다. 그런데, 아리안 5호에 오면서 일부 스펙이 변경되면서 64비트 부동소수값이 들어왔던 것 같습니다. 스펙의 변경을 고려하지 않고 예전 코드가 잘 동작했으니까, 그대로 사용하가다 그만 허공에 3억7천만불을 날려버리고 만 것입니다.
코드 재사용해야합니다. 그러나 그냥 재사용하지 말고 꼼꼼히 살펴봅시다.

참고

http://en.wikipedia.org/wiki/Ariane_5_Flight_501