Functor의 개념과 Swift내의 functor

배열은 Swift에서 동일 타입의 원소를 하나 이상 가질 수 있는 순서있는 집합을 나타내는 자료 구조이다. 배열은 Swift 뿐만 아니라 거의 모든 프로그래밍 언어에서 가장 기본적이며 중요한 자료 구조 중 하나인데, 특히 함수형 프로그래밍 언어에서는 배열을 리스트라고 하는 재귀적인 데이터 구조를 사용하여 일련의 연속적인 값들을 집합으로 다루게 된다. 배열 혹은 리스트에 대한 연산 중에서 가장 대표적인 것은 맵핑 연산이다.  하스켈의 fmap 은 임의의 타입의 원소를 갖는 리스트의 각 원소에 대해 주어진 함수를 적용하여 새로운 리스트를 생성한다. 그리고 대부분의 배열을 지원하는 현대 언어들도 비슷한 기능을 가지고 있다. 자바 스크립트의 Array와 Swift의 Array도 공통적으로 map이라는 메소드를 통해서 변형(transform)함수를 받아 자신의 원소들에게 적용하여 유사한 동작을 수행한다.

Functor의 개념과 Swift내의 functor 더보기

꼬리와 꼬리재귀는 다르다. (Swift)

꼬리재귀

Natasha ElementTypehe Robot에 꼬리재귀에 대한 글이 올라오고 Digg에서 많은 digg을 얻었는데, 좀 이상해서 내용을 정리해본다. 링크한 글의 저자는 꼬리재귀와, 함수형 언어의 자료 구조인 리스트의 head, tail을 혼동하고 있는 듯 하다. 우선 꼬리재귀에 대해서 먼저 이야기하겠다. 꼬리 재귀는 재귀의 특별한 한 형태이다. 꼬리 재귀를 설명하기 전에 먼저 재귀(recursion)에 대해 알아보자.

재귀는 어떤 함수의 내부에서 스스로를 다시 호출하는 것을 말한다. 예를 들어서 1에서 10 까지의 자연수의 합을 구하는 과정을 재귀적인 처리를 통해서 구한다고 생각해보자.

  1. 계산은 1 + 2 + 3 + 4 + … + 10 으로 이루어지고, 편의상 이걸 +(1~10) 이라고 표현하기로 약속한다.
  2. 이 때 10까지의 합과 9까지의 합은 10만큼 차이난다, 즉 +(1~10)+(1~9) + 10 인 셈이다.
  3. +(1~n)+(1~(n-1)) + n 이 된다.

이 관계를 이용하면 1에서 n 까지의 자연수의 합을 구하는 함수를 다음과 같이 작성할 수 있다.

func sumUpto(n: Int) -> Int {
  guard n > 0 else { return 0 }
  return n + sumUpto(n: n - 1)
}

재귀함수의 기술적 한계

재귀함수는 1) 어디까지 계산할 것인가와 2) 한 단계의 계산과 다음 단계의 계산의 관계만을 생각하는 것으로 전체 계산 알고리듬을 매우 간결하게 정리할 수 있는 장점이 있다. 문제는 기술적인 한계때문에 재귀의 단계는 일정한 범위 이상으로 커질 수가 없다는 점이다. 그것은 재귀함수가 자신을 호출하는 것에 대해서 시스템은 부가적인 리소스를 더 많이 소모해야 한다는 것이다.

프로그램 흐름에서 함수의 호출은 메인 루틴에서 별도의 서브 루틴으로 흐름이 이행되는 것을 의미한다. 함수 내부로 실행 흐름이 들어가게 되면 함수 내부에는 전달된 인자와 함수 내부에서 선언된 지역 변수, 상수들이 존재하며 이것은 메인 루틴의 스코프와는 개별적인 값들이 된다. 또한 함수의 실행이 끝나면 실행 흐름은 메인 루틴에서 함수를 호출했던 위치로 돌아가야 하고, 이 때 실행 흐름이 액세스할 수 있는 변수들은 원래의 스코프의 값들이 되어야 한다. 이러한 리소스 제어를 위해서 함수가 호출되면 시스템은 메모리 영역의 끝단에 별도의 스택을 만들고 여기에 인자값과 함수의 지역 변수들을 복사한다. 그리고 함수의 실행이 끝나면 스택 영역을 파괴하여 리소스를 회수하는 식으로 동작한다.

