🍭 Chapter 1: 함수형 프로그래밍이란 무엇인가?

함수형 프로그래밍(functional programming, FP)은 간단하지만 심오한 뜻을 담은 전제에 기초한다. 그 전제란, 프로그램을 오직 순수 함수(pure function)들로만, 다시 말해서 부수 효과(side effect)가 없는 함수들로만 구축한다는 것이다. 부수 효과가 무엇일까? 그냥 결과를 돌려주는 것 이외의 어떤 일을 수행하는 함수를 가리켜 부수 효과가 있는 함수라고 칭한다. "그냥 결과를 돌려주는 것 이외의 어떤 일"의 예를 몇 가지 들자면 다음과 같다.

• 변수를 수정한다.
• 자료구조를 제자리에서 수정한다.
• 객체의 필드를 설정한다.
• 예외(exception)를 던지거나 오류를 내면서 실행을 중단한다.
• 콘솔에 출력하거나 사용자의 입력을 읽어들인다.
• 파일에 기록하거나 파일에서 읽어들인다.
• 화면에 그린다.

함수형 프로그래밍은 우리가 프로그램을 작성하는 방식에 대한 제약이지 표현 가능한 프로그램의 종류에 대한 제약이 아니라는 것이다. 순수 함수들로 프로그램을 작성하면 모듈성(modularity)이 증가한다. 모듈성 덕분에 순수 함수는 검사(test), 재사용, 병렬화, 일반화, 분석이 쉽다. 더 나아가서, 순수 함수는 버그가 생길 여지가 훨씬 적다.

🎃 FP의 이점: 간단한 예제 하나

🎈 부수 효과가 있는 프로그램

커피숍에서 커피를 구매하는 과정을 처리하는 프로그램을 구현한다고 가정하자. 우선 구현에서 부수 효과를 사용하는(이를 불순한[impure] 프로그램이라고 부르기도 한다) 스칼라 프로그램부터 보자.

class Cafe {
  def buyCoffee(cc: CreditCard): Coffee = {
    val cup = new Coffee()
    // 부수 효과, 신용카드를 실제로 청구한다.
    cc.charge(cup.price)
    cup
  }
}

신용카드 청구에는 외부 세계와의 일정한 상호작용이 관여한다. 그러나 이 함수 자체는 단지 하나의 Coffee 객체를 돌려줄 뿐이고, 그 외의 동작은 모두 부수적으로(on the side) 일어난다.

부수 효과가 있기 때문에 이 코드는 검사하기가 어렵다. 코드를 검사하기 위해 실제로 신용카드 회사와 연결해서 카드 이용 대금을 청구하고 싶지는 않기 때문이다. CreditCard 대신 지급을 위한 Payments 객체를 buyCoffee에 전달한다면 코드의 모듈성과 검사성을 좀 더 높일 수 있다.

class Cafe {
  def buyCoffee(cc: CreditCard, p: Payments): Coffee = {
    val cup = new Coffee()
    p.charge(cc, cup.price)
    cup
  }
}

p.charge(cc, cup.price)를 호출할 때 여전히 부수 효과를 발생하지만, 적어도 검사성은 조금 높아졌다. 이 구현에는 buyCoffee를 재사용하기 어렵다는 또 다른 문제가 있다.

🎈 함수적 해법: 부수 효과의 제거

이에 대한 함수적 해법은 부수 효과들을 제거하고 buyCoffee가 Coffee뿐만 아니라 청구건을 하나의 값으로 돌려주게 하는 것이다. 청구 금액을 신용카드 회사에 보내고 결과를 기록하는 등의 처리 문제는 buyCoffee 바깥의 다른 어딘가에서 해결하도록 한다.

class Cafe {
  def buyCoffee(cc: CreditCard): (Coffee, Charge) = {
    val cup = new Coffee()
    (cup, Charge(cc, cup.price))
  }
}

이제 청구건의 생성 문제가 청구건의 처리 또는 연동 문제와 분리되었다. buyCoffee 함수는 이제 Coffee 뿐만 아니라 Charge도 돌려준다. 이런 변경 덕분에 여러 잔의 커피를 한 번의 거래로 구매하기 위해 이 함수를 재사용하기가 쉬워졌음을 잠시 후에 보게 될 것이다. 다음은 Charge 이다.

