Tail 과 꼬리재귀(Tail Recursion) – 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. 재귀 호출되었을 때 새로 생성해야 할 컨텍스트는 사실상 현재 컨텍스트와 동일하다.

이 말이 무엇을 의미하는가? 꼬리 재귀에서는 재귀 호출로 새로운 스택을 만들고 새 함수 컨텍스트로 실행 흐름을 옮기는 대신에, 현재 함수의 맨 처음으로 실행 흐름이 점프하면 된다는 의미이다. 즉 꼬리 재귀는 그 흐름이 루프로 치환된다는 것이다. 게다가 꼬리 재귀를 판단하는 것도 매우 간단해서 return 문에 재귀 호출구문이 있고 그외의 표현식이 없으면 된다. 따라서 컴파일러는 이러한 꼬리 재귀 패턴을 간단하게 루프로 치환할 수 있고, 그렇게 하여 스택 생성과 파괴에 따른 메모리 및 성능 낭비를 막을 수 있다. 이것을 꼬리 재귀 최적화라고 한다.

앞서 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 컴파일러는 꼬리 재귀 최적화를 수행하는 것으로 보이지만, 실제로는 최적화가 적용되지 않는 경우가 있다. 그것은 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)
  }
}

접기

다시 원글에서 나타샤는 reduce에 대한 이야기를 하고 있다. 리스트를 하나의 값으로 축약하는 행위는 엄밀하게 말하면 재귀적인 특성이 아니라 항등원을 갖는 이원연산과, 그 연산의 항등원에 관한 성질 때문이다. 이러한 연산은 두 개의 값을 하나로 합칠 수 있고, 하나의 값이 있을 때에는 항등원을 이용해서 연산을 적용할 수 있다. 이러한 연산과 항등원을 모노이드라고 하는데, 모노이드로부터 Foldable이라는 특성을 규정한다. 따라서 재귀와 아무런 관련이 없는 배열이나, 옵셔널등도 모노이드의 성질을 가지며 reduceflatMap과 같은 연산을 적용받을 수 있다.