함수의 재귀 호출은 함수는 하나지만, 함수가 매번 재귀 호출 될 때마다 별도의 독립적인 컨텍스트가 요구되기 때문에 재귀 호출을 반복하면 반복할 수록 스택영역을 계속해서 추가적으로 사용해 나가야 한다. 하지만 당연하게도 시스템의 메모리 자원은 한정되어 있기 때문에 스택 영역의 크기는 제한된다. 통상 몇 천~몇 만 단위의 횟수 내에서 스택이 중첩될 수 있고 (이것은 언어나 컴파일러마다 다르다.) 따라서 재귀의 깊이 역시 제한된다.

그런 이유에서 위의 sumUpto(n:) 함수는 몇 만 단위의 n 값에 대해서는 값을 계산하지 못하고 프로그램이 터지게 된다. 또한 시스템 입장에서 스택 영역을 할당하고 파괴하는 작업은 상당히 비싼 작업이다. 따라서 그만큼 성능 측면에서도 불리하다.

꼬리재귀 최적화

그런데 재귀 함수의 특정한 패턴 중에는 꼬리재귀(tail recursion)라는 것이 있다. 꼬리 재귀는 함수가 자신을 재귀호출한 결과를 바로 리턴하는 것을 의미한다. 꼬리 재귀가 특별한 이유는 다음과 같다.

  1. 꼬리 재귀에서 재귀의 결과는 그대로 리턴되므로 재귀의 결과에 대한 추가적인 연산이 불필요하다.
  2. 재귀 결과에 추가적인 연산이 불필요하다는 점은, 재귀 결과를 받은 시점에 해당 함수 내의 다른 컨텍스트를 더 이상 참조하지 않는다는 의미이다.
  3. 그렇다면 재귀 호출을 하려는 시점이 되면, 해당 레벨의 컨텍스트가 필요하지 않다는 것을 의미한다.
  4. 그런데 재귀 호출이 될 때 필요한 컨텍스트는 사실상 현재 컨텍스트와 동일하다.

즉 이 말은 꼬리 재귀 형태의 코드는 스택을 계속 생성할 필요 없이 함수의 첫 부분으로 되돌아 가는 것으로 실행 흐름을 대체할 수 있다는 뜻이 된다. 컴파일러 입장에서는 꼬리 재귀를 판단하는 것도 간단하다. 따라서 컴파일러는 이러한 꼬리 재귀 패턴을 간단하게 루프로 치환할 수 있고, 그렇게해서 재귀호출에 따르는 비용을 최소화하고 수행 속도도 높일 수 있다. 이것을 꼬리재귀 최적화라 한다. (현대의 대부분의 언어 구현체들은 꼬리재귀 최적화를 지원하고 있다.)

앞서 sumUpto(n:)은 재귀 호출 결과에 n을 더한 후에 리턴하기 때문에, 재귀 호출한 결과를 다시 가공하여 호출하고 있기에 꼬리 재귀가 아니라 하였다. 왜냐하면 재귀의 결과에 다른 값을 누적해서 더해야하기 때문이다. 이런 경우에는 주로 누적된 결과를 추가적인 파라미터로 넘기면 꼬리 재귀로 변경할 수 있다.

func sumUptoByTailRecursion(n: Int, _ acc: Int = 0) -> Int {
  guard n > 0 else { return acc }
  return sumUptoByTailRecursion(n: n - 1, acc + n) // 위로부터 누적하여 아래로 내려보낸다.
}

이렇게 변경된 형태는 꼬리 재귀이고, 이제 동일한 연산에 대해서 컴파일러가 최적화 할 수 있게 되었다.

Swift의 꼬리재귀 최적화

Swift 컴파일러는 꼬리 재귀 최적화를 수행하는 것으로 보이지만, 실제로는 최적화가 적용되지 않는 경우가 있다. 그것은 ARC때문에, 컴파일러가 최적화를 수행하는 이전 단계에서 메모리 관리 코드를 여기 저기에 삽입할 수 있기 때문이다. 따라서 소스 코드 원안에서 꼬리 재귀 형태였던 것이 ARC에 의해서 모양이 바뀌면서 꼬리 재귀 최적화의 혜택을 받지 못하는 경우가 발생한다.

이러한 문제를 피하기 위해서 트램폴린이라는 기법을 사용할 수 있다. (트램폴린 기법은 명시적으로 재귀를 루프로 바꿀 수 있기 때문에 최적화가 훨씬 쉬우며, 심지어 꼬리 재귀 최적화를 지원하는 다른 언어에서도 문법적으로 구현이 가능하다면 실제 꼬리 재귀보다 좋은 성능을 보인다.)

