neolith의 방
![[레벨:13]](http://old.lameproof.com/modules/point/icons/default/13.gif "포인트:16257point (43%), 레벨:13/30"){kind=icon}
neolith![[레벨:0]](http://old.lameproof.com/modules/point/icons/default/0.gif "포인트:0point (0%), 레벨:0/30"){kind=icon}
1061. 소프트웨어를 잘 만들려면 어떻게 해야 할까?
컴퓨터가 발명된 이래로, 프로그래머들은 어떻게 하면 프로그램을 더 잘 만들 수 있을까에 대해 고민해왔다. 초기에 베이직이나 코볼, 포트란으로 프로그램을 만들던 시절에는 ‘서브루틴’이라는 개념을 이용했고, 씨와 파스칼의 시대에는 모듈화라는 개념을, 그리고 c++ 의 시대에는 OOP의 개념을, 그리고 디자인 패턴과 컴포넌트 단위의 개발, 리팩토링, 테스트위주 개발에 이르기까지에 소프트웨어를 잘 만들기 위한 방법은 꾸준히 변화해왔다.
그러한 변화의 흐름속에서도 한가지 변하지 않은 기준이 있다. 그것은 바로 ‘Divide and Conquer’ 라는 것이다. 완성된 소프트웨어라는 복잡한 목표를 달성하기 위해서는 어떻게 해서든 문제를 좀 더 작고 다루기 쉬운 단위로 나누어야 했고, 그 단위가 ‘서브루틴’, ‘모듈’, ‘객체’, ‘컴포넌트’ 등으로 변천을 거친 것이다. 물론 나누는 것만이 소프트웨어 공학의 전부는 아니고, 나눠진 것을 어떻게 조합할 것인가에 대한 것도 중요한 부분이라고 하겠지만, 어쨌든 소프트웨어의 부품이 이미 나눠져 있어야 그것을 조합할 수 있다는 것을 감안한다면, 앞으로 소프트웨어 공학이 어떻게 발전해갈지는 예측하기 어렵지만, 소프트웨어 공학의 본질에는 ‘Divide And Conquer’ 라는 개념이 빠질 수는 없을 것이다.
그런데 문제는 소프트웨어를 나누는 방법은 한가지 방법만이 존재하는 것이 아니라, 실로 다양한 기준과 관점이 존재한다는 데에 있다. 어떤 기준과 목적을 가지고, 어떻게 나누느냐라는 것이 소프트웨어 엔지니어링의 본질이라고 보아도 과언이 아닐 것이다.
현대 소프트웨어 개발의 가장 큰 도전과제는 ‘대형, 복잡화’와 ‘요구사항의 변동’ 이 2가지로 크게 나눌 수 있다. 이 2가지 과제에 잘 대처할 수 있는 소프트웨어를 만들 수 있도록 소프트웨어를 잘 나누어 놓는 것이 우리가 접근해야 할 길이며, 이 글에서는 그 해결방법으로서 ‘변동성 중심의 디자인’ 해결방식을 제안할 것이다.
옛날의 소프트웨어 개발과 현재의 소프트웨어 개발의 가장 큰 차이점은 대형화, 복잡화라고 할 수 있다. 옛날에 80년대 컴퓨터들은 1Mhz 의 처리속도에 64Kb 의 메모리 용량을 가진 것이 보통이었다면, 지금은 3Ghz의 처리속도에 1GB 의 메모리 용량을 가진 것이 보통이 되어버렸다.
하드웨어가 발전하다보니 소프트웨어도 그만큼 발전을 하게 되었다. 컴퓨터의 성능이 남아돌게 되면서 예전에는 생각도 하지 못했던 기능들이 요즘에는 당연하게 기본기능들로 포함되고 있다. 컴퓨터의 가장 큰 용도중 하나인 워드프로세서의 경우를 보면 80년대에 가장 널리 쓰였던 워드프로세서의 경우 디스켓 한두장 분량에 들어가던 것이, 요즘 가장 널리 쓰이는 오피스류는 씨디롬 한장에 꽉 차게 되었다. 게임 같은 경우는 더 심해서 DVD 한장을 채우고도 남는 게임들도 종종 보이게 되었다. 기존에는 일반용 소프트웨어와 대형 (Large scale) 소프트웨어를 구분하는 것이 의미가 있었지만, 근래에는 대형소프트웨어라는 의미 자체가 무색해졌다. 모든 소프트웨어가 대형소프트웨어가 되어버렸기 때문이다. 그러다보니 업계경력이 10년 이상인 베테랑 프로그래머나, 이제 업계에 발을 들인 신입 프로그래머나 모두 똑같이 대형 프로그램을 짜는 법을 알아야만 하는 현실이 된 것이다. 심지어는 임베디드 환경 조차도 예전과 다르게 플랫폼이 점점 복잡화되고 있다.
대형 프로그램을 짜는 데에는 여러명의 공동 작업이 필수적이다. 예전에는 한 명의 천재 프로그래머가 대단한 프로그램을 만들어내는 것이 가능했고, 또 보통 소프트웨어는 그런식으로 만들어졌었다. 하지만 지금은 혼자서 대형 프로그램을 완성할 수 있는 경우는 드물다.
그런데 팀작업에는 한계가 있다. 프레드릭 브룩스가 그의 저서 The Mythical Man-month 에서 밝힌 것처럼, 소프트웨어를 만들 때에는 사람을 더 많이 투입할수록 그에 비례해서 개발기간이 단축되지 않는다. 그 이유는 작업자간의 커뮤니케이션 오버헤드는 사람이 많아질수록 기하급수적으로 늘어나기 때문이다. 팀작업을 하다 보면, 차라리 혼자 짜는 것이 낫겠다라는 푸념을 하게 되는 경우가 생기는 것이 그런 실제 예라고 할 수 있을 것이다.
처음에 말했듯이, 소프트웨어 공학의 원점은 Divide and conquer 이다. 소프트웨어를 어떻게 나눠야 사람들 간의 커뮤니케이션 오버헤드가 줄어들 수 있을 것인가? 이것은 대형 소프트웨어를 만드는 사람이라면 누구나 고민해보아야 할 주제이다.
2. 요구사항의 변동
커뮤니케이션이라는 것이 문제가 생겼을 때 모든 것을 정리해서 한번만 커뮤니케이션을 하고 끝낼 수 있는 성격의 것이라면, 아마 세상만사에 힘든 일이란 아무것도 없었을 것이다. 커뮤니케이션은 지속적으로 일어날 수 밖에 없다. 왜냐 하면 문제란 항상 변하기 때문이다.
어떤 특정한 고객의 요청을 받고 소프트웨어를 만들건, 기획팀이 대중들의 필요를 예상해서 소프트웨어를 설계하건, 프로그램팀 안에서 한쪽 모듈을 만드는 팀이 다른쪽 모듈을 만드는 팀에게 요청을 받아 모듈을 만들어주건, 모든 요청은 처음 한번으로 완벽하게 정해지고 끝나는 경우는 거의 없다. 왜냐하면, 문제해결의 과정에는 피드백이 계속 새로운 문제를 밝혀주기 때문이다. 어떤 문제가 제기 되어서 그에 대한 해답이 나왔다고 해도, 그 해답을 문제에 대입하면 새로운 문제를 발견하게 되는 것이 보통의 경우이기 때문이다.
요구사항의 변동은 결국 소프트웨어의 변동을 의미하고, 재작업 혹은 추가작업을 의미하게 된다. 하지만 소프트웨어를 어떻게 구성했느냐에 따라 요구사항의 변동이 생겼을 때 추가작업의 양은 많을 수도 있고, 적을 수도 있다. 소프트웨어를 어떻게 나눠야 요구사항의 변동에 더 쉽게 대응할 것인가? 이것이 이 글에서 논하고자 하는 문제의 요지이다.
다소 엉뚱하긴 하지만 자동차의 예를 들어보도록 하겠다. 차를 몰고 운전을 하다보면 이따금씩 벽이나 다른 자동차와 부딛혀서 긁히는 경우가 종종 있다. 그런데 대부분의 긁히는 부분은 범퍼에 해당되기 때문에, 많이 긁혔다고 하면 범퍼만 교환하면 된다. 범퍼는 재질이 철판이 아니고 더 싼 수지로 만들어져 있기 때문에 범퍼를 교환하는 비용은 다른 차체를 교환하는 비용에 비해 훨씬 싸다.
그런데 어떤 자동차가 있는데 범퍼와 차체의 구분이 없이 통째로 철판으로 만들어진 자동차라면 어떨까? 그런 자동차라면 앞부분을 살짝 긁혀도 범퍼만 가는 것으로 해결되는 것이 아니라 차체를 완전히 통째로 갈아야 하니 운전하는데 너무나 부담이 많이 될 것이다. 소비자의 입장에서는 두가지 차가 있는데 가격과 성능이 똑같다면 당연히 범퍼가 나뉜 쪽을 선호할 것이다. 소나타나 그랜져 같은 차는 여기에 한층 더 나아가서 범퍼 자체도 자주 긁히는 모서리쪽과 안쪽을 나눠서 모서리쪽에는 간단히 갈아낄 수 있는 다른 재질로 만들어놓았다. 웬만한 모서리는 긁게 되도 범퍼조차 갈지 않아도 되니 훨씬 더 경제성이 높아진 디자인이라고 할 수 있을 것이다.
위의 사례에서 접촉사고는 요구사항의 변동을 비유한 것이다. 접촉사고는 범퍼의 모서리, 범퍼, 차체의 순으로 빈도가 낮아진다. 소프트웨어를 만들 때에도 마찬가지로 모든 부분에 대해 요구사항이 변동되는 빈도가 같은 것이 아니라, 어떤 부분은 자주 변하는 반면, 어떤 부분은 자주 변하지 않는다. 그렇다면 소프트웨어를 어떻게 나눠야 할까? 답은 명백하다. 자주 바뀌는 부분과 자주 바뀌지 않는 부분을 경계로 나누어야 한다. 그렇게 했을 때 요구사항의 변동이 생기더라도(이것은 피할 수 없는 것이다), 그에 대한 대응이 훨씬 더 쉽고 빨라지는 것이다. (범퍼의 모서리만 바꾸는 것, 범퍼를 바꾸는 것, 차체를 통째로 바꾸는 것을 각각 비교해서 생각해보라)
3. 변동성의 원칙
모든 소프트웨어는 요구사항의 변동이 생길 수 있다. 요구사항의 변동 가능성을 간단히 줄여서 ‘변동성’ 이라고 부르기로 하자. 이 변동성에 대해서는 몇가지 간단한 규칙들이 존재하는데 이것들을 알아보기로 하자.
l
소프트웨어의 각 요소의
유지 보수 비용은 변동성과 크기를 곱한 것이다
(크기가 큰 것이 변동성도 높다면 전체적인 유지보수 비용은 그 크기와 변동성에 각각 비례할 것이다)
l
프로젝트 전체의 유지
보수 비용은 소프트웨어 각각 요소의 유지 보수 비용을 합한 것이다
l
하나의 소프트웨어
요소 안에 변동성이 높은 부분과 변동성이 낮은 부분이 섞여 있으면, 전체 요소의 변동성은 높은 것으로
결정된다.
위의 경우는 자동차 범퍼의 예를 생각해보면 쉽게 이해가 갈 것이다. 차체와 범퍼가 구분되어 있지 않으면, 범퍼의 교체 비용이 차체까지 확산되는 것이다.
위의 3가지 사항을 합쳐서 생각해보면 한가지 결론에 도달 할 수 있다. 프로젝트 전체의 유지 보수 비용을 낮추기 위해서는 변동성이 높은 부분과 낮은 부분을 올바르게 나누어야 한다는 것이다.
숫자를 가지고 예를 들어보겠다. 소프트웨어 프로젝트를 A 파트와 B 파트로 나눌 수 있는데, A 파트의 크기는 10, 변동성은 20 이라고 하고, B 파트의 크기는 30, 변동성은 15 이라고 하자. 이 상태에서의 유지보수 비용은 10*20 + 30*15 = 650으로 계산할 수 있다. 만약 A 와 B 가 나뉘어지지 않았다면 크기는 10+30 = 40, 변동성은 20 (20 과 15중 큰 것)이 되므로 유지보수 비용은 40*20 이 되어 800 이 된다.
그렇다고 해서 무조건 잘게 쪼개는 것만이 능사는 아닐 것이다. 소프트웨어를 쪼갤 때마다 조금씩 오버헤드가 생기기 때문에 너무 많이 쪼개는 것도 좋지 않다. 아까 자동차의 예로 돌아가서 생각해도 마찬가지다. 보통 자동차는 10장 내외의 철판, 범퍼등의 파트로 나뉘어져 있다. 만약 100 장 이상의 철판으로 잘게 나뉘어진 자동차를 상상해보라. 아마 자동차가 아니라 누더기가 되지 않을까?
l
변동성이 낮은 것이
변동성이 높은 것에 의존하면, 변동성이 낮은 것의 변동성이 그만큼 높아진다.
소프트웨어를 디자인하다 보면, 클래스 A가 클래스 B 를 의존 (참조, 상속, 등등) 할 것인가, 아니면 반대로 B 가 A 에 의존하게 할 것인가, 아니면 다른 C 를 두어서, A 와 B 가 C 에 의존하게 할 것인가 같은 고민을 하게 되기 마련이다. 올바른 의존관계를 정의하는 데에 변동성은 이와 같이 좋은 기준이 될 수 있다.
변동성의 성격이 다른 부분이 섞인다는 것은 구체적으로 참조, 상속들의 의존관계가 맺어진다는 것을 의미한다. 의존관계는 변동성을 ‘전염’시킨다는 점은 매우 중요하다
l
변동성의 성격이 다른
부분이 상호 의존하게 되면 전체 요소의 변동성은 다른 변동성간의 조합만큼 높아진다
변동성을 고려할 때 단순하게 한 가지가 높다 낮다로서 판단될 수 있는 것은 아니다. 만약 변동성이 높은 요소 2가지가 혼재되어 있는 경우가 된다면 결과는 그 조합이 된다. 예를 들어 서로 다른 변동성이 10씩인 부분이 적절한 분리 메커니즘 없이 합쳐진다면 총 변동성은 10+10 = 20 이 아니라 10*10 만큼 높아진다는 점이다. 이런 경우의 디자인 목표는 어떻게 10*10 의 복잡도를 10+10의 복잡도로 낮출 것인가가 가장 중요한 이슈가 된다. 이후에 예제로 보는 부분들에서 그러한 복잡도를 낮추는 방법들을 구체적으로 알아볼 것이다.
l
변동성이 높은 부분은
재사용하기 어렵고, 변동성이 낮은 부분은 재사용하기 쉽다
OOP 를 비롯한 소프트웨어 공학의 근본목표는 소프트웨어 개발 비용을 줄이자는 것이고, 개발비용을 줄이는 방법으로는 소프트웨어 재사용을 장려하는 것이다. 그렇다면 재사용을 제대로 하기 위해서는 먼저 변동성에 대해 이해하는 것이 필요한 것이다.
변동성이란 개념은 아주 일반적인 개념이며, 자동차 범퍼의 예에서도 볼 수 있듯이 다른 일상 생활에서도 조금만 생각을 해보면 흔히 보거나 응용해볼 수 있는 개념이다. 책상정리를 할 때도 자주 사용하는 (변동성이 높은) 물건을 손 닿는 곳 가까이에 두고, 자주 사용하지 않는 (변동성이 낮은) 물건을 깊숙한 곳에 넣어두게 되는 습관이나 컴퓨터의 메모리나 CPU 에서 캐쉬메모리의 개념도 마찬가지로 변동성의 관점에서 생각해볼 수 있을 것이다.
4. 변동성의 분리 사례
지금까지 소프트웨어를 만드는 데에 소프트웨어를 부분별로 나누는 것이 왜 중요하고, 또 변동성이라는 개념이 소프트웨어를 나누는데 왜 중요한지에 대해 알아보았다. 이제부터는 좀 더 구체적인 실제 사례를 가지고 생각해보도록 하자. 위에서 언급했듯이, 변동성은 일반적인 개념이고, 사실 지금까지 당연히 쓰이고 있던 여러가지 컴퓨터 프로그래밍에 관련된 것들 속에도 변동성의 개념이 응용되고 있다는 점을 살펴보자.
i) 헤더파일과 소스파일의 분리
C 언어로 프로그램을 짜게 되면, 보통 헤더파일과 소스파일을 나눠서 짜게 된다. 어떤 기준에 의해서 헤더 파일에 들어갈 내용과 소스 파일에 들어갈 내용이 나뉘게 되는 것일까?
헤더파일을 나눈 이유는 다른 소스 파일들에서 공통으로 참조를 하기 위해서 나눠놓은 것이다. 이것은 다르게 말하면 소스파일들은 헤더파일에 같이 의존하고 있다고 할 수 있다. 변동성의 규칙중 의존에 대한 부분이 기억나는가? 변동성이 높은 것이 변동성이 낮은 것에 의존해야 유지보수비용이 낮아진다. 따라서 헤더파일에는 변동성이 낮은 내용(한마디로 자주 안 바뀌는 내용)이 들어가고, 소스파일에는 변동성이 높은 내용이 들어가야 한다.
이것을 지키지 않고, 단지 여러군데에서 공통으로 참조하기 쉽게 만들어버리면, 사소한 내용 하나를 바꿀때마다 관련된 모든 소스들이 재컴파일되므로, 빌드시간이 점점 늘어나게 된다. 빌드시간이 늘어나는 것을 해결하기 위한 올바른 해결책은 더 빠른 컴퓨터를 사용하거나 IncrediBuild 를 사용하는 것이 아니라, 변동성을 기준으로 헤더와 소스를 나누는 것이어야 한다. John Lakos 가 Large Scale Software Design in C++ 에서 말하고자 하고 싶었던 내용이 결국 이 변동성에 대한 이야기인 것이다. 지금 당장 여러분 프로젝트의 헤더 파일을 잘 살펴보고, 변동성이 높은 부분이 들어있다면, 그것을 반드시 소스파일로 내려보내도록 하라. 그렇게 하기 위한 방법들은 여러가지가 있다.
ii) 외부용소스와 내부용소스의 분리 – 추상 인터페이스 or Pimpl idiom
여러분의 프로젝트는 추상인터페이스를 사용하고 있는가? 추상인터페이스 자체는 간단한 개념이다. 어떤 라이브러리에 사용되는 파일들 (소스와 헤더파일들)을 내부용과 외부용으로 분리하고 그 라이브러리를 사용하는 쪽에서는 외부용 파일만 참조하도록 만든 것이다. 내부용과 외부용은 물리적으로 아예 폴더 자체를 구분해 놓아야 한다. Directx 라던가 기타 라이브러리화가 잘 된 외부라이브러리를 보면 include 폴더와 src 폴더 (소스가 제공되지 않는 경우는 lib 폴더나 bin 폴더) 로 나뉘어져 있고 다른 소스는 include 폴더만 보면 되도록 구성되어 있다.
여기서 다시 질문, 라이브러리를 디자인 할 때, 어떤 파일이 내부용 폴더(src) 에 들어가고, 어떤 파일이 외부용 폴더(include) 에 들어가야 할 것인가? 역시 그에 대한 해답의 열쇠는 ‘변동성’의 개념이 쥐고 있다.
일단 소스 파일들은 변동성이 높은 것들이라는 점을 위에서 말한 바 있다. 그러니 모든 소스 파일들은 내부용 폴더에 넣고, 외부의 사용자들은 신경쓰지 않게끔 만들어야 한다.
그 다음은 헤더파일들이다. 헤더파일들이 모두 외부용 폴더에 들어가게 만들 수도 있다. 하지만, 모든 헤더파일들이 외부의 사용자들에게 꼭 필요한 것은 아니다. 외부의 사용자들은 ‘내부가 어떻게 구현되었는가’ 보다는 ‘어떻게 사용하면 되나’ 만 알면 되기 때문이다.
‘어떻게 사용하면 되는가?’ 라는 것이 바로 인터페이스(Interface)이고, ‘내부가 어떻게 구현되었는가?’ 는 바로 구현(Implementation) 이다. 인터페이스와 구현중, 어떤 것이 변동성이 높고, 어떤 것이 변동성이 낮아야 할까? 물론 인터페이스가 낮고, 구현이 상대적으로 높아야 한다.
만약에 인터페이스의 변동성이 더 높다고 하면 아직 인터페이스가 안정화되지 못한 상태 아니면, 인터페이스를 잘못 만든 경우 둘중의 하나라고 볼 수 있다.
추상 인터페이스는 하나의 클래스를 인터페이스 (흔히 I 로 시작되는 클래스명) 와 구현 클래스 (흔히 C 로 시작되는 클래스명) 로 분리해서, 외부의 사용자는 인터페이스만 include 해도 되도록 만드는 기법이다. 만약에 인터페이스와 구현을 클래스를 분리해놓고도 물리적으로 폴더를 나눠놓고 외부헤더만 액세스하고 있는 것이 아니라면 추상 인터페이스를 제대로 쓰지 못하고 있는 것이다 (필자가 본 중에는 그런 케이스가 있었다)
추상인터페이스 라는 기법 자체는 외부폴더와 내부폴더를 나누기 위한 방법(물론 전체적인변동성을 낮추기 위한)중 하나에 불과한 것이다. 추상 인터페이스는 클래스의 ‘상속’을 이용해서 구현과 인터페이스를 분리한 것이라면 Pimpl 방식은 클래스의 ‘조합’을 이용하여 구현과 인터페이스를 분리한 것이며, 본질적으로는 동일한 목적과 유사한 결과를 가져다준다.
iii) 데이터 타입과 알고리즘 코드의 분리 - Template
어떤 알고리즘과 그 알고리즘의 대상이 되는 데이터 타입도 마찬가지로 나눠놓게 되면 각각의 경우에 따라 변동성을 낮출 수 있다. 예를 들면 정수를 대상으로 퀵소트를 하는 함수를 만들었다고 하자. 퀵소트의 알고리즘 자체가 변동성이 높은가? 정수라는 타입의 변동성이 높은가? 퀵소트를 놓고 보면 당연히 정수라는 타입의 변동성이 높다. 퀵소트의 구현 방법 자체는 수십년전에 만들어져서 지금까지 거의 비슷하게 사용되고 있는데, 퀵소트의 대상은 정수, 실수, 문자열등 다양한 대상이 될 수 있다. 퀵소트뿐만 아니라 어떤 일반적인 풀이법을 놓고 볼 때 알고리즘과 데이터는 서로 변동성이 다르기 때문에 분리할 수 있다면 알고리즘 자체의 재사용성을 높일 수 있다. 이 경우에는 한쪽의 변동성이 높고, 다른 한쪽의 변동성이 낮은 경우라기 보다는 서로 성격이 다른 변동성이 조합되는 경우로 보아야 할 것이다.
자 그러면 여기서 퀴즈. C++ 이 제공하는 알고리즘과 타입을 분리하는 메커니즘은 무엇일까?
정답은 ‘템플릿’이다. 템플릿은 generic programming 의 가장 중요한 도구이다. Generic 은 말 그대로 프로그램에서 일반적으로 사용될 수 있는 요소를 추출해내서 그 부분을 모아놓는 것인데, 여기서도 변동성의 개념이 연관되어 있는 것을 알 수 있다.
이러한 알고리즘들을 변동성이 높아지지 않는 형태로 재사용하는 사례중 가장 대표적인 것은 STL 이 제공하는 각종 알고리즘들이다. STL 이 제공하는 알고리즘을 사용하기 위해서는 아무 데이터 타입을 넣을 수 있는 것은 아니고 몇가지 요구조건을 만족해야 하는데, 대표적인 것이 ‘<’ 연산자를 정의하는 것이다. 연산자 혹은 Functor 라는 ‘중간 방벽’을 둠으로써, 알고리즘이 달라지건, 알고리즘이 다룰 데이터 타입이 달라지건 그 조합만큼 코드가 늘어나는 것을 피할 수 있다는 것이 STL 알고리즘의 가장 큰 장점이다
iv) 데이터와 코드의 분리 – Data-driven design
데이터와 코드, 둘중 변동성이 높은 것은? 데이터다. 그렇다면 데이터와 코드를 분리하면 변동성이 낮아지고 유지보수에 도움이 될까? 물론이다. 우리는 그것을 ‘Data-driven Design’ 이라고 부른다.
모든 데이터가 처음부터 코드와 분리되어 보이는 것은 아니다. 숫자나 문자열이라고 해서 모두 데이터는 아니기 때문이다. 코드에서 모든 데이터를 어떤 기준없이 죄다 빼내려고만 한다면, 무엇이 목표인지 조차 모호하게 되어버릴 것이다. 데이터를 나눠내는 그 기준은 물론 변동성이어야 한다. 같거나 비슷한 코드에 데이터만 바뀌어가면서 반복되는 부분, 바로 그런 부분을 추려내는 작업은 리팩토링의 큰 부분을 차지한다.
v) 스크립트 코드와 소스 코드의 분리 – Lua, Python, …
코드중에도 명백히 변동성이 높은 코드가 있는가 하면, 변동성이 낮은 코드가 있다. 변동성이 높아서 Data 로 분리하고 싶긴 한데, 단순한 데이터가 아니라 어느정도 판단 로직이 있기 때문에 데이터로는 분리하기 쉽지 않은 그런 것들은 어쩔 수 없이 코드의 형태로 존재할 수 밖에 없는 것들이다.
가장 대표적인 예는 RPG 에서 NPC 의 대사 스크립트 같은 부분들이 될 것이다. 어떤 물건을 가져왔으면 A 이벤트로 넘어가고, 그렇지 않으면 B 로 넘어가게 만드는 그런 코드들과 화면에 물체를 그리고 키보드 입력을 받는 그런 코드들은 근본적으로 변동성이 다를 수 밖에 없다.
이러한 변동성이 높은 코드들이 소스 안에 변동성이 낮은 코드들과 함께 존재한다면 역시 프로젝트의 유지보수비용이 증가하게 된다. 그 해답은 바로 ‘스크립트 분리’ 이다.
vi) 패턴화된 코드의 집합과 어플리케이션 특정 코드의 분리 – 프레임워크
윈도우 프로그래밍의 세계를 접하게 되면서 프로그래머들은 많은 어려움을 느끼게 되었다. 단적인 예로 Hello world 같은 프로그램을 만드는 데에 DOS 같은 경우는 몇줄이면 충분했지만 윈도우의 세계로 오면서 몇줄은 커녕 몇백줄의 복잡한 windows API 를 제어하는 코드를 Event-Driven 이라는 기존과는 다른 생소한 방식으로 짜야만 했다. 그에 따르는 복잡도의 증가와 개발의 어려움이 이만저만이 아니었기에 OWL 이나 MFC 같은 프레임워크가 등장하여 프로그래머의 어려움을 덜어주었다.
프레임워크는 복잡한 윈도우 응용 프로그램의 소스코드중에서도 자주 바뀌는 부분과 자주 바뀌지 않는 – 그래서 재사용가능한 – 부분이 있다는 통찰에서 비롯된 산물이다. 물론 프레임워크 자체도 변동성이 낮다고는 볼 수 없다. MFC 같은 라이브러리도 컴파일러가 바뀌면서 계속 변화하고 발전해왔다. 하지만 어플리케이션 자체보다는 상대적으로 변동성이 낮았기 때문에 프레임워크로서의 가치가 있었던 것이다.
SideNote
![[레벨:2]](http://old.lameproof.com/modules/point/icons/default/2.gif "포인트:557point (43%), 레벨:2/30"){kind=icon}
eriastoa![[레벨:4]](http://old.lameproof.com/modules/point/icons/default/4.gif "포인트:1983point (67%), 레벨:4/30"){kind=icon}
강홍기