[고찰] 함수형 미신

글을 읽기에 앞서서, 나는 딱히 FP 를 잘하는것도 아니며, FP 만이 이 세상의 유일한 해결법이라고 생각하지 않는다, OOP 에 대한 모든 이해를 한 마스터도 아니다. 단지 패러다임에 관한 다른사람들의 글을 봣을때, FP의 난이도에 대한 많은 비난(...?)을 보고 느낀점을 쓴것뿐이다.

 

모나드, 재귀, 일급함수, 파이프, 순수함수, 수학적 함수, 불변 기타등등...

함수형 패러다임이라는것을 처음접했을때, 머리가 지끈거리는 단어들이 생각이 난다.

반면 OOP 의 경우는 우리가 친숙한 for문, if 문, while 문, 변수, 패턴, SOLID ..

우리가 친숙하고 이해할수있는 단어들만 생각이난다.

 

그래서 다음과 같은 결론이 나온다.

OOP 는 인간이 생각하는 방식을 그대로 사용해서 배우기 쉽고 실용적인 패러다임이며,
FP 는 수학적으로 정교하여 일반인들은 이해하기 힘든 학문적인 패러다임이다.

나는 위와 같은 의견에 반대한다.

 

함수형의 시초는 존 메카시의 LISP 이며, 이는 알론소 처치의 람다계산법을 컴퓨터 언어로 만든것이다.

LISP 자체가 무려 두번째로 나온 하이레벨 언어이며, 근간이 되는 람다계산법은 컴퓨터 프로그래밍보다 먼저 등장했다.

"세 번째 패러다임은 최근에 들어서야 겨우 도입되기 시작했지만, 세 패러다임 중 가장 먼저 만들어졌다. 사실 함수형 프로그래밍은 컴퓨터 프로그래밍 자체보다 먼저 등장했다" - Clean Archtecture 중

 

뭐 어찌됫건 알론소 처치는 비범한 수학자이고, 우리같은 범인들에게는 어려운 학문적인 패러다임이지 않느냐고 반문할수는 있겠다. 근데 튜링머신을 만든 엘런튜링도 비범한건 마찬가지 아닌가?

FP의 기반인 람다계산법이 너무 수학적이라 어렵다는것는, 튜링머신은 너무 친숙하기 때문에 절차지향이 쉽다는 소리와 같다. 애초에 둘은 동치다.

 

패러다임이란 절대적인 법칙이나 지켜야되는 룰이 아니고, 추상적인 레벨의 요소이다.

~~ 패러다임 언어라는것은 ~~패러다임 진형에서 자주 사용하는 Feature (또는 Tool) 을 제공해줄뿐이다.

그렇기 때문에 언어에 완전히 종속되는 요소가 아니다, 실제로 C++ 가 나오기 전에도 C 로  OOP 를 만들어서 사용했었다. [관련 포스팅]

 

그렇기때문에 한 패러다임에 관한 언어를 익히면 같은 패러다임의 언어는 금방 금방 익히는 이유가 이 때문에다, 제공해주는 Feature 가 유사하기 때문이다. 따라서 차이점과 문법정도만 익히면 어찌됫건 해당 언어를 사용할수있다. (언어적 철학을 지키는가? 해당 언어를 자유자제로 사용하는가? 등의 요소는 배재하고)

우리(대부분의 개발자)는 이미 OOP 라는 걸출한 패러다임을 학습했다. 인터페이스라는 걸출한 디커플링 방법을 알고있다. Class 라는, Prototype 이라는 뛰어난 방법에 익숙하다. 그렇기 때문에 C++ 에서 Java 로 넘어가는것이 C++ 을 처음 배울때보다 쉬었으리라, Java 에서 Kotlin 을 할때 감탄했을리라.

우리는 뛰어난 패러다임인 OOP 를 학습했으며, 감탄했으며, 또 학습했으며, 또 감탄 했으며, 또 학습했으며... 이렇게 우리는 이로인하여 OOP 라는 걸출한 패러다임에 중독 되어 버렸다. 특히 Class 기반의 OOP 만 학습했다고 하면 이제 우리는 Class 없이는 아무것도 할수없는 Class 중독자가 되어 버렸다.

