[TMMM] #9. 5파운드 자루에 담은 10파운드

문연수·2022년 10월 28일

TMMM

목록 보기

9/17

1. 프로그램 공간도 비용이다.

프로그램 크기는 사용자가 지불해야 하는 비용 중에서 많은 부분을 차지하므로, 하드웨어 제작자가 부품 개수에 대한 목표치를 세우고, 부품 수를 통제하며, 개수를 줄일 방법을 모색하듯이, 프로그래밍 시스템의 구현자 또한 크기에 대한 목표치를 세우고, 그것을 통제하며, 크기를 줄일 기법을 개발해야 한다.

과거에는 그랬을지 모르겠지만 현대에는 전혀 아니다. 메모리와 속도를 교환할 수 있다면 대체로 교환하는 것이 옳다.

2. 크기의 통제

상주 공간만이 아니라 '전체' 공간의 크기를 가지고 예산을 배정하라. 크기뿐 아니라 보조 저장 장치 접근 비도에도 제한을 두라.
어떤 모듈의 크기를 지정할 때는 그 모듈이 할 일도 정확히 정의하라.
전체적인 관점으로 시스템을 바라보며 사용자 중심의 태도를 가지도록 장려하라.

이 또한 너무 구시대적인 통제이다. 1번의 경우가 그나마? 주목할만하다. 제어 프로그램 모듈들이 제각기 엄청난 양의 디스크 접근을 수행하므로써 페이지 스래싱(page thrashing)과 상당히 비슷한 양상을 보였다고 하는데 이런 문제는 고려해볼 수도 있을 것 같다.

3. 공간 절약에 관한 기법들

- 기능 대 공간 교환

사용자에게 선택 가능한 기능을 다수 제공하도록 프로그램을 설계함으로써 메모리 사용과 기능을 교환할 수 있다. 그러나,선택적 기능을 어떻게 묶든 간에, 프로그램에 일체화하는 편이 공간을 덜 차지함은 자명하다.

다양한 메모리 크기에 대응하는 시스템을 설계하는 경우에 발생하는 또 다른 문제는 제한 효과로 인해 적정 메모리 범위를 마음대로 설정할 수가 없게 된다는 것이다. 메모리가 가장 적은 시스템에서는 모듈 대부분이 오버레이로 동작할 것이며 이 시스템의 상주 메모리 중 상당 부분은 다른 코드를 적재하기 위한 페이징 영역으로 할당되어야 하는데, 이 영역의 크기가 모든 모듈의 크기를 결정하게 된다.

솔직히 메모리 오버레이를 정확하게 이해하지 못해서 무슨 뜻인지 알 방도가 없으나 메모리가 작은 시스템에서는 오버레잉을 위해 모듈을 더 잘게 쪼개므로, 모듈이 많아지면 실제 메모리 사용량에는 별 차이가 발생하지 않을 수도 있다는 말인 것 같다.

더 자세한 정보는 다음을... https://ko.wikipedia.org/wiki/오버레이_(프로그래밍).

- 시간 대 공간 교환

어떤 기능에 더 많은 공간을 할당한다면 더 빨리 수행될 수 있다. 이 사실은 놀랄 만큼 다양한 범위에 대해 성립하며, 공간에 할당량을 배정하는 것이 실제로 효과를 얻는 것은 이 때문이다.

속도와 크기 사이에서 적절한 타협점을 찾도록 관리자가 팀을 도울 수 있는 일이 두 가지 있다:

그들이 타고난 이해력과 이전의 경험에만 의존하도록 내버려두지 않고 적절한 프로그래밍 기법에 대해 훈련을 받게 하는 것이다. 새로운 언어나 장비를 사용할 경우 이것은 특히 중요하다.
프로그래밍 기술 개발이 필요하며, 기본적인 구성 요소(적절한 자료구조)들을 마련해 둘 필요가 있음을 깨닫는 것이다.

4. 표현 방법은 프로그래밍의 정수

장인적 기교의 너머에는 창조적 발명의 영역이 있다. 군더더기 없고 빠른 프로그램들은 바로 여기에서 태어난다. 이 프로그램들은 전술적 영리함보다도 전략적이고 획기적인 발전의 결과물인 경우가 대부분이다.

하지만 획기적인 발전은 데이터나 테이블을 새롭게 표현하는 것에서 비롯되는 경우가 훨씬 더 많다. 프로그램의 핵심이 바로 여기에 있다. 순서도에서 테이블을 감추면 이해하지 못하는 내용도, 테이블만 보여준다면 순서도는 중요하지 않게 된다. 보지 않더라도 명백하기 때문이다.

공간 부족 때문에 골머리를 앓는 프로그래머라면, 스스로를 코드로부터 해방시킨 다음 한 발짝 뒤에서 데이터를 바라봄으로써 종종 최상의 결과를 얻을 수 있다.