case class Charge(cc: CreditCard, amount: Double) {
  def combine(other: Charge): Charge =
    if (cc == other.cc)
      Charge(cc, amount + other.amount)
    else
      throw new Exception("Can't combine charges to different cards")
}

그럼 커피 n잔의 구매을 구현한 buyCoffees 함수를 보자. 이전과는 달리, 이 함수는 buyCoffee를 이용해서 구현되어 있다.

class Cafe {
  def buyCoffee(cc: CreditCard): (Coffee, Charge) = {
    val cup = new Coffee()
    (cup, Charge(cc, cup.price))
  }

  def buyCoffees(cc: CreditCard, n: Int): (List[Coffee], Charge) = {
    val purchases: List[(Coffee, Charge)] = List.fill(n)(buyCoffee(cc))
    val (coffees, charges) = purchases.unzip(coffees, charges.reduce((c1, c2) => c1.combine(c2)))
  }
}

전반적으로, 이 해법은 이전보다 뚜렷이 개선되었다. 이제는 buyCoffee를 직접 재사용해서 buyCoffees 함수를 정의할 수 있으며, 두 함수 모두 Payments 인터페이스의 복잡한 모의 구현을 정의하지 않고도 손쉽게 검사할 수 있다. 실제로 Cafe는 이제 Charge의 대금이 어떻게 처리되는지 전혀 알지 못하다.

Charge를 일급(first-class) 값으로 만들면, 청구건들을 다루는 업무 논리를 좀 더 쉽게 조립할 수 있다는 예상치 못했던 또 다른 이득이 생긴다.

FP는 아주 간단한 루프에서부터 고수준 프로그램 기반구저에 이르기까지 모든 수준에서 프로그램의 조직화 방식을 아주 급진적으로 변화시킨다. FP에서 파생되는 스타일은 다른 프로그래밍의 것과 상당히 다르지만, 그것은 아름답고 응집력 있는 프로그래밍 접근방식이다.

🎃 (순수)함수란 구체적으로 무엇인가?

입력 형식이 A이고 출력 형식이 B인 함수 f는 형식이 A인 모든 값 a를 각각 형식이 B인 하나의 값 b에 연관시키되, b가 오직 a의 값에 의해서만 결정되나는 조건을 만족하는 계산이다. 내부 또는 외부 공정의 상태 변경은 f(a)의 결과를 계산하는 데 어떠한 영향도 주지 않는다. 예를 들어 Int => String 형식의 intToString 함수는 모든 정수를 그에 대응되는 문자열에 대응시킨다. 그리고 이것이 만일 실제 함수(function)이면, 그 외의 일은 전혀 하지 않는다.

다른 말로 하면, 함수는 주어진 입력으로 뭔가를 계산하는 것 외에는 프로그램의 실행에 그 어떤 관찰 가능한 영향도 미치지 않는다. 이를 두고 함수에 부수 효과가 없다고 말한다. 그런 함수를 좀 더 명시적으로 순수(pure) 함수라고 부르기도 하지만, 이는 다소 군더더기이다. 특별한 언급이 없는 한, 이 책에서 함수는 부수 효과가 없는 함수를 뜻한다.

순수 함수의 이러한 개념을 참조 투명성(referential transparency, RT)이라는 개념을 이용해서 공식화할 수 있다. 참조 투명성은 함수가 아니라 표현식(expression)의 한 속성이다. 에를 들어 2 + 3은 하나의 표현식이다. 이 표현식은 값 2와 3에 순수 함수 +를 적용한다. 이 표현식에는 부수 효과가 없다. 이 표현식의 평가는 항상 5라는 같은 결과를 낸다. 실제로, 프로그램에 있는 모든 2 + 3을 값 5로 바꾸어도 프로그램의 의미는 전혀 바뀌지 않는다.

이것이 바로 표현식의 참조 투명성의 전부이다. 즉, 임의의 프로그램에서 만일 어떤 표현식을 그 평가 결과로 바꾸어도 프로그램의 의미가 변하지 않는다면 그 표현식은 참조에 투명한 것이다. 그리고 만일 어떤 함수를 참조에 투명한 인수들로 호출하면, 그 함수도 참조에 투명하다.