Don’t be silly Jake. Where else are you going to put functions if you don’t have classes? Another beer?

[헛소리 하지 마 제이크. 만약 클래스가 없다면 어디에 함수를 선언할 수 있겠어? 맥주나 한 잔 더 마실래?]

-  Why Class?  [왜 클래스죠?(번역)]

 

딱히 OOP / Class를 비난하는것은 아니다, 반어법도 아니고 OOP 가 걸출한 패러다임이라고 생각한다. 필자가 하고자 하는 말은, 우리는 이미 너무 OOP 적으로 사고하는것이 자연스러워졌다는것이다.

객체지향 프로그래밍은 명사의 왕국(Kingdom of Nouns)이고, 함수형 프로그래밍은 동사의 왕국(Kingdom of Verb)이다. 

우리는 명사로 생각하는가? 동사로 생각하는가?

두 값을 비교하기위해서 "두 값을 비교하기(lambda)" 대신에 "두 값을 비교해주는 비교 머신 (Comparator)" 을 사용하는것이 인간의 사고방식을 묘사한 자연스러운 행위인가?

아니라고 본다. OOP 의 자연스러움은 한계가 있다.

그런데 왜 우리는 OOP 를 자연스럽게 생각하고, 왜 더 이해하기 쉽다고 느끼는가? (FP 와 비교해서)

이 "자연스러움" 은 실제로 자연스러운 현상이 아닌 인위적인 자연스러움이다.

그냥 우리가 수도없이, 몇년을 걸쳐 공부한 분야이기 때문이다. 우리한테 이 분야는 자연스럽고 이해하기 편하다.

마치 컴공과 개그와 같다. (컴퓨터 공학 학생 2명이 자리를 바꾸기 위해 필요한 의자 개수는? 3개)

 

우리는 수도 없이 공부하고, 디자인패턴에 셀수없는 시간을 쏟아 부었으며, SOLID 를 이해하기위해서 애썻다. 그렇기 때문에 더더 OOP 에 자연스러워 지고, 더 종속되어가고, 더 벗어나기 힘들어졌다.

나는 이것이 우리가 FP 를 어렵게 생각하는 이유라고 본다.

FP 가 어려운게 아니다. FP 도 어려운것이다. 왜 OOP 는 셀수없는 시간을 학습해놓고서, FP는 Map/Reduce/Filter만 보고 "아 뭐 이렇게 어려워? for문 쓰면 쉽구만.." 이라고 생각하는가?

For문이 정말로 쉬운가? 아니다 For문은 어렵다, 실제로 우리가 처음 For문을 배울때 얼마나 힘들었었는지 기억하는가? 수도 없이 마주친 out of index, 수도 없이 고친 i++, j +=2 들.. 처음에는 별찍기하나도 못해도 쩔쩔매놓고서는 왜 For문은 쉽고 map은 어렵다고 생각하는가?

 

분명히 그랬을것이다.

분명히 처음 변수를 다룰때, "머여 왜 x에 요상한 값이 들어가있어?" 라고 생각했을것이다.

분명히 OOP 의 다형성을 배울때, "아 뭐 이렇게 어려워 if문 쓰면 쉽구만.." 이라고 생각했을것이다.

분명히 디자인 패턴을 배울때, "이게 대체 어디에 쓰는거야?" 라고 생각했을것이다.

분명히 리스코프 치환원칙을 처음 봣을때, "이게 먼 개소리야?" 라고 생각했을것이다.

분명히 인터페이스를 배울때, "이런 쓸데없는걸 왜 쓰는거야?" 라고 생각했을것이다

분명히 ..

 

하지만 잊은것 뿐이다. 하지만 익숙해진것 뿐이다. 하지만.. FP는 아직 그렇지 않을 뿐이다..

 

 

나는 그렇게 생각한다.

함수형이 유난히 이해하기 어려운 패러다임이라는것은 유령과 같다고
FP 를 학습하지않기 위해서 하는 우리들의 자기 변명이라고
개발자들 사이에서 떠도는 미신과 같다고..