Dijkstra의 “자연어 프로그래밍의 어리석음”에 대하여

• 프로그래밍의 어려움을 형식 기호 탓으로 돌리는 관점은 기계가 자연어를 이해하면 인간의 부담이 줄어든다는 잘못된 기대를 낳음
• 초기 기계어의 위험은 고급 프로그래밍 언어로 일부 완화됐지만, 잘못된 답이 오류 메시지로 바뀌었을 뿐 정밀한 지시가 필요하다는 본질은 남아 있음
• 자연어 인터페이스는 노동을 나눠 갖는 해법이 아니라, 인간과 기계 사이의 협력·소통 비용을 키워 양쪽의 부담을 늘릴 수 있음
• 수학의 발전은 Vieta, Descartes, Leibniz, Boole 같은 인물들이 만든 형식 기호 체계가 복잡한 사고를 다루는 핵심 도구였음을 보여줌
• 자연어 프로그래밍을 기본 입출력으로 삼았다면 컴퓨터 과학은 결국 사용 가능한 형식 시스템으로 되돌아가기 위한 긴 우회로가 됐을 가능성이 큼

---

자연어 프로그래밍을 향한 기대와 착각

• 자동 계산 초기부터 일부 사람들은 프로그래밍이 형식 기호에 요구되는 주의와 정확성을 필요로 한다는 점을 결점으로 여김
  • 기계가 잘못된 명령도 엄격히 수행하는 점을 문제 삼았고, 사소한 사무적 오류를 거부하는 더 “분별 있는” 기계를 기대함
• 기계어는 중복성이 거의 없어 인간과 기계 사이의 위험한 인터페이스였음
  • 이에 대응해 고급 프로그래밍 언어가 개발됨
  • 시간이 지나면서 많은 사소한 실수가 잘못된 답 대신 오류 메시지로 이어지는 개선이 생김
  • 그러나 프로그래밍 언어에 대응하는 추상 기계는 여전히 주어진 명령을 충실히 수행하는 자동기계이며, 무의미한 명령도 실행할 수 있음
• 자연어로 기계를 지시하자는 제안은 기계를 더 복잡하게 만들더라도 인간의 부담을 줄일 수 있다는 논리에 기대고 있음
  • 이 논리는 “형식 기호 사용 의무”를 어려움의 원인으로 볼 때만 그럴듯함
  • 인터페이스 변경은 노동을 단순히 나누는 일이 아니라, 인터페이스를 가로지르는 협력과 소통 비용을 추가함
  • 경험적으로 인터페이스 변경은 양쪽의 작업량을 크게 늘릴 수 있으며, 그래서 “좁은 인터페이스” 선호가 커짐

형식 기호가 사고를 확장하는 방식

• 수학의 역사에서 자연어적·그림 중심 방식은 반복적으로 한계를 드러냄
  • 그리스 수학은 언어적·그림 활동에 머물러 정체됨
  • Moslem “algebra”는 상징 사용을 잠깐 시도한 뒤 수사적 방식으로 돌아가며 사라짐
  • 서유럽은 Vieta, Descartes, Leibniz, 이후 Boole 같은 인물들의 의식적으로 설계된 형식 기호 덕분에 중세 스콜라주의의 언어적 정밀성 시도에서 벗어남
• 형식 텍스트의 장점은 정당한 조작이 몇 가지 단순한 규칙만 만족하면 된다는 데 있음
  • 이 규칙성은 자연어에서 피하기 어려운 여러 종류의 무의미함을 배제하는 도구가 됨
• 형식 기호 사용은 부담이 아니라 특권에 가까움
  • 형식 기호 덕분에 예전에는 천재만 할 수 있던 일을 학생들도 배울 수 있음
  • 1977년 한 기술 보고서 서문에서 “명확성을 위해 논리 연결사의 표준 기호조차 피했다”는 문장은 이런 오해가 한 사람에게만 국한되지 않음을 보여줌
• 자연어의 “자연스러움”은 무의미함이 명백하지 않은 문장을 쉽게 만들 수 있다는 점으로 이어짐

자연어만 허용된 세계의 컴퓨터 과학

• 처음부터 정보처리 장비의 입출력이 모국어로만 이뤄졌다면, 컴퓨터 과학은 충분히 정의된 형식 시스템으로 이동하기 위한 “black art”에 가까웠을 것임
  • 사용 가능한 수준으로 인터페이스를 좁히려면 전 세계의 지성이 필요했을 것임
  • 인류 역사를 고려하면 다시 수천 년이 걸렸을 수도 있음
