논리 프로그래밍은 죽지 않았다 ── 제5세대 컴퓨터에서 LLM + MCP Solver로

본 기사의 메시지를 먼저 전달합니다.

현재, LLM (Large Language Model, 대규모 언어 모델) + MCP (Model Context Protocol) + Constraint Solver (제약 솔버)라는 구성이 등장하고 있습니다.

이는 1980년대에 일본 통상산업성(현 경제산업성)이 국가 프로젝트로서 추진했던 「제5세대 컴퓨터」 ── 논리 프로그래밍 (Logical Programming) · 병렬 추론 머신의 꿈 ── 이 40년의 세월을 거쳐, 완전히 다른 기술 스택으로 「재림」하고 있다고 볼 수 있습니다.

그리고 그 「재합류」를 상징하는 연구 성과가 바로 2025년 1월 발표된 MCP Solver (arXiv:2501.00539)입니다.

이 기사는,

• 프로그래밍 패러다임 (Programming Paradigm)의 체계 속에서,
  논리형 · 제약형이 어디에 위치하는가 - 1980년대의
  제5세대 컴퓨터 프로젝트란 무엇이었는가 - 왜 상업적으로 성공하지 못했는가
• 논리 프로그래밍과 제약 프로그래밍은,
  현대의 어디에서 계속 살아 숨 쉬고 있는가 - 그리고,
  MCP Solver가 보여주는 「40년 만의 재합류」

를 하나의 계보로서 그려냅니다.

• 평소 Python, JavaScript, Go, Rust, C++와 같은
  절차형 (Procedural, 명령형) 언어로 구현하고 있는 엔지니어

• Haskell, OCaml, Scala, Elm 등의
  **함수형 언어 (Functional Language)**에도 관심이 있으며, 패러다임의 차이에 민감한 엔지니어

• LLM, AI Agent, MCP, 멀티 에이전트(Multi-agent)와 같은
  현대 AI 기술의 흐름을 기술사적 맥락에서 깊이 이해하고 싶은 기술자

• 「논리 프로그래밍」, 「제약 프로그래밍」, 「Prolog」라는 단어를 들어본 적은 있지만 자세히는 모르는 분

• 「제5세대 컴퓨터」라는 단어를 IT 역사 속에서 본 적은 있지만, 실체를 모르는 젊은 세대의 기술자

• IT 업계의 역사와 그것이 현대의 AI 기술로 어떻게 이어지고 있는지를
  하나의 계보로서 이해하고 싶은 분

• 프로그래밍 패러다임의
  완전한 분류 체계 ── 「절차형 vs 선언형 (Declarative)」이라는 대분류와, 그 아래의 「함수형 · 논리형 · 제약형」이라는 분류의 정확한 모습

• 논리 프로그래밍이란 무엇인가, 제약 프로그래밍이란 무엇인가, 그 차이점과 공통점

• 이러한 패러다임의
  대표적인 언어 (Prolog, Datalog, Mercury, MiniZinc, Answer Set Programming 등)

• 1980년대에 일본에서 전개된
  제5세대 컴퓨터 프로젝트의 역사적 배경, 목적, 결말

• 1980년대에 전 세계 산업계에서 구현된
  **전문가 시스템 (Expert System)**의 실례 (MYCIN, XCON, DENDRAL, PROSPECTOR 등)를 망라적으로 정리한 표

• 제5세대 컴퓨터가
  왜 목표를 달성할 수 없었는가 ── 데이터 부족, 계산 능력 부족, 지식 획득의 병목 현상 등

• 논리 · 제약 프로그래밍이
  현대의 어디에서 살아 있는가 ── SAT/SMT 솔버, 데이터베이스, 형식 검증 (Formal Verification), 최적화, 제조업의 생산 계획

• 제5세대 컴퓨터가 지향했던
  **「전문가 AI (Expert System)」**가, 오늘날의 LLM · AI Agent · MCP · 멀티 에이전트로서 어떻게 형태를 바꾸어 실현되고 있는가

• 최종장에서는,
  2025년에 발표된 「MCP Solver」 ── MCP 프로토콜과 제약 프로그래밍 (MiniZinc, Z3, PySAT)을 잇는 최신 연구 ── 를 소개하며, 두 계보가 말 그대로 합류하고 있는 현대의 모습을 확인

엔지니어 여러분은, **「프로그래밍 패러다임」**이라는 단어에 무엇을 떠올리시나요?

가장 일반적인 대답은:

• 절차형 (Procedural, 명령형) ── C, Python의 절차적 작성 방식
• 객체 지향 (Object-Oriented) ── Java, C#, Ruby
• 함수형 (Functional) ── Haskell, OCaml, Scala, Elixir

아마 이 세 가지가 대표적인 대답일 것입니다.

