이해 가능한 소프트웨어를 향하여

• 프로그래밍은 읽기·테스트·유지보수가 어렵고 프로젝트 이해가 소수에게 집중되므로, LLM으로 코드 작성을 자동화하기보다 코드가 필요한 범위 자체를 줄이는 추상화가 필요함
• LLM은 개발자와 비개발자 모두에게 확산됐지만, 환경 파괴성, 도난 코드 기반, 일관성 없는 결과, 의존성 유발 같은 문제가 여전히 큼
• 출발점은 코드를 먼저 쓰고 문서를 덧붙이는 관행을 뒤집어, 문서 먼저 작성하고 코드가 그 뒤를 따르는 문학적 프로그래밍으로 옮기는 것임
• GUI 기반 시각 프로그래밍과 결정론적 자연어 프로그래밍은 코드가 여러 표현 중 하나가 되게 만들 수 있지만, 시각 환경에는 스크린리더 통합 같은 접근성 설계가 필수임
• Eve와 Inform 같은 선행 시도, Entangled·ReTangled 같은 도구는 초보자와 전문가 모두가 이해 가능한 방식으로 소프트웨어를 만들 가능성을 보여줌

LLM은 목표 모델이 아님

• LLM은 산업 소프트웨어 개발에서 중요한 도구가 됐고, 경험 많은 전문가도 테스트, 디버깅, 코드 작성에 LLM 에이전트를 사용함
• 비개발자도 LLM으로 개인용 스크립트부터 과학 데이터 처리 도구까지 만들고 있음
  • 프로그래밍은 시작점이 불명확하고, 특정 언어의 문법과 라이브러리 세부를 배우고 싶지 않은 사람에게 접근성이 낮음
• LLM 확산은 LLM이 프로그래밍을 아주 잘해서라기보다, 프로그래밍 자체가 복잡하고 불쾌한 작업이라는 신호에 가까움
  • 충돌하는 소프트웨어 스택, 끝없는 보일러플레이트, 까다로운 라이브러리가 많음
  • 평균적인 소프트웨어 개발자의 일은 흥미로운 코드를 개발하기보다 라이브러리를 붙이는 작업으로 줄어듦
• LLM에는 여전히 큰 문제가 남아 있음
  • 환경 파괴적임
  • 도난 코드에 근본적으로 기반함
  • 일관성 없는 코드를 생성함
  • 의존성을 심어줌
• 현재 프로그래밍 패러다임도 부족하지만, LLM 역시 더 나은 대안이 필요함

자동화 대신 추상화하기

• LLM을 포기한다고 해서 자동화, 높은 수준의 추상화, 인간 친화적 인터페이스까지 포기할 필요는 없음
• 목표는 코드 작성을 더 쉽게 만드는 데서 멈추지 않고, 코드 아래의 소프트웨어 스택을 다루며 코드 작성 자체의 필요를 줄이는 것임
• 어떤 추상화 계층을 반복적으로 자동화하고 싶어진다면, 그 계층을 자동화하기보다 추상화해 없애는 방향이 더 적절함
• LLM이 프로그래밍에 널리 쓰이는 현상은 코드 작성 프로세스를 자동화하고 싶은 욕구를 보여주며, 이는 코드 작성의 필요 자체를 추상화해야 한다는 신호임
• 인간이 컴퓨터처럼 생각하게 만들기보다, 인간이 자연스럽게 생각하는 방식에 가까운 새 추상화 계층이 필요함

문서가 먼저인 프로그래밍

• 이해 가능한 소프트웨어의 첫 단계는 문서화임
  • 다른 사람이 소프트웨어를 이해하길 원한다면, 그 소프트웨어를 설명해야 함
• 일반적인 방식은 코드를 먼저 쓰고, 나중에 doc-comment나 사용 예시를 붙이는 흐름임
• 제안하는 방식은 순서를 뒤집어 문서를 먼저 쓰고, 그 뒤에 코드를 붙이는 것임
  • 사람에게 프로그램이 무엇을 하는지 설명한 뒤, 컴퓨터에게 무엇을 해야 하는지 알려줌
  • 이 개념은 문학적 프로그래밍으로 알려져 있음
• 이 방식에서는 다른 사람의 코드를 바로 읽고 의도를 추론하기보다, 먼저 문서를 읽어 의도를 이해한 뒤 코드를 확인함
• Entangled는 이 접근의 좋은 구현임
  • 문서에서 코드를 추출해 적절한 소스 코드 파일로 배치하는 양방향 tangler임
  • 문서 안의 코드 블록을 편집할 수 있고, 일반 코드 파일에서 편집한 내용도 문서의 코드 블록으로 전파됨
  • 테스트, 리팩터링, 코드 포매팅 같은 기존 도구를 특별한 문학적 프로그래밍 지원 없이 계속 사용할 수 있음
  • tangler는 빌드 시스템에 적은 오버헤드를 더하며, 컴파일러와 비교하면 특히 작음
• 이 접근은 코드의 복잡함 자체를 없애지는 않지만, 다른 사람의 코드를 이해하는 영역에서 LLM을 대체할 수 있음

코드 없애기: GUI와 여러 표현

• 코드는 오래된 시대의 개념이며, 터미널을 통해 컴퓨터와 상호작용해야 했기 때문에 사용해 온 방식임
• 컴퓨팅이 지난 40년 동안 변했는데도, 모호한 기호와 키워드의 1차원 문자열로만 컴퓨터와 소통해야 한다고 고집할 이유는 없음
• GUI는 텍스트 기반 인터페이스보다 복잡한 개념을 다루기 쉽게 하고, 새 사용자에게 더 접근 가능할 때가 많음
• IDE는 편리하게 코드를 편집하는 장소를 넘어, 소프트웨어 개발과 상호작용하는 새 방식이 될 수 있음
  • 일부 IDE는 이미 이런 기능을 제공함
  • 더 나아가 시각 프로그래밍이 누구나 코드 학습 없이 원하는 것을 만들 수 있을 만큼 보편적이고 단순해질 수 있음