• 서구의 교육 흐름이 지적 훈련에서 멀어지며 사람들이 자기 언어를 다루는 능력이 크게 떨어졌다는 우려도 붙어 있음
  • 과학 논문, 기술 보고서, 정부 간행물 등에서도 면밀히 읽으면 의미 없는 말이 많다는 점을 예로 듦
  • 이 현상은 “The New Illiteracy”로 불리며, 자연어 프로그래밍 실패를 예측할 기술적 통찰이 없는 지지자들에게도 경고가 됨
• 자연어로 프로그래밍되는 기계는 Dutch, English, American, French, German, Swahili 어떤 언어를 쓰더라도 만들기만큼 사용하기도 어려울 것이라는 의심으로 마무리됨

[GN⁺]

Hacker News 의견들

• 여기서 LLM을 옹호하는 건 좋지만, 반대로 해보면 어떨까 싶음. 중간 정도 복잡도의 프로젝트를 가져와서 좋아하는 LLM으로 코드를 다시 자연어로 변환해 보는 것임
  소스 코드에 들어 있는 동작과 요구사항을, 프로그램을 재현할 수 있을 만큼의 세부사항을 잃지 않고 합리적으로 설명해 줄까? 그 자연어 설명이 추론하기 더 쉬울까?
  사람들이 보여주는 바이브 코딩 앱이 대체로 단순한 데는 이유가 있다고 봄. 복잡성과 정밀성을 관리하기 어려운 수준이 있고, 평문 영어로 정의할 수는 있어도 그 설명이 확장 가능하고 이해 가능하며 정밀한 언어보다 더 설명적인지는 의문임
  법률 문서가 평문 영어가 아닌 이유도 단순한 진입장벽 만들기 이상이라고 생각함

  • 다른 분야 예로, 항공 기상 예보와 공지는 강하게 축약되고 코드화된 형식으로 배포됨. 예를 들어 지금 호주 시드니의 기상은 METAR YSSY 031000Z 08005KT CAVOK 22/13 Q1012 RMK RF00.0/000.0 같은 식임
    새 조종사들은 거의 예외 없이 “왜 말로 쓰지 않나?”라고 묻고, 실제로 대부분의 비행 계획 앱은 이 코드를 산문으로 바꿔줌
    하지만 전문 조종사나 관제사는 코드 형식을 훨씬 선호함. 한 줄이라 압축적이고, 형식이 잘 정의되어 있어 필요한 항목을 어디서 찾아야 하는지 정확히 알 수 있으며, 모호하지 않고 명확함
    수학과 코딩도 마찬가지로, 어느 수준 이상의 숙련도에 도달하면 자연어의 복잡성과 중복이 이득보다 비용이 더 커짐. 모든 전문 분야에 적용되는 듯함
  • 정밀성보다는 작업 기억의 문제에 가깝다고 봄. 사람이 충분히 큰 산문 버전을 이해하기 어려워하는 이유는 LLM이 큰 산문 버전을 다루기 어려워하는 이유와 비슷하게, 작업 기억이 제한되어 있기 때문이라고 추정함
    산문에서 정보를 다시 불러오는 데 시간이 많이 들고, 긴 글을 읽는 사람들은 밑줄을 긋고 메모하며 자기만의 축약형을 만들기 시작함
    압축된 형식과 추상화는 작업 기억과 정보 탐색의 부담을 줄여줌. 그래서 꼭 언어의 정밀성 문제만은 아닐 수 있음
  • 언어는 엄청난 양의 맥락을 담을 수 있음. 예를 들어 “운전용 최신 내비게이션 앱을 원하고, 절대 지나가고 싶지 않은 교차로를 선택할 수 있으면 좋겠다”라는 문장은 복잡도는 낮지만 엄청난 정보를 인코딩함
    그 문장에서 실제 작동 앱까지 가려면 수많은 구현 세부사항이 필요하다고 생각하겠지만, 그 정도 정보만으로도 내 필요를 해결하는 동작하는 애플리케이션에 도달할 가능성은 있음
    그리고 그걸로 충분히 만들 수 있다면, “그걸 콘플라워 블루로 바꿔줄 수 있나?” 같은 요청도 쉬워지고 사용자는 거기서 반복 개선할 수 있음
  • 물론 우리는 새는 추상화를 만들고, 법률 문서에서도 그런 일이 일어남
    ISA와 디스플레이 드라이버만 주고 LLM에게 어셈블리로 그래픽 앱을 만들라고 하면 아무것도 못 얻을 것임
    하지만 추상화가 산더미처럼 쌓여 있으면 아마 가능해짐
    LLM을 옹호하려는 게 아니라, 올바른 추상화와 재사용 가능한 구성요소를 제공하면 훨씬 더 가까이 갈 수 있다고 보는 것임
  • 법률 문서가 평문 영어가 아닌 데는 이유가 있음. 법률 문구의 정밀성 중 일부는 특정 용어의 의미가 이미 법원 판례로 더 정확히 정의되어 있기 때문임

