1. 파일럿 공장과 규모의 확대
실험실에서 동작하던 공정이라고 해서 곧바로 공장에 투입할 수는 없다. 실험실에서 개발된 담수화 공정은, 하루 200만 갤런 규모의 지역 급수 시설에 사용되기 전에 1만 갤런 규모의 파일럿 공장 에서 시험이 이뤄져야 한다.
프로그래밍 시스템에서도 동일하게 적용된다. 대부분의 프로젝트에서 나온 첫 시스템은 거의 쓸 수 없는 수준이다. 따라서 그 일은 어짜피 일어날 것이므로 파일럿 시스템을 만든 다음에 이를 버릴지 혹은 그대로 쓸지 고민해선 안된다.
버리기 위한 계획을 세우라. 어쨌거나 버리게 될 것이다.
2. 변하지 않는 것은 변화 그 자체 뿐
변화라는 현상을 재수없고 짜증나는 예외적인 상황이 아닌 하나의 생활 양식으로써 받아들일 필요가 있다. 프로그램이 만들어지고 테스트되고 사용되는 과정에서 사용자의 실제 욕구와 그에 대한 인식도 변화할 수 있다.
그러나 이는 목표와 요구사항 변경이 모두 설계에 반영되어야 한다거나 반영될 수 있음을 의미하는 것이 아닌, 변경을 반영하는 데는 분명히 어떤 기준이 있어야 하고, 이 기준은 개발이 진행됨에 따라 차츰 더 높아져야 함을 의미하는 것이다.
목표 뿐만 아니라 개발 전력과 기법 면에서도 변화는 피할 수 없다. 만들어서 버린다는 것은, 배움이 늘어감에 따라 설계도 바뀐다는 사실을 인정 하는 것과 다르지 않다.
3. 시스템을 변화에 대비시켜라
다음의 사항을 유념하므로써 시스템 변화에 유연하게 대응할 수 있다:
- 주의 깊은 모듈화, 광범위한 서브루틴의 사용, 모듈 간 인터페이스의 명확하고 완전한 정의, 이 모든 것에 대한 철저한 문서화
- 고급 언어의 사용과 자체 문서화 기법 활용 (표준 선언을 포함하는 컴파일 타임 기능 사용 등)
- 변경 사항을 일정한 묶음으로 처리 (제품들의 버전 관리)
4. 조직을 변화에 대비시켜라
조직을 변화에 대응하도록 구성하는 일은 시스템을 그렇게 설계하는 것보다 훨씬 어렵다. 조직 전체가 기술적 유연함을 가지기 위해, 모든 구성원은 자기 역량을 넓힐 수 있는 업무에 배치 되어야 한다.
이를 위해 규모가 큰 프로젝트의 관리자는 최정예 프로그래머 두 세명을 전투가 가장 치열한 곳에 구조하러 달려갈 기마병으로 예비할 수 있다.
관리 구조 또한 시스템이 변경됨에 따라 바뀔 필요가 있다. 이것은 재능이 허락하는 범위 내에서 관리자들과 기술자들이 임무를 교대할 수 있도록 조직의 장이 많은 주의를 기울여야 함을 의미한다.
이를 가로막는 장벽은 사회학적인 것이며 다음과 같다:
- 선임자들이
너무 소중하기 때문에프로그래밍 실무에 투입할 수 없다고 관리자들이 생각한다. - 관리 쪽 직군이 기술 쪽 직군보다 더 중요시 되는 풍토가 있다.
이러한 문제로 Bell 연구소 같은 일부 연구소는 모든 직책을 폐지했고, IBM 에서는 이중 승진 체계를 도입해 양쪽 직군에서 서로 대응하는 직군은 동등하게 만들었다.
5. 두 걸음 전진 한 걸음 후퇴
프로그램 유지 보수의 근본적인 문제는, 결함을 수정할 때 상당한(20 ~ 50%) 확률로 또 다른 결함이 유입된다는 것이다. 그러므로 전체 과정은 두 걸음 전진 후에 한 걸음 후퇴가 된다.
결함이 좀 더 깔끔하게 수정되지 못하는 까닭은...
- 미묘한 종류의 결함이라도 겉으로는 국부적으로 나타나기 때문이다.
- 수리 담당자가 대게 코드를 만들었던 당사자는 아닌 데다가, 하급 직원이나 수습 사원일 때가 많기 때문이다.
부작용을 없애거나 최소한 드러나도록 만드는 프로그램 설계 방법, 더 적은 인원과 더 적은 인터페이스로 설계 내용을 구현하는 방법을 통해 버그를 줄이고 유지 보수 비용 면에서 막대한 이득을 얻을 수 있다.
6. 한 걸음 전진, 한 걸음 후퇴
모든 수정 행위는 시스템 구조를 훼손하고 엔트로피와 무질서를 증가시키는 경향을 보인다. 원래의 설계 결함은 수정하는데 투입되는 노력은 점점 더 줄고, 초반의 수정으로 유입된 새 결함들을 고치는데 점점 더 많은 시간이 소요된다. 머지 않아 수정 행위는 어떤 효과도 거두지 못하게 된다. (한 걸음 전진, 한 걸음 후퇴)
그것이 역사에 대한 열쇠다. 엄청난 에너지를 쏟아 붓는다. 그리고 문명들이 일어난다. 그리고 나서 훌륭한 제도가 고안된다. 하지만 그때마다 뭔가가 잘못된다. 어떤 치명적인 결함에 의해 항상 이기적으로 잔혹한 인물들이 정상에 오르고, 그 다음에는 모든 것이 곤궁과 몰락으로 되돌아간다. 사실 기계도 망가지기 마련이다. 멀쩡히 가동되고 몇 미터를 달리더니, 이내 고장이 나버린다.
- C. S. 루이스
시스템 프로그램을 만드는 일은 엔트로피를 감소시키는 과정이므로 본질적으로 준안정적인 상태다. 프로그램 유지 보수는 엔트로피를 증가시키는 과정이고, 아무리 능속하게 수정된다 해도 시스템이 수리 불가의 구닥다리가 되는 것을 잠시 늦출 수 있을 뿐이다.
읽으면서도 고개를 끄덕이게 만드는 내용이였다. 대형 프로그램을 직접 설계한 경험이 있는 사람이라면 더 크게 공감할 것이다.
처음 설계할 때에는 그 방향성이 올바른지조차 알 수 없다. 개발이 어느정도 진행된 후에 어디가 잘못되었고 또 무엇이 문제인지 눈에 들어오기 시작한다. 개발 초기의 설계에 있어 부주의 했기 때문일까? 필자의 경험에 따르면 다음과 같다:
목적지는 보이지만 길이 안 보이는 상황에서, 어느 길이 바른 길인지 알기란 불가능에 가깝다. 막다른 길에 놓인 후에 비로소 길을 잘못 들었음을 알 수 있다.
처음부터 설계가 제대로 들어 맞았다면 그건 운이 좋았던 것이지 처음부터 뭔가를 알고 설계를 시작하진 않는다. 한번 망치고 난 이후에 얻게 되는 통찰이 분명 존재한다. 그런 의미에서 파일럿 공장은 꽤나 흥미로운 제안이라는 생각이 들었다. 어짜피 망칠 것이라면 개발 초기에 다양한 시도를 해보는 것이 좋지 않을까?
어짜피 설계부터 틀어진 소프트웨어 제품은 더 잘 고칠 수가 없다. 애시당초 방향을 잘못 잡아서 생긴 문제이기 때문에 고쳐봐야 한 걸음 전진, 한 걸음 후퇴 가 될 수 밖에 없다.
너무 뻔한 얘기라는 생각은 들지만 정작 설계할 때에는 이러한 조심성이 결여되는 것 같다. 시스템을 변화에 대비시키는 가장 확실한 방법은 위에서 언급했던 문서화와 라이브러리의 사용, 그리고 버전 관리인데 이 또한 설계가 잘못됨을 인지하고 다시 되돌아가는 과정에서 그 부실함을 느끼는 경우가 많다.
출처
[책] 맨먼스 미신: 소프트웨어 공학에 관한 에세이 (프레더릭 브룩스 지음, 강중빈 옮김)
