구조적 프로그래밍

goto 문의 해로움

네덜란드의 컴퓨터 공학자 Dijkstra는 프로그래밍이 본질적으로 어렵다는 것을 인식하고, 프로그래밍에서 발생하는 문제를 증명이라는 수학적인 원리를 적용하여 해결하기로 했다. 프로그래머는 이미 증명된 구조를 가져와 이용하며, 이 구조를 가진 코드들을 결합시켜서 코드가 올바르다는 사실을 증명하는 방식으로 개발해야한다고 믿었다.

Dijkstra는 알고리즘을 증명하는 과정에서 goto문이 모듈을 재귀적으로 분해하는 과정에 방해가 되는 경우가 있음을 확인했다. 모듈을 분해할 수 없다면, 합리적으로 증명할 때 필수적인 기법인 분할 정복 접근법을 사용할 수 없게 된다.

반면 goto 문장을 사용하더라도 모듈을 분해하는데에 문제가 되지 않은 경우도 있었다. Dijkstra는 이런 goto문의 좋은 사용 방식은 if/then/else와 do/while과 같은 분기와 반복이라는 단순한 제어 구조에 해당한다는 사실을 발견했다.

그리고 이러한 제어 구조는 순차 실행sequential execution과 결합했을 때 특별하다는 사실을 깨달았다. 모든 프로그램은 순차sequence, 분기selection, 반복iteration이라는 세가지 구조만으로 표현할 수 있다는 사실을 증명했다.

기능적 분해

구조적 프로그래밍을 통해 모듈을 증명 가능한 작은 단위로 분해할 수 있게 되었다. 모든 고수준의 기능들은 저수준의 기능들로 나누어지고, 이들은 모두 프로그래밍의 제한된 제어 구조를 이용하여 표현할 수 있게 되었다. 이들은 모두 입증할 수 있는 작은 단위가 되어 전체 시스템을 구조적으로 설계할 수 있는 이론적 근간이 되었다.

과학적 방법론과 소프트웨어 테스트

Dijkstra가 원했던 고품질의 소프트웨어를 위한 기능 단위 분해와 이를 입증하는 방법은 끝내 완성되지 못했는데, 이는 세세한 기능 하나하나를 엄밀히 증명하는 작업에서 발생하는 비용 때문이었다.

다행히도 무언가가 올바른지 입증할 때 사용하는 전략에는 수학적인 증명 뿐만 아니라 과학적 방법도 존재한다. 과학은 근본적으로 수학과는 다른데, 과학 이론과 법칙은 그 올바름을 절대 증명할 수 없기 때문이다. 뉴턴의 운동 제 2 법칙인 F = ma에 관하여 법칙과 관련된 실험을 시연해볼 수도 있고, 소수점 이하의 정확도로 측정할 수도 있지만 수학적으로 증명할 수는 없다. 과학적 방법은 반증은 가능하지만 증명은 불가능하다.

따라서 과학은 서술된 내용이 사실임을 증명하는 방식이 아니라 서술이 틀렸음을 증명하는 방식으로 동작한다. 이러한 노력의 투입으로도 반례를 들 수 없는 서술이 있다면 목표에 부합할 만큼은 참이라고 본다.

이러한 과학적 접근은 소프트웨어 개발에서도 마찬가지로 적용되었다. 소프트웨어 개발자는 수학적인 구조를 다루는 듯 보이지만, 실제로는 수학적 증명을 통한 완전한 검증보다는 과학적 방법론을 통해 오류를 찾아내고 제거하는 과정에 더 많이 의존하게 된다. 프로그래밍은 복잡한 시스템의 모든 세부 기능을 완벽히 증명할 수 없으므로, 테스트를 통해 그 기능들이 틀렸음을 증명하려는 시도를 반복하게 된다.

구조적 프로그래밍의 강조점

구조적 프로그래밍은 프로그램을 증명 가능한 세부 기능 집합으로 재귀적으로 분해할 것을 강조한다. 그러고 나서 테스트를 통해 증명 가능한 세부 기능이 거짓인지를 증명하려고 부단히 노력해야 한다. 이를 따르기 위해서 모든 모듈, 컴포넌트, 서비스는 쉽게 반증 가능하도록 만들어져야 한다.