• Hal Abelson의 오래된 인용이 떠오름
  “이 주제에 대한 우리의 접근 아래에는 ‘컴퓨터 과학’은 과학이 아니며 그 중요성은 컴퓨터와 거의 관련이 없다는 확신이 있다. 컴퓨터 혁명은 우리가 생각하는 방식과 생각을 표현하는 방식의 혁명이다. 이 변화의 본질은 절차적 인식론이라고 부르는 것이 가장 적절할 어떤 것의 등장이다. 이는 고전적 수학 분야가 취하는 더 선언적인 관점과 달리, 명령형 관점에서 지식의 구조를 연구하는 것이다. 수학은 ‘무엇인가’라는 개념을 정밀하게 다루는 틀을 제공한다. 계산은 ‘어떻게 할 것인가’라는 개념을 정밀하게 다루는 틀을 제공한다.”

  • 핵심은 계산은 일이 일어나게 만드는 것이라는 점임. LLM으로 코딩하면 추상화 단계가 하나 늘어나지만, “일어나는 일”의 정밀성과 정확성에 대한 필요는 사라지지 않음
    멋진 데모와 “AI 때문에 코딩은 죽었다”는 선언이 아무리 많아도, 실제 작업의 대부분은 AI를 둘러싼 전처리·후처리·평가로 이동함
    프로그래밍 접근성을 높인다는 점에서는 좋지만, 프로그래밍을 정말로 대체할 수는 없음
  • 요즘 컴퓨터 과학 프로그램에서 가르치는 내용은 확실히 저런 방향이 아닌 듯함
  • Hal Abelson이 전 세계의 함수형 프로그래밍 컴퓨터 과학자들을 아무렇지 않게 격분시키고 있음

• 드디어 누가 이렇게 표현해 줬음. 자연어에는 인간의 정신적 한계에서 비롯되는 내재적 한계가 있음. 사람의 마음은 때로 너무 추상적이거나 너무 구체적으로 생각하고, 중요한 세부사항이나 일반화를 놓침
  프로그래머로서 직접 느낀 바로는, 어떤 과제의 문제나 심지어 부조리는 코드를 코드로, 즉 엄격한 기호 체계로 구현하기 시작한 뒤에야 드러나는 경우가 많음
  게다가 무언가를 자연어로 정확히 설명하는 데 걸리는 시간이 그냥 알고리즘을 코드로 쓰는 시간보다 더 오래 걸릴 때도 많음

  • 맞음. 추상화를 선호하는 성향이 있어서 사물을 추상적으로 이해하는 편인데, 그걸 자연어로 표현하기가 극도로 어려울 때가 많음
  • 오늘날 LLM의 한계에 대해 현실적인 기대가 필요함. 철학적으로도 자연어는 사람 사이에 아이디어를 전달하는 데 불완전한데, 그게 자연어의 주된 목적임에도 그렇다
    문장을 고쳐 쓰거나 “사실 내가 말하려던 건…”이라고 하거나, 보내기 전에 이메일을 다시 표현하는 일이 얼마나 잦은가? 우리는 인간이고 첫 시도에 완벽한 경우는 드묾
    이제 이 불완전한 의사소통 형식인 자연어를, 의도한 대로가 아니라 말한 그대로 수행하기로 악명 높은 기계의 언어인 코드로 변환하고 있음
    자연어 처리는 앱이나 스크립트 작성을 올바른 방향으로 시작하게 해주는 데 엄청나게 유용함. 하지만 결국 여기저기 리팩터링이 필요할 수 있음
    LLM에서 가치를 얻는 데 코드 고수가 될 필요는 없지만, 그래도 코딩 능력은 여전히 도움이 되고 때로는 필요함

