또 다른 수준의 간접층
Another level of indirection
All problems in Computer Science can be solved by another level of indirection.
전산학의 모든 문제는 또 다른 수준의 간접층으로 해결할 수 있다.
- [[#people.butler-lampson#]]{버틀러 램슨}이 했다고 알려져 있지만, 사실은 데이비드 휠러가 한 말이다.
From: Beautiful Code
"전산학의 모든 문제는 또 다른 수준의 간접층(level of indirection)으로 해결할 수 있다"라는 유명한 인용구가 있다. 이 말은 1972년에 현대적인 개인용 컴퓨터를 예견한 바 있는 과학자 램슨Butler Lampson이 한 것으로 알려져 있다. 이런 인용구가 생각나는 상황은 흔하다. 예를 들어 정말로 대화하고자 하는 사람이 아니라 그의 비서와 이야기해야 할 때, 동쪽의 상하이나 방갈로어로 가기 위해 우선 서쪽의 프랑크푸르트로 가야 할 때 등등. 물론, 복잡한 시스템의 소스 코드를 조사할 때에도 이 인용구가 머리에 떠오른다.
– 17장. 371쪽.
But that usually will create another problem
끝으로 이 여정의 시작에서 언급한 인용구(전산학의 모든 문제는 또 다른 수준의 간접층으로 해결할 수 있다)에 대한 이야기를 좀 더 추가하고자 한다. 인용구의 출처는 램슨이라고 알려져 있지만, 사실 램슨 자신은 그것이 서브루틴을 창안한 휠러David Wheeler에서 비롯된 말이라고 밝힌 바 있다. 흥미롭게도 휠러는 그 인용구에 다음과 같은 또 다른 인용구를 붙여 놓았다: "그러나 그러면 또 다른 문제가 생기는 것이 일반적이다." 실제로, 간접과 계층화는 공간과 시간의 부담을 추가하며 코드의 가독성을 해칠 수 있다.
그러한 시간과 공간상의 추가부담은 그리 크지 않기 때문에 큰 관심사가 되지 못한다. 대부분의 경우 추가적인 포인터 참조나 서브루틴 호출에 의한 시간 지연은 전반적인 구조 개선에 비할 때 사소한 수준에 그친다. 사실 요즘의 현대적 프로그래밍 언어들은 추가적인 유연성을 얻기 위한 목적으로 일부 연산들의 경우 항상 하나의 간접층을 거치도록 하는 경향을 보이고 있다. 예를 들어 Java나 C#에서는 객체에 대한 모든 접근이 하나의 포인터 간접을 거치게 하는데, 이는 쓰레기 수거(garbage collection)를 위한 것이다. 또한 Java에서는 인스턴스 메서드에 대한 거의 모든 호출이 하나의 조회 테이블을 통해서 분배되는데, 이는 다른 클래스를 상속하는 클래스들이 실행시점에서 메서드를 재정의할 수 있도록 하기 위한 것이다.
(중략)
반면 코드의 가독성에 대한 간접의 영향은 아주 중요한 문제이다. 지난 50년간 CPU 속도는 엄청나게 빨라진 반면 코드를 이해하는 사람의 능력은 별로 발전하지 않았다는 점을 감안한다면 충분히 이해할 수 있을 것이다. 그래서 애자일(Agile) 프로세스 옹호자들은 오늘의 구체적인 요구가 아니라 미래에 생길 수도 있는 애매하고 명시되지 않은 요구사항들을 처리하기 위해 계층들을 도입할 때에는 아주 신중해야 한다고 조언한다. 성능 안티패턴을 논의하면서 스몰더스Bart Smaalders는 이에 대해 "계층은 케이크를 위한 것이지 소프트웨어를 위한 것이 아니다."라고 비꼰 바 있다.
– 17장. 385쪽.
From: 운영체제 아주 쉬운 세 가지 이야기
사람들은 컴퓨터 과학에서 모든 문제의 해법은 간접 계층(level of indirection)의 활용이라고 한다. 분명한 것은 이것은 사실이 아니다. 대부분 문제들의 해법일 뿐이다(그렇다. 이 문장은 여전히 강한 주장이다. 하지만 어떤 의미인지는 이해했을 것이다). 우리가 다뤘던 모든 종류의 가상화를 생각해 볼 수 있을 것이다. 예를 들어 가상 메모리나 파일이라는 개념을 단순히 간접 계층을 사용한다고 할 수 있을 것이다. LFS의 아이노드 맵도 분명히 아이노드 번호들의 가상화이다. 이와 같은 예제들에서 모든 참조들을 변경하지 않고도 자유롭게 자료 구조들(VM에서 페이지, 또는 LFS에서 아이노드)을 이동할 수 있게 하는 간접 참조의 능력을 볼 수 있기를 바란다. 물론, 간접 참조는 오버헤드를 추가한다는 단점도 갖고 있다. 다음에 문제를 만나면 간접 참조를 이용하여 해결해 보도록 하자. 하지만, 그 전에 사용할 때 발생하는 성능 오버헤드도 먼저 생각해 보자. Wheeler 가 남긴 유명한 말이 있다 "너무 많은 간접 계층이라는 문제를 제외하면, 컴퓨터 과학에 모든 문제들은 간접 계층을 더함으로서 해결할 수 있다."
– 43.5장. 600쪽.
From: Prefactoring
간접 지정
자주 인용되는 컴퓨터 과학의 법칙이 있다. '컴퓨터 과학의 거의 모든 문제는 또 다른 간접 지정 수준(level of Indirection)을 통해서 해결될 수 있다.' 혹자는 '지나치게 많은 간접 지정 수준 때문에 유지 보수에 문제가 발생할 수 있다'고 불평하기도 한다. 하지만 다른 여러 설계 특징들처럼, 간접 지정을 만드는 것은 나중에 추가하는 것보다 쉽다.
– 11장. 201쪽.
패러다임 불일치
때때로 내부적인 구현에 대한 패러다임과 여러분이 만든 인터페이스의 패러다임이 일치하지 않을 수 있다. 보통 이러한 차이점을 감추기 위해서 어댑터를 만든다.
– 11장. 206쪽.
참고문헌
- Beautiful Code / 찰스 페졸드 외 37 저 / 류광 옮김 / 한빛미디어 / 초판발행 2007년 12월 17일
- Beautiful Code - Chapter 17. Another Level of Indirection
- 운영체제 아주 쉬운 세 가지 이야기 [제2판] / Remzi H. Arpaci-Dusseau, Andrea C. Arpaci-dusseau 공저 / 원유집, 박민규, 이성진 공역 / 홍릉 / 제2판 발행: 2020년 09월 10일 / 원제: Operating Systems: Three Easy Pieces
- 프리팩토링 / 켄 푸 저 / 서우석 역 / 한빛미디어 / 초판 발행 2006년 10월 20일