[3부 1번 수필] 재사용: 소프트웨어 부품 - 노스텔지어와 데자뷰

소프트웨어 공장, 소프트웨어 재사용, 컴포넌트 기반 소프트웨어라는 용어를 전산 업계에 몸 담고 있는 사람들은 누구나 한번쯤 들어보았을 테다. 주기적으로 꼭 찾아오는 이런 유행이 어디서 시작되었는지를 알려주는 흥미로운 수필 한 편이 소프트웨어 컨플릭트 2.0에 실려있기에 무척 즐겁게 읽은 기억이 새롭다.

1950년대 IBM 컴퓨터를 다루던 개발자들은 난감한 상황에 직면했다. 요즘과 같은 막강한 프로그래밍 환경(다양한 잡지/책/논문, 소프트웨어 분리판매/끼워팔기)이 없었기에 프로그램 작성에 필요한 자료를 구할 길이 막막했기 때문이다. 이런 어려운 상황을 극복하기 위해 상부상조하는 정신에 입각해서 각 프로그래머들이 자신이 만든 소프트웨어 코드를 기부하고 문서화시켰는데... 바로 SHARE의 시작이었다.

SHARE는 당시 IBM 컴퓨터 사용자(프로그래머)들이 자발적으로 만든 사용자 그룹이다. SHARE에 속한 사람들은 자발적으로 소프트웨어 루틴을 기부해서 이를 라이브러리화시킨 다음에 원하는 사람이면 누구나 라이브러리에 들어있는 코드를 재사용하도록 환경을 조성해주었다. SHARE에서 가장 흥미로운 사실은 SHARE 라이브러리 명세를 보면 항상 만든 개발자 이름과 소속이 나와있다는 점이다. 가상 인터뷰에서 소개하는 대화 일부를 볼까?

로버트 글래스: "소프트웨어 부품이 도움이 되나요?"(코드에 책임을 지지 못한다는 면책 조항이 마음에 걸려서 근처에 있는 프로그래머에게 물어본다.) 프로그래머: "그럼요, 거의 항상. 정말 인정하기 싫지만, 코드를 읽어보면 제 실력보다 훨씬 뛰어납니다. 졸작을 SHARE에 기부하는 사람들은 거의 없습니다. 너무 위험하거든요. 누군지 금방 들통나죠."

잡지도 논문도 책도 없는 상황에서 그 당시 소프트웨어 개발자로 우뚝 솟으려면 SHARE 참여만이 명성과 특권을 누리는 지름길이었다. 한마디로 SHARE에서 명성을 쌓기 위해 개인적인 이기심을 최대로 발휘한 결과 이타적인 결과를 얻은 셈이다.

하지만 왜 SHARE라는 좋은 시스템이 죽어버렸을까? 바로 소프트웨어 제작이 복잡해졌기 때문이다. I/O나 수학 라이브러리 같은 루틴이야 SHARE로 충분히 버틸 수 있었지만, 운영체제와 같이 너무나도 복잡한 시스템은 SHARE와 같이 자발적인 참여만으로 진행하기에는 너무 덩치가 큰 소프트웨어였다. 결국 개발자들은 회사에 소프트웨어를 만들어달라는 압력을 넣었고, 여기에 굴복한 회사가 소프트웨어를 제공하기 시작하면서부터 SHARE는 서서히 와해되기 시작했다. 결국 수학 라이브러리와 같은 몇 가지를 제외하고는 소프트웨어 부품이라는 개념이 자취를 감추게 되었다. 오호통제라!

하지만 현대판 SHARE 프로젝트가 다시 한번 등장하기 시작했다. 바로 오픈소스 운동이다. 앞서 운영체제와 같은 복잡한 소프트웨어를 기업에 의존하기 시작하면서 SHARE라는 공동체가 붕괴되기 시작했다고 말했는데, 역설적으로 오픈소스 운동은 리눅스라는 운영체제가 갖춰지기 시작하면서부터 급속도로 팽창하기 시작했다. 전 세계에 흩어져 있는 개발자들이 자신의 이름이 리눅스 운영체제에 등장하기를 갈망하면서 자발적으로 각종 코드를 기부하기 시작했고, 운영체제를 넘어서 웹 브라우저와 같은 엄청나게 복잡한 응용 프로그램 개발도 이런 흐름에 동참함으로써 제 2의 SHARE 프로젝트 전성 시대가 열린 상황이다. 결국 문명의 발전은 자아 실현이라는 개인의 동기에 의해 움직인다는 사실을 다시 한번 확인해주었다.

로버트 L. 글래스는 이 수필을 다음과 같이 말하며 끝낸다.

1950년대에 일어났던 상황의 데자뷰이다. 과거에도 일어났으니 지금도 가능하다. 단지 그렇게 하기만 하면 된다.

정말 놀라운 통찰력이 아닌가?

"소프트웨어 컨플릭트 2.0: 시대를 뛰어넘는 즐거운 논쟁" 역자 박재호 올림