에이전트 시대에 문학적 프로그래밍을 다시 검토해야 한다

• 코드와 서술을 결합해 읽을 수 있는 형태로 만드는 문학적 프로그래밍이, 대형 언어모델(LLM) 기반 에이전트 환경에서 다시 실용성을 얻고 있음
• 기존에는 코드와 설명이라는 두 개의 병렬 서사를 유지해야 하는 부담 때문에 채택이 제한되었음
• Emacs Org Mode와 같은 도구는 다언어 실행과 결과 삽입을 지원하지만, ‘tangle’ 과정의 번거로움으로 대규모 프로젝트에는 부적합했음
• 그러나 에이전트가 코드 추출, 설명 갱신, 동기화 작업을 자동화함으로써 이러한 부담이 제거됨
• 코드와 서술이 동기화된 읽기 중심의 코드베이스가 가능해지며, 이는 개발자의 역할 변화와 코드 품질 향상으로 이어질 가능성이 있음

문학적 프로그래밍의 개념과 한계

• 문학적 프로그래밍은 코드와 설명을 하나의 내러티브로 결합해, 비전문가도 코드의 동작을 이해할 수 있도록 하는 방식
  • 코드와 산문이 함께 존재하며, 읽는 사람이 프로그램의 구조와 의도를 서사적으로 파악할 수 있음
• 실제로는 코드와 설명을 병행 관리해야 하는 이중 작업이 필요해 유지가 어렵고, 이로 인해 광범위한 채택이 이루어지지 않음
• 데이터 과학 분야에서는 Jupyter Notebook 형태로 가장 흔히 사용되어, 계산과 설명, 결과가 함께 표시됨

Org Mode와 기존 활용 방식

• Emacs Org Mode의 org-babel 패키지는 다언어 실행을 지원하며, 실행 결과를 문서에 삽입할 수 있음
  • 그러나 대규모 프로젝트에서는 Org 파일이 ‘소스의 진실’이 되기 어렵고, 수정 후 매번 코드 추출(tangle) 과정을 거쳐야 함
  • 자동화가 가능하더라도, 실제 소스와 Org 파일 간의 동기화 충돌이 자주 발생함
• 개인 설정 관리나 수동 테스트 문서화에는 일정한 성공을 거두었으며, 테스트 실행과 기록을 동시에 수행할 수 있었음

에이전트와 LLM의 결합

• Claude, Kimi 등 LLM 기반 코딩 에이전트는 Org Mode 문법을 잘 이해하며, 복잡한 구문 처리에 강점이 있음
• 사용자는 에이전트에게 Org 형식의 실행 계획(runbook) 작성을 요청하고,
  • 산문은 각 단계의 의도를 설명하고,
  • 코드 블록은 검토 후 대화형으로 실행 가능하며 결과가 문서에 저장됨
• 사용자는 산문을 수정해 코드 갱신을 요청하거나, 반대로 코드를 수정해 설명을 재작성하도록 요청할 수 있음
  • 이로써 코드와 설명의 병렬 유지 문제가 사라짐

자동화된 문학적 프로그래밍의 효과

• 에이전트가 tangle 작업과 코드 추출을 자동 처리하며, Org 파일을 단일 진실의 원천(source of truth) 으로 유지
• LLM은 번역과 요약 능력을 활용해 문학적 프로그래밍의 추가 노동을 제거
• 코드베이스는 다양한 형식으로 내보내기(export) 가능해, 읽기 중심의 개발 환경에 적합
• 코드 블록의 의도를 설명하는 산문이 함께 존재함으로써 생성 코드의 품질 향상 가능성이 있음

도구의 한계와 향후 가능성

• 현재는 Org 형식이 Emacs에 종속되어 있어 확장성에 제약이 있음
  • Markdown은 대안이 될 수 있으나, 메타데이터와 코드 블록 속성(header arguments) 을 지원하지 않아 한계가 있음
• Org Mode의 속성(properties) 기능은 코드 실행 위치나 원격 실행 등 세밀한 제어를 가능하게 함
• 핵심은 특정 도구가 아니라, “코드를 읽을 수 있는 서사로 만드는 아이디어 자체” 에 있음
• 마지막으로, 에이전트가 코드와 서술을 자동 동기화하는 대규모 코드베이스가 현실화될 수 있는지 질문을 던짐