모든 소프트웨어 제작에는 두 가지 일이 수반된다. 추상적인 소프트웨어 개체를 구성하는 복잡한 개념적 구조를 만드는 본질적인 일, 그리고 이러한 추상적 개체를 프로그래밍 언어로 표현하여 시공간적 제약 안에서 기계의 언어로 대응시키는 부수적인 일 이 그것이다.
본질적이지 않은 것에 할애되는 비율이 전체의 을 넘지 않는다면, 모든 부수 작업을 0 으로 줄인다 해도 자리수 하나 만큼의 발전은 기대하기 어렵다.
그러므로 이제 소프트웨어를 만드는 일 중에서 본질적인 부분, 즉 복잡도가 엄청난 추상적 개념 구조를 만드는 일에 초점을 맞춰야 한다:
- 구매할 수 있는 것이라면 직접 만들기보다 대량 판매용 제품을 활용하라.
- 요구사항을 수립할 때는 계획된 반복 주기의 일부로 고속 프로토타이핑을 사용하라.
- 새로운 기능은 써보고 테스트한 다음에 시스템에 추가하는 식으로 하여 소프트웨어가 유기적으로 자라게 하자.
- 떠오르는 세대에서 개념적 설계에 탁월한 이들을 찾아내서 성장시키자.
1. 서론
기술이든 관리 기법이든 그 자체로 생산성, 신뢰성, 단순성을 자릿수 하나만큼이라도 향상시킬 발전은 나타나지 않을 것이다. 이 장에서는 소프트웨어 문제의 본질과 후보로 나선 탄환들의 속성을 같이 검토함으로써 왜 그럴 수 밖에 없는지 그 이유를 알아본다.
2. 힘들 수 밖에 없는가: 본질적이 어려움
먼저 우리는 소프트웨어 분야가 그토록 더디게 진보하는 것이 이상한 일이 아니라, 하드웨어의 진보가 그토록 빠른 것이 오히려 이례적인 일 임을 알아야 한다. 문명이 시작된 이래 그 어떤 기술도 30년 사이에 가격 대 성능 면에서 여섯 자리수(100만배) 단위의 발전을 이루지 못했다.
이와 같은 발전은 컴퓨터 생산이 조립 산업 (assembly industry; 부품을 조립하여 완제품을 생산하는 일) 으로부터 장치 산업 (process industry; 대규모 장치로 대량 생산이 가능한 산업) 으로 전환된 것에 기인한다.
둘째로, 소프트웨어 분야에 기대할 수 있는 발전 속도를 알아보기 위해 거기에 내재된 어려움 이 어떤 것인지를 살펴본다. 이를 아리스토텔레스를 따라 그것을 본질적인 것, 즉 소프트웨어의 본성에서 비롯된 어려움, 그리고 부수적인 것, 즉 오늘날 소프트웨어 생산에 수반되지만 본질적이지 않은 어려움 둘로 나누고자 한다.
소프트웨어 개체의 본질 은 데이터 세트, 데이터 항목 간 관계, 알고리즘, 함수 호출처럼 서로 맞물리는 개념으로 이루어진 구조물이다. 표현 방법을 달리 하더라도 개념적 구조물은 동일하다는 점에서 이 본질은 추상적 이다.
소프트웨어를 만드는데 있어 어려운 부분은 이런 개념적 구조물의 명세, 설계 및 테스트이며 이것이 진실이라면, 소프트웨어를 만드는 일은
언제나 힘들 수 밖에 없으며, 은탄환은 본래 없는 겄이다.
- 복잡성
소프트웨어 개체들은 그 크기에 비하면 인간이 만든 그 어떤 구조물보다 복잡한데, 이는 어느 하나라도 다른 것과 (최소한 문장 이상의 수준에서는) 비슷하지 않기 때문이다. 만약 두 부분이 비슷하다면 그 둘은 개방형이든 폐쇄형이든 하나의 서브루틴으로 묶을 수 있을 것이다. 이런 점에서 소프트웨어 시스템은 반복되는 요소를 허다하게 포함하고 있는 컴퓨터, 건축물, 자동차와 근본적으로 다르다.
소프트웨어의 복잡성은 본질적인 속성이며 부수적인 것이 아니다. 그런 이유로, 소프트웨어를 기술하는 추상화 과정에서 그 복잡성이 망실된다면 본질적인 부분 또한 잃어버리기 쉽다.
- 호환성
소프트웨어는 많은 경우 가장 최근에 나왔다는 이유로 호환성을 갖추어야 한다. 또는 가장 호환성이 뛰어나다고 알려져 있기 때문에 호환성을 갖추어야 하기도 한다. 그러나 어떤 경우에라도 다른 인터페이스에 맞추는 것 자체가 많은 복잡성을 초래한다. 이런 복잡성은 해당 소프트웨어만을 어떻게 재설계하든지 간에 단순화될 수 없다.
현대에는 이 호환성이 오히려 컴퓨터와 프로그래밍에 필수적인 요소가 되었다. 아마 저자의 집필 시점에 오픈소스라는 개념도 없었고, 심지어 상업용 소프트웨어조차 막 탄생하던 시기였기에 호환성이 하나의 어려움으로 작용했던 것 같다.
다만, 이건 어디까지나 위 책의 독자이자 이 글을 작성하는 필자의 생각이다. 여전히 호환성에 대해 뭔가 확 와닿는 어려움은 없다.
- 변경 가능성
성공적인 소프트웨어는 모두 변경을 피할 수 없다. 이 변경에는 두 종류의 과정이 있다. 소프트웨어 제품이 유용하다고 판단되면, 사람들은 원래 의도된 범위의 가장자리 또는 그것을 벗어난 새로운 용도를 만들어내는 사용자들로부터 비롯된다.
두 번째로, 성공적인 소프트웨어는 애초에 동작하도록 의도된 대상 장비의 통상적인 수행 이후까지 살아 남는다. 새 컴퓨터는 아니더라도 최소한 새 디스크, 새 디스플레이, 새 프린터들이 나타나고 소프트웨어는 이런 새 장비들과 호환되어야만 한다.
요약하자면, 소프트웨어 제품은 응용 분야, 사용자, 법 조항, 주변 장치들이 만들어내는 문화적 모체 안에 파묻혀 있다. 이 모든 것은 지속적으로 변화하고, 그 변화는 소프트웨어 제품의 변경을 가차없이 강제한다.
이는 Eric S. Raymond 선생님의 The Cathedral and The Bazaar 에도 나오는 얘기 중 하나이며 그의 말을 빌리자면 소프트웨어는 감가상각이 일어나는 공산품이 아니라는 것 이다.
- 비가시성
소프트웨어의 설체는 본질적으로 공간 안에 포함되지 않는다. 그래서 토지가 지도로, 실리콘 칩이 도면으로, 컴퓨터가 접속도로 표현되는 것처럼 소프트웨어를 나타낼 기하학적 표현은 존재하지 않는다.
소프트웨어의 구조를 한정짓고 단순화하려는 여러가지 진전에도 불구하고 그것은 여전히 본질적으로 시각화될 수 없으며, 그로인해 우리는 가장 강력한 개념적 도구 하나를 사용할 수 없게 되었다.
이와 같은 결핍은 한 사람의 설계 과정을 지연시킬 뿐 아니라 사람들 사이의 의사소통도 심각하게 저해된다.
필자 역시 저자와 동일한 생각을 가지고 있다. 프로그램을 작성한다는 것은 무에서 유를 창조하는 과정이다. 거기에 어떠한 동일성이 있을 수 있겠는가? 모든 소프트웨어 개발을 아우르는 천편일률적인 획일화된, 마법의 도구는 없다.
Operating System: A Three Easy Pieaces 에 나오는 말을 인용하자면 다음과 같다: 만병 통치약은 없다(No More Oracle)
3. 부수적인 어려움을 해결한 과거의 성과물
소프트웨어 기술 분야에서 과거에 가장 생산적이었던 세 가지 업적을 살펴보면, 각각이 소프트웨어 제작에 따르는 서로 다른 주요 난점을 공략 했으나 그것은 본질이 아닌 부수적 어려움이었음을 알게 된다. 또한 그 개별 공략들을 확장하는 데에도 태생적 한계가 있음을 알 수 있다.
- 고급 언어
소프트웨어의 생산성, 신뢰성, 단순성에 대한 가장 강력한 일격은, 물론 프로그래밍에 고급 언어 를 점진적으로 사용하게 된 것 이다. 많은 이들이 그로 인해 최소 다섯배의 생산성 향상 및 신뢰성, 단순성, 이해 가능성 측면의 부차적인 이득이 있었다고 본다.
고급 언어가 할 수 있는 최대치는 프로그래머가 추상적인 프로그램에서 상상하는 모든 구조물을 제공하는 것이다. 확실히 우리가 자료구조, 자료형, 연산 등에 대해 생각할 때의 복잡도는 꾸준히 높아지지만 그 속도는 계속 줄어드는 추세다. 그리고 언어의 발전 또한 사용자들의 복잡도에 점차 근접하고 있다.
더구나 고급 언어의 복잡함은 어떤 지점에 이르면 심호한 기능을 쓸 일이 없는 사용자의 지적 업무를 줄여주지 못하면서 오히려 부담으로 작용한다.
- 시분할 방식
시분할 방식은 고급 언어와는 또 다른 종류의 난점을 공략한다. 시분할은 즉시성을 보존하며 그로인해 복잡성에 대한 개관을 유지할 수 있도록 해준다. 일괄처리 프로그래밍은 전환 시간이 느려서, 프로그래밍을 중단한 후 코드를 컴파일하고 실행할 때 그때껏 생각하던 세부사항은 (핵심 사항은 아니더라도) 잊어버릴 수 밖에 없게 된다. 나중에 내용을 다시 되살려야 하기 때문에 이런 의식의 단절은 시간적으로 비용이 많이 든다.
필자가 홍삼캔디 냄새 그윽하게 풍기는 틀딱 소리를 좀 하자면... 필자가 어렸을 때 (2012년; 초등학교 5, 6 학년?) 에는
Visual Studio가 유료였고 당시 컴파일 속도는 C 언어 1,000 줄 정도 기준으로 길면 5분이 넘어갔다. (못 믿겠지만 사실이다.)
Express 는 무료였지만, WinAPI 의 Resources 작업은 불가능했기에 6.0 을 따로 찾아 쓰고 했었는데 아무튼, 저렇게 컴파일 타임이 늘어지면 디버깅 및 실행이 끝나고 다시 프로그래밍을 진행할 때 흐름이 많이 끊기는 감이 없잖아 있었다.
- 통합된 프로그래밍 환경
유닉스와 인터리스프는 널리 쓰이게 된 최초의 통합 프로그래밍 환경으로, 생산성을 여러 배 향상시켰다는 평을 듣는다. 왜 그럴까?
그 둘은 통합된 라이브러리, 통일된 파일 형식, 파이프와 필터를 제공함으로써 여러 프로그램을 함께 사용할 때 발생하는 부수적인 난점들을 공략한다. 그 결과, 이론 상으로 항상 서로 호출하고 데이터를 공급하고 서로 이동할 수 있는 개념적 구조체들이 실제로도 쉽게 그럴 수 있게 되었다.
Dennis M. Ritchie 선생님께서 작성하신 유닉스의 역사에서도 파이프의 개념이 얼마나 혁신적이였는지에 대해 자세하게 설명해주신다.
4. 은탄환에 대한 희망
- 에이다와 그 밖의 고급 언어들에 의한 진보
에이다에는 언어 개념상의 점진적인 발전 사항들이 반영되어 있을 뿐 아니라 현대적 설계와 모듈화를 촉진하는 기능들도 포함되어 있다. 에이다는 언어 자체보다도 거기 내재된 철학이 아마 더 진보적이라 할 수 있을텐데, 그 철학에는 모듈화, 추상적 자료형, 계층적 구조화라는 개념이 담겨 있기 때문이다.
물론 에이다가 소프트웨어 생산성이라는 괴물을 쓰러뜨릴 은 탄환이 되지는 않을 것이다. 어쨌거나 그것은 또 하나의 고급 언어일 뿐이고, 이런 언어에서 얻을 수 있는 최고의 대가는 기계어에 내재된 부수적 복잡성으로부터 더 추상화된 문장으로 올라가는 최초의 이행에서 이미 얻어진 바 있다.
향후 100년 뒤에 에이다의 유효성을 검토한다면 상당한 진전을 이루어냈다는 평가를 받을 것이다. 그러나 이는 에이다의 어떤 언어적 특성 때문이 아닌, 프로그래머들이 그 언어로 바꿈으로써 현대적 소프트웨어 설계 기법을 연마 하도록 하는 일이다.
- 객체지향 프로그래밍
추상적 자료형이란 어떤 객체의 타입을 이름, 고유한 값, 고유한 연산들로 정의하면서 바탕에 깔린 저장 구조를 숨겨야 한다는 개념이다. 계층적 자료형은, 일반적인 인터페이스 정의에 하위 타입을 제공함으로써 추가적인 세분화가 가능하도록 해준다. 이 두가지 개념은 서로 독립적이다. 정보은닉 없는 계층 구조가 있을 수 잇고, 계층화되지 않은 정보 은닉이 있을 수도 있다.
이러한 개념들은 각기 소프트웨어 개발의 부수적인 어려움을 하나씩 더 없앴고, 설계하는 이가 핵심 내용을 표현하기 위해 별다른 정보도 없는 문법적 구조들을 잔뜩 만들지 않아도 되게 해준다.
두 개념 모두 소프트웨어 분야에 진정한 발전이 있었음을 보여준다.
- 인공지능
많은 이들은 인공 지능 분야에서 이루어진 발전이 소프프웨어 생산성과 품질에 자리수 하나만큼의 개선을 가져올 혁명적 돌파구가 될 것으로 기대한다. 나 (책의 저자)는 그러지 않는다.
내게는 예컨데 영상 인식이 프로그래밍 관례에 어떤 주목할만한 차이를 가져올지 알기가 쉽지 않다. 이것은 음성 인식도 마찬가지다.
소프트웨어 개발의 어려운 점은 무엇을 말할지 결정하는데 있으며, 말하는 행위 자체에 있지는 않다. 표현을 편리하게 만드는 것으로는 미미한 성과 밖에 얻을 수 없다.
- 전문가 시스템
전문가 시스템은 일반화된 추론 엔진과 규칙 베이스를 포함하는 프로그램으로 데이터와 제반 가정을 입력으로 받고, 규칙 베이스로부터 유도되는 추론 과정을 되짚어 보여줌으로써 도출된 결과에 대한 설명을 제공하도록 설계된다.
동일한 문제에 대해 동일한 해법에 도달하더라도, 프로그램된 알고리즘과 비교할 때 이런 시스템에는 몇 가지 명확한 장점이 있다:
- 추론 엔진 기술은 응용 분야에 무관하도록 개발되어 다양한 용도에 쓰인다. 추론 엔진에 많은 노력을 들이는 것은 타당한 일이며, 이 기술은 실제로 상당히 앞서 있다.
- 특정 응용 분야에 연관된 가변적인 부분은 규칙 베이스에 일정한 형식으로 담겨 있으며, 그 규칙 베이스를 개발, 변경, 테스트, 문서화하기 위한 도구들이 제공된다. 이렇게 해서 응용 자체에 내재된 복잡성의 많은 부분이 정규화된다.
이 시스템은 인터페이스 규칙의 제안, 테스트 전략에 대한 조언, 버그 유형별 빈도 기억해두기, 최적화 힌트 제시 등과 같은 방식으로 소프트웨어 개발에 적용될 수 있다.
전문가 시스템의 가장 큰 공헌이라면, 역시 최고의 프로그래머들이 쌓아온 경험과 지혜를 미숙한 프로그래머가 이용할 수 있게 한다는 점일 것이다.
이것들이 빅데이터와 인공지능으로 결합하여 나온 것이 Microsoft 의 Copilot 임을 생각해봤을 때, 저자는 날카로운 통찰력과 혜안에 다시금 놀라게 되었다.
- '자동' 프로그래밍
사람들은 문제를 명세한 문장으로부터 그 문제를 푸는 프로그램을 생성해내는 자동 프로그래밍 에 대해 근 40년 동안이나 예측하고 저술해왔다. 파르니스는 그런 용어가 매력있어 보이기 위한 것일 뿐 별다른 의미는 없음을 다음 주장에서 시사하고 있다:
요약하자면, 자동 프로그래밍이라는 것은 그 당시의 프로그래머가 사용할 수 있었던 것보다 더 높은 수준의 언어로 이루어지는
프로그래밍에 대한 완곡한 표현이었다. - 파르니스요컨데, 대부분의 경우 명세가 주어져야 하는 것은 문제가 아니라 해결 방안 쪽이라는 것이 그의 주장이다. 거기에는 몇 가지 예외가 있다:
- 비교적 적은 수의 매개변수로 문제가 쉽게 특정지어진다.
- 알려진 해법이 많이 있어서 선택지를 구성하기가 쉽다.
- 폭 넓은 분석이 이루어진 덕에 주어진 매개변수의 맞는 해법을 선택하기 위한 명시적인 규칙이 존재한다.
이런 기법들은 평범한 소프트웨어 시스템 세계에서 어떤 식으로 일반화될 수 있을지 알기 어렵다. 앞에서 열거된 멋진 특성을 갖춘 경우가 오히려 예외적이기 때문이다.
한마디로 딱 울프램 알파다. 예외사항에도 잘 들어맞고 아무튼 자동으로 계산해준다. 결국 본질과는 거리가 좀 멀긴 했지만... 많은 편의를 제공해주었음은 사실이다. 필자도 요긴하게 써 먹었다.
- 그래픽 프로그래밍
소프트웨어 공학 분야에서 박사 학위 논문의 주제로 선호되는 것 중 하나가 컴퓨터 그래픽을 소프트웨어 설계에 응용한 그래픽 프로그래밍 또는 시각적 프로그래밍이다.
이런 노력들은 아직까지 부수적인 것은 물론이고 어떤 설득력있는 결과도 내놓지 못했다. 나(책의 저자)는 앞으로 그럴 일은 없을 것이라 확신한다:
- 내가 다른 문헌에서 주장한 것처럼 순서도란 소프트웨어 구조에 대한 추상화로 아주 좋지 못하다.
- 오늘날의 화면은 본격적으로 상세한 소프트웨어 구성도를 표시하기에는 그 범위나 해상도에 비해 화수 수가 너무 적다.
쉽게 생각해볼 수 있는 것이 Unity 와 같은 3D 게임 개발 툴인데, 이런 툴로 개발한다고 해서, 개발에 10년 걸리는 게임이 3년으로 줄거나 하진 않는다. 결국 본질은 다른 곳에 있었음을 알려준다.
- 프로그램 검증
현대의 프로그래밍에서는 테스트와 버그 수정에 많은 노력이 들어간다. 혹시 시스템 설계 단계에서 소스 내의 오류를 제거한다면 은 탄환이라 부를 수 있지 않을까? 시스템 구현과 테스트에 막대한 노력이 들어가기 전에 설계의 정확성을 검증한다면, 크게 차별화되는 전략에 의해 생산성과 제품 신뢰도가 모두 현저하게 개선될 수 있을까?
프로그램 검증은 대단히 강력한 개념으로, 보안을 요하는 운영체제 커널과 같은 분야에서 아주 중요한 역할을 할 것이다.
하지만 이 기술은 작업량을 줄여준다고 약속하지는 않는다.
Rust 와 같은 프로그래밍 언어가 주목받고 있는 가장 근본적인 이유가 사실상 C 의 고질적 문제인 메모리 누수 문제 때문이다. C 로 작성한 프로그램의 70~80% 의 에러가 메모리 에러라는 점을 생각해봤을 때 저자의 말처럼 Rust 는 C 를 대체할 수 있는 아주 강력한 언어임이 분명하다.
그러나 본문에서 언급한 것처럼 C, Rust 두 언어 모두 뭐가 되었든 본질적인 문제가 해결한 것은 아니기에 작업량을 줄여주진 않는다. 그래도 Rust 는 디버깅 과정 및 시간적 측면에서는 아주 유의미한 수준으로 대폭 향상될 것이라 필자는 생각한다.
- 개발환경과 도구
더 나은 프로그래밍 환경에 대한 연구들이 폭발적으로 증가하고 있다. 계층적 파일 시스템, 단일한 프로그램 인터페이스를 제공하기 위한 단일 파일 포맷, 일반화된 도구 등이 그것이다.
아직 현실화 되지는 않았지만 프로그래밍 환경 쪽에서 얻을 법한 소득 중 가장 큰 것으로 통합 데이터베이스 시스템 도입이 있다.
이것은 물론 가치잇는 일이며 생산성과 신뢰성 양쪽에서 일정한 결실을 맺을 것이다. 그러나 그 본질상 지금 시점 이후에 얻을 이득은 미비할 수 밖에 없다.
- 워크스테이션
확실하고도 급속히 증가하는 개인용 워크스테이션의 계산 능력과 메모리 용량으로부터 소프트웨어 분야가 기대할 수 있는 이득은 무엇일까? 글쎄, 그렇다면 한 사람이 효과적으로 사용할 수 있는 최대 MIPS 는 얼마나 될까?
프로그램과 문서를 작성하고 편집하는 일은 현재의 계산 속도로도 충분하다. 컴파일에는 이득이 있겠지만, 장비 속도가 열 배 빨라졌을 때 프로그래머의 일과에서 가장 주요한 활동은 생각하는 일이 될 것이다.
더 강력한 워크스테이션은 당연히 환영한다. 하지만 거기에 마법같은 발전을 기대할 수는 없다.
5. 개념적 본질을 겨냥한 유망한 시도들
소프트웨어를 만드는데 따르는 비본질적 문제를 해결하려는 모든 기술적인 시도는 근본적을 다음과 같은 생산성 공식에 의해 제약을 받는다:
만약 내가(책의 저자) 믿는 것처럼 작업 내의 개념적 요소가 시간의 대부분을 차지 한다면 개념의 표현일 뿐인 작업 요소에 얼마의 노력을 들이든 간에 생산성에 큰 이득은 없을 것이다.
그런 이유로 우리는 소프트웨어의 본질적인 문제. 즉 복잡한 개념적 구조의 구성이라는 문제를 겨냥하는 시도를 검토해야 한다.
- 살 것인가 만들 것인가
소프트웨어를 만든다는 문제에 대한 가장 급진적인 해결책은, 아예 만들지 않기로 하는 것 이다. 그 어떤 제품이라도 새로 만드는 것보다는 더 저렴하다. 10만달러에 달하는 제품이라 해도 그 비용은 프로그래머 한 명을 1년 유지하는 정도다. 그리고 납품은 즉시 이루어진다.
나는 대량 판매용 시장의 개척이야 말로 소프트웨어 공학에서 가장 의미 심장하며 장기적인 트렌드라고 믿는다.
저자의 말처럼 소프트웨어를 아예 만들지 않는 방식은 요즈음 트렌드다. 그러나 저자가 하나 간과한 사실이 있다면 그것은 심지어 무료로 제공한다는 것이다. 오픈소스 소프트웨어가 꽃피워낸, 전인류가 직접 참여하고, 만인이 무료로 사용하는, 리눅스가 가장 대표적이라고 할 수 있겠다.
- 요구사항 상세화와 고속 프로토타이핑
소프트웨어 시스템을 만들 때 가장 어려운 부분은 정확하게 무엇을 만들지 정하는 일이다. 이 작업 만큼 잘못되면 최종 시스템에 심각한 손삭을 입히는 것도 없고, 이만큼 나중에 바로 잡기 어려운 것도 없다.
그러므로 소프트웨어를 만들 때 고객을 위해 해야 할 일 중 가장 중요한 것은, 제품 요구 사항을 반복적으로 추출하고 상세하는 것이다. 진실을 말하자면, 고객들도 자기가 무엇을 원하는지 알지 못하기 때문이다.
그러므로 현대의 기술적 성과 중에서 가장 유망하며 문제의 본질을 겨냥하는 것 하나는, 반복적인 요구사항 명세의 한 부분으로서 신속하게 프로토타입을 만들도록 해주는 방법 및 도구의 개발이다.
소프트웨어 분야에서는 CI/CD 라는 형태의 서비스 방식을 사이클을 추구하고 있음을 보면 정확하게 예측했다고 생각한다.
- 점진적 개발: 소프트웨어를 구축하는 대신 성장시키기
1958년, 소프트웨어를 작성(write)하지 않고 구축(build)한다는 얘기를 어떤 친구로부터 처음 들었을 때의 충격을 나는 아직도 기억한다. 오늘날 우리는 소프트웨어 구축이 어떻게 다른 분야와 비슷한지 알고 있으며, 그 비유에 속한 다른 요소를, 즉 명세, 구성 요소 조립, 비계 같은 것들(모두 건축 관련 용어)을 사용함에 거리낌이 없다.
그러나 이 구축의 비유는 너무 오래되서 그 유용함을 잃었다. 지금은 다시 변화가 필요하다.
이제 사람드이 만든 생명없는 사물 대신 자연으로 눈을 돌려서, 살아있는 것들에 내재된 복잡함을 들여다 보아야 한다. 뇌라는 것 하나만 봐도, 지도로 나타낼 수 없을 정도로 복잡하며, 모방할 수 없이 강력하고, 풍부한 다양성과 자기 보호 및 자기 재생 능력을 갖추었다.
그 비밀은 뇌가 구축된 것이 아니라 성장한 것이라는 데에 있다. 그러므로 우리 소프트웨어 시스템도 그래야만 한다.
그것은 즉 시스템이 적절한 가짜 서브 프로그램들을 호출하는 것 외에 아무 일도 하지 않더라도 일단은 실행 되는 형태로 만들어져야 한다는 것이다. 이러한 하향식 설계는 백트래킹이 쉽도록 해주며, 초반에 프로토타입을 만들기에도 적합하다. 추가적인 기능, 더 복잡한 데이터나 상황에 대한 추가적인 대비 등은 모두 이미 있떤 것으로부터 유기적으로 성장해나간다.
임베디드 엔지니어 교과서 (와타나베 노보루, 마키노 신지 지음; 정인식 옮김) 에서도 위와 같은 형태의 린 스타트업이라는 비지니스 모델을 하드웨어/임베디드 분야에서는 채택할 수 있음을 소개한다. 소프트웨어라고 별 다를바 없다 생각한다.
- 탁월한 설계자들
뛰어난 설계는 뛰어난 설계자들로부터 나온다. 최고의 설계자들이 만들어낸 구조는 더 빠르고, 더 작고, 더 단순하고, 더 깔끔하고, 더 적은 노력으로 만들어진다는 것이 수 많은 연구에서 밝혀지고 있다.
소프트웨어를 성공적으로 개발하기 위해서는 훌륭한 관리자 만큼이나 탁월한 설계자도 중요하다는 사실을 모든 조직이 인지하도록 하며, 그들이 관리자와 대등한 수준의 육성과 포상을 기대할 수 있게 해야 함을 제안한다:
- 체계적인 방식으로 최고의 설계자들을 가능한 일찍 찾아내라. 가장 뛰어나다 해서 가장 경험이 많은 것은 아닐 수 있따.
- 후보자의 개발을 책임질 멘토를 배정하고, 경력 파일을 주의 깊게 기록하라.
- 각 후보에 대한 경력 개발 계획을 수립하고 유지하라. 여기에는 최고의 설계자들과 함께하는 세심하고 선정된 견습과정, 상급 정규 교육과정, 단기강습이 포함되며, 이 모든 것은 개인별 단독 설계 및 기술적 리더쉽에 대한 과제와 함께 배치해야 한다.
- 성장하는 설계자들이 서로 소통하며 자극을 줄 수 있는 기회를 제공하라.
출처
[책] 맨먼스 미신: 소프트웨어 공학에 관한 에세이 (프레더릭 브룩스 지음; 강중빈 옮김)
[책] 성당과 시장 (에릭 레이먼드 지음; 정직한, 최준호, 송창훈, 이기동, 윤종민 옮김)
[책] 임베디드 엔지니어 교과서 (와타나베 노보루, 마키노 신지 지음; 정인신 옮김)
[책] 운영체제: 아주 쉬운 세 가지 이야기 (Remzi H. Arpaci-Dusseau, Andrea C. Arpaci-Dusseau 지음; 원유집, 박민규, 이성진 옮김)
