코드를 설명의 뒤에 두는 것이 아니라, 설명 속에 코드를 두는 방식
문학적 프로그래밍(Literate Programming)은 이름만 들으면 조금 거창하게 들리지만, 핵심은 의외로 단순하다.
컴퓨터에게 맞는 순서로 코드를 쓰는 대신,
사람에게 설명하기 좋은 순서로 프로그램을 쓰자.
이 개념은 1984년 Donald Knuth가 제안했다. 그는 프로그램을 단순히 실행 가능한 코드로 보지 않고 사람이 읽는 문서처럼 작성해야 한다고 주장했다.
코드가 아니라 설명이 중심이 된다
보통 우리가 쓰는 프로그램은 이런 구조다.
코드
↓
주석코드가 본문이고, 설명은 보조다.
문학적 프로그래밍은 반대다.
설명
↓
코드 조각설명이 본문이고, 코드는 그 설명을 이루는 재료다.
즉 프로그램은 컴파일러보다 사람에게 먼저 읽히는 글이 된다.
핵심 개념: weave 와 tangle
문학적 프로그래밍 도구는 보통 두 가지 결과물을 만든다.
문서
+
실행 코드이 과정을 두 단어로 설명한다.
Weave
사람이 읽기 좋은 문서를 만든다.
설명
+
코드
↓
문서Tangle
컴파일 가능한 코드를 만든다.
설명 문서
↓
코드 추출
↓
실행 코드즉 하나의 소스에서
문서
코드두 결과가 동시에 나온다.
대표 도구
WEB (Knuth)
문학적 프로그래밍의 최초 도구다.
WEB
↓
Pascal + TeXnoweb
WEB을 단순화한 범용 도구.
언어 독립
간단한 구조Org Babel
Emacs 기반 문서형 프로그래밍 환경.
특징
- 코드 실행
- 결과 저장
- 문서와 코드 통합
Jupyter Notebook
현대적 형태의 문학적 프로그래밍.
텍스트
+
코드
+
결과특징
- 데이터 분석
- 실험 기록
- 계산 노트
왜 이런 방식이 필요했을까
프로그램을 유지보수할 때 가장 어려운 질문은 이것이다.
왜 이렇게 만들었지?코드는 보이지만 설계 이유는 사라지기 쉽다.
문학적 프로그래밍은 이 문제를 해결하려 한다.
설계 설명
↓
코드
↓
결과모든 사고 과정을 문서와 코드에 함께 남긴다.
장점
문학적 프로그래밍의 장점은 명확하다.
1. 설계 의도를 기록
코드를 읽는 사람이
왜 이런 구조인지 이해할 수 있다.
2. 문서와 코드가 분리되지 않는다
보통
코드
문서가 따로 존재한다.
문학적 프로그래밍에서는
문서 = 코드다.
3. 유지보수에 강하다
설계 이유가 함께 남기 때문에
나중에 수정하기 쉽다.
단점
현실에서는 많이 쓰이지 않는 이유도 있다.
1. 작성 비용이 크다
설명을 계속 유지해야 한다.
2. 팀 개발에 부담
빠르게 개발할 때는
설명 구조를 유지하기 어렵다.
3. 도구 생태계 제한
IDE 중심 워크플로와
완전히 잘 맞지 않는 경우가 많다.
현대적 형태
완전한 문학적 프로그래밍은 드물지만
아이디어는 여러 곳에 살아 있다.
예
Jupyter Notebook
Markdown + 코드
Research papers특히 데이터 과학에서는
설명과 코드가 함께 있는 문서가 매우 흔하다.
문학적 프로그래밍의 본질
문학적 프로그래밍은 도구보다
태도에 가깝다.
질문은 이것이다.
이 코드는 무엇을 하는가?가 아니라
왜 이런 방식으로 설계했는가?를 먼저 설명한다.
결론
문학적 프로그래밍을 한 문장으로 정리하면 이렇다.
프로그램을 기계가 읽는 코드가 아니라,
사람이 읽는 글로 취급하는 방식.
즉
코드 중심 개발
→ 설명 중심 개발이라는 발상의 전환이다.
그리고 좋은 소프트웨어는
종종 이런 질문에서 시작된다.
이 코드는 왜 존재하는가?