• /s: 아직 충분히 멀리 가지 않았기 때문임. 사람들은 자연어로 컴퓨터 프로그램을 생성하지만, 대신 프롬프트를 직접 실행해야 함
  “너는 그래픽 시스템이다. 화면에 무엇이 있는지 관리하는 존재다. 모든 프로그램으로부터 ‘창’을 만들고 없애는 요청을 받을 수 있고, 이전에 만든 창에 텍스트·선·원 등을 그리라는 추가 요청도 받을 수 있다. 항목은 어떤 색이든 가능하다.
  또한 사용자가 마우스를 클릭한 창을 만든 쪽에 더 많은 클릭 정보를 보내야 한다.
  창 관리자는 특별한 프로그램이며, 시스템에 연결된 모든 모니터에서 어떤 창이 어디에 표시되는지 너에게 알려줄 수 있다”
  그리고 “너는 틱택토 프로그램이다. 화면에 무엇이 있는지 관리하는 그래픽 시스템이 있다. 너는 그 시스템에 ‘창’을 만들고 없애라고 명령할 수 있고, 이전에 만든 창에 텍스트·선·원 등을 그리라고 할 수 있다. 항목은 어떤 색이든 가능하다.
  네가 그리는 그래픽은 사용자가 마우스를 클릭하며 차례를 진행하는 틱택토 게임을 보여줘야 한다. 사용자가 이기면…
  사용자가 클릭당 과금 구독을 하지 않는 한 게임에 광고를 추가하라”
  이 정도면 게임이 돌아가기에 충분할 것임
  저장하려면 또 다른 프롬프트가 필요함. “너는 파일 시스템이다. 디스크에 데이터를 영속화하는 존재다…”
  그리고 “너는 멀티태스킹 운영체제다. 여러 LLM에게 시스템의 CPU와 메모리를 완전히 제어하고 있다는 생각을 제공한다. 너는…”도 필요함
  내년 4월 초에 이걸 보게 되길 기대함

  • 이런 프롬프트들은 현재 내부적으로 Python 코드 생성과 실행으로 구현되어 있음

• “기계어는 거의 모든 형태의 중복성이 없어서 사람과 기계 사이의 불필요하게 위험한 인터페이스로 곧 인식되었다. 이런 인식에 부분적으로 대응해 이른바 ‘고수준 프로그래밍 언어’가 개발되었고, 시간이 지나며 우리는 어리석은 실수에 대한 보호를 어느 정도 강화하는 법을 배웠다. 이제 많은 어리석은 실수가 잘못된 답 대신 오류 메시지로 이어진다는 것은 중요한 개선이었다.”
  우리가 집단적으로 LLM 프로그래밍에 너무 빨리 뛰어든 느낌임. Rust가 어리석은 실수를 짚어내고 수정 방법을 훨씬 명확하게 만드는 방식으로 발전해 온 점이 정말 좋았음
  개발자로서 내가 작업 중인 코드의 맥락과 이해는 여전히 갖고 있고, 컴파일러가 명백한 오류와 수정법을 알려줌. 반면 LLM 사용은 반쯤 지능적인 추측 게임처럼 느껴짐
  Rust 컴파일러는 제자를 가르치는 스승이고, LLM은 스승을 교정하는 자신만만한 졸업생 같음. Rust의 접근을 훨씬 선호하고 가능하다면 더 발전했으면 함

  • Rust 등에는 타입 추론이 있고, LLM에는 이른바 “추론”이 있음. LLM은 이해를 가장하며, 그 거짓은 언젠가 반드시 대가를 치르게 될 것임

• 자연어는 규칙과 명령을 전달하는 매체로는 빈약함. 현재 미국 상황이 좋은 예임
  우리는 아직도 어떤 법과 수정헌법 조항이 무엇을 뜻하는지 논쟁 중임. 단어의 의미는 시간이 지나며 바뀌고, 역사적 맥락도 부족해짐
  기계를 자연어로 조작할 수 있으면 좋겠지만, 80년대 중반부터 프로그래밍해 온 입장에서는 BASIC부터 Go까지 이어지는 컴퓨터 언어의 완고함이 좋은 균형을 만든다고 봄. 명령을 내리는 쪽이 기계가 무엇을 해야 하는지 정확히 표현하도록 충분한 책임을 지게 함

