Mercury, 30년 묵은 논리형 언어가 아직도 살아있는 이유

잠깐, 논리형 언어가 뭐였더라?

프로그래밍 언어 분류를 학교에서 배울 때 "명령형, 함수형, 객체지향형, 논리형"이라고 나오는 거 기억하시나요? 거기서 논리형 언어로 항상 등장하는 게 Prolog였는데요, 사실 실무에서 Prolog를 만질 일이 거의 없다 보니 그냥 이론적 호기심으로 넘어가셨을 거예요. 그런데 최근 Mercury라는 논리형 언어 프로젝트가 다시 조명을 받고 있어요. 호주 멜버른 대학에서 1995년부터 개발해 온 언어인데, 30년이 지난 지금도 활발하게 개발되고 있고 GitHub에 코드가 공개돼 있어요.

Mercury가 뭐냐면, Prolog의 정신을 이어받되 타입 시스템, 모드 시스템, 결정성 분석을 추가해서 "진짜 큰 프로그램도 안전하게 짤 수 있게" 만든 언어예요. Prolog가 인터프리터 기반에 동적이고 자유분방한 언어라면, Mercury는 Haskell처럼 빡빡한 정적 타입 검사를 거치고 컴파일러가 C나 Java 백엔드로 코드를 떨궈주는, 훨씬 산업용에 가까운 설계예요.

논리형 프로그래밍이 명령형과 뭐가 다른가요?

쉽게 비유하자면 이래요. 명령형 언어는 "이렇게 저렇게 단계별로 계산해서 답을 내라"고 컴퓨터에게 방법을 지시하는 거예요. 반면 논리형 언어는 "이게 참이고 저게 참인데, 그럼 X는 뭐야?"라고 사실과 규칙을 선언하고 답은 컴퓨터한테 찾으라고 시키는 거예요.

예를 들어 "부모-자식 관계가 이렇게 정의되어 있을 때, 철수의 할아버지는 누구인가?" 같은 문제를 푼다고 해 봐요. 명령형이라면 트리를 두 단계 위로 올라가는 함수를 직접 짜야 하지만, 논리형에서는 "X의 할아버지는 X의 부모의 부모다"라는 규칙만 선언하면 컴파일러가 알아서 추론해 줘요. 데이터베이스 쿼리하듯이 프로그램을 짜는 느낌이라고 보시면 돼요.

Mercury는 여기에 한 발 더 나가요. 각 술어(predicate)마다 결정성(determinism) 을 명시해야 해요. 이 함수가 답을 정확히 하나만 내는지(det), 0개나 1개 내는지(semidet), 여러 개 낼 수 있는지(nondet) 같은 걸 타입처럼 선언하는 거죠. 컴파일러가 이걸 체크해서 "여기서 여러 답이 나올 수 있는데 그걸 처리 안 했네요" 같은 에러를 잡아줘요. 이게 무슨 의미냐면, Prolog에서 흔히 발생하는 "백트래킹이 폭주해서 메모리 폭발" 같은 사고를 컴파일 타임에 막을 수 있다는 뜻이에요.

왜 지금 다시 주목받을까요?

사실 Mercury 자체가 갑자기 빵 터질 언어는 아니에요. 그런데 요즘 업계 흐름과 묘하게 맞아떨어지는 지점이 있어요.

첫 번째는 선언적 프로그래밍의 부활이에요. SQL, GraphQL, Terraform, React의 JSX, Rust의 패턴 매칭까지, 요즘 인기 있는 도구들은 죄다 "어떻게"보다 "무엇"을 선언하는 방향으로 가고 있어요. 논리형 언어는 이 사고방식의 원조 같은 존재예요.

두 번째는 LLM과 기호 추론의 결합이에요. 요즘 AI 연구에서 "LLM은 직관은 좋은데 엄밀한 논리 추론이 약하다"는 이야기가 많잖아요. 그래서 LLM이 자연어를 논리식으로 바꾸고, 그 논리식을 Prolog/Mercury 같은 엔진이 풀게 하는 뉴로심볼릭(neurosymbolic) 접근이 다시 뜨고 있어요. 실제로 DeepMind의 AlphaProof도 Lean이라는 정리 증명기와 LLM을 결합한 시스템이고요.

세 번째는 정적 분석과 형식 검증의 중요성 증가예요. 항공, 의료, 금융 같은 안전 필수 분야에서 "이 프로그램은 절대 이런 상태에 빠지지 않는다"는 걸 증명하고 싶은 수요가 커지고 있어요. Mercury의 결정성 분석은 이런 검증 분야와 자연스럽게 맞물려요.

비슷한 위치의 언어로는 Prolog(전통적 논리형), Datalog(데이터 분석에 특화된 논리형, AWS도 내부에서 씀), Lean/Coq(정리 증명용), Answer Set Programming(조합 최적화) 등이 있어요. Mercury는 이 중에서 "산업용 범용 프로그래밍에 가장 가까운 논리형 언어"라는 독특한 자리를 차지하고 있어요.

한국 개발자에게 주는 시사점

솔직히 말씀드리면, 내일 출근해서 Mercury로 회사 서비스를 짤 일은 없을 거예요. 그런데 알아두면 좋은 이유가 두 가지 있어요.

하나는 사고의 도구로서 가치예요. 명령형으로만 짜다 보면 모든 문제를 for 루프와 if문으로 푸는 사고에 갇히기 쉬워요. 논리형이나 함수형 언어를 한 번이라도 진지하게 만져보면, 같은 문제를 "규칙의 집합"으로 표현하는 시야가 생겨요. 이건 SQL 쿼리를 잘 짜는 능력, Datalog 기반 정책 엔진(Open Policy Agent의 Rego 같은 것)을 다루는 능력으로 직결돼요.

또 하나는 AI 시대의 차별화예요. LLM이 명령형 코드를 짜는 건 이제 누구나 시킬 수 있는 일이 됐어요. 그런데 "비즈니스 규칙을 논리식으로 모델링하고 검증 가능한 엔진으로 실행한다"는 영역은 아직 LLM이 약하고, 그만큼 사람의 전문성이 가치 있게 남는 영역이에요. 한국에서도 컴플라이언스 자동화, 규제 산업의 룰 엔진 같은 분야에서 이런 역량이 슬슬 필요해지고 있어요.

마무리

30년 된 언어가 아직도 GitHub에서 활발히 커밋되고 있다는 사실 자체가, 프로그래밍 패러다임의 다양성이 얼마나 끈질긴지를 보여주는 것 같아요. 유행은 돌고 돌거든요.

혹시 논리형 언어를 진지하게 써보신 분 계신가요? 어떤 문제에 가장 잘 맞았는지, 명령형으로 풀 때와 비교해서 어떤 차이를 느끼셨는지 궁금해요.