• 코드 자체를 완전히 포기할 필요는 없음
  • GUI 표현은 사람이 편집 가능한 여러 표현 중 하나가 될 수 있음
  • 텍스트 기반 운영체제 인터페이스를 선호하는 사람이 있듯, 코드 기반 소프트웨어 편집을 선호하는 사람도 계속 있을 수 있음
  • 다만 코드가 기본값이거나 유일한 선택지일 필요는 없음
• 시각 프로그래밍은 더 접근 가능하도록 설계될 수 있지만, 시각 중심 환경은 시각장애인 배제로 이어질 수 있음
  • 강력한 스크린리더 통합이 필요함
  • 청각적 또는 촉각적으로 풍부하게 이해할 수 있는 대체 표현도 필요함

자연어를 결정론적 추상화로 만들기

• LLM이 추상화 계층을 하나 올린다는 말과 달리, LLM은 추상화가 아니라 자동화 계층에 가까움
• 추상화 계층은 예측 가능하고 신뢰할 수 있어야 하며, 높은 수준의 의도가 낮은 수준에서 정확하고 일관되게 표현되어야 함
• LLM은 프롬프트를 확률적으로 해석하고 의도를 예측하므로 예측 불가능하게 동작함
  • 작업 결과를 무작위적으로 근사하는 과정을 자동화함
  • 추상화라면 매우 손실이 큰 추상화에 가까움
• 자연어 처리(NLP)의 발전은 자연어에서 기계어로 가는 예측 가능한 파이프라인을 만들 가능성을 제공함
• 목표는 LLM 프롬프트처럼 입력하면서도 매번 예측 가능하고 견고한 프로그램을 만드는 것임
  • 다른 사람의 작업을 도난 코드의 평균처럼 증류하지 않고, 정의를 통해 직접 구축함
• 이 접근은 문서와 코드를 더 강하게 결합할 수 있음
  • 문학적 프로그래밍에서 코드 부분을 자연어로 대체하면 문서만 남을 수 있음
  • 사람에게 프로그램 작동 방식을 설명하는 글이, 동시에 기계와 소통하는 글이 될 수 있음
• 이 자연어 프로그래밍은 결정론적이어야 함
  • NLP는 transformer 모델의 생성 능력 없이 문법에서 의미를 파싱하는 데 쓰일 수 있음
  • 파싱된 문법은 다른 프로그래밍 언어처럼 플랫폼 요구에 맞춰 컴파일되는 중간 표현으로 직접 변환될 수 있음
• Inform과 비슷하지만, 더 높은 구문 인식과 더 넓은 정의 네트워크에 연결된 형태를 상정함
• 결정론적 품질 덕분에 프롬프트는 신뢰성 있고 일관되게 코드가 되며, 이는 LLM과 근본적으로 다른 진짜 추상화 계층임

이전 시도: Eve와 Inform

• 이런 아이디어는 새롭지 않으며, 이전에도 구현 시도가 있었음
• Eve는 프로그래밍을 인간에게 더 접근 가능하게 만들려 했던 프로그래밍 언어이자 IDE임
  • 문학적 프로그래밍 접근을 사용함
  • 도메인 특화 데이터 지향 프로그래밍 언어를 소프트웨어 동작을 설명하는 문서 안에 삽입함
  • 코드는 문서에 종속되고, 전체 프로그래밍 환경도 이를 반영함
• Eve는 이 아이디어를 더 확장해 자체 언어를 NLP 질의로 대체하려고도 했음
  • 자연어 처리의 복잡성을 감당할 준비가 되어 있지 않았음
  • 2016년에는 더 발전한 NLP가 머신러닝 중심이 아닌 회사에 쉽게 접근 가능하지 않았음
  • GUI 지향 접근도 실험함
• 전 Eve 기여자도 프로젝트의 복잡성과 LLM 한계에 대한 비슷한 우려를 다룸
• Eve는 수익화에 실패한 야심적인 VC 투자 프로젝트였기 때문에 끝났고, 아이디어가 결실을 맺는 모습을 볼 기회가 없었음
• Inform은 인터랙티브 픽션을 만들기 위한 선언형 언어로, 이런 개념이 더 넓게 적용될 수 있음을 보여줌
• 자연어가 근본적으로 새는 추상화일 가능성은 있지만, 평균적인 사람이 자신의 컴퓨터를 직접 제어할 수 있게 만드는 잠재력은 더 큰 관심을 받을 가치가 있음

다음 단계와 제안된 작업

• 이해 가능한 소프트웨어를 만들기 위한 프로젝트로 ReTangled가 개발 중임
  • Rust로 작성된 Entangled 호환 양방향 tangler임
  • 문학적 프로그래밍을 가능한 한 확장하고, 기존 툴체인과 합리적인 수준에서 긴밀히 통합하는 것이 목표임
  • 현재는 초기 개발 단계이며 기여를 환영함
• 시각 프로그래밍, 문학적 프로그래밍, 자연어 프로그래밍 각각에 대해 더 완전한 글을 쓸 계획이 있음
• 공동체 차원에서는 Eve의 발자취를 이어가되, 약간 다른 접근을 취하는 방식이 제안됨
• 목표는 초보자부터 전문가까지 유용하게 쓸 수 있는, 문서화가 잘 되어 있고 접근 가능한 시각 또는 자연어 프로그래밍 환경을 만드는 것임
• 시작점은 소프트웨어를 더 잘 문서화하는 것이고, 최종 목표는 프로그래밍이라는 개념 자체를 뒤집는 것임