소프트웨어 공학의 세계에는 늘 아름다운 수학적 이상과 messy한 현실 사이의 긴장감이 존재합니다. 한쪽 끝에는 Haskell처럼 수학적으로 순수하고 복잡한 타입 시스템을 자랑하며 범용적인 개념을 도입한 언어들이 있고, 다른 한쪽에는 Lisp과 Scheme처럼 즉흥적으로 코드를 짜고 문제를 해결하는 데 특화된 도구들이 있습니다. 최근 글로벌 개발 커뮤니티에서 이 두 흐름을 비교하며 왜 여전히 Lisp과 Scheme를 선택하는지에 대한 논의가 뜨겁게 달아오르고 있습니다.
Haskell은 분명히 압도적인 매력을 지니고 있습니다. PhD나 컴퓨터 과학 연구자들이 모이는 곳처럼 느껴질 만큼 지적인 깊이를 자랑하며, 모나드를 통한 효과적 계산 모델이나 순수 함수형 도메인 특화 언어 같은 혁신적인 아이디어들을 대중화했습니다. 하지만 이러한 brilliancy가 때로는 실용적인 해킹을 방해하는 장벽이 되기도 합니다. 특히 함수형 프로그래밍에 익숙하지 않거나 모나드 개념에 막막함을 느끼는 개발자들에게 Haskell은 빠르게 유용한 코드를 작성하는 것보다 언어의 규칙을 이해하는 데 더 많은 에너지를 요구하게 만듭니다.
반면 Lisp과 Scheme는 개발자가 언어를 자신의 의지대로 자유롭게 변형하고 확장할 수 있는 힘을 줍니다. 강력한 매크로 시스템을 통해 수십 년 동안 개발자들은 언어의 구조를 자신에게 맞게 재구성해 왔습니다. Racket 같은 Scheme 변종들은 이미 표준 라이브러리에 필요한 대부분의 도구를 갖추고 있어, 개발자가 직접 매크로를 작성할 필요조차 줄여줍니다. 이는 새로운 언어를 배우는 진입 장벽을 낮추면서도, 복잡한 작업을 수행할 때 유연성을 보장합니다.
데이터 처리 방식에서도 두 접근법의 차이는 뚜렷합니다. Haskell 생태계에서는 파싱, XML 처리, PDF 생성 등 각기 다른 목적에 맞춰 수많은 전용 DSL이 만들어지지만, 각각은 고유한 학습 곡선을 요구합니다. 반면 Lisp 개발자들은 XML이나 JSON 같은 외부 데이터 포맷을 s-표현식으로 변환하여 다룹니다. 이렇게 하면 배열, 해시, 문자열, 부동소수점 같은 제한된 데이터 타입에 맞춰야 하는 JSON의 한계를 넘어, 정렬된 맵이나 실제 날짜 객체처럼 더 자연스러운 데이터 구조를 사용할 수 있습니다.
결국 이 논쟁은 어떤 언어가 더 우월한가에 대한 단순한 비교를 넘어, 개발자가 어떤 방식으로 문제를 해결하고 싶은지에 대한 철학적 선택으로 이어집니다. 수학적 완벽함을 추구하며 언어의 규칙에 맞춰 사고하는 즐거움을 원하는 이들에게 Haskell은 여전히 최고의 선택지일 것입니다. 하지만 즉흥적으로 언어를 굽히고, 데이터의 형태를 자유롭게 바꾸며, 빠르게 결과물을 만들어내는 해킹의 재미를 중시하는 이들에게는 Lisp과 Scheme가 여전히 가장 친숙하고 강력한 친구로 남을 것입니다. 이 두 흐름이 공존하며 서로의 장점을 보완해 나가는 과정이 앞으로의 프로그래밍 트렌드를 어떻게 변화시킬지 주목해 볼 만합니다.