모나드 튜토리얼이 이렇게나 많은 이유: 함수형 학습의 오래된 농담

왜 모나드 튜토리얼이 수십 개나 있을까

Haskell 위키에 "Monad tutorials timeline"이라는 페이지가 있어요. 말 그대로 모나드를 설명하는 튜토리얼이 시간 순서대로 죽 정리된 페이지인데, 이게 보면 정말 많아요. 2000년대 초부터 지금까지, 매년 누군가가 "내가 드디어 모나드를 이해했어! 모두에게 설명해줄게!" 하면서 새 글을 쓰고 있거든요. 이걸 보고 함수형 커뮤니티에는 유명한 농담이 있어요. "모나드를 이해한 사람은 모나드 튜토리얼을 쓰고 싶어진다. 그런데 그 튜토리얼은 다른 사람을 이해시키지 못한다." 이걸 "monad tutorial fallacy(모나드 튜토리얼의 함정)"라고 불러요.

모나드가 도대체 뭐길래

일단 모나드가 뭔지부터 풀어볼게요. 한 줄로 말하면 "값을 어떤 맥락에 담아두고, 그 맥락을 자연스럽게 이어 붙일 수 있게 해주는 패턴" 이에요. 너무 추상적이죠? 예를 들어볼게요.

자바스크립트의 Promise를 떠올려보세요. Promise<유저>는 "비동기 처리 후에 유저가 나올 거야"라는 맥락에 유저 값을 담아둔 거잖아요. 그리고 .then()을 쓰면 그 안의 값을 꺼내 작업하고, 결과를 다시 Promise로 감싸서 다음으로 넘기죠. 이게 모나드의 한 예시예요. "비동기"라는 맥락을 다루는 모나드.

또 다른 예로 Optional이나 Maybe가 있어요. 값이 있을 수도, 없을 수도 있는 맥락이죠. Maybe<유저>에서 유저 이름을 꺼내려면 "유저가 있을 때만 이름을 꺼내고, 없으면 그냥 없음을 유지"하는 식으로 처리해야 해요. 모나드는 이 "있으면 처리, 없으면 통과"를 자동으로 해주는 패턴이에요.

에러 처리(Either), 상태 관리(State), 리스트(List) 등도 다 모나드로 표현돼요. 즉 공통된 인터페이스(bind/flatMap/>>=)로 다양한 부수효과를 다루는 추상화가 모나드인 거예요.

그런데 왜 그렇게 가르치기 어려울까

글쓴이들이 모나드를 이해한 순간, 자기를 깨닫게 해준 비유에 몰입하게 돼요. 어떤 사람은 "모나드는 부리토다"라고 하고, 어떤 사람은 "모나드는 우주복이다", 또 어떤 사람은 "모나드는 그냥 컨테이너다"라고 해요. 문제는 이런 비유가 자기한테는 통했지만 다른 사람에겐 안 통한다는 거예요. 왜냐면 모나드는 구체적인 무언가가 아니라 패턴이고, 패턴은 충분한 예시 없이 비유로만 잡으려고 하면 미끄러지거든요.

그래서 함수형 커뮤니티에서 점점 합의된 결론은 이거예요. "모나드를 이해하는 가장 좋은 방법은 모나드를 안 배우는 것이다." 정확히는, 모나드라는 단어를 먼저 배우지 말고, Maybe, List, IO, Either 같은 구체적인 모나드를 충분히 써보라는 거예요. 그러다 보면 "어? 이것들 다 패턴이 비슷한데?" 하는 순간이 오고, 그때 "이 공통 패턴을 모나드라고 부른다"고 알려주면 자연스럽게 이해된다는 거죠.

업계 흐름에서 보면

흥미로운 건 이 함수형 개념이 점점 주류 언어에도 들어오고 있다는 점이에요. JavaScript의 Promise는 사실상 모나드고, async/await는 그 모나드를 더 편하게 쓰는 문법이에요. Rust의 Option, Result와 ? 연산자도 모나드 패턴이에요. Swift의 Optional 체이닝도 마찬가지고요. 즉, 모나드라는 단어를 안 쓸 뿐이지 실무 개발자들은 이미 매일 모나드를 쓰고 있어요.

그래서 "함수형 프로그래머만 아는 신비한 개념"으로 모나드를 신성시하는 시대는 사실 끝나가고 있어요. 다만 Haskell처럼 모든 부수효과를 모나드로 명시적으로 표현하는 언어에 들어가면 또 다른 차원의 학습이 필요한 건 사실이에요. IO, State, Reader, Writer를 한꺼번에 다루려면 모나드 변환자(monad transformer)나 효과 시스템(effect system) 같은 더 복잡한 추상화가 필요하거든요. 최근 Haskell 진영에서는 effectful, polysemy 같은 효과 라이브러리가 인기를 얻고 있고, OCaml은 5.0에서 effect handlers를 정식 도입하면서 "모나드 없이도 부수효과를 다룰 수 있다"는 새 길을 열었어요.

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

첫째, 모나드 튜토리얼을 100개 읽어도 안 통한다면 그건 여러분 잘못이 아니에요. 그게 정상이에요. 차라리 Haskell 책 한 권을 잡고 Maybe, Either, IO로 작은 프로그램을 직접 짜보세요. 그리고 한 달쯤 지나서 다시 모나드 정의를 보면 "아" 하는 순간이 와요.

둘째, 자기가 이미 쓰고 있는 모나드를 인식해보세요. Promise 체이닝, Optional 체이닝, Result/Either 패턴, RxJS의 flatMap — 이게 다 같은 패턴이라는 걸 깨달으면 코드 설계가 한층 풍성해져요. 비동기, 에러, 상태를 모두 "맥락에 값을 담아 다루는 일"로 통합해서 사고할 수 있거든요.

셋째, 새로운 패러다임을 배울 때 자기에게 맞는 비유 한 개에 너무 매달리지 않는 게 좋아요. 비유는 디딤돌일 뿐이고, 진짜 이해는 "여러 예시를 직접 써보면서 공통점을 추상화하는 과정"에서 옵니다.