하지만 프로그래밍 패러다임의 정식 분류 체계는 이보다 조금 다른 구조를 가지고 있습니다.

학술적인 프로그래밍 언어론에서 가장 큰 분류 축은:

이 이분법적 대립이 프로그래밍 패러다임의 가장 상위의 분류입니다.

용어 노트: 명령형과 절차형

엄밀히 말하면, 「명령형 (Imperative)」이 대분류이며, 그 아래에 「절차형 (Procedural)」, 「객체 지향 (Object-Oriented)」이 나열됩니다. 일본어(또는 한국어)에서는 「명령형」과 「절차형」을 혼동하여 사용하는 경우가 있으나, 본고에서는 학술적 엄밀성에 따라 구분합니다.

그리고, 「선언형」 안에는 4개의 서로 다른 형제가 나열되어 있습니다:

즉, 논리형과 제약형은 함수형과 나란히 선언형 패러다임의 정규 기둥입니다.

이는 Wikipedia의 "Programming paradigm" 항목, Baeldung, GeeksforGeeks 등의 표준적인 기술 해설에서도 명확하게 정리되어 있습니다.

「선언형」이라고 하면 추상적으로 들리지만, 사실 많은 엔지니어가 일상적으로 사용하고 있는 선언형 언어가 있습니다.

바로 SQL입니다.

SELECT name, salary
FROM employees
WHERE department = 'Sales'
...

이 SQL 쿼리에서 우리가 쓰고 있는 것은:

「무엇을 가져오고 싶은가」 ── 영업 부서 직원 10명의 이름과 급여, 급여의 내림차순 -
「어떻게 가져올 것인가」는 일절 쓰지 않음 ── 인덱스를 사용할지, 풀 테이블 스캔 (Full Table Scan)을 할지, 정렬 알고리즘은 무엇인지 ── 모든 것을 데이터베이스 관리 시스템 (DBMS)이 자동으로 결정

이것이 선언형 언어의 본질입니다.

반면, 만약 이것을 C나 Python으로 절차형으로 쓰려고 한다면:

# 절차형에서의 의사 코드 (Pseudo code)
employees = load_all_employees()
sales_employees = []
...

「어떻게 루프를 돌 것인가」, 「어떻게 정렬할 것인가」 ── 모든 절차를 프로그래머가 명시적으로 써야 합니다.

SQL의 선언성이 보여주는 본질은:

「무엇을 달성하고 싶은가」만을 쓰고, 「어떻게 달성할 것인가」를 소프트웨어 시스템에 위임한다

는 것입니다.

그리고 이 **「소프트웨어 시스템에 위임한다」**는 사고방식이야말로, 앞으로 본 기사에서 다룰 논리 프로그래밍 · 제약 프로그래밍의 핵심 ── 그리고 40년 전 제5세대 컴퓨터 꿈의 본질 ── 이기도 합니다.

프로그래밍 패러다임
├── 명령형 (Imperative)
│   ├── 절차형 (Procedural) ── C, Python의 절차적 작성 방식
...

본고에서는 ★ 표시가 붙은 논리형과 제약형을 앞으로 깊이 있게 파헤쳐 나가겠습니다.

**논리 프로그래밍 (Logic Programming)**이란 한마디로 말해:

「사실 (Facts)과 규칙 (Rules)을 선언하고, 질문 (Query)을 던지면, 추론 엔진이 논리적 추론을 통해 답을 도출한다」

라는 패러다임입니다.

일반적인 절차적 언어 (Procedural Language)에서는 프로그래머가 **「답을 계산하는 절차」**를 작성합니다.

논리 프로그래밍 (Logic Programming)에서는 프로그래머가 **「세상의 사실과 규칙」**을 작성하며, 「답을 찾는 절차」는 논리 엔진 (Logic Engine)이 자동으로 실행합니다.

논리 프로그래밍의 가장 유명한 언어는 **Prolog (프로로그, PROgrammation en LOGique, 「논리의 프로그래밍」이라는 뜻의 프랑스어)**입니다.

1972년, 프랑스 마르세유 대학교 (Université de Marseille)의 Alain Colmerauer (알랭 콜메로에르)와 Philippe Roussel (필립 루셀), 영국 에든버러 대학교 (University of Edinburgh)의 Robert Kowalski (로버트 코왈스키) 등에 의해 개발되었습니다.

Prolog의 동작을 구체적인 예로 살펴보겠습니다.

% 사실 (Facts): 부모 자식 관계를 선언
parent(tom, bob). % tom은 bob의 부모
parent(bob, ann). % bob은 ann의 부모
...

이에 대해 다음과 같은 **질문 (Query)**을 던집니다:

?- grandparent(tom, ann).
% true (tom은 ann의 조부모이다)
?- ancestor(tom, jim).
...

