함수형 프로그래밍은 그래서 왜 쓸까?

  현재 다니고 있는 회사에서는 함수형 프로그래밍을 코드 전반에서 적극적으로 사용하고 있다. 사내에서 사용하고 있는 언어가 Kotlin이다보니, Kotlin 을 더 잘 사용할 수 있는 방법에 대해 고민하다가 함수형 프로그래밍에 대해서 스터디를 진행했었다. 스터디를 진행하면서 적용해볼 수 있겠다 싶은 내용들은 실제로 프로덕션 코드에 녹이면서 나름대로 함수형 프로그래밍을 적극적으로 활용하고 있다라고 생각했다.

  어느날, 함수형 프로그래밍을 공부할까 고민하시던 같은 팀의 프론트 엔지니어 분이 “함수형 프로그래밍이 뭐에요? 도입하면 장점이 뭐에요?”라고 여쭤보셨다. 순간 말문이 막히는 것을 느껴졌고, 내가 함수형 프로그래밍을 사용하고 있다고 생각했지만, 그 장점이 무엇인지 대체 왜 써야하는건지에 대한 답을 명확히 설명할 수 없다는 것을 깨달았다. 그 이후로 그 답을 찾기 위해서 함수형 프로그래밍에 관한 세가지 정도 책을 읽었었고 그 내용을 이번 포스팅에서 정리해보고자 한다.

 

---

함수형 프로그래밍이란?

  그래서 함수형 프로그래밍이란 무엇일까?
  나는 이 질문에 대해 명확하게 대답하는 것 이 상당히 힘들었다. 하지만 찾아보니 나만 그런 것은 아니였던 것 같다. 함수형 자바스크립트의 저자인 마이클 포거스는 ‘클로저 프로그래밍의 즐거움’에서 함수형 프로그래밍의 정의에 대해 다음과 같이 이야기했다.
   “우리도 정답을 모른다. 함수형 프로그래밍은 명확한 정의가 없는 컴퓨팅 용어 중 하나다. 어떤 사람이 어떤 책이, 또는 어떤 언어가 함수형 프로그래밍에 대한 권위를 주장할 수 있겠는가?”
   “함수형 프로그래밍의 실제적인 정의로 함수형 프로그래밍은 애플리케이션 함수의 구성요소, 더 나아가 언어 자체를 함수처럼 여기도록 만들고 이러한 함수 개념을 가장 우선순위에 놓는다. 함수는 값으로 다룰 수 있어서 다른 데이터들과 마찬가지로 저장이 가능하고 전달하거나 리턴 받을 수 있다. 이것이 함수형 프로그래밍에 가장 중요한 개념이다. 함수형 사고방식은 문제의 해결방법을 동사(함수)들의 구성으로 접근한다는 것이다”

 

내가 여러 책에서 찾아봤던 함수형 프로그래밍에 대한 정의 중에 가장 납득이 잘 갔던 문장은 다음과 같다.

함수형 프로그래밍은 성공적인 프로그래밍, 안전한 프로그램을 위해
부수 효과를 최대한 멀리하고
조합성을 강조하는 프로그래밍 패러다임이다.

 

 

함수형 프로그래밍이 부수효과를 최대한 멀리하는 이유는 다음 두가지이다.

1. 오류를 줄이기 위해
2. 조합성 혹은 모듈화 수준을 높이기 위해서

높은 모듈화 수준은 성공적인 프로그래밍의 핵심요소이다.
높은 모듈화 수준은 생산성을 높이고, 오류 없는 함수들의 조합은 프로그램 전체의 안정성을 높여준다.

 

---

함수형의 특징(장점)

🌱 함수형 프로그래밍은 범용적이다.

  객체지향 프로그래밍에서는 객체가 기준이라면 함수형 프로그래밍에서는 함수가 기준이다.
  객체가 기준이라는 말은 데이터형이 기준이 된다는 의미이고, 함수가 기준이라는 말은 로직이 기준이 된다는 의미다.
객체지향 프로그래밍이 데이터형을 설계한 후 데이터 형에 맞는 메서드를 붙여가는 식이라면, 함수형 프로그래밍은 함수로 로직을 설계한 후 로직에 맞는 데이터를 인자로 허용한다.
 함수형 프로그래밍은 각기 다르게 생긴 데이터 형을 더 많이 지원하기 위해 함수 내부를 함수로 추상화한다.
  덕분에 함수 하나가 처리할 수 있는 데이터 형은 끝이 없다. 함수형 프로그래밍에서는 데이터가 user, post,posts 인지는 별로 중요하지 않으며 모두 처리할 수 있는 아주 높은 다형성을 가진 하나의 함수를 만드는 방식으로 프로그래밍을 한다.

