한빛출판네트워크

"우리는 함수형, 객체지향과 절차지향 패러다임을 제공하는 멀티패러다임 언어를 효율적으로 사용하는 법에 대해 배워야 한다."

 

프로그래밍 세계에서는 원래 함수형 언어, 객체지향 언어와 나머지 언어(보통 절차지향 언어)로 나누어져 있었다. 한 함수형 프로그래머는 Lisp, Haskell이나 Erlang을 썼었고, 다른 한 프로그래머는 Java나 C++에서 코드를 썼었다(1990년대 학계에서 나온 이름이 “절차지향 프로그래머”라고 탈피되었을 때 “절차지향 프로그래머”라고 하면 뚱뚱한 넥타이에 나팔 스타일같은 벨 보텀 진을 입은 사람이라는 인식이 생기며 사실 자신을 “절차지향 프로그래머”라고 자칭했던 프로그래머는 없었다.).

 

하지만 이제 모든 게 바뀌고 있다. 지난 20년간 함수형과 객체지향 기능을 모두 가진 하이브리드 프로그래밍 언어가 늘어나고 있음을 보았다. 이 중 Scala와 같이 초창기부터 멀티패러다임으로 나왔으며 파이썬(파이썬 2에서 3으로 전환되며)이나 자바(Java 8에서 람다가 나오며)같은 다른 언어는 객체지향 및 절차지향 언어에서 기능적인 측면이 추가되었다. C++를 객체지향 언어로 알고 있지만, 사실 처음부터 멀티패러다임이었다. 절차지향 언어인 C로 시작해서 객체지향 기능을 추가했었다. 그 이후 C++는 Standard Template Library(STL)와 함께 Scheme과 LISP의 많은 아이디어로부터 영향을 받았다. 자바스크립트(JavaScript) 역시 Scheme에 많은 영향을 받았으며 익명 함수와 일급객체와 같은 아이디어들을 인기에 오르게 했다. 자바스크립트는 처음에 객체지향으로 시작했으며 프로토타입 기반 객체 모델과 문법(syntax)과 함께 점차적으로 자바와 비슷한 모습으로 발전했다.

 

또한 정적(static)과 동적(dynamic) 타이핑(typing)을 조합한 언어의 성장 역시 보인다(자바스크립트에서의 TypeScript, 파이썬 3.5에서 살짝 보여주는 추가 옵션 타입. Rust는 동적 타입 기능에 조금 제한적). 타이핑은 패러다임 스페이스에서 또다른 차원이다. 동적 타이핑은 언어를 프로그래밍하기 재미있고 쉽게 생산적이게 해주는 반면 strict 타이핑은 대형 시스템을 구축하고 이해하고 디버그하는데 쉽게 해준다. 2000년대 후반에 동적 및 정적 패러다임에 대해 이목을 이끌지 못했던 시기를 뺀다면 동적 언어를 찬양하는 사람들을 언제나 쉽게 찾을 수 있었다.

 

왜 아직도 함수형 프로그래밍과 객체지향 프로그래밍의 옹호자들 사이에서 논쟁이 벌어지고 있는 것일까? 이는 마치 어마어마하게 크게 놓친 기회같다. “멀티패러다임 프로그래밍”이란 무슨 뜻일까? 순수성을 거부하고 주어진 조건에 해당되는 제일 좋은 솔루션을 제공할 기능 아무거나 사용한다는 것은 무슨 의미일까? 가장 중대한 소프트웨어는 중요성이 상당하여 객체지향 패러다임이 더 잘 맞는 부분이 있으며, 또 함수형 패러다임이 우세하는 부분도 있다. 예컨대 재귀(recursion)와 같은 “함수적” 기능이 있다. 하노이 탑과 분류된 이진 트리를 순서대로 프린팅하는 것과 같이 재귀적으로 훨씬 더 쉬운 알고리즘이 있는 가 하면, 반복문(loop)이나 재귀를 사용해도 딱히 별 다를 바 없는 알고리즘이 있을 것이고, 재귀가 느리고 메모리가 부족해지는 경우도 있을 것이다. 어느 상황 속에서 어떠한 솔루션이 가장 좋다고 바로 말할 수 있는 프로그래머가 몇이나 될까?

 

이러한 질문이야말로 우리가 이제부터 던져야 할 질문들이다. 디자인 패턴(design pattern)은 처음부터 객체지향 프로그래밍과 연관되어 있었다. 멀티패러다임 시대에 어떤 디자인 패턴이 알맞을까? 디자인 패턴은 관찰되었으며 “발명”되지 않았다. 또한 계속해서 나올 문제에 대한 솔루션이며 레파토리 중 일부로 여겨져야한다. 사실 함수형 프로그래머들이 디자인 패턴에 대해 아무 말도 없는 게 조금 불행할 정도다. 패턴이 관찰된 솔루션이라는 것을 깨닫는 순간 “함수형 언어에서 패턴은 필요 없다”와 같은 말은 사라지는 게 당연해질 것이다. 함수형 프로그래머들 역시 분명 문제를 해결하며 반복되어 나오는 같은 솔루션을 볼 것이다. 이러한 문제와 솔루션이 또 다른 이름 모를 프로그래머가 관찰하는 문제와 솔루션과 같을 것이라고 생각해선 안된다. 어떤 패턴이 모든 패러다임의 베스트를 찾아낼까? 또한 어떤 패턴이 주어진 상황 속에서 어떠한 접근 방식이 가장 적절할 것이라고 알려주는데 도움이 될까?

 

프로그래밍 언어는 문제에 대해 사고 방식을 의미한다. 우리가 해결하고자 하는 문제들과 함께 패러다임은 수년간 기하급수적으로 늘어났다. 이제는 이벤트 반응형 프로그래밍(event-driven programming)에 대해 이야기가 오가며 많은 소프트웨어 시스템은 이벤트 반응형이다. 적어도 프론트 엔드(front end)에서는 말이다. 메타프로그래밍(Metaprogramming)은 JUnit에서 인기를 끌었으며 함수형 언어와 더 연관되어 위 기능을 기반으로 둔 첫번째로 널리 쓰인 툴로 자리잡았다. 그때부터 과감히 변한 몇몇 다른 버전의 메타프로그래밍은 자바, Ruby와 다른 언어에서 새로운 것을 만들어냈다.

 

여태껏 이러한 패러다임이 잘 섞일 수 있게 하는 문제에 대해 논의한 적이 없다. 지금까지는 여러 가지 패러다임을 제공하는 언어들의 사용법 연구는 프로그래머의 몫이었다. 하지만 단순히 즉석에서 패러다임을 섞는 것은 대형 시스템 구축을 위한 이상적인 방법은 아닐 것이다. 그리고 우리는 현재 불과 몇 년전만 해도 상상할 수 없었던 규모와 속도로 소프트웨어를 구축하고 있다. 많은 툴들이 개선되었으며 이제 우리는 어떻게 잘 사용할 지에 대해 배울 차례다. 그리고 이제는 오랫동안 각각 특별히 고유했고 심지어 갈등 속의 패러다임들을 섞어야할 때다.