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

 (gracefulliberty.com)
1P by GN⁺ | ★ favorite | 댓글 1개
  • 프로그래밍은 읽기·테스트·유지보수가 어렵고 프로젝트 이해가 소수에게 집중되므로, 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의 발자취를 이어가되, 약간 다른 접근을 취하는 방식이 제안됨
  • 목표는 초보자부터 전문가까지 유용하게 쓸 수 있는, 문서화가 잘 되어 있고 접근 가능한 시각 또는 자연어 프로그래밍 환경을 만드는 것임
  • 시작점은 소프트웨어를 더 잘 문서화하는 것이고, 최종 목표는 프로그래밍이라는 개념 자체를 뒤집는 것임

함께 보면 좋은 글 β

GN⁺   [-]
Lobste.rs 의견들

  • 코드를 버리거나 자연어 산문에 종속시키는 방식이 프로그래밍의 접근성 문제를 푸는 효과적인 해법인지는 확신이 안 감
    프로그래밍 언어는 컴퓨터와 인간의 요구 사이에서 균형을 잡는 사용자 인터페이스임. 잘 만든 명료한 형식 표기는 개인의 이해와 사람·기계 간 아이디어 전달을 돕는 사고의 도구가 될 수 있음
    APL 계열 언어를 배우며 큰 영향을 받았고, 익히는 데 시간은 들었지만 한 번 배우고 나니 더 큰 문제를 머릿속에 담고 더 정밀하게 생각할 수 있게 됨. K는 복잡한 IDE 없이 머릿속, 종이, 단순한 REPL만으로도 문제를 풀 수 있음
    문서화가 잘 된 프로젝트와 문예적 프로그래밍은 가치 있지만, 문서도 읽고 쓰고 고치는 시간이 듦. 테스트와 마찬가지로 문서가 많다고 무조건 좋은 건 아니며, 간결하고 구조화된 설명과 설명하기 쉬운 간결한 프로그램을 선호함. 코드는 시가 될 수 있지만, 대부분의 시는 프로그램이 아님

    • 형식적인 프로그래밍을 좋아하지만, 평균적인 사용자가 컴퓨터의 힘을 쓰기 위해 프로그래머가 되어야 한다고는 믿지 않음
      대부분의 사람은 이런 내부 작동 방식을 배우지 않을 것이므로, 더 많은 사람이 참여할 수 있게 진입 장벽을 낮추고 싶음
      그래서 LLM이 인기 있다고 봄. 비프로그래머가 작업을 처리하려고 LLM으로 코드를 쓰는 모습을 자주 보지만, 글에서 말했듯 LLM에는 피하고 싶은 큰 결함들이 있음. 사람들은 자연어 또는 편한 사용자 인터페이스로 게임을 개조하고, 스크립트를 만들고, 프로그램을 확장할 수 있어야 함
      “코드를 폐지하자”는 표현은 조금 과했을 수 있지만, 많은 사람은 코드에 대해 생각하고 싶어 하지 않으며 그럴 필요도 없어야 함

  • 프로그래머들이 비프로그래머를 버려둔 셈임
    Visual Basic은 죽었고, 프레임워크 없는 PHP도 활발해 보이지 않으며, Access도 사실상 죽었음. Notion이나 Airtable 같은 데이터베이스 비슷한 도구는 남아 있음
    프로그래머들은 코드 쓰기를 너무 사랑해서, 단순한 문제에 대한 단순한 해법과 멀어진 사람이 많음
    Python이 한때 비프로그래머 세계를 휩쓴 건 단순해 보였고 Pandas 같은 도구도 쓰기 쉬워 보였기 때문임. 흥미롭게도 많은 프로그래머는 Python이나 Pandas를 별로라고 생각함. 예를 들어 표준 라이브러리로 쉽게 할 수 있는 일을 Pandas로 처리한 코드를 보면 꽤 질리게 됨
    예전에는 비프로그래머도 HTML 페이지를 만들고 색과 이미지를 넣었음. 요즘 프로그래머에게 정적 웹사이트를 만들어 달라고 하면 터무니없는 복잡성이 딸려옴. 일부는 필요하지만, 대부분은 전혀 불필요함. 프로그래머들이 단순한 웹사이트를 만들 때 쓰는 절차를 비프로그래머에게 주면, 20년 전에는 HTML 편집을 즐겼을 사람들도 비명을 지르며 도망갈 것임
    요즘 오히려 훨씬 어려워진 것들이 있다는 점이 깊이 아이러니하고 불안함

    • 전혀 말이 안 되는 얘기임. 요즘도 누구나 HTML을 쓸 수 있고, 오히려 예전보다 쉬워졌음
      CSS는 강력해졌고, 브라우저는 덜 망가져 있으며, 모든 걸 도와줄 개인 코딩 도우미도 있음. 순수 Python도 마찬가지로 그냥 쓰면 됨. 프로그래밍은 그 어느 때보다 쉬워졌음
      현대 기술 스택의 복잡성은 대개 이유가 있지만, 이유가 생긴 뒤에 써야 하고 초보자가 쓸 필요는 전혀 없음
      사람들이 HTML 웹사이트나 기본 프로그램을 만들지 않는다면, 그건 하고 싶지 않아서임. 미래에는 모두가 기본 프로그래밍을 알 거라고 생각했지만, 실제로는 사람들이 그냥 하고 싶어 하지 않는다는 게 드러났음. 자동차나 자전거도 기본 정비는 할 줄 알아야 한다고 주장할 수 있지만 사람들은 거부함. 그건 작업이 어렵거나 불가능하다는 뜻이 아니라, 하려는 의지가 없다는 뜻에 가까움
      일반 대중의 컴퓨터 활용 능력은 거의 발전하지 않았다고 보며, 프로그래밍의 복잡성과는 관련이 없음. 교육 현장에서는 오히려 컴퓨터 활용 능력이 퇴보하는 것 같다고도 하는데, 그게 복잡한 프런트엔드 프레임워크 때문이라고 보기는 어려움

  • 글의 많은 부분에는 동의함. 예를 들어 문예적 프로그래밍은 좋아하지만, 프로그래밍 자체가 별로라고는 생각하지 않음
    일부 프로그래밍은 별로고, BigTech 회사에서 하는 프로그래밍은 대체로 별로인 경우가 많음. 하지만 나 자신이나 사랑하는 사람들을 위해 프로그램을 쓰는 일은 지금도 즐겁다
    Entangled는 몰랐는데 좋은 아이디어로 보이고, 문예적 프로그래밍에서 가장 큰 고통인 LSP와 기존 도구의 비인지 문제를 다룸. 그래서 지금까지는 주로 NixOS 설정 같은 선언형 언어에 문예적 프로그래밍을 썼음
    양방향 문예적 프로그래밍이라면 비선언형 언어를 쓸 때 삶이 더 편해질 수도 있겠음. ReTangled를 한번 써볼 생각임

    • 프로그래밍은 별로가 아님. 그 문장까지는 글쓴이에게 동의했지만, “GUI를 받아들이자”가 나오면서 흥미가 식었음
      GUI는 주로 임원급 이상이 자기들이 이해하고 할 수 있는 일을 직원들이 하고 있다고 믿게 만들기 위해 존재하는 것처럼 보임
      시각적 드래그 앤 드롭 ETL 도구 수업을 들었는데, 첫 시스템과 거의 같은 걸 다시 만들기 어렵고 전체를 버전 관리하기도 어렵겠다는 생각만 남았음. 2010년에 당시 회사가 쓰던 시각적 드래그 앤 드롭 cron 대체 시스템도 비슷했음
      임원은 끌어다 놓기 쉽지만, 실무자는 오류 찾기, 버전·백업 유지, 재사용이 어려워짐
    • 그 기능이 주목적이라면 ReTangled에서 stitching이 동작할 때까지는 Entangled를 쓰는 쪽을 추천함
    • 순간순간 쓰는 재미가 있는 무언가를 사용자가 좋아할 만한 것으로 끌어올리는 과정에는 진짜 고된 구간이 있음
      재미있는 시제품을 운영에 올릴 만한 것으로 만들려면 오류 처리, 직렬화, 역직렬화, 형식 투영 등이 많이 들어감. 훌륭한 사용자 경험은 거의 항상 지저분한 내부 구조를 수반한다는 게 내 규칙 중 하나임
      개인적으로는 그 대부분을 즐기지 않고, 예전에는 지름길을 택하거나 아예 그 작업을 하지 않은 적도 있음

  • 꽤 강하게 동의함. WYSIWYG 편집기를 보면, 웹 개발을 완전히 대체하지는 않았지만 기본적인 웹사이트나 단순한 상품 판매만 원하는 사람들의 상당한 틈새를 줄여줬음
    아직도 좋은 GUI 인터페이스로 더 단순하게 만들 수 있는 소프트웨어 영역이 큼
    지금 코드를 단순히 이어 붙이거나 LLM을 마구 돌리고 있다면, 실제로는 GUI 프로그래밍이 더 나을 수도 있음. 내가 자주 쓰는 코드도 REST 서버인 경우가 많은데, 이런 걸 위한 무언가를 만들지 못할 이유는 없음

  • 같은 목표를 공유하고 있고, 내가 쓰고 싶은 정확한 해법을 제공할 기술 스택을 수년 동안 고민해 왔음
    Curv라는 프로젝트를 하나 공개하긴 했지만, 머릿속에만 있는 훨씬 더 아름다운 시스템의 작은 일부일 뿐임
    수천 명의 다른 사람들도 이 문제에 매달려 왔음. 문제의 크기상 팀 작업이 필요해 보이지만, 실제로는 작은 1인 프로젝트가 대부분임. 가장 강한 비전을 가진 사람일수록 팀 목표를 위해 자기 비전을 타협하고 싶어 하지 않는 경우가 많음. 이걸 어떻게 해결해야 할지는 모르겠음
    영감을 주는 프로젝트로는 Alan Kay의 Dynabook 비전, 여기서 이어진 Smalltalk, Alan Kay의 후속 프로젝트인 STEPS Toward the Reinvention of Programming, Bret Victor의 작업, 특히 그의 놀라운 성과인 Dynamicland가 있음
    이 주제에 관심 있는 커뮤니티로는 예전에 Future of Coding이라 불리던 Feeling of Computing이 있음. 더 추가할 것이 있으면 알려주면 좋겠음

  • “LLM 프롬프트에 넣듯 지시를 입력해 완전한 프로그램을 만들되, 매번 예측 가능하고 견고하게 동작하게 하자”는 발상은 자연어에서 결정적이고 일관된 의미론을 파싱할 수 있다는 거대한 가정을 깔고 있음
    하지만 애초에 그게 참이라고 생각하지 않음. 아직 제대로 작동시킨 적이 없다는 문제를 제쳐두더라도, 가능한 일인지도 의심스러움
    언어에는 맥락이 너무 많음. 같은 문장을 열두 번 말해도 억양, 청중, 물리적 위치, 발화 매체, 시간대에 따라 매번 미묘하게 다른 의미가 생김. 전통적인 자연어 처리 기법은 이런 유연성을 근본적으로 다루지 못함
    바로 그래서 LLM이 존재함. 아마 존재하지 않을 엄격한 맥락 규칙을 정하려 하기보다, 맥락 감지를 가중치에 인코딩할 수 있는 모델을 학습시키는 방식임. 이게 놀랄 만큼 효과적이라는 게 드러났음
    사람들이 LLM을 쓰는 이유도 여기에 있음. 지금까지 만든 어떤 자연어 인터페이스보다 맥락을 훨씬 잘 고려해 기대한 응답을 만들 수 있기 때문임. 그런 관점에서는 정말로 작동함. LLM 밖의 자연어 처리는 같은 수준의 성공을 보여주지 못했음

  • 풍부한 시각적 프로그래밍 환경에 관심이 있다면 Glamorous Toolkit이 가능한 방향을 보여주는 좋은 예임 https://gtoolkit.com/
    아직 완성형이라고 보지는 않지만, 기존에 만들어진 것들을 더 멀리 밀어붙인 도구임. LLM 생성 코드의 시대에는 이미지 기반 환경에 대해서도 말해볼 여지가 있음

    • Glamorous Toolkit 웹사이트를 훑어봤는데 뭔지 전혀 잡히지 않았음. 몇 문장으로 요약해 줄 수 있음?

  • 부족한 것은 지금 프로그래머들이 흔히 쓰는 원시 요소, 즉 함수와 모듈로 정리된 코드 줄을 넘어서는 예측 가능한 추상화임
    특히 단순한 데이터 변환이 아니라 복잡한 외부 시스템을 모델링하는 요구사항을 그런 요소만으로 옮기면, 인간 프로그래머가 만들어도 점점 커지는 진흙덩이가 됨. LLM도 그 모습을 흉내 내고 있음

답변달기