주목해야 할 점은, 어디에도 「루프 (Loop)」도 「if 문」도 「재귀 함수 (Recursive Function)의 반환값 처리」도 작성되어 있지 않다는 것입니다.

프로그래머가 작성한 것은 「세상의 사실과 규칙」뿐이며, 「답을 찾는 절차」는 Prolog의 추론 엔진 (Inference Engine)이 자동으로 실행하고 있습니다.

**제약 프로그래밍 (Constraint Programming, CP)**은 논리 프로그래밍의 형제 격이지만, 초점이 조금 다릅니다:

「변수가 가질 수 있는 값의 범위 (Domain)와 변수 간이 만족해야 하는 관계 (Constraint)를 선언하면, 제약 솔버 (Constraint Solver)가 모든 제약을 만족하는 값의 조합을 찾는다」

논리 프로그래밍이 **「추론 (Inference)」**에 초점을 맞추는 반면, 제약 프로그래밍은 **「제약 충족 (Constraint Satisfaction)」과 「최적화 (Optimization)」**에 초점을 맞춥니다.

**MiniZinc (미니징크)**는 2008년 호주 모나쉬 대학교 (Monash University)를 중심으로 개발된, 제약 프로그래밍의 현대적인 표준 모델링 언어입니다.

현재 MiniZinc는 ICAPS (국제 자동 계획 국제 회의)에서 튜토리얼이 제공되는 등 활발하게 진화하고 있습니다.

「8x8 체스판에 8명의 퀸을 서로 공격하지 않는 위치에 배치하라」 ── 고전적인 제약 충족 문제 (8-Queens Problem)를 MiniZinc로 작성하면 다음과 같습니다:

int: n = 8;
array[1..n] of var 1..n: queens;
% 제약 1: 모든 열이 달라야 함 (같은 열에 2개의 퀸이 있지 않음)
...

이것이 전부입니다. 알고리즘은 단 한 줄도 작성되지 않았습니다. 「변수의 범위」와 「만족해야 할 제약」을 선언했을 뿐이며, 솔버 (Solver)가 해를 찾아줍니다.

제약 프로그래밍은 현재 산업계에서 널리 사용되고 있는 기술입니다:

대표적인 제약 솔버 (Constraint Solver):

• Gecode (오픈 소스, C++ 기반)
• Chuffed (SAT 솔버 기술을 도입한 CP 솔버)
• Choco (Java 기반)
• OR-Tools (Google이 공개한 오픈 소스 최적화 라이브러리)
• Z3 (Microsoft Research, SMT 솔버)
• CPLEX, Gurobi (상용)

때는 1980년대 초반, 일본이 경제적으로 세계의 정점에 서려던 시대입니다.

통상산업성(현재의 경제산업성)이 **"일본 독자적인 AI 컴퓨터를 국가 사업으로서 개발한다"**라는 장대한 프로젝트를 시동했습니다.

그것이 바로 제5세대 컴퓨터 프로젝트 (Fifth Generation Computer Systems Project, FGCS) 입니다.

"제5세대"라는 명칭은 컴퓨터의 역사적 세대 구분에서 유래합니다:

즉, 제5세대 컴퓨터는 **하드웨어의 세대 교체가 아니라, "인공지능을 핵심으로 하는 컴퓨터"**라는 질적으로 다른 패러다임 시프트를 목표로 한 것이었습니다.

제5세대 컴퓨터가 목표로 한 것은:

• 자연어의 자동 이해와 자동 번역 ── 일·영·중 자동 번역, 자연어를 통한 대화
• 전문가 시스템 (Expert System) ── 전문가의 지식을 규칙으로서 축적하여, 전문가를 대신해 판단하는 AI
• 논리 추론의 초고속화 ── 병렬 추론 머신을 통한, 일반 컴퓨터의 1000배에 달하는 논리 추론 속도
• 지식 베이스 시스템 (Knowledge-based System) ── 대규모 지식 베이스로부터 필요한 지식을 검색 및 추론

이것들은 현재 LLM · AI Agent · RAG · MCP가 실현하고 있는 기능과 놀라울 정도로 유사합니다.

제5세대 컴퓨터는 1992년에 학술적 성과를 남기면서도, 실용화에는 이르지 못한 채 종료되었습니다.

"실패"라고 불리는 경우가 많지만, 이는 조금 정확하지 않습니다.

제5세대 컴퓨터가 상업적 성공에 이르지 못한 이유는 현대의 관점에서 보면 3가지 구조적 요인으로 정리할 수 있습니다.

1980년대 당시, 디지털화된 지식 · 데이터는 현대와 비교하여 1만 분의 1 정도밖에 되지 않았습니다.

