{
  "title": "패러다임 분류의 사회문화성",
  "description": "어떤 형식 정의를 세워도 메모리 모델이 조건을 충족해 C++·Rust·Java가 선언형이 되어버린다 — 그래서 패러다임 분류는 결국 사회문화적 합의라는 결론.",
  "languageCode": "ko",
  "cards": [
    {
      "type": "ox",
      "prompt": "'함수형 언어'의 정의처럼 '선언형 언어'의 정의도, 형식적으로 완벽히 합의된 경계라기보다 관례적·사회문화적 성격이 강하다.",
      "answer": true,
      "explanation": "이 글의 4번째 논점입니다: 결국 사회문화적 분류로 받아들일 수밖에 없다."
    },
    {
      "type": "ox",
      "prompt": "선언형을 '실행 의미론에 비자명한 ∃를 갖는 언어'로 엄격히 정의하더라도, 메모리 모델 때문에 C++이 선언형에 포함되는 것을 막기 어렵다.",
      "answer": true,
      "explanation": "메모리 모델의 happens-before/rf/mo가 바로 그 비자명한 ∃이기 때문입니다."
    },
    {
      "type": "ox",
      "prompt": "어떤 정의를 채택하든 메모리 모델이 그 조건을 거의 항상 충족하므로, C++·Rust·Java가 선언형이 되는 것을 형식적으로 배제하기 어렵다.",
      "answer": true,
      "explanation": "정의를 좁혀도(자명한 ∃ 배제) 메모리 모델의 ∃가 조건을 채웁니다. 이것이 최종 결론입니다."
    },
    {
      "type": "choice",
      "prompt": "패러다임(선언형/명령형/함수형 등) 분류가 형식 정의만으로 깔끔히 나뉘지 않는 주된 이유로 가장 적절한 것은?",
      "choices": [
        "대부분의 언어가 여러 패러다임 요소를 섞은 다중 패러다임이라서",
        "세상에 언어가 너무 적어서",
        "컴파일러가 존재하지 않아서",
        "모든 언어의 문법이 같아서"
      ],
      "answer": 1,
      "explanation": "실제 언어들은 다중 패러다임이라 경계가 흐릿하고, 형식 기준은 과포함·과소포함을 일으킵니다."
    },
    {
      "type": "ox",
      "prompt": "C++·Rust·Java는 통상 '명령형 언어'로 분류되지만, 동시에 정교한 메모리 모델(실행 의미론)을 가진다.",
      "answer": true,
      "explanation": "명령형으로 부르면서도 그 실행 의미론에는 ∃ 기반 정의가 들어 있습니다 — 여기서 모순이 드러납니다."
    },
    {
      "type": "ox",
      "prompt": "'자명한 ∃(예: 이름 유일성)를 하나라도 가지면 선언형'이라는 기준은, 선언형과 명령형을 잘 가르는 좋은 정의다.",
      "answer": false,
      "explanation": "자명한 ∃는 거의 모든 언어에 있어 변별력이 없습니다. 그런 기준이면 사실상 모든 언어가 선언형이 되어 무의미합니다."
    },
    {
      "type": "text",
      "prompt": "함수형·선언형 언어의 경계가 엄밀한 형식 정의보다 관례에 의존한다는 성격을, 이 글에서는 무엇이라 표현했는가?",
      "answers": [
        "사회문화적 분류",
        "사회문화적",
        "사회문화적인 분류",
        "socio-cultural",
        "사회 문화적 분류"
      ],
      "explanation": "'사회문화적 분류'입니다. 함수형 언어 정의처럼, 결국 관례적 합의로 받아들이게 됩니다."
    },
    {
      "type": "ox",
      "prompt": "Scala·JavaScript처럼 여러 패러다임을 함께 지원하는 언어의 존재는 패러다임 경계가 흐릿함을 보여준다.",
      "answer": true,
      "explanation": "다중 패러다임 언어는 '이 언어는 X형'이라는 단정이 왜 어려운지 보여줍니다."
    },
    {
      "type": "ox",
      "prompt": "'실행 의미론'이라 한정하지 않고 그냥 '의미론'이라 하면, 정적 의미론(타입 추론 등)의 ∃까지 끌어들여 분류가 더 부정확해진다.",
      "answer": true,
      "explanation": "이 글의 1번째 논점입니다. 층위를 명시하지 않으면 ∃를 가진 언어가 폭증합니다."
    },
    {
      "type": "ox",
      "prompt": "형식적 정의가 실패하면, 남는 현실적 선택지 중 하나는 분류를 관례적·사회문화적 합의로 받아들이는 것이다.",
      "answer": true,
      "explanation": "글의 결론 방향입니다: 함수형 언어 정의와 비슷하게, 사회문화적 분류임을 받아들일 수밖에 없다."
    },
    {
      "type": "ox",
      "prompt": "이 글의 결론은 'C++은 어떤 기준으로도 절대 선언형이 될 수 없다'는 것이다.",
      "answer": false,
      "explanation": "정반대입니다. 어떻게 정의해도 메모리 모델이 조건을 충족해 C++이 선언형이 되는 것을 '막을 수 없다'는 것이 결론입니다."
    },
    {
      "type": "ox",
      "prompt": "명령형과 선언형은 상호 배타적이라, 한 언어가 두 성격을 동시에 가질 수는 없다.",
      "answer": false,
      "explanation": "실제로는 한 언어가 두 성격을 겸할 수 있습니다. 바로 그 점이 형식적 이분법을 무너뜨립니다."
    },
    {
      "type": "ox",
      "prompt": "판 로이(Van Roy)의 패러다임 분류에서는 '선언형'을 가변 상태 없이 계산하는 모델로 좁게 규정하며, 이 정의에서는 함수형과 (결정적) 논리형 프로그래밍이 선언형에 들어간다.",
      "answer": true,
      "explanation": "판 로이·하리디의 분류는 '명시적 상태(explicit state)가 없는 계산'을 선언형 모델의 기준으로 삼습니다. 흔히 쓰이는 '무엇/어떻게' 기준과는 다른 잣대입니다."
    },
    {
      "type": "ox",
      "prompt": "'선언형(declarative)'은 문헌마다 서로 다른, 때로는 양립하지 않는 정의로 쓰인다 — '무엇/어떻게의 분리', '가변 상태 없음', '수학적 논리에 기반' 등.",
      "answer": true,
      "explanation": "이 여러 정의는 서로 다른 언어 집합을 잡아냅니다. 정의를 밝히지 않고 '선언형이다/아니다'를 다투면 논쟁이 겉도는 이유입니다."
    },
    {
      "type": "ox",
      "prompt": "판 로이의 패러다임 지도는 프로그래밍 패러다임을 선언형과 명령형 정확히 둘로 나눈다.",
      "answer": false,
      "explanation": "그 지도는 20여 개(판본에 따라 27개)의 패러다임을 배열합니다. 이분법이 아니라 여러 축을 가진 지형도에 가깝습니다."
    },
    {
      "type": "ox",
      "prompt": "판 로이의 지도에서 패러다임들은 '언어에 어떤 개념을 더하는가'(명시적 상태, 동시성, 예외 등)에 따라 파생 관계로 배열된다.",
      "answer": true,
      "explanation": "개념을 하나 더하면 표현력이 늘지만 프로그램에 대한 추론은 어려워집니다. 패러다임 사이의 관계를 '유형'이 아니라 '개념의 합'으로 보는 관점입니다."
    },
    {
      "type": "choice",
      "prompt": "판 로이의 분류에서 선언형(상태 없는) 모델에 '명시적 상태(explicit state)'를 더하면 도달하는 것은?",
      "choices": [
        "상태 기반·객체지향 모델",
        "순수 함수형 모델",
        "정규표현식",
        "타입 추론"
      ],
      "answer": 1,
      "explanation": "상태를 더하면 상태 기반·객체지향 모델로 넘어갑니다. 이 분류의 핵심 축은 '상태를 명시적으로 갖는가'입니다."
    },
    {
      "type": "ox",
      "prompt": "튜링 완전성은 어떤 언어가 명령형인지 선언형인지를 판별하는 기준이 된다.",
      "answer": false,
      "explanation": "튜링 완전성은 계산 능력에 관한 성질이며 표현 방식과 무관합니다. Prolog·Haskell도, C도 모두 튜링 완전합니다."
    },
    {
      "type": "ox",
      "prompt": "람다 계산법과 튜링 기계는 계산할 수 있는 함수의 집합이 서로 같다.",
      "answer": true,
      "explanation": "처치–튜링(Church–Turing) 논제의 배경이 되는 고전적 결과입니다. 즉 '무엇을 계산할 수 있는가'는 패러다임 선택으로 달라지지 않습니다."
    },
    {
      "type": "ox",
      "prompt": "C++11 이후의 메모리 모델은 실행마다 reads-from(rf)·modification order(mo) 같은 관계가 '존재한다'고 요구하는 공리적(axiomatic) 방식으로 정의된다.",
      "answer": true,
      "explanation": "한 단계씩 상태를 바꾸는 절차가 아니라, 허용되는 실행이 만족해야 할 조건을 관계의 존재로 규정합니다. 여기서 비자명한 ∃가 등장합니다."
    },
    {
      "type": "ox",
      "prompt": "순차 일관성(sequential consistency)은 모든 스레드가 물리적으로 같은 순간의 메모리를 동시에 본다는 뜻이다.",
      "answer": false,
      "explanation": "램포트의 정의는 물리적 동시성이 아니라 '각 스레드의 프로그램 순서를 보존하면서 실행 결과를 설명하는 어떤 전체 순서가 존재한다'는 조건입니다."
    },
    {
      "type": "ox",
      "prompt": "happens-before는 전체 순서(total order)가 아니라 부분 순서(partial order)이며, 서로 순서가 정해지지 않은 두 접근이 존재할 수 있다.",
      "answer": true,
      "explanation": "순서가 정해지지 않은 채로 남는 접근들이 있기 때문에 데이터 경쟁이라는 개념이 정의될 수 있습니다."
    },
    {
      "type": "ox",
      "prompt": "C++에서 데이터 경쟁은 happens-before로 순서가 정해지지 않은 두 충돌 접근(적어도 하나가 쓰기)으로 정의되고, 그런 프로그램의 동작은 미정의(undefined)다.",
      "answer": true,
      "explanation": "'무엇이 유효한 실행인가'를 관계의 존재 조건으로 규정하는 전형입니다. 절차가 아니라 조건으로 의미를 준다는 점이 핵심입니다."
    },
    {
      "type": "text",
      "prompt": "각 스레드의 프로그램 순서를 지키면서 실행 결과를 설명하는 '어떤 전체 순서가 존재한다'는 형태로 정의되는, 램포트의 고전적 메모리 일관성 모델의 이름은?",
      "answers": [
        "순차 일관성",
        "순차일관성",
        "sequential consistency",
        "SC",
        "순차적 일관성"
      ],
      "explanation": "순차 일관성(sequential consistency, SC)입니다. 정의 자체가 ∃(존재) 진술이라는 점이 이 커리큘럼의 논지와 이어집니다."
    },
    {
      "type": "ox",
      "prompt": "명령형 언어의 의미론은 언제나 한 단계씩 상태를 바꾸는 작동 의미론(operational semantics)으로만 주어진다.",
      "answer": false,
      "explanation": "표시적(denotational)·공리적(axiomatic) 방식으로도 줄 수 있고, 실제로 C++·Java의 동시성 의미론은 공리적으로 기술됩니다."
    },
    {
      "type": "ox",
      "prompt": "'유효한 실행이 무엇인가'를 관계의 존재 조건으로 규정하는 방식은, 절차를 지정하지 않고 조건을 만족하는 답을 요구한다는 점에서 제약 만족 문제의 형태와 닮았다.",
      "answer": true,
      "explanation": "메모리 모델은 사실상 '이 제약들을 만족하는 실행이 있는가'를 묻습니다. 명령형 언어의 명세 안에 선언형적 서술이 들어 있는 셈입니다."
    },
    {
      "type": "ox",
      "prompt": "Prolog 프로그램은 '무엇이 참인가'라는 선언적 읽기만으로 완전히 이해할 수 있고, 절의 순서나 cut(!) 같은 제어 요소는 의미에 영향을 주지 않는다.",
      "answer": false,
      "explanation": "cut은 백트래킹을 잘라내 해집합과 종료성을 바꾸고, 절 순서도 탐색 결과에 영향을 줍니다. 대표적 선언형 언어조차 순수하게 선언적이지 않습니다."
    },
    {
      "type": "choice",
      "prompt": "'무엇을 기술하고 어떻게는 맡긴다'는 기준의 약점으로 가장 적절한 것은?",
      "choices": [
        "'무엇'과 '어떻게'는 추상화 층위에 상대적이라 보는 층에 따라 판정이 뒤바뀐다",
        "'무엇'에 해당하는 영어 단어가 없다",
        "모든 언어가 결국 기계어로 번역되지는 않는다",
        "선언형이라 불리는 언어가 하나뿐이다"
      ],
      "answer": 1,
      "explanation": "'무엇'과 '어떻게'는 추상화 층위에 상대적입니다. 한 층의 '어떻게'는 아래 층에서 보면 '무엇'이 되므로, 어느 층을 보느냐에 따라 판정이 뒤집힙니다."
    },
    {
      "type": "ox",
      "prompt": "힌들리–밀너(Hindley–Milner) 타입 추론은 '항에 붙일 수 있는 타입 대입이 존재하는가'를 푸는 문제로, 정적 의미론 층위의 ∃에 해당한다.",
      "answer": true,
      "explanation": "단일화로 제약을 풀어 가장 일반적인 타입을 찾습니다. 층위를 '실행 의미론'으로 한정하지 않으면 이런 ∃까지 분류 기준에 끌려 들어옵니다."
    },
    {
      "type": "ox",
      "prompt": "패러다임 분류가 형식적으로 엄밀하지 않다면 그 분류는 쓸모가 없으므로 폐기해야 한다.",
      "answer": false,
      "explanation": "관례적 분류는 언어 선택·교육·의사소통에서 여전히 유용합니다. 문제는 그것을 형식적 판정 기준처럼 휘두를 때 생깁니다."
    },
    {
      "type": "ox",
      "prompt": "'자바는 객체지향 언어다' 같은 진술도 엄밀한 형식 기준이라기보다 관례적 분류에 가깝다 — 자바에는 원시 타입·정적 메서드·람다 같은 비객체지향 요소가 있다.",
      "answer": true,
      "explanation": "선언형에서 본 문제가 객체지향에서도 똑같이 반복됩니다. 패러다임 이름은 대체로 언어의 지배적 스타일을 가리키는 라벨입니다."
    },
    {
      "type": "text",
      "prompt": "충돌하는 두 메모리 접근이 happens-before로 순서 지어지지 않을 때 발생하는, C++에서 미정의 동작을 낳는 상황을 무엇이라 하는가?",
      "answers": [
        "데이터 경쟁",
        "데이터경쟁",
        "데이터 레이스",
        "data race",
        "레이스 컨디션"
      ],
      "explanation": "데이터 경쟁(data race)입니다. 정의 자체가 '순서 관계가 존재하지 않음'이라는 부정형 ∃ 조건으로 주어집니다."
    },
    {
      "type": "ox",
      "prompt": "SQL은 절차적 요소가 전혀 없는 순수한 선언형 언어다.",
      "answer": false,
      "explanation": "커서, 저장 프로시저, PL/SQL·PL/pgSQL 같은 절차적 확장이 표준과 구현 양쪽에 존재합니다. 대표적 선언형 언어조차 순수하지 않습니다."
    },
    {
      "type": "ox",
      "prompt": "어떤 언어가 다중 패러다임이라면 그 언어에는 지배적인 스타일이나 관용구가 존재하지 않는다.",
      "answer": false,
      "explanation": "대개 커뮤니티가 선호하는 관용구가 자리 잡습니다. 그 관용구가 사실상의 분류를 만들어 낸다는 점이 분류의 사회문화적 성격을 보여줍니다."
    },
    {
      "type": "ox",
      "prompt": "분류가 사회문화적이라는 말은 '아무렇게나 불러도 된다'는 뜻이 아니라, 경계가 형식 증명이 아니라 공동체의 사용과 합의로 정해진다는 뜻이다.",
      "answer": true,
      "explanation": "관례에도 근거와 반례가 있고 토론으로 바뀝니다. 다만 그 근거가 정리(theorem)가 아니라 용례라는 점이 다릅니다."
    },
    {
      "type": "ox",
      "prompt": "정교한 메모리 모델은 C++에만 있는 특수 장치이고 자바나 Rust에는 없다.",
      "answer": false,
      "explanation": "자바는 JSR-133 이후의 자바 메모리 모델(JMM)을 갖고, Rust는 C++의 원자·순서 모델을 그대로 채택했습니다. 그래서 같은 논지가 세 언어 모두에 적용됩니다."
    }
  ]
}