[질문] 함수 호출의 부하

1. 함수가 호출될 때마다, 함수의 arguments와 local variables, 그리고 return value 등을 위한 stack이 할당됩니다. function stack이란 것이 있어서 프로그램이 실행후에 함수가 한 번 불릴 때마다 필요한 만큼 증가했다가 함수가 종료하면 줄어듭니다. 당연히 함수가 다른 함수를 계속 부른다면 그만큼 스택이 계속 증가합니다.

2. 만약 함수 A가 B를, 그리고 다시 B가 A를 부르는 상황이 발생하면 무한하게 함수 호출이 계속되면서 스택이 계속 증가하게 됩니다.

3. 제가 아는 한, 유닉스 시스템에서는 프로세스의 주소공간(address space)에 스택 영역이 따로 정해져있습니다. ulimit 등으로 확인 가능하며 일반적으로 8메가 정도로 정해져있습니다. 만약 함수 호출이 계속되면서 스택 사이즈가 증가하다가 영역을 벗어나게 되면 stack overflow가 발생합니다. 보통은 이러한 상황에서 segmentation fault를 보게 되겠죠. :(

4. 스택이 한정되어있기 때문에 함수 호출을 원하는대로 할 수 없는 상황이 발생하게 됩니다. 따라서 함수 호출할 때 그 함수에 대한 스택 증가량을 줄이는 것이 관건이며, 주로 불필요한 arguments를 줄이고 local variables의 수를 줄임으로써 해결합니다. 특히 array같은 큰 사이즈의 변수 등은 스택에 할당되지 않도록 heap 에 할당하고 - malloc()등을 사용하여 - 포인터 변수만 스택에 넣어놓음으로써 스택 사이즈를 크게 줄일 수 있습니다.

5. 어느 언어든 현재의 컴퓨터 시스템 위에서 동작하기 위하여 튜링 머신의 형태에 맞는 코드를 생성합니다. 생성되는 코드는 언어의 특성과 컴파일러에 따라 좌우되기 때문에, 언어와 사용하는 컴파일러에 대한 이해가 충분해야 합니다.

재귀호출을 안 쓰고 가능할 것 같은데 (순전히 짐작 ㅎ).. 가능한가요?

큐를 이용해서 BFS를 하면 될 것 같은데.. upper directory는 ".."로 접근할 수 있겠지요?

으음.. 근데 큐를 동적으로 관리해야 하는 압박이 있는건가.. -_-;

모든 재귀 호출 알고리즘은 비재귀 호출로 전환할 수 있습니다.

재귀 호출은 만들때는 간단해서 좋은데, 쓰다 보면 스택 초과가
일어나는 상황이 언젠가는 오게 되는 것 같아서, 저 같은 경우는
왠만하면 비재귀로 전환합니다.

재귀호출이 결국 프로그램 스택을 이용하기 때문에,
비재귀로 구현할 수 없는 리커젼 알고리즘은 있을 수가 없습니다.

구현이 어려운 것은 있어도 불가능한 것은 없는 것으로 알고 있습니다.

스택없이 비재귀로 전환하는 제약 조건이 있다면 비재귀로 구현할 수 없는 것이 많겠습니다만....

왜 스택으로 구현하는 것을 재귀함수를 시뮬레이션 한다고 생각하시는 지요? 알고리즘을 스택을 이용해서 구현했다고 생각하시면 될 것 같은데요.

자료 구조 관련 서적에서도 비재귀로 전환 부분에서 스택을 이용하는 예들이 나옵니다. 혹시 '스택을 이용하는 것이 재귀함수를 시뮬레이션 하는 것이다' 라던가, '스택을 이용하면 완전한 비재귀라 볼 수 없다'고 나온 참고 문헌이 있으면 알려주시기 바랍니다.

리얼타임이 아니라면 함수 호출의 오버헤드는 철저히 무시하는 게 좋습니다. 그 정도 오버헤드 때문에 코드의 지저분함을 감수할 필요는 없습니다.

재귀호출을 Dynamic Programming이라든지 앞서의 스택을 이용한 방법 등으로 풀 수 있긴 합니다만 재귀호출의 또다른 장점이 트리 구조 같은 자료구조를 명료한 코드로 다룰 수 있다는 것인데 그 장점을 포기할 정도로 오버헤드가 크진 않습니다. 당신들의 PC는 이미 엄청나게 빠릅니다-_-

XP에서는 Lazy Optimization & Early Profiling을 권장합니다. 성능 문제는 프로파일링을 통해 극복해 나가시고 속설에 의지하지 마십시오.

전웅님 말씀에 동의합니다.

성능이야, 최신 컴파일러들의 스택 최적화가 잘 이루어지는 편이기 때문에 비재귀호
출로 바꾼다고 해서 일반적으로 성능향상이 많이 되는것은 아니죠. 하지만 컨텍스트
를 직접 컨트롤 할 수 있다는 점에서 메리트가 생길 수 있는 상황이 많이 발생합니
다. 디버깅이 용이한 점도 있겠군요. (저만의 생각인가요?)

어쨌거나, 개인적으로는 일단 재귀호출이든 아니든 자신이 편하고 쉽게 생각할 수
있는 방향으로 먼저 개발하고 나서 최적화 과정에서 다른 방식으로 변경하면 된다
고 생각합니다. 그를 위해서는 호출방식의 변경으로 인한 side effect를 최소화하도
록 다른 코드를 작성해야겠죠. 일반론적인 얘기라 여기서 끝내겠습니다.

재귀-비재귀의 변환은 지극히 기계적인 작업에 의해 가능합니다. 일부
알고리즘 서적의 경우 알고리즘에 대한 의미적인 이해 없이도 주어진
단계를 거쳐 재귀적 구현을 비재귀로 변환하는 방법을 다루기도 합니다.
여기에 알고리즘에 대한 이해가 더해질 경우, 실제 스택에 유지하지 않아도
되는 정보, 혹은 불필요한 잔작업에 대한 배제가 가능할 뿐입니다. 더구나
실무에서 사용되는 알고리즘의 복잡도가 이론적으로 제안되고 연구되는
알고리즘에 비해 까다롭지 않다는 점을 감안할 때 실제 재귀-비재귀의
변환이 버그 발생 가능성을 높인다고 보기는 어렵습니다. 또한, 조금이라도
그와 같은 가능성이 있다면 이는 악의적인 사용자에 의해 생길 수 있는
프로그램 전반에 영향을 주는 위험성을 위해 충분히 희생할 가치가 있다고
봅니다.

이와 같은 논점에서 프로그래머의 편의와 제품의 안정성이라는 대조가
이루어진 것입니다.

분명, 재귀적 구현의 장점은 재귀적으로 쉽게 기술될 수 있는 알고리즘을
논리적 결함 없이 빠르게 구현으로 옮길 수 있다는데 있습니다. 그와 같은
재귀적 구현의 장점 까지도 애써 무시하며 비재귀를 강조하는 것은
아닙니다. 이미 실질적인 모든 가능성을 고려했을 때 안정성이 확보된다면
오히려 재귀적 호출이 프로그램의 가독성이나 유지 보수에 탁월함을
말씀드린바 있습니다 (링크된 글을 보시기 바랍니다). 하지만, 그렇지 않은
경우, 말씀하신대로 성능 문제는 감안하지 않더라도, 프로그램이 임의의
입력에 대해 비정상 종료할 수 있는지 혹은 어차피 맡은 바 기능을
수행하지 못하더라도 스택에 대한 제어를 통해 프로그램의 정상적인 수행을
유지할 수 있는지 여부는 매우 큰 차이입니다.

어차피 스택이 고갈된 상태라면 재귀적 구현도 functionality 를 유지할
수 없습니다. 차이는 앞서 말씀드린 것처럼, 좀 더 우아하게 프로그램의
비정상적인 행동을 막을 수 있다는데 있습니다. 최소한, "엄마! 여기에
10000000을 입력하니깐 옆집 컴퓨터가 멈췄어" 라는 이야기는 나오지는
말아야 한다는 것입니다.

이야기를 자꾸 성능 문제로 가져가셔서 논점을 흐리시지 않았으면 합니다.
이미 성능이 매우 민감한 지극히 특수한 분야를 제외하고는 단순히 성능
때문에 재귀를 비재귀로 바꿀 필요는 없다는 사실에는 충분한 동의가
있었다고 봅니다.

예를 들어, 충분한 검증 없이 재귀적 알고리즘으로 트리 탐색을 하는 보안
관련 프로그램이 악의적으로 전송돼온 테이블을 받아 탐색을 시도하다가
stack overflow 로 프로세스 전체가 종료되는 일은 막아야 한다는 것이 제
이야기의 논점입니다. 이는 결코 성능에 대한 이야기가 아닙니다. 앞서
언급하신 "게으른 최적화" 가 프로그램의 잠재적 위험성까지 무시하며
게으르게 하자는 뜻은 아니라고 봅니다.

다시 한번 말씀드리지만, 제가 드리는 말씀의 논점은 성능을 위한 최적화가
아닙니다.

안정성은 제일 처음에 고려하십시오. 그것이 당신의 코드를 사용하는
사용자가 해킹을 당하는 불미스러운 일이나 패치를 받아 설치해야 하는
번거로운 일을 막는 데 기여할 것입니다.

분명, 님께서도 단지 성능만을 위해 무조건 재귀를 비재귀로 바꾸는 것은
옳지 않지만, 프로그램이 가질 수 있는 잠재적 위험성까지 무시하면서
재귀를 유지하자고 주장하시는 것은 아니라고 봅니다.

그렇지 않습니다.

비재귀로 구현할 경우 스택 할당과 해제를 implementation 이 아닌
프로그램이 하게 됩니다. 즉, malloc 등의 일반적인 메모리 할당 절차를
통해 할당된 메모리를 스택으로 사용하는 것이기 때문에 재귀의 깊이가
깊어짐으로써 발생할 수 있는 stack overflow 를 사전에 감지할 수 있다는
장점이 있습니다.

입력값을 검사하는 방법은 앞서 말씀드린 재귀의 깊이를 함수 인자 등으로
제한하는 방법과 근본적으로 다르지 않습니다. 즉, 실행 환경의 변화에
따라 동적으로 적응하지 못하는 불완전한 해결책입니다.

물론 사실 저 말 자체가 님의 주된 논지와 거리가 있죠-_- 님은 성능 문제가 있든 없든 비재귀 형태로의 전환이 좋다고 말씀하시면서 profiling을 통해 증명할 경우는 재귀 형태를 유지해도 좋다고 말씀하시니...

보고자 하시는 부분만 잘라 보시면 그와 같은 오해가 가능합니다.

profiling 을 언급한 원글은 이 부분입니다.

A = "profiling 을 통해 성능에 대한 기여도가 중요하지 않음을 확인했음"
B = "실질적인 상황에서도 재귀의 깊이가 깊지 않다는 것을 확인했음"

이라고 할 때, 제가 개인적으로 재귀적 구현을 비재귀로 바꾸지 않는
상황은 A 와 B 가 모두 참인 경우입니다.

즉, 인용하신 부분은 A, B 두 경우 중 하나라도 만족되지 못하면 비재귀로
바꾸어야 한다는 이야기를 하고 있는 부분입니다.

A 조건과 B 조건이 있으면 C가 됩니다.
...
...

그러므로, A 조건이 있으면 C가 됩니다.

이렇게 써 놓으셨으면서 보고 싶은 부분만 본 거라고 하면 곤란하죠-_- 머, 이 정도 실수는 충분히 할 수 있는 일이니 그냥 실수라 인정하시면 넘어갈 수 있는 일일 텐데요.

해당 부분으로 오해를 일으켰다면 사과 말씀드립니다. 님이 생각하고
계시는 문맥에서의 profiling 이 제가 생각하고 있던 profiling 과 다름을
보다 분명히 밝히지 못했습니다. (profiling 이 배타적으로 성능에 대한
factor 만을 보고해 주는 것은 아닙니다. 예를 들어, profiler 중 하나인
gprof 역시 특정 함수에 대해 재귀가 아닌 방식으로 호출된 횟수와 재귀로
호출된 횟수를 구분해 보여줄 수 있습니다. 다시 말해, 함수의 재귀 호출
깊이를 실험적으로 파악하고자 할 때도 profiler 가 중요한 역할을 할 수
있습니다.)

신기한 이야기입니다. 어떻게 C 프로그램이 inline asm 도 쓰지 않고
비재귀 방식으로 변환한 것처럼 이식성의 손상도 없이 허용되는 재귀
호출의 깊이를 미리 예측할 수 있을까요? 저는 이 이유 때문에 재귀를
비재귀로 바꾸자고 주장하고 있는 것입니다.

재귀 호출의 깊이만이 stack overflow 의 critical factor 가 아니라는
뜻입니다. 다시 말해, 재귀 호출의 깊이 만으로 stack overflow 의
위험성을 고려하는 것은 반쪽 짜리 방법이라는 뜻이었습니다. 이 역시
지극히 재미없는 원론적인 이야기일 뿐입니다.

C 언어라는 틀에서는 일단 "stack overflow 를 exception 으로 처리해주는
언어" 라는 가정은 배제됩니다.

그리고, 제가 말씀드린 것은 80%, 90% 같은 정량적인 접근이 아니라
프로그램의 안정성을 보장할 수 있느냐 없느냐의 원칙적인 접근입니다.

정리하자면, 님이나 저나 많은 부분에서 같은 이야기를 하고 있는 것에
지나지 않습니다. 즉, 님께서는 일반적으로 생각하는 것보다 많은 경우에
stack overflow 의 위험성은 크지 않다. 따라서 (결국, stack overflow 의
위험성이 배제되는 경우에) 재귀 호출을 써도 무방하다는 주장을 하고 계신
것이고, 저는 stack overflow 의 위험성이 염려되면 재귀를 비재귀로
바꾸는 것이 좋다라는 주장을 하고 있는 것입니다.

이 두 주장의 차이는 저는 최소한 재귀-비재귀 변환처럼 이식성을
유지하면서 stack overflow 를 예방할 다른 방법을 찾기 어렵다고 주장하고
있는 반면, 님께서는 뭔가 알 수 없는 정체 불명의 방법으로 stack
overflow 가 의심되는 상황에서조차 재귀호출을 유지하면서 예방을 할 수
있다고 주장하고 계신 것입니다.

이제 서로의 논점을 충분히 정리했다면, 그 비법에 대한 기술적인 이야기로
논점을 옮겨 갔으면 합니다.

비법? 그냥 getrlimit 쓰면 되는 거 아닌가요? 그렇게 말씀하시니 제가 착각하고 있나 하는 생각까지 듭니다만...

그리고, 찾아보니까 링크 타임에 stack size를 결정할 수 있는 게 맞더군요. 그렇다면 굳이 재보지 않아도 되는 일이라 여겨집니다만? Makefile에서 결정할 수 있는 문제이니만큼 이식성 문제는 아니죠.

거듭 말씀드리지만 재귀호출을 써도 안정성은 얼마든지 보장할 수 있습니다. 실제로 MySQL 등의 오픈소스 DB의 코드를 보시면 아시겠지만 재귀호출 무진장 많이 사용됩니다. 그래도 stack overflow 안 납니다.

윗 글은 제가 올린 것입니다.

손님 모드가 허용되니 이런 불편이 있군요. :-(

실수로 같은 글이 2개가 포스팅되었습니다. 관리자님께서 적절히
처리해 주시기 바랍니다.

저라면 상황별로 다른 선택을 할 것 같습니다.

1. 개인 프로젝트: 성능보다는 깔끔하고 우아한 코드가 더 추구할 가치가 있다고 생각하니 재귀호출을 사용.
2. 회사 업무: 대게의 경우 납기일에 맞추는 것이 최우선. 그러므로 이 경우에도 조금이라도 덜 손이 가는 재귀호출 사용.
3. 내가 산 소스: 대게의 경우 소스를 볼 수 없겠지만, 철저하게 소비자의 입장에서 성능이나 안정성 면에서 조금이라도 이익인 비재귀호출로 만들어졌기를 희망.

다소 모순적이지만 둘다 필요해서 있는 것인데, 굳이 통계치까지 들먹여가며 쓰지 말라고 몰아세울 필요는 없을 것 같습니다. 쓸 곳이 없더라도 프로그래머에게 매우 기본이 되는 사항이니 알아두는 것은 확실히 도움이 되고, 또 살다보면 예외적인 상황에 처하는 경우도 많습니다. 또 압니까? 어떤 사람의 사고구조는 재귀호출을 생각해내기가 매우 어려운 대신 스택 중심의 사고는 매우 잘 되는 사람이 있을지도 모르지요. 공부하는 사람에게는 모든 가능성이 열려 있는 것이 좋다고 생각합니다.

이 부분은 문제가 될 것 같네요 8)

논의가 한 페이지를 넘어갈만큼 지리해졌으니, 좀 정리를 하고
말씀드리겠습니다.

처음 제가 이 쓰레드에 포스팅을 하게 된 계기는 재귀 호출의 비재귀
구현이 일종의 편법(?)에 가까운 방법이라는 글을 보았기 때문입니다.
신기하게도 그와 매우 유사한 논의를 오래 전에 제 홈페이지 게시판에서
했었고, 그때 썼던 글이 조금이라도 도움이 될 것 같은 다음에 링크를
했습니다. 그렇게 링크된 글은

1. 재귀의 비재귀로의 전환은 항상 가능하다.

2. 재귀 알고리즘의 비재귀 구현이 편법으로 볼 만큼 부정적인 것은 아니다.

3. 비재귀 구현의 장점은 함수 오버헤드를 피하는 성능 문제 이외에도
시스템 자원에 대한 제어를 직접할 수 있다는 것이다.

4. 일반적으로 재귀 알고리즘은 재귀로 구현하는 것이 가장 자연스럽다.
그럼에도 다음과 같은 두 가지 경우에는 비재귀로 전환할 필요가 있다.
4-1. 프로그램의 성능에 치명적인 영향을 준다고 판단되는 경우
4-2. 프로그램의 안정성에 치명적인 영향을 준다고 판단되는 경우

대충 이와 같은 내용을 담고 있는 것입니다.

이때 단지 "성능"에 대한 기우 때문에 님께서 재귀를 비재귀로 구현하는
것은 불필요하다는 글을 올리셨고, 저는 재귀를 비재귀로 바꾸는 것에는
성능 뿐만 아니라 "시스템 자원의 직접 제어"라는 장점도 함께 고려되어야
한다는 글을 올렸습니다.

그리고 한참을 지나 이제 문제점은 다음 2가지로 줄여 볼 수 있다고
생각합니다.

- (저는 별로 이야기 거리로 삼고 싶지 않은) "대부분"의 프로그램이
재귀호출에 대해 안전하냐, 그렇지 않느냐의 문제

- 프로그램의 안정성에 주는 영향이 "있다고" 확인되는 경우에도 비재귀
변환을 하지 않고 재귀로 둘 것인가 하는 문제

이식성 이야기만 잘라내어 반박하고 계시지만 이식성의 문제만 있는 것은
아닙니다.

- get/setrlimit 함수를 사용할 경우, 스택 사용을 추적하는 것이 비재귀
구현을 사용하는 것보다 결코 쉽지 않습니다. 예전에 저도 제가 만든
프로그램에 frame pointer 와 stack pointer 를 추적해 다음 재귀 호출이
stack overflow 를 일으키는지를 검사해주는 함수를 만들어 사용했었으나,
실제 그 함수가 갖는 지극히 이식성 없는 부분들과 활용도의 한계에
부딪혀 없애버리고 말았습니다. 지금 당장이라도 geet/setrlimit 함수로
그와 같은 기능을 하는 함수를 만들어 보시기 바랍니다. 단지,
get/setrlimit 함수가 제공되어야 한다는 가정 이외에도 수많은 지저분한
가정에 의존하는 너덜거리는 프로그램이 된다는 것을 확인하실 수 있을
겁니다.

- 또한, (반복해서 드리는 말씀입니다만) 설사 그와 같은 함수를
성공적으로 구현해 재귀 호출의 가능성을 검사한다고 하더라도 stack
overflow 가 예측되는 상황에서 다시 재귀를 거슬러 돌아오는 것이
비재귀 구현에서 뒷정리를 하는 것보다 여러 면에서 낫지 않다는
것입니다. 이미 제가 최소한 3가지 다른 방법을 말씀드렸으나 그 3가지
모두 그렇습니다.

반면, 비재귀 방식의 경우, 재귀를 비재귀로 바꾸는 수고는 분명히 있지만,
동적 메모리 할당이라는 지극히 언어 표준의 틀 안에서 시스템 자원에 대한
관리를 할 수 있으며, 재귀 호출 모사를 진행하다가 문제가 되어 되돌리는
경우에도 breack 문 하나와 함수 호출 하나로 모든 뒷정리가 된다는 장점이
있습니다.

일평생 "전체 분야"의 "전체" 소프트웨어 개발에 참여하는 프로그래머가
몇이나 된다고 생각하십니까? safety-critical 분야에서 주로 개발을 하게
되는 개발자와 일반 client-side 응용 프로그램을 개발하는 개발자가
바라보는 "대부분"은 다를 수 밖에 없으며, 달라야만 합니다. 예를 들어
설명해 보겠습니다. 미국, 유럽, 일본 등의 자동차 생산 업체에서 자동차에
들어가는 코드를 개발할 때 사용하는 대표적 가이드 라인인 MISRA-C 는
재귀호출의 사용을 엄격히 "금지"하고 있습니다. 참고로 이 MISRA-C 는
자동차 업계 뿐 아니라 안전이 중요시되는 다른 분야에서도 꾸준히
채택되고 있습니다. 추가로 NASA 에서 사용하는 코드를 작성할 때 지켜야
하는 문서에도 재귀호출을 "금지"하고 있습니다. 결론적으로, 소프트웨어
"전체" 분야에서 이와 같은 코드들이 차지하는 비중이 적고, 그 탓에 재귀
호출이 프로그램의 안정성에 치명적 영향을 줄 수 있는 가능성이
줄어든다고 해서, 재귀의 비재귀 구현이 갖는 가치가 줄어드는 것은
아닙니다. 즉, 전체적으로 보았을 때 20% 확률로 문제를 일으키든 80%
확률로 문제를 일으키든, 자신이 작성하는 코드에서 0% 라면 무의미한
변환이며, 100% 라면 중요한 변환이 될 수 있는 것입니다.

이와 같은 까닭에 "대부분이" 얼만큼인지에는 전혀 관심이 없으며, 권고의
문제가 된다면 앞서 언급한 코딩 가이드 라인처럼 관점이나 분야를 좁혀
권고의 내용과 무게를 달리하면 끝날 문제입니다. 단지, 전체 소프트웨어의
20% 정도가 재귀 호출로 안정성에 문제를 가질 수 있다는 이유 때문에
MISRA-C 에서 "당신의 재귀 호출 코드는 20% 의 확률로 문제를 일으킬 수
있고, 따라서 당신이 개발한 프로그램을 탑재한 자동차는 12% 의 확률로
사고가 날 수 있습니다" 라고 권고할 수는 없는 노릇입니다. 유사하게
교육을 위한 교과서에서 기반 상황에 대한 뚜렷한 명시 없이 "재귀 호출을
힘들게 비재귀로 바꿀 필요 없이 그대로 사용해도 문제를 일으키지 않는다"
와 같은 일반적 내용을 담는 것도 부적절하다고 봅니다.

그런데도, 알 수 없는 이유로 님은 "대부분"의 구체적 논의에 대한 미련을
버리지 못하고 계신듯 합니다. :-(

다시 한번 말씀드리지만, 저는 그 "대부분"의 정량적 관점에는 전혀 관심이
없습니다. 또한, 제가 관심 없는 이유는 충분히 위에서 설명 드렸다고
생각합니다.

MySQL 구현에 관심이 없어 들여다보지 않았습니다만, MySQL 역시
지극히 극단적인 경우에도 stack overflow 가 일어나지 않음을 이론적 혹은
실험적 방법으로 보장받고 있거나, 혹은 프로그램이 사용하는 스택 크기에
대한 설정을 사용자에게 전가하거나 하는 방법을 취하고 있다고 봅니다.

또한, 무엇보다도 악의적인 사용자에 의해 시스템 전체에 구멍을 낼 수
있는 부분에 stack overflow 가 나도록 내버려 두지는 않았을 것이라
생각합니다 - 만약, 그와 같은 문제가 보고된다면 이를 "의도하지 않은"
버그로 간주해 해결하리라 믿어 의심치 않습니다.

"단지 자동차의 급발진 사고가 발생할 수 있다는 이유 때문에 변속기에
안전 장치를 다느니 차라리 자동차를 타지 맙시다."

"자동차 운전자가 사망할 가능성이 있다는 이유만으로 에어백을 다느니
차라리 자동차를 타지 맙시다."

와 무엇이 다른 주장인지요? 주장의 근거로 논리적 비약을 하고 계십니다.
제 주장은 "stack overflow 때문에 재귀호출을 써서는 안 된다"가 아니라
"stack overflow 가 치명적 결과로 이어질 수 있는 경우에는 (당연히 다른
부분에서도 주의해야 하고) 재귀 호출에도 주의해야 한다" 입니다. 이 둘의
차이를 짓지 못하는 이상 더 이상의 의미있는 논의는 불가능 합니다.

또 한번 주장의 근거로 논리적 비약을 하고 계십니다.

그와 같은 문제 때문에 고민해야 하는 경우도 있다는 것이 제 주장의
요지입니다. 즉, "항상" 그런 고민을 해야 한다는 주장도 일반화의
오류이지만, 그런 고민을 하는 것은 "항상" 시간 낭비라는 주장도 일반화의
오류입니다.

저나 님이나 자신의 생각에 확고함이 있는 상태에서 이미 논의가 서로를
설득하는 목적을 가지고 있다고는 생각하지 않습니다.

또한, 처음 링크한 글에서부터 마지막 글까지 재귀호출이 갖는 유용성과
가치를 무시한 적 없으며, 제가 강조하고 싶은 부분은 재귀적 구현과
비재귀적 구현 사이의 trade-off 가 필요하며, 그 기준으로 빼놓지 말아야
하는 요소 중에 하나가 재귀호출 결과로 프로그램의 안정성에 손상이 생길
수 있는지 또 그 손상이 얼마나 치명적일 수 있는지라는 것입니다.

다른 부분에 대한 논의를 또 다시 반복할 필요 없이, 님과 제 주장의
유일한 차이는, 님은 저와 달리 "그와 같은 문제가 될 수 있는 상황에서도
재귀 호출을 유지해야 한다" 는 주장을 하고 계신 것입니다. 다르게
표현하면, 비재귀의 장점이 빛을 발할 수 있는 순간에도 비재귀의 *dark
side* 만을 끄집어 내어 비재귀가 갖는 상대적 장점을 평가절하하고
계신다는 생각마져 듭니다.

이는 아마도 애초부터 재귀 호출의 실패가 치명적인 결과로 이어질 수 있는
분야에서 개발을 하지 않으시기 때문에 경험의 차이로 재귀 호출을
바라보는 태도에도 차이가 생긴 것은 아닐까 생각합니다.

이미 재귀-비재귀와 관련해서 당장 머리에서 끄집어 낼 수 있는 지식은 다
꺼낸 것 같습니다. 이제 시험이 끝나 :-) 밀린 일 진도를 따라잡을
시간이라 :-( 제 생각은 여기서 정리하려 합니다.

재귀-비재귀에 대한 평소 생각을 명확하게 정리할 수 있는 유익한
논의였습니다.

그럼...