숙련된 프로그래머들은 자신만의 전문화된 개발 도구(편집기, 정렬 기법, 이진덤프) 등을 자기 파일 속에 몰래 숨겨둔다. 하지만 이런 접근 방식은 프로그래밍 프로젝트에서 어리석은 짓이다. 그 이유는 이하와 같다:
- 가장 근본적인 문제는 개별 도구를 사용하는 사람들 간의 의사소통 문제이다.
- 장비나 언어가 바뀌면 기술도 바뀌므로 도구의 수명은 그다지 길지 않다.
따라서 범용 프로그래밍 도구를 공통적으로 개발하고 유지보수하는 편이 더 효율적이라는 점은 명백하다.
그러나 전문화된 요구와 개인적 선호라는 두 가지 요소가 특화된 도구의 수요를 부추기므로 앞선 외과 수술 팀에 한 명씩 배정되는 도구 담당 이 필요한 것이다.
여러 팀에 흩어진 도구 제작 담당자를 한데 모아 공용 도구 팀을 확대한다면 훨씬 더 효과적일 것이라 생각하지만 그렇지 않다. 각 팀마다 저마다 특화된 도구가 있기에 이를 만드는 것을 허락해야 한다.
1. 타깃 장비
컴퓨터는 타깃 장비 와 보조 장비 로 나누는 것이 유용하다. 타깃 장비 는 작성된 소프트웨어가 실행될 곳이며, 그 위에서 최종 테스트가 이뤄져야 하는 장비다. 보조 장비 는 시스템을 개발하는 과정에 필요한 서비스를 제공하기 위한 장비이다.
* 타깃 장비에는 어떤 설비가 필요한가?
감시 프로그램이나 그 밖의 핵심 시스템 소프트웨어를 새로 만드는 팀들은 물론 전용 장비가 필요하다. 이런 시스템에는 표준적인 지원 사항을 최신으로 유지할 운영 기사와 한 두명의 시스템 프로그래머가 필요할 것이다.
* 스케줄링
타깃 장비가 새로운 것일 때에는, 장비를 사용할 시간이 부족하기 때문에 스케줄링이 중요한 문제로 대두된다.
처음에는 넉넉하지 않은 장비의 사용 시간을 최대화하기 위해 모든 장비와 테이프 라이브러리를 중앙 집중식으로 관리했으나 느린 회송시간과 상호 비난으로 컴퓨터 시간을 큰 블록으로 할당하는 정책으로 변경했다.
새로운 운영체제를 디버깅 할 때 타깃 장비 하나를 사용하는 방법은 이것이 최선인 것 같다.
2. 보조 장비와 데이터 서비스
- 1. 시뮬레이터
만약 타깃 장비가 새로운 것이라면, 그 장비에 대한 논리적인 시뮬레이터가 필요하다. 이렇게 함으로써 실제 타깃 장비가 만들어지기 훨씬 전에 디버깅용 보조 장비를 확보할 수 있다. 타깃 장비가 사용 가능하게 된 후에도 믿을 수 있는 디버깅 장비 역할을 한다는 점 역시 똑같이 중요하다.
오늘날 컴퓨터 하드웨어가 거의 항상 올바르게 작동하는데 익숙해져 있기에 응용 프로그램을 작성하는 사람은 시스템의 일관성 없는 동작을 목격하지 않는 한 보통 문제를 자신의 코드에서 찾는다. 그러나 새 장비를 지원하기 위한 프로그램을 만들 때에는 그 얘기가 달라진다. 실험실 수준이거나 생상 준비 또는 초기 단계의 하드웨어는, 정의된 대로 동작하지 않고 신뢰할 수도 없으며, 동작이 매번 똑같지 않다.
그러므로 세월로 검증된 보조 장비에서 돌아가는 믿을 수 있는 시뮬레이터는, 생각보다 훨씬 오래 그 유용함을 간직한다.
- 2. 컴파일러와 어셈블러 장비
같은 이유로, 컴파일러와 어셈블러로 신뢰할 만한 장비에서 실행되면서 타깃 장비의 오브젝트 코드를 생성하도록 할 수 있다. 그런 후에는 시뮬레이터 상에서 디버깅을 하는 것이 가능하다.
고급 프로그래밍 언어를 사용하게 되면, 타깃 장비에 맞춰 생상된 코드를 테스트하기 전에라도 보조 장비에서 컴파일하고 테스트하면서 디버깅 작업의 상당 부분을 수행할 수 있다.
이렇게 함으로써 시뮬레이션이 아닌 직접 실행의 효율성 도 얻을 수 있고, 안정적인 장비가 주는 신뢰성 도 함께 확보된다.
- 프로그램 라이브러리와 계정 관리
OS/360 프로젝트의 보조 장비 활용 사례 중에서도 대단히 성공적이고 중요했던 것은, 프로그램 라이브러리 를 만들고 유지한 것이다. 이는 다음과 같이 운영되었다.
- 각 그룹이나 프로그래머들은 자기 프로그램과 테스트 케이스, 구성 요소 테스팅에 필요한 여러가지를 보관해두는 구역을 가지고 있었다. 이런
아기 놀이울안에서 자기 프로그램을 가지고 무엇을 하건 아무 제약이 없었다. - 자신이 만든 구성 요소가 더 큰 부분에 통합될 준비가 되면 프로그래머는 해당 시스템의 관리자에게 자기 프로그램의 복사본을 전달한다.
- 관리자는 이를 다시
시스템 통합용 서브 라이브러리에 복사 해둔다. 이후로는 원 저작자라도 통합 담당 관리자의 허가 없이는 해당 프로그램을 변경할 수 없다. - 시스템이 하나로 합쳐지면서, 이 프로그램은 온갖 시스템 테스트를 통해 버그가 발견되고 수정이 이루어진다.
- 시스템의 특정 버전이 더욱 폭넓게 사용될 준비를 갖추었을 수 있다. 그런 경우 해당 버전은
현재 버전 서브 라이브러리로 지위가 상승하며, 이 복사본은 불가침이 되어 지극히 심각한 버그를 고칠 때에만 손을 댄다.
여기에는 두 가지 중요한 개념이 있다. 첫 번째는 프로그램의 복사본들이 관리자에게 속하며, 오직 해당 관리자만이 변경을 인가할 수 있다는
통제 개념이다.
두 번째는아기 놀이울로부터 통합과 출시를 향해 공식적으로 분리되어 단계별로 진행 한다는 개념이다.
- 프로그램 도구
새로운 디버깅 기법이 출현하면서 옛날 방식이 줄어들기는 했어도 사라지지는 않았다. 여전히 디버깅에는 메모리 덤프, 소스 파일 편집기, 스냅샷 덤프는 물론 트레이스까지도 필요하다.
- 문서화 시스템
모든 도구 중에서 가장 품을 덜어주는 것은, 아마도 신뢰할 수 있는 장비에서 운영되는 전산화된 텍스트 편집 시스템일 것이다.
- 성능 시뮬레이터
이것은 하나 정도 마련해두는 편이 좋으며, 다음 장에서 논의하듯이 안과 밖을 뒤짚어서 구성하도록 한다. 성능 시뮬레이터, 논리 시뮬레이터, 그리고 실제 제품은 동일한 하향식 설계를 채택해야 한다.
3. 고급 언어와 대화식 프로그래밍
오늘날 시스템 프로그래밍에서 가장 중요한 두 가지 도구는 1. 고급 언어와 2. 대화식 프로그래밍이다.
- 고급 언어
이런 도구에 대한 전형적인 반대(???)의 목소리는 다음 세 가지이다:
- 내가 원하는 것을 할 수 없다.
---> 적절한 방법을 찾는데 수고가 들 뿐 고급 언어로 할 수 없는 일은 거의 없다. - 오브젝트 코드가 너무 크다.
---> 새로이 등장하는 최적화 컴파일러들이 상당히 만족스러운 결과를 내기 시작했으며, 점차 개선될 일이다. - 속도가 너무 느리다.
---> 최적화 컴파일러들이 대부분의 프로그래머가 작성한 것보다 더 빠른 코드를 일부 생산해 내고 있으며, 성능에 민감한 일부 코드만 직접 작성해서 대체하면 된다.
그렇다면 시스템 프로그래밍에는 어떤 고급 언어를 사용해야 할까? 현재 유일하게 합리적인 후보는 PL/I 이다. (음... C 가 없었나?)
- 대화식 프로그래밍
나는 많은 응용 프로그램의 경우 대화식 시스템이 일괄 처리 시스템을 결코 대체하지 않을 것으로 확신한다. 그러나 멀틱스 팀은 시스템 프로그래밍이라는 응용 분야에서 가장 설득력 있는 사례를 만든 것 같다. (음... UNIX?)
대화식 도구와 고급 언어는 둘을 합할 때 참으로 예리한 한 쌍의 도구 를 이룬다.
프레더릭 브룩스 선생님도 모든 걸 다 알 순 없었던 것 같다.
장비나 언어가 바뀌면 기술도 바뀌므로 도구의 수명은 그다지 길지 않다.
세상이 이렇게 빠르게 변화할지 그 누가 알 수 있었겠는가? 다만 필자의 아주 주관적인 생각으론 브룩스 선생님이 스케줄링 과정에서 큰 고난을 겪었고 그로 인해 이러한 고정 관념이 생긴건 아닌가? 하는 생각도 든다 ㅎㅎ... (다만 필자는 그를 판단할 자격도 수준도 안된다. 그는 인류를 대표하여 Turing Award Prize 를 수상하셨으니... 다시 말하지만, 또 매 챕터에서 계속 얘기하지만 오히려 여기까지 예측한게 그의 탁월한 통찰력에 놀라울 뿐이다.)
출처
[책] 맨먼스 미신: 소프트웨어 공학에 관한 에세이 (프레더릭 브룩스 지음, 강중빈 옮김)
