모노이드 동물원: Factor 창시자가 정리한 분산 처리의 숨은 주인공들

모노이드 동물원에 오신 걸 환영합니다

Factor 프로그래밍 언어의 창시자 Slava Pestov가 "Monoid Zoo"라는 재미있는 글을 썼습니다. 제목 그대로 다양한 모노이드(monoid)를 한곳에 모아놓은 동물원 같은 카탈로그예요. 수학적 개념을 이렇게 쉽게 모아서 보여주는 자료가 흔치 않아서, 함수형 프로그래밍이나 추상 대수에 관심 있는 분들에게 좋은 참고서가 됩니다.

모노이드가 뭐냐면

먼저 기본부터 짚고 갈게요. 모노이드는 세 가지 조건을 만족하는 수학적 구조예요. 첫째, 원소들을 가진 집합이 있어야 해요. 둘째, 그 원소 두 개를 합치는 연산이 있어야 하고, 이 연산이 결합법칙(associative)을 만족해야 합니다. 즉 (a + b) + c = a + (b + c)가 성립해야 해요. 셋째, 항등원(identity element)이 있어야 합니다. 어떤 원소와 결합해도 자기 자신이 나오는 특별한 원소죠.

예를 들어볼게요. 숫자의 덧셈은 모노이드입니다. 결합법칙이 성립하고(1+2+3 = 1+(2+3)), 항등원은 0이에요(5+0 = 5). 문자열 이어붙이기도 모노이드예요. "안녕"+"하세요"+"!" 를 어느 순서로 합쳐도 결과가 같고, 빈 문자열 ""이 항등원 역할을 하죠.

왜 모노이드를 알아야 하나

"수학 개념이 코딩이랑 무슨 상관이냐" 싶으실 텐데요, 모노이드는 분산 처리와 병렬 연산의 가장 근본적인 토대입니다. MapReduce가 바로 모노이드를 이용한 구조거든요.

이게 무슨 말이냐면, 결합법칙이 성립한다는 건 "어느 순서로 합치든 결과가 같다"는 뜻이에요. 그래서 모노이드 연산은 분산 환경에서 여러 노드가 각자 부분 결과를 계산하고, 마지막에 아무 순서로나 합쳐도 정답이 나옵니다. 항등원이 있다는 건 "데이터가 없는 노드"를 자연스럽게 처리할 수 있다는 뜻이고요. Spark, Flink 같은 분산 처리 프레임워크가 이 원리를 전제로 만들어졌죠.

또 CRDT(Conflict-free Replicated Data Type, 충돌 없이 복제 가능한 데이터 구조)의 많은 타입이 모노이드 기반이에요. 여러 기기에서 동시에 편집해도 자동으로 병합되는 협업 도구들이 이런 자료구조 위에서 돌아갑니다.

Slava가 소개한 모노이드들

이번 글에서는 유명한 모노이드 예시를 수십 가지 정리해놨는데, 몇 개만 엄선해볼게요.

최댓값 모노이드(Max Monoid)는 두 숫자를 비교해서 큰 쪽을 반환하는 연산이에요. 항등원은 음의 무한대입니다. "지금까지 본 최대 응답 시간" 같은 모니터링 지표 계산에 딱이에요.

리스트 모노이드는 두 리스트를 이어붙이는 연산입니다. 항등원은 빈 리스트. 로그 수집처럼 "모든 노드의 이벤트를 시간 순으로 합친다"는 패턴에 쓰이죠.

함수 합성 모노이드는 f ∘ g처럼 함수를 조합하는 연산이에요. 항등원은 항등함수(x를 받아서 x를 반환). 미들웨어 체인이나 트랜스듀서 같은 구조가 여기 해당합니다.

Bloom filter 모노이드는 두 블룸 필터를 OR 연산으로 합치는 거예요. 항등원은 모든 비트가 0인 필터. 대규모 중복 제거나 캐시 존재 여부 판정에 자주 쓰이죠. 카운트-민 스케치, 하이퍼로그로그(HyperLogLog) 같은 확률적 자료구조도 모노이드 구조라서 분산 집계에 이상적이에요.

업계 맥락에서 보면

Haskell 커뮤니티에서는 모노이드가 너무 당연한 개념이라 따로 설명할 필요도 없을 정도지만, 주류 개발자들 사이에서는 여전히 낯선 개념이에요. 그런데 최근 Kotlin, Swift, Rust 같은 언어들이 함수형 특성을 많이 흡수하면서, 실무에서 모노이드적 사고가 필요한 순간이 늘고 있습니다.

특히 스트림 처리, 증분 계산(incremental computation, 바뀐 부분만 다시 계산하는 기법), 반응형 상태 관리 같은 영역은 모노이드 구조를 알면 설계가 훨씬 깔끔해져요. React의 useReducer도 따지고 보면 상태 모노이드 위에서 돌아가는 거고요. Redux의 combineReducers는 리듀서들을 모노이드적으로 합성하는 구조 그 자체입니다.

한국 개발자에게는

데이터 엔지니어링이나 백엔드 분산 시스템을 다루는 분이라면 이 글은 꼭 한 번 읽어보시길 권합니다. 당장 업무에 써먹을 게 아니더라도, "이 연산이 모노이드일까?"라는 질문을 던지는 습관이 생기면 병렬화, 캐싱, 증분 업데이트 같은 문제들을 더 우아하게 풀 수 있거든요.

특히 Scala나 Kotlin에서 백엔드를 짜시는 분, Cats나 Arrow 같은 함수형 라이브러리를 쓸 때 Monoid 타입클래스가 나오면 당황스러웠던 경험이 있으실 거예요. 이제 그 개념을 구체적인 예시로 채워볼 기회입니다. 또 실시간 대시보드 같은 걸 만드시는 분이라면, 집계 연산이 모노이드인지 아닌지가 "노드 한 대 죽으면 처음부터 다시 계산해야 하는가"를 결정한다는 사실을 기억해두세요.