리스트의 꼬리에 관하여

나타샤가 헷갈려한 tail은 무엇일까? 그것은 리스트라는 함수형 언어에서의 주력 데이터 타입에서 사용되는 용어이다. 그러려면 “리스트”라는 타입에 대해서 살펴보아야겠다. 리스트는 배열처럼 여러 개의 개별 원소값이 일렬로 나열된 순서가 정해진 집합을 나타낼 때 사용한다. 그럼 “연결리스트(linked list)”하고 비슷한 것인가라고 생각할 수 있는데, 연결리스트와는 다르다. 연결리스트는 원소값을 감싸는 노드가 자신의 다음 노드에 대한 참조를 가지고 있는 것인데, 리스트는 다음 원소와의 연결이 “연산자”에 의해 고정된다.

하스켈에서 리스트를 만드는 빌딩 블럭으로는 두 개의 표현이 사용되는데,

  1. [ ] 은 빈 리스트를 의미한다.
  2.  : 연산자는 원소:리스트 의 형태로 어떤 리스트의 앞에 하나의 원소를 결합하는 작용을 한다.

위 표현을 활용하면 얼마든지 긴 리스트를 만들 수 있다. 예를 들어 [1] 이라는 1개 원소를 가지는 리스트는 빈 리스트에 1이라는 원소를 붙인 것이므로 1:[ ] 로 표현할 수 있다. 그럼 [1, 2]는? 1:(2:[])가 된다. 이런 식으로 1:(2:(3:(4:(5:[]))))와 같이 표현되는 것을 (으아 괄호지옥이다!!!) 문법적으로 쓰기 편하게 [1,2,3,4,5]라고 표현하는 것이다.

리스트는 결국 맨 앞의 원소 하나와 그걸 제외한 나머지 리스트가 붙어있는 재귀적인 꼴로 정의된다. 여기서 맨 앞의 원소를 head, 나머지를 tail이라고 한다. 그렇다면 tail에 대한 재귀적인 처리를 tail recursion이라고 할까? 아니다. 리스트의 본질은 그 자체가 재귀적인 데이터 타입이기 때문에 리스트에 대한 거의 대부분의 연산은 재귀적으로 이루어질 수 밖에 없다. (애초에 하스켈은 반복문이라는 제어구조가 없어서 반복 자체가 모두 재귀로 수행되어야 한다.) 리스트의 합을 구하는 sum 이라는 함수를 정의한다고 하면 하스켈에서는 다음과 같이 정의할 수 있다.

sum :: Integral a => [a] -> a
sum [] = 0
sum (x:xs) = x + (sum xs)

하스켈은 선언적인 함수이기 때문에 변수라는 개념이 없다. x = 1 과 같은 식으로 값에 이름을 붙일 수 있지만 이것은 엄밀하게 1 이라는 항등함수 x를 의미하는 것이다. 따라서 각 원소의 누적값을 더해나갈 임시 변수같은 것이 존재하지 않기 때문에 리스트에 대해서 루프를 통한 연속적인 연산은 불가능하며, 리스트의 재귀적인 성질에 의존하는 재귀적인 처리만이 가능하다. 그리고 (x + sum xs라는 표현 자체는 꼬리 재귀의 모양도 아니다.)

참고로 하스켈의 리스트는 Swift에서도 구현할 수 있다. 열거체는 indirect 변경자를 사용해서 재귀적으로 정의가능하기에 다음과 비슷하게 구성할 수 있다.

enum List<T> {
  case empty
  case list(T, List<T>)
}

// 빈 리스트
let anEmptyList: List<Int> = .empty
// [1]
let one: List<Int> = .list(1, .empty)
// [1,2,3,4,5]
let oneToFive: List<Int> = .list(1, .list(2, .list(3, .list(4, .list(5, .empty)))))

// 그리고 합계를 구하는 함수
func sum(list: List<Int>) -> Int {
  switch list {
  case .empty: return 0
  case .list(let x, let xs): x + sum(list:xs)
  }
}

Swift에서 Monad와 Curried Function 사용하기

Functional Programing in Swift

Swift는 함수형 프로그래밍은 아니지만 함수형 언어들의 특성을 많이 따르고 있다. 그 중에 모나드와 커리드함수(부분적용함수)를 만드는 방법에 대해 살펴보자.

Swift에서 Monad와 Curried Function 사용하기 더보기