📖 [4장] 구조적 프로그래밍
📘 클린 아키텍처 북스터디 정리입니다
📚 도서: 로버트 C. 마틴 《Clean Architecture》
🧑💻 목적: 올바른 설계에 대한 감각과 습관을 익히기 위해
🗓️ 진행 기간: 2025년 7월 ~ 매주 2장
✅ 핵심 요약 (Key Takeaways)
이 장의 핵심 문장은?
모든 수준에서 소프트웨어는 과학과 같고, 따라서 반증 가능성에 의해 주도된다
모듈, 컴포넌트, 서비스가 쉽게 반증가능하도록 만들기 위해 노력해야 한다
저자가 전달하고자 하는 메세지 요약
- 구조적 프로그래밍은 제어 흐름에 제한을 두어, 논리적 오류를 드러낼 수 있는 구조를 만들기 위한 방법론임
- 소프트웨어는 반증 가능성이라는 기준 위에 세워져야 하며, 모듈과 컴포넌트는 테스트 가능한 단위로 분해되는 구조여야 함
- 아키텍처 설계의 핵심은 기능적 분해와 반증 가능성 확보에 있음
💡 내용 정리
서론: 데이크스트라의 시작
- 1930년 네덜란드 로테르담 출생, 원래 이론 물리학자 → 프로그래밍으로 진로 변경
- 프로그래밍의 복잡함을 인식하고 수학적 접근을 도입함
수학적 증명 도입
문제 인식
- “프로그래밍은 어렵고, 대부분의 프로그래머는 잘 하지 못한다.”
- 해결책: 수학적 증명 개념 도입
유클리드 계층 구조
- 공리: 증명 없이 참이라고 받아들이는 명제
- 정리/보조정리/따름정리: 공리를 기반으로 증명 가능한 논리적 구조
→ 프로그래밍에서도 이런 계층 구조를 만들자는 비전
→ 프로그래머는 입증된 구조를 이용하고, 이들 구조를 코드와 결합시키며, 코드가 올바르다는 사실을 스스로 증명
goto 문 제거
goto는 모듈의 재귀적 분해를 방해하는 요소- 대신
if/then/else,do/while같은 분기와 반복이라는 단순한 제어 구조 도입
제어 구조 3요소
- 뵘 & 야코피니: 모든 프로그램은
순차,분기,반복만으로 표현 가능
해로운 성명서
goto문의 해로움(goto statement considered harmful) - 1968년, 데이크스트라goto사용을 비판하는 글로 프로그래밍계 논쟁 촉발- 현대 언어 대부분은
goto를 제거 → 프로그래머는 자연스럽게 구조적 프로그래머가 됨
구조적 프로그래밍의 증명 방식
- 순차 구문: 열거법으로 입출력 추적
- 분기 구문: 경로를 나눠 각각의 논리적 타당성을 입증(열거법의 재적용)
- 반복 구문: 수학적 귀납법 사용
기능적 분해
- 구조적 프로그래밍을 통해 모듈을 증명 가능한 더 작은 단위(기능별)로 재귀적 분해
- 이를 토대로 1970년대 후반~1980년대에는 구조적 분석이나 구조적 설계와 같은 기법이 인기
- 대규모 시스템을 모듈과 컴포넌트로 분리 가능, 모듈과 컴포넌트는 입증할 수 있는 아주 작은 기능들로 세분화 가능
과학적 방법
수학적 방법과 과학적 방법의 차이
- 수학: 참임을 입증
- 과학: 거짓임을 반증
테스트의 한계
- 테스트는 버그가 있음을 보여줄 뿐, 버그가 없음을 보여줄 수는 없다(데이크스트라)
- 즉, 프로그램이 잘못되었음을 테스트를 통해 증명할 수는 있지만, 프로그램이 맞다고 증명할 수는 없음
- 테스트가 보장할 수 있는 것은 프로그램이 목표에 부합할 만큼은 충분히 참이라고 여길 수 있게 하는 것
- 부정확함에 대한 증명은 입증 가능한 프로그램에만 적용 가능
결론
구조적 프로그래밍이 오늘날까지 가치 있는 이유
- 구조적 프로그래밍은 반증 가능한 단위 구성을 가능하게 하는 방법론
- 해당 접근법은 코드의 이해도, 검증 가능성, 유지보수성 향상에 기여함
- 현대 프로그래밍 언어가
goto문장을 제한하거나 제거하는 이유는 제어 흐름의 명확성과 예측 가능성 확보에 있음 - 아키텍처 측면에서 기능을 분리하고 모듈화하는 방식은 여전히 효율적인 구조 설계 원칙으로 평가받고 있음
구조적 프로그래밍의 설계 원칙
- 소프트웨어는 과학처럼 반증 가능성에 기반해 설계되어야 함
- 소프트웨어 아키텍트는 모듈, 컴포넌트, 서비스가 테스트하기 쉬운 구조로 만들어지도록 노력해야 함
💡 인상 깊었던 문장 & 나의 인사이트
책에서 가장 기억에 남는 문장
테스트는 버그가 있음을 보여줄 뿐, 버그가 없음을 보여줄 수는 없다
인상 깊었던 문장과 관련된 인사이트
입증이라는 수학적 증명의 관점이 아니라, 반증이라는 과학적 관점을 통해 프로그래밍을 바라보는 시각이 흥미로웠다.
"테스트는 버그가 있음을 보여줄 뿐, 버그가 없음을 보여줄 수는 없다"
그래서 테스트 하기 쉽도록 코드를 짜야 하는 것이다.
그래서 테스트가 많은 부분을 커버할 수 있도록 코드를 짜야하는 것이다.
그래서 테스트를 통해 잘못된 부분이 명확히 드러나도록 설계해야 하는 것이다.
🛠 실무 적용 아이디어 (To Action)
✅ 오늘부터 실천할 작은 실천
- 테스트 가능한 단위로 기능을 분리하기