🎈 참조 투명성, 순수성, 그리고 치환 모형

참조 투명성의 정의가 원래의 buyCoffee 예제에 어떻게 적용되는지 살펴보자.

def buyCoffee(cc: CreditCard): Coffee = {
  val cup = new Coffee()
  cc.charge(cup.price)
  cup
}

cc.charge(cup.price)의 반환 형식이 무엇이든, buyCoffee는 그 반환값을 폐기한다. 따라서 buyCoffee(aliceCreditCard)의 평가 결과는 그냥 cup이며, 이는 new Coffee()와 동등하다. 앞의 참조 투명성 정의하에서 buyCoffee가 순수하려면 임의의(any) p에 대해 p(buyCoffee(aliceCreditCard))가 p(new Coffee())와 동일하게 작동해야 한다. 이 조건이 참이 아님은 명백하다. new Coffee()라는 프로그램은 아무 일도 하지 않지만 buyCoffee(aliceCreditCard)는 신용카드 회사에 연결해서 대금을 청구하기 때문이다.

참주 투명성은 함수가 수행하는 모든 것이 함수가 돌려주는 값으로 대표된다는 불변 조건을 강제한다. 이러한 제약을 지키면 치환 모형이라고 부르는, 프로그램 평가에 대한 간단하고도 자연스러운 추론 모형이 가능해진다. 참조에 투명한 표현식들의 계산 과정은 마치 대수 방정식의 풀 때와 아주 비슷하다. 즉, 표현식의 모든 부분을 전개하고, 모든 변수를 해당 값으로 치환하고, 그런 다음 그것들을 가장 간단한 형태로 환원(축약)하면 된다. 각 단계마다 하나의 항을 그에 동등한 것으로 대체한다. 즉 계산은 등치 대 등치(equals for equals) 치환을 통해서 진행된다. 다른 말로 하면, 참조 투명성은 프로그램에 대한 등식적 추론(equational reasoning)을 가능하게 한다.

치환 모형 추론은 평가의 부수 효과가 전적으로 국소적이다. 따라서 코드 블록을 이해하기 위해서 머릿속에서 일련의 상태 갱신들을 따라갈 필요가 없다. 국소 추론(local reasoning)만으로도 코드를 이해할 수 있다. 함수의 실행 이전과 이후에 발생할 수 있는 모든 상태 변화들을 머릿속으로 짚어 나가지 않고도 함수가 하는 일을 이해할 수 있는 것이다. 그냥 함수의 정의를 보고 함수 본문에서 인수들을 치환하기만 하면 된다. 바로 치환 모형으라는 구체적인 용어를 사용하지 않았더라도, 자신의 코드를 추론할 때 독자도 아마 이런 모형을 사용해 왔을 것이다.

순수성의 개념을 이런 식으로 공식화해 보면, 함수적 프로그램의 모듈성이 다른 경우에 비해 더 좋은 경우가 많은 이유를 짐작할 수 있다. 모듈적인 프로그램은 전체와는 독립적으로 이해하고 재사용할 수 있는 구성요소들로 구성된다. 그런 프로그램에서 프로그램 전체의 의미는 오직 구성요소들의 의미와 구성요소들의 합성에 관한 규칙들에만 의존한다. 즉, 구성요소들은 합성 가능(composable)하다. 순수 함수는 모듈적이고 합성 가능한데, 이는 순수 함수에서 계산 자체의 논리가 "결과로 무엇을 할 것인가"나 "입력을 어떻게 얻을 것인가"와는 분리되어 있기 때문이다. 즉, 순수 함수는 하나의 블랙박스이다. 입력이 주어지는 방식은 단 하나이다. 입력은 항상 함수에 대한 인수들로만 주어진다. 그리고 함수는 결과를 계산해서 돌려줄 뿐, 그것이 어떻게 쓰이는지는 신경 쓰지 않는다. 이러한 관심사의 분리 덕분에 계산 논리의 재사용성이 높아진다. 결고에 관련된 부수 효과나 입력에 얻는 데 관련 부수 효과가 모든 문맥에서 적절한지 걱정하지 않고 함수를 재사용할 수 있다.