패러다임으로 바라보는 코틀린
Expression Oriented Kotlin
회사에서 나의 역할은 코딩이 아닌 조직의 생산성을 지속적으로 향상시키면서도 영속 가능한 구조(조직 아키텍처의 핵심 속성이 생산성, 영속성, 진화가능성이라고 생각한다)를 만드는 일이기 때문에, 꽤 오랜 기간 거의 코딩을 하지 못했다. 하지만 나는 여전히 코딩이 가져다주는 즐거움에 갈증을 느끼기에, 이를 조금이나마 해소하고자 여가시간에는 프로그래밍과 관련된 책을 읽곤 한다. 아니, 어쩌면 나의 삶의 즐거움 중 하나를 잃고 싶지 않은 몸부림에서, 이렇게 저렇게 티끌을 모아서 계속 프로그래밍에 관심을 두려는 것인지도 모르겠다.
넋두리가 길었는데 각설하고, 이번 글은 코틀린이 프로그래밍의 패러다임에 어떠한 활력을 불어넣고 있는지에 대한 나의 생각(혹은 착각)을 공유하고자 한다.
패러다임 불황
로버트 마틴(엉클 밥)은 그의 저서 '클린 아키텍처'에서 세상에는 단 세 가지 프로그래밍 기법(혹은 패러다임)만이 존재한다고 주장한다. 구조적 프로그래밍, 함수형 프로그래밍, 객체 지향 프로그래밍이 바로 그것이다. 우선 로버트 마틴이 패러다임을 바라보는 관점을 배워보자.
구조적 프로그래밍은 다익스트라가 제안한 패러다임인데, goto 제어문 대신에 구조화된 제어문(예를 들어 if 혹은 for 등)을 사용해야 한다고 주장했다. 다익스트라는 "goto considered harmful"이라는 논문을 통해 goto 구문의 위험성을 경고했으며, 이 논문은 10년이라는 찬반 논쟁을 불러일으켰다. 그 누구도 물러서지 않을 것 같은 팽팽한 논쟁이었지만, 이후 탄생한 언어들이 모두 goto를 없애거나 제한함으로써 다익스트라의 승리로 마무리되었다고 볼 수 있다. 로버트 마틴은 구조적 프로그래밍 기법은 goto 사용을 금지하는 제약을 가하여 완성된 패러다임이라고 주장한다.
함수형 프로그래밍은 엘런 튜링의 문제를 도와준 알론조 처지의 람다 계산법에 뿌리를 두고 있다. 함수형 프로그래밍은 람다의 특징인 불변성(immutability)이 핵심 원칙이며, 값의 할당에 제약을 가하여 완성된 패러다임이라고 말한다.
달과 니가드는 스택이 아닌 힙으로 변수를 옮김으로써 함수와 변수의 생명주기를 분리할 수 있음을 발견했다. 그리고 힙에 변수를 생성하는 함수를 생성자라 부르고, 하나의 함수처럼 보이지만 실제로는 구현체가 여러 개인 현상(c언어 함수 포인터)을 다형성으로 정의하고, 함수 포인터를 직접 사용하는 대신, 객체의 다형성을 이용하도록 제한하는 기법을 객체지향 프로그래밍이라고 정의했다.
로버트 마틴은 위의 3대 패러다임 이후 더 이상의 새로운 패러다임은 나오지 않았다고 주장하는데, 그 근거는 다음과 같다. 첫째 3대 패러다임은 1958년부터 약 10년에 걸쳐 만들어진 결과물이며, 그 이후 지금까지 새로운 패러다임이 등장하지 않았으므로 더 이상은 없을 것이라고 주장한다. 둘째, 이 패러다임들은 소프트웨어 엔지니어의 행동(문법)에 제약을 가함으로써 발전했는데, 이제 더 이상 추가할 제약이 없다는 것이다.
그러나 이 주장에는 뭔가 석연치 않은 구석이 있다. 우선 위키피디아를 살펴보면 다양한 프로그래밍 패러다임이 소개되어 있다. 따라서 로버트 마틴의 주장에 온전한 동의가 이루어진 것은 아닌 것 같다. 다음으로는 프로그래밍 언어에 더 이상 추가할 제약이 남아있지 않다는 것 또한 다소 의문스럽다. 로버트 마틴이 제시한 제약은 모두 문법적 요소들(goto문, 할당문, 함수포인터)에 대한 제약이었다. 정말로 모든 문법적 요소에 가할 제약이 다 떨어진 걸까? 혹은 문법적 요소에만 제약을 가해야 할 명확한 사유가 있을까?
로버트 마틴이 이러한 생각을 가진 이유는, 아마도 그만큼 극적인 변화를 만들어낸, 모두가 인정할 만한 확실한 패러다임이 보이지 않아서가 아닐까 생각한다.
코틀린의 프로그래밍 패러다임
고대 그리스 철학자 데모크리토스는 세상의 모든 물질은 원자로 구성되어 있으며, 원자는 '더 이상 쪼갤 수 없는(atomos)' 가장 작은 물질이라고 정의했는데, 19세기 이후의 천재적인 물리학자들(존 돌턴, 닐스 보어, 하이델베르크 등등)에 의해 원자가 증명되었으며, 나아가 더 작은 물질들도 계속 발견되는 중이다. 새로운 것이 계속 나오니 지루할 틈이 없을 것 같다(난 물리학자가 아님을 밝힌다).
그런데 만약 이 세상에 존재하는 모든 프로그래밍 패러다임을 이미 다 발견해 버린 상태라면, 그래서 더 이상 새로운 프로그래밍 패러다임이 창조될 수 없다면, 나는 굉장히 실망할 것 같다. 왜냐하면 우리는 이미 모든 것을 다 알아버린 상태라서, 이제 더 이상 새로운 프로그래밍 기법의 탄생은 불가능하다는 의미가 되고, 인간은 이미 한계에 직면해서 진화가 불가능한, 따라서 현상유지 혹은 퇴화만 가능한 상태라는 결론에 도달해 버리기 때문이다. 이것은 마치 이미 너무 쉬워서 플레이하기도 귀찮은 지루한 게임을 계속 플레이하는 꼴이 아닌가 한다(물론 코딩 난이도는 헬이라서 문제가 안될지도 모른다).
다행인 점은, 과학이 진화하듯 프로그래밍 또한 진화의 진화를 거듭하고 있는 듯하다. KotlinConf23에서는 코틀린이 Expression Oriented Programming(EOP) 언어라고 주장한다. 그렇다면 코틀린은 어떠한 제약으로 만들어진 프로그래밍 언어일까?
앞선 글에서 잠깐 소개한 바대로 EOP는 문장의 사용에 제약을 가하는 기법이다. 즉, 문장(statement) 대신에 표현식(expression)을 적극적으로 사용해야 한다고 주장한다. 그렇다면 문장에는 어떠한 다크사이드(the dark side of force)가 있고, 표현식에는 어떠한 라이트 사이드(the light side of force)가 있는 걸까? 앞으로 나는 코틀린이 가진 포스(the light side of force를 짧게 포스라고 한다)에 대해서 짧은 글들로 소개하고자 한다. 그 첫 번째 토막글은 문장의 다크 사이드이다.
패러다임을 넘어서
코틀린의 패러다임은 그저 패러다임으로써의 역할만 하는 것이 아니라 일종의 프로그래밍 규율(discipline) 혹은 방법(practice)처럼 보인다. 이런 나의 기대가 어긋난 것일 수도 있겠으나 그 가능성에 대한 나의 생각을 말해보겠다.
기술의 발전이 만들어내는 가장 결정적인 차이 중 하나는 사용성에 있다. 기술의 초기 단계에 만들어지는 대부분의 도구들은 고급 기술자들만의 전유물처럼 여겨진다. 그리고 기술의 발전은 이러한 도구를 비-기술자들조차도 쉽게 사용할 수 있는 대중화로 이끌게 된다. 그렇다면 프로그래밍 언어나 기법은 이러한 기술적 발전의 흐름이 통하지 않는 것일까?
구조적 프로그래밍이 프로그램의 구조에 제어 체계를 부여하는 시도였다면, 객체지향 프로그래밍과 함수형 프로그래밍은 각각 객체와 함수의 가치를 극대화하기 위한 시도였다고 말할 수 있겠다.
객체지향 프로그래밍은 추상화(abstraction), 캡슐화(encapsulation), 상속(inheritance), 다형성(polymorphism)이라는 4대 원칙을 지원하는 객체의 중요성을 강조한다. 문법적으로는 오버로딩, 오버라이딩, 클래스, 클래스 상속, 접근제어(private, public 등)를 제공한다.
함수형 프로그래밍은 불변성과 순수성의 2대 원칙(이 부분은 논란의 여지가 있을 수 있다)을 강조한다. 데이터(맞다 데이터도 함수로 취급될 수 있다)는 불변성을 지켜야 하고, 함수는 순수성을 지켜야 한다. 문법적으로는 모나드, 람다, 고차함수, 컴포지션(currying 등)을 제공한다.
그런데 FP나 OOP 등의 기술은 소프트웨어 엔지니어의 역량에 따라 그 성능이 크게 좌우된다. 어쩌면 Refactoring, Design Patterns, TDD(test driven), RDD(responsibility driven), DDD(domain driven), BDD(behavior driven) 등등의 기법들은 이러한 파일럿의 성능에 의해 결정되는 요인을 최소화하기 위한 시도일지도 모르겠다. 과거 애자일 기법 중 하나로 XP(Extream Programming) 기법이 각광을 받았었다. 이 기법은 개발자가 체감하는 효율이 높은 실천법(practice)들을 극단적으로 많이 사용하려는 기법이었다. 그런데 지금은 XP 또한 과거의 한 장면인 것 같다. 소프트웨어 엔지니어들은 기술의 장인이 되고자 노력하지만, 어떤 길을 따라야 할지 확신할 수 없다.
코틀린은 마치 지금까지 프로그래밍 패러다임만으로는 극복할 수 없었던 파일럿에 의해 크게 좌우되는 언어 성능의 문제에 도전장을 내미는 듯한 인상을 준다. 코틀린이 가진 진화 가능한 프로그래밍 언어로써의 특징(물론 코틀린만의 특징이 아니다!)이, 마치 폴 그레이엄이 말하는 programming bottom up의 실현처럼, 코틀린을 EOP에 최적화된 언어로의 진화를 가속화시키는 것만 같다. 즉, 더 좋은 프로그램을 작성하는 베스트 프랙티스를 코틀린이라는 언어의 레벨에서 완벽하게 제공하려는 야망을 가진 것으로 보인다.
코틀린은 개발자의 실수를 줄이거나 없앨 수 있는 좋은 습관을 문법화하고, 사람(제품 담당자 혹은 고객)이 결정한 사항(요구사항)이 하나의 코드 속에서 모두 보이지만, 기술적 결정 사항들은 숨기려 한다. 마치 기술이 변했을 때 제품의 스펙이 함께 변해야 할 일은 전혀 없도록 하겠다는 것처럼 말이다. 만약 코드에서 사람이 결정한 사항들만 보인다면, 그리고 그 의도가 정확히 전달이 되고 불필요한 중복이 없다면, 그 코드를 굳이 소프트웨어 엔지니어만 봐야 할 이유가 있을까?
소프트웨어 엔지니어들은 엔진룸(under the hood) 아래의 지저분한 기름 떼와 싸우고, 제품 담당자들은 어떻게 이러한 기술을 써먹을지 스펙을 직접 작성하는 그런 완벽한 separation of concerns의 파라다이스를 꿈꿔볼 수 있을까?
(그들만의 리그에서) 흥행을 이어가는 코틀린!
맺음말
앞으로, 코틀린에 대한 나의 인상이 그저 나에게만 보이는 환영(hallucination)이었는지, 아니면 진정으로 영속하는 언어의 탄생을 직면한 것인지 (안 바쁘다면) 지켜보고자 하며, 또한 그 과정에서 내가 얻은 생각들을 (만약에 있다면) 여러분과 함께 나누고자 한다.
Disclaimer
1. 이 글은 거만한 어투로 쓰였기에 짜증 날 수 있음.
2. 코틀린은 프로그래밍 언어이기 때문에 당연히 그 역할과 한계를 인정해야 함.
3. 스케일을 너무 키워서 수습 못할 것 같음.
