에이전트 시대, 문학적 프로그래밍을 다시 바라봐야 하는 이유

이 글은 문학적 프로그래밍(Literate Programming) 이 왜 오랫동안 매력적인 개념임에도 널리 쓰이지 못했는지, 그리고 AI 코딩 에이전트의 등장으로 이 한계가 어떻게 바뀌고 있는지를 정리한 글입니다.
특히 Emacs Org Mode와 org-babel, 그리고 최근의 LLM 기반 코딩 에이전트가 결합되며 만들어지는 새로운 개발 워크플로우를 중심으로, 앞으로의 코드 작성과 유지 방식이 어떻게 달라질 수 있는지를 살펴봅니다.

반응형

---

문학적 프로그래밍이란 무엇인가

문학적 프로그래밍은 코드와 자연어 설명을 하나의 서술로 엮는 개발 방식입니다.
사전 지식이 없는 독자라도 문서를 읽듯이 코드를 따라가며 “왜 이 코드가 존재하는지”를 이해할 수 있도록 하는 것이 핵심 아이디어입니다.

개념 자체는 매우 매력적입니다.
하지만 현실에서는 다음과 같은 근본적인 문제가 있었습니다.

• 코드와 설명이라는 두 개의 병렬 서술을 동시에 유지해야 함
• 코드가 바뀔 때마다 설명도 다시 써야 하는 추가 노동
• 이 부담 때문에 실무에서의 채택이 제한됨

결국 “좋은 아이디어지만 너무 귀찮다”는 평가를 받아왔습니다.

---

실무에서 살아남은 문학적 프로그래밍의 형태

완전한 문학적 프로그래밍은 드물었지만, 그 아이디어는 일부 형태로 살아남았습니다.

가장 대표적인 예가 데이터 과학 커뮤니티의 노트북 환경입니다.
설명, 코드, 실행 결과가 한 화면에 함께 나타나며, 웹 브라우저에서 바로 확인할 수 있습니다.

또 다른 예가 Emacs Org Mode + org-babel 조합입니다.

• 여러 언어의 코드 블록을 하나의 문서에서 실행 가능
• 실행 결과를 문서 안에 그대로 캡처
• 문서 자체가 실행 가능한 실험 기록이 됨

다만 이 방식은 소수의 열성 사용자에게만 남은 니치한 패턴이었습니다.

---

Org Mode 기반 문학적 프로그래밍의 한계

Org Mode를 대규모 소프트웨어 프로젝트의 진본(source of truth)으로 쓰면 구조가 뒤집힙니다.

• Org 파일이 진짜 소스
• 실제 코드 파일은 Org에서 추출된 결과물
• 매번 수정 후 tangle 과정으로 코드 생성 필요

문제는 여기서 발생합니다.

• 실제 코드 파일을 직접 수정하면, 다음 tangle 때 덮어쓰기 위험
• 자동화는 가능하지만, 워크플로우가 번거로움
• 결국 실무 규모에서는 유지 비용이 큼

이 지점이 문학적 프로그래밍이 확산되지 못한 핵심 이유였습니다.

---

에이전트 이전에도 의미 있었던 활용 패턴

그럼에도 문학적 프로그래밍은 완전히 버려지지 않았습니다.

• 개인 설정 관리
• 수동 테스트와 절차 문서화

특히 Org Mode를 활용한 테스트 워크플로우는 이런 장점을 가졌습니다.

“노트 작성과 테스트 실행을 결합하면, 테스트가 끝날 때 문서가 무료로 생성된다.”

명령줄에서 작업하는 대신,
에디터 안에서 명령을 작성 → 실행 → 결과 확인 → 기록
이 과정이 하나의 문서로 남는 방식입니다.

---

코딩 에이전트와 함께 열리는 새로운 워크플로우

여기서 상황을 바꾼 것이 LLM 기반 코딩 에이전트입니다.

이 에이전트들은 다음과 같은 특성을 가집니다.

• Org Mode 문법을 매우 잘 이해
• 관대한 마크업 언어 특성상 오류에 강함
• 설명과 코드의 상호 변환에 강점

에이전트에게 Org 파일 기반 런북(runbook) 작성을 지시하면 다음이 가능해집니다.

• 각 단계의 의도를 자연어 설명으로 작성
• 코드 블록을 하나씩 또는 전체를 대화형으로 실행
• 실행 결과를 코드 아래에 자동 저장
• 설명을 수정하면 코드 반영
• 코드를 수정하면 설명을 자동 동기화

결과적으로,
문학적 프로그래밍의 최대 문제였던 ‘병렬 서술 유지 비용’이 사라집니다.

---

에이전트가 제거하는 핵심 노동

에이전트에게 다음과 같이 역할을 위임할 수 있습니다.

• Org Mode 파일을 소스의 진본으로 취급
• 항상 설명을 먼저 작성
• 실행 전 자동 tangling 수행

에이전트는

• 코드 수정 후 설명을 다시 쓰는 작업을 지치지 않고 수행
• 설명과 코드 간 불일치를 자동으로 제거

이는 LLM이 가장 잘하는 번역·요약·재서술 능력을 그대로 활용하는 방식입니다.

---

기대되는 이점과 가능성

이 접근이 성공한다면 기대할 수 있는 변화는 큽니다.

• 코드베이스를 다양한 포맷으로 export하여 읽기 쉬움
• 엔지니어 역할이 “작성”에서 “읽기와 이해”로 이동하는 흐름과 잘 맞음
• 각 코드 블록의 의도가 항상 설명으로 함께 제공됨
• 코드 품질이 향상될 가능성

아직은 대규모·본격적인 코드베이스에서 검증되지는 않았지만,
테스트와 수동 프로세스 문서화 영역에서는 이미 실용성을 보이고 있습니다.

---

Org Mode의 한계와 대안 논의

물론 한계도 분명합니다.

• Org 포맷은 Emacs에 강하게 의존
• Emacs 외부 생태계와의 결합이 어려움

Markdown은 대안처럼 보이지만,

• 메타데이터 표현이 부족
• 코드 실행 위치, 환경, 옵션을 표현하기 어려움

Org Mode의 Properties와 header arguments는
문서를 프로그래밍적으로 조작 가능한 객체로 만들어줍니다.
그리고 이제는 LLM이 이런 설정 자체를 대신 작성해 줄 수 있는 상황입니다.

중요한 것은 특정 툴이 아니라 아이디어 그 자체입니다.

---

728x90

핵심 질문은 이것이다

에이전트 시대에 문학적 프로그래밍이 다시 주목받는 이유는 분명합니다.
과거에 문제였던 추가 노동을, 지치지 않는 기계가 대신하기 시작했기 때문입니다.

마지막으로 남는 질문은 이것입니다.

“에이전트를 통해, 서술처럼 읽을 수 있는 대규모 코드베이스를
코드와 설명이 항상 동기화된 상태로 유지하는 것이
과연 실용적인 선택지가 될 수 있을까?”

이 질문에 대한 답이,
앞으로의 개발 문화와 코드 관리 방식의 방향을 결정하게 될지도 모릅니다.

300x250

https://silly.business/blog/we-should-revisit-literate-programming-in-the-agent-era/

We Should Revisit Literate Programming in the Agent Era