• 이 주장에는 어느 정도 동의하지 않음. 현실의 회사에서는 새 기능 아이디어가 어떤 사업 담당자의 머릿속에서 시작되는 경우가 많음. 이 사람은 어떤 형식 언어도 말하지 않을 것임
  따라서 어떻게 보든 기능 구현을 위해서는 자연어에서 기계어로의 번역이 필요함
  보통 첫 단계인 자연어에서 형식 언어로의 번역은 비즈니스 분석가와 프로그래머가 맡음. 그렇다면 그 과정에서 컴퓨터의 도움을 받아보지 않을 이유가 있을까?

  • 컴퓨터는 그 과정에서 도울 수 있고 도와야 함. 하지만 Dijkstra의 논지는 a) 인간의 아이디어가 가진 어려움의 상당 부분은 자연어를 형식 언어로 바꾸는 행위 속에서 발견되고, b) 그 행위 자체가 우리의 형식 논리적 자아를 훈련한다는 것임
    그래서 그는 프로그램을 자연어로 명세해야 한다는 생각뿐 아니라, 우리가 형식 언어를 이해할 필요를 제거하면 복잡한 시스템을 만드는 능력이 늘어난다는 생각도 반박하는 것임
    많은 “번역”은 실제로 번역이 아니라 논리적 모호성, 불일치, 잘못된 가정을 고치는 일임. Dijkstra를 진지하게 받아들이면, 그중 상당수는 자연어 안에서도 가능함. 왜냐하면 그 자리에 평생 형식화해 온 프로그래머들이 있기 때문임
    수학처럼 상당한 형식적 사고가 필요한 다른 직업도 있음. 또한 오래된 증명을 컴퓨터 증명으로 변환하면서 널리 받아들여진 많은 증명에서 구멍과 빈틈이 발견되기도 했음
    뒤집힌 것이 많지는 않지만, 우리는 아직 Fermat의 마지막 정리에 대한 완전한 증명도 갖고 있지 않음 https://xenaproject.wordpress.com/2024/12/11/fermats-last-th...
  • Dijkstra의 논지를 완전히 이해하지 못한 듯함. 그는 번역을 돕는 도구를 쓰지 말라는 게 아니라, 형식 기호로 생각하지 않는 것이 사고를 해친다고 말하는 것임
    형식 체계 안에서 생각하지 않으면 아이디어가 더 나빠짐. 자신의 생각을 형식적인 것으로 다루지 않기 때문임
    예시의 “사업 담당자” 아이디어를 어떻게 번역할지에 대해 그는 별 의견이 없을 것임. 그의 관점에서는 사업 담당자의 아이디어가 이미 형식주의를 따르지 않아 얕고 나쁘며, 번역할 가치가 없기 때문임
  • 첫 단계는 자연어에서 형식 언어가 아니라, 머릿속의 아이디어를 자연어로 옮기는 것임. 컴퓨터가 유용한 것으로 바꿀 수 있을 만큼 그 단계를 제대로 해내는 것이 어렵다
  • 그렇게 하면 컴퓨터가 무엇을 하는지 알 수 없게 됨. 이 글의 핵심은 아이디어를 형식적으로 써내려가는 과정 자체에 가치가 있다는 것임
    “컴퓨터가 중간에 돕게” 하면, 기계에서 충분히 좋은 결과를 얻기 위해 점점 더 형식적인 자연어가 필요해지는 문제에 곧바로 부딪히게 됨
  • 각 사업, 각 활동에는 자기만의 형식 언어가 있지 않나?
    프로그래밍 언어만큼 형식화되어 있지는 않아도 분명 존재함
    어떤 프로세스든 정의하려고 하면, 스스로 의식하지 못해도 결국 형식화 쪽으로 기울게 됨

