함수형 코틀린 (Recap Session) | 인프런 퇴근길 밋업 with KotlinConf 2023 Global

인프런 inflearn·인프콘 2023 2023·2023년

AI 요약

모바일 개발자 김용욱(달리나음)이 인프런 퇴근길 밋업에서 KotlinConf 2023 Global의 함수형 코틀린 발표를 리캡한다. 함수형의 역사부터 익스프레션 지향·고차 함수·모나드, 그리고 코틀린에서의 실용적 적용법까지 풀어낸다.

핵심 포인트

명령형('늪지')과 익스프레션 지향을 대비하고, 코틀린 스코프 함수로 가변 동작을 격리해 바깥을 깔끔하게 유지하는 법을 보여준다
combine→모노이드, map→펑터, flatMap→모나드로 모나드를 평이하게 정의하며, 실무에서는 flatMap 개념만 이해하면 충분하다고 강조한다
Arrow의 result 블록·bind로 모나드 컴프리헨션의 한계를 우회하되, HKT 부재로 3중 모나드는 어려우니 Result 하나로 줄이라고 제안한다

왜 읽나함수형 개념에 겁먹지 않고 코틀린 실무에 취사선택해 적용하고 싶은 개발자에게 용어보다 실용에 집중한 안내를 준다.

챕터별 상세

010:00 – 4:47

함수형의 역사와 '무엇이 함수형인가'

이 세션은 KotlinConf의 함수형 코틀린 발표를 모바일 개발자 김용욱(달리나음)이 리캡하는 자리다. 원 발표자에게 메일로 받은 자료로 진행한다. 먼저 컴포즈(Compose)와 코틀린 멀티플랫폼이 아직 해결 못 한 이슈가 많아, 스스로 버그를 해결할 수준이 돼야 실무에 쓸 수 있다고 조언하면서도, 컴포즈·플러터는 캔버스에 직접 그리는 방식이라 네이티브 UI 차이 이슈는 줄어들 것이라 전망한다. 이어 함수형의 역사를 짚는다. 1960년경 최초의 함수형 언어 리스프와 익스프레션 지향 개념이, 1968년경 객체지향이 등장했고 1970년대 스몰토크로 OOP는 70~80년대에 거의 완성형에 이르렀다. 반면 함수형은 완성이 더뎌 모나드 개념도 80년대에, 하스켈이 나왔을 때조차 모나드가 없었다. 그래서 '무엇이 함수형인가'에 대해 고차 함수·관심사 분리·모나드 등 사람마다 기준이 다르다고 정리한다.

발표자는 원 발표자가 명령형 프로그래밍을 '늪지'에 비유했다고 전한다. 명령형은 변수와 뮤테이션, 이를 다루는 루프·조건문, 그리고 사이드 이펙트(전역 변수·싱글톤·외부 입력)에 기반한다. 반대편의 익스프레션 지향 프로그래밍은 리스프·알골 68처럼 모든 것을 표현식으로 보고 데이터를 변형(transformation)하는 관점에서 입력과 출력만으로 사고하며, 더 간결하고 결정적이고 테스트하기 쉽다. 다만 현실 API에는 REST 클라이언트 설정·파일 생성 등 뮤테이션이 많은데, 코틀린의 스코프 함수(let·run·also·apply·with)로 가변 동작의 범위를 격리하면 바깥은 깔끔한 익스프레션 지향을 유지할 수 있다. 이어 고차 함수로 코드를 일반화한다. CSV·TSV처럼 구분자만 다른 두 함수에서 달라지는 부분을 파라미터로 전달하는데, 코틀린의 함수가 1급 함수여서 가능하다. 1급 함수를 파라미터·리턴값으로 다루는 함수가 고차 함수이며 둘은 늘 함께 등장한다.

발표자는 고차 함수 코드가 컴포저블하지 않다는 문제의식에서 모나드로 넘어간다. 카테고리 이론은 겁만 줄 뿐 깊이 들어가지 않는다며 핵심을 평이하게 정의한다. 두 컨테이너를 combine으로 합치면 모노이드, map을 가지면 펑터, flatMap을 가지면 모나드다. 엄격한 규칙은 순수주의자에게나 중요하고 실무에서는 flatMap만 이해하면 충분하며, 컬렉션·Optional·Mono 모두 모나드라 컴포징이 가능해진다. try/catch는 표준 라이브러리 Result로 더 컴포저블하게 바꾸되 리턴 타입에 Result를 붙여 성공/실패를 인지하게 한다. flatMap 중첩이 지저분해지는 것은 코틀린에 모나드 컴프리헨션이 없는 한계 탓인데, Arrow 라이브러리는 result 블록과 수신 객체로 bind를 붙여 수직 시퀀스처럼 쓰게 해 준다. 다만 모나드가 3중으로 겹치면 고차 종 타입(HKT) 부재로 못 풀어, 원 발표자는 suspend·널 가능 타입으로 모나드를 Result 하나로 줄이자고 제안한다. 실용적 결론으로, 전부 Result로 도배하지 말고 특별히 처리할 약 5%에만 한정적으로 쓰며, nullable 블록·Optics 같은 체리픽을 더하라고 정리하며 마친다.