소프트웨어 개발에 있어서 데이터 관리가 차지하는 의미는 무엇일까? 임베디드 개발 환경에 주목하기에 앞서 범용 개발 환경에서 데이터가 차지하는 비중을 재점검해본다. 소프트웨어의 퍼포먼스를 좌우하는 가장 중요한 요소로 자료구조가 꼽힐 만큼, 어느 분야에서나 데이터의 관리방식은 개발자들에게 가장 커다란 과제가 되고 있다.

1997년 5월 21일 열린 리눅스 회의에서 에릭 레이몬드(Eric Raymond)는 Fetchmail 개발과 관련해 자신이 깨달은 효과적인 오픈 소스 활용 방법을 글로 정리해 발표했다. 이것이 그 유명한「성당과 시장(Catheral and Bazaar)」이라는 오픈소스 프로젝트인 Fetchmail을 수행하면서 습득한 19가지 교훈을 담고 있다. 이 글에 제시된 여러 교훈들 가운데 9번째 교훈이 특히 눈길을 끈다.

「자료구조를 훌륭하게 만들고 코드를 멍청하게 만드는 것이 그 반대의 경우보다 훨씬 잘 작동한다.」

클래스와 그에 속한 메소드를 이용하는 오브젝트 기반의 프로그래밍에 익숙한 프로그래머들에게 이 문장은 그리 새로운 내용이 아닐지 모르겠다. 하지만 프로젝트를 할 때 콘솔에「voidmain (void) {」를 입력하는 프로그래밍 방식에 익숙한 다수의 임베디드 시스템 프로그래머들에게 에릭 레이몬드의 이 교훈은 곰곰히 되새겨볼 만한 가치가 있다.

또한 이 글에 인용된 프레드 브룩스(Fred Brooks)의『The Mythical Man-Month』는 소프트웨어 프로젝트 관리에 관한 기념비적인 책으로, IBM System/360의 운영체제인 OS/360의 프로젝트 관리자로 일했던 저자가 그 과정에서 얻은 교훈을 에세이 형식으로 담은 것이다(이 책은 1975년에 처음으로 발간됐다).

특히 이 책의 9장에서는「Ten Pounds in a Five-Pound Sack」이라는 제목 아래, 프로그램이차지하는 공간(메모리)을 줄이는 방법을 고찰하고 있다. 이 장의 시작에는 다음과 같은 사례가 소개되어 있다. IBMAPL이라는 소프트웨어의 월 임대료는 400 달러이고, 이 프로그램은 160KB의 메모리를 이용한다.

만일 이 소프트웨어를 1KB의 메모리를 한 달간 이용할 때 12 달러의 사용료를 내는 Model165 컴퓨터에서 계속 사용하려 한다면, 매달 무려 1,920 달러(12×160)의 메모리 사용료를 지불해야 한다. 당시 메모리 사용량을 줄이는 일이 얼마나 중요했는지를 잘 보여주는 내용이다.

전통적인 과제
물론 이 책은 약 30여 년 전에 발간된 책이므로 하드웨어(메모리)나 소프트웨어를 임대하는 방식과 비용 등에서 지금과는 큰 차이가 있다.

아울러 현재는 개인 이용자의 컴퓨터 메모리 용량이나 소프트웨어 개발에 있어서 데이터 관리가 차지하는 의미는 무엇일까? 임베디드 개발 환경에 주목하기에 앞서 범용 개발 환경에서 데이터가 차지하는 비중을 재점검해본다.

소프트웨어의 퍼포먼스를 좌우하는 가장 중요한 요소로 자료구조가 꼽힐 만큼, 어느 분야에서나 데이터의 관리 방식은 개발자들에게 가장 커다란 과제가 되고 있다.

가격이 소프트웨어의 기능이나 유지보수성에 비해 상대적으로 덜 중요하게 여겨지는 점도 책이 만들어진 당시와는 다르다. 실제로 현대적인 소프트웨어 개발에 있어서 실행 메모리나 저장 메모리 등의 점유를 줄이려고 꽁수(?)를 쓰는 것보다는 사용자가 원하는 기능을 더 안정적으로 구현하고, 나아가 소프트웨어 자체의 업그레이드와 버그 수정 등이 용이하도록 프로그래밍을 하는 것이 훨씬 중요한 것으로 평가되고 있다.

필요에 따라 시스템의 메모리를 증설하고 심지어 프로세서 성능마저 쉽게 개선할 수 있는 지금의 일반 컴퓨팅 환경에서는 어찌 보면 당연한 모습이다.

그러나 휴대폰이나 자동차용 내비게이션, 그리고 가정용 디지털 TV와 같은 임베디드 소프트웨어 개발 환경에서는 이와는 다소 다른 관점에서 접근할 필요가 있다. 물론 이런 류의 디바이스를 위한 프로젝트에도 임베디드 리눅스를 활용하는 프로젝트 수가 점차 늘어나면서 범용 소프트웨어와 디바이스용 소프트웨어의 경계가 예전보다 많이 모호해지고 있는 게 사실이다.

그럼에도 임베디드 소프트웨어와 범용 소프트웨어간의 특성을 확연히 구분 짓는 한 가지 특성만큼은 여전히 변함이 없다. 그것은 바로 임베디드 디바이스의 하드웨어 스펙은 목적에 맞도록 한번 설계되면 그 변경이 쉽지 않다는 점이다.

곰곰이 한번 생각해보자. 현재 쓰고 있는 휴대폰에서 더 많은 응용프로그램을 실행하고 싶다고 전자상가 등에서 메모리를 구입해 실행 공간을 단숨에 늘릴 순 없다. 마찬가지로 집에 있는 디지털 TV의 전자 프로그램 가이드(EPG)가 느리게 동작한다고 해서, 가전제품 대리점에서 확장 메모리를 사서 설치할 수 없는 노릇이다.

물론 언젠가는 이런 일이 가능할지 모르겠지만 현재로서는 단지 농담처럼 느껴지는 설정이다. 이렇게 제품 개발 단계에서 전체 설계가 확정되는 프로젝트에서 효과적인 메모리 사용은 제품 생산 비용의 절감이라는 눈에 보이는 이유 외에 추후 지속적인 제품 업그레이드의 비용 절감이라는 2차적인 효과와도 밀접하게 연관되어 있다.

초기 모델을 시장에 발표한 후에는 버그 수정이나 성능 개선, 혹은 기능 추가 등의 이유로 후속 모델을 개발하게 된다. 이때 수정 및 추가되는 소프트웨어로 인해 시스템 메모리를 증설해야 할 경우에는 단순히 몇 MB에 해당되는 메모리의 추가 생산 비용뿐 아니라, 그로 인한 PCB 보드의 재설계와 하드웨어 테스트, 그리고 이와 관련된 다른 소프트웨어 모듈의 동작 검증까지 매우 다양한 추가 비용이 발생할 수 있다.

핵심은 데이터 구조
다시 브룩스의 책 9장으로 돌아가 보자. 저자는 메모리 사용량을 효과적으로 통제하는 방법과 관련해 여러 아이디어를 제시했는데, 제일 마지막 부분에 있는「Representation Is the Essence of Programming」이라는 절을 보면 다음과 같은 주장을 볼 수 있다.「(프로그램을 더 작고 빠르게 만들기 위한) 결정적인 해법은 종종 데이터나 테이블의 디자인을 다시 하는 작업에서 발견된다.

이곳에 프로그램의 핵심이 있다. 내게 프로그램의 흐름도를 보여주고 자료구조(테이블)를 숨긴다면 (프로그램의 동작을) 잘 이해하지 못할 것이다. 하지만 내게 자료구조(테이블)를 보여주면 대부분의 경우 프로그램 흐름도를 보지 않아도 (프로그램의 동작을) 쉽게 이해할 수 있을 것이다.」

30년 전의 이 책에서 저자가 강조하고 싶어 하는 내용은 여러 가지 다양한 테크닉이나 알고리즘을 이용해도 물론 프로그램이 차지하는 메모리를 줄일 수 있지만, 보다 근본적으로 프로그램의 핵심을 이루는 데이터 표현(구조)을 바꾸는 것이 보다 전략적인돌파구가 된다는 점이다.

요즈음에는 C++이나 자바, 혹은 다양한 스크립트 언어 기반의 웹 프로그램 개발을 통해 매우 빠르고 효과적으로 웹 기반 응용프로그램의 개발이 이뤄진다. 그러나 과거 필자가 학교에 다닐 때는 미련스럽게도 CGI 프로그램을 모두 C를 기반으로 작성했다(소학회 홈페이지의 게시판 프로그램을 C로 작성하면서 고생했던 기억이 여전히 생생하기만 하다).

당시 CGI의 동작 원리를 이해하고 나니, 대부분의 게시판 프로그램이 그렇듯 사용자가 올리는 게시물을 처리하는 것이 관리의 주를 이뤘다. 또한 게시판 사용 중에 발생한 각종 버그를 수정하거나 기능을 개선할 때마다 종전의 데이터 구조가 지닌 한계로 인해 새로운 데이터 구조를 만들어야 하는 일이 빈번했다.

그 과정에서 기존에 저장된 데이터와의 호환 문제가 불거졌음은 두말할 나위 없다. 추가적으로 기존 게시물의 변환을 위한 변환기를 만들면서 처음부터 효율적으로 설계된 데이터 구조가 얼마나 중요한지를 뼈저리게 느끼곤 했다.

현재 운영되는 대부분의 게시판들은 데이터베이스를 활용하고 있는 것으로 알려져 있다. 그 게시판의 소스가 스크립트 기반의언어로 만들어졌든, 혹은 객체지향 언어로 작성되었든 간에 데이터 관리는 전문 소프트웨어에 맡기는 구조로 되어 있는 것이다. 이는 너무나 당연한 변화의 과정이라 할 수 있다.

이어서 소개될 내용들은 디바이스용 임베디드 소프트웨어를 위한 데이터 중심의 개발 방법론에 관한 것으로, 개발자 모두가 함께 생각해 봐야 할 주제이다. @

참고자료
1. http://wiki.kldp.org/wiki.php/DocbookSgml/Cathedral-Bazaar-TRANS
2. The Mythical Man-Month, Frederik P. Brooks, Addision Wesley, 1995


* 이 기사는 ZDNet Korea의 제휴매체인 마이크로소프트웨어에 게재된 내용입니다.