2-2. 구조적 프로그래밍

증명

데이크스트라가 초기에 인식한 문제: 프로그래밍은 어렵고, 프로그래머는 프로그래밍을 잘하지 못한다라는 사실.

모든 프로그램은 설령 단순할지 몰라도 인간의 두뇌로 감당하기에는 너무 많은 세부사항을 담고 있었다.

데이크스트라는 증명(proof)라는 수학적인 원리를 적용하여 이 문제를 해결하고자 했다.

수학자가 유클리드 계층구조를 사용하는 방식을 프로그래머도 사용할 수 있다고 믿었다.

 

데이크스트라는 이 연구를 진행하면서 goto 문장이 모듈을 더 작은 단위로 분해하는 과정에 방해가 도는 경우가 있다는 사실을 발견했고, 반면, goto문장을 사용하더라도 문제가 되지 않는 경우를 찾았다.

 if/then/else와 do/while과 같은 분기와 반복이라는 단순한 제어 구조에 해당한다는 사실을 발견했다.

그는 이러한 제어구조는 순차 실행과 결합했을 때 특별하다는 사실을 깨달았다.

 

뵘(Böhm)과 야코피티(Jacopini)가 데이크스트라보다 2년 먼저 발견했는데, 이 두명은 모든 프로그램을 순차, 분기, 반복이라는 세 가지 구조만드로 표현할 수 있다는 사실을 증명했다.

 

 

해로운 성명서

1968년 데이크스트라는 CACM(communicators of ACM)편집자에게 편지를 썼고, 그 내용이 같은 해 3월호에 실렸다.

편지의 제목은 ‘goto의 해로움’이었다.

10년이상의 논쟁 끝에, 데이크스트라가 승리했다. goto문장은 계속 뒤편으로 밀려났고, 마침내 거의 사라졌다.

현재의 우리는 모두 구조적 프로그래머이고, 현대의 언어에서는 goto를 찾아보기 힘들다.

 

기능적 분해

구조적 프로그래밍을 통해 모듈을 증명 가능한 더 작은 단위로 재귀적으로 분해할 수 있게되었고,

이는 모듈을 기능적으로 분해할 수 있음을 뜻했다.

거대한 문제 기술서를 받더라도 문제를 고수준의 기능들로 분해할 수 있다.

그리고 이들은 다시 저수준의 함수들로 분해할 수 있고, 이 과정을 끊임없이 반복할 수 있다.

 

엄밀한 증명은 없었다

하지만 끝내 증명은 이루어지지 않았다. 프로그램 관점에서 정리에 대한 유클리드 계층구조는 끝내 만들어지지 않았다.

그리고 대개의 프로그래머들은 세세한 기능 하나하나를 엄밀히 증명하는 고된 작업에서 이득을 얻으리라고는 보지 않았다.

다행히도 무언가가 올바른지를 입증할 때 사용하는 전략에 유클리드 방식같이 엄밀한 수학적인 증명만이 있는 건 아니다.

또 다른 전략으로 과학적 방법이 있었다.

 

과학이 구출하다

과학은 근본적으로 수학과 다르다. 과학 이론과 법칙은 그 올바름을 절대 증명할 수 없다.

실험과 경험적 증거가 아무리 받쳐준다고 한들, 언젠가는 만유인력과 다른 운동 법칙등이 잘못되었음이 밝혀질 가능성은 항상 열려있다.

과학적 방법은 반증은 가능하지만 증명은 불가능하다.

과학은 서술된 내용이 사실임을 증명하는 방식이 아니라 서술이 틀렸음을 증명하는 방식으로 동작한다.

 

테스트

데이크스트라는 “테스트는 버그가 있음을 보여줄 뿐, 버그가 없음을 보여줄 수는 없다”고 말한 적이 있다.

다시 말해 프로그램이 잘못되었음을 테스트를 통해 증명할 수 있지만, 프로그램이 맞다고 증명할 수는 없다.

테스트에 충분한 노력을 들였다면 테스트가 보장하는 것은 프로그램이 목표에 부합할 만큼은 충분히 참이라고 여길 수 있게 해주는 것이 전부다.

 

소프트웨어는 수학적인 구조같지만, 사실은 과학적이다. 최선을 다하더라도 100%정확함을 보여줄 수는 없기 때문이다.

구조적 프로그래밍은 프로그램을 증명 가능한 세부 기능 집합으로 재귀적으로 분해할 것을 강요한다.

그러고 나서 테스트를 통해 증명 가능한 세부 기능들이 거짓인지를 증명하려고 시도한다.

이처럼 거짓임을 증명하려는 테스트가 실패한다면, 이 기능들은 목표에 부합할 만큼은 충분히 참이라고 여기게 된다.

 

결론

구조적 프로그래밍이 오늘날까지 가치 있는 이유는 프로그래밍에서 반증 가능한 단위를 만들어 낼 수 있는 바로 이 능력 때문이다.

가장 작은 기능에서부터 가장 큰 컴포넌트에 이르기까지 모든 수준에서 소프트웨어는 과학과 같고, 따라서 반증 가능성에 의해 주도된다.

소프트웨어 아키텍트는 모듈, 컴포넌트, 서비스가 쉽게 반증 가능하도록 만들기 위해 분주히 노력해야 한다.

이를 위해서 구조적 프로그래밍과 유사한 제한적인 규칙들을 받아들여 활용해야 한다.