경험적으로, 프로그래머들은 "reduce"를 싫어한다

본문

Evan Hahn은 자신의 블로그에서 코드 리뷰를 거치며 반복적으로 관찰해 온 한 가지 현상을 짧은 에세이로 정리했습니다. 결론부터 말하면, 사람들은 map과 filter는 좋아하지만 reduce는 좋아하지 않는다는 것입니다. 저자는 map과 filter 같은 함수를 일상적으로 사용하며, 그 코드를 리뷰에 올려도 동료들이 해당 사용 자체를 문제 삼는 경우는 거의 없었다고 말합니다. 다른 설계 결정에 대한 피드백은 많이 받지만, map과 filter를 썼다는 사실 자체가 지적받는 일은 없었다는 것입니다.

reduce만 유독 다른 대접을 받는다

반면 reduce는 상황이 다릅니다. 저자는 reduce가 포함된 패치를 제출하면 종종 "이 부분은 읽기 어렵다"는 코멘트를 받았다고 회고합니다. 또한 실제 코드베이스에서 reduce는 map, filter, some 같은 다른 고차 함수들에 비해 눈에 띄게 적게 등장한다고 관찰했습니다. 이 경험을 통해 저자는 프로그래머들이 reduce를 다른 함수들만큼 선호하지 않는다는 결론에 이르렀다고, 단 일화적(anecdotal) 관찰임을 분명히 한정하며 밝힙니다.

저자가 제시한 다섯 가지 가설

왜 이런 현상이 생기는지에 대해 저자는 여러 이론을 나열합니다. 첫째, reduce가 읽기 더 어렵다는 것입니다. 둘째, reduce가 덜 친숙하다는 것입니다. 셋째, 다른 선택지에 비해 성능이 나쁠 수 있다는 것입니다. 넷째는 언어의 표현력 문제로, JavaScript, Python, Swift 같은 언어에서 reduce가 상대적으로 덜 우아하다는 지적입니다. 저자는 Clojure 개발자로 일하던 시절에는 이런 피드백을 받지 않았다고 덧붙이며, 언어가 지원하는 관용구의 차이가 영향을 준다고 봅니다. 마지막 다섯째는 자기 반성적인 가설로, 자신이 틀렸을 수 있고 실재하지 않는 경향을 보고 있는 것일 수도 있다는 점입니다.

저자의 실무적 대응

흥미로운 점은 저자 자신이 reduce를 선호하면서도 보통 그냥 다른 방식으로 바꿔서 넘어간다는 사실입니다. 본인은 reduce를 좋아하지만 그다지 고집하지는 않으며, 이를 거대한 논쟁거리가 아니라 관찰할 가치가 있는 작은 사회적 현상으로 다룹니다. 또한 최근에는 이런 피드백이 줄었다고 언급하는데, 그 이유로 요즘 코드 리뷰가 예전만큼 철저하지 않기 때문일 가능성을 조심스럽게 짚습니다. 글은 독자에게 "당신도 이런 현상을 느끼는가, reduce를 좋아하는가"라고 물으며 마무리됩니다.

Lobsters 반응

• @nick4 — reduce는 보통 너무 강력하기 때문이라고 봅니다. map과 filter는 매우 집중된 연산이지만 reduce는 꽤 강력해서, 그 함수 시그니처만으로 리스트 타입과 동등한 것을 만들 수 있습니다. type List a = forall b. (a -> b -> b) -> b -> b라는 형태가 그것이며(이 타입을 위한 함수들을 구현해 보는 것이 좋은 연습문제가 됩니다), 가능하다면 reduce를 직접 쓰기보다 더 적합한 연산을 정의하거나 찾아 쓰는 편이 보통 낫다고 말합니다.

남는 이야기

이 댓글에서 제시된 시그니처는 리스트를 그 자체를 접는(fold) 함수로 표현하는 이른바 Church 인코딩에 해당합니다. reduce가 리스트의 모든 구조를 소비할 수 있는 가장 일반적인 연산이라는 점을 타입 수준에서 보여주는 예입니다. 원문 에세이와 커뮤니티 반응이 만나 지점은 같습니다. reduce는 강력하고 일반적이기 때문에 오히려 의도가 드러나지 않고, 그래서 리뷰에서 더 구체적인 연산으로 바꾸라는 압력을 받는다는 것입니다. 함수형 관용구가 실제 팀 코드에서는 표현력이 아니라 소통 비용으로 평가된다는 점을 생각하게 하는 짧지만 밀도 있는 토론입니다.

원문: Evan Hahn's Blog (evanhahn.com) / 번역·요약: Trawling