• “많은 어리석은 실수가 잘못된 답 대신 오류 메시지로 이어진다는 것은 중요한 개선이었다. 이 개선조차 모두가 좋아한 것은 아니었다. 어떤 사람들은 무시할 수 없는 오류 메시지를 잘못된 결과보다 더 짜증나게 여겼고, 프로그래밍 언어의 상대적 장점을 판단할 때 아직도 ‘프로그래밍의 쉬움’을 발견되지 않는 실수를 쉽게 저지르는 것과 동일시하는 듯하다.”
  누가 썼는지 몰랐다면 Rust를 싫어하는 사람들을 정면으로 찌르는 말처럼 보였을 것임

  • Rust? 언제부터 Rust가 정적 타입 안전성의 정점이었나?
    Rust보다 타입으로 더 강한 불변조건을 표현할 수 있는 언어인 Scala를 한동안 써본 뒤로는, 그 특성이 어떤 상황에서든 명확한 승리라고 보지 않게 됨. 더 이상 “더 강한 타입 == 무조건 더 좋음”이라고 생각하지 않음
    “실수를 허용하지 않음”에는 대가가 있음. 타입 체계가 정말 엄격하면 탐색적 작업이 꽤 어려워짐. 빠른 반복이 불가능해질 수도 있음
    작은 변경 때문에 타입 체계를 다시 만족시키려고 프로그램의 절반을 재설계해야 할 수도 있음
    이는 트레이드오프임. 다른 모든 것과 마찬가지임. 견고한 최종 제품에는 좋지만, 빠른 실험에는 방해가 됨
    누군가 Rust와 게임 개발 맥락에서 이 문제를 잘 설명했음: https://loglog.games/blog/leaving-rust-gamedev/
    하지만 Rust나 게임 개발에만 국한된 문제는 아님
  • 진심으로 fractal-of-bad-design 시절의 PHP나 wat-talk JavaScript를 좋아하던 사람들을 떠올렸을 것 같음
    어떤 종류의 어리석음은 시대를 초월하는 듯함
  • Rust를 싫어하는 사람으로서 문제는 오류가 없는데도 나오는 오류 메시지임. Rust 타입 체계는 RAM, CPU, 그리고 어떤 장치도 정확히 모델링하지 않음
    여기서 그가 말하는 것은 인터프리터 언어임
    그는 또한 지금은 컴퓨터 과학자라고 불리는 수학자들 중 하나로, 그의 “알고리즘”은 수학을 단순히 다시 말한 것에 가깝고 장치를 필요로 하지 않음. 실제 컴퓨터를 프로그래밍하는 민망한 활동에 기질적으로 적대적인 사람임

• 자연어로 애플리케이션을 명세하고 만드는 것은, 게임 프로토타입을 시작하기 전에 게임 디자인 문서를 갖는 것과 꽤 비슷함
  하지만 원하는 것의 대부분을 구현하고 나면 구현물이 기준이 되고, GDD는 실제 게임과 어긋나기 때문에 보통 버리게 됨
  변경할 때마다 GDD를 읽고 기능을 구현한 뒤 GDD를 다시 동기화해야 한다고 고집하는 건 번거롭고 실제로 잘 작동하지 않음. 그런 일이 일어나는 걸 본 적이 없음
  언젠가 AI/LLM이 일련의 프롬프트만으로 Linux나 Windows의 다음 버전을 처음부터 코딩할 수 있게 된다면 모든 전제가 달라지겠지만, 지금은 분명히 거기까지 가지 못했고 앞으로도 그럴지는 모름

• 자연어는 복잡한 시스템의 기술 요구사항을 설명하는 데는 꽤 좋음. 즉 현재 코드 구현 자체가 아니라, 왜 다른 가능한 구현 대신 현재 구현을 선택했는지를 설명하는 데 좋음
  코드가 무엇을 하는지가 아니라 무엇을 해야 하는지, 다시 말해 저장소가 아니라 Jira 같은 곳에 있는 빠진 부분들을 담는 데 적합함
  또한 시스템 전체가 외부 규칙으로 설명되고 그 규칙을 전체 코드베이스에 강제할 수 있다면, 더 나은 리팩터링 능력을 제공할 수도 있음
  우리는 자동화·컴퓨터 맥락에서 쓰기 쉽기 때문에 프로그래밍 언어를 써왔고, 솔직히 LLM 이전에는 그것이 유일한 방법이기도 했음
  프로그래밍 언어는 국소적 규모에서는 비모호성을 주지만, 누군가 코드 일부를 복사해 붙여넣는 순간 전역 규모에서는 작동이 멈춤
  그 부분이 따라야 하는 모든 상위 수준 제약을 지키며 올바른 프로그램이라고 확신할 수 있나? 컴파일되면 실행되는 프로그램이기는 하겠지만, 실행의 정의는 꽤 느슨함. C++에서는 메모리를 전부 망가뜨리는 프로그램도 실행 가능함