"학습에 필요한 대량의 데이터"가 애초에 세상에 존재하지 않았던 것입니다.

병렬 추론 머신 (PIM)이 목표로 했던 것은 논리 추론을 가속화하는 것이었으나, 현재 GPU의 계산 능력과 비교하면 당시 슈퍼컴퓨터의 성능은 수천 분의 1에 불과했습니다.

제5세대 컴퓨터가 채택한 전문가 시스템 (Expert System) 접근 방식에서는, 전문가의 지식을 하나씩 수작업으로 규칙화하여 입력할 필요가 있었습니다.

이는 **「지식 획득의 병목 현상 (Knowledge Acquisition Bottleneck)」**이라 불리며, 전문가의 암묵지 (Tacit Knowledge)를 명시적인 규칙으로 번역하는 작업의 방대함이 전문가 시스템의 보급을 가로막았습니다.

현대의 LLM은 대량의 텍스트로부터 지식을 「암묵적으로」 학습함으로써 이 병목 현상을 극복하고 있습니다.

제5세대 컴퓨터와 동시대에, 전 세계 산업계에서 「전문가 시스템」이 차례차례 구현되었습니다.

대표적인 사례를 망라적으로 정리해 드립니다. 거대한 표가 되므로, 관심 있는 분은 펼쳐서 확인해 주시기 바랍니다.

📋 표 열기 ── 1970-1990년대의 주요 전문가 시스템 17가지 사례

BBN Technologies | 1980년대 | 군사 교육 | 해군 증기 추진 시스템 훈련 | 미 해군에서 실용화 |
REACTOR |
Idaho 국립연구소 | 1980년대 | 원자력 | 원자로 이상 진단 | 제한적이지만 원자력 안전 연구에서 활용 |
PROLOGIA |
프랑스 CNRS / 산업계 | 1980년대 | 엔터프라이즈 | 프랑스의 Prolog 기반 업무 시스템 | 유럽 내 Prolog 보급에 기여 |

이러한 전문가 시스템(Expert Systems)은, 1980년대 중반까지는 큰 기대를 모았으나, 1980년대 후반부터 급격히 상업적 쇠퇴를 겪었습니다. 이유는 앞서 언급한 세 가지입니다: 데이터 부족, 계산 능력 부족, 지식 획득의 병목 현상(Bottleneck).

그리고 1990년대 이후, AI 연구는 **「제2의 AI 겨울(AI Winter)」**에 진입합니다.

제5세대 컴퓨터가 지향했던 꿈이, 40년 후인 현대, 전혀 다른 기술적 접근 방식으로 실현되고 있다는 사실은 깊은 생각할 거리를 던져줍니다.

제5세대 컴퓨터 시대와 현대를 가른, 3가지 결정적인 변화:

제5세대 컴퓨터가 지향했던 「명시적 논리 추론」의 접근 방식은, 「데이터로부터 학습하는 뉴럴 네트워크(Neural Network)」의 접근 방식에 패배했습니다.

하지만 흥미롭게도, 현재 양자가 「합류」하는 움직임이 보이기 시작했습니다.

논리 프로그래밍(Logic Programming)과 제약 프로그래밍(Constraint Programming)은, AI Agent나 LLM이 각광받는 이면에서, 오히려 숨은 조력자로서 널리 사용되고 있습니다:

현재 급격히 주목받고 있는 움직임은, **「LLM의 취약 영역을 논리·제약 프로그래밍으로 보완한다」**는 연구 흐름입니다.

LLM은 자연어의 이해·생성, 창의적인 발상, 대량의 문서로부터의 패턴 추출에는 매우 강력하지만, 엄격한 논리 추론, 수치 최적화, 제약 충족 문제(Constraint Satisfaction Problem)에는 사실 약하다는 구조적 약점을 가지고 있습니다.

이는 「다음 단어를 확률적으로 예측한다」는 아키텍처(Architecture)의 본질적인 한계에서 기인합니다.

그리고 2025년 1월, 본 연재에서 지금까지 다루어 온 MCP 프로토콜과 제약 프로그래밍(Constraint Programming)을 직접 연결하는 연구가 논문으로 발표되었습니다.

MCP Solver ── 이는 MCP 프로토콜을 통해, LLM(Claude, GPT 등)이 MiniZinc, PySAT, Z3와 같은 제약 솔버(Constraint Solver)를 「외부 도구」로서 호출할 수 있도록 하는 연구입니다(Tsouros et al., 2025, arXiv:2501.00539v2).

이 연구의 의의는 매우 큽니다:

여기서 본 기사의 서두에서 던졌던 질문으로 돌아가겠습니다.

제5세대 컴퓨터는 정말로 「실패」였을까요?

제 견해는, 「아니오. 너무 빨랐을 뿐입니다」 입니다.