🌱 함수형 프로그래밍은 코드가 짧다.

  메서드가 계층 구조의 상속이나 인스턴스 생성으로 기능을 공유해야한다면, 함수가 혼자 존재하기에 아무렇게나 조합하면 된다. 데이터 형에서 자유롭고 조합이 자유로워 재사용성과 조합성이 매우 높다. 함수형 프로그래밍으로 작성된 코드를 보면 데이터의 생김새가 잘 보이지 않는다. 추상화의 정도가 높아 데이터 형이 코드에 잘 등장하지 않고 변수명이나 데이터의 구조가 표현되는 일이 적다. 대입문이 적어진다. 이런점들때문에 코드가 매우 짧아진다.

🌱 함수형 프로그래밍은 읽기 쉽다

  일단 분기가 적고, for while 같은 구조가 잘 등장하지 않아서 코드 모양이 단순하다. 다양한 형을 지원함에도 보조함수의 조합을 통해 분기를 대신하기때문에 if문이 적다. 위에서 아래로, 왼쪽에서 오른쪽으로 읽히는 코드는 읽기 쉽다. 분기 없이 앞으로만 가는 코드는 오류가 발생할 확률도 적고 고치기도 쉽다.

🌱 함수형 프로그래밍은 생명주기가 단순하다.

  선언과 실행이라는 단순한 생명주기를 갖기 때문에 언제든지 어디서든지 사용하기 쉽다. 함수가 언제 실행되었는가, 어느 스코프에서 선언되었는가, 언제 실행되었는가, 언제 실행될 것인가만 중요하다. 또한 대부분의 함수들은 만든이가 담은 설계, 철학과 같은 추가적인 개념들이 적어서 빨리 이해할 수 있고 쉽게 사용할 수 있다. 누가 만든 함수이든 인자와 결과만으로 가볍게 소통할 수 있다.

---

함수형 프로그래밍의 키워드

🌱 일급함수

일급은 값으로 다룰 수 있다는 의미로, 아래와 같은 조건을 만족해야한다.

• 변수에 담을 수 있다.
• 함수나 메서드의 인자로 넘길 수 있다.
• 함수나 메서드에서 리턴할 수 있다.

일급함수란, 아래와 같은 조건을 만족한다는 의미이다.

• 함수를 변수로 담을 수 있다.
• 함수나 메소드의 인자로 함수를 넘길 수 있다.
• 함수나 메서드에서 함수를 리턴할 수 있다.

🌱 고차함수

고차함수란 함수를 다루는 함수

1. 함수를 인자로 받아 대신 실행하는 함수
2. 함수를 리턴하는 함수
3. 함수를 인자로 받아서 또다른 함수를 리턴하는 함수

사실상 함수형 프로그래밍 절반은 고차함수를 적극적으로 활용하는 프로그래밍이라고도 할 수 있다.
유명한 고차함수들로는 map filter reduce 등이다.

🌱 순수한 함수

• 동일한 입력으로 실행하면 항상 동일한 결과가 나온다. (참조 투명성)
• 부수효과가 없다.

 

🌱 참조 투명성?

  프로그램의 변경 없이 어떤 표현식을 값으로 대체할 수 있다는 뜻이다.
  순수한 함수 f(x)가 y를 반환한다면, f(x)는 y로 대체될 수 있다는 뜻이다.
  같은 입력이 주어지면 항상 같은 결과를 내놓기 때문에 프로그램의 결과를 예측하고 추론할 수 있다. 이처럼 참조 투명성은 개발자나 컴파일러가 평가 결과를 추론할 수 있게 한다. 그래서 프로그램이 실행되기 전에 컴파일러가 코드를 최적화하거나 코드가 평가되는 시점을 늦출 수 있다. 또한 프로그램의 동작을 항상 알 수 있기 때문에 더 안전할 뿐만 아니라 더 쉽게 조합하고 유지 보수하고 변경하고 테스트 할 수 있다.

---

 

안전한 프로그래밍?

  이전 함수형 프로그래밍의 정의에서 이야기했던 "안전한 프로그램"에 대해 조금 더 이야기하고자 한다. 이에 대해서는 코틀린을 다루는 기술 중에서 내가 동의할 수 있는 부분만 발췌했다.

🌱 안전한 프로그래밍이란 무엇인가?

• 프로그램에서 버그를 완전히 없애지는 못한다.
• 남은 버그가 프로그램에서 별도로 구분된 (안전이 보장되지 않는) 영역에서만 일어난다고 보장된다면,
• 버그를 더쉽고 효율적으로 잡을 수 있다.
• 버그 없음이 명확히 보이는 단순한 프로그램을 작성하는 것 그것이 안전한 프로그래밍과 연결된다.

🌱 프로그램을 더 안전하게 만드려면?

• 불변 변수를 사용해라.
• 순수하지 못한 함수의 선언을 최소화하고, 순수하지 못한 작업이 필요한 부분만 모듈화하여 분리하라.
  • 부수효과를 일부영역 안에서만 일어나도록 제한하라.
  • 이말은 프로그램을 작성할 때 일부 한정된 영역을 제외한 나머지 부분에서 콘솔등의 장치를 출력하거나 파일, 데이터베이스, 네트워크등의 장치에 데이터를 쓰는 등의 행위를 하지말아햔다
• 부수효과를 없애라.
  • 프로그램이 반환하는 결괏값에 덧붙여 프고르램 밖에서 관찰할 수 있는 어떤 변화를 뜻한다.
  • 값을 반환하는 메소드나 함수가 외부상태를 변경하는 경우
  • 부수효과
• 예외를 던지지 마라.
  • 예외를 던지는 것은 goto이 현대적 변형이다.
  • 이로인해 프로그램이 스파게티 코드가 될 수 있다.
  • 스파게티 코드라는 말은 프로그램 흐름이 어디서 시작하는지 알 수 없지만, 어디로 흘러가는지 제대로 따라갈 수 없다는 뜻이다.
• 안전한 프로그램은 인자를 받아서 반환하는 여러 함수를 합성해 만들어진다.
  • 그리고 그런 함수 합성이 프로그램을 이루는 전부다.

  함수의 합성부분과 예외를 던지지 말라는 부분은 내가 함수형 프로그래밍을 처음 접했을 때는 이해가 되지 않는 부분이였다. 하지만 이제는 조금은 공감할 수 있는 부분이다.
  현재 회사에서 프로덕션 코드를 작성할때는 예외를 냅다 던지는 것보다 Result로 감싸서 사용하고 있다. Result를 사용하게되면, 예외에 대한 처리를 더 부드럽게, 자연스럽게 할 수 있다. 실패했을 때(에러가 났을때) 어디로 어떻게 가서 어떤 처리를 하는지 잘 트래킹할 수 있다. 그냥 코드를 부드럽게 읽으면 나와있다.
  물론 비슷한 처리를 try~ catch가 해줄 수 있지만 이보다 코드가 깔끔하게 나올 수 있다. 이에 관련한 글은 토스의 에러핸들링을 다른 클래스에게 위임하기 라는 블로그 글을 보면 잘 설명되어있다. Result에 적응하고 나니, throw Error를 하는데 어디서 잡아주는 지가 내 눈에 바로 보이지 않으면, 잘 처리하다가 갑자기 쓰레기통에 던져버리는 기분이 들었다. 물론 적응하기 까지는 오래걸렸다. 처음에는 Reuslt를 써서 오히려 코드가 더 어려워지는 느낌을 상당히 많이받았다. 하지만 Result를 잘 사용할 수있는 활용성(추상화 수준)이 높은 함수들이 만들어지고서야 좀 제대로 사용할 수 있었다.

try … catch를 사용했을때

return runCatching {
  loginApiClient.login(request)
}.onFailure { e -> 
  if (e.errorCode != "INVALID_PASSWORD") throw e
}.getOrNull()

runCatching을 사용했을 때

try {
  loginApiClient.login(request) 	
} catch (e: LoginException) {
  if (e.errorCode == "INVALID_PASSWORD") {
    return null
  } else {
    throw e
  }
}

   합성할 수 있는 함수를 만들기 위해서는 높은 수준으로 추상화를 해야한다. 그러다보면 저절로 작게 쪼개지게 된다. 당장은 그 함수에서 하는일이 딱히 없어보일 수 있다. 하지만 계속 사용하다보면 재사용성이 높은 함수가 되어있다는 것을 조금씩 깨닫게된다. 하나의 함수를 만들 때 처음부터 짜는 것이 아니고, 함수에 함수를 조립해서 또하나의 함수를 만들고, 그렇게 함수들을 조립하다보면 하나의 기능이 되어있다는 것을 알 수 있었다. (물론 항상 그런 것은 아니다.) 이런 식으로 한번 코드를 짜보면 약간 코드짜는게 퍼즐 맞추는 것 마냥, 레고 조립하는 것 마냥 재밌다는 느낌을 받을 때가 있다.

 

마무리

  함수형 프로그래밍의 장점에 대해서 포스팅을 썼지만, 함수형 프로그래밍이 객체지향 프로그래밍보다 우월하다고 생각하는 것이 아니다. 함수형 프로그래밍과 객체지향 프로그래밍은 상호 배제적인 관계가 아니다. 결국 두가지 패러다임 모두 유연하고 지속 가능한 시스템을 만들자는 목적이며, 서로를 보완해줄 수 있는 관계라고 생각한다. 나에게 있어서 함수형 프로그래밍을 사용해보면 얻었던 가장 큰 이득(장점)은, 함수를 더 쪼개고 재사용성 가능하게 만들어보려고 노력했었던 경험과 객체 지향 패러다임이 유일하며 가장 좋은 패러다임이라는 생각에서 벗어날 수 있었다는 것이라고 생각한다.



Ref.
코틀린을 다루는 기술
함수형 자바스크립트

코틀린으로 배우는 함수형 프로그래밍